HTTP与HTTPS那点事儿

文章转载自公众号

程序员小灰 程序员小灰 ， 作者 小灰 image

文/北妈、小灰 阅读本文需要 2.2分钟一HTTPS协议一直是web开发，无论前后端都不可或缺的重要知识点，然而由于历史原因，这个协议和知识点枯燥而繁多，如果看书和文字十分难懂苦涩。但又不得不掌握，怎么办呢？正好，从朋友小灰那里得到一片 利用漫画形式讲解https协议的有趣图文，大家看下加深理解。

image image image image image image image image image 什么是HTTP协议？HTTP协议全称Hyper Text Transfer Protocol，翻译过来就是超文本传输协议，位于TCP/IP四层模型当中的应用层。 image HTTP协议通过请求/响应的方式，在客户端和服务端之间进行通信。 image

这一切看起来很美好，但是HTTP协议有一个致命的缺点：不够安全。HTTP协议的信息传输完全以明文方式，不做任何加密，相当于是在网络上“裸奔”。这样会导致什么问题呢？让我们打一个比方：小灰是客户端，小灰的同事小红是服务端，有一天小灰试图给小红发送请求。

image

但是，由于传输信息是明文，这个信息有可能被某个中间人恶意截获甚至篡改。这种行为叫做中间人攻击。

image
image
image

如何进行加密呢？小灰和小红可以事先约定一种对称加密方式，并且约定一个随机生成的密钥。后续的通信中，信息发送方都使用密钥对信息加密，而信息接收方通过同样的密钥对信息解密。

image
image 这样做是不是就绝对安全了呢？并不是。虽然我们在后续的通信中对明文进行了加密，但是第一次约定加密方式和密钥的通信仍然是明文，如果第一次通信就已经被拦截了，那么密钥就会泄露给中间人，中间人仍然可以解密后续所有的通信内容。 image

这可怎么办呢？别担心，我们可以使用非对称加密，为密钥的传输做一层额外的保护。非对称加密的一组秘钥对中，包含一个公钥和一个私钥。明文既可以用公钥加密，用私钥解密；也可以用私钥加密，用公钥解密。在小灰和小红建立通信的时候，小红首先把自己的公钥Key1发给小灰：

image 收到小红的公钥以后，小灰自己生成一个用于对称加密的密钥Key2，并且用刚才接收的公钥Key1对Key2进行加密（这里有点绕），发送给小红： image 小红利用自己非对称加密的私钥，解开了公钥Key1的加密，获得了Key2的内容。从此以后，两人就可以利用Key2进行对称加密的通信了。 image 在通信过程中，即使中间人在一开始就截获了公钥Key1，由于不知道私钥是什么，也无从解密。 image
image 是什么坏主意呢？中间人虽然不知道小红的私钥是什么，但是在截获了小红的公钥Key1之后，却可以偷天换日，自己另外生成一对公钥私钥，把自己的公钥Key3发送给小灰。 image 小灰不知道公钥被偷偷换过，以为Key3就是小红的公钥。于是按照先前的流程，用Key3加密了自己生成的对称加密密钥Key2，发送给小红。这一次通信再次被中间人截获，中间人先用自己的私钥解开了Key3的加密，获得Key2，然后再用当初小红发来的Key1重新加密，再发给小红。 image 这样一来，两个人后续的通信尽管用Key2做了对称加密，但是中间人已经掌握了Key2，所以可以轻松进行解密。 image
image 是什么解决方案呢？难道再把公钥进行一次加密吗？这样只会陷入鸡生蛋蛋生鸡，永无止境的困局。这时候，我们有必要引入第三方，一个权威的证书颁发机构（CA）来解决。到底什么是证书呢？证书包含如下信息： image 为了便于说明，我们这里做了简化，只列出了一些关键信息。至于这些证书信息的用处，我们看看具体的通信流程就能够弄明白了。流程如下：1.作为服务端的小红，首先把自己的公钥发给证书颁发机构，向证书颁发机构申请证书。 image 2.证书颁发机构自己也有一对公钥私钥。机构利用自己的私钥来加密Key1，并且通过服务端网址等信息生成一个证书签名，证书签名同样经过机构的私钥加密。证书制作完成后，机构把证书发送给了服务端小红。 image 3.当小灰向小红请求通信的时候，小红不再直接返回自己的公钥，而是把自己申请的证书返回给小灰。 image

4.小灰收到证书以后，要做的第一件事情是验证证书的真伪。需要说明的是，各大浏览器和操作系统已经维护了所有权威证书机构的名称和公钥。所以小灰只需要知道是哪个机构颁布的证书，就可以从本地找到对应的机构公钥，解密出证书签名。接下来，小灰按照同样的签名规则，自己也生成一个证书签名，如果两个签名一致，说明证书是有效的。验证成功后，小灰就可以放心地再次利用机构公钥，解密出服务端小红的公钥Key1。

image 5.像之前一样，小灰生成自己的对称加密密钥Key2，并且用服务端公钥Key1加密Key2，发送给小红。 image 6.最后，小红用自己的私钥解开加密，得到对称加密密钥Key2。于是两人开始用Key2进行对称加密的通信。 image 在这样的流程下，我们不妨想一想，中间人是否还具有使坏的空间呢？ image image image image image image image 注：最新推出的TLS协议，是SSL 3.0协议的升级版，和SSL协议的大体原理是相同的。 image

HTTP 相关问题

1. HTTP 协议的主要特点?
   • 简单快速，每个资源 URI--统一资源符 是固定的，比如图片、页面地址；
   • 灵活，头部分的数据类型，通过一个 HTTP 协议可以完成不同类型数据的传输；
   • 无连接，连接一次就断掉，不会保持连接；
   • 无状态，客户端和服务端是两种身份，HTTP 协议仅帮助传输，不能在两次连接确定身份；
2. HTTP 报文的组成部分？
   • 请求报文：请求行、请求头、空行、请求体；
   • 请求行：HTTP 方法，页面地址，HTTP 协议以及版本；
   • 请求头：key value 值，告诉服务端要请求的内容；
   • 空行：位于请求头和请求体之间的空行；
   • 请求体：请求参数穿成的字符串 param1=value1&param2=value2；
   • 响应报文：状态行、响应头、空行、响应体；
3. HTTP 方法?
   • GET, POST, PUT 更新,DELETE, HEAD 获得报文首部；
4. POST 和 GET 的区别?
   • GET 在浏览器回退时是无害的，而 POST 会再次提交请求；
   • GET 产生的 URL 地址可以被收藏，而 POST 不可以；
   • GET 请求会被浏览器主动缓存，而 POST 不会，除非手动设置；
   • GET 请求只能进行 URL 编码，而 POST 支持多种编码方式；
   • GET 请求参数会被完整保留在浏览器历史记录中，而 POST 中的参数不会被保留；
   • GET 请求在 URL 中传递的参数是有长度限制的，而 POST 没有限制；
   • 对参数的数据类型，GET 只接受 ASCII 字符，而POST 没有限制；
   • GET 比 POST 更不安全，因为参数直接暴露在 URL 上，所以不能用来传递敏感信息；
   • GET 参数通过 URL 传递，POST 放在 Request body 中；
5. HTTP 状态码?
   • 1XX: 指示信息 -- 表示请求已接收，继续处理；
   • 2xx: 成功 -- 表示请求已被成功接收。 200 OK: 客户端请求成功， 206 partial content: 客户端发送了一个带有 range 头的 GET 请求，服务器完成了它；
   • 3xx: 重定向 -- 要完成请求必须进行更进一步操作。301 Moved Permanently: 所请求的页面已经转移至新 URL； 302 found: 所请求的页面已经临时转移至新 URL；304 Not Modified: 客户端有缓冲的文档并发出了一个条件性的请求，服务器告诉客户，原来缓冲的文档还可以继续使用；
   • 4xx: 客户端错误 -- 请求语法错误或请求无法实现。400 Bad request: 客户端请求有语法错误，不能被服务器所理解； 401 Unauthorized: 请求未经授权，这个状态码必须和 WWW-Anthenticate 报头域一起使用；403 Forbidden: 被请求页面的访问被禁止； 404 Not found: 请求资源不存在；
   • 5xx: 服务端错误 -- 服务器未能实现合法的请求。500 Internal Server Error: 服务器发生不可预期的错误，原来缓冲的文档还可以继续使用；503 Server Unavailable: 请求未完成，服务器临时过载或宕机，一段时间后可能恢复正常；
6. 什么是持久连接?
   • HTTP 协议采用“请求-应答”模式，当使用普通模式，即非 Keep-Alive 模式时，每个请求/应答客户端和服务器都需新建一个连接，完成之后立即断开连接（HTTP 协议为无连接协议）；
   • 当使用 Kepp-Alive 模式（有称持久连接、连接重用）时，Keep-alive 功能是客户端到服务器端的连接持续有效，当出现对服务器的后继请求时，Keep-alive 功能避免了建立或者重新建立连接；
7. 什么是管线化?
   • 在使用持久连接的情况下，某个连接上消息的传递类似于：请求1 -> 响应1 -> 请求2 ->响应2 -> 请求3 -> 响应3；
   • 某个连接上的消息变成了类似这样：请求1 -> 请求2 -> 请求3 -> 响应1 ->响应2 -> 响应3；
   • 管线化机制通过持久连接完成，仅 HTTP/1.1 支持此技术；
   • 只有 GET 和 HEAD 请求可以进行管线化，而 POST 则有所限制；
   • 初次创建连接时不应启动管线机制，因为对方（服务器）不一定支持 HTTP/1.1 版本的协议；
   • 管线化不会影响响应到来的顺序，如上面例子所示，响应返回的顺序并未改变；
   • HTTP/1.1 要求服务器支持管线化，但并不要求服务器端也对响应进行管线化处理，只要求对于管线化的请求不失败即可；
   • 由于上面提到的服务器端问题，开启管线化很可能并不会打来大幅度性能提升，而且很多服务端和代理程序对管线化支持并不好，因此现代浏览器如 Chrome 和Firefox 默认并未开启管线化支持；

总结：
1、https是为了给http的加密，防止用户信息被不法分子盗用；
2、https除了对称加密、非对称加密之外，还引入了一个类似公证人的联合机构组织，作为信息交换过程中双向加密的中转站；
3、这种方式并不代表绝对安全，因为没有绝对的安全系统；