TCP 的优化

Posted 2023-03-18

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了TCP 的优化相关的知识，希望对你有一定的参考价值。

参考技术A

整理自 CSDN 公众号

1. 客户端
TCP 三次握手的开始是客户端发起 SYN，如果服务端没有及时回复，那么会重传，重传的间隔和次数是可控的，默认是五次，第一次间隔 1 秒，第二次 2 秒，第三次 4 秒，第四次 8 秒，第五次16 秒，最终超时时间是 63 秒，因此在优化时可以修改重传次数和间隔，以尽快把错误暴露给应用程序。

2. 服务端的半连接队列优化
服务端在第一次返回 SYN + ACK 时，就会把这次请求维护进一个半连接队列，这个队列用来维护尚未完成的握手信息（相对于全连接），如果这个队列溢出了，服务端就无法继续接受新的请求了，这也是 SYN Flood 攻击的点。
通过一个命令 netstat -s 可以得到累计的、由于半连接队列已满引发的失败次数，隔几秒执行一次就可以知道这个次数是否有上升的趋势以及分析是否正常。
这种 SYN Flood 攻击之所以成立，是因为维护这个半连接队列一定要分配一定的内存资源，那么应对的方式之一 syncookies 就是如何不分配资源的前提下，可以确认是一次有效的连接并 establish。
syncookies 的工作原理是，服务器使用一种算法，计算出一个哈希值，它包含了客户端发来请求的部分信息，再将这个哈希值和 SYN+ACK 一起返回给客户端，客户端也经过一些运算，再返回给服务端，那么服务端根据这个返回值和之前的计算值比较，如果合法，就可以建立有效连接，从而不会占据半连接队列的内存。应对 SYN 攻击时，只需将 syncookies 的参数值调为 1（半连接队列溢出时启用），即可。
相当的，可以增大半连接队列，但是要和 accept 的队列同时增大才有效，（否则会导致 accept 队列溢出同样丢失 TCP 连接）
此时，对于客户端来说已经是 established 状态，但是还要再返回给服务端一个 ACK，服务端收到后，服务端才是 established 状态并开始传数据，如果网络不稳定，同样的，服务端会重发 SYN+ACK，当网络不稳定时，应该增加服务端重发 SYN+ACK 的次数。

3. 服务端的 accept 队列优化
当连接已经建立、应用程序尚未调用时，TCP 连接会被保存在一个 accept 队列中，如果进程未能及时调用，就会导致 accept 队列溢出，溢出部分连接将被默认丢弃。对此可以做的是，选择向客户端发送 RST 报文，告知关闭这个连接，丢弃握手过程。打开这一功能需要将 tcp_abort_on_overflow 参数设置为 1。如果想让客户端了解是由于 accept 队列溢出造成连接失败可以这样做。当 tcp_abort_on_overflow 参数设置为 0 时，则如果 accept 队列溢出，就会丢弃客户端传来的 ACK（用于最后一次握手）。
应对高并发流量时，更好的选择是 tcp_abort_on_overflow 参数设置为 0，这样对于客户端它的状态仍然是 established，客户端会定时发送带有 ack 报文的发送数据请求，一旦服务端的 accept 队列有空位，那么连接仍有可能建立成功。所以只有很确定在一段时间内 accept 都是将溢出的状态，才推荐 tcp_abort_on_overflow 参数设置为 1。
同样的，可以调整 accept 队列长度，也可以查看累计的由于溢出导致丢失的连接总数，来判断趋势。

在 Linux 3.7 内核版本之后，提供了 TCP Fast Open 功能，这个功能如此生效：
初次建立 TCP 连接时，客户端在第一个 SYN 包中传入一个请求 cookie，表明打开 fast open 功能，服务端对应生成一个 cookie 给客户端，除此之外，三次握手没有不同，但是，在 cookie 没有过期之前，下一次再连接的时候，客户端发送带有 cookie 的 SYN 包，服务端校验了 cookie 有效以后，就可以开始传输数据了，从而节约了一个往返的时间消耗。
TCP Fast Open 功能需要服务端和客户端同时打开才能生效。

（备注一个之前看到差点忘了的知识点。
当主动方收到被动方的 FIN 报文后，内核会回复 ACK 报文给被动方，同时主动方的连接状态由 FIN_WAIT2 变为 TIME_WAIT，在 Linux 系统下大约等待 1 分钟后，TIME_WAIT 状态的连接才会彻底关闭。

1. 主动方的优化
关闭的方式有两种 RST 和 FIN，RST 是暴力关闭连接的方式，安全关闭连接则必须四次挥手。
FIN 报文关闭则可以使用 close 和 shutdown 两种函数来实现。close 相对来说是“不优雅”的，调用 close 的一方的连接叫做「孤儿连接」，会同时关闭读和写，而 shutdown 可以控制是读还是写。
关闭读的时候，会丢弃接收缓冲区里的所有数据，如果后续再接受到数据，也会悄悄丢弃，并发送 ACK，对方不会知道被丢弃了。
关闭写的时候，会把发送缓冲区的数据全部发送并发送 FIN。

（1）FIN_WAIT1 的优化
主动方发送 FIN 以后，进入 FIN_WAIT1 状态，如果迟迟没收到 ACK，会定时重发 FIN，重发次数由 tcp_orphan_retries 参数控制，默认为 8 次，如果处于 FIN_WAIT1 状态的连接过多，应该考虑降低次数，重发次数超过参数时，连接会被直接关闭。
如果遇到恶意攻击，可能无法发送出 FIN，因为 TCP 按顺序发送所有包， FIN 也不能绕过，另外如果对方的接收窗口已经满了，发送方也无法再发送数据。
此时应该做的是调整 tcp_max_orphans 参数，它定义了「孤儿连接」的最大数量，当系统中的孤儿连接超过参数值，新增的孤儿连接不会再处于 FIN_WAIT1 状态，而是会被 RST 报文直接关闭。（只会影响 CLOSE 函数关闭的连接，不会影响 shutdown 关闭的，不会影响还有读或写的可能）

（2）FIN_WAIT2 的优化
主动方收到 ACK 后，会处于 FIN_WAIT2，因为被动方还可能有数据发送，如果是 shutdown 关闭，那它也可能还会发送数据，但是对于 close 关闭的连接，无法再发送和接收数据，保持在 FIN_WAIT2 的状态已经没有太大意义，tcp_fin_timeout 控制了这个状态下连接的持续时长，默认值是 60 秒。这个时间和 TIME_WAIT 状态时长是一致的。

（3）TIME_WAIT 的优化
TIME_WAIT 和 FIN_WAIT2 的时间是一致的，都是 2MSL，1MSL 表示一个报文在网络中存活的最长时间（报文每经过一次路由器的转发，IP 头部的 TTL 字段就会减 1，减到 0 时报文就被丢弃，这就限制了报文的最长存活时间），那么为什么是等待 2MSL 呢，其实就是允许报文至少丢失一次、再发送一次，这样第一个丢失了，等待的时间里第二个 ACK 还会到达，为什么不是 4MSL 以上呢，这是一个概率的问题，如果一个网络丢包率达到 1%，那么连续两次丢包的概率是万分之一，不必为了这种概率增加等待的时长。
TIME_WAIT 有存在的意义，但是太多保持在这种状态的连接会占用双方资源，占据客户端的端口资源和服务端的系统资源。
Linux 提供了 tcp_max_tw_buckets 参数，当 TIME_WAIT 的连接数量超过该参数时，新关闭的连接就不再经历 TIME_WAIT 而直接关闭。这个参数的设定应该取一个平衡点，即既不会太少导致高并发时产生连接间数据错乱的问题，也不会太多而导致耗尽端口和线程资源。

对于用户端来讲，还可以启用 tcp_tw_reuse 参数来复用处于 TIME_WAIT 状态的连接（来节约接口资源。）这个参数有几个前提，一个是只有客户端可以打开，一个是 TIME_WAIT 状态也要保持 1 秒，另一个是要同步打开时间戳功能，报文带上时间戳就可以避免没有了 2MSL 时长以后的混乱情况，时间戳过期的报文就会被丢掉。

另外对于 TIME_WAIT，还可以调整 socket 选项，来达到调用 close 关闭连接时跳过四次挥手直接关闭的效果，但不推荐。

2. 被动方的优化
首先，被动方收到 FIN 时，会自动回复 ACK，接着等待应用程序调用 close/shutdown 来结束连接，再发送 FIN。如果系统中同时查看到多个连接处于 CLOSE_WAIT 状态，则需要排查是否是应用程序出了故障。
然后，当被动方也发送了 FIN 以后，还需要等待主动方回复一个 ACK，如果迟迟没收到，也会重发 FIN，重发次数也是 tcp_orphan_retries 参数控制，这点和主动方的优化一致，可以调整次数。（需确认被动方是否有 tcp_max_orphans 参数）

3. 如果双方同时关闭？

1. ACK 延迟
目前在 TCP 中每传输一个报文都要求接收方进行确认，大量短而频繁的确认报文给网络带来了很多开销。因此采取了延迟 ACK 策略来减少 ACK 的数量，就是接收方收到一个报文以后，不会立即发送 ACK，而是等待 1~200ms，这期间若有回送数据报文就捎带确认，但收到两个连续数据报文或者等待超时则发送一个独立确认。有效减少了 ACK 的数量，改善了 TCP 的整体性能。

2. 滑动窗口
接收方的接收缓冲区不是不变的，接收到新的会变小，应用程序取出后又会变大，因此接收方会把自己当前的接收窗口大小放在 TCP 头告知发送方，如果不考虑拥塞控制，发送方的窗口大小「约等于」接收方的窗口大小。
对于这一点，可以把 tcp_window_scaling 配置设为 1（默认打开）来扩大 TCP 通告窗口至 1G 大小。要使用这一选项，需要主动方在 SYN 中先告知，被动方在 SYN 中再反馈。
但是缓冲区并非越大越好，还要考虑网络吞吐的能力。如果缓冲区与网络传输能力匹配，那么缓冲区的利用率就达到了最大化。

3. 调整缓冲区大小
这里需要说一个概念，就是带宽时延积，它决定网络中飞行报文的大小，它的计算方式：

（1）发送缓冲区的调整
发送缓冲区是自行调节的，当发送方发送的数据被确认后，并且没有新的数据要发送，就会把发送缓冲区的内存释放掉。
接收缓冲区要复杂一些：

上面三个数字单位都是字节，它们分别表示：

（2）接收缓冲区的调整
接收缓冲区可以根据系统空闲内存的大小来调节接收窗口：

（3）内存的判断
那么如何判断内存紧张或充分呢？

上面三个数字单位不是字节，而是「页面大小」，1 页表示 4KB，它们分别表示：

在实际的场景中，TCP 缓冲区最小值保持默认 4K 即可，来提高并发处理能力；最大值则尽可能靠近带宽时延积，来最大化网络效率。

总结以上：为了提高并发能力、提高网络效率，我们要充分利用网络能力和自己的内存。网络这方面就是将缓冲区大小的极值尽可能靠近带宽时延积，而同时对缓冲区的自动调节需要结合内存来判断，这个 TCP 内存的判断是通过系统内存计算出来的几个值来划分的，在不同区间会对分配给缓冲区的内存大小进行调整。

以上就是 TCP 在不同阶段的优化策略和思路，有关拥塞控制和流量控制之后再补一篇笔记。

Linux内核性能优化TCP调优

前言

TCP 是面向连接的、可靠的、双向传输的传输层通信协议，所以在传输数据之前需要经过三次握手才能建立连接。

接下来，将以三个角度来阐述提升 TCP 的策略，分别是：

TCP 三次握手的性能提升；
TCP 四次挥手的性能提升；
TCP 数据传输的性能提升；

一、TCP三次握手原理

三次握手的过程在一个 HTTP 请求的平均时间占比 10% 以上，在网络状态不佳、高并发或者遭遇 SYN 攻击等场景中，如果不能有效正确的调节三次握手中的参数，就会对性能产生很多的影响。

如何正确有效的使用这些参数，来提高 TCP 三次握手的性能，这就需要理解「三次握手的状态变迁」，这样当出现问题时，先用 netstat 命令查看是哪个握手阶段出现了问题。

三次握手建立连接的首要目的是「同步序列号」。

只有同步了序列号才有可靠传输，TCP 许多特性都依赖于序列号实现，比如流量控制、丢包重传等，这也是三次握手中的报文称为 SYN 的原因，SYN 的全称就叫 Synchronize Sequence Numbers（同步序列号）。

客户端作为主动发起连接方，首先它将发送 SYN 包，于是客户端的连接就会处于 SYN_SENT 状态。

当服务端收到 SYN 包后，服务端会立马回复 SYN+ACK 包，表明确认收到了客户端的序列号，同时也把自己的序列号发给对方。

此时，服务端出现了新连接，状态是 SYN_RCV。在这个状态下，Linux 内核就会建立一个「半连接队列」来维护「未完成」的握手信息，当半连接队列溢出后，服务端就无法再建立新的连接。

二、TCP四次挥手原理

客户端和服务端双方都可以主动断开连接，通常先关闭连接的一方称为主动方，后关闭连接的一方称为被动方。

可以看到，四次挥手过程只涉及了两种报文，分别是 FIN 和 ACK：

FIN 就是结束连接的意思，谁发出 FIN 报文，就表示它将不会再发送任何数据，关闭这一方向上的传输通道；
ACK 就是确认的意思，用来通知对方：你方的发送通道已经关闭;

四次挥手的过程:

当主动方关闭连接时，会发送 FIN 报文，此时发送方的 TCP 连接将从 ESTABLISHED 变成 FIN_WAIT1。
当被动方收到 FIN 报文后，内核会自动回复 ACK 报文，连接状态将从 ESTABLISHED 变成 CLOSE_WAIT，表示被动方在等待进程调用 close 函数关闭连接。
当主动方收到这个 ACK 后，连接状态由 FIN_WAIT1 变为 FIN_WAIT2，也就是表示主动方的发送通道就关闭了。
当被动方进入 CLOSE_WAIT 时，被动方还会继续处理数据，等到进程的 read 函数返回 0 后，应用程序就会调用 close 函数，进而触发内核发送 FIN 报文，此时被动方的连接状态变为 LAST_ACK。
当主动方收到这个 FIN 报文后，内核会回复 ACK 报文给被动方，同时主动方的连接状态由 FIN_WAIT2 变为 TIME_WAIT，在 Linux 系统下大约等待 1 分钟后，TIME_WAIT 状态的连接才会彻底关闭。
当被动方收到最后的 ACK 报文后，被动方的连接就会关闭。

你可以看到，每个方向都需要一个 FIN 和一个 ACK，因此通常被称为四次挥手。
这里一点需要注意是：主动关闭连接的，才有 TIME_WAIT 状态。

关闭的连接的方式通常有两种，分别是 RST 报文关闭和 FIN 报文关闭。

如果进程异常退出了，内核就会发送 RST 报文来关闭，它可以不走四次挥手流程，是一个暴力关闭连接的方式。

安全关闭连接的方式必须通过四次挥手，它由进程调用 close 和 shutdown 函数发起 FIN 报文（shutdown 参数须传入 SHUT_WR 或者 SHUT_RDWR 才会发送 FIN）。

三、性能优化

1.TCP三次握手优化

tcp_syn_retries

对于一个新建连接，内核要发送多少个 SYN 连接请求才决定放弃。不应该大于255。
通常，第一次超时重传是在 1 秒后，第二次超时重传是在 2 秒，第三次超时重传是在 4 秒后，第四次超时重传是在 8 秒后，第五次是在超时重传 16 秒后。没错，每次超时的时间是上一次的 2 倍。

当第五次超时重传后，会继续等待 32 秒，如果仍然服务端没有回应 ACK，客户端就会终止三次握手。所以，总耗时是 1+2+4+8+16+32=63 秒，大约 1 分钟左右。

默认值：5
建议值：net.ipv4.tcp_syn_retries = 3
3次也就是间隔15s会放弃重传（实际时间可能稍高，因为需要包括报文传输和处理的时间）

tcp_max_syn_backlog

tcp_max_syn_backlog 是内核保持的未被 ACK 的 SYN 包最大队列长度，超过这个数值后，多余的请求会被丢弃。

默认值：1024
建议值：net.ipv4.tcp_max_syn_backlog = 4096

somaxconn

somaxconn 是一个 socket 上等待应用程序 accept() 的最大队列长度。

默认值：128
建议值：net.core.somaxconn= = 65535

syncookies

当syn_backlog队列溢出时,启用cookies来处理,可防范少量SYN攻击

syncookies 参数主要有以下三个值：

0：表示关闭该功能；
1：表示仅当 SYN 半连接队列放不下时，再启用它；
2：表示无条件开启功能；

默认值：0
建议值：net.ipv4.tcp_syncookies = 1

tcp_synack_retries

如果服务器没有收到 ACK，就会重发 SYN+ACK 报文，synack即为重试次数，原理同tcp_syn_retries

默认值：5
建议值：net.ipv4.tcp_synack_retries = 2

tcp_abort_on_overflow

accept 队列已满，可以选择向客户端发送 RST 复位报文，告诉客户端连接已经建立失败。

tcp_abort_on_overflow 共有两个值分别是 0 和 1，其分别表示：

0 ：如果 accept 队列满了，那么 server 扔掉 client 发过来的 ack ；
1 ：如果 accept 队列满了，server 发送一个 RST 包给 client，表示废掉这个握手过程和这个连接；

默认值：0
建议值：net.ipv4.tcp_abort_on_overflow = 0

2.TCP四次挥手优化

tcp_orphan_retries

四次挥手主动方发送 FIN 报文后，连接就处于 FIN_WAIT1 状态，正常情况下，如果能及时收到被动方的 ACK，则会很快变为 FIN_WAIT2 状态。

但是当迟迟收不到对方返回的 ACK 时，连接就会一直处于 FIN_WAIT1 状态。此时，内核会定时重发 FIN 报文，其中重发次数由 tcp_orphan_retries 参数控制（注意，orphan 虽然是孤儿的意思，该参数却不只对孤儿连接有效，事实上，它对所有 FIN_WAIT1 状态下的连接都有效）

默认值：0，特指8次
建议值：net.ipv4.tcp_orphan_retries= 0

tcp_max_orphans

当进程调用了 close 函数关闭连接，此时连接就会是「孤儿连接」，因为它无法在发送和接收数据。Linux 系统为了防止孤儿连接过多，导致系统资源长时间被占用，就提供了 tcp_max_orphans 参数。如果孤儿连接数量大于它，新增的孤儿连接将不再走四次挥手，而是直接发送 RST 复位报文强制关闭。

默认值：8192
如果遇到恶意DOS攻击，FIN 报文根本无法发送出去时，可设置此值

tcp_fin_timeout

对于 close 函数关闭的孤儿连接，由于无法在发送和接收数据，所以这个状态不可以持续太久，而 tcp_fin_timeout 控制了这个状态下连接的持续时长。

默认值：60（秒）
建议值：net.ipv4.tcp_fin_timeout= 15

tcp_max_tw_buckets

定义系统在同一时间最多能有多少 TIME_WAIT 状态，当超过这个值时，系统会直接删掉这个 socket 而不会留下 TIME_WAIT 的状态。

tcp_tw_reuse

依赖 TCP 时间戳，即 net.ipv4.tcp_timestamps = 1，tw_reuse 会根据 TCP 时间戳决定是否复用 TIME_WAIT socket，在 tw_buckets 满的时候，会根据 TCP 时间戳决定是否复用 TIME WAIT socket，选取一个已经持续1秒以上的连接，复用这个五元组，这个选项只对客户端（反代服务器连接 upstream 时也可认为是客户端）有效。

默认值：0
建议值：net.ipv4.tcp_tw_reuse = 1

tcp_timestamps

通常需要开启，用于精确计算RTT，避免序列号回绕时序列号碰撞而产生错误，而且tw_reuse也是需要基于tcp timestamp开启来使用。

默认值：1
建议值：net.ipv4.tcp_timestamps = 1

3.TCP数据传输优化

tcp_window_scaling

tcp_window_scaling表示设置tcp/ip会话的滑动窗口大小是否可变。参数值为布尔值，为1时表示可变，为0时表示不可变。tcp/ip通常使用的窗口最大可达到 65535 字节，对于高速网络，该值可能太小，这时候如果启用了该功能，可以使tcp/ip滑动窗口大小增大数个数量级，从而提高数据传输的能力。

默认值：1
建议值：net.ipv4.tcp_window_scaling = 1

tcp_wmem

tcp_wmem包含3个整数值，分别是：min，default，max
Min：为TCP socket预留用于发送缓冲的内存最小值。每个TCP socket都可以使用它。
Default：为TCP socket预留用于发送缓冲的内存数量，默认情况下该值会影响其它协议使用的net.core.wmem中default的值，一般要低于net.core.wmem中default的值。
Max：为TCP socket预留用于发送缓冲的内存最大值。该值不会影响net.core.wmem_max，今天选择参数SO_SNDBUF则不受该值影响。默认值为 128K。

默认值：4096 16384 131072
建议值：net.ipv4.tcp_wmem = 4096 65536 4194304

tcp_rmem

tcp_rmem包含3个整数值，分别是：min，default，max
Min：为TCP socket预留用于接收缓冲的内存数量，即使在内存出现紧张情况下TCP socket都至少会有这么多数量的内存用于接收缓冲。
Default：为TCP socket预留用于接收缓冲的内存数量，默认情况下该值影响其它协议使用的 net.core.wmem中default的值。该值决定了在tcp_adv_win_scale、tcp_app_win和tcp_app_win的默认值情况下，TCP 窗口大小为65535。
Max：为TCP socket预留用于接收缓冲的内存最大值。该值不会影响 net.core.wmem中max的值，今天选择参数 SO_SNDBUF则不受该值影响。

默认值：4096 87380 174760
建议值：net.ipv4.tcp_rmem = 4096 87380 4194304

tcp_mem

tcp_mem包含3个整数值，分别是：low，pressure，high
Low：当TCP使用了低于该值的内存页面数时，TCP不会考虑释放内存。
Pressure：当TCP使用了超过该值的内存页面数量时，TCP试图稳定其内存使用，进入pressure模式，当内存消耗低于low值时则退出 pressure状态。
High：允许所有tcp sockets用于排队缓冲数据报的页面量。
一般情况下这些值是在系统启动时根据系统内存数量计算得到的。

默认值：24576 32768 49152
建议值：net.ipv4.tcp_mem = 786432 1048576 1572864

四、参数汇总

上述TCP调优参数汇总，将如下内容写入：/etc/sysctl.conf，执行sysctl -p 命令使配置文件生效。

注意：

不要以为我们在/etc/sysctl.conf 中配置了a.b.c = 1 ；sysctl -p 之后就可以在/proc/sys/就生成对应的目录和文件，结果是error的
sysctl -p 不会重新载入未定义的配置的默认值的，只会更新配置文件中配置的内容，不会影响没有配置到的内容。

net.ipv4.tcp_syn_retries = 3
net.ipv4.tcp_max_syn_backlog = 4096
net.core.somaxconn= = 65535
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_synack_retries = 2
net.ipv4.tcp_fin_timeout= 15
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_timestamps = 1
net.ipv4.tcp_window_scaling = 1
net.ipv4.tcp_wmem = 4096 65536 4194304
net.ipv4.tcp_rmem = 4096 87380 4194304
net.ipv4.tcp_mem = 786432 1048576 1572864

结尾

感谢大家的耐心阅读，如有建议请私信或评论留言。
如有收获，劳烦支持，关注、点赞、评论、收藏均可，博主会经常更新，与大家共同进步

以上是关于TCP 的优化的主要内容，如果未能解决你的问题，请参考以下文章

Linux内核性能优化TCP调优

[usb][tcp]usbredir的优化---TCP keepalive

从 TCP/IP 协议谈 Linux 内核参数优化

linux的基础优化(期中架构方面的优化)

Linux系统TCP内核参数优化总结

一般优化linux的内核，需要优化啥参数