关于java:面试官换人换人TCP-这几个参数都不懂也来面试

TCP 性能的晋升不仅考查 TCP 的理论知识，还考查了对于操作系统提供的内核参数的了解与利用。

TCP 协定是由操作系统实现，所以操作系统提供了不少调节 TCP 的参数。

如何正确无效的应用这些参数，来进步 TCP 性能是一个不那么简略事件。咱们须要针对 TCP 每个阶段的问题来隔靴搔痒，而不是病急乱投医。

接下来，将以三个角度来论述晋升 TCP 的策略，别离是：

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

TCP 是面向连贯的、牢靠的、双向传输的传输层通信协议，所以在传输数据之前须要通过三次握手能力建设连贯。

那么，三次握手的过程在一个 HTTP 申请的均匀工夫占比 10% 以上，在网络状态不佳、高并发或者遭逢 SYN 攻打等场景中，如果不能无效正确的调节三次握手中的参数，就会对性能产生很多的影响。

如何正确无效的应用这些参数，来进步 TCP 三次握手的性能，这就须要了解「三次握手的状态变迁」，这样当呈现问题时，先用 netstat 命令查看是哪个握手阶段呈现了问题，再来隔靴搔痒，而不是病急乱投医。

客户端和服务端都能够针对三次握手优化性能。被动发动连贯的客户端优化绝对简略些，而服务端须要监听端口，属于被动连贯方，其间放弃许多的中间状态，优化办法绝对简单一些。

所以，客户端（被动发动连贯方）和服务端（被动连贯方）优化的形式是不同的，接下来别离针对客户端和服务端优化。

三次握手建设连贯的首要目标是「同步序列号」。

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

SYN_SENT 状态的优化

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

客户端在期待服务端回复的 ACK 报文，失常状况下，服务器会在几毫秒内返回 SYN+ACK，但如果客户端长时间没有收到 SYN+ACK 报文，则会重发 SYN 包，重发的次数由 tcp_syn_retries 参数管制，默认是 5 次：

通常，第一次超时重传是在 1 秒后，第二次超时重传是在 2 秒，第三次超时重传是在 4 秒后，第四次超时重传是在 8 秒后，第五次是在超时重传 16 秒后。没错，每次超时的工夫是上一次的 2 倍。

当第五次超时重传后，会持续期待 32 秒，如果服务端依然没有回应 ACK，客户端就会终止三次握手。

所以，总耗时是 1+2+4+8+16+32=63 秒，大概 1 分钟左右。

你能够依据网络的稳定性和指标服务器的忙碌水平批改 SYN 的重传次数，调整客户端的三次握手工夫下限。比方内网中通信时，就能够适当调低重试次数，尽快把谬误裸露给应用程序。

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

此时，服务端呈现了新连贯，状态是 SYN_RCV。在这个状态下，Linux 内核就会建设一个「半连贯队列」来保护「未实现」的握手信息，当半连贯队列溢出后，服务端就无奈再建设新的连贯。

SYN 攻打，攻打的是就是这个半连贯队列。

如何查看因为 SYN 半连贯队列已满，而被抛弃连贯的状况？

咱们能够通过该 netstat -s 命令给出的统计后果中，能够失去因为半连贯队列已满，引发的失败次数：

下面输入的数值是累计值，示意共有多少个 TCP 连贯因为半连贯队列溢出而被抛弃。隔几秒执行几次，如果有回升的趋势，阐明以后存在半连贯队列溢出的景象。

如何调整 SYN 半连贯队列大小？

要想增大半连贯队列，不能只单纯增大 tcp_max_syn_backlog 的值，还需一起增大 somaxconn 和 backlog，也就是增大 accept 队列。否则，只单纯增大 tcp_max_syn_backlog 是有效的。

增大 tcp_max_syn_backlog 和 somaxconn 的办法是批改 Linux 内核参数：

增大 backlog 的形式，每个 Web 服务都不同，比方 Nginx 增大 backlog 的办法如下：

最初，扭转了如上这些参数后，要重启 Nginx 服务，因为 SYN 半连贯队列和 accept 队列都是在 listen() 初始化的。

如果 SYN 半连贯队列已满，只能抛弃连贯吗？

并不是这样，开启 syncookies 性能就能够在不应用 SYN 半连贯队列的状况下胜利建设连贯。

syncookies 的工作原理：服务器依据以后状态计算出一个值，放在己方收回的 SYN+ACK 报文中收回，当客户端返回 ACK 报文时，取出该值验证，如果非法，就认为连贯建设胜利，如下图所示。

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

0 值，示意敞开该性能；
1 值，示意仅当 SYN 半连贯队列放不下时，再启用它；
2 值，示意无条件开启性能；

那么在应答 SYN 攻打时，只须要设置为 1 即可：

SYN_RCV 状态的优化

当客户端接管到服务器发来的 SYN+ACK 报文后，就会回复 ACK 给服务器，同时客户端连贯状态从 SYN_SENT 转换为 ESTABLISHED，示意连贯建设胜利。

服务器端连贯胜利建设的工夫还要再往后，等到服务端收到客户端的 ACK 后，服务端的连贯状态才变为 ESTABLISHED。

如果服务器没有收到 ACK，就会重发 SYN+ACK 报文，同时始终处于 SYN_RCV 状态。

当网络忙碌、不稳固时，报文失落就会变重大，此时应该调大重发次数。反之则能够调小重发次数。批改重发次数的办法是，调整 tcp_synack_retries 参数：

tcp_synack_retries 的默认重试次数是 5 次，与客户端重传 SYN 相似，它的重传会经验 1、2、4、8、16 秒，最初一次重传后会持续期待 32 秒，如果服务端依然没有收到 ACK，才会敞开连贯，故共须要期待 63 秒。

服务器收到 ACK 后连贯建设胜利，此时，内核会把连贯从半连贯队列移除，而后创立新的齐全的连贯，并将其增加到 accept 队列，期待过程调用 accept 函数时把连贯取出来。

如果过程不能及时地调用 accept 函数，就会造成 accept 队列（也称全连贯队列）溢出，最终导致建设好的 TCP 连贯被抛弃。

accept 队列已满，只能抛弃连贯吗？

抛弃连贯只是 Linux 的默认行为，咱们还能够抉择向客户端发送 RST 复位报文，通知客户端连贯曾经建设失败。关上这一性能须要将 tcp_abort_on_overflow 参数设置为 1。

tcp_abort_on_overflow 共有两个值别离是 0 和 1，其别离示意：

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

如果要想晓得客户端连贯不上服务端，是不是服务端 TCP 全连贯队列满的起因，那么能够把 tcp_abort_on_overflow 设置为 1，这时如果在客户端异样中能够看到很多 connection reset by peer 的谬误，那么就能够证实是因为服务端 TCP 全连贯队列溢出的问题。

通常状况下，该当把 tcp_abort_on_overflow 设置为 0，因为这样更有利于应答突发流量。

举个例子，当 accept 队列满导致服务器丢掉了 ACK，与此同时，客户端的连贯状态却是 ESTABLISHED，客户端过程就在建设好的连贯上发送申请。只有服务器没有为申请回复 ACK，客户端的申请就会被屡次「重发」。如果服务器上的过程只是短暂的忙碌造成 accept 队列满，那么当 accept 队列有空位时，再次接管到的申请报文因为含有 ACK，依然会触发服务器端胜利建设连贯。

所以，tcp_abort_on_overflow 设为 0 能够进步连贯建设的成功率，只有你十分必定 TCP 全连贯队列会长期溢出时，能力设置为 1 以尽快告诉客户端。

如何调整 accept 队列的长度呢？

accept 队列的长度取决于 somaxconn 和 backlog 之间的最小值，也就是 min(somaxconn, backlog)，其中：

somaxconn 是 Linux 内核的参数，默认值是 128，能够通过 net.core.somaxconn 来设置其值；
backlog 是 listen(int sockfd, int backlog) 函数中的 backlog 大小；

Tomcat、Nginx、Apache 常见的 Web 服务的 backlog 默认值都是 511。

如何查看服务端过程 accept 队列的长度？

能够通过 ss -ltn 命令查看：

Recv-Q：以后 accept 队列的大小，也就是以后已实现三次握手并期待服务端 accept() 的 TCP 连贯；
Send-Q：accept 队列最大长度，下面的输入后果阐明监听 8088 端口的 TCP 服务，accept 队列的最大长度为 128；

如何查看因为 accept 连贯队列已满，而被抛弃的连贯？

当超过了 accept 连贯队列，服务端则会丢掉后续进来的 TCP 连贯，丢掉的 TCP 连贯的个数会被统计起来，咱们能够应用 netstat -s 命令来查看：

下面看到的 41150 times，示意 accept 队列溢出的次数，留神这个是累计值。能够隔几秒钟执行下，如果这个数字始终在减少的话，阐明 accept 连贯队列偶然满了。

如果继续一直地有连贯因为 accept 队列溢出被抛弃，就应该调大 backlog 以及 somaxconn 参数。

以上咱们只是在对三次握手的过程进行优化，接下来咱们看看如何绕过三次握手发送数据。

三次握手建设连贯造成的结果就是，HTTP 申请必须在一个 RTT（从客户端到服务器一个往返的工夫）后能力发送。

在 Linux 3.7 内核版本之后，提供了 TCP Fast Open 性能，这个性能能够缩小 TCP 连贯建设的时延。

接下来说说，TCP Fast Open 性能的工作形式。

在客户端首次建设连贯时的过程：

客户端发送 SYN 报文，该报文蕴含 Fast Open 选项，且该选项的 Cookie 为空，这表明客户端申请 Fast Open Cookie；
反对 TCP Fast Open 的服务器生成 Cookie，并将其置于 SYN-ACK 数据包中的 Fast Open 选项以返回客户端；
客户端收到 SYN-ACK 后，本地缓存 Fast Open 选项中的 Cookie。

所以，第一次发动 HTTP GET 申请的时候，还是须要失常的三次握手流程。

之后，如果客户端再次向服务器建设连贯时的过程：

客户端发送 SYN 报文，该报文蕴含「数据」（对于非 TFO 的一般 TCP 握手过程，SYN 报文中不蕴含「数据」）以及此前记录的 Cookie；
反对 TCP Fast Open 的服务器会对收到 Cookie 进行校验：如果 Cookie 无效，服务器将在 SYN-ACK 报文中对 SYN 和「数据」进行确认，服务器随后将「数据」递送至相应的应用程序；如果 Cookie 有效，服务器将抛弃 SYN 报文中蕴含的「数据」，且其随后收回的 SYN-ACK 报文将只确认 SYN 的对应序列号；
如果服务器承受了 SYN 报文中的「数据」，服务器可在握手实现之前发送「数据」，这就缩小了握手带来的 1 个 RTT 的工夫耗费；
客户端将发送 ACK 确认服务器发回的 SYN 以及「数据」，但如果客户端在初始的 SYN 报文中发送的「数据」没有被确认，则客户端将从新发送「数据」；
尔后的 TCP 连贯的数据传输过程和非 TFO 的失常状况统一。

所以，之后发动 HTTP GET 申请的时候，能够绕过三次握手，这就缩小了握手带来的 1 个 RTT 的工夫耗费。

开启了 TFO 性能，cookie 的值是寄存到 TCP option 字段里的：

注：客户端在申请并存储了 Fast Open Cookie 之后，能够一直反复 TCP Fast Open 直至服务器认为 Cookie 有效（通常为过期）。

Linux 下怎么关上 TCP Fast Open 性能呢？

在 Linux 零碎中，能够通过设置 tcp_fastopn 内核参数，来关上 Fast Open 性能：

tcp_fastopn 各个值的意义:

0 敞开
1 作为客户端应用 Fast Open 性能
2 作为服务端应用 Fast Open 性能
3 无论作为客户端还是服务器，都能够应用 Fast Open 性能

TCP Fast Open 性能须要客户端和服务端同时反对，才有成果。

本小结次要介绍了对于优化 TCP 三次握手的几个 TCP 参数。

客户端的优化

当客户端发动 SYN 包时，能够通过 tcp_syn_retries 管制其重传的次数。

服务端的优化

当服务端 SYN 半连贯队列溢出后，会导致后续连贯被抛弃，能够通过 netstat -s 察看半连贯队列溢出的状况，如果 SYN 半连贯队列溢出状况比较严重，能够通过 tcp_max_syn_backlog、somaxconn、backlog 参数来调整 SYN 半连贯队列的大小。

服务端回复 SYN+ACK 的重传次数由 tcp_synack_retries 参数管制。如果蒙受 SYN 攻打，应把 tcp_syncookies 参数设置为 1，示意仅在 SYN 队列满后开启 syncookie 性能，能够保障失常的连贯胜利建设。

服务端收到客户端返回的 ACK，会把连贯移入 accpet 队列，期待进行调用 accpet() 函数取出连贯。

能够通过 ss -lnt 查看服务端过程的 accept 队列长度，如果 accept 队列溢出，零碎默认抛弃 ACK，如果能够把 tcp_abort_on_overflow 设置为 1，示意用 RST 告诉客户端连贯建设失败。

如果 accpet 队列溢出重大，能够通过 listen 函数的 backlog 参数和 somaxconn 零碎参数进步队列大小，accept 队列长度取决于 min(backlog, somaxconn)。

绕过三次握手

TCP Fast Open 性能能够绕过三次握手，使得 HTTP 申请缩小了 1 个 RTT 的工夫，Linux 下能够通过 tcp_fastopen 开启该性能，同时必须保障服务端和客户端同时反对。

接下来，咱们一起看看针对 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）。

调用 close 函数和 shutdown 函数有什么区别？

调用了 close 函数意味着齐全断开连接，齐全断开不仅指无奈传输数据，而且也不能发送数据。此时，调用了 close 函数的一方的连贯叫做「孤儿连贯」，如果你用 netstat -p 命令，会发现连贯对应的过程名为空。

应用 close 函数敞开连贯是不优雅的。于是，就呈现了一种优雅敞开连贯的 shutdown 函数，它能够管制只敞开一个方向的连贯：

第二个参数决定断开连接的形式，次要有以下三种形式：

SHUT_RD(0)：敞开连贯的「读」这个方向，如果接收缓冲区有已接管的数据，则将会被抛弃，并且后续再收到新的数据，会对数据进行 ACK，而后悄悄地抛弃。也就是说，对端还是会接管到 ACK，在这种状况下基本不晓得数据曾经被抛弃了。
SHUT_WR(1)：敞开连贯的「写」这个方向，这就是常被称为「半敞开」的连贯。如果发送缓冲区还有未发送的数据，将被立刻发送进来，并发送一个 FIN 报文给对端。
SHUT_RDWR(2)：相当于 SHUT_RD 和 SHUT_WR 操作各一次，敞开套接字的读和写两个方向。

close 和 shutdown 函数都能够敞开连贯，但这两种形式敞开的连贯，不只性能上有差别，管制它们的 Linux 参数也不雷同。

FIN_WAIT1 状态的优化

被动方发送 FIN 报文后，连贯就处于 FIN_WAIT1 状态，失常状况下，如果能及时收到被动方的 ACK，则会很快变为 FIN_WAIT2 状态。

然而当迟迟收不到对方返回的 ACK 时，连贯就会始终处于 FIN_WAIT1 状态。此时，内核会定时重发 FIN 报文，其中反复次数由 tcp_orphan_retries 参数管制（留神，orphan 尽管是孤儿的意思，该参数却不只对孤儿连贯无效，事实上，它对所有 FIN_WAIT1 状态下的连贯都无效），默认值是 0。

你可能会好奇，这 0 示意几次？实际上当为 0 时，特指 8 次，从上面的内核源码可知：

如果 FIN_WAIT1 状态连贯很多，咱们就须要思考升高 tcp_orphan_retries 的值，当重传次数超过 tcp_orphan_retries 时，连贯就会间接敞开掉。

对于广泛失常状况时，调低 tcp_orphan_retries 就曾经能够了。如果遇到歹意攻打，FIN 报文根本无法发送进来，这由 TCP 两个个性导致的：

首先，TCP 必须保障报文是有序发送的，FIN 报文也不例外，当发送缓冲区还有数据没有发送时，FIN 报文也不能提前发送。
其次，TCP 有流量管制性能，当接管方接管窗口为 0 时，发送方就不能再发送数据。所以，当攻击者下载大文件时，就能够通过接管窗口设为 0，这就会使得 FIN 报文都无奈发送进来，那么连贯会始终处于 FIN_WAIT1 状态。

解决这种问题的办法，是调整 tcp_max_orphans 参数，它定义了「孤儿连贯」的最大数量：

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

FIN_WAIT2 状态的优化

当被动方收到 ACK 报文后，会处于 FIN_WAIT2 状态，就示意被动方的发送通道曾经敞开，接下来将期待对方发送 FIN 报文，敞开对方的发送通道。

这时，如果连贯是用 shutdown 函数敞开的，连贯能够始终处于 FIN_WAIT2 状态，因为它可能还能够发送或接收数据。但对于 close 函数敞开的孤儿连贯，因为无奈再发送和接收数据，所以这个状态不能够继续太久，而 tcp_fin_timeout 管制了这个状态下连贯的继续时长，默认值是 60 秒：

它意味着对于孤儿连贯（调用 close 敞开的连贯），如果在 60 秒后还没有收到 FIN 报文，连贯就会间接敞开。

这个 60 秒不是轻易决定的，它与 TIME_WAIT 状态继续的工夫是雷同的，前面咱们再来说说为什么是 60 秒。

TIME_WAIT 状态的优化

TIME_WAIT 是被动方四次挥手的最初一个状态，也是最常遇见的状态。

当收到被动方发来的 FIN 报文后，被动方会立即回复 ACK，示意确认对方的发送通道曾经敞开，接着就处于 TIME_WAIT 状态。在 Linux 零碎，TIME_WAIT 状态会继续 60 秒后才会进入敞开状态。

TIME_WAIT 状态的连贯，在被动方看来的确快曾经敞开了。而后，被动方没有收到 ACK 报文前，还是处于 LAST_ACK 状态。如果这个 ACK 报文没有达到被动方，被动方就会重发 FIN 报文。重发次数依然由后面介绍过的 tcp_orphan_retries 参数管制。

TIME-WAIT 的状态尤其重要，次要是两个起因：

避免具备雷同「四元组」的「旧」数据包被收到；
保障「被动敞开连贯」的一方能被正确的敞开，即保障最初的 ACK 能让被动敞开方接管，从而帮忙其失常敞开；

起因一：避免旧连贯的数据包

TIME-WAIT 的一个作用是避免收到历史数据，从而导致数据错乱的问题。

假如 TIME-WAIT 没有等待时间或工夫过短，被提早的数据包到达后会产生什么呢？

如上图黄色框框服务端在敞开连贯之前发送的 SEQ = 301 报文，被网络提早了。
这时有雷同端口的 TCP 连贯被复用后，被提早的 SEQ = 301 到达了客户端，那么客户端是有可能失常接管这个过期的报文，这就会产生数据错乱等重大的问题。

所以，TCP 就设计出了这么一个机制，通过 2MSL 这个工夫，足以让两个方向上的数据包都被抛弃，使得原来连贯的数据包在网络中都天然隐没，再呈现的数据包肯定都是新建设连贯所产生的。

起因二：保障连贯正确敞开

TIME-WAIT 的另外一个作用是期待足够的工夫以确保最初的 ACK 能让被动敞开方接管，从而帮忙其失常敞开。

假如 TIME-WAIT 没有等待时间或工夫过短，断开连接会造成什么问题呢？

如上图红色框框客户端四次挥手的最初一个 ACK 报文如果在网络中被失落了，此时如果客户端 TIME-WAIT 过短或没有，则就间接进入了 CLOSE 状态了，那么服务端则会始终处在 LAST-ACK 状态。
当客户端发动建设连贯的 SYN 申请报文后，服务端会发送 RST 报文给客户端，连贯建设的过程就会被终止。

咱们再回过头来看看，为什么 TIME_WAIT 状态要放弃 60 秒呢？这与孤儿连贯 FIN_WAIT2 状态默认保留 60 秒的原理是一样的，因为这两个状态都须要放弃 2MSL 时长。MSL 全称是 Maximum Segment Lifetime，它定义了一个报文在网络中的最长生存工夫（报文每通过一次路由器的转发，IP 头部的 TTL 字段就会减 1，减到 0 时报文就被抛弃，这就限度了报文的最长存活工夫）。

为什么是 2 MSL 的时长呢？这其实是相当于至多容许报文失落一次。比方，若 ACK 在一个 MSL 内失落，这样被动方重发的 FIN 会在第 2 个 MSL 内达到，TIME_WAIT 状态的连贯能够应答。

为什么不是 4 或者 8 MSL 的时长呢？你能够设想一个丢包率达到百分之一的蹩脚网络，间断两次丢包的概率只有万分之一，这个概率切实是太小了，疏忽它比解决它更具性价比。

因而，TIME_WAIT 和 FIN_WAIT2 状态的最大时长都是 2 MSL，因为在 Linux 零碎中，MSL 的值固定为 30 秒，所以它们都是 60 秒。

尽管 TIME_WAIT 状态有存在的必要，但它毕竟会耗费系统资源。如果发动连贯一方的 TIME_WAIT 状态过多，占满了所有端口资源，则会导致无奈创立新连贯。

客户端受端口资源限度：如果客户端 TIME_WAIT 过多，就会导致端口资源被占用，因为端口就 65536 个，被占满就会导致无奈创立新的连贯；
服务端受系统资源限度：因为一个四元组示意 TCP 连贯，实践上服务端能够建设很多连贯，服务端的确只监听一个端口，然而会把连贯扔给解决线程，所以实践上监听的端口能够持续监听。然而线程池解决不了那么多始终一直的连贯了。所以当服务端呈现大量 TIME_WAIT 时，系统资源被占满时，会导致解决不过去新的连贯；

另外，Linux 提供了 tcp_max_tw_buckets 参数，当 TIME_WAIT 的连贯数量超过该参数时，新敞开的连贯就不再经验 TIME_WAIT 而间接敞开：

当服务器的并发连贯增多时，相应地，同时处于 TIME_WAIT 状态的连贯数量也会变多，此时就该当调大 tcp_max_tw_buckets 参数，缩小不同连贯间数据错乱的概率。

tcp_max_tw_buckets 也不是越大越好，毕竟内存和端口都是无限的。

有一种形式能够在建设新连贯时，复用处于 TIME_WAIT 状态的连贯，那就是关上 tcp_tw_reuse 参数。然而须要留神，该参数是只用于客户端（建设连贯的发起方），因为是在调用 connect() 时起作用的，而对于服务端（被动连贯方）是没有用的。

tcp_tw_reuse 从协定角度了解是平安可控的，能够复用处于 TIME_WAIT 的端口为新的连贯所用。

什么是协定角度了解的平安可控呢？次要有两点：

只实用于连贯发起方，也就是 C/S 模型中的客户端；
对应的 TIME_WAIT 状态的连贯创立工夫超过 1 秒才能够被复用。

应用这个选项，还有一个前提，须要关上对 TCP 工夫戳的反对（对方也要关上）：

因为引入了工夫戳，它能带来了些益处：

咱们在后面提到的 2MSL 问题就不复存在了，因为反复的数据包会因为工夫戳过期被天然抛弃；
同时，它还能够避免序列号绕回，也是因为反复的数据包会因为工夫戳过期被天然抛弃；

工夫戳是在 TCP 的选项字段里定义的，开启了工夫戳性能，在 TCP 报文传输的时候会带上发送报文的工夫戳。

咱们来看看开启了 tcp_tw_reuse 性能，如果四次挥手中的最初一次 ACK 在网络中失落了，会产生什么？

上图的流程：

四次挥手中的最初一次 ACK 在网络中失落了，服务端始终处于 LAST_ACK 状态；
客户端因为开启了 tcp_tw_reuse 性能，客户端再次发动新连贯的时候，会复用超过 1 秒后的 time_wait 状态的连贯。但客户端新发的 SYN 包会被疏忽（因为工夫戳），因为服务端比拟了客户端的上一个报文与 SYN 报文的工夫戳，过期的报文就会被服务端抛弃；
服务端 FIN 报文迟迟没有收到四次挥手的最初一次 ACK，于是超时重发了 FIN 报文给客户端；
处于 SYN_SENT 状态的客户端，因为收到了 FIN 报文，则会回 RST 给服务端，于是服务端就来到了 LAST_ACK 状态；
最后的客户端 SYN 报文超时重发了（1 秒钟后），此时就与服务端能正确的三次握手了。

所以大家都会说开启了 tcp_tw_reuse，能够在复用了 time_wait 状态的 1 秒过后胜利建设连贯，这 1 秒次要是破费在 SYN 包重传。

另外，老版本的 Linux 还提供了 tcp_tw_recycle 参数，然而当开启了它，就有两个坑：

Linux 会放慢客户端和服务端 TIME_WAIT 状态的工夫，也就是它会使得 TIME_WAIT 状态会小于 60 秒，很容易导致数据错乱；
另外，Linux 会抛弃所有来自远端工夫戳小于上次记录的工夫戳（由同一个远端发送的）的任何数据包。就是说要应用该选项，则必须保障数据包的工夫戳是枯燥递增的。那么，问题在于，此处的工夫戳并不是咱们通常意义下面的相对工夫，而是一个绝对工夫。很多状况下，咱们是没法保障工夫戳枯燥递增的，比方应用了 NAT、LVS 等状况；

所以，不倡议设置为 1，在 Linux 4.12 版本后，Linux 内核间接勾销了这一参数，倡议敞开它：

另外，咱们能够在程序中设置 socket 选项，来设置调用 close 敞开连贯行为。

如果 l_onoff 为非 0，且 l_linger 值为 0，那么调用 close 后，会立该发送一个 RST 标记给对端，该 TCP 连贯将跳过四次挥手，也就跳过了 TIME_WAIT 状态，间接敞开。

但这为逾越 TIME_WAIT 状态提供了一个可能，不过是一个十分危险的行为，不值得提倡。

当被动方收到 FIN 报文时，内核会主动回复 ACK，同时连贯处于 CLOSE_WAIT 状态，顾名思义，它示意期待利用过程调用 close 函数敞开连贯。

内核没有权力代替过程去敞开连贯，因为如果被动方是通过 shutdown 敞开连贯，那么它就是想在半敞开连贯上接收数据或发送数据。因而，Linux 并没有限度 CLOSE_WAIT 状态的持续时间。

当然，大多数应用程序并不应用 shutdown 函数敞开连贯。所以，当你用 netstat 命令发现大量 CLOSE_WAIT 状态。就须要排查你的应用程序，因为可能因为应用程序呈现了 Bug，read 函数返回 0 时，没有调用 close 函数。

处于 CLOSE_WAIT 状态时，调用了 close 函数，内核就会收回 FIN 报文敞开发送通道，同时连贯进入 LAST_ACK 状态，期待被动方返回 ACK 来确认连贯敞开。

如果迟迟收不到这个 ACK，内核就会重发 FIN 报文，重发次数依然由 tcp_orphan_retries 参数管制，这与被动方重发 FIN 报文的优化策略统一。

还有一点咱们须要留神的，如果被动方迅速调用 close 函数，那么被动方的 ACK 和 FIN 有可能在一个报文中发送，这样看起来，四次挥手会变成三次挥手，这只是一种非凡状况，不必在意。

如果连贯单方同时敞开连贯，会怎么样？

因为 TCP 是双全工的协定，所以是会呈现两方同时敞开连贯的景象，也就是同时发送了 FIN 报文。

此时，下面介绍的优化策略依然实用。两方发送 FIN 报文时，都认为本人是被动方，所以都进入了 FIN_WAIT1 状态，FIN 报文的重发次数仍由 tcp_orphan_retries 参数管制。

接下来，单方在期待 ACK 报文的过程中，都等来了 FIN 报文。这是一种新状况，所以连贯会进入一种叫做 CLOSING 的新状态，它代替了 FIN_WAIT2 状态。接着，单方内核回复 ACK 确认对方发送通道的敞开后，进入 TIME_WAIT 状态，期待 2MSL 的工夫后，连贯主动敞开。

针对 TCP 四次挥手的优化，咱们须要依据被动方和被动方四次挥手状态变动来调整零碎 TCP 内核参数。

被动方的优化

被动发动 FIN 报文断开连接的一方，如果迟迟没收到对方的 ACK 回复，则会重传 FIN 报文，重传的次数由 tcp_orphan_retries 参数决定。

当被动方收到 ACK 报文后，连贯就进入 FIN_WAIT2 状态，依据敞开的形式不同，优化的形式也不同：

如果这是 close 函数敞开的连贯，那么它就是孤儿连贯。如果 tcp_fin_timeout 秒内没有收到对方的 FIN 报文，连贯就间接敞开。同时，为了应答孤儿连贯占用太多的资源，tcp_max_orphans 定义了最大孤儿连贯的数量，超过时连贯就会间接开释。
反之是 shutdown 函数敞开的连贯，则不受此参数限度；

当被动方接管到 FIN 报文，并返回 ACK 后，被动方的连贯进入 TIME_WAIT 状态。这一状态会继续 1 分钟，为了避免 TIME_WAIT 状态占用太多的资源，tcp_max_tw_buckets 定义了最大数量，超过时连贯也会间接开释。

当 TIME_WAIT 状态过多时，还能够通过设置 tcp_tw_reuse 和 tcp_timestamps 为 1，将 TIME_WAIT 状态的端口复用于作为客户端的新连贯，留神该参数只实用于客户端。

被动方的优化

被动敞开的连贯方应答非常简单，它在回复 ACK 后就进入了 CLOSE_WAIT 状态，期待过程调用 close 函数敞开连贯。因而，呈现大量 CLOSE_WAIT 状态的连贯时，该当从应用程序中找问题。

当被动方发送 FIN 报文后，连贯就进入 LAST_ACK 状态，在未等到 ACK 时，会在 tcp_orphan_retries 参数的管制下反复 FIN 报文。

在后面介绍的是三次握手和四次挥手的优化策略，接下来次要介绍的是 TCP 传输数据时的优化策略。

TCP 连贯是由内核保护的，内核会为每个连贯建设内存缓冲区：

如果连贯的内存配置过小，就无奈充沛应用网络带宽，TCP 传输效率就会升高；
如果连贯的内存配置过大，很容易把服务器资源耗尽，这样就会导致新连贯无奈建设；

因而，咱们必须了解 Linux 下 TCP 内存的用处，能力正确地配置内存大小。

TCP 会保障每一个报文都可能到达对方，它的机制是这样：报文收回去后，必须接管到对方返回的确认报文 ACK，如果迟迟未收到，就会超时重发该报文，直到收到对方的 ACK 为止。

所以，TCP 报文收回去后，并不会立马从内存中删除，因为重传时还须要用到它。

因为 TCP 是内核保护的，所以报文寄存在内核缓冲区。如果连贯十分多，咱们能够通过 free 命令察看到 buff/cache 内存是会增大。

如果 TCP 是每发送一个数据，都要进行一次确认应答。当上一个数据包收到了应答了，再发送下一个。这个模式就有点像我和你面对面聊天，你一句我一句，但这种形式的毛病是效率比拟低的。

所以，这样的传输方式有一个毛病：数据包的往返工夫越长，通信的效率就越低。

要解决这一问题不难，并行批量发送报文，再批量确认报文即可。

然而，这引出了另一个问题，发送方能够得心应手的发送报文吗？当然这不事实，咱们还得思考接管方的解决能力。

当接管方硬件不如发送方，或者零碎忙碌、资源缓和时，是无奈霎时解决这么多报文的。于是，这些报文只能被丢掉，使得网络效率非常低。

为了解决这种景象产生，TCP 提供一种机制能够让「发送方」依据「接管方」的理论接管能力管制发送的数据量，这就是滑动窗口的由来。

接管方依据它的缓冲区，能够计算出后续可能接管多少字节的报文，这个数字叫做接管窗口。当内核接管到报文时，必须用缓冲区寄存它们，这样残余缓冲区空间变小，接管窗口也就变小了；当过程调用 read 函数后，数据被读入了用户空间，内核缓冲区就被清空，这意味着主机能够接管更多的报文，接管窗口就会变大。

因而，接管窗口并不是恒定不变的，接管方会把以后可接管的大小放在 TCP 报文头部中的窗口字段，这样就能够起到窗口大小告诉的作用。

发送方的窗口等价于接管方的窗口吗？如果不思考拥塞管制，发送方的窗口大小「约等于」接管方的窗口大小，因为窗口告诉报文在网络传输是存在时延的，所以是约等于的关系。

从上图中能够看到，窗口字段只有 2 个字节，因而它最多能表白 65535 字节大小的窗口，也就是 64KB 大小。

这个窗口大小最大值，在当今高速网络下，很显著是不够用的。所以后续有了裁减窗口的办法：在 TCP 选项字段定义了窗口扩充因子，用于扩充 TCP 通告窗口，其值大小是 2^14，这样就使 TCP 的窗口大小从 16 位扩充为 30 位（2^16 * 2^ 14 = 2^30），所以此时窗口的最大值能够达到 1GB。

Linux 中关上这一性能，须要把 tcp_window_scaling 配置设为 1（默认关上）：

要应用窗口扩充选项，通信单方必须在各自的 SYN 报文中发送这个选项：

被动建设连贯的一方在 SYN 报文中发送这个选项；
而被动建设连贯的一方只有在收到带窗口扩充选项的 SYN 报文之后能力发送这个选项。

这样看来，只有过程能及时地调用 read 函数读取数据，并且接收缓冲区配置得足够大，那么接管窗口就能够有限地放大，发送方也就有限地晋升发送速度。

这是不可能的，因为网络的传输能力是无限的，当发送方根据发送窗口，发送超过网络解决能力的报文时，路由器会间接抛弃这些报文。因而，缓冲区的内存并不是越大越好。

在后面咱们晓得了 TCP 的传输速度，受制于发送窗口与接管窗口，以及网络设备传输能力。其中，窗口大小由内核缓冲区大小决定。如果缓冲区与网络传输能力匹配，那么缓冲区的利用率就达到了最大化。

问题来了，如何计算网络的传输能力呢？

置信大家都晓得网络是有「带宽」限度的，带宽形容的是网络传输能力，它与内核缓冲区的计量单位不同:

带宽是单位工夫内的流量，表白是「速度」，比方常见的带宽 100 MB/s；
缓冲区单位是字节，当网络速度乘以工夫能力失去字节数；

这里须要说一个概念，就是带宽时延积，它决定网络中航行报文的大小，它的计算形式：

比方最大带宽是 100 MB/s，网络时延（RTT）是 10ms 时，意味着客户端到服务端的网络一共能够寄存 100MB/s * 0.01s = 1MB 的字节。

这个 1MB 是带宽和时延的乘积，所以它就叫「带宽时延积」（缩写为 BDP，Bandwidth Delay Product）。同时，这 1MB 也示意「航行中」的 TCP 报文大小，它们就在网络线路、路由器等网络设备上。如果航行报文超过了 1 MB，就会导致网络过载，容易丢包。

因为发送缓冲区大小决定了发送窗口的下限，而发送窗口又决定了「已发送未确认」的航行报文的下限。因而，发送缓冲区不能超过「带宽时延积」。

发送缓冲区与带宽时延积的关系：

如果发送缓冲区「超过」带宽时延积，超出的局部就没方法无效的网络传输，同时导致网络过载，容易丢包；
如果发送缓冲区「小于」带宽时延积，就不能很好的施展出网络的传输效率。

所以，发送缓冲区的大小最好是往带宽时延积凑近。

在 Linux 中发送缓冲区和接管缓冲都是能够用参数调节的。设置完后，Linux 会依据你设置的缓冲区进行动静调节。

调节发送缓冲区范畴

先来看看发送缓冲区，它的范畴通过 tcp_wmem 参数配置；

下面三个数字单位都是字节，它们别离示意：

第一个数值是动静范畴的最小值，4096 byte = 4K；
第二个数值是初始默认值，87380 byte ≈ 86K；
第三个数值是动静范畴的最大值，4194304 byte = 4096K（4M）；

发送缓冲区是自行调节的，当发送方发送的数据被确认后，并且没有新的数据要发送，就会把发送缓冲区的内存开释掉。

调节接收缓冲区范畴

而接收缓冲区的调整就比较复杂一些，先来看看设置接收缓冲区范畴的 tcp_rmem 参数：

下面三个数字单位都是字节，它们别离示意：

第一个数值是动静范畴的最小值，示意即便在内存压力下也能够保障的最小接收缓冲区大小，4096 byte = 4K；
第二个数值是初始默认值，87380 byte ≈ 86K；
第三个数值是动静范畴的最大值，6291456 byte = 6144K（6M）；

接收缓冲区能够依据零碎闲暇内存的大小来调节接管窗口：

如果零碎的闲暇内存很多，就能够主动把缓冲区增大一些，这样传给对方的接管窗口也会变大，因此晋升发送方发送的传输数据数量；
反之，如果零碎的内存很缓和，就会缩小缓冲区，这尽管会升高传输效率，能够保障更多的并发连贯失常工作；

发送缓冲区的调节性能是主动开启的，而接收缓冲区则须要配置 tcp_moderate_rcvbuf 为 1 来开启调节性能：

调节 TCP 内存范畴

接收缓冲区调节时，怎么晓得以后内存是否缓和或充沛呢？这是通过 tcp_mem 配置实现的：

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

当 TCP 内存小于第 1 个值时，不须要进行主动调节；
在第 1 和第 2 个值之间时，内核开始调节接收缓冲区的大小；
大于第 3 个值时，内核不再为 TCP 调配新内存，此时新连贯是无奈建设的；

个别状况下这些值是在系统启动时依据零碎内存数量计算失去的。依据以后 tcp_mem 最大内存页面数是 177120，当内存为 (177120 * 4) / 1024K ≈ 692M 时，零碎将无奈为新的 TCP 连贯分配内存，即 TCP 连贯将被回绝。

依据理论场景调节的策略

在高并发服务器中，为了兼顾网速与大量的并发连贯，咱们该当保障缓冲区的动静调整的最大值达到带宽时延积，而最小值放弃默认的 4K 不变即可。而对于内存缓和的服务而言，调低默认值是进步并发的无效伎俩。

同时，如果这是网络 IO 型服务器，那么，调大 tcp_mem 的下限能够让 TCP 连贯应用更多的零碎内存，这有利于晋升并发能力。须要留神的是，tcp_wmem 和 tcp_rmem 的单位是字节，而 tcp_mem 的单位是页面大小。而且，千万不要在 socket 上间接设置 SO_SNDBUF 或者 SO_RCVBUF，这样会敞开缓冲区的动静调整性能。

本节针对 TCP 优化数据传输的形式，做了一些介绍。

TCP 可靠性是通过 ACK 确认报文实现的，又依赖滑动窗口晋升了发送速度也兼顾了接管方的解决能力。

可是，默认的滑动窗口最大值只有 64 KB，不满足当今的高速网络的要求，要想晋升发送速度必须晋升滑动窗口的下限，在 Linux 下是通过设置 tcp_window_scaling 为 1 做到的，此时最大值可高达 1GB。

滑动窗口定义了网络中航行报文的最大字节数，当它超过带宽时延积时，网络过载，就会产生丢包。而当它小于带宽时延积时，就无奈充分利用网络带宽。因而，滑动窗口的设置，必须参考带宽时延积。

内核缓冲区决定了滑动窗口的下限，缓冲区可分为：发送缓冲区 tcp_wmem 和接收缓冲区 tcp_rmem。

Linux 会对缓冲区动静调节，咱们应该把缓冲区的下限设置为带宽时延积。发送缓冲区的调节性能是主动关上的，而接收缓冲区须要把 tcp_moderate_rcvbuf 设置为 1 来开启。其中，调节的根据是 TCP 内存范畴 tcp_mem。

但须要留神的是，如果程序中的 socket 设置 SO_SNDBUF 和 SO_RCVBUF，则会敞开缓冲区的动静整性能，所以不倡议在程序设置它俩，而是交给内核主动调整比拟好。

无效配置这些参数后，既可能最大水平地放弃并发性，也能让资源富余时连贯传输速度达到最大值。

前言

注释

01 TCP 三次握手的性能晋升

客户端优化

服务端优化

如何绕过三次握手？

小结

02 TCP 四次挥手的性能晋升

被动方的优化

被动方的优化

小结

03 TCP 传输数据的性能晋升

滑动窗口是如何影响传输速度的？

如何确定最大传输速度？

怎么调整缓冲区大小？

小结

站内搜索