UDP

由[RFC 768]定义的UDP只是做了运输协议能够做的最少工作。出了复用/分解功能及少量的差错检验外,它几乎没有对IP增加别的东西。UDP从应用进程得到数据,附加上用于多路复用/分解服务的源和目的端口号字段,以及两个其他的小字段,然后将形成的报文段交给网络层。网络层将该运输层报文段封装到一个IP数据报中,然后尽力而为地尝试将此报文段交付给接收主机。如果该报文段到达接收主机,UDP使用目的端口号将报文段中的数据交付给正确的应用进程。值得注意的是,使用UDP时,在发送报文段前,发送方和接收方的运输层实体之间没有握手。正因为如此,UDP称为是无连接的。

DNS是一个通常使用UDP的应用层协议的例子。当一台主机中的DNS程序想要进行一次查询时,它构建了一个DNS查询报文并将其交给UDP。无须执行任何与运行在目的端系统中的UDP实体之间的握手,主机端的UDP为此报文添加首部字段,然后将形成的报文段交给网络层。网络层将此UDP报文段封装进一个IP数据报中,然后将其发送给一个域名服务器。在查询主机中的DNS应用程序则等待对该查询的响应。如果它没有收到响应(可能是由于底层网络丢失了查询或响应),则要么试图向另一个名字服务器发送该查询,要么通知调用的应用程序它不能获得响应。

在某些情况下UDP比TCP更适用:

  1. 关于何时、发送什么数据的应用层控制更为精细:采用UDP时,只要应用进程将数据传递给UDP,UDP就会将此数据打包进UDP报文段并立即将其传递给网络层。在另一方面,TCP有一个拥塞控制机制,以便当源和目的主机间的一条或多条链路变得极度拥塞时来遏制运输层TCP发送方。TCP仍将继续重新发送数据报文段直到目的主机收到此报文并加以确认,而不管可靠交付需要用多长时间。因为实时应用通常要求最小的发送速率,不希望过分地延迟报文段的传送,且能容忍一些数据丢失,TCP的服务模型并不是特别适合这些应用的需要。这些应用可以使用UDP,并作为应用的一部分来实现所需的、超出UDP的不提供不必要的报文段交付服务之外的额外功能。
  2. 无需连接建立:TCP在开始数据传输前要经过三次握手,UDP却不需要任何准备即可进行数据传输。因此UDP不会引入建立连接的时延。HTTP使用TCP而不是UDP,因为对于具有文本数的Web网页来说,可靠性是至关重要的。
  3. 无连接状态:TCP需要在端系统中维护连接状态。此连接状态包括接收和发送缓存、拥塞控制参数以及序号与确认号的参数。对于某些专门用于某特定应用的服务器,当运行在UDP之上而不是运行在TCP上时,一般都能支持更多的活跃客户。
  4. 分组首部开销小:每个TCP报文段都有20字节的首部开销,而UDP仅有8字节的开销

以下是流行的因特网引用以及其下的运输协议:
在这里插入图片描述

使用UDP的应用是可以实现可靠数据传输的,这可通过在应用程序自身中建立可靠性机制来完成(例如,可通过增加确认与重传机制来实现)

一、UDP报文段结构

在这里插入图片描述
如上图所示,应用层数据占用UDP报文段的数据字段。UDP首部只有4个字段,每个字段由两个字节组成。通过端口号可以使目的主机将应用数据交给运行在目的端系统中的相应进程(即执行分解功能)。长度字段指示了在UDP报文段中的字节数(首部加数据)。接收方使用检验和来检查在该报文段中是否出现了差错。

二、UDP检验和

(待补充/144)

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值