HTTP(一): 基础

一、历史

1.1 概述

超文本传输协议英文HyperText Transfer Protocol缩写HTTP)是互联网上应用最为广泛的一种网络协议。设计HTTP最初的目的是为了提供一种发布和接收HTML页面的方法。通过HTTP或者HTTPS协议请求的资源由统一资源标识符(Uniform Resource Identifiers,URI)来标识。

HTTP的发展是由蒂姆·伯纳斯-李于1989年在欧洲核子研究组织(CERN)所发起。由万维网协会(World Wide Web Consortium,W3C)和互联网工程任务组(Internet Engineering Task Force,IETF)制定标准,最终发布了一系列的RFC,其中最著名的是1999年6月公布的 RFC 2616,定义了HTTP协议中现今广泛使用的一个版本——HTTP 1.1。

2014年12月,互联网工程任务组(IETF)的Hypertext Transfer Protocol Bis(httpbis)工作小组将HTTP/2标准提议递交至IESG进行讨论,于2015年2月17日被批准。HTTP/2标准于2015年5月以RFC 7540正式发表,取代HTTP 1.1成为HTTP的实现标准。

1.2 版本

超文本传输协议已经演化出了很多版本,它们中的大部分都是向下兼容的。在 RFC 2145 中描述了HTTP版本号的用法。客户端在请求的开始告诉服务器它采用的协议版本号,而后者则在响应中采用相同或者更早的协议版本。

1.2.1 HTPP/0.9

已过时。只接受GET一种请求方法,没有在通讯中指定版本号,且不支持请求头。由于该版本不支持POST方法,因此客户端无法向服务器传递太多信息。

1.2.2 HTTP/1.0

这是第一个在通讯中指定版本号的HTTP协议版本,至今仍被广泛采用,特别是在代理服务器中。

  • 无状态、无连接

  • 短连接,连接无法复用

    每一个请求建立一个TCP连接,请求完成后立马断开连接。这将会导致2个问题:连接无法复用,head of line blocking
    连接无法复用会导致每次请求都经历三次握手和慢启动。三次握手在高延迟的场景下影响较明显,慢启动则对文件类大请求影响较大。head of line blocking会导致带宽无法被充分利用,以及后续健康请求被阻塞。

1.2.3 HTTP/1.1

持久连接被默认采用,并能很好地配合代理服务器工作。还支持以管道方式在同时发送多个请求,以便降低线路负载,提高传输速度。HTTP/1.1相较于HTTP/1.0协议的区别主要体现在:

  • 长连接

    通过http pipelining实现。多个http 请求可以复用一个TCP连接,服务器端按照FIFO原则来处理不同的Request

  • 增加connection header
    该header用来说明客户端与服务器端TCP的连接方式,若connection为close则使用短连接,若connection为keep-alive则使用长连接
  • 状态管理:错误通知的管理
  • Cache缓存等机制相关的请求头和响应头
  • 增加Host header
  • 身份认证:安全性及完整性

1.2.4 HTTP/2

HTTP/2当前版本,于2015年5月作为互联网标准正式发布

  • 多路复用 (Multiplexing)

    多路复用允许同时通过单一的 HTTP/2 连接发起多重的请求-响应消息。在 HTTP/1 .1 协议中浏览器客户端在同一时间,针对同一域名下的请求有一定数量限制。超过限制数目的请求会被阻塞。这也是为何一些站点会有多个静态资源 CDN 域名的原因之一,拿 Twitter 为例,http://twimg.com,目的就是变相的解决浏览器针对同一域名的请求限制阻塞问题。而HTTP/2 的多路复用(Multiplexing) 则允许同时通过单一的 HTTP/2 连接发起多重的请求-响应消息。因此 HTTP/2 可以很容易的去实现多流并行而不用依赖建立多个 TCP 连接,HTTP/2 把 HTTP 协议通信的基本单位缩小为一个一个的帧,这些帧对应着逻辑流中的消息。并行地在同一个 TCP 连接上双向交换消息。

  • 二进制分帧

    HTTP/2在 应用层(HTTP/2)和传输层(TCP or UDP)之间增加一个二进制分帧层。在不改动 HTTP/1.x 的语义、方法、状态码、URI 以及首部字段的情况下, 解决了HTTP1.1 的性能限制,改进传输性能,实现低延迟和高吞吐量。在二进制分帧层中, HTTP/2 会将所有传输的信息分割为更小的消息和帧(frame),并对它们采用二进制格式的编码 ,其中 HTTP1.x 的首部信息会被封装到 HEADER frame,而相应的 Request Body 则封装到 DATA frame 里面。

  • 首部压缩(Header Compression)

    HTTP/1.1并不支持 HTTP 首部压缩,为此 SPDY 和 HTTP/2 应运而生, SPDY 使用的是通用的DEFLATE 算法,而 HTTP/2 则使用了专门为首部压缩而设计的 HPACK 算法。

    要求通讯双方各自缓存一份首部字段表,从而避免了重复传输。

  • 服务端推送

    是一种在客户端请求之前发送数据的机制。

    在 HTTP/2 中,服务器可以对客户端的一个请求发送多个响应。Server Push 让 HTTP1.x 时代使用内嵌资源的优化手段变得没有意义;如果一个请求是由你的主页发起的,服务器很可能会响应主页内容、logo 以及样式表,因为它知道客户端会用到这些东西。这相当于在一个 HTML 文档内集合了所有的资源,不过与之相比,服务器推送还有一个很大的优势:可以缓存!也让在遵循同源的情况下,不同页面之间可以共享缓存资源成为可能。

二、工作原理

2.1 基本概念

HTTP是一个客户端终端(用户)和服务器端(网站)请求和应答的标准。

一次HTTP操作称为一个事务,其工作过程可分为四步:建立连接、发送请求信息、发送响应信息、关闭连接。

  • 客户端:浏览器、网络爬虫或者其它的工具,也称为用户代理程序(user agent)。
  • 服务端:也称服务器,应答的服务器,资源服务器(origin server),存储着一些资源,比如HTML文件和图像。
  • 中介:代理(Proxy)、网关(Gateway)和通道(Tunnel)
    • 代理根据URI的绝对格式来接受请求,重写全部或部分消息,通过URI的标识把已格式化过的请求发送到服务器。
    • 网关是一个接收代理,作为一些其它服务器的上层,并且如果必须的话,可以把请求翻译给下层的服务器协议
    • 通道作为不改变消息的两个连接之间的中继点。当通讯需要通过一个中介(例如:防火墙等)或者是中介不能识别消息的内容时,通道经常被使用。
  • 在WWW中,“客户”与“服务器”是一个相对的概念,只存在于一个特定的连接期间,即在某个连接中的客户在另一个连接中可能作为服务器。基于HTTP协议的客户/服务器模式的信息交换过程。
  • HTTP协议中,未规定必须使用它或它支持的层。
    • 事实上,HTTP可以在任何互联网协议上,或其他网络上实现。
    • HTTP假定其下层协议提供可靠的传输。
    • 因此,任何能够提供这种保证的协议都可以被其使用。因此也就是其在TCP/IP协议族使用TCP作为其传输层。

2.2 运作方式

  1. 首先客户端与服务器需要建立连接。只要单击某个超级链接,HTTP的工作就开始了。

  2. 建立连接后,客户端发送一个请求给服务器,请求方式的格式为:统一资源标识符(URL)、协议版本号,后边是MIME信息包括请求修饰符、客户机信息和可能的内容。

  3. 服务器接到请求后,给予相应的响应信息,其格式为一个状态行,包括信息的协议版本号、一个成功或错误的代码,后边是MIME信息包括服务器信息、实体信息和可能的内容。

  4. 该次请求完成之后,关闭连接。

当一个或多个中介出现在请求/响应链中时,情况就变得复杂一些。

2.3 请求方法

HTTP/1.1协议中共定义了八种方法(也叫“动作”)来以不同方式操作指定的资源:

方法 说明 版本
HEAD 与GET方法一样,都是向服务器发出指定资源的请求。只不过服务器将不传回资源的实体部分。仅回传首部部分,即“关于该资源的信息”(元信息或称元数据) 1.0
GET 向指定的资源发出“显示”请求。使用GET方法应该只用在读取数据,而不应当被用于产生“副作用”的操作中,例如在Web Application中。其中一个原因是GET可能会被爬虫等随意访问 1.0
POST 向指定资源提交数据,请求服务器进行处理(例如提交表单或者上传文件)。数据被包含在请求本文中。这个请求可能会创建新的资源或修改现有资源,或二者皆有。 1.0
OPTIONS 这个方法可使服务器传回该资源所支持的所有HTTP请求方法。用’*’来代替资源名称,向Web服务器发送OPTIONS请求,可以测试服务器功能是否正常运作 1.1
PUT 向指定资源位置上传其最新内容 1.1
DELETE 请求服务器删除Request-URI所标识的资源 1.1
TRACE 回显服务器收到的请求,主要用于测试或诊断 1.1
CONNECT HTTP/1.1协议中预留给能够将连接改为管道方式的代理服务器。通常用于SSL加密服务器的链接(经由非加密的HTTP代理服务器) 1.1

方法名称是区分大小写的。当某个请求所针对的资源不支持对应的请求方法的时候,服务器应当返回状态码405(Method Not Allowed),当服务器不认识或者不支持对应的请求方法的时候,应当返回状态码501(Not Implemented)。

HTTP服务器至少应该实现GET和HEAD方法,其他方法都是可选的。当然,所有的方法支持的实现都应当匹配下述的方法各自的语义定义。此外,除了上述方法,特定的HTTP服务器还能够扩展自定义的方法。例如:

  • PATCH(由 RFC 5789 指定的方法):用于将局部修改应用到资源。

2.4 安全方法

对于GET和HEAD方法而言,除了进行获取资源信息外,这些请求不应当再有其他意义。也就是说,这些方法应当被认为是“安全的”。 客户端可能会使用其他“非安全”方法,例如POST,PUT及DELETE,应该以特殊的方式(通常是按钮而不是超链接)告知客户可能的后果(例如一个按钮控制的资金交易),或请求的操作可能是不安全的(例如某个文件将被上传或删除)。

但是,不能想当然地认为服务器在处理某个GET请求时不会产生任何副作用。事实上,很多动态资源会把这作为其特性。这里重要的区别在于用户并没有请求这一副作用,因此不应由用户为这些副作用承担责任。

2.5 副作用

假如在不考虑诸如错误或者过期等问题的情况下,若干次请求的副作用与单次请求相同或者根本没有副作用,那么这些请求方法就能够被视作“幂等”的。GET,HEAD,PUT和DELETE方法都有这样的幂等属性,同样由于根据协议,OPTIONS,TRACE都不应有副作用,因此也理所当然也是幂等的。

假如某个由若干个请求做成的请求序列产生的结果在重复执行这个请求序列或者其中任何一个或多个请求后仍没有发生变化,则这个请求序列便是“幂等”的。但是,可能出现若干个请求做成的请求序列是“非幂等”的,即使这个请求序列中所有执行的请求方法都是幂等的。例如,这个请求序列的结果依赖于某个会在下次执行这个序列的过程中被修改的变量。

2.6 持续连接

在HTTP 0.9和1.0使用非持续连接,在非持续连接下,每个tcp只连接一个web对象,连接在每个请求-回应对后都会关闭,一个连接可被多个请求重复利用的保持连接机制被引入。这种连接持续化显著地减少了请求延迟,因为客户不用在首次请求后再次进行TCP交互确认创建连接。现在在HTTP 1.1使用持续连接,不必为每个web对象创建一个新的连接,一个连接可以传送多个对象。 HTTP1.1还进行了带宽优化,例如1.1引入了分块传输编码来允许流化传输持续连接上发送的内容,取代原先的buffer式传输。HTTP管道允许客户在上一个回应被收到前发送多重请求从而进一步减少了延迟时间。

另一项协议的改进是byte serving(字节服务),允许服务器根据客户的请求仅仅传输资源的一部分。

2.7 重定向

指当用户浏览某个网址时,将他导向到另一个网址的技术。

出于下列目的,可能会进行重定向:

  • 相似网域名称
  • 移动网站至新网域
  • 记录外送链接
  • 简化网址
  • 局部地区的使用限制

重定向返回的状态码,为3**,详见状态码

2.8 转发

指当用户请求某个地址时,服务器去另一个网址请求资源并将获得的资源返回给用户。

2.8.1 与重定向的区别

简单来说,转发是服务器行为,重定向是客户端行为。

  1. 转发过程:客户浏览器发送http请求—> web服务器接受此请求 —>调用内部的一个方法在容器内部完成请求处理和转发动作—>将目标资源发送给客户

在这里,转发的路径必须是同一个web容器下的url,其不能转向到其他的web路径上去,中间传递的是自己的容器内的request。在客户浏览器路径栏显示的仍然是其第一次访问的路径,整个过程对客户端透明。转发行为是浏览器只做了一次访问请求。

  1. 重定向过程:客户浏览器发送http请求—> web服务器接受后发送3xx状态码响应,及对应新的location给客户浏览器—>客户浏览器发现是3xx响应,则自动再发送一个新的http请求,请求url是新的location地址—>服务器根据此请求寻找资源并发送给客户。

在这里 location可以重定向到任意URL,既然是浏览器重新发出了请求,则就没有什么request传递的概念了。在客户浏览器路径栏显示的是其重定向的路径,客户可以观察到地址的变化的。重定向行为是浏览器做了至少两次的访问请求的。

  • 地址栏显示

forward:保持原来地址

redirect:会从原来地址,变换为新的重定向地址

  • 数据共享

forward:转发页面和转发到的页面可以共享request里面的数据
redirect:两次不同的请求,无法共享数据

参考

链接

  1. IEIF doc
  2. URL redirection wiki