http、https加密过程

http:
超文本传输协议，是一个基于请求与响应，无状态无连接的，应用层的协议，常基于TCP/IP协议传输数据
<协议>://<域名>:<端口>/<路径>

HTTP通常跑在TCP/IP协议栈之上，依靠IP协议实现寻址和路由、TCP协议实现可靠数据传输、DNS协议实现域名查找、SSL/TLS协议实现安全通信

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

HOST域:随着虚拟主机技术的发展，在一台物理服务器上可以存在多个虚拟主机（Multi-homed Web Servers），并且它们共享一个IP地址
多路复用: HTTP2.0使用了多路复用的技术，做到同一个连接并发处理多个请求，而且并发请求的数量比HTTP1.1大了好几个数量级
头部压缩:状态行和头部却没有经过任何压缩，直接以纯文本传输。随着Web功能越来越复杂，每个页面产生的请求数也越来越多，导致消耗在头部的流量越来越多，尤其是每次都要传输UserAgent、Cookie这类不会频繁变动的内容，完全是一种浪费。HTTP2.0使用HPACK算法对header的数据进行压缩
服务器推送:服务端推送能把客户端所需要的资源伴随着index.html一起发送到客户端，省去了客户端重复请求的步骤。正因为没有发起请求，建立连接等操作，所以静态资源通过服务端推送的方式可以极大地提升速度。具体如下：
长连接：就是多个 http 请求共用一个 tcp 连接; 这样可以减少多次临近 http 请求导致 tcp建立关闭所产生的时间消耗.其中Keep-Alive:timeout=30,max=5, timeout 是两次 http 请求保持的时间(s), ,max 是这个 tcp 连接最多为几个 http请求重用
- keep-alive 还有一个有效期，有效期结束后服务端会发侦查帧探查 TCP 是否有效，HTTP 的 keep-alive 是为了让 TCP 活久一点，而 TCP 本身也有一个 keepalive（注意没有横杠哦）机制。这是 TCP 的一种检测连接状况的保活机制，keepalive 是 TCP 保活定时器：TCP 建立后，如果闲置没用，服务器不可能白等下去，闲置一段时间[可设置]后，服务器就会尝试向客户端发送侦测包，来判断 TCP 连接状况，如果没有收到对方的回答（ACK包），就会过一会[可设置]再侦测一次，如果多次[可设置]都没回答，就会丢弃这个 TCP 连接

http建立连接过程

先通过域名系统（Domain Name System，DNS）查询将域名转换为 IP 地址。即将 test.com 转换为 221.239.100.30 这一过程。
通过三次握手建立 TCP 连接。
发起 HTTP 请求。
目标服务器接收到 HTTP 请求并处理。
目标服务器往浏览器发回 HTTP 响应。
浏览器解析并渲染页面。

https:
经由HTTP进行通信，利用SSL/TLS建立全信道，加密数据包。HTTPS使用的主要目的是提供对网站服务器的身份认证，同时保护交换数据的隐私与完整性。关于TLS就是SSL的升级版本。

SSL 安全套接层(Secure Sockets Layer)
TSL 传输层安全(Transport Layer Security)

HTTPS 连接建立过程和 HTTP 差不多，区别在于 HTTP（默认端口 80）请求只要在 TCP 连接建立后就可以发起，而 HTTPS（默认端口 443）在 TCP 连接建立后，还需要经历 SSL 协议握手，成功后才能发起请求。
HTTPS 在HTTP和TCP之间建立了一个安全层，当HTTP和TCP通信时并不是像以前那样直接通信，经过了一个中间层进行加密，将加密后的数据包传给TCP, 相应的，TCP必须将数据包解密，才能传给上面的HTTP。

对称加密

如果信息在传输过程中被劫持，传输的内容就完全暴露了，他还可以篡改传输的信息且不被双方察觉，这就是中间人攻击。所以我们才需要对信息进行加密。最直接的加密方式就是对称加密

指加密解密用的都是相同的密钥。

就是加密和解密使用同一个密钥。如AES、DES。加解密过程：

浏览器给服务器并发送一个随机数client-random和加密套件(一个支持的加密方法列表)
服务器生成给浏览器返回另一个随机数server-random和加密套件
两边分别返回确认消息。然后两者用加密方法将两个随机数混合生成密钥，这就是通信双上加解密的密钥

问题是client-random和server-random都是明文的，那过程中就很可能被窃取，中间人还是能解密拿到数据

并不安全，只要拿到密钥任何人都能解密

如果通信双方都各自持有同一个密钥，且没有别人知道，这两方的通信安全当然是可以被保证的（除非密钥被破解）。

试想一下，如果浏览器内部就预存了网站A的密钥，且可以确保除了浏览器和网站A，不会有任何外人知道该密钥，那理论上用对称加密是可以的，这样浏览器只要预存好世界上所有HTTPS网站的密钥就行啦！这么做显然不现实。

怎么办？所以我们就需要神奇的非对称加密

非对称加密
为什么会出现非对称加密，就是因为对称加密的算法是可以被攻破的，(最坏的情况下穷举攻击能攻破的
非对称加密分为两个密钥：公钥和私钥。公钥是谁都能有，用于对信息加密，只有私钥才能解密。

有两把密钥，通常一把叫做公钥、一把叫做私钥，用公钥加密的内容必须用私钥才能解开，同样，私钥加密的内容只有公钥能解开。

浏览器给服务器发送加密套件
服务器选好支持的加密方法和公钥(明文) 传给浏览器
两边分别返回确认消息。然后浏览器用公钥对数据进行加密，这个密钥只能用私钥解密

通俗版:

服务器先把公钥直接明文传输给浏览器，之后浏览器向服务器传数据前都先用这个公钥加密好再传，这条数据的安全似乎可以保障了！因为只有服务器有相应的私钥能解开这条数据。
然而由服务器到浏览器的这条路怎么保障安全？如果服务器用它的的私钥加密数据传给浏览器，那么浏览器用公钥可以解密它，而这个公钥是一开始通过明文传输给浏览器的，这个公钥被谁劫持到的话，他也能用该公钥解密服务器传来的信息了。如果使用公钥加密，但浏览器方没有私钥是无法解密的

使用公钥反推出私钥是非常困难，但不是做不到，随着计算机运算能力提高，非对称密钥至少要2048位才能保证安全性，这就导致加解密速度慢，效率太低

无法保证服务器发送给浏览器的数据安全。因为浏览器可以用公钥来加密，而浏览器就只能用私钥加密，公钥是明文传输的，中间人可以获取到，这样服务器端的数据安全就得不到保证了(疑惑。。。)

浏览器和服务器都使用非对称加密
浏览器和服务器都各自有一对公钥和私钥

某网站拥有用于非对称加密的公钥A、私钥A’；浏览器拥有用于非对称加密的公钥B、私钥B’。
浏览器像网站服务器请求，服务器把公钥A明文给传输浏览器。
浏览器把公钥B明文传输给服务器
之后浏览器向服务器传输的所有东西都用公钥A加密，服务器收到后用私钥A’解密。由于只有服务器拥有这个私钥A’可以解密，所以能保证这条数据的安全。
服务器向浏览器传输的所有东西都用公钥B加密，浏览器收到后用私钥B’解密。同上也可以保证这条数据的安全

HTTPS的加密却没使用这种方案，为什么？最主要的原因是非对称加密算法非常耗时，特别是加密解密一些较大数据的时候有些力不从心，而对称加密快很多

混合加密(非对称加密+对称加密)
TLS实际用的是两种算法的混合加密。通过非对称加密算法交换对称加密算法的密钥，交换完成后，再使用对称加密进行加解密传输数据。这样就保证了会话的机密性。过程如下

浏览器给服务器发送一个随机数client-random、对称和非对称加密套件
服务器把另一个随机数server-random、加密套件、公钥传给浏览器
浏览器又生成另一个随机数pre-random，并用公钥对 pre-random 加密后传给服务器
服务器再用私钥解密，得到pre-random，并返回确认消息
这样浏览器和服务器都有三个随机数了，然后各自将三个随机数用加密方法混合生成最终的对称密钥

然后开始数据加密传输
这样即便被截持，中间人没有私钥就拿不到pre-random，就无法生成最终密钥

通俗版:

某网站拥有用于非对称加密的公钥A、私钥A’。
浏览器像网站服务器发送请求，服务器把公钥A明文给传输浏览器。
浏览器随机生成一个用于对称加密的密钥X，用公钥A加密后传给服务器。
服务器拿到后用私钥A’解密得到密钥X。
这样双方就都拥有密钥X了，且别人无法知道它。之后双方所有数据都用密钥X加密解密。
HTTPS基本就是采用了这种方案

中间人攻击
中间人的确无法得到浏览器生成的密钥B，这个密钥本身被公钥A加密了，只有服务器才有私钥A’解开拿到它呀！然而中间人却完全不需要拿到密钥A’就能干坏事了

某网站拥有用于非对称加密的公钥A、私钥A’。
浏览器向网站服务器请求，服务器把公钥A明文给传输浏览器。
中间人劫持到公钥A，保存下来，把数据包中的公钥A替换成自己伪造的公钥B（它当然也拥有公钥B对应的私钥B’）。
- 黑客如果采用 DNS 劫持，将目标地址替换成黑客服务器的地址
浏览器随机生成一个用于对称加密的密钥X，用公钥B（浏览器不知道公钥被替换了）加密后传给服务器。
中间人劫持后用私钥B’解密得到密钥X，再用公钥A加密后传给服务器。
服务器拿到后用私钥A’解密得到密钥X。

这样在双方都不会发现异常的情况下，中间人得到了密钥X。根本原因是浏览器无法确认自己收到的公钥是不是网站自己的。
那么下一步就是解决下面这个问题：

数字证书
网站在使用HTTPS前，需要向“CA机构”申请颁发一份数字证书，数字证书里有证书持有者、证书持有者的公钥等信息，服务器把证书传输给浏览器，浏览器从证书里取公钥就行了，证书就如身份证一样，可以证明“该公钥对应该网站”。

如何放防止数字证书被篡改?我们把证书内容生成一份“签名”，比对证书内容和签名是否一致就能察觉是否被篡改。这种技术就叫数字签名

那么如何申请数字证书呢？

首先，服务器准备一套公钥和私钥，私钥留着自己用
服务器将公钥和站点等信息提交给CA认证，这个是要钱的
CA验证服务器提供的信息
审核通过后签发认证的数字证书，包含了公钥、CA信息、有效时间、证书序列等这些都是明文的，还有一个CA生成的签名

CA的签名过程（数字签名）

CA也有一套公钥和私钥
CA使用摘要算法计算服务器提交的明文信息并得出信息摘要
然后CA再用它的私钥和特定的算法对信息摘要加密，生成签名
把签名、服务器公钥等信息打包放入数字证书，并返回给服务器
服务器配置好证书，以后浏览器连接服务器，都先把证书发给客户端验证

摘要算法：主要用于保证信息的完整性。常见的MD5算法、散列函数、hash函数都属于这类算法，其特点就是单向性、无法反推原文
图中左侧是数字签名的制作过程，右侧是验证过程
数字签名的制作过程：

CA拥有非对称加密的私钥和公钥。
CA对证书明文信息进行hash。
对hash后的值用私钥加密，得到数字签名。

明文和数字签名共同组成了数字证书，这样一份数字证书就可以颁发给网站了

浏览器如何验证数字证书

浏览器连接服务器，都先把证书发给客户端验证
使用CA公钥和声明的签名算法对CA中的签名进行解密，得到服务器的摘要内容和服务器公钥
再用摘要算法对证书里的服务器公钥生成摘要，再把这个摘要和上一步得到的摘要对比
然后将两个信息摘要对比，如果是一致的，就说明证书是合法的，即证明了服务器自己，否则就是非法的

通俗版:

拿到证书，得到明文T，数字签名S。
用CA机构的公钥对S解密（由于是浏览器信任的机构，所以浏览器保有它的公钥。详情见下文），得到S’。
用证书里说明的hash算法对明文T进行hash得到T’。
比较S’是否等于T’，等于则表明证书可信

证书认证又分为单向认证和双向认证

单向认证：服务器发送证书，客户端验证证书
双向认证：服务器和客户端分别提供证书给对方，并互相验证对方的证书

不过大多数https服务器都是单向认证，如果服务器需要验证客户端的身份，一般通过用户名、密码、手机验证码等之类的凭证来验证。只有更高级别的要求的系统，比如大额网银转账等，就会提供双向认证的场景，来确保对客户身份提供认证性

另外在申请和使用证书的过程中，需要注意

申请数字证书是不需要提供私钥的，要确保私钥永远只能由服务器掌握
数字证书最核心的是CA使用它的私钥生成的数字签名
内置CA对应的证书称为根证书，根证书是最权威的机构，它们自己为自己签名，这称为自签名证书

为什么这样可以证明证书可信呢?

假设中间人篡改了证书的原文，由于他没有CA机构的私钥，所以无法得到此时加密后签名，无法相应地篡改签名。浏览器收到该证书后会发现原文和签名解密后的值不一致，则说明证书已被篡改，证书不可信，从而终止向服务器传输信息，防止信息泄露给中间人。
假设有另一个网站B也拿到了CA机构认证的证书，它想搞垮网站A，想劫持网站A的信息。于是它成为中间人拦截到了A传给浏览器的证书，然后替换成自己的证书，传给浏览器，之后浏览器就会错误地拿到B的证书里的公钥了，又会导致上文提到的混合加密的漏洞。其实这并不会发生，因为证书里包含了网站A的信息，包括域名，浏览器把证书里的域名与自己请求的域名比对一下就知道有没有被掉包了。

为什么制作数字签名时需要hash一次？
最显然的是性能问题，前面我们已经说了非对称加密效率较差，证书信息一般较长，比较耗时。而hash后得到的是固定长度的信息（比如用md5算法hash后可以得到固定的128位的值），这样加密解密就会快很多。当然还有安全上的原因，这部分内容相对深一些，感兴趣的可以看这篇解答：详情

怎么证明CA机构的公钥是可信的？
即“该公钥是否对应该网站/机构等”，那这个CA机构的公钥是不是也可以用数字证书来证明？没错，操作系统、浏览器本身会预装一些它们信任的根证书，如果其中有该CA机构的根证书，那就可以拿到它对应的可信公钥了

实际上证书之间的认证也可以不止一层，可以A信任B，B信任C，以此类推，我们把它叫做信任链或数字证书链，也就是一连串的数字证书，由根证书为起点，透过层层信任，使终端实体证书的持有者可以获得转授的信任，以证明身份。
另外，不知你们是否遇到过网站访问不了、提示要安装证书的情况？这里安装的就是根证书。说明浏览器不认给这个网站颁发证书的机构，那么没有该机构的根证书，你就得手动下载安装（风险自己承担XD）。安装该机构的根证书后，你就有了它的公钥，就可以用它验证服务器发来的证书是否可信了。

HTTPS必须在每次请求中都要先在SSL/TLS层进行握手传输密钥吗？
显然每次请求都经历一次密钥传输过程非常耗时，那怎么达到只传输一次呢？靠“session”。服务器会为每个浏览器（或客户端软件）维护一个session ID，在TSL握手阶段传给浏览器，浏览器生成好密钥传给服务器后，服务器会把该密钥存到相应的session ID下，之后浏览器每次请求都会携带session ID，服务器会根据session ID找到相应的密钥并进行解密加密操作，这样就不必要每次重新制作、传输密钥了！

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

几种版本的握手加密方法
传统的TLS握手也就是RSA握手；

客户端首先向服务端发送一个HTTPS请求
服务端会把事先配置好的公钥证书随着其它的信息返回给客户端
客户端在收到服务端发来的证书之后进行验证，验证的过程参考数字证书验证，会得到服务端的信息以及它的公钥
验证成功之后会用伪随机函数计算出一个加密所需要的对称密钥(secret)，并且用服务端的公钥加密这个对称密钥发送给服务端
服务端再用自己的私钥解密刚刚的消息，得到里面的对称密钥。此时服务端和客户端都有了对称密钥。
后面的传输都会用这个 secret 进行对称密钥加解密传输

详细的RSA握手

客户端首先发送 client_random、TSL版本号、加密套件列表给服务器
服务器在接收到之后确认TSL版本号，同时发送server_random、需要使用的加密套件、自己的证书给客户端
客户端在收到这些信息之后，首先是会对服务器的证书进行验证(也就是题目7)，若是验证成功则会用RSA算法生成一个pre_random，且用服务器的公钥(在证书中)加密pre_random发送给服务器。
此时，客户端有了 client_random、server_random、pre_random，它会将这三个参数通过一个伪随机函数计算得出最终的secret，这个secret就是它们后续通信所要用的对称密钥。
服务器接收到了刚刚用自己公钥加密的pre_random之后，用自己的私钥进行解密，得到里面的 pre_random，用和客户端一样的方式生成secret。
之后就用这个 secret对称密钥加密报文传输。

现在主流的TLS1.2版本的握手，也就是ECDHE握手。

客户端在第一次发送HTTPS请求的时候，会把 client_random、TSL版本号、加密套件列表发送给服务器
服务器在接收到之后确认TSL的版本号，同时发送 server_random、server_params、需要使用的加密套件、以及自己的证书给客户端
客户端在收到这些信息之后，首先是会对服务器的证书进行验证(也就是题目7)，若是验证成功则会传递一个 client_params 给服务器
与此同时客户端会通过ECDHE算法计算出一个pre_random，其中是传入了两个参数，一个是 client_params，还一个是 server_params。(也就是说：ECDHE(client_params, server_params) = per_random)
这时候客户端就同时拥有了 client_random、server_random、pre_random，它会将这三个参数通过一个伪随机函数计算得出最终的secret，这个secret就是它们后续通信所要用的对称密钥。
而在客户端生成完secret之后，会给服务器发送一个收尾消息，告诉服务器之后都要用对称加密，且对称加密的算法是用第一次约定好的。
服务器它在接收到刚刚传递过来的client_params之后，也会使用和客户端一样的方式生成secret，并且也会发送一个收尾消息给客户端。
当双方都收到收尾消息并验证成功之后，握手就结束了。后面开始用这个secret对称密钥加密报文进行传输。
（ECDHE基于椭圆曲线离散对数，传入的两个参数也被叫做椭圆曲线的公钥）

ECDHE握手和RSA握手又有什么区别

生成secret(对称密钥)的过程不同。RSA中是使用RSA算法生成一个pre_random并用服务器的公钥加pre_random发送给服务器，然后各自用伪随机函数生成相同的secret对称密钥；而在ECDHE握手中，它没有用到RSA算法，而是用ECDHE算法生成的pre_random，且这个过程中比RSA多了client_params和server_params两个参数。
在生成完secret之后，ECDHE握手在客户端发送完收尾消息后可以提前抢跑，直接发送 HTTP 报文，节省了一个 RTT，不必等到收尾消息到达服务器，然后等服务器返回收尾消息给自己，直接开始发请求。这也叫TLS False Start。
最主要的：RSA不具备向前安全性（向前安全性：一次破解并不影响历史信息的性质就是向前安全性），ECDHE有

向前安全性

比如在RSA握手的过程中，客户端拿到了服务端的公钥，然后用此公钥加密pre_random给服务端。如果此时有第三方有服务端的私钥，并且截获了之前所有报文的时候，那么它就可以破解这段密文并拿到pre_random、client_random、server_random并根据对应的伪随机函数生成secret，即拿到了最终通信的对称密钥，每一个历史报文都能通过这样的方式进行破解。它就不具有向前安全性。
但是ECDHE在每次握手的时候都会产生一个零时的密钥对(也就是client_params、server_params)，即使第三方有了私钥能破解，但是对之前的历史报文并没有影响。它就具有向前安全性。

通信传输:
报文从运用层传送到运输层，运输层通过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实现原理

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

HTTP/2 连接建立过程
基于 SSL/TLS 的 HTTP/2 连接建立过程和 HTTPS 差不多。在 SSL/TLS 握手协商过程中，客户端在 ClientHello 消息中设置 ALPN（应用层协议协商）扩展来表明期望使用 HTTP/2 协议，服务器用同样的方式回复。通过这种方式，HTTP/2 在 SSL/TLS 握手协商过程中就建立起来了。

http、https加密过程相关推荐

HTTPS加密过程和TLS证书验证
HTTPS加密过程和TLS证书验证 HTTPS 是在 HTTP 和 TCP 之间建立了一个安全层,HTTP 与 TCP 通信的时候,必须先进过一个安全层,对数据包进行加密,然后将加密后的数据包传送给 ...
HTTPS加密过程详解
HTTPS加密过程详解一.前言二.HTTPS的混合加密 1.摘要算法 2.混合加密和数字证书三.补充四.参考资料一.前言 http是为了解决http存在的问题而在http基础上加入了SSL/ ...
HTTPS 加密过程详解
HTTPS 加密过程详解 HTTPS 中的概念对比 HTTP 与 HTTPS 网络分层结构对称加密非对称加密 HTTPS 中的概念明文:可以直接看到原始数据的文本: 密文:看不见原始数据的文本 ...
最简单的HTTPS加密过程简介
HTTPS协议其实就是HTTP over TSL,TSL(Transport Layer Security) 传输层安全协议是https协议的核心. TSL可以理解为SSL (Secure Socke ...
https加密过程（详细）
握手.协商加密算法.获取公钥证书(含公钥一起发送至客户端).验证公钥证书(判断证书是否是第三方机构信任证书,创建对称密钥,每次传输一次对话随机创建一个对称密钥,客户端用服务器发送的公钥 ...
(非)对称加密算法在https中的应用（加密过程以及CA颁发、验证）
文章目录一.(非)对称加密对称加密非对称加密二.http与https 1. HTTP 1.1 HTTP与TCP 1.2 短/长连接(HTTP如何使用TCP) 2. HTTPS = HTTP+S ...
HTTPS 的加密过程
HTTPS 的加密过程引言理解加密解密 SSL 的握手过程场景一场景二场景三中间人攻击场景四总结引言 HTTPS:Hyper Text Transfer Protocol over ...
HTTPS加密数据传输过程
HTTPS加密过程 HTTPS采用对称加密和非对称加密的混合加密方式 1.加密方式 2.混合加密 3.HTTPS的数据传输的优缺点 HTTPS采用对称加密和非对称加密的混合加密方式 1.加密方式数据 ...
Https 加密原理分析
众所周知,HTTP 协议通过明文传输,是不安全的.于是,就在 HTTP 协议的基础上,进行了数据加密,也就诞生了 HTTPS 协议.注意,HTTPS 并不是一个新的协议,它只不过是在 HTTP 的基础 ...

http、https加密过程

http、https加密过程相关推荐

最新文章

热门文章