CDN 行業的技術出發點就是把用戶訪問網站業務的時間縮短，再縮短。因此，CDN服務商都儘可能把服務節點部署到離最終網民接近的網絡節點上。除了從系統部署方式上提高網民訪問的速度，減少網絡傳輸的時間之外，在網民用於訪問網站的網絡協議上也在不斷地演進變化。本文將根據藍汛對QUIC協議的應用和測試經驗，在該協議的開發、配置和啟動等技術環節進行分享。
由SPDY到HTTP/2
2009年，Google在 "Make the Web faster" 的目標下，針對HTTP協議提出了SPDY。當時，提出SPDY的目標是在HTTP基礎上，將頁面加載的速度提高50%，同時也將部署未來新的應用協議的複雜性降低。
SPDY被證明是成功的，因為它在以下4個方面提升了整體的性能：
1. 多路複用：通過同一個域名使用1個或者相對於HTTP/1.1更少的TCP連接數，SPDY避免了頭部阻塞（HOL），同時由於減少了TCP連接，也就降低了新開TCP連接的系統開銷。
2. 頭部壓縮：通過對HTTP Header中反覆發送的字段進行壓縮，通過SPDY之後，請求頭和響應頭的體積都大大減小。
3. 請求的優先級區分：高優先級的資源被優先請求，因此，對於頁面解析的關鍵元素也就被優先下載展示。
4. Server Push / Server Hint: Server Push 在用戶端還沒有請求的前提下，由服務端推送相關內容給用戶端；Server Hint是在服務端將一些資源標記了優先級，用戶端在請求的時候可以根據目前的帶寬情況（限制情況）決定是否下載。
因為SPDY在針對HTTP/1.x上性能的提升，IETF HTTP 工作組基於SPDY通過HTTP/2來優化HTTP協議。
HTTP/2 借鑑了SPDY的優化策略和思路，然而，兩者之間也有不同點：
HTTP/2和SPDY的主要區別在於頭部壓縮的算法： HTTP/2使用的是HPACK壓縮的方式，而SPDY使用的是DEFLATE方式壓縮。
儘管如此，HTTP/2和SPDY還都是基於TCP作為連接層的基礎，因此，性能的提升都是在同一個基礎之上的。TCP協議飽受詬病的那些擁塞和丟包處理的方式影響著它們的性能發揮。
由TCP到UDP，QUIC的提出
QUIC 是（Quick Udp Internet Connection）的首字母縮寫。是由 Google 提出的使用 UDP 進行多路併發傳輸的協議。
QUIC相比上文中 TCP+TLS+HTTP/2 組合有如下優勢 ：
· 減少了 TCP 三次握手及 TLS 握手時間。
· 改進的擁塞控制。
· 避免隊頭阻塞的多路複用。
· 連接遷移。
· 前向冗餘糾錯。
根據Jana Iyengar在2016年IETF柏林會議上針對QUIC的架構（如下圖）採用QUIC採用UDP替代TCP實現的傳輸方式相對於TCP+TLS+HTTP/2的架構有了很大的變化。
目前看，早期在Google應用QUIC協議的業務效果相當不錯，93%的業務沒有因為QUIC應用不成功而回滾到原先架構；應用QUIC協議的業務降低 了5%的頁面加載時間，而Youtube應用QUIC後，播放中再緩存降低了30%。
QUIC開發和測試
QUIC測試開發環境搭建：目前國內有的廠商已經在部分應用平臺使用了QUIC協議，然而，支持QUIC的公有云目前還都沒有。因此，我們如果需要測試QUIC的應用和平臺，還需要自己進行搭建。下面，就將我們在內部進行QUIC初期測試時候的經驗分享給大家。
Chrome瀏覽器打開QUIC：搭建一個最簡單的實驗環境，我們需要一個支持QUIC的server端和支持QUIC的客戶端。
支持QUIC的客戶端，最簡單直接的方式就是採用Chrome瀏覽器。通常而言，Chrome瀏覽器還沒有打開QUIC協議的支持，因此，需要通過以下步驟來操作：
1. 在Chrome地址欄輸入chrome://flags訪問實驗性的功能開關
2. 在頁面中搜索QUIC關鍵字
3. 將QUIC的開關由"Default"變為"Enable"
4. 重啟Chrome
QUIC協議打開後，要檢視相關的連接和配置需要通過在Chrome瀏覽器地址欄輸入chrome://net-internals/#quic 來打開相關的頁面。
由這個截圖，我們可以看到，目前chrome（69）的QUIC版本是v43，這是個相當新的版本，當然也會對QUIC的server端選擇造成困擾。
Caddy Server支持QUIC：Caddy 和我們常用的Apache、Nginx一樣，是一個Web Server，而且是使用go語言開發的。相對於後兩者，它具備以下一些優點：
· 內建對HTTP/2的支持
· 對Let'sencrypt的支持
· 對QUIC支持
· 對多核系統的支持
· 易於部署
· 對IPv6的支持
其中第2、第3點是滿足我們後面的實驗的重要功能需求。
安裝Caddy server
我們採用的是Centos7系統，安裝Caddy使用直接從getcaddy.com直接拉取編譯好的版本：
$ curl -s https://getcaddy.com | bash
腳本執行的過程中，需要提供sudo權限讓caddy程序安裝到/usr/local/bin目錄下。
等腳本執行完我們需要為caddy創建一個沒有登錄權限的用戶，如"caddy"：
$ sudo adduser -r -d /var/www -s /sbin/nologin caddy
然後我們要建立www的目錄，配置文件caddyfile的目錄，及其他一些相關權限：
$ sudo mkdir /etc/caddy
$ sudo chown -R root:caddy /etc/caddy
$ sudo touch /etc/caddy/Caddyfile
$ sudo mkdir /etc/ssl/caddy
$ sudo chown -R caddy:root /etc/ssl/caddy
$ sudo chmod 0770 /etc/ssl/caddy
$ sudo mkdir /var/www
$ sudo chown caddy:caddy /var/www
配置caddy的系統服務
由於我們使用的是Centos 7，使用的是systemd管理系統服務。方便的是，caddy的systemd服務腳本可以從以下地址下載：
$sudo curl -s
https://raw.githubusercontent.com/mholt/caddy/master/dist/init/linux-systemd/caddy.service-o /etc/systemd/system/caddy.service
我們需要修改一下caddy的service文件：
/etc/systemd/system/caddy.service當中User和Group信息，將它們改為caddy:
; User and group the process will run as.
User=caddy
Group=caddy
reload一下，以使修改生效：
$ sudo systemctl daemon-reload
現在，在啟動caddy之前，我們還需要配置一下Let'sencrypt的自動TLS。
配置Let's encrypt自動TLS
要通過Caddy使用Let'sencrypt的自動TLS，要滿足以下條件：
1. Caddy需要綁定443端口，同時，這個端口要從外網可訪問
2. Caddy HTTP只能設定為80端口，同時，TLS不能從caddy的配置裡關掉
3. Caddy裡面的server設置的域名必須是真實可解析的域名，不能使localhost，證書將綁定這個域名
4. Caddy必須設定用於私鑰恢復的郵件地址
我們來配置/etc/caddy/Caddyfile來滿足要求：
假設我們的域名是quictesting.net，那麼我們的配置文件可以是這樣：
quictesting.net {
root /var/www
gzip
}
別忘了在/var/www下面放上一個index.html文件，比如Hello World 。
$ sudo systemctl restart caddy
啟動Caddy，然後我們再使用Chrome來訪問，可以觀察header信息：
說明Let'sencrypt的HTTPS已經起作用了。然而，這個時候，QUIC還沒有啟動呢。
啟動Caddy QUIC
通過修改systemd的服務啟動選項來啟動QUIC服務。
別忘了reload daemon以保證配置生效。這時候，我們再用chrome來訪問，看看header的變化。發現在響應頭多了一行：
表明Caddy現在系統的QUIC版本是39。因此，這個時候，我們用Chrome去看QUIC信息，發現沒有active connection，原因就在於此。
解決方案：關於升級Caddy 使用的libquic，我們將在下期CC-Tech與您分享。
閱讀更多 互聯網科技圏 的文章
