udp端口范围_有了IP，为何还需要UDP？

既然IP协议也能够进行数据的无连接不可靠传输服务，为什么还需要UDP协议？ 协议复用 IP Header 协议字段只有一个字节，即最多提供255种协议的辨识，而且基本都被大牌协议所霸占着，比如：1 ICMP，2 IGMP，6 TCP，17 UDP，47 GRE，50 ESP，51 AH，88 EIGRP，89OSPF，115 L2TPv3等等。留给终端用户的空间非常小，所以需要UDP提供更大的端口空间来满足用户的应用程序的需求。UDP端口号占两个字节，理论可以提供65535个端口号，扣除1-1023为系统保留，用户可以使用超过64000个端口号。 可选的checksum校验 UDP 提供可选的checksum校验功能，覆盖的范围：Pseudo IP Header +UDP Header + UDPPayload Pseudo IP Header： Source IP (4 Byte)+ Destination IP (4 Byte)+ Total Length (2 Byte)+ Reserved (1 Byte)+Protocol (1 Byte) 其中Reserved是为了使IP 伪头是4字节的整数倍，里面数据为0。 IP 伪头一共12个字节，采用覆盖部分IP头的考虑是：为了避免系统错误地将其它的五元组的数据发给另外一个五元组。所以UDP/IP 层并没有实现真正意义上的完全的层级独立，即网络层和传输层的独立实现。 NAT穿越 IP报文没有UDP/TCP端口号，无法完成1：N的NAT。而基于UDP的封装，有UDP端口号可以无任何障碍穿越任何NAT设备。一些基于IP的协议如标准GRE、ESP无法穿越NAT，而造成通信障碍。所以现在越来越多的基于UDP协议的隧道，那是因为现在的网络NAT无处不在啊。 诚然，在设计UDP的时候不会想到未来的网络会严重依赖端口号的翻译，由于IPv4资源枯竭，现在不得不依赖这项技术。编写socket小程序，一般都调用stream 或datagram 这两种类型，可以实现TCP-Based 或 UDP-Based程序，即用户只能封装自己application的数据，而无法对IP层、以太层进行控制和协议字段的操纵；可以采用raw 这种模式可以自定义这些底层的协议字段，包括以太网帧头，IP头。自己需要对整个包负责，保证协议字段的正确，虽然增加了复杂性，但更加灵活。 如果以上文字看完还没有理解，可以用以下的文字来辅助理解。 UDP相当于街头的邮筒，扔进去就OKAY了。IP司机会来运输这些信件，根据收件人地址送达目的地。如果IP司机翻车掉进沟里，信件也一同泡汤。发件人如何知道自己的信到达收件人？很好办，只要收件人回一封信“来信已收”！ 而TCP相当于快递公司，快递扔到快递公司就立马给你运走？没有的事，多久能运走完全看他们的调度(控制)，这也是TCP为何叫控制协议的原因，TCP要完成调度的控制。 这样一些看不惯TCP慵懒、高延迟的调度方式，于是纷纷使用UDP来完成底层封装，这样应用程序完全可以避开TCP的控制。因为UDP没有控制的，“UDP是一个说走就走的传输”，所有的控制节奏全部在应用程序本身！

“生命诚可贵，爱情价更高，若为自由故，两者皆可抛”，自由是一把双刃剑，可以减少通信的延迟，但是又需要白手起家实现类似TCP的可靠性。这个难不住通信专家们，Google开发的“QUIC”协议，直接使用UDP来传输，QUIC 实现了可靠传输，又实现了安全加密：

• 低延迟

• 可靠性

• 安全性

三者都有了，试问这不就是互联网孜孜追求的终极目标吗？ 广告 报名费300, 报名前100位的同学，5折优惠，只需要150元/年/人，以转账时间为准。   要报名的同学可以公众号后台发关键字“ 会员群 ”，获取报名链接。