TCP总结:

TCP协议建立连接的过程就是双方互相SYN,ACK的过程，断开连接的过程就是互相FIN,ACK的过程。

为什么握手3次，挥手4次?

TCP连接不允许半开状态下单向传递信息，但是可以半关闭情况下单向传递信息
在建立连接的时候服务端的SYN+ACK合并为一次响应发给客户端，但是在断开连接的时候防止应用程序还在传输数据
被动关闭连接的一方受到主动关闭连接的FIN后只会返回ACK,状态变为CLOSE_WAIT，等待应用主动调用close函数才能发FIN请求。
因此握手是3次，挥手是4次。

主动方/被动方没有收到ACK怎么办?

每次SYN和FIN的时候如果没有及时获取到对方ACK就会重发，根据设置，重发次数达到一定后就会废弃掉该行为，直接关闭连接。

• tcp_syn_retries 客户端SYN重发次数设置
• tcp_max_syn_backlog 服务端SYN半连接队列最大长度设置
• tcp_synack_retries 服务端SYN重发次数设置

如何防止SYN泛洪攻击？

SYN泛洪攻击指建立连接的时候只发送SYN，但是收到服务端的SYN+ACK响应后并不返回ACK响应，导致服务端存在大量处于SYN_REC状态的连接，消耗计算机资源，导致不能建立正常的新连接。
当SYN半连接队列满时可开启syncookies功能来建立新的连接，连接信息记录在cookie里，客户端ACK时带上cookie信息，服务端认证通过即可建立正常连接。

• tcp_syncookies = 1 设置开启syncookies

半连接队列满了怎么办？

参考上面的防SYN泛洪攻击

accept队列满了怎么办？

完成握手的功能后Linux就会将连接转移到accpet队列里供应用程序获取调用获取。当应用程序不能及时从队列里取出连接信息时，就会让队列满员溢出，Linux就会默认丢弃新的建立的连接。
我们还可以选择向客户端发送 RST 复位报文，告诉客户端连接已经建立失败。打开这一功能需要将 tcp_abort_on_overflow 参数设置为 1。
通常情况下，应当把 tcp_abort_on_overflow 设置为 0，因为这样更有利于应对突发流量。举个例子，当 accept 队列满导致服务器丢掉了 ACK，与此同时，客户端的连接状态却是 ESTABLISHED，进程就在建立好的连接上发送请求。只要服务器没有为请求回复 ACK，请求就会被多次重发。如果服务器上的进程只是短暂的繁忙造成 accept 队列满，那么当 accept 队列有空位时，再次接收到的请求报文由于含有 ACK，仍然会触发服务器端成功建立连接。所以，tcp_abort_on_overflow 设为 0 可以提高连接建立的成功率，只有你非常肯定 accept 队列会长期溢出时，才能设置为 1 以尽快通知客户端。

• net.core.somaxconn = 128 accept队列长度还受此系统级长度限制

为什么连接关闭主动方需要TIME_WAIT？

主动方处于TIME_WAIT这一状态表示挥手的最后一个状态，但还可以接收处理报文。
如果没有这一状态，这一连接端口可能会被马上复用。
因为网络原因被动方没有收到主动方的ACK就会重发FIN，此时就会错误地把新连接关闭掉。
所以保持这一状态来应付可能重发的FIN或者其它数据包。

TIME_WAIT默认时长

这与孤儿连接 FIN_WAIT2 状态默认保留 60 秒的原理是一样的，因为这两个状态都需要保持 2MSL 时长。MSL 全称是 Maximum Segment Lifetime，它定义了一个报文在网络中的最长生存时间（报文每经过一次路由器的转发，IP 头部的 TTL 字段就会减 1，减到 0 时报文就被丢弃，这就限制了报文的最长存活时间）