HTTP学习

SSL：Secure Socket Layer，安全套接字层

TLS：Transport LayerSecurity，传输层安全协议

SSL是Netscape开发的专门用户保护Web通讯的，目前版本为3.0。最新版本的TLS 1.0是IETF(工程任务组)制定的一种新的协议，它建立在SSL 3.0协议规范之上，是SSL 3.0的后续版本，两者差别极小。

一、HTTP的基本优化

影响一个 HTTP 网络请求的因素主要有两个：带宽和延迟。

• 带宽：如果说我们还停留在拨号上网的阶段，带宽可能会成为一个比较严重影响请求的问题，但是现在网络基础建设已经使得带宽得到极大的提升，我们不再会担心由带宽而影响网速，那么就只剩下延迟了。
• 阻塞：
  • 浏览器阻塞（HOL blocking）：浏览器会因为一些原因阻塞请求。浏览器对于同一个域名，同时只能有 4 个连接（这个根据浏览器内核不同可能会有所差异），超过浏览器最大连接数限制，后续请求就会被阻塞。
  • DNS 查询（DNS Lookup）：浏览器需要知道目标服务器的 IP 才能建立连接。将域名解析为 IP 的这个系统就是 DNS。这个通常可以利用DNS缓存结果来达到减少这个时间的目的。
  • 建立连接（Initial connection）：HTTP 是基于 TCP 协议的，浏览器最快也要在第三次握手时才能捎带 HTTP 请求报文，达到真正的建立连接，但是这些连接无法复用会导致每次请求都经历三次握手和慢启动。三次握手在高延迟的场景下影响较明显，慢启动则对文件类大请求影响较大。

二、HTTP1.0 和HTTP1.1的一些区别

HTTP1.0最早是在1996年开始使用，HTTP1.1是在1999年开始使用，主要区别如下：

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

三、HTTPS与HTTP的区别

• HTTPS协议需要到CA申请证书，一般免费证书很少，需要交费。
• HTTP协议运行在TCP之上，所有传输的内容都是明文，HTTPS运行在SSL/TLS之上，SSL/TLS运行在TCP之上，所有传输的内容都经过加密的。
• HTTP和HTTPS使用的是完全不同的连接方式，用的端口也不一样，前者是80，后者是443。
• HTTPS可以有效的防止运营商劫持，解决了防劫持的一个大问题。

四、SPDY：HTTP1.x的优化

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

1. 降低延迟，针对HTTP高延迟的问题，SPDY优雅的采取了多路复用（multiplexing）。多路复用通过多个请求stream共享一个tcp连接的方式，解决了HOL blocking的问题，降低了延迟同时提高了带宽的利用率。

2. 请求优先级（request prioritization）。多路复用带来一个新的问题是，在连接共享的基础之上有可能会导致关键请求被阻塞。SPDY允许给每个request设置优先级，这样重要的请求就会优先得到响应。比如浏览器加载首页，首页的html内容应该优先展示，之后才是各种静态资源文件，脚本文件等加载，这样可以保证用户能第一时间看到网页内容。

3. header压缩。前面提到HTTP1.x的header很多时候都是重复多余的。选择合适的压缩算法可以减小包的大小和数量。

4. 基于HTTPS的加密协议传输，大大提高了传输数据的可靠性。

5. 服务端推送（server push），采用了SPDY的网页，例如我的网页有一个sytle.css的请求，在客户端收到sytle.css数据的同时，服务端会将sytle.js的文件推送给客户端，当客户端再次尝试获取sytle.js时就可以直接从缓存中获取到，不用再发请求了。SPDY构成图：

   

   SPDY位于HTTP之下，TCP和SSL之上，这样可以轻松兼容老版本的HTTP协议(将HTTP1.x的内容封装成一种新的frame格式)，同时可以使用已有的SSL功能。

五、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功能。

六、多路复用与长连接复用

• HTTP/1.* 一次请求-响应，建立一个连接，用完关闭；每一个请求都要建立一个连接；

• HTTP/1.1 Pipeling解决方式为，若干个请求排队串行化单线程处理，后面的请求等待前面请求的返回才能获得执行机会，一旦有某请求超时等，后续请求只能被阻塞，毫无办法，也就是人们常说的线头阻塞；

• HTTP/2多个请求可同时在一个连接上并行执行。某个请求任务耗时严重，不会影响到其它连接的正常执行；

  把多次请求放到一个连接上传输。

为什么需要头部压缩

假定一个页面有100个资源需要加载（这个数量对于今天的Web而言还是挺保守的）, 而每一次请求都有1kb的消息头（这同样也并不少见，因为Cookie和引用等东西的存在）, 则至少需要多消耗100kb来获取这些消息头。HTTP2.0可以维护一个字典，差量更新HTTP头部，大大降低因头部传输产生的流量。具体参考：HTTP/2 头部压缩技术介绍

HTTP2.0多路复用有多好？

HTTP 性能优化的关键并不在于高带宽，而是低延迟。TCP 连接会随着时间进行自我「调谐」，起初会限制连接的最大速度，如果数据成功传输，会随着时间的推移提高传输的速度。这种调谐则被称为 TCP 慢启动。由于这种原因，让原本就具有突发性和短时性的 HTTP 连接变的十分低效。
HTTP/2 通过让所有数据流共用同一个连接，可以更有效地使用 TCP 连接，让高带宽也能真正的服务于 HTTP 的性能提升。

七、HTTPS

7.1 什么是HTTPS

https简单的说就是安全版的http，因为http协议的数据都是明文进行传输的，所以对于一些敏感信息的传输就很不安全，为了安全传输敏感数据，网景公司设计了SSL（Secure Socket Layer），在http的基础上添加了一个安全传输层，对所有的数据都加密后再进行传输，客户端和服务器端收到加密数据后按照之前约定好的秘钥解密。

7.2 加密和解密

Https的发展和密码学的发展是分不开的。大家应该知道加密方式可以大体分为对称加密和非对称加密（反正我就知道这两种）

• 对称加密，就是加密和解密都是用同一个秘钥，这种方式优点就是速度快，缺点就是在管理和分配秘钥的时候不安全。
• 非对称加密算法，非对称加密有一个秘钥对，叫做公钥和私钥，私钥自己持有，公钥可以公开的发送给使用的人。使用公钥进行加密的信息，只有和其配对的私钥可以解开。目前常见的非对称加密算法是RSA，非对称的加密算法的优点是安全，因为他不需要把私钥暴露出去。

在正式的使用场景中一般都是对称加密和非对称加密结合使用，使用非对称加密完成秘钥的传递，然后使用对称秘钥进行数据加密和解密

7.3 https证书的申请流程

1. 在服务器上生成CSR文件（证书申请文件，内容包括证书公钥、使用的Hash算法、申请的域名、公司名称、职位等信息），可以使用命令在服务器上生成；也可以使用线上的工具进行生成，线上的工具会把公钥加入到CSR文件中，并同时生成私钥。

   

2. 把CSR文件和其他可能的证件上传到CA认证机构，CA机构收到证书申请之后，使用申请中的Hash算法，对部分内容进行摘要，然后使用CA机构自己的私钥对这段摘要信息进行签名，

   

3. 然后CA机构把签名过的证书通过邮件形式发送到申请者手中。

4. 申请者收到证书之后部署到自己的web服务器中。

7.4 客户端（浏览器）和服务器端交互流程

1. client Hello,客户端（通常是浏览器）先向服务器发出加密通信的请求

   • 支持的协议版本，比如TLS 1.0版。

   • 一个客户端生成的随机数 random1，稍后用于生成”对话密钥”。

   • 支持的加密方法，比如RSA公钥加密。

   • 支持的压缩方法。

2. 服务器收到请求,然后响应 (server Hello)

   • 确认使用的加密通信协议版本，比如TLS 1.0版本。如果浏览器与服务器支持的版本不一致，服务器关闭加密通信。
   • 一个服务器生成的随机数random2，稍后用于生成”对话密钥”。
   • 确认使用的加密方法，比如RSA公钥加密。
   • 服务器证书。

3. 客户端收到证书之后会首先会进行验证

   • 验证流程：

     1. 我们知道CA机构在签发证书的时候，都会使用自己的私钥对证书进行签名，证书里的签名算法字段 sha256RSA 表示，CA机构使用sha256对证书进行摘要，然后使用RSA算法对摘要进行私钥签名，而我们也知道RSA算法中，使用私钥签名之后，只有公钥才能进行验签。
     2. 如果我们使用的是购买的证书，那么很有可能，颁发这个证书的CA机构的公钥已经预置在操作系统中。这样浏览器就可以使用CA机构的公钥对服务器的证书进行验签。确定这个证书是不是由正规的CA机构颁发的。验签之后得到CA机构使用sha256得到的证书摘要，然后客户端再使用sha256对证书内容进行一次摘要，如果得到的值和验签之后得到的摘要值相同，则表示证书没有被修改过。
     3. 如果验证通过，就会显示上面的安全字样，如果服务器购买的证书是更高级的EV类型，就会显示出购买证书的时候提供的企业名称。如果没有验证通过，就会显示不安全的提示。

     既验证，服务器发送的证书与在安全机构里预存的证书一不一样。

   • 生成随机数

     验证通过之后，客户端会生成一个随机数pre-master secret，然后使用证书中的公钥进行加密，然后传递给服务器端

     PreMaster secret

     PreMaster Secret是在客户端使用RSA或者Diffie-Hellman等加密算法生成的。它将用来跟服务端和客户端在Hello阶段产生的随机数结合在一起生成 Master Secret。在客户端使用服务端的公钥对PreMaster Secret进行加密之后传送给服务端，服务端将使用私钥进行解密得到PreMaster secret。也就是说服务端和客户端都有一份相同的PreMaster secret和随机数。

     PreMaster secret前两个字节是TLS的版本号，这是一个比较重要的用来核对握手数据的版本号，因为在Client Hello阶段，客户端会发送一份加密套件列表和当前支持的SSL/TLS的版本号给服务端，而且是使用明文传送的，如果握手的数据包被破解之后，攻击者很有可能串改数据包，选择一个安全性较低的加密套件和版本给服务端，从而对数据进行破解。所以，服务端需要对密文中解密出来对的PreMaster版本号跟之前Client Hello阶段的版本号进行对比，如果版本号变低，则说明被串改，则立即停止发送任何消息。

4. 服务器收到使用公钥加密的内容，在服务器端使用私钥解密之后获得随机数pre-master secret，然后根据radom1、radom2、pre-master secret通过一定的算法得出session Key和MAC算法秘钥，作为后面交互过程中使用对称秘钥。同时客户端也会使用radom1、radom2、pre-master secret，和同样的算法生成session Key和MAC算法的秘钥。

   生成session Key的过程中会用到PRF(Pseudorandom Function伪随机方法)来生成一个key_block,然后再使用key_block,生成后面使用的秘钥。
   key_block = PRF(SecurityParameters.master_secret,”key expansion”,SecurityParameters.server_random +SecurityParameters.client_random);
   PRF是在规范中约定的伪随机函数。

   在信息交互过程中用到的秘钥有6个分别是。客户端和服务器端分别使用相同的算法生成。

   秘钥名称	秘钥作用
   client_write_MAC_key[SecurityParameters.mac_key_length]	客户端发送数据使用的摘要MAC算法
   server_write_MAC_key[SecurityParameters.mac_key_length]	服务端发送数据使用摘要MAC算法
   client_write_key[SecurityParameters.enc_key_length]	客户端数据加密，服务端解密
   server_write_key[SecurityParameters.enc_key_length]	服务端加密，客户端解密
   client_write_IV[SecurityParameters.fixed_iv_length]	初始化向量，运用于分组对称加密
   server_write_IV[SecurityParameters.fixed_iv_length]	初始化向量，运用于分组对称加密

5. 然后再后续的交互中就使用session Key和MAC算法的秘钥对传输的内容进行加密和解密。

   具体的步骤是先使用MAC秘钥对内容进行摘要，然后把摘要放在内容的后面使用sessionKey再进行加密。

   对于客户端发送的数据，服务器端收到之后，需要先使用client_write_key进行解密，然后使用client_write_MAC_key对数据完整性进行验证。服务器端发送的数据，客户端会使用server_write_key和server_write_MAC_key进行相同的操作。

---

以下为另一种方式

非对称加密 + 对称加密

非对称加密耗时，我们考虑是否可以采用非对称加密+对称加密结合的方式，而且要尽量减少非对称加密的次数。

非对称加密、解密各只需一次的方法：

1. 某网站拥有用于非对称加密的公钥A1、私钥A2。
2. 浏览器向网站服务器请求，服务器把公钥A1明文给传输浏览器。
3. 浏览器随机生成一个用于对称加密的密钥X，用公钥A1加密后传给服务器。
4. 服务器拿到后用私钥A2解密得到密钥X。
5. 这样双方就都拥有密钥X了，且别人无法知道它。之后双方所有数据都用密钥X加密解密即可。

HTTPS基本就是采用了这种方案。但还是有漏洞的。

中间人攻击

中间人的确无法得到浏览器生成的对称密钥X，这个密钥本身被公钥A1加密，只有服务器才能用私钥A2进行解密。然而中间人却完全不需要拿到私钥A2就能劫持信息，请看：

1. 某网站拥有用于非对称加密的公钥A1、私钥A2。
2. 浏览器向网站服务器请求，服务器把公钥A1明文传输给浏览器。
3. 中间人劫持到公钥A1，保存下来，把数据包中的公钥A1替换成自己伪造的公钥B1（它当然也拥有公钥B1对应的私钥B2）。
4. 浏览器随机生成一个用于对称加密的密钥X，用公钥B1（浏览器不知道公钥被替换了）加密后传给服务器。
5. 中间人劫持后用私钥B2解密得到密钥X，再用公钥A1加密后传给服务器。
6. 服务器拿到后用私钥A2解密得到密钥X。

这样在双方都不会发现异常的情况下，中间人得到了对称密钥X。根本原因是浏览器无法确认自己收到的公钥是不是网站自己的。那么下一步就是解决这个问题：如何证明浏览器收到的公钥一定是该网站的公钥？

数字证书

现实生活中，如果想证明某身份证号一定是小明的，怎么办？看身份证。这里政府机构起到了“公信”的作用，身份证是由它颁发的，它本身的权威可以对一个人的身份信息作出证明。互联网中也有这么一个公信机构，CA 机构。

网站在使用HTTPS前，需要向“CA机构”申请颁发一数字证书，数字证书里有证书持有者、证书持有者的公钥等信息。服务器把证书传输给浏览器，浏览器从证书里取公钥就可以了。然而这里又有一个显而易见的问题：证书本身的传输过程中，如何防止被篡改？即如何证明证书本身的真实性？数字证书怎么防伪呢？

数字签名

我们把证书内容生成一份“签名”，比对证书内容和签名是否一致就能察觉是否被篡改。这种技术就叫数字签名。
下图中左侧是数字签名的制作过程，右侧是验证过程

数字签名的制作过程：

1. CA拥有非对称加密的私钥和公钥。
2. CA对证书明文信息（公钥）进行hash。
3. 对hash后的值用私钥（CA的私钥）加密，得到数字签名。

CA机构对公钥进行哈希然后用CA的私钥进行加密得到数字签名。

明文和数字签名共同组成了数字证书，这样一份数字证书就可以颁发给网站了。

那浏览器拿到服务器传来的数字证书后，如何验证它是不是真的？（有没有被篡改、掉包）

浏览器验证过程：

1. 拿到证书，得到明文T1，数字签名S1。
2. 用CA机构的公钥对S1解密（由于是浏览器信任的机构，所以浏览器保有它的公钥。详情见下文），得到S2。
3. 用证书里说明的hash算法对明文T1进行hash得到T2。
4. 比较S2是否等于T2，等于则表明证书可信。

为什么这样可以证明证书可信？

假设中间人篡改了证书的原文，由于他没有CA机构的私钥，所以无法得到此时加密后签名，无法相应地篡改签名。浏览器收到该证书后会发现原文和签名解密后的值不一致，则说明证书已被篡改，证书不可信，从而终止向服务器传输信息，防止信息泄露给中间人。

既然不可能篡改，那如果整个证书被掉包呢？

假设有另一个网站B也拿到了CA机构认证的证书，它想搞垮网站A，想劫持网站A的信息。于是它成为中间人拦截到了A传给浏览器的证书，然后替换成自己的证书，传给浏览器，之后浏览器就会错误地拿到B的证书里的公钥了，会导致上文提到的漏洞。
其实这并不会发生，因为证书里包含了网站A的信息，包括域名，浏览器把证书里的域名与自己请求的域名比对一下就知道有没有被掉包了。

制作数字签名时为什么需要hash一次？

最显然的是性能问题，前面我们已经说了非对称加密效率较差，证书信息一般较长，比较耗时。而hash后得到的是固定长度的信息（比如用md5算法hash后可以得到固定的128位的值），这样加密解密就会快很多。当然除此之外也有安全上的原因。

HTTPS必须在每次请求中都要先在SSL/TLS层进行握手传输密钥吗？

显然每次请求都经历一次密钥传输过程非常耗时，那怎么达到只传输一次呢？用session就可以。
服务器会为每个浏览器（或客户端软件）维护一个session ID，在TSL握手阶段传给浏览器，浏览器生成好密钥传给服务器后，服务器会把该密钥存到相应的session ID下，之后浏览器每次请求都会携带session ID，服务器会根据session ID找到相应的密钥并进行解密加密操作，这样就不必要每次重新制作、传输密钥了

HTTPS工作原理

1. client向server发送请求https://baidu.com，然后连接到server的443端口。

2. 服务端必须要有一套数字证书，可以自己制作，也可以向组织申请。区别就是自己颁发的证书需要客户端验证通过，才可以继续访问，而使用受信任的公司申请的证书则不会弹出提示页面，这套证书其实就是一对公钥和私钥。

3. 传送证书

   这个证书其实就是公钥，只是包含了很多信息，如证书的颁发机构，过期时间、服务端的公钥，第三方证书认证机构(CA)的签名，服务端的域名信息等内容。

4. 客户端解析证书

   这部分工作是由客户端的TLS来完成的，首先会验证公钥是否有效，比如颁发机构，过期时间等等，如果发现异常，则会弹出一个警告框，提示证书存在问题。如果证书没有问题，那么就生成一个随机值（密钥）。然后用证书对该随机值进行加密。

5. 传送加密信息

   这部分传送的是用证书加密后的密钥（随机值），目的就是让服务端得到这个密钥（随机值），以后客户端和服务端的通信就可以通过这个随机值来进行加密解密了。

6. 服务端加密信息

   服务端用私钥解密，得到了客户端传过来的密钥（随机值），然后把内容通过该值进行对称加密。

7. 传输加密后的信息

   这部分信息是服务端用密钥（随机值）对称加密后的信息，可以在客户端被还原。

8. 客户端解密信息

   客户端用之前生成的密钥（随机值）解密服务端传过来的信息，于是获取了解密后的内容。