关于一个MSS值引发的疑案的思考

virtualadc在《负载均衡故障诊断：一个MSS值引发的疑案》中写到的这个故障现象引发了我的思考，我接触的很多项目中也都有负载均衡，但是却没有遇到过这个故障。现针对作者提到的故障，我在自己的实验环境中抓包测试了一下。对此提出自己的两点思考，仅此交流。
网络环境拓扑：

 抓包截图：


172.29.141.150为客户端地址
172.29.141.100为真实服务器地址
172.29.141.159为负载均衡上的VIP地址

负载均衡以旁路方式部署，但是没有做CLIENT NAT(网关是实网关没有设在负载均衡上） 。

访问流程：

1) 172.29.141.150访问 172.29.141.100
2) 负载均衡设备与客户端完成三次握手

3）然后负载均衡设备 向服务器172.29.141.100发起连接

4）服务器 与负载均衡设备完成三次握手。

我们发现两端的MSS值都是1440，没有出现差异，当然也没有发生原作者提到的故障现象。

补充：MSS就是TCP数据包每次能够传输的最大数据分段。为了达到最佳的传输效能TCP协议在建立连接的时候通常要协商双方的MSS值，这个值TCP协议在实现的时候往往用MTU值代替(需要减去IP数据包包头的大小20Bytes和TCP数据段的包头20Bytes)所以往往MSS为1460。通讯双方会根据双方提供的MSS值得最小值确定为这次连接的最大MSS值。

 

思考一：网络设备上的MTU影响
当两台远程PC互联的时候，它们的数据需要穿过很多的路由器和各种各样的网络媒介才能到达对端，网络中不同媒介的MTU各不相同，就好比一长段的水管，由不同粗细的水管组成（MTU不同 ）通过这段水管最大水量就要由中间最细的水管决定。网络通信中由于各家网络设备厂商提供的网络设备占用的MTU值不同，也会进一步减小MSS值。如果网络中有中低端路由器就需要在内网口和外网口都要配置tcp mss 值来保持传输的数据包大小统一，以避免某段网络因使用了PPPoE或NAT那些导致某些不能分片的应用而无法正常通讯。

注：NAT转换有时容易造成两端MTU值不一致。 

 

 

思考二、服务器或系统自身的MTU影响
网络层的IP协议会检查每个从上层协议下来的数据包的大小，并根据本机MTU的大小来决定是否作“分片”处理。操作系统也会根据本机MTU值自动将大小不符合要求的数据进行分包处理再进行传输，所以针对这些问题可以修改相应主机的MTU值：
windows下修改方法：
打开注册表找到如下位置HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces 在Interfaces下有多个子项，每个子项对应一个网卡，确定本机用来连接Internet的网卡，点击Interfaces上的子项，查看键值列表中的IPAddress项，如果IPAddress的键值就是你要找的IP，则该子项就是要找的网卡，然后进入该子项，在右边的窗口里按鼠标右键，选择“新建”->“双字节值”，输入名称“MTU”，按回车。再用鼠标双击“MTU”，弹出修改窗口在里面填入MTU的值，填写前请先把基数设为十进制。 设置好后，需要重启机器才能生效。

linux下修改方法：
# ifconfig eth0 mtu number

其中“number”为MTU的数值。修改完成后，可以用“ifconfig”命令来查看修改的结果。 为了不必每次都修改，我们可以在网卡配置文件中修改:
# vi /etc/sysconfig/network-scripts/ifcfg-eth0
　MTU=1000
然后保存退出。

还有其他可能引起这个故障的原因，暂未研究。欢迎大家指正交流！