浏览器输入网址后，首先解析URL，解析出协议（http或https）、服务器域名、路径等信息。
接下来要获取服务器的IP地址，这就轮到DNS干活了。浏览器先看自己的DNS缓存有没有这个域名，没有就去问操作系统，操作系统也没有就查hosts文件，都没找到才向本地DNS服务器发起请求。本地DNS服务器如果也没有缓存，它会去问根服务器，根服务器告诉它找.com顶级服务器，.com服务器告诉它找example.com的权威服务器，权威服务器把真正的IP地址返回给本地DNS，本地DNS再返回给浏览器。
拿到IP之后，浏览器开始和服务器建立TCP连接，也就是三次握手。第一次客户端发SYN，第二次服务器回SYN+ACK，第三次客户端发ACK。三次握手的目的一是确认双方都有发送和接收的能力，二是同步双方的初始序列号，为后面的可靠传输做准备。
如果是HTTPS协议，TCP建立之后还要进行TLS握手，验证证书、协商加密密钥，确保通信安全。
然后开始发送HTTP请求。请求数据从应用层往下传，TCP层加上源端口和目的端口，IP层加上源IP和目标IP，数据链路层加上源MAC和目的MAC。如果目标IP在同一个局域网就直接找目标，ARP（通过广播，寻找局域网ip对应的mac地址）获取下一跳的MAC地址。否则找网关路由器的MAC地址。
封装好的数据包交给网卡，网卡在前面加上起始帧分界符，末尾加上FCS校验，然后转成电信号发出去。
数据包先到交换机，交换机根据目的MAC地址查自己的MAC地址表，找到对应端口就转发出去，找不到就广播。经过交换机后到达路由器，路由器剥掉MAC头，根据目标IP查路由表，确定下一跳，重新封装MAC头再发出去，这样一跳一跳最终到达目标服务器所在的网络。
服务器收到数据包后开始层层扒皮：先检查MAC地址是不是自己的，是就剥掉MAC头；再检查IP地址，是就剥掉IP头交给TCP；TCP检查端口号，把数据重组后交给HTTP应用。服务器知道客户端想看哪个页面，就准备好内容，再按照同样的方式一层层封装回去，把响应数据发回给客户端。
客户端收到响应后，浏览器开始渲染：解析HTML构建DOM树，解析CSS构建CSSOM树，合并成渲染树，然后布局计算每个元素的位置，最后绘制到屏幕上。如果页面里有图片、CSS文件、JS文件，浏览器还会继续请求这些资源。全部加载完成后，页面就显示出来了。
页面显示后，如果连接不再使用，会通过四次挥手断开TCP连接。
网卡---交换机-----路由器-----路由器2-----路由器3..........公网.............路由器---交换机----目标网卡
TLS密钥协商
HTTPS的整套认证体系，最终归结为“我凭什么信任这把公钥是真的？”
答案就是：因为它在我的操作系统出厂时就已经存在，而我相信我的操作系统厂商和那些CA机构经过了足够严格的审核。可以理解为：我们把对物理世界的信任（对微软/Apple/Google等商业实体的信任）投射到了数字世界。只要这个初始条件成立，后面的密码学运算就牢不可破。这就是你所说的“基础”。
HTTPS最终方案：非对称加密 + 对称加密 + 证书认证
在客户端和服务器刚一建立连接的时候, 服务器给客户端返回一个 证书，证书包含了之前服务端的公钥, 也包含了网站的身份信息.
客户端进行认证
client第一次请求，得到返回结果，不仅仅得到了公钥，实际上client得到的是一个”证书“，CA机构签发的证书。
客户端获取到这个证书之后, 会对证书进行校验(防止证书是伪造的).
- 判定证书的有效期是否过期
- 判定证书的发布机构是否受信任(操作系统中已内置的受信任的证书发布机构).
- 验证证书是否被篡改: 从操作系统中拿到该证书发布机构的公钥, 对服务器返回证书中的签名解密, 得到一个hash 值(称为数据摘要), 设为 hash1. 然后计算整个证书（服务返回的证书）的 hash 值, 设为 hash2. 对比 hash1 和 hash2 是否相等. 如果相等, 则说明证书是没有被篡改过的
注意：
在验证证书是否被篡改这一步，从操作系统中拿到的公钥，绝不是从返回的证书里面取出的网站公钥，而是CA（证书颁发机构）的公钥。
我把这两把完全不同的公钥做一个对比，你就清楚了：
公钥来源 在哪个证书里 谁持有对应的私钥 在本步骤中的用途 CA的公钥 操作系统内置的根证书里 CA机构自己 用来解密网站证书上的数字签名，从而得到 hash1网站的公钥 网站返回的站点证书里 网站服务器持有 后续建立TLS加密会话时用于协商密钥，不是用来验证签名的
常见问题：
中间人有没有可能篡改该证书？
由于中间人没有 CA 机构的私钥，所以无法 hash 之后用私钥加密形成签名，那么也就没法办法对篡改后的证书形成匹配的签名，这个世界上只有CA机构有私钥，也就意味着，只有CA机构才有对数据进行签名的能力！
中间人整个掉包证书？
- 因为中间人没有 CA 私钥，所以无法制作假的证书
- 所以中间人只能向 CA 申请真证书，然后用自己申请的证书进行掉包
- 这个确实能做到证书的整体掉包，但是别忘记，证书明文中包含了域名等服务端认证信息，如果整体掉包，客户端依旧能够识别出来。
- 永远记住：中间人没有 CA 私钥，所以对任何证书都无法进行合法修改，包括自己的
为什么签名不直接加密，而是要先 hash 形成摘要?
缩⼩签名密文的⻓度,加快数字签名的验证签名的运算速度
HTTPS通信的完整流程：
总结 HTTPS 工作过程中涉及到的密钥有三组：
- 第一组(非对称加密): 用于校验证书是否被篡改. 服务器持有私钥(私钥在形成 CSR 文件与申请证书时获得), 客户端持有公钥(操作系统包含了可信任的 CA 认证机构有哪些, 同时持有对应的公钥). 服务器在客户端请求时，返回携带签名的证书. 客户端通过这个公钥进行证书验证, 保证证书的合法性，进一步保证证书中携带的服务端公钥权威性。
- 第二组(非对称加密): 用于协商生成对称加密的密钥. 客户端用收到的 CA 证书中的公钥(是可被信任的)给随机生成的对称加密的密钥加密, 传输给服务器, 服务器通过私钥解密获取到对称加密密钥.
- 第三组(对称加密): 客户端和服务器后续传输的数据都通过这个对称密钥加密解密.
其实一切的关键都是围绕这个对称加密的密钥. 其他的机制都是辅助这个密钥工作的！
