目录
HTTP基本概念
HTTP优缺点
HTTP优点(1.1)
HTTP缺点
HTTP与HTTPS
HTTP 与 HTTPS 的区别
HTTPS 解决 HTTP 的哪些安全问题?
HTTPS 如何解决安全问题?
HTTPS 连接建立的过程:
HTTP/1.1、HTTP/2、HTTP/3 演变
HTTP/1.1 相比 HTTP/1.0 的性能提升
HTTP/2 相比 HTTP/1.1 的性能改进
HTTP/2 的缺陷与 HTTP/3 的优化
总结
HTTP其他重要知识点
HTTP状态码
HTTP常见字段
HTTP 中的GET和POST的概念和区别
HTTP基本概念
HTTP,全称为超文本传输协议(HyperText Transfer Protocol),是网络通信的核心协议之一。它由三个关键概念组成:
- 超文本(HyperText):指的是可以包含图片、视频和链接等多媒体元素的文本,这些元素可以链接到其他文档或资源。
- 传输(Transfer):指的是数据在网络中的发送和接收过程,无论是从服务器到客户端,还是反过来。
- 协议(Protocol):定义了数据传输的规则和标准,确保不同计算机系统之间的通信能够顺利进行。
HTTP作为一种网络协议,为计算机世界提供了一种标准化的通信方式。它规定了客户端和服务器之间如何请求和交换超文本信息,包括各种控制指令和错误处理机制。
“传输”在HTTP中指的是数据在网络中的移动,这不仅是简单的数据迁移,还涉及到确保数据完整性和顺序的复杂过程。HTTP通过定义请求和响应的格式,以及状态码等机制,确保了数据能够在网络中的两点之间可靠地传输。
简而言之,HTTP是网络中数据传输的规则和规范,它使得不同计算机系统能够高效、准确地交换超文本信息。
HTTP优缺点
HTTP优点(1.1)
HTTP以其简洁性、灵活性、可扩展性、广泛的应用和跨平台特性而著称:
-
简洁性:HTTP的报文结构直观,由头部(header)和主体(body)组成,头部信息采用易于理解的键值对文本格式,这降低了学习和使用的难度。
-
灵活性和可扩展性:HTTP协议的设计允许开发者对请求方法、URI/URL、状态码和头部字段等进行自定义和扩展,提供了高度的灵活性。此外,由于HTTP工作在应用层,其下层技术可以自由变化,如HTTPS在HTTP与TCP之间增加了SSL/TLS层,而HTTP/3则采用了基于UDP的QUIC协议。
-
广泛应用和跨平台性:随着互联网的发展,HTTP已成为网络通信的基石,其应用场景从桌面浏览器到移动应用,涵盖了新闻阅读、社交媒体、在线购物、金融管理、在线游戏等多种服务。HTTP的跨平台特性意味着它能够在各种设备和操作系统上无缝工作,这进一步扩大了其应用范围。
HTTP缺点
无状态特性的双刃剑
- 优势在于减轻服务器负担,因为服务器无需存储会话状态,可以更高效地分配资源。
- 劣势在于执行一系列相关操作(如用户登录、购物、结算等)时,由于服务器无法识别这些操作的关联性,每次都需要重新验证用户身份,这可能导致用户体验下降。
明文传输的双刃剑
- 优势是便于调试,因为信息以明文形式传输,易于通过工具如浏览器控制台或Wireshark进行查看。
- 劣势是信息安全风险高,因为传输过程中的数据容易被截获和窃取,尤其是敏感信息如账号密码,可能导致用户信息泄露。
安全性不足
- HTTP不加密,通信内容可能被窃听,增加了账号信息泄露的风险。
- 不验证通信方身份,容易受到伪装攻击,如访问假冒网站,可能导致财产损失。
- 无法保证报文的完整性,可能遭受篡改,如网页被植入恶意广告。
HTTP与HTTPS
HTTP 与 HTTPS 的区别
安全性差异
-
HTTP(超文本传输协议)是一种明文传输协议,通信内容容易受到窃听、篡改和伪造。
-
HTTPS(安全超文本传输协议)在 HTTP 基础上加入了 SSL/TLS 协议,确保数据传输的安全性。SSL/TLS 协议通过加密通信内容,解决了 HTTP 的安全缺陷。
连接建立过程
-
HTTP 连接相对简单,基于 TCP 三次握手完成后即可开始数据传输。
-
HTTPS 除了 TCP 三次握手外,还需要额外的 SSL/TLS 握手过程,确保安全的加密通信。
端口号
-
HTTP 默认使用端口号 80。
-
HTTPS 默认使用端口号 443。
证书认证
- HTTPS 需要向 CA(证书颁发机构)申请并安装数字证书,验证服务器的身份,确保通信对象的可信度。
HTTPS 解决 HTTP 的哪些安全问题?
由于 HTTP 传输是明文的,因此存在以下几种主要安全风险:
-
窃听风险:通信内容可能被第三方截获。
-
篡改风险:数据传输过程中可能被篡改,导致信息不一致。
-
伪装风险:攻击者可能伪造网站,诱导用户输入敏感信息。
HTTPS 通过 SSL/TLS 协议解决这些问题:
-
信息加密:使用加密算法保证通信内容在传输过程中的机密性,防止被窃听。
-
数据完整性校验:通过摘要算法(如哈希)生成数据的唯一指纹,确保数据未被篡改。
-
身份验证:通过数字证书验证服务器身份,防止伪装攻击。
HTTPS 如何解决安全问题?
-
防止窃听:HTTPS 使用混合加密方式,即对称加密和非对称加密结合,确保信息在传输过程中加密,防止第三方监听。
-
防止篡改:使用消息摘要算法(如哈希算法),生成数据的独特“指纹”,验证数据完整性。如果数据被篡改,接收方会检测到。
-
防止伪装:服务器通过数字证书提供公钥,客户端通过 CA 机构验证证书,确保服务器的身份真实可信,避免中间人攻击。
HTTPS 连接建立的过程:
HTTPS 使用 SSL/TLS 协议建立加密连接。整个过程涉及四次信息交互,确保通信的机密性、完整性与身份验证。具体流程如下:
1.ClientHello:客户端向服务器发起加密通信请求,发送以下信息:
- 支持的 SSL/TLS 协议版本(如 TLS 1.2)。
- 客户端生成的随机数(用于生成会话秘钥)。
- 支持的加密套件列表(如 RSA 加密算法)。
2.ServerHello:服务器响应客户端请求,发送以下信息:
- 确认 SSL/TLS 协议版本,若浏览器不支持则关闭连接。
- 服务器生成的随机数(用于生成会话秘钥)。
- 确定使用的加密套件。
- 服务器的数字证书(包含公钥)。
3. 客户端响应:客户端通过 CA 的公钥验证服务器证书,并使用服务器公钥加密以下内容:
- 生成的随机数(pre-master key)。
- 加密通信算法改变通知,指示后续通信使用会话秘钥加密。
- 客户端握手结束通知,并将前述数据摘要发送给服务器。
4. 服务器响应:服务器收到客户端的 pre-master key 后,通过协商的加密算法计算会话秘钥。然后,发送以下信息:
- 加密通信算法改变通知。
- 服务器握手结束通知,并将数据摘要发送给客户端进行验证。
至此,SSL/TLS 握手完成,客户端与服务器可以开始使用会话秘钥加密的通信。
HTTP/1.1、HTTP/2、HTTP/3 演变
HTTP/1.1 相比 HTTP/1.0 的性能提升
HTTP/1.1 相比于 HTTP/1.0 进行了多项性能改进,主要包括:
TCP 长连接
- HTTP/1.0 是基于短连接的,每次请求都需要建立和关闭一个新的 TCP 连接,这会带来较大的性能开销。
- HTTP/1.1 引入了 TCP 长连接,即一个 TCP 连接可以复用多个 HTTP 请求和响应,避免了重复的连接建立与关闭,显著减少了延迟和开销。
管道化(Pipelining)
- HTTP/1.1 支持管道化传输,即客户端可以在等待第一个请求的响应时继续发送后续请求,而不要等待每个请求的回应。这种方式降低了整体响应时间,提升了请求的处理效率。
尽管如此,HTTP/1.1 仍然存在一些性能瓶颈,主要包括
- 头部未压缩:HTTP/1.1 中的请求和响应头信息未经过压缩,头部信息过多时会增加延迟。
- 冗长的头部信息:每次请求都需要发送相同的头部信息,造成不必要的数据传输浪费。
- 队头阻塞:由于 HTTP/1.1 中的请求是按顺序处理的,如果服务器响应慢,后续请求会被阻塞,导致延迟。
- 缺乏请求优先级控制:无法灵活控制哪些请求应优先响应,容易影响性能。
- 请求发起方向限制:HTTP/1.1 仍然只能由客户端发起请求,服务器只能被动响应。
HTTP/2 相比 HTTP/1.1 的性能改进
HTTP/2 引入了一系列创新的技术,解决了 HTTP/1.1 中的多项性能瓶颈:
头部压缩
- HTTP/2 使用 HPACK算法对头部信息进行压缩,尤其是当多个请求包含相同或相似的头部时,协议会去除重复的部分,减少了传输的冗余。
- 客户端和服务器维护一张头部表,使用索引来标识已经发送过的头部字段,避免重复传输相同数据,显著提高了效率。
二进制格式
- HTTP/2 改用 二进制格式,将请求和响应的头部与数据体都封装为二进制帧(frame),而不是像 HTTP/1.1 那样使用纯文本格式。
- 二进制格式更加高效,计算机可以直接解析,而不需要额外的文本解析步骤,提升了数据传输速度。
多路复用(Multiplexing)
- HTTP/2 支持 多路复用,即在一个 TCP 连接中并发处理多个请求和响应,而不必按顺序逐个处理。这样避免了 HTTP/1.1 中的 队头阻塞(Head-of-line blocking)问题,大幅度提高了连接的效率。
流控制和优先级
- HTTP/2 允许客户端指定请求的优先级,服务器可以根据优先级响应高优先级的请求,减少延迟。通过流控制,HTTP/2 能在同一连接中根据网络情况灵活地管理数据流,确保高效的数据传输。
服务器推送(Server Push)
- HTTP/2 引入了 服务器推送机制,服务器可以主动推送客户端可能需要的资源(如 JS、CSS 文件),即便客户端未明确请求。
HTTP/2 的缺陷与 HTTP/3 的优化
尽管 HTTP/2 在性能上有显著提升,但它仍然存在一些问题,主要与底层的 TCP 协议有关:
- 丢包问题:在 HTTP/2 中,多个请求共享一个 TCP 连接,如果出现丢包,整个连接中的所有请求都会受到影响,导致延迟。
- 请求阻塞:尽管 HTTP/2 可以同时发送多个请求,但如果一个请求发生丢包,仍然会导致其他请求的阻塞,这个问题与 TCP 协议本身的流量控制机制密切相关。
为了解决 HTTP/2 中的这些问题,HTTP/3 引入了新的协议设计,主要变化包括:
基于 QUIC 协议
- HTTP/3 底层使用了 QUIC(Quick UDP Internet Connections)协议,替代了传统的 TCP 协议。QUIC 是基于UDP的协议,UDP 本身没有队头阻塞的问题,因此不会因为丢包导致整个连接的阻塞。
- QUIC 实现了类似于 TCP 的可靠性,但比 TCP 更高效,因为它减少了连接建立的延迟,并且能够更灵活地处理丢包问题。
减少握手次数
- HTTP/3 将 TCP 握手和 TLS 握手 的过程合并,减少了传统 6 次交互(3 次 TCP 握手 + 3 次 TLS 握手)为 3 次,显著降低了建立连接的延迟。
改进的头部压缩
- HTTP/3 使用 QPack头部压缩算法,相较于 HTTP/2 的 HPACK,QPack 进一步优化了头部压缩的效率。
流的独立性
- 由于 QUIC 允许每个流独立于其他流进行传输,HTTP/3 可以在流之间灵活处理丢包,确保不会因为某个流的丢包影响到其他流。
总结
- HTTP/1.1 相较于 HTTP/1.0 引入了 TCP 长连接和管道化技术,有效减少了连接建立的开销,提升了传输效率,但仍然面临头部压缩不足、队头阻塞等瓶颈。
- HTTP/2在此基础上进一步改进了性能,主要通过头部压缩、二进制格式、多路复用、服务器推送等技术提升了响应速度,并解决了队头阻塞问题。
- HTTP/3 则通过基于 QUIC 协议,改用 UDP 解决了 HTTP/2 的丢包和队头阻塞问题,进一步优化了连接的效率和可靠性。
HTTP其他重要知识点
HTTP状态码
常见的HTTP状态码分为五大类,每个状态码由三位数字组成,第一位数字表示类别:
1xx:信息响应
-
100 Continue:服务器已接收请求的初步部分,客户端应继续请求。
-
101 Switching Protocols:服务器同意切换协议,如从HTTP切换到WebSocket。
2xx:成功
-
200 OK:请求成功,服务器返回所请求的资源或数据。
-
201 Created:请求成功并创建了新的资源,常用于POST请求。
-
204 No Content:请求成功但服务器不返回任何内容,常用于删除操作。
3xx:重定向
-
301 Moved Permanently:资源已永久移动到新的URL,客户端应使用新URL访问。
-
302 Found:资源临时移动到新的URL,客户端应继续使用原来的URL。
-
304 Not Modified:资源未修改,客户端可以使用缓存版本。
4xx:客户端错误
-
400 Bad Request:请求无效或语法错误,服务器无法处理。
-
401 Unauthorized:请求需要身份验证,客户端未提供有效的凭证。
-
403 Forbidden:服务器理解请求但拒绝执行,通常是权限问题。
-
404 Not Found:请求的资源在服务器上未找到。
5xx:服务器错误
-
500 Internal Server Error:服务器内部错误,无法完成请求。
-
502 Bad Gateway:服务器作为网关或代理,从上游服务器接收到无效响应。
-
503 Service Unavailable:服务器暂时无法处理请求,通常是因为过载或维护。
HTTP常见字段
Host 字段:客户端发送请求时,⽤来指定服务器的域名。
Content-Length 字段:服务器在返回数据时,会有 Content-Length 字段,表明本次回应的数据⻓度。
Connection 字段:Connection 字段最常⽤于客户端要求服务器使⽤ TCP 持久连接,以便其他请求复⽤。
Content-Type 字段: Content-Type 字段⽤于服务器回应时,告诉客户端,本次数据是什么格式。
Content-Encoding 字段: Content-Encoding 字段说明数据的压缩⽅法。表示服务器返回的数据使⽤了什么压缩格式。
HTTP 中的GET和POST的概念和区别
概念
GET:用于获取资源,通常用于请求数据而不改变服务器状态。
POST:用于提交数据到服务器,通常会改变服务器的状态或产生副作用(如创建或更新资源)。
区别
参数传递方式
GET:参数通过URL拼接传递,暴露在请求URL中,具有可见性,长度有限(取决于浏览器和服务器)。
POST:参数放在请求体中,通常不可见且长度理论上没有限制,更适合传递大量数据或敏感信息。
安全性
GET:参数可见,数据容易暴露在浏览器历史记录、日志和缓存中,不适合传递敏感信息。
POST:数据放在请求体中,相对安全,但需要HTTPS才能保证数据加密传输。
幂等性
GET:幂等(重复请求不会改变服务器状态)。
POST:非幂等(多次请求可能导致重复创建资源或执行多次相同操作)。
HTTPS
HTTP 与 HTTPSHTTP 与 HT