白话整理TCP协议

阳光穿透心脏的1/2处 2024-04-18 14:18 12阅读 0赞

### 文章目录 ###

*  前言
 *  工欲善其事，必先利其器
 *   *  协议分层模型
     *  每层报文叫法
     *  传输层
 *  TCP协议概述
 *   *  主要特点
     *  首部
     *   *  固定首部
         *  MSS
 *  TCP可靠性保证的一些方式
 *   *  数据流分块传输
     *   *  报文段最大长度
         *  滑动窗口
     *  报文正确性校验
     *  超时重传
     *  其它方式
 *  TCP的延迟确认和Nagle算法
 *   *  延迟确认
     *  Nagle算法
 *  TCP传输控制
 *   *  流量控制
     *   *  实现
         *  糊涂窗口综合症
     *  拥塞控制
     *   *  慢启动
         *  拥塞避免
         *  快重传与快恢复
 *  TCP连接建立与终止
 *   *  3次握手
     *  4次挥手
 *  参考资料

# 前言 #

标题为什么说是白话？  
本来想整理一篇比较专业点的TCP协议相关的文章，思来想去，发现自己表达能力差，术语用的不专业，词汇匮乏，文字组织排版也差强人意。想想还是算了，就用俗一点的语言文字说明吧，想到哪写到哪，写一篇关于TCP协议内容的文章。  
***下面的内容主要是我以往的学习、经验理解以及掌握的一些知识的提炼和想法的表述，所以仅供参考，毕竟不都是从专业资料中摘抄过来的。***

# 工欲善其事，必先利其器 #

在开始TCP协议之前，先把一些基础知识点准备好。省的说明TCP协议的时候，弄的云里雾里的。

## 协议分层模型 ##

协议体系结构主要有两种：1. OSI七层体系模型，2. TCP/IP的四层体系模型

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3g3NjM3OTUxNTE_size_16_color_FFFFFF_t_70]  
**p.s. 学习嘛，就用第3个（最右边那个协议体系结构模型）进行说明。**

## 每层报文叫法 ##

每一层传输的报文都是有自己专业一点的叫法：

1.  应用层  
    这个就不瞎说了，像我在工作中，发http请求的时候，天天叫请求报文、响应报文啥的，我也没个啥正经叫法。
2.  传输层  
    在OSI的术语中，它叫做运输协议数据单元（TPDU）；  
    but，平常还是以TCP/IP协议体系多吧，在这里，它是这样叫的：TCP协议叫报文段，记住是段；UDP协议叫用户数据报，记住是数据报，所以UDP叫用户数据报协议。  
    为什么叫法上有区别，后面会给解释。
3.  网络层  
    数据报，如IP数据报。。。
4.  数据链路层  
    帧，数据帧，以太网数据帧，这个叫帧！！！
5.  物理层  
    TCP/IP的4层协议中物理层和数据链路层可都是划到网络接口层的，不是应该也叫帧？再说了，物理层，物理层，都到硬件了，我也够不到，我没事我叫它干哈。

## 传输层 ##

传输层属于面向通信的最高层，用户功能的最低层；主要用来进程间的端到端通信，像网络层（如IP协议）是主机之间的通信。  
既然是主机的进程间端到端通信，那么说来传输层只有主机的协议栈才有（像我们的电脑、手机），路由器是工作在网络层，那就只有网络层及以下的协议处理能力了，而交换机是在链路层工作就是更不用说了。  
TCP是进程间端到端的通信，也就是说一条TCP连接需要两个端点。这个端点可不是端口号，端口号是为了解决*与操作系统无关*的进程标志方案，也叫协议端口号。而端点指的是socket(ip:port)（不是开发用的socket API那个socket），所以TCP唯一连接是被两端的socket确定，因此像我们平常开发用的socket API就是在这一层。  
传输层有2个主要协议，也是我们经常听到的：TCP和UDP，我们本文谈论的重点就是TCP。

# TCP协议概述 #

TCP协议，中文名传输控制协议，English name is Transmission Control Protocol.

## 主要特点 ##

*  面向连接  
    TCP在传送数据前有一个建立连接的过程，传送完毕要释放连接。就像平常打电话一样，要先拨通号码，通完话最后挂断电话。  
    UDP在通信的时候不需要先建立连接，是无连接的。而TCP是无论哪一方要发送数据都要先在双方之间建立连接。
 *  可靠  
    TCP连接传送的数据，无差错、不丢失、不重复、有序。
 *  全双工通信  
    通信的双方在任何时候可以发送数据，不存在一方发送数据的时候，另一方等待接收完毕才能继续发送（这就成半双工通信）。
 *  面向字节流  
    TCP是分块传输的，传输的是二进制字节流，所以TCP有个发送和接收的缓冲区大小，我们平常在开发过程中调用接口，都允许设置读写buffer的size，TCP协议本身不关心传输的内容。而UDP不是，UDP传送的是数据报文，应用层给的报文是啥，不管多大都会一股脑传送过去，这样的问题容易出现在哪呢？  
    第一个是如果传送报文过大，提供方怎么接收，不同的系统可能有不同的实现，有的会丢弃超过大小的部分，有的是可以持续读取，直到尾部。  
    第二个是不论怎样，在IP层都要进行分片，超过准备发往接口的MTU（最大传输单元），就必须分片。TCP会尽量避免分片，但是UDP很容易导致分片，一个网络接口的MTU默认值一般是1500个字节（这个值可不算多大再减去IP首部20个字节（不包括IP首部可选长度），TCP20个或UDP部8个，剩下的数据报最多就1472个了(TCP可能就是1460)，多1个字节都要分片，分片的时候传输过程中丢了1片还要重传，所以尽量避免IP分片），本地环回的能达到最大值65535，比如用ifconfig命令看下：  
    这里再顺便提下为什么TCP叫报文段，而UDP叫用户数据报，大家都是传输层，叫法却有区别？你看呀，TCP的一个应用层报文可能是一段一段传输，面向字节流的二进制协议，而UDP是把应用层报文直接打包带走，传输方式上这点就不一样，所以存在叫法上的区别也就合理了（纯属个人见解），至于为什么这样叫，应该查阅相关历史资料。  
    **p.s. MTU指的链路帧的帧长，注意不包括帧首部和帧尾部。帧的首部和尾部是为了帧定界。MTU一般是1500字节，指的帧的数据部分（比如如果上层是IP协议，就是整个IP数据报的长度）。我也忘了在哪见的说1500是一个数据帧的长度，这应该不对，再比如加上帧首部14字节，尾部4字节，实际可能一个帧长1518字节。*如果我理解有误，请及时留言指正，谢谢。***

## 首部 ##

### 固定首部 ###

TCP固定首部是20个字节（可变的部分算了），1个字节8位，所以也就是一共160bit，下面用图展示下：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3g3NjM3OTUxNTE_size_16_color_FFFFFF_t_70 1]  
下面对6个控制位主要说明下：

1.  URG(紧急)  
    URG置1的时候，紧急指针字段有效（首部中的紧急指针字段）。如果URG为0，则数据按序发送，接收方也按序接收的放入缓存。但是URG置为1，代表这个数据优级级比较高，也就是说可以插队，于是发送的时候，发送方会把紧急数据放在当前报文段的最前面，这个报文段中紧急数据后面才是普通数据（还按普通方式处理），那这个紧急数据有多长呢，这就是紧急指针的作用了，它指出了紧急数据的偏移。
2.  ACK(确认)  
    TCP规定：连接建立后的所有报文段的传送ACK置1
3.  PSH(推送)  
    接收方收到PSH置1的报文，会尽快将报文交付应用进程，而不是等到缓存满了再交付。
4.  RST(复位)  
    当连接出现严重差错的时候，服务端返回报文段中RST置1。比如，服务端未监听某个端口，而客户端向这个端口请求建立连接的时候。
5.  SYN(同步)  
    SYN置1，表示这是一个连接请求或连接接受报文；如，SYN=1而ACK=0说明这是一个请求建立连接的报文段，如果对端同意建立连接，响应报文段中SYN=1并且ACK=1。在3次握手的时候可以看到。
6.  FIN(终止)  
    当FIN置1的时候表示发送端完成发送，请求释放连接。4次挥手的时候可以看到。

### MSS ###

最长报文段长度，这个在选项部分，MSS指定了一个报文段的长度，这个长度指的是数据长度（不包含TCP首部的长度，而不是整个TCP报文段的长度，即MSS=MTU-（IP首部+TCP首部））。  
这个值应当在避免IP分片的情况下尽可能大，过小的话带宽利用率过低，因为仅仅是IP首部+TCP首部最少40字节，如果太小的话基本全是在传输这些首部了（用户数据每次就几个字啥）。太大了容易导致IP分片，两个路由器间不停的分片重装，丢1片还要重发，影响效率，所以还要避免IP分片。  
默认值是536字节（我是看到计算机网络-谢希仁版是说的这个默认值）。

# TCP可靠性保证的一些方式 #

## 数据流分块传输 ##

TCP和UDP的一个很大不同是，UDP是整个用户报文一股脑的一次性全部交付到IP层，IP层封装好后向下发出去；而TCP的报文段是分成一个一个大小合适的块，一点一点的向下交付到IP层发出去的。至于这个块里的内容，是二进制流呀还是ascii什么的，它不关心。  
TCP这个分块传输的策略呢，叫做滑动窗口->以字节为单位的滑动窗口（注意不是bit）。

### 报文段最大长度 ###

这个分块，谁来决定最大块长度是多少呢？这个就是由MSS来决定的，上文解释了MSS是什么。  
MSS就是当请求建立连接的时候，告诉对方，我能接受的最大报文段长度是多少，就像彼此在协商一样，协商好了以后，就做出决定对方的这个MSS的上限值是多少多少，每次传输报文段我不能比它大。因此，它也只能出现在syn报文段中。  
如下：  
![在这里插入图片描述][20190925231814647.png]  
wireshark抓的一个包的截图。MSS是1460,我的无线网卡的MTU是1500。减去IP首部和TCP首部就是这个值了。  
说了报文段的长度上限，接下来聊聊滑动窗口。

### 滑动窗口 ###

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3g3NjM3OTUxNTE_size_16_color_FFFFFF_t_70 2]  
抓了个很完整的数据传输的图（包括3次握手和4次挥手，然后在这里出现没用）。注意图中标红框的win字段，别误会，这个不是当前发送方的滑动窗口，而是告知对端我能接收的缓存就这么大，对端会设置滑动窗口大小为这个值。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3g3NjM3OTUxNTE_size_16_color_FFFFFF_t_70 3]  
要发送一段数据流，滑动窗口大概就是上面这个样子，当然了实际中序号一般是比这个大的多了，窗口大小一般也比这个大，不会像图中这么随意。  
窗口右侧边界是前沿只能往前移，也就是图中的右移，我还是说左右比较方便，就说左移（收缩），右移（前移）。  
在后沿左侧的是都被发送成功且已经收到确认序号的，在前沿右侧的，是不允许发送的。  
窗口越大能连续发送的数据越多。另外，滑动窗口只是发送缓存的一部分，不代表是整个发送缓存的大小。  
p1-p2之间的部分是已经发送但还没收到确认，如果收到确认后沿就会向前移（右移），p2-p3是允许发送还未发送的。  
看见收缩那有个x么，TCP标准中前沿是不允许后移，但是有的实现可能会对这种问题出现时进行处理。  
滑动窗口的大小不是一直固定的，比如发送方一直在发送数据，并且都正确的收到的ack，导致后沿一直前移，最终与前沿一样大小了，这时候发送方的滑动窗口为0了，是不会再发数据了。当然了，对端可能会突然来个窗口变更的ack，告知win的大小为2048了等，发送端就会把自己的窗口大小调整为2048发送新的数据。  
每次数据传输的时候，对端也都会根据自己的接收缓存大小在ack中设置不同的win大小。  
如果p1-p2之间发送到对端的时候有几个报文段丢失了，或者乱序了，当然了对端可能不知道丢失了，比如只是已经收到3的报文段，该收4的时候，5到来了，并不知道4是丢失了还是晚点到，此时会缓存5的报文段（放到接收缓存），等待4的到来，或者发送端超时重传4的报文段。  
简单说几句好了，真要细说，能说好多了。

## 报文正确性校验 ##

TCP首部有个2字节的检验和字段，校验TCP首部和数据的部分。用来检测端到端传输过程中数据没有差错。如果接收方计算检验和有差错，就丢弃这个报文段并不确认接收。

## 超时重传 ##

TCP每个连接，都管理的有4个定时器。其中一个定时器就是重传定时器，负责超时重传工作的。  
简单点说，就是有个定时器，记录一个报文段的发送时间，收到确认的时候，再用确认时间计算出这个报文段的往返时间RTT。  
但这个超时重传时间和RTT的算法可不是一句话能说明白，感兴趣的需要查找相关资料了解下了。下面抓个包，给个例子看下什么是重传，但是抓包中这个重传的时间只当前TCP计算出来的重传时间，不要以为实际重传时间就这样：  
![在这里插入图片描述][20190929231615477.png]  
我用的windows的telnet，报文进行了两次重试之后，便连接失败了。第一次重试发生在3s后，第二次发生在6s后，其实第三次会在12s后，每次重试时间是之间的2倍，直到不再重试时，再根据TCP的超时计算的算法计算下次的超时重传时间。

## 其它方式 ##

如流量控制、报文重排序、丢掉重复报文等都算是可靠性保证，这些内容在前面或后面的说明都有涉及，不在此处展开。

# TCP的延迟确认和Nagle算法 #

TCP发送方发送数据的时候，如果数据大小每次只有1个字节，那每次发送的大小为IP首部20字节加上TCP首部20字节再加上1个字节数据共41字节。如果在带宽不宽裕的情况下发送这些微小分组，效率很低下。  
下面是两种提高效率的方法：

## 延迟确认 ##

前面提到了TCP的可靠性，每次发送的报文都会有确认返回。而，延迟确认就是确认不会立即返回，而是等待接收方下次发送信息的时候把这个确认给捎上（也叫捎带确认），这里存在一个时延，在这个时延内也可能还会收到几个报文段，如果达到时延上限接收方没有发送报文的意思，也会单独发送这个ACK。  
所以抓包的时候，可能看到这种情况，发送端连着发送了几个报文段，却只看到接收方返回了一个ack，不用惊讶，正常现象。

## Nagle算法 ##

发送方会把要发送的数据逐字节存入缓存，然后把第一个字节发出去，当收到确认后，再把这段时间缓存的数据发出去，再收到确认后，再把又缓存的数据发出去…循环往复。。。  
该算法要求， 同一个TCP连接上最多只能有一个未被确认的报文段。这样就避免了来一个字节发一个来一个字节就发一个这种尴尬情况，而是我攒一点发送一次。  
另外，Nagle算法还规定，当到达的数据达到发送窗口的一半或者是一个报文段的最大长度就立即发送。

# TCP传输控制 #

TCP的传输控制主要体现在两个方面：**流量控制和拥塞控制**。  
两者的区别：流量控制是对发送端进行控制，报文的发送频率等方面控制；拥塞控制是对网络传输资源的控制。  
换句话说就是，流量控制的工作是在接收方的接收能力范围内控制发送方的发送速度，让接收方不要发送太快，这个时候我们假定网络上的带宽是足够的，不会成为流量传输的瓶颈，主要问题在于接收方的接收处理能力和发送方的发送能力；而，拥塞控制的工作是控制网络上传输的流量对于传输资源的使用，比如带宽，此时假定接收方的接收能力足够，发送方的发送能力也不是问题。  
如果上面那句话还没说明白，那就再比方说：**流量控制，是指端到端的通信量控制**，比如接收方每秒接收1M的包，多了就要丢包，那发送方每秒发送的流量就不要大于1M；而**拥塞控制防止过多的数据注入到网络中，避免网络中的路由器或链路等超负荷**，这是一个**全局性**的过程，毕竟每个发送端都有可能占用相同的网络资源，如果网络只允许传输1m/s的流量，这些发送端就应该避免每秒传输的总量超过1M。大概就是这第个意思。  
**慢启动、快重传、快恢复、拥塞避免都只是拥塞控制的一些算法。**

## 流量控制 ##

### 实现 ###

流量控制就是在接收方的接收能力范围内，控制发送方发送的数据量。发送方怎么知道当前能发送的数据量大小呢？就是前面滑动窗口中的win字段。  
比如接收方窗口大小为8192（8\*1024），发送方连续发送4个1024字节报文段，此时接收方收到数据后还在接收缓存未交付给上层，返回一个对第二个报文段的确认，此时ack中的win字段大小为6144（8192-2\*1024）的大小：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3g3NjM3OTUxNTE_size_16_color_FFFFFF_t_70 4]

### 糊涂窗口综合症 ###

接收方缓存满足了，每次ack的时候窗口大小只有1个字节，然后发送方每次就只发送1个字节，这就是糊涂窗口综合症：即因为接收方的窗口大小，每次只能发送少量数据在这个连接上进行交换，而不是一个满长度报文段。  
接收方解决方法：接收方不要每个ack立即发出并通告可接收的窗口大小，而是等待一段时间，当可以容纳一个满长度报文段或者接收缓存已有一半的空闲空间的时候，再发送ACK并且通告窗口大小。

## 拥塞控制 ##

在某一时间点，对某一网络资源需求超过网络资源所能提供的可用部分（如带宽、交换结点的缓存、处理能力等），网络性能下降，就是拥塞。即网络超负荷了。  
发送方是怎么判断网络上可能出现拥塞了？丢包、重传了，网络状况不良好，发送方判断可能是网络开始超负荷了，这时候会采用一些措施来避免拥塞。  
下面是避免拥塞的几种算法。

### 慢启动 ###

也叫慢开始算法。  
这个算法可以这样比喻，一开始发送1个报文段，然后是2、4、8、16…这种指数级增长，这个慢指的是一开始发送1个报文段的“慢”，并不是增长速率的慢， 这个增长速率还是很快的。  
但是为什么要这样“慢开始”，解释下：  
首先，要提一下网络的容量，有一个专用名词：带宽时延乘积。字面意就是带宽乘以发送端到接收端的时延，就是一个时间点这个网络的容量。就像一个水管，某个时间点能装的水量->即这个水管的容积与水管的半径和这段水管的长度有关（底面积乘高呗）。  
如果这个网络一次只能装下16个报文段，发送方向网络注入流量的时候一下注入32个报文段，超负荷了，不就开始拥塞了。  
还有，报文在传输过程中，每一段的网络能提供的资源是不尽相同的。就像平常把几要水管连接起来，如果管理粗细都一样还好说，如果其中即有粗水管又有细水管，那瓶颈就在细水管的地方，即使一开始用的粗水管到了细水管部分能流过去的水也就那么点。就像我们平常工作是在内网，网络资源很好一次能传送32个报文段，当流量走到广域网上的时候，就不会像局域网一样，可能一次只能容纳16个报文段了，  
![在这里插入图片描述][20191008232853228.png]  
慢开始算法的作用就体现在这里，先发1个探测下，收到确认没问题，然后就2个，收到2个确认没问题，就4个…  
这里发送方需要维护1个拥塞窗口（cwnd）变量，就是上面的1、2、4、8…这些值。cwnd的值取决于网络的拥塞程度，所以一直在动态变化。

> 发送方让自己的发送窗口等于拥塞窗口

cwnd的值 是1、2、4…指数增长是通过发送的报文段收到的确认之后 ，觉得网络状况良好才递增的，这个增加计算不是针对每个报文段的确认计算，而是一个传输轮次。一个传输轮次指的是cwnd允许发送的报文段全部连续发送出去并收到最后一个报文段的确认才算。比如第1次发送cwnd=1，允许发送1个报文段，收到确认后，这一轮传输结束，下一轮发送2个（上一轮每收到1个报文段的确认，本轮便增加一个报文段的发送，上一次发了1个也只收到1个，这一轮增加1个即2个）。然后这轮连续发送2个报文段收到本轮最后1个报文段的确认后，这一轮结束，因为这轮发了2个，自然是收到了2个，那下1轮增加2个就是允许发送4个。之后 8、16、32…等增加的原理就是这样。  
另外，注意这里用的1、2个报文段只是打个比喻，可能有的迷惑上面不是说过延迟确认什么的，如果我只对最后1个报文段确认，前面的没有发送确认怎么说。还能怎么说，这个问题就是风马牛不相及。TCP发送一个字节也要确认，这里用报文段指的是长度，增加的窗口长度。我这一次发送1个MSS字节，收到最后1个字节确认后，下一轮再增加1个MSS的长度呗（不是真的对报文段的确认，只是打比方）。  
那什么时候涨停，这就是接下来的拥塞避免了。

### 拥塞避免 ###

资源总是有限的，如果上面慢开始无限增长下去，肯定会出现拥塞，为了防止cwnd增长过大引起拥塞，这里还需要一个变量：慢开始门限ssthresh，就是慢开始增长的阈值。

*  当cwnd < ssthresh，使用慢开始算法；
 *  当cwnd > ssthresh，使用拥塞避免算法；
 *  当cwnd = ssthresh，既可使用慢开始算法也可使用拥塞避免算法。  
    拥塞避免算法每1个传输轮次增加1个报文段，线性增长的，慢开始是指数增长。至于拥塞避免增加1个报文段是最终计算出来的，过程是这样的（打比方）：  
    cwnd=n，即1个传输轮次允许发送n个报文段，每收到1个报文段确认，cwnd便增加1/n个报文段的长度，这样一个传输轮次结束，增加了个1/n\*n=1个报文段的大小。  
    不管是在慢开始阶段还是在使用拥塞避免算法时，如果发生拥塞（超时重传了），就把ssthresh的值设置为此时cwnd的一半（最少为2个报文段），cwnd值变为1重新执行慢开始算法。这就是所谓的**乘法减小加法增大**。

### 快重传与快恢复 ###

发送方发送了1、2、3、4、5、6，共6个报文段，接收方收到 1、2报文段便发送报文段2的确认后收到了报文段4没有收到报文段3，此时接收方正常情况下可以什么也不做，也可以延迟捎带发送一1上报文段2的重复确认。但是现在接收方立即发送了报文段2的重复确认并且随后收到报文段5、6的时候也立即发送了报文段2的重复确认。  
此时一共发送了报文段2的4个确认，包括3个重复确认，发送方发现收到了3个重复确认赶紧再发送一次报文段2，而不是等超时了再重传报文段2，这就是快重传（**一连收到3个重复确认，迟早重传**）。  
快重传之后开始快恢复（也可以慢开始，看当前版本用的哪个喽）  
说下快恢复：  
我目前见到的快恢复算法描述有两个版本：

1.  3次重复确认后，ssthresh减半即ssthresh=1/2ssthresh;cwnd=ssthresh（cwnd也是原来门限的一半大小了）。然后不执行慢启动，直接采用拥塞避免算法，因为收到了3个重复确认，说明接收方又收到了3个报文段，拥塞并不是那么糟糕（包全丢了收不到这种），网络还可以，没必要慢开始。
2.  这是另一个版本：收到3个重复确认，重传报文段后，ssthresh=1/2cwnd（是cwnd的一半）；cwnd=ssthresh+3个报文段。cwnd的值反而大了，这是因为收到了3个重复确认，说明已经有3个报文段被接收方收到了（这3个已经不在网络里占资源了），之后每收到一个重复ack，就发一个报文段并且cwnd的值增加1个报文段（收到1个重复ack，就是接收方又收到了一个报文段，同样网络资源也释放了1个报文段），直到收到最后1个确认新数据的ack(不是重复ack)，设置cwnd=ssthresh，拥塞避免。

# TCP连接建立与终止 #

建立连接需要3次握手，终止就是4次挥手，关于3次握手、4次挥手这个都比较熟悉。  
下面这个截图是我用telnet建立连接并关闭，然后抓包可以看到握手、挥手的过程：  
![在这里插入图片描述][2019100923383245.png]  
上面红框是建立连接，下面是telnet连接上的时候，我输入q退出关闭连接抓的包。

## 3次握手 ##

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3g3NjM3OTUxNTE_size_16_color_FFFFFF_t_70 5]  
握手过程大概就是这样，需要注意的是请求连接的前两个报文段：SYN、SYN,ACK，都不允许携带数据但是都需要消耗1个序号。第3个ACK可以携带报文，在所有不携带报文的ACK中都不需要1个消耗序号。可以看上面抓包的那个截图：  
![在这里插入图片描述][20191010000026950.png]  
ACK报文段seq=1，再发1个FIN报文段的时候，seq还是1，说明没有消耗序号。  
说明下3次握手过程：

1.  客户端向服务器发送1个SYN报文段请求建立连接（包含客户端的初始序号）
2.  服务器发会1个SYN报文段（包含客户端的初始序号），并对客户端的SYN确认ACK
3.  客户端返回ACK确认连接建立

p.s. 关于其中序号的初始化选择，建议查阅相关资料了解  
至于为什么是3次握手而不是两次，也是为了避免一些意外发生，如失效报文段。假如2次握手，没有最后一次确认，建立连接的时候出现这种情况，客户端发送FIN报文段请求建立连接，结果FIN报文段丢了超时重传了一个新的FIN，服务器收到了回了个FIN+ACK，连接建立然后发送数据，发送完毕释放连接。结果 ，实际这个旧的FIN并未丢只是阻塞传了慢了些，这个时候晃晃悠悠到服务器这里了，服务器以为客户端又要连接回复了个FIN+ACK建立连接等待客户端重传数据，这就尴尬了。

## 4次挥手 ##

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3g3NjM3OTUxNTE_size_16_color_FFFFFF_t_70 6]

1.  客户端向服务器发送FIN报文段请求释放连接，然后客户端进入FIN-WATI1状态
2.  服务器返回ACK确认客户端连接释放，服务器进入CLOSE-WAIT状态，客户端进入FIN-WAIT2状态。此时只是单向关闭，仅关闭了客户端到服务器的连接，客户端不会再向服务器发送数据，但是客户端还可以接收数据，服务器也可以向客户端发送数据
3.  服务器向客户端发送FIN,ACK，服务器进入LAST-ACK状态，正常情况下服务器的这个状态很快会消失连接最终释放
4.  客户端返回ACK，然后进入TIME-WAIT状态。

客户端在TIME-WAIT时，连接还未释放。在这个状态的等待时间是2MSL（2个最长报文段寿命），我以前在win10测过，1个MSL是30s，即1分钟后这些连接就释放了。有时候开的连接太多，在客户端使用netstat能看到一堆TIME-WAIT。  
至于为什么TIME-WAIT等待这么久，1个原因是万一最后1个客户端的ACK丢失了，服务器重发FIN+ACK，客户端重新确认，这样可以让服务器正确进入CLOSED状态，其实像nginx、tomcat这些服务器，对于失效连接在等一会后始终没收到客户端的ACK，都会自已释放这个连接的。另一等待这么久的原因，让网络上这个连接的报文段都已经消失了，这样下一个新连接不会出现这个旧连接的报文。

# 参考资料 #

《计算机网络》（第6版-谢希仁版）  
《TCP/IP详解》（巻1）

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3g3NjM3OTUxNTE_size_16_color_FFFFFF_t_70]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/90416d5d02de4af28867f1be17db7026.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3g3NjM3OTUxNTE_size_16_color_FFFFFF_t_70 1]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/a313507cee694ddebf8fb64b9411bef0.png
[20190925231814647.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/a3d077bd18dc41a481c15329a955745d.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3g3NjM3OTUxNTE_size_16_color_FFFFFF_t_70 2]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/4b3740d1918648c3b595ae050f98a9a3.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3g3NjM3OTUxNTE_size_16_color_FFFFFF_t_70 3]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/375f5e59b10446ac93f84b9d7bb60c7d.png
[20190929231615477.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/7d3634188ca044ffa2811c5d883d7ca7.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3g3NjM3OTUxNTE_size_16_color_FFFFFF_t_70 4]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/a1aebd31e14540b48a9f58089490e6bf.png
[20191008232853228.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/5fc77e958f4b4a1f9cb501be912c16f6.png
[2019100923383245.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/9d3bce39990741faba7a68b085743636.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3g3NjM3OTUxNTE_size_16_color_FFFFFF_t_70 5]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/51c6d847480040e888010498bcc444d5.png
[20191010000026950.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/8f3b32da582d41a784ec21bdc4e56813.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3g3NjM3OTUxNTE_size_16_color_FFFFFF_t_70 6]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/61e90790787d4862972faab5575b410c.png