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 2616，定義了HTTP協定中現今廣泛使用的一個版本——HTTP 1.1。

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協定設計成如此簡單的。可是,随着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模式的窗體參數，以“?”字元為起點，每個參數以“&”隔開，再以“=”分開參數名稱與資料，通常以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={}，這個字典裡面加就行。