tcp server 无法连接问题排查

现象

客户端无法正常tcp连接服务，使用telnet连接ip:port失败，但是有时候又可以成功。

排除过程

之前以为是防火墙没有关的原因，设置iptables -t filter -I INPUT -p tcp –dport %d -j ACCEPT后，依旧无法连通，另外有时候又可以连通，如果是防火墙问题，肯定是无法连通的，所以排除防火墙问题。

为了确认网络确实是可以通的，tcpdump -i ppp108 -vv -w 108.pcap，拿到抓包数据放到wireshark打开看了下

确实是可以收到SYN包，但是服务端并没有回SYN+ACK，为什么不回呢？一般情况下，三次握手是在内核自动完成的，也就是SYN+ACK不是在应用层完成的。使用lsof -p看了下，端口是正常监听的。

网上看到一种说法：

有些服务器（当然客户端也可以）为了避免TIME_WAIT状态占用连接，希望能加快TIME_WAIT状态的回收，通常将net.ipv4.tcp_tw_recycle选项开启。当然这个选项的生效要依赖net.ipv4.tcp_timestamps选项的开启。虽然开启这个选项能够加快TIME_WAIT连接的回收，但却引入了另一个问题。我们先看下tcp_tw_recycle选项的工作机制：
当开启了tcp_tw_recycle选项后，当连接进入TIME_WAIT状态后，会记录对应远端主机最后到达分节的时间戳。如果同样的主机有新的分节到达，且时间戳小于之前记录的时间戳，即视为无效，相应的数据包会被丢弃（rfc1323）。
Linux是否启用这种行为取决于tcp_timestamps和tcp_tw_recycle，因为tcp_timestamps缺省就是开启的，所以当tcp_tw_recycle被开启后，实际上这种行为就被激活了。

现在很多公司都用LVS做负载均衡，通常是前面一台LVS，后面多台后端服务器，这其实就是NAT，当请求到达LVS后，它修改地址数据后便转发给后端服务器，但不会修改时间戳数据，对于后端服务器来说，请求的源地址就是LVS的地址，加上端口会复用，所以从后端服务器的角度看，原本不同客户端的请求经过LVS的转发，就可能会被认为是同一个连接，加之不同客户端的时间可能不一致，所以就会出现时间戳错乱的现象，于是后面的数据包就被丢弃了，具体的表现通常是是客户端明明发送的SYN，但服务端就是不响应ACK，还可以通过下面命令来确认数据包不断被丢弃的现象：

shell> netstat -s | grep timestamp
packets rejects in established connections because of timestamp

如果服务器身处NAT环境，安全起见，通常要禁止tcp_tw_recycle，至于TIME_WAIT连接过多的问题，可以通过激活tcp_tw_reuse来缓解（只对客户端有作用）。

当然关闭tcp_timestamps选项也是可以避免这个问题的：
设置sysctl.conf里面tcp_timestamps=0也可以只用命令sysctl -w net.ipv4.tcp_timestamps=0
但个人建议关闭tcp_tw_recycle选项，而不是timestamp；因为 在tcp timestamp关闭的条件下，开启tcp_tw_recycle是不起作用的；而tcp timestamp可以独立开启并起作用。此外tcp timestamp还和其他选项起作用有关，如tcp_tw_reuse。

补充下：

net.ipv4.tcp_tw_reuse，如果开启该选项的话，客户端（连接发起方）在调用 connect() 函数时，内核会随机找一个 time_wait 状态超过 1 秒的连接给新的连接复用，所以该选项只适用于连接发起方。
TIME_WAIT 状态也不是摆设作用，它的作用有两个：一，防止具有相同四元组的旧数据包被收到，也就是防止历史连接中的数据，被后面的连接接受，否则就会导致后面的连接收到一个无效的数据，二，保证「被动关闭连接」的一方能被正确的关闭，即保证最后的 ACK 能让被动关闭方接收，从而帮助其正常关闭;

开始以为是上面这种情况，后面改了tcp_tw_recycle参数也没有效果，且机器是公网的，应该不属于这种情况。

还有一种情况，除非tcp的全连接队列满了，导致无法正常建连，通过ss -tl确认，发现Recv-Q（接收队列）的值大于Send-Q（发送队列）的值，这样就可以确定是应用层没有及时accept导致全连接队列都溢出了。

这样导致新连接过来时无法正常握手，内核就将SYN丢弃了，netstat -s |egrep -e SYNs信息如下。

这种情况一般是程序出问题了，导致没有正常的accept，比如IO线程卡死？于是打开了程序的实时日志，并没有发现io所在线程卡死，因为还有其它日志在输出，strace也看到进程正常调用系统函数，top -p也看到cpu正常。
观察到有很多CLOSE_WAIT的异常现象，这种一般是服务端没有及时调用close，看到这种现象一度怀疑是io卡死了，但查证日志又不是。

后面看了一眼ulimit -n为1024，仿佛明白了什么，当高峰期时，服务端连接过多，导致无法正常分配文件描述符，无法正常accept，boost的async_accept异常后直接返回了，就没有处理后续的onAccepted事件了，导致无法及时处理accept。

最后处理，将进程的最大可打开文件数设为1048576，boost的asio是LT模式，一般epoll对accept事件都是LT模式处理，接入的连接再设置为ET模式，async_accept由于no_descriptors异常后直接退出程序，这样重启后程序可以正常服务，当然一般不会达到100w的文件数，所以这种重启的情况一般不会发生，但是发生了不至于像现在这样无法正常的建立连接。

原理，SYN包什么时候会被丢弃

1	原文链接：https://blog.csdn.net/thehunters/article/details/122240272

客户端向服务端发起了连接，但是连接并没有建立起来，通过抓包分析发现，服务端是收到 SYN 报文了，但是并没有回复 SYN+ACK（TCP 第二次握手），说明 SYN 报文被服务端忽略了，然后客户端就一直在超时重传 SYN 报文，直到达到最大的重传次数。

接下来，我就给出我遇到过 SYN 报文被丢弃的两种场景：

开启 tcp_tw_recycle 参数，并且在 NAT 环境下，造成 SYN 报文被丢弃
accpet 队列满了，造成 SYN 报文被丢弃

TCP 四次挥手过程中，主动断开连接方会有一个 TIME_WAIT 的状态，这个状态会持续 2 MSL 后才会转变为 CLOSED 状态。

在 Linux 操作系统下，TIME_WAIT 状态的持续时间是 60 秒，这意味着这 60 秒内，客户端一直会占用着这个端口。要知道，端口资源也是有限的，一般可以开启的端口为 32768~61000 ，也可以通过如下参数设置指定范围：

1	net.ipv4.ip_local_port_range

那么，如果如果主动断开连接方的 TIME_WAIT 状态过多，占满了所有端口资源，则会导致无法创建新连接。

但是 TIME_WAIT 状态也不是摆设作用，它的作用有两个：

防止具有相同四元组的旧数据包被收到，也就是防止历史连接中的数据，被后面的连接接受，否则就会导致后面的连接收到一个无效的数据，
保证「被动关闭连接」的一方能被正确的关闭，即保证最后的 ACK 能让被动关闭方接收，从而帮助其正常关闭;

不过，Linux 操作系统提供了两个可以系统参数来快速回收处于 TIME_WAIT 状态的连接，这两个参数都是默认关闭的：

net.ipv4.tcp_tw_reuse，如果开启该选项的话，客户端（连接发起方）在调用 connect() 函数时，内核会随机找一个 time_wait 状态超过 1 秒的连接给新的连接复用，所以该选项只适用于连接发起方。
net.ipv4.tcp_tw_recycle，如果开启该选项的话，允许处于 TIME_WAIT 状态的连接被快速回收；

要使得这两个选项生效，有一个前提条件，就是要打开 TCP 时间戳，即 net.ipv4.tcp_timestamps=1（默认即为 1）。

但是，tcp_tw_recycle 在使用了 NAT 的网络下是不安全的！

对于服务器来说，如果同时开启了 recycle 和 timestamps 选项，则会开启一种称之为「 per-host 的 PAWS 机制」。

tcp_timestamps 选项开启之后， PAWS 机制会自动开启，它的作用是防止 TCP 包中的序列号发生绕回。

正常来说每个 TCP 包都会有自己唯一的 SEQ，出现 TCP 数据包重传的时候会复用 SEQ 号，这样接收方能通过 SEQ 号来判断数据包的唯一性，也能在重复收到某个数据包的时候判断数据是不是重传的。但是 TCP 这个 SEQ 号是有限的，一共 32 bit，SEQ 开始是递增，溢出之后从 0 开始再次依次递增。

所以当 SEQ 号出现溢出后单纯通过 SEQ 号无法标识数据包的唯一性，某个数据包延迟或因重发而延迟时可能导致连接传递的数据被破坏，比如：

上图 A 数据包出现了重传，并在 SEQ 号耗尽再次从 A 递增时，第一次发的 A 数据包延迟到达了 Server，这种情况下如果没有别的机制来保证，Server 会认为延迟到达的 A 数据包是正确的而接收，反而是将正常的第三次发的 SEQ 为 A 的数据包丢弃，造成数据传输错误。

PAWS 就是为了避免这个问题而产生的，在开启 tcp_timestamps 选项情况下，一台机器发的所有 TCP 包都会带上发送时的时间戳，PAWS 要求连接双方维护最近一次收到的数据包的时间戳（Recent TSval），每收到一个新数据包都会读取数据包中的时间戳值跟 Recent TSval 值做比较，如果发现收到的数据包中时间戳不是递增的，则表示该数据包是过期的，就会直接丢弃这个数据包。

对于上面图中的例子有了 PAWS 机制就能做到在收到 Delay 到达的 A 号数据包时，识别出它是个过期的数据包而将其丢掉。

面我提到，开启了 recycle 和 timestamps 选项，就会开启一种叫 per-host 的 PAWS 机制。

per-host 是对「对端 IP 做 PAWS 检查」，而非对「IP + 端口」四元组做 PAWS 检查。

但是如果客户端网络环境是用了 NAT 网关，那么客户端环境的每一台机器通过 NAT 网关后，都会是相同的 IP 地址，在服务端看来，就好像只是在跟一个客户端打交道一样，无法区分出来。

Per-host PAWS 机制利用TCP option里的 timestamp 字段的增长来判断串扰数据，而 timestamp 是根据客户端各自的 CPU tick 得出的值。

当客户端 A 通过 NAT 网关和服务器建立 TCP 连接，然后服务器主动关闭并且快速回收 TIME-WAIT 状态的连接后，客户端 B 也通过 NAT 网关和服务器建立 TCP 连接，注意客户端 A 和客户端 B 因为经过相同的 NAT 网关，所以是用相同的 IP 地址与服务端建立 TCP 连接，如果客户端 B 的 timestamp 比客户端 A 的 timestamp 小，那么由于服务端的 per-host 的 PAWS 机制的作用，服务端就会丢弃客户端主机 B 发来的 SYN 包。

因此，tcp_tw_recycle 在使用了 NAT 的网络下是存在问题的，如果它是对 TCP 四元组做 PAWS 检查，而不是对「相同的 IP 做 PAWS 检查」，那么就不会存在这个问题了。

tcp_tw_recycle 在 Linux 4.12 版本后，直接取消了这一参数。

在 TCP 三次握手的时候，Linux 内核会维护两个队列，分别是：

半连接队列，也称 SYN 队列；
全连接队列，也称 accepet 队列；

服务端收到客户端发起的 SYN 请求后，内核会把该连接存储到半连接队列，并向客户端响应 SYN+ACK，接着客户端会返回 ACK，服务端收到第三次握手的 ACK 后，内核会把连接从半连接队列移除，然后创建新的完全的连接，并将其添加到 accept 队列，等待进程调用 accept 函数时把连接取出来。