TCP大包过不去了

一、大包过不去了的表现

工作遇到了几次TCP大包过不去了，表现主要是客户端软件卡在某一登录或初始化环节、浏览器无法获取到服务端上的图片等现象，使用ping命令检测，感觉网络是正常的，有时甚至遇到Windows下ping -l 1472 x.x.x.x 仍能ping通或增加-f选项强制不分片仍能ping通【具体原因，才疏不足，待大佬指点迷津】。

二、TCP协议之上下游衔接操作

在整个协议栈、和传输链条中，数据被封装、解封装过程，我并没搜索到优秀的答案，从某些软件后台日志和日常经验推测可能有以下的要点：
1. 发送端应用层
应用层把需要通过TCP传输的数据分（片）后交给TCP层。就所见过的一个应用后台日志来看，上层从128字节到256字节再到512字节…执行类似TCP慢启动方式逐渐增大切片尺寸，并将这些切片逐一交给TCP层，日志中看到最大可达32768字节，当然这应该是由程序员调用某种接口所决定的。
2. 发送端TCP层
接收上层应用交给的数据后，确认是否需要再次对数据进行分段，确认所用到的一句是，上层数据加上TCP头部长度、IP头部后，总长度与所要送出数据接口的MTU值进行比较，不大于该值即可。
之后计算TCP头的序列号、确认号、校验和，插入源目的端口号，完成TCP头部封装。
3. 中间网络
中间网络设备，根据路由信息转发该数据。
如果需要转发的TCP数据去除数据链路层【以太网/PPP/HCL
C /帧中继】头部后总长度不超过该接口的MTU，则直接转发，如果超过，则分片转发。
如果下游某网络设备接口MTU值小于某个被分片后数据的大小的话，受IP头部分片偏移字段不能被更改影响，该数据不能被再次分片，只能被丢弃，而丢弃的一个分片会导致该分片所属的原始IP数据包需要被完整的重传，进而进一步加重源目的段即网络负载。
4.目的端
尚不清楚目的端应用层是否需要对TCP提交报文重新组成大的分片在进行处理。
中间网络进行IP分片处理的数据包，只有在目的段才能被组装。

三、根因和一般的处理方式

1.根因
源端TCP层根据源端的出接口MTU，确定了TCP MSS值的大小，直接导致了数据包IP及以上的大小是该接口的MTU，通常为1500字节，如果遇到中间不支持网络分片且MTU小于1500的设备接口，则数据将被丢弃，当源端不能感知时，直接导致应用出现问题。还有一种情况是，中间传输环节对数据进行了修改，增加一层或多层协议封装，导致数据"MTU"计算部分大小超出下游设备接口MTU，导致丢包。
2.处理方式之网络设备
在支持调整通过流量TCP MSS值的设备的出接口上配置相应命令，可以将通过接口送出的TCP SYN包中的TCP MSS修改成指定数值，使得双方在TCP建链过程中，协商一个较小的TCP MSS值，进而使得双方通信TCP数据包长得以减少。
3.处理方式之终端
在终端上可以通过命令（比如Windows的netsh interface ipv4 set interface “本地连接” mtu=1482 strore=active，Linux下ifconfig eth0 mtu 1482临时修改）修改某个接口的mtu值，mtu值修改后，通过该接口送出的TCP流量的TCP MSS值会同时受到影响。