传输层协议UDP原理

用户11719974

发布于 2025-11-15 09:27:59

860

端口号回顾

端口号的作用类似pid，用来标识进程的唯一性。只是为了与系统解耦，所以有了端口号。

通过ip来确定唯一主机，再通过端口号找到指定的进程。就可以让全网内唯一的两个进程通信了。

所以一个完整的报文至少要携带ip和端口号，ip是在网络层协议来维护的本章不做讲解，而端口号是在传输层协议中维护的，传输层协议常用的两种：UDP协议和TCP协议，本章将要讲解的是UDP协议，TCP协议在下一期进行讲解。

端口号：2字节（16个比特位）其中：

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

认识知名端口号有些服务器是非常常用的, 为了使用方便, 人们约定一些常用的服务器）, 都是用以下这些固定的端口号:

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

执行下面的命令, 可以看到知名端口号：

 cat /etc/services

思考：

一个进程是否可以 bind 多个端口号?
一个端口号是否可以被多个进程 bind?

答1：一个进程是可以绑定多个端口号的，当一个进程提供多个不同服务时，就可以通过绑定多个端口来优化。只要一个端口能确定唯一进程就行。

答2：不能。要保证一个端口确定唯一进程。

UDP协议端格式

16位源端口和16位目的端口用来确定两个唯一进程，这没啥说的。
16位UDP长度：数据字段的大小不是固定的，所以该字段来表示整个数据报(UDP 首部+UDP 数据)的长度。
16位UDP检验和：不保证可靠性，校验和是唯一确定数据是否有效的机制。因为在数据传输过程中物理干扰、路由错误等可能导致数据损坏。

UDP协议特点

无连接: 知道对端的 IP 和端口号就直接进行传输, 不需要建立连接。
不可靠：报文发出去任务就完成了，报文是否丢失不关心。注意这不是缺点，是特点！
面向数据报：发10次，收10次。而TCP协议是面向字节流的，类似自来水。
缓冲区：UDP没有发送缓冲区，直接发（TCP有发送缓冲区是为了方便重传）。有接收缓冲区，出于效率考量，忙的时候，可以缓一缓。缓冲区满了就把报文丢弃。为全双工。

内核源码

UDP协议格式其实就是一个结构体，源码如下：

struct udphdr {
	unsigned short	src_port;
	unsigned short	dst_port;
	unsigned short	len;
	unsigned short	chksum;
};

在把数据交付给传输层时，数据在应用层必做序列化和反序列化。当然可直接用结构体变量代替，但非常不推荐（结构体存在内存对齐有内存浪费，与其他语言不兼容，需要考虑字节序问题等等）。

注：即使通信双方操作系统完全不同，但网络内核部分一定相同（所以能够通信）。操作系统内核都是使用c语言实现。

在OS内部一定会同时存在大量的报文，而这些报文可分布在各个协议层，OS必须管理这些报文。如果管理？先描述，再组织。如何描述：内核源码中结构体 struct sk_buff，如下：

struct sk_buff 
{
	struct sk_buff	* next;			/* Next buffer in list 				*/
	struct sk_buff	* prev;			/* Previous buffer in list 			*/
	struct sk_buff_head * list;		/* List we are on				*/
#if CONFIG_SKB_CHECK
	int		magic_debug_cookie;
#endif
	struct sk_buff	*link3;			/* Link for IP protocol level buffer chains 	*/
	struct sock	*sk;			/* Socket we are owned by 			*/
	unsigned long	when;			/* used to compute rtt's			*/
	struct timeval	stamp;			/* Time we arrived				*/
	struct device	*dev;			/* Device we arrived on/are leaving by		*/
	union 
	{
		struct tcphdr	*th;
		struct ethhdr	*eth;
		struct iphdr	*iph;
		struct udphdr	*uh;
		unsigned char	*raw;
		/* for passing file handles in a unix domain socket */
		void *filp;
	} h;
  
	union 
	{	
		/* As yet incomplete physical layer views */
	  	unsigned char 	*raw;
	  	struct ethhdr	*ethernet;
	} mac;
  
	struct iphdr	*ip_hdr;		/* For IPPROTO_RAW 				*/
	unsigned long 	len;			/* Length of actual data			*/
	unsigned long	csum;			/* Checksum 					*/
	__u32		saddr;			/* IP source address				*/
	__u32		daddr;			/* IP target address				*/
	__u32		raddr;			/* IP next hop address				*/
	__u32		seq;			/* TCP sequence number				*/
	__u32		end_seq;		/* seq [+ fin] [+ syn] + datalen		*/
	__u32		ack_seq;		/* TCP ack sequence number			*/
	unsigned char	proto_priv[16];	        /* Protocol private data			*/
	volatile char 	acked,			/* Are we acked ?				*/
			used,			/* Are we in use ?				*/
			free,			/* How to free this buffer			*/
			arp;			/* Has IP/ARP resolution finished		*/
	unsigned char	tries,			/* Times tried					*/
  			lock,			/* Are we locked ?				*/
  			localroute,		/* Local routing asserted for this frame	*/
  			pkt_type,		/* Packet class					*/
  			pkt_bridged,		/* Tracker for bridging 			*/
  			ip_summed;		/* Driver fed us an IP checksum			*/
#define PACKET_HOST		0		/* To us					*/
#define PACKET_BROADCAST	1		/* To all					*/
#define PACKET_MULTICAST	2		/* To group					*/
#define PACKET_OTHERHOST	3		/* To someone else 				*/
	unsigned short	users;			/* User count - see datagram.c,tcp.c 		*/
	unsigned short	protocol;		/* Packet protocol from driver. 		*/
	unsigned short	truesize;		/* Buffer size 					*/

	atomic_t	count;			/* reference count				*/
	struct sk_buff	*data_skb;		/* Link to the actual data skb			*/
	unsigned char	*head;			/* Head of buffer 				*/
	unsigned char	*data;			/* Data head pointer				*/
	unsigned char	*tail;			/* Tail pointer					*/
	unsigned char 	*end;			/* End pointer					*/
	void 		(*destructor)(struct sk_buff *);	/* Destruct function		*/
	__u16		redirport;		/* Redirect port				*/
};

封包和解包的本质理解

在以上源码中我们主要关注两个部分：

该字段说明报文用了链表结构来维护，对报文进行操作的本质就是链表的增删改查。

怎么体现不同协议层报文呢？如下字段：

变量	指向位置	功能
head	缓冲区的起始地址	指向整个数据包内存的头部（包括预留的“头空间”）。
data	当前协议层头部	随着协议栈处理，动态移动：接收时：从MAC头 → IP头 → TCP（或UDP）头 → 应用数据。发送时：反向移动。
tail	当前有效数据的末尾	标识实际数据的结束位置（如应用层数据的末尾）。
end	缓冲区的结束地址	指向整个数据包内存的尾部（包括预留的“尾空间”）。