IOCP如何既能发送RST复位连接避免TIME_WAIT状态，又能重用socket？

最新推荐文章于 2022-05-14 00:05:18 发布
原创 最新推荐文章于 2022-05-14 00:05:18 发布 · 2k 阅读 · 0 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#socket

博客内容待续，目前已知标签包含socket，推测后续将围绕socket展开信息技术相关内容的介绍，如socket编程、应用等。
待续
TCP TIME_WAIT状态解析及问题解决
我心依旧，明月长歌
06-03 1万+
TCP四次挥手过程 相关参数优化调整 总结 TCP四次挥手过程 TCP在建立连接时需要握手，同理，在关闭连接的时候也需要握手。 具体如下所示： 由于TCP连接是双向的，所以在关闭连接的时候，两个方向各自都需要关闭。先发FIN包的一方执行的是主动关闭，后发送FIN包的一方执行的是被动关闭。主动关闭的一方会进入TIME_WAIT状态，并且在此状态停留2MSL时长。 对于M...
IOCP模式，socket服务器，客户连再多也不用愁
06-27
IOCP（I/O Completion Port，I/O完成端口）是性能最好的一种I/O模型。它是应用程序使用线程池处理异步I/O请求的一种机制。在处理多个并发的异步I/O请求时，以往的模型都是在接收请求是创建一个线程来应答请求。这样就有很多的线程并行地运行在系统中。而这些线程都是可运行的，Windows内核花费大量的时间在进行线程的上下文切换，并没有多少时间花在线程运行上。再加上创建新线程的开销比较大，所以造成了效率的低下......
解决 TIME_WAIT 问题
weixin_34228662的博客
11-25 289
这段时间在用完成端口编写数据库的三层访问方式，发现客户端在用线程方式进行压力测试的时候，经常会连接不到服务器，把服务器程序停一下重新开始就好了。用netstat 查看，发现大量的Time_Wait,于是找资料，发现这篇说的不错，收藏： 调整 MaxUserPort 和 TcpTimedWaitDelay 设置 注意，MaxUserPort 和 TcpTimedWaitDelay 设置仅适用于这...
计算机网络之TCP中TIME_WAIT状态意义详解
weixin_52690231的博客
05-14 5846
计算机网络之TCP中TIME_WAIT状态意义详解
服务器大量TIME_WAIT的原因及解决办法
小螺号的博客
05-31 6013
目录发送ACK和RST的场景TIME_WAIT状态产生大量TIME_WAIT原因解决办法 发送ACK和RST的场景 在有以下几种情景，TCP会把ack包发出去： 收到1个包，启动200ms定时器，等到200ms的定时器到点了（第二个包没来），于是对这个包的确认ack被发送。这叫做“延迟发送”； 收到1个包，启动200ms定时器，200ms定时器还没到，第二个数据包又来了（两个数据包一个ack）； 收到1个包，启动200ms定时器，还没超时，正好要给对方发点内容。于是对这个包的确认ack就跟着捎过去。这叫做
ioctlsocket.rar_IOCP_delphi iocp_ioctlsocket_socket ioctlsocket_
07-14
一个delphi中用多种模式socket的示例，包括： 1、阻塞单线程 2、阻塞多线程 3、非阻塞模式 4、Select模式 5、WSAAsynSelect模式 6、IOCP模式 7、UPD通讯 非常经典！
IOCP.rar_IOCP_iocp客户端_发送结构体_端口 客户端_行发送
09-19
《IOCP技术详解：构建高效客户端与服务器通信》 IOCP，全称为“完成端口”（I/O Completion Port），是Windows操作系统中一种高效的异步I/O模型，它被广泛应用于高并发网络服务中，例如游戏服务器、金融交易系统等...
IOCP.rar_IOCP_IOCP中socket_completion_完成端口_异步高效 socket
09-24
IOCP全称I/O Completion Port，中文译为I/O完成端口。IOCP是一个异步I/O的API，它可以高效地将I/O事件通知给应用程序。...此资料是对IOCP模型的深入讲解及总结，让你能更清楚的了解IOCP模型工作的本质。
精选资源
IOCP.rar_C++ iocp_DEMO_Gh0st_IOCP socket
09-20
标题中的"IOCP.rar_C++ iocp_DEMO_Gh0st_IOCP socket"表明这是一个关于C++实现的IO Completion Ports (IOCP)技术的示例项目，可能包含了一个名为"Gh0st"的特定IOCP服务器或客户端的源代码。IOCP是Windows操作系统中...
IOCP.rar_IOCP_IOCP socket_iocp client_poors66_完成端口
09-23
在实际开发中，数据转发可能涉及TCP连接的建立、数据包的接收与发送、错误处理等环节，而通过IOCP，这些操作可以被高效地并发处理。 总结来说，完成端口（IOCP）是一种强大的工具，它使得Windows上的网络服务器能够...
在TIME_WAIT状态下收到RST报文会发生什么？
居老师的博客
04-26 624
会不会断开，关键看 net.ipv4.tcp_rfc1337 这个内核参数（默认情况是为 0）： 如果这个参数设置为 0， 收到 RST 报文会提前结束 TIME_WAIT 状态，释放连接。 如果这个参数设置为 1， 就会丢掉 RST 报文。 源码处理如下： enum tcp_tw_status tcp_timewait_state_process(struct inet_timewait_sock *tw, struct sk_buff *skb, const struct tcphd
Windows下IOCP踩过的一些坑
slowlytalk
05-04 6369
前段时间在搞win下面的IOCP服务器时发现了一些很多问题，有一些问题也是折磨了好久才慢慢的理解清楚，今天就将这些踩过的坑记录下来，避免以后遇到同样的问题。 IOCP目前是性能最好的模型，主要缺点是只能在windows平台下使用，一个IOCP对象，在操作系统中可以关联多个socket和（或）文件控制端。它主要是在内部封装了LIFO原则的请求队列、FIFO原则的完成包队列、多线程处理。是异步执行的，...
iocp 取消已投递的io_boost.asio系列-io_service 简单了解
weixin_39722965的博客
12-01 203
boost.asio系列——io_serviceIO模型io_service对象是asio框架中的调度器，所有异步io事件都是通过它来分发处理的（io对象的构造函数中都需要传入一个io_service对象）。 asio::io_service io_service; asio::ip::tcp::socket socket(io_service);在asio框架中，同步的io主要流程如...
iocp 取消已投递的io_细说IO复用
weixin_39744384的博客
11-02 269
I/O动作如何执行 首先明确一点， 进程无法直接操作I/O设备，其必须通过系统调用请求内核来协助完成I/O操作。内核会为每个I/O设备维护一个bufferI/O执行流程 对于输入而言，等待数据输入至buffer是需要时间的，而从buffer复制数据到进程也是需要时间的，根据等待的模式不同，I/O动作可分为5中模式。（1）blocking I/O 阻塞IO（2）no...
TCP/IP的time_wait状态详解
热门推荐
tianmo2010的专栏
04-07 1万+
Socket中的TIME_WAIT状态 在高并发短连接的server端，当server处理完client的请求后立刻closesocket此时会出现time_wait状态然后如果client再并发2000个连接，此时部分连接就连接不上了,用linger强制关闭可以解决此问题，但是linger会导致数据丢失，linger值为0时是强制关闭,无论并发多少多能正常连接上,如果非0会发生部分
“TCP 连接关闭后，客户端端口会进入 TIME_WAIT 状态（默认保留 60 秒），占用端口资源。”你这句话中TIME_WAIT 保留60秒，windows也一样吗？为何windows里面长时间处于TIME_WAIT ？
最新发布
03-18
<think>嗯，用户之前问了关于HTTP请求没有分配到临时端口的问题，我详细解释了TIME_WAIT状态以及解决方案。现在用户接着问关于TIME_WAIT状态在Windows下是否默认保留60秒，以及为什么Windows中TIME_WAIT会长时间存在。我需要先确认不同操作系统的默认时间，尤其是Windows的情况。 首先，我记得Linux系统里，TIME_WAIT的持续时间是由tcp_fin_timeout参数控制的，默认是60秒。但Windows的默认设置可能不同。需要查证Windows的默认值。比如，在Windows中，MSDN文档或官方资料是否提到默认时间？ 然后用户问为什么Windows里TIME_WAIT会长时间存在。可能的原因包括默认超时时间更长，或者有其他机制影响。比如，Windows默认的TIME_WAIT时间是否是240秒？如果是的话，那确实比Linux长很多，导致端口占用更久，容易耗尽。 另外，需要解释为什么不同系统有不同的设计考虑。比如，确保数据包完全消失，避免旧连接干扰，但不同的实现可能有不同的策略。Windows可能有更多的保守设置，或者网络栈设计差异。 还要考虑用户可能的实际场景。比如，用户可能在Windows服务器上遇到高并发问题，导致端口不足，想知道如何调整。因此，除了解释原因，还需要提供Windows下的调整方法，比如注册表修改，或者启用端口复用。 需要检查是否有错误，比如混淆了TIME_WAIT和FIN_WAIT的状态。TIME_WAIT是在主动关闭连接的一方出现的，而FIN_WAIT是另一种状态。确保回答中术语正确。 最后，总结问题，明确Windows的默认时间，解释差异原因，并提供解决方案。可能需要分点回答，结构清晰，让用户容易理解。</think>--- ### 一、TIME_WAIT 状态的作用与默认时间 #### 1. **TIME_WAIT 的设计目的** - **确保数据包彻底消失**：TCP 关闭连接时，主动关闭方（客户端或服务端）会进入 `TIME_WAIT` 状态，等待 **2 倍 MSL（Maximum Segment Lifetime）** 时间。 - **MSL 定义**：数据包在网络中的最大存活时间（默认通常为 30 秒或 60 秒，因系统而异）。 - **2&times;MSL 逻辑**：确保网络中残留的旧连接数据包彻底失效，避免与新连接冲突。 #### 2. **Windows 与 Linux 的默认差异** - **Linux**： - 默认 `MSL = 60 秒`，因此 `TIME_WAIT` 状态持续 **60 秒 &times; 2 = 120 秒**。 - 但实际通过 `tcp_fin_timeout` 参数直接控制 `TIME_WAIT` 超时（默认 **60 秒**）。 ```bash sysctl net.ipv4.tcp_fin_timeout # 查看当前值 ``` - **Windows**： - **默认 MSL = 120 秒**，因此 `TIME_WAIT` 状态持续 **120 秒 &times; 2 = 240 秒**（即 **4 分钟**）。 - 这是 Windows 网络栈的保守设计，确保更高可靠性，但也导致端口占用时间显著长于 Linux。 --- ### 二、Windows 中 TIME_WAIT 长时间存在的原因 #### 1. **默认 MSL 设置更长** - Windows 的默认 MSL 为 **120 秒**（定义在 TCP/IP 协议栈中），导致 `TIME_WAIT` 总时间达到 **240 秒**。 - **对比**：Linux 默认 MSL 为 **60 秒**（`TIME_WAIT` 总时间 120 秒），而通过 `tcp_fin_timeout` 可进一步缩短。 #### 2. **保守的网络栈设计** - Windows 优先保障数据完整性，避免新旧连接冲突（例如：延迟的旧数据包被新连接误接收）。 - 在复杂网络环境（如高延迟、高丢包）中，更长的 `TIME_WAIT` 能进一步降低风险。 #### 3. **配置限制** - Windows 不直接提供调整 MSL 的公开参数，仅能通过修改注册表间接优化 `TIME_WAIT` 行为（例如启用端口复用）。 - 用户需依赖系统级策略，而非灵活调整超时时间。 --- ### 三、Windows 中优化 TIME_WAIT 的解决方案 #### 1. **启用端口复用（`SO_REUSEADDR`）** - 允许新连接复用处于 `TIME_WAIT` 状态的端口： - 修改注册表项： ```reg HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters ``` - 添加 DWORD 值 `TcpTimedWaitDelay`，设置为十进制 **30-60**（单位：秒，表示缩短 `TIME_WAIT` 时间）。 - 添加 DWORD 值 `MaxUserPort`，设置为 **65534**（扩大临时端口范围）。 #### 2. **调整 TCP 连接关闭行为** - 通过注册表启用快速释放端口（需谨慎）： ```reg HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters ``` - 添加 DWORD 值 `EnableFastReuse`，设置为 **1**（允许快速重用 `TIME_WAIT` 端口）。 #### 3. **优化应用程序设计** - 使用 **HTTP 连接池**（如 .NET 的 `ServicePointManager`）复用 TCP 连接，减少短连接数量。 - 异步非阻塞 IO 模型（如 `IOCP`）替代同步阻塞调用，降低端口占用频率。 --- ### 四、验证 Windows 的 TIME_WAIT 状态 1. **查看当前 TIME_WAIT 连接** ```powershell netstat -ano | Select-String "TIME_WAIT" ``` 2. **统计 TIME_WAIT 数量** ```powershell (netstat -ano | Select-String "TIME_WAIT").Count ``` 3. **监控端口占用趋势** - 使用性能计数器（Performance Monitor）跟踪 `TCPv4` 的 `Connections Time Wait`。 --- ### 五、关键结论 - **Windows 默认 TIME_WAIT 时间更长**：240 秒（4 分钟），远高于 Linux 的 60-120 秒。 - **原因**：保守设计保障可靠性，但牺牲了端口资源释放速度。 - **优化方向**：通过注册表调整端口复用策略，并优化应用层连接管理。 --- **示例场景**： 某 Windows 服务器处理 10,000 次/秒的 HTTP 短连接请求，默认配置下： - **TIME_WAIT 端口占用**：`10,000 &times; 240 秒 = 2,400,000 个端口` - **临时端口范围**：默认仅 16,384 个（49152-65535），会立即耗尽。 - **优化后**：扩大端口范围至 64k，并启用 `TcpTimedWaitDelay=30`，可显著缓解问题。
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
表情包 代码片
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值