【网络编程】TCP,UDP协议详解

「爱情、让人受尽委屈。」 2023-09-27 17:26 10阅读 0赞

> ## 前言 ##
> 
> 小亭子正在努力的学习编程，接下来将开启javaEE的学习~~
> 
> 分享的文章都是学习的笔记和感悟，如有不妥之处希望大佬们批评指正~~
> 
> 同时如果本文对你有帮助的话，烦请点赞关注支持一波, 感激不尽~~

**目录**

前言

TCP协议

TCP协议特点

TCP协议通信场景

TCP协议的几个重要机制

一、确认应答

二、 超时重传

三、连接管理（重点）

四、滑动窗口

五、流量控制

六、拥塞控制

七、延时应答

八、捎带应答

九、面向字节流 -粘包问题

十、异常处理-心跳包

缓冲区：

UDP协议

UDP协议的特点

UDP协议通信场景

UDP协议端格式

**传输层的2个常见协议**

**TCP(Transmission Control Protocol) ：传输控制协议**

**UDP(User Datagram Protocol)：用户数据报协议**

## **TCP协议** ##

### **TCP****协议特点** ###

> 使用TCP协议，必须双方先建立连接，它是一种面向连接的可靠通信协议。
> 
> 传输前，采用“三次握手”方式建立连接，所以是可靠的 。
> 
> 在连接中可进行大数据量的传输 。
> 
> 连接、发送数据都需要确认，且传输完毕后，还需释放已建立的连接，通信效率较低。

### **TCP****协议通信场景** ###

对信息安全要求较高的场景，例如：文件下载、金融等数据通信。

### TCP协议的几个重要机制 ###

TCP对数据传输提供的管控机制，主要体现在两个方面：安全和效率。

这些机制和多线程的设计原则类似：保证数据传输安全的前提下，尽可能的提高传输效率

#### 一、确认应答 ####

是实现可靠性的最核心机制

举个栗子：你约女同学出去吃饭，给她发消息

![0bf7740acff04717a378c6c611720614.png][]

为了解决上述问题，就需要对信息进行编号，给发出去的消息分配一个“序号”，同时应答报文给出“确认序号”

**确认序号，是取发送方发过来的所有数据，最后一个字节的下一个字节的序号**

TCP从前往后将每个字节分别分配一个编号，即为序列号

![76ab92cac2c6452595af0cb94877d0bb.png][]

每一个ACK都带有对应的确认序列号，意思是告诉发送者，我已经收到了哪些数据，下一次你从哪里开始发。

举个栗子：

![9f35938edfbb443e89184ed0cef6e9bb.png][]

> **确认序号 1001的含义：**
> 
> 1.<1001的数据，我已经收到
> 
> 2.我接下来想向发送方索要从1001开始的数据

**接收方通过ack的确认序号，告诉发送方哪些数据已经收到了。**

**如果一切顺利的话，就可以直接确认应答了，可靠性就得到了支持。**

#### 二、 超时重传 ####

什么是超时重传？

> **主机A发送数据给B之后，可能因为网络拥堵等原因，数据无法到达主机B**
> 
> **如果主机A在一个特定时间间隔内没有收到B发来的确认应答，就会进行重发**

**丢包，是一个网络通信中常见的问题，那么为什么会丢包呢？**

![30888466c9464f8cab23e0aa087b9d7b.png][]

在网络通信中，数据的发送很复杂，需要经过很多的设备，每个设备的转发能力都是有上限的，某一时刻，某个设备上面的流量达到峰值，就有可能引起部分数据被丢包。

【补充：看直播，看视频，对于丢包是不敏感的（看视频提前有预缓冲）

打游戏，特别是LOL，王者等对抗性游戏，对于丢包非常敏感，丢包率高直接卡成ppt】

**发送方对于丢包的判定：**

> 1.数据直接丢了，接收方没收到，自然不会发送ack
> 
> 2.接收方收到了数据，但返回的ack丢了
> 
> 发送方无法区分这两种情况，都会触发超时重传，
> 
> 但是第二种情况下，接收方会收到重复的数据，但是没关系，TCP会在接收缓冲区中，根据收到的数据的序号自动去重，保证了应用程序督导的数据任然只有一份。
> 
> 【也有可能出现连续丢包的情况，TCP的处理方式是继续超时重传，但是每一次丢包后等待的时间就会变长，此时说明网络出现了比较严重的问题，TCP就会尝试重置连接，如果还不行，TCP就会关闭连接，放弃通信，总之就是，能重传就重传，实在传不了就关闭连接，尽最大可能完成传输】

**【一切顺利的情况下，使用确认应答保证可靠性，****出现丢包，使用超时重传作为补充，****这两个机制是TCP可靠性的基石**】

#### 三、连接管理（重点） ####

在正常情况下，TCP要经过三次握手建立连接，四次挥手断开连接

**建立连接三次握手**

> 握手（handshake）是指通信双方，进行一次网络交互
> 
> 三次握手相当于客户机与服务器之间通过三次交互建立了连接（双方各自记录对方的信息）
> 
> syn：同步报文段，意思是一方向另一方申请建立连接
> 
> ack：确认字符，表示发来的数据已确认接收无误

![8c7a96bd689b4439bc2f310e3bc969af.png][]

![d2c451209eec43ffa422cd2590475d5e.png][]

三次握手这个过程，本质上是投石问路，验证一下客户端和服务器各自的接收和发送能力是否正常。

【举个栗子：就像每天的第一趟高铁和地铁一样，第一趟车都是空的，为了检验线路是否通畅】

【补充：中间的syn和ack也可以分开发送，但是没必要，一起发效率高】

**断开连接——四次挥手**

![7d02040e5bd24711be49d9b555233397.png][]

![e41830b327e1492887e8b631a413cd5d.png][]四次挥手和三次握手非常像，最主要的区别就是：

> **三次握手中，ack和syn是同一个时机触发的，都是内核完成的**
> 
> **四次挥手中，ack和fin则是不同时机触发的，ack是内核完成的，会在收到fin的时候第一时间返回，fin则是应用程序代码控制的，在调用到socket的close方法是才会触发**。

![cc2dadd3b67b43479839a9118fe15e78.png][]

**上述两个过程和可靠性多少有点关系，但是可靠性主要还是靠确认应答和超时重传。**

#### 四、滑动窗口 ####

刚才我们讨论了确认应答策略，对每一个发送的数据段，都要给一个ACK确认应答。收到ACK后再发送

下一个数据段。这样做有一个比较大的缺点，就是性能较差。尤其是数据往返的时间较长的时候。

TCP要保证的不仅仅是可靠性，还要保证效率。

![d3822316ca864d3da6d8706890bd1221.png][]

想要提升效率就需要缩短等待时间，解决的方法就是一次发送多条数据，一次等待多个ack，（批量发送）

![05ee53ae0d2b4f61b043f29696aeddae.png][]

上图所示就是批量发送4条数据，发完以后统一等待ack，每次收到一个ack后就立刻发送下一条（注意不是收到4个ack再发下一组）如下图：

![e12cd993c7ce4ca3a3edf28335507c0d.png][]

> 窗口大小指的是无需等待确认应答而可以继续发送数据的最大值。上图的窗口大小就是4000
> 
> 个字节（四个段）。
> 
> 发送前四个段的时候，不需要等待任何ACK，直接发送；
> 
> 收到第一个ACK后，滑动窗口向后移动，继续发送第五个段的数据；依次类推；
> 
> 操作系统内核为了维护这个滑动窗口，需要开辟 发送缓冲区 来记录当前还有哪些数据没有应
> 
> 答；只有确认应答过的数据，才能从缓冲区删掉；
> 
> 窗口越大，则网络的吞吐率就越高；

那么如果出现了丢包，如何进行重传？这里分两种情况讨论。

**情况一：数据包已经抵达，ACK被丢了**

![044ecc80a0d14c018c5a9e07ca7def6b.png][]

这种情况下，部分ACK丢了并不要紧，因为可以通过后续的ACK进行确认

**情况二：数据包就直接丢了。**

![8baa2d532460491da31860c086adc679.png][]

> 当某一段报文段丢失之后，发送端会一直收到 1001 这样的ACK，就像是在提醒发送端 "我想要的是 1001" 一样；
> 
> 如果发送端主机连续三次收到了同样一个 "1001" 这样的应答，就会将对应的数据 1001 -2000 重新发送；
> 
> 这个时候接收端收到了 1001 之后，再次返回的ACK就是7001了（因为2001 - 7000）接收端
> 
> 其实之前就已经收到了，被放到了接收端操作系统内核的接收缓冲区中；

![9f05000f4bf94415a406cbd00ce3acb1.png][]

> 上述重传过程，没有任何冗余操作，数据丢了才会重传，不丢数据不会重传，整体速度还是比较快的。
> 
> **这种机制被称为 "高速重发控制"（也叫 "快重传"）。**

#### 五、流量控制 ####

接收端处理数据的速度是有限的。如果发送端发的太快，导致接收端的缓冲区被打满，这个时候如果发送端继续发送，就会造成丢包，继而引起丢包重传等等一系列连锁反应。

**因此TCP支持根据接收端的处理能力，来决定发送端的发送速度。这个机制就叫做流量控制（FlowControl）；**

> 接收端将自己可以接收的缓冲区大小放入 TCP 首部中的 "窗口大小" 字段，通过ACK端通知发送端；
> 
> 窗口大小字段越大，说明网络的吞吐量越高；
> 
> 接收端一旦发现自己的缓冲区快满了，就会将窗口大小设置成一个更小的值通知给发送端；
> 
> 发送端接受到这个窗口之后，就会减慢自己的发送速度；
> 
> 如果接收端缓冲区满了，就会将窗口置为0；这时发送方不再发送数据，但是需要定期发送一
> 
> 个窗口探测数据段，使接收端把窗口大小告诉发送端。

![db5ba33d3a194ad3a536dba10768510c.png][]

> **补充：**
> 
>  **各个字段的含义：**
> 
> 源/目的端口号：表示数据是从哪个进程来，到哪个进程去；  
> 32位序号：指的是报文段序号，有时候我们会发多条数据，为了方便回答，进行编号；  
> 32位确认号：这个确认号是针对序号设定的，为了防止回复串行；  
> 4位TCP报头长度：表示该TCP头部有多少个32位bit（有多少个4字节）；所以TCP头部最大长度是15 \* 4 = 60  
> **6位标志位:**  
> URG：紧急指针是否有效  
> ACK：确认号是否有效  
> PSH：提示接收端应用程序立刻从TCP缓冲区把数据读走  
> RST：对方要求重新建立连接；我们把携带RST标识的称为复位报文段  
> SYN：请求建立连接；我们把携带SYN标识的称为同步报文段  
> FIN：通知对方，本端要关闭了，我们称携带FIN标识的为结束报文段  
> 16位窗口大小：控制每次滑块的流量  
> 16位校验和：发送端填充，CRC校验。接收端校验不通过，则认为数据有问题。此处的检验和不光包含TCP首部，也包含TCP数据部分。  
> 16位紧急指针：标识哪部分数据是紧急数据；

![8435d86e0d14465b98ff478f7b04dcd0.png][]

#### 六、拥塞控制 ####

虽然TCP有了滑动窗口这个大杀器，能够高效可靠的发送大量的数据。但是如果在刚开始阶段就发送大量的数据，仍然可能引发问题。

因为网络上有很多的计算机，可能当前的网络状态就已经比较拥堵。在不清楚当前网络状态下，贸然发送大量的数据，是很有可能引起雪上加霜的。

**TCP引入 慢启动 机制，先发少量的数据，探探路，摸清当前的网络拥堵状态，再决定按照多大的速度传输数据；**

**拥塞控制就是通过实验的方式找到一个合适的发送速率！！**

> 开始的时候，按照一个小的速率发送，如果不丢包，就可以提高一下速率（扩大窗口大小）
> 
> 如果出现丢包，则立刻把速率调小。
> 
> 重复上述过程，让传输速率达到一个动态平衡。

另外，网络的拥堵情况也不是一成不变的，拥塞控制这一策略也能很好地解决这一问题。

**慢启动：**

> 慢启动" 只是指初使时慢，但是增长速度非常快。
> 
> 为了不增长的那么快，因此不能使拥塞窗口单纯的加倍。
> 
> 此处引入一个叫做慢启动的阈值
> 
> 当拥塞窗口超过这个阈值的时候，不再按照指数方式增长，而是按照线性方式增长
> 
> ![a8471a05b60748f39bd238ed81249152.png][]

> 滑动窗口的大小取决于 流量控制 和 拥塞控制
> 
> 流量控制衡量了接收方的处理能力，拥塞控制衡量了传输路径的处理能力

#### 七、延时应答 ####

如果接收数据的主机立刻返回ACK应答，这时候返回的窗口可能比较小。

假设接收端缓冲区为1M。一次收到了500K的数据；如果立刻应答，返回的窗口就是500K；

但实际上可能处理端处理的速度很快，10ms之内就把500K数据从缓冲区消费掉了；

在这种情况下，接收端处理还远没有达到自己的极限，即使窗口再放大一些，也能处理过

来；如果接收端稍微等一会再应答，比如等待200ms再应答，那么这个时候返回的窗口大小就是

1M；

一定要记得，窗口越大，网络吞吐量就越大，传输效率就越高。我们的目标是在保证网络不拥塞的情况下尽量提高传输效率

举个栗子：你妈妈早上出门前让你干家务，你给忘了，然后他下午给你发消息说你怎么没干，你当做没看到没回消息，立刻去把家务做的差不多了，就只还剩一点的时候给他回消息，你就可以很有底气的说说马上完事儿了。

#### 八、捎带应答 ####

在延迟应答的基础上，我们发现，很多情况下，客户端服务器在应用层也是 "一发一收" 的。意味着客户端给服务器说了 "How are you"，服务器也会给客户端回一个 "Fine, thank you"；

那么这个时候ACK就可以搭顺风车，和服务器回应的 "Fine，thank you" 一起回给客户端

![035bea92aa974badb09d34496b8b9a91.png][]

#### 九、面向字节流 -粘包问题 ####

当A给B连续发了多个应用层数据报后，这些数据就会都积累到B的接收缓冲区中，紧紧挨在一起，此时B的应用程序在读数据的时候就很难区分从哪到哪是一个完整的应用层数据报，这就是粘包问题。

> 举个栗子：
> 
> 你吃了吗爸爸饿了一起吃饭吧
> 
> 这句话既可以理解为：
> 
> 你吃了吗爸爸 饿了一起吃吧
> 
> 或者：你吃了吗 爸爸饿了 一起吃吧

那么怎么解决呢？

**1.定义分隔符**

**2.约定有效长度**

#### 十、异常处理-心跳包 ####

![8a481cf207e242de95d7dacd74f9d019.png][]

> 补充：
> 
> #### 缓冲区： ####
> 
> 创建一个TCP的socket，同时在内核中创建一个 发送缓冲区 和一个 接收缓冲区；
> 
> 调用write时，数据会先写入发送缓冲区中；
> 
> 如果发送的字节数太长，会被拆分成多个TCP的数据包发出；
> 
> 如果发送的字节数太短，就会先在缓冲区里等待，等到缓冲区长度差不多了，或者其他合适
> 
> 的时机发送出去；
> 
> 接收数据的时候，数据也是从网卡驱动程序到达内核的接收缓冲区；
> 
> 然后应用程序可以调用read从接收缓冲区拿数据；
> 
> 另一方面，TCP的一个连接，既有发送缓冲区，也有接收缓冲区，那么对于这一个连接，既
> 
> 可以读数据，也可以写数据。这个概念叫做 全双工
> 
> 由于缓冲区的存在，TCP程序的读和写不需要一一匹配，例如：
> 
> 写100个字节数据时，可以调用一次write写100个字节，也可以调用100次write，每次写一
> 
> 个字节；
> 
> 读100个字节数据时，也完全不需要考虑写的时候是怎么写的，既可以一次read 100个字
> 
> 节，也可以一次read一个字节，重复100次；

## UDP协议 ##

###  **UDP****协议的特点**  ###

> UDP是一种无连接、不可靠传输的协议。
> 
> 将数据源IP、目的地IP和端口封装成数据包，不需要建立连接
> 
> 每个数据包的大小限制在64KB内
> 
> 发送不管对方是否准备好，接收方收到也不确认，故是不可靠的
> 
> 可以广播发送 ，发送数据结束时无需释放资源，开销小，速度快。

### **UDP****协议通信场景** ###

语音通话，视频会话等。

举个栗子：

街边的烧烤店，厨房和前厅，厨房做好了韭菜，把他装进盘子里，直接把盘子里的韭菜抛到客户的盘子里，只管抛，不管客户接没接到。

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

![b4bf3c6fdbb844ca8d677f2208070469.png][]

上面那个是教科书上的，不好理解，我们看下面这个

![b3dc344373b640c893e38c59ead28ed4.png][]

> **校验和：**网络传输中，可能会因为强磁场等外部的干扰，导致低电平变高，高电平变低，这样就会导致数据传输出错
> 
> 校验和就是用来判断当前传输的数据是否出错的。

举个栗子：

妈妈让我去买四样菜，我买回了五样，这一定是买错了直接一顿臭骂，但是如果我买回了四样，就有可能买对了，暂时不会被骂，但是当妈妈做饭的时候打开袋子，发现买错了品种，我还是会被骂。

再举个栗子：

![1b9987a82f0b43afa66cacf043eac590.png][]

至于校验的方法教科书中常见的有奇偶校验等，在这里我们就不详细说了。

[0bf7740acff04717a378c6c611720614.png]: https://img-blog.csdnimg.cn/0bf7740acff04717a378c6c611720614.png
[76ab92cac2c6452595af0cb94877d0bb.png]: https://img-blog.csdnimg.cn/76ab92cac2c6452595af0cb94877d0bb.png
[9f35938edfbb443e89184ed0cef6e9bb.png]: https://img-blog.csdnimg.cn/9f35938edfbb443e89184ed0cef6e9bb.png
[30888466c9464f8cab23e0aa087b9d7b.png]: https://img-blog.csdnimg.cn/30888466c9464f8cab23e0aa087b9d7b.png
[8c7a96bd689b4439bc2f310e3bc969af.png]: https://img-blog.csdnimg.cn/8c7a96bd689b4439bc2f310e3bc969af.png
[d2c451209eec43ffa422cd2590475d5e.png]: https://img-blog.csdnimg.cn/d2c451209eec43ffa422cd2590475d5e.png
[7d02040e5bd24711be49d9b555233397.png]: https://img-blog.csdnimg.cn/7d02040e5bd24711be49d9b555233397.png
[e41830b327e1492887e8b631a413cd5d.png]: https://img-blog.csdnimg.cn/e41830b327e1492887e8b631a413cd5d.png
[cc2dadd3b67b43479839a9118fe15e78.png]: https://img-blog.csdnimg.cn/cc2dadd3b67b43479839a9118fe15e78.png
[d3822316ca864d3da6d8706890bd1221.png]: https://img-blog.csdnimg.cn/d3822316ca864d3da6d8706890bd1221.png
[05ee53ae0d2b4f61b043f29696aeddae.png]: https://img-blog.csdnimg.cn/05ee53ae0d2b4f61b043f29696aeddae.png
[e12cd993c7ce4ca3a3edf28335507c0d.png]: https://img-blog.csdnimg.cn/e12cd993c7ce4ca3a3edf28335507c0d.png
[044ecc80a0d14c018c5a9e07ca7def6b.png]: https://img-blog.csdnimg.cn/044ecc80a0d14c018c5a9e07ca7def6b.png
[8baa2d532460491da31860c086adc679.png]: https://img-blog.csdnimg.cn/8baa2d532460491da31860c086adc679.png
[9f05000f4bf94415a406cbd00ce3acb1.png]: https://img-blog.csdnimg.cn/9f05000f4bf94415a406cbd00ce3acb1.png
[db5ba33d3a194ad3a536dba10768510c.png]: https://img-blog.csdnimg.cn/db5ba33d3a194ad3a536dba10768510c.png
[8435d86e0d14465b98ff478f7b04dcd0.png]: https://img-blog.csdnimg.cn/8435d86e0d14465b98ff478f7b04dcd0.png
[a8471a05b60748f39bd238ed81249152.png]: https://img-blog.csdnimg.cn/a8471a05b60748f39bd238ed81249152.png
[035bea92aa974badb09d34496b8b9a91.png]: https://img-blog.csdnimg.cn/035bea92aa974badb09d34496b8b9a91.png
[8a481cf207e242de95d7dacd74f9d019.png]: https://img-blog.csdnimg.cn/8a481cf207e242de95d7dacd74f9d019.png
[b4bf3c6fdbb844ca8d677f2208070469.png]: https://img-blog.csdnimg.cn/b4bf3c6fdbb844ca8d677f2208070469.png
[b3dc344373b640c893e38c59ead28ed4.png]: https://img-blog.csdnimg.cn/b3dc344373b640c893e38c59ead28ed4.png
[1b9987a82f0b43afa66cacf043eac590.png]: https://img-blog.csdnimg.cn/1b9987a82f0b43afa66cacf043eac590.png