TCP协议是TCP/IP栈中最复杂的协议,它最大的优点是传输的可靠性,这通过面向连接、按序传输、超时重传、流量控制等机制保证其传输的可靠性。但这并不是我们今天要讨论的重点!
TCP通信的过程分别是三个阶段:建立连接、传输数据、关闭连接。建立连接是通过三次握手完成,而关闭连接是通过四次挥手实现。这也不是我们要讨论的重点!
四次挥手的流程如下:
当其中一方在发送完自己的数据后,再没有数据需要通过TCP发送,可以发起关闭连接的请求,对方收到该请求后,首先回复ACK确认,待自己的数据发送完毕后,也会发起自己的关闭连接请求,进而完全断开TCP连接。
TCP建立和关闭连接的请求通常由客户端发起,服务器属于被动方,这是常见的TCP四次挥手的过程。但这不是我们今天要讨论的重点!
我们刚刚说了,这是常见的流程,但不是固定的流程。所有的协议在设计时有三种触发方式:调用接口主动触发、接收报文被动触发、定时器触发。这些触发方式合在为的是能保证协议在工作时的逻辑自洽。简单了说,就是要考虑到任何的可能,在任何一种可能的情况下都不能让协议崩溃。
而上面的TCP四次挥手的过程没有考虑到,如果TCP通信双方同时发起断开连接的请求怎么办?
很明显,作为设计最复杂的协议,TCP不可能不考虑到这一点:
但这还不是我们今天要讨论的重点!虽然TCP考虑到了这种情况,但我们从实际使用中思考,这种情况真的只是为了防止TCP通信双方同时发起断开连接的请求而设计的吗?
有没有可能是A应用层由于某些未知的错误,它需要把这个错误告诉对方B,同时发起断开连接的请求。对方B首先收到的是这个错误通知,这个错误通知触发了B发起断开连接的请求,然后才收到A的关闭连接的请求。
这种情况符合CLOSING的情况,但你能说是双方同时发起的吗?很明显是A发起,在请求没有到达B之前,触发B发起关闭连接的请求。这才是我们今天要讨论的重点!
那么大家在车载以太网中有遇到过这种情况吗?欢迎留言讨论!