有句話(huà)叫做一流企業(yè)定標(biāo)準(zhǔn)、二流企業(yè)做品牌、三流企業(yè)賣(mài)技術(shù)、四流企業(yè)做產(chǎn)品。Google似乎在沖著一流企業(yè)的目標(biāo)邁進(jìn)。去年，Google已經(jīng)從以SPDY為基礎(chǔ)的HTTP協(xié)議16年來(lái)的首個(gè)更新HTTP/2正式定稿中嘗到了甜頭。最近Google又開(kāi)始考慮更進(jìn)一步，用改進(jìn)版的UDP協(xié)議QUIC給web提速。根據(jù)它近日公布的性能評(píng)估，這一融合了UDP與TCP優(yōu)勢(shì)的協(xié)議似乎提升效果明顯。
QUIC是Quick UDP Internet Connection的簡(jiǎn)稱(chēng)，是Google制定的一種基于UDP的低時(shí)延的互聯(lián)網(wǎng)傳輸層協(xié)議。我們知道，TCP/IP協(xié)議族是互聯(lián)網(wǎng)的基礎(chǔ)。其中傳輸層協(xié)議包括TCP和UDP協(xié)議。與TCP協(xié)議相比，UDP更為輕量，但是錯(cuò)誤校驗(yàn)也要少得多。這意味著UDP往往效率更高（不經(jīng)常跟服務(wù)器端通信查看數(shù)據(jù)包是否送達(dá)或者按序），但是可靠性比不上TCP。通常游戲、流媒體以及VoIP等應(yīng)用均采用UDP，而網(wǎng)頁(yè)、郵件、遠(yuǎn)程登錄等大部分的應(yīng)用均采用TCP。
Google想到能否把這兩種協(xié)議的優(yōu)勢(shì)結(jié)合起來(lái)，同時(shí)實(shí)現(xiàn)低時(shí)延和高可靠并將其應(yīng)用到更高安全的協(xié)議上，于是就有了QUIC。
以往典型的安全TCP連接（TCP+TLS）往往需要在發(fā)送與接收端先進(jìn)行2、3輪的握手通信才能正式開(kāi)始數(shù)據(jù)傳輸。而利用QUIC協(xié)議，如果雙方此前通信過(guò)的話(huà)?cǎi)R上就可以對(duì)話(huà)（即便雙方此前未通信過(guò)時(shí)延也只有100毫秒，是TCP+TLS用時(shí)的1/3）。此外，QUIC還增加了擁塞控制和自動(dòng)重傳等功能，所以可靠性上要比UDP更高。
從目標(biāo)來(lái)看，QUIC跟SPDY（HTTP/2基礎(chǔ)）很多方面是類(lèi)似的，但是后者仍然基于TCP，所以仍然會(huì)存在部分相同的時(shí)延問(wèn)題。
不過(guò)這樣也許你會(huì)問(wèn)為什么Google不干脆改進(jìn)TCP？根據(jù)Google的解釋?zhuān)贿@么做的原因是TCP往往直接內(nèi)置到了操作系統(tǒng)內(nèi)核當(dāng)中，這是Google所無(wú)法控制的。所以他們就拿UDP改良版來(lái)開(kāi)刀，以期更快地測(cè)試性能改進(jìn)效果。
Google從去年開(kāi)始就已經(jīng)在Chrome瀏覽器上進(jìn)行了實(shí)驗(yàn)，實(shí)際上目前Chrome到Google服務(wù)器的請(qǐng)求當(dāng)中大概有一半已經(jīng)在采用QUIC協(xié)議。數(shù)據(jù)表明75%的連接均可利用QUIC的優(yōu)勢(shì)，哪怕預(yù)先建立的優(yōu)化連接（Google搜索）采用QUIC后頁(yè)面加載性能仍然能提高3個(gè)百分點(diǎn)。而時(shí)延嚴(yán)重的一些web應(yīng)用，在采用QUIC后的改進(jìn)效果則要更加明顯。比如有用戶(hù)報(bào)告YouTube重新緩沖次數(shù)減少了30%。
Google希望QUIC的性能得當(dāng)證明后能夠移植到TCP和TLS上面，稱(chēng)未來(lái)打算將HTTP2-over-QUIC作為新的協(xié)議提交給IETF。但是這顯然需要與IETF的配合以及長(zhǎng)期努力。這一套路跟SPDY很像，都是以Chrome為跳板展現(xiàn)協(xié)議原型和效果，然后再提出作為協(xié)議草案，但結(jié)果尚待觀(guān)察。
聯(lián)系客服
