浏览器输入网址后首先解析URL解析出协议http或https、服务器域名、路径等信息。接下来要获取服务器的IP地址这就轮到DNS干活了。浏览器先看自己的DNS缓存有没有这个域名没有就去问操作系统操作系统也没有就查hosts文件都没找到才向本地DNS服务器发起请求。本地DNS服务器如果也没有缓存它会去问根服务器根服务器告诉它找.com顶级服务器.com服务器告诉它找example.com的权威服务器权威服务器把真正的IP地址返回给本地DNS本地DNS再返回给浏览器。拿到IP之后浏览器开始和服务器建立TCP连接也就是三次握手。第一次客户端发SYN第二次服务器回SYNACK第三次客户端发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头交给TCPTCP检查端口号把数据重组后交给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 证书中的公钥(是可被信任的)给随机生成的对称加密的密钥加密, 传输给服务器, 服务器通过私钥解密获取到对称加密密钥.第三组(对称加密): 客户端和服务器后续传输的数据都通过这个对称密钥加密解密.其实一切的关键都是围绕这个对称加密的密钥. 其他的机制都是辅助这个密钥工作的