标签:pre 建立连接 计算机 不同 状态 计算 读取 没有 多次
之前上过计算机网络这门课,由于当时初次接触计算机网络,其中的有些概念无法深入理解,只停留在表面。这次借着学网络编程的机会,也把TCP的三次握手和四次分手重新梳理了一遍,有了不同的理解。借此,想做一个总结。
在学习TCP三次握手和四次分手之前,首先得对TCP协议有一个大概的了解。TCP全称是传输控制协议,其是面向连接的,可靠的,基于字节流的传输层通信协议。相比与UDP(用户数据报协议)而言,具有以下几个特点:
三次握手的作用是为了解决网络中延迟的重复分组。引用谢希仁著《计算机网络》书中的一个例子:
“已失效的连接请求报文段”的产生在这样一种情况下:client发出的第一个连接请求报文段并没有丢失,而是在某个网络结点长时间的滞留了,以致延误到连接释放以后的某个时间才到达server。
本来这是一个早已失效的报文段。但server收到此失效的连接请求报文段后,就误认为是client再次发出的一个新的连接请求。于是就向client发出确认报文段,同意建立连接。假设不采用“三次握手”,
那么只要server发出确认,新的连接就建立了。由于现在client并没有发出建立连接的请求,因此不会理睬server的确认,也不会向server发送数据。但server却以为新的运输连接已经建立,
并一直等待client发来数据。这样,server的很多资源就白白浪费掉了。采用“三次握手”的办法可以防止上述现象发生。例如刚才那种情况,client不会向server的确认发出确认。server由于收不到确认,
就知道client并没有要求建立连接。”
当客户端调用close函数之后意味客户不再会有数据发送给服务端,服务端也不会接受额外的数据。但服务器端没有调用close函数之前,服务器端是可以再向客户端发送数据的,这称为半关闭。
一个应用进程发送FIN,除了程序自己主动调用close函数之外,如果进程自愿或者被动的终止时,所有打开的描述符都会被关闭,这也会导致TCP发送一个FIN。
放一张TCP状态转换图便于理解。
再放一张完整的TCP连接所发生的实际分组交换情况。
在上面的所有状态中,最值得我们注意的两个状态是CLOSE_WAIT状态和TIME_WAIT状态。
当服务端接收到客户端发来的FIN分节时,服务端的状态由ESTABLISHED转变为CLOSE_WAIT状态,并返回一个ACK分节确认,同时在服务端的接收缓冲区中添加一个文件结束符。此时客户端将不再给服务端发送数据,但服务端的缓冲区数据可能还没有被应用程序接收完,所以此时服务端的程序暂时还不能关闭。当服务端的程序将缓冲区的数据读取完时(遇到文件结束符),将给客户端发送一个FIN分节,服务端进入LAST_ACK状态。客户端接收到FIN,由FIN_WAIT状态进入到TIME_WAIT状态。
端点停留在TIME_WAIT状态的持续时间是最长分节生命期的两倍,即2MSL。
标签:pre 建立连接 计算机 不同 状态 计算 读取 没有 多次
原文地址:https://www.cnblogs.com/zrcsy/p/12355415.html