1. 概述

HTTP（超文本傳輸協議）是建立在TCP傳輸協議之上的應用層協議。HTTP是一個基于TCP/IP通信協議來傳遞數據（HTML 文件, 圖片文件, 查詢結果等）。HTTP是一個屬于應用層的面向對象的協議，由于其簡捷、快速的方式，適用于分布式超媒體信息系統。它于1990年提出，經過幾年的使用與發展，得到不斷地完善和擴展。目前在WWW中使用的是HTTP/1.0的第六版，HTTP/1.1的規范化工作正在進行之中，而且HTTP-NG(Next Generation of HTTP)的建議已經提出。HTTP協議工作于客戶端-服務端架構為上。瀏覽器作為HTTP客戶端通過URL向HTTP服務端即WEB服務器發送所有請求。Web服務器根據接收到的請求后，向客戶端發送響應信息。

2. 主要特點

• 支持Client/Server模式
• 簡單：客戶端向服務器請求服務的時候，只需要指定服務URL，攜帶必要的請求參數或者是消息體；
• 靈活：HTTP允許傳輸任意類型的數據對象。正在傳輸的類型由Content-Type加以標記。
• 無狀態：HTTP協議是無狀態協議。無狀態是指協議對于事務處理沒有記憶能力。缺少狀態意味著如果后續處理需要前面的信息，則它必須重傳，這樣可能導致每次連接傳送的數據量增大。另一方面，在服務器不需要先前信息時它的應答就較快，負載較低。

3. HTTP協議的URL

HTTP使用統一資源標識符（Uniform Resource Identifiers, URI）來傳輸數據和建立連接。URL是一種特殊類型的URI，包含了用于查找某個資源的足夠的信息。HTTPURL的格式如下：

http://www.aspxfans.com:8080/news/index.asp?boardID=5&ID=24618&page=1#name

從上面的URL可以看出，一個完整的URL包括以下幾部分：

協議部分：該URL的協議部分為“http：”，這代表網頁使用的是HTTP協議。

域名部分：該URL的域名部分為“www.aspxfans.com”。一個URL中，也可以使用IP地址作為域名使用

端口部分：跟在域名后面的是端口，域名和端口之間使用“:”作為分隔符。

虛擬目錄部分：從域名后的第一個“/”開始到最后一個“/”為止，是虛擬目錄部分。

文件名部分：從域名后的最后一個“/”開始到“？”為止，是文件名部分，如果沒有“?”,則是從域名后的最后一個“/”開始到“#”為止，是文件部分，如果沒有“？”和“#”，那么從域名后的最后一個“/”開始到結束，都是文件名部分。

錨部分：從“#”開始到最后，都是錨部分。本例中的錨部分是“name”。錨部分也不是一個URL必須的部分

參數部分：從“？”開始到“#”為止之間的部分為參數部分，又稱搜索部分、查詢部分。本例中的參數部分為“boardID=5&ID=24618&page=1”。參數可以允許有多個參數，參數與參數之間用“&”作為分隔符。

3.1 URI和URL的區別

URI

URI，是uniform resource identifier，統一資源標識符，用來唯一的標識一個資源。

Web上可用的每種資源如HTML文檔、圖像、視頻片段、程序等都是一個來URI來定位的
URI一般由三部組成：

訪問資源的命名機制

存放資源的主機名

資源自身的名稱，由路徑表示，著重強調于資源。

URL

URL是uniform resource locator，統一資源定位器，它是一種具體的URI，即URL可以用來標識一個資源，而且還指明了如何locate這個資源。

URL是Internet上用來描述信息資源的字符串，主要用在各種WWW客戶程序和服務器程序上，特別是著名的Mosaic。采用URL可以用一種統一的格式來描述各種信息資源，包括文件、服務器的地址和目錄等。URL一般由三部組成：

協議(或稱為服務方式)

存有該資源的主機IP地址(有時也包括端口號)

主機資源的具體地址。如目錄和文件名等

URN

URN，uniform resource name，統一資源命名，是通過名字來標識資源，比如mailto:java-net@java.sun.com。

URI是以一種抽象的，高層次概念定義統一資源標識，而URL和URN則是具體的資源標識的方式。URL和URN都是一種URI?；\統地說，每個 URL 都是 URI，但不一定每個 URI 都是 URL。這是因為 URI 還包括一個子類，即統一資源名稱 (URN)，它命名資源但不指定如何定位資源。上面的 mailto、news 和 isbn URI 都是 URN 的示例。

4. HTTP請求消息（HTTP Request）

客戶端發送一個HTTP請求到服務器的請求消息包括以下格式：HTTP請求行、HTTP請求頭、HTTP請求正文。

Get請求例子，使用Charles抓取的request：

GET /562f25980001b1b106000338.jpg HTTP/1.1 Host img.mukewang.com User-Agent Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.106 Safari/537.36 Accept image/webp,image/*,*/*;q=0.8 Referer http://www.imooc.com/ Accept-Encoding gzip, deflate, sdch Accept-Language zh-CN,zh;q=0.8

4.1 請求行

請求行以一個方法符開頭，以空格分開，后面跟著請求的URI和協議的版本。格式為Method Request-URI HTTP-Version CRLF

請求方法有多種，各個方法作用如下所示：

• GET：請求獲取Request-URI所標識的資源；
• POST：在Request-URI所標識的資源后附加新的提交數據；
• HEAD：請求獲取由Request-URI所標識資源的響應消息報頭；
• PUT：請求服務器存儲一個資源，并用Request-URI作為其標識；
• DELETE：請求服務器刪除Request-URI所標識的資源；
• TRACE：請求服務器回送到的請求消息，主要用于測試或者診斷；
• CONNECT:保留作為將來使用
• OPTIONS：請求查詢服務器的性能，或者查詢與資源相關的選項和需求；

4.2 請求頭

請求頭部，緊接著請求行（即第一行）之后的部分，請求報頭允許客戶端向服務器端傳遞請求的附加信息以及客戶端自身的信息。

4.3 請求正文

請求數據也叫主體，可以添加任意的其他數據。比如在上面Get的列子里面，請求正文的數據為空。

POST請求例子，使用Charles抓取的request：

POST / HTTP1.1 Host:www.wrox.com User-Agent:Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022) Content-Type:application/x-www-form-urlencoded Content-Length:40 Connection: Keep-Alivename=Professional%20Ajax&publisher=Wiley

第一部分：請求行，第一行明了是post請求，以及http1.1版本。

第二部分：請求頭部，第二行至第六行。

第三部分：空行，第七行的空行。

第四部分：請求數據，第八行。

4.5 GET和POST請求的區別

GET請求 GET /books/?sex=man&name=Professional HTTP/1.1 Host: www.wrox.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050225 Firefox/1.0.1 Connection: Keep-Alive 注意最后一行是空行 POST請求 POST / HTTP/1.1 Host: www.wrox.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050225 Firefox/1.0.1 Content-Type: application/x-www-form-urlencoded Content-Length: 40 Connection: Keep-Alivename=Professional%20Ajax&publisher=Wiley

根據HTTP規范，GET請求主要用于信息獲取，而且應該是安全的和冪等的：POST則表示可能改變服務器上的資源的請求。

GET提交，請求的數據會附在URL之后，就是把數據放置在請求行（request line）中，以“？”分隔URL和傳輸數據，多個參數用“&”連接；而POST提交會把提交的數據放置在HTTP消息的包體中，數據不會在地址欄中顯示出來。

傳輸數據的大小不同。特定的服務器對URL的長度有限制，因此GET請求攜帶的參數的長度會受到瀏覽器的限制，而POST請求不是通過URL傳值，理論上數據長度不會受限制。

安全性。POST的安全性要比GET的安全性高。

5. HTTP響應消息（HttpResponse）

處理完客戶端發送的請求之后，HTTP服務器返回響應消息給客戶端，HTTP響應也是由三個部分組成：狀態頭、響應報文、響應正文。

5.1 狀態行

狀態行的格式為：HTTP-Version StatusCode Reason-Phrase CRLF,其中 HTTP-Version表示服務器HTTP協議的版本，Status-Code表示服務器返回的響應狀態代碼。

狀態代碼有三位數字組成，第一個數字定義了響應的類別，共分五種類別:

• 1xx：指示信息–表示請求已接收，繼續處理
• 2xx：成功–表示請求已被成功接收、理解、接受
• 3xx：重定向–要完成請求必須進行更進一步的操作
• 4xx：客戶端錯誤–請求有語法錯誤或請求無法實現
• 5xx：服務器端錯誤–服務器未能實現合法的請求

常見狀態碼：

• 200 OK //客戶端請求成功
• 400 Bad Request //客戶端請求有語法錯誤，不能被服務器所理解
• 401 Unauthorized //請求未經授權，這個狀態代碼必須和WWW-Authenticate報頭域一起使用
• 403 Forbidden //服務器收到請求，但是拒絕提供服務
• 404 Not Found //請求資源不存在，eg：輸入了錯誤的URL
• 500 Internal Server Error //服務器發生不可預期的錯誤
• 503 Server Unavailable //服務器當前不能處理客戶端的請求，一段時間后可能恢復正常

5.2 消息報頭

第二行和第三行為消息報頭，Date:生成響應的日期和時間；Content-Type:指定了MIME類型的HTML(text/html),編碼類型是UTF-8. Content-Length:122 指定了響應正文的長度。

5.3 響應正文

空行后面的html部分為響應正文。

6. HTTP工作原理

HTTP協議定義Web客戶端如何從Web服務器請求Web頁面，以及服務器如何把Web頁面傳送給客戶端。HTTP協議采用了請求/響應模型。客戶端向服務器發送一個請求報文，請求報文包含請求的方法、URL、協議版本、請求頭部和請求數據。服務器以一個狀態行作為響應，響應的內容包括協議的版本、成功或者錯誤代碼、服務器信息、響應頭部和響應數據。

以下是 HTTP 請求/響應的步驟：

1、客戶端連接到Web服務器

一個HTTP客戶端，通常是瀏覽器，與Web服務器的HTTP端口（默認為80）建立一個TCP套接字連接。例如，http://www.oakcms.cn。

2、發送HTTP請求

通過TCP套接字，客戶端向Web服務器發送一個文本的請求報文，一個請求報文由請求行、請求頭部、空行和請求數據4部分組成。

3、服務器接受請求并返回HTTP響應

Web服務器解析請求，定位請求資源。服務器將資源復本寫到TCP套接字，由客戶端讀取。一個響應由狀態行、響應頭部、空行和響應數據4部分組成。

4、釋放連接TCP連接

若connection 模式為close，則服務器主動關閉TCP連接，客戶端被動關閉連接，釋放TCP連接;若connection 模式為keepalive，則該連接會保持一段時間，在該時間內可以繼續接收請求;

5、客戶端瀏覽器解析HTML內容

客戶端瀏覽器首先解析狀態行，查看表明請求是否成功的狀態代碼。然后解析每一個響應頭，響應頭告知以下為若干字節的HTML文檔和文檔的字符集?？蛻舳藶g覽器讀取響應數據HTML，根據HTML的語法對其進行格式化，并在瀏覽器窗口中顯示。

例如：在瀏覽器地址欄鍵入URL，按下回車之后會經歷以下流程：

瀏覽器向 DNS 服務器請求解析該 URL 中的域名所對應的 IP 地址;

解析出 IP 地址后，根據該 IP 地址和默認端口 80，和服務器建立TCP連接;

瀏覽器發出讀取文件(URL 中域名后面部分對應的文件)的HTTP 請求，該請求報文作為 TCP 三次握手的第三個報文的數據發送給服務器;

服務器對瀏覽器請求作出響應，并把對應的 html 文本發送給瀏覽器;

釋放 TCP連接;

瀏覽器將該 html 文本并顯示內容;

總結

以上是生活随笔為你收集整理的计算机网络：详解HTTP协议的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。