SYN 报文什么时候情况下会被丢弃？_qq

学习必须往深处挖，挖的越深，基础越扎实！

码哥源码部分

码哥讲源码-原理源码篇【2024年最新大厂关于线程池使用的场景题】

码哥讲源码【炸雷啦！炸雷啦！黄光头他终于跑路啦！】

码哥讲源码-【jvm课程前置知识及c/c++调试环境搭建】

码哥讲源码-原理源码篇【揭秘join方法的唤醒本质上决定于jvm的底层析构函数】

码哥源码-原理源码篇【doug lea为什么要将成员变量赋值给局部变量后再操作？】

码哥讲源码【你水不是你的错,但是你胡说八道就是你不对了！】

码哥讲源码【谁再说spring不支持多线程事务，你给我抽他！】

终结b站没人能讲清楚红黑树的历史，不服等你来踢馆！

打脸系列【020-3小时讲解mesi协议和volatile之间的关系，那些将x86下的验证结果当作最终结果的水货们请闭嘴】

之前有个读者在秋招面试的时候，被问了这么一个问题：syn 报文什么时候情况下会被丢弃？

好家伙，现在面试都问那么细节了吗？

不过话说回来，这个问题跟工作上也是有关系的，因为我就在工作中碰到这么奇怪的时候，客户端向服务端发起了连接，但是连接并没有建立起来，通过抓包分析发现，服务端是收到 syn 报文了，但是并没有回复 syn+ack（tcp 第二次握手），说明 syn 报文被服务端忽略了，然后客户端就一直在超时重传 syn 报文，直到达到最大的重传次数。

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

开启 tcp_tw_recycle 参数，并且在 nat 环境下，造成 syn 报文被丢弃
tcp 两个队列满了（半连接队列和全连接队列），造成 syn 报文被丢弃

# 坑爹的 tcp_tw_recycle

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

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

     net.ipv4.ip_local_port_range

如果客户端（发起连接方）的 time_wait 状态过多 ，占满了所有端口资源，那么就无法对「目的 ip+ 目的 port」都一样的服务器发起连接了，但是被使用的端口，还是可以继续对另外一个服务器发起连接的。

因此，客户端（发起连接方）都是和「目的 ip+ 目的 port 」都一样的服务器建立连接的话，当客户端的 time_wait 状态连接过多的话，就会受端口资源限制，如果占满了所有端口资源，那么就无法再跟「目的 ip+ 目的 port」都一样的服务器建立连接了。

不过，即使是在这种场景下，只要连接的是不同的服务器，端口是可以重复使用的，所以客户端还是可以向其他服务器发起连接的，这是因为内核在定位一个连接的时候，是通过四元组（源ip、源端口、目的ip、目的端口）信息来定位的，并不会因为客户端的端口一样，而导致连接冲突。

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

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

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

net.ipv4.tcp_tw_reuse，如果开启该选项的话，客户端（连接发起方）在调用 connect() 函数时，**如果内核选择到的端口，已经被相同四元组的连接占用的时候，就会判断该连接是否处于 time_wait 状态，如果该连接处于 time_wait 状态并且 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 参数来优化 tcp，我信你个鬼，糟老头坏的很！

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

# accpet 队列满了

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

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

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