是在应用层和 传输层之间 添加的 安全层（SSL/TLS协议）
-
端口号 ：HTTP 默认是 80，HTTPS 默认是 443。
-
URL 前缀 ：HTTP 的 URL 前缀是
http://，HTTPS 的 URL 前缀是https://。 -
安全性和资源消耗 ： HTTP 协议运行在 TCP 之上，所有传输的内容都是明文，客户端和服务器端都无法验证对方的身份。HTTPS 是运行在 SSL/TLS 之上的 HTTP 协议，SSL/TLS 运行在 TCP 之上。所有传输的内容都经过加密，加密采用对称加密，但对称加密的密钥用服务器方的证书进行了非对称加密。
问题： 如果 服务端的公钥通过明文传输 不安全 可以被攻击者破解 所以就需要用到数字证书CA（数字证书颁发机构）了
-
所以说，HTTP 安全性没有 HTTPS 高，但是 HTTPS 比 HTTP 耗费更多服务器资源。
公钥传输的信赖性
假设 S 公钥不做加密，在信道中传输，那么很有可能存在一个攻击者 A，发送给 C 一个诈包，假装是 S 公钥，其实是诱饵服务器 AS 的公钥。当 C 收获了 AS 的公钥（却以为是 S 的公钥），C 后续就会使用 AS 公钥对数据进行加密，并在公开信道传输，那么 A 将捕获这些加密包，用 AS 的私钥解密，就截获了 C 本要给 S 发送的内容，而 C 和 S 二人全然不知。
解决方法:
为了公钥传输的信赖性问题，第三方机构应运而生——证书颁发机构（CA，Certificate Authority）。CA 默认是受信任的第三方。CA 会给各个服务器颁发证书，证书存储在服务器上，并附有 CA 的电子签名（见下节）。
当客户端（浏览器）向服务器发送 HTTPS 请求时，一定要先获取目标服务器的证书，并根据证书上的信息，检验证书的合法性。一旦客户端检测到证书非法，就会发生错误。客户端获取了服务器的证书后，由于证书的信任性是由第三方信赖机构认证的，而证书上又包含着服务器的公钥信息，客户端就可以放心的信任证书上的公钥就是目标服务器的公钥。
而证书是通过数字签名实现的： 证书的认证是传输的第一步 防止 出现攻击者炸包的情况
总结来说，带有证书的公钥传输机制如下：
-
设有服务器 S，客户端 C，和第三方信赖机构 CA。
-
S 信任 CA，CA 是知道 S 公钥的，CA 向 S 颁发证书。并附上 CA 私钥对消息摘要的加密签名。
-
S 获得 CA 颁发的证书，将该证书传递给 C。
-
C 获得 S 的证书，信任 CA 并知晓 CA 公钥，使用 CA 公钥对 S 证书上的签名解密，同时对消息进行散列处理，得到摘要。比较摘要，验证 S 证书的真实性。
-
如果 C 验证 S 证书是真实的，则信任 S 的公钥（在 S 证书中）。