一、HTTP請求方式
1.常見請求方式
| 方法 |
描述 |
| GET |
請求指定的頁面信息，並返回實體主體 |
| HEAD |
類似於 GET 請求，只不過返回的響應中沒有具體的內容，用於獲取報頭 |
| POST |
向指定資源提交數據進行處理請求（例如提交表單或者上傳文件）。數據被包含在請求體中。POST 請求可能會導致新的資源的建立和/或已有資源的修改 |
| PUT |
從客戶端向服務器傳送的數據取代指定的文檔的內容 |
| DELETE |
請求服務器刪除指定的頁面 |
| CONNECT |
HTTP/1.1 協議中預留給能夠將連接改為管道方式的代理服務器 |
| OPTIONS |
允許客戶端查看服務器的性能 |
| TRACE |
回顯服務器收到的請求，主要用於測試或診斷 |
| PATCH |
是對 PUT 方法的補充，用來對已知資源進行局部更新 |
常見的接口類型：
get
它本質就是發送一個請求來取得服務器上的某一資源。資源通過一組HTTP頭和呈現數據（如HTML文本，或者圖片或者視頻等）返回給客戶端。GET請求中，永遠不會包含呈現數據。
格式：請求數參數寫在網址后面，用"?"連接，多個參數之間用"&"連接；
場景：get型接口用於獲取信息，多用於查詢數據，如列表查詢功能，點擊查詢按鈕就調用一個get接口，然后把信息返回出來；
特點：1）請求數據量小，2）參數暴露於url地址中，故存在安全隱患。
post
post向服務器提交數據，這個方法用途廣泛，幾乎目前所有的提交操作都是靠這種方式完成。它用來向指定資源提交數據進行處理請求（例如：提交表單和上傳文件），數據包被包含在請求體中，post請求可能導致新的資源的建立或者已有的資源的修改。
說明：向指定資源位置提交數據（如提交表單、上傳文件）來進行請求，post請求可能會導致新資源的建立。
場景：如注冊、上傳、發帖等功能，如用戶在豆瓣網站對某本書進行收藏、寫筆記、發表評論。
特點：請求數據量大，安全性高。
如，豆瓣的發表評論的開放api
POST
https://api. douban. com/v2/book/reviews
put
put比較少見，HTML表單也不支持此方式。本質上來講， put和post極為相似，都是向服務器發送數據，但它們之間有一個重要區別，put通常指定了資源的存放位置，而post則沒有，post的數據存放位置由服務器自己決定，客戶端向服務器傳送的數據取代指定文檔的內容。
說明：put請求用於向指定資源位置上傳最新內容。
場景：如用戶在豆瓣網站修改對某本書的收藏、修改某篇筆記或修改評論。
如豆瓣的修改評論的開放api。
PUT https:// api. douban. com/v2/book/review/ :id
delete
delete刪除某一個資源，基本上這個也很少見，比如amazon的S3雲服務里面就用的這個方法來刪除資源。
說明：請求服務器刪除請求里url所標識的資源；
場景：如用戶在豆瓣網站取消對某本書的收藏、刪除某篇筆記或刪除評論；
如豆瓣的刪除評論的開放api。
DELETE
https://api. douban. com/ v2/book/review/ :id
不常見的接口類型：
head
head和get本質是一樣的，區別在於head不含有呈現數據，而僅僅是HTTP頭信息。換句話說，就是返回響應中沒有具體內容，只獲取報頭。一個業務情景：欲判斷某個資源是否存在，我們通常使用get，但這里用head則意義更加明確。
connect
HTTP/1.1協議中預留給能夠將連接改為管道方式的代理服務器。
options
options是獲取當前URL所支持的方法，若請求成功，則它會在HTTP頭中包含一個名為“Allow”的頭，值是所支持的方法，如“GET, POST”。允許客戶端查看服務器的性能。
trace
trace回顯服務器收到的請求，主要用於測試和診斷。
2. get請求與post請求的區別
1.提交數據的形式
-
GET方法一般是指獲取服務器上的數據，請求參數（query string查詢字符串）直接跟着URL后邊，以?分割URL和傳輸數據，參數之間以&相連（？key1=value1&key2=value2）的形式，直接可以放到瀏覽器地址欄里，例如登錄就是采用GET方法。
如：login.actionname=hyddd&password=idontknow&verify=%E4%BD%A0%E5 %A5%BD。如果數據是英文字母/數字，原樣發送，如果是空格，轉換為+，如果是中文/其他字符，則直接把字符串用BASE64加密，得出如：%E4 %BD%A0%E5%A5%BD，其中%XX中的XX為該符號以16進制表示的ASCII。
-
POST方法是指客戶端給服務器上提交表單數據，會把數據放到請求數據字段中以&分隔各個字段，請求行不包含數據參數，地址欄也不會額外附帶參數，所以POST是通過表單提交的，請求參數放在body中，如網頁上的新用戶的注冊、調查問卷和答題就是采用POST方法。
2.提交數據的大小/長度
-
get是直接在瀏覽器地址欄輸入，直接影響到了URL的長度，但HTTP協議規范中其實是沒有對URL限制長度的，限制URL長度的是客戶端或服務器的支持的不同所影響：比如IE對URL長度的限制是2083字節(2K+35)。對於其他瀏覽器，如Netscape、FireFox等，理論上沒有長度限制，其限制取決於操作系統的支持。由於瀏覽器有限制，一般整個URL的長度可以很長，但是不能超過2049KB的大小限制，而post沒有大小限制。
-
post方式HTTP協議規范中也沒有限定，起限制作用的是服務器的處理程序的處理能力。所以大小的限制還是得受各個web服務器配置的不同而影響。
3.提交數據的安全性
-
由於get的參數是在瀏覽器地址欄URL直接拼接，用戶名和密碼將明文出現在URL上，暴露在互聯網中，安全性差，不能用來傳遞敏感信息。
-
post請求參數放在body里，是通過表單數據提交，post比get方式的安全性要高。
get方式安全性弱因為以下幾個原因：
(1)登錄頁面有可能被瀏覽器緩存；
(2)其他人查看瀏覽器的歷史紀錄，那么別人就可以拿到賬號和密碼；
(3)當遇上跨站的攻擊時，安全性的表現更差；
4.編碼方式
-
get的參數只能支持ASCII；
-
post沒有限制,也允許二進制數據；
5.請求方式
-
get是獲取指定的資源
-
post是向指定的資源提交要被處理的數據
6.請求體
-
get沒有請求體；
-
post有請求體；
7.效率方面
-
get產生一個tcp數據包；
-
post產生兩個tcp數據包，post需要兩步，時間上消耗要多一點，get比post更有效；
8.請求過程
-
對於get方式的請求，瀏覽器會把http header和data一並發送出去，服務器響應200（返回數據），get請求的過程：
1.瀏覽器請求tcp連接（第一次握手）；
2.服務器答應進行tcp連接（第二次握手）；
3.瀏覽器確認，並發送get請求頭和數據（第三次握手，這個報文比較小，所以http 會在此時進行第一次數據發送）；
4.服務器返回200OK響應；
-
而對於post，瀏覽器先發送header，服務器響應100continue，瀏覽器再發送data，服務器響應200ok（返回數據），post請求的過程：
1.瀏覽器請求tcp連接（第一次握手）；
2.服務器答應進行tcp連接（第二次握手）；
3.瀏覽器確認，並發送post請求頭（第三次握手，這個報文比較小，所以http會在 此時進行第一次數據發送）；
4.服務器返回100 Continue響應；
5.瀏覽器發送數據；
6.服務器返回200 OK響應；
二、HTTP請求/響應報文組成
1HTTP請求報文
客戶端發送一個HTTP請求到服務器的請求消息包括：請求行、請求頭部、空行、請求數據四個部分組成。
1.請求行（Request Line）
描述客戶端的請求概要信息，包括請求方式、請求地址（URL）、http協議的版本號3個字段組成。
如 POST /mp/webcommreport?action=report&report_useruin=0&__biz=MzI5MTg1NjA4Nw== HTTP/1.1
-
請求方式：就是HTTP使用的請求方法。
HTTP/1.1 定義的請求方法有8種：GET、POST、PUT、DELETE、PATCH、HEAD、OPTIONS、TRACE。最常的兩種GET和POST，RESTful接口的話一般會用到GET、POST、DELETE、PUT。
-
請求地址
URL:統一資源定位符，是一種自願位置的抽象唯一識別方法。
組成：<協議>：//<主機>：<端口>/<路徑>
注：端口和路徑有時可以省略（HTTP默認端口號是80）
如：https://localhost:8080/index.html?key1=value1&keys2=value2
-
HTTP協議版本如
協議版本的格式為：HTTP/主版本號.次版本號，常用的有HTTP/1.0和HTTP/1.1
HTTP1.0/HTTP1.1/HTTP 2：
HTTP1.0對於每個連接都只能傳送一個請求和響應，請求就會關閉，HTTP1.0沒有Host字段;
HTTP1.1在同一個連接中可以傳送多個請求和響應，多個請求可以重疊和同時進行，HTTP1.1必須有Host字段；
在HTTP 2.0中，這些報文被嵌入到了一個新的二進制結構，幀。幀允許實現很多優化，比如報文頭部的壓縮和復用。即使只有原始HTTP報文的一部分以HTTP/2發送出來，每條報文的語義依舊不變，客戶端會重組原始HTTP/1.1請求。因此用HTTP/1.1格式來理解HTTP/2報文仍舊有效。
2.請求頭（Request Headers）
請求頭部為請求報文添加了一些附加信息，由“名/值”對組成，每行一對，名和值之間使用冒號分隔。包含客戶機請求的服務器主機名，客戶機的環境信息等。HTTP客戶程序(如瀏覽器)，向服務器發送請求的時候必須指明請求類型(一般是GET或者 POST)。如有必要，客戶程序還可以選擇發送其他的請求頭。大多數請求頭並不是必需的，但Content-Length除外。對於POST請求來說 Content-Length必須出現。
常見的請求頭字段含義：
Host:客戶端通過這個服務器，想訪問的主機名，Host頭域指定請求資源的Intenet主機和端口號，必須表示請求url的原始服務器或網關的位置。HTTP/1.1請求必須包含主機頭域，否則系統會以400狀態碼返回。
Connection：告訴服務器，請求完成后，是否保持連接；如果Servlet看到這里的值為“Keep- Alive”，或者看到請求使用的是HTTP 1.1(HTTP 1.1默認進行持久連接)，它就可以利用持久連接的優點，當頁面包含多個元素時(例如Applet，圖片)，顯著地減少下載所需要的時間。要實現這一點，Servlet需要在應答中發送一個Content-Length頭，最簡單的實現方法是：先把內容寫入 ByteArrayOutputStream，然后在正式寫出內容之前計算它的大小。
Accept：用於告訴服務器，客戶端支持的數據類型（例如：Accept:text/html,image/*、image/webp,*/*）;
Accept-Encoding：用於告訴服務器，客戶端支持的數據壓縮格式。
Accept-Language：客戶端語言環境，當服務器能夠提供一種以上的語言版本時要用到。
Accept-Charset：用於告訴服務器，客戶端采用的編碼格式，比如gzip。Servlet能夠向支持gzip的瀏覽器返回經gzip編碼的HTML頁面，許多情形下這可以減少5到10倍的下載時間。
Content-Length：表示請求消息正文的長度。
Cookie：客戶端通過這個頭，將Coockie信息帶給服務器，這是最重要的請求頭信息之一。
Referer：客戶端通過這個頭告訴服務器，它（客戶端）是從哪個資源來訪問服務器的（防盜鏈），包含一個URL，用戶從該URL代表的頁面出發訪問當前請求的頁面。
If-Modified-Since：客戶機通過這個頭告訴服務器，資源的緩存時間，只有當所請求的內容在指定的時間后又經過修改才返回它，否則返回304“Not Modified”應答。
User-Agent：客戶端通過這個頭告訴服務器，客戶機的軟件環境（操作系統，瀏覽器版本等），如果Servlet返回的內容與瀏覽器類型有關則該值非常有用。
Date：告訴服務器，當前請求的時間。
Authorization：授權信息，通常出現在對服務器發送的WWW-Authenticate頭的應答中。
Pragma：指定“no-cache”值表示服務器必須返回一個刷新后的文檔，即使它是代理服務器而且已經有了頁面的本地拷貝。
From：請求發送者的email地址，由一些特殊的Web客戶程序使用，瀏覽器不會用到它。
Range：Range頭域可以請求實體的一個或者多個子范圍。如：
表示頭500個字節：bytes=0-499
表示第二個500字節：bytes=500-999
表示最后500個字節：bytes=-500
表示500字節以后的范圍：bytes=500-
第一個和最后一個字節：bytes=0-0,-1
同時指定幾個范圍：bytes=500-600,601-999
但是服務器可以忽略此請求頭，如果無條件GET包含Range請求頭，響應會以狀態碼206(PartialContent)返回而不是以200 (OK)。
UA-Pixels，UA-Color，UA-OS，UA-CPU：由某些版本的IE瀏覽器所發送的非標准的請求頭，表示屏幕大小、顏色深度、操作系統和CPU類型。
3.空行（Blank Line）
它的作用是通過一個空行，告訴服務器請求頭部到此為止。接下來為請求數據，這一行非常重要，必不可少。
4.請求數據（Request Data）
可選部分
若方法字段是GET，則此項為空，沒有數據；
若方法字段是POST,則通常來說此處放置的就是要提交的數據；可以包含客戶提交的查詢字符串信息。如username=zhangsan&password=123，在實際應用中，HTTP請求正文可以包含更多的內容。
post請求示例：
比如要使用POST方法提交一個表單，其中有user字段中數據為“admin”, password字段為123456，那么這里的請求數據就是 user=admin&password=123456，使用&來連接各個字段。
①是請求方法，GET和POST是最常見的HTTP方法，除此以外還包括DELETE、HEAD、OPTIONS、PUT、TRACE。不過，當前的大多數瀏覽器只支持GET和POST。
②為請求對應的URL地址，它和報文頭的Host屬性組成完整的請求URL。
③是協議名稱及版本號。
④是HTTP的報文頭，報文頭包含若干個屬性，格式為“屬性名:屬性值”，服務端據此獲取客戶端的信息。
⑤是報文體，它將一個頁面表單中的組件值通過param1=value1¶m2=value2的鍵值對形式編碼成一個格式化串，它承載多個請求參數的數據。不但報文體可以傳遞請求參數，請求URL也可以通過類似於“/chapter15/user.html? param1=value1¶m2=value2”的方式傳遞請求參數。
2HTTP響應報文
HTTP響應報文由三部分組成：響應行、響應頭、響應體。
1.響應行（Response Line）
在接收和解釋請求消息后，服務器會返回一個HTTP響應消息。
響應行由協議版本、狀態碼及相應的狀態描述組成，各元素之間以空格分隔。
格式: HTTP-Version Status-Code Reason-Phrase CRLF
例如: HTTP/1.1 200 OK
其中，協議版本HTTP/1.1或者HTTP/1.0，200是狀態碼，OK則為描述。狀態描述給出關於狀態代碼的簡短的文字描述。
HTTP狀態碼（HTTP Status Code）
由3位數字組成，表示請求是否被理解或被滿足。
狀態碼詳解：
100~199（信息性）
表示臨時響應並需要請求者繼續執行操作的狀態代碼。
100 ：繼續（Continue） 請求者應當繼續提出請求。 服務器返回此代碼表示已收到請求的第一部分，正在等待其余部分
101 ：切換協議（Switching Protocols） 請求者已要求服務器切換協議，服務器已確認並准備切換
200~299（成功）
表示成功處理了請求的狀態代碼。
200 ：成功（OK） 服務器已成功處理了請求。通常，這表示服務器提供了請求的網頁
201 ：已創建（Created） 請求成功並且服務器創建了新的資源,，且其URL已經隨Location頭信息返回
202：已接受（Accepted ） 服務器已接受請求，但尚未處理。
203 ：非授權信息（Non-Authoritative Information ） 服務器已成功處理了請求，但返回的信息可能來自另一來源。
204 ：無內容（No Content） 服務器成功處理了請求，但沒有返回任何內容
205 ：重置內容（Reset Content） 服務器成功處理了請求，但沒有返回任何內容
206：部分內容（Partial Content ） 服務器成功處理了部分 GET 請求
300~399（重定向）
表示要完成請求，需要進一步操作。通常，這些狀態代碼用來重定向。
300 ：多種選擇（Multiple Choices） 針對請求，服務器可執行多種操作。 服務器可根據請求者 (user agent) 選擇一項操作，或提供操作列表供請求者選擇。
301 ：永久移動（Moved Permanently） 請求的網頁已永久移動到新URL。 服務器返回此響應（對 GET 或 HEAD 請求的響應）時，會自動將請求者轉到新位置,今后任何新的請求都應使用新的URL代替。
302 ：臨時移動（Found ） 服務器目前從不同位置的網頁響應請求，資源只是臨時被移動，但請求者應繼續使用原有URL來進行以后的請求。
303 ： 查看其他位置（See Other） 請求者應當對不同的位置使用單獨的 GET 請求來檢索響應時，服務器返回此代碼。
304 ： 未修改（Not Modified） 自從上次請求后，請求的網頁未修改過。 服務器返回此響應時，不會返回網頁內容。
305 ： 使用代理（Use Proxy） 請求者只能使用代理訪問請求的網頁。 如果服務器返回此響應，還表示請求者應使用代理。
306 ： 已經被廢棄的HTTP狀態碼（Unused）
307 ：臨時重定向（Temporary Redirect ） 服務器目前從不同位置的網頁響應請求，但請求者應繼續使用原有位置來進行以后的請求。與302類似，使用GET請求重定向。
400~499（客戶端請求錯誤）
這些狀態代碼表示請求可能出錯，妨礙了服務器的處理。
400 ：錯誤請求（Bad Request ） 客戶端請求的語法錯誤，服務器無法理解
401 ：未授權（Unauthorized） 請求要求身份驗證。對於需要登錄的網頁，服務器可能返回此響應。 如果當前請求已經包含了Authorization證書，那么401響應代表着服務器驗證已經拒絕了那些證書.
402 ：保留(Payment Required ),將來使用
403 ：禁止（Forbidden） 服務器已經理解請求，但是拒絕執行請求。
404 ：未找到（Not Found ）請求失敗， 服務器找不到請求的網頁(資源)。
405 ：方法禁用（ Method Not Allowed ） 禁用請求中指定的方法。
406 ：不接受（Not Acceptable） 無法使用請求的內容特性響應請求的網頁。
407 ：需要代理授權（Proxy Authentication Required ） 此狀態代碼與 401（未授權）類似，但指定請求者應當授權使用代理。
408 ：請求超時（Request Time-out ） 服務器等待客戶端發送的請求時間過長，發生超時。
409 ：沖突（Conflict ） 服務器在完成請求時發生沖突， 服務器必須在響應中包含有關沖突的信息。
410 ：已刪除（ Gone） 如果請求的資源已永久刪除，服務器就會返回此響應。 410不同於404，如果資源以前有現在被永久刪除了可使用410代碼。
411 ：需要有效長度（Length Required ） 服務器不接受不含有效內容長度Content-Length標頭字段的請求。
412 ：未滿足前提條件（Precondition Failed ） 服務器未滿足請求者在請求中設置的其中一個前提條件。
413 ：請求實體過大（ Request Entity Too Large ） 服務器無法處理請求，因為請求實體過大，超出服務器的處理能力。 由於請求的實體過大，服務器無法處理，因此拒絕請求。為防止客戶端的連續請求，服務器可能會關閉連接。如果只是服務器暫時無法處理，則會包含一個Retry-After的響應信息
414 ：請求的 URI 過長（Request-URI Too Large） 請求的 URI（通常為網址）過長，服務器無法處理。
415 ：不支持的媒體類型（Unsupported Media Type） 請求的媒體格式不受請求頁面的支持。
416 ：請求范圍不符合要求（Requested range not satisfiable ） 如果頁面無法提供請求的范圍，則服務器會返回此狀態代碼。
417 ：未滿足期望值（Expectation Failed ） 服務器未滿足”期望”請求標頭字段的要求。
500~599（服務器錯誤）
這些狀態代碼表示服務器在嘗試處理請求時發生內部錯誤。這些錯誤可能是服務器本身的錯誤，而不是請求出錯。
500 ： 服務器內部錯誤（ Internal Server Error ） 服務器遇到未曾預料的狀況，無法完成請求。 一般來說，這個問題都會在服務器的程序碼出錯時出現。
501： 尚未實施（Not Implemented ） 服務器不具備完成請求的功能，無法完成請求。例如，服務器無法識別請求方法時可能會返回此代碼。
502： 錯誤網關 （Bad Gateway） 服務器作為網關或代理，從上游服務器收到無效響應。
503 ： 服務不可用（Service Unavailable ） 服務器目前無法使用（由於超載或停機維護），延時的長度可包含在服務器的Retry-After頭信息中。通常，這只是暫時狀態，將在一段時間以后恢復.
504： 網關超時（Gateway Time-out ） 服務器作為網關或代理，但是沒有及時從上游服務器收到請求。
505 ： HTTP 版本不受支持（HTTP Version not supported） 服務器不支持請求中所用的 HTTP 協議版本。
2.響應頭（Response headers）
響應頭用於描述服務器的基本信息，以及數據的描述，服務器通過這些數據的描述信息，可以通知客戶端如何處理等一會兒它回送的數據。
設置HTTP響應頭往往和狀態碼結合起來。例如，有好幾個表示“文檔位置已經改變”的狀態代碼都伴隨着一個Location頭，而401(Unauthorized)狀態代碼則必須伴隨一個WWW-Authenticate頭。然而，即使在沒有設置特殊含義的狀態代碼時，指定應答頭也是很有用的。應答頭可以用來完成：設置Cookie，指定修改日期，指示瀏覽器按照指定的間隔刷新頁面，聲明文檔的長度以便利用持久HTTP連接……等等許多其他任務。
常見的響應頭字段含義：
Allow：服務器支持哪些請求方法(如GET、POST等)。
Content-Encoding：告訴瀏覽器，服務器的數據壓縮(Encode)格式。實體報頭域被使用作媒體類型的修飾符，它的值指示了已經被應用到實體正文的附加內容編碼，因而要獲得Content- Type報頭域中所引用的媒體類型，必須采用相應的解碼機制。有在解碼之后才可以得到Content-Type頭指定的內容類型。利用gzip壓縮文檔能夠顯著地減少HTML文檔的下載時間。
Content- Type：告訴瀏覽器，回送數據的類型。Servlet默認為text/plain，但通常需要顯式地指定為text/html。
Date：當前的GMT時間，例如，Date:Mon,31Dec200104:25:57GMT。Date描述的時間表示世界標准時，換算成本地時間，需要知道用戶所在的時區。可以用setDateHeader來設置這個頭以避免轉換時間格式的麻煩。
Expires：告訴瀏覽器把回送的資源緩存多長時間，-1或0則是不緩存。
Last-Modified：告訴瀏覽器當前資源緩存最后改動時間。客戶可以通過If-Modified-Since請求頭提供一個日期，該請求將被視為一個條件GET，只有改動時間遲於指定時間的文檔才會返回，否則返回一個304(Not Modified)狀態。Last-Modified也可用setDateHeader方法來設置。
Location：響應報頭域用於重定向接受者到一個新的位置，這個頭配合302狀態碼使用，告訴客戶端找誰，用於重定向接收者到一個新URI地址。表示客戶應當到哪里去提取文檔。Location通常不是直接設置的，而是通過HttpServletResponse的sendRedirect方法，該方法同時設置狀態代碼為302。
Refresh：告訴瀏覽器隔多久刷新一次，以秒計。
Server：服務器通過這個頭告訴瀏覽器服務器的類型。Server響應頭包含處理請求的原始服務器的軟件信息。此域能包含多個產品標識和注釋，產品標識一般按照重要性排序。Servlet一般不設置這個值，而是由Web服務器自己設置。
Set-Cookie：設置和頁面關聯的Cookie。Servlet不應使用response.setHeader(“Set-Cookie”, …)，而是應使用HttpServletResponse提供的專用方法addCookie。
Transfer-Encoding：告訴瀏覽器，傳送數據的編碼格式。
WWW-Authenticate：客戶應該在Authorization頭中提供什么類型的授權信息?在包含401(Unauthorized)狀態行的應答中這個頭是必需的。
setContentType：設置Content-Type頭。大多數Servlet都要用到這個方法。
setContentLength：設置Content-Length頭。對於支持持久HTTP連接的瀏覽器來說，這個函數是很有用的。
addCookie：設置一個Cookie(Servlet API中沒有setCookie方法，因為應答往往包含多個Set-Cookie頭)。
Cache-Control：控制瀏覽器不要緩存數據 no-cache
3.響應體（Response Body）
響應體就是響應的消息體，如果是純數據就是返回純數據，如果請求的是HTML頁面，那么返回的就是HTML代碼，如果是JS就是JS代碼，如此之類。
HTTP響應報文格式就如下圖所示：
①報文協議及版本；
②狀態碼及狀態描述；
③響應報文頭，也是由多個屬性組成；
④響應報文體，即我們真正要的“干貨”。
3、HTTP請求/響應步驟
HTTP協議定義Web客戶端如何從Web服務器請求Web頁面，以及服務器如何把Web頁面傳送給客戶端。HTTP協議采用了請求/響應模型。客戶端向服務器發送一個請求報文，請求報文包含請求的方法、URL、協議版本、請求頭部和請求數據。服務器以一個狀態行作為響應，響應的內容包括協議的版本、成功或者錯誤代碼、服務器信息、響應頭部和響應數據。
客戶端連接到Web服務器->發送Http請求->服務器接受請求並返回HTTP響應->釋放連接TCP連接->客戶端瀏覽器解析HTML內容。
1.客戶端連接到Web服務器
一個HTTP客戶端，通常是瀏覽器，與Web服務器的HTTP端口（默認為80）建立一個TCP套接字連接。例如，http://www.baidu.com
2.發送HTTP請求
通過TCP套接字，客戶端向Web服務器發送一個文本的請求報文，一個請求報文由請求行、請求頭部、空行和請求數據4部分組成。
3.服務器接受請求並返回HTTP響應Web服務器解析請求，定位請求資源。服務器將資源復本寫到TCP套接字，由客戶端讀取。一個響應由狀態行、響應頭部、空行和響應數據4部分組成。
4.釋放連接TCP連接
若connection 模式為close，則服務器主動關閉TCP連接，客戶端被動關閉連接，釋放TCP連接;若connection 模式為keepalive，則該連接會保持一段時間，在該時間內可以繼續接收請求;
5.客戶端瀏覽器解析HTML內容
客戶端瀏覽器首先解析狀態行，查看表明請求是否成功的狀態代碼。然后解析每一個響應頭，響應頭告知以下為若干字節的HTML文檔和文檔的字符集。客戶端瀏覽器讀取響應數據HTML，根據HTML的語法對其進行格式化，並在瀏覽器窗口中顯示。
HTTP請求消息Request客戶端發送一個HTTP請求到服務器的請求消息包括以下格式請求行（request line）、請求頭部（header）、空行和請求數據四個部分組成。
例如：在瀏覽器地址欄鍵入URL，按下回車之后會經歷以下流程：
1.瀏覽器向 DNS 服務器請求解析該 URL 中的域名所對應的 IP 地址;
2.解析出 IP 地址后，根據該 IP 地址和默認端口 80，和服務器建立TCP連接;
3.瀏覽器發出讀取文件(URL 中域名后面部分對應的文件)的HTTP 請求，該請求報文作為 TCP 三次握手的第三個報文的數據發送給服務器;
4.服務器對瀏覽器請求作出響應，並把對應的 html 文本發送給瀏覽器;
5.釋放 TCP連接;
6.瀏覽器將該 html 文本並顯示內容;
4、HTTP請求特點
1.基於請求/響應，支持客戶端/服務器模式
客戶端發送請求，服務器端響應數據。客戶端向服務器請求服務時，只需要傳送請求的方法和路徑即可。常用的請求方法有get（查）、post（增），除此之外還有put（改）、delete（刪）等，每種方法規定的客戶端與服務器聯系的方式不同，日常工作中見到的最多的是get和post兩種。
2.基於TCP/IP協議之上的應用層協議，簡單靈活
HTTP簡單，服務器的程序規模小，通信速度快；HTTP使用TCP作為它的支撐運輸協議，HTTP客戶機發起一個與服務器的TCP連接，一旦連接建立，瀏覽器（客戶機）和服務器進程就可以通過套接字接口訪問TCP，HTTP運行傳輸任意類型的數據對象。
3.無狀態
協議對於事務處理沒有記憶能力，客戶端第一次與服務器建立連接發送請求時需要進行一系列的安全認證匹配等，因此增加頁面等待時間，當客戶端向服務器端發送請求，服務器端響應完畢后，兩者斷開連接，也不保存連接狀態，（一刀兩斷，恩斷義絕，從此路人！）下一次客戶端向同樣的服務器發送請求時，由於他們之前已經遺忘了彼此，所以需要重新建立連接。
4.無連接
限制每次連接，使其只處理一個請求。服務器處理完客戶端的請求並收到客戶端的應答后，即斷開連接，這種方式可以節省傳輸時間。