最近我在做一个东西的时候,
意识到了QUIC的一个问题:大容量服务器端的多线程设计比较复杂
对于tcp,不同的连接从kernel开始就分离成了不同的socket,考虑到一个线程的处理能力总有上限,如果并发的连接多了,只需要多开几个线程,不同的socket的数据从kernel上来之后就直接进入不同的线程,这样并发连接数很容易扩展
而quic基于udp,对于服务器来讲,所有的quic连接都是来自同一个socket,所以从这个socket来的数据包,只有经过进一步的解析才能知道去的是哪个连接。
所以,要么只有一个线程专门负责调用recv,然后解析数据包,识别出对应的连接,然后分发到对应连接所在的线程;
要么不同的线程都调recv,然后解析数据包识别出是哪一个连接,然而这个连接并不一定归当前调用recv的线程管理,而这个连接此时可能正在别的线程有别的活动,所以自然的想法是需要把数据从recv的线程转交给当前处理这个连接的另一个线程,和tcp相比,应用层的整个环节就显得不那么流畅,而为了转交给别的线程必然也会引入额外的mutex,这又会影响并发性能。
【 在 pNeo 的大作中提到: 】
: quic这一步买的够大了,实实在在
--
FROM 123.168.94.*