HTTP 协议
HTTP协议叫超文本传输协议，是一种应用层协议。可以传输文字，图片，音频和视频等数据，
- TCP：HTTP协议基于TCP协议，工作与C/S架构。
- 数据：HTTP允许传输任意类型的数据
- 请求响应：每次连接只能处理一个请求，客户端收到应答后，断开连接
- 无状态：两次连接请求是相互独立的
HTTP 1.0/1.1/2.0/3.0
1.0
- 非持久连接，每次请求都需三次握手
- 阻塞IO，下次请求必须等待上次请求响应
- 明文传输字符串
1.1
- 持久连接
- 请求管道化
- 增加缓存处理(cache-control)
- 增加Host字段
- 支持断点续传(文件分段传输)
2.0
- 二进制分帧
- 多路复用
- 头部压缩
- 服务器推送
3.0
- 使用基于UDP的QUIC协议
- 改善多路复用，重发丢失的包即可
- 优化TLS，1RTT完成连接建立和秘钥协商
协议名称 | 说明 |
HTTP1.0 | 1个TCP，1次请求-响应 |
HTTP1.1 | 1个TCP，有限个请求 |
HTTP2.0 | 1个TCP，多路复用（帧） |
HTTP3.0 | 移动设备，多路复用，安全 |
HTTP 1.0
- 仅支持非持久连接，每次请求都需要建立新的TCP连接
HTTP1.1
- 支持持久连接，在1个TCP连接上可以进行多次HTTP请求响应
- 同步-非流水线：客户端请求后必须等待响应才能进行下1次请求
- 异步-流水线：客户端请求后不用等待响应就能进行下1次请求
HTTP2.0
多路复用：
- 使用1个HTTP2.0连接发送多路请求/响应消息
- HTTP2.0将信息单位缩小为帧，并行双向在1个连接上交流（多路复用）
- HTTP1.1同时对同1域名请求的数量有限制，这也是CDN出现的原因。
HTTP3.0
HTTP2.0问题：
- 多路复用：有序字节流导致的对头阻塞，影响了HTTP2.0的多路复用
- TLS：TLS增加了握手延迟，建立TCP连接的时长还可降低1倍
- 无线环境下高速移动设备：基于TCP 4元组（源IP地址，源端口号，目的IP地址，目的端口号）标识TCP连接的方式适用于有线网络，不适用于无线网络，在无线网络环境下高速移动的设备（手机坐高铁），IP地址会频繁变动，引起TCP 4元组标识变化，导致TCP和TLS频繁重新连接
HTTP3.0解决：
- 多路复用：HTTP3.0基于UDP重新定义连接，使用QUIC(Quick UDP Internet Connections)（Google）实现了无序、并发传输字节流，解决了队头阻塞问题
- TLS：HTTP3.0重定义了TLS加密QUIC头部的方式。1 RTT完成连接建立与密钥协商
- 无线环境下高速移动设备：分离Packet、QUIC Frame、HTTP3 Frame
HTTP GET vs. POST
GET：
- ASCII编码拼接字符串放到URL中
- URL编码长度有限制
- 请求服务端1次
- 幂等性方法
POST
- 放到请求体中
- 可以发送更大数据量
- 请求服务端2次（1.发送OPTIONS，2.发送数据）
- 非幂等性方法
简单的查询请求使用GET，增删改复杂查询可以使用POST
- 速度：GET请求比POST请求快一些
- 编码：GET只支持ASCII编码 包括中文，POST支持多种编码
- 数据量：GET的URL编码有长度限制，POST可以发送更大数据量
- 安全性：POST更安全，不会作为URL的一部分
- 幂等性：GET，HEAD，PUT 和 DELETE 是幂等方法。POST不是
- 读写：GET，HEAD，OPTIONS不会改变服务器状态。POST，PUT，PATCH，DELETE会
- 缓存：GET，HEAD可缓存。POST一般可缓存。PUT，DELETE不可缓存
- 异步：XMLHttpRequest在 AJAX 中被大量使用， XMLHttpRequest的POST的header和data是分开发送的。XMLHttpRequest的GET的header和data是一起发送的
HTTP GET的URL编码
URL编码为了区分分隔符
key1=value1&key2=value2- key和value的分隔符是
=，ASCII码16进制 3D - entry和entry的分隔符是
&，ASCII码16进制 26 - value中含有分隔符，
key=va&lu=e，URL编码，key=va%&lu%=e，在分隔符前加上%
HTTP POST发送2次请求
浏览器缓存问题
- 有些浏览器会在发送POST请求时先发送一次OPTIONS预检请求，如果之前已经进行过预检请求并得到服务器的允许，浏览器会将预检结果缓存起来，下次再发送POST请求时就不会再发送预检请求了。
- 但如果缓存过期或被清除，浏览器可能会再次发送OPTIONS预检请求。
自定义请求头部信息
- 当发送带有自定义请求头的POST请求时，浏览器会先发送一个OPTIONS请求进行预检，如果服务器允许该请求，则浏览器会再次发送实际的POST请求。
HTTP 常用状态码及使用场景
分类 | 作用 |
2xx | 请求成功 |
4xx | 客户端错误，请求报文错误 |
5xx | 服务端错误 |
1xx | 中间状态，需要后续请求 |
3xx | 重定向状态，需要重新请求 |
状态码 | 作用 |
200 | 请求成功 |
404 | 资源未找到 |
403 | 服务端禁止访问 |
400 | 请求错误 |
500 | 服务端错误 |
503 | 服务端繁忙 |
101 | 切换协议，HTTP到WebSocket |
301 | 永久重定向，会缓存 |
302 | 临时重定向，不会缓存 |
304 | 协商缓存命中 |
HTTP 301/302状态码的区别和用途
状态码 | 作用 |
301 | 永久重定向，会缓存 |
302 | 临时重定向，不会缓存 |
301 Move Permanently
- 多个域名指向同一资源，可以让n-1个域名永久重定义到1个域名，以累加网站在搜索引擎中的权重
302 Move Temporarily
- 页面临时重定向，有网络劫持风险，会降低网站在搜索引擎中的权重，一般别使用
请求头
请求头 | 说明 |
Authorization | token信息 |
Content-Length | 请求体长度 |
Content-Type | POST和PUT请求的多媒体类型 |
Cookie | 服务器通过Set-Cookie响应的Cookie |
User-Agent | 浏览器身份标识 |
| 长短连接 |
响应头
Content-Type
名称 | 说明 |
| 文本 |
| 图片 |
| JSON |
| 表单提交时传输二进制数据 |
| 表单提交时传输键值对数据 |
HTTP HTTPS
收费：HTTPs需要使用可信机构颁发的ssl证书，需要收费
效率：HTTPs多了一层ssl，效率相对低
安全：HTTP是明文传输，HTTPs是ssl加密传输
端口：HTTP是80端口，HTTPs是443端口
HTTP Cookie, Session
Cookie：是服务器为了辨别用户身份而存储在用户本地的数据
- 来历：HTTP是无状态协议，服务端无法区分客户端
- 作用：保存用户信息，认证信息（sessionId, token），登录信息（用户基本信息），行为信息（购物）
- 响应头：set-cookie
Session：是服务端记录用户状态
Session和Cookie的区别：
- 保存位置：Session保存在服务器端，而Cookie保存在客户端。
- 存储容量：单个Cookie保存的数据不能超过4KB，一个站点最多保存20个Cookie。相对的，Session没有大小限制，但出于对服务器端的性能考虑，Session内不要存放过多的东西，并且设置Session删除机制。
- 存储方式：Cookie只能存储ASCII字符串，需要通过编码方式存储为Unicode字符或者二进制数据。相对的，Session能够存储任何类型的数据。
- 安全性：由于Cookie保存在客户端，所以它容易被窃取。例如，如果一个恶意第三方获得了用户的Cookie，就可以获取该用户的相关信息。因此，Cookie不太安全。而Session因为保存在服务器端，所以相对比较安全。
- 有效期：Cookie可以根据有效期而存在，而Session依赖于名为JSESSIONID的Cookie，该Cookie的过期时间默认为-1，只需关闭窗口该Session就会失效，因而Session不能达到长期有效的效果。
- 对服务器压力：Cookie保存在客户端，不占用服务器资源。对于并发用户十分多的网站，Cookie是很好的选择。而Session保存在服务器端，每个用户都会产生一个Session。假如并发访问的用户十分多，会产生十分多的Session，耗费大量的内存。
- 浏览器支持：Cookie需要客户端浏览器支持，如果客户端禁用或者不支持Cookie，则会导致会话跟踪失效。对于WAP上的应用，常规的Cookie就派不上用场了。而Session不需要浏览器支持，即使在客户端不支持Cookie的情况下也能正常工作。
- 跨域支持：Cookie支持跨域名访问，而Session不支持跨域名访问。
HTTP keep-alive vs. close（非keep-alive）
HTTP header
- Connection: keep-alive #长连接、持久连接
- Connection: close #短连接、非持久连接
Connection: keep-alive #长连接、持久连接，复用TCP连接，一次请求响应之后不关闭TCP连接
Connection: close #短连接、非持久连接，每次请求响应都创建新的TCP连接, 一次请求响应之后关闭TCP连接
注意：
- 长连接 即 持久连接 即 keep-alive；短连接 即 非持久连接 即 close
- client 和 server都需要设置 connection:keep-alive, 才是长连接（持久连接）
- HTTP是应用层协议，数据的传输仍然由TCP负责
HTTP各版本
- HTTP 1.0，默认使用非持久连接，可以设置持久连接connection:keep-alive
- HTTP 1.1，默认使用持久连接
非keep-alive（close）缺点：必须为每一个请求的对象建立和维护一个全新的连接。对于每一个这样的连接，客户机和服务器都要分配 TCP 的缓冲区和变量，这给服务器带来的严重的负担，因为一台 Web 服务器可能同时服务于数以百计的客户机请求。
keep-alive优点：服务器在响应后保持该 TCP 连接打开，在同一个客户机与服务器之间的后续请求和响应报文可通过相同的连接进行传送。甚至位于同一台服务器的多个 Web 页面在从该服务器发送给同一个客户机时，可以在单个持久 TCP 连接上进行。
keep-alive缺点：当长时间的保持 TCP 连接时容易导致系统资源被无效占用，若对 Keep-Alive 模式配置不当，将有可能比非 Keep-Alive 模式带来的损失更大。因此，我们需要正确地设置 keep-alive timeout 参数，当 TCP 连接在传送完最后一个 HTTP 响应，该连接会保持 keepalive_timeout 秒，之后就开始关闭这个链接。
HTTP keep-alive vs. TCP keepalive
HTTP 长连接：用来复用 TCP 连接
TCP 长连接：用来探测对方是否 “活着”
HTTP连接：是在有 TCP连接的情况下，才能通过设置connection header实现
TCP连接：由内核设定
HTTP 长连接 vs. 短连接
见 HTTP keep-alive vs. close（非keep-alive）
注意：长连接需要服务端和客户端都设置connection: keep-alive
HTTP 长轮询 vs. 短轮询
短轮询：去服务端查询的时候，不管库存量有没有变化，服务器就立即返回结果了。
长轮询：服务器如果检测到库存量没有变化的话，将会把当前请求挂起一段时间（这个时间也叫作超时时间，一般是几十秒）。在这个时间里，服务器会去检测库存量有没有变化，检测到变化就立即返回，否则就一直等到超时为止。
注意：
- 长轮询是根据服务端的处理方式来决定的，与客户端没有关系
- 长轮询是服务器通过编程的方式，手动挂起请求来实现的
HTTP 1.x 对头阻塞
HTTP 1.x 对头阻塞设计，导致高延迟问题，降低了数据的加载速度
是的，HTTP 1.x 的头阻塞设计确实导致了高延迟问题，从而降低了数据的加载速度。在 HTTP 1.x 中，浏览器与服务器之间的通信是通过串行化的方式进行的，也就是说，每个请求必须等待前一个请求的响应完成后才能发送。
队头阻塞是指如果一个请求的响应较慢，那么后续的请求也必须等待在队列中，无法被发送，从而造成了阻塞。这种设计导致了浏览器不能同时发起多个请求，而是需要等待前一个请求完成后才能发送下一个请求，从而增加了整体加载时间。
另外，HTTP 1.x 在一个 TCP 连接上只能发送一个请求，这意味着每次请求都需要建立和关闭 TCP 连接，这也会增加延迟。
为了解决这个问题，HTTP/2 协议被引入。HTTP/2 使用二进制协议而不是文本协议，引入了多路复用的概念，允许多个请求同时在同一个连接上进行，从而避免了头阻塞问题。HTTP/2 还支持服务器推送和头部压缩等功能，进一步提高了性能和加载速度。
总结来说，HTTP 1.x 的头阻塞设计确实导致了高延迟问题，但随着 HTTP/2 的出现，这个问题得到了有效的解决。
从输入 URL 到页面展示到底发生了什么
DNS 解析
TCP 连接
发送 HTTP 请求
服务器处理请求并返回 HTTP 报文
浏览器解析渲染页面
连接结束
DNS HTTP TCP OSPF IP ARP
DNS
有哪些域名服务器
根域名服务器：提供顶级x的IP，13组根服务器
顶级域名服务器：提供权威x的IP，顶级域是指域名的后缀，例如 com
权威域名服务器：将主机名称映射为IP地址
本地域名服务器：代理主机发出的DNS请求，ISP提供
DNS的过程
先本地hosts文件》再走DNS过程
