JavaEE初阶9.0 - 技术栈

为什么不把长度扩大到4个字节呢？不是技术问题更重要的是zz问题 UDP这样的协议已经被内置到各种操作系统中了一旦一方改了另一方不改这样就会导致两个设备无法UDP通信了谁先改谁就导致无法访问没改的设备这样只会把锅怪到windows上面 windows当然不认所以udp只能这个样子（升级类工作一定要考虑到兼容性的问题~）

(3)校验和

验证数据是否发生修改的手段

HTTPS的数字签名为了防止黑客篡改（防人）

UDP的校验和不是为了防人和安全性无关而是为了防止传输过程中的"比特翻转" 1变0 0变1

光信号电磁波电信号等等受到外界的干扰可能会是信号发生改变

发送之前先计算一个校验和把整个数据包的数据都代入把数据和校验和一起发送给对端

接收方受到之后重新计算一下校验和和收到的校验和进行对比（UDP发现校验和不一致就会直接丢弃）使用的是CRCC方式（ 循环冗余检验）

把每个字节都当作整数进行累加溢出也没有关系继续加最终得到结果传输到对端数据出现错误了对端再次计算校验和就会和第一个检验和不一样了

2.0 TCP/IP

(1)简介

(2)TCP协议报文格式

这个选项使得tcp的报头长度是可变的(选项可以有一个可以有多个）

固定部分是20字节了再算上选项肯定比15要多啊这里不是使用字节为单位而是使用4个字节为单位

UDP的问题是长度不够又不能扩展~ TCP的设计者考虑了这个问题它预留了一些保留位保留了一些核心内容

(3)核心机制1 确认应答

可靠性：100%做不到 A给B发了消息之后尽可能的让B收到

A能够知道B是否收到了

确认应答：对方返回一个"应答报文" 发送方收到应答报文就可以确认对方是收到了（当年发短信非常容易丢了~~）

产生后发先至的问题消息延迟我发了拒绝了然后后悔了发了改成同意吧结果对面先接收到同意的消息这个咋整嘞

为什么网络上会出现后发先至？

结婚的时候接亲的车队中可能有一辆车比头车先到女方家(因为路况红绿灯意外路线等等）

网络上转发数据每个路由器/交换机就相当于是十字路口

TCP的处理方案是给传输的数据进行编号第一条消息编号为1 上面图片里面的32位序号 32号确认序号就是用来处理这个问题的 ack为1 表示是应答报文

TCP是面向字节流的其实在编号的时候不是按照1条 2条这样的方式而是用字节来编号的

填写法是：把收到的数据载荷部分的最后一个字节序号+1 填写到确认序号中

引入序号之后接收方就可以根据序号对数据进行排序~ TCP需要处理这样后发先至的情况确保应用程序通过socket api读到的数据顺序是正确的~ // 缓冲区啥的（先到的车在村口等新郎的头车这里面在涉及到的在村口排队的操作就是缓冲区啥的）

(4)核心机制2 超时重传

针对丢包情况做出处理：

为啥会丢包呢：

网络结构非常复杂我们的数据包经过某个路由器/交换机已经非常繁忙了导致当前转发需要转发的数据量超出路由器/交换机的转发能力上限 (路口堵车）（不可避免地丢包）

假设丢包的概率是10% 连续两个包至少有一个达到的概率是95%

随着重传次数的增加数据报到达对方的概率增加~

引入超时时间来判定是否丢包：

TCP中判定超时的阈值是动态改变的（会延长这个时间阈值随着重传概率高了重传还不成说明我们增加了概率还不成功意味着当前丢包概率是一个非常大的数值意味着网络大概率已经出现严重故障了）哈哈类似医院抢救病人多多电击几次

A---->B B------>A 过程中发生丢包 A->B 发的数据丢了 B->A发的数据丢了

第二种情况：相当于B接收了两次A发送的请求呢收到了两份同样的数据万一是扣款呢这个时候之前了解的缓冲机制就发力了根据序号去重

综上：保证TCP可靠传输的机制是确认应答+超时重传

(5)核心机制3：连接管理

主要是建立连接和断开连接

连接：网路上的连接是抽象的通信双方各自保存对端的信息

建立连接：

TCP通过三次握手的方式来完成发送一个不携带业务的数据通过这个数据和对方"打个招呼"

中间那两个可以进行合并所以叫做三次握手

同步：在TCP中的同步指的是"数据上的同步" A告诉B 接下来我要和你建立连接据需要你把我的信息保存好同时你也把你的信息同步发过来同步报文表示状态并且各自给对方返回一个ack告知自己收到了~

主动的一方叫做客户端这里一定是客户端主动发起syn 客户端和服务器不是固定的只是一种关系

为什么TCP要三次握手，有啥用，解决了啥问题：

1.三次握手相当于投石问路 先初步探一探网络的通信链路是否通畅 （地铁早上的第一班车是不载客是为了验证的路线是畅通的~）

2.验证通信双方的发送能力和接收能力是否也正常~~（先打开QQ语音看看有故障没有）

3.三次握手过程中，可以协商一些关键信息~~ TCP要协商的一个非常关键的信息通信过程中序号从几开始初始序号一般不是从0开始的~ 并且两次连接初始序号都是不同的

断开连接：

四次挥手

FIN：Finish 结束报文 ACK：Acknowledgement的缩写代表"确认" 用于确认已成功接收对方之前发送的报文

为什么不能合并是因为ACK和FIN ？

这两次交互的时机是不同的如能有时候能有时候不能

ACK是内核控制返回的内核收到FIN 第一时间返回ack 和你应用程序的代码无关

FIN则是代码中调用socket.close才会触发的（进程结束也能触发）

第二个FIN的时机和ACK的时机很可能不是同一时机~

TIME_WAIT

TIME_WAIT 是TCP连接关闭后主动关闭方会进入的状态核心作用是确保连接正常终止避免旧报文干扰新连接默认持续是2MSL(报文最大生存时间通常是1--4min）

看四次挥手的图：A发送finish B收到之后发送ack(确认了我收到了)和fin 然后A接收到之后返回ack表示我也确认收到了

假设出现这样情况：如果B给A发FIN A收到了 A收到之后返回ACK把连接释放了但是这个返回的ACK万一丢包了呢没有给B发送过去这个时候B的FIN刚好重传可是A已经把连接释放了这个时候B怎么把它的FIN发送过去呢？就是下面的这个情况：

现实例子就是：我去送妹妹上学但是我不知道学校今天是否开着我带着妹妹到了学校大门口妹妹进去到了教室门口看一下如果教室有人就进去上课如果教室没人就回来在她从学校门口到到教室门口的时候我在外面等着等待最大时间为妹妹从学校大门口到教室门口的距离所花费的时间X2 如果超时了妹妹还没回来推断出妹妹应该是上课了我就回去了

CLOSE_WAIT

被动方已收到对方的FIN报文但是自身还没有调用close()关闭连接

这个地方在等待你的应用程序代码来调用close方法我们在写服务器代码的时候

原则上来说感知到对方断开之后就应该尽快的执行close~

如果你发现服务器这边存在大量的CLOSE_WAIT 持续的还很久此时意味着你的代码大概率有bug

(6)核心特性4 滑动窗口

滑动窗口：窗口是指发送方在未接收到接收方确认的情况下最多能连续发送的数据字节数窗口的大小由接收方通过TCP报文头部的窗口字段告知发送方因此窗口的大小是动态变化的

TCP协议保证可靠性的同时也是要付出代价的

窗口越大批发量的数据越多效率也越高但是窗口也不能无限大太大也会影响到可靠性

滑动窗口是在可靠传输的基础上提高效率这样只是亡羊补牢引入可靠性会使效率产生折损引入滑动窗口是要让折损更小这种方式可能效率比UDP这种还高~~

正常情况下就是单个传送这样的效率是很低的可以攒着一块发送

这样就相当于用一份时间等待多组ACK(把多组等待ACK的时间重叠成一份了）

B收到之后要怎么发呢有两种选择：一种是等这一组的所有ACK都回来再发第二组这么做花费的时间会更长更好的做法是收到一个ACK 就发下一条

这个过程丢包怎么办：

确认序号的含义：该序号之前的数据，都确认收到了~~~ 它是告知发送方：我们已经正确接收了确认号之前的所有字节下一步请给我发从这个确认号开始的数据

2001ack能够涵盖1001的含义这个过程丢包就像是下面的情况

情况1：数据已经抵达 ACK被丢了

对于这种情况不用做任何的处理因为后面一个ACK能够涵盖前一个ACK的含义

快速重传是TCP中加速丢失数据重传的机制

超时重传和快速重传这两个不是矛盾的机制即使相当于牛顿的经典力学和相对论之间的关系两者之间是相辅相成的一个是宏观世界的规律一个是微观世界的规律

情况2:数据包直接丢了

这种情况是直接丢包了

B收到之后仍然索要1001 三次重复的确认应答让A意识到1001-2000包怕是丢了 A重传1001-2000 B收到1001-2000后补全空的拼图至此拼图完整结束

(7)核心特性5 流量控制

滑动窗口窗口越大效率就越高但是不能无限大起来太大了会影响到可靠性接收方的处理能力也是有上限的

有一个TCP缓冲区

蓄水的速度就是发送方的速度放水的速度就是应用程序读取的速度

流量控制就是给发送方踩刹车让它发的慢点

流量控制可以让接收方根据自身处理数据的速度反馈给发送方限制发送方发送的速度

在ACK中依赖一个特殊的属性窗口大小

(8)核心特性6 拥塞控制

流量控制是依据接收方处理能力进行限制的

拥塞控制是依据传输链路的转发能力进行限制的

抽象一下发送方到接收方的过程中需要穿过一张由路由器构成的网络

这个过程中先按照小的窗口(小的速度) 先发着

如果发的时候很顺利不丢包就加大速度出现丢包就减小速度又不丢包了继续加大速度又丢包了继续减小速度慢慢的达成一种动态平衡这个就是拥塞控制的大体思想

面多加水水多加面~

呜这个图就表示了拥塞控制的工作过程慢启动指数增长线性增长丢包窗口变成最小值.........

(9)核心机制7 延时应答

默认情况下接收方都是在收到数据报第一瞬间就返回ack 但是可以通过延时返回ack的方式来提高效率

通过这样返回一个更大的窗口大小~~

应用程序能够处理的限度下，尽可能的增加窗口的大小（哈哈哈看到消息之后立马补好作业做好作业之后再给老师回消息理直气壮利用延时时间赶紧消费队列中的数据）

也不是100%能提高效率完全有可能在延时期间内接收方又收到其他数据导致效率更低了理论上不是100%提高效率但是从经验上大概率提高效率

不是所有的包都可以延时应答数量限制和时间限制综合来看的具体参数隔多少包隔多少时间不需要被背参数通常是可以调整的

(10)核心机制8：捎带应答

我们在返回业务数据的时候顺便把上次的ack带回去如果没有延时应答返回ack的时机和返回响应的时机就是不同的时机这两者中间可能干一点时间我们可以让ack往后面延时一下恰好这个时候要返回响应数据此时就可以把ack也代入到响应数据中一起返回

这样就可以一个数据包完全两件事这样把两个包合并成一个提高了效率封装分用

(11)核心机制9 面向字节流

粘包问题粘nian：粘的是"应用层数据包" 通过字节流方式传输，很容易混淆包和包之间的边界从而接收方无法区分本来发的是 aaa bbb ccc 但是接收到的是aaabbbccc 怎么拆分呢

上述问题在TCP层次上无解需要站在应用层解决定义好应用层协议明确包之间的边界

约定包和包之间的分隔符(aaa\nbbb\n\ccc\n) 这样就比较明确了

约定包的长度：约定每个包开头四个字节就表示这个数据包多长3aaa4bbbb5ccccc

在HTTP中这两种方式都有体现 GET请求没有body使用空行来作为结束标记 POST请求有body的时候通过Content-Length决定body多长

成熟的方案例如json protobuf都已经把粘包问题解决了

(12)核心机制10 异常情况处理

TCP通信过程中存在特殊情况某个进程崩溃了主机关机了主机掉电了网线掉开了

进程崩溃

和主动退出没有本质区别进程释放=> 回收文件描述符表的每个资源 => 调用socket的close

FIN 触发四次挥手

进程虽然没了但是TCP的连接信息还在（内核控制的）

主机关机了

正常流程关机本质上还是会先杀死所有的用户进程本质上和进程崩溃是一样的

也会触发四次挥手正常结束

但是如果没有挥完呢 B尝试重传几次主动放弃连接最后B仍然可以把连接释放掉~

主机掉电

拔电源（补药随便拔可能会出现问题笔记本有内置电池台式机这样的情况就不太乐观）

发送方突然掉电了 B突然发现A没有声音了此时B区分不了A是挂了还是暂时休息一会 B只能继续等但是不会无限等 B等待一段时间之后就会给A传输一个特殊的报文"心跳包" 不携带业务数据(载荷）只是为了触发ACK

虽然TCP内置了心跳包，实际开发中，通常还是会在应用层重新实现心跳包效果

网线断开

站在A的视角就是和我们刚才接收方掉电是一样的情况

站在B的视角就是和刚才上面发送方掉电是一样的情况

标志位的补充：

URG 紧急指针位 TCP正常来说是按照序号顺序发送和接收~

紧急指针相当于"插队" 跳过前面的数据，直接从某个指定的序号来开始

PSH：催促标志位接收方看到了这个就会尽快的把这个数据read到应用程序中

传输层不只有UDP和TCP两个协议也有一些专门的协议来应对~ 典型的是KCP（介于UDP和TCP之间的协议兼顾两个的优点）