HTTP/1.0、HTTP/1.1、HTTP/2 和 HTTP/3
别再说 http是短链接了!!!
从HTTP/1.1
引入后,支持了keep-alive
就可以保持长链接了。
注意是说保持 长链接状态。 因为 长短链接 说的是tcp连接 是否继续保持。
所以 最多只能说HTTP/1.0
无法 进行链接
HTTP/1.0、HTTP/1.1、HTTP/2 和 HTTP/3 是互联网上用于客户端和服务器之间通信的不同版本的超文本传输协议(HTTP)。每个版本都引入了新的特性和改进,以提高性能、效率和安全性。以下是它们的主要区别:
1. HTTP/1.0
- 发布时间:1996年
- 特点:
- 简单:每个请求/响应对都需要建立一个新的 TCP 连接。
- 无连接复用:一个 TCP 连接只能处理一个请求,导致“连接开销”较高。
- 无持久连接:请求完成后立即关闭连接。
- 无管道化:请求必须按顺序处理,不能同时发送多个请求。
- 单工通信:因为它使用短连接,请求完成后立即关闭连接。数据单向传输
- 缺点:
- 性能较低,尤其是在加载包含多个资源(如图片、CSS、JavaScript)的页面时。
- 无法有效利用底层 TCP 连接的性能。
2. HTTP/1.1
- 发布时间:1997年
- 改进:
- 持久连接:通过
Connection: keep-alive
头部,多个请求可以复用同一个 TCP 连接,减少了连接开销[1]。 - 管道化:允许客户端在同一个连接上发送多个请求,而无需等待前一个请求的响应[2]。
- 分块传输编码:支持分块传输,允许服务器动态生成响应内容[3]。
- 请求范围:支持范围请求(Range Requests),允许客户端请求资源的一部分[4]。
- 半双工通信: 虽然 有了
keep-alive
,仍然是 请求-应答模型。同一时刻,只能数据单向传输
- 持久连接:通过
- 缺点:
- 尽管引入了持久连接和管道化,但仍然存在“队头阻塞”问题(Head-of-Line Blocking, HOLB),即一个请求的延迟会影响后续所有请求[5]。
- 对于包含大量资源的页面,性能瓶颈仍然存在。
3. HTTP/2
- 发布时间:2015年
- 改进:
- 多路复用(Multiplexing):在同一个 TCP 连接上可以同时发送多个请求和响应,解决了 HTTP/1.1 的队头阻塞问题。
- 二进制分帧(Binary Framing):将 HTTP 请求和响应分割成二进制帧,提高传输效率。
- 头部压缩(HPACK):通过压缩 HTTP 头部,减少了头部信息的大小,从而提高传输速度。
- 服务器推送(Server Push):允许服务器主动推送资源到客户端,减少了客户端的额外请求。
- 全双工的: 流(stream)的概念,允许多个流复用一条 TCP 连接,双方可以同时发送和接收数据。数据同时双向传输
- 缺点:
- 仍然基于 TCP,TCP 的连接建立和拥塞控制机制可能成为性能瓶颈。
- 部署和调试相对复杂,需要支持 TLS(HTTPS)。
4. HTTP/3
- 发布时间:2020年
- 改进:
- 基于 QUIC 协议:HTTP/3 基于 QUIC(Quick UDP Internet Connections),这是一个基于 UDP 的传输协议。
- 减少连接延迟:QUIC 的连接建立时间比 TCP 更快,因为它减少了握手的往返次数
- 更好的拥塞控制:QUIC 提供了更高效的拥塞控制机制,能够更好地适应网络状况
- 无队头阻塞(No HOLB):即使在多路复用中,一个请求的延迟也不会影响其他请求
- 连接迁移:支持在不同网络之间迁移连接(例如从 Wi-Fi 切换到移动网络),而不会中断连接
- 缺点:
- 部署难度较高,需要支持 QUIC 和 TLS 1.3
- UDP 的不可靠性需要额外的机制来保证数据的完整性和顺序
总结
版本 | 基础协议 | 主要特性 | 优点 | 缺点 |
---|---|---|---|---|
HTTP/1.0 | TCP | 简单,无持久连接 | 实现简单 | 性能低,连接开销大 |
HTTP/1.1 | TCP | 持久连接,管道化 | 性能提升,支持范围请求 | 队头阻塞 |
HTTP/2 | TCP | 多路复用,二进制分帧,头部压缩 | 高效传输,减少延迟 | 部署复杂,依赖 TLS |
HTTP/3 | QUIC (UDP) | 无队头阻塞,连接迁移,更快的连接建立 | 最高性能,适应性更强 | 部署难度高,依赖 UDP |
HTTP/2 和 HTTP/3 是目前主流的协议,HTTP/3 正在逐步普及。对于现代网站,建议优先支持 HTTP/2 和 HTTP/3,以提升用户体验和性能。
HTTP 和 HTTPS 的区别
核心区别:
HTTP 基于 TCP 协议,信息是明文传输;
HTTPS 在 TCP 之上引入了 TLS/SSL 协议, 信息是加密传输。
HTTP(HyperText Transfer Protocol,超文本传输协议)和 HTTPS(HyperText Transfer Protocol Secure,安全超文本传输协议)是用于客户端和服务器之间通信的两种协议。
1. 安全性
HTTP:
- 不加密:HTTP 数据以明文形式传输,包括请求头、请求体、响应头和响应体等。这意味着数据在传输过程中容易被窃听、篡改或伪造。
- 无身份验证:HTTP 不提供身份验证机制,无法验证服务器或客户端的身份,容易受到中间人攻击(MITM)。
HTTPS:
- 加密传输:HTTPS 在 HTTP 的基础上引入了 TLS(Transport Layer Security,传输层安全协议)或 SSL(Secure Sockets Layer,安全套接字层)加密。所有数据在传输前都会被加密,确保数据的机密性和完整性。
- 身份验证:通过数字证书(由证书颁发机构 CA 颁发)验证服务器的身份,客户端可以确信自己正在与合法的服务器通信,防止中间人攻击。
2. 传输方式
HTTP:
- 基于 TCP:HTTP/1.0 和 HTTP/1.1 使用 TCP 作为传输层协议。
- 明文传输:数据以明文形式传输,容易被网络设备(如路由器、代理服务器)读取和篡改。
HTTPS:
- 基于 TLS/SSL:HTTPS 在 TCP 之上引入了 TLS/SSL 层,用于加密数据。
- 加密传输:数据在传输前被加密,只有合法的接收方才能解密。即使数据被中间设备截获,也无法读取其内容。
- 证书机制:服务器必须提供有效的 SSL/TLS 证书,客户端通过证书验证服务器的身份。
3. 性能
HTTP:
- 性能较高:由于没有加密和解密的开销,HTTP 在传输速度上通常比 HTTPS 稍快。
- 无连接开销:HTTP/1.0 每次请求都需要建立新的 TCP 连接,HTTP/1.1 支持持久连接(Keep-Alive),但仍然存在连接管理的开销。
HTTPS:
- 加密开销:TLS 握手过程需要额外的计算和网络往返,增加了连接建立的时间和资源消耗。
- 性能优化:现代 HTTPS 实现(如 HTTP/2 和 HTTP/3)通过多路复用、头部压缩、服务器推送等技术,显著提高了性能,减少了加密开销对性能的影响。
- HTTP/2 和 HTTP/3:HTTPS 是 HTTP/2 和 HTTP/3 的默认传输方式,这些协议通过优化传输效率,弥补了加密带来的性能损失。
4. 证书和信任机制
HTTP:
- 无需证书:HTTP 不需要证书,任何服务器都可以提供服务。
HTTPS:
- 需要证书:服务器必须安装有效的 SSL/TLS 证书,证书由受信任的证书颁发机构(CA)签发。
- 证书验证:客户端会验证服务器证书的有效性,包括证书的颁发机构、有效期、域名匹配等。如果证书无效或不可信,客户端会拒绝连接。
5. URL 格式
HTTP:
- URL 以
http://
开头,例如http://example.com
。
- URL 以
HTTPS:
- URL 以
https://
开头,例如https://example.com
。
- URL 以
6. 浏览器支持和默认行为
HTTP:
- 浏览器通常会允许用户访问 HTTP 网站,但会显示“不安全”的警告。
HTTPS:
- 浏览器优先支持 HTTPS,并且会显示“安全”或“锁”图标,表示连接是加密的。
- 现代浏览器(如 Chrome)会逐步淘汰对 HTTP 的支持,鼓励网站使用 HTTPS。
7. 应用场景
HTTP:
- 适用于对安全性要求不高的场景,如公共信息页面。
- 由于性能较高,HTTP 仍然在某些内部网络或局域网中使用。
HTTPS:
- 适用于所有需要保护用户隐私和数据安全的场景,如电子商务、在线银行、用户登录、个人数据传输等。
- 已成为现代互联网的标准协议,几乎所有主流网站都已迁移到 HTTPS。
总结
特性 | HTTP | HTTPS |
---|---|---|
安全性 | 明文传输,无加密 | 加密传输,防止窃听和篡改 |
身份验证 | 无 | 通过 SSL/TLS 证书验证服务器身份 |
传输方式 | 基于 TCP | 基于 TLS/SSL 加密的 TCP |
性能 | 稍快(无加密开销) | 稍慢(加密开销),但可通过 HTTP/2 和 HTTP/3 优化 |
证书需求 | 无需证书 | 需要有效的 SSL/TLS 证书 |
URL 格式 | http:// | https:// |
浏览器支持 | 显示“不安全”警告 | 显示“安全”或“锁”图标 |
应用场景 | 公共信息页面 | 电子商务、在线银行、用户登录等 |
http请求 有了keep-alive
可以代替websocket 么?
首先明确长连接:TCP连接一直不断开的连接
keep-alive
能实现长连接,但是有时间限制,最多时间长一些而已- 目的主要是进行tcp连接复用的, 如 网站加载场景进行多并发
- 服务不能主动发送消息,虽然 HTTP/2 协议引入了 Server Push(服务器推送)功能,仍然需要客户端发起初始请求来触发
- 需要服务端支持
keep-alive
,因为TCP连接的断开是双向的,不是客户端说我要保持连接就行
HTTP 和 TCP 的关系
HTTP(HyperText Transfer Protocol,超文本传输协议)和 TCP(Transmission Control Protocol,传输控制协议)是网络通信中两个不同层次的协议,它们之间存在紧密的关系。
关系:HTTP 协议 基于TCP
协议来实现数据的可靠传输。HTTP 请求和响应数据通过 TCP 连接进行传输。
- TCP 是 HTTP 的传输基础:HTTP 协议依赖 TCP 提供的可靠传输、流量控制和拥塞控制等特性来 确保数据的 完整性和稳定性。
- HTTP 是 TCP 的应用层协议:HTTP 在 TCP 之上运行,通过 TCP 连接发送请求和接收响应。
- 两者相辅相成:TCP 为 HTTP 提供了可靠的传输通道,而 HTTP 则利用 TCP 的特性实现了高效的超文本数据传输。
- 层次关系
- TCP 是 传输层 协议,位于 OSI 七层模型的第四层。
- 它的主要作用是为应用程序提供可靠的、面向连接的 字节流服务 。
- TCP 负责数据的传输、错误检测与纠正、流量控制以及拥塞控制等。
- HTTP 是 应用层 协议,位于 OSI 七层模型的第七层。
- 它是一种用于客户端和服务器之间传输超文本的协议,主要用于浏览器与服务器之间的通信,以获取网页内容(HTML、图片、CSS、JavaScript 等)。
- TCP 为 HTTP 提供的服务
- 可靠传输:TCP 是一种面向连接的协议,它通过三次握手建立连接,确保数据在传输过程中不会丢失、重复或乱序。
- HTTP 协议依赖 TCP 的可靠传输特性,保证请求和响应数据能够完整、准确地到达对方。
- 流量控制与拥塞控制:TCP 通过 滑动窗口机制对流量进行控制,避免发送方发送过多数据导致接收方处理不过来。
- TCP 的拥塞控制机制能够根据网络状况动态调整传输速率,避免网络拥塞。这对于 HTTP 数据传输的稳定性和效率至关重要。
- 面向字节流:TCP 将数据封装成字节流的形式进行传输,HTTP 请求和响应数据被封装在 TCP 数据包中,通过网络传输到目标地址。
- HTTP 如何使用 TCP
- 建立连接:当客户端(如浏览器)发起 HTTP 请求时,首先需要通过 TCP 建立一个到服务器的连接。这个过程称为 三次握手:
- 客户端发送一个
SYN
数据包到服务器。 - 服务器回应一个
SYN-ACK
数据包。 - 客户端发送一个
ACK
数据包确认连接建立。
- 客户端发送一个
- 数据传输:TCP 连接建立后,客户端通过 TCP 发送 HTTP 请求报文(包括请求行、请求头和请求体),服务器通过 TCP 返回 HTTP 响应报文(包括状态行、响应头和响应体)。
- 关闭连接:数据传输完成后,客户端和服务器通过 四次挥手 断开 TCP 连接:
- 客户端发送
FIN
数据包请求关闭连接。 - 服务器回应
ACK
数据包确认。 - 服务器发送
FIN
数据包请求关闭连接。 - 客户端回应
ACK
数据包确认。
- 客户端发送
- HTTP/2 和 HTTP/3 的改进
- HTTP/2:引入了多路复用、二进制分帧、头部压缩等技术,但仍然基于 TCP。HTTP/2 的改进主要是在应用层优化数据传输效率,而 TCP 仍然负责底层的可靠传输。
- HTTP/3:基于 QUIC 协议(一种基于 UDP 的传输层协议),而不是 TCP。QUIC 提供了类似 TCP 的可靠性,同时减少了连接建立的延迟,并且支持更快的多路复用和拥塞控制。HTTP/3 的出现是为了进一步提升网络性能,但 TCP 仍然是 HTTP 的主要传输协议。
面试常问的 http 状态码
1. 301 Moved Permanently
- 含义:永久重定向: 表示请求的资源已被永久移动到新的 URL。浏览器会自动将请求的 URL 替换为新的 URL,并且搜索引擎会将旧 URL 的权重和排名转移到新的 URL
- 应用场景:用于资源的永久重定向,客户端应更新书签或链接。
- 面试要点:理解其与
302 Found
的区别,以及对搜索引擎优化(SEO)的影响。
2. 302 Found
- 含义: 临时重定向 : 浏览器会自动跳转,但 搜索引擎会保留旧 URL 的权重和排名,认为这是一个临时的跳转。
- 应用场景:用于临时重定向,客户端应继续使用旧的 URI。
- 面试要点:理解其与
301
的区别,以及浏览器对302
的默认行为(可能会将POST
转换为GET
)。
4. 304 Not Modified
- 含义:请求的资源未被修改,客户端可以 继续使用本地缓存。
- 应用场景:用于缓存机制,减少不必要的数据传输。
- 面试要点:理解其与缓存头(如
ETag
和Last-Modified
)的关系,以及如何通过条件请求实现高效的缓存验证。
5. 400 Bad Request
- 含义:请求格式错误,服务器无法理解。
- 应用场景:客户端发送了无效的请求数据。
- 面试要点:理解如何通过合理的错误提示帮助客户端修正请求。
6. 401 Unauthorized
- 含义: 没登陆
- 应用场景:客户端未提供有效的认证信息。
- 面试要点:理解其与
403 Forbidden
的区别,以及如何处理认证失败的情况。
7. 403 Forbidden
- 含义: 权限不足
- 应用场景:客户端已认证,但没有足够的权限。
- 面试要点:理解其与
401
的区别,以及如何处理权限不足的情况。
8. 404 Not Found
- 含义:请求的资源不存在。
- 应用场景:客户端请求了一个不存在的资源。
- 面试要点:理解如何处理 404 错误,例如提供友好的错误页面或日志记录。
9. 405 Method Not Allowed
- 含义:请求方法不被允许。 请求方法错误
- 应用场景:客户端使用了不支持的 HTTP 方法(如
POST
请求了一个只支持GET
的资源)。 - 面试要点:理解如何在服务器端配置允许的请求方法。
10. 500 Internal Server Error
- 含义:服务器内部错误,无法处理请求。
- 应用场景:服务器端发生未处理的异常。
- 面试要点:理解如何调试和处理服务器错误,以及如何避免将敏感信息暴露给客户端。
11. 502 Bad Gateway
- 含义:服务器作为 网关 错误。
- 应用场景:通常出现在微服务架构或反向代理场景中。
- 面试要点:理解其与
500
的区别,以及如何排查网关或代理问题。
12. 503 Service Unavailable
- 含义:服务器暂时不可用(例如过载或维护)。
- 应用场景:服务器负载过高或正在进行维护。
- 面试要点:理解如何处理服务不可用的情况,例如返回重试时间或使用负载均衡。