面试题：TCP和UDP 相关

悠悠 2022-11-26 01:40 106阅读 0赞

### 目录 ###

*   *   *   *  1. UDP和TCP分别指的是什么？
             *  2. TCP通过哪些方式来保证可靠性？
             *  3. TCP和UDP的区别是什么？
             *  4. TCP和UDP的使用场景
             *  5. TCP协议为什么更安全，更可靠？
             *  6. UDP协议为什么不可靠？
             *  7. TCP的重传机制是什么？
             *  8. TCP的拥塞控制机制是什么？
             *  9. TCP的流量控制机制是什么？
             *  10. TCP的三次握手和四次挥手

#### 1. UDP和TCP分别指的是什么？ ####

*  **UDP：** 全称是用户数据报协议，在网络中它与TCP协议一样用于处理数据包，是一种无连接的协议。在OSI模型中，在传输层，处于IP协议的上一层。UDP有不提供数据包分组、组装和不能对数据包进行排序的缺点，也就是说，当报文发送之后，是无法得知其是否安全完整到达的；
 *  **TCP：** 全称是传输控制协议是一种面向连接的、可靠的、基于字节流的传输层通信协议。TCP 是面向连接的、可靠的流协议。流就是指不间断的数据结构。

#### 2. TCP通过哪些方式来保证可靠性？ ####

*  应用数据被分割成TCP认为最适合发送的数据块
 *  确认机制，发送报文后，等待确认
 *  重发机制，没有收到确认，将重发数据报
 *  保持它的首部和数据校验，确认数据的准确性
 *  排序，将重复数据丢掉，进行流量控制

#### 3. TCP和UDP的区别是什么？ ####

<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>

#### 4. TCP和UDP的使用场景 ####

**TCP应用场景：** 效率要求相对低，但对准确性要求相对高的场景。因为传输中需要对数据确认、重发、排序等操作，相比之下效率没有UDP高。例如：文件传输（准确高要求高、但是速度可以相对慢）、接受邮件、远程登录。

**UDP应用场景：** 效率要求相对高，对准确性要求相对低的场景。例如：QQ聊天、在线视频、网络语音电话（即时通讯，速度要求高，但是出现偶尔断续不是太大问题，并且此处完全不可以使用重发机制）、广播通信（广播、多播）。

#### 5. TCP协议为什么更安全，更可靠？ ####

*  **确认和重传机制**：建立连接时三次握手同步双方的“序列号 + 确认号 + 窗口大小信息”，是确认重传、流控的基础。传输过程中，如果Checksum校验失败、丢包或延时，发送端重传
 *  **数据排序**：TCP有专门的序列号SN字段，可提供数据re-order
 *  **流量控制**：窗口和计时器的使用。TCP窗口中会指明双方能够发送接收的最大数据量
 *  **拥塞控制**

#### 6. UDP协议为什么不可靠？ ####

UDP在传输数据之前不需要先建立连接，远地主机的运输层在接收到UDP报文后，不需要确认，提供不可靠交付。总结就以下四点：

*  不保证消息交付：不确认，不重传，无超时
 *  不保证交付顺序：不设置包序号，不重排，不会发生队首阻塞
 *  不跟踪连接状态： 不必建立连接或重启状态机
 *  不进行拥塞控制： 不内置客户端或网络反馈机制

#### 7. TCP的重传机制是什么？ ####

由于TCP的下层网络（网络层）可能出现**丢失、重复或失序**的情况，TCP协议提供可靠数据传输服务。为保证数据传输的正确性，TCP会重传其认为已丢失（包括报文中的比特错误）的包。TCP使用两套独立的机制来完成重传，一是**基于时间**，二是**基于确认信息**。

TCP在发送一个数据之后，就开启一个定时器，若是在这个时间内没有收到发送数据的ACK确认报文，则对该报文进行重传，在达到一定次数还没有成功时放弃并发送一个复位信号。

#### 8. TCP的拥塞控制机制是什么？ ####

TCP的拥塞控制机制主要是以下四种机制：

*  慢启动（慢开始）
 *  拥塞避免
 *  快速重传
 *  快速恢复

**（1）慢启动（慢开始）**

*  在开始发送的时候设置cwnd = 1（cwnd指的是拥塞窗口）
 *  思路：开始的时候不要发送大量数据，而是先测试一下网络的拥塞程度，由小到大增加拥塞窗口的大小。
 *  为了防止cwnd增长过大引起网络拥塞，设置一个慢开始门限(ssthresh 状态变量)
    
     *  当cnwd < ssthresh，使用慢开始算法
     *  当cnwd = ssthresh，既可使用慢开始算法，也可以使用拥塞避免算法
     *  当cnwd > ssthresh，使用拥塞避免算法

**（2）拥塞避免**

*  拥塞避免未必能够完全避免拥塞，是说在拥塞避免阶段将拥塞窗口控制为按线性增长，使网络不容易出现阻塞。
 *  思路： 让拥塞窗口cwnd缓慢的增大，即每经过一个返回时间RTT就把发送方的拥塞控制窗口加一
 *  无论是在慢开始阶段还是在拥塞避免阶段，只要发送方判断网络出现拥塞，就把慢开始门限设置为出现拥塞时的发送窗口大小的一半。然后把拥塞窗口设置为1，执行慢开始算法。如图所示:  
    ![在这里插入图片描述][20200802172257514.png]  
    其中，判断网络出现拥塞的根据就是没有收到确认，虽然没有收到确认可能是其他原因的分组丢失，但是因为无法判定，所以都当做拥塞来处理。

**（3）快速重传**

*  快重传要求接收方在收到一个失序的报文段后就立即发出重复确认(为的是使发送方及早知道有报文段没有到达对方)。快重传算法规定，发送方只要连续收到三个重复确认就立即重传对方尚未收到的报文段，而不必继续等待设置的重传计时器时间到期。
 *  由于不需要等待设置的重传计时器到期，能尽早重传未被确认的报文段，能提高整个网络的吞吐量

**（4） 快速恢复**

*  当发送方连续收到三个重复确认时，就执行“乘法减小”算法，把ssthresh门限减半。但是接下去并不执行慢开始算法。
 *  考虑到如果网络出现拥塞的话就不会收到好几个重复的确认，所以发送方现在认为网络可能没有出现拥塞。所以此时不执行慢开始算法，而是将cwnd设置为ssthresh的大小，然后执行拥塞避免算法。  
    ![在这里插入图片描述][2020080217284188.png]

#### 9. TCP的流量控制机制是什么？ ####

一般来说，流量控制就是为了让发送方发送数据的速度不要太快，要让接收方来得及接收。

TCP采用大小可变的**滑动窗口**进行流量控制，窗口大小的单位是字节。这里说的窗口大小其实就是每次传输几个数据。

*  当一个连接建立时，连接的每一端分配一个缓冲区来保存输入的数据，并将缓冲区的大小发送给另一端。
 *  当数据到达时，接收方发送确认，其中包含了自己剩余的缓冲区大小。（剩余的缓冲区空间的大小被称为窗口，指出窗口大小的通知称为窗口通告 。接收方在发送的每一确认中都含有一个窗口通告。）
 *  如果接收方应用程序读数据的速度能够与数据到达的速度一样快，接收方将在每一确认中发送一个正的窗口通告。
 *  如果发送方操作的速度快于接收方，接收到的数据最终将充满接收方的缓冲区，导致接收方通告一个零窗口 。发送方收到一个零窗口通告时，必须停止发送，直到接收方重新通告一个正的窗口。

#### 10. TCP的三次握手和四次挥手 ####

**三次握手**

*  第一次握手：客户端发送一个SYN码给服务器，要求建立数据连接；
 *  第二次握手：服务器SYN和自己处理一个SYN （标志）；叫SYN+ACK （确认包）；发送给客户端，可以建立连接
 *  第三次握手：客户端再次发送ACK向服务器，服务器验证ACK没有问题，则建立起连接；

**四次挥手**

*  第一次挥手：客户端发送FIN（结束）报文，通知服务器数据已经传输完毕；
 *  第二次挥手:服务器接收到之后，通知客户端收到了SYN，发送ACK（确认）给客户端，数据还没有传输完成
 *  第三次挥手：服务器已经传输完毕，再次发送FIN通知客户端，数据已经传输完毕
 *  第四次挥手：客户端再次发送ACK，进入TIME\_WAIT状态；服务器和客户端关闭连接；

[20200802172257514.png]: /images/20221124/4f9478d0234a4749b4512080cd744df3.png?
[2020080217284188.png]: /images/20221124/ea6d0a1482014938914bc0219bdc1606.png?