2 ghyghost ghyghost 于 2016.03.03 12:24 提问

为什么ServerSocket关闭后不进入time_wait状态啊?

为什么ServerSocket关闭后不进入time_wait状态啊?

1个回答

wojiushiwo945you
wojiushiwo945you   Ds   Rxr 2016.03.03 13:24

Java的Socket 是对TCP/IP协议之上的封装,正常来说你执行关闭后,我们也看不到TCP关闭过程中的四次握手状态的变化的。
如果你真的想分析四次握手这个过程中通信过程及状态的变化,应该通过抓包工具分析网卡的通信数据包。
参考:http://www.360doc.com/content/14/1201/16/7669533_429603672.shtml

Csdn user default icon
上传中...
上传图片
插入图片
准确详细的回答,更有利于被提问者采纳,从而获得C币。复制、灌水、广告等回答会被删除,是时候展现真正的技术了!
其他相关推荐
主动关闭TCP连接的一方为什么要有TIME_WAIT状态
TCP连接是全双工通信,主动方和被动方都需要自主关闭通信链路,TCP正常情况下连接断开会进行四次挥手(流程如上图所示): 1.由主动断开方发起FIN 2.被动方回复ACK 3.待被动方数据传输完成,被动方发送FIN 4.主动方回复ACK,并进入TIME_WAIT状态 TIME_WAIT的状态会持续2MSL (MSL是报文在网络中生存的最大生命周期)。 那这里为什么需要2MSL的状态
socket的TIME_WAIT状态的原因及解决办法和避免的办法
一查看现在time_wait的数量及浅析          netstat -an | grep TIME_WAIT | wc -l  发现系统存在大量TIME_WAIT状态的连接,通过调整内核参数解决,在 /etc/sysctl.conf中加入          net.ipv4.tcp_tw_recycle = 1    (表示开启TCP连接中TIME-WAIT
理解tcp关闭连接中的time_wait状态
首先看一下tcp关闭连接时的四次握手过程: 1.Client向Server发送FIN包,表示Client主动要关闭连接,然后进入FIN_WAIT_1状态,等待Server返回ACK包。此后Client不能再向Server发送数据,但能读取数据。 2.Server收到FIN包后向Client发送ACK包,然后进入CLOSE_WAIT状态,此后Server不能再读取数据,但可以
服务器端主动关闭连接, 产生的TIME_WAIT状态为什么会占用服务端大量端口?
1. 理解认为accep() 返回的socket_new, 其源端口和目的端口与 listen() 的socket 是一置的,accept() 返回并未占用服务器新的端口。 2. 如果服务器端主动关闭 socket_new, 产生的TIME_WAIT状态为什么会在服务器端占用除监听端口以外的其余端口,还是其实并没有占用? 3. 如果没有占用的话,为什么高并发的短连接生成的TIME_WAIT会导
TCP释放连接时为什么time_wait状态必须等待2MSL时间(阅读笔记)?
为什么上图中的A在TIME-WAIT状态必须等待2MSL时间呢? 第一,为了保证A发送的最后一个ACK报文能够到达B。这个ACK报文段有可能丢失,因而使处在LAST-ACK状态的B收不到对已发送的FIN+ACK报文段的确认。B会超时重传这个FIN+ACK报文段,而A就能在2MSL时间内收到这个重传的FIN+ACK报文段。如果A在TIME-WAIT状态不等待一段时间,而是在发送完ACK报文段后就立即
关于tcp中time_wait状态的4个问题
面试中time_wait是个常考的问题,tcp网络编程中最不容易理解的也是它的time_wait状态,这也说明了tcp/ip四次挥手中time_wait状态的重要性。 下面通过4个问题来描述它 问题1.time_wait状态是什么2.为什么会有time_wait状态3.哪一方会有time_wait状态4.如何避免time_wait状态占用资源1.time_wait状态是什么 简单来说:ti
TCP/IP TIME_WAIT状态原理(四次握手关闭连接原理)
TIME_WAIT状态原理 ---------------------------- 通信双方建立TCP连接后,主动关闭连接的一方就会进入TIME_WAIT状态。 客户端主动关闭连接时,会发送最后一个ack后,然后会进入TIME_WAIT状态,再停留2个MSL时间(后有MSL的解释),进入CLOSED状态。 下图是以客户端主动关闭连接为例,说明这一过程的。       TIME
socket:close_wait状态和time_wait状态问题
<br />不久前,我的Socket Client程序遇到了一个非常尴尬的错误。它本来应该在一个socket长连接上持续不断地向服务器发送数据,如果socket连接断开,那么程序会自动不断地重试建立连接。<br />有一天发现程序在不断尝试建立连接,但是总是失败。用netstat查看,这个程序竟然有上千个socket连接处于CLOSE_WAIT状态,以至于达到了上限,所以无法建立新的socket连接了。<br />为什么会这样呢?<br />它们为什么会都处在CLOSE_WAIT状态呢?<br />CLOS
TIME_WAIT状态与解决方法
执行主动关闭的那端经历了这个状态,并停留MSL(最长分节生命期)的2倍,即2MSL。 TIME_WAIT存在的两个理由: 1 可靠的实现TCP全双工连接的终止 2 允许老的重复的分节在网络上的消逝 第一个:如果客户端不维持TIME_WAIT状态,那么将响应给服务端一个RST,该分节被服务器解释成一个错误。如果TCP打算执行所有必要的工作以彻底终止某个连接上两个方向的数据流,那么必须正确的处
为什么TIME_WAIT状态还需要等2MSL才能返回CLOSED状态
(1)可靠的实现TCP全双工链接的终止。 这是因为虽然双方都同意关闭连接了,而且握手的4个报文也都协调和发送完毕,按理可以直接回到CLOSED状态(就好比从SYN_SEND状态到ESTABLISH状态那样);但是因为我们必须要假想网络是不可靠的,你无法保证你最后发送的ACK报文会一定被对方收到,因此对方处于LAST_ACK状态下的SOCKET可能会因为超时未收到ACK报文,而重发FIN报