最近我在做一个东西的时候，

意识到了QUIC的一个问题：大容量服务器端的多线程设计比较复杂

对于tcp，不同的连接从kernel开始就分离成了不同的socket，考虑到一个线程的处理能力总有上限，如果并发的连接多了，只需要多开几个线程，不同的socket的数据从kernel上来之后就直接进入不同的线程，这样并发连接数很容易扩展

而quic基于udp，对于服务器来讲，所有的quic连接都是来自同一个socket，所以从这个socket来的数据包，只有经过进一步的解析才能知道去的是哪个连接。
所以，要么只有一个线程专门负责调用recv，然后解析数据包，识别出对应的连接，然后分发到对应连接所在的线程；
要么不同的线程都调recv，然后解析数据包识别出是哪一个连接，然而这个连接并不一定归当前调用recv的线程管理，而这个连接此时可能正在别的线程有别的活动，所以自然的想法是需要把数据从recv的线程转交给当前处理这个连接的另一个线程，和tcp相比，应用层的整个环节就显得不那么流畅，而为了转交给别的线程必然也会引入额外的mutex，这又会影响并发性能。


【 在 pNeo 的大作中提到: 】
: quic这一步买的够大了，实实在在  
--
FROM 123.168.94.*

io线程模型，概念上一般当港口处理即可：包当集装箱，船当投递/执行线程，卡车当执行/投递线程
io completion port名字的由来

【 在 wallyz 的大作中提到: 】
: 最近我在做一个东西的时候，
: 意识到了QUIC的一个问题：大容量服务器端的多线程设计比较复杂
: 对于tcp，不同的连接从kernel开始就分离成了不同的socket，考虑到一个线程的处理能力总有上限，如果并发的连接多了，只需要多开几个线程，不同的socket的数据从kernel上来之后就直接进入不同的线程，这样并发连接数很容易扩展
: ...................
--
FROM 123.116.210.*

这帖子真是受教了
--
FROM 123.191.63.*