**
UDP
**
1.基于Internet ip协议
1)具有多路复用/分用
2)简单的错误校验机制
2.特点：会丢，非按序到达
3.无连接的：
1)发送方与接收方不需要握手
2)每个UDP段的处理独立于其他段
UDP存在的原因：
1)无需建立连接（减少延迟）
2)实现简单，无需维护连接状态
3)头部开销小
4)没用拥塞控制，应用可以更好的控制发送时间和速率
UDP应用场景：
主要应用在一些容忍丢失、对速率敏感的流媒体
那如何在UDP上实现可靠数据传输？
在应用层增加可靠性机制、错误恢复机制。
UDP段格式
UDP的checksum
1.首先，发送方讲段的内容视为16bit的整数；计算所有整数的和，进位加在和的后面，将得到的值按位取反，得到校验和；发送方讲校验和放入校验和字段
2.接收方计算所得到段的校验和；与发送方发送的校验和比对，不相等：检测出错误；相等，没有检测出错误（不一定就是正确的）；
TCP
如何把UDP的不可靠传输改为可靠数据传输呢？考虑以下几个问题：
1.底层信道传输过程中可能出现位翻转的错误，如何改进？
利用
校验和
检测位错误
2.检查出错误如何恢复
确认机制（ACK）：接收方显示地告发送方分组是否被正确接收
NAK（Negative Acknowledgment）：接收方显示地告诉发送方分组有错误，发送方收到NAK后，重传分组。
3.如果NAK/ACK在返回过程中丢失了或者坏掉了呢？
发送方只要没收到ACK就重传，但不能盲目重传，否则会产生重复确认的分组
4.如何解决重复分组的问题
序列号（sequence number）：发送方给每个分组增加序列号，接收方丢弃重复的分组。
5.我们真的需要NAK吗？
可以不要NAK，接收方通过ACK告知最后一个被正确接收的分组，在ACK消息中，显式地加入被确认分组的序号；如果接收方想要的分组，迟迟没有收到，则会不停朝发送方通过ack传递想要的分组序号；当发送方收到
三次
的冗余确认消息，就会立刻发送该分组内容（快速重传机制）。
6.如果发送方第一次的分组丢失了或者接收方的ack丢了，会出现什么情况？
会导致发送方一直处于等待状态，怎么办？设定定时器，超时重传机制
（此时的协议基本能够正确运行了，但是效率惨不忍睹，如何改善效率问题？流水线机制、滑动窗口协议）
流水线机制：允许发送方在收到ACK之前连续发送多个分组，所以我们需要：
1）更大的序列号范围。2）发送方与接收方需要更大的存储空间以缓存分组。
滑动窗口协议：GBN、SR
当发送窗口和接收窗口的大小都等于1时，就是停止等待协议。
当发送窗口大于1，接收窗口等于1时，就是回退N步协议（GBN-go back N）。
当发送窗口和接收窗口的大小均大于1时，就是选择重发协议（SR）。
其中，GBN是累计确认机制，对于乱序到达的分组直接丢弃，会导致网络中充满重传的信息
SR在接收方也有一个缓存，所以，乱序到达的分组会被缓存，改善了GBN中的重传；但发送方窗口的size和接收方缓存的size和要小于等于2的k次方，k是分组序列号的最大值。
TCP的拥塞控制
1.发送方限制发送速率
CongWin = LastByteSend – LastByteAcked
rate ≈ CongWin/RTT
其中，CongWin会根据网络堵塞动态调整；
2.如何判断网络堵塞？
发生loss事件，即timeout或3个重复ack
3.调节机制
1）AIMD，加性增—乘性减
每个RTT将COngWin增大一个MSS（最大报文段长度），发生loss后将CongWin降为一半
2）慢启动
1°TCP连接建立时，将CongWin设为1，每个RTT将其翻倍，知道达到loss事件前值得1/2；
2°通过借助threshold变量，当发生loss时，根据触发loss的原因不同分：
若由于受到3个冗余ACK，则ConWin切到一半
若由于timeout，则CongWin变为1
直到达到threshold后，线性增长（每次加1）