写点什么

socket 是并发安全的吗

作者:C++后台开发
  • 2022-12-15
    湖南
  • 本文字数:5418 字

    阅读完需:约 18 分钟

socket是并发安全的吗

为了更好的聊今天的话题,我们先假设一个场景。


我相信我读者大部分都是做互联网应用开发的,可能对游戏的架构不太了解。


我们想象中的游戏架构是下面这样的。


想象中的游戏架构


也就是用户客户端直接连接游戏核心逻辑服务器,下面简称 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 内核已经自动帮我们加好了锁,也就是说,是线程安全的


更多 C++后台开发技术点知识内容包括 C/C++,Linux,Nginx,ZeroMQ,MySQL,Redis,MongoDB,ZK,流媒体,音视频开发,Linux 内核,TCP/IP,协程,DPDK 多个高级知识点。

C/C++Linux服务器开发高级架构师/C++后台开发架构师免费学习地址

【文章福利】另外还整理一些C++后台开发架构师 相关学习资料,面试题,教学视频,以及学习路线图,免费分享有需要的可以点击领取


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


不能。


问题的关键在于锁的粒度


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

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

最后

上面文章里提到,建议用单线程的方式去读/写 socket,但每个 socket 都配一个线程这件事情,显然有些奢侈,比如线程切换的代价也不小,那这种情况有什么好的解决办法吗?


原文链接:socket 是并发安全的吗

用户头像

C/C++后台开发技术交流qun:720209036 2022-05-06 加入

还未添加个人简介

评论

发布
暂无评论
socket是并发安全的吗_网络编程_C++后台开发_InfoQ写作社区