一、 密码学演进从对称到非对称再到证书体系要理解为什么现在的网络是安全的我们得先看看加密技术是如何一步步进化的。1.1 对称加密高效但面临“分发难题”原理加密和解密使用同一把密钥。优点算法简单计算速度极快适合加密大量业务数据。致命缺点密钥分发问题。通信双方如果从未见过面如何把密钥安全地交给对方如果在网络上明文传输密钥一旦被截获后续所有的加密都形同虚设。1.2 非对称加密解决分发但引入性能与安全问题原理一对密钥——公钥公开和私钥保密。用公钥加密只能用私钥解密反之亦然。优点不需要传输私钥完美解决了对称加密的密钥分发问题。缺点性能极差非对称加密的计算复杂度极高如果用来传输大量数据系统会不堪重负。无法抵御中间人攻击MITM这是很多人容易忽略的一点。1.3 中间人攻击Man-in-the-Middle Attack即使你用了非对称加密如果没做身份验证黑客依然可以轻松窃听。流程如下1.4 数字证书与 CA建立信任链为了证明“公钥”确实属于“真实的服务器”数字证书和CA证书颁发机构​ 登场了。证书内容包含服务器域名、服务器公钥、颁发者信息、有效期等。签名机制CA 机构会用哈希算法对证书内容生成摘要校验和再用 CA 自己的私钥加密这个摘要形成数字签名。验证过程客户端浏览器/操作系统内置了受信任 CA 的公钥。收到证书后客户端用 CA 公钥解密签名得到摘要再自己算一份摘要进行比对。一致则说明证书未被篡改且公钥确实属于该服务器。1.5 对称与非对称的结合TLS 握手实际中的 HTTPS 结合了两者优点这也就是SSL/TLS 握手​ 的核心逻辑二、 Fiddler 抓包原理合法的中间人理解了上面的加密和证书就能秒懂Fiddler​ 的工作原理。工作模式Fiddler 本质上是一个代理服务器充当客户端和服务器之间的“媒人”。解密 HTTPS为了抓取 HTTPS 流量Fiddler 会在本地生成一张伪造的服务器证书并用 Fiddler 自己的根证书需要用户手动安装并信任进行签名。结果因为你的系统信任了 Fiddler 的根证书所以客户端会信任这张伪造证书从而允许 Fiddler 完成上述的密钥协商、解密数据。这也是为什么在手机或浏览器上不安装证书就无法抓 HTTPS 包的原因。三、 HTTP 状态码速查表在排查接口问题时熟练记忆状态码能极大提升效率。以下是你提到的核心状态码总结状态码状态短语含义详解常见场景200​OK成功。请求已正常处理并返回。接口调用成功。302​Found重定向。资源临时移动到新位置。未登录时访问需授权页面跳转到登录页。404​Not Found没找到。服务器找不到请求的资源。URL 拼写错误或资源已被删除。403​Forbidden没权限。服务器理解请求但拒绝执行。登录了但没有访问该接口的权限如普通用户访问管理员接口。405​Method Not Allowed方法不允许。请求行中的方法不被支持。接口只支持 POST你却用了 GET 请求。500​Internal Server Error服务器错误。服务器内部代码出错。后端代码抛异常、空指针等。504​Gateway Timeout网关超时。网关/代理未及时从上游获取响应。服务器处理请求时间过长或后端服务宕机。四、 UDP 协议深度解析HTTP 是文本协议而 UDP/TCP 是二进制协议。我们来深入看看 UDP 的底层细节。4.1 UDP 报头结构固定 8 字节UDP 极其简单只有 4 个字段每个字段 2 字节16 位4.2 64KB 的长度限制由于“长度”字段是16 位的2 的 16 次方 65536UDP 能传输的数据最大长度是64KB包含 8 字节首部。计算65535 bytes ≈ 64KB。注意如果应用层需要传输超过 64KB 的数据就必须在应用层手动分包、多次发送并在接收端拼装。这也是为什么 TFTP、DNS 等基于 UDP 的协议都有自己的一套分包/重传机制。4.3 比特翻转与 CRC 循环冗余校验在网络传输中数据以 0 和 1 的电/光信号传输受电磁干扰可能会出现比特翻转0 变 11 变 0。校验和的作用UDP 使用校验和来防止数据出错。发送方计算校验和并附带发送接收方收到后以同样算法重新计算并对比。如果不一致说明传输出错UDP 会直接丢弃该数据报。CRC循环冗余校验UDP 的校验和通常采用CRC 算法。它不是简单的求和而是把数据字节当作二进制多项式除以一个生成多项式将得到的余数作为校验值。检错能力CRC 特性极佳。如果只有一个 bit 位发生比特翻转100% 能够被检测出来。校验和的作用更多是“证伪”不对劲肯定错了而非绝对“证实”对劲不一定完全没错但概率极低。五、 TCP 协议深度解析如果说 UDP 是“莽夫”那么 TCP 就是“精密的管家”。TCP 通过复杂的机制保证了数据传输的可靠性、有序性和效率。5.1 TCP 报头结构结合图示TCP 报头包含以下核心字段16位源端口号 / 16位目的端口号标识发送和接收的应用程序。32位序号 / 32位确认序号用于可靠传输和按序重组详见后续机制。4位首部长度注意这里的单位是4个字节而非比特位。如果值为5代表首部长度确实是20字节。保留(6位)留作未来使用目前必须置0。标志位URG, ACK, PSH, RST, SYN, FIN控制连接状态和数据处理方式。16位窗口大小用于流量控制详见滑动窗口。16位校验和 / 16位紧急指针用于校验和紧急数据处理。选项可变长度用于扩展功能如窗口扩大因子。5.2 三次握手与连接状态为了建立可靠的连接TCP 需要三次握手客户端发送SYN包携带初始序号进入SYN_SENT状态。服务端收到后回复SYN ACK包进入SYN_RCVD状态。客户端收到后回复ACK包双方进入ESTABLISHED状态。注服务端在收到连接请求前处于LISTEN状态5.3 可靠传输机制确认应答与重传确认应答 (ACK)接收方收到数据后会返回 ACK确认号表示“我期望收到的下一个字节的序号”。超时重传如果发送方在规定时间内未收到 ACK判定为丢包会重新发送数据。快速重传如果发送方连续收到3个重复的 ACK说明某个报文段丢失了发送方会立即重传该报文而不必等待超时计时器到期大大提高了效率。5.4 滑动窗口与流量控制TCP 使用滑动窗口机制来实现流量控制避免发送过快导致接收方处理不过来。16位窗口大小接收方通过 ACK 报文中的该字段告知发送方自己接收缓冲区的剩余空间。选项拓展窗口大小由于 16 位最大只能表示 64KBTCP 在选项部分引入了窗口扩大因子Window Scale在三次握手时协商。实际窗口大小 窗口字段值 × (2 ^ 扩大因子)。窗口探测包当接收方缓冲区满时会将窗口大小置为 0发送方暂停。为了防止死锁接收方的窗口更新 ACK 丢失发送方会周期性发送1字节的窗口探测包触发接收方回复当前最新的窗口大小。5.5 拥塞控制除了流量控制TCP 还要防止网络中间节点拥堵。实际发送窗口 min(接收通告窗口, 拥塞窗口)。慢启动连接刚建立时拥塞窗口cwnd初始化为 1 个 MSS。每收到一个 ACK窗口指数增长翻倍直到达到慢启动阈值ssthresh。拥塞避免达到阈值后窗口转为线性增长每轮 RTT 加 1 个 MSS谨慎探测网络极限。快恢复触发快速重传后将 ssthresh 和 cwnd 设为当前窗口的一半直接进入拥塞避免阶段避免窗口彻底归零。超时处理如果发生超时重传严重拥塞ssthresh 减半cwnd 重置为 1重新进入慢启动。5.6 发送与接收缓冲区及发包原理TCP 是面向字节流的内核为维护连接分别设置了发送缓冲区和接收缓冲区。发包原理客户端发送数据时并非发一个等一个而是根据当前的拥塞窗口和流量控制窗口将发送缓冲区的数据尽量发出去。发到一定量达到窗口上限时就停止发送等待对方的 ACK 确认后再滑动窗口继续发送后续数据。5.7 四次挥手与连接状态断开连接需要四次挥手主动关闭方发送FIN进入FIN_WAIT_1。被动关闭方回复ACK进入CLOSE_WAIT状态此时可能还有数据要发。被动关闭方发完数据后发送FIN进入LAST_ACK。主动关闭方回复ACK进入TIME_WAIT状态。为什么 TIME_WAIT 状态需要等待 2MSL*MSL报文最大生存时间通常是 30 秒到 2 分钟。等待 2*MSL约 60 秒有两个原因保证最后的 ACK 能到达如果最后的 ACK 丢失服务端会重发 FIN客户端需要在该状态下重发 ACK。防止旧连接的包干扰新连接确保网络中属于旧连接的延迟报文段全部消散避免被误认为新连接的数据。六、 总结从应用层的 HTTP 状态码到传输层 UDP 的 64KB 限制与 CRC 校验再到 TCP 精密的三次握手、滑动窗口、拥塞控制与四次挥手状态机以及安全层的对称/非对称加密、证书与 Fiddler 抓包原理网络通信的每一层都在为可靠性、安全性和效率做权衡。希望这篇总结能帮你理清这些核心概念。如果你在实际抓包或开发中遇到具体问题欢迎留言讨论