关于网络丢包的一种可能性分析
最近我在工作中经常遇到有些客户的网络传输性能不理想。 通过wireshark抓包后我发现经常会有稍大的包timeout需要重传，这个现象导致了网络传输效率的大幅下降，因此我对网络丢包方面进行了进一步的研究。
根据我的经验总结，网络丢包有两种情况。一种是在网络拥塞时的丢包，还有一种情况是网络包过大而被中间节点丢弃。由于客户的问题并非在网络拥塞，所以我研究了第二种网络丢包的情形。
我们知道在网络层中，MTU表示该网络设备所在网络支持的最大segment的传输大小。一般在Azure网络中最大的MTU支持到1500字节。那么每发出一个IP包，其大小必定小于等于1500字节。
让我们再回到TCP层面。在TCP三次握手的时候，客户端和服务器端分别会声明他们的MSS大小（所谓MSS就是每个TCP segment的最大字节数）。在握手结束时，TCP连接会使用双方声明的最小值。比如客户端声明MSS = 1200,
服务器端声明MSS = 1250, 那么这个TCP连接使用的MSS将会是1200。
那么TCP 层面的MSS 和IP 层面的MTU相互之间是怎么联系起来的呢？当TCP segement被转到IP层面并被网卡发出去之前，cpu会根据MTU设置的大小来对过大的TCP segement进行切分。比如一个TCP segment 的长度为1600， 1580 + 20（tcp 头长度） = 1600。那么如果MTU = 1500 , 在它被网卡传输出去之前它会被cpu 切分成1500和1xx 长度的网络包。如果网卡开启了TSO (tcp segment offload), 那么网卡会替代cpu做这个工作。
那么如果从客户端到服务器端有很多个网络节点。 其中一个网络节点的MTU小于1500，例如只有1380,那么当1500长度的网络包到达这个节点的时候，如果IP层允许fregmentation设置成no fregmentation。那么这个包就会被丢弃。如果设置成允许fregmentation那么这个IP包就会被拆分并传输。这个小MTU节点就是导致TCP包丢包的原因。
一般情况下在网络没有禁止ICMP的情况下用 ping -l 包长度 -n 1 命令不断增加包长度直至开始丢包，我们可以通过这种手段发现网络中最小的MTU是多少。
为了解决这样的丢包问题，我一般建议客户调小MSS 或者 MTU,以通过网络中最小MTU的节点。