计算机网络 | Linux | 解析UDP协议

目录

一.UDP概述

1.什么是UDP协议

2.UDP协议的特点

3.UDP的首部格式

二.UDP设计框架

三.UDP程序设计demo

四.UDP程序设计常用函数

五.UDP协议中一些常见的问题

1.UDP报文丢失问题

2.UDP报文乱序问题

3.UDP流量控制问题


一.UDP概述

1.什么是UDP协议

UDP 是 User Datagram Protocol 的简称, 中文名是用户数据报协议,是一个简单的面向数据报的传输层协议,在网络中用于处理数据包,是一种无连接的协议。UDP不提供可靠性的传输,它只是把应用程序传给 IP 层的数据报发送出去,但是并不能保证它们能到达目的地。由于 UDP 在传输数据报前不用在客户和服务器之间建立一个连接,且没有超时重发等机制,故而传输速度很快。远地主机的运输层在收到UDP报文后,不需要给出任何确认。虽然UDP不提供可靠交付,但在某些情况下UDP却是一种最有效的工作
方式。

下面给出部分使用UDP协议的各种应用和应用层协议:

2.UDP协议的特点

  1. UDP是无连接的,即发送数据之前不需要建立连接因此减少了开销和发送数据之前的时延。
  2. UDP使用尽最大努力交付,即不保证可靠交付,因此主机不需要维持复杂的连接状表
  3. 不进行分组出错的恢复和重传。
  4. UDP是面向报文的。发送方的UDP对应用程序交下来的报文,在添加首部后就向下交付IP层。UDP对应用层交下来的文,既不合并,也不拆分,而是保留这些报文的边界。这就是说,应用层交给UDP多长的报文,UDP就照样发送,即一次发送一个报文,也就是说,UDP一次交付一个完整的报文。
  5. UDP没有拥塞控制,因此网络出现的拥塞不会使源主机的发送速率降低。
  6. 不对数据包的顺序进行检查,不能保证分组的先后顺序。
  7. UDP支持一对一、一对多、多对一和多对多的交互通信。
  8. UDP的首部开销小。

在网络质量令人十分不满意的环境下,UDP 协议数据包丢失会比较严重。但是由于 UDP 的特性:它不属于连接型协议,因而具有资源消耗小,处理速度快的优点,所以通常音频、视频和普通数据在传送时使用 UDP 较多,因为它们即使偶尔丢失一两个数据包,也不会对接收结果产生太大影响。比如我们聊天用的 ICQ 和 QQ 就是使用的 UDP。

3.UDP的首部格式

用户数据报UDP有两个字段:数据字段和首部字段。首部字段很简单,只有8个字节,由四个字段组成,每个字段的长度都是两个字节。各字段意义如下:

  1. 源端口:源端口号。在需要对方回信时选用。不需要时可用全0。
  2. 目的端口:目的端口号。这在终点交付报文时必须使用。
  3. 长度:UDP用户数据报的长度,其最小值是8(仅有首部)。
  4. 检验和检测UDP用户数据报在传输中是否有错。有错就丢弃。

如果接收方UDP发现收到的报文中的目的端口号不正确(即不存在对应于该端口号的应用进程),就丢弃该报文,并由网际控制报文协议ICMP发送“端口不可达”差错报文给发送方。请注意,虽然在UDP之间的通信要用到其端口号,但由于UDP的通信是无连接的,因此不需要使用套接字(TCP之间的通信必须要在两个套接字之间建立连接)。

二.UDP设计框架

三.UDP程序设计demo

客户端


#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <string.h>
#include <assert.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/inet.h>

int main()
{
	int sockfd = socket(AF_INET,SOCK_DGRAM,0);
	assert(sockfd != -1);

	struct sockaddr_in saddr;
	memset(&saddr,0,sizeof(saddr));
	saddr.sin_family = AF_INET;
	saddr.sin_port = htons(6000);
	saddr.sin_addr.s_addr = inet_addr("127.0.0.1");

	while(1)
	{
		char buff[128]={
			0
		};
		printf("input:\n");
		fgets(buff,128,stdin);

		if(strncmp(buff,"end",3)==0)
		{
			break;
		}
		sendto(sockfd,buff,strlen(buff),0,(struct sockaddr*)&saddr,sizeof(saddr));

		memset(buff,0,128);

		int len = sizeof(saddr);
		recvfrom(sockfd,buff,127,0,(struct sockaddr*)&saddr,&len);

		printf("buff = %s\n",buff);
	}
	close(sockfd);
}

服务器

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <string.h>
#include <assert.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/inet.h>

int main()
{
	int sockfd = socket(AF_INET,SOCK_DGRAM,0);
		//SOCK_DGRAM 代表UDP协议
	assert(sockfd != -1);

	struct sockaddr_in saddr,caddr;
	memset(&saddr,0,sizeof(saddr));
	saddr.sin_family = AF_INET;
	saddr.sin_port = htons(6000);
	saddr.sin_addr.s_addr = inet_addr("127.0.0.1");

	int res = bind(sockfd,(struct sockaddr*)&saddr,sizeof(saddr));
	assert(res != -1);

	while(1)
	{
		int len = sizeof(caddr);
		char buff[128]={
			0
		};
		int n = recvfrom(sockfd,buff,127,0,(struct sockaddr*)&caddr,&len);
		printf("buff(%d)=%s\n",n,buff);

		sendto(sockfd,"ok",2,0,(struct sockaddr*)&caddr,sizeof(caddr));
	}
		close(sockfd);
}

四.UDP程序设计常用函数

1.sendto函数

#include <sys/types.h>
#include <sys/socket.h>
ssize_t sendto(int sockfd, 
               const void *buf, 
               size_t len, 
	       int flags, 
               const struct sockaddr *dest_addr, 
	       socklen_t addrlen);
  • 功能:向一指定目的地发送数据,sendto()适用于发送未建立连接的UDP数据包。
  • 参数:
    • sockfd:正在监听端口的套接口文件描述符,通过socket获得
    • buf:发送缓冲区,往往是使用者定义的数组,该数组装有要发送的数据
    • len:发送缓冲区的大小,单位是字节
    • flags:填0即可
    • dest_addr:指向接收数据的主机地址信息的结构体,也就是该参数指定数据要发送到哪个主机哪个进程
    • addrlen:表示第五个参数所指向内容的长度
  • 返回值: 成功:返回发送成功的数据长度,失败: -1。 

2.recvfrom()函数

#include <sys/types.h>
#include <sys/socket.h>
ssize_t recvfrom(int sockfd, void *buf,
                 size_t len, 
		 int flags,
                 struct sockaddr *src_addr, 
		 socklen_t *addrlen);
  • 功能:本函数用于从(已连接)的套接口上接收数据,并捕获数据发送源的地址。
  • 参数:
    • sockfd:正在监听端口的套接口文件描述符,通过socket获得
    • buf:接收数据缓冲区,往往是使用者定义的数组,该数组装有要发送的数据
    • len:接收缓冲区的大小,单位是字节
    • flags:填0即可
    • src_addr:指向发送数据的主机地址信息的结构体,也就是我们可以从该参数获取到数据是谁发出的
    • addrlen:表示第五个参数所指向内容的长度;
  • 返回值: 成功:返回接收成功的数据长度,失败: -1。 

3.bind()函数

#include <sys/types.h>
#include <sys/socket.h>
int bind(int sockfd,
         const struct sockaddr* my_addr, 
	 socklen_t addrlen);
  • 功能: 将本地协议地址与 sockfd 绑定,这样 ip、port 就固定了。
  • 参数:
    • sockfd:正在监听端口的套接口文件描述符,通过socket获得
    • my_addr:需要绑定的IP和端口
    • addrlen:my_addr的结构体的大小;
  • 返回值: 成功:0,失败: -1。

在上述例子中,UDP服务器调用了bind()函数为服务器套接字绑定本地地址/端口,这样使得客户端的能知道它发数据的目的地址/端口,服务器如果单单接收客户端的数据,或者先接收客户端的数据(此时通过recvfrom()函数获取到了客户端的地址信息/端口)再发送数据,客户端的套接字可以不绑定自身的地址/端口,因为UDP在创建套接字后直接使用sendto(),隐含操作是,在发送数据之前操作系统会为该套接字随机分配一个合适的UDP端口,将该套接字和本地地址信息绑定。

但是,如果服务器程序就绪后一开始就要发送数据给客户端,那么服务器就需要知道客户端的地址信息和端口,那么就不能让客户端的地址信息和端口号由客户端所在操作系统分配,而是要在客户端程序指定了。怎么指定,那就是调用用bind()函数。

五.UDP协议中一些常见的问题

1.UDP报文丢失问题

 所谓的报文丢失是指,在UDP服务器客户端的例子中,如果客户端发送的数据丢失,服务器会一直等待,直到客户端的合法数据过来。如果服务器的响应在中间被路由丢弃,则客户端会一直阻塞,直到服务器数据过来。

【解决办法】

  • 使用信号SIGALRM为recvfrom设置超时。首先我们为SIGALARM建立一个信号处理函数,并在每次调用前通过alarm设置一个5秒的超时。如果recvfrom被我们的信号处理函数中断了,那就超时重发信息;若正常读到数据了,就关闭报警时钟并继续进行下去。
  • 使用select为recvfrom设置超时,设置select函数的第五个参数即可。
int select (int maxfd + 1,
            fd_set *readset,
            fd_set *writeset,
            fd_set *exceptset,
            const struct timeval * timeout);
  •  功能:select是一个计算机函数,位于头文件#include <sys/select.h> 。该函数用于监视文件描述符的变化情况——读写或是异常。
  • 参数
    • 参数一:最大的文件描述符加1。

    • 参数二:用于检查可读性。

    • 参数三:用于检查可写性。

    • 参数四:用于检查带外数据。

    • 参数五:一个指向timeval结构的指针,用于决定select等待I/o的最长时间。如果为空将一直等待。

  • 返回值:>0 就绪描述字的正数目,-1 出错,0 超时。

2.UDP报文乱序问题

所谓乱序就是发送数据的顺序和接收数据的顺序不一致,例如发送数据的顺序为A、B、C,但是接收到的数据顺序却为:A、C、B。产生这个问题的原因在于,每个数据报走的路由并不一样,有的路由顺畅,有的却拥塞,这导致每个数据报到达目的地的顺序就不一样了。UDP协议并不保证数据报的按序接收。

【解决办法】

发送端在发送数据时加入数据报序号,这样接收端接收到报文后可以先检查数据报的序号,并将它们按序排队,形成有序的数据报。

3.UDP流量控制问题

我们知道,TCP有滑动窗口进行流量控制和拥塞控制,反观UDP因为其特点无法做到。UDP接收数据时直接将数据放进缓冲区内,如果用户没有及时将缓冲区的内容复制出来放好的话,后面的到来的数据会接着往缓冲区放,当缓冲区满时,后来的到的数据就会覆盖先来的数据而造成数据丢失(因为内核使用的UDP缓冲区是环形缓冲区)。因此,一旦发送方在某个时间点爆发性发送消息,接收方将因为来不及接收而发生信息丢失。

【解决办法】

解决方法一般采用增大UDP缓冲区,使得接收方的接收能力大于发送方的发送能力。

int n = 220 * 1024; //220kB
setsocketopt(sockfd, SOL_SOCKET, SO_RCVBUF, &n, sizeof(n));
发布了88 篇原创文章 · 获赞 40 · 访问量 1万+

猜你喜欢

转载自blog.csdn.net/ThinPikachu/article/details/105122900