Windows操作系统error10048端口释放问题TIME_WAIT状态的TCP连接快速回收时间

本文来自于https://blog.csdn.net/stillfantasy1988/article/details/43196627?tdsourcetag=s_pcqq_aiomsg、http://www.huawei.com/ecommunity/bbs/10221255.html

1.问题

大规模Windows环境下,采用Nginx反向代理服务后,操作系统会产生较多TIME_WAIT的TCP(Transmission Control Protocol)连接,操作系统默认TIME_WAIT的TCP连接回收时间是4分钟,TCP默认动态端口范围为开始端口49152,结束端口65535。这样会使回收TCP过慢导致系统吞吐量下降,甚至出现502访问失败问题。如何修改操作系统内核参数来缩短TIME_WAIT状态TCP连接回收时间和添加TCP动态端口范围,保证在大并发场景下操作系统的端口资源可用?

2.解决办法

  1. 以Administrator用户登录Windows操作系统。
  2. 修改TCP回收时间。
    1. 在Windows开始菜单中,单击“运行”。
    2. 在“运行”对话框中,输入“regedit”后按“Enter”打开注册表编辑器。
    3. 在“注册表编辑器”中打开“HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters”路径。
    4. 在“编辑”菜单中,选择“新建 > DWORD (32-位)值”,输入名称“TcpTimedWaitDelay”。
    5. 右键单击TcpTimedWaitDelay,选择“修改”。
    6. 在“编辑 DWORD(32位)值”对话框的“基数”区域中,选择十进制值为“30”,并“确定”。
    7. 关闭注册表编辑器。
  3. 修改端口范围。
    1. 在Windows开始菜单中,单击“运行”。
    2. 输入“cmd”并按“Enter”打开命令执行窗口。
    3. 执行如下命令修改端口范围。

      netsh int ipv4 set dynamicportrange tcp startport=5000 numberofports=60000
  4. 重启操作系统。

原文地址:https://www.cnblogs.com/wj12312/p/10489879.html

时间: 2024-09-27 15:04:05

Windows操作系统error10048端口释放问题TIME_WAIT状态的TCP连接快速回收时间的相关文章

TCP相关(控制位、3次握手、4次挥手、端口号分类TIME_WAIT状态...)

TCP报文格式 一.6个控制位中 URG和PSH的区别: (1)紧急URG(URGent), 当URG=1时, 表明紧急指针字段有效.它告诉操作系统此报文中有紧急数据,应尽快传输(相当于高优先级数据),而不要按照原来的排队顺序来传送.例如,已经发送了很长的一个程序要在远地的主机上运行,但后来发现了一些问题,需要取消该程序的运行.因为用户从键盘发送中断指令(Control+c),如果不使用紧急数据,那么两个字符将存储在接收TCP的缓存末尾.只有在所有的数据被处理完毕后,这两个字符才会被交付到接收方

好一个Time_Wait状态(TCP/IP)

首先简单介绍一下Time_Wait是个什么鬼: 在TCP/IP协议中,我们都知道有三次握手四次挥手的过程,先来一个简单的图: 各个状态和基本的过程想必了解过TCP/IP协议的人都清楚,本次介绍的主题只有Time_Wait状态.(Ps:本文统一将主动断开连接方称A,被动断开连接方称B) 1,Time_Wait状态是什么结点产生的? 在A发送Fin被B接收到,B会发送ACK紧接着发送Fin以后,A接收到另一方发过来的Fin信号,就会将自身的状态设置为Time_Wait状态,并返回一个ACK. 2,为

性能测试机中存在大量的TIME_WAIT状态的连接,影响并发压力的发起

现在一个测试项目,发现性能测试机中有很多TIME_WAIT状态的TCP连接,在网上查了一下,这种状态也叫TCP半连接状态. 测试环境:3台winserver测试机,其中包括一台压力控制机,即controller机器 服务器环境:websphere+DB2 问题表现:controller机器使用其中任何一台windows测试机并发5个vuser或者更多,都会在8分钟或者10分钟左右出现大量的失败交易 分析:通过在cmd中查看netstat -ano > d:/port.txt(把netstat打印

TCP/IP协议--TIME_WAIT状态存在的原因

1. 实际问题         初步查看发现,无法对外新建TCP连接时,线上服务器存在大量处于TIME_WAIT状态的TCP连接(最多的一次为单机10w+,其中引起报警的那个模块产生的TIME_WAIT约2w),导致其无法跟下游模块建立新TCP连接. TIME_WAIT涉及到TCP释放连接过程中的状态迁移,也涉及到具体的socket api对TCP状态的影响,下面开始逐步介绍这些概念. 2. TCP状态迁移        面向连接的TCP协议要求每次peer间通信前建立一条TCP连接,该连接可抽

TCP协议(二)——TIME_WAIT状态

当TCP主动关闭套接字时,采用四步握手机制来彻底关闭连接.如图: 客户端主动关闭连接,发送FIN段到服务端.TCP状态由ESTABLISHED(连接状态)转为FIN_WAIT1(表示,发送的FIN需要确认). 服务端接受FIN后,服务端的TCP状态由ESTABLISHED转为CLOSE_WAIT,并且回送ACK. 客户端接受确认ACK后,TCP状态由FIN_WAIT1转化为FIN_WAIT2(表示已经确认FIN,等待来自服务端的FIN请求). 服务端发送FIN,TCP状态CLOSE_WAIT转为

TCP的TIME_WAIT快速回收与重用

2MSL TIME_WAIT状态存在的理由:TIME_WAIT状态的存在有两个理由:(1)让4次握手关闭流程更加可靠:4次握手的最后一个ACK是是由主动关闭方发送出去的,若这个ACK丢失,被动关闭方会再次发一个FIN过来.若主动关闭方能够保持一个2MSL的TIME_WAIT状态,则有更大的机会让丢失的ACK被再次发送出去.(2)防止lost duplicate对后续新建正常链接的传输造成破坏.lost duplicate在实际的网络中非常常见,经常是由于路由器产生故障,路径无法收敛,导致一个pa

TCP四次挥手时TIME_WAIT状态以及端口号的分类

TIME_WAIT(时间等待计时器)状态是什么? 简单来说,TIME_WAIT状态是四次挥手中服务器向客户端发送FIN终止连接后进入的状态. 四次挥手的过程: 可以看到TIME_WAIT状态存在于客户端收到服务器FIN并返回ACK时的状态. 当处于TIME_WAIT状态时,我们无法创建新的连接,因为端口被占用. 2. 为什么会有TIME_WAIT状态? 原因如下两点: <1> 可靠的终止TCP连接 若处于TIME_WAIT的客户端发送给服务器确认报文段丢失的话,服务器将在此重新发送FIN报文

TIME_WAIT状态原理(转)

---------------------------- 转自:http://elf8848.iteye.com/blog/1739571 通信双方建立TCP连接后,主动关闭连接的一方就会进入TIME_WAIT状态. 客户端主动关闭连接时,会发送最后一个ack后,然后会进入TIME_WAIT状态,再停留2个MSL时间(后有MSL的解释),进入CLOSED状态. 下图是以客户端主动关闭连接为例,说明这一过程的. TIME_WAIT状态存在的理由 --------------------------

TCP/IP TIME_WAIT状态原理

TIME_WAIT状态原理 ---------------------------- 通信双方建立TCP连接后,主动关闭连接的一方就会进入TIME_WAIT状态. 客户端主动关闭连接时,会发送最后一个ack后,然后会进入TIME_WAIT状态,再停留2个MSL时间(后有MSL的解释),进入CLOSED状态. 下图是以客户端主动关闭连接为例,说明这一过程的. TIME_WAIT状态存在的理由 ---------------------------- TCP/IP协议就是这样设计的,是不可避免的.主