ssl和tls

 

HTTP 是一个网络协议，是专门用来帮你传输 Web 内容

SSL 是Secure Sockets Layer 为啥要发明 SSL 这个协议捏？由于原先互联网上使用的 HTTP 协议是明文的，存在不少缺点——好比传输内容会被偷窥（嗅探）和篡改。发明 SSL 协议，就是为了解决这些问题。到了1999年，SSL 由于应用普遍，已经成为互联网上的事实标准。IETF 就在那年把 SSL 标准化标准化以后的名称改成 TLS（是“Transport Layer Security”的缩写），中文叫作“传输层安全协议”。

不少相关的文章都把这二者并列称呼（SSL/TLS），由于这二者能够视做同一个东西的不一样阶段。

HTTPS 协议，说白了就是“HTTP 协议”和“SSL/TLS 协议”的组合。你能够把 HTTPS 大体理解为——“HTTP over SSL”或“HTTP over TLS”（反正 SSL 和 TLS 差很少）。

TCP 协议是 HTTP 协议的基石——HTTP 协议须要依靠 TCP 协议来传输数据。

有不少常见的应用层协议是以 TCP 为基础的，好比“FTP、SMTP、POP、IMAP”等。
TCP 被称为“面向链接”的传输层协议。传输层主要有两个协议，分别是 TCP 和 UDP。TCP 比 UDP 更可靠。你能够把 TCP 协议想象成某个水管，发送端这头进水，接收端那头就出水。而且 TCP 协议可以确保，先发送的数据先到达（与之相反，UDP 不保证这点）。

HTTP 对 TCP 链接的使用，分为两种方式：俗称“短链接”和“长链接”（“长链接”又称“持久链接”，洋文叫作“Keep-Alive”或“Persistent Connection”）

假设有一个网页，里面包含好多图片，还包含好多【外部的】CSS 文件和 JS 文件。在“短链接”的模式下，浏览器会先发起一个 TCP 链接，拿到该网页的 HTML 源代码（拿到 HTML 以后，这个 TCP 链接就关闭了）。而后，浏览器开始分析这个网页的源码，知道这个页面包含不少外部资源（图片、CSS、JS）。而后针对【每个】外部资源，再分别发起一个个 TCP 链接，把这些文件获取到本地（一样的，每抓取一个外部资源后，相应的 TCP 就断开）
相反，若是是“长链接”的方式，浏览器也会先发起一个 TCP 链接去抓取页面。可是抓取页面以后，该 TCP 链接并不会当即关闭，而是暂时先保持着（所谓的“Keep-Alive”）。而后浏览器分析 HTML 源码以后，发现有不少外部资源，就用刚才那个 TCP 链接去抓取此页面的外部资源

在 HTTP 1.0 版本，【默认】使用的是“短链接”（那时候是 Web 诞生初期，网页相对简单，“短链接”的问题不大）；
到了1995年末开始制定 HTTP 1.1 草案的时候，网页已经开始变得复杂（网页内的图片、脚本愈来愈多了）。这时候再用短链接的方式，效率过低下了（由于创建 TCP 链接是有“时间成本”和“CPU 成本”滴）。因此，在 HTTP 1.1 中，【默认】采用的是“Keep-Alive”的方式

所谓的“对称加密技术”，意思就是说：“加密”和“解密”使用【相同的】密钥。

所谓的“非对称加密技术”，意思就是说：“加密”和“解密”使用【不一样的】密钥。

（从功能角度而言）“非对称加密”能干的事情比“对称加密”要多。这是“非对称加密”的优势。可是“非对称加密”的实现，一般须要涉及到“复杂数学问题”。因此，“非对称加密”的性能一般要差不少（相对于“对称加密”而言）。
这二者的优缺点，也影响到了 SSL 协议的设计

由于是先有 HTTP 再有 HTTPS。因此，HTTPS 的设计者确定要考虑到对原有 HTTP 的兼容性。这里所说的兼容性包括不少方面。好比已有的 Web 应用要尽量无缝地迁移到 HTTPS；好比对浏览器厂商而言，改动要尽量小；……基于“兼容性”方面的考虑，很容易得出以下几个结论：1. HTTPS 仍是要基于 TCP 来传输（若是改成 UDP 做传输层，不管是 Web 服务端仍是浏览器客户端，都要大改，动静太大了）2. 单独使用一个新的协议，把 HTTP 协议包裹起来（所谓的“HTTP over SSL”，其实是在原有的 HTTP 数据外面加了一层 SSL 的封装。HTTP 协议原有的 GET、POST 之类的机制，基本上原封不动）