HTTP 常用的请求头
accept-encoding / accept-languate
user-agent: 客户端信息
cache-control 强缓存
connection:keep-alive 保持持久连接
content-type: application/json 请求返回格式
Referer:
https://juejin.cn/
- Referer 请求头包含了当前请求页面的来源页面的地址,即表示当前页面是通过此来源页面里的链接进入的。
- 服务端一般使用
Referer
请求头识别访问来源,可能会以此进行统计分析、日志记录以及缓存优化等。 - 空 Referer:
- referer 它作用是指示一个请求是从哪里链接过来,那么当一个请求并不是由链接触发产生的,那么自然也就不需要指定这个请求的链接来源, 比如浏览器输入 URL 地址,这种请求不包含 referer 字段
- Referer 作用:1. 防盗链 2. 防止恶意请求
origin:
https://juejin.cn
- 请求首部字段
Origin
指示了请求来自于哪个站点。该字段仅指示服务器名称,并不包含任何路径信息。 Origin: https://developer.mozilla.org
- scheme 请求协议 host: 服务器域名或 IP 地址 port 服务器正在监听的 TCP 端口号 可选
- 请求首部字段
Cookie
Access-Control-Request-Method
出现于 preflight request (预检请求)中,用于通知服务器在真正的请求中会采用哪种 HTTP 方法。因为预检请求所使用的方法总是
OPTIONS
,与实际请求所使用的方法不一样,所以这个请求头是必要的Access-Control-Request-Method: POST
Cookie 的属性
- Name、Value
- Cookie 的名称和值,Name 和 Value 是一个键值对。
- Cookie 一旦创建,名称便不可更改。
- Domain
- Cookie 的有效域
- 决定 Cookie 在哪个域是有效的,也就是决定在向该域发送请求时是否携带此 Cookie。
- Path
- Cookie 的有效路径
- Expires/Max-Age
- Cookie 的有效期
- Size
- Cookie 的大小
- HttpOnly
- 值为 true 或 false,设置为 true。则不允许通过 document.cookie 获取和更改这个值,不可见。但发送请求时依旧会携带此 Cookie
- Secure
- Cookie 的安全属性,若为 true。浏览器只会在 HTTPS 和 SSL 等安全协议中传输此 Cookie,不会在 http 协议中传输。
- SameSite
- 用来限制第三方 Cookie,从而减少安全风险。
- Strict: 完全禁止第三方 Cookie,跨站点时,任何情况下都不会发送 Cookie
- 浏览器将只发送相同站点请求的 Cookie,即当前网页 URL 与请求目标 URL 完全一致。
- Lax: 允许部分第三方请求携带 Cookie
- None:
- 无论是否跨站都会发送 Cookie, HTTP 接口不支持 SameSite=none,
- 网站可以选择显式关闭 SameSite 属性,将其设为 None. 前提是必须同时设置 Secure 属性,只在 https 协议下该 cookie 才会被发送。
- SameParty
- Priority
https://juejin.cn/post/6844904095711494151#heading-14
HTTP 响应状态码
1xx
- 101 Switching Protocols
- 它的意思是客户端使用 Upgrade 头字段,要求在 HTTP 协议的基础上改成其他的协议继续通信,比如 WebSocket。而如果服务器也同意变更协议,就会发送状态码 101,但这之后的数据传输就不会再使用 HTTP 了。
2xx
204 No Content
- 另一个很常见的成功状态码,它的含义与“200 OK”基本相同,但响应头后没有 body 数据。
206 Partial Content
是 HTTP 分块下载或断点续传的基础,部分内容。它与 200 一样,也是服务器成功处理了请求,但 body 里的数据不是资源的全部,而是其中的一部分。
206 通常会伴随头字段 Content-Range :表示响应报文里 body 数据的具体范围,供客户端确认,例如“Content-Range: bytes 0-99/2000”,意思是此次获取的是总计 2000 个字节的前 100 个字节。
3xx
- 301 Moved Permanently
- 永久重定向,含义是此次请求的资源已经不存在了,需要改用新的 URI 再次访问
- 308 永久重定向,但不允许更改请求方法
- 302 Found Moved Temporarily
- 临时重定向,意思是请求的资源还在,但需要暂时用另一个 URI 来访问。
- 301,302 都会在响应头使用字段 Location 指明后续要跳转的 URI,最终效果很相似,浏览器都会重定向到新的 URI
- 303,307 也是临时重定向
- 303 重定向到新地址时,客户端必须使用 GET 方法
- 307 不允许修改浏览器请求方法
- 304 Not Modified
- 它用于 If-Modified-Since、If-None-Match 等条件请求,表示资源未修改,用于缓存控制。
- 它不具有通常的跳转含义,但可以理解为“重定向到已缓存的文件”(即:缓存重定向)。
4xx
- 403 Forbidden
- 实际上不是客户端请求出错,而是表示服务器禁止访问资源。
- 404 Not Found
- 它的原意是资源在本服务器上未找到,所以无法提供给客户端。
- 但现在已经被“用滥了”,只要服务器“不高兴”就可以给出个 404
- 4xx 剩下等等
- 其他一些 404 较明确地说明了错误原因,都很好理解
- 405 Method Not Allowed:不允许使用某些方法操作资源,例如不允许 POST 只能 GET;
- 406 Not Acceptable:资源无法满足客户端请求的条件,例如请求中文但只有英文
- 408 Request Timeout:请求超时,服务器等待了过长的时间
- 429 Too Many Requests:客户端发送了太多的请求,通常是由于服务器的限连策略;
5xx
5xx 表示客户端请求报文正确,但服务器处理时内部发生了错误,无法返回应有的响应数据,是服务端的错误码。
- 501 Not Implemented
- 表示客户端请求的功能还不支持,这个错误码比 500 要“温和”一些,和“即将开业, 敬请期待”的意思差不多,不过具体什么时候“开业”就不好说了。
- 502 Bad Gateway
- 通常是服务器作为网关或者代理时返回的错误码,表示服务器自身工作正常,访问后端服务器时发生了错误,但具体的错误原因也是不知道的
- 503 Service Unavailable
- 表示服务器当前很忙,暂时无法响应服务,我们上网时有时候遇到的“网络服务正忙,请稍后重试”的提示信息就是状态 503
- 503 是一个“临时”的状态,很可能过几秒钟后服务器就不那么忙了,可以继续提供服务,所以 503 响应报文里通常还会有一个“Retry-After”字段,指示客户端可以在多久以后再次尝试发送请求。
HTTP HTTPS 区别
- HTTP 是
明文传输
,不安全的,HTTPS 是加密传输
,更加安全。 - HTTP 默认端口
80
, HTTPS 默认端口443
,HTTPS 浏览器上会显示安全锁。 - HTTP 不用认证证书 ,HTTPS 需要认证证书
- HTTP 是连接简单,无状态的,HTTPS = HTTP + SSL/ TLS
- HTTP + SSL/TLS = HTTPS
HTTP 可能存在的四大类安全问题
- Interception:拦截
- Spoofing:伪装
- Falsification:篡改
- Repudiation:否认
引入 SSL/TLS 协议,它使得上面四大问题中,和传输本身密切相关的前三大问题都可 以得到解决(第四个问题还需要引入数字签名来解决)
- SSL 指的是 Secure Socket Layer,
- TLS 指的是 Transport Layer Security, 其实就是标准化后的 SSL
对称加密和非对称加密
对称性加密(Symmetric Cryptography):指的是加密和解密使用相同的密钥。这种方式相对简单,加密解密速度快,但是由于加密和解密需要使用相同的密钥,如何安全地传递密钥,往往成为一个难题。
非对称性加密(Asymmetric Cryptography):指的是数据加密和解密需要使用不同的密钥。
- RSA
- ECC
- DH
- ECDHE
通常一个被称为公钥(Public Key),另一个被称为私钥(Private Key),二者一般同时生成,但是==公钥往往可以公开和传播,而私钥不能。经过公钥加密的数据,需要用私钥才能解密==;反之亦然。这种方法较为复杂,且性能较差,好处就是由于加密和解密的密钥具有相对独立性,公钥可以放心地传播出去,不用担心安全性问题。
原始数据 + 公钥 -> 加密数据
加密数据 + 私钥 -> 原始数据
TLS 连接建立原理

客户端产生随机数 A, 并携带支持的加密方法列表
服务端携带产生的随机数 B,和选定的加密方法组合(Cipher Suite)
服务端紧跟着发送包含公钥的证书
客户端验证证书的有效性,生成随机数 C; A+B+C 可以生成新的密钥 X (Master Secret), 而 X 可继续生成真正用于后续数据加密和解密的对称密钥。因为它是在本次 TLS 会话中生成的,也被成为会话密钥(Session Secret)
- 客户端随机数 A + 服务端随机数 B + 客户端 Pre-master Secret C --> 会话密钥
- 注意,Pre-master Secret 生成方法是不固定的,根据加密具体算法不同而不同
- 上述是传统 RSA 方式,Pre-master Secret 由客户端独立生成,加密后再通过 Client Key Exchange 发回服务端
- 还有一种是 ECDHE 方式,这种方式下无论在客户端还是服务端,Pre-master Secret 需要通过 Client Key Exchange 和 Server Key Exchange 两者承载的参数联合生成
接着客户端告诉服务端
- Client Key Exchange,本质上它就是上面说的这个 C,但使用了服务端通过证书发来的公钥加密;
- Change Cipher Spec,客户端同意正式启用约好的加密方法和密钥了,后面的数据传输全部都使用密钥 X 来加密;
- Encrypted Handshake Message,快速验证:这是客户端对于整个对话进行摘要并加密得到的串,如果经过服务端解密,和原串相等,就证明整个握手过程是成功的。
服务端收到消息后,用自己私钥解密上面的 Client Key Exchange,得到了 C;
- 这样它和客户端一样,也得到了 A、B 和 C,继而到 X,以及最终的会话密钥。
客户端和服务端都得到了能够加密解密传输数据的对称密钥——会话密钥
- ==TLS 是通过非对称加密技术来保证握手过程中的可靠性(公钥加密,私钥解密)==
- ==再通过对称加密技术来保证数据传输过程中的可靠性的==
证书有效验证的原理
证书中包含版本、发布机构、有效期、数字签名等基本内容,以及一个公钥。实际上,这两个服务端传回来的证书,和浏览器内置的根证书联合起来,组成了一个单向、完整的证书链:

上图中的第三行,就是携带着服务器公钥的证书,它是从证书发布机构(CA, Certificate Authority)申请得来的,也就是图中第二行的 GTS CA 1O1。证书在申请的时候,我们提到的服务器公钥就已经是该证书的一部分了,因此我们才说,如果证书是有效的,那么它携带的公钥就是有效的。
在当时申请的时候,证书发布机构对证书做摘要生成指纹,并使用它自己的私钥为该指纹加密,生成数字签名(Digital Signature),而这个数字签名也随证书一起发布。这个发布机构的私钥是它内部自己管理的,不会外泄。
指纹 + 私钥 --> 数字签名
验证过程则正好是发布过程的反向,即在客户端要对这个被检测证书做两件事:
- 对它用指定算法进行摘要,得到指纹 P1;
- 使用证书发布机构的公钥对它的数字签名进行解密,得到指纹 P2
数字签名 + 公钥 --> 指纹
如果 P1 和 P2 一致,就说明证书未被篡改过,也说明这个服务端发来的证书是真实有效的,而不是仿冒的。
问题来了,证书发布机构使用非对称性加密和数字签名保证了证书的有效性,那么谁来保证证书发布机构的有效性? 答案就是它的上一级证书发布机构。
CA 是分级管理的,每一级 CA 都根据上述同样的原理,由它的上一级 CA 来加密证书和生成数字签名,来保证其真实性,从而形成一个单向的信任链。同时,标志着最高级别 CA 的根证书数量非常少,且一般在浏览器或操作系统安装的时候就被预置在里面了,因此它们是被我们完全信任的,这就使得真实性的鉴别递归有了最终出口。
也就是说,递归自下而上验证的过程,如果一直正确,直至抵达了顶端——浏览器内置的根证书,就说明服务端送过来的证书是安全有效的。
主要从 HTTPS 解决了什么问题出发分点描述
https://juejin.cn/post/6844903912932147207
了解证书颁发的流程吗
OpenSSL 实现 RSA
openssl 有多种形式的密钥,openssl 提供 PEM 和 DER 两种编码方式对这些密钥进行编码,并提供相关指令可以使用户在这两种格式之间进行转换。
DER
DER 是一种二进制编码方式,本身可以表示任何类型的数据,但通常用来编码证书。
PEM
PEM 是一种将二进制数据编码为字符串的方法。
Base64 格式
pem 可以存储公钥、私钥、证书、完整的证书链;
PEM 是明文格式,可以包含证书或者是密钥;其内容通常是以类似 “—–BEGIN …—–” 开头 “—–END …—–” 为结尾的这样的格式进行描述的。 因为 DER 是纯二进制格式,对人不友好,所以一般都用 PEM 进行存储。
-----BEGIN <whatever>-----
data
-----END <whatever>----
whatever 可以是 private keys, public keys, X509 certificates,比如
-----BEGIN CERTIFICATE-----
... base 64 encoding of the DER encoded certificate
with line endings and padding with equals signs ...
-----END CERTIFICATE-----
-----BEGIN PRIVATE KEY-----
base 64 encoding of the private key
-----END PRIVATE KEY-----
CER
.cer 指的是证书 certificate,通常是 DER 编码格式的,但是 windows 也可以接受 PEM 格式
ECDHE
ECC : Elliptic Curve Cryptography 椭圆曲线密码学 (加密算法)
Ephemeral ECDH
- ECDHE, E 代表 Ephemeral,指的是交换的 keys 是 temporary,临时的,动态的。
- The "E" in ECDHE stands for "Ephemeral" and refers to the fact that the keys exchanged are temporary, rather than static.
- 全称 Ephemeral Elliptic Curve Diffie–Hellman;短暂-椭圆曲线-迪菲-赫尔曼 算法。
ECDHE 算法是一种非对称加密算法,数学基础是“离散对数”
- https 原理--ECDHE 密钥协商算法https://www.cnblogs.com/zipxzf/articles/14346467.html
- Cipher Suites https://ciphersuite.info/cs/?security=all&software=openssl&singlepage=true
- https://www.laoqingcai.com/tls1.2-clienthello/
TLS 四次握手过程
Client Hello
Server Hello
Client Key Exchange and Change Cipher Spec , Finished
Change Cipher Spec , Finished
使用 RSA 非对称加密时

RSA 可以通过认证(如使用 X.509数字证书)来防止中间人攻击
使用 ECDHE 算法

- **客户端问候:**客户端发送客户端问候消息,内含协议版本、客户端随机数和密码套件列表。
- **服务器问候:**服务器以其 SSL 证书、其选定的密码套件和服务器随机数回复。与上述 RSA 握手相比,服务器在此消息中还包括以下内容(步骤 3):
- **服务器的数字签名:**服务器使用其私钥对客户端随机数、服务器随机数及其 DH 参数* 进行加密。加密后的数据用作服务器的数字签名,从而确定服务器具有与 SSL 证书中的公钥相匹配的私钥。
- **确认数字签名:**客户端使用公钥解密服务器的数字签名,验证服务器控制私钥并且是其声称的身份。客户端 DH 参数:客户端将其 DH 参数发送到服务器。
- **客户端和服务器计算预主密钥:**客户端和服务器使用交换的 DH 参数分别计算匹配的预主密钥,而不像 RSA 握手那样由客户端生成预主密钥并将其发送到服务器。
- **创建会话密钥:**与 RSA 握手中一样,客户端和服务器现在从预主密钥、客户端随机数和服务器随机数计算会话密钥。
- **客户端就绪:**与 RSA 握手相同。
- 服务器就绪
- 实现安全对称加密
参考
- HTTPS 让数据传输更安全 From Geek Time
- https://blog.cloudflare.com/keyless-ssl-the-nitty-gritty-technical-details/
- https://www.laoqingcai.com/tls1.2-premasterkey/
- cloudflare-TLS
- https://levelup.gitconnected.com/deep-dive-into-tls-handshake-e029e28e2eb3
- TLS, Pre-Master Secrets and Master Secrets
- 阮一峰-图解 SSL/TLS 协议
- https://zhuanlan.zhihu.com/p/43789231