JavaEE(系列21) -- 传输层协议UDP 和 TCP

哈士奇的奥利奥

于 2023-06-09 14:10:49 发布

阅读量1.6k

点赞数

分类专栏： JavaEE 文章标签： tcp/ip 网络 java-ee

本文链接：https://blog.csdn.net/weixin_46114074/article/details/131121920

版权

JavaEE 专栏收录该内容

22 篇文章 0 订阅

订阅专栏

3.2.1 数据偏移和选项(option)

4. TCP实现可靠传输的核心机制(重点)

5. TCP实现提高通信效率的核心机制(重点)

1. 应用层和传输层的联系

        在网络通信的过程中, 应用层描述了应用程序如何理解和使用网络中的通信数据, 和程序员打交道最多的就是应用层了, 针对不同的业务场景, 很多时候程序员需要去自定义应用层协议, 自定义协议主要需要完成下面的两件事情:

结合业务场景和需求, 分析清楚, 客户端和服务器之间(请求/响应)要传递哪些信息.
明确传递的信息要以什么样的格式来组织, 可以是普通文本的方式, 也可以一些广泛使用的数据格式, 比如: XML, json, protobuffer.

        其中xml和json都是按照文本的方式来组织的, 优点是可读性好, 用户不需要借助其他工具, 肉眼就能看懂数据的含义, 缺点是要额外传很多的标签或键名, 占用较多的网络带宽, 影响效率; 而protobuffer会将文本数据压缩为二进制数据传输, 特点是肉眼无法解析, 但占用空间更小小, 传输占用的带宽也就降低了.

        应用层也有知名并广泛使用的成品协议, 就比如 : HTTP协议.

除了最上层的应用层, 下面的传输层, 网络层, 数据链路层, 物理这四层都是已经在系统内核/驱动程序/硬件中已经实现好了, 不许要我们去实现, 传输层是紧接着应用层的一层, 虽然传输层是操作系统内核实现好了, 但是我们在写应用层代码的时候, 是要调用系统的socket API去完成网络编程, 所以需要我们了解这里传输层的一些关键协议UDP和TCP.

端口号:

端口号是传输层协议的概念, TCP和UDP协议的报头中都会包含源端口和目的端口, 并且都是使用2个字节, 16bit来表示端口号, 范围也就是 0 -> 65535; 但是我们日常写的程序使用的端口号一般都是从1024开始的, 因为0 -> 1023这个范围的端口号也称为 “知名端口号/具名端口号”, 这些端口号系统已经分配给了一些知名并广泛使用的应用程序.

这里我们并不是完全不能使用0 -> 1023这个范围的端口号, 只是建议使用, 虽然这些端口被分配给了特定程序, 但是这些程序是否在主机运行着, 主机上是否安装了这些程序都是不一定的, 要使用0 -> 1023这些端口, 需要注意2点 :

要确定这个端口没有和程序绑在一起.
要拥有管理员权限.

2. UDP协议

2.1 UDP简介

UDP是User Datagram Protocol的缩写, UDP的特点:

无连接
不可靠传输
面向数据报
全双工

UDP使用起来简单高效, 但它的数据载荷较小, 一般适用于以下场景：

包总量较少的通信（DNS、SNMP等）
视频、音频等多媒体通信（即时通信）
限定于LAN()局域网)等特定网络中的应用通信
广播通信（广播、多播）

2.2 UDP格式

也可以理解成下面的格式:

2.2.1 目的端口和源端口

UDP会把从应用层拿到数据(就是网络编程中应用层调用socket API, send()发送的数据)的基础上再前面拼装上8个字节的报头.

下面是各个部分占用的字节数.

2.2.2 报文长度

UDP的包长度, 也叫报文长度(报头+载荷), 这个属性表示了一个UDP数据报的大小, 单位为字节, 2字节表示 0->65535这个范围, 也就是说一个UDP数据报最大不超过64KB.

那如果应用层的数据报大于64KB怎么办呢?

这里有两种方案:

一是可以在应用层的代码层面将应用层的数据报手动进行分包, 这样拆分成多个小的包通过多个UDP数据报进行传输.
第二种方案是就不用UDP协议了, 改用TCP协议, TCP没有这样的限制的, 后文会介绍到.

2.2.3 校验和

检验和:

像这样的现象是客观存在不可避免了, 我们能做的只是及时的识别出当前的数据是否出现了问题, 因此就引入了校验和来进行鉴别, 校验和是针对数据的内容进行一系类的运算(每一个比特位都会参与运算)得到一个比较短的结果, 我们可以认为, 数据内容一定, 得到的校验和就是相同的, 如果我们的数据变了, 那么的校验和就变了, 如此即可验证得到数据是否准确.

比如发送方要发送的数据是 “反射导弹”, 计算出来的校验和也会放到报头中发送, 当接收方拿到数据就会有两种情况了, 第一种情况是接收方拿到数据后重新计算一个校验和, 得到的结果如果和拿到的校验和相同, 就认为数据是正确的, 不同, 则认为数据不正确.

3. TCP协议

3.1 TCP简介

TCP, 即Transmission Control Protoco, TCP协议相比于UDP协议要更复杂,

TCP的特点:

有连接
可靠传输
面向字节流
全双工.

TCP对数据传输提供的管控机制，主要体现在两个方面：安全和效率。
这些机制和多线程的设计原则类似：保证数据传输安全的前提下，尽可能的提高传输效率。

3.2 TCP格式

3.2.1 数据偏移和选项(option)

数据偏移和选项(option), 选项可有可无也可以有多个, 用于对TCP一些功能的扩展和TCP中的一些属性进行解释说明, 可能包括 “窗口扩大因子”, “时间戳” 等选项, 数据偏移表示TCP数据起始处与TCP报文起始处之间的距离, 也就是4个比特位(0到15)表示TCP首部报头的长度, 单位是4字节;

正是由于TPC当中有了数据偏移和选项这两个属性, 致使使TCP的报头长度是可变的, 不像UDP一样固定是8字节, 选项之前的部分是固定的长度(20字节), 选项长度 = 首部长度 - 20字节, 通过首部长度就可以去调节选项长度; 如果首部长度值是5, 表示整个TCP报头是20字节(相当于没有选项), 如果首部长度值是15, 表示整个TCP报头是60字节(选项部分就是40字节), 填充是为了保证选项为32比特的整数倍.

3.2.2 保留项

数据偏移后面还有6位保留项, 这里保留项的存在是为了未来TCP协议的拓展升级准备的, 网络协议的拓展升级是一件成本极高的事情, 比如现在UDP协议报文长度是最大是2字节(64KB), 如果想要升级一下让UDP的报文支持更大的长度, 在技术上可以实现, 但实际上要想让世界上所有能上网的设备所安装的各式的操作系统都能够同步完成升级, 支持新的UDP, 这是不现实的; 一种系统升级了, 其他系统不升级, 就办法进行通信了…

而像TCP这样引入了 “保留位”, 如果在未来想要引入一些新的功能, 就可以使用这些保留位, 这样对于TPC本来的报头结构影响是比较小的, 针对不升级的设备也更容易兼容就版本的TPC.

3.2.3 6位控制位

6位控制位从左至右分别为 , URG, ACK, PSH, RST, SYN, FIN, 含义如下:

URG(Urgent Flag):该位为1时, 表示包中有需要紧急处理的数据.
ACK(Acknowledgement Flag)该位为1时, 确认应答的字段变为有效, TCP规定除了最初建立连接时的SYN包之外该位必须设置为1.
PSH(Push Flag):该位为1时, 表示需要将受到的数据立刻传给上层应用协议, PSH为0时, 不需要立即传而是先进行缓存.
RST(Reset Flag):该位为1时表示TCP连接中出现异常必须强制断开连接.
SYN（Synchronize Flag）:用于建立连接, SYN为1表示希望建立连接, 并在其序列号的字段进行序列号初始值的设定(Synchronize本身有同步的意思, 也就意味着建立连接的双方, 序列号和确认应答号要保持同步).
FIN(Fin Flag):该位为1时, 表示今后不会再有数据发送, 希望断开连接.

3.2.4 32位序号和32位确认序号

32位序号和32位确认序号和TCP确认应答机制有关

3.2.5 16位窗口和滑动窗口

16位窗口和滑动窗口, 流量控制机制有关;

3.2.6 16 位紧急指针

16 位紧急指针要配合URG控制位一起使用的, 用于指明紧急数据之后正常数据的起始位置;