TCP关闭连接(为什么会能 Time_wait,Close_wait ) ?

作者:胡文斌

Tcp 关闭连接问题及注意

最近一段时间一直在学习阅读mina和nio的源码,也发现了一些问题无法解决,然后重读了一下tcp协议,收获颇多。(这就是带着问题去读书的好处

这次就和大家分享一下我们的netframework服务总会抛出一个“connet reset by peer”的原因吧。通过抓包工具分析,主动关闭方直接发送了一个RST flags,而非FIN。就终止连接了。如下图所示:

为什么调用sokcet的close时只通过一次握手就终结连接了?

要分析这个原因那就得从关闭连接程的四次握手,有时也会是三次握手,说起。如下图所示:

大家都知道tcp正常的关闭连接要经过四次握手。如下所示:

在这四次握手状态中,有一个特别要注意的状态TIME_WAIT这个状态是主动关闭方在收到被关闭方的FIN后会处于并长期(2个MSL时间,根据具体的实现不同,这个值会不同,在RFC 1122建议MSL=2分钟,但在Berkeley的实现上使用的值为30s,具体可以看www.rfc.net ,要是没有耐心去看英文的可以看这个网站www.cnpaf.net 里面有协议说明以及相应的源码,java源码中我没有发现这个值,我只能追踪到PlainSocketImpl.java这个类,再往下就是本地接口调用了,因此它是依赖本地操作系统的实现)处于的一个状态也就是大约1-4分钟,然后由操作系统自动回收并将TCP连接设为CLOSED初始状态。如下图所示:

然而在socket的处于TIME_WAIT状态之后到它结束之前,该socket所占用的本地端口号将一直无法释放,因此服务在高并发高负载下运行一段时间后,就常常会出现做为客户端的程序无法向服务端建立新的socket连接的情况,过了1~4分钟之后,客户又可以连接上了,没多久又连接不上,再等1~4分钟之后又可以连接上,(上一个星期我们在做一个服务切换时遇到了这种情况)

这是因为服务方socket资源已经耗尽。netstat命令查看系统将会发现机器上存在大量处于TIME_WAIT状态的socket连接,我这边曾经出现达到了2w多个,并且占用大量的本地端口号。而此时机器上的可用本地端口号被占完,旧的大量处于TIME_WAIT状态的socket尚未被系统回收时,就会出现无法向服务端创建新的socket连接的情况。只能过2分钟之后等系统回收这些socket和端口资源之后才能服务,就这样往复下去。

TCP为什么要这么要让这种TIME_WAIT状态存活这么久呢?其原因有两个(参考stevens的unix网络编程卷1 第38页):

  1. 可靠地实现TCP全双工连接的终止。(确保最后的ACK能让被关闭方接收)
  2. 允许老的重复分节在网络中消逝。(TCP中是可靠的服务,当数据包丢失会重传,当有数据包迷路的情况下,如果不等待2MSL时,当客户端以同样地方式重新和服务建立连接后,上一次迷路的数据包这时可能会到达服务,这时会造成旧包被重新读取)

解决方法:

1、(推荐方法,只能治标不治本)重用本地端口设置SO_REUSEADDR和SO_REUSEPORT (stevens的unix网络编程卷1 第179~182页)有详情的讲解,这样就可以允许同一端口上启动同一服务器的多个实例。怎样理解呢?说白了就是即使socket断了,重新调用前面的socket函数不会再去占用新的一个,而是始终就是一个端口,这样防止socket始终连接不上,会不断地换新端口。Java 中通过调用Socket的setReuseAddress,详细可以查看java.net.Socket源码。【这个地方会有风险,具体可以看(stevens的unix网络编程卷1 第181页)

2、修改内核TIME_WAIT等待的值,如果客户端和服务器都在同个路由器下,这个是非常推荐的。(链路好,重传机率低)

3、(不推崇,但目前我们是这样做的,这个是造成(“connet reset by peer”)的元凶)设置SO_LINGER的值,java中是调用socket的 setSoLinger目前我们是设置为0的。设置为这个值的意思是当主动关闭方设置了setSoLinger(true,0)时,并调用close后,立该发送一个RST标志给对端,该TCP连接将立刻夭折,无论是否有排队数据未发送或未被确认。这种关闭方式称为“强行关闭”,而后套接字的虚电路立即被复位,尚未发出的所有数据都会丢失。而被动关闭方却不知道对端已经彻底断开。当被动关闭方正阻塞在recv()调用上时,接受到RST时,会立刻得到一个“connet reset by peer”的异常(即对端已经关闭),c中是返回一个EPEERRST错。

为什么不推崇这种方法在(stevens的unix网络编程卷1 第173页)有详细的讲解。因为TIME_WAIT状态是我们的朋友,它是有助有我们的(也就是说,它会让旧的重复分节在网络中超时消失(当我们的链路越长,ISP复杂的情况下(从网通到教育网的ping包用了9000ms),重复的分节的比例是非常高的。))。而且我们主动关闭连接方大都是由客户端发起的(除了HTTP服务和异常),而且客户方一般都不会有持续的大并发请求。 因此对资源没有这么苛刻要求。

原创声明,本文系作者授权云+社区发表,未经许可,不得转载。

如有侵权,请联系 yunjia_community@tencent.com 删除。

编辑于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏企鹅号快讯

如何解决web系统session劫持

往期精选 session劫持是一种比较复杂的攻击方法。大部分互联网上的电脑多存在被攻击的危险。这是一种劫持tcp协议的方法,所以几乎所有的局域网,都存在被劫持 ...

21710
来自专栏Golang语言社区

linux服务器开发三(网络编程) --二

半关闭 当TCP链接中A发送FIN请求关闭,B端回应ACK后(A端进入FIN_WAIT_2状态),B没有立即发送FIN给A时,A方处在半链接状态,此时A可以接收...

5227
来自专栏散尽浮华

TCP连接的TIME_WAIT和CLOSE_WAIT 状态解说-运维笔记

相信很多运维工程师遇到过这样一个情形: 用户反馈网站访问巨慢, 网络延迟等问题, 然后就迫切地登录服务器,终端输入命令"netstat -anp | grep ...

3221
来自专栏我和PYTHON有个约会

30.3. 企业级开发进阶2.3:UDP编程

回顾TCP协议:一个非常重要的数据传输协议,很多网络协议都是以TCP协议为基础的;TCP协议要求服务器和客户端通过三次握手交互的方式建立可靠的连接,然后再进行数...

1113
来自专栏吴伟祥

计算机网络基础知识总结 转

计算机网络学习的核心内容就是网络协议的学习。网络协议是为计算机网络中进行数据交换而建立的规则、标准或者说是约定的集合。因为不同用户的数据终端可能采取的字符集是不...

571
来自专栏JAVA烂猪皮

使用并发工具实现 RPC 调用流量控制

RPC 服务中,每个服务的容量都是有限的,即资源有限,只能承受住给定的网络请求,所以,在设计 RPC 框架的时候,一定要考虑流量控制这个问题。而 Java 中,...

791
来自专栏Java Web

Java 面试知识点解析(五)——网络协议篇

2169
来自专栏转载gongluck的CSDN博客

UNPv13:#第2章#传输层:TCP、UDP和SCTP

概述 虽然协议族被称为“TCP/IP”,但除了TCP和IP这两个主要协议外,还有许多其他成员。所有网际协议由一个或多个称为请求评注(Request fo...

2956
来自专栏我是东东强

转发表(MAC表)、ARP表、路由表总结

计算机网络中一个关键步骤在于通信路径上不同节点对于流经本节点的数据包转发,常见的交换设备主要是交换机(第二层、三层)和路由器(第三层),在实际运行时,它们各自维...

3203
来自专栏Golang语言社区

优化Linux的内核参数来提高服务器并发处理能力

PS:在服务器硬件资源额定有限的情况下,最大的压榨服务器的性能,提高服务器的并发处理能力,是很多运维技术人员思考的问题。要提高Linux系统下的负载能力,可以使...

2594

扫码关注云+社区