ubuntu中解决进程的time_wait和FIN_WAIT2状态

Ubuntu开放端口及其查看端口开放状态 前言 在服务器部署应用的时候,我们经常要查看这个应用是否部署成功,而一般就是通过ip + 端口的方式在浏览器上进行查看默认的一些页面是否出现 当页面没有出现的情况下,不一定是应用没启动成功,可能是因为端口未开放出去,导致了问题 对于端口是否开放的验证问题一般需要做两件事情: 查看端口是否开放 若没有开放,需要开放端口,若开放了即可 若开放了端口,则排除了端口未开放的问题 查看端口 1、利用lsof命令进行查看网络信息 lsof(list open files)是一个列出当前系统打开文件的工具。在li 阅读详情

 

 

TIMEWAIT状态本身和应用层的客户端或者服务器是没有关系的。如果你的程序设计为服务器主动关闭,那么你才有可能需要关注这个TIMEWAIT状态过多的问题。如果你的服务器设计为被动关闭,那么你首先要关注的是CLOSE_WAIT。
1
大量TIMEWAIT出现在业务上

在高并发短连接的TCP服务器上,当服务器处理完请求后立刻按照主动正常关闭连接。。。这个场景下,会出现大量socket处于TIMEWAIT状态。如果客户端的并发量持续很高,此时部分客户端就会显示连接不上。
1
业务上两个方面需要注意:

1、高并发可以让服务器在短时间范围内同时占用大量端口,而端口有个0~65535的范围,并不是很多,刨除系统和其他服务要用的,剩下的就更少了。

2、在这个场景中,短连接表示“业务处理+传输数据的时间 远远小于 TIMEWAIT超时的时间”的连接。这里有个相对长短的概念,比如,取一个web页面,1秒钟的http短连接处理完业务,在关闭连接之后,这个业务用过的端口会停留在TIMEWAIT状态几分钟,而这几分钟,其他HTTP请求来临的时候是无法占用此端口的。单用这个业务计算服务器的利用率会发现,服务器干正经事的时间和端口(资源)被挂着无法被使用的时间的比例是 1:几百,服务器资源严重浪费。(说个题外话,从这个意义出发来考虑服务器性能调优的话,长连接业务的服务就不需要考虑TIMEWAIT状态。同时,假如你对服务器业务场景非常熟悉,你会发现,在实际业务场景中,一般长连接对应的业务的并发量并不会很高)
1
2
3
综合这两个方面,持续的到达一定量的高并发短连接,会使服务器因端口资源不足而拒绝为一部分客户服务。同时,这些端口都是服务器临时分配,无法用SO_REUSEADDR选项解决这个问题:(

解决进程的time_wait状态

短时间后,所有的 TIME_WAIT 全都消失,被回收,端口包括服务,均正常。
Nginx 作为反向代理时,大量的短链接,可能导致 Nginx 上的 TCP 连接处于 time_wait 状态:

1、每一个 time_wait 状态,都会占用一个「本地端口」,上限为 65535(16 bit,2 Byte);
2、当大量的连接处于 time_wait 时,新建立 TCP 连接会出错,address already in use : connect
异常
即,在高并发的场景下,TIME_WAIT 连接存在,属于正常现象。
线上场景中,持续的高并发场景

一部分 TIME_WAIT 连接被回收,但新的 TIME_WAIT 连接产生;
一些极端情况下,会出现大量的 TIME_WAIT 连接。
问题分析
大量的 TIME_WAIT 状态 TCP 连接存在,其本质原因是什么?

1、大量的短连接存在
2、特别是 HTTP 请求中,如果 connection 头部取值被设置为 close 时,基本都由「服务端」发起主动关闭连接
3、而,TCP 四次挥手关闭连接机制中,为了保证 ACK 重发和丢弃延迟数据,设置 time_wait 为 2 倍的 MSL(报文最大存活时间)
TIME_WAIT 状态:

1、TCP 连接中,主动关闭连接的一方出现的状态;(收到 FIN 命令,进入 TIME_WAIT 状态,并返回 ACK 命令)
2、保持 2 个 MSL 时间,即,4 分钟;(MSL 为 2 分钟)

思路 :

1、可以修改内核协议栈代码中关于这个TIMEWAIT的超时时间参数,重编内核,让它缩短超时时间,加快回收;
2、利用SO_LINGER选项的强制关闭方式,发RST而不是FIN,来越过TIMEWAIT状态,直接进入CLOSED状态。
1
2
查看进程连接状态
统计 TCP 连接的状态:

统计:各种连接的数量
#netstat -an|awk ‘/tcp/ {print $6}’|sort|uniq -c
16 CLOSING
130 ESTABLISHED
298 FIN_WAIT1
13 FIN_WAIT2
9 LAST_ACK
7 LISTEN
103 SYN_RECV
5204 TIME_WAIT
#netstat -nat |grep TIME_WAIT

或者
统计:各种连接的数量
$ netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'
ESTABLISHED 1154
TIME_WAIT 1645

查询 TCP 连接状态,其中 -E 表示 grep 或的匹配逻辑
$ netstat -nat | grep -E "TIME_WAIT|Local Address"
Proto Recv-Q Send-Q  Local Address          Foreign Address        (state)
tcp4       0      0  127.0.0.1.1080         127.0.0.1.59061        TIME_WAIT
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
状态:描述

CLOSED:    无连接是活动的或正在进行
LISTEN:    服务器在等待进入呼叫
SYN_RECV:    一个连接请求已经到达,等待确认
SYN_SENT:    应用已经开始,打开一个连接
ESTABLISHED:    正常数据传输状态
FIN_WAIT1:      应用说它已经完成
FIN_WAIT2:      另一边已同意释放
ITMED_WAIT:    等待所有分组死掉
CLOSING:       两边同时尝试关闭
TIME_WAIT:     另一边已初始化一个释放
LAST_ACK:      等待所有分组死掉
1
2
3
4
5
6
7
8
9
10
11
如发现系统存在大量TIME_WAIT状态的连接,通过调整内核参数解决,
vim /etc/sysctl.conf
netstat下time_wait状态的tcp连接:

1.这是一种处于连接完全关闭状态前的状态; 
2.通常要等上4分钟(windows server)的时间才能完全关闭; 
3.这种状态下的tcp连接占用句柄与端口等资源,服务器也要为维护这些连接状态消耗资源; 
4.解决这种time_wait的tcp连接只有让服务器能够快速回收和重用那些TIME_WAIT的资源:修改注册表[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Tcpip\Parameters]添加dword值TcpTimedWaitDelay=30(30秒也为微软建议值;默认为2分钟)和MaxUserPort:65534(可选值5000 - 65534); 
1
2
3
4
启动程序发现端口被占用,netstat查看之后发现如下现象:

发现端口处于TIME_WAIT状态以及FIN_WAIT2状态,无法释放

TIME_WAIT状态的来源 : 可能是之前虚拟机异常关机导致
TIME_WAIT状态 产生原因: 只有首先调用close()发起主动关闭的一方才会进入TIME_WAIT状态,进入TIME_WAIT状态的TCP连接需要经过2MSL才能回到初始状态,
避免办法 :尽量由客户端主动关闭,避免服务端出现time_wait

根据一个查询TCP连接数

netstat -ant|awk '/^tcp/ {++S[$NF]} END {for(a in S) print (a,S[a])}'
或者
netstat -an|awk ‘/tcp/ {print $6}’|sort|uniq -c
1
2
3


解决办法
解决上述 time_wait 状态大量存在,导致新连接创建失败的问题,一般解决办法:

1、客户端, HTTP 请求的头部,connection 设置为 keep-alive,保持存活一段时间:现在的浏览器,一般都这么进行了
2、服务器端,
允许 time_wait 状态的 socket 被重用
缩减 time_wait 时间,设置为 1 MSL(即,2 mins)
3、编辑内核文件/etc/sysctl.conf,加入以下内容:

net.ipv4.tcp_syncookies = 1     表示开启SYN Cookies。当出现SYN等待队列溢出时,启用cookies来处理,可防范少量SYN攻击,默认为0,表示关闭;
net.ipv4.tcp_tw_reuse = 1       表示开启重用。允许将TIME-WAIT sockets重新用于新的TCP连接,默认为0,表示关闭;
net.ipv4.tcp_tw_recycle = 1     表示开启TCP连接中TIME-WAIT sockets的快速回收,默认为0,表示关闭。
net.ipv4.tcp_fin_timeout = 30        修改系默认的 TIMEOUT 时间
1
2
3
4
然后执行 /sbin/sysctl -p 让参数生效.

/etc/sysctl.conf是一个允许改变正在运行中的Linux系统的接口,它包含一些TCP/IP堆栈和虚拟内存系统的高级选项,修改内核参数永久生效。
1
注释 :

net.ipv4.tcp_syncookies = 1 表示开启SYN Cookies。当出现SYN等待队列溢出时,启用cookies来处理,可防范少量SYN攻击,默认为0,表示关闭;
net.ipv4.tcp_tw_reuse = 1 表示开启重用。允许将TIME-WAIT sockets重新用于新的TCP连接,默认为0,表示关闭;
net.ipv4.tcp_tw_recycle = 1 表示开启TCP连接中TIME-WAIT sockets的快速回收,默认为0,表示关闭。
net.ipv4.tcp_fin_timeout 修改系默认的 TIMEOUT 时间
1
2
3
4
简单来说,就是打开系统的TIMEWAIT重用和快速回收。

如果以上配置调优后性能还不理想,可继续修改一下配置:

vi /etc/sysctl.conf
net.ipv4.tcp_keepalive_time = 1200 
#表示当keepalive起用的时候,TCP发送keepalive消息的频度。缺省是2小时,改为20分钟。
net.ipv4.ip_local_port_range = 1024 65000 
#表示用于向外连接的端口范围。缺省情况下很小:32768到61000,改为1024到65000。
net.ipv4.tcp_max_syn_backlog = 8192 
#表示SYN队列的长度,默认为1024,加大队列长度为8192,可以容纳更多等待连接的网络连接数。
net.ipv4.tcp_max_tw_buckets = 5000 
#表示系统同时保持TIME_WAIT套接字的最大数量,如果超过这个数字,TIME_WAIT套接字将立刻被清除并打印警告信息。
默认为180000,改为5000。对于Apache、Nginx等服务器,上几行的参数可以很好地减少TIME_WAIT套接字数量,但是对于 Squid,效果却不大。此项参数可以控制TIME_WAIT套接字的最大数量,避免Squid服务器被大量的TIME_WAIT套接字拖死。

net.ipv4.tcp_syncookies=1        打开TIME-WAIT套接字重用功能,对于存在大量连接的Web服务器非常有效。 
net.ipv4.tcp_tw_recyle=1 
net.ipv4.tcp_tw_reuse=1           减少处于FIN-WAIT-2连接状态的时间,使系统可以处理更多的连接。 
net.ipv4.tcp_fin_timeout=30              减少TCP KeepAlive连接侦测的时间,使系统可以处理更多的连接。 
net.ipv4.tcp_keepalive_time=1800         增加TCP SYN队列长度,使系统可以处理更多的并发连接。 
net.ipv4.tcp_max_syn_backlog=8192
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17


net.ipv4.tcp_max_syn_backlog = 8192
net.ipv4.tcp_keepalive_time = 1200
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_tw_recycle = 1
1
2
3
4
5
查看效果


解决进程的FIN_WAIT2状态
FIN_WAIT_2状态很多的原因: 服务端关闭,但客户端没有关闭。
解决:

1.服务端程序读到 -1时,应该关闭连接,这样服务端就会发起fin 指令。
      进程关闭也会自动发fin 指令。

2. tcp协议里没有针对这个状态设置超时时间,但linux服务器实现了超时回收,
1
2
3
4
tcp_fin_timeout ,默认是60秒, 可通过 /sbin/sysctl -a | grep timeout 查看

网络超时:socket本身有 重连控制,网络拥塞控制。

结论:几个核心要点
1、time_wait 状态的影响:
TCP 连接中,「主动发起关闭连接」 的一端,会进入 time_wait 状态
time_wait 状态,默认会持续 2 MSL(报文的最大生存时间),一般是 2x2 mins
time_wait 状态下,TCP 连接占用的端口,无法被再次使用
TCP 端口数量,上限是 6.5w(65535,16 bit)
大量 time_wait 状态存在,会导致新建 TCP 连接会出错,address already in use : connect 异常
2、现实场景:
1、服务器端,一般设置:不允许「主动关闭连接」
2、但 HTTP 请求中,http 头部 connection 参数,可能设置为 close,则,服务端处理完请求会主动关闭 TCP 连接
3、现在浏览器中, HTTP 请求 connection 参数,一般都设置为 keep-alive
4、Nginx 反向代理场景中,可能出现大量短链接,服务器端,可能存在
3、解决办法:
服务器端,
允许 time_wait 状态的 socket 被重用
缩减 time_wait 时间,设置为 1 MSL(即,2 mins)

FIN_WAIT1:
1、sysctl -a |grep tcp_max_orph(记下 net.ipv4.tcp_max_orphans 的值 第三步需要赋给orig_orphans)

2、sysctl -w net.ipv4.tcp_max_orphans=0 然后等待FIN_WAIT1的消失,可以用 netstat -np|grep 9080 反复查看,直到没有任何条目

3、sysctl -w net.ipv4.tcp_max_orphans=$orig_orphans

参考链接 :
解决TIME_WAIT过多造成的问题 : https://www.cnblogs.com/dadonggg/p/8778318.html
netstat -an查看到大量的TIME_WAIT状态的解决办法 :https://www.cnblogs.com/mobilecard/archive/2018/08/13/9468934.html

linux端口被占用,netstat查看无进程号,端口状态一直停留在FIN_WAIT1以及CLOSE_WAIT状态
https://blog.youkuaiyun.com/microgp/article/details/86588973
http://blog.sina.com.cn/s/blog_77d329940102xa4t.html
FIN_WAIT_2 tcp状态多原因剖析和解决 :https://blog.youkuaiyun.com/fei33423/article/details/50889385
基础原理系列:服务端 TCP 连接的 TIME_WAIT 问题 :https://ningg.top/computer-basic-theory-tcp-time-wait/

 

高并发场景下大量TCP链接处于time_wait状态原因及优化思路分析 time_wait问题处理 阅读详情

相关推荐

TCP三次握手原理与实战:从SYN到TIME_WAIT全解析

TCP连接是互联网可靠传输的基石,其核心机制建立在序列号、确认应答、重传控制等基础概念之上。理解TCP需先把握‘不可靠网络上构建可靠逻辑’这一根本矛盾,进而深入三次握手的状态同步原理——它通过双向初始序列号交换与确认,确保通信双方状态机严格一致,从而规避丢包、乱序与历史报文干扰。该机制支撑着HTTP、HTTPS、数据库访问等绝大多数关键应用,技术价值体现在电商下单不丢单、金融交易不丢帧、实时协作不断连等工程实践中。本文结合Wireshark抓包、tc故障注入与sysctl调优,覆盖从连接建立(SYN/SYN

baochuanying9531的博客 422

ubuntu中解决进程的TIME_WAIT和FIN_WAIT2链接状态_ubuntu16

可以戳这里获取](https://bbs.youkuaiyun.com/topics/618631832)**

2401_84141219的博客 495

TCP与UDP抓包分析实战:从三次握手到TIME_WAIT排查

传输层是网络通信的核心,TCP与UDP分别代表了可靠与高效两种设计哲学。TCP通过三次握手建立连接,依靠序列号与确认号保障数据有序到达,却也因此引入了握手开销与状态管理复杂度;UDP仅用8字节首部提供无连接传输,效率虽高却将丢包、乱序的处理责任交给了应用层。抓包分析时,理解这些底层差异直接决定了排查效率:Wireshark过滤条件选择、UDP端口测试方法、SYN Flood识别、TIME_WAIT与CLOSE_WAIT异常处理,都离不开对协议原理的掌握。本文从抓包视角出发,梳理TCP连接建立与断开的状态迁移

weixin_34393428的博客 285

LINUX如何解决服务器TCP连接TIMEOUT过长

net.ipv4.tcp_tw_reuse = 1 表示开启重用。允许将TIME-WAIT sockets重新用于新的TCP连接,默认为0,表示关闭;当出现SYN等待队列溢出时,启用cookies来处理,可防范少量SYN攻击,默认为0,表示关闭;net.ipv4.tcp_tw_recycle = 1 表示开启TCP连接中TIME-WAIT sockets的快速回收,默认为0,表示关闭。net.ipv4.tcp_fin_timeout 修改系統默认的 TIMEOUT 时间。

科比不来it 4013

ubuntu中解决进程的TIME_WAIT和FIN_WAIT2链接状态

环境 :Ubuntu 16.04 LTS 解决进程的time_wait状态 查看进程连接状态 #netstat -an|awk ‘/tcp/ {print $6}’|sort|uniq -c 16 CLOSING 130 ESTABLISHED 298 FIN_WAIT1 13 FIN_WAIT2 9 LAST_ACK 7 LISTEN 103 SYN_RECV 5204 TIME_WAIT 状...

qq_40907977的博客 2531

Crossformer实战:从零开始搭建多变量时间序列预测模型(附ETTh1数据集调参指南)

本文提供了从零开始搭建Crossformer多变量时间序列预测模型的实战指南,并附有详细的ETTh1数据集调参攻略。文章深入解析了Crossformer的核心设计,重点探讨了seg_len和win_size等关键参数对模型性能的影响,并分享了环境配置、训练调试及常见问题的解决方案,帮助开发者高效应用这一前沿深度学习模型。

weixin_29281915的博客 325

当系统出现大量TIME_WAIT状态的连接,如何修改内核参数来优化?

当出现SYN等待队列溢出时,启用cookies来处理,可防范少量SYN攻击,默认为0,表示关闭;允许将TIME-WAIT sockets重新用于新的TCP连接,默认为0,表示关闭;net.ipv4.tcp_syncookies = 1 表示。net.ipv4.tcp_tw_recycle = 1 表示。net.ipv4.tcp_tw_reuse = 1 表示。然后执行一下命令让参数生效。,默认为0,表示关闭。

bbj1030的博客 1194

Keil环境下单片机串口通信实战:如何用printf发送中文(附完整代码)

本文详细解析了在Keil开发环境下,单片机通过串口通信发送中文信息时产生乱码的根本原因及解决方案。核心在于理解并统一编码(如GB2312或UTF-8),并正确重定向printf函数。文章提供了针对STC89C52和STM32F103的完整代码示例,涵盖工程配置、编码设置、调试技巧,帮助开发者实现稳定可靠的中文串口输出。

weixin_29168675的博客 469

FIN_WAIT_2的超时时间

FIN_WAIT_2状态的超时时间

书唐瑞的博客 3199

绝对旋转编码器学习笔记(基本原理,与PC通信等,不定期更新中)

前言 最近开始学习编码器相关内容,目的在于搞清楚编码器的原理,与上位机的联系等问题。笔记资料来源为网络,整理的同时也会有一些总结和感悟。由于研究方向需求,主要研究数字旋转编码器。 1.编码器的定义 编码器(encoder)是将信号(如比特流)或数据进行编制、转换为可用以通讯、传输和存储的信号形式的设备。——摘自《百度百科》 通常来说,编码器可以将角度位移、直线位移、转速等物理量转换为电信号。这里的电信号根据不同原理的编码器输出脉冲、二进制数码等不同的类型,下面会提到。 2.编码器的分类 编.

黑化咸鱼的博客 1万+

OAI数据集申请下载全攻略:从个人NDA账号注册到数据包下载的保姆级避坑指南

本文提供OAI数据集申请下载的完整指南,涵盖从个人NDA账号注册到数据包下载的全流程。重点解析login.gov验证陷阱、浏览器兼容性问题、NDA权限申请技巧及nda-tools高效使用方法,帮助医学影像研究者避开常见技术障碍,快速获取全球骨关节炎研究数据库OAI的宝贵数据资源。

weixin_28698059的博客 755

TCP端口状态说明ESTABLISHED、TIME_WAIT

查看网络连接数: netstat -an |wc -l netstat -an |grep xx |wc -l查看某个/特定ip的连接数 netstat -an |grep TIME_WAIT|wc -l查看连接数等待time_wait状态连接数 netstat -an |grep ESTABLISHED |wc -l查看建立稳定连接数量 查看不同状态的连...

MarkZP 8714

数据预处理

数据预处理 数据预处理(数据清洗)是数据挖掘过程中的重要一步,它主要包括数据清洗,数据集成,数据变换和数据规约。 在我们进行数据挖掘的过程中,大量的原始数据中存在着大量有问题的数据(脏数据)比如有缺失值的,不一致的,有异常的,大量重复的数据等。这些脏数据会严重影响到数据挖掘建模过程的执行效率,也可能会使挖掘结果产生偏差。通过数据预处理(数据清洗)可以提高数据的质量,更好的适应特定的挖掘技术及工具。...

CJW的博客 9931

TCP协议之TIME_WAIT状态实战与分析

TCP/IP协议的三次握手和四次挥手,我们应该都滚瓜烂熟了。下面是一张代表发送接收双方全状态的图本文我们重点关注下TIME_WAIT状态。从图中我们可以看出来,该状态属于主动发起关闭的一方,在收到对方的关闭请求时,所处于的状态。按照TCP/IP协议规定:当TCP执行一个主动关闭并发送最终的ACK时,连接必须处于TIME_WAIT并持续两倍于最大生存期的时间,这样就能够让TCP重新发送最终的ACK以避免出现丢失的情况。Q:出现丢失?A:怎么理解出现丢失,我们看以下这种场景:当上图中的Server(在Clien

恐龙弟旺仔的博客 1983

【ComfyUI】Flux 图像扩展

本文介绍了一个基于Flux扩图技术的ComfyUI工作流,能够智能扩展图像尺寸并保持内容连贯性。该流程通过扩散模型与条件编码的结合,对图像边缘进行语义填充生成,适用于艺术创作、海报设计等场景。工作流包含图像加载、外扩填充、文本编码、扩散采样等核心节点,采用Flux1-fill-dev等专业模型确保生成质量。演示效果显示,系统能自然延伸原图内容,保持风格统一。该技术可广泛应用于插画扩展、摄影增强、游戏场景构建等领域,显著提升创意工作效率。

Mr数据杨 930

【测开求职】面试题:JAVA 吐血整理

本篇文章包含本次测开工程师秋招过程中遇到的所有JAVA面试题,全文两万字,亲测应对各个大厂的面试毫无压力👉

vector的博客 1213

彻底理解并解决服务器出现大量TIME_WAIT - 第二篇

2. 设置 l_onoff 为1,l_linger为0,则连接立即终止,TCP将丢弃残留在发送缓冲区中的任何数据并发送一个RST报文给对方,而不是通常的四分组终止序列。只是代名层的修改往往会比较大。这里的HZ是1s,因此可以得出RTO最大是120s,最小是200ms,对于局域网的机器来说,正常情况下RTO基本上就是200ms,因此3.5 RTO就是。这两个选项是linux内核提供的控制选项,和具体的应用程序没有关系,而且网上也能够查询到大量的相关资料,但信息都不够完整,最主要的几个问题如下;

papaya的博客 1639

从扩散到流匹配:具身智能中的生成模型原理与实现细节(具身智能/VLA/机器人面试常考)

本文探讨了生成模型在具身智能中的应用,重点对比了扩散模型和流匹配(Flow Matching)两种方法。扩散模型通过逐步加噪和去噪过程学习数据分布,建模能力强但采样速度慢;而Flow Matching直接学习连续向量场,更适合实时轨迹规划等需要快速连续生成的任务。文章还分析了自注意力机制的优势、ROS1/ROS2通信架构差异,并提供了Flow Matching的PyTorch实现代码。这些生成模型使机器人系统能够处理不确定性、多模态信息和连续控制问题,从传统的确定解转向更灵活的分布建模范式。

m0_51738372的博客 236

ubuntu系统TCP连接参数优化-TIME_WAIT过多解决办法

状态:描述CLOSED:无连接是活动的或正在进行LISTEN:服务器在等待进入呼叫SYN_RECV:一个连接请求已经到达,等待确认SYN_SENT:应用已经开始,打开一个连接ESTABLISHED:正常数据传输状态FIN_WAIT1:应用说它已经完成FIN_WAIT2:另一边已同意释放ITMED_WAIT:等待所有分组死掉CLOSING:两边同时尝试关闭TIME_WAIT:另一...

weixin_30367543的博客 940

文档:亲测可用解决vnc灰屏,黑屏,鼠标大黑叉情况

主要解决vnc-viewer灰屏,黑屏,鼠标大黑叉等现象,详细见文档。

温度PID控制PLC程序

温度PID稳定控制程序,适用于欧姆龙PLC,对其他PLC也具有很大参考价值

linux 大量的TIME_WAIT解决办法

转载自:http://space.itpub.net/9653957/viewspace-626059

风过无声 1万+

jre9下载 jdk9

(Java SE Runtime Environment 9.0) 9.0u175 官方最新版 【x86|x64】

tcp 协议TIME_WAIT状态详解

上一篇文章提到执行主动关闭的一端进入 tcp TIME_WAIT状态,关于原因,unix网络编程卷一中给出两点: 1. 实现终止TCP全双工链接的可靠性,即保证tcp连接可靠断开。 2. 让老的重复分节在网络中消失 第一个原因的解释,执行主动关闭的一端最终会发ACK给对端,如果这个ACK最终丢失,那么发FIN的对端将由于在等待ACK超时后重发FIN分节,而如果主动关闭的一端在发完最终的A...

管子(zero)的杂乱空间 237

Camera2Demo

在Camera2 的基础上进行封装,使得Camera2一堆初始化逻辑与Activity分离,降低耦合度,完成预览拍照并保存的操作

linux下解决大量的TIME_WAIT

[root@web02 ~]# vi /etc/sysctl.conf 新增如下内容: net.ipv4.tcp_tw_reuse = 1 net.ipv4.tcp_tw_recycle = 1 net.ipv4.tcp_syncookies=1 使内核参数生效: [root@web02 ~]# sysctl -p readme: net.ipv4.tcp_syncookies=1 打开TIME-

邃森泓蛟的专栏 676

TIME_WAIT过多的处理方法

http://blog.youkuaiyun.com/yusiguyuan/article/details/21445883 http://www.itdhz.com/post-298.html

stay hungry,stay foolish 1811

ubuntu退出python命令_如何在ubuntu中指令行关闭python socket服务器

本文介绍下,在solaris 系统下,python socket server重启后,提示端口被占用,telnet端口失败。这里给出一个解决方法,有需要的朋友参考下。在solaris 系统下,socket server被重启后,提示端口被占用,telnet端口又是不成功的,说明服务已被关闭。通过netstat可以看到端口还处于于fin_wait_2状态,solaris要4分钟才能关闭。遇到这个问题...

weixin_39637711的博客 316

Ubuntu/Linux TCP 参数优化 解决 TIME_WAIT 过多

状态:描述CLOSED:无连接是活动的或正在进行LISTEN:服务器在等待进入呼叫SYN_RECV:一个连接请求已经到达,等待确认SYN_SENT:应用已经开始,打开一个连接ESTABLISHED:正常数据传输状态FIN_WAIT1:应用说它已经完成FIN_WAIT2:另一边已同意释放ITMED_WAIT:等待所有分组死掉CLOSING:两边同时尝试关闭TIME_WAIT:另一边已初始化一个释放...

liming495的专栏 942

⟅UNIX网络编程⟆⦔TCP客户/服务器程序实例(二)

目录说在前面正常启动 说在前面 环境: WSL 参考: UNIX网络编程 目录:这里 其他:接上篇⟅UNIX网络编程⟆⦔TCP客户/服务器程序实例(一) 正常启动

o0o 320
上一篇: Protobuf与JSON互相转换
下一篇: HTTP请求协议头部字段-Connection=keepalive
王树民
博客等级 码龄10年 912粉丝 560原创
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明:

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

余额充值