導(dǎo)語：2018年11月13~14日，由亞太CDN聯(lián)盟主辦的第七屆GFIC全球家庭互聯(lián)網(wǎng)大會在上海舉辦，藍汛ChinaCache資深架構(gòu)師王立鷗先生分享了《QUIC在CDN 超遠(yuǎn)節(jié)點間的互聯(lián)應(yīng)用》的技術(shù)內(nèi)容。
在QUIC的快速發(fā)展中，藍汛ChinaCache第一時間關(guān)注了gQUIC和IETF兩個不同的分支，并通過實踐和比較兩個分支異同和自己業(yè)務(wù)的需求，將QUIC應(yīng)用到了CDN系統(tǒng)中。對此，王立鷗從CDN的層級架構(gòu)間通信的要求、QUIC和傳統(tǒng)層級間通信方式的對比、以及在超遠(yuǎn)場景中的應(yīng)用進行了總結(jié)和分享。
眾所周知，傳統(tǒng)CDN會有多級結(jié)構(gòu)，每一級結(jié)構(gòu)會有不同熱度數(shù)據(jù)。在CDN節(jié)點之間有大量的通訊數(shù)據(jù)，這些數(shù)據(jù)進行分布式存儲時的路徑對最終CDN服務(wù)質(zhì)量有著非常重要的影響。通常來說影響通訊質(zhì)量的因素通常會受到緩存業(yè)務(wù)內(nèi)容的性質(zhì)、節(jié)點間的網(wǎng)絡(luò)連接和Client-server側(cè)的傳輸架構(gòu)和機制的影響。這些層級間的數(shù)據(jù)拉取性能會直接影響到整體CDN的下發(fā)響應(yīng)速度。通?？梢酝ㄟ^TCP優(yōu)化手段（數(shù)據(jù)連接池、TCP優(yōu)化）、緩存數(shù)據(jù)分塊、高層級向低層次的數(shù)據(jù)推送、緩存數(shù)據(jù)預(yù)拉取、數(shù)據(jù)壓縮等手段實現(xiàn)超遠(yuǎn)節(jié)點之間的進一步傳輸。
在這種情況下，QUIC的優(yōu)勢就展現(xiàn)出來了。QUIC協(xié)議其實是一個快速演進的協(xié)議，分為兩個版本。我們看的版本一般都叫g(shù)QUIC，另外一個QUIC是IETF QUIC。所謂gQUIC，是指在HTTP/2之后，Google用UDP承載開發(fā)的，chrome支持的協(xié)議；而IETFQUIC，是IETF 在gQUIC成功應(yīng)用的基礎(chǔ)上，作為QUIC標(biāo)準(zhǔn)化的版本。
王立鷗進一步演示分析了相同的gQUIC版本、不同的實現(xiàn)之間兼容性問題，以及不同的gQUIC版本，和實際業(yè)務(wù)部署環(huán)境、使用場景間的兼容性問題。
那么QUIC在應(yīng)用中具體有什么優(yōu)勢呢？王立鷗通過對超遠(yuǎn)的CDN節(jié)點PoP測試展示，呈現(xiàn)了QUIC在安全、性能、吞吐、壓縮四個方面的特點。在測試中，一個文件同時用QUIC下載，QUIC的確在一個新建的TLS連接過程中非常節(jié)約時間。如在200多毫秒延時的情況下，這個過程對于一個HTTP1+TLS連接過程可能花一秒鐘，對于QUIC來說可能花三分之一時間就建連成功。由此，可以看出，QUIC應(yīng)用效率非常驚人，它既能滿足安全傳輸?shù)囊?，也實現(xiàn)了提升傳輸效率、降低傳輸成本的需求。
測試驗證的環(huán)境
最后，王立鷗表示，QUIC對于業(yè)務(wù)系統(tǒng)的負(fù)擔(dān)（CPU占用等）通過不斷優(yōu)化，仍然會高于TCP/HTTP的傳輸方式，但這個負(fù)擔(dān)目前來看是可以接受的。由于QUIC現(xiàn)在沒有真正事實上標(biāo)準(zhǔn)，在前端應(yīng)用可能會有更多阻力，但這并不妨礙我們在后端業(yè)務(wù)中使用QUIC這種新技術(shù)提高業(yè)務(wù)實踐的效率。
關(guān)于QUIC，您還想了解什么？歡迎大家留言與我們互動。
申請創(chuàng)業(yè)報道，分享創(chuàng)業(yè)好點子。點擊此處，共同探討創(chuàng)業(yè)新機遇！
