UDP与TCP

**

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）