HTTP

增加了 HEAD、POST 等新方法

增加了响应状态码

引入了协议版本号概念

引入了 HTTP Header 概念

传输不再仅限文本

增加 PUT、DELETE 等新方法

增加缓存管理和控制

明确了连接管理,允许持久连接

允许响应数据分块(chunked),利于传输大文件

强制要求 Host 头

从纯文本到二进制协议

可以发起多个请求,废弃了 1.1 的管道

使用专用算法压缩头部,减少数据传输量

允许服务器主动向客户端推送数据

增强了安全性,要求加密通信

HTTP 是一个在计算机世界里专门在两点之间传输文字、图片、音频、视频等超文本数据的约定和规范

HTTP 是一个在计算机世界里专门用来在两点之间传输数据的约定和规范

HTTP 是一个用在计算机世界里的协议,它使用计算机能够理解的语言确立了一种计算机之间交流通信的规范,以及相关的各种控制和错误处理方式

负载均衡

安全防护

周边计算

跨运营商网络

加速访问

应用层

传输层 TCP 所在的层,又叫 TCP 层

网际层 IP 所在的层,又叫 IP 层

链接层

Internet Protocol

解决寻址和路由问题,以及如何在两点之间传数据包

分为 V4 和 V6 两个版本

V4 使用"."分割数字,最大 2^32 次方个,大概 4 亿

V6 使用 8 组":"分割,最大 2^128 次方个

Transmission Control Protocol "传输控制协议"

位于IP 之上,基于 IP 协议提供可靠的,字节流通信

可靠,是指保证数据不丢失

字节流,是指保证数据完整

HTTP 全称: HTTP over TCP/IP

统一资源标识符

唯一的标记互联网上的资源

构成

统一资源定位符(网址)

URI 的子集

负责加密通信的安全协议

建立在 TCP 之上

可靠的传输协议

全称: Secure Socket Layer

网景公司发明,在 3.0 版本成功成为了标准,改名为 TLS 即Transport Layer Security

匿名代理

透明代理

正向代理

反向代理

中间层

HAProxy代理软件定制 

不属于 RFC 标准

application layer 应用层

transport layer 传输层

Internet layer 网际层/网络互联层

link layer 链接层

HTTP 的单位是 消息/报文 message

TCP 层是 段 segment

IP 层是 包 packet

MAC 层是 帧 frame

应用层

表示层

会话层

传输层

网络层

数据链路层

物理层

OSI 中五六七层分的太细

而在 TCP/IP 实际应用中,会话管理, 编码转换,压缩等和具体应用经常联系的很紧密,很难分开

就是分摊到多个操作单元上执行

例如多个请求过来之后,Nginx 分发到各个不同的服务器上

在传输层上

基于 TCP/IP 协议特性

如 IP 地址,端口号等实现对后端服务器的负载均衡

在应用层上

检查 HTTP 协议,解析 HTTP 报文里的 URI,主机名,资源类型等数据,再用适当策略转发给后端服务器

域名解析必须通过 DNS

DNS 的核心是一个三层的树状、分布式服务

DNS 如何更快速,更稳定的提供结果

DNS 分为几种

浏览器缓存

操作系统DNS缓存

HOSTS 文件

非权威域名服务器

根域名服务器

顶级域名服务器

二级域名服务器

权威域名服务器

当主机需要迁移,下线的时候,更改 DNS 记录,让域名指向其它主机

通过 bind9 等开源软件搭建内部 DNS ,这样,内部服务就可以用域名来标记

1、给域名绑定多个 IP 地址,让客户端自己使用轮询算法依次向服务器发请求,实现负载均衡

2、域名解析配置内部策略,返回离客户端最近的主机,或者返回当前服务质量最好的主机

对域名直接不解析,返回错误,让你无法拿到 IP 地址

也叫域名污染,需要访问 A 网站,但 DNS 给了 B 网站

如 hosts 中 把某些软件的地址给设置成 127.0.0.1

地址栏输入 "127.0.0.1"

浏览器使用 52085 端口,服务器使用 80 端口

浏览器依照 TCP 协议规范,使用"三次握手"建利与 web 服务器的连接

三次握手依次是 SYN 、SYN/ACK、ACK 三个包

浏览器与服务器的 TCP 连接建立起来了

这里浏览器也是按照 HTTP 协议规定的格式,通过 TCP 发包

这个回复是在 TCP 协议层面的,这个 TCP 包 HTTP 协议是看不见的

Web 服务器依据 HTTP 协议规定解析报文,查看浏览器请求要干啥

这里是需要把对应的文件读出来,再拼成符合 HTTP 格式的报文

四次挥手依次是

浏览器向服务器发送 FIN 断开信号

服务器发送 ACK 确认

服务器发送 FIN 断开信号

浏览器向服务器发送 ACK 确认

CDN 会缓存网站大部分资源

如四层的 LVS 或者七层的 Nginx

描述请求或响应的基本信息

请求行

在浏览器中叫 General

响应头(数据返回的时候才会有) Response Headers

请求头(发送的时候才会有) Requests Headers

实际传输的数据,不一定是纯文本,也可以是图片,视频等二进制数据

又叫body

GET / HTTP/1.1

Bdpagetype: 2
Bdqid: 0xc5464998000054ba
Cache-Control: private
Connection: keep-alive
Content-Encoding: gzip
Content-Type: text/html;charset=utf-8
Date: Tue, 30 Nov 2021 13:59:18 GMT
Expires: Tue, 30 Nov 2021 13:59:17 GMT
Server: BWS/1.1
Set-Cookie: BDSVRTM=581; path=/
Set-Cookie: BD_HOME=1; path=/
Set-Cookie: H_PS_PSSID=35359_35104_31660_34902_34584_34504_35234_34872_35328_35315_26350_35145_22160; path=/; domain=.baidu.com
Strict-Transport-Security: max-age=172800
Traceid: 1638280758033839156214215130191025427642
X-Frame-Options: sameorigin
X-Ua-Compatible: IE=Edge,chrome=1
Transfer-Encoding: chunked

Host: www.baidu.com
Connection: keep-alive
Pragma: no-cache
Cache-Control: no-cache
sec-ch-ua: " Not A;Brand";v="99", "Chromium";v="96", "Google Chrome";v="96"
sec-ch-ua-mobile: ?0
sec-ch-ua-platform: "macOS"
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/96.0.4664.55 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
Cookie: PSTM=1610960062; BD_UPN=123253; BIDUPSID=413D02B41275409B2F813A64AAEE746C;

因为是个 GET 请求,所以没有消息正文

请求方法

请求目标

版本号

这三个部分使用空格分隔,最后要用 CRLF 换行表示结束

GET / HTTP/1.1

版本号

状态码

原因

HTTP/1.1 200 OK

HTTP/1.1 404 Not Found

有的网站反爬会做字段名排序检查

在请求头和响应头里都可以出现的

仅能在请求头中出现

仅能出现在响应头中

实际上属于通用字段,但专门描述 body 的额外信息

从服务器获取资源

获取资源的元信息

服务器不会返回请求的实体数据,只会传回响应头,这就是"元信息"

想要检查一个文件是否存在,发个 HEAD 请求就可以了

向资源提交数据,相当于上传,写入

表示新建 "Create"的含义

数据放在报文的 body 里

类似于 POST

UPDATE 的含义

删除资源

建利特殊的连接隧道

类似于代理IP 中的隧道代理

列出可对资源实行的方法

在响应头的 Allow 字段里返回,功能有限,用处不大

追踪请求- 响应的传输路径

多用于 HTTP 链路的测试或诊断,可以显示出请求 - 响应的传输路径

存在漏洞,会泄漏网站信息,所以 web 服务器通常也是禁用的

锁定资源暂时不允许修改

删除锁

给资源打小补丁,部分更新数据

在HTTP协议里，所谓的安全，是指请求方法不会对服务器上的资源造成实质的修改，所以只有GET和HEAD是安全的，因为是只读操作。

概念:多次执行相同的操作，结果也都是相同的

GET和HEAD 即是安全的也是幂等的

DELETE可以多次删除同一个资源，效果都是“资源不存在”，所以也是幂等

POST是新增或提交数据，多次提交会创建多个资源，所以不是幂等的

PUT是替换或更新数据，多次更新一个资源，资源还是第一次更新的状态。所以是幂等的

POST

本质上是一个字符串,这个字符串的作用是唯一地标记资源的位置或者名字

协议名

特定字符

资源所在的主机名

路径

查询参数

http://nginx.org

http://www.chrono.com:8080/11-1

https://tools.ietf.org/html/rfc7230

file:///D:/http_study/www/

http://www.chrono.com:8080/11-1?uid=1234&name=mario&referer=xxx

根据 RFC7230 ,现在不推荐这种形式

暴露了敏感信息,存在安全隐患

URI 所定位的资源内部的一个"锚点","标签"

浏览器可以在获取资源后直接跳转到它指示的位置

仅能浏览器这样的客户端使用,服务器看不到

不会把 "#fragment" 发送给服务器

俗称转义

URI 中只能使 ASCII 码

把非 ASCII 字符或特殊字符转换成十六进制字节值,并且前面加上一个"%"

中文,日文等使用 UTF-8 编码后再转义

把字符(unicode)编码成 utf-8,然后再每个字节转换成 16 进制,并在前面用"%"连接

空格

"?"

"银河"

其实是可以看到的,浏览器会友好一点,隐藏 URI 编码后的结果

提示信息,表示目前是协议处理的中间状态,还需要后续的操作

101

成功,报文已经收到并被正确处理

200 OK

204 No Content

206 Partial Content

重定向,资源位置发生变化,需要客户端重新发送请求

301 Moved Permanently

302 Found

303 See Other

304 Not Modified

307 Temporary Redirect

308 Permanent Redirect

客户端错误,请求报文有误,服务器无法处理

400 Bad Request

403 Forbidden

404 Not Found

405 Method Not Allowed

406 Not Acceptable

408 Request Timeout

409 Conflict

413 Request Entity Too Large

414 Request-URI Too Long

429 Too Many Requests

431 Request Header Fields Too Large

服务器错误,服务器在处理请求时内部发生错误

500 Internal Server Error

501 Not Implemented

502 Bad Gateway

503 Service Unavailable

向目标服务器请求,对客户端做出应答

把 HTTP 请求处理封装成远程函数调用

产物

HTTP 最大的优点是简单、灵活和易于扩展；

简单: header+body 都是简单的文本格式,常用的英文单词,降低了学习难度和使用门槛

灵活和易于扩展:

HTTP 拥有成熟的软硬件环境，应用的非常广泛，是互联网的基础设施

从简单的 web 页面到 json、XML 数据

从台式机浏览器上到 APP、新闻、论坛、游戏等等

天然具有"跨语言、跨平台",不局限于某种特定语言或者操作系统

服务器不需要额外资源来记录状态信息

没有"状态"差异,容易组成集群,让负载均衡把请求转发到任何一台服务器

轻松实现高并发

HTTP 是无状态的，可以轻松实现集群化，扩展性能，但有时也需要用 Cookie 技术来实现“有状态”；

服务器没有"记忆能力",无法支持需要连续多个步骤的"事务"操作

例如: 电商购物,登录,添加购物车,下单,结算,支付这个流程每次请求都需要检查用户的身份信息

HTTP 是明文传输，数据完全肉眼可见，能够方便地研究分析，但也容易被窃听

HTTP 报文的所有信息暴露

容易伪造

HTTP 是不安全的，无法验证通信双方的身份，也不能判断报文是否被窜改；

缺少身份认证和完整性校验

HTTPS 解决了这一点

HTTP 的性能不算差，但不完全适应现在的互联网，还有很大的提升空间

关键在于"请求-应答"

当顺序发送的请求序列中有一个请求因为某种原因被阻塞,之后的所有请求都被阻塞

官方为了决绝这个问题,在 HTTP 官方标准里有"缓存"一章(RFC7234)

现有解决方案: HTTP/2 和 HTTP/3

在 HTTP 诞生之前就有了解决方案,应用于电子邮件系统里,让电子邮件可以发送 ASCII 码以外的任意数据

通常被叫做 MIME type

text

image

audio/video

application

压缩

请求头中

作用: 标记客户端可理解的 MIME type

可以用 "," 分隔列出多个类型,让服务器选择

Accept: text/html,application/xml,image/webp,image/png

请求头中

标记客户端支持的压缩格式

可以给服务端传多个,服务端选一个

如果请求头中没有这个字段,表示客户端不支持压缩数据

Accept-Encoding: gzip, deflate, br

响应头中

作用是告诉浏览器,实体数据的真实类型

Content-Type: text/html
Content-Type: image/png

响应头中

标记服务器返回的数据压缩格式

只能选择客户端传过来的其中一种

Content-Encoding: gzip

请求头中

标记客户端可理解的自然语言

允许用","分隔

Accept-Language: zh-CN, zh, en

字符集在 HTTP 里的使用字段

请求头中

Accept-Charset: gbk, utf-8

响应头中

告诉客户端实体数据使用的实际语言类型

Content-Language: zh-CN

在响应头里包含了 body 的编码格式

响应头里

Content-Type: text/html; charset=utf-8

Content-Type: text/html; charset=utf-8

意思是它表示浏览器最希望使用的是 HTML文件,权重是 1

其次是 XML 文件,权重是 0.9

最后是任意数据类型,权重是 0.8

vary 字段表示服务器依据什么字段,然后决定发回的响应报文

Vary: Accept-Encoding,User-Agent,Accept

响应报文的特殊的"版本标记"

意思是报文里的 body 部分不是一次性发过来的,而是分块逐个发送的

表示 body 数据的长度未知

表示 body 里数据长度是已知的

要嘛有明确的数据长度,用 Content-Length

要嘛未知数据长度,用 Transfer-Encoding:chunked

采用了明文,类似响应头

具体规则

Range: bytes=x-y

x,y 表示请求范围

x,y 都是可以省略的

服务器收到 Range 字段后的四件事

Accept-Ranges:bytes

Accept-Ranges:none

Content-Length: 146515

先发个 HEAD,查看服务器是否支持范围你请求,同时获取文件大小

开 N 个线程,每个线程使用 Range 字段划分出各自负责下载的片段,发请求传输数据

下载意外中断,使用 Range 请求剩下的一部分就可以

表示报文的 body 是由多段字节序列组成

还需要一个参数"boundary=xxx"给出段之间的分隔标记

请求

响应

在请求头里加上"Connection:close" 字段,服务器看到这个字段,会在响应头里也加上这个字段,发送后调用 Socket API 关闭 TCP 连接

Nginx 中

HTTP/1.1 中的连接默认启动长连接,不需要特殊头字段指定

只要向服务器发送一次请求,后续的请求都会重复利用第一次打开的 TCP 连接,也就是长连接

也可以使用 Connection: keep-alive

如果服务器支持长连接,会在响应头中返回 "Connection: keep-alive"

断开可以在最后一个请求头中添加"Connection:close"字段

请求头中

请求头中添加"Connection:keep-alive"字段

断开可以在最后一个请求头中添加"Connection:close"字段

由 HTTP 的"请求-应答" 模型所致

因为 HTTP 规定报文必须是"一发一收",形成了一个先进先出的队列

队列里的请求没有优先级,只有入队的先后顺序

先进来的请求处理太慢,后面的请求全部阻塞等待

对同一域名发起多个长连接,用数量解决质量问题

RFC2616 里明确了每个客户端最多并发 2 个连接,被众多浏览器无视,后来在修订 RFC7230 中取消了

目前浏览器中使用 6-8 个连接

还是用数量来解决质量的思路

多开域名,将多个域名指向同一服务器

每次请求访问多个域名,都会指向同一服务器,这样就算是提高了并发量

由浏览器的使用者主动发起的,可以称为"主动跳转"

如: 点击网页上的一个超链接

由服务器来发起的,浏览器使用者无法控制的跳转

HTTP 协议里叫做"重定向"(Redirection)

请求返回状态码 302/301

响应头里面标记了"Location: URI"

站内重定向地址栏的地址不会发生显式变化,但是浏览器会隐式的去请求并把结果显示在浏览器中

站外重定向

301

302

303

307

308

资源不可用,需要用另一个新的 URI 来代替

避免重复

在决定要用重定向后一定要考虑是用 301 还是 302

性能损耗

循环跳转

用于服务器给浏览器发送身份标识

可以多行

用于身份甄别

多个字段使用";"分隔

设置 Cookie 的生存周期

设置 Cookie 的作用域

Cookie 的安全性

chrome -> F12 -> Network -> Cookies

保存用户登录信息,实现回话事务

状态保持

广告网站会给你贴上 Cookie 标签,(这里的 Cookie 标签是第三方 Cookie,就是广告商的 Cookie)这样,上其它网站,别的广告就能用 Cookie 读到你得身份,然后进行行为分析,再精确的给你推广告

如果广告商势力比较大,这样你走到哪里广告都会精准推送

为了防止 Cookie 搜集用户隐私,互联网组织提出 DNT(Do Not Track) 和 P3P(platform for Privacy Preferences Project) 但是作用不大

1、浏览器发现缓存无数据,发送请求,向服务器获取资源

2、服务器响应请求,返回资源,同时标记资源的有效期

3、浏览器缓存资源,等待下次重用

Cache-Control: max-age=31536000

no-store

no-cache

must-revalidate

意思是请求一个最新资源

这个头字段只支持 HTTP/1.0

windows：Ctrl+F5

Mac：cmd+shift+r

其实就是发送了一个“Cache-Control:no-cache”

如果验证资源是否失效，发送多个验证比较消耗资源

这个在head里增加“条件请求”字段，专门用来验证资源是否过期，把多个请求合并成一个，降低资源消耗

请求头

响应头

欺上瞒下

即可以保护客户端，又可以保护服务端

负载均衡

健康检查

安全防护

加密卸载

数据过滤

内容缓存

通用字段

标明代理身份

只是解决了客户端和源服务器判断是否存在代理的问题，不能知道对方的真实信息

如果有多个代理服务器，那么请求经过多少个代理服务器，Via 字段后面会追加多少个代理标识

有时候响应头里会使用“X-Via”，意义和 Via 相同

不属于 HTTP 标准，但是属于“事实标准”

意思是为谁转发

添加的是请求方的 IP 地址，最左边的 IP 就是源请求方的 IP 地址

另一种获取客户端真是 IP 的手段

作用：只记录客户端的 IP 地址，没有中间的代理信息

因为 X-Forwarded-For 等头字段需要修改原始报文，在有些情况下是不允许甚至不可能被修改的，比如使用了 HTTPS 通信被加密

所以出现了专门的“代理协议”

属于“事实协议”

HAProxy 所定义

V2 是二进制格式

V1 是明文，只是在 HTTP 报文前增加了一行 ASCII 码文本，相当于又多了一个头

格式

例子

private

public

must-revalidate

proxy-revalidate

s-maxage

no-transform

例子：Last-modified: max-age=30,proxy-revalidate,no-transform

max-stale

min-fresh

内容协商的结果

报文版本标记

同一个请求，经过内容协商后可能会有不同的字符集、编码、浏览器等版本

当收到同一个请求，代理就读取缓存里的 Vary，对比请求头里的所有字段

当用了 Vary，要求当前请求和上一个请求得完全匹配，包括压缩，user-agent，Accept-Encoding 等都得一致

缓存清理

对代理非常重要

功能

作法：使用自定义请求方法“PURGE”，发送给代理服务器，要求删除 URI 对应的缓存数据

对数据的“保密”

只能由可信的人访问，对其他人是不可见的

也叫一致性

指在传输过程中没有被篡改，“完完整整”的保持着原样

确认对方的真是身份

保证消息只能发送给可信的人

也叫不可抵赖

不能否认已经发生过的行为

收到了就是收到了，没收到就是没收到

防止耍赖皮

1.1 2006 年发布

1.2 2008 年发布

1.3 2018 年发布

记录协议

握手协议

警告协议

变更密码规范协议

扩展协议等几个自协议组成

秘钥交换算法+签名算法+对称加密算法+摘要算法

ECDHE-RSA-AES256-GCM-SHA384

握手时使用 ECDHE 算法进行秘钥交换，用 RSA 签名和身份认证，握手后的通信用 AES 对称算法，秘钥长度 256，分组模式是 GCM，摘要算法 SHA384 用于消息认证和产生随机数

1.02

1.1.0

1.1.1

RC4

DES

3DES

AES

ChaCha20

ECB

CBC

CFB

OFB

AEAD

GCM

CCM

Poly1305

DH

DSA

RSA

ECC

非对称加密解决密钥交换问题（这里交换的是对称加密密钥）

然后用随机数产生对称算法使用的“会话密钥”（session key）再用公钥加密

对方拿到密钥后用私钥解密，取出会话密钥，双方实现了对称密钥的安全交换

之后不再使用非对称加密

MD5

SHA-1

SHA224

SHA256

SHA384

私钥通过对 SHA-2 加密

拿到文件之后通过公钥解密，拿到 SHA-2 之后和原文的 SHA-2 对比

专业术语叫“签名”和“验签”

客户端用自己的私钥签名一个消息

网站收到后用客户端的公钥验签

确认身份之后，用服务端的私钥签名一个消息

客户端收到后用服务端的公钥进行验签

之后就可以用混合加密进行安全通信了

（Certificate Authority 证书认证机构） 用自身信誉来保证公钥无法伪造，必须是具有极高可信度的

CA 对公钥签名认证是有格式的

包含了序列号、用途、颁发者、有效时间等，打包再签名形成了“数字证书”

证书办法机构

证书类型

CA 如何证明自己

证书的验证

CA 被欺骗或者失误，造成错发证书

CA 被黑客攻陷

CA 有恶意

解决办法

规定了 TLS 收发数据的基本单位，记录（record）

类似于 TCP 的 segment

向对方发出警报信息

像 HTTP 协议里的状态码

例子

收到报警后另一方可以选择继续，也可以终止连接

TLS 里最复杂的子协议

比 TCP 的 SYN/ACK 复杂

浏览器和服务器需要通过握手协商 TLS 版本，随机数，密码套件等信息

然后交换证书和密钥参数，最终双方协商得到会话密钥

通知对方，后续数据都将使用加密保护

在它之前，所有数据都是明文的

用于生成后续会话密钥

Handshake Protocol: Client Hello 
    Version: TLS 1.2 (0x0303) 
    Random: 1cbf803321fd2623408dfe… 
    Cipher Suites (17 suites) 
        Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f) 
        Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)

密码套件：TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

作用就是对一下版本号和选一个密码套件，然后给一个随机数，用于加密解密

Handshake Protocol: Server Hello
    Version: TLS 1.2 (0x0303)
    Random: 0e6320f21bae50842e96…
    Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)

证明自己的身份

实现密钥交换算法，再加上自己的私钥签名认证

这里使用椭圆曲线生成公钥是因为这里的前面交换的信息中使用的密码套件是 ECDHE 的他用的是椭圆曲线生成公钥

Handshake Protocol: Server Key Exchange
    EC Diffie-Hellman Server Params
        Curve Type: named_curve (0x03)
        Named Curve: x25519 (0x001d)
        Pubkey: 3b39deaf00217894e...
        Signature Algorithm: rsa_pkcs1_sha512 (0x0601)
        Signature: 37141adac38ea4...

这里，客户端拿到了 Client Random，Server Random 和 Server Params，还有服务器的证书

Server Params 是服务器的公钥

确认服务器身份

这里的证书是加密了公钥的

交换密钥算法参数

服务器拿到了客户端的公钥

Handshake Protocol: Client Key Exchange
    EC Diffie-Hellman Client Params
        Pubkey: 8c674d0e08dc27b5eaa…

计算出主密钥 Master Secret

主密钥不是会话密钥

还会再用 PRF 扩展出更多的密钥，比如客户端发送用的会话密钥（client_write_key）、服务器发送用的会话密钥（server_write_key）

PRF 基于密码套件里的最后一个参数进强化

master_secret = PRF(pre_master_secret, "master secret",
                    ClientHello.random + ServerHello.random)

为什么非要三个随机数

随机数 C，客户端的 TLS 版本号，密码套件列表，扩展列表

随机数 S，确认 TLS 版本号和使用的密码套件（RSA）

服务器使用的证书

服务器 Hello 完成

通过证书链

服务端 RSA 公钥加密 Pre-Master

这里的 Pre-Master 是一个客户端生成的随机数，没有用算法生成

密钥交换

这里的 “随机数c/s” 的意思是 client 随机数和 server 随机数

告诉服务器，之后改用会话密钥加密通信

发送所有握手数据的摘要，让 server 端校验

告诉 client，之后所有会话机密通信

所有握手数据的摘要，让客户端校验

只是在“Server Hello Done” 之后 “Client Key Exchange”之前，客户端要发送 “Client Certificate”消息

服务器收到后也把证书链走一遍，验证客户端的身份

0x303

0x304

因为 TLS1.1，1.2 协议出现了很多年，很多的软件，中间代理等只认老的记录协议格式

更新改造很困难，

一旦变更了记录头字段里的版本号，大量的代理服务器，网关都将无法正常处理，TLS 握手失败

为了老设备能够继续使用，避免新协议带来的冲击

扩展协议（Extension Protocol）

握手 Hello 消息后面添加 supported_versions

如果服务器不支持 1.3，那就“向后兼容”降级成为 1.2

supported_groups

key_share

signature_algorithms

server_name

例子

废除原因，不具有“前向安全”

每次握手时都会生成一对临时公钥和私钥，即“一次一密”

每次通信的密钥对都是不同的

TLS1.3 只有 5 个套件

Client Hello 消息里用 “supported_groups”带上支持的曲线

“key_share”带上曲线对应的客户端公钥参数

用“signature_algorithms”带上签名算法

服务器收到后再扩展里选定一个曲线和参数，再用“key_share”扩展返回服务器公钥参数，实现了双方密钥交换

用 pre_shared_key 和 early_data 扩展

随机数 C、密码套件、密钥交换算法参数（key_share）

Handshake Protocol: Client Hello
    Version: TLS 1.2 (0x0303)
    Random: cebeb6c05403654d66c2329…
    Cipher Suites (18 suites)
        Cipher Suite: TLS_AES_128_GCM_SHA256 (0x1301)
        Cipher Suite: TLS_CHACHA20_POLY1305_SHA256 (0x1303)
        Cipher Suite: TLS_AES_256_GCM_SHA384 (0x1302)
    Extension: supported_versions (len=9)
        Supported Version: TLS 1.3 (0x0304)
        Supported Version: TLS 1.2 (0x0303)
    Extension: supported_groups (len=14)
        Supported Groups (6 groups)
            Supported Group: x25519 (0x001d)
            Supported Group: secp256r1 (0x0017)
    Extension: key_share (len=107)
        Key Share extension
            Client Key Share Length: 105
            Key Share Entry: Group: x25519
            Key Share Entry: Group: secp256r1

supported_versions

supported_groups

key_share

随机数 S、确认密码套件、交换算法参数（key_share）

Handshake Protocol: Server Hello
    Version: TLS 1.2 (0x0303)
    Random: 12d2bce6568b063d3dee2…
    Cipher Suite: TLS_AES_128_GCM_SHA256 (0x1301)
    Extension: supported_versions (len=2)
        Supported Version: TLS 1.3 (0x0304)
    Extension: key_share (len=36)
        Key Share extension
            Key Share Entry: Group: x25519, Key Exchange length: 32

supported_versions

key_share

Client Random

Server Random

Client Params

Server Params

告诉Client，之后都用会话密钥加密通信

比 TLS1.2 提早进入加密通信，后面的证书等都是加密的，减少握手时明文信息泄漏

被加密的扩展信息

服务器使用的证书

使用证书签名握手数据

用服务器私钥把前面的曲线、套件、参数等握手数据加了签名，作用和“Finished”差不多

由于是私钥签名，强化了身份认证和防篡改

所有握手数据的摘要

ECDHE 生成用于密钥交换的临时公钥对

验证证书时访问 CA 获取 CRL 或者 OCSP

非对称加密解密处理“Pre-Master”等

所以，网卡，带宽，SSD 存储没有优化作用

加解密时调用它的 API

让专门的硬件来做非对称加解密，分担 CPU 的计算压力

缺点：升级慢、支持算法有限

专门的服务器集群来“卸载”TLS 握手时的加解密计算

将软件尽量升级到最新版本

只能用 1.2时，握手时使用的密钥交换协议尽量用椭圆曲线的 ECHDE 算法

使用椭圆曲线选择高性能曲线，最好是 x25519，次优选择P-256

AES_128_GCM

ssl_ciphers   TLS13-AES-256-GCM-SHA384:TLS13-CHACHA20-POLY1305-SHA256:EECDH+CHACHA20；
ssl_ecdh_curve              X25519:P-256;

证书传输

证书验证

224 位的 ECC 相当于 2048 位的 RSA，所以椭圆曲线证书比 RSA 证书小很多

能够节省宽带

由 CA 定期发布

所有被撤销信任的证书序列号

只查这个列表就可以知道证书是否有效

不太常用

被 OCSP 替代

让服务器预先访问 CA 获取 OCSP 响应，然后在握手时随证书一期发送给客户端，免去了客户端连接 CA 服务器查询的时间

和 HTTP Cache 一样

Server 和 Client 首次连接之后各自保存一个会话 ID

内存里存储主密钥和其他相关信息

当 Client 再次连接时发 ID 过来，服务器直接在内存找，找到了直接用主密钥恢复会话状态，跳过证书验证和密钥交换

只用一个消息往返就可以建立安全通信

服务器得保存每一个客户端的会话数据，客户端太多对服务器是一种压力，百万级，千万级用户存储量会成问题

客户端使用扩展“session_ticket”发送“Ticket”，服务器解密后验证有效期，然后开始会话，开始加密通信

DigiCert

GlobalSign

Let’s Encrypt

应当同时申请 RSA 和 ECDSA 两种证书，Nginx 配置双证书验证

RSA 证书私钥至少要 2048 位，摘要算法应该选 SHA-2

在 listen 指令后面加上参数 ssl，再配上证书文件

为了提高 HTTPS 的安全系数和性能，还可以强制 Nginx 只支持 TLS1.2 以上协议，打开“Session Ticket”会话复用

密码套件以服务器套件优先，避免客户端选择较弱套件，密码套件看齐 TLS1.3，只使用 ECDHE、AES 和 ChaCha20，支持“False Start”

如果服务器使用了 OpenSSL 分支 BorringSSL，使用特殊“等价密码组”

如果客户端没有 AES 优化，服务器会优先选择与 AES“等价”的 ChaCha20，让客户端能快一点

多个域名可以在同一个 IP 地址上运行

Web 服务器会使用请求头里的 Host 字段来选择

作用和 Host 字段差不多

客户端会在 Client Hello 时带上域名信息，也是在 Nginx 配置

重定向增加网络成本

安全隐患：重定向响应被中间人篡改，实现“会话劫持”

告诉服务器，这个网站，必须严格使用 HTTPS 协议，半年内不允许用 HTTP

如请求方法

URI

状态码

头字段等概念不变

在客户端和服务器两端建立“字典”

用索引号表示重复字符串，还用哈夫曼编码来压缩整数和字符串，压缩率可达 50%~90%

这样做效率提高，方便计算机解析

把原来的“Header+Body”打散为二进制“帧”（Frame）

“HEADERS”帧存放头数据

“DATA”帧存放实体数据

同一个消息往返的帧会分配一个唯一的流 ID

“流”是虚拟的，在 HTTP/2 可以在一个 TCP 连接上用“流”同时发送多个“碎片化”消息，

多个往返通信都复用一个连接来处理

TCP 层面还是有序的

多个请求 / 响应之间没有顺序，不需要排队

不会出现“队头阻塞”，降低了延迟，提高了连接的利用率

如 浏览器要请求 HTML 的时候，提前把会用到的 JS、CSS 文件发送给客户端，减少等待的延迟

加密

明文

将起始行里的请求方法、URI、状态码等统一转换成头字段形式

"伪头字段"会在名字前加一个“:”

:authority

:method

:status

将常用的头字段定义了一张只读表

客户端和服务端通过查静态表就可以通过 Index 查到具体的请求方法等

比如 2 代表 GET，8 代表状态码 200

添加在静态表后面，结构相同

采用哈夫曼压缩编码发送，客户端和服务器都得更新自己的动态表

最终只会两边的字典越来越大，但是发送的头部字段小很多，只有一两个字节的代码

长度

帧类型

帧标志

流标识符

流是可并发的，一个 HTTP/2 连接可以同时多个流传输数据，实现“多路复用”

客户端和服务端都可以创建流，互不干扰

流是双向的，一个流里客户端，服务端都可以发送或接收数据帧

流之间没有固定关系，彼此独立，流内部的帧有严格顺序

流可以设置优先级，让服务器优先处理

流 ID 不能重复，只能顺序底层

客户端发起的 ID 是奇数，服务器发起的 ID 是偶数

在流上发送“RST_STEAM”帧可以随时终止流，取消接收或发送

第 0 号流比较特殊，既不能关闭，也不能发送数据帧，只能发送控制帧

最开始流都是“空闲”（idle）状态

client->server 发送 HEADERS帧

client->server 发送请求

client->server 发送 END_STREAM 帧

server -> client 发送数据

server -> client 发送 END_STREAM 帧

两端都进入关闭状态，流结束

流程图

“丢包重传”机制

当 TCP 发出 N 个段，有其中一个段没有收到回复，那么，其它的回复都会在TCP 协议栈中暂存，等那个没有收到回复的重发，然后收到回复再一起发送到上层

TCP 在这里会把 http 中的包拆分成更小的包，这里叫段 segment

例子：
TCP 发送了1，2，3 个包，服务端收到了 2，3 两个包并做出回应，
TCP 把 2，3 两个包的回复数据暂存在缓冲区，重发 1 包的数据，等收到 1 包的回复数据再把整体发送给上层

这种队头阻塞是 TCP 固有的

QUIC 最早是由 Google 发明，被称为 gQUIC

目前由 IETF 标准化的 QUIC 被称为 iQUIC，两者差异非常大

基于 UDP，无需“握手”和“挥手”，比 TCP 快

引入了类似 HTTP/2 的“流”和“多路复用”，单个“流”是有序的，可能会因为丢包而阻塞，但其他“流”不会受到影响

采用加密通信，抵御篡改和“协议僵化”，防止网络中间设备识别协议细节

使用了 TLS1.3，获得了 0-RTT、1-RTT 连接的好处

并不是建立在 TLS 之上，是内部“包含”了 TLS，使用自己的帧“接管”了 TLS里的“记录”，握手消息、警报消息都不使用 TLS 记录，是封装成 QUIC 的帧发送，节省了一次开销

详细的看 https://quicwg.org/

QUIC 和 TLS 是相互协作的关系

基本数据传输单位是包（packet）和帧（frame）
一个包由多个帧组成，包面向的是“连接”，帧面向的是“流”

QUIC使用“连接 ID”来标记通信的两个端点，这个连接 ID 是在握手阶段生成的

连接 ID 代替了 TCP 中的“IP 地址+端口”，支持连接转移

连接转移：比如，你在家里用的 WIFI，突然断网了，转换成 4/5G手机流量了，IP 发生了变化，