加载中...

关闭时状态转变:

client:   Fin_wait_1 -> Fin_wait_2 -> Time_wait -> closed

server: Close_wait -> Last_ack -> closed

Fin_wait_1 发生在client 发出Fin包后, 并等待server 回 ack 时.

Fin_wait_2 发生在client收到ack包后, 并等待server发出Fin包时.

Time_wait 发生在client收到Fin包并发出ack包后, 在等待2msl的时间时.

Close_wait 发生在server收到client的fin包并且发出ack包后以及自己主动关闭发出fin包前.

Last_ack发生在server发出fin包后, 并等待client回ack时.

经常出现的状态组合:

client: fin_wait_2;  server: close_wait
原因: 当client close了,但是server忘记close的时候, 即server在收到client的fin后并没有发送fin包给client, 导致自己处于close_wait状态, 而client在等待server的fin包,处于fin_wait_2状态.

 client:time_wait; server: closed
原因: 当client, server都close了, client必须处于time_wait状态等待2msl时间. 于是如果server是处于高并发短连接的状态, 就会有大量的time_wait的连接霸占着. 使得其他的连接连接不了.

解决方法: 用linger强制关闭可以解决此问题(用rst代替fin)，但是linger会导致数据丢失，linger值为0时是强制关闭,无论并发多少多能正常连接上,如果非0会发生部分连接不上的情况!（可调用setsockopt设置套接字的linger延时标志，同时将延时时间设置为0。）
TCP/IP的RFC文档。TIME_WAIT是TCP连接断开时必定会出现的状态。
是无法避免掉的，这是TCP协议实现的一部分。
在WINDOWS下，可以修改注册表让这个时间变短一些
time_wait的时间为2msl,默认为4min.
你可以通过改变这个变量:
TcpTimedWaitDelay
把它缩短到30s

PS: Linux 查看 tcp 状态的命令 netstat -an | grep portnumber

Linux close()和shutdown()的区别.

    Linux的版本是kernel-2.6.21：
    1，只要TCP栈的读缓冲里更有未读取（read）数据，则调用close时会直接向对端发送RST。
    2，shutdown和socket描述符没有关系，即使调用shutdown(fd, SHUT_RDWR)也不会关闭fd，最终还需close(fd)。
    3，能认为shutdown(fd, SHUT_RD)是空操作，因为shutdown后还能继续从该socket读取数据，这点也许还需要进一步证实。
    4，在已发送FIN包后write该socket描述符会引发EPIPE/SIGPIPE。
    5，当有多个socket描述符指向同一socket对象时，调用close时首先会递减该对象的引用计数，计数为0时才会发送FIN包结束TCP连接。shutdown不同，只要以SHUT_WR/SHUT_RDWR方式调用即发送FIN包。
    6，SO_LINGER和close，当SO_LINGER选项开启但超时值为0时，调用close直接发送RST（这样能避免进入TIME_WAIT状态，但破坏了TCP协议的正常工作方式），SO_LINGER对shutdown无影响。
    7，TCP连接上出现RST和随后可能的TIME_WAIT状态没有直接关系，主动发FIN包方必然会进入TIME_WAIT状态，除非不发送FIN而直接以发送RST结束连接。

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/daeees/archive/2010/07/07/5719285.aspx