在一次生产上线后,发现使用的 8086 端口相关的 TCP 连接数竟然多大 6K+ ,有时候甚至会逼近 1w ,这个数量对于一个只是在内部使用的监控系统来说, 无论如何都是无法接受的, 于是开始一系列的排查过程. 本文记录了这个问题的主要解决过程,算是对这一次杀 bug 过程的一个总结. 问题描述    使用命令 netstat -apn | grep 8086 可以看到大量处于 TIME_WAIT状态的 tcp 连接 使用命令 netstat -apn | grep 8086 | gr

在写TCP服务的时候经常需要面对的问题就是如何知道一个TCP连接当前是否有效,但这个问题对很多初入门的同学来说是很困惑的,主要原因是当对方关闭连接后,另一方无法有效的知道:对于同步操作来说可以通过设置操作超时来解决,但异步操作则没有这样方便的了,那只能等keepalive的检测完成引发异步回调了. 那在编写应用的时候一般通讯什么方式来检测连接的有效性呢?解决方法一般有两种一种是设置TCP的keepalive时间,另一种则是通过Ping,Pong的方式来实现.前者相对比较简单通过socket.IO

        经过前面对TCP连接管理的介绍,我们本小节通过TCP连接管理的状态机来总结一下看看TCP连接的状态变化 一.TCP状态机整体状态转换图(截取自第二版TCPIP详解) 二.TCP连接建立和终止过程中状态迁移总结 下面我们总结一下前面介绍过的连接建立方式和终止过程中client端和server端的状态切换 1.三次握手 client:CLOSED -> SYN_SENT -> ESTABLISHED server:CLOSED -> LISTEN -> SYN_RCVD

问题 线上的一个项目会和微信服务器有API请求(目的是获取用户的微信信息),但会有偶发的报错: 'Connection aborted.', ConnectionResetError(104, 'Connection reset by peer')) 原因是微信那边认为我频繁建立TCP连接是不对,很消耗他们的连接资源,所以把我的连接中断了. 概念 HTTP 的header里有一个"Keep-Alive"参数,用来告知服务器:我想要保存此次连接,我稍后还会请求,这样我们可以避免再次TCP

系统TCP连接内存大小限制 TCP的每一个连接请求,读写都需要占用系统内存资源,可根据系统配置,对TCP连接数,内存大小,限制调优. 查看系统内存资源 记录内存 详情:cat /proc/meminfo 命令:free -m TCP连接内存限制 内核调优 修改文件:/etc/sysctl.conf 生效命令:sysctl -p /etc/sysctl.conf 1.限制TCP总连接内存使用 # 内核分给TCP的内存大小范围,单位为page. # 第一个数字表示,当 tcp 使用的 page 少于

1.TCP是面向连接的协议. 运输连接时用来传送TCP报文的.TCP运输连接的建立和释放是每一次面向连接的通信中必不可少的过程.因此,运输链接就有三个阶段,即:连接建立.数据传送和连接释放. 在TCP连接建立过程中要解决以下三个问题: (1)要能使每一方都确知对方的存在. (2)要允许双方协商一些参数(如最大窗口值.是否使用窗口扩大选项和时间戳选项以及服务质量等). (3)能够对运输实体资源(如缓存大小.连接表中的项目等)进行分配. 2.TCP的连接建立 上面给出的连接建立过程叫做三次握手 2.

我们通过了解 TCP各个状态 ,可以排除和定位网络或系统故障时大有帮助. 一.TCP状态 LISTENING :侦听来自远方的TCP端口的连接请求 . 首先服务端需要打开一个 socket 进行监听,状态为LISTEN. 有提供某种服务才会处于LISTENING状态, TCP状态变化就是某个端口的状态变化,提供一个服务就打开一个端口,例如:提供www服务默认开的是80端口,提供ftp服务默认的端口为21,当提供 的服务没有被连接时就处于LISTENING状态.FTP服务启动后首先处于侦听(LIS

修改Time_Wait和CLOSE_WAIT时间 修改Time_Wait参数的方法 (在服务端修改)Windows下在HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Services/Tcpip/Parameters,添加名为TcpTimedWaitDelay的DWORD键,设置为30,以缩短TIME_WAIT的等待时间 解决CLOSE_WAIT的方法:(在客户端修改)1 一般原因都是TCP连接没有调用关闭方法.需要应用来处理网络链接关闭.2 对于Web请

概念 TIME_WAIT: socket 仍然有数据在内核中待发送直到发送成功或超时,此socket不能被内核删除,同时等待是否要重传Ack对端还已发过来的FIN Linger Time:socket关闭后,如果send buffer里仍有数据,内核删除socket的超时时间,一般2min SO_REUSEADDR:如果有socket在TIME_WAIT状态,别的socket可以绑定和它相同的“地址:端口” SO_REUSEPORT:允许绑定相同的“地址:端口”,但要求前面的socket也设置了

其实对于网络通信的学习,最好还是能够自己抓到包详细地一下,不然只单单通过文字和图的描述印象不够深刻.本文通过实际的抓包操作来看一下tcp的连接与断开是怎样的. 首先需要去https://www.wireshark.org/下载wireshark对应你机器位数的版本,也可以用这个连接直接下载(64位)http://sw.bos.baidu.com/sw-search-sp/software/16fb23dbe1547/Wireshark-win32-2.4.3.0.exe. 安装完成后打开,会看到

第15章     RL-TCPnet之创建多个TCP连接 本章节为大家讲解RL-TCPnet的TCP多客户端实现,因为多客户端在实际项目中用到的地方还挺多,所以我们也专门开启一个章节做讲解.另外,学习本章节前,务必要优先学习第14章TCP客户端.学会创建一个TCP客户端了,创建多个客户端是一样的. 本章教程含STM32F407开发板和STM32F429开发板. 15.1  初学者重要提示 15.2  创建多个TCP客户端连接服务器 15.3  TCP配置说明(Net_Config.c) 15.4

1.CLOSE_WAIT的简单解决方案 不久前,我的Socket Client程序遇到了一个非常尴尬的错误.它本来应该在一个socket长连接上持续不断地向服务器发送数据,如果socket连接断开,那么程序会自动不断地重试建立连接. 有一天发现程序在不断尝试建立连接,但是总是失败.用netstat查看,这个程序竟然有上千个socket连接处于CLOSE_WAIT状态,以至于达到了上限,所以无法建立新的socket连接了. 为什么会这样呢? 它们为什么会都处在CLOSE_WAIT状态呢? CLOS

相信很多运维工程师遇到过这样一个情形: 用户反馈网站访问巨慢, 网络延迟等问题, 然后就迫切地登录服务器,终端输入命令"netstat -anp | grep TIME_WAIT | wc -l " 查看一下, 接着发现有几百几千甚至几万个TIME_WAIT 连接数. 顿时慌了~ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38

在面试时,会经常被问到TCP报文的一些细节,可以说TCP报文是不少企业用来考察面试者对网络的掌握程度的一道题目. TCP连接作为网络传输的一个环节,是不可或缺的一部分.例如,OSI七层模型的应用层HTTP就是基于TCP连接实现的. TCP连接的三次握手和四次挥手机制相信是每个后台开发人员耳熟能详的知识点,那么关于TCP的报文细节以及背后的原理是怎么样的呢?TCP是怎样借助报文来实现三次握手和四次挥手呢?笔者通过阅读书本和加上自己的理解.通过本文,来谈谈TCP报文首部以及报文首部背后的原理. 首先

相信很多运维工程师遇到过这样一个情形: 用户反馈网站访问巨慢, 网络延迟等问题, 然后就迫切地登录服务器,终端输入命令"netstat -anp | grep TIME_WAIT | wc -l " 查看一下, 接着发现有几百几千甚至几万个TIME_WAIT 连接数. 顿时慌了~ 通过 "netstat -anp | grep TIME_WAIT | wc -l" 命令查看数量,发现TIME_WAIT的连接数量很多! 可能是因为服务器主动关闭连接导致TIME_WAI

from http://blog.csdn.net/nyist327/article/details/39586203 心跳包的发送,通常有两种技术方法1:应用层自己实现的心跳包 由应用程序自己发送心跳包来检测连接是否正常,大致的方法是:服务器在一个 Timer事件中定时 向客户端发送一个短小精悍的数据包,然后启动一个低级别的线程,在该线程中不断检测客户端的回应, 如果在一定时间内没有收到客户端的回应,即认为客户端已经掉线:同样,如果客户端在一定时间内没 有收到服务器的心跳包,则认为连接不可用.

一.问题概述 今天遇到个小问题. 我们的程序依赖了大数据那边的服务,大数据那边提供了restful接口供我们调用. 测试反映接口有问题,我在本地重现了. 我这边感觉抓包可能对分析问题有用,就用wireshark抓包了.然后发给大数据的同事看了下,是他们的问题. 然后就帮忙把问题解决了. 然后我这边重新测试,自己抓包了下,结果反而发现我方程序的一个问题. 下图,是我方和大数据方的交互数据包. 前三个为tcp连接建立,中间(序号4,5,6)为http请求响应,序号7-8为大数据方在请求完毕后关闭连接

TCP RST 网络 linux 目录[-] 1 端口未打开 2 请求超时 3 提前关闭 4 在一个已关闭的socket上收到数据 总结 参考文献: 应该没有人会质疑,现在是一个网络时代了.应该不少程序员在编程中需要考虑多机.局域网.广域网的各种问题.所以网络知识也是避免不了学习的.而且笔者一直觉得TCP/IP网络知识在一个程序员知识体系中必需占有一席之地的. 在TCP协议中RST表示复位,用来异常的关闭连接,在TCP的设计中它是不可或缺的.发送RST包关闭连接时,不必等缓冲区的包都发出去,直接

我们一直认为,HTTP连接分为长连接和短连接,而我们现在常用的都是HTTP1.1,因此我们用的都是长连接. 这句话其实只对了一半,我们现如今的HTTP协议,大部分都是1.1的,因此我们平时用的基本上都是长连接.但是前半句是不对的,HTTP协议根本没有长短连接这一说,也正因为误解了这个,导致LZ对于长连接一直不明不白,始终不得其要领,具体下面一段会说到. 网络上很多文章都是误人子弟,根本没有说明白这个概念.这里LZ要强调一下,HTTP协议是基于请求/响应模式的,因此只要服务端给了响应,本次HTTP

FROM:http://blog.csdn.net/hguisu/article/details/38700899 该博文的条理清晰,步骤明确,故复制到这个博文中收藏,若文章作者看到且觉得不能装载,麻烦请告知,谢谢. 我们通过了解TCP各个状态,可以排除和定位网络或系统故障时大有帮助.(总结网络上的内容) 1.TCP状态 linux查看tcp的状态命令: 1).netstat -nat  查看TCP各个状态的数量 2).lsof  -i:port  可以检测到打开套接字的状况 3).  sar

TCP传输控制协议是面向连接的可靠的传输层协议,在进行数据传输之前,需要在传输数据的两端(客户端和服务器端)创建一个连接,这个连接由一对插口地址唯一标识,即是在IP报文首部的源IP地址.目的IP地址,以及TCP数据报首部的源端口地址和目的端口地址.TCP首部结构如下: 其中在TCP连接和断开连接过程中的关键部分如下: 1.源端口号:即发送方的端口号,在TCP连接过程中,对于客户端,端口号往往由内核分配,无需进程指定: 2.目的端口号:即发送目的的端口号: 3.序号:即为发送的数据段首个字节的序号