1.網(wǎng)絡(luò)模型 應(yīng)用層、傳輸層、網(wǎng)絡(luò)層、數(shù)據(jù)鏈路層、物理層

網(wǎng)絡(luò)層：HTTP協(xié)議、FTP協(xié)議、DNS 協(xié)議 傳輸層：TCP協(xié)議、UDP協(xié)議 網(wǎng)絡(luò)層： IP（internet protocol）協(xié)議 數(shù)據(jù)鏈路層：硬件 注意： TCP/IP協(xié)議是互聯(lián)網(wǎng)各類協(xié)議族的總稱

2.一個(gè)HTTP請求的過程

1045569A-DFB9-4DE5-976F-EC77791A49CD.png

• 首先作為發(fā)送端的客戶端在應(yīng)用層 (HTTP 協(xié)議)發(fā)出一個(gè)想看某個(gè) Web 頁面的 HTTP 請求。

接著，為了傳輸方便，在傳輸層(TCP 協(xié)議)把從應(yīng)用層處收到的數(shù) 據(jù)(HTTP 請求報(bào)文)進(jìn)行分割，并在各個(gè)報(bào)文上打上標(biāo)記序號(hào)及端 口號(hào)后轉(zhuǎn)發(fā)給網(wǎng)絡(luò)層。 在網(wǎng)絡(luò)層(IP 協(xié)議)，增加作為通信目的地的 MAC 地址后轉(zhuǎn)發(fā)給鏈 路層。這樣一來，發(fā)往網(wǎng)絡(luò)的通信請求就準(zhǔn)備齊全了。 接收端的服務(wù)器在鏈路層接收到數(shù)據(jù)，按序往上層發(fā)送，一直到應(yīng)用 層。當(dāng)傳輸?shù)綉?yīng)用層，才能算真正接收到由客戶端發(fā)送過來的 HTTP 請求。 TCP協(xié)議通信的三次握手 syn synchronize ack acknowledgement [圖片上傳失敗...(image-102eb-1583985222182)]

3.代理、網(wǎng)關(guān)、隧道

代理 代理是一種有轉(zhuǎn)發(fā)功能的應(yīng)用程序，它扮演了位于服務(wù)器和客戶 端“中間人”的角色，接收由客戶端發(fā)送的請求并轉(zhuǎn)發(fā)給服務(wù)器，同時(shí) 也接收服務(wù)器返回的響應(yīng)并轉(zhuǎn)發(fā)給客戶端。 每次通過代理服務(wù)器轉(zhuǎn)發(fā)請求或響應(yīng)時(shí)，會(huì)追加寫入 Via 首 部信息 [圖片上傳失敗...(image-90cc7d-1583985222181)]

緩存代理 代理轉(zhuǎn)發(fā)響應(yīng)時(shí)，緩存代理(Caching Proxy)會(huì)預(yù)先將資源的副本 (緩存)保存在代理服務(wù)器上。 當(dāng)代理再次接收到對相同資源的請求時(shí)，就可以不從源服務(wù)器那里獲 取資源，而是將之前緩存的資源作為響應(yīng)返回。 透明代理 轉(zhuǎn)發(fā)請求或響應(yīng)時(shí)，不對報(bào)文做任何加工的代理類型被稱為透明代理 (Transparent Proxy)。反之，對報(bào)文內(nèi)容進(jìn)行加工的代理被稱為非 透明代理。 網(wǎng)關(guān) 網(wǎng)關(guān)是轉(zhuǎn)發(fā)其他服務(wù)器通信數(shù)據(jù)的服務(wù)器，接收從客戶端發(fā)送來的請 求時(shí)，它就像自己擁有資源的源服務(wù)器一樣對請求進(jìn)行處理。有時(shí)客 戶端可能都不會(huì)察覺，自己的通信目標(biāo)是一個(gè)網(wǎng)關(guān)。網(wǎng)關(guān)的工作機(jī)制和代理十分相似。而網(wǎng)關(guān)能使通信線路上的服務(wù)器提供非 HTTP 協(xié)議服務(wù)。 隧道 隧道是在相隔甚遠(yuǎn)的客戶端和服務(wù)器兩者之間進(jìn)行中轉(zhuǎn)，并保持雙方 通信連接的應(yīng)用程序。

4.HTTP 首部字段（請求頭）

• 通用首部字段
  

  F11F5BD4-B3F2-4010-B5B0-66128349D6C2.png

• 請求首部字段
  

  45FF5A64-61A9-4A26-AF7A-FF741FFD2EB0.png

• 響應(yīng)首部字段

  
  
  75EF701D-6246-43FC-9B34-EA3C57DDA73F.png

• 實(shí)體首部字段
  

  FF12C53A-F402-4E18-A0E7-D771F68F9419.png

Cache-Control 緩存指令

• 請求指令

  
  
  8999D9C6-6B13-4210-BE1B-5674C84BBFA3.png

• 響應(yīng)指令

  
  
  7A3ECCC2-23D6-433C-9821-6B819E5F48CA.png

Connecttion 持久連接 不再轉(zhuǎn)發(fā)給代理

• Connection: 不再轉(zhuǎn)發(fā)的首部字段名

• Connection: close 請求后斷開鏈接

• connection: Keep-Alive HTTP/1.1默認(rèn)鏈接是持久連接

Pragma 向后兼容緩存的 HTTP/1.1中直接使用Cache-Control

Trailer

Transfer-Encoding 規(guī)定了傳輸報(bào)文主體采用的編碼，僅對分塊傳輸編碼有效

Upgrade 檢測HTTP協(xié)議及其他協(xié)議是否可以使用更高的版本進(jìn)行通信

Via 追蹤客戶端與服務(wù)器之間的請求和響應(yīng)報(bào)文的傳輸路徑

3F0C6628-3E91-4D74-9EE0-2E2ABE5C1923.png

• text/html

Accept 用戶代理能夠處理的媒體類型及媒體 類型的相對優(yōu)先級(jí)

Accept-Charset 通知服務(wù)器用戶代理支持的字符集及 字符集的相對優(yōu)先順序

Accept-Encoding 告知服務(wù)器用戶代理支持的內(nèi)容編碼及 內(nèi)容編碼的優(yōu)先級(jí)順序

Accept-Language 用來告知服務(wù)器用戶代理能夠處理的自然 語言集(指中文或英文等)，以及自然語言集的相對優(yōu)先級(jí)。可一次 指定多種自然語言集。

Host 首部字段 Host 會(huì)告知服務(wù)器，請求的資源所處的互聯(lián)網(wǎng)主機(jī)名和端 口號(hào)。Host 首部字段在 HTTP/1.1 規(guī)范內(nèi)是唯一一個(gè)必須被包含在請 求內(nèi)的首部字段。

If-Match 首部字段 If-Match，屬附帶條件之一，它會(huì)告知服務(wù)器匹配資源所用 的實(shí)體標(biāo)記(ETag)值

形如 If-xxx 這種樣式的請求首部字段，都可稱為條件請求。服務(wù)器接 收到附帶條件的請求后，只有判斷指定條件為真時(shí)，才會(huì)執(zhí)行請求。

如果在If-Modified-Since 字段指定的日期時(shí)間后，資源發(fā)生了 更新，服務(wù)器會(huì)接受請求

Max-Forward: 請求被轉(zhuǎn)發(fā)的次數(shù)，每次減1，到0后直接返回

Proxy-Authorization 接收到從代理服務(wù)器發(fā)來的認(rèn)證質(zhì)詢時(shí)，客戶端會(huì)發(fā)送包含首部字段 Proxy-Authorization 的請求，以告知服務(wù)器認(rèn)證所需要的信息。

Range Range: bytes=5001-10000

Referer 首部字段 Referer 會(huì)告知服務(wù)器請求的原始資源的 URI。

ETag 服務(wù)器返回的實(shí)體標(biāo)識(shí)，將資源以字符串形式做唯一性標(biāo)識(shí)的方式

Location: http://www.test.com 重定向指定的url

Retry-After： 120 服務(wù)端告知客戶端在多久之后再次發(fā)送請求

Server: Apache/2.2.17 (Unix) 服務(wù)器上HTTP服務(wù)器應(yīng)用程序的信息

Vary 當(dāng)代理服務(wù)器接收到帶有 Vary 首部字段指定獲取資源的請求時(shí)，如果使用的 Accept-Language 字段的值相同，那么就直接從緩存返回響應(yīng)。反之，則需要先從源服務(wù)器端獲取資源后才能作為響應(yīng)返回

Allow: GET, HEAD 告知客戶端服務(wù)器支持的HTTP請求方式

Content-Encoding: gzip 告知客戶端服務(wù)器對實(shí)體的主體部分的編碼方式

Content-Location: http://abc.html 返回的資源對應(yīng)的URI

Content-Type: text/html; charset=UTF-8 實(shí)體主體內(nèi)對象的媒體類型 和 Accept 字段使用形式一樣 Expires: Wed, 04 Jul 2020 08:33:22 GMT 資源失效日期，超過該時(shí)間后，請求會(huì)轉(zhuǎn)向源服務(wù)器 優(yōu)先級(jí)低于Cache-Control

Set-Cookie: status=enable; expires=Tue, 04 Jul 2020 07:22:22

22D0E694-01F6-4D4A-9E91-BBC8F86A33A5.png

Cookie: status=enable 首部字段 Cookie 會(huì)告知服務(wù)器，當(dāng)客戶端想獲得 HTTP 狀態(tài)管理支 持時(shí)，就會(huì)在請求中包含從服務(wù)器接收到的 Cookie。接收到多個(gè) Cookie 時(shí)，同樣可以以多個(gè) Cookie 形式發(fā)送。

5.HTTP請求的安全機(jī)制

1.加密通道 SSL(Secure Socket Layer) 安全套接層 TLS （Transport Layer Security) 安全層傳輸協(xié)議

2.加密報(bào)文內(nèi)容

3.HTTPS:

• HTTP加上加密處理和認(rèn)證以及完整性保護(hù)后即是HTTPS（HTTP secure）

• 通常，HTTP 直接和 TCP 通信。當(dāng)使用 SSL 時(shí)，則演變成先和 SSL 通 信，再由 SSL 和 TCP 通信了。簡言之，所謂 HTTPS，其實(shí)就是身披 SSL 協(xié)議這層外殼的 HTTP。

• 和使用 HTTP 相比，網(wǎng)絡(luò)負(fù)載可能會(huì)變慢 2 到 100 倍。除去和 TCP 連接、發(fā)送 HTTP 請求 ? 響應(yīng)以外，還必須進(jìn)行 SSL 通信， 因此整體上處理通信量不可避免會(huì)增加。

• 另一點(diǎn)是 SSL 必須進(jìn)行加密處理。在服務(wù)器和客戶端都需要進(jìn)行 加密和解密的運(yùn)算處理。因此從結(jié)果上講，比起 HTTP 會(huì)更多地 消耗服務(wù)器和客戶端的硬件資源，導(dǎo)致負(fù)載增強(qiáng)。

6.確認(rèn)訪問用戶身份的認(rèn)證

1.Basic認(rèn)證（基本認(rèn)證）

• 客戶端請求瀏覽器后，瀏覽器會(huì)返回狀態(tài)碼401 Authorization Required 并且返回WWW-Authenticate 的首部字段的響應(yīng)。

• 客戶端將用戶ID和密碼（以冒號(hào)鏈接，并且經(jīng)過Base64編碼處理）發(fā)送給服務(wù)器。Authorization: Basic xxxxxxxxx

• 服務(wù)端對Authorization進(jìn)行解析并驗(yàn)證用戶，正確則返回一條包含Request-URI資源的響應(yīng)

2.Digest認(rèn)證

• 客戶端請求服務(wù)器后，服務(wù)器返回狀態(tài)碼401 和 Authorization Required 并且返回WWW-Authenticate 的首部字段的響應(yīng)。

• 客戶端將包含DIGEST認(rèn)證必須的首字段Authorization信息。首部字段包含username 、realm、nonce、uri和response的字段信息。

• 服務(wù)端對Authorization進(jìn)行解析并驗(yàn)證用戶，正確則返回一條包含Request-URI資源的響應(yīng)。并且會(huì)在首部字段Authentication-Info寫入一些認(rèn)證成功的相關(guān)信息。

  3.SSL客戶端認(rèn)證

  SSL 即是HTTPS請求的認(rèn)證過程，客戶端必須事先將可證書安裝。

• 服務(wù)器接收到需要認(rèn)證資源的請求，發(fā)送Certificate Request報(bào)文，要求客戶端提供客戶端證書。

• 客戶端將證書信息以Client Certificate報(bào)文方式發(fā)送給服務(wù)器。

• 服務(wù)端驗(yàn)證通過后方可領(lǐng)取證書內(nèi)客戶端的公開密鑰，開始HTTPS通信。

  4.基于表單驗(yàn)證

  多數(shù)web程序使用的認(rèn)證方式，通過表單登錄服務(wù)器，通過session和cookie的方式進(jìn)行驗(yàn)證。

1.HTTP的瓶頸

• 一條鏈接上只能發(fā)送一個(gè)請求
• 請求只能從客戶端開始，服務(wù)器進(jìn)行響應(yīng)
• 請求、響應(yīng)的首部未經(jīng)壓縮，內(nèi)容越多，傳輸越慢
• 每次發(fā)送相同的首部信息，造成資源的浪費(fèi)
• 壓縮格式可以任選，不是強(qiáng)制壓縮發(fā)送

2.解決辦法

• Ajax(Asynchronous JavaScript and XML) 請求，通過異步加載的方式，來局部的更新web應(yīng)用的頁面

• Comet客戶端向服務(wù)器發(fā)起請求后，服務(wù)器不會(huì)立即響應(yīng)，而是先將響應(yīng)掛起，等到有內(nèi)容更新的時(shí)候，才會(huì)向客戶端返回響應(yīng)。但是這樣會(huì)消耗服務(wù)器的資源。

• SPDY 在TCP/IP的應(yīng)用層與傳輸層之間通過新加會(huì)話層的形式運(yùn)作。通信中使用SSL加密。它有以下功能：

  ? 多路復(fù)用：單一的TCP鏈接可以無限制的處理多個(gè)HTTP請求，TCP處理的效率得到提高。

  ? 賦予請求優(yōu)先級(jí)：可以給請求分配優(yōu)先級(jí)順序。

  ? 壓縮HTTP首部：壓縮請求和響應(yīng)的首部，提高效率。

  ? 支持推送功能：服務(wù)器可以直接發(fā)送數(shù)據(jù)到客戶端。

  ? 服務(wù)器提示功能：服務(wù)器可以主動(dòng)提示客戶端請求所需的資源。

3.WebSocket協(xié)議

WebSocket通信協(xié)議建立后，客戶端和服務(wù)端可以互相發(fā)送任意格式的數(shù)據(jù)。

主要特點(diǎn)：

• 推送功能
• 減少通信量 建立連接后會(huì)一直保持連接，且首部信息很小。建立連接只需要一次握手。

4.HTTP2.0

HTTP/2協(xié)議是基于HTTPS的，所以它的安全性有保障。相比HTTP/1.1性能上的改進(jìn)

• 頭部壓縮：會(huì)壓縮頭部，如果同時(shí)發(fā)出多個(gè)請求，他們的頭是一樣的或者相似的，協(xié)議會(huì)幫你消除重復(fù)的部分
• 二進(jìn)制格式： 不再采用HTTP/1.1中的純文本形式的報(bào)文，全面采用了二進(jìn)制的格式，把頭和請求體稱為頭信息幀和數(shù)據(jù)幀。二進(jìn)制增加了數(shù)據(jù)傳輸?shù)男省?/li>
• 數(shù)據(jù)流：數(shù)據(jù)包不是按照順序發(fā)送的，同一個(gè)連接里面連接的數(shù)據(jù)包，可能屬于不同的回應(yīng)。每個(gè)請求或回應(yīng)的所有數(shù)據(jù)包稱為一個(gè)數(shù)據(jù)流。客戶端還可以指定數(shù)據(jù)流的優(yōu)先級(jí)。
• 多路復(fù)用：可以在一個(gè)連接中并發(fā)的發(fā)送多個(gè)請求，而不用按照順序一一對應(yīng)的響應(yīng)。降低了延遲，大幅度的提高了連接的利用率。
• 服務(wù)器推送：服務(wù)器可以主動(dòng)向客戶端發(fā)送數(shù)據(jù)。

5.HTTP/3

• 把傳輸層的TCP協(xié)議改成了UDP協(xié)議，TCP協(xié)議是可靠的，UDP不是可靠的協(xié)議，但是基于UPD的QUIC協(xié)議可以實(shí)現(xiàn)類似TCP的可靠性傳輸。

• HTTPS 要建立一個(gè)連接，要花費(fèi) 6 次交互，先是建立三次握手，然后是 TLS/1.3 的三次握手。QUIC 直接把以往的 TCP 和 TLS/1.3 的 6 次交互合并成了 3 次，減少了交互次數(shù)。