GET请求
-
通过URL传递参数：GET请求将请求参数包含在URL中，具体来说，是放在URL的查询字符串部分。查询字符串以
?开始，后面跟着一个或多个键值对，每个键值对之间用&分隔。例如： -
GET /search?query=python&sort=desc HTTP/1.1 Host: www.example.com这里的参数
query=python和sort=desc就是通过URL传递的。 -
常用于读取数据：GET请求通常用于请求数据，而不会对服务器上的数据产生副作用（如修改数据）。
-
有长度限制：由于参数包含在URL中，GET请求的URL长度是有限的（通常在2048字符以内，这取决于具体的浏览器和服务器实现）。
POST请求
POST /submit HTTP/1.1
Host: www.example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 27
username=user&password=pass
-
在这个例子中，参数
username=user和password=pass是通过请求体传递的。 -
常用于发送数据：POST请求通常用于向服务器发送数据，例如表单提交、文件上传等，这些操作通常会改变服务器上的数据。
-
没有长度限制：POST请求的请求体可以包含任意大小的数据（理论上受限于服务器配置和浏览器实现），因此它没有像GET请求那样的长度限制。
客户端缓存机制：
1.强制缓存：头部仅有Cache-control（相对时间）、expires（绝对时间）
浏览器会对比缓存时间决定。
2.协商缓存：
每一次客户端都要发送请求给服务端，询问是否读取缓存里的内容。
etag：客户端发出请求携带if-none-match即为第一次服务返回资源携带的etag值，发送给服务端，服务端对比if-none-match与新的etag值，如果一致，返回304；不一致返回200（并携带新的资源）。
last-modified：客户端发出请求携带if-modified-since即为第一次服务返回资源携带的last-modified值发送给服务端，服务端对比if-modified-since与新的last-modified值，如果一致，返回304；不一致返回200（并携带新的资源）。
两者同时存在，强制缓存的优先级更高。
Http传输会有三个风险
1.窃听风险--混合加密算法（对称+非对称）
（1）对称：明文--会话密钥--密文--会话密钥--明文
（2）非对称：公钥加密可用私钥解密，反之亦然；且公钥和私钥在请求时服务端是都知道的
2.篡改风险--数字签名
3.冒充风险--数字证书
1.请求公钥
2.响应公钥
3.用非对称公钥将对称加密的密钥加密，传输到服务端，用服务端本就有的私钥解密
4.用对称算法密钥加密信息传输，服务端解密，拿到请求信息
5.用对称加密算法加密内容，传输到客户端，客户端解密。
以上解决了坏路由器窃听到私钥，使其无法解密公钥，保护了信息
请求公钥的一端会有公钥，另一端有公钥和私钥
1.hash形成签名（摘要）和信息一起加密传输；
2.到另一端解密信息并利用hash生成签名（摘要），再与解密的签名（摘要）对比。
冒充：
使用数字证书和 HTTPS 协议可以有效防止中间人攻击。在你描述的情况下，以下是详细的流程和防御机制：
场景描述
- A：客户端，用户想要传递信息到服务器。
- B：服务器，接收和处理用户的信息。
- M：中间人，试图拦截和篡改客户端和服务器之间的通信。
数字证书和 HTTPS 工作机制
-
客户端 A 访问服务器 B：
- A 客户端尝试与 B 服务器建立 HTTPS 连接。
-
服务器 B 发送数字证书：
- 服务器 B 发送自己的数字证书给客户端 A。这个数字证书由受信任的证书颁发机构（CA）签发，包含服务器的公钥和域名等信息。
-
客户端 A 验证数字证书：
- 客户端 A 验证数字证书的真实性：
- 检查证书是否由受信任的 CA 签发。
- 检查证书是否在有效期内。
- 检查证书上的域名是否与客户端试图访问的域名匹配。
- 如果所有验证通过，客户端 A 确信自己正在与真实的服务器 B 通信。
- 客户端 A 验证数字证书的真实性：
中间人 M 试图进行攻击
-
中间人 M 拦截初始连接请求：
- M 拦截客户端 A 发往服务器 B 的连接请求。
- M 伪装成服务器 B，向客户端 A 发送自己的数字证书。
-
客户端 A 验证中间人 M 的数字证书：
- 客户端 A 会检查 M 提供的数字证书。
- 客户端 A 会发现证书的域名与自己要访问的服务器 B 的域名不匹配。
-
验证失败：
- 由于域名不匹配，客户端 A 无法通过验证。
- 客户端 A 会拒绝与 M 建立 HTTPS 连接，通信失败。
防御机制总结
- 域名验证：客户端 A 验证服务器 B 的数字证书时，确保证书上的域名与访问的域名匹配。这是防止中间人攻击的关键步骤。
- 证书颁发机构（CA）：受信任的 CA 签发数字证书，保证了证书的可信度和合法性。
- 加密通信：使用 HTTPS 协议加密通信数据，防止中间人读取和篡改数据。
具体流程示意
-
A 向 B 发起连接请求：
- A: "我要连接 example.com"。
-
M 拦截请求，伪装成 B：
- M: "我是 example.com，这是我的证书（假冒的）"。
-
A 验证证书：
- A 检查证书，发现域名不匹配或证书不受信任。
- A: "你不是 example.com，我不和你通信"。
-
B 发送真实证书（如果没有中间人干扰）：
- B: "我是 example.com，这是我的证书（真实的）"。
-
A 验证通过：
- A 检查证书，发现域名匹配且证书受信任。
- A: "验证通过，开始安全通信"。
通过上述机制，即使中间人 M 试图拦截并伪造信息，也无法通过客户端 A 的验证，通信安全得以保证。
cookie
http2
1. 头部压缩：HTTP2的HPACK算法
静态表：有61个头部字段，只需要提取对应的编码即可
动态表：将静态表没有的字段保存在动态表中，首次请求动态表字段为空
huffman编码：将字符串压缩
ASCII 编码表
以下是部分ASCII字符及其对应的十进制值和二进制表示：
- '0' 的十进制值是 48，二进制表示是 00110000
- '1' 的十进制值是 49，二进制表示是 00110001
- '2' 的十进制值是 50，二进制表示是 00110010
在HTTP/2中，头部帧（HEADERS帧）和数据帧（DATA帧）可以属于同一个流，但它们不能在不同的流中传输。HTTP/2引入了流的概念，每个流都有一个唯一的流标识符，用于在单个TCP连接上多路复用多个并发的HTTP请求和响应。
HTTP/2中的帧和流
流
- 每个流都有一个唯一的流标识符。
- 一个流中的所有帧（包括HEADERS帧和DATA帧）必须使用相同的流标识符。
- 客户端和服务器可以并发地在不同的流中发送多个请求和响应。
帧
- HTTP/2的基本单位是帧，所有通信都通过帧完成。
- 不同类型的帧包括HEADERS帧、DATA帧、PRIORITY帧、RST_STREAM帧等。
- HEADERS帧用于传输头部信息。
- DATA帧用于传输主体数据。
头部帧和数据帧的传输
- HEADERS帧：包含HTTP请求或响应的头部信息，通常是一个流的第一个帧，用于初始化流。
- DATA帧：包含HTTP请求或响应的实际数据。
不能跨流传输
- HTTP/2协议规定，一个流的HEADERS帧和DATA帧必须在同一个流中传输，不能跨流传输。也就是说，属于同一个请求或响应的头部信息和数据必须共享同一个流标识符。
- 例如，流ID为1的HEADERS帧和流ID为1的DATA帧都属于流1，但不能有流ID为1的HEADERS帧和流ID为2的DATA帧同时用于一个请求或响应。
多路复用
- HTTP/2支持在同一个TCP连接上多路复用多个流。每个流可以独立地发送HEADERS帧和DATA帧。
- 这样可以并行处理多个HTTP请求和响应，提升传输效率和资源利用率。
示例
假设客户端发送两个并发请求，分别在流ID为1和流ID为3上：
- 请求1在流ID为1上发送HEADERS帧和DATA帧。
- 请求2在流ID为3上发送HEADERS帧和DATA帧。
在此过程中，流ID为1的所有帧（包括HEADERS帧和DATA帧）只能属于流1，流ID为3的所有帧只能属于流3。
总结
在HTTP/2中，头部帧和数据帧必须在相同的流中传输，而不能跨流传输。这一机制通过流标识符来管理和区分不同的并发请求和响应，确保协议的高效性和准确性。
location /test.html {
http2_push /test.css;
}就可以在流1中GET，流2中获取额外的信息
扫一扫
1286
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
