握手失败
第一次握手丢失了，会发生什么？
当客户端想和服务端建立 TCP 连接的时候，首先第一个发的就是 SYN 报文，然后进入到 SYN_SENT 状态。
在这之后，如果客户端迟迟收不到服务端的 SYN-ACK 报文（第二次握手），就会触发超时重传机制。
不同版本的操作系统可能超时时间不同，有的 1 秒的，也有 3 秒的，这个超时时间是写死在内核里的，如果想要更改则需要重新编译内核，比较麻烦。
当客户端在 1 秒后没收到服务端的 SYN-ACK 报文后，客户端就会重发 SYN 报文，那到底重发几次呢？
在 Linux 里，客户端的 SYN 报文最大重传次数由 tcp_syn_retries 内核参数控制，这个参数是可以自定义的，默认值一般是 5。
[root@localhost ~]# cat /proc/sys/net/ipv4/tcp_syn_retries 5
通常，第一次超时重传是在 1 秒后，第二次超时重传是在 2 秒，第三次超时重传是在 4 秒后，第四次超时重传是在 8 秒后，第五次是在超时重传 16 秒后。没错，每次超时的时间是上一次的 2 倍。
当第五次超时重传后，会继续等待 32 秒，如果服务端仍然没有回应 ACK，客户端就不再发送 SYN 包，然后断开 TCP 连接。
所以，总耗时是 1+2+4+8+16+32=63 秒，大约 1 分钟左右。
场景复现
在服务端先 ban 掉客户端的 IP iptables -I INPUT -s 客户端 IP -j DROP，然后客户端通过 curl 指令去访问服务端：
可以自己设置 tcp_syn_retries：
[root@localhost ~]# echo 6 > /proc/sys/net/ipv4/tcp_syn_retries
第二次握手丢失了，会发生什么？
当服务端收到客户端的第一次握手后，就会回 SYN-ACK 报文给客户端，这个就是第二次握手，此时服务端会进入 SYN_RCVD 状态。
第二次握手的 SYN-ACK 报文其实有两个目的 ：
- 第二次握手里的 ACK， 是对第一次握手的确认报文；
- 第二次握手里的 SYN，是服务端发起建立 TCP 连接的报文；
所以，如果第二次握手丢了，就会发送比较有意思的事情，具体会怎么样呢？
因为第二次握手报文里是包含对客户端的第一次握手的 ACK 确认报文，所以，如果客户端迟迟没有收到第二次握手，那么客户端就觉得可能自己的 SYN 报文（第一次握手）丢失了，于是客户端就会触发超时重传机制，重传 SYN 报文。
然后，因为第二次握手中包含服务端的 SYN 报文，所以当客户端收到后，需要给服务端发送 ACK 确认报文（第三次握手），服务端才会认为该 SYN 报文被客户端收到了。
那么，如果第二次握手丢失了，服务端就收不到第三次握手，于是服务端这边会触发超时重传机制，重传 SYN-ACK 报文。
在 Linux 下，SYN-ACK 报文的最大重传次数由 tcp_synack_retries 内核参数决定，默认值是 5。
因此，当第二次握手丢失了，客户端和服务端都会重传：
- 客户端会重传 SYN 报文，也就是第一次握手，最大重传次数由 tcp_syn_retries 内核参数决定；
- 服务端会重传 SYN-AKC 报文，也就是第二次握手，最大重传次数由 tcp_synack_retries 内核参数决定。
场景复现
这时候解除服务端 ban 掉的 客户端的IP iptables -D INPUT -s 客户端 IP -j DROP，转而让客户端 ban 掉服务端的 IP，这样的话，客户端发送的 SYN 包能被服务端收到，但是服务端返回的 ACK 包会在网络层就被嘎掉，无法到达传输层交给 TCP 解析，因此就人为的造成了第二次握手失败的场景；
客户端设置了防火墙，屏蔽了服务端的网络包，为什么 tcpdump 还能抓到服务端的网络包？
添加 iptables 限制后， tcpdump 是否能抓到包 ，这要看添加的 iptables 限制条件：
- 如果添加的是 INPUT 规则，则可以抓得到包；
- 如果添加的是 OUTPUT 规则，则抓不到包；
网络包进入主机后的顺序如下：
- 进来的顺序 Wire -> NIC -> tcpdump -> netfilter/iptables；
- 出去的顺序 iptables -> tcpdump -> NIC -> Wire；
第三次握手丢失了，会发生什么？
客户端收到服务端的 SYN-ACK 报文后，就会给服务端回一个 ACK 报文，也就是第三次握手，此时客户端状态进入到 ESTABLISH 状态。
因为这个第三次握手的 ACK 是对第二次握手的 SYN 的确认报文，所以当第三次握手丢失了，如果服务端那一方迟迟收不到这个确认报文，就会触发超时重传机制，重传 SYN-ACK 报文，直到收到第三次握手，或者达到最大重传次数。
注意，ACK 报文是不会有重传的，当 ACK 丢失了，就由对方重传对应的报文。
0 socket(..., SOCK_STREAM, IPPROTO_TCP) = 3 +0 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0 +0 bind(3, ..., ...) = 0 +0 listen(3, 1) = 0 +0 `echo socket is listening!` +0 < S 0:0(0) win 4000 <mss 100> +0 > S. 0:0(0) ack 1 <...> +0 `sleep 1000000`
挥手失败
第一次挥手丢失了，会发生什么？
当客户端（主动关闭方）调用 close 函数后，就会向服务端发送 FIN 报文，试图与服务端断开连接，此时客户端的连接进入到 FIN_WAIT_1 状态。
正常情况下，如果能及时收到服务端（被动关闭方）的 ACK，则会很快变为 FIN_WAIT2 状态。
如果第一次挥手丢失了，那么客户端迟迟收不到被动方的 ACK 的话，也就会触发超时重传机制，重传 FIN 报文，重发次数由 tcp_orphan_retries 参数控制。
当客户端重传 FIN 报文的次数超过 tcp_orphan_retries 后，就不再发送 FIN 报文，直接进入到 CLOSE 状态。
第二次挥手丢失了，会发生什么？
当服务端收到客户端的第一次挥手后，就会先回一个 ACK 确认报文，此时服务端的连接进入到 CLOSE_WAIT 状态。
在前面我们也提了，ACK 报文是不会重传的，所以如果服务端的第二次挥手丢失了，客户端就会触发超时重传机制，重传 FIN 报文，直到收到服务端的第二次挥手，或者达到最大的重传次数。
这里提一下，当客户端收到第二次挥手，也就是收到服务端发送的 ACK 报文后，客户端就会处于 FIN_WAIT2 状态，在这个状态需要等服务端发送第三次挥手，也就是服务端的 FIN 报文。
对于 close 函数关闭的连接，由于无法再发送和接收数据，所以 FIN_WAIT2 状态不可以持续太久，而 tcp_fin_timeout 控制了这个状态下连接的持续时长，默认值是 60 秒。
这意味着对于调用 close 关闭的连接，如果在 60 秒后还没有收到 FIN 报文，客户端（主动关闭方）的连接就会直接关闭。
第三次挥手丢失了，会发生什么？
当服务端（被动关闭方）收到客户端（主动关闭方）的 FIN 报文后，内核会自动回复 ACK，同时连接处于 CLOSE_WAIT 状态，顾名思义，它表示等待应用进程调用 close 函数关闭连接。
此时，内核是没有权利替代进程关闭连接，必须由进程主动调用 close 函数来触发服务端发送 FIN 报文。
服务端处于 CLOSE_WAIT 状态时，调用了 close 函数，内核就会发出 FIN 报文，同时连接进入 LAST_ACK 状态，等待客户端返回 ACK 来确认连接关闭。
如果迟迟收不到这个 ACK，服务端就会重发 FIN 报文，重发次数仍然由 tcp_orphan_retries 参数控制，这与客户端重发 FIN 报文的重传次数控制方式是一样的。
0 socket(..., SOCK_STREAM, IPPROTO_TCP) = 3 +0 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0 +0 bind(3, ..., ...) = 0 +0 listen(3, 1) = 0 +0 `echo socket is listening!` +0 < S 0:0(0) win 4000 <mss 100> +0 > S. 0:0(0) ack 1 <...> +.1 < . 1:1(0) ack 1 win 1000 +0 accept(3, ..., ...) = 4 +0 `echo connection established!` +0 < F. 1:1(0) ack 1 win 1000 +0 > . 1:1(0) ack 2 +0.1 close(4)=0 +0 > F. 1:1(0) ack 2 <...> +0 `sleep 1000000`
第四次挥手丢失了，会发生什么？
当客户端收到服务端的第三次挥手的 FIN 报文后，就会回 ACK 报文，也就是第四次挥手，此时客户端连接进入 TIME_WAIT 状态。
在 Linux 系统，TIME_WAIT 状态会持续 60 秒后才会进入关闭状态。
然后，服务端（被动关闭方）没有收到 ACK 报文前，还是处于 LAST_ACK 状态。
如果第四次挥手的 ACK 报文没有到达服务端，服务端就会重发 FIN 报文，重发次数仍然由前面介绍过的 tcp_orphan_retries 参数控制。
为什么是三次握手？
现在耳熟能详的 TCP 连接就是三次握手，四次挥手，那么你有想过 为什么是三次握手，而不是两次或者四次呢？
相信比较平常回答的是：“因为三次握手才能保证双方具有接收和发送的能力”。这样的回答是没问题的，但是这回答是片面的，并没有说出主要的原因。
在前面我们知道了什么是 TCP 连接：用于保证可靠性和流量控制维护的某些状态信息，这些信息的组合，包括 Socket、序列号和窗口大小称为连接。
所以，重要的是为什么三次握手才可以初始化 Socket、序列号和窗口大小并建立 TCP 连接。
接下来以三个方面分析三次握手的原因：
- 三次握手才可以阻止重复历史连接的初始化（主要原因）；
- 三次握手才可以同步双方的初始序列号；
- 三次握手才可以避免资源浪费；
原因一：避免历史连接
RFC 793 指出的 TCP 连接使用三次握手的首要原因：
The principle reason for the three-way handshake is to prevent old duplicate connection initiations from causing confusion.
简单来说，三次握手的首要原因是为了防止旧的重复连接初始化造成混乱。
网络环境是错综复杂的，往往并不是如我们期望的一样，先发送的数据包，就先到达目标主机；可能会由于网络拥堵等乱七八糟的原因，会使得旧的数据包，先到达目标主机。那么这种情况下 TCP 三次握手是如何避免的呢？
客户端连续发送多次 SYN 建立连接的报文，在网络拥堵情况下：
- 一个「旧 SYN 报文」比「最新的 SYN 」 报文早到达了服务端；
- 那么此时服务端就会回一个 SYN + ACK 报文给客户端；
- 客户端收到后可以根据自身的上下文，判断这是一个历史连接（序列号过期或超时），那么客户端就会发送 RST 报文给服务端，表示中止这一次连接。
如果是两次握手连接，就不能判断当前连接是否是历史连接，三次握手则可以在客户端（发送方）准备发送第三次报文时，客户端因有足够的上下文来判断当前连接是否是历史连接：
- 如果是历史连接（序列号过期或超时），则第三次握手发送的报文是 RST 报文，以此中止历史连接；
- 如果不是历史连接，则第三次发送的报文是 ACK 报文，通信双方就会成功建立连接；
所以，TCP 使用三次握手建立连接的最主要原因是防止历史连接初始化了连接。
原因二：同步双方初始序列号
TCP 协议的通信双方， 都必须维护一个「序列号」， 序列号是可靠传输的一个关键因素，它的作用：
- 接收方可以去除重复的数据；
- 接收方可以根据数据包的序列号按序接收；
- 可以标识发送出去的数据包中， 哪些是已经被对方收到的；
可见，序列号在 TCP 连接中占据着非常重要的作用，所以当客户端发送携带「初始序列号」的 SYN 报文的时候，需要服务端回一个 ACK 应答报文，表示客户端的 SYN 报文已被服务端成功接收，那当服务端发送「初始序列号」给客户端的时候，依然也要得到客户端的应答回应，这样一来一回，才能确保双方的初始序列号能被可靠的同步。
四次握手与三次握手：
四次握手其实也能够可靠的同步双方的初始化序号，但由于第二步和第三步可以优化成一步，所以就成了「三次握手」。
而两次握手只保证了一方的初始序列号能被对方成功接收，没办法保证双方的初始序列号都能被确认接收。
原因三：避免资源浪费
如果只有「两次握手」，当客户端的 SYN 请求连接在网络中阻塞，客户端没有接收到 ACK 报文，就会重新发送 SYN ，由于没有第三次握手，服务器不清楚客户端是否收到了自己发送的建立连接的 ACK 确认信号，所以每收到一个 SYN 就只能先主动建立一个连接，这会造成什么情况呢？
如果客户端的 SYN 阻塞了，重复发送多次 SYN 报文，那么服务器在收到请求后就会建立多个冗余的无效链接，造成不必要的资源浪费。
两次握手会造成资源浪费:
即两次握手会造成消息滞留情况下，服务器重复接受无用的连接请求 SYN 报文，而造成重复分配资源。
小结
TCP 建立连接时，通过三次握手能：
- 防止历史连接的建立，能减少双方不必要的资源开销；
- 能帮助双方同步初始化序列号，序列号能够保证数据包不重复、不丢弃和按序传输；
不使用「两次握手」和「四次握手」的原因：
- 「两次握手」：无法防止历史连接的建立，会造成双方资源的浪费，也无法可靠的同步双方序列号；
- 「四次握手」：三次握手就已经理论上最少可靠连接建立，所以不需要使用更多的通信次数；
如何避免 SYN 攻击？
什么是 SYN 攻击？
在了解如何避免 SYN 攻击前，我们得先了解什么是 SYN 攻击；
我们都知道 TCP 连接建立是需要三次握手，假设攻击者短时间伪造不同 IP 地址的 SYN 报文，服务端每接收到一个 SYN 报文，就进入SYN_RCVD 状态，但服务端发送出去的 SYN + ACK 报文，无法得到未知 IP 主机的 ACK 应答，久而久之就会占满服务端的 SYN 接收队列（未连接队列），使得服务器不能为正常用户服务。
也就是上面曾讲述的 第三次握手失败；
常用的工具有 LOIC，Hping3 等，演示攻击如下：
因为虚拟机的配置低，所以很容易就实现 CPU 爆满的状况了，这时候服务器就很难响应其他服务请求，更严重的可能会直接宕机；
避免 SYN 攻击方式一
第一种解决方式是通过修改 Linux 内核参数，控制队列大小和当队列满时应做什么处理。
当网卡接收数据包的速度大于内核处理的速度时，会有一个队列保存这些数据包。
- 控制该队列的最大值：net.core.netdev_max_backlog；
- SYN_RCVD 状态连接的最大个数：net.ipv4.tcp_max_syn_backlog；
- 超出处理能时，对新的 SYN 直接回报 RST，丢弃连接：net.ipv4.tcp_abort_on_overflow；
避免 SYN 攻击方式二
我们先来看下 Linux 内核的 SYN （未完成连接建立）队列与 Accpet （已完成连接建立）队列是如何工作的：
1、正常流程；
- 当服务端接收到客户端的 SYN 报文时，会将其加入到内核的「 SYN 队列」；
- 接着发送 SYN + ACK 给客户端，等待客户端回应 ACK 报文；
- 服务端接收到 ACK 报文后，从「 SYN 队列」移除放入到「 Accept 队列」；
- 应用通过调用 accpet() socket 接口，从「 Accept 队列」取出连接。
2、应用程序过慢；
如果应用程序过慢时，就会导致「 Accept 队列」被占满。
3、受到 SYN 攻击；
如果不断受到 SYN 攻击，就会导致「 SYN 队列」被占满。
tcp_syncookies 的方式可以应对 SYN 攻击的方法：net.ipv4.tcp_syncookies = 1
- 当 「 SYN 队列」满之后，后续服务器收到 SYN 包，不进入「 SYN 队列」；
- 计算出一个 cookie 值，再以 SYN + ACK 中的「序列号」返回客户端；
- 服务端接收到客户端的应答报文时，服务器会检查这个 ACK 包的合法性，如果合法，直接放入到「 Accept 队列」；
- 最后应用通过调用 accpet() socket 接口，从「 Accept 队列」取出的连接。
MTU与 MSS 那些事儿
最大报文段长度 MSS 与 最大传输单元 MTU 均是协议用来定义最大长度的。不同的是，MTU 应用于 OSI 模型的第二层数据链接层，并无具体针对的协议，限制了数据链接层上可以传输的数据包的大小，也因此限制了上层（网络层）的数据包大小；MSS 针对的是 OSI 模型里的第四层传输层的 TCP 协议，因为 MSS 应用的协议在数据链接层的上层，所以 MSS 会受到 MTU 的限制。
- MTU：Maximum Transmission Unit，最大传输单元，由硬件规定，如以太网的 MTU 为1500字节。
- MSS：Maximum Segment Size，最大分段大小，是 TCP 数据包每次传输的最大数据分段大小，一般由发送端向对端 TCP 通知，对端在每个分节中能发送的最大 TCP 数据。MSS 值为 MTU 值减去IPv4 Header（20 Byte）和 TCP header（20 Byte）得到。
- 分片：Fragmentation，若 IP 数据报大小超过相应链路的 MTU 的时候，IPV4 和 IPV6 都执行分片操作，各片段到达目的地前通常不会被重组 (re-assembling)。IPV4 主机对其产生的数据报执行分片，IPV4 路由器对其转发的数据也执行分片，然而 IPV6 只在数据产生的主机执行分片，IPV6 路由器对其转发的数据不执行分片。
那么问题来了，为什么由 Wireshark 抓到的数据包的MSS = 1460，但却在Len = 1448的时候就进行分包了呢？如下图所示：
既然在握手阶段就协商了 MSS = 1460，那为什么 TCP 的最大数据段长度却只有 1448 bytes 呢？
原来在实际场景中，TCP 包头中会带有12字节的选项，时间戳（Timestamps），这样，单个 TCP 包实际传输的最大量就缩减为1448字节了，如下所示：
那 MTU = MSS + IP 头长度 + TCP 头长度，一般 IP 头长度和 TCP 头长度都为20，即MTU = MSS + 20 +20 = 1500，但是呢，从下图中不难发现，一个 TCP 包的总长度 Length 却大于 MTU，这是为什么呢？
这是根据以太网帧结构所决定的，至于如何判断是否为以太网，可以根据物理层中的[Protocols in frame: eth:ethertype:ip:tcp]判定，这表示帧内封装的协议层次结构；
在不选择填充 802.1Q 标签，负载拉满（即为 MTU 值）的前提下，以太网的最大帧大小应该是 前导码+帧开始符+MAC目标地址+MAC源地址+以太类型+负载+冗余校验 = 7+1+6+6+2+1500+4 = 1526 字节，那为什么 Wireshark 抓来的数据包的最大帧却只有1514字节呢？
原来是因为当数据帧到达网卡时，在物理层上网卡要先去掉前导码和帧开始定界符，然后对帧进行 CRC 校验：如果帧校验和错误，就丢弃此帧；如果帧校验和正确，就判断该帧的 MAC 目的地址是否符合自己的接收条件，如果符合，就将此帧交付 设备驱动程序 做进一步处理。这时 Wireshark 才能抓到数据，因此，Wireshark 抓到的是去掉前导码、帧开始分界符、CRC校验之外的数据，其最大值是 6＋6＋2＋1500＝1514 字节；
TIME_WAIT 的巧妙设计
为什么 TIME_WAIT 等待的时间是 2MSL？
MSL (Maximum Segment Lifetime)，报文最大生存时间，它是任何报文在网络上存在的最长时间，超过这个时间报文将被丢弃。因为 TCP 报文基于是 IP 协议的，而 IP 头中有一个 TTL 字段，是 IP 数据报可以经过的最大路由数，每经过一个处理他的路由器此值就减 1，当此值为 0 则数据报将被丢弃，同时发送 ICMP 报文通知源主机。
MSL 与 TTL 的区别： MSL 的单位是时间，而 TTL 是经过路由跳数。所以 MSL 应该要大于等于 TTL 消耗为 0 的时间，以确保报文已被自然消亡。
TIME_WAIT 等待 2 倍的 MSL，比较合理的解释是： 网络中可能存在来自发送方的数据包，当这些发送方的数据包被接收方处理后又会向对方发送响应，所以一来一回需要等待 2 倍的时间。
比如被动关闭方没有收到断开连接的最后的 ACK 报文，就会触发超时重发 FIN 报文，另一方接收到 FIN 后，会重发 ACK 给被动关闭方， 一来一去正好 2 个 MSL。
2MSL 的时间是从客户端接收到 FIN 后发送 ACK 开始计时的。如果在 TIME-WAIT 时间内，因为客户端的 ACK 没有传输到服务端，客户端又接收到了服务端重发的 FIN 报文，那么 2MSL 时间将重新计时。
在 Linux 系统里 2MSL 默认是 60 秒，那么一个 MSL 也就是 30 秒。Linux 系统停留在 TIME_WAIT 的时间为固定的 60 秒。
其定义在 Linux 内核代码里的名称为 TCP_TIMEWAIT_LEN：
#define TCP_TIMEWAIT_LEN (60*HZ) /* how long to wait to destroy TIME-WAIT state, about 60 seconds */
如果要修改 TIME_WAIT 的时间长度，只能修改 Linux 内核代码里 TCP_TIMEWAIT_LEN 的值，并重新编译 Linux 内核。
为什么需要 TIME_WAIT 状态？
主动发起关闭连接的一方，才会有 TIME-WAIT 状态。
需要 TIME-WAIT 状态，主要是两个原因：
- 防止具有相同「四元组」的「旧」数据包被收到；
- 保证「被动关闭连接」的一方能被正确的关闭，即保证最后的 ACK 能让被动关闭方接收，从而帮助其正常关闭；
原因一：防止旧连接的数据包
假设TIME-WAIT没有等待时间或时间过短，被延迟的数据包抵达后会发生什么呢？
- 如上图黄色框框服务端在关闭连接之前发送的 SEQ = 301 报文，被网络延迟了。
- 这时有相同端口的 TCP 连接被复用后，被延迟的 SEQ = 301 抵达了客户端，那么客户端是有可能正常接收这个过期的报文，这就会产生数据错乱等严重的问题。
所以，TCP 就设计出了这么一个机制，经过 2MSL 这个时间，足以让两个方向上的数据包都被丢弃，使得原来连接的数据包在网络中都自然消失，再出现的数据包一定都是新建立连接所产生的。
原因二：保证连接正确关闭
在 RFC 793 指出 TIME-WAIT 另一个重要的作用是：
TIME-WAIT - represents waiting for enough time to pass to be sure the remote TCP received the acknowledgment of its connection termination request.
也就是说，TIME-WAIT 作用是等待足够的时间以确保最后的 ACK 能让被动关闭方接收，从而帮助其正常关闭。
假设 TIME-WAIT 没有等待时间或时间过短，断开连接会造成什么问题呢？
- 如上图红色框框客户端四次挥手的最后一个 ACK 报文如果在网络中被丢失了，此时如果客户端 TIME-WAIT 过短或没有，则就直接进入了 CLOSED 状态了，那么服务端则会一直处在 LASE_ACK 状态。
- 当客户端发起建立连接的 SYN 请求报文后，服务端会发送 RST 报文给客户端，连接建立的过程就会被终止。
如果 TIME-WAIT 等待足够长的情况就会遇到两种情况：
- 服务端正常收到四次挥手的最后一个 ACK 报文，则服务端正常关闭连接。
- 服务端没有收到四次挥手的最后一个 ACK 报文时，则会重发 FIN 关闭连接报文并等待新的 ACK 报文。
所以客户端在 TIME-WAIT 状态等待 2MSL 时间后，就可以保证双方的连接都可以正常的关闭。
TIME_WAIT 过长有什么危害？
如果服务器有处于 TIME-WAIT 状态的 TCP，则说明是由服务器方主动发起的断开请求。
过多的 TIME-WAIT 状态主要的危害有两种：
- 第一是内存资源占用；
- 第二是对端口资源的占用，一个 TCP 连接至少消耗一个本地端口；
第二个危害是会造成严重的后果的，要知道，端口资源也是有限的，一般可以开启的端口为 32768～61000，也可以通过参数设置指定
net.ipv4.ip_local_port_range，如果发起连接一方的 TIME_WAIT 状态过多，占满了所有端口资源，则会导致无法创建新连接。
客户端受端口资源限制：
- 客户端 TIME_WAIT 过多，就会导致端口资源被占用，因为端口就65536个，被占满就会导致无法创建新的连接。
服务端受系统资源限制：
- 由于一个四元组表示 TCP 连接，理论上服务端可以建立很多连接，服务端确实只监听一个端口 但是会把连接扔给处理线程，所以理论上监听的端口可以继续监听。但是线程池处理不了那么多一直不断的连接了。所以当服务端出现大量 TIME_WAIT 时，系统资源被占满时，会导致处理不过来新的连接。
如何优化 TIME_WAIT？
这里给出优化 TIME-WAIT 的几个方式，都是有利有弊：
方式一：net.ipv4.tcp_tw_reuse 和 tcp_timestamps
如下的 Linux 内核参数开启后，则可以复用处于 TIME_WAIT 的 socket 为新的连接所用。
有一点需要注意的是，tcp_tw_reuse 功能只能用于客户端（连接发起方），因为开启了该功能，在调用 connect() 函数时，内核会随机找一个 time_wait 状态超过 1 秒的连接给新的连接复用。
net.ipv4.tcp_tw_reuse = 1
使用这个选项，还有一个前提，需要打开对 TCP 时间戳的支持，即 net.ipv4.tcp_timestamps=1（默认即为 1），这个时间戳的字段是在 TCP 头部的「选项」里，用于记录 TCP 发送方的当前时间戳和从对端接收到的最新时间戳。
由于引入了时间戳，我们在前面提到的 2MSL 问题就不复存在了，因为重复的数据包会因为时间戳过期被自然丢弃。
方式二：net.ipv4.tcp_max_tw_buckets
这个值默认为 18000，当系统中处于 TIME_WAIT 的连接一旦超过这个值时，系统就会将后面的 TIME_WAIT 连接状态重置。
这个方法过于暴力，而且治标不治本，带来的问题远比解决的问题多，不推荐使用。
方式三：程序中使用 SO_LINGER
我们可以通过设置 socket 选项，来设置调用 close 关闭连接行为。
struct linger so_linger; so_linger.l_onoff = 1; so_linger.l_linger = 0; setsockopt(s, SOL_SOCKET, SO_LINGER, &so_linger,sizeof(so_linger));
如果 l_onoff 为非 0， 且 l_linger 值为 0，那么调用 close 后，会立该发送一个 RST 标志给对端，该 TCP 连接将跳过四次挥手，也就跳过了 TIME_WAIT 状态，直接关闭。
但这为跨越 TIME_WAIT 状态提供了一个可能，不过是一个非常危险的行为，不值得提倡。
如果已经建立了连接，但是客户端突然出现故障了怎么办？
TCP 有一个机制是保活机制。这个机制的原理是这样的：
定义一个时间段，在这个时间段内，如果没有任何连接相关的活动，TCP 保活机制会开始作用，每隔一个时间间隔，发送一个探测报文，该探测报文包含的数据非常少，如果连续几个探测报文都没有得到响应，则认为当前的 TCP 连接已经死亡，系统内核将错误信息通知给上层应用程序。
在 Linux 内核可以有对应的参数可以设置保活时间、保活探测的次数、保活探测的时间间隔，以下都为默认值：
net.ipv4.tcp_keepalive_time=7200 net.ipv4.tcp_keepalive_intvl=75 net.ipv4.tcp_keepalive_probes=9 # 表示保活时间是 7200 秒（2小时），也就 2 小时内如果没有任何连接相关的活动，则会启动保活机制 tcp_keepalive_time=7200 # 表示每次检测间隔 75 秒 tcp_keepalive_intvl=75 # 表示检测 9 次无响应，认为对方是不可达的，从而中断本次的连接。 tcp_keepalive_probes=9：
也就是说在 Linux 系统中，最少需要经过 2 小时 11 分 15 秒才可以发现一个「死亡」连接。
这个时间是有点长的，我们也可以根据实际的需求，对以上的保活相关的参数进行设置。
如果开启了 TCP 保活，需要考虑以下几种情况：
第一种，对端程序是正常工作的。当 TCP 保活的探测报文发送给对端, 对端会正常响应，这样 TCP 保活时间会被重置，等待下一个 TCP 保活时间的到来。
第二种，对端程序崩溃并重启。当 TCP 保活的探测报文发送给对端后，对端是可以响应的，但由于没有该连接的有效信息，会产生一个 RST 报文，这样很快就会发现 TCP 连接已经被重置。
第三种，是对端程序崩溃，或对端由于其他原因导致报文不可达。当 TCP 保活的探测报文发送给对端后，石沉大海，没有响应，连续几次，达到保活探测次数后，TCP 会报告该 TCP 连接已经死亡。
初始序列号 ISN为什么不同？
主要原因是为了防止历史报文被下一个相同四元组的连接接收。
如果一个已经失效的连接被重用了，但是该旧连接的历史报文还残留在网络中，如果序列号相同，那么就无法分辨出该报文是不是历史报文，如果历史报文被新的连接接收了，则会产生数据错乱。所以，每次建立连接前重新初始化一个序列号主要是为了通信双方能够根据序号将不属于本连接的报文段丢弃。
另一方面是为了安全性，防止黑客伪造的相同序列号的 TCP 报文被对方接收。
初始序列号 ISN 是如何随机产生的？
起始 ISN 是基于时钟的，每 4 毫秒 + 1，转一圈要 4.55 个小时。
RFC1948 中提出了一个较好的初始化序列号 ISN 随机生成算法。
ISN = M + F (localhost, localport, remotehost, remoteport)
M 是一个计时器，这个计时器每隔 4 毫秒加 1。
F 是一个 Hash 算法，根据源 IP、目的 IP、源端口、目的端口生成一个随机数值。要保证 Hash 算法不能被外部轻易推算得出，用 MD5 算法是一个比较好的选择。
TIME_WAIT 状态不是会持续 2 MSL 时长，历史报文不是早就在网络中消失了吗？
是的，如果能正常四次挥手，由于 TIME_WAIT 状态会持续 2 MSL 时长，历史报文会在下一个连接之前就会自然消失。
但是来了，我们并不能保证每次连接都能通过四次挥手来正常关闭连接。
假设每次建立连接，客户端和服务端的初始化序列号都是从 0 开始：
过程如下：
- 客户端和服务端建立一个 TCP 连接，在客户端发送数据包被网络阻塞了，而此时服务端的进程重启了，于是就会发送 RST 报文来断开连接。
- 紧接着，客户端又与服务端建立了与上一个连接相同四元组的连接；
- 在新连接建立完成后，上一个连接中被网络阻塞的数据包正好抵达了服务端，刚好该数据包的序列号正好是在服务端的接收窗口内，所以该数据包会被服务端正常接收，就会造成数据错乱。
可以看到，如果每次建立连接，客户端和服务端的初始化序列号都是一样的话，很容易出现历史报文被下一个相同四元组的连接接收的问题。
客户端和服务端的初始化序列号不一样不是也会发生这样的事情吗？
是的，即使客户端和服务端的初始化序列号不一样，也会存在收到历史报文的可能。
但是我们要清楚一点，历史报文能否被对方接收，还要看该历史报文的序列号是否正好在对方接收窗口内，如果不在就会丢弃，如果在才会接收。
如果每次建立连接客户端和服务端的初始化序列号都「不一样」，就有大概率因为历史报文的序列号「不在」对方接收窗口，从而很大程度上避免了历史报文，比如下图：
相反，如果每次建立连接客户端和服务端的初始化序列号都「一样」，就有大概率遇到历史报文的序列号刚「好在」对方的接收窗口内，从而导致历史报文被新连接成功接收。
所以，每次初始化序列号不一样能够很大程度上避免历史报文被下一个相同四元组的连接接收，注意是很大程度上，并不是完全避免了。
客户端和服务端的初始化序列号不一样不是也会发生这样的事情吗？
是的，但是也不是完全避免了。
为了能更好的理解这个原因，我们先来了解序列号（SEQ）和初始序列号（ISN）。
- 序列号，是 TCP 一个头部字段，标识了 TCP 发送端到 TCP 接收端的数据流的一个字节，因为 TCP 是面向字节流的可靠协议，为了保证消息的顺序性和可靠性，TCP 为每个传输方向上的每个字节都赋予了一个编号，以便于传输成功后确认、丢失后重传以及在接收端保证不会乱序。序列号是一个 32 位的无符号数，因此在到达 4G 之后再循环回到 0。
- 初始序列号，在 TCP 建立连接的时候，客户端和服务端都会各自生成一个初始序列号，它是基于时钟生成的一个随机数，来保证每个连接都拥有不同的初始序列号。初始化序列号可被视为一个 32 位的计数器，该计数器的数值每 4 微秒加 1，循环一次需要 4.55 小时。
通过前面我们知道，序列号和初始化序列号并不是无限递增的，会发生回绕为初始值的情况，这意味着无法根据序列号来判断新老数据。
不要以为序列号的上限值是 4GB，就以为很大，很难发生回绕。在一个速度足够快的网络中传输大量数据时，序列号的回绕时间就会变短。如果序列号回绕的时间极短，我们就会再次面临之前延迟的报文抵达后序列号依然有效的问题。
为了解决这个问题，就需要有 TCP 时间戳。tcp_timestamps 参数是默认开启的，开启了 tcp_timestamps 参数，TCP 头部就会使用时间戳选项，它有两个好处，一个是便于精确计算 RTT ，另一个是能防止序列号回绕（PAWS）。
试看下面的示例，假设 TCP 的发送窗口是 1 GB，并且使用了时间戳选项，发送方会为每个 TCP 报文分配时间戳数值，我们假设每个报文时间加 1，然后使用这个连接传输一个 6GB 大小的数据流。
32 位的序列号在时刻 D 和 E 之间回绕。假设在时刻B有一个报文丢失并被重传，又假设这个报文段在网络上绕了远路并在时刻 F 重新出现。如果 TCP 无法识别这个绕回的报文，那么数据完整性就会遭到破坏。
使用时间戳选项能够有效的防止上述问题，如果丢失的报文会在时刻 F 重新出现，由于它的时间戳为 2，小于最近的有效时间戳（5 或 6），因此防回绕序列号算法（PAWS）会将其丢弃。
防回绕序列号算法要求连接双方维护最近一次收到的数据包的时间戳（Recent TSval），每收到一个新数据包都会读取数据包中的时间戳值跟 Recent TSval 值做比较，如果发现收到的数据包中时间戳不是递增的，则表示该数据包是过期的，就会直接丢弃这个数据包。
客户端和服务端的初始化序列号都是随机生成，能很大程度上避免历史报文被下一个相同四元组的连接接收，然后又引入时间戳的机制，从而完全避免了历史报文被接收的问题。
你知道 TCP 的最大连接数吗？
有一个 IP 的服务器监听了一个端口，它的 TCP 的最大连接数是多少？
服务器通常固定在某个本地端口上监听，等待客户端的连接请求。因此，客户端 IP 和 端口是可变的，其理论值计算公式如下：
对 IPv4，客户端的 IP 数最多为 2的32次方，客户端的端口数最多为 2的16次方，也就是服务端单机最大 TCP 连接数，约为 2的48次方。
当然，服务端最大并发 TCP 连接数远不能达到理论上限：
- 首先主要是文件描述符限制，Socket 是文件，所以首先要通过 ulimit 配置文件描述符的数目；
- 另一个是内存限制，每个 TCP 连接都要占用一定内存，操作系统的内存是有限的。
end
