前戲

在之前的徵求意見中，覺得大家對網絡協議還是比較感興趣的。所以我就挑一個最常用的協議給大家講解下，本頭條號也有相關網絡協議系列 ，有興趣的童鞋可以自行查看。

HTTP特點

HTTP（HyperText Transfer Protocol，超文本傳輸協議），是一個應用層協議，雖然在2015年已推出HTTP/2版本，並被主要的web瀏覽器和web服務器支持。但目前使用最廣泛的還是HTTP/1.1版本。

它的主要特點可概括如下：

• 支持客戶/服務器模式。
• 簡單快速：客戶向服務器請求服務時，只需傳送請求方法和路徑。由於HTTP協議簡單，使得HTTP服務器的程序規模小，因而通信速度很快。
• 靈活：HTTP允許傳輸任意類型的數據對象。正在傳輸的類型由Content-Type加以標記。
• 無連接：無連接的含義是限制每次連接只處理一個請求。服務器處理完客戶的請求，並收到客戶的應答後，即斷開連接。採用這種方式可以節省傳輸時間。
• 無狀態：HTTP協議是無狀態協議。無狀態是指協議對於事務處理沒有記憶能力。缺少狀態意味著如果後續處理需要前面的信息，則它必須重傳，這樣可能導致每次連接傳送的數據量增大。另一方面，在服務器不需要先前信息時它的應答就較快。為了解決這個問題， Web程序引入了Cookie機制來維護狀態。

另外，HTTP請求報文和響應報文都是由開始行（對於請求消息，開始行就是請求行，對於響應消息，開始行就是狀態行），消息報頭（可選），空行（只有CRLF的行），消息正文（可選）組成。將在下面詳細講解。

1、請求報文結構

報文中的數據都使用ASCII編碼，各個字段的長度是不確定的（除了作為結尾的CRLF外，不允許出現單獨的CR或LF字符）。

2、請求報文樣例

3、請求報文參數詳解

請求方法

所有請求方法名稱全為大寫，目前有9種：

備註

安全性：https://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol

冪等性：表示的操作至多隻會被處理一次，每次調用都將返回第一次調用時的處理結果。

關於HTTP請求GET和POST的區別

• (1).提交形式：

GET提交的數據會放在URL之後，以?分割URL和傳輸數據，參數之間以&相連，如EditPosts.aspx?name=test1&id=123456. POST方法是把提交的數據放在HTTP包的Body中.

• (2).傳輸數據的大小：

HTTP協議本身沒有對傳輸的數據大小進行限制，HTTP協議規範也沒有對URL長度進行限制。 而在實際開發中存在的限制主要有：

GET:特定瀏覽器和服務器對URL長度有限制，例如IE對URL長度的限制是2083字節(2K+35)。對於其他瀏覽器，如Netscape、FireFox等，理論上沒有長度限制，其限制取決於操作系統的支持。

因此對於GET提交時，傳輸數據就會受到URL長度的限制。

POST:由於不是通過URL傳值，理論上數據不受限。但實際各個WEB服務器會規定對post提交數據大小進行限制，Apache、IIS6都有各自的配置。

• (3).安全性：

POST的安全性要比GET的安全性高，具有真正的Security的含義。而且通過GET提交數據，用戶名和密碼將明文出現在URL上，因為登錄頁面有可能被瀏覽器緩存，其他用戶瀏覽歷史紀錄就可以拿到賬號和密碼了。

請求報頭域

報頭域指頭部中的Key，且不分大小寫。

4、響應報文結構

如所見，響應報文結構與請求報文結構唯一真正的區別在於第一行中用狀態信息代替了請求信息。狀態行（status line）通過提供一個狀態碼來說明所請求的資源情況。

5、響應報文樣例

6、響應報文參數詳解

響應狀態碼

狀態代碼由三位數字組成，第一個數字定義了響應的類別，且有五種可能取值。

1xx：指示信息--表示請求已接收，繼續處理。

2xx：成功--表示請求已被成功接收、理解、接受。

3xx：重定向--要完成請求必須進行更進一步的操作。

4xx：客戶端錯誤--請求有語法錯誤或請求無法實現。

5xx：服務器端錯誤--服務器未能實現合法的請求。

常用狀態碼：

200 OK：成功返回狀態，對應，GET,PUT,PATCH,DELETE。

201 created - 成功創建。

302 Found：重定向，新的URL會在response中的Location中返回，瀏覽器將會使用新的URL發出新的Request。

例如在IE中輸入http://www.google.com. HTTP服務器會返回304， IE取到Response中Location header的新URL, 又重新發送了一 個 Request.

304 Not Modified：代表上次的文檔已經被緩存了， 還可以繼續使用。

400 bad request - 請求格式錯誤。

401 unauthorized - 未授權。

403 forbidden - 鑑權成功，但是該用戶沒有權限。

404 not found - 請求的資源不存在。

405 method not allowed - 該http方法不被允許。

410 gone - 這個url對應的資源現在不可用。

415 unsupported media type - 請求類型錯誤。

422 unprocessable entity - 校驗錯誤時用。

429 too many request - 請求過多。

500 Internal Server Error：服務器發生了不可預期的錯誤。

503 Server Unavailable：服務器當前不能處理客戶端的請求，一段時間後可能恢復正常。

其它狀態碼請查閱：https://en.wikipedia.org/wiki/List_of_HTTP_status_codes

響應報頭域

報頭域指頭部中的Key，且不分大小寫。

7、HTTP報文抓取工具

Wireshark、Fiddler、HttpWatch（需結合IE）、Telnet

Wireshark：

在顯示過濾器中填入表達式：http and ip.addr == 42.121.252.58 and tcp.port == 80 過濾出http的響應和請求流程

8、Session和Cookie

說到HTTP，就不得不提Session和Cookie。但嚴格來說，Session和Cookie並不是http協議的一部分。由於HTTP協議設計原則是無狀態的，但是近年來出現了種種需求，其中cookie的作用就是為了解決HTTP協議無狀態的缺陷所作出的努力。後來出現的session機制則是又一種在客戶端與服務器之間保持狀態的解決方案。 具體來說cookie機制採用的是在客戶端保持狀態的方案，而session機制採用的是在服務器端保持狀態的方案。同時我們也看到，由於採用服務器端保持狀態的方案在客戶端也需要保存一個標識，所以session機制可能需要藉助於cookie機制來達到保存標識的目的，但實際上它還有其他選擇。

Session

Session是可以存儲針對於某一個用戶的瀏覽器以及通過其當前窗口打開的任何窗口具有針對性的用戶信息存儲機制。

通常大家認為，只要關閉瀏覽器，session就消失，其實這是錯誤的理解。對session來說也是一樣的，除非程序通知服務器刪除一個session，否則服務器會一直保留。由於關閉瀏覽器不會導致session被刪除，迫使服務器為seesion設置了一個失效時間，當距離客戶端上一次使用session的時間超過這個失效時間時，服務器就可以認為客戶端已經停止了活動，才會把session刪除以節省存儲空間.

(1)第一次訪問某個web站點資源時，客戶端提交沒有帶SessionID的請求（請求報文頭沒有Cookie頭域信息）。

而web服務器會檢查是否有SessionID過來，沒有則創建SessionID，並根據web程序自身定義在請求哪個資源時添加屬於當前會話的信息（也可為空），這個信息列表以SessionID作為標識。然後將SessionID返回給客戶端（通過響應報文頭的Set-Cookie頭域）。

(2 )客戶端再次訪問同個web站點時，提交帶有SessionID的請求（通過Cookie頭域存儲SessionID）。由服務端判斷session是否失效，如果未失效，可查詢屬於當前會話的信息列表。如果失效，則創建新的session（產生新的SessionID），而原先的session（包含session帶的信息列表）則丟失，無法訪問。

Cookie

保存SessionID的方式可以採用Cookie，這樣在交互過程中瀏覽器可以自動的按照規則把這個SessionID發回給服務器。Cookie的命名方式類似於SessionID。有時Cookie被人為的禁止，所以出現了其他機制以便在Cookie被禁止時仍然能夠把SessionID傳遞迴服務器。這種技術叫做URL重寫，就是把SessionID直接附加在URL路徑的後面，附加方式也有兩種，一種是作為URL路徑的附加信息，表現形式為http://www.wantsoft.com/index.asp;jsessionid= ByOK3vjFD75aPnrF7C2HmdnV6QZcEbzWoWiBYEnLerjQ99zWpBng!-145788764 。

另一種是作為查詢字符串附加在URL後面，表現形式為http://www.wantsoft.com/index?js ... 99zWpBng!-145788764 。

在本頭條號的主頁置頂文章中有【文章分類】包含:

[數據庫系列]

[數據結構和算法系列]

[高級網絡編程篇系列]

[Linux系統篇系列]

[C++進階篇系列]

[C++基礎知識篇系列]

[協議篇系列]

[設計模式系列]

不要只收藏和轉發哦，點擊屏幕右上角的【關注】每天文章不落下。