TCP协议--应用程序的数据交换

最新推荐文章于 2024-07-11 08:30:00 发布

mybright_

最新推荐文章于 2024-07-11 08:30:00 发布

阅读量1k

点赞数

分类专栏： Linux系统/网络编程 Linux编程文章标签： Nagle算法交互数据流成块数据流

本文链接：https://blog.csdn.net/qq_29344757/article/details/78689857

版权

Linux系统/网络编程同时被 2 个专栏收录

66 篇文章 17 订阅

订阅专栏

Linux编程

62 篇文章 9 订阅

订阅专栏

《Linux高性能服务器编程》阅读笔记：

TCP报文段所携带的应用程序数据按照长度可分为2种: 交互数据和成块数据。交互数据仅包含很少的字节数据，使用交互数据的应用程序对实时性的要求高，如telnet、ssh等。成块数据的长度通常为TCP报文段允许的最大数据长度，使用成块数据的应用程序对传输效率要求高，如ftp。

下面分析一下比较简单的交互数据流：
使用telnet登录本机，并在shell命令提示符中执行ls，同时用tcpdump抓取过程中，客户端与服务器在数据交换部分(ls)的报文段:

$ sudo tcpdump -nt -i lo port 23
$ telnet 127.0.0.1     #在另一终端

输入登录名和密码后，输入ls命令，tcpdump抓到”ls”命令的数据包如下:

1. IP 127.0.0.1.56578 > 127.0.0.1.23: Flags [P.], seq 89:90, ack 512, win 350, options [nop,nop,TS val 1049914 ecr 1046410], length 1
2. IP 127.0.0.1.23 > 127.0.0.1.56578: Flags [P.], seq 512:513, ack 90, win 342, options [nop,nop,TS val 1049920 ecr 1049914], length 1
3. IP 127.0.0.1.56578 > 127.0.0.1.23: Flags [.], ack 513, win 350, options [nop,nop,TS val 1049920 ecr 1049920], length 0

4. IP 127.0.0.1.56578 > 127.0.0.1.23: Flags [P.], seq 90:91, ack 513, win 350, options [nop,nop,TS val 1049937 ecr 1049920], length 1
5. IP 127.0.0.1.23 > 127.0.0.1.56578: Flags [P.], seq 513:514, ack 91, win 342, options [nop,nop,TS val 1049937 ecr 1049937], length 1
6. IP 127.0.0.1.56578 > 127.0.0.1.23: Flags [.], ack 514, win 350, options [nop,nop,TS val 1049937 ecr 1049937], length 0


7. IP 127.0.0.1.56578 > 127.0.0.1.23: Flags [P.], seq 91:93, ack 514, win 350, options [nop,nop,TS val 1050080 ecr 1049937], length 2
8. IP 127.0.0.1.23 > 127.0.0.1.56578: Flags [P.], seq 514:516, ack 93, win 342, options [nop,nop,TS val 1050080 ecr 1050080], length 2
9. IP 127.0.0.1.56578 > 127.0.0.1.23: Flags [.], ack 516, win 350, options [nop,nop,TS val 1050080 ecr 1050080], length 0

10. IP 127.0.0.1.23 > 127.0.0.1.56578: Flags [P.], seq 516:915, ack 93, win 342, options [nop,nop,TS val 1050084 ecr 1050080], length 399
11. IP 127.0.0.1.56578 > 127.0.0.1.23: Flags [.], ack 915, win 359, options [nop,nop,TS val 1050084 ecr 1050084], length 0
12. IP 127.0.0.1.23 > 127.0.0.1.56578: Flags [P.], seq 915:977, ack 93, win 342, options [nop,nop,TS val 1050084 ecr 1050084], length 62
13. IP 127.0.0.1.56578 > 127.0.0.1.23: Flags [.], ack 977, win 359, options [nop,nop,TS val 1050084 ecr 1050084], length 0

(1) 报文段1携带1个字节的应用程序数据’l’，由客户端发给服务器。
(2) 报文段2是服务器对TCP报文段1的确认，同时回显字母’l’。
(3) 报文段3是客户端对报文段2的确认。
第4~6个TCP报文段是针对字母’s’的上述过程。
(4) 报文段7的2字节应用程序数据分别是客户端键入的回车符和流结束符(EOF，本例中是0x00)
第8~9报文段分别是服务端的确认/回显、客户端的确认。
(5) 报文段10携带服务端返回的客户查询的目录的内容(ls命令的输出)，包括该目录下文件的文件名及其显示控制参数
(6) 报文段11是客户端对报文段10的确认。
(7) 报文段12也是服务端返回给客户端的数据，包括一个回车符、一个换行符、客户端登录用户的PS1环境变量
(8) 报文段13是客户端对报文段12的确认。

上述过程中，客户端针对服务端返回的数据所发送的数据的确认报文段(报文段3、6、9、11、13)都不携带任何应用程序数据(length为0)，而服务端每次发送的确认报文(报文段2、5、8)都包含它需要发送的应用程序数据。服务端的这种处理方式称为延迟确认: 它不立即确认上次收到的数据，而是在一段延迟时间后查看本端是否有数据需要发送，如果有则和确认信息一起发出。因为服务端对客户端的请求处理得很快，所以它发送确认报文段的时候可以和数据一起发送。延迟确认可以减少发送TCP报文段数量。对于客户端来说，由于用户的输入速度明显慢于客户端程序的处理速度，所以客户端的确认报文段总是不携带任何应用程序数据。

上例是在本地回路(lo)运行的结果，在局域网中也能得到基本相同的结果，但是在广域网就未必如此。广域网的交互数据可能需要经受很大的延迟，并且携带交互数据的微小TCP报文段数量一般很多，例如一个按键输入就导致一个TCP报文段，这些因素可能导致拥塞发生。这就需要使用Nagle算法。

Nagle算法要求一个TCP连接的通信双方在任意时间都最多发送一个未被确认的TCP报文段，在该TCP报文段的确认到达之前不能发送其他TCP报文段。另一方面，发送方在等待确认的同时收集需要发送的微量数据，并在确认到来时以一个TCP报文段将它全部发出，这样就极大减少了网络上的微小TCP报文段的数量。该算法的另一个有点是自适应性: 确认到达得越快，数据也就发送得越快。