QUIC代理服务的实现

QUIC Proxy

随着http/3的临近，quic越来越受到关注，关于quic的介绍网上有很多，这里就不做介绍了。目前，quic有两个版本Google QUIC 和 IETF QUIC，随着IETF的最终定稿，谷歌也会向其靠拢。
作为全球最大的浏览器Chrome很早以前就开始支持GQUIC（Google QUIC），并且Youtube已经开始全站应用GQUIC协议，所以本文介绍的QUIC代理服务实现的是谷歌版本的quic服务。

QUIC Proxy 特点

基于chromium开源项目（Chrome开源项目）

chromium 本身提供了一个测试用的quic服务，但是这个服务是单进程，且http回源需要整个文件下载完才能发给前端，大的视频文件这种方式是不能接受的，所以在epoll_quic_server这个demo基础上，基于chromium架构，重新开发了一个支持高并发，可商用的quic to http代理服务。
相较于其他quic开源项目， 因为使用chromium中的quic协议，所以可以做到与chrome浏览器做到同步更新，完美的兼容各个版本的chrome内核浏览器，避免了其他开源项目quic协议更新慢，实现不完全的苦恼。

使用最新的linux内核特性解决性能问题

quic服务属于udp服务，udp的服务在性能上有两个很难解决的问题：

1. 多核的利用问题，由于不像tcp那样，accept上来一个连接后，可以分配到一个固定的线程或进程上进行读写，udp服务recvfrom的数据包无法确定哪个线程会收到，所以需要通过消息队列，或加锁的方式，进行串行处理。
2. 频繁的系统调用导致cpu过高问题，相对于tcp服务，udp服务往往cpu都比较高，是由于为了避免网络传输过程中IP包被拆包，一般包的大