目錄

• HTTP協議簡介
• HTTP協議概述
• HTTP工作原理
• 基於 請求-響應 的模式
• 無狀態儲存
• 無連線
• HTTP請求方法
• GET
• HEAD
• POST
• PUT
• DELETE
• TRACE
• OPTIONS
• CONNECT
• HTTP狀態碼
• URL
• HTTP請求格式(請求協議)
• HTTP響應格式（響應協議）

HTTP協議簡介

超文字傳輸協議（英文：HyperText Transfer Protocol，縮寫：HTTP）是一種用於分散式、協作式和超媒體資訊系統的應用層協議。HTTP是全球資訊網的資料通訊的基礎。

HTTP的發展是由蒂姆伯納斯-李於1989年在歐洲核子研究組織（CERN）所發起。HTTP的標準制定由全球資訊網協會（World Wide Web Consortium，W3C）和網際網路工程任務組（Internet Engineering Task Force，IETF）進行協調，最終釋出了一系列的RFC，其中最著名的是1999年6月公佈的 RFC 2616www.cppcns.com

2014年12月，網際網路工程任務組（IETF）的Hypertext Transfer Protocol Bis（httpbis）工作小組將HTTP/2標準提議遞交至IESG進行討論，於2015年2月17日被批准。 HTTP/2標準於2015年5月以RFC 7540正式發表，取代HTTP 1.1成為HTTP的實現標準。

HTTP協議概述

HTTP是一個客戶端終端（使用者）和伺服器端（）請求和應答的標準（TCP）。通過使用瀏覽器、網路爬蟲或者其它的工具，客戶端發起一個HTTP請求到伺服器上指定埠（預設埠為80）。我們稱這個客戶端為使用者代理程式（user agent）。應答的伺服器上儲存著一些資源，比如HTML檔案和影象。我們稱這個應答伺服器為源伺服器（origin server）。在使用者代理和源伺服器中間可能存在多個“中間層”，比如代理伺服器、閘道器或者隧道（tunnel）。

儘管TCP/IP協議是網際網路上最流行的應用，HTTP協議中，並沒有規定必須使用它或它支援的層。事實上，HTTP可以在任何網際網路協議上，或其他網路上實現。HTTP假定其下層協議提供可靠的傳輸。因此，任何能夠提供這種保證的協議都可以被其使用。因此也就是其在TCP/IP協議族使用TCP作為其傳輸層。

通常，由HTTP客戶端發起一個請求，建立一個到伺服器指定埠（預設是80埠）的TCP連線。HTTP伺服器則在那個埠監聽客戶端的請求。一旦收到請求，伺服器會向客戶端返回一個狀態，比如"HTTP/1.1 200 OK"，以及返回的內容，如請求的檔案、錯誤訊息、或者其它資訊。

HTTP工作原理

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

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

• 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的語法對其進行格式化，並在瀏覽器視窗中顯示。

例如：在瀏覽器位址列鍵入URL，按下回車之後會經歷以下流程：

• 瀏覽器向 DNS 伺服器請求解析該 URL 中的域名所對應的 IP 地址;
• 解析出 IP 地址後，根據該 IP 地址和預設埠 80，和伺服器建立TCP連線;
• 瀏覽器發出讀取檔案(URL 中域名後面部分對應的檔案)的HTTP 請求，該請求報文作為 TCP 三次握手的第三個報文的資料傳送給伺服器;
• 伺服器對瀏覽器請求作出響應，並把對應的 html 文字傳送給瀏覽器;
• 釋放 TCP連線;
• 瀏覽器將該 html 文字並顯示內容;

http協議是基於TCP/IP協議之上的應用層協議。

基於 請求-響應 的模式

HTTP協議規定,請求從客戶端發出,最後伺服器端響應該請求並 返回。換句話說,肯定是先從客戶端開始建立通訊的,伺服器端在沒有接收到請求之前不會發送響應

無狀態儲存

HTTP是一種不儲存狀態,即無狀態(stateless)協議。HTTP協議自身不對請求和響應之間的通訊狀態進行儲存。也就是說在HTTP這個級別,協議對於傳送過的請求或響應都不做持久化處理。

使用HTTP協議,每當有新的請求傳送時,就會有對應的新響應產生。協議本身並不保留之前一切的請求或響應報文的資訊。這是為了更快地處理大量事務,確保協議http://www.cppcns.com的可伸縮性,而特意把HTTP協議設計成 如此簡單的。可是,隨著Web的不斷髮展,因無狀態而導致業務處理變得棘手 的情況增多了。比如,使用者登入到一家購物網站,即使他跳轉到該站的 其他頁面後,也需要能繼續保持登入狀態。針對這個例項,網站為了能 夠掌握是誰送出的請求,需要儲存使用者的狀態。HTTP/1.1雖然是無狀態協議,但為了實現期望的保持狀態功能,於是引入了Cookie技術。有了Cookie再用HTTP協議通訊,就可以管 理狀態了。有關Cookie的詳細內容稍後講解。

無連線

無連線的含義是限制每次連線只處理一個請求。伺服器處理完客戶的請求，並收到客戶的應答後，即斷開連線。採用這種方式可以節省傳輸時間，並且可以提高併發效能，不能和每個使用者建立長久的連線，請求一次相應一次，服務端和客戶端就中斷了。但是無連線有兩種方式，早期的http協議是一個請求一個響應之後，直接就斷開了，但是現在的http協議1.1版本不是直接就斷開了，而是等幾秒鐘，這幾秒鐘是等什麼呢，等著使用者有後續的操作，如果使用者在這幾秒鐘之內有新的請求，那麼還是通過之前的連線通道來收發訊息，如果過了這幾秒鐘使用者沒有傳送新的請求，那麼就會斷開連線，這樣可以提高效率，減少短時間內建立連線的次數，因為建立連線也是耗時的，預設的好像是3秒中現在，但是這個時間是可以通過咱們後端的程式碼來調整的，自己網站根據自己網站使用者的行為來分析統計出一個最優的等待時間。

HTTP請求方法

HTTP/1.1協議中共定義了八種方法（也叫“動作”）來以不同方式操作指定的資源：

GET

向指定的資源發出“顯示”請求。使用GET方法應該只用在讀取資料，而不應當被用於產生“副作用”的操作中，例如在Web Application中。其中一個原因是GET可能會被網路蜘蛛等隨意訪問。

HEAD

與GET方法一樣，都是向伺服器發出指定資源的請求。只不過伺服器將不傳回資源的本文部分。它的好處在於，使用這個方法可以在不必傳輸全部內容的情況下，就可以獲取其中“關於該資源的資訊”（元資訊或稱元資料）。

POST

向指定資源提交資料，請求伺服器進行處理（例如提交表單或者上傳檔案）。資料被包含在請求本文中。這個請求可能會建立新的資源或修改現有資源，或二者皆有。

PUT

向指定資源位置上傳其最新內容。

DELETE

請求伺服器刪除Request-URI所標識的資源。

TRACE

回顯伺服器收到的請求，主要用於測試或診斷。

OPTIONS

這個方法可使伺服器傳回該資源所支援的所有HTTP請求方法。用'*'來代替資源名稱，向Web伺服器傳送OPTIONS請求，可以測試伺服器功能是否正常運作。

CONNECT

HTTP/1.1協議中預留給能夠將連線改為管道方式的代理伺服器。通常用於SSL加密伺服器的連結（經由非加密的HTTP代理伺服器）。

注意事項：

• 方法名稱是區分大小寫的。當某個請求所針對的資源不支援對應的請求方法的時候，伺服器應當返回狀態碼405（Method Not Allowed），當伺服器不認識或者不支援對應的請求方法的時候，應當返回狀態碼501（Not Implemented）。
• HTTP伺服器至少應該實現GET和HEAD方法，其他方法都是可選的。當然，所有的方法支援的實現都應當匹配下述的方法各自的語義定義。此外，除了上述方法，特定的HTTP伺服器還能夠擴充套件自定義的方法。例如PATCH（由 RFC 5789 指定的方法）用於將區域性修改應用到資源。

請求方式: get與post請求（通過form表單我們自己寫寫看）

• GET提交的資料會放在URL之後，也就是請求行裡面，以?分割URL和傳輸資料，引數之間以&相連，如EditBook?name=test1&id=123456.（請求頭裡面那個content-type做的這種引數形式，後面講） POST方法是把提交的資料放在HTTP包的請求體中.
• GET提交的資料大小有限制（因為瀏覽器對URL的長度有限制），而POST方法提交的資料沒有限制.
• GET與POST請求在服務端獲取請求資料方式不同，就是我們自己在服務端取請求資料的時候的方式不同了，這句廢話昂。

HTTP狀態碼

所有HTTP響應的第一行都是狀態行，依次是當前HTTP版本號，3位數字組成的狀態程式碼，以及描述狀態的短語，彼此由空格分隔。

狀態程式碼的第一個數字代表當前響應的型別：

• 1xx訊息——請求已被伺服器接收，繼續處理
• 2xx成功——請求已成功被伺服器接收、理解、並接受
• 3xx重定向——需要後續操作才能完成這一請求
• 4xx請求錯誤——請求含有詞法錯誤或者無法被執行
• 5xx伺服器錯誤——伺服器在處理某個正確請求時發生錯誤

雖然 RFC 2616 中已經推薦了描述狀態的短語，例如"200 OK"，"404 Not Found"，但是WEB開發者仍然能夠自行決定採用何種短語，用以顯示本地化的狀態描述或者自定義資訊。

URL

超文字傳輸協議（HTTP）的統一資源定位符將從因特網獲取資訊的五個基本元素包括在一個簡單的地址中：

• 傳送協議。
• 層級URL標記符號(為[//],固定不變)
• 訪問資源需要的憑證資訊（可省略）
• 伺服器。（通常為域名，有時為IP地址）
• 埠號。（以數字方式表示，若為HTTP的預設值“:80”可省略）
• 路徑。（以“/”字元區別路徑中的每一個目錄名稱）
• 查詢。（GET模式的窗體引數，以“?”字元為起點，每個引數以“gtghk&”隔開，再以“=”分開引數名稱與資料，通常以UTF8的URL編碼，避開字元衝突的問題）
• 片段。以“#”字元為起點

以http://www.luffycity.com:80/news/index.html?id=250&page=1 為例,其中：

http，是協議；

www.luffycity.com，是伺服器；

80，是伺服器上的預設網路埠號，預設不顯示；

/news/index.html，是路徑（URI：直接定位到對應的資源）；

?id=250&page=1，是查詢。

大多數網頁瀏覽器不要求使用者輸入網頁中“http://”的部分，因為絕大多數網頁內容是超文字傳輸協議檔案。同樣，“80”是超文字傳輸協議檔案的常用埠號，因此一般也不必寫明。一般來說使用者只要鍵入統一資源定位符的一部分（www.luffycity.com:80/news/index.html?id=250&page=1）就可以了。

由於超文字傳輸協議允許伺服器將瀏覽器重定向到另一個網頁地址，因此許多伺服器允許使用者省略網頁地址中的部分，比如 www。從技術上來說這樣省略後的網頁地址實際上是一個不同的網頁地址，瀏覽器本身無法決定這個新地址是否通，伺服器必須完成重定向的任務。

HTTP請求格式(請求協議)

URL包含：/index/index2?a=1&b=2；路徑和引數都在這裡。

請求頭裡面的內容舉個例子：這個length表示請求體裡面的資料長度，其他的請求頭裡面的這些鍵值對，陸續我們會講的，大概知道一下就可以了，其中有一個user-agent，算是需要你記住的吧，就是告訴你的服務端，我是用什麼給你傳送的請求。

以京東為例，看一下user-agent

看一個爬蟲的例子，爬京東的時候沒問題，但是爬抽屜的時候必須帶著user-agent，因為抽屜對user-agent做了判斷，來判斷你是不是一個正常的請求，算是反扒機制的一種。

開啟我們儲存的demo.html檔案，然後通過瀏覽器開啟看看就能看到頁面效果。

寫上面這些內容的意思是讓你知道有這麼個請求頭的存在，有些是有意義的，請求頭我們還可以自己定義，就在requests模組裡面那個headers={}，這個字典裡面加就行。

HTTP響應格式（響應協議）

以上就是本文的全部內容，希望對大家的學習有所幫助，也希望大家多多支援我們。