TCP-面向连接的传输层协议

浅浅的花香味﹌ 2022-12-26 10:19 203阅读 0赞

### TCP ###

*  主要特点
 *  工作方式
 *   *  建立连接---三次握手
     *  为什么 TCP 建立连接需要三次握手，而不是两次？
     *  连接终止---四次挥手
     *  为什么要四次挥手
     *  为什么要等待2MSL
 *  TCP流量控制
 *  TCP拥塞控制
 *   *  1.慢开始和拥塞避免
     *  2.快重传和快恢复

传输控制协议（TCP，Transmission Control Protocol）是一种 **面向连接**的、 **可靠的**、 **基于字节流**的 **传输层**通信协议。许多高层应用协议（包括HTTP、FTP）都是以它为基础的，TCP非常适合数据的连续传输。  
传输控制协议TCP是为了在 **不可靠的互联网络**上提供 **可靠**的端到端字节流而专门设计的一个传输协议。

# 主要特点 #

TCP是一种面向广域网的通信协议，目的是**在跨越多个网络通信**时，为两个通信端点之间提供一条具有下列特点的通信方式：

1.  **基于字节流**的方式；（流就是指不间断的数据结构）TCP不像UDP一样那样一个个报文独立地传输，而是在不保留报文边界的情况下以字节流方式进行传输。
2.  **面向连接**；面向连接，是指发送数据之前必须在两端建立连接。建立连接的方法是“三次握手”，这样能建立可靠的连接。建立连接，是为数据的可靠传输打下了基础。
3.  **可靠通信**方式；对于可靠传输，判断丢包，误码靠的是TCP的段编号以及确认号。TCP为了保证报文传输的可靠，就给每个包一个序号，同时序号也保证了传送到接收端实体的包的按序接收。然后接收端实体对已成功收到的字节发回一个相应的确认(ACK)；如果发送端实体在合理的往返时延(RTT)内未收到确认，那么对应的数据（假设丢失了）将会被重传。
4.  在网络状况不佳的时候尽量降低系统由于重传带来的带宽开销；当网络出现拥塞的时候，TCP能够减小向网络注入数据的速率和数量，缓解拥塞
5.  通信连接维护是面向通信的两个端点的，而不考虑中间网段和节点。TCP允许通信双方的应用程序在任何时候都能发送数据，因为TCP连接的两端都设有**缓存**，用来临时存放双向通信的数据。当然，TCP可以立即发送一个数据段，也可以缓存一段时间以便一次发送更多的数据段（最大的数据段大小取决于MSS）

TCP能够为应用程序提供可靠的通信连接，使一台计算机发出的字节流无差错地送达网络上的其他计算机。因此，对可靠性要求高的数据通信系统往往使用TCP传输数据，但在正式收发数据前，通信双方必须首先建立连接。

# 工作方式 #

## 建立连接—三次握手 ##

TCP是因特网中的传输层协议，使用**三次握手**协议建立连接。当主动方发出SYN连接请求后，等待对方回答SYN+ACK，并最终对对方的 SYN 执行 ACK 确认。这种建立连接的方法可以防止产生错误的连接，TCP使用的流量控制协议是可变大小的滑动窗口协议。  
![在这里插入图片描述][20201204164523610.gif_pic_center]

*  第一次握手  
    建立连接。客户端发送连接请求报文段，将SYN位置为1，Sequence Number为x；该报文段中包含自身的数据通讯初始序号。请求发送后，客户端便进入 SYN-SENT 状态。等待服务器的确认；
 *  第二次握手  
    服务端收到连接请求报文段后，如果同意连接，则会发送一个应答，该应答中也会包含自身的数据通讯初始序号，服务器收到客户端的SYN报文段，需要对这个SYN报文段进行确认，设置Acknowledgment Number为x+1(Sequence Number+1)；同时，自己自己还要发送SYN请求信息，将SYN位置为1，Sequence Number为y；服务器端将上述所有信息放到一个报文段（即SYN+ACK报文段）中，一并发送给客户端，
 *  第三次握手  
    当客户端收到连接同意的应答后，还要向服务端发送一个确认报文。将Acknowledgment Number设置为y+1，向服务器发送ACK报文段，客户端发完这个报文段后便进入 ESTABLISHED 状态，服务端收到这个应答后也进入 ESTABLISHED 状态，此时连接建立成功。

## 为什么 TCP 建立连接需要三次握手，而不是两次？ ##

这是因为这是为了防止出现**失效**的连接请求报文段被服务端接收的情况，从而产生错误。

> 三次握手的目的是“为了防止已经失效的连接请求报文段突然又传到服务端，因而产生错误”，这种情况是：一端(client)A发出去的第一个连接请求报文并没有丢失，而是因为某些未知的原因在某个网络节点上发生滞留，导致延迟到连接释放以后的某个时间才到达另一端(server)B。本来这是一个早已失效的报文段，但是B收到此失效的报文之后，会误认为是A再次发出的一个新的连接请求，于是B端就向A又发出确认报文，表示同意建立连接。如果不采用“三次握手”，那么只要B端发出确认报文就会认为新的连接已经建立了，但是A端并没有发出建立连接的请求，因此不会去向B端发送数据，B端没有收到数据就会一直等待，这样B端就会白白浪费掉很多资源。如果采用“三次握手”的话就不会出现这种情况，B端收到一个过时失效的报文段之后，向A端发出确认，此时A并没有要求建立连接，所以就不会向B端发送确认，这个时候B端也能够知道连接没有建立。

问题的核心在于**保证信道数据传输的可靠性，避免资源浪费**。  
![在这里插入图片描述][20201204165523787.gif_pic_center]

## 连接终止—四次挥手 ##

TCP 是**全双工**的，在断开连接时两端都需要发送 FIN 和 ACK。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2x1b2xhaWh1YTIwMTg_size_16_color_FFFFFF_t_70]

*  第一次挥手： 若主机A 认为数据发送完成，则它需要向 主机B 发送连接释放请求；主机A（可以使客户端，也可以是服务器端），设置Sequence Number，向主机B发送一个FIN报文段；此时，主机A进入FIN\_WAIT\_1状态；这**表示主机A没有数据要发送给主机B**了；
 *  第二次挥手： 主机B收到了主机A发送的FIN报文段，向主机A回一个ACK报文段，Acknowledgment Number为Sequence Number加1；主机A进入FIN\_WAIT\_2状态；**主机B告诉主机A，我“同意”你的关闭请求；** B进入 CLOSE\_WAIT 状态，此时表明 A 到 B 的连接已经释放，不再接收 A 发的数据了。但是因为 TCP 连接是双向的，所以 B 仍旧可以发送数据给 A。
 *  第三次挥手： B 如果此时还有没发完的数据会继续发送，完毕后会向 A 发送连接释放请求。主机B向主机A发送FIN报文段，请求关闭连接，同时主机B进入LAST\_ACK状态；
 *  第四次挥手： 主机A收到主机B发送的FIN报文段，向主机B发送ACK报文段，然后主机A进入TIME\_WAIT状态；主机B收到主机A的ACK报文段以后，就关闭连接；此时，主机1等待**2MSL**后依然没有收到回复，则证明Server端已正常关闭，那好，主机1也可以关闭连接了。

![在这里插入图片描述][20201204165816132.gif_pic_center]  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2x1b2xhaWh1YTIwMTg_size_16_color_FFFFFF_t_70_pic_center]

## 为什么要四次挥手 ##

TCP协议是一种面向连接的、可靠的、基于字节流的运输层通信协议。TCP是**全双工模式**，这就意味着，当主机1发出FIN报文段时，只是表示主机1已经没有数据要发送了，主机1告诉主机2，它的数据已经全部发送完毕了；但是，这个时候主机1还是可以接受来自主机2的数据；当主机2返回ACK报文段时，表示它已经知道主机1没有数据发送了，但是主机2还是可以发送数据到主机1的；当主机2也发送了FIN报文段时，这个时候就表示主机2也没有数据要发送了，就会告诉主机1，我也没有数据要发送了，之后彼此就会愉快的中断这次TCP连接。

## 为什么要等待2MSL ##

**MSL：报文段最大生存时间，它是任何报文段被丢弃前在网络内的最长时间。**  
原因有二：

1.  保证TCP协议的全双工连接能够可靠关闭
2.  保证这次连接的重复数据段从网络中消失

**第一点**：如果主机1直接CLOSED了，那么由于IP协议的不可靠性或者是其它网络原因，导致主机2没有收到主机1最后回复的ACK。那么主机2就会在超时之后继续发送FIN，此时由于主机1已经CLOSED了，就找不到与重发的FIN对应的连接。所以，主机1不是直接进入CLOSED，而是要保持TIME\_WAIT，当再次收到FIN的时候，能够保证对方收到ACK，最后正确的关闭连接。  
**第二点**：如果主机1直接CLOSED，然后又再向主机2发起一个新连接，我们不能保证这个新连接与刚关闭的连接的端口号是不同的。也就是说有可能新连接和老连接的端口号是相同的。一般来说不会发生什么问题，但是还是有特殊情况出现：假设新连接和已经关闭的老连接端口号是一样的，如果前一次连接的某些数据仍然滞留在网络中，这些延迟数据在建立新连接之后才到达主机2，由于新连接和老连接的端口号是一样的，TCP协议就认为那个延迟的数据是属于新连接的，这样就和真正的新连接的数据包发生混淆了。所以TCP连接还要在TIME\_WAIT状态等待2倍MSL，这样可以保证本次连接的所有数据都从网络中消失。

# TCP流量控制 #

如果发送方把数据发送得过快，接收方可能会来不及接收，这就会造成数据的丢失。所谓**流量控制就是让发送方的发送速率不要太快，要让接收方来得及接收。**  
利用**滑动窗口机制**可以很方便地在TCP连接上实现对发送方的流量控制。  
设A向B发送数据。在连接建立时，B告诉了A：“我的接收窗口是 rwnd = 400 ”(这里的 rwnd 表示 receiver window) 。因此，发送方的发送窗口不能超过接收方给出的接收窗口的数值。请注意，TCP的窗口单位是字节，不是报文段。假设每一个报文段为100字节长，而数据报文段序号的初始值设为1。大写ACK表示首部中的确认位ACK，小写ack表示确认字段的值ack。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2x1b2xhaWh1YTIwMTg_size_16_color_FFFFFF_t_70 1]  
从图中可以看出，B进行了三次流量控制。第一次把窗口减少到 rwnd = 300 ，第二次又减到了 rwnd = 100 ，最后减到 rwnd = 0 ，即不允许发送方再发送数据了。这种使发送方暂停发送的状态将持续到主机B重新发出一个新的窗口值为止。B向A发送的三个报文段都设置了 ACK = 1 ，只有在ACK=1时确认号字段才有意义。  
TCP为每一个连接设有一个持续计时器(persistence timer)。只要TCP连接的一方收到对方的零窗口通知，就启动持续计时器。若持续计时器设置的时间到期，就发送一个零窗口控测报文段（携1字节的数据），那么收到这个报文段的一方就重新设置持续计时器。

# TCP拥塞控制 #

## 1.慢开始和拥塞避免 ##

发送方维持一个拥塞窗口 cwnd ( congestion window )的状态变量。拥塞窗口的大小取决于网络的拥塞程度，并且动态地在变化。发送方让自己的发送窗口等于拥塞窗口。  
发送方控制拥塞窗口的原则是：只要网络没有出现拥塞，拥塞窗口就再增大一些，以便把更多的分组发送出去。但只要网络出现拥塞，拥塞窗口就减小一些，以减少注入到网络中的分组数。  
慢开始算法：  
当主机开始发送数据时，如果立即所大量数据字节注入到网络，那么就有可能引起网络拥塞，因为现在并不清楚网络的负荷情况。因此，较好的方法是 先探测一下，即由小到大逐渐增大发送窗口，也就是说，由小到大逐渐增大拥塞窗口数值。  
通常在刚刚开始发送报文段时，先把拥塞窗口 cwnd 设置为一个最大报文段MSS的数值。而在每收到一个对新的报文段的确认后，把拥塞窗口增加至多一个MSS的数值。用这样的方法逐步增大发送方的拥塞窗口 cwnd ，可以使分组注入到网络的速率更加合理。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2x1b2xhaWh1YTIwMTg_size_16_color_FFFFFF_t_70 2][]  
每经过一个传输轮次，拥塞窗口 cwnd 就加倍。一个传输轮次所经历的时间其实就是往返时间RTT。不过“传输轮次”更加强调：把拥塞窗口cwnd所允许发送的报文段都连续发送出去，并收到了对已发送的最后一个字节的确认。  
另，慢开始的“慢”并不是指cwnd的增长速率慢，而是指在TCP开始发送报文段时先设置cwnd=1，使得发送方在开始时只发送一个报文段（目的是试探一下网络的拥塞情况），然后再逐渐增大cwnd。  
为了防止拥塞窗口cwnd增长过大引起网络拥塞，还需要设置一个慢开始门限ssthresh状态变量。慢开始门限ssthresh的用法如下：

当 cwnd < ssthresh 时，使用上述的慢开始算法。  
当 cwnd > ssthresh 时，停止使用慢开始算法而改用拥塞避免算法。  
当 cwnd = ssthresh 时，既可使用慢开始算法，也可使用拥塞控制避免算法。  
拥塞避免  
让拥塞窗口cwnd缓慢地增大，即每经过一个往返时间RTT就把发送方的拥塞窗口cwnd加1，而不是加倍。这样拥塞窗口cwnd按线性规律缓慢增长，比慢开始算法的拥塞窗口增长速率缓慢得多。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2x1b2xhaWh1YTIwMTg_size_16_color_FFFFFF_t_70 3]

无论在慢开始阶段还是在拥塞避免阶段，只要发送方判断网络出现拥塞（其根据就是没有收到确认），就要把慢开始门限ssthresh设置为出现拥塞时的发送 方窗口值的一半（但不能小于2）。然后把拥塞窗口cwnd重新设置为1，执行慢开始算法。  
这样做的目的就是要迅速减少主机发送到网络中的分组数，使得发生 拥塞的路由器有足够时间把队列中积压的分组处理完毕。  
如下图，用具体数值说明了上述拥塞控制的过程。现在发送窗口的大小和拥塞窗口一样大。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2x1b2xhaWh1YTIwMTg_size_16_color_FFFFFF_t_70 4]

## 2.快重传和快恢复 ##

**快重传**  
快重传算法首先要求接收方每收到一个失序的报文段后就立即发出重复确认（为的是使发送方及早知道有报文段没有到达对方）而不要等到自己发送数据时才进行捎带确认。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2x1b2xhaWh1YTIwMTg_size_16_color_FFFFFF_t_70 5]  
接收方收到了M1和M2后都分别发出了确认。现在假定接收方没有收到M3但接着收到了M4。  
显然，接收方不能确认M4，因为M4是收到的失序报文段。根据 可靠传输原理，接收方可以什么都不做，也可以在适当时机发送一次对M2的确认。  
但按照快重传算法的规定，接收方应及时发送对M2的重复确认，这样做可以让 发送方及早知道报文段M3没有到达接收方。发送方接着发送了M5和M6。接收方收到这两个报文后，也还要再次发出对M2的重复确认。这样，发送方共收到了 接收方的四个对M2的确认，其中后三个都是重复确认。  
快重传算法还规定，**发送方只要一连收到三个重复确认就应当立即重传对方尚未收到的报文段M3，而不必 继续等待M3设置的重传计时器到期。**  
由于发送方尽早重传未被确认的报文段，因此采用快重传后可以使整个网络吞吐量提高约20%。

**快恢复**  
与快重传配合使用的还有快恢复算法，其过程有以下两个要点：

当发送方连续收到三个重复确认，就执行“乘法减小”算法，把慢开始门限ssthresh减半。  
与慢开始不同之处是现在不执行慢开始算法（即拥塞窗口cwnd现在不设置为1），而是把cwnd值设置为 慢开始门限ssthresh减半后的数值，然后开始执行拥塞避免算法（“加法增大”），使拥塞窗口缓慢地线性增大。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2x1b2xhaWh1YTIwMTg_size_16_color_FFFFFF_t_70 6]

<table> 
 <thead> 
  <tr> 
   <th>性能</th> 
   <th>UDP</th> 
   <th>TCP</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>是否连接</td> 
   <td>无连接</td> 
   <td>面向连接</td> 
  </tr> 
  <tr> 
   <td>是否可靠</td> 
   <td>不可靠传输，不使用流量控制和拥塞控制</td> 
   <td>可靠传输，使用流量控制和拥塞控制</td> 
  </tr> 
  <tr> 
   <td>连接对象个数</td> 
   <td>支持一对一，一对多，多对一和多对多交互通信</td> 
   <td>只能是一对一通信</td> 
  </tr> 
  <tr> 
   <td>传输方式</td> 
   <td>面向报文</td> 
   <td>面向字节流</td> 
  </tr> 
  <tr> 
   <td>首部开销</td> 
   <td>首部开销小，仅8字节</td> 
   <td>首部最小20字节，最大60字节</td> 
  </tr> 
  <tr> 
   <td>适用场景</td> 
   <td>适用于实时应用（IP电话、视频会议、直播等）</td> 
   <td>适用于要求可靠传输的应用，例如文件传输</td> 
  </tr> 
 </tbody> 
</table>

参考链接: [关于 TCP/IP，必知必会的十个问题][TCP_IP].

[20201204164523610.gif_pic_center]: /images/20221120/fa8c2d45611e4f22a6c6d6b2fdb5f6ec.png
[20201204165523787.gif_pic_center]: /images/20221120/eaf1afa249ea48edb6845371ee62799b.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2x1b2xhaWh1YTIwMTg_size_16_color_FFFFFF_t_70]: /images/20221120/0845cae9950d472ab58e07c3d4cb9ddd.png
[20201204165816132.gif_pic_center]: /images/20221120/b173eb92394d4a909630b99fe8193631.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2x1b2xhaWh1YTIwMTg_size_16_color_FFFFFF_t_70_pic_center]: /images/20221120/386757a44fa441d89e9fe7ef36580498.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2x1b2xhaWh1YTIwMTg_size_16_color_FFFFFF_t_70 1]: /images/20221120/4d907e2ceee846c7b46bdec2261b9a73.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2x1b2xhaWh1YTIwMTg_size_16_color_FFFFFF_t_70 2]: /images/20221120/a569025dacec48ed8b598a60077c0dc8.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2x1b2xhaWh1YTIwMTg_size_16_color_FFFFFF_t_70 3]: /images/20221120/24da7299d7574f798629d270a3cdede3.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2x1b2xhaWh1YTIwMTg_size_16_color_FFFFFF_t_70 4]: /images/20221120/411dc05cc90a4d89a08f26290ca5b4f8.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2x1b2xhaWh1YTIwMTg_size_16_color_FFFFFF_t_70 5]: /images/20221120/83c45a660e064badb24d0d3de7a772ae.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2x1b2xhaWh1YTIwMTg_size_16_color_FFFFFF_t_70 6]: /images/20221120/461bb6d249c140499ad4b02735115561.png
[TCP_IP]: https://juejin.cn/post/6844903490595061767#heading-10