tcp死连接(tcp长连接)

      最后更新:2024-03-15 22:49:02 手机定位技术交流文章

      Modbus tcp 连接成功后断开网线再连死机

      系统不兼容。Modbustcp是通讯连接电力通讯管理系统,需要独立的系统兼容,系统不兼容时可以正常进行连接操作,但是会在断网后由于系统不兼容导致tcp连接丢失造成电脑的死机。
      Modbus tcp 连接成功后断开网线再连死机

      什么是死连接

      在数据库postgresql中,一个客户端到服务器连接实际上是一个tcp socket连接,tcp连接是虚连接,一方非正常退出(如断电),另一方会继续维持这个连接。 举个例子,一个客户端电脑正常连上服务器后,强行拔掉电源造成人为断电,重新启动电脑,再此连上服务器。用SQL语句select * from pg_stat_activily 查看服务器的所有连接,会发现本客户端的连接除了本次外,断电前的连接还在。因为服务器根本不知道客户端的断电行为,还以为那连接正在空闲状态。然而这个死连接不会永远存在,2个小时后,服务器上的这个连接会自动切掉,因为postgresql支持TCP_KEEPLIVE机制。有三个系统变量tcp_keepalives_idle,tcp_keepalives_interval ,tcp_keepalives_count 来设置postgresql如何处理死连接。对于每个连接,postgresql会对这个连接空闲tcp_keepalives_idle秒后,主动发送tcp_keeplive包给客户端,以侦探客户端是否还活着 ,当发送tcp_keepalives_count个侦探包,每个侦探包在tcp_keepalives_interval秒内没有回应,postgresql就认为这个连接是死的。于是切断这个死连接。在postgresql, 这三个参数都设为0将使用操作系统的默认值,在linux下,tcp_keepalives_idle一般是2个小时,也就是2个小时后,服务器才可以自动关掉死连接。在实际应运中,可以自行调整以上参数。然而,单单依靠服务器以此方法来切掉死连接,是永远不够。假设有一个连接,在运行以下交互式命令中突然断电begin transaction;lock table xxx in exclusive mode;-- 突然断电,这种可能很小,但肯定存在。。。commit由于这个连接还保留着,且这个transaction还没结束(本来上1秒之内的事务,现在变成至少要2个小时),所以这个表的锁一直存在着,导致系统的并发性严重降低。所以必需有手工杀掉连接的语句来切掉此连接,以释放锁。不幸的是,直到8.3,postgresql还没有此语句,源代码是有pg_terminate_query函数,因为有bug, 被屏蔽掉,必须到8.4才有。所以只能用操作系统的命令杀掉此连接,或者重启服务器。 在linux下,杀掉此连接的命令是: kill -s SIGTERM 进程号。
      失效的链接 就叫死链
      什么是死连接

      TCP keepalive 和 http keep-alive 以及心跳保活

      HTTP的长连接和短连接本质上是TCP长连接和短连接。短连接短连接,顾名思义,与长连接的区别就是,客户端收到服务端的响应后,立刻发送FIN消息,主动释放连接。也有服务端主动断连的情况,凡是在一次消息交互(发请求-收响应)之后立刻断开连接的情况都称为短连接。长连接/http keep-alive也叫持久连接,即一个TCP连接服务多次请求,在TCP层握手成功后,不立即断开连接,并在此连接的基础上进行多次消息(包括心跳)交互,直至连接的任意一方(客户端OR服务端)主动断开连接,此过程称为一次完整的长连接。在HTTP/1.0中得到了初步的支持,客户端在请求header中携带Connection:Keep-Alive,即是在向服务端请求持久连接。如果服务端接受持久连接,则会在响应header中同样携带Connection: Keep-Alive,这样客户端便会继续使用同一个TCP连接发送接下来的若干请求。(Keep-Alive的默认参数是[timout=5, max=100],即一个TCP连接可以服务至多5秒内的100次请求)HTTP/1.1开始,即使请求header中没有携带Connection: Keep-Alive,传输也会默认以持久连接的方式进行,只有加入"Connection: close "后,才关闭。http keepalive是客户端浏览器与服务端httpd守护进程协作的结果。TCP中的KeepAliveTCP协议的实现中,提供了KeepAlive报文,用来探测连接的对端是否存活。在应用交互的过程中,可能存在以下几种情况:客户端或服务器意外断电,死机,崩溃,重启;中间网络已经中断,而客户端与服务器并不知道;利用保活探测功能,可以探知这种对端的意外情况,从而保证在意外发生时,可以释放半打开的TCP连接。TCP保活报文交互过程如下:因此,KeepAlive并不适用于检测双方存活的场景,这种场景还得依赖于应用层的心跳。应用层心跳也具备着更大的灵活性,可以控制检测时机,间隔和处理流程,甚至可以在心跳包上附带额外信息。应用层心跳是检测连接有效性以及判断双方是否存活的有效方式。但是心跳过于频繁会带来耗电和耗流量的弊病,心跳频率过低则会影响连接检测的实时性。业内关于心跳时间的设置和优化,主要基于如下几个因素:理想的情况下,客户端应当以略小于NAT超时时间的间隔来发送心跳包。根据微信团队测试的一些数据,一些常用网络的NAT超时时间如下表所示:TCP的KeepAlive机制意图在于保活、心跳,检测连接错误如何快速区分当前连接使用的是长连接还是短连接1、凡是在一次完整的消息交互(发请求-收响应)之后,立刻断开连接(有一方发送FIN消息)的情况都称为短连接;2、长连接的一个明显特征是会有心跳消息(也有没有心跳的情况),且一般心跳间隔都在30S或者1MIN左右,用wireshark抓包可以看到有规律的心跳消息交互(可能会存在毫秒级别的误差)。什么时候用长连接,短连接?1、需要频繁交互的场景使用长连接,如即时通信工具(微信/QQ,QQ也有UDP),相反则使用短连接,比如普通的web网站,只有当浏览器发起请求时才会建立连接,服务器返回相应后,连接立即断开。2、维持长连接会有一定的系统开销,用户量少不容易看出系统瓶颈,一旦用户量上去了,就很有可能把服务器资源(内存/CPU/网卡)耗尽,所以使用需谨慎。keep-alive与TIME_WAIT使用http keep-alvie,可以减少服务端TIME_WAIT数量(因为由服务端httpd守护进程主动关闭连接)。道理很简单,相较而言,启用keep-alive,建立的tcp连接更少了,自然要被关闭的tcp连接也相应更少了。短连接和长链接 图:参考: https://caofengbin.github.io/2018/03/16/dhcp-and-nat/#4-%E5%BD%B1%E5%93%8D%E5%BF%83%E8%B7%B3%E9%A2%91%E7%8E%87%E7%9A%84%E5%85%B3%E9%94%AE%E5%9B%A0%E7%B4%A0https://blog.csdn.net/hengyunabc/article/details/44310193http://wingjay.com/2018/12/05/android-arch-long-link/https://www.levicc.com/2018/06/30/yi-dong-duan-wang-luo-you-hua/能被我参考的都很优秀,哈哈
      TCP keepalive 和 http keep-alive 以及心跳保活

      XE2做的Android应用服务程序产生大量的TCP死连接,怎么清除

      tcp协议,在三次握手成功即表示连接建立,之后若一方异常断开而没有通知对方,也就是没有主动断开连接。那么另一方是不知道的,他以为对方一直还在。 winsock为了解决这个问题提供了一个keepalive的参数设置项,可以用来设置在tcp层每隔一段时间发送心跳数据来探测对方是否还在,如果不在,socket的发送和接收函数会返回响应的错误。因此你只要设置这个参数,然后再发送或接收的时候处理错误即可。 当然你也可以不使用这个参数项,而自己在上层的协议中加入心跳保活机制,当然也就需要你自己处理和设计相关的协议了。
      XE2做的Android应用服务程序产生大量的TCP死连接,怎么清除

      tcp连接状态详解

      unix的哲学是一切皆文件,可以把socket看成是一种特殊的文件,而一些socket函数就是对其进行的操作api(读/写IO、打开、关闭)。我们知道普通文件的打开操作(open)返回一个文件描述字,与之类似,socket()用于创建一个socket描述符(socket descriptor),它唯一标识一个socket。当我们调用socket创建一个socket时,返回的socket描述字它存在于协议族(address family,AF_XXX)空间中,但没有一个具体的地址。如果想要给它赋值一个地址,就必须调用bind()函数,sockfd即socket描述字,它是通过socket()函数创建了,唯一标识一个socket。bind()函数就是将给这个描述字绑定一个名字。在将一个地址绑定到socket的时候,需要先将主机字节序转换成为网络字节序,而不要假定主机字节序跟网络字节序一样使用的是Big-Endian。由于这个问题曾引发过不少血案,谨记对主机字节序不要做任何假定,务必将其转化为网络字节序再赋给socket。这里的主机字节序就是我们平常说的大端和小端模式:不同的CPU有不同的字节序类型,这些字节序是指整数在内存中保存的顺序,这个叫做主机序。引用标准的Big-Endian和Little-Endian的定义如下:listen函数的第一个参数即为要监听的socket描述字,第二个参数为socket可以接受的排队的最大连接个数。listen函数表示等待客户的连接请求。connect函数的第一个参数即为客户端的socket描述字,第二参数为服务器的socket地址,第三个参数为socket地址的长度。客户端通过调用connect函数来建立与TCP服务器的连接。TCP服务器端依次调用socket()、bind()、listen()之后,就会监听指定的socket地址了。TCP客户端依次调用socket()、connect()之后就向TCP服务器发送连接请求。TCP服务器监听到这个请求之后,就会调用accept()函数去接收请求,这样连接就建立好了(在connect之后就建立好了三次连接),之后就可以开始进行类似于普通文件的网络I/O操作了。如果accpet成功,那么其返回值是由内核自动生成的一个全新的描述字,代表与客户的TCP连接。accept的第一个参数为服务器的socket描述字,是服务器开始调用socket()函数生成的,称为监听socket描述字;而accept函数返回的是已连接的socket描述字。一个服务器通常通常仅仅只创建一个监听socket描述字,它在该服务器的生命周期内一直存在。内核为每个由服务器进程接受的客户连接创建了一个已连接socket描述字,当服务器完成了对某个客户的服务,相应的已连接socket描述字就被关闭。read函数是负责从fd中读取内容.当读成功时,read返回实际所读的字节数,如果返回的值是0表示已经读到文件的结束了,小于0表示出现了错误。如果错误为EINTR说明读是由中断引起的,如果是ECONNREST表示网络连接出了问题。write函数将buf中的nbytes字节内容写入文件描述符fd.成功时返回写的字节数。失败时返回-1,并设置errno变量。 在网络程序中,当我们向套接字文件描述符写时有俩种可能。1)write的返回值大于0,表示写了部分或者是全部的数据。2)返回的值小于0,此时出现了错误在服务器与客户端建立连接之后,会进行一些读写操作,完成了读写操作就要关闭相应的socket描述字,类似于操作完打开的文件要调用fclose关闭打开的文件。close一个TCP socket的缺省行为时把该socket标记为已关闭,然后立即返回到调用进程。该描述字不能再由调用进程使用,也就是说不能再作为read或write的第一个参数close操作只是使相应socket描述字的引用计数-1,只有当引用计数为0的时候,才会触发TCP客户端向服务器发送终止连接请求。我们知道tcp建立连接要进行“三次握手”,即交换三个分组。大致流程如下:客户端向服务器发送一个SYN J服务器向客户端响应一个SYN K,并对SYN J进行确认ACK J+1客户端再想服务器发一个确认ACK K+1socket中TCP的四次握手释放连接详解某个应用进程首先调用close主动关闭连接,这时TCP发送一个FIN M;另一端接收到FIN M之后,执行被动关闭,对这个FIN进行确认。一段时间之后,服务端调用close关闭它的socket。这导致它的TCP也发送一个FIN N;接收到这个FIN的源发送端TCP对它进行确认,这样每个方向上都有一个FIN和ACK。为什么要三次握手由于tcp连接是全双工的,存在着双向的读写通道,每个方向都必须单独进行关闭。当一方完成它的数据发送任务后就可以发送一个FIN来终止这个方向的连接。收到FIN只意味着这个方向上没有数据流动,但并不表示在另一个方向上没有读写,所以要双向的读写关闭需要四次握手,3. time_wait状态如何避免?首先服务器可以设置SO_REUSEADDR套接字选项来通知内核,如果端口忙,但TCP连接位于TIME_WAIT状态时可以重用端口。在一个非常有用的场景就是,如果你的服务器程序停止后想立即重启,而新的套接字依旧希望使用同一端口,此时SO_REUSEADDR选项就可以避免TIME_WAIT状态。1.客户端连接服务器的80服务,这时客户端会启用一个本地的端口访问服务器的80,访问完成后关闭此连接,立刻再次访问服务器的80,这时客户端会启用另一个本地的端口,而不是刚才使用的那个本地端口。原因就是刚才的那个连接还处于TIME_WAIT状态。2.客户端连接服务器的80服务,这时服务器关闭80端口,立即再次重启80端口的服务,这时可能不会成功启动,原因也是服务器的连接还处于TIME_WAIT状态。实战分析:状态描述:CLOSED:无连接是活动的或正在进行LISTEN:服务器在等待进入呼叫SYN_RECV:一个连接请求已经到达,等待确认SYN_SENT:应用已经开始,打开一个连接ESTABLISHED:正常数据传输状态FIN_WAIT1:应用说它已经完成FIN_WAIT2:另一边已同意释放ITMED_WAIT:等待所有分组死掉CLOSING:两边同时尝试关闭TIME_WAIT:另一边已初始化一个释放LAST_ACK:等待所有分组死掉命令解释:如何尽量处理TIMEWAIT过多?编辑内核文件/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 修改系默认的 TIMEOUT 时间然后执行 /sbin/sysctl -p 让参数生效./etc/sysctl.conf是一个允许改变正在运行中的Linux系统的接口,它包含一些TCP/IP堆栈和虚拟内存系统的高级选项,修改内核参数永久生效。简单来说,就是打开系统的TIMEWAIT重用和快速回收。本文主要讲述了socket的主要api,以及tcp的连接过程和其中各个阶段的连接状态,理解这些是更深入了解tcp的基础!
      tcp连接状态详解

      本文由 在线网速测试 整理编辑,转载请注明出处,原文链接:https://www.wangsu123.cn/news/302828.html

          热门文章

          文章分类