為了更好的聊今天的話題，我們先假設一個場景。
我相信我讀者大部分都是做互聯網應用開發的，可能對游戲的架構不太了解。
(資料圖)
我們想象中的游戲架構是下面這樣的。
想象中的游戲架構
也就是用戶客戶端直接連接游戲核心邏輯服務器，下面簡稱GameServer。GameServer主要負責實現各種玩法邏輯。
這當然是能跑起來，實現也很簡單。
但這樣會有個問題，因為游戲這塊蛋糕很大，所以總會遇到很多挺刑的事情。
如果讓用戶直連GameServer，那相當于把GameServer的ip暴露給了所有人。
不賺錢還好，一旦游戲賺錢，就會遇到各種攻擊。
你猜《羊了個羊》最火的時候為啥老是崩潰？
假設一個游戲服務器能承載4k玩家，一旦服務器遭受直接攻擊，那4k玩家都會被影響。
這攻擊的是服務器嗎？這明明攻擊的是老板的錢包。
所以很多時候不會讓用戶直連GameServer。
而是在前面加入一層網關層，下面簡稱gateway。類似這樣。
實際的某些游戲架構
GameServer就躲在了gateway背后，用戶只能得到gateway的IP。
然后將大概每100個用戶放在一個gateway里，這樣如果真被攻擊，就算gateway崩了，受影響的也就那100個玩家。
由于大部分游戲都使用TCP做開發，所以下面提到的連接，如果沒有特別說明，那都是指TCP連接。
那么問題來了。
假設有100個用戶連gateway，那gateway跟GameServer之間也會是100個連接嗎？
當然不會，gateway跟GameServer之間的連接數會遠小于100。
因為這100個用戶不會一直需要收發消息，總有空閑的時候，完全可以讓多個用戶復用同一條連接，將數據打包一起發送給GameServer，這樣單個連接的利用率也高了，GameServer 也不再需要同時維持太多連接，可以節省了不少資源，這樣就可以多服務幾個大怨種金主。
我們知道，要對網絡連接寫數據，就要執行send(socket_fd, data)。
于是問題就來了。
已知多個用戶共用同一條連接。
現在多個用戶要發數據，也就是多個用戶線程需要寫同一個socket_fd。
那么，socket是并發安全的嗎？能讓這多個線程同時并發寫嗎？
并發讀寫socket
寫TCP Socket是線程安全的嗎？對于TCP，我們一般使用下面的方式創建socket。
sockfd=socket(AF_INET,SOCK_STREAM, 0))
返回的sockfd是socket的句柄id，用于在整個操作系統中唯一標識你的socket是哪個，可以理解為socket的身份證id。
創建socket時，操作系統內核會順帶為socket創建一個發送緩沖區和一個接收緩沖區。分別用于在發送和接收數據的時候給暫存一下數據。
寫socket的方式有很多，既可以是send，也可以是write。
但不管哪個，最后在內核里都會走到tcp_sendmsg()函數下。
// net/ipv4/tcp.cint tcp_sendmsg(struct kiocb *iocb, struct sock *sk, struct msghdr *msg, size_t size){ // 加鎖 lock_sock(sk); // ... 拷貝到發送緩沖區的相關操作 // 解鎖 release_sock(sk);}在tcp_sendmsg的目的就是將要發送的數據放入到TCP的發送緩沖區中，此時并沒有所謂的發送數據出去，函數就返回了，內核后續再根據實際情況異步發送。關于這點，我在之前寫過的《動圖圖解 | 代碼執行send成功后，數據就發出去了嗎？》有更詳細的介紹。
tcp_sendmsg 邏輯
從tcp_sendmsg的代碼中可以看到，在對socket的緩沖區執行寫操作的時候，linux內核已經自動幫我們加好了鎖，也就是說，是線程安全的。
所以可以多線程不加鎖并發寫入數據嗎？
不能。
問題的關鍵在于鎖的粒度。
但我們知道TCP有三大特點，面向連接，可靠的，基于字節流的協議。
TCP是什么
問題就出在這個"基于字節流"，它是個源源不斷的二進制數據流，無邊界。來多少就發多少，但是能發多少，得看你的發送緩沖區還剩多少空間。
舉個例子，假設A線程想發123數據包，B線程想發456數據包。
A和B線程同時執行send()，A先搶到鎖，此時發送緩沖區就剩1個數據包的位置，那發了"1"，然后發送緩沖區滿了，A線程退出（非阻塞），當發送緩沖區騰出位置后，此時AB再次同時爭搶，這次被B先搶到了，B發了"4"之后緩沖區又滿了，不得不退出。
重復這樣多次爭搶之后，原本的數據內容都被打亂了，變成了142356。因為數據123是個整體，456又是個整體，像現在這樣數據被打亂的話，接收方就算收到了數據也沒辦法正常解析。
并發寫socket_fd導致數據異常
也就是說鎖的粒度其實是每次"寫操作"，但每次寫操作并不保證能把消息寫完整。
那么問題就來了，那是不是我在寫整個完整消息之前加個鎖，整個消息都寫完之后再解鎖，這樣就好了?
類似下面這樣。
// 偽代碼int safe_send(msg string){ target_len = length(msg) have_send_len = 0 // 加鎖 lock(); // 不斷循環直到發完整個完整消息 do { send_len := send(sockfd,msg) have_send_len = have_send_len + send_len } while(have_send_len < target_len) // 解鎖 unlock();}這也不行，我們知道加鎖這個事情是影響性能的，鎖的粒度越小，性能就越好。反之性能就越差。
當我們搶到了鎖，使用send(sockfd,msg)發送完整數據的時候，如果此時發送緩沖區正好一寫就滿了，那這個線程就得一直占著這個鎖直到整個消息寫完。其他線程都在旁邊等它解鎖，啥事也干不了，焦急難耐想著搶鎖。
但凡某個消息體稍微大點，這樣的問題就會變得更嚴重。整個服務的性能也會被這波神仙操作給拖垮。
歸根結底還是因為鎖的粒度太大了。
有沒有更好的方式呢？
其實多個線程搶鎖，最后搶到鎖的線程才能進行寫操作，從本質上來看，就是將所有用戶發給GameServer邏輯服務器的消息給串行化了，
那既然是串行化，我完全可以在在業務代碼里為每個socket_fd配一個隊列來做，將數據在用戶態加鎖后塞到這個隊列里，再單獨開一個線程，這個線程的工作就是發送消息給socket_fd。
于是上面的場景就變成了下面這樣。
并發寫到加鎖隊列后由一個線程處理
于是在gateway層，多個用戶線程同時寫消息時，會去爭搶某個socket_fd對應的隊列，搶到鎖之后就寫數據到隊列。而真正執行send(sockfd,msg)的線程其實只有一個。它會從這個隊列中取數據，然后不加鎖的批量發送數據到 GameServer。
由于加鎖后要做的事情很簡單，也就塞個隊列而已，因此非常快。并且由于執行發送數據的只有單個線程，因此也不會有消息體亂序的問題。
讀TCP Socket是線程安全的嗎？在前面有了寫socket是線程安全的結論，我們稍微翻一下源碼就能發現，讀socket其實也是加鎖了的，所以并發多線程讀socket這件事是線程安全的。
// net/ipv4/tcp.cint tcp_recvmsg(struct kiocb *iocb, struct sock *sk, struct msghdr *msg, size_t len, int nonblock, int flags, int *addr_len){ // 加鎖 lock_sock(sk); // ... 將數據從接收緩沖區拷貝到用戶緩沖區 // 釋放鎖 release_sock(sk);}但就算是線程安全，也不代表你可以用多個線程并發去讀。
因為這個鎖，只保證你在讀socket 接收緩沖區時，只有一個線程在讀，但并不能保證你每次的時候，都能正好讀到完整消息體后才返回。
所以雖然并發讀不報錯，但每個線程拿到的消息肯定都不全，因為鎖的粒度并不保證能讀完完整消息。
TCP是基于數據流的協議，數據流會源源不斷從網卡那送到接收緩沖區。
如果此時接收緩沖區里有兩條完整消息，比如 "我是小白"和"點贊在看走一波"。
有兩個線程A和B同時并發去讀的話，A線程就可能讀到“我是點贊走一波"， B線程就可能讀到”小白在看"
兩條消息都變得不完整了。
并發讀socket_fd導致的數據異常
解決方案還是跟讀的時候一樣，讀socket的只能有一個線程，讀到了消息之后塞到加鎖隊列中，再將消息分開給到GameServer的多線程用戶邏輯模塊中去做處理。
單線程讀socket_fd后寫入加鎖隊列
讀寫UDP Socket是線程安全的嗎？
聊完TCP，我們很自然就能想到另外一個傳輸層協議UDP，那么它是線程安全的嗎？
我們平時寫代碼的時候如果要使用udp發送消息，一般會像下面這樣操作。
ssize_t sendto(int sockfd, const void *buf, size_t nbytes, int flags, const struct sockaddr *to, socklen_t addrlen);
而執行到底層，會到linux內核的udp_sendmsg函數中。
int udp_sendmsg(struct kiocb *iocb, struct sock *sk, struct msghdr *msg, size_t len) { if (用到了MSG_MORE的功能) { lock_sock(sk); // 加入到發送緩沖區中 release_sock(sk); } else { // 不加鎖，直接發送消息 }}這里我用偽代碼改了下，大概的含義就是用到MSG_MORE就加鎖，否則不加鎖將傳入的msg作為一整個數據包直接發送。
首先需要搞清楚，MSG_MORE是啥。它可以通過上面提到的sendto函數最右邊的flags字段進行設置。大概的意思是告訴內核，待會還有其他更多消息要一起發，先別著急發出去。此時內核就會把這份數據先用發送緩沖區緩存起來，待會應用層說ok了，再一起發。
但是，我們一般也用不到MSG_MORE。
所以我們直接關注另外一個分支，也就是不加鎖直接發消息。
那是不是說明走了不加鎖的分支時，udp發消息并不是線程安全的？
其實。還是線程安全的，不用lock_sock(sk)加鎖，單純是因為沒必要。
開啟MSG_MORE時多個線程會同時寫到同一個socket_fd對應的發送緩沖區中，然后再統一一起發送到IP層，因此需要有個鎖防止出現多個線程將對方寫的數據給覆蓋掉的問題。而不開啟MSG_MORE時，數據則會直接發送給IP層，就沒有了上面的煩惱。
再看下udp的接收函數udp_recvmsg，會發現情況也類似，這里就不再贅述。
能否多線程同時并發讀或寫同一個UDP socket？
在TCP中，線程安全不代表你可以并發地讀寫同一個socket_fd，因為哪怕內核態中加了lock_sock(sk)，這個鎖的粒度并不覆蓋整個完整消息的多次分批發送，它只保證單次發送的線程安全，所以建議只用一個線程去讀寫一個socket_fd。
那么問題又來了，那UDP呢？會有一樣的問題嗎？
我們跟TCP對比下，大家就知道了。
TCP不能用多線程同時讀和同時寫，是因為它是基于數據流的協議。
那UDP呢？它是基于數據報的協議。
UDP是什么
基于數據流和基于數據報有什么區別呢？
基于數據流，意味著發給內核底層的數據就跟水進入水管一樣，內核根本不知道什么時候是個頭，沒有明確的邊界。
而基于數據報，可以類比為一件件快遞進入傳送管道一樣，內核很清楚拿到的是幾件快遞，快遞和快遞之間邊界分明。
水滴和快遞的差異
那從我們使用的方式來看，應用層通過TCP去發數據，TCP就先把它放到緩沖區中，然后就返回。至于什么時候發數據，發多少數據，發的數據是剛剛應用層傳進去的一半還是全部都是不確定的，全看內核的心情。在接收端收的時候也一樣。
但UDP就不同，UDP 對應用層交下來的報文，既不合并，也不拆分，而是保留這些報文的邊界。
無論應用層交給 UDP 多長的報文，UDP 都照樣發送，即一次發送一個報文。至于數據包太長，需要分片，那也是IP層的事情，跟UDP沒啥關系，大不了效率低一些。而接收方在接收數據報的時候，一次取一個完整的包，不存在TCP常見的半包和粘包問題。
正因為基于數據報和基于字節流的差異，TCP 發送端發 10 次字節流數據，接收端可以分 100 次去取數據，每次取數據的長度可以根據處理能力作調整；但 UDP 發送端發了 10 次數據報，那接收端就要在 10 次收完，且發了多少次，就取多少次，確保每次都是一個完整的數據報。
所以從這個角度來說，UDP寫數據報的行為是"原子"的，不存在發一半包或收一半包的問題，要么整個包成功，要么整個包失敗。因此多個線程同時讀寫，也就不會有TCP的問題。
所以，可以多個線程同時讀寫同一個udp socket。
但就算可以，我依然不建議大家這么做。
為什么不建議使用多線程同時讀寫同一個UDP socket
udp本身是不可靠的協議，多線程高并發執行發送時，會對系統造成較大壓力，這時候丟包是常見的事情。雖然這時候應用層能實現重傳邏輯，但重傳這件事畢竟是越少越好。因此通常還會希望能有個應用層流量控制的功能，如果是單線程讀寫的話，就可以在同一個地方對流量實現調控。類似的，實現其他插件功能也會更加方便，比如給某些vip等級的老板更快速的游戲體驗啥的（我瞎說的）。
所以正確的做法，還是跟TCP一樣，不管外面有多少個線程，還是并發加鎖寫到一個隊列里，然后起一個單獨的線程去做發送操作。
udp并發寫加鎖隊列后再寫socket_fd
總結1. 多線程并發讀/寫同一個TCP socket是線程安全的，因為TCP socket的讀/寫操作都上鎖了。雖然線程安全，但依然不建議你這么做，因為TCP本身是基于數據流的協議，一份完整的消息數據可能會分開多次去寫/讀，內核的鎖只保證單次讀/寫socket是線程安全，鎖的粒度并不覆蓋整個完整消息。因此建議用一個線程去讀/寫TCP socket。
2. 多線程并發讀/寫同一個UDP socket也是線程安全的，因為UDP socket的讀/寫操作也都上鎖了。UDP寫數據報的行為是"原子"的，不存在發一半包或收一半包的問題，要么整個包成功，要么整個包失敗。因此多個線程同時讀寫，也就不會有TCP的問題。雖然如此，但還是建議用一個線程去讀/寫UDP socket。
最后上面文章里提到，建議用單線程的方式去讀/寫socket，但每個socket都配一個線程這件事情，顯然有些奢侈，比如線程切換的代價也不小，那這種情況有什么好的解決辦法嗎？
標簽：
