TCP缓冲区和4次挥手调优

目录

如何修改TCP缓冲区才能兼顾并发数量与传输速度？

四次挥手性能调优

1,为什么建立连接是三次握手，而关闭连接需要四次挥手呢?

2.四次挥手的流程,注意5个状态 

 3.主动方优化

4,被动方调优

最后

---

如何修改TCP缓冲区才能兼顾并发数量与传输速度？

----------缓冲区动态调节功能-----------

①发送缓冲区自动调整（自动开启）： net.ipv4.tcp_wmem = 4096(动态范围下限) 16384(初始默认值) 4194304(动态范围上限) 一旦发送出的数据被确认，而且没有新的数据要发送，就可以把发送缓冲区的内存释放掉

②接收缓冲区自动调整（通过设置net.ipv4.tcp_moderate_rcvbuf = 1开启）： net.ipv4.tcp_rmem = 4096(动态范围下限) 87380(初始默认值) 6291456(动态范围上限) 可以依据空闲系统内存的数量来调节接收窗口。如果系统的空闲内存很多，就可以把缓冲区增大一些，这样传给对方的接收窗口也会变大，因而对方的发送速度就会通过增加飞行报文来提升。反之，内存紧张时就会缩小缓冲区，这虽然会减慢速度，但可以保证更多的并发连接正常工作。

③接收缓冲区判断内存空闲的方式： net.ipv4.tcp_mem = 88560 118080 177120 当 TCP 内存小于第 1 个值时，不需要进行自动调节； 在第 1 和第 2 个值之间时，内核开始调节接收缓冲区的大小； 大于第 3 个值时，内核不再为 TCP 分配新内存，此时新连接是无法建立的。 ④带宽时延积的衡量方式：对网络时延多次取样计算平均值，再乘以带宽。

---

四次挥手性能调优

1,为什么建立连接是三次握手，而关闭连接需要四次挥手呢?

这是因为 TCP 不允许连接处于半打开状态时就单向传输数据，所以在三次握手建立连接时，服务器会把 ACK 和 SYN 放在一起发给客户端，其中，ACK 用来打开客户端的发送通道，SYN 用来打开服务器的发送通道。这样，原本的四次握手就降为三次握手了

 

2.四次挥手的流程,注意5个状态 

 

 3.主动方优化

关闭连接有多种方式，比如进程异常退出时，针对它打开的连接，内核就会发送 RST 报文来关闭。RST 的全称是 Reset 复位的意思，它可以不走四次挥手强行关闭连接，但当报文延迟或者重复传输时，这种方式会导致数据错乱，所以这是不得已而为之的关闭连接方案.

安全关闭连接的方式必须通过四次挥手，它由进程调用 close 或者 shutdown 函数发起，这二者都会向对方发送 FIN 报文（shutdown 参数须传入 SHUT_WR 或者 SHUT_RDWR 才会发送 FIN），区别在于 close 调用后，哪怕对方在半关闭状态下发送的数据到达主动方，进程也无法接收。

此时，这个连接叫做孤儿连接，如果你用 netstat -p 命令，会发现连接对应的进程名为空。而 shutdown 函数调用后，即使连接进入了 FIN_WAIT1 或者 FIN_WAIT2 状态，它也不是孤儿连接，进程仍然可以继续接收数据。 

当连接收到 ACK 进入 FIN_WAIT2 状态后，就表示主动方的发送通道已经关闭，接下来将等待对方发送 FIN 报文，关闭对方的发送通道。这时，如果连接是用 shutdown 函数关闭的，连接可以一直处于 FIN_WAIT2 状态。但对于 close 函数关闭的孤儿连接，这个状态不可以持续太久,默认是60秒.这里的60秒和我们TIME_WAIT 状态的60秒一样.这是因为这两个状态都需要保持 2MSL 时长。MSL 全称是 Maximum Segment Lifetime，它定义了一个报文在网络中的最长生存时间（报文每经过一次路由器的转发，IP 头部的 TTL 字段就会减 1，减到 0 时报文就被丢弃，这就限制了报文的最长存活时间）。

四次挥手的主动方，为了应对丢包，允许在 tcp_orphan_retries 次数内重发 FIN 报文。当收到 ACK 报文，连接就进入了 FIN_WAIT2 状态，此时系统的行为依赖这是否为孤儿连接。

如果这是 close 函数关闭的孤儿连接，那么在 tcp_fin_timeout 秒内没有收到对方的 FIN 报文，连接就直接关闭，反之 shutdown 函数关闭的连接则不受此限制。毕竟孤儿连接可能在重发次数内存在数分钟之久，为了应对孤儿连接占用太多的资源，tcp_max_orphans 定义了最大孤儿连接的数量，超过时连接就会直接释放。

当接收到 FIN 报文，并返回 ACK 后，主动方的连接进入 TIME_WAIT 状态。这一状态会持续 1 分钟，为了防止 TIME_WAIT 状态占用太多的资源，tcp_max_tw_buckets 定义了最大数量，超过时连接也会直接释放。当 TIME_WAIT 状态过多时，还可以通过设置 tcp_tw_reuse 和tcp_timestamps 为 1 ，将 TIME_WAIT 状态的端口复用于作为客户端的新连接。

4,被动方调优

被动关闭的连接方应对非常简单，它在回复 ACK 后就进入了 CLOSE_WAIT 状态，等待进程调用 close 函数关闭连接。因此，出现大量 CLOSE_WAIT 状态的连接时，应当从应用程序中找问题。当被动方发送 FIN 报文后，连接就进入 LAST_ACK 状态，在未等来 ACK 时，会在 tcp_orphan_retries 参数的控制下重发 FIN 报文。需要你注意的是，如果被动方迅速调用 close 函数，那么被动方的 ACK 和 FIN 有可能在一个报文中发送，这样看起来，四次挥手会变成三次挥手，这只是一种特殊情况，不用在意。

最后

 接下来，双方在等待 ACK 报文的过程中，都等来了 FIN 报文。这是一种新情况，所以连接会进入一种叫做 CLOSING 的新状态，它替代了 FIN_WAIT2 状态。此时，内核回复 ACK 确认对方发送通道的关闭，仅己方的 FIN 报文对应的 ACK 还没有收到。所以，CLOSING 状态与 LAST_ACK 状态下的连接很相似，它会在适时重发 FIN 报文的情况下最终关闭