JavaEE 初阶第二十一期：网络原理，底层框架的“通关密码”(一)
专栏：JavaEE初阶起飞计划
个人主页：手握风云
目录
一、UDP协议
1.1. UDP协议端格式
1.2. UDP的特点
1.3. UDP 的典型应用场景
二、TCP协议
2.1. TCP协议段格式
2.2. TCP的核心机制
2.2.1.确认应答
一、UDP协议
1.1. UDP协议端格式
学习网络协议，主要就是学习它的一个协议格式。各个协议的特性各种特点，它其实就能够通过这个协议格式上充分的体现出来。协议的格式就要约定数据的组织以及包含什么样的信息。
UDP报头的总长度为8个字节，分为4个部分，每个部分2个字节，分别是源端口、目的端口、UDP长度
- 源端口：数据发送端（发起通信的一方）应用程序所使用的端口号，用于接收端在回复数据时，准确定位发送端的对应应用程序。
- 目的端口：数据接收端（响应通信的一方）应用程序所使用的端口号，用于发送端明确 “数据要发送给接收端的哪个应用程序”。
- UDP长度：报文和载荷的总长度。UDP长度有这么个不好的点。2个字节，表示的数据范围0——65535，也就是一个UDP数据报最大长度为64kb。如果需要传输的数据比较大，就可能会装不下。比如我们在百度或者搜狗搜出来的广告内容，有的就比较复杂，像下图这种带有图片的，就有可能突破64kb的上限。
对于上面问题的解决方案：1. 对应用层的数据进行拆分，但是这个开发量非常巨大。2. 换成TCP协议。
但其实要想UDP长度扩充一些，技术上只需要修改下格式。但是哪些设计UDP协议却没有这样做，这是因为具体实施起来需要通信双方的设备都得一起升级，才能有效。世界上的任意两个设备之间都可能使用 UDP 进行通信一旦进行升级，一定会出现，一部分设备是新版本，一部分设备是旧版本的情况。新版设各和旧版设备就无法正确通信了，造成的后果难以量。
协议标准好升级，协议具体的实现，是在各种操作系统厂商手里。
- 校验和：验证UDP数据是否在传输中出错。网络数据包在传输过程中会发生出错，数据包本质上电信号、光信号或者电磁波。这个出错的情况叫比特翻转，而这个比特翻转是客观存在的，无法避免，校验和就是用来甄别当前数据是否有错。
校验和具体是怎么工作的：发送方构造 UDP 数据报，构造完成之后，把数据报的每个字节的数据都进行累加，结果累加到一个16位的整数上，此时得到的结果就是校验和check1，填充到 UDP 报头的校验和字段。接收方收到 UDP 数据报之后，就会按照相同的算法，再计算一遍校验和 check2。接收方就可以比较 check1 ==check2。如果相等，就可以视为数据传输是正确的；如果不相等，说明数据传输出错了。
发现校验和不一致，就意味着一定是发送的数据和接收的数据其中的某个字节或者比特位出现问题了。虽然不知道是哪个比特位出错了，但是可以知道出错还是没出错。如果出错了就把数据丢弃掉即可。
1.2. UDP的特点
UDP 的传输过程类似 “寄信”，无需提前建立通信链路，也不保证数据能准确送达。
- 无连接：知道对端的 IP 和端口号就直接进行传输，不需要建立连接。
- 不可靠：没有确认机制，没有重传机制；如果因为网络故障该段无法发到对方，UDP 协议层也不会给应用层返回任何错误信息。
- 面向数据报：UDP 对应用层数据的处理方式是 “原样转发”，不拆分、不合并，数据报是其最小传输单位，具体表现为。应用层交给 UDP 的 “一整段报文”，UDP 会原样封装成一个 UDP 数据报发送，不会拆分；接收端必须通过一次 recvfrom 调用接收完整的 UDP 数据报，不能分多次读取。
1.3. UDP 的典型应用场景
UDP 适合 “实时性优先于可靠性” 的场景。
- DNS（域名解析）：解析请求 / 响应数据量小，需快速返回，丢包可重试；
- DHCP（动态主机配置）：主机启动时获取 IP 地址，需快速建立通信，无需长期连接；
- TFTP（简单文件传输）：用于小型文件传输（如路由器固件更新），协议简单，避免 TCP 连接开销；
- NFS（网络文件系统）：局域网内文件访问，实时性要求高于可靠性；
- 其他：视频流、语音通话、广播 / 组播（UDP 支持一对多传输，TCP 仅支持点对点）。
二、TCP协议
2.1. TCP协议段格式
- 16 位源端口号：标识发送方的应用程序（如浏览器、服务器进程），让接收方知道 “数据从哪个应用发来”。
- 16 位目的端口号：标识接收方的应用程序，让发送方知道 “数据要交给哪个应用处理”。
- 4 位首部长度：表示 TCP 首部的总长度（单位：4 字节）。例：若值为
5，则首部长度为5*4字节（无选项时的最小长度）；若有 “选项”，最大值为15（对应首部60字节）。 - 保留（6 位）：预留未来使用，当前置0。
- 16 位检验和：和UDP校验一样，对 “TCP 首部 + 数据” 整体做校验，检测传输中的比特错误（如网络干扰导致数据翻转）。若校验失败，报文段会被直接丢弃。
- 16 位紧急指针：仅当URG=1时有效，标识紧急数据在报文段数据部分的末尾位置（是相对于 “序号” 的偏移量），让接收方优先提取紧急数据。
2.2. TCP的核心机制
发送的数据，能够知道对方是否收到，就可以认为是“可靠传输”。如果知道对方收到了,传输成功；如果知道对方没收到(丢包)，采取其他措施补救。
2.2.1.确认应答
比如我向别人发送信息——一起去吃饭，别人给我回复——好啊好啊，别人给我回复的信息就可以看作应答报文。如果这个人没有回复，就可以看作丢包。
这里面还涉及到另一个问题，如果我再给这个人发送另一个信息，他也会给我回复。在网络中会出现后发先至的情况，先回复的信息的数据包却是后到达，就会造成歧义。
为什么会网络中出现后发先至，这是因为网络中有许多的路由交换机，一系列的数据包传输过程中不一定是按照相同的路线转发的，不同的路线，有的可能堵，有的可能通畅。
为了解决上述问题，引入"序号和确认序号"对于传输的数据进行标识。我发送给别人的信息可以看作序号，别人会给我的就是确认序号。TCP 是字节流传输，序号和确认序号是针对"字节"进行编号的。一个 TCP 数据报，包含多个字节，编号又是连续递增的，只要知道 TCP 载荷的第一个字节的编号是多少，后面的每个字节的编号就都知道了。
同一个 TCP 连接内,序号会持续累加，下一个数据报的序号在上一个数据报最后一个字节的序号基础上继续递增。确认序号只在应答报文ACK中生效。当ACK这一位为1时，确认序号字段就会有效，否则属于是“无效字段”。确认序号根据收到的数据的最后一个字节的序号+1进行填充。
