1.输入URL到页面渲染流程
在浏览器输入URL回车后，整体会经历DNS解析、网络请求、资源响应、页面解析、渲染展示一整套流程，具体过程如下：
首先进行DNS域名解析，将域名转化为服务器IP地址。浏览器会按照优先级依次查找缓存：先查浏览器缓存、系统缓存、路由器缓存，缓存无结果后，再查询本地hosts文件。若仍未匹配到对应IP，则向DNS服务器发起递归、迭代查询，最终获取目标服务器的IP地址。
拿到IP地址后，浏览器通过对应端口建立网络连接，HTTP默认80端口、HTTPS默认443端口。基于TCP协议经过三次握手建立可靠连接，随后浏览器组装HTTP请求报文，包含请求行、请求头、请求体等信息，通过网络层级依次经过传输层、网络层、数据链路层、物理层，发送至服务端。
服务端接收并解析请求，处理业务逻辑后返回响应报文，将HTML、静态资源等数据返回给浏览器，数据传输完成后通过四次挥手断开TCP连接。
浏览器接收HTML资源后，自上而下解析HTML结构，构建DOM树。解析过程中若遇到内嵌JS或外部JS文件，会暂停DOM构建，优先下载、执行JS代码，因为JS会修改DOM和样式，会造成渲染阻塞，因此业务中通常将JS放置在页面底部。
同时浏览器解析页面所有样式，包括内联样式、内部样式、外部样式表，生成CSSOM样式树。随后将DOM树与CSSOM树合并，生成渲染树，渲染树会过滤掉无需展示的节点，比如script、meta标签，以及display为none的隐藏节点。
渲染树构建完成后，进入页面渲染阶段。首先执行布局（回流），计算所有可见元素的精确位置和尺寸；随后执行绘制（重绘），将元素的颜色、图片、文字、阴影等样式渲染到屏幕；最后通过图层合成，完成页面最终展示。
此外，HTML解析过程中遇到图片、视频、音频等静态资源，浏览器会开启并行下载，同一域名下默认并行限制为4-6个，提升资源加载效率。
整个过程中会配合HTTP缓存机制优化加载性能。主要通过Cache-Control、Expires、ETag、Last-Modified四个字段控制。其中Expires是服务端绝对时间，存在本地时差问题，兼容性较差；Cache-Control为相对时间，优先级更高、使用更广。资源未过期时直接读取本地缓存；资源过期后，浏览器携带缓存标识向服务端校验：优先通过If-None-Match校验ETag，ETag不存在时则校验Last-Modified，文件未发生修改则返回304，浏览器继续复用本地缓存，否则返回最新资源完成更新。
2.TCP 三次握手
握手流程：
第一次（客户端→服务端：SYN=x）：客户端发起连接，携带 SYN 同步报文、随机序号 x，客户端变为SYN_SEND，等待应答。
第二次（服务端→客户端：ACK=x+1、SYN=y）：服务端收到 SYN，回复 ACK 确认客户端（确认号 x+1）；同时自身发起同步 SYN=y，合并成 SYN+ACK 报文，服务端进入SYN_RECV。
第三次（客户端→服务端：ACK=y+1）：客户端收到报文后回复 ACK 确认服务端，双方切换ESTABLISHED，连接正式建立。
为什么不能两次？
两次握手仅服务端确认客户端，无法校验客户端能否接收服务端报文。老旧滞留的过期 SYN 报文延迟抵达服务端，两次握手会直接建立无效连接，服务端持续等待数据、占用端口与内存资源；第三次握手可以让服务端确认客户端正常收到同步报文，丢弃无效老旧连接。
为什么不用四次？
服务端的 SYN 同步和 ACK 确认可以合并在同一个报文，三次就能双向验证收发能力，四次多余、浪费报文开销。
3.TCP 四次挥手
第一次（主动方 FIN）：主动关闭端发 FIN 报文，表示不再发送新数据，但还能接收剩余存量数据，进入FIN_WAIT1。
第二次（被动方 ACK）：被动端收到 FIN，回复 ACK 确认关闭请求，继续传输剩余未发完数据，主动方进入FIN_WAIT2。
第三次（被动方 FIN）：被动方数据全部发完，发送 FIN 报文告知对方己方不再发送数据，进入LAST_ACK。
第四次（主动方 ACK）：主动方收到 FIN 后回复 ACK，被动方收到 ACK 立刻断开；主动方等待一段时间无报文再释放连接，防止 ACK 丢包导致服务端重传 FIN。
拆分四次原因：ACK 应答和 FIN 不能合并，被动方收到关闭请求后，需要时间传输遗留数据，要等数据发送完毕才会发送 FIN，因此拆成两次报文。