爬蟲開發技術基礎教程之HTTP基礎.

時間  2019-12-06
標籤 爬蟲 開發 技術 基礎 教程 http 欄目 網絡爬蟲 简体版
原文   原文鏈接

HTTP簡介

HTTP協議是創建在TCP之上的無狀態應用層協議，用於收發網絡資源（一般是HTML頁面），默認使用80端口。php

HTTP報文

請求報文

HTTP 協議是以 ASCII 碼傳輸，創建在 TCP/IP 協議之上的應用層規範。規範把 HTTP 請求分爲三個部分：狀態行、請求頭、消息主體。相似於下面這樣：html

<method> <request-URL> <version>
<headers>

<entity-body>

HTTP定義了與服務器交互的不一樣方法，最基本的方法有4種，分別是GET，POST，PUT，DELETE。URL全稱是資源描述符，咱們能夠這樣認爲：一個URL地址，它用於描述一個網絡上的資源，而 HTTP 中的GET，POST，PUT，DELETE就對應着對這個資源的查，增，改，刪4個操做。python

  1. GET用於信息獲取，並且應該是安全的 和 冪等的。git

所謂安全的意味着該操做用於獲取信息而非修改信息。換句話說，GET 請求通常不該產生反作用。就是說，它僅僅是獲取資源信息，就像數據庫查詢同樣，不會修改，增長數據，不會影響資源的狀態。github

冪等的意味着對同一URL的多個請求應該返回一樣的結果。chrome

GET請求提交的參數在URL裏，爲 ? 後面的部分，以下面的示例，其中參數爲sex和name，其值分別爲 man 和 Professional。數據庫

GET請求報文示例：編程

GET /books/?sex=man&name=Professional HTTP/1.1
 Host: www.example.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

  1. POST表示可能修改變服務器上的資源的請求。json

    POST / HTTP/1.1
 Host: www.example.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-Alive

 sex=man&name=Professional

  2. 注意:後端

    • GET 可提交的數據量受到URL長度的限制，HTTP 協議規範沒有對 URL 長度進行限制。這個限制是特定的瀏覽器及服務器對它的限制

    • 理論上講，POST 是沒有大小限制的，HTTP 協議規範也沒有進行大小限制，出於安全考慮，服務器軟件在實現時會作必定限制

    • 參考上面的報文示例，能夠發現 GET 和 POST 數據內容是如出一轍的，只是位置不一樣，一個在URL裏，一個在 HTTP 包的包體裏

    • GET 方法訪問的地址一般複製到瀏覽器地址欄，能夠直接訪問結果，而POST方法必須藉助工具（如 POSTman 或者 CURL命令等）來進行訪問。

POST 提交數據的方式

HTTP 協議中規定 POST 提交的數據必須在 body 部分中，可是協議中沒有規定數據使用哪一種編碼方式或者數據格式。實際上，開發者徹底能夠本身決定消息主體的格式，只要最後發送的 HTTP 請求知足上面的格式就能夠。

可是，數據發送出去，還要服務端解析成功纔有意義。通常服務端語言如 php、python 等，以及它們的 framework，都內置了自動解析常見數據格式的功能。服務端一般是根據請求頭（headers）中的 Content-Type 字段來獲知請求中的消息主體是用何種方式編碼，再對主體進行解析。因此說到 POST 提交數據方案，包含了 Content-Type 和消息主體編碼方式兩部分。下面就正式開始介紹它們：

  • application/x-www-form-urlencoded

這是最多見的 POST 數據提交方式。瀏覽器的原生 <form> 表單，若是不設置 enctype 屬性，那麼最終就會以 application/x-www-form-urlencoded 方式提交數據。上個小節當中的例子即是使用了這種提交方式。能夠看到 body 當中的內容和 GET 請求是徹底相同的。

  • multipart/form-data

這又是一個常見的 POST 數據提交的方式。咱們使用表單上傳文件時，必須讓 <form> 表單的 enctype 等於 multipart/form-data。直接來看一個請求示例：

POST http://www.example.com HTTP/1.1
Content-Type:multipart/form-data; boundary=----WebKitFormBoundaryrGKCBY7qhFd3TrwA

------WebKitFormBoundaryrGKCBY7qhFd3TrwA
Content-Disposition: form-data; name="text"

title
------WebKitFormBoundaryrGKCBY7qhFd3TrwA
Content-Disposition: form-data; name="file"; filename="chrome.png"
Content-Type: image/png

PNG ... content of chrome.png ...
------WebKitFormBoundaryrGKCBY7qhFd3TrwA--

這個例子稍微複雜點。首先生成了一個 boundary 用於分割不一樣的字段，爲了不與正文內容重複，boundary 很長很複雜。而後 Content-Type 裏指明瞭數據是以 multipart/form-data 來編碼，本次請求的 boundary 是什麼內容。消息主體裏按照字段個數又分爲多個結構相似的部分，每部分都是以 --boundary 開始，緊接着是內容描述信息，而後是回車，最後是字段具體內容（文本或二進制）。若是傳輸的是文件，還要包含文件名和文件類型信息。消息主體最後以 --boundary-- 標示結束。關於 multipart/form-data 的詳細定義，請前往 RFC1867 查看（或者相對友好一點的 MDN 文檔）。

這種方式通常用來上傳文件，各大服務端語言對它也有着良好的支持。

上面提到的這兩種 POST 數據的方式，都是瀏覽器原生支持的，並且現階段標準中原生 <form> 表單也只支持這兩種方式（經過 <form> 元素的 enctype 屬性指定，默認爲 application/x-www-form-urlencoded。其實 enctype 還支持 text/plain，不過用得很是少）。

隨着愈來愈多的 Web 站點，尤爲是 WebApp，所有使用 Ajax 進行數據交互以後，咱們徹底能夠定義新的數據提交方式，例如 application/json，text/xml，乃至 application/x-protobuf 這種二進制格式，只要服務器能夠根據 Content-Type 和 Content-Encoding 正確地解析出請求，都是沒有問題的。

條件 GET

HTTP 條件 GET 是 HTTP 協議爲了減小沒必要要的帶寬浪費，提出的一種方案。詳見 RFC2616 。

  1. HTTP 條件 GET 使用的時機？

客戶端以前已經訪問過某網站，並打算再次訪問該網站。

  1. HTTP 條件 GET 使用的方法？

客戶端向服務器發送一個包詢問是否在上一次訪問網站的時間後是否更改了頁面，若是服務器沒有更新，顯然不須要把整個網頁傳給客戶端，客戶端只要使用本地緩存便可，若是服務器對照客戶端給出的時間已經更新了客戶端請求的網頁，則發送這個更新了的網頁給用戶。

下面是一個具體的發送接受報文示例：

客戶端發送請求：

GET / HTTP/1.1  
 Host: www.sina.com.cn:80  
 If-Modified-Since:Thu, 4 Feb 2010 20:39:13 GMT  
 Connection: Close

第一次請求時，服務器端返回請求數據，以後的請求，服務器根據請求中的 If-Modified-Since 字段判斷響應文件沒有更新，若是沒有更新，服務器返回一個 304 Not Modified響應，告訴瀏覽器請求的資源在瀏覽器上沒有更新，可使用已緩存的上次獲取的文件。

HTTP/1.0 304 Not Modified  
 Date: Thu, 04 Feb 2010 12:38:41 GMT  
 Content-Type: text/html  
 Expires: Thu, 04 Feb 2010 12:39:41 GMT  
 Last-Modified: Thu, 04 Feb 2010 12:29:04 GMT  
 Age: 28  
 X-Cache: HIT from sy32-21.sina.com.cn  
 Connection: close

若是服務器端資源已經更新的話，就返回正常的響應。

響應報文

HTTP 響應與 HTTP 請求類似，HTTP響應也由3個部分構成，分別是：

  • 狀態行

  • 響應頭(Response Header)

  • 響應正文

狀態行由協議版本、數字形式的狀態代碼、及相應的狀態描述，各元素之間以空格分隔。

常見的狀態碼有以下幾種：

  • 200 OK 客戶端請求成功

  • 301 Moved Permanently 請求永久重定向

  • 302 Moved Temporarily 請求臨時重定向

  • 304 Not Modified 文件未修改，能夠直接使用緩存的文件。

  • 400 Bad Request 因爲客戶端請求有語法錯誤，不能被服務器所理解。

  • 401 Unauthorized 請求未經受權。這個狀態代碼必須和WWW-Authenticate報頭域一塊兒使用

  • 403 Forbidden 服務器收到請求，可是拒絕提供服務。服務器一般會在響應正文中給出不提供服務的緣由

  • 404 Not Found 請求的資源不存在，例如，輸入了錯誤的URL

  • 500 Internal Server Error 服務器發生不可預期的錯誤，致使沒法完成客戶端的請求。

  • 503 Service Unavailable 服務器當前不可以處理客戶端的請求，在一段時間以後，服務器可能會恢復正常。

下面是一個HTTP響應的例子：

HTTP/1.1 200 OK

Server:Apache Tomcat/5.0.12
Date:Mon,6Oct2003 13:23:42 GMT
Content-Length:112

<html>...

RESTful API

隨着開發技術的發展，愈來愈多的複雜功能被放置到了網站上，網站能夠被理解爲下載到瀏覽器裏執行的軟件，而這個網站與後端系統有頻繁和複雜的通訊；同時，隨着移動互聯網的興起，開發人員傾向於APP和網站使用統一的通訊接口，從而減少開發和維護的工做量。

RESTful架構便是目前最流行的一種互聯網軟件架構。它結構清晰、符合標準、易於理解、擴展方便，正獲得愈來愈多網站的採用。（REST 是 Representational State Transfer 的縮寫）

  1. 資源（Resources）

REST的名稱"表現層狀態轉化"中，省略了主語。"表現層"其實指的是"資源"（Resources）的"表現層"。

所謂"資源"，就是網絡上的一個實體，或者說是網絡上的一個具體信息。它能夠是一段文本、一張圖片、一首歌曲、一種服務，總之就是一個具體的實在。你能夠用一個URI（統一資源定位符）指向它，每種資源對應一個特定的URI。要獲取這個資源，訪問它的URI就能夠，所以URI就成了每個資源的地址或獨一無二的識別符。

所謂"上網"，就是與互聯網上一系列的"資源"互動，調用它的URI。

  1. 表現層（Representation）

"資源"是一種信息實體，它能夠有多種外在表現形式。咱們把"資源"具體呈現出來的形式，叫作它的"表現層"（Representation）。

好比，文本能夠用txt格式表現，也能夠用HTML格式、XML格式、JSON格式表現，甚至能夠採用二進制格式；圖片能夠用JPG格式表現，也能夠用PNG格式表現。

URI只表明資源的實體，不表明它的形式。嚴格地說，有些網址最後的".html"後綴名是沒必要要的，由於這個後綴名錶示格式，屬於"表現層"範疇，而URI應該只表明"資源"的位置。它的具體表現形式，應該在HTTP請求的頭信息中用Accept和Content-Type字段指定，這兩個字段纔是對"表現層"的描述。

  1. 狀態轉化（State Transfer）

訪問一個網站，就表明了客戶端和服務器的一個互動過程。在這個過程當中，勢必涉及到數據和狀態的變化。

互聯網通訊協議HTTP協議，是一個無狀態協議。這意味着，全部的狀態都保存在服務器端。所以，若是客戶端想要操做服務器，必須經過某種手段，讓服務器端發生"狀態轉化"（State Transfer）。而這種轉化是創建在表現層之上的，因此就是"表現層狀態轉化"。

客戶端用到的手段，只能是HTTP協議。具體來講，就是HTTP協議裏面，四個表示操做方式的動詞：GET、POST、PUT、DELETE。它們分別對應四種基本操做：GET用來獲取資源，POST用來新建資源（也能夠用於更新資源），PUT用來更新資源，DELETE用來刪除資源。

JSON

經過HTTP傳輸的文本數據一般是HTML、XML或者JSON格式。

JSON(JavaScript Object Notation) 是一種輕量級的數據交換格式。 易於人閱讀和編寫。同時也易於機器解析和生成。在API的設計中使用尤其普遍。

JSON建構於兩種結構：

「名稱/值」對的集合（A collection of name/value pairs）。不一樣的語言中，它被理解爲對象（object），紀錄（record），結構（struct），字典（dictionary），哈希表（hash table），有鍵列表（keyed list），或者關聯數組 （associative array）。
值的有序列表（An ordered list of values）。在大部分語言中，它被理解爲數組（array）。
這些都是常見的數據結構。事實上大部分現代計算機語言都以某種形式支持它們。這使得一種數據格式在一樣基於這些結構的編程語言之間交換成爲可能。

如，下面爲京東的商品評論API及返回的JSON格式數據。能夠直接複製該連接到瀏覽器地址欄打開，查看結果。

GET https://item.m.jd.com/ware/getDetailCommentList.json?wareId=4586850
{
  "wareDetailComment": {
    "allCnt": "303",
    "badCnt": "8",
    "canConsultFlag": "true",
    "code": "0",
    "commentInfoList": [
      {
        "commentData": "在京東買電子產品，從沒失望過！好！速度超快！！昨天下午下單，今天11點就到了！牛！",
        "commentDate": "2017-03-15 15:47:52",
        "commentId": "10215478304",
        "commentScore": "5",
        "commentShareUrl": "http://share.m.jd.com/shareOrder/showSharePage.action?productId=4586850&commentId=817a736c-03b5-4bb2-add5-e9bfc9d63327",
        "commentType": "1",
        "guid": "817a736c-03b5-4bb2-add5-e9bfc9d63327",
        "orderDate": "2017-03-14 17:31:18",
        "pictureInfoList": [
          {
            "picURL": "http://img30.360buyimg.com/shaidan/s310x310_jfs/t3061/109/8735941683/32854/f3537a9d/58c8f1a6Nbb778993.jpg",
            "largePicURL": "http://img30.360buyimg.com/shaidan/s640x640_jfs/t3061/109/8735941683/32854/f3537a9d/58c8f1a6Nbb778993.jpg"
          },
          {
            "picURL": "http://img30.360buyimg.com/shaidan/s310x310_jfs/t4483/105/56391975/33044/caacfc3/58c8f1a7N3a2f3283.jpg",
            "largePicURL": "http://img30.360buyimg.com/shaidan/s640x640_jfs/t4483/105/56391975/33044/caacfc3/58c8f1a7N3a2f3283.jpg"
          },
          {
            "picURL": "http://img30.360buyimg.com/shaidan/s310x310_jfs/t4369/292/1941272094/42891/8ef49d7a/58c8f1a6N40c3a49a.jpg",
            "largePicURL": "http://img30.360buyimg.com/shaidan/s640x640_jfs/t4369/292/1941272094/42891/8ef49d7a/58c8f1a6N40c3a49a.jpg"
          }
        ],
        "plusAddress": "https://plus.m.jd.com/index",
        "plusAvailable": "0",
        "praiseCnt": "0",
        "replyCnt": "1",
        "userImgURL": "img30.360buyimg.com/mobile/s60x60_jfs/t493/15/557644423/10532/62d3112/5473e62aNdb4251d8.png",
        "userLevel": "2",
        "userNickName": "只***9",
        "wareAttribute": []
      },
      {
        "commentData": "在官網查過確實是正品，剛開始設置的時候出了點小插曲，不過很快就解決了，如今能夠安心使用了！",
        "commentDate": "2017-03-15 14:08:39",
        "commentId": "10215168513",
        "commentScore": "5",
        "commentShareUrl": "http://share.m.jd.com/shareOrder/showSharePage.action?productId=4586850&commentId=6eac73a8-5ea3-47d2-8672-3402bd940c8b",
        "commentType": "1",
        "guid": "6eac73a8-5ea3-47d2-8672-3402bd940c8b",
        "orderDate": "2017-03-13 18:35:34",
        "pictureInfoList": [
          {
            "picURL": "http://img30.360buyimg.com/shaidan/s310x310_jfs/t3118/52/8822524381/41316/3ddbbeff/58c8da66Ne2e4f805.jpg",
            "largePicURL": "http://img30.360buyimg.com/shaidan/s640x640_jfs/t3118/52/8822524381/41316/3ddbbeff/58c8da66Ne2e4f805.jpg"
          }
        ],
        "plusAddress": "https://plus.m.jd.com/index",
        "plusAvailable": "0",
        "praiseCnt": "1",
        "replyCnt": "1",
        "userImgURL": "img30.360buyimg.com/mobile/s60x60_jfs/t493/15/557644423/10532/62d3112/5473e62aNdb4251d8.png",
        "userLevel": "1",
        "userNickName": "7***7",
        "wareAttribute": []
      },
      {
        "commentData": "圖片是我蘋果5拍的。昨天蘋果6到手，下載完了所需app，內存足夠的，還剩16.6g，運行速度還算快，可是估計想玩大遊戲就掃興了。總結吧：比較滿意，可是建議你們仍是加點錢買6s長治久安。哈哈哈",
        "commentDate": "2017-03-16 12:42:34",
        "commentId": "10217967740",
        "commentScore": "5",
        "commentShareUrl": "http://share.m.jd.com/shareOrder/showSharePage.action?productId=4586850&commentId=bc436fcf-d814-4b01-a19b-572c597aa516",
        "commentType": "0",
        "guid": "bc436fcf-d814-4b01-a19b-572c597aa516",
        "orderDate": "2017-03-12 19:10:32",
        "pictureInfoList": null,
        "plusAddress": "https://plus.m.jd.com/index",
        "plusAvailable": "0",
        "praiseCnt": "0",
        "replyCnt": "0",
        "userImgURL": "img30.360buyimg.com/mobile/s60x60_jfs/t493/15/557644423/10532/62d3112/5473e62aNdb4251d8.png",
        "userLevel": "2",
        "userNickName": "q***0",
        "wareAttribute": []
      }
    ],
    "consultationCount": "13",
    "goodCnt": "290",
    "normalCnt": "5",
    "pictureCnt": "53",
    "showPicCnt": "53"
  }
}

關於JSON的詳細介紹可參考：http://www.json.org/json-zh.html。

XMLHttpRequest

XMLHttpRequest是一個瀏覽器接口，使得Javascript能夠進行HTTP(S)通訊。XMLHttpRequest 對象用於在後臺與服務器交換數據，這樣就能夠

  • 在不從新加載頁面的狀況下更新網頁

  • 在頁面已加載後從服務器請求數據

  • 在頁面已加載後從服務器接收數據

  • 在後臺向服務器發送數據

會話跟蹤

  1. 什麼是會話？

客戶端打開與服務器的鏈接發出請求到服務器響應客戶端請求的全過程稱之爲會話。

  1. 什麼是會話跟蹤？

會話跟蹤指的是對同一個用戶對服務器的連續的請求和接受響應的監視。

  1. 爲何須要會話跟蹤？

瀏覽器與服務器之間的通訊是經過HTTP協議進行通訊的，而HTTP協議是」無狀態」的協議，它不能保存客戶的信息，即一次響應完成以後鏈接就斷開了，下一次的請求須要從新鏈接，這樣就須要判斷是不是同一個用戶，因此纔有會話跟蹤技術來實現這種要求。

  1. 會話跟蹤經常使用的方法:

    1. URL重寫

    URL(統一資源定位符)是Web上特定頁面的地址，URL重寫的技術就是在URL結尾添加一個附加數據以標識該會話,把會話ID經過URL的信息傳遞過去，以便在服務器端進行識別不一樣的用戶。

    1. 隱藏表單域

    將會話ID添加到HTML表單元素中提交到服務器，此表單元素並不在客戶端顯示

    1. Cookie

    Cookie是Web服務器發送給客戶端的一小段信息，客戶端請求時能夠讀取該信息發送到服務器端，進而進行用戶的識別。對於客戶端的每次請求，服務器都會將Cookie發送到客戶端,在客戶端能夠進行保存,以便下次使用。

    客戶端能夠採用兩種方式來保存這個Cookie對象，一種方式是保存在客戶端內存中，稱爲臨時Cookie，瀏覽器關閉後這個Cookie對象將消失。另一種方式是保存在客戶機的磁盤上，稱爲永久Cookie。之後客戶端只要訪問該網站，就會將這個Cookie再次發送到服務器上，前提是這個Cookie在有效期內，這樣就實現了對客戶的跟蹤。

    Cookie是能夠被禁止的。

    1. Session:

    每個用戶都有一個不一樣的session，各個用戶之間是不能共享的，是每一個用戶所獨享的，在session中能夠存放信息。

    在服務器端會建立一個session對象，產生一個sessionID來標識這個session對象，而後將這個sessionID放入到Cookie中發送到客戶端，下一次訪問時，sessionID會發送到服務器，在服務器端進行識別不一樣的用戶。

    Session的實現依賴於Cookie，若是Cookie被禁用，那麼session也將失效。

    Session是存儲在服務器端，Cookie是存儲在客戶端，SessionID是Cookie裏的一部分。

持久鏈接

咱們知道 HTTP 協議採用「請求-應答」模式，當使用普通模式，即非 Keep-Alive 模式時，每一個請求/應答客戶和服務器都要新建一個鏈接，完成以後當即斷開鏈接（HTTP協議爲無鏈接的協議）；當使用 Keep-Alive 模式（又稱持久鏈接、鏈接重用）時，Keep-Alive 功能使客戶端到服務器端的鏈接持續有效，當出現對服務器的後繼請求時，Keep-Alive 功能避免了創建或者從新創建鏈接。

在 HTTP 1.0 版本中，並無官方的標準來規定 Keep-Alive 如何工做，所以實際上它是被附加到 HTTP 1.0協議上，若是客戶端瀏覽器支持 Keep-Alive ，那麼就在HTTP請求頭中添加一個字段 Connection: Keep-Alive，當服務器收到附帶有 Connection: Keep-Alive 的請求時，它也會在響應頭中添加一個一樣的字段來使用 Keep-Alive 。這樣一來，客戶端和服務器之間的HTTP鏈接就會被保持，不會斷開（超過 Keep-Alive 規定的時間，意外斷電等狀況除外），當客戶端發送另一個請求時，就使用這條已經創建的鏈接。

在 HTTP 1.1 版本中，默認狀況下全部鏈接都被保持，若是加入 "Connection: close" 才關閉。目前大部分瀏覽器都使用 HTTP 1.1 協議，也就是說默認都會發起 Keep-Alive 的鏈接請求了，因此是否能完成一個完整的 Keep-Alive 鏈接就看服務器設置狀況。

因爲 HTTP 1.0 沒有官方的 Keep-Alive 規範，而且也已經基本被淘汰，如下討論均是針對 HTTP 1.1 標準中的 Keep-Alive 展開的。

注意：

  • HTTP Keep-Alive 簡單說就是保持當前的TCP鏈接，避免了從新創建鏈接。

  • HTTP 長鏈接不可能一直保持，例如 Keep-Alive: timeout=5, max=100，表示這個TCP通道能夠保持5秒，max=100，表示這個長鏈接最多接收100次請求就斷開。

  • HTTP是一個無狀態協議，這意味着每一個請求都是獨立的，Keep-Alive沒能改變這個結果。另外，Keep-Alive也不能保證客戶端和服務器之間的鏈接必定是活躍的，在HTTP1.1版本中也如此。惟一能保證的就是當鏈接被關閉時你能獲得一個通知，因此不該該讓程序依賴於Keep-Alive的保持鏈接特性，不然會有意想不到的後果。

  • 使用長鏈接以後，客戶端、服務端怎麼知道本次傳輸結束呢？兩部分：1. 判斷傳輸數據是否達到了Content-Length 指示的大小；2. 動態生成的文件沒有 Content-Length ，它是分塊傳輸（chunked），這時候就要根據 chunked 編碼來判斷，chunked 編碼的數據在最後有一個空 chunked 塊，代表本次傳輸數據結束，詳見這裏。什麼是 chunked 分塊傳輸呢？下面咱們就來介紹。

Transfer-Encoding

Transfer-Encoding 是一個用來標示 HTTP 報文傳輸格式的頭部值。儘管這個取值理論上能夠有不少，可是當前的 HTTP 規範裏實際上之定義了一種傳輸取值——chunked。

若是一個HTTP消息（請求消息或應答消息）的Transfer-Encoding消息頭的值爲chunked，那麼，消息體由數量未定的塊組成，並以最後一個大小爲0的塊爲結束。

每個非空的塊都以該塊包含數據的字節數（字節數以十六進制表示）開始，跟隨一個CRLF （回車及換行），而後是數據自己，最後塊CRLF結束。在一些實現中，塊大小和CRLF之間填充有白空格（0x20）。

最後一塊是單行，由塊大小（0），一些可選的填充白空格，以及CRLF。最後一塊再也不包含任何數據，可是能夠發送可選的尾部，包括消息頭字段。 消息最後以CRLF結尾。

注意： chunked 和 multipart 兩個名詞在乎義上有相似的地方，不過在 HTTP 協議當中這兩個概念則不是一個類別的。multipart 是一種 Content-Type，標示 HTTP 報文內容的類型，而 chunked 是一種傳輸格式，標示報頭將以何種方式進行傳輸。

HTTP Pipelining（HTTP 管線化）

默認狀況下 HTTP 協議中每一個傳輸層鏈接只能承載一個 HTTP 請求和響應，瀏覽器會在收到上一個請求的響應以後，再發送下一個請求。在使用持久鏈接的狀況下，某個鏈接上消息的傳遞相似於請求1 -> 響應1 -> 請求2 -> 響應2 -> 請求3 -> 響應3。

HTTP Pipelining（管線化）是將多個 HTTP 請求整批提交的技術，在傳送過程當中不需等待服務端的迴應。使用 HTTP Pipelining 技術以後，某個鏈接上的消息變成了相似這樣請求1 -> 請求2 -> 請求3 -> 響應1 -> 響應2 -> 響應3。

注意下面幾點：

  • 管線化機制經過持久鏈接（persistent connection）完成，僅 HTTP/1.1 支持此技術（HTTP/1.0不支持）

  • 只有 GET 和 HEAD 請求能夠進行管線化，而 POST 則有所限制

  • 初次建立鏈接時不該啓動管線機制，由於對方（服務器）不必定支持 HTTP/1.1 版本的協議

  • 管線化不會影響響應到來的順序，如上面的例子所示，響應返回的順序並未改變

  • HTTP /1.1 要求服務器端支持管線化，但並不要求服務器端也對響應進行管線化處理，只是要求對於管線化的請求不失敗便可

  • 因爲上面提到的服務器端問題，開啓管線化極可能並不會帶來大幅度的性能提高，並且不少服務器端和代理程序對管線化的支持並很差，所以現代瀏覽器如 Chrome 和 Firefox 默認並未開啓管線化支持

更多關於 HTTP Pipelining 的知識能夠參考這裏。

HTTPS

HTTP協議是明文傳輸數據，在客戶端和服務器之間截獲通訊流量便可獲取明文，好比代理服務器或者網關等；同時，對於服務器的真僞，客戶端也沒法鑑別。爲了實現較安全的通訊，一般是用HTTPS來保證。

超文本傳輸安全協議（英語：Hypertext Transfer Protocol Secure，縮寫：HTTPS，常稱爲HTTP over TLS，HTTP over SSL或HTTP Secure）是一種網絡安全傳輸協議。在計算機網絡上，HTTPS經由超文本傳輸協議進行通訊，但利用SSL/TLS來加密數據包。HTTPS開發的主要目的，是提供對網絡服務器的身份認證，保護交換數據的隱私與完整性。

使用了HTTPS的網站，現代瀏覽器會在地址欄以綠色鎖形標記進行提示。如：

更多關於 HTTPS 的知識參考維基百科-HTTPS

楚江數據是一家專業的互聯網數據技術服務商，提供網站APP數據採集和爬蟲軟件定製開發服務，服務範圍涵蓋社交網絡、電子商務、分類信息、學術研究等。
官方網站 http://www.chujiangdata.com。

整理自：

  1. https://hit-alibaba.github.io...

  2. http://www.ruanyifeng.com/blo...

相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程