超硬核TCP、UDP基础知识汇总2

注意事项：

1.TCP发送窗口是由对方发回的报文段(窗口大小，ack)设置的但是同一时刻发送窗口接收窗口大小未必相等(当接收方发回一个报文窗口大小改变但由于网络时延发送方窗口值可能不变)。

2.接收方应该有累计确认功能这样可以减小传输开销。

3.TCP是全双工通信，所以两端都有发送窗口和接收窗口。

3.2、发送缓冲区和接收缓冲区

发送窗口只是发送缓冲区的一部分，发送缓冲区通常包括发送方应用程序传送给发送方TCP准备发送的数据。这里面包括已发送但还未收到确认的数据和未发送但在发送窗口的数据以及未发送但不再发送窗口的数据。

接收缓冲区包含了按序到达但尚未被应用程序读取的数据，不按序到达以及尚未进入接收窗口的数据。

4、TCP的流量控制

4.1、流量控制介绍

发送方一次发送的字节数量不要太多要让对方来的及接收。接收方是通过调整滑动窗口来进行流量控制的。

•来看下面这样一个实例A为发送方，B为接收方。B的接收窗口由400字节。

•首先A向B发送了一个序号为1的100字节的数据(1~100)。此时B的接收窗口还剩300字节。

•然后A向B发送了序号为101的100字节数据(101~200).此时B的接收窗口还剩200字节。

•然后A向B发送了序号为201的100字节的数据(201~300)但是这个报文丢失了。

•此时B向A发送一个回复报文ACK = 201说明我已经接收1200字节的数据下一次要从201开始发。同时进行了一次流量控制即rwnd = 300也就是说B能接收300字节。所以A要发送201500的报文。

•A已经发送过201的报文了所以它连续发送301,401的报文此时他知道201发送失败进行超时重传。

•这时A收到了B成功收到401的报文下一次要从501开始发而且又进行了一次流量控制rwnd = 100还能接收100字节的数据。

•然后A又继续发送了一个序号为501的报文，然后A停止发送。然后收到了B返回的回复序号为601滑动窗口置为0的报文。

4.2、死锁问题及解决

接上文，过了一段时间后B的接收缓存又有了一些存储空间。这时候会向A发送一个报文下次发送的序号为601，rwnd=400滑动窗口。但是如果这个报文丢失那么就会造成A不知道B中滑动窗口更新的消息那么就永远不会向B发送报文。

解决方案：TCP为每个连接都设置了一个持续计时器。只要收到对方的零窗口通知，就启动该持续计时器：

持续计时器到期发送一个零窗口探测报文段，对方再确认这个探测报文段时给出现在的窗口值如果窗口值仍然是0，接收方确认报文方重新设置持续计数器；若窗口不是0，死锁的僵局便被打破了。

5、TCP的效率问题

5.1、TCP的3种发送时机

1.当发送缓存中达到双方约定的MSS时然后发送。

2.当URG = 1时立刻发送。

3.当发送方一个计时器期限到了就把当前已有的数据装入报文段发送出去(这个数据长度不能超过MSS)

5.2、TCP的效率问题

举例：

比如说Telnet远程终端协议客户端A向服务端B发送一个字符需要消耗41字节，B端服务器向A发送一个确认报文40字节，同时服务端要向客户端回显那一个字符。又是41字节，A客户端向B服务端发送一个确认报文40个字节我一共要交流2字节的数据我却用了162字节的报文利用率太低了。

解决方案：Nagle算法

发送方发送第一个字节，然后缓存剩下的数据字节。发送方收到对方发送的确认报文以后才把发送缓存中所有数据组装成一个报文段发送出去。当发送缓存中数据达到对方接收窗口一半或者达到MSS时立刻发送。

5.3、糊涂窗口综合症

当接收方缓冲区已满会向发送方发送一个rwnd为0的报文告诉对方不要再发了。当应用进程读取1字节接收缓存时，接收方向发送方发送rwnd = 1的报文此时发送方将1字节的数据打包成报文段发送给接收方。如此循环往复每次只能发一个字节。

解决方案：

接收方等待一段时间，使得接收缓存已有足够空间容纳一个最长的报文段，或者等到接收缓存已有一半空间；只要出现这两种情况之一，接收方就发出确认报文，并向发送方通知当前窗口的大小。