QUIC选项是否能做到强制QUIC?

[zhangyz1997]

这两日访问Google还是时常遭遇RST, 把 www.google.com:443 加入 Edge 的 --origin-to-force-quic-on 参数里面就好转很多，但是这个参数只能逐个逐个域名添加，不支持通配符，能添加的域名有限。正好我看到 ghostcp 中提供quic参数, 但是似乎在config里面加上QUIC也不总是能自动像https那样升级到QUIC? 还是我对QUIC这个选项的理解有问题?

[zhangyz1997]

那可惜了，ghostcp在ipv6下用quic看googlevideos还是挺快的，就是时灵时不灵

不过说起来Quora的QUIC又能work，就很奇怪:

[jonm58]

那可惜了，ghostcp在ipv6下用quic看googlevideos还是挺快的，就是时灵时不灵

不过说起来Quora的QUIC又能work，就很奇怪:

googlevideos试一试加"sat"

[jonm58]

IPv4没办法使用QUIC,为什么IPv6就可以用🤨

[zhangyz1997]

那可惜了，ghostcp在ipv6下用quic看googlevideos还是挺快的，就是时灵时不灵 不过说起来Quora的QUIC又能work，就很奇怪:

googlevideos试一试加"sat"

已经是了

Youtube.Video

ipv6=true method=quic,https,s-seg,sat,df .googlevideo.com

如果QUIC这问题能解决，那Google系、Meta系、CF系和BBC这四大系列的问题就都解决了 (感觉也是两难，ghostcp彻底用不了DoT/DoH, phantomsocks用不了QUIC) 顺便一提，你YouTube.Video那里ipv6=true你写成了ture, 然后 storage.googleapis.com 那里的IP地址里面有一个多了个 "]" 号

[jonm58]

那可惜了，ghostcp在ipv6下用quic看googlevideos还是挺快的，就是时灵时不灵 不过说起来Quora的QUIC又能work，就很奇怪:

googlevideos试一试加"sat"

已经是了

Youtube.Video ipv6=true method=quic,https,s-seg,sat,df .googlevideo.com

如果QUIC这问题能解决，那Google系、Meta系、CF系和BBC这四大系列的问题就都解决了 (感觉也是两难，ghostcp彻底用不了DoT/DoH, phantomsocks用不了QUIC) 顺便一提，你YouTube.Video那里ipv6=true你写成了ture, 然后 storage.googleapis.com 那里的IP地址里面有一个多了个 "]" 号

额,你怎么Quora的IP是来自SJC? 我的是HKG.

[jonm58]

1. 网络质量较好的链路上QUIC的表现可能还不如TCP
2. 底层传输协议：QUIC底层使用UDP进行传输，而由于内核中设计的UDP收发包机制存在一定问题，使得其批量收发包等接口性能都不如TCP，而这也同时影响QUIC报文的传输性能
3. 报文加解密：QUIC内部利用TLS对报文进行了从头到尾全方位的加密，而TCP本身并不会强制使用SSL机制来进行加密。复杂的加密过程对CPU的性能损耗不容小觑
4. ACK处理：虽然TCP和QUIC均是反馈驱动的传输协议，发送方通过来自接收方的ACK来进行丢包重传等一系列处理，然而TCP的ACK报文是直接在内核中通过tcp_ack函数进行处理，而QUIC则是不管三七二十一把包括ACK在内的所有报文先收上来放到用户层后再进行处理，这就导致了额外的用户级和内核级的上下文切换以及数据从内核转移至用户的额外拷贝；
5. UDP限速（UDP throttling）：国内不少运营商会对UDP流量进行限速处理，主要原因在于UDP这类不存在流量控制、拥塞控制的协议可能会被滥用从而抢占大量链路带宽，因此才会出现许多故意把UDP报文伪装成TCP报文（俗称fake TCP）从而绕开限速的工具。另外由于UDP五元组变化频繁，这就会导致某些状态设备在短时间内需要保存大量的UDP连接，这会给设备造成很大的压力