HTTP背后的故事：理解现代网络如何工作的关键（三）

一.认识状态码(status code)

1.常见的状态码

状态码：状态码表示访问一个页面的结果. (是访问成功, 还是失败, 还是其他的一些情况)

HTTP 中的状态码都是标准约定好的，先介绍几个常见的状态码：

 200 OK 这是一个最常见的状态码, 表示访问成功.

404 Not Found 访问的资源没找到（没找到url 中的路径，人家服务器没有提供这个页面）

---

403 Forbidden：表示访问被拒绝. 有的页面通常需要用户具有一定的权限才能访问(登陆后才能访问)， 如果用户没有登陆 ，直接访问, 就容易见到 403。

---

405 Method Not Allowed：对方的服务器不支持你使用的方法(或者不允许用户使用一些其他的方法)

前面我们已经学习了 HTTP 中所支持的方法 , 有 GET, POST, PUT, DELETE 等 .

但是对方的服务器不一定都支持所有的方法。

500 Internal Server Error 服务器内部错误(服务器挂了) 

504 Gateway Timeout 访问服务器超时了，可能是服务器挂了,也可能是网挂了~~

302 Move temporarily 重定向(临时重定向)，你要找到的是A网站，但是网站的域名更新为B网站，就帮你跳转到B网站。在登陆页面中经常会见到 302. 用于实现登陆成功后自动跳转到主页.

响应报文的 header 部分会包含一个 Location 字段 , 表示要跳转到哪个页面

301永久重定向。如果是永久重定向，浏览器就会把重定向的结果记录下来。
后续再次访问,就直接访问重定向的目标地址即可,不必多一次跳转了~~
如果是临时重定向，就不太方便缓存。

418 在 HTTP 协议的标准文档上是存在的- >"l am a teapot" 我是个茶壶(我是个杯具)

(虽然没有啥实际的含义，属于彩蛋)

状态码小结：

---

2.Postman

如何构造出 HTTP 请求
1. 通过代码构造任何一种编程语言,只要能够操作网络,都可以构造 HTTP 请求!!

2).通过第三方工具构造 PostMan 经典的,广泛使用的工具

 

二.HTTPS

1.什么是HTTPS

HTTPS 也是一个应用层协议. 是在 HTTP 协议的基础上引入了一个加密层(SSL).

HTTP 协议内容都是按照文本的方式明文传输的. 这就导致在传输过程中出现一些被篡改的情况。

 

2.运营商劫持

比如我要下载一个天天动听应用。

未被劫持的效果, 点击下载按钮, 就会弹出天天动听的下载链接.

已被劫持的效果, 点击下载按钮, 就会弹出 QQ 浏览器的下载链接

 

由于我们通过网络传输的任何的数据包都会经过运营商的网络设备 ( 路由器 , 交换机等 ), 那么运营商的网络设备就可以解析出你传输的数据内容, 并进行篡改， 点击 " 下载按钮 ", 其实就是在给服务器发送了一个 HTTP 请求 , 获取到的 HTTP 响应其实就包含了该 APP的下载链接. 运营商劫持之后, 就发现这个请求是要下载天天动听, 那么就自动的把交给用户的响应给篡改成 "QQ浏览器" 的下载地址了。

不止运营商可以劫持 , 其他的 黑客 也可以用类似的手段进行劫持 , 来窃取用户隐私信息 , 或者篡改内容 .

试想一下 , 如果黑客在用户登陆支付宝的时候获取到用户账户余额 , 甚至获取到用户的支付密码......

在互联网上 , 明文传输是比较危险的事情 !!!

HTTPS 就是在 HTTP 的基础上进行了加密 , 进一步的来保证用户的信息安全!

上述的运营商劫持 无论是修改 referer 还是修改返回的 链接(body),本质上都是明文传输惹的祸

需要引入加密，对上述传输的数据进行保护。主要就是要针对 header 和 body 进行加密

所以解决安全问题,最核心的要点,就是“加密".

3.加密是什么

加密就是把 明文 ( 要传输的信息 ) 进行一系列变换 , 生成 密文。

解密就是把 密文 再进行一系列变换 , 还原成 明文  。

在这个加密和解密的过程中 , 往往需要一个或者多个中间的数据 , 辅助进行这个过程 , 这样的数据称为 密 钥（yao 第四声）。

既然要保证数据安全 , 就需要进行 " 加密 ".

4.对称加密

加密的方式有很多 , 但是整体可以分成两大类 : 对称加密 和 非对称加密

对称加密：加密和解密，使用的是同一个密钥。

一个简单的对称加密 , 按位异或

假设 明文 a = 1234, 密钥 key = 8888

则加密 a ^ key 得到的密文 b 为 9834.

然后针对密文 9834 再次进行运算 b ^ key, 得到的就是原来的明文 1234.

( 对于字符串的对称加密也是同理 , 每一个字符都可以表示成一个数字 )

当然 , 按位异或只是最简单的对称加密 . HTTPS 中并不是使用按位异或 .

对称加密步骤：

客户端在本地生成对称密钥 , 通过公钥加密 , 发送给服务器 .

• 由于中间的网络设备没有私钥, 即使截获了数据, 也无法还原出内部的原文, 也就无法获取到对称密钥
• 服务器通过私钥解密, 还原出客户端发送的对称密钥. 并且使用这个对称密钥加密给客户端返回的响应数据.
• 后续客户端和服务器的通信都只用对称加密即可. 由于该密钥只有客户端和服务器两个主机知道,其他主机/设备不知道密钥即使截获数据也没有意义

引入对称加密之后 , 即使数据被截获 , 由于黑客不知道密钥是啥 , 因此就无法进行解密 , 也就不知道请求的真实内容是啥了.

但事情没这么简单 . 服务器同一时刻其实是给很多客户端提供服务的 . 这么多客户端 , 每个人用的秘钥都必须是不同的( 如果是相同那密钥就太容易扩散了 , 黑客就也能拿到了 ). 因此 服务器就需要维护每个客户 端和每个密钥之间的关联关系 , 这也是个很麻烦的事情.

比较理想的做法 , 就是能在客户端和服务器建立连接的时候 , 双方 协商 确定这次的密钥是啥

但是如果直接把密钥明文传输 , 那么黑客也就能获得密钥了 ~~ 此时后续的加密操作就形同虚设了

因此密钥的传输也必须再加密传输 !

此时 就需要引入 非对称加密 .。

 5.非对称加密

非对称加密要用到两个密钥, 一个叫做 "公钥", 一个叫做 "私钥"。

公钥和私钥是配对的 . 最大的缺点就是 运算速度非常慢 ，比对称加密要慢很多。

• 通过公钥对明文加密, 变成密文
• 通过私钥对密文解密, 变成明文

也可以反着用

• 通过私钥对明文加密, 变成密文
• 通过公钥对密文解密, 变成明文

6.加密步骤（重要）

根据对称密匙和非对称密匙我们来捋顺步骤：

 1.先通过对称加密,针对 HTTP 中的 header / body 进行加密

• 每个客户端都需要使用不同的密钥
• 此时就需要客户端生成好密钥之后,告知服务器(需要确保密匙能够安全传过去)

2. 引入非对称加密.主要就是针对 对称密钥 的传输 来进行加密。

由于非对称加密系统开销,远远大于对称加密.不太适合使用非对称加密,针对大规模的数据进行加密

3.服务器生成一对非对称密钥，私钥服务器自己持有，公钥则可以告知任何的客户端。

4.客户端在连上服务器之后,就需要先从服务器这边拿到公钥.(公钥本身就可以公开出去,不需要加密传输)，

• 客户端生成对称密钥,拿着公钥针对对称密钥进行加密。
• 此时就可以把加密之后的密文进行传输了.由于要想解密,必须通过私钥,而私钥只有服务器自己知道.
• 此时这样的加密的数据就可以比较安全的到达服务器了.

5.服务器通过私钥解密之后得到了对称密钥,接下来和客户端之间的通信就通过对称加密来完成了。

步骤如下：

补充：

以上过程也是SSL 内部完成的工作

• 使用 HTTPS 的时候,底层也是 TCP
• 先进行 TCP 三次握手,TCP 连接打通之后
• 就要进行 SSL 的握手了(交换密钥的过程
• 后面才是真正传输业务数据.(完整的 HTTPS 的请求/响应了)

但问题是：即使是上述操作下，仍然存在重大的安全漏洞,黑客仍然是有办法获取到对称密钥 key 的！

服务器可以创建出一对公钥和私钥,黑客也可以按照同样的方式，创建出一对公钥和私钥
冒充自己是服务器。

如图所示：

对于黑客来说：

黑客自己也能生成一对公钥和私钥，设 公钥为 pub2 私钥为 pri2
黑客不关心服务器的公钥私钥是啥,自己生成一对就行了
生成公钥和私钥的算法都是开放的，服务器能生成,黑客也能生成。

黑客就可以使用 pri2 对上述数据进行解密!!
因此黑客就拿到了 key !!!
黑客继续使用从服务器拿到的 pub1 重新对 key 进行加密，并且传输给服务器!!!

道高一尺魔高一丈，此时我们还有应对黑客的手段，办法如下：

既然如此，客户端拿到公钥的时候,要能有办法验证,这个公钥是否是真的,而不是黑客伪造的。 

怎么证明公钥呢？

7.引入证书

引入证书：

在客户端和服务器刚一建立连接的时候 , 服务器给客户端返回一个 证书 .

这个证书包含了刚才的公钥 , 也包含了网站的身份信息 .

 

这个 证书 可以理解成是一个，证书发布机构，证书有效期，公钥，证书所有者，签名。

当客户端获取到这个证书之后 , 会对证书进行校验 ( 防止证书是伪造的 ).

• 判定证书的有效期是否过期
• 判定证书的发布机构是否受信任(操作系统中已内置的受信任的证书发布机构).
• 验证证书是否被篡改: 从系统中拿到该证书发布机构的公钥, 对签名解密, 得到一个 hash 值(称为数据摘要), 设为 hash1. 然后计算整个证书的 hash 值, 设为 hash2. 对比 hash1 和 hash2 是否相等.
• 如果相等, 则说明证书是没有被篡改过的.       

补充：

什么是校验和？
把证书中其他的字段通过一系列的算法(CRC,MD5 等),得到一个较短的字符串=> 校验和

什么是签名？

颁布证书的公正机构，会在发布证书的时候,给这个证书计算出，一个校验和，然后公证机构使用自己的私钥(和服务器的私钥无关)，针对校验和进行加密.此时就得到了证书的签名。

如果两份数据内容一样,此时校验和,就一定是相同的，则签名为真。
如果校验和不同,两份数据的内容则一定不同，签名为假。

客户端拿到证书之后,主要做两件事:
1.按照同样的校验和算法,把证书的其他字段都重新算一遍,得到 校验和1
2.使用系统中内置的公正机构公钥,对证书中的签名进行解密，得到校验和2

• 此时，就可以对比,看这俩校验和是否一致!!
• 如果一致,说明证书是没有被修改过的.就是原版证书
• 如果不一致,说明证书被别人篡改过了.(比如黑客如果替换了自己的公钥,此时算
• 出来的校验和一定发生改变)，此时客户端就能识别出来了!!!

此时黑客的手段有哪些呢？

1.如果黑客直接修改公钥,不修改签名
此时,客户端验证的校验和是一定不一样的.就识别出来了

2.如果黑客修改公钥,尝试重新生成签名？
由于黑客不知道公证机构的私钥,所以黑客无法重新生成加密的签名

3.如果黑客拿自己的私钥加密呢??

客户端这边拿着公证机构的公钥也会解密失败。

4.黑客能不能自己也去公证机构申请个证书?? 然后把自己的证书替换掉服务器的证书呢??

不行！域名是唯一的， 黑客申请的证书的域名，和服务器的域名肯定不相同!!!
客户端拿到证书之后,一看域名都不一样,直接就知道证书是假冒的了，都不用验证校验和了。