從新學習的HTTP協議

時間  2019-11-24
標籤 從新 學習 http 協議 欄目 HTTP/TCP 简体版
原文   原文鏈接

在雞年的最後一天完成了這篇文章。表示愉悅的同時，更要祝福你們狗年大吉吧....css

下方是一根正經的分割線...html

從新學習前端知識，本身整理總結了些內容...因此想分享給你們。在分享的同時，也能夠本身學習的更紮實...若是有錯誤或者理解不正確的地方，麻煩告知我會及時更正。同時也很是歡迎你們一塊兒討論。鞠躬。 Github地址：項目地址 (不按期更新...前端

HTTP協議

定義

HTTP( HyperText Transfer Protocol )超文本傳輸協議 ，是一種用於分佈式、協做式和超媒體信息系統的應用層協議。設計HTTP最初的目的是爲了提供一種發佈和接收HTML頁面的方法。經過HTTP或者HTTPS協議請求的資源由統一資源標識符（Uniform Resource Identifiers，URI）來標識。git

TCP/IP & HTTP

  1. HTTP是如何創建鏈接的 首先咱們要看下熟知的七層網絡模型(計算機網絡中的七層模型畢竟是理想中的狀況，現實是不多有應用實現了七層模型，通常都是整合其中兩個或多個，實現一個四層或者五層的模型)和TCP/IP的四層網絡模型（TCP處於傳輸層，IP屬於網絡(際)層 ps:關於TCP/IP到底是幾層協議，目前爲止沒有定論，四層和五層都有，這裏不展開討論 ），以下圖

網絡模型

在這裏咱們研究的是HTTP，天然要知道它所處在哪一個模型中，答案是應用層 由於HTTP是基於TCP/IP開發的協議，看過HTTP協議的同窗確定都知道，有句話概述HTTP協議爲無差錯的協議，按序傳輸，未分段的數據流，這其實說的就是TCP協議。github

  1. 當你在瀏覽器輸入一個URL的時候，其中發生了什麼？
    • 獲取主機名
    • DNS 緩存/ 解析 獲取服務器IP + 端口 (瀏覽器緩存，系統緩存，路由器緩存，IPS服務器緩存，根域名服務器緩存，頂級域名服務器緩存，主域名服務器緩存)
    • 鏈接到服務器 （這裏實際上是TCP鏈接）
    • 經過TCP信道發送一個HTTP請求
    • 服務器讀取一個HTTP請求
    • 服務器查找所需資源並經過TCP信道返回資源
    • 關閉TCP鏈接

版本變遷

  1. HTTP/0.9 已過期,只接受 GET 一種請求方法，沒有在通信中指定版本號，且不支持請求頭.
  2. HTTP/1.0 第一個在通信中指定版本號的HTTP 協議版本。
  3. HTTP/1.1 繼承了HTTP1.0簡單的特色，持久鏈接被默認創建，並能很好地配合代理服務器工做。還支持以管道方式在同時發送多個請求，以便下降線路負載，提升傳輸速度。
  4. HTTP/2.0 2015年5月做爲互聯網標準正式發佈。

HTTP客戶端請求和服務端響應（目前主流的HTTP1.1和HTTP2

  • 請求組成
    1. 起始行(start line) 請求方法 + 請求URI + 協議版本
    2. 報文首部（Header）
    3. 空行
    4. 報文主體
  • 響應組成
    1. 起始行(start line) 協議版本 + 狀態碼 + 狀態嘛的緣由短語
    2. 報文首部（Header）
    3. 空行
    4. 報文主體
  • 請求方法
    • GET — 獲取資源
    • HEAD — 得到報文首部
    • POST -- 傳輸實體文本
    • PUT -- 傳輸文件
    • DELETE — 刪除文件
    • CONNECT — 要求用隧道協議鏈接代理
    • OPTIONS — 詢問支持的方法
    • TRACE — 追蹤路徑
  • 首部文件 這一塊圖解HTTP的第六章有詳細內容
    • 通用首部
      1. 信息：Connection/Date/MIME-Version/Trailer/Update/Via
      2. 緩存：Cache-Control/Pragma
    • 請求首部
      1. 信息：Client-IP/From/Host/Referer/UA-Color/UA-CPU/UA-Disp/UA-OS/UA-Pixels/User-Agent
      2. Accept：Accept/Accept-Charset/Accept-Encoding/Accept-Language/TE
      3. 條件請求：Expect/If-Match/If-Modified-Since/If-None-Match/If-Range/If-Unmodified-Since/Range
      4. 安全請求：Authorization/Cookie/Cookie2
      5. 代理請求：Max-Forward/Proxy-Authorization/Proxy-Connection
    • 響應首部
      1. 信息：Age/Public/Retry-After/Server/Title/Warning
      2. 協商：Accept-Ranges/Vary
      3. 安全響應：Proxy-Authorization/Set-Cookie/Set-Cookie2/WWW-Authenticate
    • 實體首部
      1. 信息：Allow/Location
      2. 內容：Content-Base/Content-Encoding/Content-Language/Content-Length/Content-Location/Content-MD5/Content-Range/Content-Type
      3. 實體緩存：ETag/Expires/Last-Modified
  • 響應狀態碼
    • 100 Continue 繼續，通常在發送post請求時，已發送了http header以後服務端將返回此信息，表示確認，以後發送具體參數信息
    • 200 OK 正常返回信息
    • 201 Created 請求成功而且服務器建立了新的資源
    • 202 Accepted 服務器已接受請求，但還沒有處理
    • 206 Partial Content 響應報文包含了多個範圍內的內容
    • 301 Moved Permanently 請求的網頁已永久移動到新位置。
    • 302 Found 臨時性重定向。
    • 303 See Other 臨時性重定向，且老是使用 GET 請求新的 URI。
    • 304 Not Modified 自從上次請求後，請求的網頁未修改過。
    • 400 Bad Request 服務器沒法理解請求的格式，客戶端不該當嘗試再次使用相同的內容發起請求。
    • 401 Unauthorized 請求未受權。
    • 403 Forbidden 禁止訪問。
    • 404 Not Found 找不到如何與 URI 相匹配的資源。
    • 500 Internal Server Error 最多見的服務器端錯誤。
    • 503 Service Unavailable 服務器端暫時沒法處理請求（多是過載或維護）。

各版本簡介

HTTP/1.0

  • 早先的HTTP/1.0是一種無狀態、無鏈接的應用層協議。規定瀏覽器和服務器保持短暫的鏈接，瀏覽器的每次請求都須要與服務器創建一個TCP鏈接，服務器處理完成後當即斷開TCP鏈接（無鏈接），服務器不跟蹤每一個客戶端也不記錄過去的請求（無狀態）
  • 這種無狀態性能夠藉助cookie/session機制來作身份認證和狀態記錄。而下面兩個問題就比較麻煩了。
    1. 首先，無鏈接的特性致使最大的性能缺陷就是沒法複用鏈接。每次發送請求的時候，都須要進行一次TCP的鏈接，而TCP的鏈接釋放過程又是比較費事的。這種無鏈接的特性會使得網絡的利用率很是低。
    2. 其次就是就是隊頭阻塞（head of line blocking）。因爲HTTP1.0規定下一個請求必須在前一個請求響應到達以前才能發送。假設前一個請求響應一直不到達，那麼下一個請求就不發送，一樣的後面的請求也給阻塞了。

HTTP/1.1

  • 長鏈接，經過設置Keep-Alive能夠保持HTTP鏈接不斷開，避免了每次客戶端與服務器請求都要重複創建釋放創建TCP鏈接，提升了網絡的利用率。能夠在請求頭中攜帶Connection: false來告知服務器關閉請求。
  • 支持請求管道化（pipelining）。 基於長鏈接，使得請求管線化成爲可能。管線化使得請求可以並行傳輸。舉個例子來講，假如響應的主體是一個html頁面，頁面中包含了不少img，這個時候keep-alive就起了很大的做用，可以進行並行發送多個請求。（客戶端依據域名來向服務器創建鏈接，通常PC瀏覽器會針對單個域名的服務器同時創建6 ~ 8個鏈接，手機端通常控制在4 ~ 6個。這也是爲何不少大型網站設置不一樣的靜態資源CDN域名來加載資源。） 須要注意的是，服務器必須按照客戶端請求的前後順序依次回送相應的結果，以保證客戶端可以區分出每次請求的響應內容。 也就是說，HTTP管道化可讓咱們把先進先出隊列從客戶端（請求隊列）遷移到服務端（響應隊列）。

http請求圖

如圖所示，客戶端同時發了兩個請求分別來獲取html和css，假如說服務器的css資源先準備就緒，服務器也會先發送html再發送css。 同時，管道化技術只是使得客戶端可以往一個服務器同時發送一組請求，倘若客戶端想往這個相同的服務器發起另外一組請求，也必須等待上一組請求所有響應完畢。 可見，HTTP1.1解決隊頭阻塞（head of line blocking）還不完全。chrome

  • 緩存處理，支持斷點傳輸，以及增長了Host字段（使得一個服務器可以用來建立多個Web站點）。

HTTP/2.0

HTTP/2 is the future of the Web 這是 Akamai 公司創建的一個官方的演示，用以說明 HTTP/2 相比於以前的 HTTP/1.1 在性能上的大幅度提高。 同時請求 379 張圖片，從Load time 的對比能夠看出 HTTP/2 在速度上的優點。 順口提一句 HTTP/2 協議是從 SPDY 演變而來，SPDY 已經完成了使命並很快就會退出歷史舞臺（例如 Chrome 將在「2016 年初結束對 SPDY 的支持」；Nginx 已經正式支持 HTTP/2 後，也再也不支持 SPDY）segmentfault

  • 二進制分幀 HTTP2.0經過在應用層和傳輸層之間增長一個二進制分幀層，突破了HTTP1.1的性能限制、改進傳輸性能。

二進制分幀

可見，雖然HTTP2.0的協議和HTTP1.x協議之間的規範徹底不一樣了，可是實際上HTTP2.0並無改變HTTP1.x的語義。 簡單來講，HTTP2.0只是把原來HTTP1.x的header和body部分用frame從新封裝了一層而已。瀏覽器

  • 多路複用 下面是幾個概念：
    • 流（stream）：已創建鏈接上的雙向字節流。
    • 消息：與邏輯消息對應的完整的一系列數據幀。
    • 幀（frame）：HTTP2.0通訊的最小單位，每一個幀包含幀首部，至少也會標識出當前幀所屬的流（stream id）。

多路複用

從圖中可見，全部的HTTP2.0通訊都在一個鏈接上完成，這個鏈接能夠承載任意數量的雙向數據流。 每一個數據流以消息的形式發送，而消息由一或多個幀組成。這些幀能夠亂序發送，而後再根據每一個幀首部的流標識符（stream id）從新組裝。 舉個例子，每一個請求是一個數據流，數據流以消息的方式發送，而消息又分爲多個幀，幀首部記錄着stream id用來標識所屬的數據流，不一樣屬的幀能夠在鏈接中隨機混雜在一塊兒。接收方能夠根據stream id將幀再歸屬到各自不一樣的請求當中去。緩存

  • 請求優先級 多路複用致使全部資源都是並行發送，可能會致使關鍵請求被阻塞。那麼就須要「優先級」的概念了，這樣就能夠對重要的文件進行先傳輸，加速頁面的渲染。
  • 首部壓縮 在HTTP1.x中，首部元數據都是以純文本的形式發送的，一般會給每一個請求增長500~800字節的負荷。 HTTP/2.0規定了在客戶端和服務器端會使用而且維護「首部表」來跟蹤和存儲以前發送的鍵值對，對於相同的頭部，沒必要再經過請求發送，只需發送一次。 事實上,若是請求中不包含首部（例如對同一資源的輪詢請求），那麼首部開銷就是零字節。此時全部首部都自動使用以前請求發送的首部。 若是首部發生變化了，那麼只須要發送變化了數據在Headers幀裏面，新增或修改的首部幀會被追加到「首部表」。首部表在 HTTP2.0的鏈接存續期內始終存在,由客戶端和服務器共同漸進地更新。

首部壓縮

好比說cookie，默認狀況下，瀏覽器會在每次請求的時候，把cookie附在header上面發送給服務器。（因爲cookie比較大且每次都重複發送，通常不存儲信息，只是用來作狀態記錄和身份認證）安全

  • 服務器推送 服務器除了對最初請求的響應外，服務器還能夠額外的向客戶端推送資源，而無需客戶端明確的請求。 在 HTTP/2官網 能夠找到更多有關 HTTP/2 協議的資料。
  • HTTP/2 的協議協商機制？ 瀏覽器 服務器 協商結果 不支持 HTTP/2 不支持 HTTP/2 不協商，使用 HTTP/1.1 不支持 HTTP/2 支持 HTTP/2 不協商，使用 HTTP/1.1 支持 HTTP/2 不支持 HTTP/2 協商，使用 HTTP/1.1 支持 HTTP/2 支持 HTTP/2 協商，使用 HTTP/2

HTTPS

  1. HTTPS, 全稱Hyper Text Transfer Protocol Secure。相比HTTP，多了一個Secure,這是由TLS（SSL）提供的。 固然也能夠理解爲：HTTPS = HTTP + 加密 + 認證 + 完整性保護。
  2. SSL(Secure Sockets Layer 安全套接層),及其繼任者傳輸層安全（Transport Layer Security，TLS）是爲網絡通訊提供安全及數據完整性的一種安全協議。TLS 與 SSL 在傳輸層對網絡鏈接進行加密。 圖解SSL/TLS協議 - 阮一峯的網絡日誌 這一篇阮老師的內容寫的不錯.就是時間有點久了，目前TLS 1.3已經上線了，感興趣的能夠了解下，這個也屬於性能優化的一部分。（這裏就大體的說下：TLS 1.2：須要兩次往返才能完成握手，而後才能發送請求。經過移動網絡訪問網站能夠在加載時間上增長超過半秒的時間。TLS 1.3：初始握手會減半，只須要一次往返…）
  3. 傳輸過程：
    • HTTP => TCP => IP
    • HTTP => SSL/TLS => TCP => IP

CURL

這個實際上是題外話，由於本身調試不多用到CURL，瞭解了後才發現這東西真的很好用，因此也就帶在這裏寫了進去，當給本身記錄下 用法也很簡單 curl [options...] <url> 具體的options能夠用curl -help 去查看，這裏我就說我幾個會用到的

  • -H/--header 自定義頭信息傳遞給服務器
  • -X/--request 指定什麼命令
  • -d/--data HTTP POST方式傳送數據
  • -e/--referer 來源網址

總結

若是沒有時間看，直接看這裏和以第一張的思惟導圖。若是你以爲好，點個star.這個是個人git地址 個人Git地址

  • HTTP是一種無狀態、無鏈接的應用層協議
  • 如今主流的在使用的是HTTP/1.1 （特色：持久連接，增長緩存處理，支持斷點傳輸）和 HTTP/2（特色：二進制分幀，首部壓縮，多路複用，服務端推送）
  • HTTPS 是由TLS（SSL）提供安全的HTTP協議

chrome查看協議類型

上次看到有人提問這個，按照如下步驟就能夠了

  1. 打開檢查 ...選擇到Network
  2. 右鍵Bar勾選protocol 便可
    下圖中就能夠在protocol裏看到是http/1.1 仍是http2 了

文檔參考

總結這篇學習筆記也是從不少大神的文章中和書裏找到的，感興趣的同窗能夠去看下，更深的研究。歡迎你們一塊兒來討論學習。固然我寫的有問題的地方，也麻煩各位幫助指出,謝謝。

  1. 《圖解 HTTP》和《HTTP 權威指南》 我是先看了圖解HTTP以後讀的文章。最後粗看了一下HTTP 權威指南，這本書很優秀，可是其實比較厚，因此一上來閱讀比較困難，建議看圖解HTTP，圖片可愛，介紹的也清楚，關鍵這本書頁數少….
  2. http2講解 · GitBook 中文翻譯…
  3. HTTP1.0 HTTP1.1 HTTP2.0 主要特性對比 - 前端的那些事兒 - SegmentFault 思否
  4. Mark Nottingham 在 Velocity Beijing 2015 的 speech ,關於 HTTP/2 下的前端性能優化相關 HTTP/2 for Front-End Developers
  5. 專題 | JerryQu 的小站
  6. HTTP1.0 HTTP1.1 HTTP2.0 主要特性對比 - 前端的那些事兒 - SegmentFault 思否
相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程