【网络】计算机网络笔记——UDP 协议笔记

UDP 协议相对于 TCP 来说就没有那么多复杂的功能了,它只在 IP 协议提供的不可靠服务的基础上增加了一些基本的功能。

报文格式

我们先来看看它的报文格式:

可以看到,它的首部只有以下四个字段:

  • 源端口号:数据源进程的端口号
  • 目的端口号:目的进程的端口号
  • UDP 长度:表示 UDP 报文的长度(包括首部)
  • UDP 检验和:用于进行差错检测的检验和。

同时,只需要 目的 IP 地址目的端口号 这样一个二元组即可唯一确定一个 UDP Socket

这里不得不思考一下,为什么 UDP 只需要这样一个二元组就可以唯一确定一个 Socket 呢?

因为 UDP 它并不是面向连接的,接收方完全可以用一个 Socket 来接收不同的源发来的数据,并不需要像 TCP 一样向源回馈是否收到,因为对方并不关心。

UDP 的伪首部

UDP 的检验和不仅仅包含了数据及 UDP 首部,还包含了一个 12 字节的 『伪首部』。它添加在 UDP 首部前面,只是为了用于计算检验和而临时存在,目的是让 UDP 判断目的是否正确到达目的地。

UDP 的使用场景

UDP 的使用场景主要在于一些不是那么在意对方是否收到的场景下,这些场景往往需要对方能更快地收到数据而并不在意数据是否一定能够收到。

例如日常生活中常见的一些视频播放、网络直播,以及一些在线游戏,这些服务的即时性非常强,需要即时收到最新的数据,因此之前发出的数据是否收到就显得没那么重要了。

UDP 如何实现可靠传输

以下内容参考自 RUDP传输那些事儿

这个标题可能非常奇怪,UDP 本来就是不可靠的,为什么还要把它变成可靠的呢?如果需要可靠性直接使用 TCP 不就好了么?

实际上 TCP 所实现的可靠性是一种完全可靠,也就是说,发送端发送的数据必须完整按序的到达接收端。

但这样完全可靠带来的后果就是在一些比较苛刻的条件下 TCP 无法保证通信的质量,并且要进行 TCP 传输,还需要首先进行三次握手,关闭时还需要进行四次挥手,也就是说:TCP 带来的可靠性成本在某些场景下过高了

因此,出现了一种 RUDP(Reliable UDP)协议,也就是可靠的 UDP 协议,它基于 UDP 实现了一个介于 UDP 与 TCP 之间的基本可靠的保证,同时相比 TCP 它的成本更低,传输效率更高。像 Google 推出的 QUIC 协议中就采用了 RUDP 来实现。

重传

为了实现 UDP 的可靠,首先我们要引入重传机制。下面是 RUDP 的基本框架:

RUDP 的重传通过接收端 ACK 的丢包信息进行数据重传,发送端会根据场景来设计自己的重传方式:

超时重传

定时重传就是指发送方在经过一个超时时间(RTO)之后还是没有收到对方的 ACK,则对这个数据包进行重传,这与 TCP 的超时重传机制类似。

如果使用的场景对延迟较敏感但不在意流量成本,可以将 RTO 设置的小一些,例如在线游戏等。

请求重传

请求重传指接收端进行 ACK 时在报文中携带丢失的报文信息,发送端收到 ACK 时会提取丢失的报文信息并进行重传。

由于 UDP 在传输过程中不保证按序,会造成包的乱序,因此不能像上图中这样理想的认为 104 到达就把前面没有到达的进行请求重传。我们可以设定一个时延 RTT,如果在发现丢包的情况的时候,还不把这个包视为丢包,而是等它被视为丢包的时间超过了 RTT 时,再将其确定为丢包,进行请求重传。

也就是说,假设发现丢包的时间为 time,则当 time + RTT < currentTime 时再进行请求重传。

FEC 选择重传

除了超时重传和请求重传之外,还存在着一种前向纠错(FEC)选择重传。

FEC 选择重传的方式是给予 FEC 前向纠错技术。发送方发送报文的时候会通过 FEC 算法根据前面几个报文生成 FEC 报文,当接收方发现丢包时,首先会尝试通过 FEC 算法来尝试恢复出丢失的报文。如果能够恢复,就不再向发送方请求重传。但显然,如果没有发生丢包,那 FEC 报文就是冗余的,会增大带宽压力。

拥塞控制

为了实现拥塞控制,RUDP 往往也在接收方和发送方分别维护了接收窗口和发送窗口。

但接收窗口是否进行排序、缓冲就取决于 RUDP 的具体策略。如果 RUDP 要实现可靠、有序的数据传输,就会对接收窗口进行排序、缓冲,否则往往就不进行窗口缓冲,直接进行位置滑动。

经典拥塞控制算法

经典拥塞控制算法就是 TCP 所使用的那一套拥塞控制算法,也就是慢启动拥塞避免快速恢复

慢启动

cwnd 从 1 开始呈指数增长,每次乘以 2(每收到一个 ACK 加 1)。

拥塞避免

cwnd 呈线性增长,每次加 1(收到一组 ACk 加 1)。

快速恢复

cwnd 固定,每收到一个向前滑动 1。

BBR 拥塞控制算法

经典拥塞控制算法存在对延迟和带宽的压榨问题,因此 Google 设计了一种基于发送端延迟和带宽评估的 BBR 拥塞控制。它的主要目的是实现如下两个功能:

  1. 在存在一定丢包率的网络上充分利用带宽。
  2. 降低网络传输中的延迟。

它主要的策略是通过一种周期性的 ACK 及 NACK 对链路的 min_rttmax_bandwidth 进行评估。

而拥塞窗口大小 cwnd = max_bandwidth / min_rtt

与 TCP 的对比

最后我们将 UDP 与 TCP 进行一下对比:

相比 TCP 协议来说,UDP 协议有以下区别:

  • TCP 是面向字节流的,它的数据是没有边界的。而 UDP 是面向报文的,它的数据是有边界的。(体现在前面一篇 TCP 的文章中提到的粘包问题上)
  • TCP 协议可以保证数据的按序、可靠交付,UDP 无法保证数据的可靠交付
  • TCP 协议是面向连接的,在发送数据前要通过三次握手建立连接,关闭连接需要四次挥手,而 UDP 不需要。
  • TCP Socket 需要通过 目的、源 IP 以及 目的、源端口号 这个四元组唯一确定,而 UDP Socket 只需要通过 目的 IP 以及 目的端口号 这个二元组即可唯一确定。
  • TCP 为了保证可靠交付丧失了一定的传输效率,而 UDP 的传输效率更高。
  • TCP 的首部在不包含选项字段的情况下有 20 个字节,而 UDP 的首部仅仅有 8 个字节。
  • TCP 只支持一对一的数据传输,而 UDP 支持一对一、一对多、多对一的数据传输。
  • TCP 具有拥塞控制,可以进尽量避免网络中出现拥塞,而 UDP 则没有拥塞控制,并不会因为中间网络的拥塞而减小占用的带宽,有可能造成加剧网络拥堵。

参考资料

《TCP/IP 详解卷 1》

RUDP传输那些事儿

点赞

发表评论

电子邮件地址不会被公开。必填项已用 * 标注

%d 博主赞过: