网路是怎样连接的(十)UDP简介

思考重点

• 为甚麽要设计UDP?
• UDP对比TCP的优势?

核心知识

UDP与TCP的差别

众所皆知，TCP是面向连接的可靠传输，前几篇文章我们也从TCP消息的收发讲到如何确认回应，再谈到TCP一系列特殊的效率优化机制，本篇就要来谈谈传输层的另一种传输协议UDP(User Datagram Protocol)，到底UDP相较TCP有什麽不同之处?其实如果我们知道TCP设计的初衷，那麽就可以理解UDP了

TCP具有响应确认与重传、滑动窗口、流量控制、壅塞控制，之所以这麽复杂，无非就是要面对几个问题:

1. 怎麽样才能高效传输资料
2. 在高效传输资料的情况下，要麽知道封包没有遗失
3. 如何避免封包遗失
4. 封包遗失了怎麽在最短时间内重传
5. 要如何只重传特定遗失的封包，而不是重传整个资料

这些就是TCP的设计原因，为了解决特定封包的重传才有了这麽多的收发机制。UDP恰恰相反，它主打说走就走，随插即用的收发方式，也就是说上述原因一盖不讨论，UDP只管将应用程序数据装上头部消息就可以发送了

因为UDP发後不理的不可靠性，在封包传输过程中必须仰赖应用程序进行封包的重传判断以及收发处理，也就是说应用程序开发者必须要另外开发一块专门判断封包传输状况的区块来控制消息。你也可以说是将TCP一系列的复杂处理程序揽到自己身上来。乍看之下需要额外的开发时间与空间，不过这也解放了开发者对传输过程的控制权，可以依照应用程序特性量身打造传输判断机制，所以UDP也可以说是为开发特定应用程序提供传输控制权的一种通讯协定

此外由於TCP的可靠性传输，它在一定程度上牺牲了即时性，你想想每次进行通讯前都要进行三次握手，通讯过程中也需要时时判断消息是否被成功接收，更不用说如果发生逾时。现实中很多事往往不能兼得，硬币的另一面就是这些机制会以及时性作为代价，但UDP不需要考虑这些问题，它只判断是否有数据进来，有那就发送，丢失了那就再重发一次，牺牲了可靠性，换来更快速的反应，UDP就像毫无拘束的儿童，想干嘛较干嘛

TCP与UDP的比较

UDP的使用场景

短封包

UDP适合那种封包长度小，尤其是不用分段的消息封包，如此一来就不用考虑分段丢失问题，另外假如该封包在传输过程中丢失，因为封包较小的特性，重传也不会占用网路太多资源。使用场景如常见的DNS请求、SNMP简单网路管理协定、RIP路由协定等

多媒体

UDP的即时性还可以在多媒体领域发挥所长，特别是直播与即时影音等需要Live现场互动的影音媒体。就算发生网路问题，直接发送下一个封包就好了，毕竟不会有观众会慢慢等待丢失的影像回传，。此外如果在直播这种不断发送封包的场景使用逾时重传等机制，会对加重原本就很吃紧的网路状况

TCP的用武之地 : 串流(Stream Media)
TCP适合那种不需要即时性的影片，例如youtube上的影片，这些称为串流媒体，即将多媒体影像压缩後，稳定
发送给客户端，多媒体资料可以在观看影片的同时下载，这时候就会需要TCP稳定且可靠的特性。

另外需要统一传送通讯的场合也适合使用UDP，例如广播(Broadcasting)和群播(Multicast)这种一对多传输

UDP头部

发送方端口号
发送方的端口号，长度为16个bits。可选项目，不需要回应的通讯可以不填，该值会被设置成0

接收方端口号
接收方的端口号，长度为16个bits

资料长度
UDP头部与资料的总长，长度为16个bits

检查码
用於校验错误，长度为16个bits

总结

UDP是一种不提供非必要服务的通讯协定，它的关注点更多是放在如何将封包传送出去，仅此而已

UDP是不可靠的，也就是说它没有像TCP一样的握手建立连线流程，socket创建後就直接将封包发往指定IP地址上的指定端口号应用程序，另外UDP不需要ACK响应来确认对方是否收到消息，这有可能造成封包的乱序到达以及丢失问题。缺乏壅塞控制，也使得UDP可以依照想要的速率发送封包(不过真实的封包传输速率还是要看网路核心中的带宽限制)

听起来UDP好像什麽事也没做，也不如TCP来的厉害，不过传输层的分工一直都是为端到端之间的应用进程提供相互通讯的渠道，TCP与UDP双双承接了这个使命，差别在於它们选择了不同的道路，UDP崇尚大道至简，选择不提供稳定性上的服务，换来了即时性优势，乍看之下是什麽都没做，但不做选择也是一种选择，为了不同应用场景提供不同服务才是网路分层追求的目的，而不是越复杂越好