谷歌在對抗網路速度緩慢的鬥爭中開啟了新的篇章，大量使用了“QUIC”，這是一種新的實驗性傳輸協定（4 級），其加密程度相當於TLS/SSL，但速度更快。這並不是這家加州巨頭第一次想要推動網路發展。 2012年，他就已經提出了SPDY協議，它透過在單一 TCP 連線（也是第 4 級傳輸協定）上重複使用多個 Web 請求來最佳化連線。這減少了建立連線開始時客戶端和伺服器之間的往返次數（英文為「Round Trip」）。此機制已得到 IETF 的驗證，並將其整合到新標準中HTTP/2。
透過 QUIC，Google 希望更進一步，在之前已經聯繫過某個網站時，將往返次數減少到零：然後客戶端將能夠直接將資料傳送到伺服器，而無需浪費時間進行初步交換。事實上，QUIC 會假設第一次交換的參數（例如伺服器憑證或用戶端 IP 位址）保持不變，以便能夠立即發起連線。如果參數發生變化，QUIC將像第一次一樣執行完整的協定交換。但通常這不是必需的。
為了能夠在現實生活中與真實的互聯網用戶一起測試其實驗協議，Google 沒有依賴 TCP 來構建 QUIC，而是依賴 UDP，另一個 4 級傳輸協議（因此在其他地方得名：問尤克UDP我網際網路C連接）。該協定不如 TCP 完整，但有幾個優點。與 TCP 不同，UDP 並未直接整合到作業系統核心中，Google對此幾乎沒有影響力，而且新功能需要時間才能傳播。
其次，UDP像TCP一樣不會被防火牆和其他安全設備自動阻止。這也是為什麼谷歌從一開始就拒絕了從頭開始構建新協議的想法，該協議默認會被所有安全解決方案阻止……最後，為了彌補 UDP 在丟包管理和質量方面的缺點在服務控制方面，谷歌在這方面推出了自己的機制。“QUIC 使我們能夠測試和實驗新想法，並快速獲得結果”，編輯總結為文件。
谷歌沒有浪費時間。第一次使用 QUIC 可以追溯到 2013 年中期。此後，該協議已整合到 Chrome 瀏覽器中，並在其許多伺服器上啟動。“現在大約有一半的 Chrome 客戶端對 Google 伺服器的請求是透過 QUIC 發出的”，宣布供應商。在效能方面，使用者最多可以節省一秒鐘的時間來顯示 Google 搜尋頁面。在 YouTube 上，影片資料緩衝將減少 30%。
谷歌顯然希望其新協議得到更廣泛的採用，並打算將其提交給IETF。
來源 ：部落格筆記來自Google
