UDP:修订间差异
建立內容為「400px Category:Network」的新頁面 |
|||
(未显示同一用户的4个中间版本) | |||
第1行: | 第1行: | ||
UDP即用户数据报协议(User Datagram Protocol)。在TCP/IP模型中,UDP为网络层以上和应用层以下提供了一个简单的接口。UDP只提供数据的不可靠传递,它一旦把应用程序发给网络层的数据发送出去,就不保留数据备份(所以UDP有时候也被认为是不可靠的数据报协议)。UDP在IP数据报的头部仅仅加入了复用和数据校验字段。 | |||
UDP适用于不需要或在程序中执行错误检查和纠正的应用,它避免了协议栈中此类处理的开销。对时间有较高要求的应用程序通常使用UDP,因为丢弃数据包比等待或重传导致延迟更可取。 | |||
[[Image:UDP_encapsulation.png|400px]] | [[Image:UDP_encapsulation.png|400px]] | ||
=可靠性= | |||
一些应用程序不太需要可靠性机制,甚至可能因为引入可靠性机制而降低性能,所以它们使用UDP这种缺乏可靠性的协议。流媒体,实时多人游戏和IP语音(VoIP)是经常使用UDP的应用程序。 在这些特定应用中,丢包通常不是重大问题。如果应用程序需要高度可靠性,则可以使用诸如TCP之类的协议。 | |||
例如,在VoIP中延迟和抖动是主要问题。如果使用TCP,那么任何数据包丢失或错误都将导致抖动,因为TCP在请求及重传丢失数据时不向应用程序提供后续数据。如果使用UDP,那么应用程序则需要提供必要的握手,例如实时确认已收到的消息。 | |||
由于UDP缺乏拥塞控制,所以需要基于网络的机制来减少因失控和高速UDP流量负荷而导致的拥塞崩溃效应。换句话说,因为UDP发送端无法检测拥塞,所以像使用包队列和丢弃技术的路由器之类的网络基础设备会被用于降低UDP过大流量。数据拥塞控制协议(DCCP)设计成通过在诸如流媒体类型的高速率UDP流中增加主机拥塞控制,来减小这个潜在的问题。 | |||
=报文结构= | |||
报文头包含四个字段共计8个字节: | |||
* 源端口 | |||
* 目的端口 | |||
* 长度 | |||
* 校验和 | |||
为计算校验和,会在报文前面添加伪头部,讲IPv4或者ipv6中的地址信息等添加进去以计算校验和。 | |||
= Check UDP Connectivity = | |||
<syntaxhighlight lang="bash"> | |||
nc -v -u -z -w 3 geekflare.com 20-30 | |||
Connection to geekflare.com port 20 [udp/ftp-data] succeeded! | |||
Connection to geekflare.com port 21 [udp/ftp] succeeded! | |||
Connection to geekflare.com port 22 [udp/ssh] succeeded! | |||
Connection to geekflare.com port 23 [udp/telnet] succeeded! | |||
Connection to geekflare.com port 24 [udp/*] succeeded! | |||
Connection to geekflare.com port 25 [udp/smtp] succeeded! | |||
Connection to geekflare.com port 26 [udp/*] succeeded! | |||
Connection to geekflare.com port 27 [udp/nsw-fe] succeeded! | |||
Connection to geekflare.com port 28 [udp/*] succeeded! | |||
Connection to geekflare.com port 29 [udp/msg-icp] succeeded! | |||
Connection to geekflare.com port 30 [udp/*] succeeded! | |||
</syntaxhighlight> | |||
[[Category:Network]] | [[Category:Network]] | ||
[[Category:UDP]] | |||
[[Category:RFC]] | |||
[[Category:Protocol]] |
2024年1月23日 (二) 04:11的最新版本
UDP即用户数据报协议(User Datagram Protocol)。在TCP/IP模型中,UDP为网络层以上和应用层以下提供了一个简单的接口。UDP只提供数据的不可靠传递,它一旦把应用程序发给网络层的数据发送出去,就不保留数据备份(所以UDP有时候也被认为是不可靠的数据报协议)。UDP在IP数据报的头部仅仅加入了复用和数据校验字段。
UDP适用于不需要或在程序中执行错误检查和纠正的应用,它避免了协议栈中此类处理的开销。对时间有较高要求的应用程序通常使用UDP,因为丢弃数据包比等待或重传导致延迟更可取。
可靠性
一些应用程序不太需要可靠性机制,甚至可能因为引入可靠性机制而降低性能,所以它们使用UDP这种缺乏可靠性的协议。流媒体,实时多人游戏和IP语音(VoIP)是经常使用UDP的应用程序。 在这些特定应用中,丢包通常不是重大问题。如果应用程序需要高度可靠性,则可以使用诸如TCP之类的协议。
例如,在VoIP中延迟和抖动是主要问题。如果使用TCP,那么任何数据包丢失或错误都将导致抖动,因为TCP在请求及重传丢失数据时不向应用程序提供后续数据。如果使用UDP,那么应用程序则需要提供必要的握手,例如实时确认已收到的消息。
由于UDP缺乏拥塞控制,所以需要基于网络的机制来减少因失控和高速UDP流量负荷而导致的拥塞崩溃效应。换句话说,因为UDP发送端无法检测拥塞,所以像使用包队列和丢弃技术的路由器之类的网络基础设备会被用于降低UDP过大流量。数据拥塞控制协议(DCCP)设计成通过在诸如流媒体类型的高速率UDP流中增加主机拥塞控制,来减小这个潜在的问题。
报文结构
报文头包含四个字段共计8个字节:
- 源端口
- 目的端口
- 长度
- 校验和
为计算校验和,会在报文前面添加伪头部,讲IPv4或者ipv6中的地址信息等添加进去以计算校验和。
Check UDP Connectivity
nc -v -u -z -w 3 geekflare.com 20-30
Connection to geekflare.com port 20 [udp/ftp-data] succeeded!
Connection to geekflare.com port 21 [udp/ftp] succeeded!
Connection to geekflare.com port 22 [udp/ssh] succeeded!
Connection to geekflare.com port 23 [udp/telnet] succeeded!
Connection to geekflare.com port 24 [udp/*] succeeded!
Connection to geekflare.com port 25 [udp/smtp] succeeded!
Connection to geekflare.com port 26 [udp/*] succeeded!
Connection to geekflare.com port 27 [udp/nsw-fe] succeeded!
Connection to geekflare.com port 28 [udp/*] succeeded!
Connection to geekflare.com port 29 [udp/msg-icp] succeeded!
Connection to geekflare.com port 30 [udp/*] succeeded!