本文主要是介绍【传输层协议】UDP协议 {端口号的范围划分;UDP数据报格式;UDP协议的特点;UDP的缓冲区;基于UDP的应用层协议},希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!
一、再谈端口号
1.1 使用“五元组”标识一个通信
端口号(Port)标识了一个主机上进行通信的不同的应用程序
在TCP/IP协议中, 用 “源IP”, “源端口号”, “目的IP”, “目的端口号”, “协议号” 这样一个五元组来标识一个通信(可以通过netstat -n查看);
netstat 查看网络状态的重要工具
1.2 端口号的范围划分
- 0 - 1023:这个范围内的端口号被保留用于一些特定的服务和应用程序,称为“系统端口”或“熟知端口”Well-Know Port Number)。例如:HTTP, FTP, SSH等这些广为使用的应用层协议, 他们的端口号都是固定的。系统一般不允许用户自己绑定这个范围内的端口号。
- 1024 - 65535:这个范围内的端口号大多数是可以自由绑定的,但也有个别例外,比如mysql绑定3306号端口。除去这些例外,其他的端口号可以由用户显式bind绑定,也可以由操作系统动态分配(客户端端口号绑定)。
常用的熟知端口
有些服务器是非常常用的, 为了使用方便, 人们约定一些常用的服务器, 都是用以下这些固定的端口号:
- ssh服务器, 使用22端口
- ftp服务器, 使用21端口
- telnet服务器, 使用23端口
- http服务器, 使用80端口
- https服务器, 使用443端口
提示:在
/etc/services
文件中可以查看到系统中所有的知名端口号。我们自己编写的程序使用端口号时, 要避开这些知名端口号.
两个问题
- 一个进程是否可以bind多个端口号?当然可以,一个进程可以从多个端口收发数据。
- 一个端口号是否可以被多个进程bind?不可以,端口号指向系统中唯一的一个进程。
介绍两个小工具:
pidof <进程名>
:通过进程命查看进程ID,在查看服务器的进程ID时非常方便。... | xargs proc ...
:xargs可以将前面命令行中管道文件的输出转换为之后程序的命令行参数。
打一套组合拳:
二、UDP协议
2.1 UDP数据报格式
UDP(User Datagram Protocol,用户数据报协议)是工作在OSI(开放系统互连,Open Systems Interconnection)模型中传输层的一种协议,使用IP作为底层协议。UDP协议的格式相对简单,主要由以下几个部分组成:
UDP数据报分为首部和用户数据部分,整个UDP数据报作为IP数据报的数据部分封装在IP数据报中。UDP数据报文结构包括:
- 源端口号(Source Port):占用2个字节(16位),表示发送方端口号。在要求对方回信时选用,不要求时可使用全0。
- 目的端口号(Destination Port):占用2个字节(16位),表示接收方端口号。在终点交付报文时必须使用。
- 长度(Length):占用2个字节(16位),表示UDP数据报的长度,包括首部和数据部分。其标定的长度最小值是8B(只有首部),最大值是2^16 = 64KB。
- 校验和(Checksum):占用2个字节(16位),用于检测UDP数据报在传输过程中是否有错误。如果检测到校验和出错,就会直接丢弃该报文。
- 数据(Data):占用0个或多个字节,是实际传输的数据部分。
UDP如何将报头与有效载荷进行分离?
- UDP采用定长报头,UDP在读取报文时读取完前8个字节后剩下的就都是有效载荷
UDP如何决定将有效载荷交付给上层的哪一个协议?
- UDP是通过报头当中的目的端口号来找到对应的应用层进程的,即由目的端口号决定。
- 当UDP数据报到达时,操作系统会根据目的端口号找到相应的应用程序或服务,并将数据报交付给它进行处理
在Linux内核中数据报是怎样被封装和管理的?
-
首先Linux内核是使用C语言编写的,那么UDP作为传输层协议(内核中)自然也是一样。
-
所以UDP报头结构在内核中其实就是一个结构体类型:
-
所以当应用程调用sendto接口发送数据时,系统就会创建并填充UDP报头。
-
sk_buff(socket buffer)结构是linux网络代码中重要的数据结构,它负责管理和控制接收或发送数据包的信息
-
sk_buff结构其实就是对数据报的封装,将UDP协议的报头和数据内容封装成一份完整的数据报。
-
sk_buff结构中包含prev和next指针,操作系统将所有进程发出的sk_buff通过链表组织到一起,按序发送到网络。
-
对端主机将接收到的数据存入新创建的sk_buff结构当中,并依据端口号将其分派给对应进程的UDP接收缓冲区。
-
客户端调用recvfrom接口从UDP缓冲区读取数据,得到源端口号和报文内容。
注意:sk_buff结构较为复杂,上面的内容只是我片面的理解,甚至可能存在错误。
详情请阅读:Linux内核:sk_buff解析 - 唐稚骅 - 博客园 (cnblogs.com)
2.2 UDP协议的特点
- 无连接:UDP在发送数据前不进行连接,发送结束时也没有连接可以释放,减少了开销和发送数据之前的时延。
- 不可靠:没有确认机制,没有重传机制,如果因为网络故障使该段无法发送到对方,UDP协议层也不会给应用层返回任何错误信息。也正是因为UDP不保证可靠交付,使得主机不必维持复杂的连接状态。
- 面向报文:发送方的UDP对应用程序交下来的报文,再添加首部后就向下交付IP层。UDP对应用层交下来的报文,既不合并,也不拆分,而是保留这些报文的边界。发送方发送了多少次数据报,接收方就需要接收多少次,不能一次性合并接收,也不存在接收到不完整的数据报。
- 无拥塞控制:很多实时应用(如IP电话、实时视频会议等)要求源主机以恒定的速率发送数据,并且允许网络发生拥塞时丢失一些数据,却不允许数据有太大的时延,UDP正好适合这种要求。
- 首部开销小:UDP只有8个字节的首部,适用于对时间敏感、但对可靠性要求不高的应用场景。
- 全双工通信:虽然UDP没有发送缓冲区,但是UDP的socket既能读,也能写,所以也是全双工通信协议。
综上所述,UDP协议的格式简单,开销小,适用于对实时性要求较高但对可靠性要求不高的应用场景。
面向数据报
-
应用层交付给UDP多长的报文,UDP就原样发送,既不会拆分,也不会合并,这就叫做面向数据报。
-
可以想像成快递:你朋友给你发了1个快递,你就只能收1个快递,你不能只收0.5个快递,也不能收2个快递,你只能收1个,即发多少就收多少。
-
UDP发送的数据不能太大,UDP的报文最大长度是64KB(UDP首部+UDP数据)
-
如果需要传输的数据超过64K,就需要在应用层进行手动分包,多次发送,并在接收端进行手动拼装。
2.3 UDP的缓冲区
- UDP没有真正意义上的发送缓冲区。调用sendto会直接交给内核,由内核将数据传给网络层协议进行后续的传输动作。
- UDP具有接收缓冲区。但是这个接收缓冲区不能保证UDP数据报的接收顺序和发送顺序一致;如果缓冲区满了,再到达的UDP数据报就会被丢弃。
为什么UDP没有发送缓冲区
- 因为不需要,UDP协议的设计目标是提供一种简单的、无连接的通信方式。
- UDP协议的设计初衷是为了实现高效的数据传输,尽量减少协议本身的开销。不提供可靠性和流量控制的机制,因此不需要发送缓冲区
- 调用sendto会把数据直接交给内核,由内核将数据传给网络层协议进行后续的传输动作。
为什么UDP要有接收缓冲区?
虽然 UDP 是一种无连接的、不可靠的传输协议,但仍然需要接收缓冲区来暂时存储接收到的 UDP 数据包。以下是几个理由:
-
数据处理速度不匹配:发送端的数据处理速度可能快于接收端的数据处理速度。如果没有接收缓冲区,接收端处理数据的速度跟不上发送端发送数据的速度,可能导致数据包在传输过程中被丢弃或溢出。通过接收缓冲区,接收端可以临时存储尚未处理的数据包,以便之后逐个处理。
-
数据包乱序、丢失处理:由于 UDP 协议本身不提供拥塞控制和重传机制,可能会导致数据包乱序到达或部分数据包丢失。接收缓冲区可以暂时保存乱序到达的数据包,并允许应用程序按顺序处理数据。此外,接收缓冲区还可以让应用程序检查是否丢失了某些数据包,并采取适当的措施。
-
简化应用程序设计:即使 UDP 是一种简单的协议,但应用程序仍需要一定的缓冲区来存储接收的数据。接收缓冲区的存在可以简化应用程序设计,让应用程序不需要关心接收时的数据处理细节,只需从缓冲区中读取数据即可。
总之,虽然 UDP 协议不提供可靠性保证,但接收缓冲区仍然是必要的,用于在一定程度上处理乱序到达、丢包等情况,并为应用程序提供一个暂存数据的地方,以便后续处理。
三、基于UDP的应用层协议
- NFS:网络文件系统
- TFTP:简单文件传输协议
- DHCP:动态主机配置协议
- BOOTP:启动协议(用于无盘设备启动)
- DNS:域名解析协议
提示:当然, 也包括你自己写UDP程序时自定义的应用层协议。
这篇关于【传输层协议】UDP协议 {端口号的范围划分;UDP数据报格式;UDP协议的特点;UDP的缓冲区;基于UDP的应用层协议}的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!