HTTP协议（六）

1. HTTP报文首部

在这里插入图片描述
HTTP 协议的请求和响应报文中必定包含 HTTP 首部。首部内容为客户端和服务器分别处理请求和响应提供所需要的信息。

HTTP请求报文
在请求中，HTTP 报文由方法、URI、HTTP 版本、HTTP 首部字段等部分构成。
在这里插入图片描述

示例：

GET / HTTP/1.1
Host: hackr.jp
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/⇒
20100101 Firefox/13.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,⇒
*/*; q=0.8
Accept-Language: ja,en-us;q=0.7,en;q=0.3
Accept-Encoding: gzip, deflate
DNT: 1
Connection: keep-alive
If-Modified-Since: Fri, 31 Aug 2007 02:02:20 GMT
If-None-Match: "45bae1-16a-46d776ac"
Cache-Control: max-age=0

 

HTTP响应报文
在响应中，HTTP 报文由 HTTP 版本、状态码（数字和原因短语）、HTTP 首部字段 3 部分构成。
在这里插入图片描述

示例：

HTTP/1.1 304 Not Modified
Date: Thu, 07 Jun 2012 07:21:36 GMT
Server: Apache
Connection: close
Etag: "45bae1-16a-46d776ac"

 

1.1 通用首部字段 via
使用首部字段 Via 是为了追踪客户端与服务器之间的请求和响应报文的传输路径。报文经过代理或网关时，会先在首部字段 Via 中附加该服务器的信息，然后再进行转发。这个做法和 traceroute 及电子邮件的 Received 首部的工作机制很类似。首部字段 Via 不仅用于追踪报文的转发，还可避免请求回环的发生。所以必须在经过代理时附加该首部字段内容。

在这里插入图片描述

1.2 通用首部字段 warning
HTTP/1.1 的 Warning 首部是从 HTTP/1.0 的响应首部（Retry-After）演变过来的。该首部通常会告知用户一些与缓存相关的问题的警告。
在这里插入图片描述

常见警告码：
在这里插入图片描述

在这里插入图片描述

1.3 请求首部字段Accept
Accept 首部字段可通知服务器，用户代理能够处理的媒体类型及媒体类型的相对优先级。 可使用 type/subtype 这种形式，一次指定多种媒体类型。
在这里插入图片描述

1.4 请求首部字段 Host
首部字段 Host 会告知服务器，请求的资源所处的互联网主机名和端口号。Host 首部字段在 HTTP/1.1 规范内是唯一一个必须被包含在请求内的首部字段。
首部字段 Host 和以单台服务器分配多个域名的虚拟主机的工作机制有很密切的关联，这是首部字段 Host 必须存在的意义。
请求被发送至服务器时，请求中的主机名会用 IP 地址直接替换解决。但如果这时，相同的 IP 地址下部署运行着多个域名，那么服务器就会无法理解究竟是哪个域名对应的请求。因此，就需要使用首部字段Host 来明确指出请求的主机名。若服务器未设定主机名，那直接发送一个空值即可。
在这里插入图片描述
1.5 响应首部字段 Location
使用首部字段 Location 可以将响应接收方引导至某个与请求 URI位置不同的资源。几乎所有的浏览器在接收到包含首部字段 Location 的响应后，都会强制性地尝试对已提示的重定向资源的访问。
在这里插入图片描述

1.6 响应首部字段 Server
首部字段 Server 告知客户端当前服务器上安装的 HTTP 服务器应用程序的信息。不单单会标出服务器上的软件应用名称，还有可能包括版本号和安装时启用的可选项。
在这里插入图片描述

示例：

Server: Apache/2.2.6 (Unix) PHP/5.2.5

 

2. 确保Web安全的HTTPS

2.1 首先提一下HTTP的缺点
到现在为止，我们已了解到 HTTP 具有相当优秀和方便的一面，然而 HTTP 并非只有好的一面，事物皆具两面性，它也是有不足之处的。

  • 通信使用明文（不加密），内容可能会被窃听
  • 不验证通信方的身份，因此有可能遭遇伪装
  • 无法证明报文的完整性，所以有可能已遭篡改

这些问题不仅在HTTP 上出现，其他未加密的协议中也会存在这类问题。

2.1.1 通信的加密
针对HTTP通信使用明文（不加密），内容可能会被窃听这个问题，现在研究的几种对策中，最为普及的就是加密技术。

一种方式就是将通信加密。HTTP 协议中没有加密机制，但可以通过和 SSL（Secure Socket Layer，安全套接层）或 TLS（Transport Layer Security，安全层传输协议）的组合使用，加密 HTTP 的通信内容。用 SSL 建立安全通信线路之后，就可以在这条线路上进行 HTTP通信了。与 SSL 组合使用的 HTTP 被称为 HTTPS（HTTP Secure，超文本传输安全协议）或 HTTP over SSL。
在这里插入图片描述
还有一种方式是将参与通信的内容本身加密。由于 HTTP 协议中没有加密机制，那么就对 HTTP 协议传输的内容本身加密。即把 HTTP 报文里所含的内容进行加密处理。在这种情况下，客户端需要对 HTTP 报文进行加密处理后再发送请求。
在这里插入图片描述
诚然，为了做到有效的内容加密，前提是要求客户端和服务器同时具备加密和解密机制。主要应用在 Web 服务中。有一点必须引起注意，由于该方式不同于SSL 或 TLS 将整个通信线路加密处理，所以内容仍有被篡改的风险。

2.1.2 不验证通信方的身份就可能遭遇伪装
HTTP 协议中的请求和响应不会对通信方进行确认。也就是说存在“服务器是否就是发送请求中 URI 真正指定的主机，返回的响应是否真
的返回到实际提出请求的客户端”等类似问题。
任何人都可以发起请求，HTTP收到请求就会返回响应
在 HTTP 协议通信时，由于不存在确认通信方的处理步骤，任何人都可以发起请求。另外，服务器只要接收到请求，不管对方是谁都会返回一个响应（但也仅限于发送端的 IP 地址和端口号没有被 Web 服务器设定限制访问的前提下）。因此而不确认通信方，会存在以下各种隐患。

  • 无法确定请求发送至目标的 Web 服务器是否是按真实意图返回响应的那台服务器。有可能是已伪装的 Web 服务器。
  • 无法确定响应返回到的客户端是否是按真实意图接收响应的那个客户端。有可能是已伪装的客户端。
  • 无法确定正在通信的对方是否具备访问权限。因为某些 Web 服务器上保存着重要的信息，只想发给特定用户通信的权限。
  • 无法判定请求是来自何方、出自谁手。
  • 即使是无意义的请求也会照单全收。无法阻止海量请求下的 DoS攻击（Denial of Service，拒绝服务攻击）。

配备证书
虽然使用 HTTP 协议无法确定通信方，但如果使用 SSL 则可以。SSL 不仅提供加密处理，而且还使用了一种被称为证书的手段，可用于确定方。
证书由值得信任的第三方机构颁发，用以证明服务器和客户端是实际存在的。另外，伪造证书从技术角度来说是异常困难的一件事。所以只要能够确认通信方（服务器或客户端）持有的证书，即可判断通信方的真实意图。
在这里插入图片描述

2.1.3 无法证明报文完整性，可能已遭篡改
由于 HTTP 协议无法证明通信的报文完整性，因此，在请求或响应送出之后直到对方接收之前的这段时间内，即使请求或响应的内容遭到篡改，也没有办法获悉。
换句话说，没有任何办法确认，发出的请求 / 响应和接收到的请求 / 响应是前后相同的。
在这里插入图片描述

像这样，请求或响应在传输途中，遭攻击者拦截并篡改内容的攻击称为中间人攻击（Man-in-the-Middle attack，MITM）。

在这里插入图片描述
2.2 HTTP + 加密 + 认证 + 完整性保护 =HTTPS
我们把添加了加密及认证机制的 HTTP 称为 HTTPS（HTTP Secure）。
在这里插入图片描述
我们经常会在 Web 的登录页面和购物结算界面等使用 HTTPS 通信。使用 HTTPS 通信时，不再用 http://，而是改用 https://。另外，当浏览器访问 HTTPS 通信有效的 Web 网站时，浏览器的地址栏内会出现一个带锁的标记。对 HTTPS 的显示方式会因浏览器的不同而有所改变。

在这里插入图片描述

2.2.1 HTTPS 是身披 SSL 外壳的 HTTP
HTTPS 并非是应用层的一种新协议。只是 HTTP 通信接口部分用SSL（Secure Socket Layer）和 TLS（Transport Layer Security）协议代替而已。
在这里插入图片描述

SSL 是独立于 HTTP 的协议，所以不光是 HTTP 协议，其他运行在应用层的 SMTP 和 Telnet 等协议均可配合 SSL 协议使用。可以说 SSL是当今世界上应用最为广泛的网络安全技术。

在这里插入图片描述
2.2.2 HTTPS 的安全通信机制
为了更好地理解 HTTPS，我们来观察一下 HTTPS 的通信步骤。
在这里插入图片描述

  1. 客户端通过发送 Client Hello 报文开始 SSL 通信。报文中包含客户端支持的 SSL 的指定版本、加密组件（Cipher Suite）列表（所使用的加密算法及密钥长度等）。
  2. 服务器可进行 SSL 通信时，会以 Server Hello 报文作为应答。和客户端一样，在报文中包含 SSL 版本以及加密组件。服务器的加密组件内容是从接收到的客户端加密组件内筛选出来的。
  3. 之后服务器发送 Certificate 报文。报文中包含公开密钥证书。
  4. 最后服务器发送 Server Hello Done 报文通知客户端，最初阶段的 SSL 握手协商部分结束。
  5. SSL 第一次握手结束之后，客户端以 Client Key Exchange报文作为回应。报文中包含通信加密中使用的一种被称为Pre-master secret 的随机密码串。该报文已用步骤 3 中的公开密钥进行加密。
  6. 接着客户端继续发送 Change Cipher Spec 报文。该报文会提示服务器，在此报文之后的通信会采用 Pre-master secret密钥加密。
  7. 客户端发送 Finished 报文。该报文包含连接至今全部报文的整体校验值。这次握手协商是否能够成功，要以服务器是否能够正确解密该报文作为判定标准。
  8. 服务器同样发送 Change Cipher Spec 报文。
  9. 服务器同样发送 Finished 报文。
  10. 服务器和客户端的 Finished 报文交换完毕之后，SSL 连接就算建立完成。当然，通信会受到 SSL 的保护。从此处开始进行应用层协议的通信，即发送 HTTP 请求。
  11. 应用层协议通信，即发送 HTTP 响应。
  12. 最后由客户端断开连接。断开连接时，发送 close_notify报文。上图做了一些省略，这步之后再发送 TCP FIN 报文来关闭与 TCP
    的通信。

在以上流程中，应用层发送数据时会附加一种叫做 MAC（Message Authentication Code）的报文摘要。MAC 能够查知报文是否遭到篡改，从而保护报文的完整性。
下面是对整个流程的图解。
在这里插入图片描述
HTTPS 也存在一些问题，那就是当使用 SSL 时，它的处理速度会变慢。
在这里插入图片描述
SSL 的慢分两种。一种是指通信慢。另一种是指由于大量消耗 CPU及内存等资源，导致处理速度变慢。另一点是 SSL 必须进行加密处理。在服务器和客户端都需要进行加密和解密的运算处理。因此从结果上讲，比起 HTTP 会更多地消耗服务器和客户端的硬件资源，导致负载增强。
这也是在HTTPS安全可靠的情况下，不是所有web网站以及所有情况下都使用HTTPS的主要原因。
除此之外，想要节约购买证书的开销也是原因之一。

posted @ 2020-11-03 16:03  336699强强  阅读(188)  评论(0)  编辑  收藏  举报