HTTP協議圖解【超詳細】md
章節一：HTTP的由來
** 1.1 使用HTTP協議訪問web**
客戶端(client)：通過發送請求獲取服務器資源的web瀏覽器。
Snip20170427_6.png
WWW(World Wide Web,萬維網)三項構建技術
把 SGML(Standard Generalized Markup Language,標準通用標記語言)作為頁面的文本標 記語言HTML(HyperText Markup Language,超文本標記語言)。
作 為文檔傳遞協議的 HTTP；
指定文檔所在地址的 URL(Uniform Resource Locator,統一資源定位符)
TCP/IP協議
計算機與網絡要互相通信，雙方就必須基於相同的方法，不同的硬件，操作系統都需要一種規則，我們把這種規則稱之為協議（protocol）。
TCP/IP協議群.png
互聯網相關聯的協議集合起來總稱為 TCP/IP。也有說 法認為,TCP/IP 是指 TCP 和 IP 這兩種協議。還有一種說法認為,TCP/ IP 是在 IP 協議的通信過程中,使用到的協議族的統稱.
TCP/IP 分層管理
應用層:
HTTP ,FTP, DNS（Domain Name System, 域名系統）
傳輸層
- 網絡層
網絡層用來處理在網絡上流動的數據包。數據包是網絡傳輸的最小數據單位。該層規定了通過怎樣的路徑(所謂的傳輸路線)到達對 方計算機,並把數據包傳送給對方。 與對方計算機之間通過多臺計算機或網絡設備進行傳輸時,網絡層 所起的作用就是在眾多的選項內選擇一條傳輸路線。- 鏈路層（網絡接口層）
用來處理連接網絡的硬件部分。包括控制操作系統、硬件的設備驅動、NIC(Network Interface Card,網絡適配器,即網卡),及光纖等物理可見部分(還包括連接器等一切傳輸媒介)。硬件上的範疇 均在鏈路層的作用範圍之內**
與HTTP相關的IP,TCP,DNS協議- IP:
- 屬於網絡層，不要和IP地址混淆，它是一種協議
- 它的作用是把數據包傳送給對方。確保能傳遞準確和成功的兩個重要條件是:IP地址和MAC地址。
- IP地址指的是節點分配地址，可變換，MAC地址基本不會更改
https://bbs.hupu.com/bxj
bbs.hupu.com/bxj就是指節點分配地址，還是bxj是節點地址，希望有看到的朋友請指教
- ARP 協議憑借 MAC 地址進行通信
IP 間的通信依賴 MAC 地址。在網絡上,通信的雙方在同一局域網 (LAN)內的情況是很少的,通常是經過多臺計算機和網絡設備中轉才 能連接到對方。而在進行中轉時,會利用下一站中轉設備的 MAC 地址 來搜索下一個中轉目標。這時,會采用 ARP 協議(Address Resolution Protocol)。ARP 是一種用以解析地址的協議,根據通信方的 IP 地址就 可以反查出對應的 MAC 地址。 路由選擇 在到達通信目標前的中轉過程中,那些計算機和路由器等網絡設備 只能獲悉很粗略的傳輸路線。這種機制稱為路由選擇(routing),所以無論哪臺計算機或哪臺網絡設備都無法掌握全面的細節 TCP協議位於網絡層，提供可靠的的字節流服務 字節流服務:將數據庫切割成報文段（segment）的單位數據，TCP 協議為了更容易傳送大數據才把數據分割。 可靠性:準確的送達到對方 三次握手：確保數據傳輸的可靠性 回傳一個帶有 SYN/ACK 標誌的數據包以示傳達確認信息。最後,發送 端再回傳一個帶 ACK 標誌的數據包,代表“握手”結束。 若在握手過程中某個階段莫名中斷,TCP 協議會再次以相同的順序 發送相同的數據包。
- DNS協議：提供通過域 名查找 IP 地址,或逆向從 IP 地址反查域名的服務。
HTTP與各種協議的關系
```client發送URL請求，首先DNS會將解析對應的IP地址，HTTP協議生成針對目標服務器的HTTP請求報文，TCP協議將報文割成文段，按序號分為多個數據包，可靠的發給對方（三次握手），通過ARP協議解析IP地址的MAC地址，發給對方（IP協議），此處會有通過路由中轉的過程。服務器接收數據包，再以TCP協議按序號順序重組報文,HTTP解析報文，服務器處理內容在以相同的方式向用戶進行回傳
URI/URL
URI（Uniform Resource Locator,統一資源定位符）
URL 是URI的子集
URL的格式:
Snip20170427_13.png
RFC(Request for Comments)HTTP協議技術的標準文檔
章節二:HTTP 協議用於客戶端和服務器端之間的通信
通過請求和響應交換達成協議
請求報文：
請求方法、請求 URI、協議版本、可選的請求首部字
段和內容實體構成的。
Snip20170427_15.png
響應報文
請求內容的處理結果以響應的形式返回
Snip20170427_17.png
HTTP是一種不保存狀態
HTTP 是一種不保存狀態,即無狀態(stateless)協議。HTTP 協議 自身不對請求和響應之間的通信狀態進行保存。
協議本身並不保留之前一切的請求或響應報文的信息。這是為了更快地處理大量事務,確保協議的可伸縮性,而特意把 HTTP 協議設計成 如此簡單的。
為了保持狀態，HTTP1.1引入Cookie概念。
告知服務器意圖的 HTTP 方法
GET :獲取資源
GET 方法用來請求訪問已被 URI 識別的資源。指定的資源經服務器端解析後返回響應內容。也就是說,如果請求的資源是文本,那就保 持原樣返回;如果是像 CGI(Common Gateway Interface,通用網關接 口)那樣的程序,則返回經過執行後的輸出結果。
POST:傳輸實體主體
POST 的功能與 GET 很相似,但 POST 的主要目的並不是獲取響應的主體內容。
PUT :傳輸文件
HEAD:獲得報文首部
DELETE:刪除文件
但是,HTTP/1.1 的 DELETE 方法本身和 PUT 方法一樣不帶驗證機 制,所以一般的 Web 網站也不使用 DELETE 方法- OPTIONS 方法用來查詢針對請求 URI 指定的資源支持的方法。 - TRACE 方法 是讓 Web 服務器端將之前的請求通信環回給客戶端的 方法。 - CONNECT:要求用隧道協議連接代理  **HTTP長連接** - 每次的請求都會造成無謂的 TCP 連接建立和斷開, 增加通信量的開銷 - HTT持久倡長連接只要任意一端沒 有明確提出斷開連接,則保持 TCP 連接狀態 - 管線化：持久連接使得多數請求以管線化(pipelining)方式發送成為可能。 從前發送請求後需等待並收到響應,才能發送下一個請求。管線化技術 出現後,不用等待響應亦可直接發送下一個請求。  **使用 Cookie 的狀態管理** - Cookie 技術通過在請求和響應報文中寫入 Cookie 信息來控制客戶端的狀態Cookie 會根據從服務器端發送的響應報文內的一個叫做 Set-Cookie 的首部字段信息,通知客戶端保存 Cookie。當下次客戶端再往該服務器 發送請求時,客戶端會自動在請求報文中加入 Cookie 值後發送出去。
服務器端發現客戶端發送過來的 Cookie 後,會去檢查究竟是從哪 一個客戶端發來的連接請求,然後對比服務器上的記錄,最後得到之前 的狀態信息
Cookie
HTTP報文內的HTTP信息
HTTP報文大致可分為報文首部，報文主兩塊。通常,並不一定要有報文主體。
報文結構.png
報文結構詳解.png
請求報文和響應報文的組成
請求行
包含用於請求的方法,請求 URI 和 HTTP 版本。
狀態行
包含表明響應結果的狀態碼,原因短語和 HTTP 版本。
首部字段
包含表示請求和響應的各種條件和屬性的各類首部。
編碼提升傳輸效率
報文
基本單位：8位字節流
實體
作為請求或響應的有效載荷數據(補充項)被傳輸,其內容由實 體首部和實體主體組成。
壓縮傳輸內容編碼
內容編碼指明應用在實體內容上的編碼格式,並保持實體信息原樣壓縮。內容編碼後的實體由客戶端接收並負責解碼。
常用的內容編碼格式:
gzip
compress(UNIX 系統的標準壓縮)
deflate(zlib)
identity(不進行編碼)
分割發送的分塊傳輸編碼
分塊傳輸編碼
在 HTTP 通信過程中,請求的編碼實體資源尚未全部傳輸完成之 前,瀏覽器無法顯示請求頁面。在傳輸大容量數據時,通過把數據分割 成多塊,能夠讓瀏覽器逐步顯示頁面，這種實體分塊功能稱為傳塊編碼
分塊傳輸.png
分塊傳輸會將實體主體分為多個部分，每一部分用16進制開標記塊的大小，而實體主體的最後一塊會使用“0(CR+LF)”
HTTP/1.1 中存在一種稱為傳輸編碼(Transfer Coding)的機制,它 可以在通信時按某種編碼方式傳輸,但只定義作用於分塊傳輸編碼中來標記。
發送多種數據的多部分對象集合
MIME(Multipurpose Internet Mail Extensions,多用途因特網 郵件擴展)機制
多部分對象集合包含的對象如下
multipart/form-data
在 Web 表單文件上傳時使用。
multipart/byteranges
狀態碼 206(Partial Content,部分內容)響應報文包含了多個範 圍的內容時使用。
multipart/form-data
multipart/byteranges
獲取部分內容的範圍請求
內容協商返回最合適的內容
當瀏覽器的 認 為 或中文, 問相同 URI 的 Web 頁面時, 會顯示對應的 版或中文版的 Web 頁面。這樣的機制 為內容協
請求報文中首部字段的判斷基準
Accept
Accept-Charset
Accept-Language
Content-Language
內容協 技術有以 3 種
服務器 動協商(Se e - i en Negotiation)
客戶端 動協商(Agent- i en Negotiation)
明協商(T ans a ent Negotiation)
HTTP返回結果狀態碼
狀態碼的職 是當客戶端向服務器端發送請求時, 返回的請求 結果。借助狀態碼,用戶可以知道服務器端是正常 理了請求,還是出 現了 。
響應的狀態碼.png
以3位數字和原因組成的短語叫做狀
狀態類別.png
用單臺虛擬主機實現多個域名
HTTP/1.1 許一 HTTP 服務器 建多個 Web 站點
即使 理 面只有一 服務器,但只要使用 主機的功能, 可 以 想已具有多 服務器。
在相同的 IP 地 ,由於 主機可以 存多個不同主機名和域 名的 Web 網站,因此在發送 HTTP 請求時, 在 Host 首部內完整指 定主機名或域名的 URI。
虛擬主機
通訊數據轉發程序:代理 網關 隧道
代理
代理服務器最基本的行為就是接受客戶端發送給他的請求
代理
在 HTTP 通信過程中,可級聯多 代理服務器。請求和響應的 發 會經過數 一樣 接起來的代理服務器。 發時,需要 加 Via 首部字段以標記出經過的主機信
代理使用方法的兩種基類分類
緩存代理
當代理再 接 到對相同資源的請求時,就可以不從源服務器那裏 資源,而是將之前緩存的資源作為響應返回。```
- 透明代理
發請求或響應時,不對報文做 何加工的代理 被 為透明代 理(Transparent Pro y)。 之,對報文內容進行加工的代理被 為 透明代理
網關
- 網關的工作機制和代理十分相似。網關能使通信路上的服務器提供非HTTP協議的服務。
- 利用網關能提高通信的安全 ,因為可以在客戶端與網關之間的通 信 路上加密以確保 接的安全。 如,網關可以 接數據 ,使用 S L 查 數據。另外,在 Web 網站上進行信用 結 時,網
關可以和信用 結 聯動。
- 隧道
```隧道是在相隔甚遠的客戶端和服務器之間進行中轉的，並保持雙方通訊鏈接的應用程序。 - 隧道可 要求建立起一 與其他服務器的通信 路, 時使用 SSL 等加密手段進行通信。隧道的目的是確保客戶端能與服務器進行安全的 通信。
- 隧道不會解析HTTP請求，原樣轉給服務器，隧道會在客戶端和服務器斷開連接時結束。
保存資源的緩存
緩存服務器的 在於利用緩存可 多 從源服務器 發資源。 因此客戶端可就 從緩存服務器上 資源,而源服務器也不 多 理相同的請求了。
HTTP 首部
HTTP報文首部
請求報文結構
在請求中，HTTP報文由方法 URL HTTP版本 HTTP首部字段構成。
請求報文
響應報文結構
4種HTTP首部字段類型
通用首部字段
請求報文和響應報文兩方都會使用的首部。如協議版本號
請求首部字段
從客戶端向服務器端發送請求報文時使用的首部。 了請求的加內容、客戶端信 、響應內容相關 先級等信 。
響應首部字段
從服務器端向客戶端返回響應報文時使用的首部。 了響應的 加內容,也會要求客戶端 加 外的內容信 。
實體首部字段
對請求報文和響應報文的實體部分使用的首部。 了資源內容 更新時間等與實體有關的信 。
HTTP 首部字段一覽
非HTTP/1.1首部字段
在 HTTP 協議通信交互中使用到的首部字段,不 於 RFC2616 中 定義的 47 種首部字段。還有 Cookie、Set-Cookie 和 Content-Disposition 等在其他 RFC 中定義的首部字段,它們的使用 也很高。
這些 正式的首部字段 一 在 RFC4229 HTTP Header Field Registrations 中。
End-to-end首部 和 Hop by hop首部
HTTP/1.1通用首部字段
Cache-Control
通過指定首部字段 Cache-Control 的指令,就能 作緩存的工作機制。指令的 數是可 的,多個指令之間通過“,”分 。首部字段,Cache-Control 的指令可用於請求及響應時。
Cache-Control
響應緩存
Connetion
控制不在轉發給代理的首部字段
Connection: 不再發的首部字段
Snip20170502_42.png
管理持久鏈接
HTTP/1.1 之前的 HTTP 版本的 認 接都是 持 接。為此, 如果想在 版本的 HTTP 協議上維持持 接, 需要指定 Connection 首部字段的值為 Keep-Alive。
Date
首部字段 Date 表明 建 HTTP 報文的日 和時間。
Pragma
Pragma 是 HTTP/1.1 之前版本的 史 留字段,僅作為與 HTTP/1.0 的向後 容而定義。
該首部字段 於通用首部字段,但只用在客戶端發送的請求中。客 戶端會要求所有的中間服務器不返回緩存的資源。
EG: Pragma:no-cache
Trailer
首部字段 Trailer 會 先說明在報文主體後記 了哪些首部字段。該 首部字段可應用在 HTTP/1.1 版本分 編碼時。
Transfer - Encoding
規定了報文主體采用的編碼方式
Upgrade
首部字段 Upgrade 用於檢 HTTP 協議及其他協議是否可使用更高 的版本進行通信,其 數值可以用來指定一個完全不同的通信協議。
Via
使用首部字段 Via 是為了 客戶端與服務器之間的請求和響應報 文的 路 。
Warning
請求首部字段
請求首部字段是從客戶端 服務器端發送請求報文中所使用的字 段,用於 請求的 加信 、客戶端信 、對響應內容相關的 先級 等內容。
Accept
Accept 首部字段可通知服務器,用戶代理能 理的 體 及 體 的相對 先級。 可使用 type/subtype 這種形式,一 指定多種 體 。
文本文件，圖片文件...
text/html, text/plain, text/css ...
q表示權重 0-1的小數，默認1，以分好；分割。 quality factor 質量因數
Accept-Charset
首部字段可用來通知服務器用戶代理支持的字 及字 的相對 先順序。另外,可一 指定多種字 。與首部字 段 Accept 相同的是可用權重 值來表示相對先級。
該首部字段應用於內容協 機制的服務器 動協 。
Accept-Encoding
首部字段用來 知服務器用戶代理支持的內容編 碼及內容編碼的 先級順序。可一 指定多種內容編碼
Accept - Language
首部字段 Accept-Language 用來 知服務器用戶代理能 理的自 然 (指中文或 文等),以及自然 的相對 先級。可一 指定多種自然 。q表示權重
Authorization
Expect
客戶端使用首部字段 Expect 來 知服務器, 望出現的某種特定 行為。因服務器無法理解客戶端的 望作出回應而發生 時,會返回 狀態碼 417 E pectation Failed。
From
首部字段 From 用來 知服務器使用用戶代理的用戶的 件地 。 通常,其使用目的就是為了顯示 引 等用戶代理的 人的 件聯 方式。使用代理時,應 可能包含 From 首部字段(但可 能會因代理不同,將 件地 記 在 User-Agent 首部字段內)。
Host
首部字段 Host 會 知服務器,請求的資源所 的互聯網主機名和 端 。Host 首部字段在 HTTP/1.1 內是 一一個 被包含在請 求內的首部字段。
為cookie服務的首部字段
HTTP的缺點
HTTP的不足
通信使用明文（不加密），內容可能會被竊聽
不驗證通信方的身份，因此有可能遇到偽裝
無法驗證報文的完整性，所以有可能已遭篡改
加密策略
通信的加密
一種方式就是講通信加密。HTTP協議中沒有加密機制但可以通 過和SSL(Secure Socket Layer,安全 接 )或TLS(Transport Layer Security,安全 協議)的 使用,加密 HTTP 的通信內容。
內容加密
對HTTP報文內容進行加密
不驗證通信方的身份就會可能遭遇偽裝
HTTP協議非常簡單，但是存在各種隱患
無法確定請求發送 目 的 Web 服務器是 是 實意圖返回 響應的 臺服務器。有可能是已偽裝的 Web 服務器
無法確定正在通信的對方是否具備訪問權限。
無法判斷請求來自何方，出自誰手
即使是無意義的請求也會照單全收。
查看對手的證書
SSL.png
HTTP +加密+認證+ 完整性保護 = HTTPS
HTTPS不是一種新的應用層協議。只是HTTP部分通信接口用SSL和TLS
HTTP 接和 TCP 通信。當使用 SSL 時, 變成先和 SSL 通信,再由 SSL 和 TCP 通信了。簡 之,所謂 HTTPS,其實就是 身 SSL 協議這 外 的 HTTP
HTTPS
HTTP協議圖解【超詳細】md