前言

近几年，互联网发生着翻天覆地的变化，尤其是我们一直习以为常的HTTP协议，在逐渐的被HTTPS协议所取代，在浏览器、搜索引擎、CA机构、大型互联网企业的共同促进下，互联网迎来了“HTTPS加密时代”，HTTPS将在未来的几年内全面取代HTTP成为传输协议的主流。

读完本文，希望你能明白：

• HTTP通信存在什么问题

• HTTPS如何改进HTTP存在那些问题

• HTTPS工作原理是什么

想阅读更多优质文章请猛戳https://github.com/ljianshu/Blog,一年五十篇优质文章等着你！

一、什么是HTTPS

HTTPS是在HTTP上建立SSL加密层，并对传输数据进行加密，是HTTP协议的安全版。现在它被广泛用于万维网上安全敏感的通讯，例如交易支付方面。

HTTPS主要作用是：

（1）对数据进行加密，并建立一个信息安全通道，来保证传输过程中的数据安全;

（2）对网站服务器进行真实身份认证。

我们经常会在Web的登录页面和购物结算界面等使用HTTPS通信。使用HTTPS通信时，不再用 http://，而是改用 https://。另外，当浏览器访问HTTPS通信有效的Web网站时，浏览器的地址栏内会出现一个带锁的标记。对HTTPS的显示方式会因浏览器的不同而有所改变。

二、为什么需要HTTPS

在HTTP协议中有可能存在信息窃取或身份伪装等安全问题。使用HTTPS通信机制可以有效地防止这些问题，接下来，我们先来了解下 HTTP协议存在的哪些问题：

• 通信使用明文（不加密），内容可能被窃听

由于HTTP本身不具备加密的功能，所以也无法做到对通信整体（使用HTTP协议通信的请求和响应的内容）进行加密。即，HTTP报文使用明文（指未经过加密的报文）方式发送。

HTTP明文协议的缺陷是导致数据泄露、数据篡改、流量劫持、钓鱼攻击等安全问题的重要原因。HTTP协议无法加密数据，所有通信数据都在网络中明文“裸奔”。通过网络的嗅探设备及一些技术手段，就可还原HTTP报文内容。

• 无法证明报文的完整性，所以可能遭篡改

所谓完整性是指信息的准确度。若无法证明其完整性，通常也就意味着无法判断信息是否准确。由于HTTP协议无法证明通信的报文完整性，因此，在请求或响应送出之后直到对方接收之前的这段时间内，即使请求或响应的内容遭到篡改，也没有办法获悉。换句话说，没有任何办法确认，发出的请求/响应和接收到的请求/响应是前后相同的。

• 不验证通信方的身份，因此有可能遭遇伪装

HTTP协议中的请求和响应不会对通信方进行确认。在HTTP协议通信时，由于不存在确认通信方的处理步骤，任何人都可以发起请求。另外，服务器只要接收到请求，不管对方是谁都会返回一个响应（但也仅限于发送端的IP地址和端口号没有被Web服务器设定限制访问的前提下）

HTTP协议无法验证通信方身份，任何人都可以伪造虚假服务器欺骗用户，实现“钓鱼欺诈”，用户无法察觉。

反观HTTPS协议，它比HTTP协议相比多了以下优势（下文会详细介绍）:

• 数据隐私性：内容经过对称加密，每个连接生成一个唯一的加密密钥

• 数据完整性：内容传输经过完整性校验

• 身份认证：第三方无法伪造服务端（客户端）身份

三、HTTPS如何解决HTTP上述问题?

HTTPS并非是应用层的一种新协议。只是HTTP通信接口部分用SSL和TLS协议代替而已。

通常，HTTP直接和TCP通信。当使用SSL时，则演变成先和SSL通信，再由SSL和TCP通信了。简言之，所谓HTTPS，其实就是身披SSL协议这层外壳的HTTP。

在采用SSL后，HTTP就拥有了HTTPS的加密、证书和完整性保护这些功能。也就是说HTTP加上加密处理和认证以及完整性保护后即是HTTPS。

HTTPS 协议的主要功能基本都依赖于 TLS/SSL 协议，TLS/SSL 的功能实现主要依赖于三类基本算法：散列函数 、对称加密和非对称加密，其利用非对称加密实现身份认证和密钥协商，对称加密算法采用协商的密钥对数据加密，基于散列函数验证信息的完整性。

1.解决内容可能被窃听的问题——加密

方法1.对称加密

这种方式加密和解密同用一个密钥。加密和解密都会用到密钥。没有密钥就无法对密码解密，反过来说，任何人只要持有密钥就能解密了。

以对称加密方式加密时必须将密钥也发给对方。可究竟怎样才能安全地转交？在互联网上转发密钥时，如果通信被监听那么密钥就可会落人攻击者之手，同时也就失去了加密的意义。另外还得设法安全地保管接收到的密钥。

方法2.非对称加密

公开密钥加密使用一对非对称的密钥。一把叫做私有密钥，另一把叫做公开密钥。顾名思义，私有密钥不能让其他任何人知道，而公开密钥则可以随意发布，任何人都可以获得。

使用公开密钥加密方式，发送密文的一方使用对方的公开密钥进行加密处理，对方收到被加密的信息后，再使用自己的私有密钥进行解密。利用这种方式，不需要发送用来解密的私有密钥，也不必担心密钥被攻击者窃听而盗走。

非对称加密的特点是信息传输一对多，服务器只需要维持一个私钥就能够和多个客户端进行加密通信。

这种方式有以下缺点：

• 公钥是公开的，所以针对私钥加密的信息，黑客截获后可以使用公钥进行解密，获取其中的内容；

• 公钥并不包含服务器的信息，使用非对称加密算法无法确保服务器身份的合法性，存在中间人攻击的风险，服务器发送给客户端的公钥可能在传送过程中被中间人截获并篡改；

• 使用非对称加密在数据加密解密过程需要消耗一定时间，降低了数据传输效率；

方法3.对称加密+非对称加密(HTTPS采用这种方式)

使用对称密钥的好处是解密的效率比较快，使用非对称密钥的好处是可以使得传输的内容不能被破解，因为就算你拦截到了数据，但是没有对应的私钥，也是不能破解内容的。就比如说你抢到了一个保险柜，但是没有保险柜的钥匙也不能打开保险柜。那我们就将对称加密与非对称加密结合起来,充分利用两者各自的优势，在交换密钥环节使用非对称加密方式，之后的建立通信交换报文阶段则使用对称加密方式。

具体做法是：发送密文的一方使用对方的公钥进行加密处理“对称的密钥”，然后对方用自己的私钥解密拿到“对称的密钥”，这样可以确保交换的密钥是安全的前提下，使用对称加密方式进行通信。所以，HTTPS采用对称加密和非对称加密两者并用的混合加密机制。

2.解决报文可能遭篡改问题——数字签名

网络传输过程中需要经过很多中间节点，虽然数据无法被解密，但可能被篡改，那如何校验数据的完整性呢？----校验数字签名。

数字签名有两种功效：

• 能确定消息确实是由发送方签名并发出来的，因为别人假冒不了发送方的签名。

• 数字签名能确定消息的完整性,证明数据是否未被篡改过。

数字签名如何生成:

将一段文本先用Hash函数生成消息摘要，然后用发送者的私钥加密生成数字签名，与原文文一起传送给接收者。接下来就是接收者校验数字签名的流程了。

校验数字签名流程：

接收者只有用发送者的公钥才能解密被加密的摘要信息，然后用HASH函数对收到的原文产生一个摘要信息，与上一步得到的摘要信息对比。如果相同，则说明收到的信息是完整的，在传输过程中没有被修改，否则说明信息被修改过，因此数字签名能够验证信息的完整性。

假设消息传递在Kobe，James两人之间发生。James将消息连同数字签名一起发送给Kobe，Kobe接收到消息后，通过校验数字签名，就可以验证接收到的消息就是James发送的。当然，这个过程的前提是Kobe知道James的公钥。问题的关键的是，和消息本身一样，公钥不能在不安全的网络中直接发送给Kobe,或者说拿到的公钥如何证明是James的。

此时就需要引入了证书颁发机构（Certificate Authority，简称CA），CA数量并不多，Kobe客户端内置了所有受信任CA的证书。CA对James的公钥（和其他信息）数字签名后生成证书。

3.解决通信方身份可能被伪装的问题——数字证书

数字证书认证机构处于客户端与服务器双方都可信赖的第三方机构的立场上。

我们来介绍一下数字证书认证机构的业务流程：

• 服务器的运营人员向第三方机构CA提交公钥、组织信息、个人信息(域名)等信息并申请认证;

• CA通过线上、线下等多种手段验证申请者提供信息的真实性，如组织是否存在、企业是否合法，是否拥有域名的所有权等;

• 如信息审核通过，CA会向申请者签发认证文件-证书。证书包含以下信息：申请者公钥、申请者的组织信息和个人信息、签发机构 CA的信息、有效时间、证书序列号等信息的明文，同时包含一个签名。其中签名的产生算法：首先，使用散列函数计算公开的明文信息的信息摘要，然后，采用 CA的私钥对信息摘要进行加密，密文即签名;

• 客户端 Client 向服务器 Server 发出请求时，Server 返回证书文件;

• 客户端 Client 读取证书中的相关的明文信息，采用相同的散列函数计算得到信息摘要，然后，利用对应 CA的公钥解密签名数据，对比证书的信息摘要，如果一致，则可以确认证书的合法性，即服务器的公开密钥是值得信赖的。

• 客户端还会验证证书相关的域名信息、有效时间等信息; 客户端会内置信任CA的证书信息(包含公钥)，如果CA不被信任，则找不到对应 CA的证书，证书也会被判定非法。

四、 HTTPS工作流程

1.Client发起一个HTTPS（比如 https://juejin.im/user）的请求，根据RFC2818的规定，Client知道需要连接Server的443（默认）端口。

2.Server把事先配置好的公钥证书（public key certificate）返回给客户端。

3.Client验证公钥证书：比如是否在有效期内，证书的用途是不是匹配Client请求的站点，是不是在CRL吊销列表里面，它的上一级证书是否有效，这是一个递归的过程，直到验证到根证书（操作系统内置的Root证书或者Client内置的Root证书）。如果验证通过则继续，不通过则显示警告信息。

4.Client使用伪随机数生成器生成加密所使用的对称密钥，然后用证书的公钥加密这个对称密钥，发给Server。

5.Server使用自己的私钥（private key）解密这个消息，得到对称密钥。至此，Client和Server双方都持有了相同的对称密钥。

6.Server使用对称密钥加密“明文内容A”，发送给Client。

7.Client使用对称密钥解密响应的密文，得到“明文内容A”。

8.Client再次发起HTTPS的请求，使用对称密钥加密请求的“明文内容B”，然后Server使用对称密钥解密密文，得到“明文内容B”。

五、HTTP 与 HTTPS 的区别

• HTTP 是明文传输协议，HTTPS 协议是由 SSL+HTTP 协议构建的可进行加密传输、身份认证的网络协议，比 HTTP 协议安全。

关于安全性，用最简单的比喻形容两者的关系就是卡车运货，HTTP下的运货车是敞篷的，货物都是暴露的。而https则是封闭集装箱车，安全性自然提升不少。

• HTTPS比HTTP更加安全，对搜索引擎更友好，利于SEO,谷歌、百度优先索引HTTPS网页;

• HTTPS需要用到SSL证书，而HTTP不用;

• HTTPS标准端口443，HTTP标准端口80;

• HTTPS基于传输层，HTTP基于应用层;

• HTTPS在浏览器显示绿色安全锁，HTTP没有显示;

六、为何不所有的网站都使用HTTPS

既然HTTPS那么安全可靠，那为何不所有的Web网站都使用HTTPS？

首先，很多人还是会觉得HTTPS实施有门槛，这个门槛在于需要权威CA颁发的SSL证书。从证书的选择、购买到部署，传统的模式下都会比较耗时耗力。

其次，HTTPS普遍认为性能消耗要大于HTTP，因为与纯文本通信相比，加密通信会消耗更多的CPU及内存资源。如果每次通信都加密，会消耗相当多的资源，平摊到一台计算机上时，能够处理的请求数量必定也会随之减少。但事实并非如此，用户可以通过性能优化、把证书部署在SLB或CDN，来解决此问题。举个实际的例子，“双十一”期间，全站HTTPS的淘宝、天猫依然保证了网站和移动端的访问、浏览、交易等操作的顺畅、平滑。通过测试发现，经过优化后的许多页面性能与HTTP持平甚至还有小幅提升，因此HTTPS经过优化之后其实并不慢。

除此之外，想要节约购买证书的开销也是原因之一。要进行HTTPS通信，证书是必不可少的。而使用的证书必须向认证机构（CA）购买。

最后是安全意识。相比国内，国外互联网行业的安全意识和技术应用相对成熟，HTTPS部署趋势是由社会、企业、政府共同去推动的。

欢迎关注公众号：前端工匠，你的成长我们一起见证！

参考文章与书籍

• 图解HTTP

• 珠峰架构课(推荐)

• 数字签名是什么？(推荐)

• HTTPS工作原理

• HTTPS 原理详解

• 详解HTTPS是如何确保安全性的？

• [信息安全] 3.HTTPS工作流程

• 为什么HTTPS比HTTP更安全

一、前言：

先来观察这两张图，第一张访问域名http://www.12306.cn，谷歌浏览器提示不安全链接，第二张是https://kyfw.12306.cn/otn/regist/init，浏览器显示安全，为什么会这样子呢？2017年1月发布的Chrome 56浏览器开始把收集密码或信用卡数据的HTTP页面标记为“不安全”，若用户使用2017年10月推出的Chrome 62，带有输入数据的HTTP页面和所有以无痕模式浏览的HTTP页面都会被标记为“不安全”，此外，苹果公司强制所有iOS App在2017年1月1日前使用HTTPS加密。

二、HTTP和HTTPS发展历史

什么是HTTP?

超文本传输协议，是一个基于请求与响应，无状态的，应用层的协议，常基于TCP/IP协议传输数据，互联网上应用最为广泛的一种网络协议,所有的WWW文件都必须遵守这个标准。设计HTTP的初衷是为了提供一种发布和接收HTML页面的方法。

发展历史：

这个Akamai公司建立的一个官方的演示，使用HTTP/1.1和HTTP/2同时请求379张图片，观察请求的时间，明显看出HTTP/2性能占优势。

多路复用：通过单一的HTTP/2连接请求发起多重的请求-响应消息，多个请求stream共享一个TCP连接，实现多留并行而不是依赖建立多个TCP连接。

HTTP报文格式

什么是HTTPS？

《图解HTTP》这本书中曾提过HTTPS是身披SSL外壳的HTTP。HTTPS是一种通过计算机网络进行安全通信的传输协议，经由HTTP进行通信，利用SSL/TLS建立全信道，加密数据包。HTTPS使用的主要目的是提供对网站服务器的身份认证，同时保护交换数据的隐私与完整性。

PS:TLS是传输层加密协议，前身是SSL协议，由网景公司1995年发布，有时候两者不区分。

参考连接：

1.https://kamranahmed.info/blog/2016/08/13/http-in-depth/

2.https://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol

3.https://tools.ietf.org/html/rfc1945

4.https://http2.github.io/http2-spec/

5.https://www.zhihu.com/question/34074946

三、HTTP VS HTTPS

HTTP特点：

1. 无状态：协议对客户端没有状态存储，对事物处理没有“记忆”能力，比如访问一个网站需要反复进行登录操作
2. 无连接：HTTP/1.1之前，由于无状态特点，每次请求需要通过TCP三次握手四次挥手，和服务器重新建立连接。比如某个客户机在短时间多次请求同一个资源，服务器并不能区别是否已经响应过用户的请求，所以每次需要重新响应请求，需要耗费不必要的时间和流量。
3. 基于请求和响应：基本的特性，由客户端发起请求，服务端响应
4. 简单快速、灵活
5. 通信使用明文、请求和响应不会对通信方进行确认、无法保护数据的完整性

下面通过一个简单的抓包实验观察使用HTTP请求传输的数据：

结果分析：HTTP协议传输数据以明文形式显示

针对无状态的一些解决策略：

场景：逛电商商场用户需要使用的时间比较长，需要对用户一段时间的HTTP通信状态进行保存，比如执行一次登陆操作，在30分钟内所有的请求都不需要再次登陆。

1. 通过Cookie/Session技术
2. HTTP/1.1持久连接（HTTP keep-alive）方法，只要任意一端没有明确提出断开连接，则保持TCP连接状态，在请求首部字段中的Connection: keep-alive即为表明使用了持久连接

HTTPS特点：

基于HTTP协议，通过SSL或TLS提供加密处理数据、验证对方身份以及数据完整性保护

通过抓包可以看到数据不是明文传输，而且HTTPS有如下特点：

1. 内容加密：采用混合加密技术，中间者无法直接查看明文内容
2. 验证身份：通过证书认证客户端访问的是自己的服务器
3. 保护数据完整性：防止传输的内容被中间人冒充或者篡改

**混合加密：**结合非对称加密和对称加密技术。客户端使用对称加密生成密钥对传输数据进行加密，然后使用非对称加密的公钥再对秘钥进行加密，所以网络上传输的数据是被秘钥加密的密文和用公钥加密后的秘密秘钥，因此即使被黑客截取，由于没有私钥，无法获取到加密明文的秘钥，便无法获取到明文数据。


**数字摘要：**通过单向hash函数对原文进行哈希，将需加密的明文“摘要”成一串固定长度(如128bit)的密文，不同的明文摘要成的密文其结果总是不相同，同样的明文其摘要必定一致，并且即使知道了摘要也不能反推出明文。


**数字签名技术：**数字签名建立在公钥加密体制基础上，是公钥加密技术的另一类应用。它把公钥加密技术和数字摘要结合起来，形成了实用的数字签名技术。

• 收方能够证实发送方的真实身份；
• 发送方事后不能否认所发送过的报文；
• 收方或非法者不能伪造、篡改报文。

非对称加密过程需要用到公钥进行加密，那么公钥从何而来？其实公钥就被包含在数字证书中，数字证书通常来说是由受信任的数字证书颁发机构CA，在验证服务器身份后颁发，证书中包含了一个密钥对（公钥和私钥）和所有者识别信息。数字证书被放到服务端，具有服务器身份验证和数据传输加密功能。

四、HTTP通信传输

客户端输入URL回车，DNS解析域名得到服务器的IP地址，服务器在80端口监听客户端请求，端口通过TCP/IP协议（可以通过Socket实现）建立连接。HTTP属于TCP/IP模型中的运用层协议，所以通信的过程其实是对应数据的入栈和出栈。

报文从运用层传送到运输层，运输层通过TCP三次握手和服务器建立连接，四次挥手释放连接。

为什么需要三次握手呢？为了防止已失效的连接请求报文段突然又传送到了服务端，因而产生错误。

比如：client发出的第一个连接请求报文段并没有丢失，而是在某个网络结点长时间的滞留了，以致延误到连接释放以后的某个时间才到达server。本来这是一个早已失效的报文段，但是server收到此失效的连接请求报文段后，就误认为是client再次发出的一个新的连接请求，于是就向client发出确认报文段，同意建立连接。假设不采用“三次握手”，那么只要server发出确认，新的连接就建立了，由于client并没有发出建立连接的请求，因此不会理睬server的确认，也不会向server发送数据，但server却以为新的运输连接已经建立，并一直等待client发来数据。所以没有采用“三次握手”，这种情况下server的很多资源就白白浪费掉了。

为什么需要四次挥手呢？TCP是全双工模式，当client发出FIN报文段时，只是表示client已经没有数据要发送了，client告诉server，它的数据已经全部发送完毕了；但是，这个时候client还是可以接受来server的数据；当server返回ACK报文段时，表示它已经知道client没有数据发送了，但是server还是可以发送数据到client的；当server也发送了FIN报文段时，这个时候就表示server也没有数据要发送了，就会告诉client，我也没有数据要发送了，如果收到client确认报文段，之后彼此就会愉快的中断这次TCP连接。

五、HTTPS实现原理

SSL建立连接过程

1. client向server发送请求https://baidu.com，然后连接到server的443端口，发送的信息主要是随机值1和客户端支持的加密算法。
2. server接收到信息之后给予client响应握手信息，包括随机值2和匹配好的协商加密算法，这个加密算法一定是client发送给server加密算法的子集。
3. 随即server给client发送第二个响应报文是数字证书。服务端必须要有一套数字证书，可以自己制作，也可以向组织申请。区别就是自己颁发的证书需要客户端验证通过，才可以继续访问，而使用受信任的公司申请的证书则不会弹出提示页面，这套证书其实就是一对公钥和私钥。传送证书，这个证书其实就是公钥，只是包含了很多信息，如证书的颁发机构，过期时间、服务端的公钥，第三方证书认证机构(CA)的签名，服务端的域名信息等内容。
4. 客户端解析证书，这部分工作是由客户端的TLS来完成的，首先会验证公钥是否有效，比如颁发机构，过期时间等等，如果发现异常，则会弹出一个警告框，提示证书存在问题。如果证书没有问题，那么就生成一个随即值（预主秘钥）。
5. 客户端认证证书通过之后，接下来是通过随机值1、随机值2和预主秘钥组装会话秘钥。然后通过证书的公钥加密会话秘钥。
6. 传送加密信息，这部分传送的是用证书加密后的会话秘钥，目的就是让服务端使用秘钥解密得到随机值1、随机值2和预主秘钥。
7. 服务端解密得到随机值1、随机值2和预主秘钥，然后组装会话秘钥，跟客户端会话秘钥相同。
8. 客户端通过会话秘钥加密一条消息发送给服务端，主要验证服务端是否正常接受客户端加密的消息。
9. 同样服务端也会通过会话秘钥加密一条消息回传给客户端，如果客户端能够正常接受的话表明SSL层连接建立完成了。

问题：
1.怎么保证保证服务器给客户端下发的公钥是真正的公钥，而不是中间人伪造的公钥呢？

2.证书如何安全传输，被掉包了怎么办？

数字证书内容
包括了加密后服务器的公钥、权威机构的信息、服务器域名，还有经过CA私钥签名之后的证书内容（经过先通过Hash函数计算得到证书数字摘要，然后用权威机构私钥加密数字摘要得到数字签名)，签名计算方法以及证书对应的域名。

验证证书安全性过程

1. 当客户端收到这个证书之后，使用本地配置的权威机构的公钥对证书进行解密得到服务端的公钥和证书的数字签名，数字签名经过CA公钥解密得到证书信息摘要。
2. 然后证书签名的方法计算一下当前证书的信息摘要，与收到的信息摘要作对比，如果一样，表示证书一定是服务器下发的，没有被中间人篡改过。因为中间人虽然有权威机构的公钥，能够解析证书内容并篡改，但是篡改完成之后中间人需要将证书重新加密，但是中间人没有权威机构的私钥，无法加密，强行加密只会导致客户端无法解密，如果中间人强行乱修改证书，就会导致证书内容和证书签名不匹配。

那第三方攻击者能否让自己的证书显示出来的信息也是服务端呢？（伪装服务端一样的配置）显然这个是不行的，因为当第三方攻击者去CA那边寻求认证的时候CA会要求其提供例如域名的whois信息、域名管理邮箱等证明你是服务端域名的拥有者，而第三方攻击者是无法提供这些信息所以他就是无法骗CA他拥有属于服务端的域名。

六、运用与总结

安全性考虑：

1. HTTPS协议的加密范围也比较有限，在黑客攻击、拒绝服务攻击、服务器劫持等方面几乎起不到什么作用
2. SSL证书的信用链体系并不安全，特别是在某些国家可以控制CA根证书的情况下，中间人攻击一样可行

中间人攻击（MITM攻击）是指，黑客拦截并篡改网络中的通信数据。又分为被动MITM和主动MITM，被动MITM只窃取通信数据而不修改，而主动MITM不但能窃取数据，还会篡改通信数据。最常见的中间人攻击常常发生在公共wifi或者公共路由上。

成本考虑：

1. SSL证书需要购买申请，功能越强大的证书费用越高
2. SSL证书通常需要绑定IP，不能在同一IP上绑定多个域名，IPv4资源不可能支撑这个消耗（SSL有扩展可以部分解决这个问题，但是比较麻烦，而且要求浏览器、操作系统支持，Windows XP就不支持这个扩展，考虑到XP的装机量，这个特性几乎没用）。
3. 根据ACM CoNEXT数据显示，使用HTTPS协议会使页面的加载时间延长近50%，增加10%到20%的耗电。
4. HTTPS连接缓存不如HTTP高效，流量成本高。
5. HTTPS连接服务器端资源占用高很多，支持访客多的网站需要投入更大的成本。
6. HTTPS协议握手阶段比较费时，对网站的响应速度有影响，影响用户体验。比较好的方式是采用分而治之，类似12306网站的主页使用HTTP协议，有关于用户信息等方面使用HTTPS。

最后插播下广告，对IOS感兴趣的或者校招同学可以看这两篇文章-：
看一篇就够入门Objective-C
手把手教学IOS自定义cell-仿微信消息列表
面试必备操作系统

https协议 的工作过程

前面是对http协议的补充，后面的https工作流程才是这篇帖子的重点！

一、用代码构造http请求

1、通过HTML中的form标签，构造出GET/POST请求

​ > 通过input标签搭配form来使用，实现给服务器提交数据这样的功能。

<form action="https://www.baidu.com" method="GET">
        <input type="text" name="username">
        <input type="text" name="password">
        <input type="submit" value="提交">
</form>

action: 请求提交给谁

method：请求的方法是啥（GET/POST)

2、ajax方法

ajax（Asynchronous Javascript And XML)，这个是当前进行前后端交互的一个主要方式。

Asynchronous：异步，相当于多件事情不是同时进行，是一件处理完后再处理下一件的事情。

XML：是以一种文件组织的方式，这个方式类似于HTML，也是使用标签化的组织方式，但是随着时代的发展使用XML的组织格式化的数据很少了，现在都在使用JSON，YML更新更好用的组织数据的格式。

用原生的ajax方式来请求服务器这种写法相当繁琐，所以就用简单的方式使用JavaScript中的第三方库了进行操作，jQuery里面就对ajax提供了一个更简便的封装版本。

jQuery的安装，只需要使用script标签，把jQuery的 cdn 地址写进去就行了；（百度搜索 jQuery cdn）

关于 cdn：

cdn是互联网中的一种设施，这是一组服务器，服务器是运营商提供，存在的目的就是加快用户的访问速度；运营商在全国各地都有cdn服务器，各种互联网产品都可以付费使用运营商cdn的服务器，来存放各自的一些静态资源，用户访问的时候，就会自动的就近访问。

参数：data，表示响应的body，status表示响应的具体状态，请求成功响应回来了就会浏览器自动调用这个函数。

$：是一个变量名，是jQuery中定义好的一个对象，jQuery里面的各种方法，都是这个对象的成员。

注意：

ajax有个重要的限制，默认情况下，不能跨域！！ajax是通过js代码触发的，是在一个html里面，访问html就有一个域名1，ajax构造一个请求的时候也有一个域名2，ajax默认情况下要求域名1和域名2是必须一样的，如果不一样就会出现访问错误；但有的时候域名1和域名2是可以访问的，原因是服务器端开放了跨域。

二、https ☆（这篇帖子的重点）

https是http的同胞兄弟，https也是基于http的基础上，引入了一个加密层，SSL/TLS。

http不安全的根源在于是“明文传输”，而我们的https中都是加密的。

加密相关的术语：

1、明文，要传输的原始消息；

2、密文，经过一定的变换规则之后的内容；

3、明文 -> 密文 称之为加密；

4、密文 -> 明文 称之为解密；

5、在加密和解密的过程中，经过需要用到一个特殊的数据，叫做密钥（yue）

2.1 加密的概念

加密，众所周知，就是把明文经过一系列的计算转换生成密文，解密就是把密文在经过一系列的转换，还原成明文。

1、对称加密；

​ > 加密使用的密钥，和解密使用的密钥是同一个；

可以看做key是一个密钥，a^{key=b,a是明文的话，b就是密文，解密：b}key=a;

2、非对称加密；

​ > 分成两个密钥，一个公钥一个私钥；

​ > 使用公钥来加密，私钥来解密；

​ > 也可以私钥加密，公钥解密；

2.2 加密的工作流程

加密的流程分为两大类，对称加密，非对称加密

2.2.1 对称加密 ☆

• 因为上诉对称加密黑客会劫持里面的信息同时会获得密钥，不安全，所以就引出了非对称密钥

2.2.2 非对称加密 ☆

为了使黑客拿不到密钥，就用公钥对密钥进行加密，最后只能拿到私钥才能解密拿到密钥。

公钥：使用公钥加密；

私钥：使用秘钥解密；

步骤：
1、首先服务器自己生成公钥私钥对；
   >  公钥公布出去，私钥自己保留；
2、客服端拿到公钥后，使用公钥，对 对称密钥 进行加密；
   >  对这个加密后的 密钥密文 通过网络传输给服务器；
   >  这样黑客只能拿到公钥，但是黑客没有私钥，所以就不能对密钥密文进行解密；
3、后续客户端和服务器之间就可以使用对称密钥进行加密解密了；

注意：

非对称加密更安全，为啥不全用非对称加密，还是会用对称加密尼？

对称加密的成本要低，对机器的消耗也要低，实际上客户端给服务器传输的数据量是很大的，如果都用非对称加密那么整体的传输效率就很很慢，最后只是用非对称加密的方式对密钥进行加密和解密，其他时候都用对称加密这样才能使安全性和效率达到一个平衡。

• 这个方法看似很完美，但是黑客有想到了，新办法来破解这个非对称加密的局，叫做**“中间人夹击”**。

出现中间人攻击的漏洞就在于非对称加密中客户端是无法辨别服务器传过来的公钥是否是伪造的！！！！

有图可知，黑客可以拿自己手中的公钥给客服端，客服端就会用黑客的公钥对密钥进行加密，然后传给服务器，中途黑客就可以用自己的私钥进行解密，从而拿到密钥，黑客拿到了密钥，那么后续的数据传输的内容黑客也是可以拿到的！！！

• 为了解决黑客的偷梁换柱，我们这边也采取了响应的措施来应对。

出现中间人攻击的漏洞就在于非对称加密中客户端是无法辨别服务器传过来的公钥是否是伪造的！！！！

关键的点就是，无法确认公钥是否是服务器公布的正版公钥，因此就引入了第三方公正机构.

步骤：
1、服务器开服，同时生成自己的公钥和私钥
2、去公正机构申请一个证书；（公正机构不是人人可申请，需要提供各种资质，审核通过才能颁发证书，证书里面就要公钥）
3、把证书给客服端看；
4、客服端再拿去第三方机构去确认合不合法，合法，证书和证书里面的公钥就可以信任。

那么又有问题了，黑客可否在服务器和公正机构之间，还有在客服端和公正机构之间做手脚尼？？

从理论是哪个来讲是可以这么做，也确实这么做了过后可以拿到密钥；

但是从实际出发，成本花销特别大，而且还是双倍，一般的黑客是做不到的，再说破解个密钥证书可能也会耗费好几年的时间，时间成本都大，所以从实际上来讲黑客不会这么做。

（网络这个东西没有绝对安全）

总结：

1、对称加密：用于传输数据进行加密（请求，响应），需要一个密钥，客服端生成需要告诉给服务器；

2、非对称加密：服务器自己生成公钥和私钥，私钥自己留着，客服端利用公钥对密钥进行加密，传输给服务器；

3、中间人攻击，黑客利用自己生成的公钥和私钥，把公钥给客服端，从客服端生成的密文解密出密钥

4、引入证书机制，为了防止中间人攻击，服务器需要在公正机构里面申请一个证书，客服端拿着这个证书去公正机构验证是否合法，合法说明这个证书和证书里面的公钥是可以信任的。

https协议的整个加密过程就在这篇帖子中体现出来了，大家认真看，并且掌握这个加密的过程❤🧡💛💚💙💜🤎🖤🤍💟，收藏关注呗，你们支持就是我写博客最大的动力！！！！