【计算机网络】TCP原理 | 可靠性机制分析（一）

灰太狼 2024-04-27 07:13 37阅读 0赞

> 个人主页：[兜里有颗棉花糖][Link 1]  
> 欢迎 点赞? 收藏✨ 留言✉ 加关注?本文由 [兜里有颗棉花糖][Link 1] 原创  
> 收录于专栏【[网络编程][Link 2]】【[Java系列][Java]】  
> 本专栏旨在分享学习网络编程、计算机网络的一点学习心得，欢迎大家在评论区交流讨论?

#### 目录 ####

*  一、UDP协议
 *   *  UDP协议特性
     *  UDP协议端格式
 *  二、TCP协议
 *   *  TCP协议头格式
 *  三、TCP协议可靠性分析
 *   *  确认应答机制
     *  超时重传机制

## 一、UDP协议 ##

### UDP协议特性 ###

*  **无连接：知道对端的IP和端口号就可以直接进行传输，不需要进行连接。**
 *  **不可靠：发送端发送数据报以后，如果因为网络故障该段无法发到对方，UDP协议层也不会给应用层返回任何错误信息。**
 *  **面向数据报：应用层交给UDP多长的报文，UDP原样发送，既不会拆分，也不会合并（比如发送端一次性接收100个字节，那么接收端也必须一次性接收100个字节）。**

### UDP协议端格式 ###

UDP协议端格式即UDP协议报文格式。

![在这里插入图片描述][859d1470000d4a738094a27fda19c803.png]

![在这里插入图片描述][e3567a3b4d884881aeca044a7a50585d.png]

*  **UDP的校验和如何实现：是通过CRC校验算法来进行实现的，即将数据报中的每个字节进行累加，传输数据的时候将数据和校验和一并发送出去；接收方接收到的校验和我们视为旧校验和，而接收方受到的数据将每个字节累加后得到的结构视为新的校验和。当数据相同时，校验和一定相同；校验和不同时，数据一定不同，但是校验和相同时数据不一定相同（工程上不考虑，因为概率太小了，可以忽略不计）。`最后，如果数据出错的话，UDP的做法是直接丢弃掉，如果你想让对方重新发一遍数据的话，哈哈，对不起，UDP协议做不到（TCP就可以做到，这也算是TCP协议可靠性的一种体现把）！！！`**

## 二、TCP协议 ##

### TCP协议头格式 ###

下面是TCP协议头格式的图片：  
![在这里插入图片描述][0a3cae164f894d20a797ce1d2e0d6d28.png]

*  **端口号：属于传输层，知道了端口号之后才能进一步确定数据要交给哪个应用程序。端口号的范围依然是0-65535，0-1024端口号在这里依然存在。**
 *  **首部长度：TCP首部长度字段的最小值是5，最大值是15，单位是字节；所以首部长度字段的最小字节是`4*5=20`字节，最大字节为`15*4=60`字节。另外TCP报头长度是可变长的，TCP报头长度的最短长度是20字节，`选项部分可有可无，可以有一个选项，也可以有多个选项，选项的存在与否就影响到了4位首部长度最终是几，最终通过4位首部长度可以确定选项到哪里结束，数据从哪里开始`（即我们需要通过首部长度来确定载荷数据是从哪里开始，报头是从哪里结束的）。**
 *  **6位保留位：保留位是为了以后协议的发展保留的，目前它们的值必须被设置为0（保留位就是为了将来对TCP协议进行升级留下了空间，但是就目前来看大概率是用不到了）。**
 *  **16位校验和同UDP协议中的校验和是一个意思，用于确保数据传输的正确性。**

> ![在这里插入图片描述][564c917bb2c2417f8c9c0daeac1d0418.png]  
> **上图表示6个标志位，每个标志位是1bit，表示非常重要的含义。**

*  **32位序号：每个数据报文段（segment）都会包含一个 TCP 报文头和数据载荷，而TCP 数据报中载荷数据的第一个字节的序号存储在 32 位序号字段（Sequence Number）中。**
 *  **32位确认序号：确认序号的数值就是收到的最后一个字节的编号+1（在 TCP 数据传输过程中，接收方收到发送方发送的每个数据报文段，会对其进行确认，确认号就是接收方期望接收的下一个字节的序号。）**
 *  **六位标志位之`ACK`：当ACK为0的时候只有32位序号是有效的，32位确认序号是无效的；当ACK为1的时候，32位序号和32位确认序号都是有效的。**

## 三、TCP协议可靠性分析 ##

*  **面向连接：TCP在数据传输前要建立连接，数据传输后要释放连接，因此是一种面向连接的传输协议。**
 *  **面向字节流：TCP像一个字节流一样传输数据，以字节流位单位进行读写，应用程序可以将数据分割成任意大小的段，不同的数据段会拼成一个完整的数据流。**
 *  **全双工：TCP的一个连接，既有发送缓冲区，也有接收缓冲区，那么对于这一个连接，既可以读数据，也可以写数据。**
 *  **`确认应答机制`：TCP协议的可靠性最核心的机制就是确认应答。**

### 确认应答机制 ###

> **`确认应答`：简单理解就是A给B发送了一个消息，但是A不能确定B是否收到了自己发送的消息，B如果收到了A发送的消息后就可以给A发送一个消息说我收到了，此时A就可以确定B已经接收到了自己的消息。**  
> **`后发先至`：在数据传输的过程中，一个数据报是先发送出去的，另一个数据报是后发送出去的，但是最终结果是后发出去的数据报反而优先到达目的地（这里两个数据报的目的地都相同）。**  
> **`后发先至产生的原因`：假设现在有两个数据报，都是从出发地A到达目的地B，但是两个数据报走的路线是可以有很多种的，另外每个节点（路由器/交换器）的繁忙程度是不一样的，所以就有可能出现后发先至的情况。**  
> **`如何解决后发先至的情况`：针对数据进行编号，比如`发送消息1、发送消息2、应答1、应答2`，通过这种方式就可以避免消息发送错乱的情况。`TCP是面向字节流的，并没有一条一条这样的概念，所以当然不能以条作为传输单位，所以这里的编号是根据字节来进行编号的`，另外`应答报文要和收到的消息相关联`。如下图所示：**  
> ![在这里插入图片描述][0931df46a989453fb7c7db385b948974.png]  
> ![在这里插入图片描述][0c225bf65b8d486d9b20a8eb4e5c9a41.png]

> **如何确定每个字节的编号：**  
> **我们只需要知道`这一串字节的第一个字节的编号以及报文长度`，此时每个字节的编号自然也就能够确定了（载荷长度在TCP中是感知不到的，但是在IP报头中可以感知到）。**

### 超时重传机制 ###

> **`超时重传`：`确认应答是保证TCP传输数据可靠性的核心机制。`但是由于丢包问题可能收不到应答，等待一定时间后如果还收不到数据包，此时就需要考虑到重新将数据包进行传输，我们称之为`超时重传`。**

> **超时重传分为两种情况：第一种情况是发的消息本身丢包了；另外一种情况是应答报文丢包了。发送方是无法区分到底是哪种情况的。**  
> **情况1：消息本身丢包**  
> ![在这里插入图片描述][5fbf6e79ecf0407d9d57dd8afdb08a66.png]  
> **情况2：应答报文丢包**  
> ![在这里插入图片描述][502b6d76f464428ab8fbd1b443cadb7c.png]  
> **既然发送方针对丢包情况无法区分具体是哪一种情况，所以发送方的做法是重传。**  
> **第一种情况如果重传并没有什么太大的问题；但是如果是第二种情况的话，发送方就会出现同一条数据包发送了两次的重复传送（即同一个消息发送了两遍）的现象。**  
> **`所以接收方的做法是：接收方收到数据之后会对数据进行去重（即将重复的数据去除掉），以保证应用程序调用inputStream.read的时候读到的数据不会重复`。**  
> **那如何对数据进行去重呢：可以TCP的序号来作为判定条件，TCP会在内核中给每个socket对象安排一个内存空间，相当于一个队列，我们称之为接收缓冲区，作用是把接收到的数据都放到内存缓冲区中，并且按照序号排列好顺序（`这里其实相当于一个生产者消费者模型：当接收方收到数据后，接收方的网卡会把数据放到对应的socket的接收缓冲区中。当应用程序调用read的时候，此时就会从接收缓冲区中进行数据的消费`）。我们知道接收缓冲区中数据的序号是有序排列的，如果队列队首元素的序号已经超过了新收到的这个数据的序号，说明新收到的这个数据的序号对应的数据已经被读取过了。**  
> **当read被调用来读取数据的时候，有两种模式，一种模式是读到数据后就删除（这是默认模式），另一种模式就是读到数据后不对数据进行删除。**  
> **队列中是数据的序号是有序排列的，正因为是有序排列，所以也解决了数据后发先制的情况，因此应用程序就不用担心数据传输的先后顺序问题。**

> **现在来看下一个问题，即为什么数据重传时就一定能够保证数据一定能够传过去呢：这是个概率问题，本来丢包概率就已经很小了，连续丢包的概率就更小了，总体数据传输成功就好即可。**

> **超时等待时间是多久呢：这里的等待时间是可以进行手动设置的，随着超时轮次的增加，超时时间是不断增加的（随着超时轮次的增加，超时时间会越来越长）。这里解释下为什么随着超时轮次增加超时时间会越长呢，既然超时重传好几次都不成功的话，那可能网络是有故障的，之所以拉长了超时的时间间隔就是为了给网络恢复留下了一定的时间。当然超时轮次不是无限的，超时轮次到了一定次数之后，如果一直重传不成功的话就会放弃重传，此时就会`重置TCP连接`，复位TCP报文（六个标志位中有个标志位是`RST`，为1表示是一个复位报文）**

> **复位报文：**  
> **如果发送方连续重传了一定次数（通常是超过一定阈值），但仍然没有收到接收方的任何响应，这可能意味着连接发生了某种异常，无法继续通信。在这种情况下，发送方会发送一个复位（RST）报文给接收方，以中断当前的连接。  
> 复位报文是TCP中一种特殊的控制报文，它用于异常情况下的连接中断。接收方收到复位报文后，会立即中断连接，并且双方的TCP栈都会清除关于这个连接的状态信息。复位报文的作用是快速通知对方连接已经不能继续，并且清理连接资源以防止资源浪费。  
> 需要注意的是，复位报文是作为异常情况下的最后手段使用的，通常在网络故障、主机崩溃或拒绝服务攻击等情况下。在正常情况下，TCP会使用其他机制（如超时重传和拥塞控制）来保证数据可靠传输和连接的稳定。**

**以上就是超时重传机制，仅仅依靠确认应答机制并不能保证数据传输的可靠性，超时重传机制是确认应答机制的有效补充。确认应答机制是正常情况下接收方给发送方说明我已经收到消息了，而超时重传机制是用来解决丢包这种非正常情况的一种策略。**

**本文到这里就结束了，希望友友们可以支持一下一键三连哈。嗯，就到这里吧，再见啦！！！**

![在这里插入图片描述][fd869e0e0776441cae49025ee922cb7c.png]

[Link 1]: https://xiaofeizhu.blog.csdn.net/
[Link 2]: https://blog.csdn.net/m0_74352571/category_12535230.html?spm=1001.2014.3001.5482
[Java]: https://blog.csdn.net/m0_74352571/category_12520599.html?spm=1001.2014.3001.5482
[859d1470000d4a738094a27fda19c803.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/27/9006999dbf2940cfa4f1a09224429617.png
[e3567a3b4d884881aeca044a7a50585d.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/27/228c34280fa442058a9a670af3228c33.png
[0a3cae164f894d20a797ce1d2e0d6d28.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/27/fc6aa544dc5d48758324912a4313eaf0.png
[564c917bb2c2417f8c9c0daeac1d0418.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/27/054bc368b56a425484ddc5647717d726.png
[0931df46a989453fb7c7db385b948974.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/27/7bf10a262c1b478694831a72a6a35163.png
[0c225bf65b8d486d9b20a8eb4e5c9a41.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/27/df310a66d05545c7b3dd6d3f8a1e62dc.png
[5fbf6e79ecf0407d9d57dd8afdb08a66.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/27/b962f71a80fe47a687b2d282b6791482.png
[502b6d76f464428ab8fbd1b443cadb7c.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/27/274fe42b992248f69c381a8fecac3839.png
[fd869e0e0776441cae49025ee922cb7c.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/27/37a39153da3d4e6ab0e37ffc796ba2f8.png