网络协议五步走天。我们一路走过物理层和链路层，今天终于到了传输层。从这一层开始，服务端开发应该需要很多知识，今天我们就一起来梳理一下。其实说到UDP，就少不了TCP。这两个家伙简直就是“连体兄弟”，只要一个出现，另一个绝对会在不远处等着你。博主相信大部分服务端开发都遇到过类似“TCP和UDP的区别”这样的面试题，而在实际业务开发中，也会比较TCP和UDP来选择合适的协议进行开发。那么，还是老生常谈吧，来看看两兄弟的区别吧。TCP和UDP的区别相信很多人都知道TCP是面向连接的，而UDP是面向无连接的。那么，什么是面向连接，什么是无连接呢？在相互通信之前，面向连接的协议会先建立连接，然后进行通信。就像TCP会进行三次握手，而UDP不会。那为什么会建立连接呢？TCP进行三次握手，而UDP玩玩不能发送三个数据包。有什么不同？其实这里所谓的连接建立就是通过建立一定的数据结构来维持客户端与服务端交互的状态，并利用这样的数据结构来保证所谓的面向连接的特性。在上面这段话中，有一个很重要的词——地位。换句话说，TCP本质上是一种有状态的服务。这个状态可以说是它和UDP的本质区别。通俗地说，statefulTCP是有大脑的。它会记住数据发送是否准确，发送到哪里，应该接收哪些数据。容不得半点差错。与之对应的是UDP无脑无辜，发送出去的数据完全没有考虑网络世界的“恶意”。既然TCP有大脑，它肯定能做很多UDP做不到的事情，比如：提供可靠的传递。通过TCP连接传输的数据没有错误，没有丢失，没有重复，并且按顺序到达。而UDP则不保证不丢失，也不保证按顺序到达。面向字节流。当TCP发送流时，没有头和尾。UDP基于数据报，一个一个发送一个接收；可以进行拥塞控制。当TCP意识到数据包被丢弃或网络环境不好时，它会调整自己的行为，决定是快点发送还是慢点发送。而UDP就是应用要我发，我就发，不管泛滥。.UDP包发送的UDP头到达目标机后，发现MAC地址匹配，所以去掉，然后交给IP层处理，发现IP匹配，接下来做什么？包裹是给谁的？发送时，接收机器如何知道数据包是UDP包呢？所以IP头中有一个8位的协议，无论数据包是TCP还是UDP，都会存放在这里。处理完传输层，内核就基本搞定了，里面的数据要交给应用程序处理。但是，谁应该把它交给一台机器上运行这么多应用程序呢？无论应用程序是使用TCP寻呼机还是UDP来传输数据，它都必须侦听一个端口。官方这个端口是用来区分应用的。这样UDP头中的内容就会显示出来，如下图：当我们看到UDP头时，发现确实有端口号、活动端口号和目的端口号。但它除了端口号之外什么都没有。与TCP头相比，简直就是一团糟。UDP的三大特点前面说过，UDP比较简单，像个孩子，有以下几个特点：通信简单。没有花哨的想法（大量的数据结构、处理逻辑、header字段），秉承“善性论”，相信网络访问容易到达，不易丢弃；相信别人。不建立连接，只识别端口号，任何人都可以向他发送数据，他也可以向任何人发送数据，甚至可以同时向多人发送数据；不会根据网络请求进行拥塞控制，不管网络有多差，它都会按该发送。UDP使用场景就是所谓的“祸福相报”。UDP虽然存在很多问题，但是在特定的场景下也能更好的发挥作用。首先，它需要的资源较少，多用于网络条件较好的内网，或者对丢包不敏感的应用。这个很好理解，就像你是leader，你会要求你那群应届生做一些难度不大，或者失败了还能忍的实验项目。我们之前知道的DHCP是基于UDP协议的。一般获取IP地址都是内网请求，一次获取不到IP也没关系，过段时间再请求获取。二是无需建立连接，一对一通信，需要广播的应用。UDP的非面向连接功能可以承载广播或组播协议。DHCP是一种广播形式。对于组播来说，我们前面提到的IP地址中的D类地址也是组播地址。使用这个地址，数据包可以多播到一批机器。当一台机器上的一个进程想要监听一个多播地址时，它需要发送一个IGMP数据包。网络上的路由器收到这个数据包，就知道有一台机器和一个进程在监听这个多播地址。当路由器收到这个组播地址的数据包时，会转发给本机，从而实现跨路由器的组播。第三，要求处理速度快，延迟低，能容忍少量丢包，但要求即使网络阻塞也不会退缩，继续前进。UDP简单、快速，不需要像TCP那样小心。而且，当TCP在网络不好的时候丢包，它的拥塞策略会主动降低发送速度。许多当前的应用程序需要低延迟。他们不想使用TCP这么复杂的机制，而是想根据自己的场景实现自己的可靠性和连接保证。比如应用程序感觉有些包丢了，丢了不需要重传，而有些重要的包丢了，应用程序会自己重传，不依赖TCP。因为UDP很简单，基本什么都不做，给了应用“城里玩”的机会。就像在和平年代一样，每个人都应该有独立的思想和行为，应该可靠和有礼貌。但在战争时期，往往不需要太过独立思考，而是要求军人??简单地服从命令。基于UDP的“CityPlay”CityPlay的五个例子1：访问网页或app?网页和手机app都是基于HTTP协议的，HTTP协议是基于TCP的。建立连接需要多次交互。对于时延比较长的移动互联网来说，建立连接的时间比较长，而且移动互联网还在动，TCP可能会断开重连，也是非常耗时的。另外，目前的HTTP协议往往采用多个数据通道共享一个连接的情况。这本来是为了加快传输速度，但是TCP严格的顺序策略使得即使共享信道，前一个不来，后一个和前一个连关系都没有，得等，延迟会增加。而QUIC（QuikUDPInternetConnections，快速UDP互联网连接）是Google提出的一种基于UDP的改进通信协议。其目的是降低网络通信的延迟，提供更好的用户交互体验。QUIC在应用层实现快速连接建立，减少重传延迟，自适应拥塞控制。《城市玩转》2：流媒体协议直播协议多采用RTMP，RTMP是基于UDP的。TCP严格的顺序传输必须保证前一个收到后才能确认下一个。对于直播来说，这显然是不合适的，因为旧的视频帧丢失了，即使重新上传用户也无所谓。他们想看新的。代顿，我什至看不到新的。因此，对于直播来说，实时性更为重要。丢失数据包比冻结更好。另外对于丢包，其实对于美食播放来说，有的包可以丢，有的包不能丢，因为在视频的连续帧中，有的包重要，有的包不重要。丢失了几帧。其实看视频的人是不会感知到的，但是如果连续丢帧，用户就会感知到。因此，在网络不好的情况下，应用程序希望有选择地丢帧。另外，当网络不好的时候，TCP会主动降低发送速度。这对于那些已经卡在观看视频中的人来说是致命的。他们应该立即重传，而不是放弃。因此，许多直播应用程序基于UDP实现了自己的视频传输协议。《城市会玩》3：实时游戏?游戏有一个特点，就是具有比较高的实时性。快一秒你杀人，慢一秒你被人爆头，所以很多职业玩家都会买很专业的键鼠，和时间赛跑。因此，在实时游戏中，客户端和服务端需要建立长连接来保证实时传输。但是，游戏玩家多，服务器不多。由于维护一个TCP连接需要在内核中维护一些数据结构，所以一台机器所能支持的TCP连接数是有限的。由于UDP不连接，在引入异步IO机制之前，往往是处理海量客户端连接的策略。另外，还有一个TCP强序列的问题。对战游戏对网络的要求非常简单。播放器通过客户端将鼠标和键盘的行走位置发送给服务器，服务器会处理每个用户发送的所有制造商，然后返回给客户端，客户端解析响应并渲染最新的场景给播放器.如果数据包丢失，一切都需要停止并等待数据包重新发送。客户端会出现等待接收数据的状态，但玩家并不关心过期的数据。相信大家在玩CF的时候，如果在激战中卡住1秒，是不是会有敲击键盘的冲动呢？当游戏对实时性有严格要求时，可以使用自定义的UDP协议和自定义的重传策略，将丢包带来的延迟降到最低，将网络问题对游戏性能的影响降到最低。《城市会玩》4：IoT物联网一方面，物联网领域的终端资源少，很可能是内存很小的嵌入式系统，TCP协议的维护是太贵了。另一方面，物联网对实时性也有很高的要求。Google的Nest成立了ThreadGroup，推出了基于UDP协议的物联网通信协议Thread。《城市玩转》5：在移动通信领域?在4G网络中，移动数据接入的数据协议GTP-U也是基于UDP的。因为手机网络协议比较复杂，而GTP协议本身就包含了手机上下线的复杂通信协议。总结如果把TCP比作一个成熟的社会人，那么UDP就是一个头脑简单的孩子。TCP复杂，UDP简单；TCP维护连接，UDP为大家所信；TCP知进退，UDP愣了愣，一往无前；UDP简单，但可以用在环境简单、组播、应用层控制传输的地方。例如DHCP、QUIC等。参考：百度百科-UDP词条；刘超-浅谈网络协议系列课程；
