HTTP 1.0/1.1/2/3
HTTP/1.0
- 超文本传输协议（Hyper Text Transfer Protocol）
- 只支持最基本的功能，如 GET 和 POST 请求方法
- 无连接、无状态
HTTP/1.1
- 长连接：引入了长连接（Connection: keep-alive），允许在同一个 TCP 连接上发送多个请求/响应，减少了建立和关闭连接的开销。
- 更多头部字段：增加了更多的请求和响应头部字段，如 Host、Connection、Content-Length 等。
- 缓存控制：引入了缓存控制机制，如 Cache-Control、ETag、Last-Modified 等。
HTTP/2
- 二进制协议：不再是基于文本的协议，而是二进制协议，提高了解析效率。
- 多路复用：允许在同一个连接上并行交错发送多个请求和响应，避免队头阻塞问题。
- 头部压缩：引入了 HPACK 算法，对请求和响应头部进行压缩，减少了头部大小，提高了效率。
- 服务端推送：服务端可以主动向客户端推送资源，而不需要客户端明确请求。
HTTP/3
- 基于 QUIC：使用 QUIC 协议替代 TCP。QUIC 是 UDP 上的一个多路复用、加密传输协议，提供了更快的连接建立和更高效的数据传输。
HTTPS
在 HTTP 基础上增加了 TLS 协议
建立连接过程
- 客户端发送 Client Hello 请求报文，包含（TLS 版本、支持的加密套件、随机数 A）
- 服务端发送 Server Hello 响应报文，包含（确认 TLS 版本、选择的加密套件、随机数 B）
- 服务端发送证书，客户端进行验证并得到公钥
- 客户端生成第三个随机数（预主密钥），用公钥进行加密发送给服务端
- 服务端用私钥解密得到预主密钥
- 最后客户端用 随机数 A、随机数 B、预主密钥 用之前协商的加密算法计算出会话密钥
- 服务端也用相同方法得到会话密钥，以后的数据传输全部用会话密钥进行对称加密
HTTP 状态码
- 1xx：表示消息
- 2xx：表示成功
- 3xx：表示重定向
- 4xx：表示客户端错误
- 5xx：表示服务器错误
常见：
- 101：切换协议，如 websocket
- 200：请求成功处理
- 301：永久重定向
- 302：临时重定向
- 304：资源未更改，使用缓存
- 400：请求错误
- 401：未进行身份认证
- 403：无权限
- 404：服务器没有找到资源
- 500：服务器内部错误
- 502：网关错误
301 和 302 区别
| 301 | 302 | |
|---|---|---|
| 搜索引擎 SEO | 将权重给新的地址 | 不会 |
| 浏览器 | 将新的地址缓存下来，后续访问原地址直接跳转新地址 | 不会 |
| 应用场景 | 网站改版，旧页面永久失效 | 单点登录跳转认证中心 |
HTTP 缓存
- 首次请求时，服务器返回响应头
Cache-Control或Expires，设置资源的缓存时间 - 下次请求时判断是强缓存（
Cache-Control有max-age）还是协商缓存（Cache-Control为no-cache）
强缓存
根据 max-age 判断是否过期，没有过期则从缓存（内存缓存 Memory Cache 或 硬盘缓存 Disk Cache）中读取，否则重新请求服务器
Cache-Control：
max-age：过期时间，单位秒no-cache：进行协商缓存no-store：不使用缓存- …
协商缓存
将上次资源的 Etag 作为 If-None-Match 发送服务器判断是否真的过期（也可以使用 Last-Modified 和 If-Modified-Since），没过期返回 304 状态码，浏览器继续使用缓存，否则返回 200
NOTE
如果没有返回 Cache-Control，则浏览器采用 启发式缓存：会用
Date减去Last-Modified的 1/10 作为缓存时间
TCP / UDP
对比
| TCP | UDP | |
|---|---|---|
| 连接性 | 面向连接 | 无连接 |
| 面向 | 字节流 | 报文 |
| 可靠性 | 可靠 | 不可靠 |
| 效率 | 低 | 高 |
| 拥塞控制 | 有 | 无 |
| 应用场景 | 网页（HTTP）、邮件（SMTP）、文件传输（FTP） | 直播、在线游戏、实时通信 |
TCP 三次握手
- 客户端向服务器发送一个 SYN 报文（生成一个初始 ISN 序号）
- 服务器向客户端发送一个 SYN-ACK 报文段作为应答（将客户端的 ISN+1 作为 ACK 的值）
- 客户端向服务器发送一个 ACK 报文段，对服务器的 SYN 报文段进行确认（将服务端的 ISN+1 作为 ACK 的值）
为什么不是两次握手?
第三次握手没有的话，服务端没办法确定发送的报文客户端能不能收到
TCP 四次挥手
- 客户端向服务器发送一个 FIN 报文
- 服务器向客户端发送一个 ACK 报文段（客户端 FIN 报文段的序号加 1），对客户端的 FIN 报文段进行确认
- 服务器在处理完所有接收到的数据后，也会向客户端发送一个 FIN 报文段
- 客户端向服务器发送一个 ACK 报文段（服务端 FIN 报文段的序号加 1），对服务器的 FIN 报文段进行确认，等待 2MSL（2 倍报文段最长寿命）后正式关闭连接
为什么不能把服务端发送的 ACK 和 FIN 合并起来，变成三次挥手？
因为服务端收到客户端断开连接的请求时，可能还有一些数据没有发完，这时先回复 ACK，表示接收到了断开连接的请求。等到数据发完之后再发 FIN，断开服务端到客户端的数据传送。
为什么要等待 2MSL
第四次挥手时，客户端发送给服务端的 ACK 有可能丢失，如果服务端因为某些原因而没有收到 ACK 的话，服务端就会重发 FIN，如果客户端在 2MSL 的时间内收到了 FIN，就会重新发送 ACK 并再次等待 2MSL，防止服务端没有收到 ACK 而不断重发 FIN。
DNS
DNS（Domain Names System），域名系统，是进行域名和它对应的 IP 地址进行转换的服务器
域名解析过程：
- 搜索浏览器的 DNS 缓存
- 若没有命中，则继续搜索操作系统的 DNS 缓存（hosts）
- 若没有命中，则操作系统将域名发送至本地域名服务器，本地域名服务器递归查询自己的 DNS 缓存
- 若没有命中，则本地域名服务器向上级域名服务器进行迭代查询
- 最终本地域名服务器将得到的 IP 地址返回给操作系统
- 操作系统将 IP 地址返回给浏览器，并缓存
- 浏览器得到了域名对应的 IP 地址，并缓存
CDN
CDN（Content Delivery Network），内容分发网络，将源服务器资源分布到接近用户的边缘节点，加快内容获取
好处
- 提高访问速度
- 减轻源站服务器压力
OSI 七层模型
- 物理层：网卡
- 数据链路层：以太网协议
- 网络层：IP 协议
- 传输层：TCP 协议
- 会话层：Telnet 或 SSH
- 表示层：SSL/TLS
- 应用层：HTTPS