什么是 TCP 半开连接和 TCP 半闭连接

Question

我想了解 TCP 半开放连接和 TCP 半封闭连接之间有什么区别，谁能说出它们到底是什么？

Answer 1

这篇文章扩展了半封闭连接。对于半开放连接，请参阅 KContreau 的正确描述。

什么是半封闭连接？或者：这不是错误——这是一个功能！

每个 TCP 连接都由两个彼此独立关闭的半连接组成。因此，如果一端发送 FIN，则另一端可以自由地仅 ACK 该 FIN（而不是 FIN+ACK-ing），这会向 FIN 发送端发出信号，表明它仍有数据要发送。所以两端最终都处于一个稳定的数据传输状态，而不是 ESTABLISHED——即 FIN_WAIT_2（对于接收端）和 CLOSE_WAIT（对于发送端）。这样的连接据说是半关闭的，而 TCP 实际上就是为了支持这些场景而设计的，所以半关闭连接是 TCP 的一个特性。

半封闭连接的历史

虽然 RFC 793 只描述了原始机制，甚至没有提到术语“半封闭”，但 RFC 1122 在 4.2.2.13 节中详细说明了这个问题。您可能想知道到底谁需要该功能。TCP 的设计者还为 Unix 系统实现了 TCP/IP，并且像每个 Unix 用户一样，喜欢 I/O 重定向。根据 W. Stevens（TCP/IP 说明，第 18.5 节）的说法，I/O 重定向 TCP 流的愿望是引入该功能的动机。它允许 FIN ack 扮演 EOF 的角色或被翻译为 EOF。所以它基本上是一个功能，允许您在应用层随意创建即兴请求/响应式交互，其中 FIN 表示“请求结束”。

Answer 2

其他人在描述半开和半闭连接实际上是什么方面做得相当不错，但是半开连接的想法也经常在他们成为问题的背景下被搜索。

关于术语“半开”或“半闭”应该代表什么，互联网上存在争论，但就我而言，术语只是语义。有人说“半开”连接是一个“问题”，而“半闭”是一种设计功能，它允许您在文件下载以半关闭状态完成之前通过关闭发送流来关闭发送流（如其他用户所述）。

但是，关于另一个......“问题”：打开 TCP 连接需要 3 次握手，关闭它需要 4 次握手。

TCP 有一个漏洞，即发送到客户端的最终 FIN 数据包可能会被路由器/网络丢弃，从而导致连接半开，而实际意图是完全关闭连接。这种和类似的方法一直是流行的拒绝服务攻击类型，因为它们不需要大量带宽，但可能会根据服务器实现消耗宝贵的句柄、套接字和线程，但它们也可能发生在现实世界中由于我们劣质的无线运营商，频率越来越高。

操作系统已经尝试通过限制在给定时间操作系统中可以存在的半开/关连接的数量以及引入连接可以保持在一个最大的时间长度来反击半开 DDoS 攻击。半开/关状态。然而，最后我亲自检查过，Windows 上的时间限制非常高（如果我记得的话，是 2 天）。

TCP keep-alives 的可选性质进一步加剧了这种情况，如果完全实现，它旨在作为协议级（而不是应用程序级）解决方案来检测死/僵尸连接。但是，在设计 TCP 时，带宽比现在更加宝贵，有人担心 TCP 的强制保持活动计时器会过于“健谈”。因此，keep-alives 是可选的，一般不使用，并且不保证根据 RFC1122 由路由器传输。所以......即使你在 TCP 层启用了 keep-alives 以尝试检测/处理场景，你可能会发现当你的流量在世界各地传播时，一些路由器正在丢弃 keep-alive 数据包......创建可能需要测试的另一种罕见场景。

半开连接对编写基于 TCP 的服务器的编码人员构成了一些工程挑战，特别是因为它们可能会在高负载期间无意中随机出现......并且通常在生产服务器上......并且可以在 Alpha/Beta 测试阶段很难注意到。根据我的经验，我发现在每天处理 250 万个连接的服务器上，它们可能发生在每 40,000 个连接中的 1 个，但这些数字会因您的流量状况以及您的服务器和客户端之间的互联网每个分支的流量状况而有所不同.

作为一名工程师，很难追踪不经常发生的问题，并且只在实时部署的服务器上发生，因此在编写 TCP 服务器代码时尝试模拟这种罕见的连接状态很重要，以分析您的服务器在以下情况下会如何反应面对这种情况。例如，如果您的 TCP 服务器使用静态数量的工作线程，例如，当您部署到生产时，您可能会发现所有这些工作线程都被僵尸连接消耗掉了。如果连接需要大量工作内存，则最终结果可能类似于内存泄漏。等等等等

如果没有 100% 可行的保活解决方案，TCP 会将其留给用户层来确定如何处理半开/关连接，因此您的代码必须有一个计划/机制来检测、超时和清理-当这种情况发生时增加资源......也就是说......假设这是你发明的协议，而不是程序员通常使用的许多（坏）开放标准之一。当然，我指的是诸如 HTTP 之类的协议，它们专门通过 TCP 运行。在这位程序员看来，这些协议被高估了。

认识到 TCP 的弱点及其在传输 HTTP/Web 流量方面的不幸普及，聪明的公司已经寻求寻找替代品。例如，Google 试验了一种称为 QUIC 的协议，该协议通过 UDP 传输 HTTP。还有一个名为 TSCP 的开放协议。然而，这些协议都没有被广泛采用。

作为一项规则，我构建了所有自己的服务器，专门使用我自己的基于 UDP 的协议进行通信。然而，UDP 比你想象的更棘手，我觉得我一直在调整它以使其更快、更智能、更低延迟、更低拥塞……但至少我不再需要处理半开连接； )

Answer 3

当 TCP 建立连接时，它被认为是有保证的，因为发生了握手：

1. 发起计算机发送连接请求，发送一个 SYN
2. 响应计算机同意请求，回复 SYN-ACK
3. 发起计算机发送确认，以 ACK 回复

此时，连接建立，数据开始流动。相比之下，UDP 数据包是没有保证的，只是希望它能到达那里。

http://en.wikipedia.org/wiki/Transmission_Control_Protocol#Connection_establishment

正式地，根据 RFC 的规定，半开 TCP 连接是指已建立连接的一侧崩溃，并且没有发送连接正在结束的通知。这不是今天的常见用法。

非正式地，如果可以指一个胚胎连接，它是一个正在建立过程中的连接。

http://en.wikipedia.org/wiki/Embryonic_connection

半封闭与非官方定义相反。它是中间某处的状态，计算机正在断开已建立的连接。