HTTP协议有哪些特色 当前咱们使用的HTTP 协议版本号是 1.1(也就是 HTTP 1.1)。这个 1.1 版本是1995*底开始起草的(技术文档是 RFC2068)，并在1999*正式发布(技术文档是 RFC2616)。在 1.1 以前，还有曾经出现过两个版本“0.9 和 1.0”，其中的 HTTP 0.9 【没有】被普遍使用，而 HTTP 1.0 被普遍使用过。据悉，2015IETF 就要发布HTTP 2.0 的标准。简单地说，TCP 协议是 HTTP 协议的基石——HTTP 协议须要依靠 TCP 协议来传输数据。在网络分层模型中，TCP 被称为“传输层协议”，而 HTTP 被称为“应用层协议”。有不少常见的应用层协议是以 TCP 为基础的，好比“FTP、SMTP、POP、IMAP”等。TCP 被称为“面向链接”的传输层协议。传输层主要有两个协议，分别是 TCP 和 UDP。TCP 比 UDP 更可靠。你能够把 TCP 协议想象成某个水管，发送端这头进水，接收端那头就出水。而且 TCP 协议可以确保，先发送的数据先到达(与之相反，UDP 不保证这点)。HTTP 对 TCP 链接的使用，分为两种方式：俗称“短链接”和“长链接”(又称“持久链接”)。假设有一个网页，里面包含好多图片，还包含好多【外部的】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”的方式。
什么是“对称加密”和“非对称加密” 安全
1. “加密”和“解密” 通俗而言，你能够把“加密”和“解密”理解为某种【互逆的】数学运算。就比如“加法和减法” 互为逆运算、“乘法和除法”互为逆运算。“加密”的过程，就是把“明文”变成“密文”的过程;反之，“解密”的过程，就是把“密文”变为“明文”。在这两 个过程当中，都须要一个关键的东西——叫作“密钥”——来参与数学运算。
2. 什么是“对称加密” 所谓的“对称加密技术”，意思就是说：“加密”和“解密”使用【相同的】密钥。这个比较好理 解。就比如你用 7zip 或 WinRAR 建立一个带密码(口令)的加密压缩包。当你下次要把这个压缩文件解开的时候，你须要输入【一样的】密码。在这个例子中，密码/口令就如同刚才说的“密 钥”。
3. 什么是“非对称加密” 所谓的“非对称加密技术”，意思就是说：“加密”和“解密”使用【不一样的】密钥。这玩意儿比较难理解，也比较难想到。当*“非对称加密”的发明，还被誉为“密码学”历史上的一次革命。具体相关“非对称加密”后面再详细介绍。
4.“对称加密”和“非对称加密”的优缺点 从功能角度而言“非对称加密”能干的事情比“对称加密”要多。这是“非对称加密”的优势。可是“非对称加密”的实现，一般须要涉及到“复杂数学问*”。因此，“非对称加密”的性能一般要差不少(相对于“对称加密”而言)。这二者的优缺点，也影响到了 SSL 协议的设计。
HTTPS 协议的需求 由于是先有 HTTP 再有 HTTPS。因此，HTTPS 的设计者确定要*虑到对原有 HTTP 的兼容性。这里所说的兼容性包括不少方面。好比已有的 Web 应用要尽量无缝地迁移到 HTTPS;好比对浏览器厂商而言，改动要尽量小;...... 基于“兼容性”方面的*虑，很容易得出以下几个结论： 1. HTTPS 仍是要基于TCP 来传输 (若是改成 UDP 做传输层，不管是 Web 服务端仍是浏览器客户端，都要大改，动静太大了)2. 单独使用一个新的协议，把 HTTP 协议包裹起来 (所谓的“HTTP over SSL”，其实是在原有的 HTTP 数据外面加了一层 SSL 的封装。HTTP 协议原有的 GET、POST 之类的机制，基本原封不动) 打个比方：若是原来的 HTTP 是塑料水管，容易被戳破;那么现在新设计的 HTTPS 就像是在原有的塑料水管以外，再包一层金属水管。一来，原有的塑料水管照样运行;二来，用金属加固了以后，不容易被戳破。 【可扩展性】 前面说了，HTTPS 至关因而“HTTP over SSL”。若是 SSL 这个协议在“可扩展性”方面的设计足够牛逼，那么它除了能跟 HTTP 搭配，还可以跟其它的应用层协议搭配。如今看来，当初设计 SSL 的人确实比较牛。现在的 SSL/TLS 能够跟不少经常使用的应用层协议(好比：FTP、SMTP、POP、Telnet)搭配，来强化这些应用层协议的安全性。接着刚才打的比方：若是把 SSL/TLS 视做一根用来加固的金属管，它不只能够用来加固输水的管道，还能够用来加固输煤气的管道。 【保密性】 HTTPS 须要作到足够好的保密性。说到保密性，首先要可以对抗嗅探(行话叫 Sniffer)。所谓的“嗅探”，通俗而言就是监视你的网络传输流量。若是你使用明文的 HTTP 上网，那么监视者经过嗅探，就知道你在访问哪些网站的哪些页面。嗅探是最低级的攻击手法。除了嗅探，HTTPS 还须要能对抗其它一些稍微高级的攻击手法——好比“重放攻击”。【完整性】 除了“保密性”，还有一个一样重要的目标是“确保完整性”。在发明 HTTPS 以前，因为 HTTP 是明文的，不但容易被嗅探，还容易被篡改。举个例子：好比天朝的网络运营商(ISP)都比较流氓，常常有网友抱怨说访问某网站(原本是 没有广告的)，居然会跳出不少中国*信的广告。为啥会这样捏?由于你的网络流量须要通过 ISP 的线路才能到达公网。若是你使用的是明文的 HTTP，ISP 很容易就能够在你访问的页面中植入广告。因此，当初设计 HTTPS 的时候，还有一个需求是“确保 HTTP 协议的内容不被篡改”。【真实性】 在谈到 HTTPS 的需求时，“真实性”常常被忽略。其实“真实性”的重要程度不亚于前面的“保密性”和“完整性”。举个例子：你由于使用网银，须要访问该网银的 Web 站点。那么，你如何确保你访问的网站确实是你想访问的网站。有些天真的同窗会说：经过看网址里面的域名，来确保。为啥说这样的同窗是“天真的”?由于 DNS 系统自己是不可靠的(尤为是在设计 SSL 的那个*代，连 DNSSEC 都还没发明)。因为 DNS 的不可靠(存在“域名欺骗”和“域名劫持”)，你看到的网址里面的域名【未必】是真实滴!因此，HTTPS 协议必须有某种机制来确保“真实性”的需求。【性能】 引入 HTTPS 以后，【不能】致使性能变得太差。不然的话，谁还愿意用?为了确保性能，SSL 的设计者至少要*虑以下几点： 如何选择加密算法(“对称”or“非对称”)? 如何兼顾 HTTP 采用的“短链接”TCP 方式? (SSL 是在1995*以前开始设计的，那时候的 HTTP 版本仍是 1.0，默认使用的是“短链接”的 TCP 方式——默认不启用 Keep-Alive) 设计 HTTPS 协议的主要难点 设计 HTTPS 这个协议，有好几个难点。我的认为最大的难点在于“密钥交换”。在传统的密码学场景中，假如张三要跟李四创建一个加密通信的渠道，双方事先要约定好使用哪 种加密算法?同时也要约定好使用的密钥是啥?在这个场景中，加密算法的【类型】让旁人知道，没太大关系。可是密钥【千万不能】让旁人知道。一旦旁人知道了 密钥，天然就能够破解通信的密文，获得明文。当你访问某个公网的网站，你的浏览器和网站的服务器之间，若是要创建加密通信，必然要商量好 双方使用啥算法，啥密钥。——在网络通信术语中，这个过程称之为“握手/handshake”。在握手阶段，由于加密方式尚未协商好，因此握手阶段的通 讯一定是明文!既然是明文，天然有可能被第三方偷窥到。而后，还要*虑到双方之间隔着一个互联网，什么样的偷窥均可能发生。所以，在握手的过程当中，如何作 到安全地交换密钥信息，而不让周围的第三方看到。这就是设计 HTTPS 最大的难点。HTTPS和SSL支持使用X.509数字认证，若是须要的话用户能够确认发送者是谁。 https协议须要到ca申请证书，通常免费证书不多，须要交费。 http和https使用的是彻底不一样的链接方式用的端口也不同,前者是80,后者是443。HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议 要比http协议安全 1 . 信任主机的问*. 采用https 的server 必须从CA 申请一个用于证实服务器用途类型的证书.改证书只有用于对应的server 的时候,客户度才信任次主机.因此目前全部的银行系统网站,关键部分应用都是https 的.客户经过信任该证书,从而信任了该主机.其实这样作效率很低,可是银行更侧重安全. 这一点对咱们没有任何意义,咱们的server ,采用的证书无论本身issue 仍是从公众的地方issue, 客户端都是本身人,因此咱们也就确定信任该server. 1. 通常意义上的https, 就是 server 有一个证书. i. 具体讲,是客户端产生一个对称的密钥,经过server 的证书来交换密钥. 通常意义上的握手过程. ii. 加下来全部的信息往来就都是加密的. 第三方即便截获,也没有任何意义.由于他没有密钥. 固然窜改也就没有什么意义了. 2. 少量对客户端有要求的状况下,会要求客户端也必须有一个证书. a) 这里客户端证书,其实就相似表示我的信息的时候,除了用户名/密码, 还有一个CA 认证过的身份. 应为我的证书通常来讲上别人没法模拟的,全部这样可以更深的确认本身的身份. b) 目前少数我的银行的专业版是这种作法,具体证书多是拿U盘做为一个备份的载体. a) 原本简单的http协议,一个get一个response. 因为https 要还密钥和确认加密算法的须要.单握手就须要6/7 个往返. i. 任何应用中,过多的round trip 确定影响性能. i. 尽管对称加密/解密效率比较高,但是仍然要消耗过多的CPU,为此有专门的SSL 芯片. 若是CPU 信能比较低的话,确定会下降性能,从而不能serve 更多的请求.