TCP报文分段导致的数据重传

引言：不同厂家生产的不同型号的计算机，它们运行着不同的操作系统，但它们仍然可以相互通信，因为它们的网卡驱动程序都支持TCP/IP协议族。

一、TCP/IP协议模型

图一 TCP/IP协议模型

      TCP/IP协议族是一个四层的协议系统，它有很多种协议，其中tcp和udp是两个最重要的传输层协议，它们的都使用IP作为网络层协议，tcp虽然使用不可靠的IP服务，可它却提供了一种可靠的传输层服务，使用tcp协议的应用有telnet,ftp,smtp,http等；udp为应用程序发送和接收数据报，与tcp不同的是，udp是不可靠的，它无法保证数据能安全的到达目的地，使用udp协议的应用有tftp,snmp等；IP是网络层上主要的协议，同时被tcp和udp使用，tcp和ip的每组数据都通过端系统和每一个中间路由器中的IP层在网络中进行传输；ICMP是IP协议的附属协议，IP层用它来与其他主机或者路由器交换错误报文和其他重要信息，尽管icmp主要被IP使用，但应用程序也有可能访问它，使用icmp的应用程序主要有ping。IGMP是internet组管理协议，它用来把一个UDP数据报多播到多个主机；ARP（地址解析协议）和RARP（逆向地址解析协议）是某些接口（如以太网）使用的特殊协议，用来转换IP层和数据链路层使用的地址。

二、以太网数据的分用

图二 以太网数据的分用过程

       当目的主机收到一个以太网数据帧时，数据就开始从协议栈中由底向上升，同时去掉各层协议加上的报文首部。每层协议盒都要去检查报文首部中的协议标识，以确定接收数据上层协议。

三、故障现象

       用户抱怨打开网页速度慢，引起这个的原因有很多，比如通道拥塞，端口错误率高，局域网中有广播风暴等；

四、排错过程

        先用ping工具来排查，ping两端的网关，不丢包，ping大包也不丢包，接着再ping服务器和客户端PC，也不丢包，从客户端ping服务器同样不丢包，检查往返路由，径路一致，初步分析可以排除网络层和数据链路层的原因。

       从tcp/ip协议模型来看，往上就到了传输层，远程登录到客户端PC，刷新一个网页大概要等20S左右，用户体验确实非常差。网页采用的是http协议，看来只有用wireshark抓包分析了。http协议使用的传输层协议是tcp，我们知道任何的tcp协议在传输数据之前都要进行TCP三次握手，下图是用wireshark抓到的原始数据，我们对刷新页面这个动作的tcp流进行跟踪。

图三 打开网页的TCP连接

从上图可以看出，第一行表示请求端发送了一个SYN包，指明了客户打算连接的服务器端口以及本端所能接收的MSS（最大报文段长度）值，第二行表示服务器回包进行应答和确认，第三表示客户端对服务器的回包进行确认，这个过程就是三次握手（three-way handshake)的过程，第8行，10行、12行表示了tcp重传。

从原始的数据包来看，三次握手后，出现了tcp重传，三次握手到重传成功的时间间隔大概是20S左右，和我们刷新网页等待的时间一致，只要找到tcp重传的原因，应该就可以解决这个问题。

图四 RTO时间是21.122秒

图5 TCP报文的长度536

Mss(最大报文长度)表示TCP传往另一端的最大块数据的长度。当一个连接建立时，每一方都有用于通告它期望接受的MSS选项（MSS选项只能出现在SYN报文段中）。如果一方不接收来自另一方的MSS值，则mss就定为默认值536字节。

观察这个tcp流，tcp重传的数据被分段了，每个段590byte，数据长536byte，数据+tcp头+ip头+二层头=536+20+20+14=590，而这个536恰好是MSS的默认值，前面已经说过mss值只在三次握手的sync包着带着，这意味着通信双方的mss值没有协商成功，mss自动降为默认值536byte，这是导致数据出现分段重传的原因。

五、解决办法

       如果把客户端的mss值改成和服务器端的mss一样，会否就不重传了呢？马上登录网关，在接口上启用 tcp adjust-mss 1024 这条命令，验证网页打开的速度，0.1S的延时，再次抓包，tcp的mss值变为1024，虽然出现了tcp分段，但不再重传。

图六 网页访问正常

为何TCP进行536的分段后会重传，而且重传了20多秒，难道和应用有关？