关于TCP连接的过程就不再赘述了，直接看下图。

我们从一次tcp的传输开始分析，从建立连接、数据传输和断开连接三部分。

建立连接阶段net.ipv4.tcp_syn_retries

syn重传次数，如果服务端没有响应ack，则会重传设定的次数。

如果在内网中，中间链路少，网络比较稳定，可以调低重传次数，让客户端尽快失败。这个和架构设计中fail fast原理类似。

net.ipv4.tcp_syncookies

SYN Cookies开关，主要是针对syn泛洪攻击。

net.ipv4.tcp_synack_retries

控制服务端发送syn+ack次数

和上面syn一样，如果是内网环境，可以调低重传次数。

net.ipv4.tcp_max_syn_backlog

半连接队列长度设置。

所谓半连接是指服务端收到了客户端的 SYN 包后，就会把这个连接放到半连接队列中，然后再向客户端发送 SYN+ACK 。为了应对新建连接数暴增的场景，建议调大，半连接队列溢出观察方法：netstat -s | grep "SYNs to LISTEN"

net.core.somaxconn

全连接队列长度

和上面半连接对应，所谓全连接队列是指服务端已经收到客户端三次握手第三步的 ACK，然后就会把这个连接放到全连接队列中。

进入全连接队列中的连接会被触发 accept() 系统调用，如果并发比较高的情况下，建议适当调大，全连接队列溢出观察方法：netstat -s | grep "listen queue"

net.ipv4.tcp_abort_on_overflow

当全连接队列满了之后，新的连接就会被丢弃掉。服务端在将新连接丢弃时，默认行为是直接丢弃不会去通知客户端，有的时候需要发送 reset 通知客户端连接被重置，这样客户端就不会再次重试，至于是否需要给客户端安发送 reset，是由 tcp_abort_on_overflow参数控制，默认为 0，即不发送 reset 给 客户端。

二、数据传输阶段net.ipv4.tcp_wmem

tcp发送缓冲区大小，包含min、default、max三个值，内核会控制发送缓冲区在min-max之间动态调整，可根据实际业务场景和服务器配置适当调大。

net.core.wmem_max

socket发送缓冲区的最大值，需要设置 net.core.wmem_max 的值大于等于 net.ipv4.tcp_wmem 的 max值。

net.ipv4.tcp_mem

系统中所有tcp连接最多可消耗的内存，有三个值，当 TCP 总内存小于第 1 个值时，不需要内核进行自动调节，在第 1 和第 2 个值之间时，内核开始调节缓冲区的大小，大于第 3 个值时，内核不再为 TCP 分配新内存，此时无法新建连接，需要注意的是，三个值的单位都是内存页，也就是4KB

net.ipv4.tcp_rmem

tcp接收缓冲区大小，包含min、default、max三个值，内核会控制接收缓冲区在min-max之间动态调整，可根据实际业务场景和服务器配置适当调大。

net.core.rmem_max

socket接收缓冲区的最大值，需要设置 net.core.rmem_max 的值大于等于 net.ipv4.tcp_rmem 的 max值

net.ipv4.tcp_moderate_rcvbuf

接收缓冲区动态调整功能，默认打开，建议保持默认配置

net.ipv4.tcp_window_scaling

扩充滑动窗口，当网络传输比较流畅时，TCP会增加滑动窗口大小，以便加速网络传输。默认打开，建议保持默认配置

net.ipv4.tcp_keepalive_probes、net.ipv4.tcp_keepalive_intvl 、net.ipv4.tcp_keepalive_time

linux控制keepalive有三个参数。保活时间net.ipv4.tcp_keepalive_time、保活时间间隔net.ipv4.tcp_keepalive_intvl、保活探测次数net.ipv4.tcp_keepalve_probes，默认值分别是 7200 秒（2 小时）、75 秒和 9 次探测。如果使用 TCP 自身的 keep-Alive 机制，在 Linux 系统中，最少需要经过 2 小时 + 9*75 秒后断开。

net.ipv4.tcp_available_congestion_control

查看内核支持的拥塞控制算法

net.ipv4.tcp_congestion_control

配置拥塞控制算法，默认cubic，内核4.9版本后支持BBR，弱网络条件下建议配置成BBR

三、断开连接阶段net.ipv4.tcp_fin_timeout

是从Fin_WAIT_2到TIME_WAIT的超时时间，长时间收不到对端FIN包，大概率是对端机器有问题，不能及时调用close()关闭连接，建议调低，避免等待时间太长，资源开销过大

net.ipv4.tcp_max_tw_buckets

系统TIME_WAIT连接的最大数量，根据实际业务需要调整，超过最大值后dmesg会有报错TCP: time wait bucket table overflow。

net.ipv4.tcp_tw_reuse

允许TIME_WAIT状态的连接复用，客户端可开启

net.ipv4.tcp_tw_recycle

开启后，TIME_WAIT状态的连接不用等待2MSL时间就可用于新建连接，在NAT环境下，开启tcp_tw_recycle参数会触发PAWS机制导致丢包，建议不开启，事实上，内核在4.1版本后就把这个参数删除了