HTTP 不足 [ 新手入门 ]

1.1 明文传输 Http 的整个报文信息，从客户端到服务端到都是明文传输到。信息从我们的电脑发出去，中间需要经历哪些设备才能被另一台电脑接收，我们是不好确定也很难评估的。有可能跨越多个运营商机房，有可能通过海底光缆横跨大洋，有可能穿过 某某学校 / 某某厂房 / 某某集团 的内部 路由器/ 交换机 / 集线器 等。中间这么多节点我们都是控制不到的，所以只要别人有心，我们就很难保证我们的信息不被泄漏。

网络传输

1.2 没有验证通信方身份 通信双方无法确认对方的身份是否正确。

案例1: 本地电脑有木马，路由表被踹改，www.baidu.com 的域名被解析到另一台虚假的服务器，此时你在浏览器访问的百度就是黑客的另一个钓鱼网站，然后给你推送了很多虚假消息，此时客户端很难知情。

案例2: 路由表没问题，但是目标服务器被人黑了，处理不了请求，此时有其它服务冒充提供服务。 伪装

案例3: 某个资源只有特定用户有查询的权限，黑客通过伪造该客户端一样的请求来查询，服务端只是简单的根据入参判断，并无法知道对应客户端的真实性，于是消息很容易泄漏。

1.3 无法保证数据完整性 消息篡改

客户端 A 像服务端 B 充值 100。 A 的网络报文被黑客窃取了，修改了中间的金额，后面继续把报文传向 B，此时就造成了严重的金额损失。 上面的例子如果没有做数据完整性校验就很容易被攻陷。当然很多系统即使用 Http 协议，也可以自己在业务层参数中定义签名信息，实现自己的签名算法保障数据的完整性。

signature = MD5(privateKey + MD5（ 参数1 + 参数2 + 参数2 +...）) 代码块 1 签名算法有很多种，系统的签名算法是机密性的信息，不能对外透漏。例如上面的算法中，将请求的所有参数依次相加然后做 MD5 运算，取得的值再与约定的一个私密 key 再进行一次 MD5，最后生成一个签名 signature。这个算法客户端和服务端都是知道的，所以服务端接收到请求后，就拿着获取到的参数做执行一遍通用的算法，然后将生成的签名与客户端传过来的签名做比较，相同的话就证明请求数据没有被人改动过。

但是这边有个问题，浏览器上面的 Js 代码能容易被查看到，即使加密也很容易破解，我们的算法和私钥都很容易泄漏。如果是安卓或者IOS程序，亦或是2个后台服务的通信，这种情况算法用户是看不到，但是软件开发是一个团队协作的工作，一般负责的开发人员都知道，可靠性就没办法太高。相比，Https 的签名算法是公开的，他生成的签名算法还会用公钥去加密。同样，如果 Http 也要整这么麻烦也是可以的，只是需要在自己的业务逻辑中去实现，而 Https 借助的是安全套接字层，对应用层完全透明，我们的应用不需要多做什么就可以实现可靠性传输了。