NAT 协议详解（网络层）
IPv4 地址不够分，NAT 让一整个内网共享少量公网地址对外通信：出向改写源地址和端口（SNAT/NAPT），回程再按转换表改回来。它缓解了地址枯竭，也天然打破了端到端直连，催生出打洞、ALG 等一系列补偿手段。 私有地址存在的意义：IPv4 枯竭IPv4 只有约 43 亿个地址，远不够全球设备人手一个。于是标准划出三段私有地址——10.0.0.0/8、172.16.0.0/12、192.168.0.0/16——任何人都可以在内网自由使用，公网路由器见到这些地址直接丢弃。私有地址在不同内网之间可以重复，这正是省地址的关键：全世界的家庭网络都在用 192.168.1.x，互不冲突。 但私有地址出不了门。内网主机要访问公网，必须有人在边界把私有地址换成公网地址，这个角色通常由路由器承担，干的就是 NAT（Network Address Translation）。 SNAT/DNAT 与端口映射（NAPT）按改写方向分两类： SNAT（源地址转换）：内网主动出访时，把报文的源 IP（和端口）改成公网地址，是最常见的形态。 DNAT（目的地址转换）：把发向公网...
HTTPS 握手里的 RSA 和 ECDHE，到底差在哪？（应用层）
HTTPS 并不等于”RSA 加密”。TLS 握手的核心任务是协商出一把对称会话密钥，而 RSA 与 ECDHE 是两条截然不同的协商路径：前者把密钥材料加密后”寄”给服务器，后者让双方各自在本地”算”出同一份秘密。这个差别决定了前向安全性的有无，也解释了 TLS 1.3 为什么把静态 RSA 密钥交换彻底移除。 它解决什么问题TLS 握手要同时回答两个问题。一是密钥怎么来：握手结束后业务数据用 AES-GCM 这类对称算法保护，双方必须先安全地得到同一把会话密钥。二是身份怎么证：客户端要确认对端真的是目标服务器，而不是中间人塞过来的假公钥——这靠证书与 CA 信任链解决。 RSA 与 ECDHE 在身份认证上做法一致（都用证书签名），分歧集中在第一个问题上：会话密钥的材料，到底是”一方生成、加密传输”，还是”双方协商、各自计算”。 核心原理RSA 握手：客户端生成，加密传输TLS 1.2 的静态 RSA 握手流程： Client Server | ---------- ClientHello -...
HTTP 1.0 vs HTTP 1.1：长连接、缓存、Host 头等核心差异（应用层）
HTTP/1.0 与 1.1 只差一个小版本号，工程体验却天差地别：前者每个请求都要重建 TCP 连接，后者默认复用连接，还补上了 Host 头、精细化缓存、范围请求等一整套现代 Web 的地基。理解这组差异，也就理解了 HTTP/2 后来要解决什么。 核心差异一：短连接 vs 长连接HTTP/1.0 默认短连接：一次请求对应一次 TCP 连接，响应到手就断开。一个含十几张图的页面就要十几次握手挥手，开销全耗在建连上。1.0 也提供了 Connection: Keep-Alive 请求头作为显式选项，但需要双方协商。 HTTP/1.1 把长连接（Keep-Alive）变成默认行为：TCP 连接建立后保持打开，后续请求直接复用，服务器靠空闲超时回收。想恢复短连接行为，显式发 Connection: close 即可。注意两点：HTTP 层的长连接本质是复用 TCP 连接，和 TCP 自身的 Keepalive 保活探测是两码事；长连接也不是永久连接，超时不用照样关闭。 核心差异二：管线化为什么失败连接复用之后，1.1 还尝试过管线化（Pi...
有了 HTTP 协议，为什么还要 RPC？HTTP 与 RPC 区别对比
HTTP 与 RPC 经常被放在一起比较，但它们不是同一层的概念：HTTP 是应用层传输协议，规定报文怎么写；RPC 是一种”远程方法调用”的语义抽象，规定调用怎么组织。一个 RPC 框架完全可以用 HTTP/2 当传输层——gRPC 就是这么做的。本文从两者各自解决的问题出发，讲清差异落在哪里，以及微服务选型怎么选。 它解决什么问题假设服务 A 要调用服务 B 的”查询用户”功能。最原始的办法是自己拿 TCP 写：建立连接、把方法名和参数拼成字节流发出去、解析返回。但 TCP 只保证字节可靠到达，不管消息边界——连发两次请求，对端收到的可能是一段粘连的字节流，拆包、编码、超时、错误码全要自己处理。 HTTP 解决的是”报文格式”问题：请求行、Header、Body、状态码，一套通用格式让所有语言、所有中间设备都能看懂。用 HTTP 完成远程调用完全可行，写一个 GET /users/1001 就能拿到数据。 RPC 解决的是更高一层的”调用体验”问题：让跨进程的调用在代码里看起来和本地方法调用一样。业务方写的是 userService.getUser(1001)，...
HTTP vs HTTPS：区别在哪里、HTTPS 为什么更安全（应用层）
HTTP 是明文协议，链路上任何中间节点都能看到完整报文，由此产生窃听、篡改、冒充三类风险。HTTPS 通过在 HTTP 之下加入 TLS（Transport Layer Security，传输层安全协议），用混合加密和数字证书逐一补上这些短板。本文按”风险、设计、握手、对比、实践”的顺序展开。 HTTP 的三个风险HTTP 报文以明文跑在 TCP 上，链路上的任何一环——同网段的攻击者、被入侵的路由器、不可信的代理——都能看到并改写内容。具体对应三类风险： 窃听：公共 Wi-Fi 下，攻击者抓包即可读到账号密码和 Cookie，进而劫持整个会话。 篡改：中间节点可以改写响应内容。运营商在网页里插入广告脚本就是典型案例——服务器返回的是干净页面，用户看到的却多了弹窗。 冒充：DNS 劫持可以把用户引向伪造服务器，而 HTTP 没有身份验证机制，客户端无从分辨对端真假。 三者分别对应机密性（Confidentiality）、完整性（Integrity）、身份认证（Authentication），HTTPS 的设计目标就是补齐这三块短板。 HTTPS 的核心设计HTTPS 不...
DNS 域名系统详解（应用层）
DNS 是把域名翻译成 IP 地址的应用层协议，本质是一个分层、分布式的数据库。理解它要抓住三件事：谁来回答（根、顶级域、权威、本地递归解析器）、怎么问（递归与迭代）、以及答案长什么样（各类资源记录）。 为什么不能只有一本集中的电话簿早期互联网确实用一份集中维护的 hosts 文件做域名映射，但主机数量爆炸之后，集中式方案在更新分发、负载和一致性上全部失效。DNS 的解法是分层加委托：把名字空间按点号切成层级，每层只负责给出下一层的指路信息，具体记录分散在各级权威服务器上，任何单点都不必存全量数据，还能水平扩展。 真正发起 DNS 网络查询之前，其实还有几级本地缓存：浏览器缓存、操作系统缓存、hosts 文件。全部未命中，才轮到下面的解析链路。 域名层级与四类服务器角色以 www.example.com. 为例（末尾的点代表根，书写时通常省略），从右往左依次是根、顶级域 com、二级域 example.com，对应四类角色： 根服务器：只知道各顶级域服务器在哪里。逻辑上有 13 个命名标识（a 到 m），但每个标识通过任播（Anycast）在全球部署了大量物理实例，”全球只...
《计算机网络》（谢希仁）内容总结
计算机网络教材内容庞杂，本篇按五层体系（物理、数据链路、网络、传输、应用）重组核心知识点：每层给出关键概念清单与一句话要点，形成一份可速查的知识地图，适合期末复习与面试巩固。 概述：先统全局 互联网的构成：互联网是「网络的网络」，分边缘部分（主机，跑 C/S 或 P2P 进程）与核心部分（路由器，负责分组交换）。分组交换采用存储转发：报文切成带首部的分组，每个分组独立选路。 性能指标别混淆：带宽是链路能力上限，吞吐量是实际测得的速率；时延由发送、传播、处理、排队四部分组成——高带宽不等于低时延。 一句话要点：分组交换与分层体系是整个互联网的两大设计基石。 物理层关键概念：单工、半双工、全双工三种通信方式；奈氏准则给出无噪声信道的码元速率上限，香农定理给出有噪声信道的信息速率上限；基带信号与带通调制；信道复用有频分 FDM、时分 TDM、统计时分 STDM、码分 CDM、波分 WDM（光的频分）。 一句话要点：物理层只负责在传输媒体上透明地传送比特流，把媒体与通信手段的差异屏蔽掉，让链路层不必关心底下是双绞线还是光纤。 数据链路层关键概念：三大基本问题——封装成帧、...
TCP 和 UDP 可以使用同一个端口吗？
可以。TCP 和 UDP 各自维护一套独立的端口空间，同一个数字端口在两种协议下是完全不同的绑定对象——TCP/53 和 UDP/53 可以同时存在、互不干扰，DNS 服务正是这么做的。 问题的本质：端口空间按协议独立端口号是传输层用来定位主机上具体应用的编号，TCP 和 UDP 首部中的端口字段都是 16 位，取值范围都是 0~65535。数字范围相同，不等于命名空间相同。 关键在于内核的分发顺序。报文到达网卡后，内核先看 IP 首部的协议字段（IPv4 的 Protocol，IPv6 的 Next Header）：值为 6 交给 TCP 协议栈，值为 17 交给 UDP 协议栈。先按协议分流，再在各自的协议栈内按端口查找 socket。所以 TCP/8080 与 UDP/8080 在内核看来是两条完全不同的路径，谈不上冲突。 IP 报文到达 ├─ Protocol = 6 → TCP 栈 → 按 (TCP, 本地IP, 端口) 找 socket └─ Protocol = 17 → UDP 栈 → 按 (UDP, 本地IP, 端口) 找 socket 用 sock...
能 Ping 通，TCP 就一定能连通吗？
不一定。ping 走的是 ICMP，工作在网络层，只证明”IP 可达、ICMP 未被拦”；TCP 连通还要求目标端口有服务监听、三次握手双向畅通、链路上的防火墙与安全组放行对应端口。两者命中的根本不是同一套规则。 问题的本质：ICMP 通不代表端口通ping 发送的是 ICMP Echo Request，收到 Echo Reply 就算通。它没有端口概念，也不关心对端是否跑着任何服务。更微妙的是，目标前面若有负载均衡、NAT 或 Anycast 节点，ICMP 应答甚至可能来自中间设备，而非后端真实主机。 TCP 连通的条件苛刻得多：客户端发出 SYN 后，要收到 SYN-ACK 并回 ACK，三次握手全部完成才算建立；中间的防火墙、安全组、负载均衡还需逐跳放行这个 IP:端口。任何一环丢掉 SYN，连接就建立不起来。反过来也成立：很多云主机默认禁 ICMP，ping 不通但业务端口照常工作。 TCP 连不上的常见原因清单从客户端视角按可能性梳理： 防火墙/安全组按端口过滤：ICMP 常被运维放行，TCP 端口却按需开放。静默丢包表现为超时，主动拒绝表现为 RST...
ARP 协议详解（网络层）
以太网里真正搬运数据帧的是 MAC 地址，而应用层只知道 IP。ARP 的任务就是在本地广播域里把”下一跳的 IP”翻译成”下一跳的 MAC”，靠广播问询、单播应答完成，结果缓存在 ARP 表里复用。 为什么需要地址解析：IP 与 MAC 的分工IP 地址是逻辑地址，负责跨网络的全局寻址，随设备接入位置而变化；MAC 地址是链路层地址，标识网卡接口，只在当前链路（广播域）内有意义。发送一个 IP 数据报时，网络层只关心”目的 IP 是谁”，但链路层封装帧时必须填上”下一跳的 MAC”——这个空缺就由 ARP 来补。 关键点是：ARP 解析的永远是下一跳，不是最终目的地。查路由表后发现目标同网段，就解析目标主机的 MAC；目标在外网，就解析默认网关的 MAC。之后每一跳路由器重新查表、重新封装链路层头部，MAC 逐跳改写，IP 全程不变。 请求与响应流程：广播问询，单播应答以主机 A（192.168.1.10）要给同网段主机 B（192.168.1.20）发包、且缓存未命中为例： A -- ARP Request(广播帧, 目的MAC=FF:FF:FF:FF:FF:FF) --...