tcp三次握手、四次挥手涉及到的优化参数【全】

tcp三次握手

tcp_syn_retries

tcp 发送syn重试次数，默认6次

net.ipv4.tcp_syn_retries = 6

第 1 次重试发生在 1 秒钟后，接着会以翻倍的方式在第2、4、8、16、32 秒共做 6 次重试，最后一次重试会等待 64 秒，如果仍然没有返回ACK，才会终止三次握手。所以，总耗时是 1+2+4+8+16+32+64=127 秒，超过 2 分钟。

tcp_max_syn_backlog

半连接状态的队列大小，默认1024

net.ipv4.tcp_max_syn_backlog = 1024

net.ipv4.tcp_syncookies = 1

开启 syncookies 功能就可以在不使用 SYN 队列的情况下成功建立连接。syncookies 是这么做的：服务器根据当前状态计算出一个值，放在己方发出的 SYN+ACK 报文中发出，当客户端返回 ACK 报文时，取出该值验证，如果合法，就认为连接建立成功。

其中值为 0 时表示关闭该功能，2 表示无条件开启功能，而 1 则表示仅当 SYN 半连接队列放不下时，再启用它。由于 syncookie 仅用于应对 SYN 泛洪攻击（攻击者恶意构造大量的 SYN 报文发送给服务器，造成 SYN 半连接队列溢出，导致正常客户端的连接无法建立），这种方式建立的连接，许多 TCP 特性都无法使用。所以，应当把 tcp_syncookies 设置为 1，仅在队列满时再启用。

net.ipv4.tcp_synack_retries = 5

重发 SYN+ACK 报文次数。它的重试会经历1、2、4、8、16 秒，最后一次重试后等待 32 秒，若仍然没有收到 ACK，才会关闭连接，故共需要等待 63 秒。

net.ipv4.tcp_abort_on_overflow = 0

tcp_abort_on_overflow是，当进程未及时调用accept函数，造成accept队列溢出，最终导致连接被丢弃。设置为0关闭丢弃操作，等待进程取出；反之1开启丢弃。

net.core.somaxconn = 128

listen函数的backlog参数表示accepte队列的大小。事实上，backlog参数还受限于Linux系统级的队列长度上限，就是 net.core.somaxconn 控制。
当下各监听端口上的accept队列长度可通过ss -ltn命令查看。
通过netstat -s命令给出的统计结果，可以看到究竟有多少应溢出而被丢弃的连接。

# netstat -s | grep "listen queue" 
14 times the listen queue of a socket overflowed

tcp四次挥手

安全关闭连接的函数有close和shutdown，两者都会向对方发送FIN报文，区别在于，close调用后，哪怕对方在半关闭状态下发送的数据到达主动方，进程也无法接收。

net.ipv4.tcp_orphan_retries = 0

重发FIN报文次数，默认值0，特指8次。

net.ipv4.tcp_max_orphans = 16384

tcp_max_orphans 定义了孤儿连接的最大数量。当进程调用close函数关闭后，无论该连接是在FIN_WAIT1状态，还是确实关闭了，该连接都与该进程无关了，变成孤儿连接。

net.ipv4.tcp_fin_timeout = 60

tcp_fin_timeout 控制连接收到对方发送的FIN报文，处于FIN_WAIT2状态下的持续时长。

net.ipv4.tcp_max_tw_buckets = 5000

当 TIME_WAIT 的连接数量超过该参数时，新关闭的连接就不再经历 TIME_WAIT 而直接关闭。
当服务器的并发连接增多，相应地，同时处于TIME_WAIT状态的连接数量也会变多，此时就应当调大tcp_max_tw_buckets参数，减少不同连接间数据错乱的概率。

net.ipv4.tcp_tw_reuse = 1

允许作为客户端的新连接，在安全条件下使用TIME_WAIT状态下的端口。那怎么判断安全条件呢？有两点：
1、只用用于连接发起方，也就是c/s模型中的客户端
2、对应的TIME_WAIT状态的连接创建时间超过1秒才可以被复用

tcp_tw_recycle

老版本Linux提供了tcp_tw_recycle参数，开启它会有巨大坑，强烈不建议开启。尤其是在NAT、LVS环境下，会导致同一个ip的，时间戳小于上次记录的时间戳的包被丢弃。