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 许可协议，版权归本人所有。
除另行说明，本站图片内容版权归本人所有，未经许可前，严禁以任何形式的使用。

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