概述

http是一个简单的请求-响应协议,它通常运行在TCP之上。它指定了客户端可能发送给服务器什么样的消息以及得到什么样的响应。请求和响应消息的头以ASCII码形式给出;而消息内容则具有一个类似MIME的格式。这个简单模型是早期Web成功的有功之臣,因为它使得开发和部署是那么的直截了当。

万维网WWW(world wide web)发源于欧洲日内瓦量子物理实验室CERN,正是WWW技术的出现使得因特网得以超乎想象的速度迅猛发展。这项基于TCP/IP的技术在短短的十年时间内迅速成为已经发展了几十年的Internet上的规模最大的信息系统,它的成功归结于它的简单、实用。在WWW的背后有一系列的协议和标准支持它完成如此宏大的工作,这就是Web协议族,其中就包括HTTP超文本传输协议。

在1990年,HTTP就成为WWW的支撑协议。当时由其创始人WWW之父蒂姆·贝纳斯·李(TimBemers—Lee)提出,随后WWW联盟(WWW Consortium)成立,组织了IETF(Internet Engineering Task Force)小组进一步完善和发布HTTP协议。
HTTP是应用层协议,同其他应用层协议一样,是为了实现某一类具体应用的协议,并由某一运行在用户空间的应用程序来实现其功能。HTTP是一种协议规范,这种规范记录在文档上,为真正通过HTTP协议进行通信的HTTP的实现程序。
HTTP协议是基于C/S架构进行通信的,而HTTP协议的服务器端实现程序有httpd、nginx等,其客户端的实现程序主要是Web浏览器,例如Firefox、InternetExplorer、Google chrome、Safari、Opera等,此外,客户端的命令行工具还有elink、curl等。Web服务是基于TCP的,因此为了能够随时响应客户端的请求,Web服务器需要监听在80/TCP端口。这客户端浏览器和Web服务器之间就可以通过HTTP协议进行通信了。

从 HTTP/1到HTTP/2

如今的生活中已经离不开互联网,智能家居、在线支付、网上购物都需要互联网的支持。互联网切切实实地给生活带来了诸多便利。有了互联网,我们可以呆在空调房里,一边刷着微博,一边等透心凉的西瓜送到手上,安安静静地做一个吃瓜群众。

互联网的建立打破了地域限制,用户直接上网就可以浏览到各种信息。用户上网的过程,即浏览器向服务端发送请求,然后将服务端主机上的内容显示到本地。而浏览器与服务器之间,走的就是 HTTP 协议。HTTP(Hypertext Transfer Protocol),超文本传输协议,它是应用层协议。由于其简捷、快速的方式,适用于分布式和合作式超媒体信息系统。自 1990 年起,HTTP 就已经被应用于万维网(WWW)全球信息服务系统。

HTTP 协议发展至今已经更新迭代了多个版本,下面我们来看看 HTTP 的发展史。

最原始的 HTTP/0.9

已过时的 HTTP/0.9 是 HTTP 协议的第一个版本,诞生于 1989 年。它的组成极其简单,只允许客户端发送 GET 这一种请求,而且不支持请求头。由于没有协议头,所以 HTTP/0.9 只能支持一种内容——纯文本。服务器只能回应 HTML 格式的字符串,不能回应别的格式。服务器发送完毕后,就会关闭 TCP 连接。

HTTP/0.9 具有典型的无状态性,每个访问都独立处理,处理完成后就会断开连接。如果请求的页面不存在,也不会返回任何错误码。

进化后的 HTTP/1

HTTP/1 是 HTTP 1.0 和 HTTP 1.1 的统称,分别指 HTTP 协议的版本是 1.0 和 1.1。
HTTP 1.0 是 HTTP 协议的第二个版本,至今仍被广泛采用。它在 HTTP/0.9 的基础上做了大量的扩充和改进,包括:
可以发送更多格式的内容,如图像、视频、二进制文件,不仅仅局限于文本了
在 GET 的基础上,增加了 HEAD 和 POST 请求方法
改变了 HTTP 请求和回应的格式。除了数据部分,每次通信都必须包括头信息(HTTP Header),用来描述一些元数据,即增加了请求头信息
新增了响应状态码(status code)、多字符集支持、权限(authorization)、缓存(cache)、内容编码(content encoding)等功能
虽然还是无状态协议,不过在请求(request)中增加 了“Connection: keep-alive”Header 头后就能支持长连接
更新后的 HTTP 1.0 相比之前变化尤其大,支持的功能也很丰富,但仍有诸多缺点。
HTTP 1.0 默认不支持长连接,这样就增加了 TCP 连接次数,造成开销浪费。HTTP 1.0 所保持的 TCP 每次只能处理一个请求,虽然能一次性接收多个请求,但是还是得按顺序一次处理一个请求,这样在后续请求等待前序请求完成时,很容易造成阻塞。同时,它还不支持断点续传。
这时,HTTP 1.1 登场了。它也是目前主流的 HTTP 协议版本,相比于 HTTP 1.0,它有了明显的优势:
加强和优化长连接

HTTP 1.1 支持长连接和请求的流水线处理,在一个 TCP 连接上可以传送多个 HTTP 请求和响应,减少了建立和关闭连接的消耗和延迟。在 HTTP 1.1 中默认开启 “Connection: keep-alive”,一定程度上弥补了 HTTP 1.0 每次请求都要创建连接的缺点。

http工作原理
缓存支持
所有 HTTP 1.1 请求里的响应头都包含了“Date:”标头,因此每个 Response 都为缓存添加了时间戳。
请求头引入了 range 头域
它允许只请求资源的某个部分,即返回状态码是 206(Partial Content),这样就方便了开发者自由的选择,以便于充分的利用带宽和连接。
采用分块传输编码
对于一些很耗时的动态操作,服务器需要等到所有操作完成后才能发送数据,显然这样的效率不高。更好的处理方法是,产生一块数据,就发送一块,采用流模式来取代缓存模式。
新增了多个请求方法和错误状态码
包括 PUT、PATCH、HEAD、OPTIONS、DELETE。另外,客户端请求的头信息中新增了 Host 字段,用来指定服务器的域名。同时新增了 24 个错误状态码。
http状态返回码详解(点我展开)

HTTP 返回码详解


200 服务器成功返回网页
404 请求的网页不存在
503 服务不可用

1xx(临时响应)

表示临时响应并需要请求者继续执行操作的状态代码。

100(继续)请求者应当继续提出请求。 服务器返回此代码表示已收到请求的第一部分,正在等待其余部分。  
101(切换协议)请求者已要求服务器切换协议,服务器已确认并准备切换。

2xx (成功)

表示成功处理了请求的状态代码。

200(成功)服务器已成功处理了请求。通常,这表示服务器提供了请求的网页。
201(已创建)请求成功并且服务器创建了新的资源。
202(已接受) 服务器已接受请求,但尚未处理。
203(非授权信息)服务器已成功处理了请求,但返回的信息可能来自另一来源。
204(无内容)服务器成功处理了请求,但没有返回任何内容。
205(重置内容)服务器成功处理了请求,但没有返回任何内容。
206(部分内容)服务器成功处理了部分 GET 请求。

3xx (重定向)

表示要完成请求,需要进一步操作。 通常,这些状态代码用来重定向。

300(多种选择)针对请求,服务器可执行多种操作。 服务器可根据请求者 (user agent) 选择一项操作,或提供操作列表供请求者选择。
301(永久移动)请求的网页已永久移动到新位置。 服务器返回此响应(对 GET 或 HEAD 请求的响应)时,会自动将请求者转到新位置。
302(临时移动)服务器目前从不同位置的网页响应请求,但请求者应继续使用原有位置来进行以后的请求。
303(查看其他位置)请求者应当对不同的位置使用单独的 GET 请求来检索响应时,服务器返回此代码。
304(未修改)自从上次请求后,请求的网页未修改过。 服务器返回此响应时,不会返回网页内容。
305(使用代理)请求者只能使用代理访问请求的网页。 如果服务器返回此响应,还表示请求者应使用代理。
307(临时重定向)服务器目前从不同位置的网页响应请求,但请求者应继续使用原有位置来进行以后的请求。

4xx(请求错误)

这些状态代码表示请求可能出错,妨碍了服务器的处理。

400(错误请求)服务器不理解请求的语法。
401(未授权)请求要求身份验证。 对于需要登录的网页,服务器可能返回此响应。
403(禁止)服务器拒绝请求。
404(未找到)服务器找不到请求的网页。
405(方法禁用)禁用请求中指定的方法。
406(不接受)无法使用请求的内容特性响应请求的网页。
407(需要代理授权)此状态代码与 401(未授权)类似,但指定请求者应当授权使用代理。
408(请求超时)服务器等候请求时发生超时。
409(冲突)服务器在完成请求时发生冲突。 服务器必须在响应中包含有关冲突的信息。
410(已删除)如果请求的资源已永久删除,服务器就会返回此响应。
411(需要有效长度)服务器不接受不含有效内容长度标头字段的请求。
412(未满足前提条件)服务器未满足请求者在请求中设置的其中一个前提条件。
413(请求实体过大)服务器无法处理请求,因为请求实体过大,超出服务器的处理能力。
414(请求的 URI 过长)请求的 URI(通常为网址)过长,服务器无法处理。
415(不支持的媒体类型)请求的格式不受请求页面的支持。
416(请求范围不符合要求)如果页面无法提供请求的范围,则服务器会返回此状态代码。
417(未满足期望值)服务器未满足”期望”请求标头字段的要求。

5xx(服务器错误)

这些状态代码表示服务器在尝试处理请求时发生内部错误。 这些错误可能是服务器本身的错误,而不是请求出错。

500(服务器内部错误)服务器遇到错误,无法完成请求。
501(尚未实施)服务器不具备完成请求的功能。 例如,服务器无法识别请求方法时可能会返回此代码。
502(错误网关)服务器作为网关或代理,从上游服务器收到无效响应。
503(服务不可用)服务器目前无法使用(由于超载或停机维护)。 通常,这只是暂时状态。
504(网关超时)服务器作为网关或代理,但是没有及时从上游服务器收到请求。
505(HTTP 版本不受支持)服务器不支持请求中所用的 HTTP 协议版本。


HTTP 1.1 虽然增加了很多功能,但是它自身仍然有很多不足。由于各个请求到达服务器的速度不同,如果先发的请求先到达可能会发生阻塞,剩下所有的请求都会被阻塞在那次请求应答之后,这样就降低了带宽。

增强后的 HTTP/2

随着 Web 技术的飞速发展,HTTP 1.1 已经无法满足用户对性能的要求,此后 Google 推出协议 SPDY,意在解决 HTTP 1.1 中广为人知的性能问题。HTTP/2 因此应运而生,它是 HTTP 协议自 1999 年 HTTP 1.1 发布后的首个更新,主要基于 SPDY 协议。
那 HTTP/2 到底有哪些具体变化呢?
多路复用:HTTP/2 使用多路复用技术,使用一个 TCP 连接并发处理多个请求,不但节约了开销而且可处理请求的数量也比 HTTP 1.1 大了很多
数据传输:HTTP/2 采用二进制格式传输数据,而非 HTTP 1.x 的文本格式,二进制协议解析起来更高效
头部压缩:HTTP 1.1 不支持 Header 数据压缩,HTTP/2 使用 HPACK 算法对 Header 的数据进行压缩,使得数据传输更快
服务器推送(Server Push):当对支持 HTTP/2 的服务器请求数据的时候,服务器会顺便把一些客户端需要的资源一起推送到服务器,这种方式适用于加载静态资源,节约带宽

即将到来的 HTTP/3

就像 HTTP/1 到 HTTP/2 一样,HTTP/3 到来同样有着它的重要任务。

由于 HTTP/2 是基于 HTTP/1 的升级,因此第一个版本中发现的许多核心问题都会向前延伸。其中就包括 TCP 协议在整个互联网上实施的方式所带来的问题:HTTP/2 使用了多路复用,一般来说同一个地址只需要使用一个 TCP 连接;单连接最终会成为网络质量较差的环境中的数据瓶颈 - 网络质量下降更容易出现丢包,导致在重传期间不能传输其他数据,势必会降低整个请求的处理速度。

修改 TCP 协议显然是不可能的,因此 HTTP/3 引用了基于 UDP 的 QUIC 协议,并有望成为 HTTP 协议的第三个正式版本。HTTP/3 曾用名 HTTP-over-QUIC,QUIC 代表“快速 UDP 互联网连接”,本身就是 Google 试图将 TCP 协议重写进而改进出来的一种技术,它结合了 HTTP/2,TCP,UDP 和 TLS(用于加密)等等。
QUIC协议原理

针对 HTTP/2 的软肋,HTTP/3 和 QUIC 弥补了前者的不足。QUIC 使用 UDP 协议,它在两个端点间创建连线,且支持多路复用连线。QUIC 能够提供等同于 SSL/TLS 层级的网络安全保护,减少数据传输及创建连线时的延迟时间,双向控制带宽,以避免网络拥塞。Google 希望使用这个协议来取代 TCP 协议,使网页传输速度更快。

展望未来

有些人认为,目前 HTTP/2 的标准尚未完全采用,推出 HTTP/3 可能还为时尚早。这确实是一个有效的观点,但是正如我们所看到的,这个协议已经得到了世界大规模的测试和实现。谷歌早在 2015 年就已经开始测试,并且在 2017 年 Facebook 也进行了测试。

从概念上讲,HTTP/3 是一个出色的协议。但是,在当前的应用程序中实现,仍然需要进行大量的迭代更新。虽然 QUIC 和 UDP 的结合为 Google 提供了出色的使用示例,但 IETF(互联网工程任务组)标准认为仍未达到目标。网站管理者应该根据自身实际情况进行权衡,来确定哪个协议适合自己的网站,这样才是正确的做法。
未来如何,我们拭目以待!


版权属于:Digran(InetGeek)

本文链接:https://digran.cn/archives/170/

插件TePay的配置信息没有找到

Typecho_Plugin_Exception: 插件TePay的配置信息没有找到 in /www/wwwroot/www.digran.cn/var/Widget/Options.php:560 Stack trace: #0 /www/wwwroot/www.digran.cn/usr/plugins/TePay/Plugin.php(150): Widget_Options->plugin('TePay') #1 /www/wwwroot/www.digran.cn/usr/themes/handsome/post.php(92): TePay_Plugin::getTePay() #2 /www/wwwroot/www.digran.cn/var/Widget/Archive.php(2022): require_once('/www/wwwroot/ww...') #3 /www/wwwroot/www.digran.cn/var/Typecho/Router.php(138): Widget_Archive->render() #4 /www/wwwroot/www.digran.cn/index.php(23): Typecho_Router::dispatch() #5 {main}