Internet1 http协议简单介绍

目录

1 协议的基本概念

1-0 队头阻塞问题

TCP队头阻塞: TCP某个部分丢失，但是后续的数据不按序到达接收端的时候,由于TCP协议要保证有序性,其先达到的后续数据必须等待丢失数据重传过来才能该将数据包交给应用层, 即HTTP2某个stream出现丢包时，该stream后续的包需要等待TCP重传，那么就会影响其他stream(HTTP/3解决了用UDP+QUIC解决了TCP队头阻塞的问题)

HTTP1.1队头阻塞: 在HTTP/1.1中客户端发送请求，服务器回应客户端的请求，客户端发送的每一个请求，需要等待服务器回应后才能发送下一个请求，即所有请求在一个FIFO队列里，如果队头请求意外阻塞，这样就会造成队头阻塞。即如果队头的请求响应时间太长，会影响后面的请求的处理(HTTP2用流和分帧的方式HTTP的队头阻塞问题)
缓解技术:
1)管道化:可以不等待上次请求的响应,直接发送下一个请求信息,但是客户端仍然需要按照请求的顺序处理响应,单个请求响应时间较长仍然会阻塞后续的请求,不能解决队头阻塞问题.
2)并发的TCP连接

1-1 http协议发展概述

协议的本质区分：安全性，性能问题

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

QUIC协议

协议名称 性能 安全 缺陷 传输层协议
http1.0 TCP短连接，不支持断点传输 无法解决窃听，篡改，顶替问题,配合TLS协议 TCP
http1.1 TCP长连接（Connection:keep-alive），支持断点续传（Range） 无法解决窃听，篡改，顶替问题，配和TLS协议 TCP
http2.0（主流网站使用配合TLS协议） 头部压缩、⼆进制编码、多路复⽤、服务器推送 TLS(SSL)层解决窃听，篡改，顶替问题 TCP
http3.0 采用QUIC协议,该协议基于UDP保证可靠传输 QUIC协议包含TLS UDP 
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字段显示的信息也是不同的。

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
字段名称 属性说明 应用场景 属性值
Host 服务器的域名 服务端根据host字段来确定客户端将访问的网站路径
User-Agent 多个公司的浏览器标识，如：Mozilla、Chrome、Safari，也包含多个渲染引擎标识 聚合扫码服务，可以根据每个app的user-agent字段确定扫码app类型 浏览器的常见User Agent 各字段的解释
Content-Length 响应内容长度 根据这个字段获取响应消息体的内容
Connection 持久连接设置字段 客户端要求服务器使⽤ TCP 持久连接，以便其他请求复⽤。 keep-live
Content-Type 内容类型 客户/服务端根据这个字段确定内容的类型，并采用对应的解码方式 可选值
Content-Encoding/Accept-Encoding 内容压缩方法设置 客户端根据Content-Encoding确定解压方式，通过Accept-Encoding告知解压方法 gzip
expires 缓存过期的时间（1.0字段，1.1使用cache-control:max-age取代该字段）服务端可以通过该字段告知返回资源的有效期 强制缓存字段
cache-control 在缓存未失效时候，浏览器向服务端发起请求，直接从缓存中获取数据， 强制缓存字段 private, public, nocache, max-age, nostore
If-modified-Since(Last-Modified) 资源最后修改的时间 对比缓存使用
Etag（Entity Tag） 根据实体内容计算的hash值，用于标记当前资源是否改变

知识点：对比缓存（协商缓存）

核心思想：客户端请求携带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？

  1. 冒充风险：访问的站点非目标服务器站点。钓鱼网站(CA证书)。
  • https 被劫持: 客户单安装伪造的CA 证书,被代理服务器劫持。没有认证的证书，客户端选择信任。
HTTPS
窃听风险（泄密） 混合加密（对称+非对称）
篡改风险（劫持） 摘要算法（本质是哈希函数）
冒充风险（冒充） CA证书（服务器公钥放⼊到数字证书 ）
知识点1：CA证书如何确保服务器的公钥是可靠的(冒充风险)？

HTTPS体系中若攻击者将自己公钥上传CA得到签名，并将两者一起用于篡改证书的中间人攻击会怎样

  • 关键对象：浏览器，服务器，证书颁发机构（CA, Certificate Authority）（CA服务器）
  • 核心：浏览器与服务器必须保证证书颁发机构可靠（CA的私匙不会被泄漏）
问题:CA证书的检验的流程
1) 服务器向CA注册公匙
2）CA用自己的私匙对服务端公钥进行加密，并放入到数字证书中，颁发给服务端
3）客户端拿到服务端数字证书后，使用CA服务器提供的公钥进行解密并校验数字签名，没有问题则获取到服务端公钥，
  • 可靠性依赖于认证机构
知识点2：DNS协议的安全问题
DNS劫持：修改域名解析的结果（比如修改操作系统的域名文件将IP地址进行替换）
劫持方法：控制域名解析流程中任意环节都能够实现DNS劫持
====================================================================================
浏览器域名解析的流程：
1）首先搜索浏览器的 DNS 缓存（各种浏览器有固定值），缓存中维护一张域名与 IP 地址的对应表
2）若没有命中，则继续搜索操作系统的 DNS 缓存（C:WindowsSystem32driversetchosts）
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)
TLS协议字段比较重要的字段 说明
Content Type 内容类型（Handshake,Change Cipher Spec,Application Data）
Random 客户端产生的随机数
Session ID 会话ID
Cipher Suites（16种供服务端选择） 密码套件
Compression Methods 压缩方法
Extensions 扩展字段 
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 无前向安全性 使⽤ RSA 密钥交换算法的 TLS 握⼿过程，不仅慢，⽽且安全性也不⾼。
DH 无前向安全性
DHE 前向安全
ECDHE 前向安全 该算法由于⽀持可以让客户端抢跑，在 TLS 协议的第 3 次握⼿后就可以发送应用数据

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 协议优化点

特点 实现
头部压缩 HPACK 算法， HPACK 算法主要包含三个组成部分：静态字典；动态字典；Huffman 编码（压缩算法），http1.1可以采用gzip压缩资源 传输数据压缩
⼆进制帧 数据压缩
并发传输 多个 Stream 复⽤⼀条 TCP 连接，同一stream通过stream ID乱序传输（TCP特性，单个流的数据丢失会影响其他流） 应用层队头阻塞问题解决
服务器主动推送资源 客户端发起的请求，必须使⽤的是奇数号 Stream，服务器主动的推送，使⽤的是偶数号 Stream。服务器在推送源时，会通过 PUSH_PROMISE 帧传输 HTTP 头部，并通过帧中的 Promised Stream ID 字段告知客户端，接下来会在哪个偶数号 Stream 中发送包体
问题：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 HTTP2
⽆传输层或者应用层的队头阻塞 (流与流之间没有影响，影响限制在单个流) HTTP/2 只要某个流中的数据包丢失了，其他流也会因此受影响。
更快连接建⽴(QUIC 内部包含了 TLS ) TLS与TCP都需要分别建立连接
连接迁移 （通过上下⽂信息（连接 ID、 TLS 密钥等），就可以“⽆缝”地复⽤原连接，消除重连的成本） TCP基于四元组

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响应头中缓存相关字段

【推广】 免费学中医，健康全家人
原文地址：https://www.cnblogs.com/kfcuj/p/15227468.html