HTTP學習筆記。

HTTP簡介

HTTP協議是Hyper Text Transfer Protocol（超文本傳輸協議）的縮寫，是用於從萬維網服務器傳輸超文本到本地瀏覽器的傳輸協議。
HTTP是一個基於TCP/IP通訊協議來傳遞數據（HTML文件，圖片文件，查詢結果等）。

HTTP工做原理

HTTP協議工做於客戶端-服務端架構上。瀏覽器做爲HTTP客戶端經過URL向HTTP服務端發送全部的請求。
Web服務器：Apache服務器，IIS服務器等。
Web服務器根據接收的請求後，向客戶端發送響應信息。
HTTP默認端口號爲80，可是你也能夠改成8080或者其它端口。
HTTP三點注意事項：

*HTTP是無鏈接的：無鏈接的含義是限制每次鏈接只處理一次請求。服務器處理完客戶請求，並收到客戶的應答後，即斷開鏈接。採用這種方式能夠節省傳輸時間。
*HTTP是媒體獨立的：這意味着，只要客戶端和服務器知道如何處理的數據內容，任何類型的數據均可以經過HTTP發送。客戶端以及服務器指定使用適合的MIME-type內容類型。
*HTTP是無狀態：HTTP協議是無狀態協議。無狀態是指協議對於事務處理沒有記憶能力。缺乏狀態意味着若是後續處理須要前面的信息，則它必須重傳，這樣可能致使每次鏈接傳送的數據量增大。另外一方面，在服務器不須要先前信息時它的應答就較快。

如下圖表展現了HTTP協議通訊流程：

HTTP消息結構

HTTP是基於客戶端/服務端的架構模型，經過一個可靠的連接來交換信息，是一個無狀態的請求/響應協議。
一個HTTP客戶端是一個應用程序（Web瀏覽器或其它任何客戶端），經過鏈接到服務器達到向服務器發送一個或多個HTTP的請求的目的。
一個HTTP服務器一樣也是一個應用程序（一般是一個Web服務，如Apache Web服務器等），經過接收客戶端的請求並向客戶端發送HTTP響應數據。
HTTP使用統一資源標識符來傳輸數據和創建鏈接。一旦創建鏈接後，據消息就經過相似Internet郵件所使用的格式[RFC5322]和多用途Internet郵件擴展（MIME）[RFC2045]來傳送。

客戶端請求消息

客戶端發送一個HTTP請求到服務器的請求消息包括如下格式：請求行（request line）、請求頭部（header）、空行和請求數據四個部分組成。

服務器響應信息

HTTP響應也由四個部分組成，分別是：狀態行、消息報頭、空行和響應正文。

HTTP請求方法

根據HTTP標準，HTTP請求可使用多種請求方法。
HTTP1.0定義了三種請求方法：GET，POST，和HEAD方法。
HTTP1.1新增了五種請求方法：OPTIONS,PUT,DELETE,TRACE和CONNECT方法。

HTTP響應頭信息

HTTP請求頭提供了關於請求，響應或者其它的發送實體的信息。

HTTP狀態碼

當瀏覽者訪問一個網頁時，瀏覽者的瀏覽器會向網頁所在服務器發出請求。當瀏覽器接收並顯示網頁前，此網頁所在的服務器會返回一個包含HTTP狀態碼的信息頭用以響應瀏覽器的請求。
下面是常見的HTTP狀態碼：

200：請求成功。
301：資源(網頁等)被永久轉移到其它URL。
404：請求的資源（網頁等）不存在。
500：內部服務器錯誤。

HTTP狀態碼分類

HTTP狀態碼由三個十進制數字組成，第一個十進制數字定義了狀態碼的類型，後兩個數字沒有分類的做用。HTTP狀態碼共分爲5種類型：

HTTP content-type

Content-Type，內容類型，通常是指網頁中存在的Content-Type，用於定義網絡文件的類型和王爺編碼，決定瀏覽器將以什麼形式、什麼編碼讀取這個文件，這就是常常看到一些Asp網頁點擊的結果卻不是下載到一個文件或一張圖片的緣由。

HTTP協議：持久鏈接、非持久鏈接

定義：

非持久鏈接：每一個鏈接處理一個請求-響應事務，每次交互都要打開關閉鏈接。
持久鏈接：每一個鏈接能夠處理多個請求-響應事務，第一次交互會打開鏈接，交互結束後鏈接並不關閉，下次交互就省去了創建鏈接的過程。
持久鏈接狀況下，服務器發出響應後讓TCP鏈接繼續打開着。同一對客戶/服務器之間的後續請求和響應能夠經過這個鏈接發送。
HTTP1.0使用非持久鏈接。 HTTP1.1默認使用持久鏈接。
持久鏈接的實現有兩種：HTTP/1.0+的keep-alive與HTTP/1.1的持久鏈接。

非持久鏈接示例：

非持久鏈接下，客戶端請求一個頁面。假設該頁面包含1個html文件和10個JPEG圖像，全部這些對象在同一臺服務器主機中。再假設該節本HTML文件的URL：www.yesky.com/sompath/index.html。
1.HTTP客戶端與服務器主機www.yesky.com中的HTTP服務器創建一個TCP鏈接。
2.HTTP客戶端發送HTTP請求消息。包含/sompath/index.html。
3.HTTP服務器接收請求消息，從服務器主機內存或硬盤拿去除對象/sompath/index.html，發出該對象的響應消息。
4.HTTP服務器告知TCP關閉這個TCP鏈接（TCP要等客戶收到這個響應消息後，纔會真正終止這個鏈接）。
5.HTTP客戶端接收響應消息。TCP鏈接終止。該消息標明所拆裝的對象是一個HTML文件。客戶取出文件，分析後發現10個JPEG對象的引用。
6.給每個引用到的JPEG對象重複步驟1——4.

HTTP協議中TCP的三次握手和四次揮手

CLOSED：表示初始狀態。
LISTEN: 服務器端的某個SOCKET處於監聽狀態，能夠接受鏈接了。
SYN_SENT：表示客戶端已發送 SYN 報文。
SYN_RCVD：表示服務器接受到了 SYN 報文。
ESTABLISHED：表示鏈接已經創建。
ACK 確認字段：在鏈接創建後全部傳送的報文段 ACK 必須爲 1 。
SYN 同步字段：鏈接創建時使用同步序號。
FIN 終止字段：FIN = 1 是表示釋放一個鏈接。
序號 seq ：發送了多少被成功接受數據。
確認號 ack：接受了多少數據。
注意：

ACK = 1 不攜帶數據不消耗序號。
 SYN = 1 不能攜帶數據而且要消耗一個序號。

第一次握手：創建鏈接時，客戶端發送syn包(syn=j)到服務器，並進入SYN_SEND狀態，等待服務器確認；
第二次握手：服務器收到syn包，必須確認客戶的SYN（ack=j+1），同時本身也發送一個SYN包（syn=k），即SYN+ACK包，此時服務器進入SYN_RECV狀態；
第三次握手：客戶端收到服務器的SYN＋ACK包，向服務器發送確認包ACK(ack=k+1)，此包發送完畢，客戶端和服務器進入ESTABLISHED狀態，完成三次握手。 完成三次握手，客戶端與服務器開始傳送數據.

那麼如何斷開鏈接呢？過程以下：（中斷鏈接的能夠是Client端，也能夠是Sever端）

FIN_WAIT_1：表示等待對方的FIN報文。當SOCKET在ESTABLISHED狀態時，它想主動關閉鏈接，向對方發送了FIN報文，此時該SOCKET進入到FIN_WAIT_1 狀態
FIN_WAIT_2：也表示等待對方的FIN報文。FIN_WAIT_2狀態下的SOCKET，表示半鏈接，也即有一方要求close鏈接，但另外還告訴對方，我暫時還有點數據須要傳送給你，稍後再關閉鏈接。
CLOSE_WAIT: 這種狀態的含義實際上是表示在等待關閉。你回覆一個ACK給對方，並進入CLOSE_WAIT狀態。接下來就是查看你是否還有數據要發送給對方，若是沒有，就能夠close這個socket，併發送FIN給對方，即關閉鏈接。
CLOSING：表示主機1給主機2發送FIN後，並無收到主機2迴應的ACK，而收到了主機2發送的FIN。表示雙方同時close一個socket，出現同時發送FIN現象。
LAST_ACK: 發送FIN報文後，等待對方的ACK報文，當收到ACK報文後，進入到CLOSED狀態。
TIME_WAIT: 表示收到了對方的FIN報文，併發送出了ACK確認，等2MSL後便可回到CLOSED可用狀態了。若是FIN_WAIT_1狀態下，收到了對方同時帶FIN標誌和ACK標誌的報文時，能夠直接進入到TIME_WAIT狀態。

第一次揮手：主機1向主機2，發送FIN報文段，表示關閉數據傳送，並主機1進入FIN_WAIT_1狀態，表示沒有數據要傳輸了
第二次揮手：主機2收到FIN報文段後進入CLOSE_WAIT狀態（被動關閉），而後發送ACK確認，表示贊成你關閉請求了，主機到主機的數據鏈路關閉，主機進入FIN_WAIT_2狀態
第三次揮手：主機2等待主機1發送完數據，發送FIN到主機1請求關閉，主機2進入LAST_ACK狀態
第四次揮手：主機1收到主機2發送的FIN後，回覆ACK確認到主機2，主機1進入TIME_WAIT狀態。主機2收到主機1的ACK後就關閉鏈接了，狀態爲CLOSED。主機1等待2MSL，仍然沒有收到主機2的回覆，說明主機2已經正常關閉了，主機1關閉鏈接。

爲何鏈接的時候是三次握手，關閉的時候倒是四次握手？由於當Server端收到Client端的SYN鏈接請求報文後，能夠直接發送SYN+ACK報文。其中ACK報文是用來應答的，SYN報文是用來同步的。可是關閉鏈接時，當Server端收到FIN報文時，極可能並不會當即關閉SOCKET，因此只能先回復一個ACK報文，告訴Client端，"你發的FIN報文我收到了"。只有等到我Server端全部的報文都發送完了，我才能發送FIN報文，所以不能一塊兒發送。故須要四步握手。