【网络】传输层协议UDP

之前我们已经把应用层http协议说完了,我们知道一些优秀的应用层协议会绑定知名端口号,就是说它们的端口号默认是固定的,比如http是80,https是443,ssh是22等,我们也可以通过查看下面的文件来查看知名端口号

复制代码
cat /etc/services

并且我们还要知道端口号到进程是唯一的,就是说,一个进程可以绑定多个端口号,但是一个端口号只能被一个进程绑定

下面我们正式进入UDP
UDP 全称用户数据报协议(User Datagram Protocol)

下面是UDP的报文格式

我们说传输层协议是操作系统的一部分,所谓的协议在C语言中不过是结构体,我们可以在Linux内核源代码中看到相关结构体定义

也就是说报头占8个字节,这里的16位UDP长度指的是报头+正文的总长度(字节),16位表示的最大的数是2^16-1,也就是说UDP一次发送的报文长度是64kb-1,如果一次发送的数据超过这么多,sendto就会调用失败
一个很关键的问题就是UDP如何解包和分用,解包其实就是通过16位UDP长度,这个长度减去报头的八个字节其实就是报文的长度

并且根据目的端口号就可以向上交付给应用层的某个进程,如何通过端口号找到相对应的进程呢?我们可以认为OS为我们维护一张hash表,表中存着端口号到进程PCB的映射关系
UDP没有发送缓冲区,并且它也不需要,调用sendto时数据会直接交给内核,内核将数据交给下面的网络层进行后续的传输动作

但是UDP是有接收缓冲区的,但是这个接收缓冲区不能保证收到的UDP报的顺序和发送UDP报的顺序一致;并且如果缓冲区满了,再到达的UDP数据就会被丢弃

这也就是为什么UDP是不可靠的,当然我们不能把它看成一种缺点,而是一种特点,因为不可靠也就决定了它是比较简单的;如果要添加可靠性,那协议就会复杂,这样的协议叫做TCP
UDP的特点:

**无连接:**知道对端的IP和端口号就直接进行传输,不需要建立连接

**不可靠:**没有确认机制,没有重传机制;如果因为网络故障没有把信息发到对方,UDP协议层不会给应用层返回任何错误信息

**面向数据报:**发送方如何发,接收方就要如何收(调用多少次write,就要调用多少次read),不能够灵活的控制读写数据的次数和数量

相关推荐
liulilittle6 小时前
关于拥塞控制的几点思考
网络·c++·tcp/ip·计算机网络·信息与通信·tcp·通信
AOwhisky7 小时前
MySQL 学习笔记(第四期):SQL 语言之多表查询
linux·运维·网络·数据库·笔记·学习·mysql
Phantom Void7 小时前
服务器处理客户端请求的设计方法
linux·运维·网络
王码码20357 小时前
办了500M宽带看视频还是卡?我用NAS搭了个测速服务器,宽带有没有缩水一测便知
网络·接口·nas
ylscode7 小时前
Anthropic Claude Oceanus意外泄露:Mythos系列AI红队测试遭遇API代理滥用危机
网络·人工智能·安全·web安全·安全威胁分析
myenjoy_19 小时前
MQTT 与 Sparkplug B——从车间到云端的最后一公里
网络·python
8125035339 小时前
第13篇:TCP vs UDP——可靠与速度的博弈
网络协议·tcp/ip·udp
2401_8734794010 小时前
企业安全运营中,如何用IP离线库提前发现失陷主机?三步实现风险画像
网络·数据库·python·tcp/ip·ip
代码中介商12 小时前
HTTP 完全指南(最终篇):CORS 跨域资源共享深度详解
网络·网络协议·http
liulilittle12 小时前
过冲:拥塞控制的呼吸与盲行
linux·网络·c++·tcp/ip·计算机网络·tcp·通信