TCP报文段结构

三次握手，四次挥手 - 图1

三次握手

三次握手，四次挥手 - 图2
第一次和第二次是不可以携带数据的，但是第三次是可以携带数据的。

  1. 客户端发送一个SYN段，并指明客户端的初始序列号，即ISN(c).
  2. 服务端发送自己的SYN段作为应答，同样指明自己的ISN(s)。为了确认客户端的SYN，将ISN(c)+1作为ACK数值。这样，每发送一个SYN，序列号就会加1. 如果有丢失的情况，则会重传。
  3. 为了确认服务器端的SYN，客户端将ISN(s)+1作为返回的ACK数值。

第一次握手：客户端发送网络包，服务端收到了。这样服务端就能得出结论：客户端的发送能力、服务端的接收能力是正常的。
第二次握手：服务端发包，客户端收到了。这样客户端就能得出结论：服务端的接收、发送能力，客户端的接收、发送能力是正常的。 从客户端的视角来看，我接到了服务端发送过来的响应数据包，说明服务端接收到了我在第一次握手时发送的网络包，并且成功发送了响应数据包，这就说明，服务端的接收、发送能力正常。而另一方面，我收到了服务端的响应数据包，说明我第一次发送的网络包成功到达服务端，这样，我自己的发送和接收能力也是正常的。
第三次握手：客户端发包，服务端收到了。这样服务端就能得出结论：客户端的接收、发送能力，服务端的发送、接收能力是正常的。 第一、二次握手后，服务端并不知道客户端的接收能力以及自己的发送能力是否正常。而在第三次握手时，服务端收到了客户端对第二次握手作的回应。从服务端的角度，我在第二次握手时的响应数据发送出去了，客户端接收到了。所以，我的发送能力是正常的。而客户端的接收能力也是正常的。
经历了上面的三次握手过程，客户端和服务端都确认了自己的接收、发送能力是正常的。之后就可以正常通信了。

从上面的过程可以看到，最少是需要三次握手过程的。

为什么是三次握手？

两次无法保证客户端是否接受了数据，四次则降低了传输效率。

四次握手的过程

1.1 A 发送同步信号SYN + A’s Initial sequence number
1.2 B 确认收到A的同步信号，并记录 A’s ISN 到本地，命名 B’s ACK sequence number

1.3 B发送同步信号SYN + B’s Initial sequence number

1.4 A确认收到B的同步信号，并记录 B’s ISN 到本地，命名 A’s ACK sequence number
很显然1.2和1.3 这两个步骤可以合并，只需要三次握手，可以提高连接的速度与效率。**

二次握手的过程

2.1 A 发送同步信号SYN + A’s Initial sequence number
2.2 B发送同步信号SYN + B’s Initial sequence number + B’s ACK sequence number
这里有一个问题，A与B就A的初始序列号达成了一致，这里是1000。但是B无法知道A是否已经接收到自己的同步信号，如果这个同步信号丢失了，A和B就B的初始序列号将无法达成一致。

四次挥手

三次握手，四次挥手 - 图3

  1. 客户端发送一个FIN段，并包含一个希望接收者看到的自己当前的序列号K. 同时还包含一个ACK表示确认对方最近一次发过来的数据;
  2. 服务端发送一个ACK段，将K+1作为ACK序号值，表明收到了上一个包。这时上层的应用程序会被告知另一端发起了关闭操作，通常这将引起应用程序发起自己的关闭操作;
  3. 服务端发起自己的FIN段，ACK=K+1, Seq=L；
  4. 客户端确认，ACK=L+1。

第二次挥手还是能够传输数据的。

为什么是四次挥手？

因为服务器还有消息没发完，所以不能马上把FIN发过去。

服务器第一次收到来自客户端的fin信号的时候，可能还没有传输完所有的数据，只是先给客户端发送一个确认报文，告诉客户端自己收到了信号。然后继续把所有的数据发完，发完以后再发送fin信号关闭这一方向上的数据传输。

推荐阅读