基于UDP的可靠传输——QUIC 协议

oywLearning

已于 2023-01-07 19:34:39 修改

阅读量2.4k

点赞数 1

分类专栏：计算机网络文章标签： udp 网络网络协议

于 2022-12-06 12:59:11 首次发布

本文链接：https://blog.csdn.net/weixin_44479862/article/details/127001830

版权

计算机网络专栏收录该内容

9 篇文章 0 订阅

订阅专栏

一、UDP协议

UDP用户数据报协议，非连接的协议，传输数据之前源端和终端不建立连接，当它想传送时直接去抓取来自应用程序的数据，并尽可能快地把它扔到网络上。

UDP传输协议的特点

UDP无连接，时间上不存在建立连接需要的时延。
UDP没有拥塞控制，应用层能够更好的控制要发送的数据和发送时间，网络中的拥塞控制也不会影响主机的发送速率。
UDP提供尽最大努力的交付，不保证可靠交付。所有维护传输可靠性的工作需要用户在应用层来完成。
UDP是面向报文的，对应用层交下来的报文，添加首部后直接向下交付给IP层，既不合并，也不拆分，保留这些报文的边界。
UDP常用一次性传输比较少量数据的网络应用，如DNS,SNMP等；

UDP的首部格式

UDP校验

在计算校验和的时候，需要在UDP数据报之前增加12字节的伪首部，伪首部并不是UDP真正的首部。 仅仅是为了计算校验和。这样的校验和，既检查了UDP数据报，又对IP数据报的源IP地址和目的IP地址进行了检验。

UDP客户端和服务器端编程示例

客户端：

#include<sys/socket.h>
#include<stdio.h>
#include<assert.h>
#include<netinet/in.h>
#include<arpa/inet.h>
#include<string.h>
#include<unistd.h>
int main()
{
    //创建套接字，SOCK_DGRAM为UDP数据报套接字
    int fd=socket(AF_INET,SOCK_DGRAM,0);
    assert(fd!=-1);

    struct sockaddr_in saddr;//服务器套接字结构
    struct sockaddr_in caddr;//客户端套接字结构
    //saddr其实有四项成员，最后一项用来占位的，必须搞为0，索性我们开始直接给全部置为0，后面再来绑定ip和端口
    saddr.sin_family=AF_INET;//地址族，TCP/ipv4协议族
    saddr.sin_port=htons(6000);//将端口值从小端序列转换为大端序列
    saddr.sin_addr.s_addr=inet_addr("172.27.209.173");//将一个点分十进制的ip地址转换为一个长整型数

    while(1)
    {
        //创建发送缓冲区
        char buff[128]={0};
        //从标准输入中输入数据
        fgets(buff,128,stdin);
        //设置退出暗号
        if(strncmp(buff,"break",5)==0)
        break;
        //向服务器发送数据
        sendto(fd,buff,sizeof(buff)-1,0,(struct sockaddr*)&saddr,sizeof(saddr));
        //将发送缓冲区转换成接收缓冲区
        memset(buff,0,128);
        int len = sizeof(saddr);
        //接收服务器的数据回复
        recvfrom(fd,buff,127,0,(struct sockaddr*)&saddr,(socklen_t*)&len);
        printf("buff: %s \n",buff);
    }
    close(fd);
}

服务器端：

#include<sys/socket.h>
#include<stdio.h>
#include<assert.h>
#include<netinet/in.h>
#include<arpa/inet.h>
#include<unistd.h>
int main()
{
    //创建套接字，SOCK_DGRAM为UDP数据报套接字
    int fd=socket(AF_INET,SOCK_DGRAM,0);
    assert(fd!=-1);

    struct sockaddr_in saddr;//服务器套接字结构
    struct sockaddr_in caddr;//客户端套接字结构
    //saddr其实有四项成员，最后一项用来占位的，必须搞为0，索性我们开始直接给全部置为0，后面再来绑定ip和端口
    saddr.sin_family=AF_INET;//地址族，TCP/ipv4协议族
    saddr.sin_port=htons(6000);//将端口值从小端序列转换为大端序列
    saddr.sin_addr.s_addr=inet_addr("172.27.209.173");//将一个点分十进制的ip地址转换为一个长整型数

    //将套接字fd与本地ip地址绑定【此处注意强转】
    int res=bind(fd,(struct sockaddr*)&saddr,sizeof(saddr));
    assert(res!=-1);

    /*UDP协议传输中没有监听队列这个东西*/

    while(1)
    {
        //接收缓冲区
        char buff[128]={0};
        int len=sizeof(caddr);
        //接收来自客户端发送的数据
        recvfrom(fd,buff,127,0,(struct sockaddr*)&caddr,(socklen_t*)&len);
        printf("buff: %s\n",buff);
        //将OK发送回客户端
        sendto(fd,"ok\n",3,0,(struct sockaddr*)&caddr,(socklen_t)len);
    }
    close(fd);
}

二、QUIC协议

1.QUIC 是如何实现可靠传输的？

一个 Packet 报文中可以存放多个 QUIC Frame。每一个 Frame 都有明确的类型，针对类型的不同，功能也不同，自然格式也不同。

举例 Stream 类型的 Frame 格式，Stream 可以认为就是一条 HTTP 请求：

Stream ID 作用：多个并发传输的 HTTP 消息，通过不同的 Stream ID 加以区别，类似于 HTTP2 的 Stream ID；
Offset 作用：类似于 TCP 协议中的 Seq 序号，保证数据的顺序性和可靠性；
Length 作用：指明了 Frame 数据的长度。

数据包 Packet N 丢失了，后面重传该数据包的编号为 Packet N+2，丢失的数据包和重传的数据包 Stream ID 与 Offset 都一致，说明这两个数据包的内容一致。这些数据包传输到接收端后，接收端能根据 Stream ID 与 Offset 字段信息将 Stream x 和 Stream x+y 按照顺序组织起来，然后交给应用程序处理。

总的来说，QUIC 通过单向递增的 Packet Number，配合 Stream ID 与 Offset 字段信息，可以支持乱序确认而不影响数据包的正确组装，摆脱了TCP 必须按顺序确认应答 ACK 的限制，解决了 TCP 因某个数据包重传而阻塞后续所有待发送数据包的问题。

2.QUIC 是如何解决 TCP 队头阻塞问题的？

HTTP/2 的队头阻塞

HTTP/2 多个 Stream 请求都是在一条 TCP 连接上传输，这意味着多个 Stream 共用同一个 TCP 滑动窗口，那么当发生数据丢失，滑动窗口是无法往前移动的，此时就会阻塞住所有的 HTTP 请求，这属于 TCP 层队头阻塞。

没有队头阻塞的 QUIC

QUIC 给每一个 Stream 都分配了一个独立的滑动窗口，这样使得一个连接上的多个 Stream 之间没有依赖关系，都是相互独立的，各自控制的滑动窗口。

假如 Stream2 丢了一个 UDP 包，也只会影响 Stream2 的处理，不会影响其他 Stream，与 HTTP/2 不同，HTTP/2 只要某个流中的数据包丢失了，同一个HTTP连接的其他流也会因此受影响。

3.QUIC 是如何做流量控制的？

同一个 Stream 的数据也是要保证顺序的，不然无法实现可靠传输，因此同一个 Stream 的数据包丢失了，也会造成窗口无法滑动。

QUIC 的每个 Stream 都有各自的滑动窗口，不同 Stream 互相独立，队头的 Stream A 被阻塞后，不妨碍 StreamB、C的读取。而对于 HTTP/2 而言，所有的 Stream 都跑在一条 TCP 连接上，而这些 Stream 共享一个滑动窗口，因此同一个连接内，Stream A 被阻塞后， StreamB、StreamC 必须等待。

QUIC 实现了两种级别的流量控制，分别为 Stream 和 Connection 两种级别：

Stream 级别的流量控制：Stream 可以认为就是一条 HTTP 请求，每个 Stream 都有独立的滑动窗口，所以每个 Stream 都可以做流量控制，防止单个 Stream 消耗连接的全部接收缓冲。
Connection 级别的流量控制：限制连接中所有 Stream 相加起来的总字节数，防止发送方超过连接的缓冲容量。

Stream 级别的流量控制：

Connection 级别的流量控制：

4.QUIC 对拥塞控制改进

因为 QUIC 处于应用层，所以就可以针对不同的应用设置不同的拥塞控制算法。

5.QUIC 更快的连接建立

QUIC 内部包含了 TLS，它在自己的帧会携带 TLS 里的“记录”，再加上 QUIC 使用的是 TLS1.3，因此仅需 1 个 RTT 就可以「同时」完成建立连接与密钥协商，甚至在第二次连接的时候，应用数据包可以和 QUIC 握手信息一起发送，达到 0-RTT 的效果。

QUIC 具体握手过程如下：

客户端判断本地是否已有服务器的全部配置参数（证书配置信息），如果有则直接跳转到(5)，否则继续；
客户端向服务器发送CHLO消息，请求服务器传输配置参数；
服务器收到 CHLO，回复REJ消息，其中包含服务器的部分配置参数；
客户端收到REJ，提取并存储服务器配置参数，跳回到(1) ；
客户端向服务器发送 full client hello 消息，开始正式握手，消息中包括客户端选择的一个公开数。此时客户端根据获取的服务器配置参数和客户端选择的公开数，可以计算出初始密钥 K1；
服务器收到 full client hello，如果同意连接，根据客户端的公开数计算出初始密钥 K1，回复 SHLO消息，SHLO 用初始密钥 K1 加密，并且其中包含服务器选择的一个临时公开数；
客户端收到服务器的回复，如果是 SHLO，则尝试用初始密钥 K1 解密，提取出临时公开数；
客户端和服务器根据临时公开数和初始密钥 K1，各自基于 SHA-256 算法推导出会话密钥 K2；
双方更换为使用会话密钥 K2 通信，初始密钥 K1 此时已无用，QUIC 握手过程完毕。

上述QUIC握手步骤，其中步骤1-4均为客户端获取服务器配置信息，步骤5-8为真正的握手阶段，耗时1RTT。

6.QUIC 是如何迁移连接的？

那么当移动设备的网络从 4G 切换到 WIFI 时，意味着 IP 地址变化了，那么就必须要断开连接，然后重新建立 TCP 连接。

而建立连接的过程包含 TCP 三次握手和 TLS 四次握手的时延，以及 TCP 慢启动的减速过程，给用户的感觉就是网络突然卡顿了一下，因此连接的迁移成本是很高的。

QUIC 协议没有用四元组的方式来“绑定”连接，而是通过64 位的随机数作为连接 ID来标记通信的两个端点，客户端和服务器可以各自选择一组 ID 来标记自己，因此即使移动设备的网络变化后，导致 IP 地址变化了，只要仍保有上下文信息（比如连接 ID、TLS 密钥等），就可以“无缝”地复用原连接，消除重连的成本，没有丝毫卡顿感，达到了连接迁移的功能。

UDP通信协议详解_udp_神厨小福贵！-DevPress官方社区
 4.17 如何基于 UDP 协议实现可靠传输？ | 小林coding
QUIC 协议原理浅解_腾讯技术工程的博客-CSDN博客
 HTTP/3核心概念之QUIC - 掘金
 10 分钟讲完 QUIC 协议 - 掘金