# 標準化進展情況 QUIC工作組自2016年底以來在積極標準化該協議，現計劃于2019年7月之前完成。 到2018年11月為止，還沒有過大型的HTTP/3互通性測試。目前來說，只有2個實現進行過測試，且這兩個實現不基于瀏覽器和主流的開源服務器軟件。 QUIC工作組的wiki頁面目前列出了大約15種QUIC實現（[QUIC實現列表](https://github.com/curl/curl/wiki/QUIC-implementation)），但距離它們都能與最新版的規范草案互操作仍有很長的路。 實現QUIC并不容易，且到目前為止，協議本身還在不斷演變。 ## 服務器 Apache和Nginx還沒有對QUIC支持的公開聲明。 ## 客戶端 還沒有任何主流瀏覽器的任何狀態的任何版本支持IETF版本的QUIC或者HTTP/3協議。 Google Chrome在數年前已經支持Google版的QUIC，但是該版本不能與官方的QUIC版本互操作，且它的HTTP實現與HTTP/3不同。 ## 實現的障礙 為了避免重復發明輪子，以及依靠可信賴的現有協議，QUIC決定使用TLS 1.3作為它的加密和安全協議層。不過工作組決定大幅精簡QUIC中TLS的使用，只使用“TLS信息”（TLS Messages）而不是協議中的“TLS記錄”（TLS Records）。 這聽上去可能人畜無害，但也事實上成為了很多QUIC堆棧實現者的重大障礙。現存的支持TLS 1.3的TLS庫都沒有提供此功能的API并允許QUIC訪問它。有一些QUIC的實現由大型機構完成，這些機構可能有自己的TLS協議棧，但并不是所有實現都能如此。 例如，主流的重量級開源軟件OpenSSL就沒有這些API，且到目前（2018年11月）為止，沒有表達過在任何時間點提供這些API的意愿。 這最終將成為QUIC協議棧部署的障礙。因為QUIC要么基于其他TLS庫，要么使用補丁版OpenSSL或者等待OpenSSL版本更新。 ## 操作系統內核、CPU負載 據Google和Facebook稱，與基于TLS的HTTP/2相比，它們大規模部署的QUIC需要近2倍的CPU使用量。 對此的進一步解釋包括： - Linux內核的UDP部分沒有得到像TCP堆棧那樣的優化，因為傳統上沒有使用UDP進行如此高速的信息傳輸。 - TCP和TLS有硬件加速（負載卸載到硬件，offload），而這對于UDP很罕見，對于QUIC則基本不存在。 就上述理由，我們可以相信QUIC的CPU使用量能隨著時間的推移得到改善。