瀏覽器中常見網絡協議介紹

上週五我在公司有一個關於《HTTP 協議》的培訓，只有兩個小時，估計能講到的東西不會太多。實際上，瀏覽器爲了完成 WEB 應用的各項功能，須要跟各類網絡協議打交道，HTTP 只是其中一種。本文會介紹瀏覽器中常見的網絡協議，以及各類協議之間的關係。

咱們常常會聽到「TCP/IP 協議」這個名詞，從字面上看，有人會認爲它專指 TCP 和 IP 兩種協議。實際上大多數狀況，TCP/IP 協議指的是整個網際協議族（Internet Protocol Suite），是利用 IP 協議進行通信的其餘協議統稱。TCP/IP 包含的協議衆多，還有一個分層模型。相比較 OSI 模型，TCP/IP 的分層更簡單，從下到上分別爲：物理層、數據鏈路層、網絡層、傳輸層和應用層。

IP（Internet Protocol）屬於網絡層協議，負責聯網主機之間的路由選擇和尋址。IPv4 中的 4 指的是 TCP/IP 協議的第 4 個版本，直到這個版本，IP 協議才單獨拆出來，因此並無單獨的 IPv1 - IPv3。而 IPv5 分給了一個沒什麼進展的試驗性協議，因此下一個版本的 IP 協議變成了 IPv6。

TCP（Transmission Control Protocol）和 UDP（User Datagram Protocol）是整個 TCP/IP 協議中最重要的兩個傳輸層協議。TCP 是面向鏈接的、可靠的流協議；UDP 是不具備可靠性的數據報協議。後面能夠看到，對可靠性要求比較高的上層協議通常會基於 TCP；而對高速傳輸和實時性有較高要求的上層協議通常會基於 UDP。

介紹完比較低層的 IP、TCP 和 UDP 以後，下面看幾個瀏覽器中常見的應用層協議。

HTTP 與 WebSocket

HTTP 協議是瀏覽器須要用到的最重要的網絡協議，它包括不少版本，例如最多見的 HTTP/1.1，剛剛發佈的 HTTP/2，還有 Google 實現的過渡版本 SPDY 等等。本文不討論 HTTP 的細節以及各版本之間的差別，只打算列出 HTTP 與其餘協議 / 應用之間的關係，見下圖：

+-------------+-------------+--------------+
|     XHR     |     SSE     |      WS      |
+-------------+-------------+------+       +
|               HTTP               |       |
+----------------------------------+-------+
|                    TLS *                 |
+------------------------------------------+
|                    TCP                   |
+------------------------------------------+
|                    IP                    |
+------------------------------------------+

從上圖能夠看出 HTTP 是在 TCP 之上實現的，因此 HTTP 中並不須要關注數據傳輸的可靠性，相似於順序控制、重發這樣的機制在傳輸層已經有了。同時，HTTP 也擁有 TCP 的一些缺點，給 WEB 性能優化帶來挑戰。

XHR（XmlHTTPRequest）和 SSE（Server-Sent Events）都是瀏覽器提供的數據交互功能，它們的本質都仍是 HTTP。XHR 是 Ajax 技術的核心，你們都很熟，這裏略過不討論；SSE 概念還算新，多說幾句。咱們知道 HTTP 只能由客戶端發起請求，再由服務端響應。SSE 也是這樣，只不過服務端會保持住這個 HTTP 鏈接，屢次發送響應，不像平時發送完響應就結束了。實際上，很早以前在 WebIM 中相似的 HTTP 長鏈接技術就已經很盛行了，有興趣的同窗能夠看下這篇八年前的文章：Comet：基於 HTTP 長鏈接的「服務器推」技術。

既然 XHR 和 SSE 本質都是 HTTP 鏈接，因此 HTTP 協議中一些常見概念，例如請求方式（GET、POST 等），請求響應頭部（Cookie、內容編碼、傳輸編碼、緩存等）等等，依然存在。

而 WS（WebSocket）是直接基於 TCP 實現的，HTTP 協議中的那些概念都不復存在。須要注意的是，從前面圖表中能夠看出，它仍是依賴於 HTTP，這是由於 WebSocket 握手利用了 HTTP 的 Upgrade 機制。一旦握手完成，後續數據傳輸就直接在 TCP 上完成。瀏覽器中新協議藉助 HTTP 做爲引導，是一個較爲廣泛的作法。

TLS（Transport Layer Security，傳輸層安全），做用是保證數據在傳輸過程當中的完整性和保密性，屬於可選項。啓用了 TLS 以後，HTTP 協議的 URL 前綴須要由 http:// 改爲 https://；WebSocket 協議的 URL 前綴須要由 ws:// 改爲 wss://。

DNS

DNS（Domain Name System），就是你們熟知的域名解析服務，提供了從域名到 IP 的轉換。瀏覽器中大部分網絡交互都會使用域名，而傳輸層協議須要的是 IP，因此 DNS 是基礎。

+-------------------------------+
|              DNS              |
+-------------------------------+
|      TCP      |      UDP      |
+---------------+---------------+
|               IP              |
+-------------------------------+

DNS 服務默認使用 UDP 協議得到查詢結果，一般僅當結果超過 512 字節或者進行 DNS 服務器同步時纔會使用 TCP 協議。這是由於 DNS 的使用很是頻繁，又是基礎，響應速度是優先須要考慮的。使用 UDP 能夠知足速度上的要求，但同時也引入了相似於「DNS 緩存投毒」這類問題。

WebRTC

WebRTC（Web Real-Time Communication）出現以前，DNS 幾乎是瀏覽器惟一使用的基於 UDP 的協議。WebRTC 提供的三大功能中，MediaStream 與網絡無關，RTCPeerConnection 和 RTCDataChannel 都是基於 UDP，如圖：

+-----------------------+-------------------------+
|   RTCPeerConnection   |      RTCDataChannel     |
+-----------------------+-------------------------+
|          SRTP         |           SCTP          |
+             +---------+-------------------------+
|             |                DTLS               |
+-------------+-----------------------------------+
|                ICE, STUN, TURN                  |
+-------------------------------------------------+
|                       UDP                       |
+-------------------------------------------------+
|                       IP                        |
+-------------------------------------------------+

這個圖比較複雜，咱們從下往上介紹：

ICE（Interactive Connectivity Establishment）框架，做用是在端與端之間創建一條有效的通道，優先直連，其次用 STUN 協商，再不行只能用 TURN 轉發：

• STUN（Session Traversal Utilities for NAT）協議，解決了三個問題：1）得到外網 IP 和端口；2）在 NAT 中創建路由條目，綁定外網端口，使獲得達外網 IP 和端口的入站分組能找到應用程序，不被丟棄；3）定義了一個簡單的 keep-alive 機制，保證 NAT 路由條目不會由於超時而被刪除。STUN 服務器必須架設在公網上，能夠本身搭建，也可使用第三方提供的公開服務，例如 Google 的「stun:stun.l.google.com:19302」。
• TURN（Traversal Using Relays around NAT）協議，依賴外網中繼設備在兩端之間傳遞數據。簡單說就是經過兩端均可以訪問的 TURN 服務轉發消息，間接把兩端連起來。

DTLS（Datagram Transport Layer Security，數據報傳輸層安全），本質上就是 TLS，只是爲了兼容 UDP 的數據報傳輸而作了一些微小的修改，能夠簡單把它理解爲 UDP 版的 TLS。

再往上就兵分兩路，一路的目標是 RTCPeerConnection，負責音頻和視頻數據通訊，對傳輸速度和實時性有很高的要求，這裏又有兩個新的協議出現：

• SRTP（Secure Real-time Transport Protocol，安全實時傳輸協議）。WebRTC 中的音頻和視頻等實時數據都是經過這個協議傳輸。它是 RTP 協議的安全版。
• SRTCP（Secure Real-Time Control Transport Protocol，安全實時控制傳輸協議）。它會跟蹤 SRTP 的運行狀況，以便調整每一個流的發送速率、編碼品質和其餘參數。它是 RTCP 協議的安全版。

另外一路的目標是 RTCDataChannel，用來在端到端之間傳輸任意應用數據，SRTP 是專門爲傳輸媒體數據爲設計的，不適合傳輸應用數據，因此這裏又須要一個新的協議：

• SCTP（Stream Control Transmission Protocol，流控制傳輸協議）。自己 SCTP 是一個傳輸層協議，直接運行在 IP 協議之上，與 TCP 和 UDP 相似。但在 WebRTC 這裏，SCTP 卻運行於 DTLS 之上。SCTP 很好的一點是提供了交付屬性選項，使用者能夠指定消息是有序仍是亂序，是可靠仍是部分可靠，部分可靠時還能夠指定使用超時重傳仍是計數重傳策略。

QUIC

Google 正在試驗一種新的傳輸層協議：QUIC（Quick UDP Internet Connections），它的本質是基於 UDP 實現 HTTP，至關於以前的 TCP + TLS。從目前的資料來看，QUIC 能夠大幅減小創建鏈接的時間，這是經過簡化握手步驟從而減小 RTT（Round-Trip Time）來實現的，相似於 TFO（TCP Fast Open）。有興趣的同窗能夠點這個鏈接圍觀，聽說 Google 自家服務來自 Chrome 的請求中，已經有 50% 使用了 QUIC 協議。

最後表達下對 Google 的佩服。Google 爲了優化 WEB 性能，在瀏覽器（Chrome）、排版引擎（Blink）、JS 引擎（V8）、圖片格式（WebP）、傳輸層協議（TCP 的 TFO，QUIC）、應用層協議（SPDY）以及 HTML5（從 Google Gears 開始）等等方面都作了大量努力，實在是技術型公司典範，歎爲觀止！