UDP
长度字段：在UDP报文段中的字节数（首部加数据）
检验和：接收方检查报文段中是否出现了差错，计算时，除了UDP报文段还包括IP首部的一些字段。发送方的UDP对报文段中的所有16比特字的和进行反码运算，遇到溢出即被回卷。
如何计算检验和：
假定有3个16比特的字：
将结果反码运算得到最终结果，即为检验和。接收方将包括检验和的4个16比特字加在一起，若没差错则全为1。
为什么UDP首先提供了检验和：
1）不能保证源和目的之间的所有链路都提供差错检测。
2）但它对差错恢复无能为力，只能丢弃或交给应用程序并警告。
可靠数据传输原理
为上层实体提供的服务抽象：数据可以通过一条可靠的信道传输，所有数据按照发送顺序进行交付。底层信道将不会对分组重排序。
构造可靠数据传输协议（reliable data transfer protocol）
1）经完全可靠信道
所有分组从发送方流向接收方，接收端无需提供任何反馈信息给发送方
2）经具有比特差错信道
基于重传机制的rdtp称为自动重传请求协议（Automatic Repeat request，ARQ）
ARQ协议中还需另外三种协议功能处理比特差错：
差错检测（检验和）、接收方反馈（ACK和NAK）、重传
当发送方处于等待ACK或NAK的状态时，它不能从上层获得更多的数据。发送方将不会发送一块新数据，除非发送方确信接收方已正确接收当前分组。
如果一个ACK或NAK分组受损，发送方无法知道接收方是否正确接收了上一块发送的数据。
处理受损ACK和NAK：
在数据分组中添加一新字段，让发送方对其数据分组编号，即将发送数据分组的序号（sequence number）放在该字段
3）经具有比特差错的丢包信道
怎样检测丢包以及发生丢包后该做什么？让发送方负责检测和恢复丢包工作：
至少等待这样长时间确定丢包：发送方与接收方之间的一个往返时延加上接收方处理一个分组所需的时间。发送方选择一个时间值，以判定可能发生了丢包。
发送方重传：一个数据分组丢失、一个ACK丢失或者该分组或ACK过度延时。
实现基于时间的重传机制，需要一个倒计数定时器，在一个给定的时间量过期后，可中断发送方。
发送方需要做到：
每次发送一个分组（包括第一次分组和重传分组）时，便启动一个定时器
响应定时器中断
终止定时器
解决流水线的差错恢复
1、GBN（滑动窗口协议）
那些已经被发送但还未确认的分组的许可序号范围被看成是一个在序号范围内长度为N的窗口。
GBN发送方必须响应三种类型的事件：上层的调用、收到一个ACK、超时事件。
基于事件的编程
协议栈中实现该协议可能是以各种过程形式出现，每个过程实现了在响应各种可能出现的事件时要采取的动作。
这些过程要么被协议栈中的其他过程调用，要么作为一次中断结果。
在发送方，这些事件包括：来自上层实体的调用、定时器中断、报文到达时来自下层的调用。
2、选择重传协议
1）GBN协议潜在地允许发送方用多个分组“填充流水线”，避免了停等协议的信道利用率问题。
2）单个分组的差错会引起CBN重传大量分组。
通过让发送方仅重传那些它怀疑在接收方出错（即丢失或受损）的分组而避免了不必要的重传。
对于哪些分组已经被正确接收，哪些没有，发送方和接收方并不总能看到相同的结果，意味着发送方和接收方的窗口并不总是一致。
窗口的长度必须小于或等于序号空间大小的一半。
在高速网络的TCP扩展中，最长的分组寿命被假定为大约3分钟，避免分组序号重用。
TCP
1、TCP连接
1）中间路由器对TCP连接完全视而不见，它们看到的是数据报，而不是连接。
2）TCP连接提供的是全双工服务，也总是点对点的。
2、TCP报文段结构（数据字段的最大长度为1460字节）
3、序号和确认号
TCP把数据看成一个无结构的、有序的字节流。
序号是建立在传送的字节流之上，而不是建立在传送的报文段的序列之上。
一个报文段的序号是该报文段首字节的字节流编号。
4、估计往返时间
报文段的样本RTT：从某报文段被发出（即交给IP）到对该报文段的确认被收到之间的时间量。
在任意时刻，仅为一个已发送的但目前尚未被确认的报文段估计SampleRTT，为了估计一个典型的RTT，采取某种对SampleRTT取平均的方法。一旦获得一个新的SampleRTT时，更新EstimatedRTT：
EstimatedRTT =（1-a）* EstimatedRTT + a * SampleRTT（a的参考值为0.125）
5、测量RTT的变化
RTT的偏差DevRTT，用于估算SampleRTT一般会偏离EstimatedRTT的程度：
DevRTT =（1-b）* DevRTT + b * | SampleRTT– EstimatedRTT |
该值是一个SampleRTT与EstimatedRTT之间差值的指数加权移动平均（EWMA）
6、设置和管理重传超时间隔
应大于等于EstimatedRTT，所以设为EstimatedRTT加上一定余量。
当SampleRTT值波动较大时，余量大些；波动较小时，余量小些。
TimeoutInterval = EstimatedRTT + 4 * DevRTT
推荐的初始TimeoutInterval值为1秒，当出现超时后，值加倍，以免即将被确认的后继报文段过早出现超时。
7、超时间隔加倍
每当超时事件发生时，TCP重传具有最小序号的还未被确认的报文段。每次重传将下一次的超时间隔设为先前值的两倍，而不是用从EstimatedRTT和DevRTT推算出的值。
每当定时器在另两个事件（收到上层应用的数据和收到ACK）中的任意一个启动时，TimeoutInterval由最近的EstimatedRTT和DevRTT值推算得出。
8、快速重传
超时触发重传存在的问题之一是超时周期可能相对较长，增加了端到端时延。
发送当通常可在超时事件发生之前通过冗余ACK检测丢包。
如果TCP发送方接收到对相同数据的3个冗余ACK，说明跟在这个已被确认过3次的报文段之后的报文段已经丢失。此时，立即执行快速重传，即在该报文段的定时器过期之前重传丢失的报文段。
TCP是一个GBN协议还是一个SR协议？
TCP确认是累积式的，正确接收但失序的报文段是不会被接收方逐个确认的。
TCP发送方仅需维持已发送但未被确认的字节的最小序号。
这种意义下，TCP更像一个GBN协议。
区别：TCP实现会将正确接收但失序的报文段缓存，当某个分组丢失，TCP至多重传这一个分组，甚至不会重传。
选择确认允许TCP接收方有选择的确认失序报文段，而不是累积的确认，当其与选择重传机制结合时，TCP又像SR协议。
因此，TCP的差错恢复机制为二者的结合体。
流量控制
TCP为应用程序提供了流量控制服务（flow-control service），以消除发送方使接收方缓存溢出的可能性。
流量控制是一个速度匹配服务，即发送方的发送速率与接收方应用程序的读取速率相匹配。
TCP通过让发送方维护一个称为接收窗口的变量来提供流量控制，接收窗口用于给发送方一个指示——该接收方还有多少可用的缓存空间。
TCP拥塞控制
方法：让每一个发送方根据所感知到的网络拥塞程度来限制其能像连接发送流量的速率。
1）一个TCP发送方如何限制它向其连接发送流量的速率呢？
TCP连接的每一端都是由一个接收缓存、发送缓存和几个变量组成。
发送方跟踪一个额外的变量，即拥塞窗口，表示为cwnd。
在一个发送方中未被确认的数据量不会超过cwnd与rwnd中的最小值。
2）一个TCP发送方如何感知从它到目的地之间的路径上存在拥塞呢？
发送方的丢包事件（要么超时或收到3个冗余ACK）
给定调节cwnd值以控制发送速率的机制，TCP发送方怎样确定它应当发送的速率呢？
一个丢失的报文段表意味着拥塞，因此当丢失报文段时应当降低TCP发送方的速率。
一个确认报文段指示该网络正在向接收方交付发送方的报文段，当对先前未确认报文段的确认到达时，增加发送方的速率。
带宽探测。
3）当发送方感知到端到端的拥塞时，采用何种算法来改变其发送速率呢？
