前言
上次说到 HTTP基础 概念相关的问题，这次非常简单的讲解一道超高频率的面试题。
在浏览器输入
url到页面展示的过程 ,我主要从网络相关的层面去讲一下。
当你输入了 www.baidu.com 到页面显示出来一共发生了什么？
解析url
首先这个过程肯定是需要涉及到 「 客户端跟服务端的数据传输 」 的，数据传输的前提就是 「 双方建立连接 」 ，那么这个建立连接的过程是如何建立的呢？
当你敲上网址然后敲了回车之后，浏览器就会开始解析这个域名了，其实解析域名最主要的就是 「 把
url网址解析成对应的服务器的IP地址 」 ，而解析成地址的方式有很多种，这里从最外层的浏览器一直到路由器再到dns服务器都有。具体流程的话有：
- 检查浏览器缓存中是否缓存过该域名对应的IP地址
- 查看host文件有没有跟域名对应的规则（本地主机host文件中一般会存储经常访问的url到host文件中）。
- 查看路由器里面有没有缓存。
- 最后才发出DNS请求到本地DNS(域名分布系统)服务器 。本地DNS服务器一般都是你的网络接入服务器商提供，比如中国电信，中国移动。
建立tcp连接
为什么要建立tcp连接呢？主要就是为了保证两端能够进行 「 可靠的传输 」 ，可靠的传输的基本，就是两端对数据的发送和接收的功能。
ssl / tls 证书
ssl / tls 是什么？大白话来说一下，在我们中国，身份证就是我们个人的专属身份的标志，同理，在网络中，为了确定连接那头的人是不是你要找的人，就会有一个大型的网上认证系统，ssl / tls 其实就是每个人自己服务器的
身份证， 确认了建立连接对面的人是你要的那个人，就是通过 ssl / tls 这个证书来确认的。
所以由于http的 「 明文传输 」 ，导致了一次普通的没有
身份证的http的调用其实是不不够安全的，有可能会被恶意修改数据或者是截取信息，这个时候https来了，它主要就是通过 ssl / tls 提供验证服务端的身份，加密处理数据等等，只要服务端提前在ca机构注册好自己的身份证， 就可以做到保证两端身份的确定性，就进行可靠安全的传输了。这里的话不细讲具体是如何加密的，简单说一下流程。
- 客户端向服务端请求连接，请求头里面包含了客户端支持的加密解密类型等等。
- 服务端根据客户端可接受的加密类型中，选择最合适自己的那一个，加密自己的私钥，并且存在证书里面，连同 「 证书 」 一起发给客户端。
- 客户端收到证书之后，首先向权威 「 ca机构 」 验证证书的有效性，确认了服务端的身份后，将自己用来对称加密的公钥用证书返回的公钥加密，发送给服务端。
总的来说，就是确定了双方同时持有对称加密使用的公钥，就可以安全的进行传输了。
这里补充一下，假如服务端申请了客户端未信任的证书机构的话（也有可能自己制作ssl证书），客户端需要信任（或者直接拒绝访问了），而且自制的ssl证书容易被伪造的，不咋安全（毕竟没收到国际认证和电子签发许可），所以这也是一种可能被钓鱼的情况之一。
三次握手
三次握手的主要目的，就是确定 「 双方同时具备正常的收和发功能 」 的功能，需要站在客户端和服务端的角度来看这个为什么需要三次握手的问题，接下来说一下流程：
- 客户端发送连接请求 「 你好服务器兄弟听得到吗 」 给服务端，服务端收到。
「 服务端的角度 」
服务端的角度：我服务端收到了客户端的消息，所以服务端是知道客户端的发是正常的，服务端自己的收也是正常的。
| 客户端 | 服务端 | |
|---|---|---|
| 收 | X | 正常 |
| 发 | 正常 | X |
「 客户端的角度 」
客户端的角度：不清楚自己发出去的服务端收到没，也不清楚自己能不能收到服务端的消息。
| 客户端 | 服务端 | |
|---|---|---|
| 收 | X | X |
| 发 | X | X |
- 服务端发送 「 听得到啊，客户端兄弟听得到吗 」 给客户端，客户端收到了。
「 服务端的角度 」
服务端的角度:是只能确认自己的收是正常的，但是不确定客户端有没有收到自己发出去的东西。
| 客户端 | 服务端 | |
|---|---|---|
| 收 | X | 正常 |
| 发 | 正常 | X |
「 客户端的角度 」
客户端的角度:客户端是已经可以确认，客户端的收发的功能都是正常的，服务端的收发功能也是正常的。（此时客户端的角度已经确认好了）。
| 客户端 | 服务端 | |
|---|---|---|
| 收 | 正常 | 正常 |
| 发 | 正常 | 正常 |
- 客户端发送 「 我也听得到 」 给服务端。
这个时候服务端才知道，客户端收到了，所以就确认了自己可以发数据给客户端。（此时服务端的角度也确认好了）。 总的来说，照着 「 确定双方同时具备收和发的功能 」 这个思路说下去，三次握手就很好理解了。
「 服务端的角度 」
| 客户端 | 服务端 | |
|---|---|---|
| 收 | 正常 | 正常 |
| 发 | 正常 | 正常 |
「 客户端的角度 」
| 客户端 | 服务端 | |
|---|---|---|
| 收 | 正常 | 正常 |
| 发 | 正常 | 正常 |
数据传输。
连接建立后自然就是发送数据了，这时候客户端也就可以发送请求给服务端了，服务端收到对应的请求，（可能有代理）找到自己的对应的服务对应的端口去做相应的处理，并反回数据给客户端（tcp的拥塞机制）。
四次挥手
四次挥手 「 连接终止协议 」 ，这个很好理解，主要就是确认双方都没有数据发送了。
为什么要四次挥手? 主要就是因为上面说到的三次握手，建立的连接是去确定双方同时具备收和发的功能来建立的一个通道，那么关闭这个通道肯定也是要双方去确认的，所以我们可以按照这个思路往下去整理。
- 当客户端发起所有需要的请求后，决定关闭连接了，他向服务器发送了一个 「 我已经没啥要的了 」 。
- 服务器收到后，要给客户端返回一个 「 收到 」。
其实这样的话是存在服务器数据还没发完数据的情况的，所以上面的两次挥手的主要作用只是断开了客户端的发，但服务器还是可以继续传输没传输完的数据。
- 当服务器发送完所有之后，决定关闭连接了，他向客户端发送了一个 「 我也把东西都发完给你了 」。
- 完了客户端也要回复一个 「 收到 」。
到此四次挥手就结束了，这里补充一张四次挥手的图给大家参悟一下。
最后
关于https相关流程可以看看 HTTPS原理及流程。
PS
都结合网上资料加上自己的一些理解，如果有影响到人的地方，可以联系我：[email protected]