HTTP与HTTPS

HTTP 超文本传输协议，是一个简单的请求 - 响应协议，基于 TCP 之上，在互联网时代，是一个十分重要的协议，我们在生活中处处能看到他的身影。

URL

对我们来说，HTTP 和我们直接接触的就是 https://blog.dextercai.com/404.html 这样的链接形式（URL）。
其格式为 protocol://username:password@host:port/dir/filename?getArgName1=value#anchor
URL 和 URI 的概念通常会被人混淆。这里再引入 URN 的概念。
首先，URL 和 URN 共同被称为 URI，URL 就是上面的一个形式；而对于 URN，举个例子 ISBN:XXXX，就可以称之为 URN。
URI 是一个 Identifier，可以是一个页面，可以是一本书。
URL 是一种 URI 的特殊实现，或者可以理解为，特殊类型的 URI。他不仅是标识了资源，更重要的是包含了 Access 方式的信息。

发送和响应

GET /index.html HTTP/1.1 //请求头部
Host: blog.dextercai.com //Header字段开始
Connection: keep-alive
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 
Accept:text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Encoding: gzip, deflate, sdch
Accept-Language: zh-CN,zh;q=0.8
Cookie: xxxxxxxx

username=cai //请求Payload，如有。

HTTP/1.1 200 OK //响应头部
Date: Sat, 01 Jul 2017 14:51:26 GMT //响应字段
Server: WebServer
Set-Cookie: ESSIONID=84C993F5E433C4DE;path=/;HttpOnly
Content-Language: zh-CN
Vary: Accept-Encoding
Content-Encoding: gzip
Content-Length: 7333
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: text/html;charset=UTF-8
 
content //内容主体

请注意，GET /index.html HTTP/1.1 和 HTTP/1.1 200 OK 的结构。

1.0 To 2.0

HTTP1.0 在网页中使用是在 1996 年，那个时候只是用于较为简单的网页上和网络请求上。
HTTP1.1 在 1999 年开始广泛应用，同时 HTTP1.1 也是当前使用最为广泛的 HTTP 协议。

主要区别体现在：

缓存处理，在 HTTP1.0 中主要使用 header 里的 If-Modified-Since,Expires 来做为缓存判断的标准，HTTP1.1 则引入了更多的缓存控制策略例如 Entity tag，If-Unmodified-Since, If-Match, If-None-Match 等更多可供选择的缓存头来控制缓存策略。
带宽优化及网络连接的使用，HTTP1.0 中，存在一些浪费带宽的现象，例如客户端只是需要某个对象的一部分，而服务器却将整个对象送过来了，并且不支持断点续传功能，HTTP1.1 则在请求头引入了 range 头域，它允许只请求资源的某个部分，即返回码是 206（Partial Content），这样就方便了开发者自由的选择以便于充分利用带宽和连接。
错误通知的管理，在 HTTP1.1 中新增了 24 个错误状态响应码，如 409（Conflict）表示请求的资源与资源的当前状态发生冲突；410（Gone）表示服务器上的某个资源被永久性的删除。
Host 头处理，在 HTTP1.0 中认为每台服务器都绑定一个唯一的 IP 地址，因此，请求消息中的 URL 并没有传递主机名（hostname）。但随着虚拟主机技术的发展，在一台物理服务器上可以存在多个虚拟主机（Multi-homed Web Servers），并且它们共享一个 IP 地址。HTTP1.1 的请求消息和响应消息都应支持 Host 头域，且请求消息中如果没有 Host 头域会报告一个错误（400 Bad Request）。
长连接，HTTP 1.1 支持长连接（PersistentConnection）和请求的流水线（Pipelining）处理，在一个 TCP 连接上可以传送多个 HTTP 请求和响应，减少了建立和关闭连接的消耗和延迟，在 HTTP1.1 中默认开启 Connection： keep-alive，一定程度上弥补了 HTTP1.0 每次请求都要创建连接的缺点。

1.1 To SPDY

2012 年 Google 提出了 SPDY 的方案，优化了 HTTP1.X 的请求延迟，解决了 HTTP1.X 的安全性，具体如下：

降低延迟，针对 HTTP 高延迟的问题，SPDY 优雅的采取了多路复用（multiplexing）。多路复用通过多个请求 stream 共享一个 tcp 连接的方式，解决了 HOL blocking 的问题，降低了延迟同时提高了带宽的利用率。
请求优先级（request prioritization）。多路复用带来一个新的问题是，在连接共享的基础之上有可能会导致关键请求被阻塞。SPDY 允许给每个 request 设置优先级，这样重要的请求就会优先得到响应。比如浏览器加载首页，首页的 html 内容应该优先展示，之后才是各种静态资源文件，脚本文件等加载，这样可以保证用户能第一时间看到网页内容。
header 压缩。前面提到 HTTP1.x 的 header 很多时候都是重复多余的。选择合适的压缩算法可以减小包的大小和数量。
基于 HTTPS 的加密协议传输，大大提高了传输数据的可靠性。
服务端推送（server push），采用了 SPDY 的网页，例如我的网页有一个 sytle.css 的请求，在客户端收到 sytle.css 数据的同时，服务端会将 sytle.js 的文件推送给客户端，当客户端再次尝试获取 sytle.js 时就可以直接从缓存中获取到，不用再发请求了。SPDY 构成图：

SPDY To 2.0

和 SPDY 的区别

HTTP2.0 支持明文 HTTP 传输，而 SPDY 强制使用 HTTPS
HTTP2.0 消息头的压缩算法采用 HPACK http://http2.github.io/http2-spec/compression.html，而非 SPDY 采用的 DEFLATE http://zh.wikipedia.org/wiki/DEFLATE （此处不解，需深入了解）

HTTP2.0 和 HTTP1.X 相比的新特性

新的二进制格式（Binary Format），HTTP1.x 的解析是基于文本。基于文本协议的格式解析存在天然缺陷，文本的表现形式有多样性，要做到健壮性考虑的场景必然很多，二进制则不同，只认 0 和 1 的组合。基于这种考虑 HTTP2.0 的协议解析决定采用二进制格式，实现方便且健壮。
多路复用（MultiPlexing），即连接共享，即每一个 Request 都是是用作连接共享机制的。一个 Request 对应一个 id，这样一个连接上可以有多个 Request，每个连接的 Request 可以随机的混杂在一起，接收方可以根据 Request 的 id 将 Request 再归属到各自不同的服务端请求里面。
header 压缩，如上文中所言，对前面提到过 HTTP1.x 的 Header 带有大量信息，而且每次都要重复发送，HTTP2.0 使用 Encoder 来减少需要传输的 Header 大小，通讯双方各自 Cache 一份 Header Fields 表，既避免了重复 Header 的传输，又减小了需要传输的大小。
服务端推送（server push），同 SPDY 一样，HTTP2.0 也具有 server push 功能。

HTTPS 过程

1. 客户端想服务器发起 HTTPS 的请求，连接到服务器的 443 端口；
2. 服务器将非对称加密的公钥传递给客户端，以证书的形式回传到客户端
3. 客户端接受到该公钥进行验证，如有问题，则 HTTPS 请求无法继续；如果没有问题，则上述公钥是合格的。（第一次 HTTP 请求）客户端这个时候随机生成一个私钥，成为 Client Key，客户端私钥，用于对称加密数据的。使用前面的公钥对 Client Key 进行非对称加密
4. 进行二次 HTTP 请求，将非对称加密之后的 Client Key 传递给服务器
5. 服务器使用私钥进行解密，得到 Client Key，使用 Client Key 对数据进行对称加密
6. 将对称加密的数据传递给客户端，客户端使用对称解密，得到服务器发送的数据，完成第二次 HTTP 请求

总体而言，先验证传来的证书，然后随机生成一个私钥，利用证书进行非对称加密后，传输给服务端。
服务端用私钥解密，然后根据客户端传来的 ClientKey，进行对称加密，完成后续传输。

使用对称加密，是因为非对称加密在密集请求场景下，效率并不高。
CA 机制保障服务端的权威性，非对称加密保障了由客户端生成的 ClientKey 的安全（一定只能由服务端解密），而后对称加密保障了数据的安全（中间人问题），也保障了加解密效率。

本文标题：HTTP 与 HTTPS
本文连接：https://blog.dextercai.com/archives/157.html
除另行说明，本站文字内容采用创作共用版权 CC-BY-NC-ND 4.0 许可协议，版权归本人所有。
除另行说明，本站图片内容版权归本人所有，未经许可前，严禁以任何形式的使用。

即日起视情况关闭全站评论区，您可以通过关于页面的电邮地址和我取得联系，谢谢