1. 速记版第二篇先解决“背了不会答”的老毛病写第一篇计网八股速记的时候我把重点放在了分层模型、三次握手四次挥手、HTTP 报文结构这些“骨架题”上。那篇发出去之后后台收到最多的反馈不是“记不住”而是另一句话结论我能背面试官一追问我就散了。这个问题我太熟了因为我自己当年也是这样能把“TCP 是面向连接的、可靠的、基于字节流的传输层协议”背得滚瓜烂熟结果人家问一句“你这个可靠到底靠什么保证”我脑子里只剩一个词——确认重传然后就没词了。所以这篇计网八股速记的第二部分我想换个思路写。不再按“协议说明书”的顺序平铺而是按面试现场真实发生的追问链来组织从滑动窗口讲到拥塞控制从 HTTP 版本演进讲到缓存和跨域最后把“浏览器输入 URL 到页面出现”这条大主线串起来。每一块我都会给一个能直接说出口的结论句、一张自己手画的草图、一组关键参数再配一个能救场的真实场景。速记的核心从来不是口诀而是“结论 图 参数 场景”这套答题骨架口诀只是帮你把骨架串起来的钩子。这篇适合谁看准备校招和社招的同行、刚接触网络编程的后端同学、平时写业务接口但被问到“为什么这里要加 Connection: keep-alive”会愣一下的朋友还有那些做前端但总在跨域和 Cookie 上栽跟头的人。文中所有例子我都用了虚构代称不涉及任何真实项目信息你直接拿去对着改就行。下面进入正题先啃 TCP 可靠传输这块最硬的骨头。2. TCP 可靠传输窗口、确认、重传三件事拎清楚2.1 滑动窗口到底在“滑”什么很多人被问到滑动窗口第一反应是“为了提高效率不用等一个确认发一个包”这个答案对但只答了一半面试官接着问“那窗口大小谁说了算”很多人就卡住了。我的标准答法是发送方的可用窗口等于接收窗口 rwnd 和拥塞窗口 cwnd 里较小的那个rwnd 反映接收方的处理能力cwnd 反映网络当前的承载能力两者取小谁卡住就听谁的。这句话说出来基本就把这题的分拿到了。再往下展开滑动窗口在发送端其实维护的是四个指针位置的概念已发送已确认、已发送未确认、可发送未发送、还不能发送。窗口“滑”的本质是收到新的 ACK 之后左边界右移右边界跟着右移可发送区间整体往前推。这里有个特别容易被追问的细节——TCP 的确认是累积确认收到 ACK1001 意味着 1000 及之前的字节全部收到了而不是“我只收到了第 1001 个字节”。这个点说出来很加分因为它直接解释了后面“为什么三个重复 ACK 就能触发重传”。还有个小坑TCP 报文头里的窗口字段只有 16 位最大 65535 字节在长肥管道带宽大、时延高的链路里根本不够用。所以有了窗口缩放选项通过在三次握手时协商一个移位因子把窗口最大放大到 1GB 量级。面试时提一句“窗口缩放是在 SYN 阶段协商的握手之后不能改”对方基本会认为你不是纯背书。2.2 带宽时延积窗口开多大才算真的够这题是真的高频而且是真的能算出来。核心公式一句话要让一条链路跑满发送窗口至少要等于带宽时延积也就是带宽乘以往返时延。我一般现场这么算假设链路是 100 MbpsRTT 是 40 ms那么带宽时延积 100 × 10⁶ bit/s × 0.04 s 4 × 10⁶ bit折合 500 KB。也就是说在途数据必须能塞下 500 KB这条链路才可能被填满。再往下换算成报文段数量假设 MSS 是 1460 字节500 KB ÷ 1460 B ≈ 342 个报文段。这时候你就能顺理成章地解释为什么 16 位窗口字段最大 65535 字节约 44 个满 MSS 段在这种链路上会成为瓶颈为什么必须上窗口缩放。这一串算下来比干巴巴地说“窗口能提高吞吐量”有说服力太多。我建议把这个计算练到能脱口而出因为它是一个万能接口往哪个方向都能延伸往左延伸可以聊慢开始阶段窗口怎么涨、多久能涨到 BDP往右延伸可以聊 BBR 这类基于带宽和时延建模的拥塞控制思路往下延伸可以聊接收缓冲区和应用层读数据速度的关系——接收方应用如果不及时 read接收缓冲区满了就会通告零窗口发送方直接停摆。2.3 零窗口、糊涂窗口还有那个让人抓狂的 40ms零窗口这个点面试官很爱问因为它是“可靠性”和“性能”交汇的地方。当接收方缓冲区满了它会发一个窗口为 0 的 ACK发送方收到之后停止发送但不能就这么一直等下去因为万一那个“窗口更新”的报文丢了双方就死锁了。所以发送方会启动一个持续计时器定期发零窗口探测报文接收方收到后必须回一个带当前窗口值的 ACK这样就能把死锁打破。答到这里面试官通常会点头。糊涂窗口综合征是另一个经典。接收方每次只腾出几个字节就通告一个小窗口发送方就发一个 barely 满的小包头部开销占比极高链路效率极差。解决思路是两头配合接收方攒够一定空间比如半个缓冲区或者一个 MSS再通告窗口发送方这边就是 Nagle 算法——在已发送未确认的数据还没清空之前小包先攒着不发攒够一个 MSS 或者收到 ACK 再发。但 Nagle 算法和延迟确认凑到一起会出事这个坑我实打实踩过。延迟确认的意思是接收方收到数据后不马上回 ACK等 40ms 左右看看有没有数据要捎带回去。于是场景就变成发送方发了一个小包等着 ACK 才发下一个接收方拿着数据等着 40ms 再回 ACK。两边互相等一次交互硬生生多出 40ms。当年我在一个实时性要求比较高的接口上排查了很久最后用抓包才看出来是这么回事。解决办法有三条看你场景选一是业务层合并小包把多次小写入拼成一次 write二是对延迟敏感的长连接设置 TCP_NODELAY 关掉 Nagle三是别在应用层做“发一个字节等一个响应”的交互。这三条我在不同项目里都用过效果最稳的其实是第一条——大多数所谓的网络延迟问题本质是代码写得太碎。注意TCP_NODELAY 不是什么场景都能开。批量传输场景开了反而会增加小包数量加剧网络负担。判断标准很简单你的写入是不是“请求-响应”式的低延迟交互是就开不是就别动。2.4 可靠传输的速记口诀我自己编的口诀是“一窗两算三确认超时乱序分开治”。一窗指滑动窗口两算指 rwnd 和 cwnd 取小、BDP 算窗口三确认指累积确认、重复 ACK、选择性确认SACK。后半句是重传策略超时重传和快重传走的是两套参数调整逻辑千万别混在一起答。顺便把超时时间怎么定也说清楚这是很多人漏掉的加分项。RTO 不是拍脑袋定的而是根据 RTT 采样动态算的维护一个平滑往返时间 SRTT 和一个偏差 RTTVARRTO SRTT 4 × RTTVAR。而且有个 Karn 算法规定被重传过的报文段不能用它的 ACK 来更新 RTT 采样否则会算错。这一句话甩出去基本就说明你真看过实现不是只背了教材目录。3. 拥塞控制一条曲线串起四个阶段3.1 慢开始和拥塞避免的分界线在哪里拥塞控制这块我的建议是别背四个名词背一条曲线。横轴是时间或者轮次纵轴是 cwnd曲线先指数上升碰到阈值拐成线性丢包后掉下来然后再涨。你把这条曲线画出来四个阶段自然就出来了。慢开始的“慢”是相对的它其实是指数增长每收到一个 ACKcwnd 加一个 MSS效果是每个 RTT 翻一倍。初始值老教材写 1 个 MSS实际现代实现里初始窗口通常是 10 个 MSS 左右这个细节说出来挺能体现你读过 RFC 而不是只看了课本。指数增长不可能一直持续涨到慢开始阈值 ssthresh 就切换成拥塞避免每个 RTT 只加 1 个 MSS变成线性增长。这里有个新手最容易答错的点ssthresh 的初始值不是一个固定数字而是一个很大的值比如 65535 字节意义是“我一开始不知道网络能撑多少先设个很大的上限”。很多人以为是随便设的一问就露馅。3.2 快重传和快恢复三个重复 ACK 的分量超时和收到重复 ACK在 TCP 眼里是两种严重程度完全不同的事件。超时意味着情况很糟可能链路真的堵了所以反应要猛ssthresh 降到当前 cwnd 的一半cwnd 直接打回 1 个 MSS重新慢开始。这是“重置式”的保守反应。收到三个重复 ACK 则意味着后面的包都到了只有中间某一个丢了网络其实是通的。所以不用那么悲观走快重传立刻重发那个丢失的段不用等超时计时器。同时走快恢复ssthresh 同样降到 cwnd 的一半但 cwnd 不降到 1而是降到新的 ssthresh有的实现加 3 个 MSS因为那三个重复 ACK 说明有三个包已经离开了网络然后直接进入拥塞避免的线性增长。为什么是三个而不是两个我一般这么解释网络乱序是常态轻度乱序一般不会超过一两个包等三个重复 ACK 再动手是对乱序和真丢包的一个折中判断。这个解释比“教材就这么写的”强很多因为它讲的是设计动机。3.3 拿一组数字走一遍参数才记得住光看公式没用拿数字跑一遍考场上才不会算错。假设初始 cwnd 1 MSSssthresh 16 MSS。第 1 到第 4 个 RTTcwnd 依次是 1 → 2 → 4 → 8 → 16指数增长到 16 时到达 ssthresh切换拥塞避免。之后每个 RTT 加 117、18、19……假设涨到 24 的时候发生了超时那么新的 ssthresh 24 ÷ 2 12cwnd 重置为 1重新慢开始1 → 2 → 4 → 8 → 12到 12 就切拥塞避免因为已经到阈值了之后线性加 1。如果同样的位置不是超时而是收到三个重复 ACK那么 ssthresh 12cwnd 12快恢复下一轮直接 13、14……这个对比一摆出来两种情况的差异就非常直观了。面试时如果你能主动把这两种情况拿同一组数字对比一遍基本不用再解释什么叫“快恢复”。3.4 拥塞控制的速记表触发事件ssthresh 变化cwnd 变化后续阶段超时重传降为当前 cwnd 的一半重置为 1 个 MSS重新慢开始三个重复 ACK降为当前 cwnd 的一半降为新 ssthresh部分实现 3 MSS直接快恢复进入拥塞避免cwnd 达到 ssthresh不变继续增长但改为线性慢开始切拥塞避免再补一句现代演进很多面试官听到这儿会顺口问“现在 Linux 默认用什么算法”。答默认一般是 CUBIC它用三次函数代替线性增长在高带宽长时延链路上恢复更快另一条路线是 BBR不把丢包当拥塞信号而是建模带宽和最小 RTT在有一定丢包率的链路上表现更稳。这句话不用展开太深点到即止反而显得你知道边界在哪。4. HTTP 版本演进一条主线打通三道题4.1 HTTP/1.1 的三板斧和它绕不过去的队头阻塞HTTP/1.1 相比 1.0 主要改了三件事持久连接默认 keep-alive不用每个请求都握手、管道化可以连续发多个请求不用等响应、以及更完善的缓存控制头。前两个是性能优化第三个是可维护性优化答题时把这三个点摆出来结构就很清楚。但管道化在实践里几乎没人用原因就是队头阻塞虽然请求可以连着发但响应必须按顺序回第一个请求慢后面全堵着。所以浏览器实际的做法是给同一个域名开多个并发连接一般是 6 个左右用连接数硬扛。这就带来另一个副作用——每个连接都要单独握手、单独慢开始浪费。这里有个很实用的延伸域名分片。把静态资源分散到多个子域名上突破单域名 6 连接的限制。但这招在 HTTP/2 下反而变成负优化因为 HTTP/2 一个连接就能多路复用分片反而拆散了连接复用。这个“同一手段在不同协议版本下结论相反”的点讲出来特别有味道。4.2 HTTP/2 的二进制分帧把“排队”变成“标签”HTTP/2 最大的变化是把报文从文本改成二进制分帧一个请求被切成多个帧每个帧带上 stream id同一个连接上的多个 stream 交错传输接收端按 stream id 重新组装。这就是多路复用它解决的是 HTTP 层的队头阻塞不是 TCP 层的。这个区分一定要讲清楚。TCP 是字节流它保证有序交付一旦某个包在网络里丢了后面所有数据都得在内核缓冲区里等着哪怕这些数据属于完全不同的 stream。所以 HTTP/2 在丢包率高的网络下表现有时候还不如 HTTP/1.1 开六个连接。这是 HTTP/3 出现的直接动因答题链条就这么接上了。HTTP/2 还有两个常考点HPACK 头压缩用静态表和动态表把重复的头部字段压掉同时防止压缩侧信道攻击和服务端推送实际效果不好主流浏览器已经放弃支持。敢说“服务端推送基本被判死刑了”比背书上的优点列表更能体现你在跟进行业。4.3 HTTP/3 为什么干脆绕开 TCPHTTP/3 的答案一句话TCP 的有序字节流语义在多路复用场景下是负担所以干脆换到基于 UDP 的 QUIC 上把可靠性、加密、多路复用都做进用户态。具体好处列三条就够第一stream 之间真正独立一个 stream 丢包不影响其他 stream彻底解决传输层队头阻塞第二QUIC 把 TLS 1.3 集成在握手过程里首次连接 1-RTT会话恢复可以做到 0-RTT第三连接迁移用连接 ID 而不是四元组标识连接手机从 Wi-Fi 切到蜂窝网络时连接不用重建。代价也要说不然显得你只会夸QUIC 在用户态实现拥塞控制CPU 开销比内核 TCP 高部分网络设备对 UDP 的限制会影响连通性可观测性和排障工具链还不如 TCP 成熟。能把代价说清楚才算真懂。4.4 版本对比速记表维度HTTP/1.1HTTP/2HTTP/3传输层TCPTCPQUIC基于 UDP报文格式文本二进制分帧二进制分帧多路复用无靠多连接有同连接多 stream有stream 相互独立队头阻塞应用层存在应用层解决TCP 层仍在两层都解决头部压缩无HPACKQPACK握手开销TCP TLS 分开TCP TLS 分开集成可 0-RTT5. 缓存与跨域面试官最爱顺着追的两条线5.1 强缓存和协商缓存判定顺序别答反这题的标准答法是先给顺序再给细节先看强缓存命中就直接用本地副本不发请求强缓存没命中或者已过期再走协商缓存带验证字段去问服务端服务端说没变就返回 304 让客户端用本地副本变了就返回 200 和新内容。强缓存靠两个头Cache-Control 的 max-age相对时间优先级高和 Expires绝对时间受客户端时钟影响优先级低。这两个同时存在时以 Cache-Control 为准理由很实在——客户端时间可能不准相对时间更可靠。协商缓存靠两对字段ETag 配 If-None-MatchLast-Modified 配 If-Modified-Since。ETag 优先级更高因为它基于内容做标识能识别“文件修改时间没变但内容变了”这种 Last-Modified 识别不了的情况而且 Last-Modified 只精确到秒。这两个优先级问题的答案都是“后者更可靠”背后逻辑都是精度和准确性记住逻辑就不用死背。几个容易翻车的指令必须拎出来单独说no-cache 不是不缓存是“可以存但每次必须验证”等价于走协商缓存no-store 才是真的完全不存一般用于含敏感信息的响应must-revalidate 是说缓存过期后必须回源验证不能用过期副本凑合。我见过不少人把 no-cache 当成 no-store 用结果该省请求的地方一个没省该保密的地方反而落了盘。提示调试缓存问题最有效的手段是看响应头而不是猜。用 curl -I 直接看 Cache-Control、ETag、Age 这几个字段比在浏览器里反复刷新靠谱得多因为浏览器刷新行为本身就会影响缓存判定普通刷新会跳过强缓存。5.2 Cookie 的四个属性配一个真实事故Cookie 的考点集中在属性上我一般按“作用域、安全、发送时机”三类来讲。作用域是 Domain 和 Path决定了这个 Cookie 会跟着哪些请求发出去安全是 Secure只在加密通道发送和 HttpOnlyJS 读不到防 XSS 窃取发送时机是 SameSite取值 Strict、Lax、None。SameSite 这块必须重点讲因为我在这上面栽过跟头。有个项目做前后端分离登录接口返回 302 重定向前端用 fetch 发请求结果登录成功后立刻又变回未登录状态。排查了半天最后发现是 SameSiteLax 的问题跨站发起的 POST 请求默认不带 Cookie服务端拿不到会话自然认为你没登录。这类“看起来像后端 bug实际是浏览器策略”的问题靠读代码是读不出来的。解决办法有两条要么前后端约定接口返回 JSON由前端自己做路由跳转避开 302要么在确实需要跨站携带的场景下显式设置 SameSiteNone 并且必须同时加 Secure。两条我都用过前者更推荐因为它把跳转逻辑收归前端链路更可控。顺带把 Cookie、Session、Token 三者的关系一句话说清Cookie 是浏览器的存储和自动携带机制Session 是服务端保存的会话状态Token 是把状态编码后交给客户端保存的凭据。Cookie 是载体Session 和 Token 是两种不同的状态管理策略。这个表述能把这三者从“三个并列名词”变成“一个载体加两种策略”答题层次立刻不一样。5.3 CORS 预检把流程走一遍就忘不掉跨域的本质是浏览器的同源策略协议、域名、端口三者任一不同就算跨域。注意是浏览器在拦不是服务端在拦请求可能已经发到服务端并执行了只是响应被浏览器丢掉了。这个认知很关键因为它解释了为什么有些“跨域报错”但其实数据库已经写进去了。简单请求不触发预检条件是方法是 GET、HEAD、POST 之一Content-Type 限于三种表单类型没有自定义请求头。不满足这些条件就是非简单请求浏览器会先发一个 OPTIONS 预检带上 Access-Control-Request-Method 和 Access-Control-Request-Headers服务端要用对应的 Allow-Methods、Allow-Headers 回应再用 Max-Age 告诉浏览器这个预检结果能缓存多久免得每个请求都预检一次。最容易错的一个点需要携带 Cookie 时前端要设 withCredentials服务端的 Access-Control-Allow-Origin不能写星号必须写具体来源同时要加 Access-Control-Allow-Credentials: true。这个限制的原因是安全——星号配凭证等于谁都能带着你的身份发请求。6. 从输入 URL 到页面出现一条线串起所有考点6.1 六个阶段每个阶段都埋着追问这道题是计网的“总复习题”答得好能撑十分钟答不好三十秒就结束。我的答法是按阶段走每个阶段留一个钩子给面试官咬URL 解析与缓存检查 → DNS 解析 → 建立连接TCP 握手如果是加密站点还有 TLS 握手→ 发送请求与接收响应 → 浏览器解析渲染 → 连接释放或复用。每个阶段我都准备了一句展开DNS 阶段可以聊递归和迭代、聊 TTL 和预解析连接阶段可以聊握手为什么是三次不是两次、TLS 握手里对称和非对称怎么配合请求阶段可以聊缓存命中、聊 keep-alive 复用渲染阶段点到为止因为那是前端的战场说多了容易翻车。这里有个技巧主动说出“哪一步可以省略”。比如 DNS 有本地缓存就直接跳过、连接有复用就跳过握手、强缓存命中就跳过请求。主动讲优化路径比被动答流程更能体现工程思维。6.2 DNS 的递归与迭代别答混这题错的人特别多因为两个词都是“查询”很容易说反。我的记法是递归是客户端甩锅给本地 DNS迭代是本地 DNS 自己跑腿。具体说客户端把查询请求发给本地 DNS 服务器说“你帮我查到结果为止”这是递归查询客户端只发一次。本地 DNS 如果没有缓存就自己去问根服务器根说“你去问顶级域”本地 DNS 再问顶级域顶级域说“你去问权威服务器”最后问到结果。这一路上本地 DNS 发了好几次请求每次都被指路而不是直接给答案这就是迭代查询。一句话总结客户端递归服务端迭代。常见记录类型也顺手记一下A 是 IPv4 地址AAAA 是 IPv6 地址CNAME 是别名NS 是域名服务器MX 是邮件路由TXT 常用于域名验证。这个不用背全记住前四个够用。6.3 这道题的追问陷阱最常见的陷阱是“HTTPS 握手过程中非对称加密用在哪、对称加密用在哪”。答非对称加密只用来协商出对称密钥和验证身份真正的业务数据全部走对称加密。原因是非对称加密计算开销大不适合加密大量数据。第二个陷阱是“TLS 1.3 相比 1.2 快在哪”。答握手轮次从 2-RTT 降到 1-RTT会话恢复支持 0-RTT同时砍掉了一堆不安全的加密套件。这三个点足够。第三个陷阱是“连接释放为什么要有 TIME_WAIT”。标准答案是两条一是保证最后那个 ACK 能到达对端如果 ACK 丢了对端会重发 FIN这时候还能回 ACK二是让这条连接上的旧报文在网络中自然消亡避免它们串到后续使用相同四元组的新连接上。等待时长是 2 倍的报文最大生存时间也就是 2MSL。这两个作用一定要都说只说“等 2MSL”是拿不到分的。7. 面试现场的追问链拆解与自查手段7.1 追问链怎么接给你三条真实路径第一条链从“三次握手”出发 → “为什么不能两次” → “那四次挥手为什么不能三次” → “TIME_WAIT 有什么用” → “服务器上大量 TIME_WAIT 怎么办”。最后这一问是实战题答法分两层先判断是不是短连接太多改成连接池复用再看是不是主动关闭方设计不合理可以让客户端做主动关闭方把 TIME_WAIT 分散到量大但压力小的那一侧。注意不要一上来就答改内核参数那是最后手段而且改不好会出问题。第二条链从“HTTP 缓存”出发 → “ETag 和 Last-Modified 谁优先” → “为什么” → “强缓存期间服务端更新了文件怎么办”。最后这问的答案是文件名加哈希指纹也就是常说的内容指纹方案靠改 URL 来绕过缓存而不是靠缩短 max-age。第三条链从“TCP 粘包”出发 → “为什么会粘” → “怎么解” → “UDP 会不会粘”。标准答案TCP 是字节流没有消息边界所以会出现应用层看到的“粘”和“拆”解法是定义应用层协议边界定长、分隔符、长度字段三选一长度字段最通用UDP 是面向报文的一个包一个边界不存在粘包但会有丢包和乱序。7.2 自己动手验证比背十遍都管用我特别建议你把这些结论亲手验一遍验证过的知识是长在身上的背下来的知识是挂在墙上的。下面几条命令都是我常年在用的。看连接状态分布判断是不是短连接太多ss -s ss -tan state time-wait | wc -l看 HTTP 响应头判断缓存策略有没有生效curl -I https://example.com/static/app.js curl -s -o /dev/null -w %{http_code} %{time_total}\n https://example.com/api/ping抓包看握手和重传直观感受一下什么叫重复 ACKtcpdump -i eth0 -nn port 443 -c 30如果你用抓包工具过滤条件记这两个就够日常用tcp.port 443看流量tcp.analysis.flags直接筛出重传、重复 ACK、零窗口这些异常事件。我第一次看到连续三个重复 ACK 的时候那种“原来书上写的是这个样子”的感觉比看十页教材都深刻。服务端侧配置也建议自己改一遍比如连接复用和压缩keepalive_timeout 65; keepalive_requests 1000; gzip on; gzip_types text/css application/javascript application/json;改完用 curl 看响应头里有没有 Connection: keep-alive 或者 HTTP/2 的标识用浏览器开发者工具看同一个域名下的连接数变化。动手一次胜过背十遍这句话在计网上是真的成立。7.3 常见问题速查表现象最可能的原因第一步怎么查接口偶发多出 40ms 延迟Nagle 与延迟确认互相等待抓包看小包与 ACK 的时间差登录成功后又变未登录跨站请求 Cookie 被 SameSite 拦住看请求头里有没有带 Cookie改了文件浏览器还是旧的强缓存未过期或 CDN 未刷新curl 看 Cache-Control 与 Age跨域报错但数据已写入浏览器拦截响应请求已执行看服务端日志与预检响应头大量 TIME_WAIT 堆积短连接过多或主动关闭方设计不当ss 统计状态分布高丢包下 HTTP/2 反而更慢TCP 层队头阻塞对比同场景下连接数策略上传大文件经常断中间层超时或缓冲区限制查代理层超时配置与分片大小再补三个我自己的避坑心得。第一个不要在没抓包的情况下凭直觉改内核参数很多所谓“网络调优”最后调出的是更难排查的问题先把应用层的小包合并做好收益比调参数大得多。第二个跨域问题优先在开发环境用同源代理解决别一上来就上宽泛的响应头配置安全性会打折。第三个缓存策略上线前一定要在文件名里带内容指纹否则用户端会出现“一半新一半旧”的诡异状态排查成本极高。最后说说我自己的复习节奏可能对你有用。我不追求一次背完而是按“三遍法”走第一遍只求能画出图滑动窗口、拥塞曲线、HTTP 版本对比这三张图必须能默写第二遍给每张图配三句话的解释和一个数字第三遍拿真实问题去倒推比如看到一次线上慢请求逼自己用这套框架去定位是哪一层的问题。能把八股讲成排查问题的语言才算真的记住。这个系列后面我还想写一篇专门讲连接池和长连接治理的那块在实际项目里踩的坑最多等整理完再拿出来聊。