Http
Http (Hypertext Transfer Protocol) 超文本传输语言
- Http协议 的诞生主要还是为了物理机之间能够进行资源的传递，当然仅仅依靠http协议无法完成资源的传递， 还需要依靠 Tcp/Ip 协议族 、DNS 解析服务器等等一些复杂的过程，这里我们只需要了解到 Http 生成了针对目标服务器的Http请求报文，报文具体内容我们 F12 就能在在network中看到每个Http请求的具体内容
Http协议缺点
- 通信使用明文（不加密），内容有可能会贝窃听
- 不验证通信方的身份，因此有可能遭遇伪装
- 无法证明报文的完整性，所以有可能已遭篡改 通信使用明文（不加密），内容有可能会贝窃听： http请求设计之初是本着足够简单的原则，身不具备加密的功能，所以也无法做到对通信整体（使用 HTTP 协议通信的请求和响应的内容）进行加密。即，HTTP 报文使用明文（指未经过加密的报文）方式发送。当然，http请求其实并未暴露我们所请求的资源，最多也就是暴露了请求的uri，资源的定位符，但是TCP/IP 是可能被窃听的网络，我们可以通过抓包（Packet Capture）或嗅探器（Sniffer）工具来窃听通信过程。
不验证通信方的身份，因此有可能遭遇伪装： HTTP 协议的实现本身非常简单，不论是谁发送过来的请求都会返回响应，因此不确认通信方。当然我们可以在代码层面上做很多验证，如cookie+session的方式，但是 http 本身是不会去验证通信方的身份。不验证通信方的身份就可能遭遇伪装，客户端发送请求给服务端，服务端收到请求返回相应给客户端，客户端收到响应。如果通信方的身份是不确定的，那么可能客户端会收到伪装的服务端相应过来的消息，服务端也会收到伪装的客户端发送的请求，并且，即使是无意义的请求也会照单全收。无法阻止海量请求下的 DoS 攻击（Denial of Service，拒绝服务攻击）
无法证明报文的完整性，所以有可能已遭篡改：http 无法判断通信收到的报文是完整的，当然这里我们会想到报文的校验在Tcp/Ip 协议族里，数据链路层等都有过报文段完整的校验，报文的差错校验等，但是由于应用层即Http层是没有加密的，这些方法目前仍然是不够安全的，曾经我们常用MD5、PGP之类的散列值校验的方法，来进行加密，但是依然无法百分百保证确认结果正确。因为 PGP 和 MD5 本身被改写的话，用户是没有办法意识到的。
为了解决这些问题，我们可以采用HttpsHttps
Https
Https (HTTP+ 加密 + 认证 + 完整性保护) HTTPS 并非是应用层的一种新协议。只是 HTTP 通信接口部分用SSL（Secure Socket Layer）和 TLS（Transport Layer Security）协议代替而已。
通常，HTTP 直接和 TCP 通信。当使用 SSL时，则演变成先和 SSL通信，再由 SSL和 TCP 通信了。简言之，所谓 HTTPS，其实就是身披SSL协议这层外壳的 HTTP。
解决被监听问题
加密处理防止被窃听: 在目前大家正在研究的如何防止窃听保护信息的几种对策中，最为普及的就是加密技术。加密的对象可以有这么几个。
通信的加密: 一种方式就是将通信加密。HTTP 协议中没有加密机制，但可以通过和 SSL（Secure Socket Layer，安全套接层）或 TLS（Transport Layer Security，安全层传输协议）的组合使用，加密 HTTP 的通信内容。用 SSL建立安全通信线路之后，就可以在这条线路上进行 HTTP通信了。与 SSL组合使用的 HTTP 被称为 HTTPS（HTTPSecure，超文本传输安全协议）或 HTTP over SSL。
内容的加密:还有一种将参与通信的内容本身加密的方式。由于 HTTP 协议中没有加密机制，那么就对 HTTP 协议传输的内容本身加密。即把HTTP 报文里所含的内容进行加密处理。在这种情况下，客户端需要对 HTTP 报文进行加密处理后再发送 请求。
解决身份伪装问题 SSL使用了一种被称为证书的手段，可用于确定身份。证书由值得信任的第三方机构颁发，用以证明服务器和客户端是 实际存在的。另外，伪造证书从技术角度来说是异常困难的一件事。所以只要能够确认通信方（服务器或客户端）持有的证书，即可判断通信方的真实意图。
解决报文完整性的问题 SSL提供认证和加密处理及摘要功能,当我们能对通信过程和内容都能进行加密的话，报文被篡改就变得十分困难
SSL
SSL 的加密技术 目前我们有两种主流的加密技术
共享加密技术：即加密和解密需要同一把密钥，也成为对称加密技术，缺点很容易想到，既然是同一把密钥，发送方就需要把密钥传给接收方，如果通道被监听，那么密钥同样有可能落入他人之手
两把密钥的公开密钥加密：公开密钥加密使用一对非对称的密钥。一把叫做私有密钥（private key），另一把叫做公开密钥（public key）。顾名思义，私有密钥不能让其他任何人知道，而公开密钥则可以随意发布，任何人都可以获得。使用公开密钥加密方式，发送密文的一方使用对方的公开密钥进行加密处理，对方收到被加密的信息后，再使用自己的私有密钥进行解密。利用这种方式，不需要发送用来解密的私有密钥，也不必担心密钥被攻击者窃听而盗走。
SSL采取两种混合方式，再通信信道安全的情况瞎采用共享加密方法，否则采用公开密钥方法，毕竟共享加密更快一些
这里还有一个问题要处理的就是私有密钥怎么确定？公开密钥又怎么确定是不上真的公开密钥？比如，正准备和某台服务器 建立公开密钥加密方式下的通信时，如何证明收到的公开密钥就是原本预想的那台服务器发行的公开密钥。或许在公开密钥传输途中，真正的公开密钥已经被攻击者替换掉了。
这里可以用数字证书来解决这个问题。数字证书认证机构处于客户端与服务器双方都可信赖的第三方机构的立场上。首先，服务器的运营人员向数字证书认证机构提出公开密钥的申请。数字证书认证机构在判明提出申请者的身份之后，会对已申请的公开密钥做数字签名，然后分配这个已签名的公开密钥，并将该公开密钥放入公钥证书后绑定在一起。
服务器会将这份由数字证书认证机构颁发的公钥证书发送给客户端，以进行公开密钥加密方式通信。公钥证书也可叫做数字证书或直接称为证书。
接到证书的客户端可使用数字证书认证机构的公开密钥，对那张证书上的数字签名进行验证，一旦验证通过，客户端便可明确两件事：一，认证服务器的公开密钥的是真实有效的数字证书认证机构。二，服务器的公开密钥是值得信赖的。此处认证机关的公开密钥必须安全地转交给客户端。使用通信方式 时，如何安全转交是一件很困难的事，因此，多数浏览器开发商发布版本时，会事先在内部植入常用认证机关的公开密钥。
总结：
1、数字证书认证机构的公钥已默认植入浏览器
2、服务器再第三方数字证书机构注册自己的公共密钥，生成数字证书
3、数字证书认证机构用自己的私有密钥向服务器的公开密钥署数字签名并颁发公钥证书
4、客户端收到服务器的公钥证书后，使用浏览器内嵌的数字证书认证机构的公钥进行解密
5、用服务器的公钥加密后向服务器发送消息
SSL的EV SSL 证书同样也是基于这个原理 基于 Https 的方式通信时，客户端需要先向服务器端发SSL安全通道的请求，服务器向客户端发送公钥数字证书，客户端解密得到服务器公钥，客户端利用服务器公钥加密发送消息，当然，我们知道要建立一个可靠信道的最短通信次数是三次，否则TCP协议也不会是三次握手，建立一个可靠的SSL通道也需要多次协商，具体过程各位自己查资料把，类似于TCP三次握手
