- 主题:HTTP是不是太啰嗦了
quic早已经从draft变成standard了
In May 2021, the IETF standardized QUIC in RFC 9000, supported by RFC 8999, RFC 9001 and RFC 9002
【 在 eGust 的大作中提到: 】
: 我看 nginx 的意思是，quic 终稿还没定，别家的支持基本上也只对某版 draft，包括各家云供应商。一般用用只要 reverse proxy 支持了就差不多了，反正 auto scaling 也不可能让每个 web service 都开长链接
:
--
FROM 123.168.94.*
所有基于纯文本编码的东西都是罗嗦的
其实Json也是罗嗦的
【 在 threebird 的大作中提到: 】
: 巨大的头部，因为无状态，还得附上巨大的cookie。
--
FROM 123.168.94.*
本质上，http最早诞生的那个时候，不是用来处理session或者dialog的
那个时候甚至一个http request结束，连接都会拆掉
后来需要用http来承载session或者dialog，很自然的就需要在每个request里面携带和session相关联的信息，类似于cookie这些东西
不带行不行呢？不行啊，你也不知道你同一个session里面的下一个请求什么时候来，从什么连接来，那你怎么关联整个session呢？
后来有了http1.1，连接会复用，但这个连接保持的时间，大致也限于客户端当前页面的最后一个请求完成。谁也不知道过多久之后，用户会点下一个链接发起一个什么动作，所以连接不可能一直保持。
所以还是没有持久的连接，还是需要解决后续request和整个session的关联问题，所以还是需要带类似cookie这种东西。
即使后来到了HTTP2，连接也依然不是长时间持续的，上面的情况依然类似。
现在到了http3 over quic, 在quic层面上能支持connection-id刷新，connection重用，等等，但是本质上，quic的session，不可能和第七层的session生命周期一样长，不然服务器会有最大并发session的容量的压力。
所以实际上，即使是http3 over quic，依然需要http自己通过特定的header来标识和维护关联session
【 在 threebird 的大作中提到: 】
: 不是文本问题，无效的东西太多，比如所有cookie每次都要带上，HTTP头中很多字段没必要每次都出现。
: :
--
修改:wallyz FROM 123.168.94.*
FROM 123.168.94.*
最近我在做一个东西的时候，
意识到了QUIC的一个问题：大容量服务器端的多线程设计比较复杂
对于tcp，不同的连接从kernel开始就分离成了不同的socket，考虑到一个线程的处理能力总有上限，如果并发的连接多了，只需要多开几个线程，不同的socket的数据从kernel上来之后就直接进入不同的线程，这样并发连接数很容易扩展
而quic基于udp，对于服务器来讲，所有的quic连接都是来自同一个socket，所以从这个socket来的数据包，只有经过进一步的解析才能知道去的是哪个连接。
所以，要么只有一个线程专门负责调用recv，然后解析数据包，识别出对应的连接，然后分发到对应连接所在的线程；
要么不同的线程都调recv，然后解析数据包识别出是哪一个连接，然而这个连接并不一定归当前调用recv的线程管理，而这个连接此时可能正在别的线程有别的活动，所以自然的想法是需要把数据从recv的线程转交给当前处理这个连接的另一个线程，和tcp相比，应用层的整个环节就显得不那么流畅，而为了转交给别的线程必然也会引入额外的mutex，这又会影响并发性能。
【 在 pNeo 的大作中提到: 】
: quic这一步买的够大了，实实在在
--
FROM 123.168.94.*