http与https

原文：https://blog.csdn.net/u013777975/article/details/80496121 

原文：https://blog.csdn.net/qq_36908872/article/details/87740122  

HTTP(超文本传输协议)

HTTP是Hyper Text Transfer Protocol（超文本传输协议）的缩写

一次完整的HTTP请求过程
当我们在web浏览器的地址栏中输入： www.baidu.com，然后回车，到底发生了什么

过程概览
　　1.对www.baidu.com这个网址进行DNS域名解析，得到对应的IP地址

　　2.根据这个IP，找到对应的服务器，发起TCP的三次握手

　　3.建立TCP连接后发起HTTP请求

　　4.服务器响应HTTP请求，浏览器得到html代码

　　5.浏览器解析html代码，并请求html代码中的资源（如js、css图片等）（先得到html代码，才能去找这些资源）

　　6.浏览器对页面进行渲染呈现给用户

注：1.DNS域名解析采用的是递归查询的方式，过程是，先去找DNS缓存->缓存找不到就去找根域名服务器->根域名又会去找下一级，这样递归查找之后，找到了，给我们的web浏览器

2.为什么HTTP协议要基于TCP来实现？  TCP是一个端到端的可靠的面相连接的协议，HTTP基于传输层TCP协议不用担心数据传输的各种问题（当发生错误时，会重传）

3.最后一步浏览器是如何对页面进行渲染的？  a）解析html文件构成 DOM树，b）解析CSS文件构成渲染树，  c）边解析，边渲染 ，  d）JS 单线程运行，JS有可能修改DOM结构，意味着JS执行完成前，后续所有资源的下载是没有必要的，所以JS是单线程，会阻塞后续资源下载

 

下面我们来详细看看这几个过程的具体细节：
　　1.域名解析
　　a）首先会搜索浏览器自身的DNS缓存（缓存时间比较短，大概只有1分钟，且只能容纳1000条缓存）

　　b）如果浏览器自身的缓存里面没有找到，那么浏览器会搜索系统自身的DNS缓存

　　c）如果还没有找到，那么尝试从 hosts文件里面去找

　　d）在前面三个过程都没获取到的情况下，就递归地去域名服务器去查找，具体过程如下
1. 域名解析
以Chrome浏览器为例：

① Chrome浏览器 会首先搜索浏览器自身的DNS缓存（缓存时间比较短，大概只有1分钟，且只能容纳1000条缓存），看自身的缓存中是否有https://www.cnblogs.com 对应的条目，而且没有过期，如果有且没有过期则解析到此结束。

注：我们怎么查看Chrome自身的缓存？可以使用 chrome://net-internals/#dns 来进行查看

② 如果浏览器自身的缓存里面没有找到对应的条目，那么Chrome会搜索操作系统自身的DNS缓存,如果找到且没有过期则停止搜索解析到此结束.

注：怎么查看操作系统自身的DNS缓存，以Windows系统为例，可以在命令行下使用 ipconfig /displaydns 来进行查看

③ 如果在Windows系统的DNS缓存也没有找到，那么尝试读取hosts文件（位于C:\Windows\System32\drivers\etc），看看这里面有没有该域名对应的IP地址，如果有则解析成功。

④ 如果在hosts文件中也没有找到对应的条目，浏览器就会发起一个DNS的系统调用，就会向本地配置的首选DNS服务器（一般是电信运营商提供的，也可以使用像Google提供的DNS服务器）发起域名解析请求（通过的是UDP协议向DNS的53端口发起请求，这个请求是递归的请求，也就是运营商的DNS服务器必须得提供给我们该域名的IP地址），运营商的DNS服务器首先查找自身的缓存，找到对应的条目，且没有过期，则解析成功。如果没有找到对应的条目，则有运营商的DNS代我们的浏览器发起迭代DNS解析请求，它首先是会找根域的DNS的IP地址（这个DNS服务器都内置13台根域的DNS的IP地址），找打根域的DNS地址，就会向其发起请求（请问www.cnblogs.com这个域名的IP地址是多少啊？），根域发现这是一个顶级域com域的一个域名，于是就告诉运营商的DNS我不知道这个域名的IP地址，但是我知道com域的IP地址，你去找它去，于是运营商的DNS就得到了com域的IP地址，又向com域的IP地址发起了请求（请问www.cnblogs.com这个域名的IP地址是多少?）,com域这台服务器告诉运营商的DNS我不知道www.cnblogs.com这个域名的IP地址，但是我知道cnblogs.com这个域的DNS地址，你去找它去，于是运营商的DNS又向cnblogs.com这个域名的DNS地址（这个一般就是由域名注册商提供的，像万网，新网等）发起请求（请问www.cnblogs.com这个域名的IP地址是多少？），这个时候cnblogs.com域的DNS服务器一查，诶，果真在我这里，于是就把找到的结果发送给运营商的DNS服务器，这个时候运营商的DNS服务器就拿到了www.cnblogs.com这个域名对应的IP地址，并返回给Windows系统内核，内核又把结果返回给浏览器，终于浏览器拿到了www.cnblogs.com 对应的IP地址，该进行一步的动作了。

注：一般情况下是不会进行以下步骤的

如果经过以上的4个步骤，还没有解析成功，那么会进行如下步骤（以下是针对Windows操作系统）：

⑤ 操作系统就会查找NetBIOS name Cache（NetBIOS名称缓存，就存在客户端电脑中的），那这个缓存有什么东西呢？凡是最近一段时间内和我成功通讯的计算机的计算机名和Ip地址，就都会存在这个缓存里面。什么情况下该步能解析成功呢？就是该名称正好是几分钟前和我成功通信过，那么这一步就可以成功解析。

⑥ 如果第⑤步也没有成功，那会查询WINS 服务器（是NETBIOS名称和IP地址对应的服务器）

⑦ 如果第⑥步也没有查询成功，那么客户端就要进行广播查找

⑧ 如果第⑦步也没有成功，那么客户端就读取LMHOSTS文件（和HOSTS文件同一个目录下，写法也一样）

如果第八步还没有解析成功，那么就宣告这次解析失败，那就无法跟目标计算机进行通信。只要这八步中有一步可以解析成功，那就可以成功和目标计算机进行通信。

2.TCP连接（三次握手）
　　拿到域名对应的IP地址之后，User-Agent（一般指浏览器）会以一个随机端口（1024<端口<65535）向服务器的WEB程序（常用的有httpd，nginx）等的80端口。这个连接请求（原始的http请求经过TCP/IP4层模型的层层封包）到达服务器端后（这中间有各种路由设备，局域网内除外），进入到网卡，然后是进入到内核的TCP/IP协议栈（用于识别连接请求，解封包，一层一层的剥开），还有可能要经过Netfilter防火墙（属于内核的模块）的过滤，最终达到WEB程序，最终建立了TCP/IP的连接

3.建立TCP连接之后，发起HTTP请求
　　HTTP请求报文由三部分组成：请求行，请求头和请求正文

　　请求行：用于描述客户端的请求方式，请求的资源名称以及使用的HTTP协议的版本号（例：GET/books/java.html HTTP/1.1）

　　请求头：用于描述客户端请求哪台主机，以及客户端的一些环境信息等

　　注：这里提一个请求头 Connection，Connection设置为 keep-alive用于说明 客户端这边设置的是，本次HTTP请求之后并不需要关闭TCP连接，这样可以使下次HTTP请求使用相同的TCP通道，节省TCP建立连接的时间

　　请求正文：当使用POST, PUT等方法时，通常需要客户端向服务器传递数据。这些数据就储存在请求正文中（GET方式是保存在url地址后面，不会放到这里）

 

　　4.服务器端响应http请求，浏览器得到html代码
　　HTTP响应也由三部分组成：状态码，响应头和实体内容

　　状态码：状态码用于表示服务器对请求的处理结果

　　列举几种常见的：200（没有问题） 302（要你去找别人） 304（要你去拿缓存） 307（要你去拿缓存） 403（有这个资源，但是没有访问权限） 404（服务器没有这个资源） 500（服务器这边有问题）

　　若干响应头：响应头用于描述服务器的基本信息，以及客户端如何处理数据

　　实体内容：服务器返回给客户端的数据

　　注：html资源文件应该不是通过 HTTP响应直接返回去的，应该是通过nginx通过io操作去拿到的吧

 

　　5.浏览器解析html代码，并请求html代码中的资源
　　浏览器拿到html文件后，就开始解析其中的html代码，遇到js/css/image等静态资源时，就向服务器端去请求下载（会使用多线程下载，每个浏览器的线程数不一样），这是时候就用上 keep-alive特性了，建立一次HTTP连接，可以请求多个资源，下载资源的顺序就是按照代码里面的顺序，但是由于每个资源大小不一样，而浏览器又是多线程请求请求资源，所以这里显示的顺序并不一定是代码里面的顺序。

 

　　6.浏览器对页面进行渲染呈现给用户
　　最后，浏览器利用自己内部的工作机制，把请求的静态资源和html代码进行渲染，渲染之后呈现给用户

 　　浏览器是一个边解析边渲染的过程。首先浏览器解析HTML文件构建DOM树，然后解析CSS文件构建渲染树，等到渲染树构建完成后，浏览器开始布局渲染树并将其绘制到屏幕上。这个过程比较复杂，涉及到两个概念: reflow(回流)和repain(重绘)。DOM节点中的各个元素都是以盒模型的形式存在，这些都需要浏览器去计算其位置和大小等，这个过程称为relow;当盒模型的位置,大小以及其他属性，如颜色,字体,等确定下来之后，浏览器便开始绘制内容，这个过程称为repain。页面在首次加载时必然会经历reflow和repain。reflow和repain过程是非常消耗性能的，尤其是在移动设备上，它会破坏用户体验，有时会造成页面卡顿。所以我们应该尽可能少的减少reflow和repain。

　　JS的解析是由浏览器中的JS解析引擎完成的。JS是单线程运行，JS有可能修改DOM结构，意味着JS执行完成前，后续所有资源的下载是没有必要的，所以JS是单线程，会阻塞后续资源下载

 

　　自此一次完整的HTTP事务宣告完成.
HTTP状态码

• 100 Continue 继续，一般在发送post请求时，已经发送了http header之后服务端将返回此信息，表示确认，之后发送具体参数信息
• 200 OK 正常返回信息
• 201 Created 请求成功并且服务器创建了新的资源
• 202 Accepted 服务器已接受请求，但尚未处理
• 301 Moved Permanently 请求的网页已永久移动到新位置。
• 302 Found 临时性重定向。
• 303 See Other 临时性重定向，且总是使用 GET 请求新的 URI。
• 304 Not Modified 自从上次请求后，请求的网页未修改过。
• 400 Bad Request 服务器无法理解请求的格式，客户端不应当尝试再次使用相同的内容发起请求。
• 401 Unauthorized 请求未授权。
• 403 Forbidden 禁止访问。
• 404 Not Found 找不到如何与 URI 相匹配的资源。
• 500 Internal Server Error 最常见的服务器端错误。
• 503 Service Unavailable 服务器端暂时无法处理请求(可能是过载或维护)。

HTTPS

HTTPS是HTTP over SSL的简称，即工作在SSL上的HTTP。也就是加密通信的HTTP。

2 工作原理
HTTPS在通信过程中使用的是对称加密，当然，它的密钥是无法直接获取的，因为它的密钥是通过非对称加密进行传输的，中间还有很多复杂的过程，保证密钥是绝对安全的。那么，问题来了，非对称加密那么安全，为什么要多此一举来使用这种复杂的对称加密方式呢，原因很简单。非对称加密的通信过程会影响网络通信的性能。

3 连接建立的过程
1  客户端发送Client Hello，同时发送的，还有两个东西，一个是客户端的随机数，一个是客户端支持的 TLS版本、对称加密算法、非对称加密算法、hash算法。其中，TLS版本，加密算法等，可能不止一个，让服务端选择适合自己的。

2  服务端发送Server Hello，同时，自己也会发送一个随机数给客户端，这个随机数叫服务端的随机数。另外，会从客户端发送的TSL版本，加密算法、hash算法中选定一个。此时，双方确立了TLS的版本，对称加密的算法、非对称加密的算法、hash算法。服务端有两个随机数，服务端自己生成的随机数和客户端发送过来的随机数。客户端也有这两个随机数。

3  服务端发送公钥，这个公钥是为了加密非对称加密的密钥的。但是，这个服务器是需要做验证的，证明你就是我想访问的服务器。所以，服务器发送的不是公钥，而是证书，这个证书包含服务器公钥、服务器地址、证书签名等。

4  为了证明服务器证书是真实有效的，需要用证书机构的公钥来对它进行签名，那么证书机构如何证明自己是真实的呢，证书机构是由根证书机构签的。根证书机构是可以找到可靠来源的，这个可靠来源就是操作系统。任何一个操作系统，包括ios android windows等，都有一个根证书机构的列表。根证书是被操作系统研发方认证的，所以是绝对安全的。

5  客户端生成一个随机数，叫pre-master secret。这个随机数会通过非对称加密发送给服务端，公钥就是之前服务端发送过来的，然后服务端自己有私钥，所以这个随机数理论上是获取不到的。像之前的客户端随机数和服务端随机数都是明文的，而这个是非对称加密后发送的。这个也是HTTPS中唯一的一次非对称加密。

6  这个时候，双方就可以生成对称密钥了。这三个随机数会通过一个算法，得出一个新的master secret。但是这个master secret并不是密钥，密钥是有好几个东西的。它们分别是客户端加密密钥，服务端加密密钥，客户端MAC Secret，服务端MAC Secret。这个MAC Secret就是一个HMAC的Secret。类似于普通的hash算法。但是比hash更安全，因为它会先对原数据做一些操作，再进行hash算法。通过加密密钥和这个MAC Secret，就可以实现数据的加密和验证身份。

7  双方进行一次加密验证，看下这个加密算法能否正常使用。首先，客户端说它要开始加密通信了，然后，客户端把前面的全部信息使用密钥加密和使用HMAC签名，并且发送到服务器端。服务端验证能否解密，能否进行身份验证。如果都可以，服务端就可以对客户端足够信任。

8  客户端验证完后，开始到服务端验证。服务端也是先发送，我要开始加密了。然后，把前面的信息也用服务端的对称密钥进行加密，使用服务端的HMAC进行签名，发送到客户端。客户端能够解密并且验证身份。客户端就可以对服务端也有足够的信任。此时，双方的验证完全结束。

9  最后一步，它们就可以开始使用HTTPS进行加密通信了。

四、HTTPS的优点
尽管HTTPS并非绝对安全，掌握根证书的机构、掌握加密算法的组织同样可以进行中间人形式的攻击，但HTTPS仍是现行架构下最安全的解决方案，主要有以下几个好处：

（1）使用HTTPS协议可认证用户和服务器，确保数据发送到正确的客户机和服务器；
　　（2）HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，要比http协议安全，可防止数据在传输过程中不被窃取、改变，确保数据的完整性。
　　（3）HTTPS是现行架构下最安全的解决方案，虽然不是绝对安全，但它大幅增加了中间人攻击的成本。
　　（4）谷歌曾在2014年8月份调整搜索引擎算法，并称“比起同等HTTP网站，采用HTTPS加密的网站在搜索结果中的排名将会更高”。

五、HTTPS的缺点
虽然说HTTPS有很大的优势，但其相对来说，还是存在不足之处的：

（1）HTTPS协议握手阶段比较费时，会使页面的加载时间延长近50%，增加10%到20%的耗电；
　　（2）HTTPS连接缓存不如HTTP高效，会增加数据开销和功耗，甚至已有的安全措施也会因此而受到影响；
　　（3）SSL证书需要钱，功能越强大的证书费用越高，个人网站、小网站没有必要一般不会用。
　 （4）SSL证书通常需要绑定IP，不能在同一IP上绑定多个域名，IPv4资源不可能支撑这个消耗。
　　（5）HTTPS协议的加密范围也比较有限，在黑客攻击、拒绝服务攻击、服务器劫持等方面几乎起不到什么作用。最关键的，SSL证书的信用链体系并不安全，特别是在某些国家可以控制CA根证书的情况下，中间人攻击一样可行。

HTTP与HTTPS有什么区别？

HTTPS和HTTP的区别主要如下：
　　1、https协议需要到ca申请证书，一般免费证书较少，因而需要一定费用。
　　2、http是超文本传输协议，信息是明文传输，https则是具有安全性的ssl加密传输协议。
　　3、http和https使用的是完全不同的连接方式，用的端口也不一样，前者是80，后者是443。
　　4、http的连接很简单，是无状态的；HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，比http协议安全。