[TCP/IP] 传输层代表协议--UDP协议介绍:UDP协议格式、端口号在网络协议栈那一层工作...
TCP/IP网络模型, 将网络分为了四层:
HTTP和HTTPS这两个协议为代表, 简单介绍了应用层协议. 实际上, 无论是HTTP还是HTTPS等应用层协议, 都是在传输层协议的基础上实现的UDP和TCP协议了. 以HTTP为例, 在使用HTTP协议通信之前, 是先需要建立TCP连接的.UDP协议开始再谈端口号
UDP/TCP Socket时, 都对服务器绑定过端口号. 在实际通信中, 当一个客户端向服务器发送数据时, 服务器主机接收到数据之后, 操作系统会 根据报文中的端口号 将数据推送给对应的进程TCP/IP协议中, 通过 源IP、源端口、目的IP、目的端口、协议号 这样一个五元组标识一个通信IP标记主机唯一性(用来寻找主机), 端口号标记进程唯一性(用来选择主机中的进程)端口号实际是传输层的内容, 因为传输层向上就是应用层了, 那么传输层就需要解决将数据交给上层哪一个进程的问题IP则是解决报文在网络中进行路由的问题, 需要通过 源IP和目的IP解决从哪来到哪去 的问题IP和端口号, 是会使用在TCP/IP的不同层次中的: IP使用在网络层, 端口号则使用在传输层端口号划分
0~665350~1023是知名端口号, 它特定分配给一些知名的应用层协议使用, 比如:-
SSH服务器, 使用22端口 -
FTP服务器, 使用21端口 -
TELNET服务器, 使用23端口 -
HTTP服务器, 使用80端口 -
HTTPS服务器, 使用443端口 -
知名端口号在
/etc/services文件中存储着, 可以进行查看![]()
1024~65535, 就是操作系统可以动态分配的端口号, 也可以被指定.UDP协议
sendto()等一系列系统调用时, 并不是直接将数据发送到了另一套主机上, 而是由操作系统给网络的下一层, 添加对应的协议报头:
UDP协议的格式UDP协议格式
UDP协议的格式可以用一张图来表示
UDP协议报头部分是固定的8个字节, 剩下的则是应用层传输过来的原始数据, 即有效载荷UDP协议的报头非常容易理解实际上,
TCP/IP的每层都要考虑如何封装、解包和分用的问题
UDP协议使用固定长度的报头长度, 就很好的解决了如何封装和解包的问题UDP协议发送数据时, 只需要在原始数据前加上这8字节的报头就可以 实现封装UDP报头的内容了UDP报头中存在 16位的源端口号 和 16位的目的端口号. 当主机接收到UDP报文之后, 读取报头中存储的 16位目的端口号, 就可以知道要向哪一个应用层进程的可用空间传输数据了. 即 可以实现分用Linux中, 一切皆文件. 我们之前也介绍过
socket套接字, 实际就是文件描述符当传输层协议知道应用层对应服务的端口号之后, 就可以找到对应的进程, 然后就可以找到进程对应的网络文件, 将数据写入到网络文件的文件缓冲区中
进程服务就可以读取数据了
16位UDP长度该作何理解呢?16位UDP长度表示, UDP报文的整体长度, 而不是单指有效载荷的长度UDP协议的特点之一是 面向数据报UDP数据报都应该是完整的. 两个数据报之间是具有明显的边界的.UDP报文时, 可以通过读取每个报头中的UDP长度来准确的获取到完整的UDP报文, 而不产生混乱16位检验和则用于检验报文内容是否出现了差错等, 如果出现了差错操作系统就会直接丢弃掉整个报文(这就是UDP协议 不可靠 的表现)
UDP协议的不可靠是否看作一种缺点?不能将 不可靠 看作
UDP协议的缺点, 不可靠 是UDP协议的特点使用
UDP协议通信, 数据报发生损坏会被直接丢弃. 这使UDP协议可以使用在一些 对数据丢失有一定的容忍度的 一些特定的场景中, 比如: 视频直播视频直播可以容忍短暂的卡顿和画面丢失, 但是需要保证直播内容的持续输出. 类似这样的场景中,
UDP协议可以很好的适配也就是说, 不可靠 不是一种缺点 而是一种特点, 可以用在更合适的场景中
UDP不可靠, 也就意味这它不用像TCP那样 需要做一系列的保证数据可靠的操作和处理, 也就不用非常的复杂
UDP协议的格式就是8字节的UDP报头+原始数据UDP协议报头在Linux中的格式
UDP协议通信时, 操作系统在传输层添加协议报头时, 是以什么形式添加的, UDP报头的本质是什么?TCP/IP是在Linux内核中实现的, Linux内核是由C语言实现的UDP报头的实现就是一个结构体:
UDP协议封装数据时, 是以结构体的形式添加的UDP协议报头, 因为UDP协议报头的格式在Linux内核中的实现方式就是一个结构体UDP协议创建网络套接字时候, 需要将套接字bind()到特定的端口上sendto()进行发送数据时, 操作系统就会创建udphdr对象并填充端口号、内容以及检验和. 并将udphdr对象以一定的形式拷贝到原始数据之前. 形成一个完整的UDP报文UDP的缓冲区
在Linux系统中, 我们无论使用
UDP还是TCP进行通信, 无论是使用sendto()还是write()向网络中发送数据实际上, 在函数执行完毕之后都没有直接将数据发送到网络中, 而是在操作系统对数据进行处理了之后, 将数据放入到 发送缓冲区 中, 什么时候真正的发送出去, 由操作系统内核决定
所以, 要理解一个东西:
sendto()和write()并不是发送的接口, 而是拷贝的接口. 调用这两个接口, 都只是将数据拷贝到内核中, 而不是制剂发送到网络中或者直接写入到内核中接收数据也是一样的, 操作系统接收网络数据时, 从网络层到传输层 也会将数据暂时存储到接收缓冲区, 等待内核中传输层的接收、解包以及分用
UDP协议在内核中并没有真正意义上的发送缓冲区UDP协议在发送数据时, 操作系统需要对数据进行的处理动作很简单, 毕竟udphdr是一个很简单的只有8字节的结构体, 只需要添加一个结构体就可以. 并且UDP协议不需要保证数据可靠性, 这也就意味着UDP协议不需要将发送的数据在本地长时间维护, 也就不需要一个真正的发送缓冲区sendto()将数据交给内核时, 内核会尽快的将数据发送到网络层, 不需要在传输层存储数据UDP协议并没有发送缓冲区, 但 UDP协议是有接收缓冲区的UDP报文数据, 并且 针对每一个UDP套接字都会维护那一块空间, 这就是内核中UDP的接收缓冲区UDP协议数据报时, UDP协议会对UDP数据报进行解包, 然后再将数据存储到对应UDP Socket的接收缓冲区中, 这个过程实际就是UDP协议对UDP数据报解包和分用的过程UDP协议是面向数据报的. 使用UDP协议通信发送数据时, 都是以一个数据报一个数据报的形式发送的. 但是UDP协议的接收缓冲区是 不保证 接收到UDP数据报的顺序 与 发送端发送UDP数据报的顺序 是一致的(即, 如果发送端按照12345的顺序发送数据报, 接收端很可能并不是按照12345的顺序接收到的)
UDP数据报的发送顺序与接收顺序可能一致, 也体现了UDP协议的不可靠性因为无法保证
UDP数据报的接收顺序, 所以如果有顺序一致的需求, 那么接收端就需要对UDP数据报进行重排序, 一般在发送方和接收方的应用层实现
UDP协议接收缓冲区满了之后, 再发送过来的UDP数据报会被直接丢弃
UDP协议发送端与接收端的 发送 与 接收 是互不影响的, 所以UDP协议是全双工的. 使用UDP协议可以同时发送和接收数据报
UDP报文大小
UDP报文首部中, 有一块16位的空间 是用来存储UDP报文总长度的UDP报文, 最大也就 2的16次方个字节, 即 64KB(包括8字节首部)64KB在现在是非常的小的. 那么, 如果使用UDP协议传输大一点(超过64KB)的文件时, 就需要在应用层进行分包, 多次发送. 对应的, 接收端同样需要对接受的数据进行手动拼装.UDP协议简单介绍的全部内容了作者： 哈米d1ch 发表日期：2024 年 1 月 8 日