Tcp 断开连接
2013-08-14 15:53
183 查看
TCP协议规定,对于已经建立的连接,网络双方要进行四次握手才能成功断开连接,如果缺少了其中某个步骤,将会使连接处于假死状态,连接本身占用的资源不会被释放。网络服务器程序要同时管理大量连接,所以很有必要保证无用连接完全断开,否则大量僵死的连接会浪费许多服务器资源。在众多TCP状态中,最值得注意的状态有两个:CLOSE_WAIT,TIME_WAIT。
1、LISTENING状态
FTP服务启动后首先处于侦听(LISTENING)状态。
2、ESTABLISHED状态
ESTABLISHED的意思是建立连接。表示两台机器正在通信。
3、CLOSE_WAIT
对方主动关闭连接或者网络异常导致连接中断,这时我方的状态会变成CLOSE_WAIT 此时我方要调用close()来使得连接正确关闭
4、TIME_WAIT
我方主动调用close()断开连接,收到对方确认后状态变为TIME_WAIT。TCP协议规定TIME_WAIT状态会一直持续2MSL(即两倍的分段最大生存期),以此来确保旧的连接状态不会对新连接产生影响。处于TIME_WAIT状态的连接占用的资源不会被内核释放,所以作为服务器,在可能的情况下,尽量不要主动断开连接,以减少TIME_WAIT状态造成的资源浪费。目前有一种避免TIME_WAIT资源浪费的方法,就是关闭socket的LINGER选项。但这种做法是TCP协议不推荐使用的,在某些情况下这个操作可能会带来错误。
TCP连接关闭的几种方式:
1、“正常”关闭:调用close()关闭socket、没close但进程正常结束(当然这是不应该的做法)、进程core掉、在shell命令行中kill掉进程,都可抽象成“正常”关闭。因为即使core掉,内核也会马上帮应用程序回收(close)socket文件描述符。
“正常”关闭,默认情况下(非默认即设置Linger下面会介绍),关闭端即客户端TCP层会发FIN包,对端即服务器TCP层收到后,回ACK,客户端进入FIN_WAIT2状态。此时,TCP终止连接的4个分组中服务器应该发的第3个分组FIN包,其TCP层是不会主动发的,只有服务器端socket“正常”关闭,才会发出这个FIN包。至此,客户端进入TIME_WAIT状态。
2、“非”正常关闭:客户端崩溃了,此时肯定发不出FIN包了(当然啦,内核都没机会帮应用程序回收资源了)。这种情况,服务器端有如下两种情况:
A、服务器send数据,因为客户端已经崩溃,服务器收不到ACK自然会不停的重传。源自
Berkeley的重传机制,重传8次,相对第一次传的15分钟后仍没收到ACK,则返回
ETIMEDOUT或EHOSTUNREAC错误。如果服务器不理会这个错误,再次调用send,则
立马返回Broken Pipe错误。
注:15分钟超时可以在 /proc/sys/net/ipv4/tcp_retries2 中修改
B、 服务器不发任何数据了,那只有靠应用层心跳检测机制或Keepalive,来发觉TCP断连了。
1、LISTENING状态
FTP服务启动后首先处于侦听(LISTENING)状态。
2、ESTABLISHED状态
ESTABLISHED的意思是建立连接。表示两台机器正在通信。
3、CLOSE_WAIT
对方主动关闭连接或者网络异常导致连接中断,这时我方的状态会变成CLOSE_WAIT 此时我方要调用close()来使得连接正确关闭
4、TIME_WAIT
我方主动调用close()断开连接,收到对方确认后状态变为TIME_WAIT。TCP协议规定TIME_WAIT状态会一直持续2MSL(即两倍的分段最大生存期),以此来确保旧的连接状态不会对新连接产生影响。处于TIME_WAIT状态的连接占用的资源不会被内核释放,所以作为服务器,在可能的情况下,尽量不要主动断开连接,以减少TIME_WAIT状态造成的资源浪费。目前有一种避免TIME_WAIT资源浪费的方法,就是关闭socket的LINGER选项。但这种做法是TCP协议不推荐使用的,在某些情况下这个操作可能会带来错误。
TCP连接关闭的几种方式:
1、“正常”关闭:调用close()关闭socket、没close但进程正常结束(当然这是不应该的做法)、进程core掉、在shell命令行中kill掉进程,都可抽象成“正常”关闭。因为即使core掉,内核也会马上帮应用程序回收(close)socket文件描述符。
“正常”关闭,默认情况下(非默认即设置Linger下面会介绍),关闭端即客户端TCP层会发FIN包,对端即服务器TCP层收到后,回ACK,客户端进入FIN_WAIT2状态。此时,TCP终止连接的4个分组中服务器应该发的第3个分组FIN包,其TCP层是不会主动发的,只有服务器端socket“正常”关闭,才会发出这个FIN包。至此,客户端进入TIME_WAIT状态。
2、“非”正常关闭:客户端崩溃了,此时肯定发不出FIN包了(当然啦,内核都没机会帮应用程序回收资源了)。这种情况,服务器端有如下两种情况:
A、服务器send数据,因为客户端已经崩溃,服务器收不到ACK自然会不停的重传。源自
Berkeley的重传机制,重传8次,相对第一次传的15分钟后仍没收到ACK,则返回
ETIMEDOUT或EHOSTUNREAC错误。如果服务器不理会这个错误,再次调用send,则
立马返回Broken Pipe错误。
注:15分钟超时可以在 /proc/sys/net/ipv4/tcp_retries2 中修改
B、 服务器不发任何数据了,那只有靠应用层心跳检测机制或Keepalive,来发觉TCP断连了。
相关文章推荐
- winpcap发送数据包模拟TCP连接和断开的7次握手
- 【转】TCP3次握手连接协议和4次握手断开连接协议
- Tcp服务端判断客户端是否断开连接
- TCP客户端断开连接后,服务器连接处于CLOSE_WAIT状态之解决办法
- linux网络编程之TCP/IP基础(四):TCP连接的建立和断开、滑动窗口
- tcp 服务端如何判断客户端断开连接
- 为什么TCP连接的建立是需要三次,而断开却需要四次
- TCP建立连接和断开连接流程
- TCP连接与断开
- TCP需要三次握手才能建立,而断开连接则需要四次握手
- 用select检测对方断开tcp连接
- 从mysql 连接断开到tcp 包原理分析
- 断开某tcp连接
- tcp断开连接,4次握手,为什么wireshark 只能抓到3个包?
- 检查非正常断开的tcp连接
- TCP建立连接时三次握手,断开时为何4次握手
- esp8266 作为 tcp server,客户端连接后再断开,这样反反复复多次,第6次就再也连不上了
- 一次tcp连接及断开的抓包
- TCP断开连接_legend050709
- linux内核中tcp连接的断开处理