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