分组交换总结
为什么电路交换（用于电话）不适合用于网络：
1.低效，由于电脑的通信往往是呈突发式的（你可能在很长一段时间打开网页但是什么都不做，也有可能在短时间内对这个网页进行很多操作），如果为每个通信都提供一条专用的链路，那么对于链路的利用率之低将是不可接受的，
2.多样的速率需求，电脑间的通信有的可能需要很高的速率，有的可能只需要很低的速率。如果我们的链路都是固定速率的链路，那么这样的链路可能几乎无法使用。
3.状态管理，电路交换需要管理每个通信的状态，这意味着大量的工作。
分组交换与之相比：
1.分组交换可以高效的利用珍贵的链路，允许大量的突发到的流共享整个链路。
2.分组交换可以使网络更加健壮，当网络中的一个交换机损坏时，由于所有交换机中都没有这个特定流的状态，也就是说一个特定流的状态不会由特定的交换机维护，我们可以简单地数据包发送到不同路径上。
注：为什么分组交换机需要缓冲区：1.当多个包同时到达交换机时，需要先将一个发送，将其他的缓存起来。2.当拥堵发生时，也需要将包先缓存起来。3.存储转发机制(store and forward)，核心思想为，一个网络节点（如路由器或交换机）必须接收完一个完整的、独立的数据单元（如一个数据包或帧），将其完整地存储在自己的缓冲区中，然后才能根据其头部信息，决定下一步要将其转发到哪里。使用存储转发，可以在网络节点处就进行错误检验，使之尽快早的发现已经损坏的垃圾数据包，避免其占用带宽和后续路由器的处理资源。
传播延迟（propagation delay）：t=l/c,l是电缆的长度，c是每个比特的传播速度。传播延迟只取决于这两者。
分组延迟（packetization delay）：这是从数据包的第一个比特被放置到链路上，直到最后一个比特被放置到链路上的时间。t=p/r，p是位的总数，r是单位时间可以放置多少比特到链路上的速率。分组延迟只取决于这两者。
端到端延迟：从我们在第一条链路上发送第一个比特到数据包的最后一个比特到达目的地的时间。通过求和每条链路的传播延迟和分组延迟得到。实际上，端到端延迟还必须包括包在交换机缓冲区的等待时间之和（queueing delay）。在端到端延迟中，只有它才是不确定部分。
播放缓冲区：对于一些应用程序，他们会使用播放缓冲区来吸收端到端延迟的不确定部分，以达到帮助应用程序以固定速率将视频流提供给我们的效果。播放缓冲区最大容量固定，当前缓冲数据量一开始值为最大容量，之后由字节接受速率和视频播放速率共同决定。当缓冲区大小为0时，播放的就是最新达到的数据。若此时接受字节曲线的斜率小于播放速率的斜率，那么就会被迫暂停。此时，应用程序会尝试更新更大的播放缓冲区，但是如果网速没有改善并且也不降低清晰度的话，两条曲线仍然会慢慢接近，然后再次被迫暂停。
分组交换机的队列模型（假设为FIFO模型，first in first out）：
队列缓冲区的字节数Q(t)=已经到达的字节数A(t)-已经发送的字节数D(t)
某个字节在队列缓冲区中的延误时间d(t)，在图中为A(t)和D(t)之间画一条直线，线段长度即为d(t)
A(t)的斜率为包在链路中传输的速率，D(t)的斜率为数据离开的速率
讨论分组交换对数据传输速率的影响：
为什么不在一条信息中发送整个包呢？我们可以看到，在右侧图中，一旦接受完第一个包就立刻发送第一个包到R2，然后R2接受完第一个包就立刻将其发送至R3。整个工作流程是流水线式的。而在图一中，必须等待所有数据都到达R1后才能发往R2，使得端到端延迟大大增加。（其实造成延迟增加的主要原因在于存储转发机制，为了避免这种增加，理论上，包越小越好，如果达到理想中最小的情况的话，就真的能像水流那样流动了，但是，为了避免巨量的头部开销，包又不能太小，包的大小应该适中）
讨论分组交换对提高链路利用率的影响：
统计复用：即按需分配资源，当有N条链路同时以速率R向路由传输数据时，不需要提供一条速率达到NR的链路，因为一条链路速率较高时可能另一条链路速率较低，一个低于NR的数据离开速率也能保证运行正常，如果提供速率达到NR的链路，反而是一种资源上的浪费。如果总的吸收数据的速率大于了数据离开的速率，缓冲区也可以吸收超过的部分。但由于缓冲区容量有限，数据到达速率过大时会丢包。
队列模型的三个特征：
1.突发性到达往往增加排队延迟。
2.Little's result：L=λd。L为队列平均占用，λ为到达率，d为该队列中客户的平均延迟。
3.泊松分布：虽然数据包到达本身并不是泊松分布，但一些过程如网页请求和新流是泊松过程。
分组交换机
以太网交换机（处理MAC地址，48位）：
1.检查每个到达帧的头部。
2.如果目的MAC地址在转发表中，将帧转发至正确的输出端口中。
3.如果目的MAC地址不在转发表中，它会向所有端口广播这些帧。
4.当交换机从一个端口（比如端口1）收到一个数据帧时，它会查看该帧的源MAC地址，然后在转发表中建立源MAC地址和对应端口之间的联系。
路由器（处理IP地址，32位）：
1.检查接受到的帧的目的MAC地址是否属于路由器，若不是，则丢弃它。
2.检查IP版本号和数据段长度。
3.减少TTL并更新IP头校验和。
4.检查TTL，如果为0则丢弃。
5.如果IP的目的地址在转发表中，则转发到正确的出端口。
6.寻找下一跳的路由的MAC地址。
7.将IP数据段又封装为以太网帧并发送到线路上。
路由器中的转发表：关键字为IP destination address，值为数据应该到达的下一个路由器接口的IP地址。此处关键字的匹配使用字典树来存储和查找最长匹配前缀，也可使用TCAM。TCAM的特征是三态和并行搜索，其搜索效率极高，缺点是成本更高。
输出队列交换机：上面的图是一个输出队列交换机，缓冲区位于每个输出端口。输出队列交换机不存在任何内部阻塞，数据包能够尽快通过交换矩阵，只需要在输出端队列中等待，是理论上效率最佳的交换机。但是当多个输入端口都向同一输出端口发送数据时，对交换矩阵和输出内存的速度要求最坏情况下达到了N*R，这在物理和经济上都是难以实现和接受的。
输入队列交换机：缓冲区位于每个输入端口。输入队列交换机对交换矩阵和输出端口的要求低。此时，交换矩阵在任何一个时间点，对于一个特定的输出端口，最多只有一个输入端口向他发送数据。但是，输入队列交换机的结构本身存在巨大的缺陷——线头阻塞。打个比方同一时刻只能有一辆车左转，如果多个车道的第一辆车都要左转，由于只有一辆车能够左转，除这辆车以外的车道就会发生堵塞，后面的车即使是想要直走也会被堵住，这是输入队列交换机自身结构的缺陷。
并且，在多个包想要发往同一输出端的情况下，由于这些包并不在同一队列中，此时交换机需要一个额外的，专门的调度器来决定首先应该发送谁。
总的来说，对于这样一个包，在输入队列交换机中，它位于输入端队列最前端；而在输出队列交换机中，它即将被输入端发往输出端端口。你可以看到，在两种情况中它被处理的方式其实等同。只不过对于前者，它在输入端端口排队等待一段时间t1，然后发送到达输出端耗费时间t2，最后被输出端处理耗费时间t3。而对于后者，它发送到输出端耗费时间t2，在输出端排队等待耗费时间t1，然后被输出端处理耗费时间t3。其实该有的步骤谁也没有比对方更加简略。但是，在整个全局下，在何处排队所造成的影响是巨大的。在输入端排队能使得交换矩阵和输出端口的压力大大降低，但是又引起了线头阻塞的问题。从上面可以看出，排队的时间在不论哪种交换机中都是不可避免的，而输出端交换机的安排能使每个包尽快的到他应该排队的地方去排队，这本应该是理想中最好的情况，但是，这对交换矩阵和输出内存的速度要求又是难以接受的。现实中，一种经过优化的输入队列交换机是更常用的。
使用虚拟输出队列对输入队列交换机进行优化：其核心机制为，每个输入端口为每个输出端口都设一个虚拟队列。这样，在一个输入端口中，买馒头的客户就不会耽误买包子的客户了。其主要性能瓶颈受调度器复杂度制约。优化后的输入队列交换机和输出队列交换机在理论上效率等同，实际上效率略低，却是更为经济的选择。
Rate guarantee：速率保证是网络节点（如路由器）对一个数据流做出的服务承诺。它承诺：“无论网络有多繁忙，我保证至少会以 R bps的速率，来为你这个数据流服务（即从你的专属队列中抽取数据并进行转发）。”
FIFO output queue的缺陷：对于先入先出输出队列而言，如果有多个流同时通过的话，那么发送数据包最多，发送速率最高的那个流将会占用最多的输出链路资源，这很容易助长一些糟糕的行为，因为对于一个流来说，最好的策略就是尽可能快的发送数据并挤掉其他流，针对这种情况可用两种方式进行优化。
优先级排队：当数据包到达时，永远优先服务最高优先级的队列。只有当所有更高优先级的队列都完全变空时，才会去服务次一级优先级的队列。因为很容易造成低优先级队列饿死，只有在高优先级流量较少时才能这样设计，事实上，纯粹的严格优先级排队在公共互联网上很少被直接使用。
加权公平排队：调度器不再是简单地看优先级，而是试图模拟一个“比特级的、流体化的公平排队系统”。（只能模拟，因为实际过程只能按包发送，不能按字节发送）它会为每个队列分配一个权重（Weight）。权重越高的队列，意味着它在“理想的”公平系统中应该获得更大比例的带宽。调度器会计算每个队列队头包的虚拟完成时间（Virtual Finish Time）。这个时间代表了“如果系统是完美的流体模型，这个包应该在什么时候被完全发送出去”。在每个发送时机，调度器总是选择那个虚拟完成时间最早的数据包进行发送。实际过程中模拟的效果会有一定误差，但并不影响总的效果。
delay guarantee：使用加权公平排队，我们可以选择队列的服务速率，理想情况下，如果我们已经有速率保证的话，足够我们得到一个期望的最坏端到端延迟了。但是这样的话无法避免短时间内涌入大量流量，然后发生丢包的情况，所以我们也需要约束到达流量。根据之前的模型，只要在任何时间段内，接收方这边都满足A(t + T) – A(t) <= B + r_1*T，那么接收方就可以做到避免丢包。那么，对于发送方而言，只要在任意时间段内发送的字节数都满足这个方程，那么发送方就可以断定：只要供给方能够保证提供大小为B的缓冲区，并且数据处理速率为r_1，那么就一定不会丢包。（因为在一个理想的、无干扰的物理介质中，同一个数据包内任意两个字节（或比特）的第一个比特位，到达同一位置的时间差，是恒定的。所以在T时间段内发送的字节数，一定能和未来接收方在某个T时间内接收的字节数对应）
我们用更加通用的参数σ和ρ来分别代替B和r_1，ρ对应允许的长期平均到达速率，σ对应允许的最大突发尺寸，就得到了网络演算中的(σ, ρ)流量约束的定义。ρ和σ分别是发送方经过预估后，期望得到的缓冲区大小和数据处理速率，路由器作为供给方，为发送方预留的B和r_1必须分别大于等于ρ和σ。
那么，现在我们只需要确保发送方发送的数据流符合(σ, ρ)模型，并且接收方知道发送方规定的σ和ρ并提供对应的保证就可以达到我们的目的了。
如何确保发送方发送的数据流符合(σ, ρ)模型——漏桶算法和令牌算法：
供给方如何得知需求方的ρ和σ——RSVP协议：RSVP 是用来承载和传递这份“流量规范”以及相关资源请求的信令协议（Signaling Protocol）。RSTVP协议本身不“设置”σ和ρ，而是作为一个“信使”，忠实地将应用程序定义的σ和ρ，传递给路径上的每一个路由器，以便它们能够做出正确的资源预留决策。
严格的延迟保证并未在网络上有过大规模的应用，因为需要维护大量的状态，不够经济，以及现有一些解决方法已经足够好。但是，其思想哲学影响深远。