TCP交互式数据流

1. 交互式数据流

1.1 实验配置：wireshark + ssh localhost

1.2 交互数据流

1.2.1 可能的交互数据流

一个字节的通信过程如下：

1.2.2 实际的交互数据流(延时确认/稍带ACK)

接收端 得到接收数据后，并不急于发送ACK给发送端！
接收端 首先延时200ms等待接收端是否有数据送回给发送端

1.3 抓包分析

报文1～3 4～6 7～9 10～12 13～15 分别为字节”date\n“的交互过程

单独分析报文1～3：
首先客户端口发送d字节给服务器端口
服务器端口发送回显字节以及d的ack
客户端端口发送ACK（延时200ms）

2. Nagle算法

2.1 算法定义

交互式数据流一个字节发送一个分组会加重网络负担!

Nagle算法要求在一条TCP连接上最多只能有一个未被确认的未完成小分组，在该分组ACK到达之前不能够发送其他的小分组，发送端需要收集需要发送的小分组，在接收端的ACK响应到来的时候将所有收集的小分组以一个大分组的形式发送出去。其中小分组被定义为小于MSS的任何分组

2.2 场景分析

在第1.3 节，键入”date\n“ 的数据流一个字节生成了一个分组注入到网络
这是因为使用了本机地址/局域网，网速很快！当我键入一个字节的时候，在极短的时间内就被处理完毕！

现在考虑广域网的场景，因为网络延时可能很大！第一个字节的ack传回来之前，我可能键入了多个剩余字符（而这些字符因为Nagle算法没有被发送到网络），这些字符将在下一次分组同时被注入网络

2.3 抓包分析

…缺少实验环境，贴图…
因为广域网延时较长，发送端字节累计，所以出现了多字节分组的情况
同时因为发送端有字节发送，发送端的ACK一般也不会因为延时确认阻塞

分组号	字节数
1	1
3	1
5	2
7	1
9	2
11	2
14	3
15	1
17	3

3. 延时确认和Nagle算法分析

3.1 延时确认解决的问题

优点：
把要发送的数据和要反回的ACK 绑定在一起，减少注入到网络的分组数
缺点：
增加ACK延时，一般为200ms

3.2 Nagle解决的问题

优点：
一次只注入网络一个分组，降低网络负担。它即适用于局域网，也适用于广域网
局域网数据处理快，一次注入一个分组不会产生瓶颈
广域网数据处理慢，一次注入一个分组，但是一个分组包含多个字节，一般也不会有大的问题

缺点：
某些场景需要同时注入网络多个分组，这时候需要禁用Nagle算法

3.3 Nagle算法和延时确认各自的关闭方法

https://blog.csdn.net/u010913001/article/details/85060689