网站开发明细报价表,网络营销策划是指,拥有自己的网站,潍坊方圆网站建设#x1f970;#x1f970;#x1f970;来都来了#xff0c;不妨点个关注叭#xff01; #x1f449;博客主页#xff1a;欢迎各位大佬!#x1f448; 文章目录 1. UDP1.1 UDP 报文格式1.1.1 源端口/目的端口1.1.2 报文长度1.1.3 校验和 2. TCP2.1 TCP 报文结构2.2 TCP 特… 来都来了不妨点个关注叭 博客主页欢迎各位大佬! 文章目录 1. UDP1.1 UDP 报文格式1.1.1 源端口/目的端口1.1.2 报文长度1.1.3 校验和 2. TCP2.1 TCP 报文结构2.2 TCP 特性2.2.1 确认应答2.2.2 超时重传2.2.3 连接管理2.2.3.1 TCP 三次握手2.2.3.2 TCP 四次挥手 2.2 4 滑动窗口2.2.5 流量控制2.2.6 拥塞控制2.2.7 延时应答2.2.8 捎带应答2.2.9 面向字节流2.2.10 异常处理 3. UDP 和 TCP 比较 传输层常见的两个协议有UDP 和 TCP协议这期内容我们一起来看看 UDP 和 TCP ~ 1. UDP
学习一个协议其中一个重要的环节就是认识协议报文格式了解具体是怎么组织这个数据的~
1.1 UDP 报文格式 1.1.1 源端口/目的端口 源ip 源端口 —— 数据从哪里来 目的ip 目的端口 —— 数据到哪里去 打一个比方不知道小伙伴们还记不记得唐僧的自我介绍~ 贫僧自东土大唐而来到西天拜佛求经 这样小伙伴们有没有更加了解源ip、源端口、目的ip、目的端口之间区别和联系~
可以看到每个端口号在 UDP 报文中占 2 个字节这就表明端口号的取值范围是 0 - 65535 其中 1024 的端口号称为知名端口号给一些名气比较大的服务器预留的端口号这部分端口我们写代码不应该使用比如http 服务器对应 80ftp 对应21ssh 对应 22当然用了也没事但是可能需要管理员权限~
1.1.2 报文长度
也是 2 个字节2 个字节表示的范围是 0 - 65535 等价于 64KB即一个 UDP 报文的最大长度就是 64 KB
那么就有一个问题了如果真要传输一个比较大的数据怎么办呢有两个解决方案 1可以把一个较大的数据拆分成多个部分使用多个 UDP 2不使用 UDP直接使用 TCPTCP 没有限制
因此需要注意使用 UDP 编程的时候需要注意 UDP 的数据报不能太长了否则就会出现问题!!!
1.1.3 校验和
校验和也是 2 个字节~ 网络传输并非那么稳定可能会出现一些幺蛾子通过网线传输电信号电信号使用高低电平表示 0 1但是如果外部环境干扰强磁场之类的就可能导致低电平 —— 高电平高电平 —— 低电平这样比特反转数据传输就出错了
校验和的存在意义就是用来判定当前传输的数据是否出错but 如果校验和不对此时传输的数据一定不对如果校验和对但是数据不一定对有一定概率是错误的
打一个比方假设这样一个场景 小万让小丁去买烧烤小万想要 3 个烤面筋2 个烤翅中20串烤肉~ 一共 25 个签子 小丁就屁颠屁颠去买啦买回来的如果不是 25 个签子那么小丁一定有买错的地方如果是 25 个 签子可能小丁买对了也可能买错了~ 为了让校验和能够识别率更高一些计算的时候通常会以数据内容作为参数来进行计算这样数据内容发生变化校验和也会发生变化
校验和往往就是取内容/内容的一部分通过一些算术运算数学公式变换这里的数学公式有很多种方式奇偶校验是其中的一种得到一个数值如果内容发生变化得到的校验和也就发生变化~ 比如说大家都知道金庸写武侠小说~ 飞雪连天射白鹿笑书神侠倚碧鸳是由金庸先生的14部作品的名称首字相连组合而成的十四字对联。这个对联的字面意思是只见漫天大雪中有人正在射白鹿而作者胸有成竹大笑之后又继续书写那神侠眷侣和鸳鸯相倚的故事 如果有一部作品的首字错了那么就不能形成这个对联但是如果首字组成的对联是对的这 14 部作品名称不一定都对可能会在某一部作品的中间出现差错~ 发送方把载荷数据带入到校验和算法中计算生成得到校验和结果设为 sum1 发送方就把这一整串数据发送给接收方
接收方收到的数据既有载荷也有这个校验和 sum1
接收方就可以把载荷按照同样的算法再计算一遍校验和得到 sum2
对比 sum1 和 sum2是否相同如果不相同数据就一定出现了问题
因为我们知道前提输入的内容一样按照同一个算法得到的校验和结果也是一样的 校验和结果不一样原始输入的内容一定不一样!!! 就可以认为传输出错了~
当然有的小伙伴会有疑问传输过程中除了载荷数据可能会传输有问题那校验和会不会传输得有问题呢答案是校验和也可能会出错如果 sum1 变了内容没变但这样还是和 sum2 对不上这样也视为传输出错~
UDP 这里使用的校验和算法是 CRC 算法一个简单粗暴的校验和算法
UDP 的介绍就到这里啦接下来我们来看看 TCP !!! 重头戏来了~ 2. TCP
2.1 TCP 报文结构 源/目的端口号表示数据是从哪个进程来到哪个进程去32位序号/32位确认号与确认应答机制有关(这里讲~)4位TCP报头长度表示该TCP头部有多少个32位bit(有多少个4字节)首部长度有4个bit位表示最大长度是15因此TCP头部最大长度是15 * 4 60 字节6位标志位 URG紧急指针是否有效 ACK确认号是否有效 PSH提示接收端应用程序立刻从TCP缓冲区把数据读走 RST对方要求重新建立连接将携带RST标识的称为复位报文段 SYN请求建立连接把携带SYN标识的称为同步报文段 FIN通知对方本端要关闭了称携带FIN标识的为结束报文段16位窗口大小与滑动窗口有关(这里讲~)16位校验和发送端填充CRC校验接收端校验不通过则认为数据有问题。此处的检验和不仅包含TCP首部也包含TCP数据部分16位紧急指针标识哪部分数据是紧急数据40字节头部选项是一个可变长的可选信息部分允许TCP报文携带额外的配置或控制信息TCP包括20字节固定部分以及最多 40 字节可选部分因此TCP 报头的总长度可以在 20-60字节变化~
2.2 TCP 特性
2.2.1 确认应答
实现可靠机制的最核心机制!!! 接收方就可以通过 ack 的确认序号告诉发送方哪些数据已经收到了TCP 传输引入了序号和确认序号
TCP 将每个字节的数据都进行了编号即为序列号 每个 ACK 都带有对应的确认序列号就是告诉发送方我已经收到这些数据了下次从哪里开始发~
TCP 是针对每个字节都去编号TCP 并没有一条消息两条消息这样的说法是从前往后把每个字节分别分配一个编号~
【注意】确认序号的规则 并不是说发送发的序号是什么确认序号就是什么 而是取得是发送发过来的所有数据最后一个字节的下一个字节的序号 确认序号 1001 的含义 1 1001 的数据接受方已经收到 2接下来想向发送方索要从 1001 开始的数据
Q1为什么要有序号
举一个例子更好理解~ 假设这样一个场景小丁准备把小万追到手小丁想通过发短信来表达自己的心意 小万是想应答小丁可以一起去吃饭但是不能做小丁的女朋友~ 结果这两个短信回应因为一些原因比如网络呀等导致了先发后至的效果~ 造成小丁理解错误不吃饭就不吃饭呗反正可以做我的女朋友
因此需要引入序号确保数据传输的可靠性避免造成语义错误~ 对于TCP来说自身也承担着整队的任务TCP 会有一个接收缓冲区一块内核中的内存空间每个 socket 都有一份自己的缓冲区TCP 就可以按照序号针对收到的消息进行整队排好序这样应用程序读数据读到的一定是有序的和发送顺序一致了~
A1因此答案也就显而易见了有序号是为了解决网络中的数据包可能经过不同的路径到达接收端因此到达的顺序可能与发送的顺序不一致的问题TCP为每个字节分配了一个唯一的序号这样接收端就可以根据序号将接收到的字节按照正确的顺序重新组装起来
2.2.2 超时重传
如果上述过程一切顺利就可以直接确认应答可靠性自然得到了支持
但是丢包也是网络非常典型的情况~
如果中间任何一个节点出现了问题都会导致丢包每个设备都是在承担了很多的转发任务的每个设备转发能力都是有上限的某一时刻某个设备上面的流量达到了峰值就可能引起部分数据被丢包~
这种情况下非常容易出现概率性丢包~ 对于看视频看直播对于丢包是不敏感的看视频提前有预缓冲 打游戏尤其是对抗性的游戏对于丢包是非常敏感的
超时重传
如果包丢了接收方就收不到了自然不会返回ack发送方就迟迟拿不到应答的报文 等待了一段时间之后还是没有收到应答报文发送发就视为刚才发送的数据报丢失了就会重新发一遍 网络丢包是概率性事件上个包丢了重传还是有很大机会传过去的
对于丢包的判定
发送方对于丢包的判定是一定时间内没有收到 ACK有如下两种情况 1传输的数据直接丢了接收方没收到自然就不会发ACK 2接收方收到数据了返回的ACK丢了 发送发无法区分这两种情况的只能都重传
在第 2 种情况下返回ACK丢失了发送方又传了一遍数据这样接收方不是会收到重复的数据嘛~ TCP 非常贴心地帮助我们处理好这个问题了会在接收缓冲区中根据收到的数据的序号自动去重保证应用程序读到的数据仍然只有1份 哪有什么岁月静好全是 TCP 帮助我们负重前行呀
有小伙伴就问了重传的数据有没有可能又丢失了 也是有可能的重传不是百分之百可以传过去的~一旦出现连续丢包这种情况多半你的网络出现了非常严重的问题!!!
对于多个包丢失
TCP 针对多个包丢失处理思路是继续超时重传~ 但每丢一次包超时等待的时间都会变长即重传的频率降低了TCP 可能觉得重传也怕是没啥希望的干脆就摆烂摸鱼了反正重传过去也啥用网络已经出现严重的问题了~
对于连续多次重传都无法得到ACK 连续多次重传都无法得到 ACK此时 TCP 就会尝试重置连接相当于尝试重连如果重置连接也失效TCP 就会关闭连接放弃网络通信
总结一句话能重传就重传实在传不了就关闭连接尽可能完成传输~ 如果数据传输一切顺利使用确认应答保证可靠性出现丢包使用超时重传作为补充 确认应答和超时重传这两个机制是 TCP 可靠性的基石!!!
2.2.3 连接管理
TCP 建立连接三次挥手 TCP 断开连接四次挥手
上述这两个过程和可靠性多少有一点关系但也仅此而已~ 比如被问到TCP 是如何实现可靠性的 答确认应答超时重传 可能有些小伙伴们会回答是因为 TCP 有三次握手和四次挥手这是不正确滴 2.2.3.1 TCP 三次握手
握手指的是通信双方进行一次网络交互相当于客户端和服务器之间通过三次交互建立了连接关系双方各自记录对方的信息**确认客户端和服务器各自的发送能力和接收能力都正常**这就是后续可靠传输的基础~ syn 称为同步报文段意思就是一方要向另一方申请建立连接~
就比如小丁对小万说你愿意做我的唯一嘛~小丁的内心独白小万你只能爱我一个我还可以爱别人! 小万就返回一个应答 ack可以捏当然小万也不蠢听出了里面的话里的潜在含义也发一个 syn你也愿意做我的唯一嘛~ 意思就是小丁只能爱小万一个!!! 小丁就返回一个应答 ack俺也一样只爱你一个
双方都确认了自己是对方的唯一此时关系就建立起来了连接建立完成
上述过程内核自动完成应用程序干预不了~ 等到连接完成后服务器 accept 把建立好的连接从内核拿到应用程序~
三次握手需要达成什么样的效果 三次握手本质上是投石问路确认一下是可以发送数据的验证了客户端和服务器各自的发送能力和接收能力是否正常 (从这个角度看三次握手和可靠性也是有关系的但是肯定没有确认应答超时重传更重要!)
再举一个形象的栗子帮助我们更好的理解~ 假如小丁和小万连麦甜蜜双排~ 每次连麦的时候需要进行三次握手的测试测试双方的麦克风和耳机的正确性
确认了客户端和服务器各自的发送能力和接收能力都正常这就是后续可靠传输的基础!!!
Q1两次握手可以吗 不可以为了防止服务器一直等(服务器不知道客户端接收的能力)同时也为了防止客户端将已经失效的连接请求突然又传送到了服务器
Q2四次握手可以吗 完全可以但是没有必要中间的 syn 和 ack 可以分两次分别发送同样可以达成目的但是完全没必要! 分两次发的效率不如合并成一次! 原因是多一个封装和分用!不用多此一举啦~
2.2.3.2 TCP 四次挥手
TCP 四次挥手即断开连接和三次握手非常像 通信双方各自给对方发送一个 FIN 结束报文再各自给对方返回 ACK ACK 和 FIN 有一定概率合并成一个的但是通常情况下不能合并!
Q有小伙伴就会问FIN 和 ACK不能合并一次发过去嘛~ 就跟三次握手SYN 和 ACK 一起发过去一样为什么三次握手能100%合并四次挥手就不能合并呢
A因为 FIN 和 ACK 触发时机不同 三次握手ACK 和 SYN 都是同一时机触发的都是内核来完成的 四次挥手ACK 和 FIN则是不同时机触发的ACK 是内核完成的会收到 FIN 的时候第一时间返回但是FIN 则是应用程序代码控制的在调用 socket 的 close 方法的时候才会触发 FIN 服务器发现客户端断开连接后服务器自己也进行 close 操作正是这个 close 触发了第二个 FIN 但是这个 close 的执行时机可能是立即也可能是隔很久取决于代码如何写如果是立即 close就可以趁着刚才的 ACK 还没有发这里就可以合并了如果是隔很久再 close此时 fin 就只能单独发送了~
还有一些情况比如 TCP 客户端没有显示调用 closefin 如何发呢~ 其实进程结束了自然就会自动进行 close此时就触发了 fin!
此时客户端虽然结束进程了但是 TCP 连接还在内核维护的进程是结束了但是内核还是会把 TCP 连接继续维护直到四次挥手完成服务器这边也是一样~ 小小总结因此进程的结束对四次挥手没有太大的影响~
【注意】 建立连接一定是客户端主动发起的! 断开连接客户端和服务器都有可能先发起
2.2 4 滑动窗口
TCP 要保证的不仅仅是可靠性还有效率~ 提升可靠性往往意味着损失效率(总不能啥都想要吧~)
滑动窗口批量传输数据 (上述图片来自一本书《图解 TCP/ IP》非常好的讲解网络原理的书~) 这样我们就可以清楚的知道滑动窗口的目的是提高数据传输的效率~
但是!!! 整体效率的提升是和没有进行批量发送进行对比的而不是和可靠性对比的再怎么快都比不上 UDP 的快TCP 的效率机制本质上是让性能损少一点~
同时并不是所有时候都需要批量发送如果数据量很少只有一两条等少量的低频的操作就完全不需要批量发送呀就仍然按照前面朴素的确认应答和超时重传~
注意!! 批量不是无限发送是发送到一定程度就等待 ACK不等待直接发送数据量是有上限的并且是回来一个 ACK就立即发送下一条就相当于总的要批量等待的数据是一致的把批量等待数据的数量就称为 窗口大小
下面模拟一下滑动窗口 批量发送了四条数据就等待着四个ACK(红色框起来的区域就相当于是等待的窗口)收到一个 ACK就会立即发送下一条当收到 2001 这个 ACK意味着 1001 - 2000 这个数据得到了确认此时就会立即发送 5001-6000这个数据此时就可以看到窗口移动了一格如果收到的 ACK 非常快此时这个窗口就在快速的往后滑动~ Q1批量发送的过程中如果出现丢包怎么办呢~ A1分为两种情况
1ACK 丢了的情况 分析 这种情况什么事都没有即使丢了这么多 ACK对可靠性没有任何影响!!!
我们可以回顾一下确认序号的含义确认序号表示该序号之前的数据都已经收到了后一个 ACK 能够涵盖前一个 ACK 的意思当收到 2002 这个 ACK 的时候此时发送方就知道 2001 之前的数据都收到了即 1- 1000 这个数据也就收到了1001 这个 ACK 丢了就丢了无所谓的~
因此确认序号的目的就在于这里可以表示该序号之前的数据都已经收到后一个 ACK 能够涵盖前一个 ACK 的作用
当然如果是最后一个 ACK 丢了那就照常超时重传~
2数据丢了的情况 【注意】 当A把1001-2000这个数据重传后B收到之后返回的ACK确认序号是7001而不是2001!!!因为2001 - 7000 这些数据B都已经收到过了~ 通过下面这个图进行解释 上述重传的过程没有任何冗余的操作丢了数据才会重传不丢的数据不必重传整体速度是比较快的这个重传过程也叫快速重传是基于滑动窗口的~
B这边接收的数据是先放到接收缓冲区接下来应用程序就可以通过 socket 里的 InputStream 来读代码中读出来的数据就从接收缓冲区删除了 有没有想起是生产者消费者模型生产者就是对端发送过来数据消费者就是应用程序通过socket 里的 InputStream 来读取出数据消费数据
2.2.5 流量控制
也是保证可靠性的机制~
滑动窗口是批量发送数据窗口越大相当于批量的数据越多整体的速度就越快~ 但是越快就越好吗要记得我们 TCP 可是可靠传输呀如果发额度太快瞬间让接受让缓冲区接下来继续发送此时数据就会丢包这种情况就得不偿失 那还不如发慢一点呢~
因此通过流量控制本质上就是让接收方来限制一下发送方的速度让发送的慢一点甚至阻塞一下
具体控制的方式是让 ACK 报文携带一个窗口大小的字段
当 ACK 为 1 的时候此时为ACK 报文窗口大小字段就会生效这里的值就是建立发送方发送的窗口大小 接收方计算窗口大小的方式简单粗暴直接使用接受缓冲区剩余空间作为窗口大小 用一张图生动解释一下 既然实际的发送窗口大小由流量控制和拥塞控制共同决定下面介绍拥塞控制
2.2.6 拥塞控制
滑动窗口的大小取决于流量控制衡量接收方的处理能力和拥塞控制衡量了传输路径的处理能力
互联网中的两台主机通信可不是拿一个网线直连的~ 在这中间包括很多路由器和交换机的如下图
从上面的图可以很明显看到传输路径上任何一个设备如果处理能力遇到了问题都会对整体的传输速率产生明显的影响~
拥塞控制做的事情就是衡量中间节点传输的能力
拥塞控制是要衡量中间路径如何衡量呢
如果通过中间路径有多少节点每个节点的当前情况是不好衡量的因为可能每次传输走的路径都不一样
拥塞控制的衡量方式这里采用的是实验的方式找到一个合适的发送速率开始的时候按照一个小的速率发送如果不丢包就可以提高一下速率扩大窗口的大小如果出现丢包则立即把速率再调小重复上述过程。同时网络拥堵的情况也不是一成不变的在时刻变化中此时拥塞控制这样的策略就是能很嗨的适应变化的网络环境
实际的发送方的窗口的大小 min(拥塞窗口流量控制窗口)
通过一张图理解拥塞窗口变化的策略趋势如下 第 1 阶段刚开始传输会给一个非常小的窗口比较小的初始速度称为慢开始第 2 阶段以指数增长速度非常快可以让窗口大小在短时间内就达到一个比较大的值快速地接近当前网络传输路径的能力瓶颈第 3 阶段指数增长到一定阈值就变成线性增长避免一下突然超过上限很多这样线性增长可以使传输速度逐渐接近传输上限增长到一定程度出现丢包认为当前窗口大小已经达到当前路径上的传输上限了第 4 阶段此时又立即把窗口大小回归到一个比较小的初始值重复上述过程第 5阶段以指数增长阈值变小很快就达到新的阈值变成线性增长与上述过程一致
2.2.7 延时应答
TCP 可靠性的核心是确认应答ACK 要发但不是立即发送而是稍稍等一会发送就是延时应答
通过上述 TCP 核心特点介绍TCP 中决定传输效率的关键元素就是窗口大小而窗口大小是通过流量控制和拥塞控制一起决定的其中流量控制的窗口大小是接收方接收缓冲区剩余空间的大小 如果立即返回一个 ACK 此时 ACK 里带有一个窗口大小设为 n如果稍等片刻再返回 ACK此时 ACK 的窗口大小大概率比 n 大因为等的这一小会应用程序从接收缓冲区里消费了一批数据了所以窗口变大了
由此可见延时应答的目的就是通过这个延时让接收方应用程序趁着这个时间多消费一些数据此时反馈的窗口大小就会更大一些这样发送方的发送率也就能快一些了同时满足接收方能够处理得过来
不是所有的包都可以延迟应答这里有两种情况
数量限制每隔 n 个包就应答一次时间限制超过最大延迟时间就应答一次
2.2.8 捎带应答
捎带应答是基于延时应答的字面意思就是带着一起发过去~
客户端服务器之间的通信模型通常是一问一答的这种模式通过下图进行解释 显而易见合成一个比分两次发效率要更高
因此相信小伙伴们已经知道为啥是四次挥手有可能是三次挥完同上述是捎带应答起的效果fin 和 ack 触发时机不同但如果在应用层调用 socket 的 close 方法触发 fin 和 内核负责 ack 是同一时机的时候ack 就可以捎带 fin捎带应答过去了~
2.2.9 面向字节流
我们知道 TCP 是面向字节流的这里暗藏一个问题粘包问题
举一个栗子吧如下小丁和小万的对话 小万的视角很好区分从哪到哪是一句完整的话因为小丁的说话习惯都是以小万开头容易区分 但是小丁的视角到底从哪到哪是一句完整的话呢难以区分这里的一句话就相当于一个应用层数据报
即当 A 给 B 连续发了多个应用层数据报之后这些数据就都积累到 B 的接收缓冲区中紧紧挨在一起此时 B 的应用程序在读数据的时候就难以区分从哪到哪是一个完整的应用层数据报很容易读出半个包或者一个半包等等
粘包问题的有效解决方式
定义分隔符约定长度
以上两种方式都是自定义应用层协议的注意事项HTTP 协议既会使用分隔符也会使用长度的策略~
Q不是定义了序号吗怎么会区分不了呢 A注意接收缓冲区已经是分用过的了把 TCP 报头都拆掉了只剩下应用层数据 TCP 载荷~
2.2.10 异常处理
这里列举 4 个 异常情况TCP 的处理
进程关闭/进程崩溃
进程没有了 socket 是文件随之被关闭虽然进程没有了但是连接还在仍然可以四次挥手进程关闭与四次挥手无关
主机关机正常流程关机
先杀死所有的用户进程这样进程没有了同理socket 随之被关闭也会触发四次挥手如果在关机这段时间挥完了更好如果没有挥完比如对方发过来的 FIN这边还没有来得及发 ACK就关机了此时对端就会重传 FIN重传几次后发现都没有 ACK尝试重置连接如果还不行就直接释放连接
主机掉电不考虑笔记本拔电源一下很快的关机
瞬间就关机了来不及进行任何挥手操作分两种情况
1对端是发送方 对端就会收不到 ACK就会超时重传几次超时重传后没有反应就重置连接释放连接 (收不到ACK —— 超时重传 —— 重置连接 —— 释放连接)
2对端是接收方 对端是没法立即知道这边是还没来得及发新的数据还是直接没有了TCP 内置了心跳包保活机制虽然对端是接收方对端会定时给这边发一个心跳包ping这边返回 pong如果每个 ping 都有及时的 pong说明当前对端的状态良好如果 ping 过去了之后没有 pong说明心跳没了这边挂了(不是说一发 ping 没 pong 就证明心跳没了因为 ping 和 pong 也有可能丢失比如连续几次都没 pong说明心跳没了)
心跳包的特点 a周期性 b如果心跳没了就挂了
网线断开 同 3 主机掉电的处理方式
这里只是介绍了 TCP 的十大核心特性TCP 还有很多特性~小伙伴们还可以继续深入了解
3. UDP 和 TCP 比较
连接TCP 是面向连接的UDP 是无连接的可靠性TCP 传输是可靠的而 UDP 传输不可靠传输形式TCP 以字节流的形式传输UDP 以数据段报文传输传输效率TCP传输效率慢所需要资源多而 UDP 传输形式快所需要资源少结构TCP 首部字节20-60UDP首部字节为8个适用场景TCP 适用于那些对数据准确性要求高于数据传输速度的场合例如网页浏览、电子邮件、文件传输FTP、远程控制、数据库链接UDP 适用于对速度要求高、可以容忍一定数据丢失的场合例如QQ 聊天、在线视频、网络语音电话、广播通信。容忍一定的数据丢失。
本期内容回顾 ✨✨✨本期内容到此结束啦~
