什么是 HTTP 协议?

简介: HTTP 协议不用我多说了吧,大家都知道,现在我 web 开发一般都是使用 HTTP 协议来进行通信的。到目前为止,HTTP 进行了几次版本更新,HTTP 1.1 就是表示HTTP 的 1.1 版本。1.1 版本也是目前大部分网站所用的版本。

网络异常,图片无法展示
|

版本介绍


HTTP 协议不用我多说了吧,大家都知道,现在我 web 开发一般都是使用 HTTP 协议来进行通信的。到目前为止,HTTP 进行了几次版本更新,HTTP 1.1 就是表示HTTP 的 1.1 版本。1.1 版本也是目前大部分网站所用的版本。

HTTP 0.9

  • 发布时间:1991 年
  • 简介:梦开始的地方,只接受GET一种请求方法,没有在通讯中指定版本号,且不支持请求头。由于该版本不支持POST方法,因此客户端无法向服务器传递太多信息。

HTTP 1.0

  • 发布时间:1996 年 5 月
  • 简介:这是第一个在通讯中指定版本号的HTTP协议版本。同时比 0.9 版本增加大量新特性。非持续连接,每次都要重新与服务器建立连接。

HTTP 1.1

  • 发布时间:1997 年1月
  • 简介:默认采用持续连接(Connection: keep-alive),能很好地配合代理服务器工作。还支持以管道方式在同时发送多个请求,以便降低线路负载,提高传输速度。同时这也是目前最流行的版本。

HTTP/1.1相较于HTTP/1.0协议的区别主要体现在:

  • 缓存处理
  • 带宽优化及网络连接的使用
  • 错误通知的管理
  • 消息在网络中的发送
  • 互联网地址的维护
  • 安全性及完整性

HTTP 2.0

  • 发布时间:2015 年 5 月
  • 简介:HTTP/2 是 HTTP 协议自 1999 年 HTTP 1.1 的改进版 RFC 2616 发布后的首个更新,主要基于 SPDY 协议。它由互联网工程任务组(IETF)的Hypertext Transfer Protocol Bis(httpbis)工作小组进行开发。该组织于 2014 年 12 月将 HTTP/2 标准提议递交至 IESG 进行讨论,于 2015 年 2 月 17 日被批准。

报文格式


请求报文

请求报文分为 4 个部分,分别是请求行、请求头、换行行、请求数据,每个部分的末尾都会带上回车符(CR,ASCII:0d)和换行符(LF,ASCII:0a)

其中请求行分为请求方法、请求的 URL 地址、HTTP 版本号,每个字段用空格(ASCII:20)来分隔

请求头部分可以有多行,每行用回车符和换行符区分

网络异常,图片无法展示
|

为了方便理解,我们可以用 Wireshark 来抓取一个 HTTP 请求来看看,并把它和上图进行关联

网络异常,图片无法展示
|

响应报文

响应报文和请求报文基本差不多,唯一有区别就第一行状态行和请求报文的第一行请求行有区别。

状态行也分为三个部分,分别是 HTTP 版本、状态码、状态码描述,每个部分用空格进行分隔。

响应头和请求头一样,可以有多行

网络异常,图片无法展示
|

同样,用 Wireshark 抓取一个响应报文,来和上图进行一一对应。

网络异常,图片无法展示
|

持续连接和非持续连接

上面说了,HTTP 1.1 的连接由原来的非持续连接变为了持续连接(Connection: keep-alive)。那么这两个有什么区别呢?

非持续连接指的是当向服务器多次请求资源时,每次都需要单独的进行 TCP 的连接和断开。

持续连接指的是当向服务器请求资源时,可以共用一个 TCP 连接来进行资源的传输。

尽管 HTTP 1.1 默认使用持续连接,但是也可以配置为非持续连接,设置方法:Connection 字段设置为 close

为了好理解,为画了一张图,图中省略了 TCP 建立连接和断开连接的细致步骤。

网络异常,图片无法展示
|

请求方法

一般我们常用的只有 GET 和 POST 两个请求方法,但是如果遵循 REST 风格来进行 API 接口的设计,就可以用到下面的一些请求方法了。

  • OPTIONS:这个方法会请求服务器返回该资源所支持的所有HTTP请求方法
  • GET:获取指定资源地址的数据,不推荐进行上传数据等操作。
  • HEAD:服务器在响应 HEAD 请求时不会回传 Body 资源的内容部分,这样,我们可以不传输全部内容的情况下,就可以获取服务器的响应头信息。
  • POST:POST 请求会 向指定资源提交数据,请求服务器进行处理,请求数据会被包含在请求体中。
  • PUT:可以将指定资源的最新数据传送给服务器取代指定的资源的内容。
  • DELETE:删除指定资源的数据。
  • TRACE:TRACE 请求服务器回显其收到的请求信息,该方法主要用于 HTTP 请求的测试或诊断。
  • ......

响应码


1xx

Informational(信息性状态码),表示接收的请求正在处理,具体可以查看 RFC 文档

2xx

Success(成功状态码),请求正常处理完毕,具体可以查看 RFC 文档

3xx

Redirection(重定向状态码),需要进行附加操作以完成请求,具体可以查看 RFC 文档

4xx

Client Error(客户端错误状态码),服务器无法处理请求,具体可以查看 RFC 文档

5xx

Server Error(服务器错误状态码),服务器处理请求出错,具体可以查看 RFC 文档

目录
相关文章
|
4月前
|
数据采集 数据可视化 API
QUIC协议优化:HTTP/3环境下的超高速异步抓取方案
本文介绍了一种基于QUIC和HTTP/3的异步爬虫方案,用于抓取知乎热榜数据并生成趋势图。通过HTTPX与aioquic结合实现高性能连接复用,配合代理IP绕过反爬限制,提取标题、热度等信息。利用Python代码示例展示了异步抓取流程,并借助Matplotlib绘制话题热度变化图表。分析显示突发热点生命周期短,而深度话题热度更稳定。此方案可优化内容运营策略,快速捕捉潜在爆款话题。
177 4
QUIC协议优化:HTTP/3环境下的超高速异步抓取方案
|
2月前
|
缓存 监控 搜索推荐
301重定向实现原理全面解析:从HTTP协议到SEO最佳实践
301重定向是HTTP协议中的永久重定向状态码,用于告知客户端请求的资源已永久移至新URL。它在SEO中具有重要作用,能传递页面权重、更新索引并提升用户体验。本文详解其工作原理、服务器配置方法(如Apache、Nginx)、对搜索引擎的影响及最佳实践,帮助实现网站平稳迁移与优化。
429 68
|
1月前
HTTP协议中请求方式GET 与 POST 什么区别 ?
GET和POST的主要区别在于参数传递方式、安全性和应用场景。GET通过URL传递参数,长度受限且安全性较低,适合获取数据;而POST通过请求体传递参数,安全性更高,适合提交数据。
320 2
|
2月前
|
存储 网络协议 安全
HTTP 协议及会话跟踪机制详解
本文详解了 HTTP 协议的核心知识,包括其定义(超文本传输协议,基于 TCP,规定客户端与服务器通信规则)及与 HTTPS 的区别(安全性、端口、资源消耗)。 介绍了 GET 与 POST 请求的差异(参数限制、安全性、应用场景),以及 Restful 风格(通过 URL 定位资源,请求方式决定操作)。列举了常见 HTTP 状态码(如 200 成功、404 资源未找到),对比了转发与重定向的区别(服务器端一次请求 vs 客户端两次请求)。 还阐述了会话跟踪机制:Cookie 基于客户端存储,通过Set-Cookie和Cookie头实现,安全性较低;Session 基于服务端存储,依赖 C
233 1
|
1月前
|
缓存 网络协议 UED
深度解析HTTP协议从版本0.9至3.0的演进和特性。
总的来说,HTTP的演进是互联网技术不断发展和需求日益增长的结果。每一次重要更新都旨在优化性能,增进用户体验,适应新的应用场景,而且保证了向后兼容,让互联网的基础架构得以稳定发展。随着网络技术继续进步,我们可以预期HTTP协议在未来还会继续演化。
336 0
|
2月前
|
XML 安全 网络架构
深度对比SOAP与HTTP协议:详细理解它们的工作原理和差异
在设计服务和系统交云策略时,考虑到上述差异是至关重要的。SOAP适合需要高安全性、可靠性和事务支持的企业级应用。而HTTP适合Web界面浏览、RESTful服务和需要快速响应的轻量级通信。根据具体需求和上下文,开发者可以选择合适的协议以实现最优的系统性能和用户体验。
283 0
|
3月前
|
缓存
HTTP协议深度剖析:常见请求头信息讲解
这就是HTTP请求头背后的工作原理,希望通过比作“邮差”和“标签”,可以让你对这个繁琐技术更有感触,更得心应手。尽管这些信息可能很琐碎,但了解了它们的含义和工作方式,就等于揭开了HTTP协议神秘的面纱,掌控了网络交流的核心。你还等什么,赶快动手尝试一下吧!
129 17
|
2月前
HTTP协议中常见的状态码 ?
HTTP协议状态码分为1xx、2xx、3xx、4xx、5xx五类。常见状态码包括:101(切换协议)、200(请求成功)、302(重定向)、401(未认证)、404(资源未找到)、500(服务器错误)。
271 0
|
3月前
HTTP协议探究:常用方法一网打尽
总的来说,HTTP协议的命令犹如一把钥匙,解锁了互联网世界的大门。它是规则,也是工具,了解了它,就等于掌握了互联网的一把通行证。我们每天都在用,也常常无视它,但是只有深刻理解了它,才能更好地运用它。如此,我们的互联网世界旅程就会变得更加顺畅,更加有趣。
109 14