HTTP和HTTPS详解

HTTP

一、HTTP定义

HTTP定义：HTTP 是超文本传输协议，也就是 HyperText Transfer Protocol。HTTP 是一个在计算机 世界里专门在「两点」之间「传输」文字、图片、音频、视频等「超文本」数据的「约定和 规范」。PS：HTTP 不止是从互联网服务器传输超文本到本地浏览器的协议，还是服务器到 服务器之间的传输协议。

HTTP解析

• HTTP是构建于TCP/IP协议之上，是应用层协议，默认端口号80
• HTTP协议是无连接无状态的

HTTP请求报文格式：

HTTP响应报文格式：

HTTP特性

优点是「简单、灵活和易于扩展、应用广泛和跨平台」。

1. 简单：HTTP 基本的报文格式就是 header + body ，头部信息也是 key-value 简单文本的形式，易 于理解，降低了学习和使用的门槛。

2. 灵活和易于扩展：HTTP 协议里的各类请求方法、URI/URL、状态码、头字段等每个组成要求都没有被固定死， 都允许开发人员自定义和扩充。同时 HTTP 由于是工作在应用层（ OSI 第七层），则它下 层可以随意变化。HTTPS 也就是在 HTTP 与 TCP 层之间增加了 SSL/TLS 安全传输层， HTTP/3 甚至把 TCP 层换成了基于 UDP 的 QUIC。

3. 应用广泛和跨平台：互联网发展至今，HTTP 的应用范围非常的广泛，从台式机的浏览器到手机上的各种 APP， 同时天然具有跨平台的优越性。 HTTP 协议里有优缺点一体的双刃剑，分别是「无状态、明文传输」，同时还有一大缺点「不安全」。

   无状态：

   • 无状态的好处，因为服务器不会去记忆 HTTP 的状态，所以不需要额外的资源来记录状态 信息，这能减轻服务器的负担，能够把更多的 CPU 和内存用来对外提供服务。
   • 无状态的坏处，既然服务器没有记忆能力，它在完成有关联性的操作时会非常麻烦。例如登录->添加购 物车->下单->结算->支付，这系列操作都要知道用户的身份才行。但服务器不知道这 些请求是有关联的，每次都要问一遍身份信息。这样每操作一次，都要验证信息，这种体验对用户来说很不友好。对于无状态的问题，解法方案有很多种，其中比较简单的方式用 Cookie 技术。Cookie 通过在请求和响应报文中写入 Cookie 信息来控制客户 端的状态。相当于，在客户端第一次请求后，服务器会下发一个装有客户信息的「小贴纸」， 后续客户端请求服务器的时候，带上「小贴纸」，服务器就能认得了。

   明文传输：

   • 不安全
   • 方便阅读

HTTP不同版本的特点

HTTP 1.0

1.0的HTTP版本，是一种无状态，无连接的应用层协议。HTTP1.0规定浏览器和服务器保持短暂的链接。

浏览器每次请求都需要与服务器建立一个TCP连接，服务器处理完成以后立即断开TCP连接(无连接)，服务器不跟踪也每个客户单，也不记录过去的请求(无状态)。这种无状态性可以借助cookie/session机制来做身份认证和状态记录。

存在的问题

• 无法复用连接，每次发送请求，都需要进行一次TCP连接，而TCP的连接释放过程又是比较费事的。这种无连接的特性会使得网络的利用率变低。
• 队头阻塞(head of line blocking)，由于HTTP1.0规定下一个请求必须在前一个请求响应到达之前才能发送，假设前一个请求响应一直不到达，那么下一个请求就不发送，后面的请求就阻塞了。
• 不支持断点续传，也就是说，每次都会传送全部的页面和数据。

HTTP 1.1

HTTP1.1继承了HTTP1.0的简单，克服了HTTP1.0性能上的问题。

特点

• 长连接，HTTP1.1增加Connection字段，对于同一个host，通过设置Keep-Alive保持HTTP连接不断。避免每次客户端与服务器请求都要重复建立释放建立TCP连接。提高了网络的利用率。如果客户端想关闭HTTP连接，可以在请求头中携带Connection:false来告知服务器关闭请求。
• 支持断点续传，通过使用请求头中的 Range 来实现。
• 可以使用管道传输，多个请求可以同时发送，但是服务器还是按照顺序，先回应 A 请求，完成后再回应 B 请求。要是 前面的回应特别慢，后面就会有许多请求排队等着。这称为「队头堵塞」。

HTTP 2.0

特点

• 二进制分帧，HTTP2.0通过在应用层和传输层之间增加一个二进制分层帧，突破了HTTP1.1的性能限制，改进传输性能。
• 多路复用(链接共享)— 真并行传输

1. 流(stream)：已建立连接上的双向字节流；
2. 消息：与逻辑消息对应的完整的一系列数据帧；
3. 帧(frame)：HTTP2.0通信的最小单位，每个帧包含头部，至少也会标识出当前所属的流(stream_id)。

所有HTTP2.0通信都在一个TCP链接上完成，这个链接可以承载任意流量的双向数据流。 每个数据流以消息的形式发送，而消息由一或多个帧组成。这些帧可以乱序发送，然后再根据每个帧头部的流标识符(Stream_id)重新封装。

多路复用(连接共享)可能会导致关键字被阻塞，HTTP2.0里每个数据流都可以设置优先级和依赖，优先级高的数据流会被服务器优先处理和返回客户端，数据流还可以依赖其他的子数据流。

可见，HTTP2.0实现了真正的并行传输，它能够在一个TCP上进行任意数量的HTTP请求。而这个强大的功能基于“二进制分帧”的特性。

• 头部压缩，在HTTP1.X中，头部元数据都是以纯文本的形式发送的，通常会给每个请求增加500-8000字节的负荷。比如cookie，默认情况下，浏览器会在每次请求的时候，把cookie附在header上面发给服务器。
  HTTP2.0使用encoder来减少需要传输的header大小，通讯双方各自cache一份header_files表，既避免重复header的传输，又减少了需要传输的大小。
  高效的压缩算法可以很大的压缩header，减少发送包的数量从而降低延迟。
• 服务器推送，服务器除了最初请求的响应外，服务器还可以额外向客户端推送资源，而无需客户端明确的需求。

HTTP 3.0

基于Google的QUIC，HTTP3 背后的主要思想是放弃 TCP，转而使用基于 UDP 的 QUIC 协议。

与 HTTP2 在技术上允许未加密的通信不同，QUIC 严格要求加密后才能建立连接。此外，加密不仅适用于 HTTP 负载，还适用于流经连接的所有数据，从而避免了一大堆安全问题。建立持久连接、协商加密协议，甚至发送第一批数据都被合并到 QUIC 中的单个请求/响应周期中，从而大大减少了连接等待时间。如果客户端具有本地缓存的密码参数，则可以通过简化的握手（0-RTT）重新建立与已知主机的连接。

为了解决传输级别的线头阻塞问题，通过 QUIC 连接传输的数据被分为一些流。流是持久性 QUIC 连接中短暂、独立的“子连接”。每个流都处理自己的错误纠正和传递保证，但使用连接全局压缩和加密属性。每个客户端发起的 HTTP 请求都在单独的流上运行，因此丢失数据包不会影响其他流/请求的数据传输。

0-RTT — QUIC协议相比HTTP2.0的最大优势

缓存当前会话的上下文，下次恢复会话的时候，只需要将之前的缓存传递给服务器，验证通过，就可以进行传输了。

0-RTT建连可以说是QUIC相比HTTP2最大的性能优势。

什么是0-RTT建连?

• 传输层0-RTT就能建立连接
• 加密层0-RTT就能建立加密连接

为什么要有HTTP3.0：HTTP/2底层TCP的局限带来的问题

由于HTTP/2使用了多路复用，一般来说，同一个域名下只需要使用一个TCP链接，但当这个连接中出现了丢包的情况，就会导致HTTP/2的表现情况反倒不如HTTP/2了。

原因是： 在出现丢包的额情况下，整个TCP都要开始等待重传，导致后面的所有数据都被阻塞。

但是对于HTTP/1.1来说，可以开启多个TCP连接，出现这种情况只会影响其中一个连接，剩余的TCP链接还可以正常传输数据。

总结

HTTP 1.0

• 无状态，无连接；
• 短连接：每次发送请求都要重新建立tcp请求，即三次握手，非常浪费性能；
• 无host头域，也就是http请求头里的host；
• 不允许断点续传，而且不能只传输对象的一部分，要求传输整个对象。

HTTP 1.1

• 长连接，流水线，使用connection:keep-alive使用长连接；
• 请求管道化；
• 增加缓存处理(新的字段如cache-control)；
• 增加Host字段，支持断点传输等；
• 由于长连接会给服务器造成压力。

HTTP 2.0

• 二进制分帧；
• 多路复用(或连接共享)，使用多个stream，每个stream又分帧传输，使得一个tcp连接能够处理多个http请求；
• 头部压缩，双方各自维护一个header的索引表，使得不需要直接发送值，通过发送key缩减头部大小；
• 服务器推送(Sever push)。

HTTP 3.0

• 基于google的QUIC协议，而quic协议是使用udp实现的；
• 减少了tcp三次握手时间，以及tls握手时间；
• 解决了http 2.0中前一个stream丢包导致后一个stream被阻塞的问题；
• 优化了重传策略，重传包和原包的编号不同，降低后续重传计算的消耗；
• 连接迁移，不再用tcp四元组确定一个连接，而是用一个64位随机数来确定这个连接；
• 更合适的流量控制。

参考链接：http://events.jianshu.io/p/cd70b8e90d00

HTTP的缺点

HTTP虽然使用极为广泛, 但是却存在不小的安全缺陷, 主要是其数据的明文传送和消息完整性检测的缺乏, 而这两点恰好是网络支付, 网络交易等新兴应用中安全方面最需要关注的 [3] 。

关于 HTTP的明文数据传输, 攻击者最常用的攻击手法就是网络嗅探, 试图从传输过程当中分析出敏感的数据, 例如管理员对 Web 程序后台的登录过程等等, 从而获取网站管理权限, 进而渗透到整个服务器的权限。即使无法获取到后台登录信息, 攻击者也可以从网络中获取普通用户的隐秘信息, 包括手机号码, 身份证号码, 信用卡号等重要资料, 导致严重的安全事故。进行网络嗅探攻击非常简单, 对攻击者的要求很低。使用网络发布的任意一款抓包工具, 一个新手就有可能获取到大型网站的用户信息 [3] 。

另外,HTTP在传输客户端请求和服务端响应时, 唯一的数据完整性检验就是在报文头部包含了本次传输数据的长度, 而对内容是否被篡改不作确认。 因此攻击者可以轻易的发动中间人攻击, 修改客户端和服务端传输的数据, 甚至在传输数据中插入恶意代码, 导致客户端被引导至恶意网站被植入木马 [3] 。

二、HTTPS

HTTPS （全称：Hyper Text Transfer Protocol over SecureSocket Layer），是以安全为目标的 HTTP 通道，在HTTP的基础上通过传输加密和身份认证保证了传输过程的安全性 。HTTPS 在HTTP 的基础下加入SSL，HTTPS 的安全基础是 SSL，因此加密的详细内容就需要 SSL。 HTTPS 存在不同于 HTTP 的默认端口及一个加密/身份验证层（在 HTTP与 TCP 之间）。这个系统提供了身份验证与加密通讯方法。它被广泛用于万维网上安全敏感的通讯，例如交易支付等方面 。

HTTPS要使客户端与服务器端的通信过程得到安全保证，必须使用的对称加密算法，但是协商对称加密算法的过程，需要使用非对称加密算法来保证安全，然而直接使用非对称加密的过程本身也不安全，会有中间人篡改公钥的可能性，所以客户端与服务器不直接使用公钥，而是使用数字证书签发机构颁发的证书来保证非对称加密过程本身的安全。这样通过这些机制协商出一个对称加密算法，就此双方使用该算法进行加密解密。从而解决了客户端与服务器端之间的通信安全问题。

相较于HTTP的改进：

HTTPS 协议是由 HTTP 加上 TLS/SSL 协议构建的可进行加密传输、身份认证的网络协议，主要通过数字证书、加密算法、非对称密钥等技术完成互联网数据传输加密，实现互联网传输安全保护。设计目标主要有三个。

（1）数据保密性：保证数据内容在传输的过程中不会被第三方查看。就像快递员传递包裹一样，都进行了封装，别人无法获知里面装了什么 。

（2）数据完整性：及时发现被第三方篡改的传输内容。就像快递员虽然不知道包裹里装了什么东西，但他有可能中途掉包，数据完整性就是指如果被掉包，我们能轻松发现并拒收 。

（3）身份校验安全性：保证数据到达用户期望的目的地。就像我们邮寄包裹时，虽然是一个封装好的未掉包的包裹，但必须确定这个包裹不会送错地方，通过身份校验来确保送对了地方 。

三、HTTPS与HTTP原理区别

HTTPS 主要由两部分组成：HTTP + SSL / TLS，也就是在 HTTP 上又加了一层处理加密信息的模块。服务端和客户端的信息传输都会通过 TLS 进行加密，所以传输的数据都是加密后的数据。

HTTP 原理

① 客户端的浏览器首先要通过网络与服务器建立连接，该连接是通过TCP 来完成的，一般 TCP 连接的端口号是80。 建立连接后，客户机发送一个请求给服务器，请求方式的格式为：统一资源标识符（URL）、协议版本号，后边是 MIME 信息包括请求修饰符、客户机信息和许可内容 。

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

具体的可以看前文总结的HTTP请求报文、HTTP响应报文格式。

HTTPS 原理

① 客户端将它所支持的算法列表和一个用作产生密钥的随机数发送给服务器 ；

② 服务器从算法列表中选择一种加密算法，并将它和一份包含服务器公用密钥的证书发送给客户端；该证书还包含了用于认证目的的服务器标识，服务器同时还提供了一个用作产生密钥的随机数 [2] ；

③ 客户端对服务器的证书进行验证（有关验证证书，可以参考数字签名），并抽取服务器的公用密钥；然后，再产生一个称作 pre_master_secret 的随机密码串，并使用服务器的公用密钥对其进行加密（参考非对称加 / 解密），并将加密后的信息发送给服务器 ；

④ 客户端与服务器端根据 pre_master_secret 以及客户端与服务器的随机数值独立计算出加密和 MAC密钥（参考 DH密钥交换算法） ；

⑤ 客户端将所有握手消息的 MAC 值发送给服务器 ；

⑥ 服务器将所有握手消息的 MAC 值发送给客户端 。

优缺点：

优点

1. 使用 HTTPS 协议可认证用户和服务器，确保数据发送到正确的客户机和服务器 ；
2. HTTPS 协议是由 SSL+HTTP构建的可进行加密传输、身份认证的网络协议，要比 HTTP安全，可防止数据在传输过程中被窃取、改变，确保数据的完整性 。
3. HTTPS 是现行架构下最安全的解决方案，虽然不是绝对安全，但它大幅增加了中间人攻击的成本 。

缺点

1. 相同网络环境下，HTTPS 协议会使页面的加载时间延长近 50%，增加 10%到 20%的耗电。此外，HTTPS 协议还会影响缓存，增加数据开销和功耗 。
2. HTTPS 协议的安全是有范围的，在黑客攻击、拒绝服务攻击和服务器劫持等方面几乎起不到什么作用 。
3. 最关键的是，SSL 证书的信用链体系并不安全。特别是在某些国家可以控制 CA 根证书的情况下，中间人攻击一样可行 。
4. 成本增加。部署 HTTPS 后，因为 HTTPS 协议的工作要增加额外的计算资源消耗，例如 SSL 协议加密算法和 SSL 交互次数将占用一定的计算资源和服务器成本。在大规模用户访问应用的场景下，服务器需要频繁地做加密和解密操作，几乎每一个字节都需要做加解密，这就产生了服务器成本。随着云计算技术的发展，数据中心部署的服务器使用成本在规模增加后逐步下降，相对于用户访问的安全提升，其投入成本已经下降到可接受程度 。

参考：https://baike.baidu.com/item/HTTPS/285356?fr=aladdin

四、中间人攻击

中间人攻击(Man-in-the-MiddleAttack，简称“MITM攻击”)是指攻击者与通讯的两端分别创建独立的联系，并交换其所收到的数据，使通讯的两端认为他们正在通过一个私密的连接与对方 直接对话，但事实上整个会话都被攻击者完全控制。在中间人攻击中，攻击者可以拦截通讯双方的通话并插入新的内容。中间人攻击是一个(缺乏)相互认证的攻击。大多数的加密协议都专门加入了一些特殊的认证方法以阻止中间人攻击。例如，SSL协议可以验证参与通讯的一方或双方使用的证书是否是由权威的受信 任的数字证书认证机构颁发，并且能执行双向身份认证。

中间人攻击过程：

1. 客户端发送请求到服务端，请求被中间人截获。

2. 服务器向客户端发送公钥。

3. 中间人截获公钥，保留在自己手上。然后自己生成一个伪造的公钥，发给客户端。

4. 客户端收到伪造的公钥后，生成加密hash值发给服务器。

5. 中间人获得加密hash值，用自己的私钥解密获得真秘钥。同时生成假的加密hash值，发给服务器。

6. 服务器用私钥解密获得假密钥。然后加密数据传输给客户端。

中间人攻击的几种攻击方式，一般说来，中间人攻击的方式有嗅探、数据包注入、会话劫持和SSL剥离。

1. 嗅探：嗅探或数据包嗅探 是一种用于捕获流进和流出系统/网络的数据包的技术。网络中的数据包嗅探就好像电话中的监听。

2. 数据包注入：在这种技术中，攻击者会将恶意数据包注入常规数据中。这样用户便不会注意到文件/恶意软件，因为它们是合法通讯流的一部分。在中间人攻击和拒绝式攻击中，这些文件是很常见的。

3. 会话劫持：当客户端和服务器端在进行一个会话时，会话中包含了很多重要信息，一些黑客会潜伏在这个会话中，最终控制这个会话，这既是 会话劫持。

4. SSL剥离：SSL/TLS证书通过加密保护着我们的通讯安全。在SSL剥离攻击中，攻击者使SSL/TLS连接剥落，随之协议便从安全的HTTPS变成了不安全的HTTP。

如何避免中间人攻击呢？

• 暂时未知，后续知道了，补充到这里，或者有知道的欢迎评论区告诉我。