文章目录
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