我們利用Linux reuseaddr和connect以后的udp fd特性，只有第一個數據包經主線程收包后投遞到邏輯處理線程，其它數據包直接在邏輯線程接收。
我們具體是怎么做的？
首先主線程還是創建一個fd，綁定7000端口。當然這里面有一個關鍵點是需要設置套接字的選項——reuseaddr，這個套接字選項在TCP領域用的很多，在UDP領域中大家可能還比較少接觸。同樣在主線監聽可讀事件。主線程開始收包了，同樣的流程，收到到第一個stun包，獲取WebRTC的web address(IP+端口)以及區分會議的RoomID和區分與會者的UserID。使用Hash(RoomID)到一個邏輯處理的子線程，到此為止流程與之前的多線程方案沒有太大區別。
在邏輯處理子線程里面的方案就有一定的技巧了。它首先會在這個子線程里面再創建一個fd，這個fd監聽的端口和主線程是一樣的，也是7000端口。因為它設置了reuseaddr，所以說它的綁定可以成功，也就是說這個7000端口可以在多個線程里面同時監聽。
接下來的流程就比較重要了，我們有了這個fd之后，我們需要做一次connect， connect在UDP領域大家使用得不多，但是它connect之后有什么效果呢？
大家可以閱讀《UNIX網絡編程 卷1第3版》的8.11，簡單概括：UDP fd connect之后，會綁定本端與對端的四元組。當內核選擇fd來收udp包時采用的是最佳匹配的原則。
因此connect過后的fd是四元組匹配最高的，這時內核會直接選擇我們在子線程里面創建的fd。這個方案有點繞，但是還是比較有意思的，涉及到一些內核的事情，推薦大家感興趣可以深入研究一下。在邏輯處理子線程中，我們還是會把這個新創建的fd注冊到我們的事件循環里面。此后這個用戶的上下行數據的IO操作將直接在這個邏輯處理線程。
這個方案就是我們優化后的Server的線程方案，它可以最大程度的降低跨線程的調用與加鎖，整體的性能和代碼的可讀性也都會變高。