面试加分题--socket是否是并发安全的？

忘是亡心i 2024-03-29 15:16 53阅读 0赞

今天和大家聊一个有点儿东西的面试题：socket是否是并发安全的？

为了帮助大家理解，我们先假设一个场景。

就拿游戏架构来说，我们想象中的游戏架构是下面这样的。

![317db5efa8fa113b7db00fc32ca210ff.png][]

想象中的游戏架构

也就是用户客户端直接连接游戏核心逻辑服务器，下面简称**GameServer**。GameServer主要负责实现各种玩法逻辑。

这当然是能跑起来，实现也很简单。

但这样会有个问题，因为游戏这块蛋糕很大，所以总会遇到很多**挺刑**的事情。

如果让用户直连GameServer，那相当于把**GameServer的ip**暴露给了所有人。

不赚钱还好，一旦游戏赚钱，就会遇到各种攻击。

> 你猜《羊了个羊》最火的时候为啥老是崩溃？

假设一个游戏服务器能承载4k玩家，一旦服务器遭受直接攻击，那4k玩家都会被影响。

这攻击的是服务器吗？这明明攻击的是老板的钱包。

所以很多时候不会让用户直连GameServer。

而是在前面加入一层**网关层，下面简称gateway**。类似这样。

![5c9072d0cb91278f7c90bcafdae59c1f.png][]

实际的某些游戏架构

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是并发安全的吗？能让这多个线程同时并发写吗？**

![feae38c5cd0f13a6f95497d600c65177.png][]

并发读写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.c
    int tcp_sendmsg(struct kiocb *iocb, struct sock *sk, struct msghdr *msg, size_t size)
    {
        // 加锁
        lock_sock(sk);
    
    
        // ... 拷贝到发送缓冲区的相关操作
    
    
        // 解锁
        release_sock(sk);
    }

在`tcp_sendmsg`的目的就是将要发送的数据放入到 TCP 的发送缓冲区中，此时并没有所谓的发送数据出去，函数就返回了，内核后续再根据实际情况异步发送。

![086ad3a6c013975e46119a79928956a7.png][]

tcp\_sendmsg 逻辑

从`tcp_sendmsg`的代码中可以看到，在对 socket 的缓冲区执行写操作的时候，linux 内核已经自动帮我们**加好了锁**，也就是说，是**线程安全的**。

所以可以多线程不加锁并发写入数据吗？

**不能。**

问题的关键在于**锁的粒度**。

但我们知道 TCP 有三大特点，**面向连接，可靠的，基于字节流**的协议。

![76a437b18135954473fbedfb72f61faf.png][]

TCP是什么

问题就出在这个"**基于字节流**"，它是个源源不断的二进制数据流，无边界。来多少就发多少，但是能发多少，得看你的**发送缓冲区还剩多少空间**。

举个例子，假设A线程想发`123`数据包，B线程想发`456`数据包。

A和B线程同时执行`send()`，A先抢到锁，此时发送缓冲区就剩`1个`数据包的位置，那发了`"1"`，然后发送缓冲区**满了**，A线程退出（非阻塞），当发送缓冲区腾出位置后，此时AB再次同时争抢，这次被B先抢到了，B发了`"4"`之后缓冲区**又满了**，不得不退出。

重复这样多次争抢之后，原本的数据内容都被打乱了，变成了`142356`。因为数据`123是个整体`，`456又是个整体`，像现在这样数据**被打乱**的话，接收方就算收到了数据也**没办法正常解析**。

![6ba817e708e34775782059f0be22c5c6.png][]

并发写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。

于是上面的场景就变成了下面这样。

![9463c475d7df35064b4ea84af0f9f225.png][]

并发写到加锁队列后由一个线程处理

于是在 gateway 层，多个用户线程同时写消息时，会去争抢某个 socket\_fd 对应的队列，抢到锁之后就写数据到队列。而真正执行 `send(sockfd,msg)`的线程其实**只有一个**。它会从这个队列中取数据，然后**不加锁的**批量发送数据到 GameServer。

由于加锁后要做的事情很简单，也就塞个队列而已，因此非常快。并且由于执行发送数据的只有单个线程，因此也不会有消息体乱序的问题。

### 读TCP Socket是线程安全的吗？ ###

在前面有了写 socket 是线程安全的结论，我们稍微翻一下源码就能发现，**读socket其实也是加锁了的，所以并发多线程读 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);
    
        // ... 将数据从接收缓冲区拷贝到用户缓冲区
    
        // 释放锁
        release_sock(sk);
    
    }

但就算是线程安全，也不代表你可以用多个线程并发去读。

**因为这个锁，只保证你在读 socket 接收缓冲区时，只有一个线程在读，但并不能保证你每次的时候，都能正好读到完整消息体后才返回。**

所以虽然并发读不报错，但**每个线程拿到的消息肯定都不全，因为锁的粒度并不保证能读完完整消息。**

TCP 是基于数据流的协议，数据流会源源不断从网卡那送到**接收缓冲区**。

如果此时接收缓冲区里有两条完整消息，比如 "**我是小白**"和"`点赞在看走一波`"。

有两个线程 A 和 B 同时**并发去读**的话，A 线程就可能读到“**我是** `点赞走一波`"， B 线程就可能读到”**小白** `在看`"

两条消息都变得不完整了。

![be4dd6e72462b8ff485e0114585aa0db.png][]

并发读socket\_fd导致的数据异常

解决方案还是跟读的时候一样，读 socket 的只能有**一个**线程，读到了消息之后塞到**加锁队列**中，再将消息分开给到 GameServer 的多线程用户逻辑模块中去做处理。

![decb83c9db4e43c6c7226d1d5bb46e55.png][]

单线程读 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呢？它是基于**数据报**的协议。

![f731034cff53e9983c7ad08784e28abc.png][]

UDP是什么

基于数据流和基于数据报有什么区别呢？

基于**数据流**，意味着发给内核底层的数据就跟**水进入水管**一样，内核根本不知道什么时候是个头，没有明确的**边界**。

而基于**数据报**，可以类比为一件件**快递进入传送管道**一样，内核很清楚拿到的是**几件**快递，快递和快递之间**边界分明**。

![2ae75f9eb6a7db91659a9ff91fe8c021.png][]

水滴和快递的差异

那从我们使用的方式来看，应用层通过 TCP 去发数据，TCP 就先把它放到缓冲区中，然后就返回。至于**什么时候发数据，发多少数据，发的数据是刚刚应用层传进去的一半还是全部都是不确定的**，全看内核的心情。在接收端收的时候也一样。

但 UDP 就不同，UDP 对应用层交下来的报文，**既不合并，也不拆分**，而是保留这些报文的**边界**。

无论应用层交给 UDP 多长的报文，UDP 都照样发送，即一次发送一个报文。至于数据包太长，需要分片，那也是 IP 层的事情，跟 UDP 没啥关系，大不了效率低一些。而接收方在接收数据报的时候，一次取一个完整的包，不存在 TCP 常见的半包和粘包问题。

正因为**基于数据报**和**基于字节流**的差异，**TCP 发送端发 10 次字节流数据，接收端可以分 100 次去取数据，每次取数据的长度可以根据处理能力作调整；但 UDP 发送端发了 10 次数据报，那接收端就要在 10 次收完，且发了多少次，就取多少次，确保每次都是一个完整的数据报。**

所以从这个角度来说，UDP 写数据报的行为是"原子"的，不存在发一半包或收一半包的问题，要么整个包成功，要么整个包失败。因此多个线程同时读写，也就不会有 TCP 的问题。

所以，可以多个线程同时读写同一个UDP socket。

但**就算可以，我依然不建议大家这么做。**

#### 为什么不建议使用多线程同时读写同一个 UDP socket ####

UDP 本身是**不可靠**的协议，多线程高并发执行发送时，会对系统造成较大压力，这时候**丢包**是常见的事情。虽然这时候应用层能实现**重传逻辑**，但重传这件事毕竟是越少越好。因此通常还会希望能有个应用层流量控制的功能，如果是**单线程**读写的话，就可以在同一个地方对流量实现调控。类似的，实现其他插件功能也会更加方便，比如给某些 vip 等级的老板更快速的游戏体验啥的（我瞎说的）。

所以正确的做法，还是跟 TCP 一样，不管外面有多少个线程，还是并发加锁写到一个队列里，然后起一个单独的线程去做发送操作。

![61a9eb93388e0de7a7c06a70691e3432.png][]

UDP 并发写加锁队列后再写 socket\_fd

### 总结 ###

1. 多线程并发读/写同一个 TCP socket 是线程安全的，因为 TCP socket 的读/写操作都上锁了。虽然线程安全，但依然不建议你这么做，因为TCP本身是基于数据流的协议，一份完整的消息数据可能会**分开多次**去写/读，内核的锁只保证**单次**读/写socket是线程安全，**锁的粒度**并不覆盖整个完整消息。因此建议用一个线程去读/写 TCP socket。

2. 多线程并发读/写同一个 UDP socket 也是线程安全的，因为UDP socket的读/写操作也都上锁了。UDP 写数据报的行为是"原子"的，不存在发一半包或收一半包的问题，要么整个包成功，要么整个包失败。因此多个线程同时读写，也就不会有 TCP 的问题。虽然如此，但还是建议用一个线程去读/写 UDP socket。

[317db5efa8fa113b7db00fc32ca210ff.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/28/b48a0cef86d943c6be7990fa10b01a73.png
[5c9072d0cb91278f7c90bcafdae59c1f.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/28/3b1e6fb72fd4472d872c4883d3224d21.png
[feae38c5cd0f13a6f95497d600c65177.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/28/444eaae0da84470a92af6e24917427cc.png
[086ad3a6c013975e46119a79928956a7.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/28/8d579991f0ce4cda80ddf2aab6ce7fc4.png
[76a437b18135954473fbedfb72f61faf.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/28/c8d4ca39348c49d9ad66dfe0ef8c14e8.png
[6ba817e708e34775782059f0be22c5c6.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/28/587146030eb7402aa92b36b463a207ce.png
[9463c475d7df35064b4ea84af0f9f225.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/28/7e3383ce84b74eb08e9b34b44ed5edb9.png
[be4dd6e72462b8ff485e0114585aa0db.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/28/ee4046848b9d4d0aace46dec0f92223e.png
[decb83c9db4e43c6c7226d1d5bb46e55.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/28/bee5cef236194b4993abb5e33ac5253e.png
[f731034cff53e9983c7ad08784e28abc.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/28/62078ab8f8754f99bc1ff9b0c431fc97.png
[2ae75f9eb6a7db91659a9ff91fe8c021.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/28/fbc9a183fbdd4b7ab80f68b52dcc6a55.png
[61a9eb93388e0de7a7c06a70691e3432.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/28/ad38a75ef70247eeb046e726510c5b6b.png