【0基礎學爬蟲】爬蟲基礎之HTTP協議的基本原理介紹

大資料時代，各行各業對資料采集的需求日益增多，網路爬蟲的運用也更為廣泛，越來越多的人開始學習網路爬蟲這項技術，K哥爬蟲此前已經推出不少爬蟲進階、逆向相關文章，為實作從易到難全方位覆寫，特設【0基礎學爬蟲】專欄，幫助小白快速入門爬蟲，本期為 HTTP 協議的基本原理介紹，

計算機網路模型

計算機網路是指由通信線路互相連接的許多自主作業的計算機構成的集合體，各個部件之間以何種規則進行通信，就是網路模型研究的問題，除了標準的 OSI 七層模型以外，常見的網路層次劃分還有 TCP/IP 四層協議以及 TCP/IP 五層協議，它們之間的對應關系如下圖所示：

• **物理層（Physical）：**負責傳輸位元流的硬體部分，包括各種傳輸介質（如銅線、光纖、無線信道）和傳輸設備（如集線器、交換機、路由器），基于電器特性發送高低電壓（電信號）傳輸位元流（Bits），高電壓對應數字 1，低電壓對應數字 0，定義物理設備標準，如網線的介面型別、光纖的介面型別、各種傳輸介質的傳輸速率等；
• **資料鏈路層（Data Link）：**負責在物理層的傳輸介質上傳送資料幀，并在源主機和目的主機之間建立邏輯鏈路，定義了電信號的分組方式，規定電信號多少位一組，每組代表什么，這一層還提供了對傳輸資料的檢測和傳輸資料錯誤的糾正以確保資料的可靠傳輸，例如：Wi-Fi（IEEE 802.11）、ethernet（以太網）、FDDI（Fiber Distributed Data Interface，光纖分布式資料介面）等；
• **網路層（Network）：**負責在多個主機之間傳送資料包，并為分組交換提供路由選擇功能，基本資料單位為 IP 資料報，主要協議：IP協議（Internet Protocol，因特網互聯協議）、 ICMP（Internet Control Message Protocol，因特網控制報文協議）、IGMP（Internet Group Management Protocol，Internet 組管理協議）、ARP（Address Resolution Protocol，地址決議協議）等；
• **傳輸層（Transport）：**負責在源主機和目的主機之間的端到端的資料傳輸，并為上層協議提供可靠的資料傳輸服務，主要協議：TCP 協議（Transmission Control Protocol，傳輸控制協議）、UDP 協議（User Datagram Protocol，用戶資料報協議）；
• **會話層（Session）：**負責封裝呼叫 TCP，會話層建立和管理應用程式之間的通信，封裝了呼叫 TCP 去打包，然后呼叫 IP 協議去找路由等操作；
• **表示層（presentation）：**負責解決不同系統之間的通信語法問題（資料格式化，代碼轉換，資料加密）；
• **應用層（Application）：**負責向用戶提供網路服務，包括檔案傳輸、電子郵件、遠程登錄等，主要協議：FTP（檔案傳送協議）、Telnet（遠程登錄協議）、DNS（域名決議協議）、SMTP（郵件傳送協議），POP3協議（郵局協議），HTTP協議（Hyper Text Transfer Protocol），

HTTP 發展史

HTTP 協議和 HTTPS 協議

HTTP（Hypertext Transfer Protocol）中文名為超文本傳輸協議，其作用是把超文本資料從網路傳輸到本地瀏覽器，能夠高效而準確地傳輸超文本檔案，HTTP 是由萬維網協會（World Wide Web Consortium）和 Internet 作業小組 IETF（Interner Engineering Task Force）合作制定的規范，目前被廣泛使用的是 HTTP 1.1 版本，如今也有不少網站支持 HTTP 2.0 版本，

HTTP 協議的特點：

• 應用層協議，由請求和回應構成，是一個標準的客戶端服務器模型；
• 無狀態的協議，對客戶端沒有狀態存盤，對事物處理沒有“記憶”能力，比如訪問一個網站需要反復進行登錄操作；
• 通常承載于 TCP 協議之上；
• 由請求和回應構成，是一個標準的客戶端服務器模型（B/S）；
• 永遠都是客戶端發起請求，服務器回送回應；
• 通信使用明文、請求和回應不會對通信方進行確認、無法保護資料的完整性；
• 雙向協議，例如在上網沖浪時，瀏覽器是請求方 A，百度網站就是應答方 B，雙方約定用 HTTP 協議來通信，于是瀏覽器把請求資料發送給網站，網站再把一些資料回傳給瀏覽器，最后由瀏覽器渲染在螢屏，就可以看到圖片、視頻了，

HTTPS（Hypertext Transfer Protocol over Secure Socket Layer）是一種通過計算機網路進行安全通信的傳輸協議，經由 HTTP 進行通信，利用 SSL/TLS 建立全信道，加密資料包，HTTPS 使用的主要目的是提供對網站服務器的身份認證，同時保護交換資料的隱私與完整性，相當于 HTTP 協議的安全版，

HTTPS 協議的特點：

• **內容加密：**建立了一個資訊安全通道，保證資料傳輸的安全性；
• **身份驗證：**確認網站的真實性，凡是使用 HTTPS 協議的網站，都可以通過單機瀏覽器地址欄的鎖頭標志來查看網站認證之后的真實資訊，此外還可以通過 CA 機構頒發的安全簽章來查詢；
• **保護資料完整性：**防止傳輸的內容被中間人冒充或者篡改，

時勢發展：

• 蘋果公司強制所有 iOS APP 在2017年1月1日前全部改為使用 HTTPS 加密，否則 APP 無法在應用商店上架；
• 谷歌從2017年1月推出的 Chrome 56 開始，對未進行 HTTPS 加密的網址亮出風險提示，即在地址欄的顯著位置提示用戶”此網頁不安全“；
• 騰訊微信小程式的官方需求檔案要求后臺使用 HTTPS 請求進行網路通信，不滿足條件的域名和協議無法正常請求，

HTTP 和 HTTPS 的區別主要如下：

• HTTPS 協議需要到 CA 申請證書，一般免費證書較少，因而需要一定費用；
• HTTP 是超文本傳輸協議，資訊是明文傳輸，HTTPS 則是具有安全性的 SSL 加密傳輸協議；
• HTTP 和 HTTPS 使用的是完全不同的連接方式，用的埠也不一樣，前者是80，后者是443；
• HTTP 的連接很簡單，是無狀態的；HTTPS 協議是由 SSL+HTTP 協議構建的可進行加密傳輸、身份認證的網路協議，比 HTTP 協議安全，

上述 HTTPS 看起來是加強版的 HTTP，可圈可點，但并不是完美無缺的：

• HTTPS 協議的加密范圍也比較有限，在黑客攻擊、拒絕服務攻擊、服務器劫持等方面幾乎起不到什么作用；
• SSL 證書的信用鏈體系并不安全，特別是在某些國家可以控制 CA 根證書的情況下，中間人攻擊一樣可行；
• SSL 證書需要購買申請，功能越強大的證書費用越高；
• SSL 證書通常需要系結 IP，不能在同一 IP 上系結多個域名，IPv4 資源不可能支撐這個消耗（SSL 有擴展可以部分解決這個問題，但是比較麻煩，而且要求瀏覽器、作業系統支持）；
• 根據 ACM CoNEXT 資料顯示，使用HTTPS協議會使頁面的加載時間延長近50%，增加10%到20%的耗電；
• HTTPS 連接快取不如 HTTP 高效，流量成本高；
• HTTPS 連接服務器端資源占用高很多，支持訪客多的網站需要投入更大的成本；
• HTTPS 協議握手階段比較費時，對網站的回應速度有影響，影響用戶體驗，比較好的方式是采用分而治之，比如首頁用 HTTP，用戶資訊相關頁用 HTTPS，

HTTP 請求程序

HTTP 由請求和回應構成，是一個標準的客戶端服務器模型（B/S），HTTP 協議永遠都是客戶端發起請求，服務器回送回應，HTTP 是一個無狀態的協議，無狀態是指客戶機（Web 瀏覽器）和服務器之間不需要建立持久的連接，這意味著當一個客戶端向服務器端發出請求，然后服務器回傳回應（response），連接就被關閉了，在服務器端不保留連接的有關資訊，HTTP 遵循請求(Request)/應答(Response)模型，客戶機（瀏覽器）向服務器發送請求，服務器處理請求并回傳適當的應答，所有 HTTP 連接都被構造成一套請求和應答，

HTTP 請求/回應的步驟：

1. 客戶端連接到 Web 服務器：一個 HTTP 客戶端，通常是瀏覽器，與 Web 服務器的 HTTP 埠（默認為80）建立一個 TCP 套接字連接；
2. 發送 HTTP 請求：通過 TCP 套接字，客戶端向 Web 服務器發送一個文本的請求報文，一個請求報文由請求行、請求頭部、空行和請求資料四部分組成；
3. 服務器接受請求并回傳 HTTP 回應：Web 服務器決議請求，定位請求資源，服務器將資源復本寫到 TCP 套接字，由客戶端讀取，一個回應由狀態行、回應頭部、空行和回應資料四部分組成；
4. 釋放連接 TCP 連接：若 connection 模式為 close，則服務器主動關閉 TCP 連接，客戶端被動關閉連接，釋放 TCP 連接;若 connection 模式為 keepalive，則該連接會保持一段時間，在該時間內可以繼續接收請求；
5. 客戶端瀏覽器決議 HTML 內容：客戶端瀏覽器首先決議狀態行，查看表明請求是否成功的狀態代碼，然后決議每一個回應頭，回應頭告知以下為若干位元組的 HTML 檔案和檔案的字符集，客戶端瀏覽器讀取回應資料 HTML，根據 HTML 的語法對其進行格式化，并在瀏覽器視窗中顯示，

步驟簡述：

1. 瀏覽器向 DNS 服務器請求決議該 URL 中的域名所對應的 IP 地址；
2. 決議出 IP 地址后，根據該 IP 地址和默認埠 80，和服務器建立 TCP 連接；
3. 瀏覽器發出讀取檔案(URL 中域名后面部分對應的檔案)的 HTTP 請求，該請求報文作為 TCP 三次握手的第三個報文的資料發送給服務器；
4. 服務器對瀏覽器請求作出回應，并把對應的 HTML 文本發送給瀏覽器；
5. 釋放 TCP 連接；
6. 瀏覽器將該 HTML 文本并顯示內容，

HTTP 請求/回應模型:

通俗點講就是在瀏覽器地址欄輸入一個 URL，按下回車之后便可觀察到對應的頁面內容，實際上，這個程序是瀏覽器先向網站所在的服務器發送一個請求，網站服務器接收到請求后對其進行處理和決議，然后回傳對應的回應，接著傳回瀏覽器，由于回應里包含頁面的源代碼等內容，所以瀏覽器在對其進行決議，便將網頁呈現出來，

HTTP 請求方法

HTTP/1.1 協議中共定義了八種方法（有時也叫“動作”），來表明 Request-URL 指定的資源不同的操作方式，HTTP1.0 定義了三種請求方法：GET，POST 和 HEAD 方法，HTTP1.1 新增的五種請求方法：OPTIONS，PUT，DELETE，TRACE 和 CONNECT 方法：

1. OPTIONS：回傳服務器針對特定資源所支持的 HTTP 請求方法，也可以利用向 web 服務器發送 ‘*’ 的請求來測驗服務器的功能性；
2. HEAD：向服務器索與 GET 請求相一致的回應，只不過回應體將不會被回傳，這一方法可以再不必傳輸整個回應內容的情況下，就可以獲取包含在回應報頭中的元資訊；
3. GET：向特定的資源發出請求，并回傳物體主體；
4. POST：向指定資源提交資料進行處理請求（例如提交表單或者上傳檔案），資料被包含在請求體中，POST 請求可能會導致新的資源的建立和/或已有資源的修改；
5. PUT：向指定資源位置上傳其最新內容；
6. DELETE：請求服務器洗掉 Request-URL 所標識的資源；
7. TRACE：回顯服務器收到的請求，主要用于測驗或診斷；
8. CONNECT：把服務器仿作跳板，讓服務器代替客戶端訪問其他網頁，

最為常見的請求方法是 GET 和 POST，在瀏覽器地址欄輸入一個 URL，按下回車，即發起了一個 GET 請求，請求的引數會直接包含到 URL 里；POST 請求大多在提交表單時發起，例如登錄，輸入用戶名和密碼，點擊登錄即發起一個 POST 請求，其資料通常以表單的形式傳輸，而不會體現在 URL 中，GET 和 POST 請求方法區別如下：

• GET 請求中的引數包含在 URL 里，資料可以在 URL 中看到；而 POST 請求的 URL 不會包含這些資料，資料都是通過表單形式傳輸的，會包含在函式體中；

• GET 請求提交的資料最多只有 1024 位元組，POST 方式則沒有限制；

• GET 請求是不安全的，因為在傳輸程序中，引數資料直接暴露在 URL 上，所以不能用來傳遞敏感資訊；

• GET 請求引數會完整的保留在瀏覽器的歷史記錄中，POST 請求的引數不會保留；

• GET 請求在瀏覽器回退的時候是無害的，POST 請求會再次提交資料；

• GET 請求在瀏覽器中可以被主動 cache（快取），而 POST 請求不會，可以手動設定；

• GET 請求產生的 URL 地址是可以被 bookmark（添加書簽）的，POST 請求不可以；

• GET 請求只允許 ASCII 碼，POST 請求沒有限制，允許二進制資料；

• GET 請求的執行效率比 POST 請求好；

• 對于 GET 請求，瀏覽器會把 http header 和 data 一起發送出去，服務器回應200，請求成功；

  對于POST請求，瀏覽器先發送 header，服務器會回應100（已經收到請求的第一部分，正在等待其余部分），瀏覽器再次發送 data，服務器回傳200，請求成功；

  簡而言之：GET 產生一個 TCP 資料包，POST 產生兩個 TCP 資料包，不過并不是所有瀏覽器都會在 POST 中發送兩次包，Firefox（火狐）就只發送一次；

HTTP 請求頭

HTTP 請求頭（HTTP Request Header）提供了關于請求，回應或者其他的發送物體的資訊，HTTP 的頭資訊包括通用頭、請求頭、回應頭和物體頭四個部分：

1. 通用頭標：即可用于請求，也可用于回應，是作為一個整體而不是特定資源與事務相關聯；
2. 請求頭標：允許客戶端傳遞關于自身的資訊和希望的回應形式；
3. 回應頭標：服務器和于傳遞自身資訊的回應；
4. 物體頭標：定義被傳送資源的資訊，即可用于請求，也可用于回應，

每個頭域由一個域名，冒號（:）和域值三部分組成，常用的 HTTP 請求頭如下：

• Accept：請求報頭域，用于指定客戶端可接受那些型別的資訊；

  Accept: application/json 瀏覽器可以接受服務器回發的型別為 application/json；

  Accept: */* 代表瀏覽器可以處理所有型別,(一般瀏覽器發給服務器都是發這個)；

• Accept-Encoding：用于指定客戶端可接受的內容編碼，通常指定壓縮方法，是否支持壓縮，支持什么壓縮方法（gzip，deflate）；

• Accept-Language：用于指定客戶端可接受的語言型別（zh-cn,zh;q=0.5：支持的語言分別是簡體中文和中文，優先支持簡體中文）；

• Content-type：也叫互聯網媒體型別（Internet Media Type）或者 MIME 型別，在 HTTP 協議訊息頭中用來表示具體請求中的媒體型別資訊（text/html：HTML 格式、image/gif：GIF 圖片、application/json：JSON 型別、application/x-www-form-urlencoded：表單資料、multipart/form-data：表單檔案上傳等）；

• Host：請求報頭域主要用于指定被請求資源的 Internet 主機和埠號，其內容為請求 URL 的原始服務器或網關的位置，從 HTTP1.1 版本開始，請求必須包含此內容；

• Referer：用于標識請求是從哪個頁面發過來的，服務器可以拿到這一資訊并做相應的處理，如做來源統計、防盜鏈處理等；

• User-Agent：簡稱 UA，這是一個特殊的字串頭，可以使服務器識別客戶端使用的作業系統及版本、瀏覽器及版本等資訊；

• Connection：表示是否需要持久連接（HTTP 1.1默認進行持久連接）；

• Date：請求發送的日期和時間；

• Expect：請求的特定的服務器行為；

• Warning：關于訊息物體的警告資訊；

• Max-Forwards：限制資訊通過代理和網關傳送的時間；

• Cookie：主要功能更是維持當前訪問會話，用來存盤一些用戶資訊以便讓服務器辨別用戶身份的（大多數需要登錄的網站上面會比較常見），比如 Cookie 會存盤一些用戶的用戶名和密碼，當用戶登錄后就會在客戶端產生一個 Cookie 來存盤相關資訊，這樣瀏覽器通過讀取 Cookie 的資訊去服務器上驗證并通過后會判定你是合法用戶，從而允許查看相應網頁；

HTTP 回應頭

HTTP 回應頭（HTTP Responses Header）中包含了服務器對請求的應答資訊，HTTP回應也由四個部分組成，分別是：狀態行、訊息報頭、空行和回應正文：

1. 狀態行：由 HTTP 協議版本號， 狀態碼， 狀態訊息 三部分組成；
2. 訊息報頭：用來說明客戶端要使用的一些附加資訊；
3. 空行：訊息報頭后面的空行是必須的；
4. 回應正文：服務器回傳給客戶端的文本資訊，

常用的 HTTP 回應頭如下：

• Accept-Ranges：表明服務器是否支持指定范圍請求及哪種型別的分段請求；
• Allow：對某網路資源的有效的請求行為，不允許則回傳405；
• Cache-Control：告訴所有的快取機制是否可以快取及哪種型別；
• Content-Language：回應體的語言；
• Content-Length：回應體的長度；
• Content-Location：請求資源可替代的備用的另一地址；
• Content-Range：在整個回傳體中本部分的位元組位置；
• Content-Type：回傳內容的 MIME 型別；
• Date：原始服務器訊息發出的時間；
• Expires：回應過期的日期和時間，可以讓代理服務器或瀏覽器將加載的內容更新到快取中，當再次訪問相同的內容時，就可以直接從快取中加載，達到降低服務器負載、縮短加載時間的目的；
• Location：用來重定向接收方到非請求 URL 的位置來完成請求或標識新的資源；
• Proxy-Authenticate：它指出認證方案和可應用到代理的該 URL 上的引數；
• refresh：應用于重定向或一個新的資源被創造，在5秒之后重定向（由網景提出，被大部分瀏覽器支持）；
• Server：包含服務器的資訊，例如名稱、版本號等；
• Set-Cookie：設定 Http Cookie，回應頭中的 Set-Cookie 用于告訴瀏覽器需要將此內容放在 Cookie 中，下次請求時將 Cookie 攜帶上；
• Warning：警告物體可能存在的問題；
• WWW-Authenticate：表明客戶端請求物體應該使用的授權方案，

HTTP 回應狀態碼

**1xx：**該狀態碼表示臨時回應并需要請求者繼續執行操作

• 100（繼續）：請求者應當繼續提出請求，服務器已收到請求的第一部分，正在等待剩余部分；
• 101（切換協議）：請求者要求服務器切換協議，服務器也已確認切換協議；

**2xx：**該狀態碼表示成功

• 200（成功）：服務器已成功處理請求，一般這表示服務器正常處理了請求，并且正常回傳了相應的頁面；
• 201（已創建）：請求成功并且服務器成功創建新資源；
• 202（已接受）：服務器已接收請求，但仍未處理；
• 203（非授權資訊）：服務器成功處理請求，但是回傳的資訊可能來自另外一來源;
• 204（無內容）：服務器成功處理請求，但是沒有回傳任何內容；
• 205（重置內容）：服務器成功處理請求，但沒有回傳任何內容；
• 206（部分內容）：服務器成功處理了部分GET請求；

**3xx：**該狀態碼表示要完成請求，需要進一步操作，通常這些狀態碼用來重定向

• 300（多鐘選擇）：針對請求，服務器可以執行多種操作，服務器可以根據請求者的（user-agent）選擇一項操作，或者提供操作串列供請求者選擇；
• 301（永久移動）：請求的網頁已永久移動到新的位置，服務器回傳該狀態碼時，會自動將請求者轉到新位置；
• 302（臨時移動）：服務器目前從不同位置的網頁回應請求，但請求者應繼續使用原有位置進行后續的請求；
• 303（查看其它位置）：請求者應當對不同的位置使用單獨的 GET 請求來檢索回應時，服務器回傳此狀態碼；
• 304（未修改）：自從上次請求后，請求的網頁未修改過，服務器回傳此狀態碼時，不會回傳網頁內容；
• 305（使用代理）：請求者只能使用代理訪問請求的網頁；
• 307（臨時重定向）：服務器目前從不同位置的網頁回應請求，但請求者應繼續使用原有位置來進行后續請求；

**4xx：**表示請求可能出錯，妨礙了服務器的處理

• 400（錯誤請求）：表示客戶端請求的語法錯誤，服務器無法理解；
• 401（未授權）：請求要求身份驗證，一般需要登錄的網站，服務器可能會回傳此狀態碼；
• 402：保留；
• 403（禁止）：服務器理解請求客戶端的請求，拒絕請求；
• 404（未找到）：服務器無法根據客戶端請求找到資源；
• 405（方法禁用）：禁用請求中指定的方法；
• 406（不接受）：無法使用請求的內容特性回應請求的網頁；
• 407（需要代理授權）：此狀態碼與401類似，但指定請求者應當授權使用代理；
• 408（請求超時）：服務器等候請求時超時；
• 409（沖突）：服務器在完成請求是發生沖突，服務器必須在回應中包含有關沖突的資訊；
• 410（已洗掉）：請求的資源已永久洗掉；
• 411（需要有效長度）：服務器不接受不含有效內容長度標頭欄位的請求；
• 412（未滿足前提條件）：服務器未滿足請求者在請求中設定的其中一個前提條件；
• 413（請求物體過大）：相應物體過大，服務器拒絕處理當前請求，請求超過服務器所能處理和允許處理的最大值；
• 414（請求的url過長）：請求的url過長，服務器無法處理；
• 415（不支持的媒體型別）：請求的格式不受請求頁面的支持；
• 416（請求范圍不符合要求）：如果頁面無法提供請求的范圍，服務器則會回傳此狀態碼；
• 417（未滿足期望值）：在請求頭 Expect 指定的預期內容無法被服務器滿足；
• 422（不可處理的物體）：請求格式正確，但由于含有語意錯誤，無法回應；

**5xx：**表示服務器在嘗試處理請求時發生內部錯誤，這些錯誤可能是服務器本身的錯誤，并不是請求出錯，當然也有可能是請求者的故意為之，使服務器本身出現錯誤

• 500（服務器內部錯誤）：服務器遇到一個未預料到的狀況，導致無法完成對請求的處理；
• 501（尚未實施）：服務器不具備完成請求的功能；
• 502（錯誤網關）：服務器作為網關或者代理，從上游服務器收到無效回應；
• 503（服務不可用）：服務器目前無法使用；
• 504（網關超時）：服務器作為網關或代理，但未及時收到上游服務器的回應；
• 505（HTTP版本不受支持）：服務器不支持請求中所用的 HTTP 版本，

標籤：其他

上一篇：Java基礎語法:型別轉換、變數、常量

下一篇：Java-反射