目录
[HTTP和HTTPS的基本概念(应用层协议）](#HTTP和HTTPS的基本概念(应用层协议）)
HTTP和HTTPS的基本概念(应用层协议）
HTTP（HyperText Transfer Protocol：超文本传输协议）：是互联网上应用最为广泛的一种网络协议，是一个客户端和服务器端请求和应答的标准（TCP），用于从Web服务器传输超文本到本地浏览器的传输协议，它可以使浏览器更加高效，使网络传输减少。
HTTPS（HyperText Transfer Protocol Secure：超文本传输安全协议）：是以安全为目标的HTTP通道，即HTTP下加入SSL层，HTTPS的安全基础是SSL，因此加密的详细内容就需要SSL。HTTPS 开发的主要目的，是提供对网站服务器的身份认证，保护交换数据的隐私与完整性。
HTTP的版本
HTTP协议主要有1.0,1.1,2.0三个版本:
HTTP/1.0:
- 0.9版本,第一次定义HTTP基本功能。
- 1.0版本,增加内容类型信息。定义了GET、POST、HEAD等方法。
HTTP/1.1：
- 增加Host请求头,支持同时连接多个主机。
- 新增缓存处理机制。
- 增加Range请求头,支持断点续传。
- 增加PUT和DELETE方法。
- 增加流水线的概念,支持在同一个TCP连接上发起多个请求。
HTTP/1的长连接：
HTTP长连接（long connection）与短连接（short connection）本质上是TCP长连接和短连接：短连接是指在一次HTTP请求和响应之后立即关闭本次TCP连接，下次请求响应重建一个新的TCP连接；而长连接是指请求响应之后并不立即关闭本次TCP连接，下次请求响应继续重用该TCP连接。HTTP/1.0默认短连接，HTTP/1.1起默认长连接，长连接通过请求头Connection: keep-alive启用长连接、通过Keep-Alive: timeout=20设置长连接的超时时间（秒）。
HTTP/1的长轮询：
而HTTP长轮询（long polling）是指服务端收到请求后若有数据立即返回，若无数据则保持到有数据或一段时间后超时，浏览器收到响应后立即重新发送相同的请求；HTTP短轮询（short polling）是指服务端收到请求后无论是否有数据都立即返回，浏览器收到响应后间隔一段时间后重新发送相同的请求。轮询建立在连接基础上，轮询是长是短与连接是长是短无关。
HTTP长轮询主要用于实现需要实时获取数据的地方，例如：即时消息、实时股票价格等，其主要技术要点在于服务端无数据时如何保持到有数据或超时。另外在请求发生频率上，长轮询也可以在入短连接一样收到响应后间隔一段时间后才发送，只是会不够实时；短轮询也可以如长连接一样在收到响应后立即发送，只是会给服务器端造成过大压力。
HTTP/2.0:
- 二进制协议,更高效。
- 全双工:客户端和服务器之间可以同时发送数据。
- 数据流:可以在一个连接中交替使用多个流进行数据传输。
- 首部压缩:发送相同的首部只发送一次。
- 服务端推送:服务器可以在客户端请求时主动推送数据。
HTTP/2的队头阻塞：
HTTP1.1中引入了长连接，允许多个连接复用一个TCP连接。
当多个请求先后调用HTTP发送的时候，如果前一个请求不响应的话，后一个请求是不会发送的。
所以如果前一个响应阻塞的话，后边的请求也会被迫阻塞，叫做队头阻塞。
HTTP2.0时，引入了帧、流的概念。
HTTP2是基于TCP的。HTTP2允许多个请求不按照先后顺序发送数据，并允许穿插的发送数据，也就是每次发送一个帧。
那么怎么区分帧属于哪个HTTP请求呢？
会对每个HTTP请求进行编号，然后再帧中插入对应的HTTP编号和其在HTTP请求中的位置序号，然后发送到服务器，服务器根据HTTP编号和位置序号来将帧重组，然后同时乱序的发送应答，客户端也通过HTTP编号和位置序号来重组帧。
这样就避免了HTTP层面的队头阻塞。
但是仍无法解决TCP的队头阻塞。
TCP由于引入了滑动窗口，并且每次可以发送多个数据，并且可以乱序接受。当序号大的数据先到达后，仍然不能被应用程序读取，需要等到序号靠前的数据到了之后，才能被应用程序读取，这也出现了队头阻塞。
这个队头阻塞是TCP实现可靠传输的副作用，无法解决。
HTTP/3.0:
- 实现了类似TCP的流量控制，传输可靠性的功能。
- 实现了快速握手功能（QUIC基于UDP，UDP是面向无连接的，不需要握手和挥手，比TCP快
- 集成了TLS加密功能
- 多路复用，彻底解决TCP中队头阻塞的问题（单个"流"是有序的，可能会因为丢包而阻塞，但是其他流不会受到影响）
总结
- HTTP1.1的缺点：安全性不足和性能不高；
- HTTP2.0完全兼容HTTTP1.0，是"更安全的HTTP，更快的HTTPS"，头部压缩，多路复用等技术充分利用了带宽，降低了延迟。
- HTTP3.0的底层支撑协议QUIC基于UDP实现，又含TCP的特点，实现了又快又可靠的协议。
HTTP与HTTPS有什么区别？
1、HTTPS协议需要到CA（Certificate Authority，数字证书认证机构）申请证书，一般免费证书较少，因而需要一定费用。
2、HTTP是超文本传输协议，信息是明文传输，数据是不加密的，而HTTPS则是具有安全性的SSL加密传输协议。
3、HTTP和HTTPS使用的是完全不同的连接方式，用的端口也不一样，HTTP是80端口，HTTPS是443端口。
4、HTTP的连接很简单，是无状态的，HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，比HTTP协议安全。
HTTP的工作原理
1.客户端与服务器建立TCP连接（三次握手）
2.连接成功后，客户端发送请求给服务器
3.服务器接收到客户端发送的请求后作出相应，并将响应信息发送给客户端
4.服务器发送完响应信息后，就会断开TCP连接，因此HTTP是无状态的，下一次访问的时候不会知道之前访问的过程
5.客户端接收到响应信息，浏览器进行解析，将html文件解析后呈现一个网页在浏览器上
HTTPS的工作原理
1、客户端发起HTTPS请求
这个没什么好说的，就是用户在浏览器里输入一个https网址，然后连接到server的443端口。
2、服务端的配置
采用HTTPS协议的服务器必须要有一套数字证书，可以自己制作，也可以向组织申请，区别就是自己颁发的证书需要客户端验证通过，才可以继续访问，而使用受信任的公司申请的证书则不会弹出提示页面(startssl就是个不错的选择，有1年的免费服务)。
这套证书其实就是一对公钥和私钥，如果对公钥和私钥不太理解，可以想象成一把钥匙和一个锁头，只是全世界只有你一个人有这把钥匙，你可以把锁头给别人，别人可以用这个锁把重要的东西锁起来，然后发给你，因为只有你一个人有这把钥匙，所以只有你才能看到被这把锁锁起来的东西。
3、传送证书
这个证书其实就是公钥，只是包含了很多信息，如证书的颁发机构，过期时间等等。
4、客户端解析证书
这部分工作是有客户端的TLS来完成的，首先会验证公钥是否有效，比如颁发机构，过期时间等等，如果发现异常，则会弹出一个警告框，提示证书存在问题。
如果证书没有问题，那么就生成一个随机值，然后用证书对该随机值进行加密，就好像上面说的，把随机值用锁头锁起来，这样除非有钥匙，不然看不到被锁住的内容。
5、传送加密信息
这部分传送的是用证书加密后的随机值，目的就是让服务端得到这个随机值，以后客户端和服务端的通信就可以通过这个随机值来进行加密解密了。
6、服务段解密信息
服务端用私钥解密后，得到了客户端传过来的随机值(私钥)，然后把内容通过该值进行对称加密，所谓对称加密就是，将信息和私钥通过某种算法混合在一起，这样除非知道私钥，不然无法获取内容，而正好客户端和服务端都知道这个私钥，所以只要加密算法够彪悍，私钥够复杂，数据就够安全。
7、传输加密后的信息
这部分信息是服务段用私钥加密后的信息，可以在客户端被还原。
8、客户端解密信息
客户端用之前生成的私钥解密服务段传过来的信息，于是获取了解密后的内容，整个过程第三方即使监听到了数据，也束手无策。
HTTPS的优点
1、SEO方面
谷歌曾在2014年8月份调整搜索引擎算法，并称"比起同等HTTP网站，采用HTTPS加密的网站在搜索结果中的排名将会更高"。
2、安全性
尽管HTTPS并非绝对安全，掌握根证书的机构、掌握加密算法的组织同样可以进行中间人形式的攻击，但HTTPS仍是现行架构下最安全的解决方案，主要有以下几个好处：
（1）、使用HTTPS协议可认证用户和服务器，确保数据发送到正确的客户机和服务器；
（2）、HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，要比http协议安全，可防止数据在传输过程中不被窃取、改变，确保数据的完整性。
（3）、HTTPS是现行架构下最安全的解决方案，虽然不是绝对安全，但它大幅增加了中间人攻击的成本。
HTTPS的缺点：
1、SEO方面
据ACM CoNEXT数据显示，使用HTTPS协议会使页面的加载时间延长近50%，增加10%到20%的耗电，此外，HTTPS协议还会影响缓存，增加数据开销和功耗，甚至已有安全措施也会受到影响也会因此而受到影响。
而且HTTPS协议的加密范围也比较有限，在黑客攻击、拒绝服务攻击、服务器劫持等方面几乎起不到什么作用。
最关键的，SSL证书的信用链体系并不安全，特别是在某些国家可以控制CA根证书的情况下，中间人攻击一样可行。
2、经济方面
（1）、SSL证书需要钱，功能越强大的证书费用越高，个人网站、小网站没有必要一般不会用。
（2）、SSL证书通常需要绑定IP，不能在同一IP上绑定多个域名，IPv4资源不可能支撑这个消耗（SSL有扩展可以部分解决这个问题，但是比较麻烦，而且要求浏览器、操作系统支持，Windows XP就不支持这个扩展，考虑到XP的装机量，这个特性几乎没用）。
（3）、HTTPS连接缓存不如HTTP高效，大流量网站如非必要也不会采用，流量成本太高。
（4）、HTTPS连接服务器端资源占用高很多，支持访客稍多的网站需要投入更大的成本，如果全部采用HTTPS，基于大部分计算资源闲置的假设的VPS的平均成本会上去。
（5）、HTTPS协议握手阶段比较费时，对网站的相应速度有负面影响，如非必要，没有理由牺牲用户体验。
HTTPS的优缺点（总结）
1.优点：
（1）使用HTTPS协议可认证用户和服务器，确保数据发送到正确的客户机和服务器；
（2）HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，要比http协议安全，可防止数据在传输过程中不被窃取、改变，确保数据的完整性。
（3）HTTPS是现行架构下最安全的解决方案，虽然不是绝对安全，但它大幅增加了中间人攻击的成本。
（4）谷歌曾在2014年8月份调整搜索引擎算法，并称"比起同等HTTP网站，采用HTTPS加密的网站在搜索结果中的排名将会更高"。
2.缺点：
（1）HTTPS协议握手阶段比较费时，会使页面的加载时间延长近50%，增加10%到20%的耗电；
（2）HTTPS连接缓存不如HTTP高效，会增加数据开销和功耗，甚至已有的安全措施也会因此而受到影响；
（3）SSL证书需要钱，功能越强大的证书费用越高，个人网站、小网站没有必要一般不会用。
（4）SSL证书通常需要绑定IP，不能在同一IP上绑定多个域名，IPv4资源不可能支撑这个消耗。
（5）HTTPS协议的加密范围也比较有限，在黑客攻击、拒绝服务攻击、服务器劫持等方面几乎起不到什么作用。最关键的，SSL证书的信用链体系并不安全，特别是在某些国家可以控制CA根证书的情况下，中间人攻击一样可行。
对称加密
- 采⽤单钥密码系统的加密⽅法，同⼀个密钥可以同时⽤作信息的加密和解密，这种加密⽅法称为对称加密，也称为单密钥加密，特征：加密和解密所⽤的密钥是相同的
- 常⻅对称加密算法(了解)：DES、3DES、AES、TDEA、Blowfish、RC2等
- 特点：算法公开、计算量⼩、加密速度快、加密效率⾼
- 对称加密其实就是通过同⼀个 "密钥" , 把明⽂加密成密⽂, 并且也能把密⽂解密成明⽂
⼀个简单的对称加密, 按位异或
假设 明⽂ a = 1234, 密钥 key = 8888 则加密 a ^ key 得到的密⽂ b 为 9834. 然后针对密⽂ 9834 再次进⾏运算 b ^ key, 得到的就是原来的明⽂ 1234. (对于字符串的对称加密也是同理, 每⼀个字符都可以表⽰成⼀个数字) 当然, 按位异或只是最简单的对称加密. HTTPS 中并不是使⽤按位异或
非对称加密
- 需要两个密钥来进⾏加密和解密，这两个密钥是公开密钥（public key，简称公钥）和私有密钥（private key，简称私钥）。
- 常⻅⾮对称加密算法(了解)：RSA，DSA，ECDSA
- 特点：算法强度复杂、安全性依赖于算法与密钥但是由于其算法复杂，⽽使得加密解密速度没有对
- 称加密解密的速度快。
- ⾮对称加密要⽤到两个密钥, ⼀个叫做 "公钥", ⼀个叫做 "私钥".
- 公钥和私钥是配对的. 最⼤的缺点就是运算速度⾮常慢，⽐对称加密要慢很多.
- 通过公钥对明⽂加密, 变成密⽂
- 通过私钥对密⽂解密, 变成明⽂
- 也可以反着⽤
- 通过私钥对明⽂加密, 变成密⽂
- 通过公钥对密⽂解密, 变成明⽂
⾮对称加密的数学原理⽐较复杂, 涉及到⼀些 数论 相关的知识. 这⾥举⼀个简单的⽣活上的例⼦.
A 要给 B ⼀些重要的⽂件, 但是 B 可能不在. 于是 A 和 B 提前做出约定:
B 说: 我桌⼦上有个盒⼦, 然后我给你⼀把锁, 你把⽂件放盒⼦⾥⽤锁锁上, 然后我回头拿着钥匙来开锁取⽂件.
在这个场景中, 这把锁就相当于公钥, 钥匙就是私钥. 公钥给谁都⾏(不怕泄露), 但是私钥只有 B ⾃⼰持有. 持有私钥的⼈才能解密.
证书
中间⼈有没有可能篡改该证书？
- 中间⼈篡改了证书的明⽂
- 由于他没有CA机构的私钥，所以⽆法hash之后⽤私钥加密形成签名，那么也就没法办法对篡改后的证书形成匹配的签名
- 如果强⾏篡改，客⼾端收到该证书后会发现明⽂和签名解密后的值不⼀致，则说明证书已被篡改，证书不可信，从⽽终⽌向服务器传输信息，防⽌信息泄露给中间⼈
中间⼈整个掉包证书？
- 因为中间⼈没有CA私钥，所以⽆法制作假的证书(为什么？)
- 所以中间⼈只能向CA申请真证书，然后⽤⾃⼰申请的证书进⾏掉包
- 这个确实能做到证书的整体掉包，但是别忘记，证书明⽂中包含了域名等服务端认证信息，如果整体掉包，客⼾端依旧能够识别出来。
- 永远记住：中间⼈没有CA私钥，所以对任何证书都⽆法进⾏合法修改，包括⾃⼰的
为什么摘要内容在⽹络传输的时候⼀定要加密形成签名?
假设我们的证书只是⼀个简单的字符串 hello, 对这个字符串计算hash值(⽐如md5), 结果为
BC4B2A76B9719D91
如果 hello 中有任意的字符被篡改了, ⽐如变成了 hella, 那么计算的 md5 值就会变化很⼤.
BDBD6F9CF51F2FD8
然后我们可以把这个字符串 hello 和 哈希值 BC4B2A76B9719D91 从服务器返回给客⼾端, 此时客⼾端如何验证 hello 是否是被篡改过?
那么就只要计算 hello 的哈希值, 看看是不是 BC4B2A76B9719D91
但是还有个问题, 如果⿊客把 hello 篡改了, 同时也把哈希值重新计算下, 客⼾端就分辨不出来了呀
所以被传输的哈希值不能传输明⽂, 需要传输密⽂.
所以，对证书明⽂(这⾥就是"hello")hash形成散列摘要，然后CA使⽤⾃⼰的私钥加密形成签名，将
hello和加密的签名合起来形成CA证书，颁发给服务端，当客⼾端请求的时候，就发送给客⼾端，中间 ⼈截获了，因为没有CA私钥，就⽆法更改或者整体掉包，就能安全的证明，证书的合法性。
最后，客⼾端通过操作系统⾥已经存的了的证书发布机构的公钥进⾏解密, 还原出原始的哈希值, 再进⾏校验.
为什么签名不直接加密，⽽是要先hash形成摘要?
缩⼩签名密⽂的⻓度,加快数字签名的验证签名的运算速度
HTTPS的加密
HTTPS ⼯作过程中涉及到的密钥有三组.
第⼀组(⾮对称加密): ⽤于校验证书是否被篡改. 服务器持有私钥(私钥在形成CSR⽂件与申请证书时获
得), 客⼾端持有公钥(操作系统包含了可信任的 CA 认证机构有哪些, 同时持有对应的公钥). 服务器在客
⼾端请求是，返回携带签名的证书. 客⼾端通过这个公钥进⾏证书验证, 保证证书的合法性，进⼀步保
证证书中携带的服务端公钥权威性。
第⼆组(⾮对称加密): ⽤于协商⽣成对称加密的密钥. 客⼾端⽤收到的CA证书中的公钥(是可被信任的)
给随机⽣成的对称加密的密钥加密, 传输给服务器, 服务器通过私钥解密获取到对称加密密钥.
第三组(对称加密): 客⼾端和服务器后续传输的数据都通过这个对称密钥加密解密.
其实⼀切的关键都是围绕这个对称加密的密钥. 其他的机制都是辅助这个密钥⼯作的.
第⼆组⾮对称加密的密钥是为了让客⼾端把这个对称密钥传给服务器.
第⼀组⾮对称加密的密钥是为了让客⼾端拿到第⼆组⾮对称加密的公钥.