TCP建立连接概述及三次握手、四次挥手的流程

连 接 概 述

顺着第一篇的思路下来，到最后我们已经可以依靠分层达到两台主机之间的自由通信，那么问题来了，假设现在有主机A（客户端）及主机B（服务端），其中主机A需要访问主机B的资源，需要哪几个必要条件呢？经过上篇文章可知至少需要四个条件：

• 主机A需要具有一个ip地址
• 主机B需要具有一个ip地址
• 主机A需要具有一个客户端端口号
• 主机B需要具有一个服务端端口号

具备上述四个条件后A获取B的信息是有要求的，根本上的要求是数据信道可靠，就是平时所说的可靠连接，那么如何保证连接的可靠性呢，TCP协议就是靠确认应答机制、超时重传机制等保证连接可靠性的，接下来就通过TCP协议的三次握手及四次（三次）挥手来分析一下A与B建立连接、关闭连接的技术细节是如何落地实现的。

三 次 握 手

第一次： 首先客户端A会向服务端B发送一个数据同步请求，可以称为建立连接请求syn，同时客户端A 的cpu内核会为这个syn请求生成一个随机的序列号seq发送给服务端。此处整体称为第一次握手，注意此处为随机序列号。

第二次： 服务端B接到客户端A发送的syn请求后，会回复一个[syn+ack]的响应，其中syn仍表达数据同步的意思，这个应答seq值由服务端B的cpu随机生成，ack的值为第一次握手seq的值+1，ack表示两层含义：

• 服务端B已经收到了客户端A发过来的数据同步请求
• 希望客户端接下来的应答消息的seq的值以ack回复的值开始传输。

这个称为第二次握手。

第三次： 客户端A接收到服务端B的[syn+ack]应答消息会给B回复一个ack应答，ack消息中seq值为第二次握手ack的值，而ack则为第二次握手的请求的seq值+1。

三次握手通信释义图如上所示，接下来我们来通过抓包的形式来看一下实际报文，印证三次握手的报文通信。

笔者通过wireshark（抓包工具）抓取数据包，采用打开一个浏览器网页的场景模拟对服务器B的请求。

第一次握手抓包图如下：

第二次握手抓包释义图如下：

第三次握手抓包释义图如下：

通过三次握手的抓包可以很清晰的展示三次交互流程，可能有人会有连带的疑问，为什么一定是三次，而不是别的次数，这里三次其实是最优的次数，而不是一定的次数，比如如果两次的话A、B两方将会有一方无法做出信息是否送达的确认，而超过三次则造成了浪费，因为三次交互中A、B都已经对两方应答一次了。接下来来看一下四次挥手的交互流程。

四 次 挥 手

理解三次握手及流程后，四次挥手其实本质和三次握手的确认流程基本上是一样的，下面我们简单梳理一下挥手标准流程。

第一次： 当A确认当前连接数据已经全部发送完成以后，会发起关闭连接请求，此时A不再发送业务报文，发送的请求标志为FIN ,seq为x,此处整体为第一次挥手。

第二次： B收到A发出的关闭连接的请求之后，会给A一个确认响应，告诉A我收到你关闭连接的请求了，但是我有可能还有没发完的数据需要继续给你发送，响应的标志为ack,seq为Y，ack为x+1，此处整体为第二次挥手。

第三次： 当B把数据传输完之后会发送释放连接响应，此处标志B释放连接，不会再发送业务报文，此时请求的标志为FIN+ack，seq的值为y，ack的值为x+1,此处整体为第三次挥手。

第四次： A对B第三次挥手做最后确认，并释放连接，此时请求标志为ack，seq为x+1,ack为y+1。

四次挥手通信释义图如上所示，由于三次握手的每一次都通过抓包工具详细描述了通信详情，此处挥手抓一个整体包截图，由读者自行解析分析即可。

四次挥手抓包整体释义图如下：

可以看到，这里面的挥手包数与咱们分析的标准流程不一样，这里是因为第二次和第三次挥手都是B向A发起确认响应，区别是第二次只是确认，因为可能还有数据没有传完，要继续传，全部数据传完后B才能发出最后指令进行释放连接，但这时如果发第二次挥手的时候就可以确认没有数据需要再同步给A了，这时如果按照标准流程，B会给A发送两个相同的数据包，这样就造成了资源浪费，故这块挥手做了优化，可以确认数据的情况下，可以把第二次和第三次挥手合并成一次，所以此处是三次握手。