TCP三次握手TCP三次握手过程假设有发送端计算机和接收端计算机，纵轴为时间轴。第一次握手假设发送方先与接收方建立连接，所以，发送方会第一次发送消息（此时SYN=1，表示这是一个连接请求消息，seq=x是串口同步发送方自身的编号）第二次握手的接收方收到连接请求后，打开TCP连接，同时也会发送消息，这就是第二次握手。报文信息包括：SYN=1：表示连接请求ACK=1：表示序号确认ack=x+1：小写ack表示确认序号。这里的ack=x+1表示接收方期望收到序号x+1的值seq=y：同时接收方发送的报文也会携带自己的序号，即seq=yth三次握手的发送端收到消息后，会进行响应。响应中的消息内容：ACK=1：表示这条消息的确认号有效。seq=x+1：发送方携带的序号，表示发送方当前发送的数据序号为x+1ack=y+1：确认号为y+1，表示发送方期望通过这3次握手，从接收端收到序号为y+1的数据，TCP连接就建立了。三次握手中的关键信息有第一次和第二次握手的SYN标记，表示这是一次连接请求。第二次和第三次握手都有确认标记。对于ack标记，其实是先同步连接双方的序号。比如通过两次ack同步，发送方已经知道接收方的ack是什么，同时接收方也知道发送方的ack是什么。通过三次握手，他们不仅建立了连接，还同步了他们的序号。在三次握手的时间轴中，接收方和发送方在不同的时间有不同的状态。接收方在接收到数据之前，一直处于监听状态（Listen）。发送方在第一个消息发出后，收到对第一个消息的响应，属于同步发送状态（SYNC-SENT），表示SYN已经发出，对方的SYN信息正在等待接收方的第一次发送。一条消息，在收到第二条消息之间，属于同步接收状态（SYNC-RCVD），表示发送端发给我的SYN消息已经收到，接下来发送端会进入连接建立（ESTABLISHED）状态发送方，只要第二次握手成功，发送方就会建立连接。但对于接收方来说，只有在收到发送方的第三次握手后，连接才建立（ESTABLISHED）。双方建立连接状态的时间不同，就变成建立连接的状态。但是对于接收方来说，只有在收到发送方的第三次握手后，连接才会建立。双方进入建立连接状态后，即可进行数据传输。为什么发件人要发送第三条确认消息？为什么不两次？结论：避免向对方发送无效的连接请求报文，造成此时有发送端计算机和接收端计算机的错误假设。首先，发送方需要发送请求消息建立连接（第一次握手）。假设第一个握手消息在到达接收方之前已经在网络中传输了很长时间。因为发了很久，发件人也很久没有收到了。给接收者的确认消息。发送方会认为第一条消息超时，所以发送方会第二次发送同样的消息。假设第二次发送的消息很快就会到达对方，接收方在收到第二条消息后会发送同样的消息。在第二次连接请求消息后，它会响应并建立它们之间的连接。那么对于发送方发送的第一个请求报文，应该是一个无效的请求报文，因为它的功能已经被第二个连接请求完成了。所以，对于第一次发送的请求连接报文，在网络中徘徊了很久之后，其实是一条无效的请求报文，没有任何作用。如果在发送方发送的两次连接请求中都建立了连接会怎样？？首先考虑第二个请求的消息。此消息提前到达接收方，接收方将对其进行响应。响应被确认后，连接就建立了（因为我们假设连接是在两次握手后建立的。）现在考虑第一次发送的连接请求。如果两次握手后建立了连接，那么对于无效的请求也会建立连接，因为只要接收方有响应，就意味着连接已经建立。这样就会导致，同一个请求如果发送两次，就会建立两个TCP连接。这种情况是错误的，所以双向握手是不正确的。三次握手如何解决二次握手带来的问题呢？对于双向握手来说，只要接收方有响应，就意味着连接建立。对于三次握手来说，第一个确认报文会先到达发送方，然后发送方再发送一个确认报文（第三次握手），此时连接就建立了。接收方的连接请求报文，接收方也会向发送方发送一条确认报文用于此报文（第二次握手）。但是，发送方已经进行了第三次握手，因此发送方将忽略第二次确认消息，不会进行任何操作。这样第一次缓慢到达的连接请求不会建立连接，避免了两次握手造成的错误。接收方电脑，纵轴为时间轴。当连接正常时，双方始终可以进行数据传输。假设数据传输完成，此时会释放TCP连接。假设发送方主动释放连接并第一次挥手。发件人发送了第一波消息。报文内容：FIN=1：该标志表示需要释放连接seq=u：将自己的序列号同步给接收方此时发送方进入第一个等待状态（FIN-WAIT-1）连接结束。第二次挥手后，接收方收到发送方的断开连接请求后，会发送消息确认。,以确认我已收到对方发给我的序列号。确认报文内容为：ACK=1：表示这条报文已经确认seq=v：同步自己的序列号ack=u+1：确认号为u+1，表示接收方期望收到数据其序号为u+1。发送方收到确认报文后，进入连接结束的第二次等待状态（FIN-WAIT-2）。接收方发送完第一个确认消息后，进入关闭等待状态（CLOSE-WAIT）。此时接收方仍然可以发送数据，因为释放连接的请求是由发送方发起的，说明发送方的数据发送完成，但接收方可能还没有发送完第三次挥手。接收方发送第一条确认消息后，将发送一条新消息。此消息将携带FIN=1。mark，表示也可以释放连接，里面会带一个ack，表示对发送方发送的序列号进行反复确认。报文的完整内容：FIN=1：这个标志表示需要释放连接。是一个释放连接的请求ACK=1：表示收到确认报文seq=w：同步序号给发送方ack=u+1：确认号为u+1，表示接收方期待接收和发送方的序列号是u+1的数据。第四次挥手后，发送方在收到接收方的确认信息后，会再次发送确认信息，确认我已经收到了接收方发送的信息。这个时候就可以放出来了。当连接断开时，接收方在接收方发送断开连接请求和接收方收到发送方的确认消息之间处于最终确认状态（LAST-ACK）。确认发送方已收到连接释放消息。此时发送方进入等待定时器状态（TIME-WAIT）。发送方会在这个时间等待状态等待一段时间，确保这段时间没有问题，然后进入关闭状态（CLOSE）。以上就是四次挥手的过程
