告知你不为人知的 UDP：连接性和负载均衡( 二 ) _小知识

这里有个注意点要说明一下，由于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地址和源端口也参与进来了，内核查找算法可以保证：

[1] 固定的四元组的UDP数据包总是查找到同一个UDP Socket；
[2] 不同的四元组的UDP数据包可能会查找到不同的UDP Socket 。

这样对于不同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) 。