本篇文章給大家分享的是有關(guān)HTTP 基礎(chǔ)知識(shí)有哪些，小編覺(jué)得挺實(shí)用的，因此分享給大家學(xué)習(xí)，希望大家閱讀完這篇文章后可以有所收獲，話不多說(shuō)，跟著小編一起來(lái)看看吧。

讓客戶滿意是我們工作的目標(biāo)，不斷超越客戶的期望值來(lái)自于我們對(duì)這個(gè)行業(yè)的熱愛(ài)。我們立志把好的技術(shù)通過(guò)有效、簡(jiǎn)單的方式提供給客戶，將通過(guò)不懈努力成為客戶在信息化領(lǐng)域值得信任、有價(jià)值的長(zhǎng)期合作伙伴，公司提供的服務(wù)項(xiàng)目有：主機(jī)域名、雅安服務(wù)器托管、營(yíng)銷軟件、網(wǎng)站建設(shè)、大興安嶺網(wǎng)站維護(hù)、網(wǎng)站推廣。

HTTP 是什么

HTTP是一種超文本傳輸協(xié)議，用于完成客戶端和服務(wù)器端等等一系列的運(yùn)作流程。而協(xié)議指的是規(guī)則的約定?？梢哉f(shuō)，Web 是建立在 HTTP 協(xié)議上進(jìn)行通信的。

HTTP的誕生

我相信大家也是這樣，在學(xué)一門技術(shù)之前都會(huì)去了解一下它的歷史，下面來(lái)看看 HTTP 的發(fā)展史。

HTTP 誕生于 1989 年 3 月。是一個(gè)名叫蒂姆伯納斯-李的哥們兒提出的，最初設(shè)想的基本理念是：借助多文檔之間相互關(guān)聯(lián)形成的超文本，連成可相互參閱的 WWW（World Wide Web，萬(wàn)維網(wǎng)）。簡(jiǎn)稱 Web。

HTTP 0.9 在 1990 年問(wèn)世。那時(shí)候的 HTTP 還沒(méi)有作為正式的標(biāo)準(zhǔn)被建立。

HTTP 1.0 在 1996 年 5 月 正式作為標(biāo)準(zhǔn)。該協(xié)議標(biāo)準(zhǔn)現(xiàn)在仍然被廣泛使用在服務(wù)器端。

HTTP 1.1 在 1997 年 1 月公布為當(dāng)前主流的 HTTP 協(xié)議版本。

HTTP 2.0 在 2012 年 3 月 征集建議。

HTTP 2.0 在 同年的 9 月份 發(fā)布了第一個(gè)草案。

HTTP 2.0 在 2014 年 11 月實(shí)現(xiàn)了標(biāo)準(zhǔn)化。

了解 TCP/IP

在理解 HTTP 之前，我們先簡(jiǎn)單的來(lái)了解一下 TCP/IP 協(xié)議族。一般使用的網(wǎng)絡(luò)都是在 TCP/IP 協(xié)議的基礎(chǔ)上運(yùn)作的，而 HTTP 屬于它內(nèi)部的一個(gè)子集。

TCP/IP 協(xié)議族

在計(jì)算機(jī)和網(wǎng)絡(luò)設(shè)備進(jìn)行互相通信時(shí)，雙方都必須基于相同的方法。比如，如何探測(cè)到通信目標(biāo)，是哪邊先發(fā)起通信、用什么語(yǔ)言進(jìn)行通信、怎樣結(jié)束通信等等一些規(guī)則都是先要確定好的。不同的硬件、操作系統(tǒng)之間的通信，所有的這一切都需要一種規(guī)則。而這種規(guī)則稱為協(xié)議。

協(xié)議中包括：從電纜的規(guī)格到 IP 地址的選定方法、尋找異地用戶的方法、雙方建立通信的順序，以及 Web 頁(yè)面顯示要處理的步驟，等等。將這些相關(guān)聯(lián)的協(xié)議集合起來(lái)總稱為 TCP/IP。

TCP/IP 模型各層作用

TCP/IP 重要的點(diǎn)就是分層。有以下4層：應(yīng)用層、傳輸層、網(wǎng)絡(luò)層和數(shù)據(jù)鏈路層。

TCP四層.png

下面來(lái)介紹各層的作用。

•  應(yīng)用層：應(yīng)用層決定了向用戶提供應(yīng)用服務(wù)時(shí)通信的活動(dòng)。比如，F(xiàn)TP(文件傳輸協(xié)議)和 DNS(域名解析系統(tǒng))。HTTP 協(xié)議也在該層。

•  傳輸層：傳輸層對(duì)上層應(yīng)用層，提供處于網(wǎng)絡(luò)連接中的兩臺(tái)計(jì)算機(jī)之間的數(shù)據(jù)傳送。該層有兩個(gè)不同的協(xié)議：TCP 傳輸控制協(xié)議和 UDP 用戶數(shù)據(jù)協(xié)議。

•  網(wǎng)絡(luò)層：網(wǎng)絡(luò)層用來(lái)處理在網(wǎng)絡(luò)上的數(shù)據(jù)包。數(shù)據(jù)包是網(wǎng)絡(luò)傳輸?shù)淖钚?shù)據(jù)單位。網(wǎng)絡(luò)層的作用就是在多條路線中選出一條傳輸路線進(jìn)行數(shù)據(jù)傳輸。

•  鏈路層：用來(lái)處理連接網(wǎng)絡(luò)的硬件部分。包括什么操作系統(tǒng)、硬件的設(shè)備、什么路由器啊之類的等等，都屬于該層。

TCP/IP 層次化的好處是：如果互聯(lián)網(wǎng)由一個(gè)協(xié)議統(tǒng)一規(guī)劃，某個(gè)地方需要改變?cè)O(shè)計(jì)時(shí)，就必須將所有部分整體替換掉。而分層之后只需要把變動(dòng)的層替換掉。把各層之間的接口部分規(guī)劃好之后，每層內(nèi)部的設(shè)計(jì)就可以自由改動(dòng)。比如，處于應(yīng)用層上的應(yīng)用可以只考慮分配給自己的任務(wù)，不用去考慮其他的問(wèn)題。

TCP/IP 通信傳輸流

TCP/IP 協(xié)議進(jìn)行通信時(shí)，會(huì)通過(guò)分層順序和對(duì)方進(jìn)行通信。客戶端從應(yīng)用層往下走，服務(wù)器端則從鏈路層往上走?？聪旅娴膱D。

1.3.1.jpg

•  首先客戶端在應(yīng)用層發(fā)出一個(gè) HTTP 請(qǐng)求。

•  接著，在傳輸層接收到應(yīng)用層的數(shù)據(jù)后進(jìn)行分割，給每個(gè)報(bào)文打上標(biāo)記序號(hào)以及端口號(hào)轉(zhuǎn)發(fā)給網(wǎng)絡(luò)層。

•  在網(wǎng)絡(luò)層，添加通信目的地的 MAC 地址后轉(zhuǎn)發(fā)給鏈路層。

•  接收端（也叫服務(wù)器端）的服務(wù)器在鏈路層接收到數(shù)據(jù)，按次序向上層發(fā)送，一直到應(yīng)用層。傳輸?shù)綉?yīng)用層才算真正接收到客戶端發(fā)過(guò)來(lái)的 HTTP 請(qǐng)求。

和HTTP相關(guān)的協(xié)議

在HTTP客戶端向服務(wù)器端發(fā)送報(bào)文之前，需要用到 IP、TCP、DNS 這三個(gè)和 HTTP 密不可分的協(xié)議。

IP 網(wǎng)絡(luò)協(xié)議

IP（Internet Protocol）網(wǎng)絡(luò)協(xié)議處于網(wǎng)絡(luò)層。IP協(xié)議的作用是把各種數(shù)據(jù)包傳送給對(duì)方。但要保證正確的傳送給對(duì)方，其中兩個(gè)重要的條件是 IP 地址和 MAC 地址?？梢园阉胂蟪赡慵业牡刂?，或者說(shuō)你的電話號(hào)碼。

IP 地址指的是節(jié)點(diǎn)被分配到的地址，MAC 地址指的是網(wǎng)卡所屬的固定地址。IP 地址可以跟 MAC 地址進(jìn)行配對(duì)。IP 地址是可變的，MAC 地址是不可變的。

IP 和 IP地址別搞混了，IP是一種協(xié)議。而IP地址是則是每臺(tái)計(jì)算機(jī)的標(biāo)識(shí)

ARP 協(xié)議

IP 間的通信依賴 MAC 地址。在網(wǎng)絡(luò)上通信的雙方很少會(huì)在同一個(gè)局域網(wǎng)，一般都是經(jīng)過(guò)多臺(tái)計(jì)算機(jī)或者網(wǎng)絡(luò)設(shè)備中專才能連接到對(duì)方。而在中轉(zhuǎn)的過(guò)程中，會(huì)利用下一站中轉(zhuǎn)設(shè)備的 MAC 地址進(jìn)行搜索下一個(gè)中轉(zhuǎn)目標(biāo)。而這時(shí)，會(huì)用到ARP協(xié)議。ARP協(xié)議是一種用來(lái)解析地址的協(xié)議，通過(guò)通信方的 IP 地址就能反查出對(duì)應(yīng)的 MAC 地址。

在到達(dá)通信目標(biāo)前的中轉(zhuǎn)過(guò)程中，計(jì)算機(jī)和路由器只能獲取粗略的傳輸路線，這種機(jī)制叫做路由選擇。

就跟你在淘寶上買東西是一樣的道理。比如，你在淘寶網(wǎng)買了件衣服，快遞公司會(huì)根據(jù)你的地址進(jìn)行送貨，在送貨這個(gè)過(guò)程中，并不是直接送到你手里。而是經(jīng)過(guò)各種什么杭州中轉(zhuǎn)站然后又到深圳中轉(zhuǎn)站，之后才送到你手里。

TCP 協(xié)議

TCP 協(xié)議處于傳輸層，主要的作用是提供可靠的字節(jié)流服務(wù)。字節(jié)流服務(wù)指的是，為了方便傳輸，將大塊的數(shù)據(jù)分割成以報(bào)文段為單位的數(shù)據(jù)包進(jìn)行管理。而可靠性的傳輸服務(wù)指的是，能夠把數(shù)據(jù)準(zhǔn)確可靠的傳給對(duì)方。

為了準(zhǔn)確的將數(shù)據(jù)傳送給對(duì)方，三次握手就出現(xiàn)了。下圖展示這個(gè)過(guò)程。

1.4.1.jpg

1. 鴻蒙官方戰(zhàn)略合作共建——HarmonyOS技術(shù)社區(qū)

2.  第一次握手：客戶端先發(fā)送一個(gè)帶 SYN 標(biāo)志的數(shù)據(jù)包給對(duì)方。

3.  第二次握手：服務(wù)器端收到之后，回傳一個(gè)帶有 SYN/ACK 標(biāo)志的數(shù)據(jù)包表示傳達(dá)確認(rèn)信息。

4.  第三次握手：最后，客戶端再傳回一個(gè)帶 ACK 標(biāo)志的數(shù)據(jù)包，表示 “握手” 結(jié)束。

DNS 服務(wù)

DNS 服務(wù)和 HTTP協(xié)議一樣，處于應(yīng)用層。它主要的作用是，將域名解析成 IP 地址。DNS 協(xié)議可以通過(guò)域名查找 IP 地址，也可以通過(guò) IP 地址反查域名的服務(wù)。

下面展示每個(gè)協(xié)議和HTTP協(xié)議的關(guān)系。

什么是URL和URI？

•  URL指的是統(tǒng)一資源定位符，是訪問(wèn)Web網(wǎng)站需要輸入的網(wǎng)站地址。例如，http://www.tutu.com。

•  URI指的是統(tǒng)一資源標(biāo)識(shí)符，全稱為Uniform Resource Identifier，它的作用是區(qū)分互聯(lián)網(wǎng)中的不同資源。比如，HTML 文檔、圖像、視頻片段、程序等等。而 URL 是 URI 的一個(gè)子集。

URI格式

下圖展示了 URI 的格式。

URI.jpg

•  協(xié)議名：http:或https:表示協(xié)議名稱。不區(qū)分字母大小寫(xiě)，最后加上//。

•  登錄信息：user:pass@ 表示獲取服務(wù)器資源的用戶和密碼。但不推薦使用，因?yàn)椴话踩?/p>

•  服務(wù)器地址：服務(wù)器地址有三種：

•  以域名的形式www.tutu.com;

•  以 IPv4 192.168.0.1地址名;

•  以[0:0:0:0:0:0:1]這種方括號(hào)括起來(lái)的 IPv6 地址;

•  服務(wù)器端口號(hào)：:8080表示端口號(hào)。

•  文件路徑：/html/index.html表示服務(wù)器文件路徑，資源的訪問(wèn)位置。

•  查詢字符串：?userId=1表示文件路徑中的參數(shù)。?后面以key=value的形式。如果后面還需要加參數(shù)，用&拼接。

•  片段標(biāo)識(shí)符：#cn1表示文件中的某個(gè)位置。就是平時(shí)的網(wǎng)頁(yè)錨點(diǎn)定位。

HTTP基礎(chǔ)

HTTP 是一種無(wú)狀態(tài)的協(xié)議，對(duì)發(fā)送過(guò)的請(qǐng)求/響應(yīng)都不做持久化處理。

持久化連接

HTTP 1.1 中的所有連接都是默認(rèn)開(kāi)啟的（keep-alive）。通過(guò)請(qǐng)求/響應(yīng)頭部的Connection字段可以查看是否開(kāi)啟持久化連接（后面會(huì)介紹該字段的值），而在 HTTP1.0中是默認(rèn)關(guān)閉的（close）。

它的特點(diǎn)是，不管是客戶端還是服務(wù)器端，只要其中的一端沒(méi)有提出斷開(kāi)連接，那么就會(huì)保持 TCP 連接。好處是，減少 TCP 連接的重復(fù)建立和斷開(kāi)連接造成的額外開(kāi)銷，減輕服務(wù)器壓力。這樣使得 HTTP 請(qǐng)求和響應(yīng)速度更快結(jié)束，也提高頁(yè)面的顯示速度。

管線化

管線化是不用等待響應(yīng)就可以發(fā)送下一個(gè)請(qǐng)求，也就是并行處理。不用一個(gè)接一個(gè)的等待響應(yīng)，管線化比持久化連接還要更快。

HTTP 報(bào)文

HTTP 一共有兩種報(bào)文：請(qǐng)求報(bào)文、響應(yīng)報(bào)文。報(bào)文又分為報(bào)文頭部和報(bào)文主體，報(bào)文主體是可選的。報(bào)文包含了以下三個(gè)部分。

•  起始行（start line）有以下兩種類型。

•  請(qǐng)求行：請(qǐng)求的方法、請(qǐng)求的 URL、HTTP的版本

•  響應(yīng)行：HTTP 版本、狀態(tài)碼

•  頭部字段（header）：一些頭部信息，以key: value的形式。

•  主體（body）：被發(fā)送的數(shù)據(jù)。

報(bào)文主體.jpg

這張圖是以請(qǐng)求報(bào)文為例。

HTTP 的請(qǐng)求方法

•  GET：獲取服務(wù)器資源。

•  POST：提交信息給服務(wù)器。

•  PUT：傳輸文件。

•  HEAD：和 GET 方法一樣。但是只返回響應(yīng)頭部。作用是確定 URL 的有效性和資源更新的時(shí)間。

•  DELETE：刪除指定的資源。

•  OPTIONS：查詢請(qǐng)求服務(wù)器指定的資源所支持的方法。

•  TRACE：用來(lái)確認(rèn)連接過(guò)程中發(fā)生的一些操作。

•  CONNECT：建立連接渠道，用于代理服務(wù)器。

HTTP 狀態(tài)碼

1xx

1XX表示接收的請(qǐng)求正在處理。

2xx 成功

•  200 OK：表示客戶端發(fā)送的請(qǐng)求在服務(wù)器端被正常處理了。

•  204 No Content：表示請(qǐng)求被處理成功，但沒(méi)有資源可返回。

•  206 Partial Content：表示客戶端只獲取文件的一部分內(nèi)容，而服務(wù)器成功執(zhí)行了這部分的GET請(qǐng)求。響應(yīng)報(bào)文中含Content-Range指定部分的實(shí)體內(nèi)容。

3xx 重定向

• 301 Moved Permanenty：永久重定向。表示請(qǐng)求的資源已經(jīng)被分配了新的 URL，以后就使用資源現(xiàn)在所指的 URL。

•  302 Found：臨時(shí)重定向。表示請(qǐng)求的資源被分配了新的 URL。

•  303 See Other：表示請(qǐng)求的資源存著另一個(gè) URL，應(yīng)該用GET方法獲取請(qǐng)求的資源。

•  304 Not Modified：表示請(qǐng)求已經(jīng)找到，但不符合條件請(qǐng)求。協(xié)商緩存就會(huì)返回這個(gè)狀態(tài)碼。

•  307 Temporary Redirect：臨時(shí)重定向，和302類似。但是補(bǔ)鞥呢改變請(qǐng)求方法。

當(dāng)301、302、303響應(yīng)狀態(tài)碼返回時(shí)，幾乎所有瀏覽器都會(huì)將POST改為GET，并刪除請(qǐng)求報(bào)文中的主體，之后請(qǐng)求會(huì)自動(dòng)再次發(fā)送。301、302標(biāo)準(zhǔn)是禁止把POST改成GET的，但實(shí)際使用的時(shí)候大家都會(huì)這么做。

4xx 客戶端錯(cuò)誤

•  400 Bad Request：表示請(qǐng)求報(bào)文中存在語(yǔ)法錯(cuò)誤。

•  401 Unauthorized：表示發(fā)送的請(qǐng)求要通過(guò) HTTP 認(rèn)證的認(rèn)證消息。如果之前請(qǐng)求過(guò)一次，就表示用戶認(rèn)證失敗。

•  403 Forbidden：表示對(duì)請(qǐng)求資源的訪問(wèn)被服務(wù)器拒絕。

•  404 Not Found：表示服務(wù)器上無(wú)法找到請(qǐng)求的資源。

5xx 服務(wù)器錯(cuò)誤

•  500 Internal Serve Error：表示服務(wù)器端在執(zhí)行請(qǐng)求時(shí)發(fā)生錯(cuò)誤。

•  503 Service Unavailable：表示服務(wù)器暫處于超負(fù)荷或者正在進(jìn)行停機(jī)維護(hù)。

和HTTP相關(guān)Web服務(wù)器

HTTP進(jìn)行通信時(shí)，除了客戶端和服務(wù)器端這兩個(gè)之外，還有一些用于通信數(shù)據(jù)轉(zhuǎn)發(fā)的應(yīng)用程序。例如代理、網(wǎng)關(guān)、隧道和緩存。

代理

代理是一種具有轉(zhuǎn)發(fā)功能的應(yīng)用程序，它存在于客戶端和服務(wù)器端之間，相當(dāng)于一個(gè)中間人。它將客戶端發(fā)送過(guò)來(lái)的請(qǐng)求并轉(zhuǎn)發(fā)給服務(wù)器端。當(dāng)然，它也會(huì)將服務(wù)器端返回的響應(yīng)轉(zhuǎn)發(fā)給客戶端。

代理服務(wù)器.jpg

每次通過(guò)代理服務(wù)器轉(zhuǎn)發(fā)請(qǐng)求或響應(yīng)時(shí)，頭部都會(huì)出現(xiàn)Via這個(gè)字段。

網(wǎng)關(guān)

網(wǎng)關(guān)是一種特殊的服務(wù)器，作為其他服務(wù)器的中間實(shí)體使用。用于將 HTTP 請(qǐng)求轉(zhuǎn)化成其他協(xié)議通信。網(wǎng)關(guān)接收請(qǐng)求時(shí)就好像自己的資源的源服務(wù)器一樣對(duì)請(qǐng)求做處理。

網(wǎng)關(guān).jpg

隧道

隧道是可按要求建立一條和其他服務(wù)器的通信線路，到時(shí)候使用 SSL 加密進(jìn)行通信。隧道的目的是保證客戶端和服務(wù)器進(jìn)行安全的通信。

隧道.jpg

緩存

緩存是指代理服務(wù)器或客戶端本地磁盤(pán)中保存的資源副本。利用緩存可以減少向源服務(wù)器的訪問(wèn)，主要目的是減少網(wǎng)絡(luò)帶寬的流量和通信時(shí)間。

緩存服務(wù)器是代理服務(wù)器的一種，當(dāng)代理轉(zhuǎn)發(fā)從服務(wù)器返回的響應(yīng)時(shí)，會(huì)保存一份資源的副本。緩存服務(wù)器的優(yōu)點(diǎn)在于通過(guò)緩存可以避免多次從源服務(wù)器轉(zhuǎn)發(fā)資源。因此客戶端可就近從緩存服務(wù)器上獲取資源，而源服務(wù)器也不必多次處理相同的請(qǐng)求。

緩存的有效期

每當(dāng)源服務(wù)器上的資源更新時(shí)，如果還是用不變的緩存，那就會(huì)變成返回更新前的舊資源。

即使存在緩存，也會(huì)因?yàn)榭蛻舳说囊?、緩存的有效期等等一些因素，向源服?wù)器確認(rèn)資源的有效性。如果緩存的資源已過(guò)期，緩存服務(wù)器會(huì)向源服務(wù)器上獲取新的資源。

客戶端緩存

這里的客戶端緩存指的是瀏覽器中的緩存。瀏覽器緩存如果未過(guò)期，就不用向源服務(wù)器請(qǐng)求相同的資源，直接獲取緩存在本地磁盤(pán)中的資源。當(dāng)資源過(guò)期時(shí)，會(huì)向源服務(wù)器確認(rèn)資源的有效性。如果緩存的資源過(guò)期，就會(huì)再次向源服務(wù)器發(fā)起資源請(qǐng)求。

內(nèi)容協(xié)商

內(nèi)容協(xié)商機(jī)制是指客戶端和服務(wù)器端就響應(yīng)的資源內(nèi)容進(jìn)行互相協(xié)商，然后提供客戶端最合適的資源。內(nèi)容協(xié)商會(huì)以語(yǔ)言、字符集、編碼方式等。

主要使用的請(qǐng)求頭有：

•  Accept

•  Accept-Charset

•  Accept-Language

•  Content-Language

內(nèi)容協(xié)商技術(shù)有下面三種類型。

•  服務(wù)器驅(qū)動(dòng)協(xié)商（Server-driven Negotiation）

•  由服務(wù)器進(jìn)行內(nèi)容協(xié)商。

•  客戶端啟動(dòng)協(xié)商（Agent-driven Negotiation）

•  由客戶端進(jìn)行內(nèi)容協(xié)商。

•  透明協(xié)商 服務(wù)器驅(qū)動(dòng)和客戶端驅(qū)動(dòng)的結(jié)合體，由服務(wù)器和客戶端進(jìn)行內(nèi)容協(xié)商的一種方法。

End-to-end頭部和Hop-by-hop頭部

HTTP 頭字段定義成緩存代理和非緩存代理。分為兩種類型。

•  端到端頭部End-to-end

         分在這個(gè)類別中的頭部會(huì)轉(zhuǎn)發(fā)給請(qǐng)求或響應(yīng)對(duì)應(yīng)的最終接收目標(biāo)，而且必須保存在緩存生成的響應(yīng)中，另外規(guī)定它必須被轉(zhuǎn)發(fā)。

•  逐跳頭部Hop-by-hop

         分在這個(gè)類別中的頭部只對(duì)單次轉(zhuǎn)發(fā)有效，會(huì)因通過(guò)緩存或代理而不轉(zhuǎn)發(fā)。在 HTTP 1.1 和之后的版本中，如果使用Hop-by-hop頭，就要提供 Connection 頭字段。

除了下面 8 個(gè)頭字段外，其他所有字段都屬于端到端頭部。

•  Connection

•  Keep-Alive

•  Proxy-Authenticate

•  Proxy-Authorization

•  Trailer

•  TE

•  Transfer-Encoding

•  Upgrade

HTTP通用頭部字段

下面列出請(qǐng)求/響應(yīng)頭都會(huì)出現(xiàn)的字段，這些字段都含有重要的信息。

Cache-Control

Cache-Control表示資源的緩存操作，參數(shù)是可選的，如果存在多個(gè)參數(shù)的話，以,分隔開(kāi)。

請(qǐng)求頭

在請(qǐng)求頭中使用Cache-Control字段時(shí)，它的值如下：

•  no-cache：不使用強(qiáng)緩存，強(qiáng)制向源服務(wù)器再次驗(yàn)證緩存的資源是否過(guò)期（走協(xié)商緩存）。

•  no-store：不使用任何緩存，每次都向源服務(wù)器獲取最新的資源。

•  max-age：以秒為單位。表示緩存的資源沒(méi)有超過(guò)指定的時(shí)間，客戶端就從緩存中獲取資源。

•  min-fresh：以秒為單位。要求代理服務(wù)器返回至少還沒(méi)過(guò)指定時(shí)間的緩存資源。

•  max-stale：即使是過(guò)期的資源，也照樣接收。

•  only-if-cached：告訴代理服務(wù)器，從緩存中獲取資源（如果有）。

•  no-transform：不能對(duì)資源進(jìn)行轉(zhuǎn)換，可以防止緩存或代理壓縮圖片等類似操作。

響應(yīng)頭

在響應(yīng)頭中使用Cache-Control字段時(shí)，它的值如下：

•  public：資源可被瀏覽器和代理服務(wù)器進(jìn)行緩存。

•  private：資源只可以被瀏覽器進(jìn)行緩存。其他都不可以。

•  no-cache：可以緩存，但每次使用前要向源服務(wù)器驗(yàn)證緩存資源是否過(guò)期。

•  s-maxage：只提供給代理服務(wù)器，表示代理服務(wù)器中的資源過(guò)期時(shí)長(zhǎng)，用s-maxage后，會(huì)忽略max-age和Expires字段。

•  max-age：以秒為單位。設(shè)置緩存時(shí)間，如果沒(méi)超過(guò)該時(shí)間，不用向服務(wù)器請(qǐng)求資源。如果超過(guò)，就證明資源已過(guò)期。如果響應(yīng)頭出現(xiàn)Expires字段，在 HTTP 1.1 中會(huì)有限處理max-age，而 HTTP1.0 中則相反。

•  must-revalidate：可以緩存，但必須向源服務(wù)器再次驗(yàn)證。如果請(qǐng)求失敗，則返回504狀態(tài)碼。該字段會(huì)忽略max-stale。

•  proxy-revalidate：要求緩存服務(wù)器對(duì)緩存的響應(yīng)有效性進(jìn)行確認(rèn)。

•  no-transform：不能對(duì)資源進(jìn)行轉(zhuǎn)換，可以防止緩存或代理壓縮圖片等類似操作。

Connection

Connection字段決定當(dāng)前 TCP連接 完成后，是否關(guān)閉連接。有以下兩種。

•  keep-Alive：持久化連接。

•  close：TCP 連接完成后，立馬關(guān)閉連接。

Date

Date字段的值為GMT時(shí)間日期格式，表示 HTTP 報(bào)文創(chuàng)建的時(shí)間和日期。

Date: Tue, 13 Apr 2021 12:35:41 GMT

Pragma

Pragma是用來(lái)向后兼容只支持 HTTP1.0 協(xié)議的緩存服務(wù)器。它的效果和Cache-Control一樣。

Pragma: no-cache

Upgrade

Upgrade用于查看 HTTP 協(xié)議或者其他協(xié)議是否可以使用更高的版本進(jìn)行通信。

Upgrade: HTTP/2.0  Connection: Upgrade 

Via

Via用于跟蹤客戶端和服務(wù)器端之間的請(qǐng)求和響應(yīng)報(bào)文的傳輸路徑，還可以避免請(qǐng)求循環(huán)的發(fā)生。

  Via: 1.0 gw.hackr.jp(Squid/3.1)   Via: 1.0 gw.hackr.jp(Squid/3.1), 1.1 al.example.com(Squid/2.7)

經(jīng)過(guò)代理服務(wù)器 A 時(shí)，Via頭部附加了 “1.0 gw.hackr.jp(Squid/3.1)” 這樣的字符串值。行頭 1.0 指的是接收請(qǐng)求的服務(wù)器上應(yīng)用的 HTTP 協(xié)議版本。如果經(jīng)過(guò)多個(gè)代理服務(wù)器的話，這些信息會(huì)后面追加。

Warning

Warning字段告訴用戶一些與緩存有關(guān)的警告。

請(qǐng)求頭字段

Accept

Accept請(qǐng)求頭用來(lái)告訴服務(wù)器，客戶端能處理的內(nèi)容類型。下面列出幾種媒體類型。

•  文本文件: text/html、text/plain、text/css、application/xhtml+xml、application/xml等等。

•  圖片文件: image/jpeg、image/gif、image/png;

•  視頻文件: video/mpeg、video/quicktime;

•  二進(jìn)制文件：application/octet-stream、application/zip;

當(dāng)值為*/*，表示客戶端可以是任意內(nèi)容類型。當(dāng)值為image/*，用來(lái)代表任何其他圖片類型。

如果想給顯示的媒體類型增加優(yōu)先級(jí)，通過(guò)用q=表示權(quán)重值，用分號(hào)（;）分隔開(kāi)。權(quán)重值的范圍是0~1，可以精確到小數(shù)點(diǎn)后 3 位，1是最大值。沒(méi)有指定權(quán)重值時(shí)，默認(rèn)權(quán)重是q=1.0。

Accept: text/html, appliaction/json;q=0.9

Accept-Charset

Accept-Charset請(qǐng)求頭用來(lái)告訴服務(wù)器，客戶端可處理的字符集類型。另外，可以一次性指定多種字符集。和Accept一樣，通過(guò)q值來(lái)表示優(yōu)先級(jí)。該頭部應(yīng)用于內(nèi)容協(xié)商機(jī)制的服務(wù)器驅(qū)動(dòng)協(xié)商。

Accept-Charset: iso-8859-1  Accept-Charset: iso-8859-1;q=0.5

Accept-Encoding

Accept-Encoding請(qǐng)求頭用來(lái)告訴服務(wù)器，客戶端能理解的內(nèi)容編碼方式?？梢砸淮涡灾付ǘ喾N內(nèi)容編碼，有以下幾種編碼。

•  gzip：由文件壓縮程序 gzip 生成的編碼格式，使用 Lempel-Ziv 算法以及 32 位循環(huán)冗余驗(yàn)證。

•  compress：由 UNIX 文件壓縮程序compress生成的編碼方式，采用Lempel-Ziv-Welch算法。

•  deflate：組合使用 zlib 格式以及由deflate壓縮算法生成的編碼方式。

•  indentity：不執(zhí)行壓縮或不會(huì)變化的默認(rèn)編碼格式。

Accept-Encoding: gzip, deflate

和Accept一樣，用q值來(lái)設(shè)置優(yōu)先級(jí)。還有使用星號(hào)（*），表示指定任意的編碼格式。

Accept-Language

Accept-Language請(qǐng)求頭用來(lái)告訴服務(wù)器，客戶端可以理解的自然語(yǔ)言集（指中文和英文集），以及自然語(yǔ)言集的優(yōu)先級(jí)。和Accept一樣的，可指定多個(gè)自然語(yǔ)言集。使用q值設(shè)置優(yōu)先級(jí)。

Accept-Language: zh-CN,zh;q=0.9;q=0.8

客戶端在服務(wù)器有中文版的情況下，會(huì)請(qǐng)求返回中文版的響應(yīng)，如果沒(méi)有，則返回英文版。

Authorization

Authorization用來(lái)告訴服務(wù)器，用戶代理的認(rèn)證信息（證書(shū)值）。通常會(huì)在服務(wù)器返回401狀態(tài)碼響應(yīng)后，把頭部字段Authorization添加到請(qǐng)求中。

Authorization: Basic dWVub3NlbjpwYXNzd29yZA==

Expect

Expect用來(lái)告訴服務(wù)器，只有在滿足這個(gè)條件的情況下才會(huì)處理請(qǐng)求。如果服務(wù)器不能滿足客戶端的要求，會(huì)返回417狀態(tài)碼。目前只規(guī)定了100-continue這個(gè)條件。

Expect: 100-continue

From

From字段表示用戶代理的用戶的電子郵箱地址，目的是為了顯示搜索引擎用戶代理的負(fù)責(zé)人的電子郵箱聯(lián)系方式。

From: info@hackr.jp

Host

Host請(qǐng)求頭指明了請(qǐng)求的資源所在的服務(wù)器主機(jī)名和端口號(hào)。如果服務(wù)器沒(méi)設(shè)置主機(jī)名，會(huì)發(fā)送一個(gè)空值。

Host: www.tutu.com

If-Match

像這種If-xxxx開(kāi)頭的請(qǐng)求頭字段，都是條件請(qǐng)求。服務(wù)器接收到附帶條件的請(qǐng)求后，只判斷條件是真時(shí)才會(huì)執(zhí)行請(qǐng)求。

If-Match字段用于和服務(wù)器資源的ETag值做對(duì)比時(shí)，ETag值和If-Match的值相等時(shí)才會(huì)處理該請(qǐng)求。否則返回412狀態(tài)碼。通過(guò)用星號(hào)（*）的方式，表示只要資源存在就處理請(qǐng)求，但服務(wù)器會(huì)忽略掉ETag的值。

If-Match: "123456"

If-Modified-Since

If-Modified-Since用于確定代理服務(wù)器或客戶端的資源有效性。在指定的時(shí)間之后，請(qǐng)求的資源發(fā)生改變時(shí)，就處理請(qǐng)求。如果資源都沒(méi)有改變，則返回304狀態(tài)碼。

If-Modified-Since: Tue, 13 Apr 2021 12:35:41 GMT

If-None-Match

If-None-Match和If-Match相反，只有服務(wù)器資源的ETag的值和If-None-Match的值不一樣時(shí)，才會(huì)處理該請(qǐng)求。在GET和HEAD請(qǐng)求方法中加入該字段可以獲取最新的資源。

If-Range

If-Range用于告訴服務(wù)器，如果If-Range字段的值和請(qǐng)求資源的ETag值或時(shí)間一樣時(shí)，就會(huì)作為范圍請(qǐng)求處理（Range字段規(guī)定請(qǐng)求多少字節(jié)的數(shù)據(jù)）。否則，忽略范圍請(qǐng)求，返回全部資源。

If-Range: "123456"  Range: bytes=5001-10000

If-Unmodified-Since

If-Unmodified-Since字段用來(lái)告訴服務(wù)器，只有當(dāng)請(qǐng)求資源在指定的時(shí)間之后沒(méi)有修改的情況下，才會(huì)處理請(qǐng)求。如果在指定的時(shí)間后發(fā)生了修改，則返回412狀態(tài)碼。

If-Unmodified-Since: Tue, 13 Apr 2021 12:35:41 GMT

Proxy-Authorization

Proxy-Authorization字段包含了用戶代理提供給代理服務(wù)器用于身份驗(yàn)證的憑證。

Proxy-Authorization: Basic dGlwOjkpNLAGfFY5

Range

Range請(qǐng)求頭字段表示獲取資源的哪一部分。服務(wù)器收到帶有Range字段的請(qǐng)求后，會(huì)在處理請(qǐng)求之后返回206狀態(tài)碼。如果無(wú)法處理，則返回200狀態(tài)碼并把全部資源返回。

Range: bytes=5001-10000 

Referer

Referer字段表示請(qǐng)求的URL是從哪個(gè) Web 頁(yè)面發(fā)起的。服務(wù)器通過(guò)Referer字段來(lái)標(biāo)識(shí)訪問(wèn)來(lái)源，進(jìn)行統(tǒng)計(jì)分析、日志記錄和緩存優(yōu)化。

Referer: www.tutu.com 

TE

TE表示客戶端能夠處理響應(yīng)的傳輸編碼方式以及優(yōu)先級(jí)。

TE: gzip, deflate;q=0.5

User-Agent

User-Agent字段用于把請(qǐng)求的瀏覽器和用戶代理名稱等信息傳給服務(wù)器。

User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 11_2_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/89.0.4389.128 Safari/537.36

響應(yīng)頭字段

Accept-Ranges

Accept-Ranges表示服務(wù)器端能處理指定范圍內(nèi)的資源。有兩個(gè)值：bytes和none。none表示不能處理指定范圍內(nèi)的請(qǐng)求。

Age

Age表示源服務(wù)器再多久前返回過(guò)資源。單位為秒。

Age: 3600

ETag

ETag表示資源的特定標(biāo)識(shí)符，服務(wù)器會(huì)給每份資源都分配對(duì)應(yīng)的ETag值。當(dāng)資源發(fā)生變化時(shí)，ETag值也會(huì)改變。例如，訪問(wèn)同一個(gè) URL 的網(wǎng)站同時(shí)具備有中英文版，當(dāng)切換中文時(shí)，會(huì)返回中文的資源（ETag: user-chi），而切換到英文時(shí)，返回的是英文的資源（ETag: user-us）。

強(qiáng)弱ETag

•  強(qiáng)ETag: 不管資源發(fā)生了什么變化都會(huì)改變其值。

ETag: "user-123456"

•  弱ETag: 用于資源是否相同，只有資源發(fā)生了根本改變，產(chǎn)生差異時(shí)才會(huì)改變ETag值。字段值最開(kāi)頭會(huì)添加W/的字符 

ETag: W/"user-123456"

Location

Location字段表示需要將頁(yè)面重定向到某個(gè)地址，一般都是響應(yīng)碼為3xx的響應(yīng)才有用。

Location: www.baidu.com 

Proxy-Authenticate

Proxy-Authenticate字段表示獲取代理服務(wù)器的資源要通過(guò)身份驗(yàn)證的方式。

Retry-After

Retry-After字段表示客戶端應(yīng)該在多久之后再次請(qǐng)求。配合503和3xx狀態(tài)碼響應(yīng)一起使用。

Retry-After: 120

Server

Server字段表示處理請(qǐng)求的服務(wù)器所用到的軟件相關(guān)信息。

Server: Apache/2.2.17

Vary

Vary字段可以對(duì)緩存進(jìn)行控制。從代理服務(wù)器收到源服務(wù)器返回含有Vary指定項(xiàng)的響應(yīng)后，如果要進(jìn)行緩存，那么會(huì)對(duì)請(qǐng)求中含有Vary指定頭部字段的請(qǐng)求返回緩存。即使對(duì)相同資源發(fā)起請(qǐng)求，如果Vary指定的頭部字段不相同，就必須從源服務(wù)器重新獲取資源。

Vary: Accept-Language

實(shí)體頭字段

Allow

Allow用于告訴客戶端，資源所支持的 HTTP 方法，如果服務(wù)器收到不支持的 HTTP 方法時(shí)，會(huì)返回405狀態(tài)碼作為響應(yīng)。

Allow: GET, DELETE

Content-Encoding

Content-Encoding字段表示服務(wù)器對(duì)實(shí)體的主體部分用的內(nèi)容編碼方式。內(nèi)容編碼在Accept-Encoding中已經(jīng)介紹過(guò)，一共有4種。

Content-Encoding: gzip

Content-Language

Content-Language字段表示實(shí)體主體使用的自然語(yǔ)言。

Content-Language: zh-CN

Content-Length

Content-Length表示實(shí)體主體部分的大?。ㄒ宰止?jié)為單位）。

Content-Length: 1500

Content-Location

Content-Location字段表示要返回?cái)?shù)據(jù)的地址。

Content-Location: https://www.tutu.com/index.html

Content-Range

Content-Range字段表示的是一個(gè)數(shù)據(jù)片段在整個(gè)文件中的位置。

Content-Range: bytes 5001-10000/10000

Content-type

Content-type字段表示實(shí)體主體中對(duì)象的媒體類型。

Content-type: text/html; charset=UTF-8

Expires

Expires字段會(huì)把資源失效的日期告訴客戶端。在這個(gè)日期后，資源就會(huì)過(guò)期。也就是說(shuō)，在指定的日期內(nèi)可以從瀏覽器緩存中獲取資源。如果超過(guò)了這個(gè)日期，就必須向服務(wù)器發(fā)起資源請(qǐng)求。如果頭部存在Cache-Control: max-age時(shí)，會(huì)優(yōu)先處理max-age指令。

Expires: Tue, 13 Apr 2021 12:35:41 GMT

Last-Modified

Last-Modified字段表示資源最后修改的時(shí)間。

Last-Modified: Tue, 13 Apr 2021 12:35:41 GMT

HTTP 緩存

HTTP 緩存可分為強(qiáng)緩存和協(xié)商緩存，主要用于加快資源的獲取速度，提高用戶體驗(yàn)，減少網(wǎng)絡(luò)連接，緩解服務(wù)器壓力。

強(qiáng)緩存

對(duì)強(qiáng)緩存來(lái)說(shuō)，瀏覽器會(huì)判斷請(qǐng)求的資源是否在有效期內(nèi)。如果是在有效期內(nèi)，就直接從緩存中讀取資源，不用向服務(wù)器發(fā)送資源請(qǐng)求。強(qiáng)緩存通過(guò)Expires、Cache-Control和Pragma這三個(gè)頭部字段設(shè)置。

Cache-Control

Cache-Control頭部字段在上面也詳細(xì)介紹過(guò)在各端所具備的屬性值。下面來(lái)列出最常見(jiàn)的幾個(gè)值。

•  public: 該資源可以被瀏覽器和代理服務(wù)器進(jìn)行緩存。

•  private: 該資源只可以被瀏覽器緩存，其他都不可以。

•  no-cache: 不使用強(qiáng)緩存，強(qiáng)制向源服務(wù)器再次驗(yàn)證緩存的有效性。這個(gè)值表示走協(xié)商緩存。

•  no-store: 不使用任何緩存，每次都向源服務(wù)器獲取最新資源。

•  max-age: 如果緩存的資源沒(méi)有超過(guò)規(guī)定的時(shí)間，客戶端就從緩存中獲取資源。以秒為單位。

•  s-maxage: 只適用于代理服務(wù)器，表示代理服務(wù)器中的資源過(guò)期時(shí)長(zhǎng)，用了s-maxage后，會(huì)忽略max-age和Expires字段。

Expires

Expires字段的值是一個(gè)GMT格式的時(shí)間日期，將資源失效的日期告訴客戶端，客戶端收到帶有該字段的響應(yīng)體后進(jìn)行緩存。后續(xù)客戶端發(fā)起相同的資源請(qǐng)求，會(huì)用Expires的值和本地時(shí)間做對(duì)比，如果該請(qǐng)求的本地時(shí)間小于Expires的值，就直接用緩存中的資源，不用向服務(wù)器發(fā)起請(qǐng)求。

Expires的值會(huì)產(chǎn)生一個(gè)問(wèn)題。如果修改了本地時(shí)間，就會(huì)導(dǎo)致客戶端和服務(wù)器端的時(shí)間不一致，那么對(duì)于緩存過(guò)期的判斷就無(wú)法和預(yù)期一樣了。

Expires在三者中優(yōu)先級(jí)最低。

Pragma

Pragma可以看上面的介紹，這里不過(guò)多講解。

強(qiáng)緩存在 Chrome 中會(huì)返回200狀態(tài)碼并且有兩種情況。

•  memory cache: 只要頁(yè)面不關(guān)閉，就會(huì)從瀏覽器內(nèi)存中獲取資源。

•  disk cache: 從磁盤(pán)中讀取緩存資源。

強(qiáng)緩存.jpg

用了強(qiáng)緩存后，如果服務(wù)器端的資源更新了，客戶端是不知道的，而且在過(guò)期之前都會(huì)用緩存中的資源?？梢酝ㄟ^(guò)Ctrl + F5強(qiáng)制刷新。

協(xié)商緩存

協(xié)商緩存是在用本地緩存之前，會(huì)向服務(wù)器發(fā)起一次GET請(qǐng)求，驗(yàn)證瀏覽器保存在本地的資源是否過(guò)期。

last-modified和if-unmodified-sine

一般情況下是用請(qǐng)求資源的最近一次修改時(shí)間戳來(lái)判斷。來(lái)舉個(gè)例子：假設(shè)客戶端向服務(wù)器端請(qǐng)求一個(gè)文件，為了讓資源被再次請(qǐng)求時(shí)能通過(guò)協(xié)商緩存機(jī)制使用本地緩存。首次返回該資源的響應(yīng)頭中會(huì)包含一個(gè)last-modified的字段，字段的值表示資源最后修改的時(shí)間。當(dāng)刷新頁(yè)面時(shí)，該資源使用的是協(xié)商緩存，瀏覽器無(wú)法確認(rèn)本地緩存是否過(guò)期，然后向服務(wù)器發(fā)起一次GET請(qǐng)求，進(jìn)行緩存有效性的協(xié)商，本次請(qǐng)求的請(qǐng)求頭中包含一個(gè)if-unmodified-since字段，字段的值是上次響應(yīng)頭中的last-modified字段的值。

last-modified的不足之處

last-modified存在兩個(gè)缺陷：

1. 鴻蒙官方戰(zhàn)略合作共建——HarmonyOS技術(shù)社區(qū)

2.  它只是根據(jù)資源最后的修改時(shí)間進(jìn)行判斷，雖然請(qǐng)求的文件資源進(jìn)行了編輯，但內(nèi)容并沒(méi)有改變，時(shí)間也會(huì)更新。這就導(dǎo)致了協(xié)商緩存時(shí)關(guān)于有效性的判斷驗(yàn)證失效，就要重新進(jìn)行資源的請(qǐng)求。

3.  由于文件資源修改的時(shí)間單位是秒，如果文件修改很頻繁。比如，幾百毫秒內(nèi)改一次，就無(wú)法識(shí)別出該文件資源的更新。

ETag和if-none-match

為了彌補(bǔ)通過(guò)時(shí)間判斷的不足，HTTP 1.1 加入了ETag（實(shí)體標(biāo)簽）的頭信息。

ETag表示資源的特定標(biāo)識(shí)符，類似文件指紋。作用上面也有提到，這里不過(guò)多講解。

當(dāng)響應(yīng)頭同時(shí)存在last-modified和ETag這兩個(gè)字段時(shí)，會(huì)以ETag為準(zhǔn)。再次對(duì)該資源發(fā)起請(qǐng)求時(shí)，會(huì)將之前的響應(yīng)頭中ETag的值當(dāng)作這次請(qǐng)求中if-none-match字段的值，發(fā)送給服務(wù)器進(jìn)行緩存有效性驗(yàn)證。如果驗(yàn)證緩存有效，就返回304狀態(tài)碼響應(yīng)重定向到本地緩存。

ETag的不足之處

ETag的出現(xiàn)并不是last-modified的代替品，而是一種補(bǔ)充方案，它還是存在弊端的。

•  如果資源比較大，數(shù)量多而且修改頻繁的話，那么生成ETag的過(guò)程會(huì)影響到服務(wù)器的性能。

•  上面也講了ETag還分強(qiáng)ETag和弱ETag。

•  強(qiáng)ETag值是根據(jù)資源內(nèi)容進(jìn)行生成，保證每個(gè)字節(jié)都相同。

•  弱ETag值是根據(jù)資源的部分屬性值來(lái)生成，生成速度快但是無(wú)法保證每個(gè)字節(jié)都相同。

如果瀏覽器走的是協(xié)商緩存，并且資源沒(méi)發(fā)生改變，服務(wù)器端會(huì)返回304狀態(tài)響應(yīng)碼告訴瀏覽器獲取本地緩存的資源即可。

1617632172962.jpg

HTTP 的缺點(diǎn)

HTTP協(xié)議主要的不足之處有以下幾點(diǎn)。

•  通信使用明文，內(nèi)容會(huì)被竊聽(tīng)

•  不驗(yàn)證通信方的身份，可能遭遇偽裝

•  無(wú)法證明報(bào)文的完整性，可能已遭到篡改

通信使用明文，內(nèi)容會(huì)被竊聽(tīng)

HTTP 協(xié)議本身沒(méi)有加密功能，所以無(wú)法做到對(duì)通信請(qǐng)求和響應(yīng)內(nèi)容進(jìn)行加密。

TCP/IP 是會(huì)被竊聽(tīng)的網(wǎng)絡(luò)

由于 TCP/IP 協(xié)議的工作機(jī)制，通信內(nèi)容在所有通信線路上都有可能遭到窺視。不管是哪個(gè)角落的服務(wù)器在跟客戶端進(jìn)行通信，通信的線路上的一些設(shè)備都不可能是個(gè)人物品。所以不排除在某個(gè)環(huán)節(jié)上遭到惡意窺視的行為。即使進(jìn)行加密處理，也會(huì)被窺視到通信的內(nèi)容。竊聽(tīng)相同端上的通信并不是難事，只要收集在網(wǎng)絡(luò)上流動(dòng)的數(shù)據(jù)包就行?？梢酝ㄟ^(guò)抓包和嗅探器工具來(lái)收集數(shù)據(jù)包。

解決方案: 加密處理防止竊聽(tīng)

最常見(jiàn)的兩種加密方式是通信加密和內(nèi)容加密

通信加密

HTTP 協(xié)議中本身沒(méi)有加密機(jī)制，但可以通過(guò) SSL（Secure Socket Layer 安全套階層） 或 TLS（Transport Layer Security 安全傳輸層協(xié)議） 的組合使用，加密HTTP的通信內(nèi)容。用 SSL 建立安全通信線路后，就可以在這條線路上進(jìn)行 HTTP 通信。和 SSL 組合使用的 HTTP 叫做 HTTPS （HTTP Secure 超文本傳輸安全協(xié)議） 或 HTTP over SSL。

內(nèi)容加密

由于 HTTP 協(xié)議中沒(méi)有加密機(jī)制，那么可以對(duì)傳輸?shù)膬?nèi)容本身進(jìn)行加密。也就是把 HTTP 報(bào)文中包含的內(nèi)容進(jìn)行加密處理。在這種情況下，客戶端需要對(duì) HTTP 報(bào)文主體(body)進(jìn)行加密處理后再發(fā)送請(qǐng)求。要做到內(nèi)容的加密，前提是客戶端和服務(wù)器端同時(shí)具有加密和解密的機(jī)制。主要應(yīng)用在 Web 服務(wù)器中。該方式不同于 SSL 和 TLS 把整個(gè)通信線路加密處理，所以內(nèi)容還是會(huì)有被篡改的可能。

不驗(yàn)證通信放的身份可能遭遇偽裝

HTTP 協(xié)議的請(qǐng)求和響應(yīng)都不會(huì)對(duì)通信方進(jìn)行確認(rèn)。

任何人都可以發(fā)起請(qǐng)求

在 HTTP 協(xié)議通信時(shí)，由于不存在確定通信方的處理步驟，任何人都可以發(fā)起請(qǐng)求。服務(wù)器只要收到請(qǐng)求，不管是誰(shuí)都會(huì)返回一個(gè)響應(yīng)（僅限發(fā)送端的 IP 地址和端口號(hào)沒(méi)被 Web 服務(wù)器設(shè)置限制訪問(wèn)的前提下）。也就是來(lái)者不拒。

•  有可能是偽裝的服務(wù)器。

•  有可能是偽裝的客戶端。

•  無(wú)法確定正在通信的對(duì)方是否具備訪問(wèn)權(quán)限。因?yàn)槟承?Web 服務(wù)器上保存有重要的信息，只想發(fā)給特定用戶通信的權(quán)限。

•  無(wú)法判斷請(qǐng)求是從哪來(lái)、出自誰(shuí)手。

•  即使是無(wú)意義的請(qǐng)求也照樣接收。無(wú)法阻止大量請(qǐng)求下的 Dos 攻擊（Denial of Service，拒絕服務(wù)器攻擊）。

解決方案：查明對(duì)方的證書(shū)

雖然使用 HTTP 協(xié)議無(wú)法確定通信方，但使用 SSL 可以。SSL 除了加密處理外，還用了一種證書(shū)的手段，用于確認(rèn)通信方。證書(shū)是由值得信任的第三方機(jī)構(gòu)頒發(fā)，用來(lái)證明服務(wù)器和客戶端是真實(shí)存在的。

通過(guò)證書(shū)，以證明通信方就是意料中的服務(wù)器，對(duì)個(gè)人來(lái)說(shuō)，減少了個(gè)人信息泄露的危險(xiǎn)。另外，客戶端持有證書(shū)即可完成個(gè)人身份的確認(rèn)，也可用于對(duì) Web 網(wǎng)站的認(rèn)證環(huán)節(jié)。

無(wú)法證明報(bào)文完整性，可能已篡改

收到的內(nèi)容不完整

沒(méi)有任何辦法確認(rèn)，發(fā)出去的請(qǐng)求或響應(yīng)和接收到的請(qǐng)求或響應(yīng)是前后相同的。有可能在中途被篡改成其他的內(nèi)容，即使內(nèi)容是真的被改了，接收方也不會(huì)知道。

解決方案：MD5 和 SHA-1

可以使用 MD5 和 SHA-1 等散列值校驗(yàn)方法，以及用來(lái)確認(rèn)文件的數(shù)字簽名方法(PGP簽名)對(duì)內(nèi)容進(jìn)行加密。但是用這些方法也無(wú)法保證正確，因?yàn)?MD5 和 PGP 本身被修改的話，用戶也不會(huì)知道。

HTTPS

HTTP加上加密處理和認(rèn)證以及完整性保護(hù)機(jī)制就是HTTPS

HTTPS 是身披 SSL 外殼的 HTTP

HTTPS 不是應(yīng)用層的一種新協(xié)議。只是 HTTP 通信接口部分用 SSL 和 TLS 協(xié)議代替而已。之前是 HTTP 和 TCP 進(jìn)行通信，用了 SSL 之后，就變成了 HTTP 先和 SSL 通信，之后 SSL 和 TCP 通信。

HTTPS.png

使用 SSL 之后，HTTP 就有了 HTTPS 的加密、證書(shū)和完整保護(hù)性這些功能。

加密方式

SSL 用的是公開(kāi)密鑰加密的處理方式。加密方法中的加密算法是公開(kāi)的，密鑰則是保密的。通過(guò)這種方式可以保持加密方法的安全性。

加密和解密都會(huì)用到密鑰。沒(méi)有密鑰就沒(méi)辦法對(duì)密碼解密，任何人只要有密鑰就可以進(jìn)行解密，如果密鑰被攻擊者獲得，那么加密也就沒(méi)有意義了。

對(duì)稱加密

加密和解密同用一個(gè)密鑰的方式叫做共享密鑰加密，也稱為對(duì)稱密鑰加密。也就是說(shuō)，客戶端和服務(wù)器端共用一個(gè)密鑰對(duì)消息進(jìn)行加密?？蛻舳嗽诎l(fā)送請(qǐng)求時(shí)，會(huì)用密鑰對(duì)消息加密。服務(wù)器收到后，再用密鑰對(duì)消息進(jìn)行解密。

缺點(diǎn)

對(duì)稱加密雖然保證了消息保密性，但客戶端和服務(wù)器端用的都是同一個(gè)密鑰，如果說(shuō)在傳輸?shù)倪^(guò)程中出現(xiàn)了中間人或攻擊者。密鑰就有可能落到攻擊者手中，這樣就對(duì)消息加密就沒(méi)有什么意義了。

非對(duì)稱加密

非對(duì)稱加密解決了對(duì)稱加密的缺點(diǎn)。非對(duì)稱加密用的是一對(duì)非對(duì)稱的密鑰。一把叫做私有密鑰，另一把叫做公開(kāi)密鑰。私有密鑰只能是自己所擁有，而公開(kāi)密鑰則是任何人都可以拿到。

當(dāng)客戶端發(fā)送消息前，使用公共密鑰進(jìn)行加密，而服務(wù)器收到消息后，使用私有密鑰進(jìn)行解密。

缺點(diǎn)

非對(duì)稱加密需要在發(fā)送端在發(fā)送消息時(shí)，用公鑰加密。但公鑰是任何人都可以拿到，中間人也可以。中間人雖然不知道接收方的私鑰是什么，但可以截獲發(fā)送端的公鑰，自己另外生成一把公鑰或者篡改公鑰，把公鑰發(fā)給接收端。而且非對(duì)稱加密處理起來(lái)比對(duì)稱加密的方式更加復(fù)雜，這樣就導(dǎo)致了效率變低。

混合加密機(jī)制

HTTPS 用的就是對(duì)稱加密和非對(duì)稱加密兩者的混合加密。使用對(duì)稱加密的好處是解密效率快，使用非對(duì)稱加密的好處是在傳輸消息的過(guò)程中不會(huì)被破解。即使截獲了數(shù)據(jù)，沒(méi)有對(duì)應(yīng)的私鑰，也無(wú)法對(duì)消息進(jìn)行破解。

摘要算法

數(shù)字摘要是采用 Hash 函數(shù)將需要加密的明文 “摘要” 成一串固定長(zhǎng)度（128位）的密文，這串密文又稱為數(shù)字指紋，它有固定長(zhǎng)度，而且不同的明文摘要成密文，其結(jié)果總是不同，而同樣的明文摘要必須一致。數(shù)字摘要是 HTTPS 能確保數(shù)據(jù)完整性和防篡改的根本原因。

數(shù)字簽名

數(shù)字簽名是非對(duì)稱加密和數(shù)字摘要兩項(xiàng)技術(shù)的應(yīng)用，它將摘要信息用發(fā)送者的私鑰加密，和原文一起發(fā)給接收者。接收者只有用發(fā)送者的公鑰才能解密被加密的摘要信息，然后用 Hash 函數(shù)對(duì)收到的原文產(chǎn)生一個(gè)摘要信息，與解密的摘要信息對(duì)比。如果一樣，那就說(shuō)明收到的信息是完整的。否則說(shuō)明信息被修改過(guò)，因此數(shù)字簽名能夠驗(yàn)證信息的完整性。

數(shù)字簽名是附加在報(bào)文上的特殊加密校驗(yàn)碼。使用數(shù)字簽名有以下兩點(diǎn)好處。

•  簽名能確定消息是由發(fā)送方簽名并發(fā)過(guò)來(lái)的，因?yàn)閯e人假冒不了發(fā)送方的簽名。

•  簽名能確定消息的完整性，證明數(shù)據(jù)沒(méi)有被篡改過(guò)。

數(shù)字簽名的過(guò)程如下：明文 \-> hash運(yùn)算 \-> 摘要 \-> 私鑰加密 \-> 數(shù)字簽名

數(shù)字證書(shū)

數(shù)字證書(shū)（CA）就像我們的身份證一樣，信息都是唯一性的。它是屬于可信任的一些第三方機(jī)構(gòu)所有。證書(shū)包含了以下的信息。

•  證書(shū)的發(fā)布機(jī)構(gòu) CA

•  證書(shū)的有效期

•  公鑰

•  證書(shū)所有者

•  簽名

數(shù)字證書(shū)還包括對(duì)象的公鑰，對(duì)象和所用簽名算法的描述信息。所有人都可以創(chuàng)建一個(gè)數(shù)字證書(shū)，但并不是所有人都能獲得簽發(fā)權(quán)，從而為證書(shū)信息擔(dān)保，并用它私有密鑰簽發(fā)證書(shū)。

HTTPS 的工作流程

1. 鴻蒙官方戰(zhàn)略合作共建——HarmonyOS技術(shù)社區(qū)

2.  首先是客戶端向服務(wù)器端發(fā)起一個(gè) HTTPS 請(qǐng)求。

3.  服務(wù)器端返回公鑰證書(shū)給客戶端。

4.  客戶端收到公鑰證書(shū)后，用證書(shū)的公鑰驗(yàn)證數(shù)字簽名，以確認(rèn)服務(wù)器的公鑰的真實(shí)性。

5.  客戶端用隨機(jī)數(shù)生成器生成臨時(shí)的會(huì)話密鑰，然后用服務(wù)器的公鑰對(duì)該會(huì)話密鑰進(jìn)行加密，發(fā)送給服務(wù)器端。

6.  服務(wù)器收到后，用自己的密鑰對(duì)會(huì)話密鑰解密。

7. 之后客戶端和服務(wù)器端就開(kāi)始了 HTTPS 通信。

SSL 和 TSL

HTTPS 用的是 SSL（Secure Socket Layer 安全套階層） 和 TLS（Transport Layer Security 安全傳輸層協(xié)議）這兩個(gè)協(xié)議。SSL 最開(kāi)始是網(wǎng)景先倡導(dǎo)，后來(lái)網(wǎng)景涼了，就轉(zhuǎn)移給了 IETF 的手里。IETF 以 SSL 3.0 為準(zhǔn)，之后又定制了 TLS1.0、TLS1.1和 TLS1.2。TLS 是以 SSL 為原型開(kāi)發(fā)的協(xié)議。有時(shí)候統(tǒng)一稱該協(xié)議為 SSL。

為什么不一直用 HTTPS

凡事都具有兩面性，不是說(shuō) HTTPS 安全就沒(méi)有問(wèn)題了。其實(shí)它還是存在一些問(wèn)題的。在使用 SSL 時(shí)，它的處理速度會(huì)變慢。其原因有兩種，一是通信慢，二是每次都進(jìn)行加密通信，就導(dǎo)致消耗大量的 CPU 和內(nèi)存資源，導(dǎo)致處理速度變慢。

•  除了和 TCP 連接、發(fā)送請(qǐng)求和響應(yīng)之外，還要和 SSL 進(jìn)行通信。

•  另外 SSL 要進(jìn)行加密處理，在服務(wù)器和客戶端都要進(jìn)行加密和解密的運(yùn)算處理。

•  要用 HTTPS 通信，購(gòu)買證書(shū)是必不可少的。

當(dāng)然可以用 SSL 加速（專用服務(wù)器）硬件來(lái)改善效率的問(wèn)題?？梢蕴岣?SSL 的計(jì)算速度，分擔(dān)負(fù)載。但只有在 SSL 處理時(shí)才發(fā)揮 SSL 加速器的效果。像一些非敏感的信息就用 HTTP 進(jìn)行通信，對(duì)于敏感信息采用 HTTPS 通信，以節(jié)約資源。

HTTP 和 HTTPS 的區(qū)別

1. 鴻蒙官方戰(zhàn)略合作共建——HarmonyOS技術(shù)社區(qū)

2.  HTTP 是以明文的方式進(jìn)行傳輸，HTTPS 則是具有安全性的 SSL 加密傳輸協(xié)議。

3.  HTTP 和 HTTPS 用的是兩種不同的方式進(jìn)行連接，端口號(hào)也不一樣。前者是 80，后者是 443。

4.  想要用 HTTPS 就得購(gòu)買證書(shū)（CA），而免費(fèi)的整數(shù)一般都很少，所以需要支付一定的費(fèi)用。

5.  HTTPS 對(duì)搜索引擎更友好，有利于 SEO ，優(yōu)先索引 HTTPS 的網(wǎng)頁(yè)。

6.  HTTP 的連接簡(jiǎn)單，并且是無(wú)狀態(tài)的。HTTPS 是由 SSL + HTTP 協(xié)議構(gòu)建的可進(jìn)行加密傳輸、身份認(rèn)證的網(wǎng)絡(luò)協(xié)議，比 HTTP 要安全。

解決 HTTP 1.x 瓶頸的 SPDY

HTTP 1.x的缺點(diǎn)

HTTP 1.x主要有以下幾個(gè)缺點(diǎn)：

  1.  HTTP 1.0 只允許在一個(gè) TCP 連接上發(fā)送一個(gè)請(qǐng)求，HTTP 1.1中默認(rèn)允許多個(gè) TCP 連接。但是同一個(gè) TCP 連接中，所有的數(shù)據(jù)通信都是按次序進(jìn)行的，服務(wù)器一般是處理完一個(gè)響應(yīng)之后，再繼續(xù)處理下一個(gè)。這就造成了隊(duì)首阻塞問(wèn)題。

  2.  請(qǐng)求只能從客戶端開(kāi)始，客戶端不可以接收除了響應(yīng)之外的指令。

  3.  請(qǐng)求/響應(yīng)頭部不進(jìn)行壓縮就發(fā)送。頭部信息越多延遲就越大。

  4.  發(fā)送冗長(zhǎng)的頭部，每次互相發(fā)送相同的頭部導(dǎo)致資源浪費(fèi)。

  5.  可隨意選擇數(shù)據(jù)壓縮格式，非強(qiáng)制壓縮發(fā)送。

SPDY

SPDY 是由谷歌開(kāi)發(fā)的基于 TCP 協(xié)議的應(yīng)用層協(xié)議。目標(biāo)是為了優(yōu)化 HTTP 協(xié)議的性能，通過(guò)壓縮、多路復(fù)用和優(yōu)先級(jí)技術(shù)，縮短網(wǎng)頁(yè)的加載時(shí)間并提高安全性。SPDY 協(xié)議的核心思想是盡量減少 TCP 的連接數(shù)。SPDY 并不是一種代替 HTTP 的協(xié)議，而是對(duì) HTTP 協(xié)議的增強(qiáng)。

SPDY 沒(méi)有改寫(xiě) HTTP 協(xié)議，而是在 TCP/IP的應(yīng)用層和傳輸層之間通過(guò)新加會(huì)話層的形式運(yùn)作。同時(shí)，考慮到安全問(wèn)題，SPDY 規(guī)定通信中使用 SSL。

SPDY.jpg

SPDY 以會(huì)話層的形式加入，控制對(duì)數(shù)據(jù)的流動(dòng)，但還是采用 HTTP 建立通信。因此，可以照常使用 HTTP 的請(qǐng)求方法、Cookie 以及 HTTP 報(bào)文等等。

HTTP 2.0

HTTP 2.0 可以說(shuō)是 SPDY 的升級(jí)版（其實(shí)是基于 SPDY 設(shè)計(jì)的），但HTTP 2.0和 SPDY 還是存在一些不同的。主要有以下兩點(diǎn)：

1. 鴻蒙官方戰(zhàn)略合作共建——HarmonyOS技術(shù)社區(qū)

2.  HTTP 2.0 支持明文傳輸，而 SPDY 強(qiáng)制使用 HTTP。

3.  HTTP 2.0 消息頭的壓縮算法用的是 HPACK，而 SPDY 用的是 DEFLATE。

下面就簡(jiǎn)單的介紹一下 HTTP 2.0 新增的功能。由于HTTP 2.0 設(shè)計(jì)到的東西太多了，之后我會(huì)一篇文章單獨(dú)講講 HTTP 2.0。

•  二進(jìn)制分幀層：HTTP 2.0 性能增強(qiáng)的核心就是新增的二進(jìn)制分幀層，HTTP 1.x是以換行符作為純文本的分隔符，而 HTTP 2.0 把所有傳輸?shù)男畔⒎指畛筛〉南⒑蛶?duì)它們采用二進(jìn)制的格式編碼。

•  多向請(qǐng)求和響應(yīng)：HTTP 2.0 中心的二進(jìn)制分幀層，將 HTTP 消息分解成獨(dú)立的幀，交錯(cuò)發(fā)送。然后在另一個(gè)端根據(jù)流標(biāo)識(shí)符和頭部把它們重新組裝。解決了 HTTP 1.x的隊(duì)首阻塞問(wèn)題。

•  請(qǐng)求優(yōu)先級(jí)：把 HTTP 消息分解成多個(gè)獨(dú)立的幀后，就可以通過(guò)優(yōu)化這些幀的交錯(cuò)和傳輸順序進(jìn)一步性能優(yōu)化。

•  服務(wù)器推送：服務(wù)器可以對(duì)一個(gè)客戶端請(qǐng)求發(fā)送多個(gè)響應(yīng)。服務(wù)器還可以向客戶端推送資源而且無(wú)需客戶端明確的請(qǐng)求。

•  頭部壓縮：在 HTTP 2.0 中，使用了 HPACK（HTTP2頭部壓縮算法）壓縮格式對(duì)傳輸?shù)念^部進(jìn)行編碼，減少了頭部的大小。并在兩端維護(hù)了索引表，用于記錄出現(xiàn)過(guò)的頭部，之后在傳輸過(guò)程中就可以傳輸已經(jīng)記錄過(guò)的頭部健名，對(duì)端收到數(shù)據(jù)后就可以通過(guò)鍵名找到對(duì)應(yīng)的值。

如果想要了解更多 HTTP2.0 的知識(shí)可以看看《Web性能權(quán)威指南》這本書(shū)，里面講得挺詳細(xì)的。

補(bǔ)充

OSI模型

網(wǎng)絡(luò)架構(gòu)模型除了TCP/IP模型之外，還有OSI模型。OSI模型實(shí)際上是多了三層。

OSI模型.png

也就是上面所說(shuō)的多加了 SSL 和 SPDY 這兩個(gè)協(xié)議（都處于應(yīng)用層）。

而數(shù)據(jù)鏈路層細(xì)分的話有兩層：

•  數(shù)據(jù)鏈路層: 在不可靠的物理鏈路上，提供可靠的數(shù)據(jù)傳輸服務(wù)。包括組幀、物理編址、流量控制、差錯(cuò)控制、接入控制等等。

•  物理層: 主要功能就是連接網(wǎng)絡(luò)設(shè)備。

Cookie

前面也說(shuō)到，HTTP 是無(wú)狀態(tài)的協(xié)議，它不會(huì)對(duì)之前發(fā)送過(guò)的請(qǐng)求和響應(yīng)的狀態(tài)進(jìn)行管理。假設(shè)，客戶端的用戶發(fā)送一個(gè)請(qǐng)求，服務(wù)器端收到請(qǐng)求后想知道這個(gè)請(qǐng)求是哪個(gè)家伙發(fā)過(guò)來(lái)的，那么就要有一個(gè)狀態(tài)進(jìn)行管理。而Cookie正是解決這類問(wèn)題而出現(xiàn)。

從服務(wù)器端返回的響應(yīng)頭信息中有一個(gè)Set-Cookie的字段信息，告訴客戶端保存Cookie。在下次客戶端向服務(wù)器端發(fā)送請(qǐng)求時(shí)，客戶端會(huì)自動(dòng)在請(qǐng)求頭信息中加入Cookie的值發(fā)送出去。

服務(wù)器收到客戶端發(fā)送過(guò)來(lái)的Cookie之后，會(huì)檢查到底是從哪個(gè)客戶端發(fā)送過(guò)的請(qǐng)求，然后對(duì)比服務(wù)器上的記錄，最后得到了之前的狀態(tài)信息。

Set-Cookie

Set-Cookie是屬于響應(yīng)頭中的一個(gè)字段，它包含以下的值。

•  NAME=VALUE: Cookie的名稱和值。

•  expires=DATE: Cookie的有效期。

•  path=PATH: 把服務(wù)器上的文件目錄作為Cookie的使用對(duì)象，如果沒(méi)有設(shè)置，默認(rèn)是文檔所在的文件目錄。

•  domain=域名: 作為Cookie適用對(duì)象的域名，如果沒(méi)有設(shè)置，默認(rèn)是創(chuàng)建Cookie的服務(wù)器的域名。

•  Secure: 只有在 HTTPS 時(shí)才會(huì)發(fā)送Cookie。

•  HttpOnly: JavaScript 不能訪問(wèn)Cookie。主要是為了防止跨站腳本攻擊時(shí)Cookie的信息竊取。

請(qǐng)求頭中的Cookie字段

Cookie是請(qǐng)求頭中的一個(gè)字段，它包含服務(wù)器通過(guò)Set-Cookie頭部設(shè)置并存到客戶端的值。如果接收多個(gè)Cookie時(shí)，可以以多個(gè)Cookie形式發(fā)送回去。

以上就是HTTP 基礎(chǔ)知識(shí)有哪些，小編相信有部分知識(shí)點(diǎn)可能是我們?nèi)粘９ぷ鲿?huì)見(jiàn)到或用到的。希望你能通過(guò)這篇文章學(xué)到更多知識(shí)。更多詳情敬請(qǐng)關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道。