那天和boss聊天，不經(jīng)意間提到了Meteor，然后聊到了WebSocket，然后就有了以下對(duì)話，不得不說，看問題的方式不同，看到的東西也會(huì)大不相同。

[[269579]]

A：Meteor是一個(gè)很新的開發(fā)框架，我覺得它設(shè)計(jì)得十分巧妙。

B：怎么個(gè)巧妙之處？

A：它的前后端全部使用JS，做到了真正的前后端統(tǒng)一；前端瀏覽器里存有一份后臺(tái)開放出來的數(shù)據(jù)庫的拷貝，快；使用WebSocket協(xié)議來做數(shù)據(jù)傳輸協(xié)議，來同步前后端的數(shù)據(jù)庫，實(shí)現(xiàn)了真正的實(shí)時(shí)同步。

B：哦？WebSocket是什么東西？真實(shí)時(shí)？那底層是不是還是輪訓(xùn)？和HTTP的長(zhǎng)連接有什么不同？

A：（開始心虛）它是一個(gè)新的基于TCP的應(yīng)用層協(xié)議，只需要一次連接，以后的數(shù)據(jù)不需要重新建立連接，可以直接發(fā)送，它是基于TCP的，屬于和HTTP相同的地位（呃，開始胡謅了），底層不是輪訓(xùn)，和長(zhǎng)連接的區(qū)別……這個(gè)就不清楚了。

B：它的傳輸過程大致是什么樣子的呢？

A：首先握手連接（又是胡謅），好像可以基于HTTP建立連接（之前用過Socket.io，即興胡謅），建立了連接之后就可以傳輸數(shù)據(jù)了，還包括斷掉之后重連等機(jī)制。

B：看起來和HTTP長(zhǎng)連接做的事情差不多嘛，好像就是一種基于HTTP和Socket的協(xié)議啊。

A：呃……（我還是回去看看書吧）

有時(shí)候看事情確實(shí)太流于表面，了解到了每個(gè)事物的大致輪廓，但不求甚解，和朋友聊天說出來也鮮有人會(huì)刨根問底，導(dǎo)致了很多基礎(chǔ)知識(shí)并不牢靠，于是回來大致把HTTP和WebSocket協(xié)議的RFC文檔（RFC2616 和 RFC6455），剛好對(duì)HTTP的傳輸過程一直有點(diǎn)模糊，這里把兩個(gè)協(xié)議的異同總結(jié)一下。

協(xié)議基礎(chǔ)

仔細(xì)去看這兩個(gè)協(xié)議，其實(shí)都非常簡(jiǎn)單，但任何一個(gè)事情想做到***都會(huì)慢慢地變得異常復(fù)雜，各種細(xì)節(jié)。這里只會(huì)簡(jiǎn)單地描述兩個(gè)協(xié)議的結(jié)構(gòu)，并不會(huì)深入到很深的細(xì)節(jié)之處，對(duì)于理解http已經(jīng)足夠了。

HTTP

HTTP的地址格式如下：

http_URL = "http:" "//" host [ ":" port ] [ abs_path [ "?" query ]]

協(xié)議和host不分大小寫

HTTP消息

一個(gè)HTTP消息可能是request或者response消息，兩種類型的消息都是由開始行（start-line），零個(gè)或多個(gè)header域，一個(gè)表示header域結(jié)束的空行（也就是，一個(gè)以CRLF為前綴的空行），一個(gè)可能為空的消息主體（message-body）。一個(gè)合格的HTTP客戶端不應(yīng)該在消息頭或者尾添加多余的CRLF，服務(wù)端也會(huì)忽略這些字符。

header的值不包括任何前導(dǎo)或后續(xù)的LWS（線性空白），線性空白可能會(huì)出現(xiàn)在域值（filed-value）的***個(gè)非空白字符之前或***一個(gè)非空白字符之后。前導(dǎo)或后續(xù)的LWS可能會(huì)被移除而不會(huì)改變域值的語意。任何出現(xiàn)在filed-content之間的LWS可能會(huì)被一個(gè)SP（空格）代替。header域的順序不重要，但建議把常用的header放在前邊（協(xié)議里這么說的）。

Request消息

RFC2616中這樣定義HTTP Request 消息：

Request = Request-Line 
          *(( general-header  
            | request-header（跟本次請(qǐng)求相關(guān)的一些header） 
            | entity-header ) CRLF)（跟本次請(qǐng)求相關(guān)的一些header） 
          CRLF 
          [ message-body ]  

一個(gè)HTTP的request消息以一個(gè)請(qǐng)求行開始，從第二行開始是header，接下來是一個(gè)空行，表示header結(jié)束，***是消息體。

請(qǐng)求行的定義如下：

//請(qǐng)求行的定義 
Request-Line = Method SP Request-URL SP HTTP-Version CRLF 
 
//方法的定義 
Method = "OPTIONS" | "GET" | "HEAD"  |"POST" |"PUT" |"DELETE" |"TRACE" |"CONNECT"  | extension-method 
 
//資源地址的定義 
Request-URI   ="*" | absoluteURI | abs_path | authotity（CONNECT） 

Request消息中使用的header可以是general-header或者request-header，request-header（后邊會(huì)講解）。其中有一個(gè)比較特殊的就是Host，Host會(huì)與reuqest Uri一起來作為Request消息的接收者判斷請(qǐng)求資源的條件，方法如下：

1. 如果Request-URI是絕對(duì)地址（absoluteURI），這時(shí)請(qǐng)求里的主機(jī)存在于Request-URI里。任何出現(xiàn)在請(qǐng)求里Host頭域值應(yīng)當(dāng)被忽略。
2. 假如Request-URI不是絕對(duì)地址（absoluteURI），并且請(qǐng)求包括一個(gè)Host頭域，則主機(jī)由該Host頭域值決定。
3. 假如由規(guī)則１或規(guī)則２定義的主機(jī)是一個(gè)無效的主機(jī)，則應(yīng)當(dāng)以一個(gè)400（錯(cuò)誤請(qǐng)求）錯(cuò)誤消息返回。

Response消息

響應(yīng)消息跟請(qǐng)求消息幾乎一模一樣，定義如下：

Response      = Status-Line               
                  *(( general-header         
                   | response-header        
                   | entity-header ) CRLF)   
                  CRLF 
                  [ message-body ]      

可以看到，除了header不使用request-header之外，只有***行不同，響應(yīng)消息的***行是狀態(tài)行，其中就包含大名鼎鼎的返回碼。

Status-Line的內(nèi)容首先是協(xié)議的版本號(hào)，然后跟著返回碼，***是解釋的內(nèi)容，它們之間各有一個(gè)空格分隔，行的末尾以一個(gè)回車換行符作為結(jié)束。定義如下：

Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF 

返回碼

返回碼是一個(gè)3位數(shù)，***位定義的返回碼的類別，總共有5個(gè)類別，它們是：

- 1xx: Informational - Request received, continuing process 
 
  - 2xx: Success - The action was successfully received, 
    understood, and accepted 
 
  - 3xx: Redirection - Further action must be taken in order to 
    complete the request 
 
  - 4xx: Client Error - The request contains bad syntax or cannot 
    be fulfilled 
 
  - 5xx: Server Error - The server failed to fulfill an apparently 
    valid request 

RFC2616中接著又給出了一系列返回碼的擴(kuò)展，這些都是我們平時(shí)會(huì)用到的，但是那些只是示例，HTTP1.1不強(qiáng)制通信各方遵守這些擴(kuò)展的返回碼，通信各方在返回碼的實(shí)現(xiàn)上只需要遵守以上邊定義的這5種類別的定義，意思就是，返回碼的***位要嚴(yán)格按照文檔中所述的來，其他的隨便定義。

任何人接收到一個(gè)不認(rèn)識(shí)的返回碼xyz，都可以把它當(dāng)做x00來對(duì)待。對(duì)于不認(rèn)識(shí)的返回碼的響應(yīng)消息，不可以緩存。

Header

RFC2616中定義了4種header類型，在通信各方都認(rèn)可的情況下，請(qǐng)求頭可以被擴(kuò)展的（可信的擴(kuò)展只能等到協(xié)議的版本更新），如果接收者收到了一個(gè)不認(rèn)識(shí)的請(qǐng)求頭，這個(gè)頭將會(huì)被當(dāng)做實(shí)體頭。4種頭類型如下：

1、通用頭（General Header Fields）：可用于request，也可用于response的頭，但不可作為實(shí)體頭，只能作為消息的頭。

general-header = Cache-Control            ; Section 14.9 
              | Connection               ; Section 14.10 
              | Date                     ; Section 14.18 
              | Pragma                   ; Section 14.32 
              | Trailer                  ; Section 14.40 
              | Transfer-Encoding        ; Section 14.41 
              | Upgrade                  ; Section 14.42 
              | Via                      ; Section 14.45 
              | Warning                  ; Section 14.46 

2、請(qǐng)求頭（Request Header Fields）：被請(qǐng)求發(fā)起端用來改變請(qǐng)求行為的頭。

request-header = Accept                   ; Section 14.1 
               | Accept-Charset           ; Section 14.2 
               | Accept-Encoding          ; Section 14.3 
               | Accept-Language          ; Section 14.4 
               | Authorization            ; Section 14.8 
               | Expect                   ; Section 14.20 
               | From                     ; Section 14.22 
               | Host                     ; Section 14.23 
               | If-Match                 ; Section 14.24 
               | If-Modified-Since        ; Section 14.25 
               | If-None-Match            ; Section 14.26 
               | If-Range                 ; Section 14.27 
               | If-Unmodified-Since      ; Section 14.28 
               | Max-Forwards             ; Section 14.31 
               | Proxy-Authorization      ; Section 14.34 
               | Range                    ; Section 14.35 
               | Referer                  ; Section 14.36 
               | TE                       ; Section 14.39 
               | User-Agent               ; Section 14.43 

3、響應(yīng)頭（Response Header Fields）：被服務(wù)器用來對(duì)資源進(jìn)行進(jìn)一步的說明。

response-header = Accept-Ranges           ; Section 14.5 
                | Age                     ; Section 14.6 
                | ETag                    ; Section 14.19 
                | Location                ; Section 14.30 
                | Proxy-Authenticate      ; Section 14.33 
                | Retry-After             ; Section 14.37 
                | Server                  ; Section 14.38 
                | Vary                    ; Section 14.44 
                | WWW-Authenticate        ; Section 14.47 

4、實(shí)體頭（Entity Header Fields）：如果消息帶有消息體，實(shí)體頭用來作為元信息；如果沒有消息體，就是為了描述請(qǐng)求的資源的信息。

entity-header  = Allow                    ; Section 14.7 
               | Content-Encoding         ; Section 14.11 
               | Content-Language         ; Section 14.12 
               | Content-Length           ; Section 14.13 
               | Content-Location         ; Section 14.14 
               | Content-MD5              ; Section 14.15 
               | Content-Range            ; Section 14.16 
               | Content-Type             ; Section 14.17 
               | Expires                  ; Section 14.21 
               | Last-Modified            ; Section 14.29 
               | extension-header 

消息體（Message Body）和實(shí)體主體（Entity Body）

如果有Transfer-Encoding頭，那么消息體解碼完了就是實(shí)體主體，如果沒有Transfer-Encoding頭，消息體就是實(shí)體主體。

message-body = entity-body 
               | <entity-body encoded as per Transfer-Encoding> 

在request消息中，消息頭中含有Content-Length或者Transfer-Encoding，標(biāo)識(shí)會(huì)有一個(gè)消息體跟在后邊。如果請(qǐng)求的方法不應(yīng)該含有消息體（如OPTION），那么request消息一定不能含有消息體，即使客戶端發(fā)送過去，服務(wù)器也不會(huì)讀取消息體。

在response消息中，是否存在消息體由請(qǐng)求方法和返回碼來共同決定。像1xx，204，304不會(huì)帶有消息體。

消息體的長(zhǎng)度

消息體長(zhǎng)度的確定有一下幾個(gè)規(guī)則，它們順序執(zhí)行：

1. 所有不應(yīng)該返回內(nèi)容的Response消息都不應(yīng)該帶有任何的消息體，消息會(huì)在***個(gè)空行就被認(rèn)為是終止了。
2. 如果消息頭含有Transfer-Encoding，且它的值不是identity，那么消息體的長(zhǎng)度會(huì)使用chunked方式解碼來確定，直到連接終止。
3. 如果消息頭中有Content-Length，那么它就代表了entity-length和transfer-length。如果同時(shí)含有Transfer-Encoding，則entity-length和transfer-length可能不會(huì)相等，那么Content-Length會(huì)被忽略。
4. 如果消息的媒體類型是multipart/byteranges，并且transfer-length也沒有指定，那么傳輸長(zhǎng)度由這個(gè)媒體自己定義。通常是收發(fā)雙發(fā)定義好了格式， HTTP1.1客戶端請(qǐng)求里如果出現(xiàn)Range頭域并且?guī)в卸鄠€(gè)字節(jié)范圍（byte-range）指示符，這就意味著客戶端能解析multipart/byteranges響應(yīng)。
5. 如果是Response消息，也可以由服務(wù)器來斷開連接，作為消息體結(jié)束。

從消息體中得到實(shí)體主體，它的類型由兩個(gè)header來定義，Content-Type和Content-Encoding（通常用來做壓縮）。如果有實(shí)體主體，則必須有Content-Type,如果沒有，接收方就需要猜測(cè)，猜不出來就是用application/octet-stream。

HTTP連接

HTTP1.1的連接默認(rèn)使用持續(xù)連接（persistent connection），持續(xù)連接指的是，有時(shí)是客戶端會(huì)需要在短時(shí)間內(nèi)向服務(wù)端請(qǐng)求大量的相關(guān)的資源，如果不是持續(xù)連接，那么每個(gè)資源都要建立一個(gè)新的連接，HTTP底層使用的是TCP，那么每次都要使用三次握手建立TCP連接，將造成極大的資源浪費(fèi)。

持續(xù)連接可以帶來很多的好處：

1. 使用更少的TCP連接，對(duì)通信各方的壓力更小。
2. 可以使用管道（pipeline）來傳輸信息，這樣請(qǐng)求方不需要等待結(jié)果就可以發(fā)送下一條信息，對(duì)于單個(gè)的TCP的使用更充分。
3. 流量更小
4. 順序請(qǐng)求的延時(shí)更小。
5. 不需要重新建立TCP連接就可以傳送error，關(guān)閉連接等信息。

HTTP1.1的服務(wù)器使用TCP的流量控制來控制HTTP的流量，HTTP1.1的客戶端在收到服務(wù)器連接中發(fā)過來的error信息，就要馬上關(guān)閉此鏈接。關(guān)于HTTP連接還有很多細(xì)節(jié)，之后再詳述。

WebSocket

只從RFC發(fā)布的時(shí)間看來，WebSocket要晚近很多，HTTP 1.1是1999年，WebSocket則是12年之后了。WebSocket協(xié)議的開篇就說，本協(xié)議的目的是為了解決基于瀏覽器的程序需要拉取資源時(shí)必須發(fā)起多個(gè)HTTP請(qǐng)求和長(zhǎng)時(shí)間的輪訓(xùn)的問題……而創(chuàng)建的。

待續(xù)

本來是打算在一篇文章里把HTTP和WebSocket兩個(gè)協(xié)議的大致細(xì)節(jié)理出來，然后進(jìn)行對(duì)比?？墒菍懼鴮懼桶l(fā)現(xiàn)篇幅可能會(huì)比較長(zhǎng)，讀起來就不那么友好了，那么剛好就再寫第二篇吧。第二篇里會(huì)將WebSocket的大致情況描述一下，然后和HTTP適用的場(chǎng)景進(jìn)行對(duì)比。