zoukankan      html  css  js  c++  java
  • UDP协议

    概述

    在OSI七层协议的传输层,有两个重要协议,UDP与TCP。

    TCP与UDP区别

    TCP是面向连接的,而UDP是面向无连接的。什么是面向连接,什么叫无连接哪?在互通之前,面向连接的协议会先建立连接,是为了在客户端和服务端维护连接,而建立一定的数据结构来维护双方交互状态,用这样的数据结构来保证面向连接的特性。例如,TCP提供可靠交互,通过TCP连接传输的数据,无差错,不丢失,不重复,并且按序到达。我们都知道IP包是没有任何可靠性保证的,一旦发出去,就像西天取经,走丢了,被妖怪吃了,也不得而知,只能随它去。UDP继承了IP的特性,基于数据报发,一个一个的发,一个一个的收。

    TCP有拥塞控制,意识到包丢失或者网络的环境不好。就会根据情况调整自己的行为,是否发快了,要不要发慢些。UDP就不会,应用让我发,我就发,管它洪水滔天。因而TCP其实是有状态的一个服务,通俗的说就是有脑子,精确的记着我发送了没有,接收了没有,发送到哪个了,错一点儿都不行。而UDP则是无状态服务,就是没脑子,发出去就发出去了,不记这么多。

    UDP包头

    一个UDP包传输到目标机器,他怎么知道这个包是UDP还是TCP的哪,这是因为IP头里面有8位协议,这里面存放,数据里面是TCP还是UDP的。发现是UDP,于是我们知道UDP头的个数,就能从数据里面,将它解析出来,解析完后,交给谁处理?这时就不关传输层的事情了,里面的数据应该交给应用程序去处理,无论应用程序写的使用TCP传数据,还是UDP传数据,都要监听一个端口。正是这个端口,用来区分应用程序。

    会发现与TCP相比,UDP包简单得一塌糊涂,除了源端口和目标端口,在没有其他了。

    UDP三个特点

    沟通简单:不需要大量的数据结构,处理逻辑,包头字段,前提是它相信网络世界是美好的,秉承性善论,相信网络通路默认到达,不容易丢失。

    轻信他人:不会建立连接,虽有端口号,但监听的这个地方,谁都可以传给数据,他也可以传给任何人数据,甚至可以同时传给多个人数据。

    不懂权变:不会根据网络的情况进行发包的拥塞控制,无论网络包丢成啥样了,该怎么发还是怎么发。

    UDP使用场景

    需要资源少,在网络情况比较好的内网,或者对于丢包不敏感的应用。比如我们说过DHCP就是基于UDP协议的。

    不需要一对一沟通,建立连接,而是广播的应用,VXLAN协议就是需要用到组播。

    需要处理速度快,时延低,可容忍少数丢包。

    网页或者APP的访问

    原来访问网页和手机 APP 都是基于 HTTP 协议的。HTTP 协议是基于 TCP 的,建立连接都需要多次交互,对于时延比较大的目前主流的移动互联网来讲,建立一次连接需要的时间会比较长,然而既然是移动中,TCP 可能还会断了重连,也是很耗时的。而且目前的 HTTP 协议,往往采取多个数据通道共享一个连接的情况,这样本来为了加快传输速度,但是 TCP 的严格顺序策略使得哪怕共享通道,前一个不来,后一个和前一个即便没关系,也要等着,时延也会加大。而QUIC(全称Quick UDP Internet Connections,快速 UDP 互联网连接)是 Google 提出的一种基于 UDP 改进的通信协议,其目的是降低网络通信的延迟,提供更好的用户互动体验。QUIC 在应用层上,会自己实现快速连接建立、减少重传时延,自适应拥塞控制。

    流媒体的协议

    现在直播比较火,直播协议多使用 RTMP,而这个 RTMP 协议也是基于 TCP 的。TCP 的严格顺序传输要保证前一个收到了,下一个才能确认,如果前一个收不到,下一个就算包已经收到了,在缓存里面,也需要等着。对于直播来讲,这显然是不合适的,因为老的视频帧丢了其实也就丢了,就算再传过来用户也不在意了,他们要看新的了,如果老是没来就等着,卡顿了,新的也看不了,那就会丢失客户,所以直播,实时性比较重要,宁可丢包,也不要卡顿的。另外,对于丢包,其实对于视频播放来讲,有的包可以丢,有的包不能丢,因为视频的连续帧里面,有的帧重要,有的不重要,如果必须要丢包,隔几个帧丢一个,其实看视频的人不会感知,但是如果连续丢帧,就会感知了,因而在网络不好的情况下,应用希望选择性的丢帧。还有就是当网络不好的时候,TCP 协议会主动降低发送速度,这对本来当时就卡的看视频来讲是要命的,应该应用层马上重传,而不是主动让步。因而,很多直播应用,都基于 UDP 实现了自己的视频传输协议。

    实时游戏

    游戏有一个特点,就是实时性比较高。快一秒你干掉别人,慢一秒你被别人爆头,所以很多职业玩家会买非常专业的鼠标和键盘,争分夺秒。因而,实时游戏中客户端和服务端要建立长连接,来保证实时传输。但是游戏玩家很多,服务器却不多。由于维护 TCP 连接需要在内核维护一些数据结构,因而一台机器能够支撑的 TCP 连接数目是有限的,然后 UDP 由于是没有连接的,在异步 IO 机制引入之前,常常是应对海量客户端连接的策略。另外还是 TCP 的强顺序问题,对战的游戏,对网络的要求很简单,玩家通过客户端发送给服务器鼠标和键盘行走的位置,服务器会处理每个用户发送过来的所有场景,处理完再返回给客户端,客户端解析响应,渲染最新的场景展示给玩家。如果出现一个数据包丢失,所有事情都需要停下来等待这个数据包重发。客户端会出现等待接收数据,然而玩家并不关心过期的数据,激战中卡 1 秒,等能动了都已经死了。游戏对实时要求较为严格的情况下,采用自定义的可靠 UDP 协议,自定义重传策略,能够把丢包产生的延迟降到最低,尽量减少网络问题对游戏性造成的影响。

    IoT 物联网

    物联网领域终端资源少,很可能只是个内存非常小的嵌入式系统,而维护 TCP 协议代价太大;另一方面,物联网对实时性要求也很高,而 TCP 还是因为上面的那些原因导致时延大。Google 旗下的 Nest 建立 Thread Group,推出了物联网通信协议 Thread,就是基于UDP 协议的。

    移动通信领域

     4G 网络里,移动流量上网的数据面对的协议 GTP-U 是基于 UDP 的。因为移动网络协议比较复杂,而 GTP 协议本身就包含复杂的手机上线下线的通信协议。如果基于 TCP,TCP 的机制就显得非常多余。

  • 相关阅读:
    二级指针内存模型(二)
    Winserver-FailoverCluster验证异常
    IIS-This configuration section cannot be used at this path.
    SQL SERVER-Extendevent捕获堵塞
    SQL SERVER-Extendevent
    Powershell-加域脚本
    SQL SERVER-端口Port
    WinServer-SMTP服务
    Linux-开机启动程序
    SQL SERVER-修改服务器名称
  • 原文地址:https://www.cnblogs.com/dslx/p/10811298.html
Copyright © 2011-2022 走看看