1 協議的基本概念

1-1 http協議發展概述

協議的本質區分：安全性，效能問題

發展：http1.0+TCP => http1.1 + TLS/SSL+TCP => http2.0+TLS+TCP => http3.0+QUIC+UDP

QUIC協議

HTTP 1.0 （1996年）
1)僅提供了最基本認證，使用者名稱及密碼未加密，不安全。
2)使用短連線，每次傳送資料都會經過TCP三次握手和四次揮手，效率低。
3)只使用 header 中的 If-Modified-Since 和 Expires 作為快取失效的標準。
4)不支援斷點續傳，每次都會傳送全部頁面和資料。
5)認為每臺計算機只繫結一個IP，因此請求訊息中的URL 並沒有傳遞主機名。
==================================================================
HTTP 1.1 （1999年）
1)使用摘要演算法進行身份驗證
2)預設使用長連線，只需要建立一次連線就可以傳輸多次資料。連線時長通過請求頭中的 keep-alive來設定。
3)增加 E-tag，If-Unmodified-Since，If-Match，If-None-Match 等快取控制標頭來控制快取失效。
4)支援斷點續傳，通過使用請求頭中的 Range 來實現。
5) 使用虛擬網路，可以支援虛擬機器共享同一個IP地址。
======================================================================
HTTP 2.0 （2015年）
1)使用 HPACK 演算法進行頭部壓縮，HTTP 1.1 會出現cookie、user-agent 等欄位佔用幾百個位元組，導致頭部偏重。　　
2)使用二進位制格式而非ASCII碼，提升瞭解析效率。
3)強化安全，HTTP 2.0 跑在 HTTPS 上。
4) 多路複用，每個請求都是作為連線共享，一個請求對應一個id，一個連線上可以多個請求。
=============================================================================\
HTTP3.0（最新）
HTTP/3 就將傳輸層從 TCP 替換成了 UDP，並在 UDP 協議上開發了 QUIC 協議，來保證資料的可靠傳輸。
QUIC 協議的特點：
1）⽆隊頭阻塞， QUIC 連線上的多個 Stream 之間並沒有依賴，都是獨⽴的，也不會有底層協議限制，某個流發
⽣丟包了，只會影響該流，其他流不受影響；
2）建⽴連線速度快，因為 QUIC 內部包含 TLS1.3，因此僅需 1 個 RTT 就可以「同時」完成建⽴連線與 TLS 金鑰
協商，甚⾄在第⼆次連線的時候，應⽤資料包可以和 QUIC 握⼿資訊（連線資訊 + TLS 資訊）⼀起傳送，達到
0-RTT 的效果。
3）連線遷移， QUIC 協議沒有⽤四元組的⽅式來“繫結”連線，⽽是通過「連線 ID 」來標記通訊的兩個端點，客戶
端和伺服器可以各⾃選擇⼀組 ID 來標記⾃⼰，因此即使移動裝置的⽹絡變化後，導致 IP 地址變化了，只要仍保有上下⽂資訊（⽐如連線 ID、 TLS 金鑰等），就可以“⽆縫”地復⽤原連線，消除重連的成本；
4)另外 HTTP/3 的 QPACK 通過兩個特殊的單向流來同步雙⽅的動態表，解決了 HTTP/2 的 HPACK 隊頭阻塞問題。
 

1-2 http協議頭部常用欄位

1-2-1 實際欄位資訊

General

Request URL: https://www.baidu.com/
Request Method: GET
Status Code: 200 OK
Remote Address: 180.101.49.11:443
Referrer Policy: strict-origin-when-cross-origin

1）請求url,
2）請求方法，
3）狀態碼，
4）遠端伺服器IP地址：埠號，
5）Referrer Policy:用於控制請求頭中的referrer欄位顯示的資訊，這個欄位用於顯示當前的請求是是從哪個頁面發起該請求的
比如：在某網站點選外部連結跳轉，那麼不同策略最終得到的跳轉頁面的referrer欄位顯示的資訊也是不同的。
 

• 5)的策略通常從安全和隱私的角度設定，更多參考HTTP請求中的referrer和Referrer-Policy

Request Headers

GET / HTTP/1.1
Host: www.baidu.com
Connection: keep-alive
Cache-Control: max-age=0         # 預設資源有效期為0即每次都重新請求（chrome瀏覽器特性）
sec-ch-ua: "Chromium";v="92", " Not A;Brand";v="99", "Google Chrome";v="92"
sec-ch-ua-mobile: ?0
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/92.0.4515.159 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
Sec-Fetch-Site: none
Sec-Fetch-Mode: navigate
Sec-Fetch-User: ?1
Sec-Fetch-Dest: document
Accept-Encoding: gzip, deflate, br
Accept-Language: zh-CN,zh;q=0.9,en;q=0.8,zh-TW;q=0.7
Cookie: BIDUPSID=AC40325179B6B61E75468AC472209C14; PSTM=1630076261; BAIDUID=AC40325179B6B61E0605129DD7DC3488:FG=1; BD_UPN=12314753; BDORZ=B490B5EBF6F3CD402E515D22BCDA1598; __yjs_duid=1_f4dfa29776139c045828bf93c4ea919c1630295908965; BDSFRCVID_BFESS=Pn0OJeC62RiLby3H-WQ6UOtXH8_S9r7TH6ao-EetxyN9kucQCyPwEG0PEf8g0KAbl_9MogKK0eOTHk-F_2uxOjjg8UtVJeC6EG0Ptf8g0f5; H_BDCLCKID_SF_BFESS=tbut_KDMJDK3j-_kh4nb-P4ObqKX5-RLfaRXop7F5l8-hxoYX-5BDUvD3nLqLxRJyg-OMM8X-D3xOKQphIcpbJ0b2tI8abQ2Lm78bP3N3KJmsJL9bT3vLtDjBNru2-biWbR-2Mbd256P_IoG2Mn8M4bb3qOpBtQmJeTxoUJ25DnJhbLGe4bK-TryeHuj3J; H_PS_645EC=ee61Y%2FHwA96Y7VOPX5mUVVoNu0XFjTjZ3dQBaa0co6HvSsx6R7dcV2%2B%2FLqaPmfcuzg; BD_HOME=1; H_PS_PSSID=34439_34497_31254_33848_34092_34107_26350_34418_34473; BA_HECTOR=8ga02l00840l248ksm1gj1l650q

Response Headers

HTTP/1.1 200 OK
Bdpagetype: 1
Bdqid: 0x93ba5c8f000078e1
Cache-Control: private                     # 客戶端可以快取
Connection: keep-alive
Content-Encoding: gzip
Content-Type: text/html;charset=utf-8
Date: Thu, 02 Sep 2021 13:42:55 GMT
Expires: Thu, 02 Sep 2021 13:41:58 GMT     # 資源過期時間
Server: BWS/1.1
Set-Cookie: BDSVRTM=0; path=/
Set-Cookie: BD_HOME=1; path=/
Set-Cookie: H_PS_PSSID=34439_34497_31254_33848_34092_34107_26350_34418_34473; path=/; domain=.baidu.com
Strict-Transport-Security: max-age=172800
Traceid: 1630590175279410689010644922438493698273
X-Frame-Options: sameorigin
X-Ua-Compatible: IE=Edge,chrome=1
Transfer-Encoding: chunked

1-2-2 常用欄位資訊分類以及作用

• 總體上可以分為3個類別，客戶端資訊，訊息體的資訊，快取設定

a)客戶端資訊相關欄位：包括host,瀏覽器標識(User-Agent)
b)訊息體相關欄位：內容長度，型別，編碼(壓縮)方式
c)強快取控制欄位：cache-control.exprie
d)協商快取控制欄位：Etag,If-modified

知識點：對比快取（協商快取）

核心思想：客戶端請求攜帶Last-Modified和Etag欄位，服務端校驗這兩個欄位進行返回*，如果無需更新則返回304，否則返回修改後的資源。

對比快取定義：伺服器對比判斷檔案是否修改，告訴瀏覽器是否可以使用本地快取。對比生效時，伺服器返回給瀏覽器的http code 為304，伺服器只返回http header資訊，並無響應正文。瀏覽器收到304的返回，知道本地快取並無修改，直接使用本地快取。
--------------------------------------------------------------------------------------------------------
對比快取對比流程：
	瀏覽器請求資源
	伺服器返回Last-Modified/If-Modified-Since和Etag
	瀏覽器快取Last-Modified/If-Modified-Since和Etag在本地
	瀏覽器再次請求資源，請求頭包含If-Modified-Since/If-None-Match
	伺服器再次計算資源的Last-Modified和Etag，並和瀏覽器傳過來的比較
	如不相同，資源發生變化，返回Http code 200，並且返回資源。如相同，返回http code 304，不需要返回資源。
---------------------------------------------------------------------------------------------------------
對比快取何時使用？
	對於瀏覽器來說的話，一般會在強制快取過期的情況下，如果資源原先的響應header中帶有Last-Modified和Etag的話，瀏覽器請求時會在請求header中帶上If-Modified-Since和If-None-Match。
------------------------------------------------------------
Etag是否可以替代If-Modified-Since?
   可以，但是對於快取一致性要求不是太高的場景，If-modfied-Since可以節約hash計算開銷
   Etag比lastModified更加嚴謹，如果資源發生變化，Etag就會發生變化，就會把最新的資源給客戶端返回去，而lastModified不識別s（秒）單位裡的修改，所以如果資源在s（秒）單位裡發生了修改，那lastModified也不會發生改變，這樣如果只用了lastModified，客戶端得到的資源就不是最新的；但是設定了Etag之後，每次客戶端發出請求，服務端都會根據資源重新生成一個Etag，對效能有影響

注意：對比快取通常與強快取一起使用

1-3 Http常見狀態碼

RFC文件共定義了5類狀態碼：

1. Informational responses (100–199)
2. Successful responses (200–299)
3. Redirects (300–399)
4. Client errors (400–499)
5. Server errors (500–599)

1）資訊提示資訊： 100(Continue)表示客戶端應該繼續請求
2) 成功響應資訊： 200(OK),206(Partial Content)
3) 重定向資訊：   
--301(Moved Permanently): 永久移動。請求的資源已被永久的移動到新URI，返回資訊會包括新的URI，瀏覽器會自動定向到新URI
--302(Found):臨時移動。與301類似。但資源只是臨時被移動。客戶端應繼續使用原有URI
--304(Not Modified):快取資訊提示，表示請求的資源沒有修改
--305（Use Proxy):使用代理。所請求的資源必須通過代理訪問
4) 客戶端錯誤:
--403(Forbidden):伺服器理解請求客戶端的請求，但是拒絕執行此請求
--404(Not Found)
--410(Gone):請求資源被移除
5) 服務端錯誤:
500	Internal Server Error	伺服器內部錯誤，無法完成請求
501	Not Implemented	伺服器不支援請求的功能，無法完成請求
502	Bad Gateway	作為閘道器或者代理工作的伺服器嘗試執行請求時，從遠端伺服器接收到了一個無效的響應
503	Service Unavailable	由於超載或系統維護，伺服器暫時的無法處理客戶端的請求。延時的長度可包含在伺服器的Retry-After頭資訊中
504	Gateway Time-out	充當閘道器或代理的伺服器，未及時從遠端伺服器獲取請求
505	HTTP Version not supported	伺服器不支援請求的HTTP協議的版本，無法

http超時設定

瀏覽器有預設連線超時，Firefox 好像是115秒，Chrome 好像是5分鐘還是6分鐘。如果後端需要處理十多分鐘才能返回結果，那肯定是要非同步返回結果。不可能同步，沒理由同步，就算瀏覽器不超時，你也沒必要同步返回，浪費資源。要及時返回處理結果，你可以用 WebSocket 和 Ajax 輪詢實現。使用者上傳檔案，伺服器成功接受檔案後返回一個上傳成功的結果，然後前端給個 Loading 提示，然後定時輪詢，查詢後端處理結果，處理成功了就更新前端提示成功，沒有就繼續 Loading 提示。

2 協議安全問題

2-1 http協議安全概述（三個風險的解決策略）

http明文傳輸帶來的問題

1. 竊聽⻛險：個人隱私資訊可被其他人獲取(比如自己的家庭地址，手機號，父母姓名等)
2. 篡改⻛險：收到的資料可能被第三方修改過，或被植入廣告等（截住資料包在http的body新增內容在發給接受方，http劫持,運營商劫持）。

為什麼 2015 年底各大網站都紛紛用起了 HTTPS？

3. 冒充風險：訪問的站點非目標伺服器站點。釣魚網站(CA證書)。

• https 被劫持: 客戶單安裝偽造的CA 證書,被代理伺服器劫持。沒有認證的證書，客戶端選擇信任。

知識點1：CA證書如何確保伺服器的公鑰是可靠的(冒充風險)？

HTTPS體系中若攻擊者將自己公鑰上傳CA得到簽名，並將兩者一起用於篡改證書的中間人攻擊會怎樣

• 關鍵物件：瀏覽器，伺服器，證書頒發機構（CA, Certificate Authority）（CA伺服器）
• 核心：瀏覽器與伺服器必須保證證書頒發機構可靠（CA的私匙不會被洩漏）

1) 伺服器向CA註冊公匙
2）CA用自己的私匙對服務端公鑰進行加密，並放入到數字證書中，頒發給服務端
3）客戶端拿到服務端數字證書後，使用CA伺服器提供的公鑰進行解密並校驗數字簽名，沒有問題則獲取到服務端公鑰，

• 可靠性依賴於認證機構

知識點2：DNS協議的安全問題

DNS劫持：修改域名解析的結果（比如修改作業系統的域名檔案將IP地址進行替換）
劫持方法：控制域名解析流程中任意環節都能夠實現DNS劫持
====================================================================================
瀏覽器域名解析的流程：
1）首先搜尋瀏覽器的 DNS 快取（各種瀏覽器有固定值），快取中維護一張域名與 IP 地址的對應表
2）若沒有命中，則繼續搜尋作業系統的 DNS 快取（C:\Windows\System32\drivers\etc\hosts）
3）若仍然沒有命中，則作業系統將域名傳送至本地域名伺服器，本地域名伺服器查詢自己的 DNS 快取，查詢成功則返回結果（注意：主機和本地域名伺服器之間的查詢方式是遞迴查詢）；
====================================================================================
4）若本地域名伺服器的 DNS 快取沒有命中，則本地域名伺服器向上級域名伺服器進行查詢，通過以下方式進行迭代查詢（注意：本地域名伺服器和其他域名伺服器之間的查詢方式是迭代查詢，防止根域名伺服器壓力過大）：
5）首先本地域名伺服器向根域名伺服器發起請求，根域名伺服器是最高層次的，它並不會直接指明這個域名對應的 IP 地址，而是返回頂級域名伺服器的地址，也就是說給本地域名伺服器指明一條道路，讓他去這裡尋找答案
本地域名伺服器拿到這個頂級域名伺服器的地址後，就向其發起請求，獲取許可權域名伺服器的地址
本地域名伺服器根據許可權域名伺服器的地址向其發起請求，最終得到該域名對應的 IP 地址
============================================================================
6）本地域名伺服器將得到的 IP 地址返回給作業系統，同時自己將 IP 地址快取起來
7）作業系統將 IP 地址返回給瀏覽器，同時自己也將 IP 地址快取起來
8）至此，瀏覽器就得到了域名對應的 IP 地址，並將 IP 地址快取起來
====================================================================================

遞迴查詢和迭代查詢的使用場景：

主機->本地域名伺服器使用遞迴查詢的原因如下：
1）本地域名伺服器負責一片地區的域名解析，需要對DNS記錄進行快取
2）通常伺服器的數量不是太多，壓力比較小。

本地域名伺服器向根域名伺服器的查詢的迭代查詢的原因
1）根域名數量稀少，每次請求都自己獲取結果頂不住
2）頂級域名伺服器在收到本地域名伺服器的查詢請求後，要麼給出所要查詢的IP地址，要麼告訴本地伺服器下一步應當向哪一個許可權域名伺服器進行查詢。

DNS汙染（欺騙）：當你的電腦向域名伺服器傳送了“域名查詢”的請求，然後域名伺服器把迴應傳送給你的電腦，這之間是有一個時間差的。如果某個攻擊者能夠在域名伺服器的“DNS應答”還沒有到達你的電腦之前，先偽造一個錯誤的“DNS應答”發給你電腦。那麼你的電腦收到的就是錯誤的資訊，並得到一個錯誤的 IP地址。

知識點3：DNS底層協議的變更歷史

1）當年內容貧乏，硬體效能低下。認為主機查詢的動作頻次低，資料量少。用TCP短連結握手和揮手的開銷比查詢還高。用長連線伺服器又承受不住。UDP是很好的選擇（開銷小）
2）網際網路起來後DNS頻率急劇增加，所以又加上了TCP版本（內容多）。
3）隨著惡意的DNS汙染出現後，DNS又升級了TLS版本（網上壞蛋多）
一般情況：DNS既用UDP也用TCP，大部分情況下是UDP，根據長度使用TCP，根據實際需求來

2-2 https協議訪問部落格園主頁流程分析（TLS1.2抓包分析）

概述

從抓包的資訊來看，部落格園使用http2.0協議+TLS協議實現通訊。

2-2-1 TLS協議預備知識

• 下面是TLS四次握手過程中第一次握手的資訊（Client Hello資訊）

Transport Layer Security
    TLSv1.2 Record Layer: Handshake Protocol: Client Hello
        Content Type: Handshake (22)
        Version: TLS 1.0 (0x0301)
        Length: 512
        Handshake Protocol: Client Hello
            Handshake Type: Client Hello (1)
            Length: 508
            Version: TLS 1.2 (0x0303)
            Random: 2f1be521a6026fc823d215486c851fe49b4e02cf622eff058e28593097ed7362
                GMT Unix Time: Jan 17, 1995 23:41:21.000000000 中國標準時間
                Random Bytes: a6026fc823d215486c851fe49b4e02cf622eff058e28593097ed7362
            Session ID Length: 32
            Session ID: bd4eb383ad1bfb074dd591e58d5fd49b7ce3e6cd91001af9c6e18501fbd074a6
            Cipher Suites Length: 32
            Cipher Suites (16 suites)
                Cipher Suite: Reserved (GREASE) (0x3a3a)
                Cipher Suite: TLS_AES_128_GCM_SHA256 (0x1301)
                Cipher Suite: TLS_AES_256_GCM_SHA384 (0x1302)
                Cipher Suite: TLS_CHACHA20_POLY1305_SHA256 (0x1303)
                Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b)
                Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)
                Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02c)
                Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)
                Cipher Suite: TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 (0xcca9)
                Cipher Suite: TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (0xcca8)
                Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)
                Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)
                Cipher Suite: TLS_RSA_WITH_AES_128_GCM_SHA256 (0x009c)
                Cipher Suite: TLS_RSA_WITH_AES_256_GCM_SHA384 (0x009d)
                Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)
                Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)
            Compression Methods Length: 1
            Compression Methods (1 method)
                Compression Method: null (0)
            Extensions Length: 403
            Extension: Reserved (GREASE) (len=0)
            Extension: server_name (len=20)
            Extension: extended_master_secret (len=0)
            Extension: renegotiation_info (len=1)
            Extension: supported_groups (len=10)
            Extension: ec_point_formats (len=2)
            Extension: session_ticket (len=0)
            Extension: application_layer_protocol_negotiation (len=14)
            Extension: status_request (len=5)
            Extension: signature_algorithms (len=18)    
            Extension: signed_certificate_timestamp (len=0)
            Extension: key_share (len=43)
            Extension: psk_key_exchange_modes (len=2)
            Extension: supported_versions (len=11)
            Extension: compress_certificate (len=3)
            Extension: Unknown type 17513 (len=5)
            Extension: Reserved (GREASE) (len=1)
            Extension: padding (len=196)

cipher [ˈsaɪfər]：密碼   suites[swi:ts] ：套件

TLS的子協議有哪些（訊息型別）

TLS 握手協議又細分為四個子協議，分別是握手協議、密碼規格變更協議、警告協議和應用資料協議。
----------------------------------------------------------------------------------
Transport Layer Security
    TLSv1.2 Record Layer: Handshake Protocol: Client Hello
        Content Type: Handshake (22)                 # 握手協議
---------------------------------------------------------------------------------
Transport Layer Security
    TLSv1.2 Record Layer: Handshake Protocol: Server Hello
        Content Type: Handshake (22)
        Version: TLS 1.2 (0x0303)
        Length: 74
        Handshake Protocol: Server Hello
            Handshake Type: Server Hello (2)
            Length: 70
            Version: TLS 1.2 (0x0303)
------------------------------------------------------------------------------------
Transport Layer Security
    TLSv1.2 Record Layer: Handshake Protocol: Server Key Exchange
        Content Type: Handshake (22)
        Version: TLS 1.2 (0x0303)
        Length: 300
        Handshake Protocol: Server Key 
        .........
Transport Layer Security
    TLSv1.2 Record Layer: Handshake Protocol: Server Hello Done
        Content Type: Handshake (22)
        Version: TLS 1.2 (0x0303)
        Length: 4
        Handshake Protocol: Server Hello Done
            Handshake Type: Server Hello Done (14)
            Length: 0
-----------------------------------------------------------------------------------
Transport Layer Security
    TLSv1.2 Record Layer: Handshake Protocol: Client Key Exchange
        Content Type: Handshake (22)
        Version: TLS 1.2 (0x0303)
        Length: 37
        Handshake Protocol: Client Key Exchange
            Handshake Type: Client Key Exchange (16)
            Length: 33
            EC Diffie-Hellman Client Params
                Pubkey Length: 32
                Pubkey: 9794d9fb624442d8fe38422e66f75fb238b7bf7711261180e5ce6258f9f71d11
    TLSv1.2 Record Layer: Change Cipher Spec Protocol: Change Cipher Spec
        Content Type: Change Cipher Spec (20)      # 密碼規格變更
        Version: TLS 1.2 (0x0303)
        Length: 1
        Change Cipher Spec Message
    TLSv1.2 Record Layer: Handshake Protocol: Encrypted Handshake Message
        Content Type: Handshake (22)
        Version: TLS 1.2 (0x0303)
        Length: 40
        Handshake Protocol: Encrypted Handshake Message
-----------------------------------------------------------------------------------------
Transport Layer Security
    TLSv1.2 Record Layer: Application Data Protocol: http2
        Content Type: Application Data (23)       # 應用資料
        Version: TLS 1.2 (0x0303)
        Length: 94
        Encrypted Application Data: 00000000000000010330a080c236d86aae91be7f0035145f74bd9f2d245ec4528b37e72a…
        [Application Data Protocol: http2]     
-----------------------------------------------------------------------------------
Transport Layer Security
    TLSv1.2 Record Layer: Handshake Protocol: New Session Ticket
        Content Type: Handshake (22)
        Version: TLS 1.2 (0x0303)
        Length: 202
        Handshake Protocol: New Session Ticket
            Handshake Type: New Session Ticket (4)
            Length: 198
            TLS Session Ticket
                Session Ticket Lifetime Hint: 300 seconds (5 minutes)
                Session Ticket Length: 192
                Session Ticket: 6b493048344b6c62545630734b58616746b035cebe98b47299f98db9e76ea5214b0e2e75…
    TLSv1.2 Record Layer: Change Cipher Spec Protocol: Change Cipher Spec
        Content Type: Change Cipher Spec (20)
        Version: TLS 1.2 (0x0303)
        Length: 1
        Change Cipher Spec Message
    TLSv1.2 Record Layer: Handshake Protocol: Encrypted Handshake Message
        Content Type: Handshake (22)
        Version: TLS 1.2 (0x0303)
        Length: 40
        Handshake Protocol: Encrypted Handshake Message

https協議中密碼套件內容

• 下圖是TLS第二次握手返回的資訊（服務端的Server Hello資訊）

Transport Layer Security
    TLSv1.2 Record Layer: Handshake Protocol: Server Hello
        Content Type: Handshake (22)
        Version: TLS 1.2 (0x0303)
        Length: 74
        Handshake Protocol: Server Hello
            Handshake Type: Server Hello (2)
            Length: 70
            Version: TLS 1.2 (0x0303)
            Random: 2b3e737287f120241fbf1c4ff1595e3b5c028795d69a0e47cc0d806cf9aee080
                GMT Unix Time: Dec 28, 1992 11:24:34.000000000 中國標準時間
                Random Bytes: 87f120241fbf1c4ff1595e3b5c028795d69a0e47cc0d806cf9aee080
            Session ID Length: 0
            Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)  

密碼套件的內容

Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f) 
密匙交換演算法ECDHE+伺服器證書的簽名演算法型別（RSA型別簽名演算法） + 對稱加密演算法（AES_128，分組模式是GCM） + hash演算法（SHA256）
注意：
1）證書是RSA的，則就可以支援RSA的簽名演算法，如果是ECDSA的證書，則可以支援ECDSA的簽名演算法

密匙協商的定義：金鑰協商(key establishment)包括“金鑰傳輸”(key transmission)和“金鑰交換”(key exchange)。

密匙協商DH演算法背後的數學思想

數學原理：離散對數

底數a和模數p是離散對數的公共引數，i是對數，b是真數 
知道對數i很容易計算真數b,但知道真數b很難獲知對數i => b作為公鑰，i作為私匙

注意：當模數 p 是⼀個很⼤的質數，即使知道底數 a 和真數 b ，在現有的計算機的計算⽔平是⼏乎⽆法算出離散
對數的，這就是 DH 演算法的數學基礎。

密匙協商演算法DH（Diffie-Hellman）計算出對稱加密密匙作為會話金鑰使⽤流程

加密雙方：bob和Alice
step1: bob和Alice首先進行通訊約定2個引數即模數P和底數G作為DH演算法的公共引數，並各⾃⽣成⼀個隨機整數作為DH演算法的私鑰
step2:bob和Alice使用2個公共引數與自己的私鑰匙各自計算出對應的公鑰A和B
step3:再次通訊交換DH演算法公鑰
step4：使用對方提供的DH演算法公鑰和自己的私匙，利用離散對數的冪運算有交換律，計算出相同的會話密匙也就是對稱加密密匙K
獲取會話密匙的注意點：
1）雙方需要約定公共引數
2）雙方需要交換DH演算法公匙

DH演算法分類

分類依據：根據私鑰的分類方式

• static DH:有⼀⽅的私鑰是靜態的，也就說每次金鑰協商的時候有⼀⽅的私鑰都是⼀樣的，⼀般是伺服器⽅固定，即 a 不變，客戶端的私鑰則是隨機⽣成的。

static DH缺點：存在安全隱患，沒有前向安全性
DH 交換金鑰時就只有客戶端的公鑰是變化，⽽服務端公鑰是不變的，那麼隨著時間延⻓，⿊客就會截獲海
量的金鑰協商過程的資料，因為金鑰協商的過程有些資料是公開的，⿊客就可以依據這些資料暴⼒破解出伺服器的
私鑰，然後就可以計算出會話金鑰了，於是之前截獲的加密資料會被破解，所以 static DH 演算法不具備前向安全
性。

• DHE 演算法， E 全稱是 ephemeral（臨時性的）

DHE演算法缺點：計算開銷較大
固定⼀⽅的私鑰有被破解的⻛險，那麼⼲脆就讓雙⽅的私鑰在每次金鑰交換通訊時，都是隨機⽣成的、臨時
的，這個⽅式也就是 DHE 演算法， E 全稱是 ephemeral（臨時性的）。
ephemeral: [ɪˈfɛmərəl]

• ECDHE 演算法

在 DHE 演算法的基礎上利⽤了 ECC 橢圓曲線特性，可以⽤更少的計算量計算出公鑰，以及最終的會話金鑰。  

⼩紅和⼩明使⽤ ECDHE 金鑰交換演算法的過程：
1) 雙⽅事先確定好使⽤哪種橢圓曲線，和曲線上的基點 G，這兩個引數都是公開的；
2) 雙⽅各⾃隨機⽣成⼀個隨機數作為私鑰d，並與基點 G相乘得到公鑰Q（Q = dG），此時⼩紅的公私鑰為 Q1和 d1，⼩明的公私鑰為 Q2 和 d2；
3) 雙⽅交換各⾃的公鑰，最後⼩紅計算點（x1， y1） = d1Q2，⼩明計算點（x2， y2） = d2Q1，由於橢圓曲線
上是可以滿⾜乘法交換和結合律，所以 d1Q2 = d1d2G = d2d1G = d2Q1 ，因此雙⽅的 x 座標是⼀樣的，所以
它是共享金鑰，也就是會話金鑰。
4) 這個過程中，雙⽅的私鑰都是隨機、臨時⽣成的，都是不公開的，即使根據公開的資訊（橢圓曲線、公鑰、基點
G）也是很難計算出橢圓曲線上的離散對數（私鑰）。

採用RSA和ECDHE進行密匙協商對於加密連線建立影響

12501	31.146350	49.52.10.139	101.37.115.180	TLSv1.2	571	Client Hello
12505	31.157473	101.37.115.180	49.52.10.139	TCP	60	443 → 4608 [ACK] Seq=1 Ack=518 Win=30720 Len=0
12506	31.160535	101.37.115.180	49.52.10.139	TLSv1.2	1434	Server Hello
12507	31.161218	101.37.115.180	49.52.10.139	TLSv1.2	1434	Certificate [TCP segment of a reassembled PDU]
12508	31.161218	101.37.115.180	49.52.10.139	TLSv1.2	319	Server Key Exchange, Server Hello Done
12509	31.161283	49.52.10.139	101.37.115.180	TCP	54	4608 → 443 [ACK] Seq=518 Ack=3026 Win=131072 Len=0
12517	31.190495	49.52.10.139	101.37.115.180	TLSv1.2	147	Client Key Exchange, Change Cipher Spec, Encrypted Handshake Message
----------------------------------------------------------------------------------
12518	31.190825	49.52.10.139	101.37.115.180	TLSv1.2	153	Application Data
---------------------------------------------------------------------------------
12519	31.191459	49.52.10.139	101.37.115.180	TCP	1434	4608 → 443 [ACK] Seq=710 Ack=3026 Win=131072 Len=1380 [TCP segment of a reassembled PDU]
12520	31.191459	49.52.10.139	101.37.115.180	TLSv1.2	1361	Application Data
12521	31.202447	101.37.115.180	49.52.10.139	TLSv1.2	312	New Session Ticket, Change Cipher Spec, Encrypted Handshake Message
-------------------------------------------------------------------------------------
12522	31.203126	101.37.115.180	49.52.10.139	TLSv1.2	123	Application Data

• 上面抓包流程中在12519之前即在 TLS 第四次握⼿前，客戶端就已經發送了加密的 HTTP 資料（說明客戶端/服務端已經獲取到了會話密匙），⽽對於 RSA 握⼿過程，必須要完成 TLS 四次握⼿，才能傳輸應⽤資料

ECDHE 相⽐ RSA 握⼿過程省去了⼀個訊息往返的時間，這個有點「搶跑」的意思，它被稱為是「TLS
False Start」，跟「TCP Fast Open」有點像，都是在還沒連線完全建⽴前，就傳送了應⽤資料，這樣便提⾼了傳
輸的效率。

金鑰協商演算法總結

目的：用於TLS/SSL四次握手過程中協商對稱金鑰

金鑰協商(key establishment)包括“金鑰傳輸”(key transmission)和“金鑰交換”(key exchange)。

RSA演算法與DH系列演算法的本質區別：

RSA演算法:作用是Key Transmission（密匙傳輸）,用於產生Session Key的“種子”是由客戶端決定，用伺服器的公鑰加密並再次傳輸到伺服器端。
DH演算法：作用是密匙交換，DH演算法一定是配合對稱加密演算法使用，對稱加密演算法工作前必須必須確保雙方持有會話密匙，DH演算法通過雙發的隨機數交換利用離散對數的交換律可以直接計算出對稱加密的鑰匙。
總結如下：
1) RSA 金鑰協商演算法「不⽀持」前向保密， ECDHE 金鑰協商演算法「⽀持」前向保密；
2) 使⽤了 RSA 金鑰協商演算法， TLS 完成四次握⼿後，才能進⾏應⽤資料傳輸，⽽對於 ECDHE 演算法，客戶端可以不⽤等服務端的最後⼀次 TLS 握⼿，就可以提前發出加密的 HTTP 資料，節省了⼀個訊息的往返時間；
3) 使⽤ ECDHE， 在 TLS 第 2 次握⼿中，會出現伺服器端發出的「Server Key Exchange」訊息，⽽ RSA 握⼿過程沒有該訊息

密匙協商演算法定義

2-2-2 TLS建立加密通訊的流程

step1:建立TCP連線即三次握手

抓包分析：

瀏覽器發起TCP連線，可以看到：
1）本地瀏覽器IP地址為49.52.10.139，使用的埠號為4608
2）部落格園網站的公網IP為101.37.115.180，使用埠為443
注意：443為https協議常用的埠

step2: TLS四次互動(2RTT:Round-Trip Time))

• 採用EDCH的密匙協商演算法，公鑰是算出來的

step1:客戶端向服務端發起加密通訊握手請求，也就是Client Hello資訊
主要資訊包括：協議版本，密碼套件等的約定
（1）客戶端⽀持的 SSL/TLS 協議版本，如 TLS 1.2 版本。
（2）客戶端⽣產的隨機數（ Client Random ），後⾯⽤於⽣產「會話祕鑰」。
（3）客戶端⽀持的密碼套件列表，如 RSA 加密演算法。

step2:服務端響應加密通訊的請求，返回server Hello資訊
主要資訊包括服務端最終選擇密碼套件以及版本等資訊，還有最重要的就是服務端證書和用於產生會話密匙的協商演算法所需要的協商演算法公鑰資訊。
（1）確認 SSL/ TLS 協議版本，如果瀏覽器不⽀持，則關閉加密通訊。
（2）伺服器⽣產的隨機數（ Server Random ），後⾯⽤於⽣產「會話祕鑰」。
（3）確認的密碼套件列表，如 RSA 加密演算法。
（4）伺服器的數字證書CA

step3：客戶端收到伺服器的響應，校驗CA證書並從證書中獲取公匙，後續簽名信息都會用證書中的公匙加密，並且計算出會話密匙，然後服務端所需要的用於產生會話密匙的協商演算法所需要的協商演算法公鑰資訊。

step4:服務端收到計算會話密匙所需要的資訊後，然後響應表示自己準備好了加密通訊所需要的會話密匙，發「Change Cipher Spec」和「Encrypted Handshake Message」訊息.

注意：上面的流程是基於ECDH協商演算法生成會話密匙的流程，基於RSA協商演算法的流程會有所區別

https四次互動的流程梳理

四次通訊梳理：
1）第一次往返後，客戶端與服務端約定好協議版本，密碼套件，客戶端獲取CA證書並校驗從而拿到服務端的RSA公匙，該公共鑰匙會最為簽名信息的加密密匙
2）第二次往返後，客戶端與服務端要計算出會話密匙(比如AES128的對稱加密密匙)，用於加密傳輸的資料。

問題：TLS加密通訊連線建立的過程中三次隨機數的作用？

最終的會話金鑰，就是⽤「客戶端隨機數 + 服務端隨機數 + x（ECDHE 演算法算出的共享金鑰） 」三個材料⽣成
的。 
傳輸隨機數的動機：TLS 設計者不信任客戶端或伺服器「偽隨機數」的可靠性，為了保證真正的完全隨機，
把三個不可靠的隨機數混合起來，那麼「隨機」的程度就⾮常⾼了，⾜夠讓⿊客計算出最終的會話金鑰，安全性更
⾼

2-2-3 基於ECDH的TLSv1.2的建立流程抓包資訊

可以參考小林coding的圖解網路書籍，寫的非常不錯

抓包分析

12489	31.131823	49.52.10.139	101.37.115.180	TCP	66	4608 → 443 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 WS=256 SACK_PERM=1
12499	31.143002	101.37.115.180	49.52.10.139	TCP	66	443 → 4608 [SYN, ACK] Seq=0 Ack=1 Win=29200 Len=0 MSS=1380 SACK_PERM=1 WS=512
12500	31.143109	49.52.10.139	101.37.115.180	TCP	54	4608 → 443 [ACK] Seq=1 Ack=1 Win=131072 Len=0
12501	31.146350	49.52.10.139	101.37.115.180	TLSv1.2	571	Client Hello
12505	31.157473	101.37.115.180	49.52.10.139	TCP	60	443 → 4608 [ACK] Seq=1 Ack=518 Win=30720 Len=0
12506	31.160535	101.37.115.180	49.52.10.139	TLSv1.2	1434	Server Hello
12507	31.161218	101.37.115.180	49.52.10.139	TLSv1.2	1434	Certificate [TCP segment of a reassembled PDU]
12508	31.161218	101.37.115.180	49.52.10.139	TLSv1.2	319	Server Key Exchange, Server Hello Done
12509	31.161283	49.52.10.139	101.37.115.180	TCP	54	4608 → 443 [ACK] Seq=518 Ack=3026 Win=131072 Len=0
12517	31.190495	49.52.10.139	101.37.115.180	TLSv1.2	147	Client Key Exchange, Change Cipher Spec, Encrypted Handshake Message
12518	31.190825	49.52.10.139	101.37.115.180	TLSv1.2	153	Application Data
12519	31.191459	49.52.10.139	101.37.115.180	TCP	1434	4608 → 443 [ACK] Seq=710 Ack=3026 Win=131072 Len=1380 [TCP segment of a reassembled PDU]
12520	31.191459	49.52.10.139	101.37.115.180	TLSv1.2	1361	Application Data
12521	31.202447	101.37.115.180	49.52.10.139	TLSv1.2	312	New Session Ticket, Change Cipher Spec, Encrypted Handshake Message
12522	31.203126	101.37.115.180	49.52.10.139	TLSv1.2	123	Application Data
12523	31.203126	101.37.115.180	49.52.10.139	TLSv1.2	92	Application Data

握手過程中的抓包提示資訊

瀏覽器->部落格園：1) Client Hello
部落格園->瀏覽器：2) Server Hello 
   				Certificate [TCP segment of a reassembled PDU]
   				Server Key Exchange, Server Hello Done
瀏覽器->部落格園：3) Client Key Exchange, Change Cipher Spec, Encrypted Handshake Message
                Application Data
部落格園->瀏覽器 4) New Session Ticket, Change Cipher Spec, Encrypted Handshake Message

總結：TLS1.2協議由於ECDH演算法特性，實際上第三次互動，客戶端就可以傳送資料給服務端了。

session Ticket的作用：

知識點：TCP segment of a reassembled PDU的含義

基於TCP在傳輸訊息時，對於上面的應用層如果出於某些原因（如超過MSS）TCP Segment不能一次包含全部的應用層PDU，而要把一個完整訊息分成多個段，就會將除了最後一個分段（segment）的所有其他分段都打上“TCP segment of a reassembled PDU”

2-2-4 TLS協議的發展

起源

SSL(Secure Sockets Layer)與TLS(Transport Layer Security)本質上一個東西，一個是標準化前的名稱，一個是標準化後的名稱。

TLS1.3對TLS1.2的優化

上圖是TLS1.2和TLS1.3的區別

• 1）TLS1.3優化了TLS1.2過程，只需要 1 個 RTT 往返時延，也就是隻需要3次握⼿

TLS1.3預設只支援ECDH密匙協商演算法！！！！！！。因此不需要像TLS1.2一樣，通過hello的應答資訊確定密匙協商演算法，所有在第一次互動中將hello資訊與公鑰互動的資訊合併傳送，從而減少了一次握手

• 2）TLS1.3支援更少的密碼套件

TLS_AES_256_GCM_SHA384
TLS_CHACHA20_POLY1305_SHA256
TLS_AES_128_GCM_SHA256
TLS_AES_128_CCM_8_SHA256
TLS_AES_128_CCM_SHA256
動機：安全考量

2-2-5 https的優化策略

策略1：TLS連線的會話複用

動機：⾸次 TLS 握⼿協商的對稱加密金鑰快取起來，待下次需要建⽴ HTTPS 連線時，直接「復⽤」這個金鑰，不就減少 TLS 握⼿的效能損耗

會話復⽤分採用兩種機制實現：
第⼀種叫 Session ID；
第⼆種叫 Session Ticket；

Session ID 的⼯作原理：
    客戶端和伺服器⾸次 TLS 握⼿連線後，雙⽅會在記憶體快取會話金鑰，並⽤唯⼀的Session ID 來標識， Session ID 和會話金鑰相當於 key-value 的關係。當客戶端再次連線時， hello 訊息⾥會帶上 Session ID，伺服器收到後就會從記憶體找，如果找到就直接⽤該會話金鑰恢復會話狀態，跳過其餘的過程，只⽤⼀個訊息往返就可以建⽴安全通訊。當然為了安全性，記憶體中的會話金鑰會定期失效。
缺點：1）多個連線的多個ID引入伺服器的記憶體開銷 2）負載均衡導致連線的伺服器未必是同一伺服器，id未必有效

Session Ticket:伺服器不再快取每個客戶端的會話金鑰，⽽是把快取的工作交給了客戶端
----------------------------------------------------------------------------------------------------------
原理：客戶端與伺服器⾸次建⽴連線時，伺服器會加密「會話金鑰」作為 Ticket 發給客戶端，交給客戶端快取該 Ticket。客戶端再次連線伺服器時，客戶端會發送 Ticket，伺服器解密後就可以獲取上⼀次的會話金鑰，然後驗證有效期，如果沒問題，就可以恢復會話了，開始加密通訊。
-----------------------------------------------------------------------------------------------------------

注意：有點類似於token與session資訊的維護

3 http2.0協議簡介

3-1 協議設計動機

網站資料傳輸需求變化：訊息變大，資源的內容樣式更加多 => 對請求與響應的延遲有了更加嚴格的效能要求

針對http1.1的延遲以及連線上限問題問題，從具體的技術層面有以下的技巧優化：

1) 多張⼩圖合併成⼀張⼤圖供瀏覽器 JavaScript 來切割使⽤，這樣可以將多個請求合併成⼀個請求，但是帶來了新的問題，當某張⼩圖⽚更新了，那麼需要重新請求⼤圖⽚，浪費了⼤量的⽹絡頻寬（減少資源數目過多引發的請求開銷),類似機制比如多個體積較⼩的 JavaScript ⽂件使⽤ webpack 等⼯具打包成⼀個體積更⼤的 JavaScript ⽂件。同樣某個js⽂件變化，需要重新請求同⼀個包⾥的所有js⽂件。
2) 圖⽚的⼆進位制資料通過base64編碼後，把編碼資料嵌⼊到HTML或CSS⽂件中，以此來減少⽹絡請求次數(作為文字後，瀏覽器不需要另外再去請求圖片資源，圖片直接作為文字給傳輸過來)
3）將同⼀個⻚⾯的資源分散到不同域名，提升併發連線上限，因為瀏覽器通常對同⼀域名的 HTTP 連線最⼤只能是6個

知識點：使用base64編碼圖片的動機

優點：1）減少了HTTP請求 2）某些檔案可以避免跨域的問題 3）沒有圖片更新要重新上傳，還要清理快取的問題
缺點：1）根據 base64 的編碼原理，編碼後的大小會比原檔案大小大 1/3 ，如果把大圖片編碼到
html/css 中，不僅會造成檔案體積的增加，影響檔案的載入速度，還會增加瀏覽器對 html 或 css 檔案解析渲染的時間。
2）使用 base64 無法直接快取，要快取只能快取包含 base64 的檔案，比如 HTML 或者 CSS ，
這相比域直接快取圖片的效果要差很多
3）相容性的問題,ie8以前的瀏覽器不支援。一般一些網站的小圖示可以使用 base64 圖片來引入。
------------------------------------------------------------------------------------------------------------------
使用base64編碼需要考慮三點：
    1）編碼資源是否需要快取
    2）減少http請求是否很有必要
    3）瀏覽器的相容性需要考慮

3-2 協議優化點

問題：http1.1和http2.0的隊頭阻塞問題的區別？

本質區別：1.1是應用層的隊頭阻塞，而2.0是傳輸層的隊頭阻塞

http2.0的隊頭阻塞問題：HTTP/2 是基於 TCP 協議來傳輸資料的， TCP 是位元組流協議， TCP 層必須保證收到的位元組資料是完整且連續的，
這樣核心才會將緩衝區⾥的資料返回給 HTTP 應⽤，那麼當「前 1 個位元組資料」沒有到達時，後收到的位元組資料只能存放在核心緩衝區⾥，只有等到這 1 個位元組資料到達時， HTTP/2 應⽤層才能從核心中拿到資料，這就是HTTP/2 隊頭阻塞問題。

4 http3.0協議

3-1 設計動機

http2.0的設計動機回顧：

對http1.1的效能進行優化：採用頭部壓縮、⼆進位制編碼、多路復⽤、伺服器推送

http2.0在效能上仍然存在以下問題：傳輸層隊頭阻塞，TLS握手延遲，網路遷移開銷

http2.0使用的是TCP，由於TCP本身的特性，帶來下面問題：
1) 隊頭阻塞：TCP在設計上通過序號機制保證了資料的有序性，因此如果低位序號丟失，那麼高位序列資料也無法被應用層獲取，這一定程度造成了阻塞。
2) TCP 與 TLS 的握⼿時延遲：(三次握手+四次加密通訊請求握手,3個RTT延遲)
3) ⽹絡遷移需要重新連線：一個TCP連線是通過四元組確定，因此 IP 地址或者端⼝變動了，就會導致需要 TCP 與 TLS 重新握⼿，這不利於移動裝置切換⽹絡的場景，⽐如 4G ⽹絡環境切換成WIFI。

http2.0的問題本質：TCP協議的設計所限制

3-2 QUIC協議

QUIC 協議：基於 UDP 協議在「應⽤層」實現

QUIC 協議的特點：

• ⽆隊頭阻塞， QUIC 連線上的多個 Stream 之間並沒有依賴，都是獨⽴的，也不會有底層協議限制，某個流發
  ⽣丟包了，只會影響該流，其他流不受影響；
• 建⽴連線速度快，因為 QUIC 內部包含 TLS1.3，因此僅需 1 個 RTT 就可以「同時」完成建⽴連線與 TLS 金鑰
  協商，甚⾄在第⼆次連線的時候，應⽤資料包可以和 QUIC 握⼿資訊（連線資訊 + TLS 資訊）⼀起傳送，達到
  0-RTT 的效果。
• 連線遷移， QUIC 協議沒有⽤四元組的⽅式來“繫結”連線，⽽是通過「連線 ID 」來標記通訊的兩個端點，客戶
  端和伺服器可以各⾃選擇⼀組 ID 來標記⾃⼰，因此即使移動裝置的⽹絡變化後，導致 IP 地址變化了，只要仍
  保有上下⽂資訊（⽐如連線 ID、 TLS 金鑰等），就可以“⽆縫”地復⽤原連線，消除重連的成本；

3-3 http3.0的特點

http3.0直接使用QUIC提供的資料幀，因此更加資料幀簡單

HTTP/3 在頭部壓縮演算法升級HPACK為QPACK。HTTP/3 中的 QPACK 也採⽤了靜態表、動態表及 Huffman 編碼， QPACK 通過兩個特殊的單向流來同步雙⽅的動態表，解決了 HTTP/2 的 HPACK 隊頭阻塞問題。  
特點：動態表的優化
動態表，在⾸次請求-響應後，雙⽅會將未包含在靜態表中的 Header 項更新各⾃的動態表，接著後續傳輸時
僅⽤ 1 個數字表示，然後對⽅可以根據這 1 個數字從動態表查到對應的資料，就不必每次都傳輸⻓⻓的資料，⼤⼤
提升了編碼效率。可以看到， 動態表是具有時序性的，如果⾸次出現的請求發⽣了丟包，後續的收到請求，對⽅就⽆法解碼出
HPACK 頭部，因為對⽅還沒建⽴好動態表，因此後續的請求解碼會阻塞到⾸次請求中丟失的資料包重傳過來。
HTTP/3 的 QPACK 解決了這⼀問題，那它是如何解決的呢？QUIC 會有兩個特殊的單向流，所謂的單項流只有⼀端可以傳送訊息，雙向則指兩端都可以傳送訊息，傳輸 HTTP
訊息時⽤的是雙向流，這兩個單向流的⽤法：⼀個叫 QPACK Encoder Stream， ⽤於將⼀個字典（key-value）傳遞給對⽅，⽐如⾯對不屬於靜態表的
HTTP 請求頭部，客戶端可以通過這個 Stream 傳送字典；⼀個叫 QPACK Decoder Stream，⽤於響應對⽅，告訴它剛發的字典已經更新到⾃⼰的本地動態表了，後續就
可以使⽤這個字典來編碼了。這兩個特殊的單向流是⽤來同步雙⽅的動態表，編碼⽅收到解碼⽅更新確認的通知後，才使⽤動態表編碼 HTTP 頭部。

更多說明參考尾部連結02

Wireshark簡單使用

常用單條過濾命令

http請求相關

http.request.method=="GET" 
http.request.method=="POST"

ip地址過濾

ip.dst==49.52.10.41
ip.src==10.15.112.61
ip.addr==xxx.xxx.xxx.xxx     # 同時過濾

埠過濾：協議+埠號

tcp.srcport==80
tcp.dstport==80

組合命令

http.request.method=="GET"and tcp.port==80    # 過濾出GET方法並且埠是80

參考資料

01 wireshark的安裝包下載

02 微信公眾號:⼩林coding(圖解網路內容)，特別推薦

03 http請求user_agent欄位解析

04 http響應頭中快取相關欄位