一、网页浏览的全过程（引出以下的计网）
-
在浏览器中输入指定网页的 URL。
-
浏览器通过 DNS 协议，获取域名对应的IP 地址。
-
浏览器根据 IP 地址和端口号，向目标服务器发起一个 TCP 连接请求。
-
浏览器在 TCP 连接上，向服务器发送一个 HTTP 请求报文，请求获取网页的内容。
-
服务器收到 HTTP 请求报文后，处理请求，并返回 HTTP 响应报文给浏览器。
-
浏览器收到 HTTP 响应报文后，解析响应体中的 HTML 代码，渲染网页的结构和样式，同时根据 HTML 中的其他资源的 URL（如图片、CSS、JS 等），再次发起 HTTP 请求，获取这些资源的内容，直到网页完全加载显示。
-
浏览器在不需要和服务器通信时，可以主动关闭 TCP 连接，或者等待服务器的关闭请求。
二、URL的组成
URL（Uniform Resource Locators），即统一资源定位器。网络上的所有资源都靠 URL 来定位，每一个文件就对应着一个 URL，就像是路径地址。理论上，文件资源和 URL 一一对应。实际上也有例外，比如某些 URL 指向的文件已经被重定位到另一个位置，这样就有多个 URL 指向同一个文件。
-
协议。URL 的前缀通常表示了该网址采用了何种应用层协议，通常有两种------HTTP 和 HTTPS。当然也有一些不太常见的前缀头，比如文件传输时用到的
ftp:。 -
域名。域名便是访问网址的通用名，这里也有可能是网址的 IP 地址，域名可以理解为 IP 地址的可读版本，毕竟绝大部分人都不会选择记住一个网址的 IP 地址。
-
端口。如果指明了访问网址的端口的话，端口会紧跟在域名后面，并用一个冒号隔开。
-
资源路径。域名（端口）后紧跟的就是资源路径，从第一个
/开始，表示从服务器上根目录开始进行索引到的文件路径，上图中要访问的文件就是服务器根目录下/path/to/myfile.html。早先的设计是该文件通常物理存储于服务器主机上，但现在随着网络技术的进步，该文件不一定会物理存储在服务器主机上，有可能存放在云上，而文件路径也有可能是虚拟的（遵循某种规则）。 -
参数。参数是浏览器在向服务器提交请求时，在 URL 中附带的参数。服务器解析请求时，会提取这些参数。参数采用键值对的形式
key=value，每一个键值对使用&隔开。参数的具体含义和请求操作的具体方法有关。 -
锚点。锚点顾名思义，是在要访问的页面上的一个锚。要访问的页面大部分都多于一页，如果指定了锚点，那么在客户端显示该网页是就会定位到锚点处，相当于一个小书签。值得一提的是，在 URL 中，锚点以
#开头，并且不会作为请求的一部分发送给服务端。
三、DNS
键入了 URL 之后，第一个重头戏登场------DNS 服务器解析。DNS（Domain Name System）域名系统，要解决的是 域名和 IP 地址的映射问题 。毕竟，域名只是一个网址便于记住的名字，而网址真正存在的地址其实是 IP 地址。
四、HTTP/ HTTPS
利用 DNS 拿到了目标主机的 IP 地址之后，浏览器便可以向目标 IP 地址发送 HTTP 报文，请求需要的资源了。在这里，根据目标网站的不同，请求报文可能是 HTTP 协议或安全性增强的 HTTPS 协议。
1、HTTP常见的状态码
1XX：信息性状态码
2XX：响应成功状态码
3XX：资源重定向状态码。301永久重定向【网站的网址更换了】、302临时重定向
4XX：客户端错误。401权限不足，403非法请求的直接拒绝，404请求的资源未找到
5XX：服务器错误。一般都是服务器（后端）代码有问题。
2、HTTPS怎么保证传输安全的（重点）
HTTPS 并不是一个全新的协议，而是在 HTTP 的基础上，通过 SSL 增加了一层加密协议，从而大大增加了 HTTP 协议的安全性。
HTTP：在建立完 TCP 连接（三次握手）之后，就直接开始传输数据了，这时候数据是明文传输的，这也是 HTTP 最不安全的地方。
HTTPS：浏览器在发送 HTTP 请求之前，先通过某种方式对其进行加密，然后再进行传输。服务器端收到数据之后，对其解密，读取真实内容，生成 HTTP 响应，同样对响应进行加密，然后传回给浏览器，浏览器收到数据之后，对其进行解密，得到真正的 HTTP 响应。这样就可以保证数据在传输过程中的安全性，无论是路由器还是运营商，都没有办法"窃听"你们的数据了。
即避免中间节点的窃听和修改。
怎么加密的呢？通过SSL协议，现在已经被继承为TLS。
在 TCP 协议中加入 TLS 之后，三次握手成功之后就不会再立刻开始传输数据了，而是紧接着开始 TLS 的建立过程，也被称为 TLS 握手。（涉及到对称、非对称密钥以及数字证书）
非对称加密是TLS握手的时候，安全的商量好这个对称密钥，防止密钥被其他人窃取
对称加密是 TLS 握手成功后，通信双方之间采用的数据加密方案。
用户手握两把密钥，一把称为公钥，一把称为私钥，其中公/私钥都可以用来加密/解密数据，其特点为：用公钥加密后的数据，只有用私钥才能将其解开；用私钥加密后的数据，只有用公钥才能将其解开！
具体过程
服务器会用非对称加密方案事先生成自己的一对密钥，公钥和私钥。当用户（浏览器）向服务器发送请求（建立TLS连接），服务器会把自己的公钥以及响应发送回用户，用户收到请求后，把自己的对称密钥通过服务器发送的公钥加密，并发送回服务器。服务器通过自己的私钥进行解密，这样就能拿到浏览器的对称密钥了。
如何保证浏览器收到的响应是服务器发的？通过数字证书与CA
数字证书是由证书权威机构（CA）颁发的一个用于证明身份的证书，当然其中还包含了该用户的公钥等信息。
例如还是以百度为例，假设百度需要给 www.baidu.com 这个域名申请一个数字证书，他需要在生成公钥/私钥后，将自身的信息（包括域名、公司名称、公钥信息等）发给某个证书权威机构（CA），让 CA 给自己颁发一个数字证书。
CA 需要验证百度的真实身份，并且他确实拥有 www.baidu.com 这个域名，一切都验证通过后，CA 才会给百度颁发这么一个数字证书。那么之后，不管是谁用浏览器访问 www.baidu.com 的时候，百度都会将刚才那个 CA 颁发的数字证书发送给用户，既可以用来自证身份，同时还顺便告诉了用户自己的公钥。
证书不能被伪造，不能被篡改。基于证书的指纹与签名。
-
签名，证明数字证书有效的关键信息。如果把数字证书类比成一张合同的话，我们知道合同需要老板签字才算有效，同样，数字证书是需要 CA 签名才算有效的，这里的一长串字符就是 CA 对该证书的"签名"了。
-
指纹。将整张证书经过哈希运算后得到的特征值。CA 作为权威机构，其本身也是有一对公钥/私钥的，它在颁发数字证书的时候，会用自己的私钥对证书的指纹进行加密，生成的这段加密数据，就是该证书的签名了！那么我们浏览器是如何验证证书的真伪呢？我们只需要使用 CA 的公钥对签名进行解密，看看得到的值是不是跟证书的指纹是一样的，这样就 OK 了，只要是一样，说明这个证书一定是 CA 颁发的。
浏览器的公钥哪来的？
我们的浏览器或操作系统已经内置了世界权威的 CA 的数字证书（证书里就包含了其公钥）
如果黑客通过直接将CA证书返回给用户，也不能获取用户的密钥，以上面百度举例：
百度的私钥是不会公布出来的，即黑客本身是无法解开【用户通过百度的公钥加密后的信息】，因为需要百度的私钥。
总结
HTTPS 的加密过程中其实既用到了非对称加密也用到了对称加密，其中握手过程使用的是非对称加密，主要目的是双方可以安全的协商一个统一的密钥，而真正的数据传输过程则使用的是对称加密，正是使用刚才商量的这个密钥。
使用对称密钥是因为效率高，尤其是在大数据量传输的时候，使用对称密钥可以快很多！
根据以下链接进行整理，如要观看完整版，可移步跳转，本人做笔记便于自己理解和查看。