為了更好的聊今天的話題，我們先假設(shè)一個場景。

我相信我讀者大部分都是做互聯(lián)網(wǎng)應(yīng)用開發(fā)的，可能對游戲的架構(gòu)不太了解。

我們想象中的游戲架構(gòu)是下面這樣的。

想象中的游戲架構(gòu)

也就是用戶客戶端直接連接游戲核心邏輯服務(wù)器，下面簡稱GameServer。GameServer主要負(fù)責(zé)實(shí)現(xiàn)各種玩法邏輯。

這當(dāng)然是能跑起來，實(shí)現(xiàn)也很簡單。

但這樣會有個問題，因?yàn)橛螒蜻@塊蛋糕很大，所以總會遇到很多挺刑的事情。

如果讓用戶直連GameServer，那相當(dāng)于把GameServer的ip暴露給了所有人。

不賺錢還好，一旦游戲賺錢，就會遇到各種攻擊。

你猜《羊了個羊》最火的時候?yàn)樯独鲜潜罎ⅲ?/p>

假設(shè)一個游戲服務(wù)器能承載4k玩家，一旦服務(wù)器遭受直接攻擊，那4k玩家都會被影響。

這攻擊的是服務(wù)器嗎？這明明攻擊的是老板的錢包。

所以很多時候不會讓用戶直連GameServer。

而是在前面加入一層網(wǎng)關(guān)層，下面簡稱gateway。類似這樣。

實(shí)際的某些游戲架構(gòu)

GameServer就躲在了gateway背后，用戶只能得到gateway的IP。

然后將大概每100個用戶放在一個gateway里，這樣如果真被攻擊，就算gateway崩了，受影響的也就那100個玩家。

由于大部分游戲都使用TCP做開發(fā)，所以下面提到的連接，如果沒有特別說明，那都是指TCP連接。

那么問題來了。

假設(shè)有100個用戶連gateway，那gateway跟GameServer之間也會是 100個連接嗎？

當(dāng)然不會，gateway跟GameServer之間的連接數(shù)會遠(yuǎn)小于100。

因?yàn)檫@100個用戶不會一直需要收發(fā)消息，總有空閑的時候，完全可以讓多個用戶復(fù)用同一條連接，將數(shù)據(jù)打包一起發(fā)送給GameServer，這樣單個連接的利用率也高了，GameServer 也不再需要同時維持太多連接，可以節(jié)省了不少資源，這樣就可以多服務(wù)幾個大怨種金主。

我們知道，要對網(wǎng)絡(luò)連接寫數(shù)據(jù)，就要執(zhí)行 send(socket_fd, data)。

于是問題就來了。

已知多個用戶共用同一條連接。

現(xiàn)在多個用戶要發(fā)數(shù)據(jù)，也就是多個用戶線程需要寫同一個socket_fd。

那么，socket是并發(fā)安全的嗎？能讓這多個線程同時并發(fā)寫嗎？

并發(fā)讀寫socket

寫TCP Socket是線程安全的嗎？

對于TCP，我們一般使用下面的方式創(chuàng)建socket。

sockfd=socket(AF_INET,SOCK_STREAM, 0))

返回的sockfd是socket的句柄id，用于在整個操作系統(tǒng)中唯一標(biāo)識你的socket是哪個，可以理解為socket的身份證id。

創(chuàng)建socket時，操作系統(tǒng)內(nèi)核會順帶為socket創(chuàng)建一個發(fā)送緩沖區(qū)和一個接收緩沖區(qū)。分別用于在發(fā)送和接收數(shù)據(jù)的時候給暫存一下數(shù)據(jù)。

寫socket的方式有很多，既可以是send，也可以是write。

但不管哪個，最后在內(nèi)核里都會走到 tcp_sendmsg() 函數(shù)下。

// net/ipv4/tcp.c
int tcp_sendmsg(struct kiocb *iocb, struct sock *sk, struct msghdr *msg, size_t size)
{
    // 加鎖
    lock_sock(sk);


    // ... 拷貝到發(fā)送緩沖區(qū)的相關(guān)操作


    // 解鎖
    release_sock(sk);
}

在tcp_sendmsg的目的就是將要發(fā)送的數(shù)據(jù)放入到TCP的發(fā)送緩沖區(qū)中，此時并沒有所謂的發(fā)送數(shù)據(jù)出去，函數(shù)就返回了，內(nèi)核后續(xù)再根據(jù)實(shí)際情況異步發(fā)送。關(guān)于這點(diǎn)，我在之前寫過的 《動圖圖解 | 代碼執(zhí)行send成功后，數(shù)據(jù)就發(fā)出去了嗎？》有更詳細(xì)的介紹。

tcp_sendmsg 邏輯

從tcp_sendmsg的代碼中可以看到，在對socket的緩沖區(qū)執(zhí)行寫操作的時候，linux內(nèi)核已經(jīng)自動幫我們加好了鎖，也就是說，是線程安全的。

所以可以多線程不加鎖并發(fā)寫入數(shù)據(jù)嗎？

不能。

問題的關(guān)鍵在于鎖的粒度。

但我們知道TCP有三大特點(diǎn)，面向連接，可靠的，基于字節(jié)流的協(xié)議。

TCP是什么

問題就出在這個"基于字節(jié)流"，它是個源源不斷的二進(jìn)制數(shù)據(jù)流，無邊界。來多少就發(fā)多少，但是能發(fā)多少，得看你的發(fā)送緩沖區(qū)還剩多少空間。

舉個例子，假設(shè)A線程想發(fā)123數(shù)據(jù)包，B線程想發(fā)456數(shù)據(jù)包。

A和B線程同時執(zhí)行send()，A先搶到鎖，此時發(fā)送緩沖區(qū)就剩1個數(shù)據(jù)包的位置，那發(fā)了"1"，然后發(fā)送緩沖區(qū)滿了，A線程退出（非阻塞），當(dāng)發(fā)送緩沖區(qū)騰出位置后，此時AB再次同時爭搶，這次被B先搶到了，B發(fā)了"4"之后緩沖區(qū)又滿了，不得不退出。

重復(fù)這樣多次爭搶之后，原本的數(shù)據(jù)內(nèi)容都被打亂了，變成了142356。因?yàn)閿?shù)據(jù)123是個整體，456又是個整體，像現(xiàn)在這樣數(shù)據(jù)被打亂的話，接收方就算收到了數(shù)據(jù)也沒辦法正常解析。

并發(fā)寫socket_fd導(dǎo)致數(shù)據(jù)異常

也就是說鎖的粒度其實(shí)是每次"寫操作"，但每次寫操作并不保證能把消息寫完整。

那么問題就來了，那是不是我在寫整個完整消息之前加個鎖，整個消息都寫完之后再解鎖，這樣就好了?

類似下面這樣。

// 偽代碼
int safe_send(msg string)
{
    target_len = length(msg)
        have_send_len = 0
    // 加鎖
    lock();

    // 不斷循環(huán)直到發(fā)完整個完整消息
       do {
     send_len := send(sockfd,msg)
     have_send_len = have_send_len + send_len
       } while(have_send_len < target_len)
   

    // 解鎖
    unlock();

}

這也不行，我們知道加鎖這個事情是影響性能的，鎖的粒度越小，性能就越好。反之性能就越差。

當(dāng)我們搶到了鎖，使用 send(sockfd,msg) 發(fā)送完整數(shù)據(jù)的時候，如果此時發(fā)送緩沖區(qū)正好一寫就滿了，那這個線程就得一直占著這個鎖直到整個消息寫完。其他線程都在旁邊等它解鎖，啥事也干不了，焦急難耐想著搶鎖。

但凡某個消息體稍微大點(diǎn)，這樣的問題就會變得更嚴(yán)重。整個服務(wù)的性能也會被這波神仙操作給拖垮。

歸根結(jié)底還是因?yàn)殒i的粒度太大了。

有沒有更好的方式呢？

其實(shí)多個線程搶鎖，最后搶到鎖的線程才能進(jìn)行寫操作，從本質(zhì)上來看，就是將所有用戶發(fā)給GameServer邏輯服務(wù)器的消息給串行化了，

那既然是串行化，我完全可以在在業(yè)務(wù)代碼里為每個socket_fd配一個隊(duì)列來做，將數(shù)據(jù)在用戶態(tài)加鎖后塞到這個隊(duì)列里，再單獨(dú)開一個線程，這個線程的工作就是發(fā)送消息給socket_fd。

于是上面的場景就變成了下面這樣。

并發(fā)寫到加鎖隊(duì)列后由一個線程處理

于是在gateway層，多個用戶線程同時寫消息時，會去爭搶某個socket_fd對應(yīng)的隊(duì)列，搶到鎖之后就寫數(shù)據(jù)到隊(duì)列。而真正執(zhí)行 send(sockfd,msg) 的線程其實(shí)只有一個。它會從這個隊(duì)列中取數(shù)據(jù)，然后不加鎖的批量發(fā)送數(shù)據(jù)到 GameServer。

由于加鎖后要做的事情很簡單，也就塞個隊(duì)列而已，因此非?？?。并且由于執(zhí)行發(fā)送數(shù)據(jù)的只有單個線程，因此也不會有消息體亂序的問題。

讀TCP Socket是線程安全的嗎？

在前面有了寫socket是線程安全的結(jié)論，我們稍微翻一下源碼就能發(fā)現(xiàn)，讀socket其實(shí)也是加鎖了的，所以并發(fā)多線程讀socket這件事是線程安全的。

// net/ipv4/tcp.c
int tcp_recvmsg(struct kiocb *iocb, struct sock *sk, struct msghdr *msg,
        size_t len, int nonblock, int flags, int *addr_len)
{

    // 加鎖
    lock_sock(sk);

    // ... 將數(shù)據(jù)從接收緩沖區(qū)拷貝到用戶緩沖區(qū)

    // 釋放鎖
    release_sock(sk);

}

但就算是線程安全，也不代表你可以用多個線程并發(fā)去讀。

因?yàn)檫@個鎖，只保證你在讀socket 接收緩沖區(qū)時，只有一個線程在讀，但并不能保證你每次的時候，都能正好讀到完整消息體后才返回。

所以雖然并發(fā)讀不報錯，但每個線程拿到的消息肯定都不全，因?yàn)殒i的粒度并不保證能讀完完整消息。

TCP是基于數(shù)據(jù)流的協(xié)議，數(shù)據(jù)流會源源不斷從網(wǎng)卡那送到接收緩沖區(qū)。

如果此時接收緩沖區(qū)里有兩條完整消息，比如 "我是小白"和"點(diǎn)贊在看走一波"。

有兩個線程A和B同時并發(fā)去讀的話，A線程就可能讀到“我是 點(diǎn)贊走一波"， B線程就可能讀到”小白 在看"

兩條消息都變得不完整了。

并發(fā)讀socket_fd導(dǎo)致的數(shù)據(jù)異常

解決方案還是跟讀的時候一樣，讀socket的只能有一個線程，讀到了消息之后塞到加鎖隊(duì)列中，再將消息分開給到GameServer的多線程用戶邏輯模塊中去做處理。

單線程讀socket_fd后寫入加鎖隊(duì)列

讀寫UDP Socket是線程安全的嗎？

聊完TCP，我們很自然就能想到另外一個傳輸層協(xié)議UDP，那么它是線程安全的嗎？

我們平時寫代碼的時候如果要使用udp發(fā)送消息，一般會像下面這樣操作。

ssize_t sendto(int sockfd, const void *buf, size_t nbytes, int flags, const struct sockaddr *to, socklen_t addrlen);

而執(zhí)行到底層，會到linux內(nèi)核的udp_sendmsg函數(shù)中。

int udp_sendmsg(struct kiocb *iocb, struct sock *sk, struct msghdr *msg, size_t len) {
   if (用到了MSG_MORE的功能) {
        lock_sock(sk);
    // 加入到發(fā)送緩沖區(qū)中
    release_sock(sk);
   } else {
        // 不加鎖，直接發(fā)送消息
   }
}

這里我用偽代碼改了下，大概的含義就是用到MSG_MORE就加鎖，否則不加鎖將傳入的msg作為一整個數(shù)據(jù)包直接發(fā)送。

首先需要搞清楚，MSG_MORE 是啥。它可以通過上面提到的sendto函數(shù)最右邊的flags字段進(jìn)行設(shè)置。大概的意思是告訴內(nèi)核，待會還有其他更多消息要一起發(fā)，先別著急發(fā)出去。此時內(nèi)核就會把這份數(shù)據(jù)先用發(fā)送緩沖區(qū)緩存起來，待會應(yīng)用層說ok了，再一起發(fā)。

但是，我們一般也用不到 MSG_MORE。

所以我們直接關(guān)注另外一個分支，也就是不加鎖直接發(fā)消息。

那是不是說明走了不加鎖的分支時，udp發(fā)消息并不是線程安全的？

其實(shí)。還是線程安全的，不用lock_sock(sk)加鎖，單純是因?yàn)闆]必要。

開啟MSG_MORE時多個線程會同時寫到同一個socket_fd對應(yīng)的發(fā)送緩沖區(qū)中，然后再統(tǒng)一一起發(fā)送到IP層，因此需要有個鎖防止出現(xiàn)多個線程將對方寫的數(shù)據(jù)給覆蓋掉的問題。而不開啟MSG_MORE時，數(shù)據(jù)則會直接發(fā)送給IP層，就沒有了上面的煩惱。

再看下udp的接收函數(shù)udp_recvmsg，會發(fā)現(xiàn)情況也類似，這里就不再贅述。

能否多線程同時并發(fā)讀或?qū)懲粋€UDP socket？

在TCP中，線程安全不代表你可以并發(fā)地讀寫同一個socket_fd，因?yàn)槟呐聝?nèi)核態(tài)中加了lock_sock(sk)，這個鎖的粒度并不覆蓋整個完整消息的多次分批發(fā)送，它只保證單次發(fā)送的線程安全，所以建議只用一個線程去讀寫一個socket_fd。

那么問題又來了，那UDP呢？會有一樣的問題嗎？

我們跟TCP對比下，大家就知道了。

TCP不能用多線程同時讀和同時寫，是因?yàn)樗腔跀?shù)據(jù)流的協(xié)議。

那UDP呢？它是基于數(shù)據(jù)報的協(xié)議。

UDP是什么

基于數(shù)據(jù)流和基于數(shù)據(jù)報有什么區(qū)別呢？

基于數(shù)據(jù)流，意味著發(fā)給內(nèi)核底層的數(shù)據(jù)就跟水進(jìn)入水管一樣，內(nèi)核根本不知道什么時候是個頭，沒有明確的邊界。

而基于數(shù)據(jù)報，可以類比為一件件快遞進(jìn)入傳送管道一樣，內(nèi)核很清楚拿到的是幾件快遞，快遞和快遞之間邊界分明。

水滴和快遞的差異

那從我們使用的方式來看，應(yīng)用層通過TCP去發(fā)數(shù)據(jù)，TCP就先把它放到緩沖區(qū)中，然后就返回。至于什么時候發(fā)數(shù)據(jù)，發(fā)多少數(shù)據(jù)，發(fā)的數(shù)據(jù)是剛剛應(yīng)用層傳進(jìn)去的一半還是全部都是不確定的，全看內(nèi)核的心情。在接收端收的時候也一樣。

但UDP就不同，UDP 對應(yīng)用層交下來的報文，既不合并，也不拆分，而是保留這些報文的邊界。

無論應(yīng)用層交給 UDP 多長的報文，UDP 都照樣發(fā)送，即一次發(fā)送一個報文。至于數(shù)據(jù)包太長，需要分片，那也是IP層的事情，跟UDP沒啥關(guān)系，大不了效率低一些。而接收方在接收數(shù)據(jù)報的時候，一次取一個完整的包，不存在TCP常見的半包和粘包問題。

正因?yàn)榛跀?shù)據(jù)報和基于字節(jié)流的差異，TCP 發(fā)送端發(fā) 10 次字節(jié)流數(shù)據(jù)，接收端可以分 100 次去取數(shù)據(jù)，每次取數(shù)據(jù)的長度可以根據(jù)處理能力作調(diào)整；但 UDP 發(fā)送端發(fā)了 10 次數(shù)據(jù)報，那接收端就要在 10 次收完，且發(fā)了多少次，就取多少次，確保每次都是一個完整的數(shù)據(jù)報。

所以從這個角度來說，UDP寫數(shù)據(jù)報的行為是"原子"的，不存在發(fā)一半包或收一半包的問題，要么整個包成功，要么整個包失敗。因此多個線程同時讀寫，也就不會有TCP的問題。

所以，可以多個線程同時讀寫同一個udp socket。

但就算可以，我依然不建議大家這么做。

為什么不建議使用多線程同時讀寫同一個UDP socket

udp本身是不可靠的協(xié)議，多線程高并發(fā)執(zhí)行發(fā)送時，會對系統(tǒng)造成較大壓力，這時候丟包是常見的事情。雖然這時候應(yīng)用層能實(shí)現(xiàn)重傳邏輯，但重傳這件事畢竟是越少越好。因此通常還會希望能有個應(yīng)用層流量控制的功能，如果是單線程讀寫的話，就可以在同一個地方對流量實(shí)現(xiàn)調(diào)控。類似的，實(shí)現(xiàn)其他插件功能也會更加方便，比如給某些vip等級的老板更快速的游戲體驗(yàn)啥的（我瞎說的）。

所以正確的做法，還是跟TCP一樣，不管外面有多少個線程，還是并發(fā)加鎖寫到一個隊(duì)列里，然后起一個單獨(dú)的線程去做發(fā)送操作。

udp并發(fā)寫加鎖隊(duì)列后再寫socket_fd

總結(jié)

1. 多線程并發(fā)讀/寫同一個TCP socket是線程安全的，因?yàn)門CP socket的讀/寫操作都上鎖了。雖然線程安全，但依然不建議你這么做，因?yàn)門CP本身是基于數(shù)據(jù)流的協(xié)議，一份完整的消息數(shù)據(jù)可能會分開多次去寫/讀，內(nèi)核的鎖只保證單次讀/寫socket是線程安全，鎖的粒度并不覆蓋整個完整消息。因此建議用一個線程去讀/寫TCP socket。

2. 多線程并發(fā)讀/寫同一個UDP socket也是線程安全的，因?yàn)閁DP socket的讀/寫操作也都上鎖了。UDP寫數(shù)據(jù)報的行為是"原子"的，不存在發(fā)一半包或收一半包的問題，要么整個包成功，要么整個包失敗。因此多個線程同時讀寫，也就不會有TCP的問題。雖然如此，但還是建議用一個線程去讀/寫UDP socket。

最后

上面文章里提到，建議用單線程的方式去讀/寫socket，但每個socket都配一個線程這件事情，顯然有些奢侈，比如線程切換的代價也不小，那這種情況有什么好的解決辦法嗎？