既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上C C++开发知识点，真正体系化！
由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新
实现上，需要考虑这样一个特殊情况：UDP Client 在Endpoint_C1只往UDP Server的Endpoint_S1发送数据包，并且只接收来自Endpoint_S1的数据包，把UDP通信双方都固定下来，这样不就形成一条单向的虚”连接”了么？
1. UDP的”连接性”
估计很多同学认为UDP的连接性只是将UDP通信双方都固定下来了，一对一只是多对多的一个特例而已，这样UDP连接不连接到无所谓了。果真如此吗？其实不然，UDP的连接性可以带来以下两个好处：
1.1 高效率、低消耗
我们知道Linux系统有用户空间(用户态)和内核空间(内核态)之分，对于x86处理器以及大多数其它处理器，用户空间和内核空间之前的切换是比较耗时(涉及到上下文的保存和恢复，一般3种情况下会发生用户态到内核态的切换：发生系统调用时、产生异常时、中断时)。
那么对于一个高性能的服务应该减少频繁不必要的上下文切换，如果切换无法避免，那么尽量减少用户空间和内核空间的数据交换，减少数据拷贝。熟悉socket编程的同学对下面几个系统调用应该比较熟悉了，由于UDP是基于用户数据报的，只要数据包准备好就应该调用一次send或sendto进行发包，当然包的大小完全由应用层逻辑决定的。
细看两个系统调用的参数便知道，sendto比send的参数多2个，这就意味着每次系统调用都要多拷贝一些数据到内核空间。同时，参数到内核空间后，内核还需要初始化一些临时的数据结构来存储这些参数值(主要是对端Endpoint_S的地址信息)，在数据包发出去后，内核还需要在合适的时候释放这些临时的数据结构。进行UDP通信的时候，如果首先调用connect绑定对端Endpoint_S的后，那么就可以直接调用send来给对端Endpoint_S发送UDP数据包了。
用户在connect之后，内核会永久维护一个存储对端Endpoint_S的地址信息的数据结构，内核不再需要分配/删除这些数据结构，只需要查找就可以了，从而减少了数据的拷贝。这样对于connect方而言，该UDP通信在内核已经维护这一个“连接”了，那么在通信的整个过程中，内核都能随时追踪到这个“连接”。
1.2 错误提示
相信大家写UDP Socket程序的时候，有时候在第一次调用sendto给一个unconnected UDP socket发送UDP数据包时，接下来调用recvfrom()或继续调sendto的时候会返回一个ECONNREFUSED错误。对于一个无连接的UDP是不会返回这个错误的，之所以会返回这个错误，是因为你明确调用了connect去连接远端的Endpoint_S了。那么这个错误是怎么产生的呢？没有调用connect的UDP Socket为什么无法返回这个错误呢？
当一个UDP socket去connect一个远端Endpoint_S时，并没有发送任何的数据包，其效果仅仅是在本地建立了一个五元组映射，对应到一个对端，该映射的作用正是为了和UDP带外的ICMP控制通道捆绑在一起，使得UDP socket的接口含义更加丰满。这样内核协议栈就维护了一个从源到目的地的单向连接，当下层有ICMP(对于非IP协议，可以是其它机制)错误信息返回时，内核协议栈就能够准确知道该错误是由哪个用户socket产生的，这样就能准确将错误转发给上层应用了。
对于下层是IP协议的时候，ICMP错误信息返回时，ICMP的包内容就是出错的那个原始数据包，根据这个原始数据包可以找出一个五元组，根据该五元组就可以对应到一个本地的connect过的UDP socket，进而把错误消息传输给该socket，应用程序在调用socket接口函数的时候，就可以得到该错误消息了。
对于一个无“连接”的UDP，sendto系统调用后，内核在将数据包发送出去后，就释放了存储对端Endpoint_S的地址等信息的数据结构了，这样在下层的协议有错误返回的时候，内核已经无法追踪到源socket了。
这里有个注意点要说明一下，由于UDP和下层协议都是不可靠的协议，所以，不能总是指望能够收到远端回复的ICMP包。例如：中间的一个节点或本机禁掉了ICMP，socket api调用就无法捕获这些错误了。
2. UDP的负载均衡
在多核(多CPU)的服务器中，为了充分利用机器CPU资源，TCP服务器大多采用accept/fork模式，TCP服务的MPM机制(multi processing module)，不管是预先建立进程池，还是每到一个连接创建新线程/进程，总体都是源于accept/fork的变体。
然而对于UDP却无法很好的采用PMP机制，由于UDP的无连接性、无序性，它没有通信对端的信息，不知道一个数据包的前置和后续，它没有很好的办法知道，还有没后续的数据包以及如果有的话，过多久才会来，会来多久，因此UDP无法为其预先分配资源。
2.1 端口重用SO_REUSEADDR、SO_REUSEPORT
要进行多处理，就免不了要在相同的地址端口上处理数据，SO_REUSEADDR允许端口的重用，只要确保四元组的唯一性即可。对于TCP，在bind的时候所有可能产生四元组不唯一的bind都会被禁止(于是，ip相同的情况下，TCP套接字处于TIME_WAIT状态下的socket，才可以重复绑定使用)；对于connect，由于通信两端中的本端已经明确了，那么只允许connect从来没connect过的对端(在明确不会破坏四元组唯一性的connect才允许发送SYN包)；对于监听listen端，四元组的唯一性油connect端保证就OK了。
TCP通过连接来保证四元组的唯一性，一个connect请求过来，accept进程accept完这个请求后(当然不一定要单独accept进程)，就可以分配socket资源来标识这个连接，接着就可以分发给相应的worker进程去处理该连接后续的事情了。这样就可以在多核服务器中，同时有多个worker进程来同时处理多个并发请求，从而达到负载均衡，CPU资源能够被充分利用。
UDP的无连接状态(没有已有对端的信息)，使得UDP没有一个有效的办法来判断四元组是否冲突，于是对于新来的请求，UDP无法进行资源的预分配，于是多处理模式难以进行，最终只能“守株待兔“，UDP按照固定的算法查找目标UDP socket，这样每次查到的都是UDP socket列表固定位置的socket。UDP只是简单基于目的IP和目的端口来进行查找，这样在一个服务器上多个进程内创建多个绑定相同IP地址(SO_REUSEADDR)，相同端口的UDP socket，那么你会发现，只有最后一个创建的socket会接收到数据，其它的都是默默地等待，孤独地等待永远也收不到UDP数据。
UDP这种只能单进程、单处理的方式将要破灭UDP高效的神话，你在一个多核的服务器上运行这样的UDP程序，会发现只有一个核在忙，其他CPU核心处于空闲的状态。创建多个绑定相同IP地址，相同端口的UDP程序，只会起到容灾备份的作用，不会起到负载均衡的作用。
要实现多处理，那么就要改变UDP Socket查找的考虑因素，对于调用了connect的UDP Client而言，由于其具有了“连接”性，通信双方都固定下来了，那么内核就可以根据4元组完全匹配的原则来匹配。于是对于不同的通信对端，可以查找到不同的UDP Socket从而实现多处理。而对于server端，在使用SO_REUSEPORT选项(linux 3.9以上内核)，这样在进行UDP socket查找的时候，源IP地址和源端口也参与进来了，内核查找算法可以保证：
（需要补图）
这样对于不同client发来的数据包就能查找到不同的UDP socket从而实现多处理。这样看来，似乎采用SO_REUSEADDR、SO_REUSEPORT这两个socket选项并利用内核的socket查找算法，我们在多核CPU服务器上多个进程内创建多个绑定相同端口，相同IP地址的UDP socket就能做到负载均衡充分利用多核CPU资源了。然而事情远没这么顺利、简单。
2.2 UDP Socket列表变化问题
通过上面我们知道，在采用SO_REUSEADDR、SO_REUSEPORT这两个socket选项后，内核会根据UDP数据包的4元组来查找本机上的所有相同目的IP地址，相同目的端口的socket中的一个socket的位置，然后以这个位置上的socket作为接收数据的socket。那么要确保来至同一个Client Endpoint的UDP数据包总是被同一个socket来处理，就需要保证整个socket链表的socket所处的位置不能改变。
然而，如果socket链表中间的某个socket挂了的话，就会造成socket链表重新排序，这样会引发问题。于是基本的解决方案是在整个服务过程中不能关闭UDP socket(当然也可以全部UDP socket都close掉，从新创建一批新的)。要保证这一点，我们需要所有的UDP socket的创建和关闭都由一个master进行来管理，worker进程只是负责处理对于的网络IO任务，为此我们需要socket在创建的时候要带有CLOEXEC标志(SOCK_CLOEXEC)。
2.3 UDP和Epoll结合 – UDP的Accept模型
到此，为了充分利用多核CPU资源，进行UDP的多处理，我们会预先创建多个进程，每个进程都创建一个或多个绑定相同端口，相同IP地址(SO_REUSEADDR、SO_REUSEPORT)的UDP socket，这样利用内核的UDP socket查找算法来达到UDP的多进程负载均衡。然而，这完全依赖于Linux内核处理UDP socket查找时的一个算法，我们不能保证其它的系统或者未来的Linux内核不会改变算法的行为；同时，算法的查找能否做到比较好的均匀分布到不同的UDP socket，(每个处理进程只处理自己初始化时候创建的那些UDP socket)负载是否均衡是个问题。于是，我们多么想给UPD建立一个accept模型，按需分配UDP socket来处理。
在高性能Server编程中，对于TCP Server而已有比较成熟的解决方案，TCP天然的连接性可以充分利用epoll等高性能event机制，采用多路复用、异步处理的方式，哪个worker进程空闲就去accept连接请求来处理，这样就可以达到比较高的并发，可以极限利用CPU资源。
然而对于UDP server而言，由于整个Svr就一个UDP socket，接收并响应所有的client请求，于是也就不存在什么多路复用的问题了。UDP svr无法充分利用epoll的高性能event机制的主要原因是，UDP svr只有一个UDP socket来接收和响应所有client的请求。然而如果能够为每个client都创建一个socket并虚拟一个“连接”与之对应，这样不就可以充分利用内核UDP层的socket查找结果和epoll的通知机制了么。server端具体过程如下：
通过上面的步骤，这样UDP svr就能充分利用epoll的事件通知机制了。第一次收到一个新的client的UDP数据包，就创建一个新的UDP socket和这个client对应，这样接下来的数据交互和事件通知都能准确投递到这个新的UDP socket fd了。
这里的UPD和Epoll结合方案，有以下几个注意点：
（需要补图）
上面的UDP和Epoll结合的accept模型有个不好处理的小尾巴(也就是上面的注意点[2])，这个小尾巴的存在其本质是UDP和4元组没有必然的对应关系，也就是UDP的无连接性。
2.4 UDP Fork 模型 – UDP accept模型之按需建立UDP处理进程
为了充分利用多核CPU(为简化讨论，不妨假设为8核)，理想情况下，同时有8个工作进程在同时工作处理请求。于是我们会初始化8个绑定相同端口，相同IP地址(SO_REUSEADDR、SO_REUSEPORT)的UDP socket，接下来就靠内核的查找算法来达到client请求的负载均衡了。
由于内核查找算法是固定的，于是，无形中所有的client被划分为8类，类型1的所有client请求全部被路由到工作进程1的UDP socket由工作进程1来处理，同样类型2的client的请求也全部被工作进程2来处理。这样的缺陷是明显的，比较容易造成短时间的负载极端不均衡。
一般情况下，如果一个UDP包能够标识一个请求，那么简单的解决方案是每个UDP socket n的工作进程n，自行fork出多个子进程来处理类型n的client的请求。这样每个子进程都直接recvfrom就OK了，拿到UDP请求包就处理，拿不到就阻塞。
然而，如果一个请求需要多个UDP包来标识的情况下，事情就没那么简单了，我们需要将同一个client的所有UDP包都路由到同一个工作子进程。为了简化讨论，我们将注意力集中在都是类型n的多个client请求UDP数据包到来的时候，我们怎么处理的问题，不同类型client的数据包路由问题交给内核了。
这样，我们需要一个master进程来监听UDP socket的可读事件，master进程监听到可读事件，就采用MSG_PEEK选项来recvfrom数据包，如果发现是新的Endpoit(ip、port)Client的UDP包，那么就fork一个新的进行来处理该Endpoit的请求。具体如下：
该fork模型很别扭，过多的探测行为，一个数据包来了，会”惊群”唤醒所有worker子进程，大家都去PEEK一把，最后只有一个worker进程能够取出UDP包来处理。同时到来的数据包只能排队被取出。更为严重的是，由于recvfrom的排他唤醒，可能会造成死锁。考虑下面一个场景：
假设有worker1、worker2、worker3、和master共四个进程都阻塞在poll调用上，client1的一个新的UDP包过来，这个时候，四个进程会被同时唤醒，worker1比较神速，赶在其他进程前将UPD包取走了(worker1可以处理client1的UDP包)，于是其他三个进程的recvfrom扑空，它们worker2、worker3、和master按序全部阻塞在recvfrom上睡眠(worker2、worker3排在master前面先睡眠的)。
这个时候，一个新client4的UDP包packet4到来，(由于recvfrom的排他唤醒)这个时候只有worker2会从recvfrom的睡眠中醒来，然而worker而却不能处理该请求UDP包。如果没有新UDP包到来，那么packet4一直留在内核中，死锁了。之所以recv是排他的，是为了避免“承诺给一个进程”的数据被其他进程取走了。
通过上面的讨论，不管采用什么手段，UDP的accept模型总是那么别扭，总有一些无法自然处理的小尾巴。UDP的多路负载均衡方案不通用，不自然，其本因在于UPD的无连接性、无序性(无法标识数据的前续后继)。我们不知道client还在不在，于是难于决策虚拟的”连接”何时终止，以及何时结束掉fork出来的worker子进程(我们不能无限fork吧)。于是，在没有好的决策因素的时候，超时似乎是一个比较好选择，毕竟当所有的裁决手段都失效的时候，一切都要靠时间来冲淡。
3. UDP疑难杂症
3.1 UDP的传输方式：面向报文
面向报文的传输方式决定了UDP的数据发送方式是一份一份的，也就是应用层交给UDP多长的报文，UDP就照样发送，即一次发送一个报文。那么UDP的报文大小由哪些影响因素呢？UDP数据包的理论长度是多少，合适的UDP数据包应该是多少呢？
(1)UDP报文大小的影响因素，主要有以下3个
[1] UDP协议本身，UDP协议中有16位的UDP报文长度，那么UDP报文长度不能超过2^16=65536.
[2] 以太网(Ethernet)数据帧的长度，数据链路层的MTU(最大传输单元)。
[3] socket的UDP发送缓存区大小
(2) UDP数据包最大长度
根据UDP协议，从UDP数据包的包头可以看出，UDP的最大包长度是216-1的个字节。由于UDP包头占8个字节，而在IP层进行封装后的IP包头占去20字节，所以这个是UDP数据包的最大理论长度是216 – 1 – 8 – 20 = 65507字节。如果发送的数据包超过65507字节，send或sendto函数会错误码1(Operation not permitted， Message too long)。
当然啦，一个数据包能否发送65507字节，还和UDP发送缓冲区大小（linux下UDP发送缓冲区大小为：cat /proc/sys/net/core/wmem_default）相关，如果发送缓冲区小于65507字节，在发送一个数据包为65507字节的时候，send或sendto函数会错误码1(Operation not permitted， No buffer space available)。
(3) UDP数据包理想长度
理论上UDP报文最大长度是65507字节，实际上发送这么大的数据包效果最好吗？我们知道UDP是不可靠的传输协议，为了减少UDP包丢失的风险，我们最好能控制UDP包在下层协议的传输过程中不要被切割。相信大家都知道MTU这个概念。MTU最大传输单元，这个最大传输单元实际上和链路层协议有着密切的关系，EthernetII帧的结构DMAC+SMAC+Type+Data+CRC由于以太网传输电气方面的限制，每个以太网帧都有最小的大小64字节，最大不能超过1518字节，对于小于或者大于这个限制的以太网帧我们都可以视之为错误的数据帧，一般的以太网转发设备会丢弃这些数据帧。
由于以太网EthernetII最大的数据帧是1518字节，除去以太网帧的帧头（DMAC目的MAC地址48bit=6Bytes+SMAC源MAC地址48bit=6Bytes+Type域2bytes）14Bytes和帧尾CRC校验部分4Bytes那么剩下承载上层协议的地方也就是Data域最大就只能有1500字节这个值我们就把它称之为MTU。
在下层数据链路层最大传输单元是1500字节的情况下，要想IP层不分包，那么UDP数据包的最大大小应该是1500字节 – IP头(20字节) – UDP头(8字节) = 1472字节。不过鉴于Internet上的标准MTU值为576字节，所以建议在进行Internet的UDP编程时，最好将UDP的数据长度控制在 (576-8-20)548字节以内。
3.2 UDP数据包的发送和接收问题
(1) UDP的通信有界性
在阻塞模式下，UDP的通信是以数据包作为界限的，即使server端的缓冲区再大也要按照client发包的次数来多次接收数据包，server只能一次一次的接收，client发送多少次，server就需接收多少次，即客户端分几次发送过来，服务端就必须按几次接收。
(2) UDP数据包的无序性和非可靠性
client依次发送1、2、3三个UDP数据包，server端先后调用3次接收函数，可能会依次收到3、2、1次序的数据包，收包可能是1、2、3的任意排列组合，也可能丢失一个或多个数据包。
(3) UDP数据包的接收
client发送两次UDP数据，第一次 500字节，第二次300字节，server端阻塞模式下接包，第一次recvfrom( 1000 )，收到是 1000，还是500，还是300，还是其他？
在假定数据包是不丢失并且是按照发送顺序按序到达的情况下，server端阻塞模式下接包，先后三次调用：recvfrom( 200)，recvfrom( 1000)，recvfrom( 1000)，接收情况如何呢？
既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上C C++开发知识点，真正体系化！
由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新
合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上C C++开发知识点，真正体系化！**
由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新
218
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
