极客时间已完结课程限时免费阅读

06 | 嗨，别忘了UDP这个小兄弟

06 | 嗨，别忘了UDP这个小兄弟-极客时间

06 | 嗨，别忘了UDP这个小兄弟

2019-08-14 盛延敏 来自北京
《网络编程实战》
课程介绍

讲述：冯永吉

时长09:22大小12.87M

你好，我是盛延敏，这里是网络编程实战第 6 讲，欢迎回来。
前面几讲我们讲述了 TCP 方面的编程知识，这一讲我们来讲讲 UDP 方面的编程知识。
如果说 TCP 是网络协议的“大哥”，那么 UDP 可以说是“小兄弟”。这个小兄弟和大哥比，有什么差异呢？
首先，UDP 是一种“数据报”协议，而 TCP 是一种面向连接的“数据流”协议。
TCP 可以用日常生活中打电话的场景打比方，前面也多次用到了这样的例子。在这个例子中，拨打号码、接通电话、开始交流，分别对应了 TCP 的三次握手和报文传送。一旦双方的连接建立，那么双方对话时，一定知道彼此是谁。这个时候我们就说，这种对话是有上下文的。
同样的，我们也可以给 UDP 找一个类似的例子，这个例子就是邮寄明信片。在这个例子中，发信方在明信片中填上了接收方的地址和邮编，投递到邮局的邮筒之后，就可以不管了。发信方也可以给这个接收方再邮寄第二张、第三张，甚至是第四张明信片，但是这几张明信片之间是没有任何关系的，他们的到达顺序也是不保证的，有可能最后寄出的第四张明信片最先到达接收者的手中，因为没有序号，接收者也不知道这是第四张寄出的明信片；而且，即使接收方没有收到明信片，也没有办法重新邮寄一遍该明信片。
这两个简单的例子，道出了 UDP 和 TCP 之间最大的区别。
TCP 是一个面向连接的协议，TCP 在 IP 报文的基础上，增加了诸如重传、确认、有序传输、拥塞控制等能力，通信的双方是在一个确定的上下文中工作的。
而 UDP 则不同，UDP 没有这样一个确定的上下文，它是一个不可靠的通信协议，没有重传和确认，没有有序控制，也没有拥塞控制。我们可以简单地理解为，在 IP 报文的基础上，UDP 增加的能力有限。
UDP 不保证报文的有效传递，不保证报文的有序，也就是说使用 UDP 的时候，我们需要做好丢包、重传、报文组装等工作。
既然如此，为什么我们还要使用 UDP 协议呢？
答案很简单，因为 UDP 比较简单，适合的场景还是比较多的，我们常见的 DNS 服务，SNMP 服务都是基于 UDP 协议的，这些场景对时延、丢包都不是特别敏感。另外多人通信的场景，如聊天室、多人游戏等，也都会使用到 UDP 协议。

UDP 编程

UDP 和 TCP 编程非常不同，下面这张图是 UDP 程序设计时的主要过程。
我们看到服务器端创建 UDP 套接字之后，绑定到本地端口，调用 recvfrom 函数等待客户端的报文发送；客户端创建套接字之后，调用 sendto 函数往目标地址和端口发送 UDP 报文，然后客户端和服务器端进入互相应答过程。
recvfrom 和 sendto 是 UDP 用来接收和发送报文的两个主要函数：
#include <sys/socket.h>
ssize_t recvfrom(int sockfd, void *buff, size_t nbytes, int flags,
　　　　　　　　　　struct sockaddr *from, socklen_t *addrlen);
ssize_t sendto(int sockfd, const void *buff, size_t nbytes, int flags,
const struct sockaddr *to, socklen_t addrlen);
我们先来看一下 recvfrom 函数。
sockfd、buff 和 nbytes 是前三个参数。sockfd 是本地创建的套接字描述符，buff 指向本地的缓存，nbytes 表示最大接收数据字节。
第四个参数 flags 是和 I/O 相关的参数，这里我们还用不到，设置为 0。
后面两个参数 from 和 addrlen，实际上是返回对端发送方的地址和端口等信息，这和 TCP 非常不一样，TCP 是通过 accept 函数拿到的描述字信息来决定对端的信息。另外 UDP 报文每次接收都会获取对端的信息，也就是说报文和报文之间是没有上下文的。
函数的返回值告诉我们实际接收的字节数。
接下来看一下 sendto 函数。
sendto 函数中的前三个参数为 sockfd、buff 和 nbytes。sockfd 是本地创建的套接字描述符，buff 指向发送的缓存，nbytes 表示发送字节数。第四个参数 flags 依旧设置为 0。
后面两个参数 to 和 addrlen，表示发送的对端地址和端口等信息。
函数的返回值告诉我们实际发送的字节数。
我们知道， TCP 的发送和接收每次都是在一个上下文中，类似这样的过程：
A 连接上: 接收→发送→接收→发送→…
B 连接上: 接收→发送→接收→发送→ …
而 UDP 的每次接收和发送都是一个独立的上下文，类似这样：
接收 A→发送 A→接收 B→发送 B →接收 C→发送 C→ …

UDP 服务端例子

我们先来看一个 UDP 服务器端的例子：
#include "lib/common.h"
static int count;
static void recvfrom_int(int signo) {
printf("\nreceived %d datagrams\n", count);
exit(0);
}
int main(int argc, char **argv) {
int socket_fd;
socket_fd = socket(AF_INET, SOCK_DGRAM, 0);
struct sockaddr_in server_addr;
bzero(&server_addr, sizeof(server_addr));
server_addr.sin_family = AF_INET;
server_addr.sin_addr.s_addr = htonl(INADDR_ANY);
server_addr.sin_port = htons(SERV_PORT);
bind(socket_fd, (struct sockaddr *) &server_addr, sizeof(server_addr));
socklen_t client_len;
char message[MAXLINE];
count = 0;
signal(SIGINT, recvfrom_int);
struct sockaddr_in client_addr;
client_len = sizeof(client_addr);
for (;;) {
int n = recvfrom(socket_fd, message, MAXLINE, 0, (struct sockaddr *) &client_addr, &client_len);
message[n] = 0;
printf("received %d bytes: %s\n", n, message);
char send_line[MAXLINE];
sprintf(send_line, "Hi, %s", message);
sendto(socket_fd, send_line, strlen(send_line), 0, (struct sockaddr *) &client_addr, client_len);
count++;
}
}
程序的 12～13 行，首先创建一个套接字，注意这里的套接字类型是“SOCK_DGRAM”，表示的是 UDP 数据报。
15～21 行和 TCP 服务器端类似，绑定数据报套接字到本地的一个端口上。
27 行为该服务器创建了一个信号处理函数，以便在响应“Ctrl+C”退出时，打印出收到的报文总数。
31～42 行是该服务器端的主体，通过调用 recvfrom 函数获取客户端发送的报文，之后我们对收到的报文进行重新改造，加上“Hi”的前缀，再通过 sendto 函数发送给客户端对端。

UDP 客户端例子

接下来我们再来构建一个对应的 UDP 客户端。在这个例子中，从标准输入中读取输入的字符串后，发送给服务端，并且把服务端经过处理的报文打印到标准输出上。
#include "lib/common.h"
# define MAXLINE 4096
int main(int argc, char **argv) {
if (argc != 2) {
error(1, 0, "usage: udpclient <IPaddress>");
}
int socket_fd;
socket_fd = socket(AF_INET, SOCK_DGRAM, 0);
struct sockaddr_in server_addr;
bzero(&server_addr, sizeof(server_addr));
server_addr.sin_family = AF_INET;
server_addr.sin_port = htons(SERV_PORT);
inet_pton(AF_INET, argv[1], &server_addr.sin_addr);
socklen_t server_len = sizeof(server_addr);
struct sockaddr *reply_addr;
reply_addr = malloc(server_len);
char send_line[MAXLINE], recv_line[MAXLINE + 1];
socklen_t len;
int n;
while (fgets(send_line, MAXLINE, stdin) != NULL) {
int i = strlen(send_line);
if (send_line[i - 1] == '\n') {
send_line[i - 1] = 0;
}
printf("now sending %s\n", send_line);
size_t rt = sendto(socket_fd, send_line, strlen(send_line), 0, (struct sockaddr *) &server_addr, server_len);
if (rt < 0) {
error(1, errno, "send failed ");
}
printf("send bytes: %zu \n", rt);
len = 0;
n = recvfrom(socket_fd, recv_line, MAXLINE, 0, reply_addr, &len);
if (n < 0)
error(1, errno, "recvfrom failed");
recv_line[n] = 0;
fputs(recv_line, stdout);
fputs("\n", stdout);
}
exit(0);
}
10～11 行创建一个类型为“SOCK_DGRAM”的套接字。
13～17 行，初始化目标服务器的地址和端口。
28～51 行为程序主体，从标准输入中读取的字符进行处理后，调用 sendto 函数发送给目标服务器端，然后再次调用 recvfrom 函数接收目标服务器发送过来的新报文，并将其打印到标准输出上。
为了让你更好地理解 UDP 和 TCP 之间的差别，我们模拟一下 UDP 的三种运行场景，你不妨思考一下这三种场景的结果和 TCP 的到底有什么不同？

场景一：只运行客户端

如果我们只运行客户端，程序会一直阻塞在 recvfrom 上。
$ ./udpclient 127.0.0.1
1
now sending g1
send bytes: 2
<阻塞在这里>
还记得 TCP 程序吗？如果不开启服务端，TCP 客户端的 connect 函数会直接返回“Connection refused”报错信息。而在 UDP 程序里，则会一直阻塞在这里。

场景二：先开启服务端，再开启客户端

在这个场景里，我们先开启服务端在端口侦听，然后再开启客户端：
$./udpserver
received 2 bytes: g1
received 2 bytes: g2
$./udpclient 127.0.0.1
g1
now sending g1
send bytes: 2
Hi, g1
g2
now sending g2
send bytes: 2
Hi, g2
我们在客户端一次输入 g1、g2，服务器端在屏幕上打印出收到的字符，并且可以看到，我们的客户端也收到了服务端的回应：“Hi,g1”和“Hi,g2”。

场景三: 开启服务端，再一次开启两个客户端

这个实验中，在服务端开启之后，依次开启两个客户端，并发送报文。
服务端：
$./udpserver
received 2 bytes: g1
received 2 bytes: g2
received 2 bytes: g3
received 2 bytes: g4
第一个客户端：
$./udpclient 127.0.0.1
now sending g1
send bytes: 2
Hi, g1
g3
now sending g3
send bytes: 2
Hi, g3
第二个客户端：
$./udpclient 127.0.0.1
now sending g2
send bytes: 2
Hi, g2
g4
now sending g4
send bytes: 2
Hi, g4
我们看到，两个客户端发送的报文，依次都被服务端收到，并且客户端也可以收到服务端处理之后的报文。
如果我们此时把服务器端进程杀死，就可以看到信号函数在进程退出之前，打印出服务器端接收到的报文个数。
$ ./udpserver
received 2 bytes: g1
received 2 bytes: g2
received 2 bytes: g3
received 2 bytes: g4
^C
received 4 datagrams
之后，我们再重启服务器端进程，并使用客户端 1 和客户端 2 继续发送新的报文，我们可以看到和 TCP 非常不同的结果。
以下就是服务器端的输出，服务器端重启后可以继续收到客户端的报文，这在 TCP 里是不可以的，TCP 断联之后必须重新连接才可以发送报文信息。但是 UDP 报文的“无连接”的特点，可以在 UDP 服务器重启之后，继续进行报文的发送，这就是 UDP 报文“无上下文”的最好说明。
$ ./udpserver
received 2 bytes: g1
received 2 bytes: g2
received 2 bytes: g3
received 2 bytes: g4
^C
received 4 datagrams
$ ./udpserver
received 2 bytes: g5
received 2 bytes: g6
第一个客户端：
$./udpclient 127.0.0.1
now sending g1
send bytes: 2
Hi, g1
g3
now sending g3
send bytes: 2
Hi, g3
g5
now sending g5
send bytes: 2
Hi, g5
第二个客户端：
$./udpclient 127.0.0.1
now sending g2
send bytes: 2
Hi, g2
g4
now sending g4
send bytes: 2
Hi, g4
g6
now sending g6
send bytes: 2
Hi, g6

总结

在这一讲里，我介绍了 UDP 程序的例子，我们需要重点关注以下两点：
UDP 是无连接的数据报程序，和 TCP 不同，不需要三次握手建立一条连接。
UDP 程序通过 recvfrom 和 sendto 函数直接收发数据报报文。

思考题

最后给你留两个思考题吧。在第一个场景中，recvfrom 一直处于阻塞状态中，这是非常不合理的，你觉得这种情形应该怎么处理呢？另外，既然 UDP 是请求 - 应答模式的，那么请求中的 UDP 报文最大可以是多大呢？
欢迎你在评论区写下你的思考，我会和你一起讨论。也欢迎把这篇文章分享给你的朋友或者同事，一起讨论一下 UDP 这个协议。
分享给需要的人，Ta购买本课程，你将得18元
生成海报并分享

赞 17

提建议

© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
上一篇
05 | 使用套接字进行读写：开始交流吧
下一篇
07 | What? 还有本地套接字？
unpreview
 写留言

精选留言(58)

  • 许童童
    2019-08-14
    第一个场景中，可以添加超时时间做处理，当然你也可以自己实现一个复杂的请求-确认模式，那这样就跟TCP类似了，HTTP/3就是这样做的。 用UDP协议发送时，用sendto函数最大能发送数据的长度为：65535- IP头(20) - UDP头(8)＝65507字节。用sendto函数发送数据时，如果发送数据长度大于该值，则函数会返回错误。 由于IP有最大MTU，因此， UDP 包的大小应该是 1500 - IP头(20) - UDP头(8) = 1472(Bytes) TCP 包的大小应该是 1500 - IP头(20) - TCP头(20) = 1460 (Bytes)
    展开
    共 6 条评论
    89
  • tongmin_tsai
    2019-09-30
    老师，UDP被IP层分包发送后，对端如何保证UDP包整个组合的？比如用UDP发送3000字节，假设拆分2个MTU发送，后一个先到服务端，前一个后到服务端，那应用层接收的时候，UDP怎么组装的？

    作者回复: 很简单，1-1500为一个seq=1的包，1501-3000为seq=2的包，根据sequence组装就可以了。

    共 3 条评论
    19
  • 何赫赫
    2020-03-09
    老师，UDP没有发送缓冲区这个概念吗

    作者回复: 实际上不存在UDP发送缓冲区，因为发往UDP发送缓冲区的包只要超过一定阈值(值很小)就可以发往对端。所以我们一般认为UDP是没有发送缓冲区的。

    共 2 条评论
    18
  • 刘明
    2019-08-14
    1、一直阻塞会导致程序无法正常退出，可以使用接收超时、IO多路复用的超时机制。 2、IP和UDP头中都有16bit的长度字段，最长65535字节，去掉头部长度得到UDP数据净荷长度：65535-20-8=65507字节。
    共 1 条评论
    11
  • 你好
    2019-10-30
    多人聊天室使用UDP，消息发出后怎么保证消息可以被收到呀，UDP不是不可靠传输嘛，中间丢了消息咋办呀

    作者回复: 第一，丢了就丢了，反正UDP就是不可靠的； 第二，给每条消息加个sequence，收到后再确认，一段时间内没收到，就重发。

    共 4 条评论
    10
  • 旅途
    2019-12-29
    第一个思考题 另起一个线程进行recvfrom

    作者回复: 我的本意是使用超时或者非阻塞来解

    6
  • 记事本
    2019-08-14
    recv from会导致进程一直阻塞，可以通过setsocketopt接口设置TIMEOUT 超时后退出.
    共 1 条评论
    6
  • YUAN
    2020-10-03
    udp之所以sendto要目的地址是因为他是非连接的，否则不知道将数据发给谁，recvfrom要发送方地址也是因为udp是非连接的，有了from内核就可以判定将数据上传给谁（应用进程）。是这样吗？

    作者回复: 基本是这样的。

    4
  • 范龙dragon
    2019-08-18
    客户端代码的29行sendline数组之前没有初始化数组元素为0，直接用strlen应该会有问题吧，strlen不是以0作为结束标志吗？

    作者回复: 好问题，fgets函数会"默默"的给我们加上\0

    共 2 条评论
    4
  • Godblesser
    2019-08-14
    recvfrom函数可以设置超时，当限定时间内未接收到服务器端回复，打印超时消息并退出
    4
  • 郑祖煌
    2020-06-12
    1.可以用非阻塞状态来做，或者用select 用户复用的弄。就是不阻塞，而是一定的时间内去轮询看有没有包到达。或者说当服务器有包达到事件通知客户端，客户端再去服务器那边读取数据。 2. 用UDP协议发送时，用sendto函数最大能发送数据的长度为：如果是本地套接字的话就是655356。如果是非本地套接字而是走网络端的话 由于IP有最大MTU，因此， UDP 包的大小应该是 1500 - IP头(20) - UDP头(8) = 1472(Bytes) TCP 包的大小应该是 1500 - IP头(20) - TCP头(20) = 1460 (Bytes)
    展开
    3
  • 钱
    2019-11-22
    小结 1：UDP是一个不可靠的通信协议，没有重传和确认，没有有序控制，也没有拥塞控制。 2：UDP 不保证报文的有效传递，不保证报文的有序，也就是说使用 UDP 的时候，我们需要做好丢包、重传、报文组装等工作。 3： UDP 相对TCP比较简单，适合的场景还是比较多的，我们常见的 DNS 服务，SNMP 服务都是基于 UDP 协议的，这些场景对时延、丢包都不是特别敏感。另外多人通信的场景，如聊天室、多人游戏等，也都会使用到 UDP 协议。 4：把UDP协议比做发生明信片确实生动形象，我告诉邮局送到那些地址，具体送到没有，需要接收端主动的响应（注意：这里的响应者更靠上层）协议本身不会进行重传/确认/时序/拥塞等控制。
    展开
    3
  • kissingers
    2019-09-06
    老师，TCP 流，UDP包，流的说法怎么理解？

    作者回复: 流就像水流，一直持续不断的流淌，只不过流淌的是0101这样的比特流。

    共 4 条评论
    3
  • zhchnchn
    2019-08-14
    如果不开启服务端，TCP 客户端的 connect 函数会直接返回“Connection refused”报错信息。而在 UDP 程序里，则会一直阻塞在这里。 ------------------------- 这个地方不太理解。请问老师,对TCP来说，收到“Connection refused”报错信息，表明收到了服务端的RST包，如果服务端不开启，谁负责发送RST包呢?

    作者回复: 不是RST包，RST的意思是connection reset；这里connection refused是对方的TCP协议栈发送的，工作在操作系统内核中。

    共 2 条评论
    3
  • 江永枫
    2019-08-14
    关于阻塞io，可以考虑使用多线程模型去提升性能，或者结合io多路复用来处理能力。 https://m.php.cn/article/410029.html

    作者回复: 很快就会讲到了 ：）

    3
  • null
    2021-03-16
    老师好，有 3 个问题请教一下： 1. TCP 有序传输的意思是：需要等到当前发送的包 ACK 之后，才发下一个包么？还是说可以一直发消息，收到 ACK 之后再确认对应的包发送成功？ 2. 关于 TCP 和 UDP 连接，我可以这么理解么？ TCP 连接之后直到关闭，这期间发的消息，比如 client 发给(send 函数) server， 然后 server 回复(不知道用啥函数写回，也是 send 函数么？) client； client 又继续发给 server，继续重复刚才的步骤....， 走的都是同一个连接。 而 UDP，client 发给（sendto 函数） server 是一个连接。而 server 回复（sendto 函数） client，又是另一个连接。 3. 下面的循环发送，我甚至是可以动态更改对端 client_addr 地址和端口信息的吧？ for (;;) { sendto(socket_fd, send_line, strlen(send_line), 0, (struct sockaddr *) &client_addr, client_len); }
    展开

    作者回复: 1. TCP有序传输的意思是对于传送的字节流，接收端总是保证按照发送的顺序来接收； 2.TCP是面向连接的，UDP没有连接的概念； 3.当然可以，但是意义不大。

    2
  • 流浪在寂寞古城
    2019-10-31
    https://github.com/worsun/study/tree/master/hack_time/socket_code/6

    作者回复: 👍

    共 3 条评论
    2
  • 马留
    2019-08-29
    如果对udp套接字调用了listen函数，会怎么样呢？

    作者回复: 改下程序，试试就知道了，最好把你的结果贴上来，大家一起研究。

    共 5 条评论
    2
  • 胜辉（大V）
    2021-10-25
    示例程序在我的测试机(ubuntu 20.04）上有几个报错。除了include需要添加多个库，还有就是sprintf不分需要改为如下： char send_line[MAXLINE+4]; sprintf(send_line, "Hi, %s", message); 因为"Hi, "本身占用了额外的4个字节，所以导致send_line跟"Hi, "+message的长度不匹配，需要修改send_line为message长度加4。不知道其他同学的测试环境那里如何？
    展开

    作者回复: 我觉得不用啊，程序是用了strlen重新计算了新的send_line的长度的。 sendto(socket_fd, send_line, strlen(send_line), 0, (struct sockaddr *) &client_addr, client_len);

    1
  • null
    2021-03-16
    如果不开启服务端，而在 UDP 程序里，则会一直阻塞在这里（sendto）。 阻塞是为了等待消息发出去之后的 ACK 确认么？ 不是说把明信片放到邮筒就不管了么？ 邮筒可以认为是 IP 协议栈（即网络接口层？）吧？把 udp 包传递给 IP 层就不管了。 谢谢老师
    展开

    作者回复: 阻塞是因为服务端没有开启，无法从服务端得到响应，你看一下程序原文，sendto已经执行成功了； 明信片的比喻对的，这里sendto已经成功执行了，相当于把明信片放到邮筒了，原程序里是希望通过recvfrom来或得服务端的反馈。

    1