详解下TCP的三次握手和四次挥手

1.三次握手建立连接

a.请求端(通常称为客户)发送一个SYN段指明客户打算连接的服务器的端口，以及初始序号(ISN,在这个例子中为1415531521)。这个SYN段为报文段1。

b.服务器发回包含服务器的初始序号的SYN报文段(报文段2)作为应答。同时，将确认序号设置为客户的ISN加1以对客户的SYN报文段进行确认。一个SYN将占用一个序号

c.客户必须将确认序号设置为服务器的ISN加1以对服务器的SYN报文段进行确认(报文段3)

这三个报文段完成连接的建立。这个过程也称为三次握手(three-way handshake)



用wirshark抓包如下:



可以看到三次握手确定了双方间包的序号、最大接受数据的大小(window)以及MSS(Maximum Segment Size)。

MSS = MTU - IP头 - TCP头,MTU表示最大传输单元，我们在IP头分析的时候会讲到,它一般为1500个字节。IP头和TCP 头部带可选选项的时候都是20个字节。这样的话MSS=1500 - 20 -20 = 1460。

MSS限制了TCP包携带数据的大小,它的意思就是当应用层向传输层提交数据通过TCP协议进行传输时，如果应用层的数据>MSS就必须分段，分成多个段，逐个的发过去。

例如:应用层一次性向传输层提交4096个字节数据，这个时候通过wirshark抓包效果如下:



前三次是三次握手的过程，后面三次是传送数据的过程，由于数据大小是4096个字节，所以用了三次进行传递(1448 + 1448 + 1200)。

细心的人会问为什么每次传送的最大数据大小不是1460个字节呢?因为这里的TCP携带可选项，TCP头长度 = 20 + 12（可选选项大小） = 32字节。 这样能传输的最大数据为:1500 - 20 - 32 = 1448个字节。

1.1 思考

咱们先把三次握手理解成这三个步骤 1.Client说“我这边想和你建立一个TCP链接，行么？” 2.Service端收到这个请求，说“嗯，好的，我收到你要连接请求了，我这边也准备好需要的资源，可以连接了”3.Client端说“嗯，我收到你的确认信息了，我也准备好需要的资源了，可以连接了”

那两次握手行不行？？不行！好，为什么尼？因为少了第三步，由于网络上存在着丢包性，正好把就是把第二个步骤 Service端给Client的确认信息丢掉了，那么Service端认为自己已经发送了，然后开始发送data数据包,但是Client端，却因为没有收到Service发来的第二步骤的信息，所以即使Service发送来Data数据包，也不会处理他，而是选择了丢弃。

就是因为没有了第三步骤的确认，所以导致了Client无法确认Service是不是准备好了，证明了三次握手的必要性。

那为什么不四次握手？？ 四次握手就显得有些多余了，相当于加了第四步：Service端说“我收到了Client的确认信息”。第二，三步已经完成了确认双方都已确认完毕了，再加一次也是多余的了。

2.四次挥手断开连接

a.现在的网络通信都是基于socket实现的，当客户端将自己的socket进行关闭时，内核协议栈会向服务器自动发送一个FIN置位的包，请求断开连接。我们称首先发起断开请求的一方称为主动断开方。

b.服务器端 (PS ：其实S端和C端都可以来断开这个连接，这里先举一个例子，两端断开连接其实一样) 收到请客端的FIN断开请求后，内核协议栈会立即发送一个ACK包作为应答，表示已经收到客户端的请求

c.服务器运行一段时间后，关闭了自己的socket。这个时候内核协议栈会向客户端发送一个FIN置位的包，请求断开连接

d.客户端收到服务端发来的FIN断开请求后，会发送一个ACK做出应答，表示已经收到服务端的请求



用wirshar抓包分析如下:



2.1思考

咱们先把四次握手理解成这四个步骤 1.Client说“我要断开这个连接啦” 2.Service端收到这个请求（PS：有可能当时服务器正在发送Data数据包,所以不可能立马回“嗯，好，可以断开连接啦”），说“嗯，好的，我收到你这个断开请求啦，我这边准备下”3.Service端解决完要发送的数据包说“嗯，我已经准备好了，可以断开连接了”Service关闭应用程序 4.Client端：“嗯，我收到你的确认信息了，我也要关闭啦”Client关闭应用程序

为什么要四次挥手，三次不行么？好吧，那还真不行，断开连接比新建连接多个在Client断开时，Service正好在发送数据包，那这时候Service不可能回“嗯，可以断开连接啦”。所以就是四次挥手啦