【網(wǎng)絡(luò)協(xié)議】HTTP 重要知識點（二）

1. HTTP 連接管理

1.1 短連接和長連接的區(qū)別

image

短連接：每次請求-響應(yīng)珠插，都需要建立和斷開 TCP 連接，而 TCP 連接相比比較耗時颖对，所以捻撑，短連接效率低。

長連接：當(dāng) TCP 連接建立后缤底，狀態(tài)會被保持顾患，后續(xù)的請求-響應(yīng)不會再建立 TCP 連接了。如果在一定時間內(nèi)客戶端-服務(wù)器之間沒有再次發(fā)送任何 HTTP 請求-響應(yīng)數(shù)據(jù)包个唧，比如：30 分鐘江解，會自動斷開 TCP 連接。

1.2 長連接存在的問題

服務(wù)器需要在內(nèi)存中保存當(dāng)前狀態(tài)徙歼，如果出現(xiàn)大量的空閑長連接連而不發(fā)犁河，就會耗盡服務(wù)器的資源，導(dǎo)致服務(wù)器無法為真正的用戶提供服務(wù)魄梯。

解決方法

一定時間無“請求-響應(yīng)”數(shù)據(jù)包傳輸時桨螺，斷開長連接。

常見的服務(wù)器長連接策略（nginx）

使用 keep-timeout 指令酿秸，設(shè)置長連接超時時間
使用 keep-requests 指令灭翔，設(shè)置長連接可以發(fā)送的最大請求數(shù)
同時配置 keep-timeout 和 keep-requests

2. HTTP 隊頭阻塞

2.1 問題描述

HTTP 收發(fā)數(shù)據(jù)是一個先進先出的“串行”隊列，如果隊首的請求由于處理的太慢辣苏，后面的數(shù)據(jù)就不得不等待肝箱，導(dǎo)致其它的請求承擔(dān)了不應(yīng)有的時間成本。

2.2 優(yōu)化方法

并發(fā)連接

一般會創(chuàng)建一個連接池考润，對連接進行復(fù)用狭园，來進行并發(fā)的請求，也就是只要連接池里的連接沒有被使用完糊治，每個連接都是并發(fā)執(zhí)行的唱矛，不會出現(xiàn)由于串行導(dǎo)致的隊頭阻塞問題。

域名分片

使用多個域名指向同一個服務(wù)器，突破 HTTP 和瀏覽器對并發(fā)數(shù)量的限制绎谦。

3. HTTP 重定向

3.1 HTTP 重定向的方式

由服務(wù)器控制管闷，并使用狀態(tài)碼 301/302 + 響應(yīng)頭字段 Location: 重寫向網(wǎng)址 來定義重定向。

其中窃肠，這里的域名可以是絕對 URI（帶域名）或相對 URI（只帶 path 和 query 部分）包个。

3.2 重定向的種類

301：永久重定向。意思是原 URI 已經(jīng)“永久”的不存在了冤留。搜索引擎的爬蟲看到了 301碧囊，會更新數(shù)據(jù)庫，不再使用老的 URI纤怒。一般的應(yīng)用場景為：啟用新域名糯而、服務(wù)器切換到新的機房、網(wǎng)站目錄層次重構(gòu)等泊窘。

302：臨時重定向熄驼。意思是 URI 處于臨時維護狀態(tài)。搜索引擎的爬蟲會認為原來的 URI 仍然有效烘豹，但暫時不可用瓜贾，所以只會執(zhí)行簡單的跳轉(zhuǎn)動作不記錄新的 URI。一般應(yīng)用場景為網(wǎng)站維護携悯。

3.3 重定向可能導(dǎo)致的問題

循環(huán)跳轉(zhuǎn)問題祭芦。由于設(shè)置不合理，導(dǎo)致跳轉(zhuǎn)中出現(xiàn)了環(huán)憔鬼。好在這個問題一般的瀏覽器做了都有做的相應(yīng)處理
性能損耗实束。重定向由原來的一次請求變成了兩次請求，如果大量的跳轉(zhuǎn)就會對服務(wù)器產(chǎn)生影響

4. Cookie

4.1 Cookie 的工作原理

image

這里需要使用兩個頭字段逊彭。分別是：

服務(wù)端的 Set-Cookie 頭字段
客戶端的 Cookie 頭字段

瀏覽器首次訪問服務(wù)器時，服務(wù)器是不知道它的身份的构订，就會為該客戶端創(chuàng)建一個獨特的身份標(biāo)識侮叮，格式是“key=value”的形式，然后放進 Set-Cookie 字段里悼瘾，隨響應(yīng)數(shù)據(jù)一起發(fā)送給客戶端囊榜。

瀏覽器收到帶有 Set-Cookie 的字段時，會將其保存起來亥宿，下次再請求的時候卸勺，就是通過 Cookie 頭字段將保存的 Cookie 信息帶給服務(wù)器。

注意

瀏覽器如果要發(fā)送多個 key-value 的信息給瀏覽器烫扼，會通過添加多個 Set-Cookie 頭字段的方式來進行響應(yīng)曙求。而客戶端在請求的時候，并不需要通過添加多個 Cookie，而只需要將多個 key-value 鍵值對通過 “;” 分隔即可悟狱。

同時静浴，Cookie 是由瀏覽器保存的，所以挤渐，換了瀏覽器后苹享，需要重新發(fā)送或保存 Cookie。

4.2 常見的 Cookie 屬性

Expires：使用絕對時間點浴麻。比如：2020 年 12 月 21 日失效
Max-Age：使用的是相對時間點得问，單位秒。比如：過 10000s 后失效
Domain：指定作用域中的域名软免，表示當(dāng)前 Cookie 所屬的域名
Path：指定作用域中的路徑宫纬，表示當(dāng)前 Cookie 所屬域名下的路徑
HttpOnly：表示此 Cookie 只允許瀏覽器訪問，禁止其它方式訪問或杠，瀏覽器的 JS 引擎會禁用訪問 Cookie 的 API
SameSite：可以防范跨站請求偽造哪怔，設(shè)置成 sameSite=strict 表示嚴格限制 Cookie 不能隨著跳轉(zhuǎn)鏈接跨站發(fā)送
Secure：表示這個 Cookie 僅能用 Https 協(xié)議加密傳輸，但 Cookie 本身還是明文的

Expires 和 Max-Age 同時出現(xiàn)

瀏覽器會優(yōu)先使用 Max-Age 來作為失效的計算時間向抢。

4.3 Cookie 的應(yīng)用

身份識別

保存用戶的登錄信息认境，實現(xiàn)會話事務(wù)。

廣告追蹤

一般像 Google 這樣的廣告商會偷偷給你貼上 Cookie 小紙條挟鸠，當(dāng)你上其它網(wǎng)站的時候叉信，別的廣告就能讀取出你的身份，然后給你推送廣告艘希。

而這里的 Cookie 小紙條等一般都是第三方 Cookie硼身。

5. HTTP 緩存控制

5.1 服務(wù)器緩存

image

瀏覽器發(fā)現(xiàn)本地?zé)o緩存，就向服務(wù)器發(fā)送請求
服務(wù)器響應(yīng)請求覆享，返回資源佳遂，同時標(biāo)記資源的有效期
瀏覽器緩存資源，等待下次重用

Cache-Control 響應(yīng)頭字段

服務(wù)器使用 Max-Congtrol 響應(yīng)頭字段來標(biāo)記資源的有效期撒顿，如：max-age=30丑罪，表示緩存時間為 30s。

Cache-Contrl 值的范圍：

no-store：不允許使用緩存凤壁，例如：秒殺頁面
no-cache：可以緩存吩屹，但在使用之前需要去服務(wù)器上驗證是否過期，是否有新版本
must-revalidate：正常緩存拧抖，過期了煤搜，需要去服務(wù)器重新獲取

緩存流程圖

image

5.2 客戶端緩存控制

Cache-Control

瀏覽器也可以使用 Cache-Control 來進行緩存控制。

當(dāng)點擊刷新（F5）時唧席，瀏覽器會在請求頭中添加 Cache-Control: max-age=0擦盾，此時嘲驾，會向服務(wù)器發(fā)送請求。

當(dāng)強制刷新時（Ctrl + F5）瀏覽器會在請求頭中添加 Cache-Control: no-cache厌衙，此時距淫，也會向服務(wù)器發(fā)送請求。

除刷新或強制刷新的操作外婶希，其它時候瀏覽器都不會使用 Cache-Control 請求頭字段榕暇，也就是當(dāng)成一個正常的請求，會先去讀本地是否有緩存喻杈。

條件請求

If-Modified-Since 和 Last-Modified 通過修改時間來判斷文件是否被修改彤枢，是否需要更新請求新的數(shù)據(jù)。

If-None-Match 和 ETag 通過文件內(nèi)容是否有變化筒饰，或者變化是否大來判斷是否需要請求新的數(shù)據(jù)缴啡。

image

Last-Modefied：表示資源最后修改的時間。
ETag：資源的唯一標(biāo)識瓷们，類似于 MD5业栅，用來區(qū)分文件是否變化。

6. HTTP 代理

6.1 什么是 HTTP 代理服務(wù)

代理服務(wù)：服務(wù)本身不產(chǎn)生內(nèi)容谬晕，而是處理中間位置轉(zhuǎn)發(fā)上下游的請求和響應(yīng)碘裕，具有雙重身份。

6.2 代理的作用

負載均衡

通過請求分發(fā)到不同的服務(wù)器攒钳，來達到負載均衡的目的帮孔。

健康檢查

使用“心跳”等監(jiān)控后端服務(wù)器，如果出現(xiàn)問題不撑，就將其從集群移除文兢，保證服務(wù)的高可用。

安全防護

保護后端服務(wù)器焕檬，限制 IP 地址或流量姆坚，抵御網(wǎng)絡(luò)攻擊和過載。

加密卸載

對外使用 SSL/TLS 加密通信認證实愚，而在安全內(nèi)網(wǎng)不加密旷偿，消除內(nèi)部通信加密成本。

數(shù)據(jù)過濾

攔截上下行數(shù)據(jù)爆侣，通過策略來過濾請求或響應(yīng)。

內(nèi)容緩存

暫存幢妄，利用服務(wù)器響應(yīng)兔仰。

6.3 代理相關(guān)頭字段

Via

代理服務(wù)器需要通過 Via 來表明代理的身份。請求頭或響應(yīng)頭都可以出現(xiàn)蕉鸳。

每經(jīng)歷一個代理服務(wù)器乎赴，都會在 Via 頭字段的值后面追加當(dāng)前代理服務(wù)器的信息忍法。

image

X-Forward-For（非 HTTP 協(xié)議標(biāo)準(zhǔn)字段）

表示每經(jīng)歷一個代理服務(wù)器，就將當(dāng)前服務(wù)器的 IP 追加進來榕吼。

X-Real-IP（非 HTTP 協(xié)議標(biāo)準(zhǔn)字段）

只記錄客戶端 IP 地址饿序，而不關(guān)心代理服務(wù)器的 IP 地址。

為什么需要知道客戶端的 IP 地址

主要是方便服務(wù)器做訪問控制羹蚣、用戶畫像和統(tǒng)計分析等原探。

6.4 HTTP Proxy 代理抓包

image

客戶端 55061 先用 TCP 三次握手連接到代理的 80 端口，然后發(fā)送 GET 請求
代理代表客戶端顽素，用 55063 端口連接到源服務(wù)器咽弦，也是三次握手
代理連接源服務(wù)器成功后，發(fā)送了一個 HTTP/1.0 的 GET 請求
因為 HTTP/1.0 默認是短連接胁出，在接收到服務(wù)器響應(yīng)報文后立即用四次握手關(guān)閉連接
代理拿到響應(yīng)報文后再發(fā)回給客戶端型型，完成一次代理任務(wù)

6.5 代理協(xié)議

為什么會有代理協(xié)議

主要是由于代理服務(wù)器如果想要操作代理信息就必須解析 HTTP 報頭的 X-Forward-For 字段，使得原本只需要轉(zhuǎn)發(fā)消息的代理服務(wù)器全蝶，還需要費力解析數(shù)據(jù)再修改數(shù)據(jù)闹蒜，會降低代理的轉(zhuǎn)發(fā)性能。

另一個原因是：使用 X-Forward-For 頭字段記錄代理服務(wù)器的 IP抑淫，就必須修改原始報文绷落，在一些情況下，如：Https 通信被加密丈冬，是不可能修改報文的嘱函。

代理協(xié)議

代理協(xié)議分為 v1 和 v2 兩個版本。其中埂蕊，v1 是明文往弓；v2 是二進制格式。

v1：在 HTTP 報文前增加了一行 ASCII 碼文本蓄氧，相當(dāng)于添加了一個代理頭函似。具體的格式為：PROXY + TCP4/6 + 請求 IP 地址 + 應(yīng)答方 IP 地址 + 請求方端口號 + 應(yīng)答方端口號 + 回車換行（\r\n）。

PROXY TCP4 1.1.1.1 2.2.2.2 55555 80\r\n
GET / HTTP/1.1\r\n
Host: www.xxx.com\r\n
\r\n

好處：服務(wù)器拿到這樣的報文喉童，只需要解析第一行就可以拿到客戶端地址撇寞。

7. 緩存代理

7.1 什么是緩存代理

緩存代理主要是代理服務(wù)器為 HTTP 服務(wù)器緩存數(shù)據(jù)，讓客戶端請求不需要到達源服務(wù)器堂氯，就能獲得到相應(yīng)的數(shù)據(jù)蔑担，進行返回，減少源服務(wù)的訪問壓力咽白。

image

代理服務(wù)器在收到源服務(wù)器返回的報文后啤握，在將報文返回給客戶端的同時，也將報文存入到自己的 Cache 里晶框。

緩存代理服務(wù)器即是客戶端排抬，又是服務(wù)器

在面向源服務(wù)器時懂从，緩存代理服務(wù)器是客戶端；在面向客戶端時蹲蒲，緩存代理服務(wù)器又是服務(wù)器番甩。所以，緩存代理服務(wù)器可以同時使用 Cache-Control 的各種屬性來實現(xiàn)緩存控制策略届搁。

image

7.2 客戶端的緩存控制

image

max-stale：如果代理上的緩存過期了缘薛，也是可以接受到，但是過期時間不能太長咖祭，超過 x 秒后也會不要掩宜。

min-fresh：緩存必須有效，必須在 x 秒后必須有效么翰。

only-if-cached：只接受代理緩存的數(shù)據(jù)牺汤，不接收來自源服務(wù)器的響應(yīng)。如果代理沒有或緩存過期浩嫌，則返回一個 504（Gateway Timeout）檐迟。

Cache-Control: public,max-age=10,s-maxage-30

數(shù)據(jù)可以被緩存到代理服務(wù)器和瀏覽器。其中码耐，可以緩存在代理服務(wù)器 30s追迟，瀏覽器為 10s。

8. HTTPS

8.1 什么樣的通信過程才是安全的骚腥？

如果通信過程具有四個特性：

機密性：只能由可信的人訪問敦间，簡單來說就是不能讓不相關(guān)的人看到不該看的東西
完整性：數(shù)據(jù)在傳輸?shù)倪^程中，沒有被竄改
身份認證：確認對方的真實身份束铭，也就是證明“你就是你”
不可否認：也叫不可抵賴性廓块，意思是不能否認已經(jīng)發(fā)生過的行為

8.2 什么是 HTTPS？

HTTPS 是在 HTTP 與 TCP 層之間加了一層安全層契沫，主要對應(yīng)的協(xié)議為 SSL/TLS带猴，其中，TLS 是 SSL 3.0 改名而來的懈万，而 SSL 是由網(wǎng)景公司開發(fā)的拴清。

目前 TLS 的版本經(jīng)歷了 V1.0（就是 SSL 的 V3.1） V1.1、V1.2 和 V1.3 四個版本会通。其中口予，應(yīng)用最廣泛的是 TLS 1.2，之前的版本已經(jīng)被驗證了是不安全的涕侈。

TLS 由哪些子協(xié)議組成

TLS 由記錄協(xié)議苹威、握手協(xié)議、警告協(xié)議驾凶、變更密碼規(guī)范協(xié)議牙甫、擴展協(xié)議等子協(xié)議組成。

瀏覽器和服務(wù)器在進行連接時需要選擇一組恰當(dāng)?shù)募用芩惴▉韺崿F(xiàn)安全通信调违，這些算法的組合被稱為“密碼套件”窟哺。

image

上圖分別羅列了客戶端和服務(wù)端所支持的“密碼套件”，而最終選擇了 ECDHE-RSA-AES256-GCM-SHA384技肩。

密碼套件由四個部分組成：密鑰交換算法 + 簽名算法 + 對稱加密算法 + 摘要算法且轨。

ECDHE-RSA-AES256-GCM-SHA384：表示握手時使用 ECDHE 算法進行密鑰交換，用 RSA 簽名和身份認證虚婿，握手后旋奢，通信使用 AES 對稱算法，密鑰長度為 256 位然痊，分組模式為 GCM至朗，摘要算法 SHA384 用于消息認證和產(chǎn)生隨機數(shù)。

OpenSSL 庫

OpenSSL 是一個著名的密碼學(xué)工具包剧浸，幾乎支持所有公開的加密算法和協(xié)議锹引，很多應(yīng)用軟件使用 OpenSSL 來作為底層庫實現(xiàn) TLS 功能，包括 Apache 和 Ngnix唆香。

9. 對稱加密與非對稱加密

9.1 對稱加密

對稱加密：加密和解密時使用的密鑰都是同一個嫌变，是“對稱”的。只要保證了密鑰的安全躬它，那整個通信過程就可以說具有了機密性腾啥。TLS 里提供了多種對稱加密方式，但基本上只有 AES 和 chacha20 被認為是安全的冯吓。

加密分組模式

它可以讓算法用固定長度的密鑰加密任意長度的明文倘待。

9.2 非對稱加密

TLS 中常用的非對稱加密只有 DSA、RSA桑谍、ECC 等幾種延柠。目前推薦的是 RSA 2048 位。

ECC：比起 RSA锣披，ECC 在安全強度和性能上都有明顯的優(yōu)勢贞间。160 位的 ECC 相當(dāng)于 1024 位的 RSA。而 224 位的 ECC 相當(dāng)于 2048 位的 RSA雹仿。

私鑰和公鑰的關(guān)系

公鑰和私鑰具體“單向性”的特性增热，雖然都可以用來加密、解密胧辽，但公鑰加密后峻仇，只能用私鑰來解密，反過來邑商，私鑰加密后也只能用公鑰來解密摄咆。

有了非對稱加密凡蚜，還需要對稱加密技術(shù)么？

由于非對稱加密是基于復(fù)雜的數(shù)學(xué)難題吭从，運算速度很慢朝蜘，即使是 ECC 也比 AES 差幾個數(shù)量級。

下面是 AES 和 RSA 性能的對比：

aes_128_cbc enc/dec 1000 times : 0.97ms, 13.11MB/s

rsa_1024 enc/dec 1000 times : 138.59ms, 93.80KB/s
rsa_1024/aes ratio = 143.17

rsa_2048 enc/dec 1000 times : 840.35ms, 15.47KB/s
rsa_2048/aes ratio = 868.13

9.3 混合加密

密鑰交換過程

在通信剛開始的時候使用非對稱算法涩金，比如：RSA谱醇、ECDHE，首先解決密鑰交換的問題步做。

然后用隨機數(shù)產(chǎn)生對稱算法使用的 會話密鑰副渴，再用公鑰加密。會話密鑰一般 16 或 32 字節(jié)全度。

對方拿到密文后用私鑰解密煮剧，取出會話密鑰。這樣就完成了密鑰交換的過程讼载。后續(xù)傳輸數(shù)據(jù)使用對稱加密轿秧。

10. 數(shù)字簽名和證書

10.1 完整性

實現(xiàn)完整性的手段是：摘要算法，也稱散列函數(shù)和哈希函數(shù)咨堤。

10.2 摘要算法

任意長度的字符串經(jīng)過摘要算法處理后菇篡，都會變成長度固定、而且獨一無二的“摘要”字符串一喘，就好像為這段數(shù)據(jù)生成了一個指紋驱还。

TLS 使用摘要算法來生成隨機數(shù)。TLS 推薦的摘要算法是 SHA-2凸克。而 MD5 和 SHA-1 由于安全強度比較低议蟆，已被禁止使用。

摘要算法與非對稱加密算法的區(qū)別

摘要算法只有通過算法生成的密文萎战，沒有密鑰咐容，加密后的數(shù)據(jù)無法解密。而非對稱加密算法既有密文蚂维，也有密鑰戳粒。

TLS 中摘要算法存在的問題

如果明文傳輸，那么黑客可以修改消息后把摘要也一起改了虫啥，網(wǎng)站還是鑒別不出完整性蔚约。

所以，真正的完整性需要建立在機密性之上涂籽，在混合加密系統(tǒng)里用“會話密鑰”加密消息和摘要苹祟。這樣由于消息和消息摘要都被加密了，而密鑰只有客戶端才知道，所以树枫，黑客無法修改數(shù)據(jù)直焙。

image

10.3 數(shù)字簽名

沒有數(shù)字簽名之前，存在的問題

黑客可以偽造網(wǎng)站來竊取信息砂轻。而反過來箕般，他也可以偽裝成你，向網(wǎng)站發(fā)送支付舔清、轉(zhuǎn)賬等信息，網(wǎng)站沒有辦法確認你的身份曲初，錢可能就這么被偷走了体谒。

數(shù)字簽名的實現(xiàn)

使用“私鑰”加摘要算法，就可以實現(xiàn)數(shù)字簽名臼婆，同時抒痒，實現(xiàn)“身份認證”和“不可否認”。

就是把公鑰和私鑰反過來用颁褂，之前是公鑰加密故响，私鑰解密；現(xiàn)在是私鑰加密颁独、公鑰解密彩届。但由于非對稱加密的效率太低，所以誓酒，私鑰只加密原文的摘要樟蠕，這樣運算就小的多，而且得到的數(shù)字簽名也小得多靠柑，方便保管和傳輸寨辩。

image

這整個過程又被稱為“簽名”和“驗簽”〖弑客戶端和服務(wù)器分別生成簽名靡狞，來確保雙方的身份。

數(shù)字摘要在 TLS 中的作用

加密原文隔嫡，用于驗證數(shù)據(jù)完整性
加密原文甸怕，得到摘要，再使用私鑰加密摘要畔勤，得到數(shù)字簽名

10.4 數(shù)字證書和 CA

公鑰的信任問題

也就是缺少黑客偽造公鑰的問題蕾各。

解決方法

使用權(quán)威機構(gòu)頒發(fā)的數(shù)字證書。CA 是頒發(fā)數(shù)字證書的權(quán)威機構(gòu)庆揪，而數(shù)字證書是里包含公鑰式曲。

知名的 CA 機構(gòu)：DigiCert、VeriSign、Entrust 等吝羞，它們簽發(fā)的證書分為 DV兰伤、OV 和 EV 三個等級，用于區(qū)分可信度钧排。其中敦腔，DV 最低，EV 最高恨溜。

同時符衔，操作系統(tǒng)和瀏覽器內(nèi)置了各大 CA 的根證書。上網(wǎng)的時候糟袁，瀏覽器發(fā)過來它的證書判族，操作系統(tǒng)和瀏覽器又可以驗證證書里的簽名。順著證書鏈项戴，一層一層地驗證形帮，直到找到根證書，就能證明證書是可信的周叮，從而證明里面的公鑰也是可信的辩撑。

證書體系的弱點

如果 CA 失誤或者被欺騙了，簽發(fā)了錯誤的證書仿耽，雖然證書是真的合冀，可以代表的網(wǎng)站卻是假的。針對這個問題氓仲，開發(fā)出了 CRL 和 OOP ,及時廢止有問題的證書水慨。

另一種情況，CA 被黑客攻陷敬扛。將該 CA 從操作系統(tǒng)和瀏覽器的根證書中移除晰洒。

說明

此文是根據(jù)羅劍鋒透視 HTTP 協(xié)議相關(guān)專欄內(nèi)容整理而來，非原創(chuàng)啥箭。