深度理解HTTP請求報文和HTTP響應報文
HTTP請求報文和HTTP響應報文
HTTP協議簡介
超文字傳輸協議（英文：Hyper Text Transfer Protocol，縮寫：HTTP）是網際網路上應用最為廣泛的一種網路協議。設計HTTP最初的目的是為了提供一種釋出和接收HTML頁面的方法。通過HTTP協議請求的資源由統一資源識別符號（Uniform Resource Identifiers，URI）來標識。
HTTP報文是面向文字的，報文中的每一個欄位都是一些ASCII碼串，各個欄位的長度是不確定的。HTTP有兩類報文：請求報文和響應報文。
HTTPS（Hypertext Transfer Protocol over Secure Socket Layer）簡單講是HTTP的安全版，在HTTP下加入SSL層
SSL（Secure Sockets Layer 安全套接層）主要用於Web的安全傳輸協議，在傳輸層對網路連線進行加密，保障在Internet上資料傳輸的安全。
OSI網路模型 TCP/IP協議族
HTTP是一個應用層協議，由請求和響應構成，是一個標準的客戶端伺服器模型。HTTP是基於TCP/IP的短連線，無狀態的協議。HTTP假定其下層協議提供可靠的傳輸。因此也就是其在TCP/IP協議族使用TCP作為其傳輸層。
如圖為我們常說的tcp/ip協議棧。Internet四層網路模型（也叫TCP/IP四層模型）包括資料鏈路層(網路介面)、網路層、傳輸層和應用層。
HTTP協議的主要特點可概括如下：
簡單：客戶向伺服器請求服務時，只需傳送請求方法和路徑。請求方法常用的有GET、POST、PUT。每種方法規定了客戶與伺服器聯絡的不同型別。 由於HTTP協議簡單，使得HTTP伺服器的程式規模小，因而通訊速度很快。
靈活：HTTP允許傳輸任意型別的資料物件。正在傳輸的型別由Content-Type加以標記。
請求-響應模式：客戶端每次向伺服器發起一個請求時都建立一個連線， 伺服器處理完客戶端的請求即斷開連線。
無狀態：HTTP協議是無狀態協議。無狀態是指協議對於事務處理沒有記憶能力。缺少狀態意味著如果後續處理需要前面的資訊，則它必須重傳，這樣可能導致每次連線傳送的資料量增大。
建立TCP連線需要三次握手:
（1）客戶端傳送一個帶SYN標誌的TCP報文到伺服器。這是三次握手過程中的報文1。
（2） 伺服器端迴應客戶端的，這是三次握手中的第2個報文，這個報文同時帶ACK標誌和SYN標誌。因此它表示對剛才客戶端SYN報文的迴應；同時又標誌SYN給客戶端，詢問客戶端是否準備好進行資料通訊。
（3） 客戶端必須再次迴應服務段一個ACK報文，這是報文段3。
關閉連線需要四次分手:(先關讀,再關寫)
(1) TCP客戶端傳送一個FIN，用來關閉客戶到伺服器的資料傳送（報文段1）。
（2） 伺服器收到這個FIN，它發回一個ACK，確認序號為收到的序號加1（報文段2）。和SYN一樣，一個FIN將佔用一個序號。
（3） 伺服器關閉客戶端的連線，傳送一個FIN給客戶端（報文段3）。
（4） 客戶段發回ACK報文確認，並將確認序號設定為收到序號加1（報文段4）。
HTTP工作流程
HTTP，是符合C/S模型的，總是Client端來發起請求。
1、客戶機（瀏覽器）主動向伺服器（web server)發出連線請求。
2、伺服器接受連線請求並建立起連線。 (1,2步即我們所熟知的TCP三次握手)
3、客戶機通過此連線向伺服器發出GET等http命令，(“HTTP請求報文”)。
4、伺服器接到命令並根據命令向客戶機傳送相應的資料，(“HTTP響應報文”)。
5、客戶機接收從伺服器送過來的資料。
6、伺服器傳送完資料後，主動關閉此次連線。 （”TCP四次分手“）。
概況起來就是 客戶/伺服器傳輸過程可分為四個基本步驟：
1) 瀏覽器與伺服器建立連線； (TCP三次握手)
2) 瀏覽器向伺服器請求文件；
3) 伺服器響應瀏覽器請求；
4) 斷開連線。（”TCP四次分手“）
HTTP協議的URL,URI介紹
HTTP協議中的URL(URL是一種特殊型別的URI（Uniform Resource Identifier），包含了用於查詢某個資源的足夠的資訊)
主要是用於定位伺服器端資源的位置。我們來看下它的語法定義：
http://host[:port][path]
其中：
http:// 表示我們要使用HTTP協議；
host 表示一個可用的域名或IP地址；
port 為可選，表示要請求的埠號，預設情況下為80
path 為可選，表示要請求的資源所在的路徑（也叫URI），預設情況下為/ ,如果URL中沒有給出path，那麼當它作為請求URI時，
必須以“/”的形式給出，比如瀏覽器中輸入： www.abc.edu.cn 則瀏覽器自動換成 www.abc.edu.cn/ 。
- HTTP請求報文
一個HTTP請求報文由請求行（request line）、請求頭部（header）、空行和請求資料4個部分組成，下圖給出了請求報文的一般格式。
報文由三個部分組成: 開始行,首部行和實體主體.在請求報文中,開始行就是請求行
GET index.html / HTTP/1.1
Host:"www.baidu.com"
User-Agent:"Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Firefox/52.0"
Connection: Keep-Alive
POST index.html / HTTP/1.1
Host:"www.baidu.com"
User-Agent:"Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Firefox/52.0"
Connection: Keep-Alive
Pn=2&kw=nba
1.請求行
請求行由請求方法欄位、URL欄位和HTTP協議版本欄位3個欄位組成，它們用空格分隔。例如，GET /index.html HTTP/1.1。
HTTP協議的請求方法有GET、POST、HEAD、PUT、DELETE、OPTIONS、TRACE、CONNECT。
2.請求頭部
請求頭部由鍵/值對組成，每行一對，鍵和值用英文冒號“:”分隔。請求頭部通知伺服器有關於客戶端請求的資訊
典型的常用請求頭有：
User-Agent：產生請求的客戶端型別。
Accept：客戶端可識別的內容型別列表。
Host：請求的主機名，允許多個域名同處一個IP地址，即虛擬主機。
Accept-Encoding： 客戶端使用的編碼環境和編碼方式
Accept-Language： 客戶端語言環境
Authorization：授權資訊，一般用於存放授權之後的資訊
Connection：表示是否需要持久連線
Content-Length：表示請求資料正文的長度
Cookie：這個與伺服器端做互動的，儲存保持會話的重要資訊 Referer：表示該次請求的來源，一般用於做防盜鏈
HTTP 請求方法概述：
GET: 請求讀取由URL所標識的資訊
POST: 給伺服器傳送資料
HEAD: 請求讀取由URL所有標識的資訊的首部
PUT: 在指明的URL下儲存一個文件
OPTION: 請求一些選項的資訊
DELETE: 刪除指明的URL所標識的資源
TRACE: 用來進行環回測試的請求報文
CONNECT: 用於代理伺服器
- 換行符
最後一個請求頭之後是一個空行，傳送回車符和換行符，通知伺服器以下不再有請求頭。
- 請求資料
請求資料不在GET方法中使用，而是在POST方法中使用。POST方法適用於需要客戶填寫表單的場合。與請求資料相關的最常使用的請求頭是Content-Type和Content-Length。
2.HTTP響應報文
HTTP響應也由四個部分組成，分別是：狀態行、響應頭、空格、響應資料。
如下所示，HTTP響應的格式與請求的格式十分類似
響應報文的開始是狀態行,包括三項內容: HTTP版本,狀態碼,解釋狀態碼的簡單短語
在響應中唯一真正的區別在於第一行中用狀態資訊代替了請求資訊。狀態行（status line）通過提供一個狀態碼來說明所請求的資源情況。
狀態行格式如下：
HTTP-Version Status-Code Reason-Phrase CRLF
其中，HTTP-Version表示伺服器HTTP協議的版本；Status-Code表示伺服器發回的響應狀態程式碼；Reason-Phrase表示狀態程式碼的文字描述。狀態程式碼由三位數字組成，第一個數字定義了響應的類別，且有五種可能取值。
•• 1xx：指示資訊--表示請求已接收，繼續處理。
•• 2xx：成功--表示請求已被成功接收、理解、接受。
•• 3xx：重定向--要完成請求必須進行更進一步的操作。
•• 4xx：客戶端錯誤--請求有語法錯誤或請求無法實現。
•• 5xx：伺服器端錯誤--伺服器未能實現合法的請求。
常見狀態程式碼、狀態描述的說明如下。
•• 200 OK：客戶端請求成功。
•• 301 Moved Permanently：客戶端啊，你要請求的資源已經永久的搬家了，我把他的新地址放到了Location頭部域中了；
••302 Moved Temporarily：客戶端啊，你要請求的資源臨時有事去別的地方了，我把他的位置放到了Location頭部域中了，你可以先去那裡找他，不過他應該是會回到他自己的家的；
••304 Not Modified：客戶端啊，你要請求的資源自從上次你請求之後，就再也沒有改動過，我想你是應該早就有這個資源了，所以在響應報文的資料部分我也沒有再放這個資源。
•• 400 Bad Request：客戶端請求有語法錯誤，不能被伺服器所理解。
•• 401 Unauthorized：請求未經授權，這個狀態程式碼必須和WWW-Authenticate報頭域一起使用。
•• 403 Forbidden：伺服器端順利收到了客戶端的請求，但是因為某些理由，伺服器端拒絕為他提供服務
•• 404 Not Found：請求資源不存在，八成是資源地址寫錯了；舉個例子：輸入了錯誤的URL。
•• 500 Internal Server Error：伺服器發生不可預期的錯誤。
•• 502 Bad Gateway：客戶端你好，我是請求報文的代理伺服器，持有資源的那個伺服器在給我傳送資源時出問題了；
•• 503 Server Unavailable：伺服器當前不能處理客戶端的請求，一段時間後可能恢復正常
HTTP常見問題
HTTP協議是無狀態的和Connection: keep-alive的區別
無狀態是指協議對於事務處理沒有記憶能力，伺服器不知道客戶端是什麼狀態。從另一方面講，開啟一個伺服器上的網頁和你之前開啟這個伺服器上的網頁之間沒有任何聯絡。HTTP是一個無狀態的面向連線的協議，無狀態不代表HTTP不能保持TCP連線，更不能代表HTTP使用的是UDP協議。
從HTTP/1.1起，預設都開啟了Keep-Alive，保持連線特性，簡單地說，當一個網頁開啟完成後，客戶端和伺服器之間用於傳輸HTTP資料的TCP連線不會關閉，
如果客戶端再次訪問這個伺服器上的網頁，會繼續使用這一條已經建立的連線。Keep-Alive不會永久保持連線，它有一個保持時間，可以在不同的伺服器軟體（如Apache、GlassFish）中設定這個時間。
TCP (打電話)是長連線 穩定 TCP連線的建立需要三次握手
UDP (寫信)無連線 不穩定 使用者資料報協議，是一個面向無連線的協議。採用該協議不需要兩個應用程式先建立連線。UDP協議不提供差錯恢復，不能提供資料重傳，因此該協議傳輸資料安全性差
HTTP 是短連線
GET 引數追加在URL後 長度受限制 不安全
POST 引數在請求報文的請求資料部分 引數長度比GET長 安全
常用的HTTP請求方法如下：
1.GET請求
當客戶端想從伺服器讀取文件時，點選網頁上的超連結或者在瀏覽器輸入框內輸入地址按回車時，都是傳送的GET請求，伺服器根據請求的地址從資原始檔中找到客戶端想要的資原始檔，放在響應報文中的相應資料部分回送給客戶端
使用GET請求需要將請求引數放在url之後，以?分割網址與引數，多個引數用&符號連結，例如https://www.baidu.com/?tn=monline_3_dg&pn=1 ?問號前表示請求地址，?後表示請求引數,&用來連線多個請求引數，這種請求方式對URL長度有限制，一般最多隻能識別1024個字元，所以如果需要傳輸大量資料，也不適合使用GET請求，並且GET請求會把引數值直接暴露在URL地址中，不適合傳輸私密資料。
- POST請求
對於上面提到的不適合使用GET方式的情況，可以考慮使用POST方式，因為使用POST方法可以允許客戶端給伺服器提供資訊較多。POST方法將請求引數封裝在HTTP請求資料中，以名稱/值的形式出現，可以傳輸大量資料，這樣POST方式對傳送的資料大小沒有限制，而且也不會顯示在URL中。如果使用POST方式的話，格式如下：
POST /search HTTP/1.1
Accept: image/gif, image/x-xbitmap
Connection: Keep-Alive
.......
username=zhangsan&password=123
可以看到，POST方式請求行中不包含資料字串，這些資料儲存在”請求內容”部分，各資料之間也是使用”&”符號隔開。POST方式大多用於頁面的表單中。因為POST也能完成GET的功能，因此多數人在設計表單的時候一律都使用POST方式，其實這是一個誤區。GET方式也有自己的特點和優勢，我們應該根據不同的情況來選擇是使用GET還是使用POST。