Network

table {:toc} 问题的表面现象 问题的背景是这样的： 一个应用程序监听某端口的 UDP 包，发送者发送的 UDP 包比较大，有 65535 个字节。显然，发送者的 UDP 包在经过 IP 层时，会被拆分层多个 1460 字节长度的 IP 分片，经过网络传输之后到达接收方，接收方的网卡收到包后，在内核协议栈的 IP 层又将分片重新组合，生成大的 UDP 包给应用程序。 正常情况下，应用程序能准确无误的收到大 UDP 包，偶尔系统网络流量十分巨大的时候，会丢个别 UDP 包 ——这都在允许范围内。 突然有一天，即便网络流量不是很大的时候，UDP 包的丢包十分严重，应用程序几乎收不到任何数据包。 开始 debug 遇到这样的问题，第一反应有两种可能： 网络不通，数据包没送到网卡。 个别 IP 分片在传输中丢失了，导致接收方无法重组成完整的 UDP 包。 于是用 tcpdump 在 interface eth0 上抓包，出乎意料的是，抓到的 pcap 有完整的 IP 分片。用 wireshark 打开 pcap，wireshark 会自动把 IP 分片重组成 UDP 数据包，检查这个 UDP 包，数据完整无误。 那么现在能断定是应用程序自己出了问题吗？ 因为一直以来一个根深蒂固的想法是：既然抓到的 pcap 准确无误，所以数据包已经送到了接收方了，linux 内核只要把分片重组一下交给应用层就可以了，这个过程一般不会出错，所以应用程序没收到只能怪它自己咯？ 实际导致问题的原因 最终查明的原因是这台 linux 系统上有两个参数被修改了，当 IP 分片数量过大时，内核中分配给重组的缓冲区已满，导致之后的分片都被丢弃了。 ...