Cloudflare已經準備了一個模塊，以在NGINX中提供對HTTP / 3協議的支持。。 模塊完成 以乳蛋餅庫中的快照形式 由Cloudflare開發，並實現了QUIC和HTTP / 3傳輸協議。 乳蛋餅代碼是用Rust編寫的，但是NGINX的模塊是用C編寫的，並通過動態鏈接訪問該庫。 根據BSD許可，營業時間為開放時間。
在客戶端軟件中， HTTP / 3支持已添加到Chrome Canary實驗版本中 和curl工具。 在服務器端，到目前為止，要求使用功能有限的隔離測試實現。 在Nginx中處理HTTP / 3的能力 將大大簡化具有HTTP / 3支持的服務器的部署 它將使新協議的測試實現更容易訪問。
HTTP / 3標準化了QUIC協議的使用 作為HTTP / 2的傳輸方式。 Google開發了QUIC協議，替代了網絡上的TCP + TLS，從而 打算解決TCP中安裝和協調化合物的時間過長的問題 並延遲消除數據傳輸過程中的分組丟失。 QUIC是UDP協議的插件，支持多個連接的多路復用，並提供與TLS / SSL等效的加密方法。
在QUIC的主要特徵中脫穎而出：
- 類似於TLS的高安全性（實際上，QUIC提供了在UDP上使用TLS的能力）。
- 流完整性控制，可防止數據包丟失。
- 能夠立即建立連接的能力（0-RTT，在大約75％的情況下，可以在發送連接建立數據包後立即傳輸數據），並確保在發送請求和接收響應之間的最小延遲（RTT，往返時間） 。
- 重傳數據包時不使用相同的序列號，這避免了確定接收到的數據包時的歧義並消除了超時。
- 丟失數據包只會影響與其關聯的流的傳遞，並且不會停止通過當前連接並行傳輸的流中數據的傳遞。
- 糾錯工具可最大程度地減少因丟失數據包的重傳而造成的延遲。 使用特殊的數據包級糾錯碼可以減少需要重新傳輸丟失的數據包數據的情況。
- 密碼塊邊界與QUIC數據包邊界對齊，減少了數據包丟失對後續數據包內容解碼的影響
- 阻止TCP隊列沒有問題
- 支持連接標識符，從而減少了為移動客戶端建立重新連接的時間
- 能夠連接高級機制以控制連接過載
- 使用預測每個方向上的帶寬的技術來確保發送數據包的最佳強度，從而防止其達到觀察到數據包丟失的擁塞狀態
- 通過TCP獲得顯著的性能和性能提升。 對於YouTube之類的視頻服務，QUIC在觀看視頻時將重新緩衝操作減少了30％。
如何在NGINX中實現支持HTTP / 3的模塊？
對於那些對能夠在其服務器上實現此模塊感興趣的人， 他們可以按照我們下面分享的說明進行操作。
要編譯它， 他們只需要下載Nginx 1.16的補丁 和乳蛋餅庫代碼。
curl -O https://nginx.org/download/nginx-1.16.1.tar.gz tar xzvf nginx-1.16.1.tar.gz git clone --recursive https://github.com/cloudflare/quiche cd nginx-1.16.1 patch -p01 < ../quiche/extras/nginx/nginx-1.16.patch
我們編譯了啟用了HTTP / 3支持的NGINX：
./configure \ --prefix=$PWD \ --with-http_ssl_module \ --with-http_v2_module \ --with-http_v3_module \ --with-openssl=../quiche/deps/boringssl \ --with-quiche=../quiche make
在編譯期間，TLS支持應基於BoringSSL庫（“ –with-openssl = .. / quiche / deps / boringssl”），尚不支持使用OpenSSL。
要接受配置中的連接，他們將需要在偵聽器指令中添加“ quic”標誌。