《圖解HTTP》學習筆記(三):HTTP報文內的HTTP信息

HTTP報文

  • 用于HTTP協議交互的信息被稱作為HTTP報文。請求端和服務端分別被叫做請求報文和響應報文。HTTP報文由報文首部和報文主體組成,首部和主體之間由【CR+LF】換行分割,一個HTTP報文不一定需要報文主體。

  • 請求報文首部:請求行、請求首部字段、通用首部字段、實體首部字段、其他。

  • 響應報文首部:狀態行、響應首部字段、通用首部字段、實體首部字段、其他。

  • 請求報文:

    GET / HTTP/1.1  --請求行
    Host:www.baidu.com
    User-Agent:Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.100 Safari/537.36
    Accept:text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
    Accept-Language:zh-CN,zh;q=0.8,en;q=0.6
    Accept-Encoding:gzip, deflate, br
    Upgrade-Insecure-Requests:1
    Cache-Control:max-age=0
    Connection:keep-alive                --各種首部字段
    (CR-LF) --空行
    
  • 響應報文:

    HTTP/1.1 200 OK -- 狀態行
    Bdpagetype:2
    Bdqid:0xb377d200000097b1
    Bduserid:1270621848
    Cache-Control:private
    Connection:Keep-Alive
    Content-Encoding:gzip
    Content-Type:text/html;charset=utf-8
    Date:Wed, 18 Oct 2017 05:57:28 GMT
    Expires:Wed, 18 Oct 2017 05:57:28 GMT
    Server:BWS/1.1
    Set-Cookie:BDSVRTM=187; path=/
    Set-Cookie:BD_HOME=1; path=/
    Set-Cookie:H_PS_PSSID=1450_21119_20929; path=/; domain=.baidu.com
    Strict-Transport-Security:max-age=172800
    Transfer-Encoding:chunked
    X-Ua-Compatible:IE=Edge,chrome=1    -- 各種首部字段
    (CR-LF) -- 空行
    <!Doctype html>
    <html xmlns=http://www.w3.org/1999/xhtml>
    <head>
    ...                                 -- 響應主體
    
  • 請求報文和響應報文的首部內容由以下數據組成:

    • 請求行: 包含用于請求的方法,請求的URI和HTTP版本
    • 狀態行: 包含表面闡述響應結果的狀態碼,原因短語和HTTP版本
    • 首部字段:包含表示請求和響應結果的各種條件和屬性的各類首部。一般有4中首部,分別是:通用首部、請求首部、響應首部、實體首部。
    • 其他: 可能包含HTTP的RFC里沒有定義的首部(Cookie等)。
  • 編碼提升傳輸效率

    通過在傳輸時編碼,能有效地處理大量的訪問請求。但是,編碼的操作需要計算機來完成,因此會消耗更多的CPU等資源。

    • 報文主體和實體主體的差異

      • 報文

        是HTTP通信中的基本你單位,由8位字節流組成,通過HTTP通信傳輸。

      • 實體

        作為請求或響應的有效載荷數據被傳輸,其內容由實體首部和實體主體組成。

      HTTP報文的主體用于傳輸請求或響應的實體主體。

      通常,報文主體等于實體主體,只有在傳輸中進行編碼操作,實體主體的內容會發生變化,才導致它和報文主體產生差異。

  • 壓縮傳輸的內容編碼

    HTTP協議中有一種被稱為內容編碼的功能也能進行類型的操作,內容編碼指明應用在實體內容上的編碼格式,并保持實體信息原樣壓縮。內容編碼后的實體由客戶端接收并負責解碼。

    • 壓縮并解碼.png

常用的內容編碼有以下幾種

  • gzip(GNU zip)

  • compress (UNIX 系統的標準壓縮)

  • deflate (zlib)

  • identity (不進行編碼)

  • 分割發送的分塊傳輸編碼

    • 分塊編碼傳輸.png

在HTTP通信過程中,請求的編碼實體在沒有全部傳輸完成之前,瀏覽器是無法顯示請求頁面的。所以在傳輸大量數據時,通常會把數據分割成多塊。將這種技術稱為 分塊傳輸編碼。

使用分塊傳輸編碼的實體主體會由接收的客戶端負責解碼,恢復到編碼前的實體主體。

  • 發送多種數據的多部分對象集合

    發送郵件時,我們可以在郵件里寫入文字并添加多發附件。這是因為采用了MIME(Multipurpose Internet Mail Extensions,多用途因特網郵件擴展)機制,它允許郵件處理文本、圖片、視頻等多個不同類型的數據。

    HTTP協議中也采納了多部分對象集合,發送的一份報文主體內可含多類型實體。通常是在圖片或文本文件等上傳時使用。

    多部分對象集合包含的對象如下:

    • multipart/form-data

      在Web表單文件上傳使用

    • multipart/byteranges

      狀態碼206響應報文包含了多個范圍的內容時使用。

    • multipart/form-data

      Content-Type: multipart/form-data; boundary=AaB03x
      --AaB03x
      Content-Disposition: form-data; name="field1"
      Joe Blow
      --AaB03x
      Content-Disposition: form-data; name="pics"; filename="file1.txt"
      Content-Type: text/plain
      ...(file1.txt的數據)...
      --AaB03x--
      
    • multipart/byteranges

      HTTP/1.1 206 Partial Content
      Date: Fri, 13 Jul 2012 02:45:26 GMT
      Last-Modified: Fri, 31 Aug 2007 02:02:20 GMT
      Content-Type: multipart/byteranges; boundary=THIS_STRING_SEPARATES
      --THIS_STRING_SEPARATES
      Content-Type: application/pdf
      Content-Range: bytes 500-999/8000
      ...(范圍指定的數據)...
      --THIS_STRING_SEPARATES
      Content-Type: application/pdf
      Content-Range: bytes 7000-7999/8000
      ...(范圍指定的數據)...
      --THIS_STRING_SEPARATES--
      
  • 獲取部分內容的范圍請求

    以前的用戶帶寬不夠,下載一個尺寸稍大的圖片或者文件就會很吃力。如果下載過程中遇到網絡問題中斷了下載,那么就需要從頭開始。為了解決上述問題,就產生了一種叫范圍請求的功能。

    對于一份10000字節大小的資源,如果使用范圍請求,可以只請求5001~10000字節內的資源。

    • 范圍請求.png

執行范圍請求時,會用到首部字段Range來指定資源的byte范圍:

Range: bytes=5001-10000 // 5001-10000字節之間
Range: bytes=5001- // 從5001字節之后全部
Range: bytes=1-3000,5000-10000 // 多范圍指定

針對范圍請求,響應會返回206狀態碼。對于多重范圍請求,響應會在首部字段Content-Type表明multipart/byteranges后返回響應報文

如果服務端無法響應范圍請求,則會返回狀態碼200 OK然后返回完整的實體內容。

github 歡迎Star,歡迎討論

最后編輯于
?著作權歸作者所有,轉載或內容合作請聯系作者
平臺聲明:文章內容(如有圖片或視頻亦包括在內)由作者上傳并發布,文章內容僅代表作者本人觀點,簡書系信息發布平臺,僅提供信息存儲服務。
  • 序言:七十年代末,一起剝皮案震驚了整個濱河市,隨后出現的幾起案子,更是在濱河造成了極大的恐慌,老刑警劉巖,帶你破解...
    沈念sama閱讀 227,882評論 6 531
  • 序言:濱河連續發生了三起死亡事件,死亡現場離奇詭異,居然都是意外死亡,警方通過查閱死者的電腦和手機,發現死者居然都...
    沈念sama閱讀 98,208評論 3 414
  • 文/潘曉璐 我一進店門,熙熙樓的掌柜王于貴愁眉苦臉地迎上來,“玉大人,你說我怎么就攤上這事?!?“怎么了?”我有些...
    開封第一講書人閱讀 175,746評論 0 373
  • 文/不壞的土叔 我叫張陵,是天一觀的道長。 經常有香客問我,道長,這世上最難降的妖魔是什么? 我笑而不...
    開封第一講書人閱讀 62,666評論 1 309
  • 正文 為了忘掉前任,我火速辦了婚禮,結果婚禮上,老公的妹妹穿的比我還像新娘。我一直安慰自己,他們只是感情好,可當我...
    茶點故事閱讀 71,477評論 6 407
  • 文/花漫 我一把揭開白布。 她就那樣靜靜地躺著,像睡著了一般。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發上,一...
    開封第一講書人閱讀 54,960評論 1 321
  • 那天,我揣著相機與錄音,去河邊找鬼。 笑死,一個胖子當著我的面吹牛,可吹牛的內容都是我干的。 我是一名探鬼主播,決...
    沈念sama閱讀 43,047評論 3 440
  • 文/蒼蘭香墨 我猛地睜開眼,長吁一口氣:“原來是場噩夢啊……” “哼!你這毒婦竟也來了?” 一聲冷哼從身側響起,我...
    開封第一講書人閱讀 42,200評論 0 288
  • 序言:老撾萬榮一對情侶失蹤,失蹤者是張志新(化名)和其女友劉穎,沒想到半個月后,有當地人在樹林里發現了一具尸體,經...
    沈念sama閱讀 48,726評論 1 333
  • 正文 獨居荒郊野嶺守林人離奇死亡,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內容為張勛視角 年9月15日...
    茶點故事閱讀 40,617評論 3 354
  • 正文 我和宋清朗相戀三年,在試婚紗的時候發現自己被綠了。 大學時的朋友給我發了我未婚夫和他白月光在一起吃飯的照片。...
    茶點故事閱讀 42,807評論 1 369
  • 序言:一個原本活蹦亂跳的男人離奇死亡,死狀恐怖,靈堂內的尸體忽然破棺而出,到底是詐尸還是另有隱情,我是刑警寧澤,帶...
    沈念sama閱讀 38,327評論 5 358
  • 正文 年R本政府宣布,位于F島的核電站,受9級特大地震影響,放射性物質發生泄漏。R本人自食惡果不足惜,卻給世界環境...
    茶點故事閱讀 44,049評論 3 347
  • 文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧,春花似錦、人聲如沸。這莊子的主人今日做“春日...
    開封第一講書人閱讀 34,425評論 0 26
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽。三九已至,卻和暖如春,著一層夾襖步出監牢的瞬間,已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 35,674評論 1 281
  • 我被黑心中介騙來泰國打工, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留,地道東北人。 一個月前我還...
    沈念sama閱讀 51,432評論 3 390
  • 正文 我出身青樓,卻偏偏與公主長得像,于是被迫代替她去往敵國和親。 傳聞我的和親對象是個殘疾皇子,可洞房花燭夜當晚...
    茶點故事閱讀 47,769評論 2 372

推薦閱讀更多精彩內容