tcp握手PHP技巧_TCP三次握手事理你到底知道若干

最近碰到一个问题，Client 端连接做事器总是抛非常。
在反复定位剖析、并查阅各种资料搞懂后，我创造并没有文章能把这两个行列步队以及怎么不雅观察他们的指标说清楚。

因此写下这篇文章，希望借此能把这个问题说清楚。
欢迎大家一起互换磋商。

问题描述

场景：Java 的 Client 和 Server，利用 Socket 通信。
Server 利用 NIO。

问题：

剖析问题

正常 TCP 建连接三次握手过程，分为如下三个步骤：

从问题的描述来看，有点像 TCP 建连接的时候全连接行列步队（Accept 行列步队，后面详细讲）满了。

尤其是症状 2、4 为了证明是这个缘故原由，立时通过 netstat -s | egrep \"大众listen\"大众 去看行列步队的溢出统计数据：

反复看了几次之后创造这个 overflowed 一贯在增加，可以明确的是 Server 上全连接行列步队一定溢出了。

接着查看溢出后，OS 怎么处理：

tcp_abort_on_overflow 为 0 表示如果三次握手第三步的时候全连接行列步队满了那么 Server 扔掉 Client 发过来的 Ack（在 Server 端认为连接还没建立起来）。

为了证明客户端运用代码的非常跟全连接行列步队满有关系，我先把 tcp_abort_on_overflow 修正成 1。

1 表示第三步的时候如果全连接行列步队满了，Server 发送一个 Reset 包给 Client，表示废掉这个握手过程和这个连接（本来在 Server 端这个连接就还没建立起来）。

接着测试，这时在客户端非常中可以看到很多 connection reset by peer 的缺点，到此证明客户端缺点是这个缘故原由导致的（逻辑严谨、快速证明问题的关键点所在）。

于是开拓同学翻看 Java 源代码创造 Socket 默认的 backlog（这个值掌握全连接行列步队的大小，后面再详述）是 50。

于是改大重新跑，经由 12 个小时以上的压测，这个缺点一次都没涌现了，同时不雅观察到 overflowed 也不再增加了。

到此问题办理，大略来说 TCP 三次握手后有个 Accept 行列步队，进到这个行列步队才能从 Listen 变成 Accept，默认 backlog 值是 50，很随意马虎就满了。

满了之后握手第三步的时候 Server 就忽略了 Client 发过来的 Ack 包（隔一段韶光 Server 重发握手第二步的 Syn + Ack 包给 Client），如果这个连接一贯排不上队就非常了。

但是不能只是知足问题的办理，而是要去复盘办理过程，中间涉及到了哪些知识点是我所缺失落或者理解不到位的。

这个问题除了上面的非常信息表现出来之外，还有没有更明确地指征来查看和确认这个问题。

深入理解 TCP 握手过程中建连接的流程和行列步队

如上图所示，这里有两个行列步队：Syns Queue(半连接行列步队）；Accept Queue（全连接行列步队）。

三次握手中，在第一步 Server 收到 Client 的 Syn 后，把这个连接信息放到半连接行列步队中，同时回答 Syn + Ack 给 Client（第二步）：

第三步的时候 Server 收到 Client 的 Ack，如果这时全连接行列步队没满，那么从半连接行列步队拿出这个连接的信息放入到全连接行列步队中，否则按 tcp_abort_on_overflow 指示的实行。

这时如果全连接行列步队满了并且 tcp_abort_on_overflow 是 0 的话，Server 过一段韶光再次发送 Syn + Ack 给 Client（也便是重新走握手的第二步），如果 Client 超时等待比较短，Client 就很随意马虎非常了。

在我们的 OS 中 Retry 第二步的默认次数是 2（Centos 默认是 5 次）：

如果 TCP 连接行列步队溢出，有哪些指标可以看呢？

上述办理过程有点绕，听起来懵，那么下次再涌现类似问题有什么更快更明确的手段来确认这个问题呢？（通过详细的、感性的东西来强化我们对知识点的理解和接管。
）

netstat -s

比如上面看到的 667399 times ，表示全连接行列步队溢出的次数，隔几秒钟实行下，如果这个数字一贯在增加的话肯定全连接行列步队偶尔满了。

ss 命令

上面看到的第二列 Send-Q 值是 50，表示第三列的 Listen 端口上的全连接行列步队最大为 50，第一列 Recv-Q 为全连接行列步队当前利用了多少。

全连接行列步队的大小取决于：min(backlog，somaxconn)。
backlog 是在 Socket 创建的时候传入的，Somaxconn 是一个 OS 级别的系统参数。

这个时候可以跟我们的代码建立联系了，比如 Java 创建 ServerSocket 的时候会让你传入 backlog 的值：

半连接行列步队的大小取决于：max(64，/proc/sys/net/ipv4/tcp_max_syn_backlog)，不同版本的 OS 会有些差异。

我们写代码的时候从来没有想过这个 backlog 或者说大多时候就没给它值（那么默认便是 50），直接忽略了它。

首先这是一个知识点的盲点；其次大概哪天你在哪篇文章中看到了这个参数，当时有点印象，但是过一阵子就忘了，这是知识之间没有建立连接，不是体系化的。

但是如果你跟我一样首先经历了这个问题的痛楚，然后在压力和痛楚的驱动下自己去找为什么。

同时能够把为什么从代码层推理理解到 OS 层，那么这个知识点你才算是比较好地节制了，也会成为你的知识体系在 TCP 或者性能方面发展自我成长的一个有力抓手。

netstat 命令

netstat 跟 ss 命令一样也能看到 Send-Q、Recv-Q 这些状态信息，不过如果这个连接不是 Listen 状态的话，Recv-Q 便是指收到的数据还在缓存中，还没被进程读取，这个值便是还没被进程读取的 bytes。

而 Send 则是发送行列步队中没有被远程主机确认的 bytes 数，如下图：

netstat -tn 看到的 Recv-Q 跟全连接半连接没有关系，这里特意拿出来说一下是由于随意马虎跟 ss -lnt 的 Recv-Q 搞稠浊，顺便建立知识体系，巩固干系知识点 。

比如如下 netstat -t 看到的 Recv-Q 有大量数据堆积，那么一样平常是 CPU 处理不过来导致的：

上面是通过一些详细的工具、指标来认识全连接行列步队（工程效率的手段）。

实践验证一下上面的理解

把 Java 中 backlog 改成 10（越小越随意马虎溢出），连续跑压力，这个时候 Client 又开始报非常了，然后在 Server 上通过 ss 命令不雅观察到：

按照前面的理解，这个时候我们能看到 3306 这个端口上的做事全连接行列步队最大是 10。

但是现在有 11 个在行列步队中和等待进行列步队的，肯定有一个连接进不去行列步队要 overflow 掉，同时也确实能看到 overflow 的值在不断地增大。

Tomcat 和 Nginx 中的 Accept 行列步队参数

Tomcat 默认短连接，backlog（Tomcat 里面的术语是 Accept count）Ali-tomcat 默认是 200，Apache Tomcat 默认 100。

Nginx 默认是 511，如下图：

由于 Nginx 是多进程模式，以是看到了多个 8085，也便是多个进程都监听同一个端口以只管即便避免高下文切换来提升性能。

总结

全连接行列步队、半连接行列步队溢出这种问题很随意马虎被忽略，但是又很关键，特殊是对付一些短连接运用（比如 Nginx、PHP，当然它们也是支持长连接的）更随意马虎爆发。

一旦溢出，从 CPU、线程状态看起来都比较正常，但是压力上不去，在 Client 看来 RT 也比较高（RT = 网络 + 排队 + 真正做事韶光），但是从 Server 日志记录的真正做事韶光来看 rt 又很短。

JDK、Netty 等一些框架默认 backlog 比较小，可能有些情形下导致性能上不去。

希望通过本文能够帮大家理解 TCP 连接过程中的半连接行列步队和全连接行列步队的观点、事理和浸染，更关键的是有哪些指标可以明确看到这些问题（工程效率帮助强化对理论的理解）。

其余每个详细问题都是最好学习的机会，光看书理解肯定是不足深刻的，请珍惜每个详细问题，碰到后能够把来龙去脉弄清楚，每个问题都是你对详细知识点通关的好机会。

末了提出干系问题给大家思考：

提出这些问题，希望以这个知识点为抓手，让你的知识体系开始自我成长。

参考文章：