Linux设置tcp 交互数据流,3.6 TCP交互数据流

3.6　TCP交互数据流

前面讨论了TCP连接及其状态，从本节开始我们讨论通过TCP连接交换的应用程序数据。TCP报文段所携带的应用程序数据按照长度分为两种：交互数据和成块数据。交互数据仅包含很少的字节。使用交互数据的应用程序(或协议)对实时性要求高，比如telnet、ssh等。成块数据的长度则通常为TCP报文段允许的***数据长度。使用成块数据的应用程序(或协议)对传输效率要求高，比如ftp。本节我们讨论交互数据流。

考虑如下情况：在ernest-laptop上执行telnet命令登录到本机，然后在shell命令提示符后执行ls命令，同时用tcpdump抓取这一过程中telnet客户端和telnet服务器交换的TCP报文段。具体操作过程如下：

$ tcpdump –nt –i lo port 23

$ telnet 127.0.0.1

Trying 127.0.0.1...

Connected to 127.0.0.1.

Escape character is '^]'.

Ubuntu 9.10

ernest-laptop login: ernest(回车) #输入用户名并回车

Password:(回车)    #输入密码并回车

ernest@ernest-laptop:~$ ls(回车)

上述过程将引起客户端和服务器交换很多TCP报文段。下面我们仅列出我们感兴趣的、执行ls命令产生的tcpdump输出，如代码清单3-4所示。

代码清单3-4　TCP交互数据流

1. IP 127.0.0.1.58130>127.0.0.1.23: Flags [P.], seq 1408334812:1408334813,

ack 1415955507, win 613, length 1

2. IP 127.0.0.1.23>127.0.0.1.58130: Flags [P.], seq 1:2, ack 1, win 512,

length 1

3. IP 127.0.0.1.58130>127.0.0.1.23: Flags [.], ack 2, win 613, length 0

4. IP 127.0.0.1.58130>127.0.0.1.23: Flags [P.], seq 1:2, ack 2, win 613,

length 1

5. IP 127.0.0.1.23>127.0.0.1.58130: Flags [P.], seq 2:3, ack 2, win 512,

length 1

6. IP 127.0.0.1.58130>127.0.0.1.23: Flags [.], ack 3, win 613, length 0

7. IP 127.0.0.1.58130>127.0.0.1.23: Flags [P.], seq 2:4, ack 3, win 613,

length 2

8. IP 127.0.0.1.23>127.0.0.1.58130: Flags [P.], seq 3:176, ack 4, win 512,

length 173

9. IP 127.0.0.1.58130>127.0.0.1.23: Flags [.], ack 176, win 630, length 0

10. IP 127.0.0.1.23>127.0.0.1.58130: Flags [P.], seq 176:228, ack 4, win 512,

length 52

11. IP 127.0.0.1.58130>127.0.0.1.23: Flags [.], ack 228, win 630, length 0

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

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

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

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

【责任编辑：book TEL：(010)68476606】

点赞 0