：在使用Linux作为服务器操作系统时，为了达到高并发解决能力，充分的利用机器性能，经常会进行一些内核参数的调整优化，但不合理的调整常常也会引起意想不到的别的问题，怎么识别并处理这样一些问题呢？

　　在上篇中（点击文章下方阅读原文查看），我们就一次Linux服务器丢包故障的处理过程，结合Linux内核参数说明和TCP/IP协议栈相关的理论，已经排除了防火墙拦截、连接跟踪表溢出、Ring Buffer溢出、netdev_max_backlog溢出这四种可能性。下篇将介绍其他的三种可能性，为大家带来完整的丢包故障定位方法及解决思路。

　　本次故障的反馈现象是：从办公网访问公网服务器不稳定，服务器某些端口访问经常超时，但Ping测试显示客户端和服务器的链路始终是稳定低延迟的。

　　从办公网访问服务器有多个客户端，是同一个出口IP，有少部分是始终能够稳定连接的，另一部分间歇访问超时或延迟很高

　　同一时刻的访问，无论哪个客户端的数据包先到达，服务端会立即处理部分客户端的SYN请求，对另一部分客户端的SYN包“视而不见”

　　那么，在上篇中排除了防火墙拦截、连接跟踪表溢出、Ring Buffer溢出、netdev_max_backlog溢出这四种可能性，后续还有哪些情况会导致Linux服务器丢弃数据包？

　　反向路由过滤机制是Linux通过反向路由查询，检查收到的数据包源IP是否可路由（Loose mode）、是否最佳路由（Strict mode），如果没有通过验证，则丢弃数据包，设计的目的是防范IP地址欺骗攻击。

　　1 - RFC3704定义的严格模式：对每个收到的数据包，查询反向路由，如果数据包入口和反向路由出口不一致，则不通过

　　2 - RFC3704定义的松散模式：对每个收到的数据包，查询反向路由，如果任何接口都不可达，则不通过

　　查看当前rp_filter策略配置，如果设置为1，就需要查看主机的网络环境和路由策略是否有几率会使客户端的入包无法通过反向路由验证。

　　从原理来看这个机制工作在网络层，因此，如果客户端能够Ping通服务器，就能够排除这个因素了。

　　半连接队列指的是TCP传输中服务器收到SYN包但还未完成三次握手的连接队列，队列大小由内核参数tcp_max_syn_backlog定义。

　　当服务器保持的半连接数量达到tcp_max_syn_backlog后，内核将会丢弃新来的SYN包。

　　通过dmesg可以确认是否有该情况出现：如果输出值中有“TCP: drop open request from”，说明半连接队列已被打满。

　　半连接队列的连接数量能够最终靠netstat统计SYN_RECV状态的连接得知。大多数情况下这个值应该是0或很小，因为半连接状态从第一次握手完成时进入，第三次握手完成后退出，正常的网络环境中这样的一个过程发生很快，如果这个值较大，服务器非常有可能受到了SYN Flood攻击。

　　tcp_max_syn_backlog的默认值是256，通常推荐内存大于128MB的服务器可以将该值调高至1024，内存小于32MB的服务器调低到128，同样，该参数通过sysctl修改。

　　另外，上述行为受到内核参数tcp_syncookies的影响，若启用syncookie机制，当半连接队列溢出时，并不会直接丢弃SYN包，而是回复带有syncookie的SYC+ACK包，设计的目的是防范SYN Flood造成正常请求服务不可用。

　　如上图所示，客户端发送的序列号为A的数据包A1因某些原因在网络中“迷路”，在一段时间没有到达服务端，客户端等待ACK超时后重发序列号为A的数据包A2，接下来的通信用尽了序列号空间，重新再回到A。此时，服务端等待的是序列号为A的数据包A3，而恰巧此时前面“迷路”的A1到达服务端，如果服务端仅靠序列号A就判断数据包合法，就会将错误的数据传递到用户态程序，造成程序异常。

　　PAWS要解决的就是以上问题，它依赖于timestamp机制，理论依照是：在一条正常的TCP流中，按序接收到的所有TCP数据包中的timestamp都应该是单调非递减的，这样就能判断那些timestamp小于当前TCP流已处理的最大timestamp值的报文是延迟到达的重复报文，可以予以丢弃。在上文的例子中，服务器已经处理数据包Z，而后到来的A1包的timestamp必然小于Z包的timestamp，因此服务端会丢弃迟到的A1包，等待正确的报文到来。

　　PAWS机制的实现关键是内核保存了Per-Connection的最近接收时间戳，如果加以改进，就可拿来优化服务器TIME_WAIT状态的快速回收。

　　TIME_WAIT状态是TCP四次挥手中主动关闭连接的一方需要进入的最后一个状态，并且常常要在该状态保持2*MSL（报文最大生存时间），它存在的意义有两个：

　　可靠地实现TCP全双工连接的关闭：关闭连接的四次挥手过程中，最终的ACK由主动关闭连接的一方（称为A）发出，如果这个ACK丢失，对端（称为B）将重发FIN，如果A不维持连接的TIME_WAIT状态，而是立即进入CLOSED，则无法重传ACK，B端的连接因此不能及时可靠释放。

　　等待“迷路”的重复数据包在网络中因生存时间到期消失：通信双方A与B，A的数据包因“迷路”没有及时到达B，A会重发数据包，当A与B完成传输并断开连接后，如果A不维持TIME_WAIT状态2*MSL时间，便有可能与B再次建立相同源端口和目的端口的“新连接”，而前一次连接中“迷路”的报文有可能在这时到达，并被B接收处理，造成异常，维持2*MSL的目的是等待前一次连接的数据包在网络中消失。

　　TIME_WAIT状态的连接需要占用服务器内存资源维持，Linux内核提供了一个参数来控制TIME_WAIT状态的快速回收：tcp_tw_recycle，它的理论依照是：

　　在PAWS的理论基础上，如果内核保存Per-Host的最近接收时间戳，接收数据包时进行时间戳比对，就能避免TIME_WAIT意图解决的第二个问题：前一个连接的数据包在新连接中被当做有效数据包处理的情况。这样就没有必要维持TIME_WAIT状态2*MSL的时间来等待数据包消失，仅需要等待足够的RTO（超时重传），解决ACK丢失需要重传的情况，来达到快速回收TIME_WAIT状态连接的目的。

　　但上述理论在多个客户端使用NAT访问服务器时会产生新的问题：同一个NAT背后的多个客户端时间戳是很难保持一致的（timestamp机制使用的是系统启动相对时间），对于服务器来说，两台客户端主机各自建立的TCP连接表现为同一个对端IP的两个连接，按照Per-Host记录的最近接收时间戳会更新为两台客户端主机中时间戳较大的那个，而时间戳比较小的客户端发出的所有数据包对服务器来说都是这台主机已过期的重复数据，因此会直接丢弃。

　　通过sysctl查看是不是启用了tcp_tw_recycle和tcp_timestamp，如果这两个选项同时开启，则有一定的概率会导致上述现象。我们这次的问题正是因为服务器做了这个配置，而客户端正是使用NAT来访问服务器，造成启动时间相对较短的客户端得不到服务器的正常响应。

　　如果服务器作为服务端提供服务，且明确客户端会通过NAT网络访问，或服务器之前有7层转发设备会替换客户端源IP时，是不应该开启tcp_tw_recycle的，而timestamps除了支持tcp_tw_recycle外还被其他机制依赖，推荐继续开启。

　　Linux提供了丰富的内核参数供使用者调整，调整得当可以大幅度提高服务器的解决能力，但如果调整不当，就会引进莫名其妙的很多问题，比如这次开启tcp_tw_recycle导致丢包，实际也还是为了减少TIME_WAIT连接数量而进行参数调优的结果。我们在做系统优化时，时刻要保持辩证和空杯的心态，不盲目吸收他人的果，而多去追求因，只有知其所以然，才能结合实际业务特点，得出最合理的优化配置。

　　作者 :田泉，CloudIn云英研发工程师，社区贡献者，曾就职人民搜索、等，从事基础平台架构、搜索服务端开发，支撑日均十亿量级搜索业务访问，加入CloudIn云英后，专注于网络及SDN领域，对网络架构、网络性能调优有丰富经验返回搜狐，查看更加多