多線程優化方案，主線程監聽在一個端口，并使用前面提到方案在服務器將用戶的數據包進行識別和區分。
首先我們服務器端主線程會創建一個UDP的socket，綁定到7000端口，并注冊監聽可讀事件，WebRTC客戶端會給服務端7000端口發數據包。當然在之前SDP和ICE Candidate的協商流程已經做完了，我們從stun的第一個數據包（stun binding request）中就可以拿到這個WebRTC的web address(IP+端口)以及區分會議的RoomID和區分與會者的UserID。
拿到RoomID以后，我們可以把客戶端的web address和RoomID綁定，建立一個映射關系。為什么要做這個綁定關系？
這是為了后續我們可以把同一個會議的用戶全部投遞到一個業務邏輯處理線程來處理。如果用戶的數據是在不同邏輯處理線程上處理，我們在做數據處理的時候就要做跨線程的處理，跨線程處理就一定要加鎖，這是我們不太愿意看到的。
如果同一會議的用戶數據都在一個邏輯線程里面處理，其實它是在一個單線程里面的順序處理，沒有并發的問題，也不需要加鎖，所以它的性能會比較高。
有了剛剛我們建立的映射關系，后續處理同一個會議的用戶上行的stun包、dtls、SRTP、SRTCP，我們都根據RoomID做同樣的Hash算法，Hash到我們后面的業務主線程里面，這樣每一次主線程把I/O做完后，一次性將主線程收到的各個數據包按照Hash算法投遞給對應的后端的邏輯處理多線程，這樣同一個會議的SFU邏輯都在同一個線程里面處理完了。
這個是我們一開始使用的方案，但是大家也能看到，這個方案還有一個缺陷，就是I/O都是在主線程做的，后續的數據都需要通過跨線程的投遞方式讓后續的邏輯處理現場來做，那么有沒有辦法不要做跨線程的投遞，讓用戶的數據包可以直接在對應的邏輯處理多線程里面處理。
其實傳統的TCP服務器是比較容易做到的，它可以在主線程上Accept后為每個客戶端創建一些新的fd，并分配一個子線程處理這個新fd的讀寫。那UDP能不能這么做？UDP在常規的編程方法是無法做到的，針對這個問題，我們設計了一個進階方案。