回答
收藏
分享
举报
Nginx QUIC如何区分支持 gQUIC 和 ietf QUIC
提问于2020-10-27 00:58

浏览 1.8k

看了陶辉老师 infoQ 上 “Nginx支持 QUIC/HTTP3的实现路径和实践思考” 的公开课的回放,有几个问题十分想提问一下。

1. 目前市面上的QUIC太多了,微软的MSQUIC、Google的GQUIC还有 IETF 的 QUIC,这么多QUIC都是不一样的标准,wireshark抓包解析完全和老师课上演示的不一样(因为抓到的是g),Nginx 该如何支持。据我了解,阿里云gslb是支持gQUIC的。而且chrome浏览器应该也是默认发的是gQUIC。

2. 公开课结尾有同学提到是否QUIC有弱点,我个人感觉QUIC的最大弱点就是UDP吧,UDP太灵活了,迟早有人会参考KCP把QUIC改成完全不遵守“交通规则”的协议,因为拥塞控制算法完全由用户可控了,我为了自己快,疯狂发包就完事了。而且QUIC把这些本应该内核考虑的事情都提到用户态做了,是否会对Nginx的资源使用率造成压力(是否有测过相同配置下,开启QUIC是否承受的QPS会更小)

3.  陶辉老师还有类似HTTP3的分享吗?

已修改于2023-03-17 02:12



写下您的回答
发表回答
全部回答(1)

按点赞数排序

按时间排序

1、IETF的QUIC已经有33个草案了,这是RFC规范,所以现在Nginx不太会去支持其他QUIC版本了。目前Nginx的quic分支,是基于最新的RFC 33 draft草案实现的。你可以参考下spdy与HTTP2在Nginx上的实现,那时HTTP2迟迟未推出时,google的spdy广为使用,Nginx推出了spdy模块,所以这其实是个开发效率、成本的权衡问题。

2、拥塞控制由应用层来实现,还是由内核来实现,对于网络安全性来说,这并不是问题。对于网络来说,每一台主机也未必可信。对于Linux来说,内核也是可以去改的。所以,长期来看,拥塞控制不会是问题,个人看法。

3、11.27号在GOPS上海站还会做HTTP3的进一步探讨。

赞同

1

回复举报

回答于2020-10-30 10:08



回复陶辉
回复
提问者
清荣
这家伙很懒还未留下介绍~
0
文章
2
问答
1
粉丝
相关问答

关于quic http3服务,首先需要明白以下几点:
1. 关于证书,证书跟具体的http协议无关,如果http2 同样证书可以成功访问,而http3服务不可以,应该排除证书问题
2. 关于域名,同样的局域网,不管是http2还是http3服务 ,域名都是一样的,不一样的只是协议类型和端口号,http2是基于tcp,http基于quic,quic又基于udp,协议类型的话是浏览器客户端主动的行为,端口也是可以可指定,如果http2服务可以通过域名访问成功,说明跟域名没有关系,可以排除域名问题
3. 有一点需要注意,目前常见浏览器已经支持http3,不过访问服务的时候,都首先会通过http1或者http2去访问服务,这就要求服务端同事需要有tcp 的端口提供服务,然后response 带有Alt-Svc 'quic=":443"; h3=":443" 类似header,告诉浏览器服务端支持http3, 然后浏览器才会通过quic发送udp包去访问服务端的udp server端口,访问服务
4. 基于上述1和2这两点,证书和域名问题都可以排除,而您仿照此前的配置文件,但是访问主页却显示http1协议连接。关于这个问题,就可以参考第3点,浏览器先是http1访问,在这一处,您可在浏览器通过f12看到请求的返回信息,看response 处是否有Alt-Svc 'quic=":443"; h3=":443" 类似header, 如果没有该header ,请检查server端tcp 服务的配置;如果有说明您部署的服务tcp端口提供了服务,而且说明证书和域名都是没有问题的,这时候您重新点击浏览器访问服务,通过浏览器或者wireshark抓包工具查看浏览器是否发送了udp的包去请求server,按照您在云环境可以成功访问,说明浏览器是没问题的,应该肯定会发送udp请求报文,这时候您要看局域网内部去抓包udp端口上的报文,确认是否收到来自于浏览器的udp报文,如果没有,可能是局域网服务器屏蔽掉了该端口的报文,请检查局域网服务器的防火墙等配置;如果能够抓到该报文,您需要查看nginx的log文件了,这时候可以看到quic相关日志,如果有错误,可以看到原因

点赞 0
浏览 979