网络协议五步登天路,咱们一路迈过了物理层、链路层,今天终于到了传输层。从这一层开始,不少知识应该都是服务端开发必备的知识了,今天咱们就一块儿来梳理下。html
其实,讲到 UDP,就少不了 TCP。这俩货简直就是个“连体兄弟”,只要出现一个,另外一个确定就在不远处等着你。面试
博主相信,绝大多数的服务端开发都碰到过“TCP 与 UDP 的区别”这样的面试题,而在实际业务开发中,也会对比 TCP 与 UDP,选择合适的协议进行开发。服务器
因此,我们仍是老生常谈,先来看看这俩兄弟的区别。网络
相信不少人都知道,TCP 是面向链接的,UDP 是面向无链接的。数据结构
那么,什么是面向链接,什么是面向无链接呢?app
在互通以前,面向链接的协议会先创建链接,再进行通讯。就像 TCP 会进行三次握手,而 UDP 不会。异步
那为何会创建链接呢?TCP 进行三次握手,UDP 就不能发三个数据包玩玩,有什么区别呢?tcp
其实这里所谓的创建链接,就是经过创建必定的数据结构来维护客户端和服务端交互的状态,用这样的数据结构来保证所谓的面向链接的特性。性能
上面这段话中,有一个很重要的词-状态。也就是说,TCP 实质上是一个有状态的服务。这个状态,能够说是它和 UDP 的本质区别。ui
通俗点讲,有状态的 TCP 就是有脑子的,它会记住数据是否已经精确发送了,发到哪里了,应该接收哪一个数据,不能容忍一点错误。
与之对应的,UDP 就是没脑子的,天真无邪,发出去的数据就发出去,不会考虑网络世界的“恶意”。
TCP 既然有脑子,那确定能作到不少 UDP 作不到的事情,例如:
发送的 UDP 包到达目标机器后,发现 MAC 地址匹配,因而取下来,而后再交给 IP 层处理,发现 IP 匹配,接下来呢?数据包给谁呢?
发送的时候,接收机器怎么知道数据包是 UDP 的包呢?因此在 IP 头里面有个 8 位协议,这里会存放,数据包到底是 TCP 仍是 UDP。
处理完传输层的事情,内核的事情基本上就干完了,里面的数据应该交给应用程序本身去处理。但是,一台机器上跑着那么多的应用程序,应该给谁呢?
不管应用程序写的是使用 TCP 传呼机,仍是 UDP 传数据,都要监听一个端口。正式这个端口,用来区分应用程序。
这样,UDP 头里面的内容就都出来了,以下图:
当咱们看到 UDP 包头的时候,发现的确有端口号,有源端口号和目标端口号。可是它除了端口号,就再没有其余的,和 TCP 头比起来,简单的一塌糊涂。
上面提过,UDP 像个小孩子同样,比较简单,有如下特色:
正所谓“祸兮福所倚”,虽然 UDP 有着不少问题,但也能够在特定场景中发挥更好的做用。
第一,须要资源少,在网络状况比较好的内网,或者对于丢包不敏感的应用。这很好理解,就像你是领导,你会让大家组刚毕业的小伙伴去作一些没有那么难,或者是失败了也能忍受的实验性项目。
咱们以前认识的 DHCP 就是基于 UDP 协议的。通常的获取 IP 地址都是内网请求,并且一次获取不到 IP 也不要紧,过一会还能够请求获取。
第二,不须要创建链接,一对一沟通,并且须要广播的应用。 UDP 的不面向链接的功能,能够承载广播或多播的协议。DHCP 就是一种广播的形式。
对于多播,咱们以前提到的 IP 地址中的 D 类地址,也就是组播地址。使用这个地址,能够将包组播给一批机器。当一台机器上的某个进程想监听某个组播地址时,须要发送 IGMP 包,所在网络的路由器收到这个包,知道有个机器有个进程在监听这个组播地址。当路由器收到这个组播地址的数据包时,就会将包转发给这台机器,这样就实现了跨路由器的组播。
第三,须要处理速度快、延时低、能够容忍少数丢包,可是要求即使网络阻塞,也绝不退缩,勇往直前的时候。
UDP 简单、处理速度快,不像 TCP 那样操那么多的心。而且,TCP 在网络很差出现丢包的时候,它的拥塞策略会主动的下降发送速度,这就至关于原本环境就差,还自断臂膀,用户原本就卡,这下更卡了。
当前不少应用都是要求低时延的,他们可不想用 TCP 如此复杂的机制,而是想根据本身的场景,实现本身的可靠和链接保证。例如,若是应用以为,有的包丢了就丢了,不必重传了,而有的比较重要的包丢了,则应用本身重传,不依赖 TCP。
因为 UDP 十分简单,基本啥都没作,也就给了应用“城会玩”的机会。就像在和平年代,每一个人应该有独立的思考和行为,应该可靠且礼让。可是若是在战争年代,每每不太须要过于独立的思考,而须要士兵简单服从命令便可。
网页和手机 APP 都是基于 HTTP 协议的,而HTTP 协议是基于 TCP 的,创建链接都须要屡次交互,对于时延比较大的移动互联网来说,创建一次链接须要的时间会比较长,并且移动互联网仍是在移动中,TCP 可能还会断了重连,这也是很耗时的。
除此以外,目前的 HTTP 协议,每每采起多个数据通道共享一个链接的状况这样原本为了加快传输速度,可是 TCP 的严格顺序策略使得哪怕共享通道,前一个不来,后一个和前一个即使不要紧,也要等着,时延也会加大。
而 QUIC(Quik UDP Internet Connections,快速 UDP 互联网链接)是 Google 提出的一种基于 UDP 改进的通讯协议,其目的是下降网络通讯的延迟,提供更好的用户互动体验。
QUIC 在应用层会本身实现快速链接创建、减小重传时延,自适应拥塞控制,是应用层“城会玩”的表明。
直播协议多使用 RTMP,这个协议就是基于 UDP 的。TCP 的严格顺序传输要保证前一个收到了,下一个才能确认。对于直播来说,这显然是不合适的,由于老的视频帧丢了就丢了,就算再传过来用户也不在乎,他们要看新的了,若是一直没来,用户就会一直显示卡顿,新的也看不了。因此,对于直播,实时性比较重要,宁肯丢包,也不要卡顿的。
另外,对于丢包,其实对于食品播放来说,有的包能够丢,有的包不能丢,由于视频的连续帧里面,有的包重要,有的包不重要,若是必需要丢包,隔几个帧丢一个,其实看视频的人不会感知,可是若是连续丢帧,用户就会有感知了。所以,在网络很差的状况下,应用但愿选择性的丢帧。
还有就是,当网络很差的时候,TCP 会主动下降发送速度。这对原本就卡的看视频来说是要命的,原本应该立刻重传,而不是主动让步。所以,不少直播应用,都基于 UDP 实现了本身的视频传输协议。
游戏有一个特色,就是实时性比较高。快一秒你干掉别人,慢一秒就被别人爆头,因此不少职业玩家会买很是专业的鼠标和键盘,争分夺秒。
于是,实时游戏中客户端和服务端要创建长链接,来保证明时传输,可是游戏玩家不少,服务器却很少,因为维护 TCP 链接须要在内核维护一些数据结构,于是一台机器可以支撑的 TCP 链接数量是有限的。而 UDP 因为是没有链接的,在异步 IO 机制引入以前,经常是应对海量客户端链接的策略。
另外仍是 TCP 的强顺序问题,对战的游戏,对网络的要求很简单,玩家经过客户端发送给服务器鼠标和键盘行走的位置,服务器会处理每一个用户发送过来的全部厂家,处理完再返回给客户端,客户端解析响应,渲染最新的场景展现给玩家。
若是出现一个数据包丢失,全部事情都须要停下来等待这个数据包重发。客户端会出现等待接收数据,然而玩家并不关心过时的数据,相信你们玩CF 的时候,若是激战中卡 1 秒,是否是就有拍键盘的冲动?
游戏对实时要求较为严格的状况下,采用自定义的 UDP 协议,自定义重传策略,可以把丢包产生的延迟降到最低,尽可能减小网络问题对游戏性能形成的影响。
一方面,物联网领域终端资源少,极可能只是内存很是小的嵌入式系统,而维护 TCP 协议代价太大。另外一方面,物联网对实时性要求也很高。Google 旗下的 Nest 创建 Thread Group,推出了物联网通讯协议 Thread,就是基于 UDP 协议的。
在 4G 网络里,移动流量上网的数据协议 GTP-U 也是基于 UDP 的。由于移动网络协议比较复杂,而 GTP 协议自己就包含复杂的手机上线下线的通讯协议。
若是把 TCP 比做成熟的社会人,那么 UDP 就是头脑简单的小朋友。TCP 复杂,UDP 简单;TCP 维护链接,UDP 谁都相信;TCP 会知进退,UDP 愣头青一个,一往无前;
UDP 虽然简单,可是它能够用在环境简单、须要多播、应用层本身控制传输的地方。例如 DHCP、QUIC 等。
参考: