【JavaEE精炼宝库】网络原理基础—

【JavaEE精炼宝库】网络原理基础——UDP详解

文章目录

一、应用层
二、传输层
- 2.1 端口号：
- 2.2 UDP 协议：
- - 2.2.1 UDP 协议端格式：
  - 2.2.2 UDP 存在的问题：
- 2.3 UDP 特点：
- 2.4 基于 UDP 的应用层协议：

一、应用层

我们 Java 程序员在日常开发中，最经常与应用层打交道，在应用层一般是使用 HTTP 协议与自定义协议。

如何自定义协议?
答：

确定传输信息。
确定数据格式（xml、json、yml、protobuffer）。

二、传输层

负责数据能够从发送端传输接收端。

2.1 端口号：

端口号(Port)标识了一个主机上进行通信的不同的应用程序。
在这里插入图片描述

端口号范围划分：

端口号是两个字节无符号整数（0 ~ 65535）。

0 ~ 1023 知名端口号： HTTP、FTP、SSH 等这些广为使用的应用层协议，他们的端口号都是固定的。
1024 ~ 65535 操作系统动态分配的端口号： 客户端程序的端口号，就是由操作系统从这个范围分配的。

常见知名端口号（well-know port Number）了解即可:

ssh 服务器，使用 22 端口。
ftp 服务器，使用 21 端口。
telnet 服务器，使用 23 端口。
http 服务器，使用 80 端口。
https 服务器，使用 443 端口。

我们自己写一个程序使用端口号时，要避开这些知名端口号。

端口号的两个常见问题：

问题1：一个进程是否可以同时绑定多个端口号？
答：可以。这个是非常可行的，而且在日常开发中经常使用到。举个栗子：一个服务器绑定两个端口，一个端口给普通用户使用，另一个端口给程序员 + 运营人员使用，以便进行日常维护，两个端口的功能可以是不一样的。
问题2：一个端口号是否可以同时被多个进程绑定？
答：不能。好比“一山不容二虎，除非一公一母。”如果一个服务器是 TCP，一个是 UDP 此时，端口号即使在同一时刻重复了，是不影响的（一公一母），但是如果两个 TCP 或者两个 UDP，在同一时刻，使用同一个端口号，就会出现绑定失败的情况。

2.2 UDP 协议：

2.2.1 UDP 协议端格式：

下面 16 位指的是 16个bit 位。

16 位 UDP 长度，表示整个数据报（UDP 首部 + UDP 数据）的最大长度。
如果校验和出错，就会直接丢弃。
各个术语在下面会做出详细介绍。

上面那张图由于排版问题，画的不是很好，下面我给出一张更加清晰的图：

一个 UDP 数据报由报头和载荷构成。

源端口号：发送端的端口号。
目的端口号：接收方的端口号。
UDP 长度：整个 UDP 数据报占多少个字节。
UDP 校验和（UDP Checksum）：UDP 校验和是用于检测 UDP 数据报在传输过程中是否发生错误的一种机制。 举个栗子：如果发送方计算得到的校验和为 0x1234，接收方接收到数据后按照相同的算法计算校验和，在传输的过程中可能会出现 bit 翻转的情况，如果结果也为 0x1234，则说明数据在传输过程中没有发生错误。

UDP 中使用 CRC 算法来作为计算校验和的算法。 CRC 是一个简单粗暴的计算校验和的方式，循环冗余校验（校验和不是为了得到确切的值，只是为了判断算出来得值是否一样）。例如：设定 2 个字节得变量，把数据得每个字节取出来往这个变量上进行累加。如果结果溢出超过 2 个字节，溢出部分舍弃。

2.2.2 UDP 存在的问题：

UDP 长度描述了整个 UDP 数据报占的字节数，通过 UDP 长度，就能知道载荷一共是多少字节（全部的字节数 - 报头字节数）。

无符号 2 字节数的范围为：0 ~ 65535（1024 * 64）。也就是说一个 UDP 数据报最长就是 64 KB，不能再长了。对于现在来说有点短，随便拿手机拍个照片，10 MB左右，所以使用 UDP 开发程序会有很大的制约。最好的解决方法是将 UDP 改写成 TCP，TCP 对于应用层数据包的大小是无限制的。

既然 UDP 有上面的长度限制，那么为什么不对 UDP 进行升级呢？

答：这里的升级难点不在于技术，而是 zz 问题，升级到更高的字节数，成本很高。单个主机升级是没有意义的，需要对端一起升级（不然会出现解析错误的情况），由于 UDP 是系统内核实现的，如果全世界都是使用同一个操作系统，升级的成本还会小一点，但是市面上存在各种各样的操作系统，很难统一升级。