波仔
🕸️ 第二章 Web特有的架构
📄 一句话概括

浏览器里按一下 F12，抽象的协议立刻变成一行行能点开的消息——这一节讲的就是怎么用它去看前面两条讲的请求与响应。

📝 本节和前面几节的关系

2-6 和 2-7 分别讲了请求与响应，但它们一直是纸面上的。这一条把两半合起来：一条报文到底由哪几段组成，以及在哪里能看到真的。教材这一条提到的【开发者工具】，就是浏览器按 F12 打开的那个面板。

一、一条报文的四段

不管是请求还是响应，结构都是四段：第一行说明这次是什么，接着一串头部说明细节，一个空行做分隔，最后是正文。

第一行是【结论】，头部是【条件】，正文是【货】。排查问题的时候，顺序恰好是反的：先看第一行（成功了吗），再看头部（为什么是这样），最后才关心正文。

二、几行值得单独记住的头部

Host 决定去哪个网站——一台服务器上常常挂着很多家网站，就是靠它分开的（这一点在 1-2 里见过）。

Content-Type 说明这份正文是什么格式、用什么编码。它写错，浏览器就会把网页当文件下载下来——这个现象很多人都遇到过。

Cache-Control 是给浏览器看的有效期；Set-Cookie 是服务器给浏览器发的一小段凭证，它上面的三个标志（HttpOnly、Secure、SameSite）在 2-13 会展开讲。

三、动手 Demo：把报文量一量

req, res, body = 720, 410, 20480
print("请求头 %d 字节，响应头 %d 字节" % (req, res))
print("头部合计占整条消息 %.1f%%" % ((req + res) * 100.0 / (req + res + body)))
print("一页 64 条请求，光请求头 = %d 字节，约 %.0f KB"
      % (req * 64, req * 64 / 1024.0))

实跑输出：

--------------------------------------------------------------------
D8  确认 HTTP 消息：开发者工具
--------------------------------------------------------------------
  一条消息分四段，从上往下读：
  ----------------------------------------------------------------------------------------
  段落            内容
  ----------------------------------------------------------------------------------------
  请求行          方法 + 路径 + 协议版本
  请求头          关于这次请求的说明，一行一条
  空行            分隔用，一行空白
  请求体          提交上去的数据（GET 通常没有）
  ----------------------------------------------------------------------------------------

  一条真实请求长这样：
    GET /index.html HTTP/2
    Host: www.example.com
    User-Agent: Mozilla/5.0 ...
    Accept: text/html
    Accept-Encoding: gzip, br
    Cookie: sid=8f3a...

  服务器回过来长这样：
    HTTP/2 200 OK
    Content-Type: text/html; charset=utf-8
    Content-Length: 20480
    Cache-Control: max-age=600
    Set-Cookie: sid=8f3a...; HttpOnly; Secure; SameSite=Lax

  这几行里，有两行值得单独记住：
    Cache-Control: max-age=600 —— 十分钟内不用再来问我（前端缓存）。
    Set-Cookie 上的三个标志 —— HttpOnly 让脚本读不到，
    Secure 只走加密连接，SameSite=Lax 挡住跨站带 Cookie。

  头部占多少？量一下：
  ----------------------------------------------------------------------------------------
  部分                  字节      说明
  ----------------------------------------------------------------------------------------
  请求头（6 条）        720       每条约 120 字节
  响应头（4 条）        410       每条约 100 字节
  正文                  20480     这一页的 HTML
  ----------------------------------------------------------------------------------------
  头部合计占比          5.2%      整条消息算下来
  ----------------------------------------------------------------------------------------

  5% 听着不多，但一条页面要发 64 条请求（见 D6）：
    光请求头就是 720 x 64 = 46080 字节，约 45 KB。
  HTTP/2 起，头部会被压缩（HPACK），第二次以后的请求往往只剩几十字节——
  这正是 HTTP/1.1 与 HTTP/2 在手感和速度上拉开差距的一个原因。

  这些东西在浏览器里怎么看？按 F12 打开开发者工具：
  ----------------------------------------------------------------------------------------
  面板              看什么
  ----------------------------------------------------------------------------------------
  Elements          页面结构（HTML 与 CSS 的实时样子）
  Console           程序运行中的报错与打印
  Network           每条请求：地址、状态码、大小、耗时
  Sources           页面用到的代码文件
  Performance       卡在哪一步（渲染、脚本、还是网络）
  Application       Cookie、本地存储、缓存
  Lighthouse        一次性给性能、无障碍、SEO 打分
  ----------------------------------------------------------------------------------------

  教材这一条提到的工具，就是 Network 面板。
  它把 D7 那张状态码表变成了眼前可以逐条点开的东西——
  这是【让协议变得看得见】最快的一条路：随便打开一个网站，
  按 F12、刷一下，你就能看到那些报文在眼前跑过去。

读这个输出：单个请求头部只占 5% 左右，看着不多。但一条页面要发六十多条请求——乘起来就是几十 KB 的纯开销，一个字的内容都没算进去。这也是 HTTP/2 要给头部做压缩（HPACK）的原因：它省下的正是这一块。

四、开发者工具的七个面板

F12 打开的面板里，最常用的七个各管一段：Elements 看页面结构，Console 看报错，Network 看请求，Sources 看代码文件，Performance 看卡在哪一步，Application 看 Cookie 与缓存，Lighthouse 一次性打分。

其中 Network 就是教材这一条说的那个工具。它把 2-7 那张状态码表变成了眼前可以逐条点开的东西。

这是【让协议变得看得见】最快的一条路：随便打开一个网站，按 F12、刷一下，前面两条讲的东西就会在眼前跑过去。

30 秒实验

  1. 按 F12，切到 Network 面板，勾上 Preserve log（保留日志），然后随便点几个链接。
  2. 在一堆请求里找出状态码不是 200 的那几条，点开看看它们的头部。
  3. 再挑一条请求，把它的响应头里的 Content-Type 记下来，想想这一行如果写错了，页面会变成什么样。

常见误区

  1. 错误：开发者工具是给专业前端用的，普通人用不上。——纠正：它是所有人的排查工具。页面加载慢、图片显示不出来、表单提交后没反应——这些问题的答案都在 Network 面板里，不需要懂多少代码就能看。
  2. 错误：报文里的头部都是可有可无的。——纠正：它们决定了整条消息怎么被解读。Content-Type 写错会被当成文件下载，Cache-Control 写错会让用户一直看到旧页面，Set-Cookie 少一个标志就多一类风险。正文是货，头部是提单——提单写错，货就走不到。
  3. 错误：看到的状态码是 200，就说明一切正常。——纠正：200 只说明【这次请求被正常回答了】，不代表返回的内容是对的。接口返回一条错误信息，状态码也可以是 200。所以还要看内容，必要时接口层会约定业务错误码。
  4. 错误：慢就是网络慢。——纠正：Performance 面板会告诉你卡在哪一步：是网络等待、还是脚本执行、还是页面重排。只看一个面板容易把问题归错地——而找错方向，比找不到原因更费时间。
自测三问（点开对答案） 1. 一条报文的四段，排查问题时的查看顺序是什么？ —— **反着来**：先看第一行（成了没有），再看头部（为什么是这个结果），最后才看正文。**因为第一行是结论**，它能把排查范围一下缩掉一大半——5 开头的问题，正文再怎么看也没用。 2. 为什么单个请求的头只占 5%，却仍然要专门去优化它？ —— 因为**一条页面要发六十多条请求**。单看一条不多，乘起来就是几十 KB 的纯开销。**这正是 HTTP/2 要给头部做压缩的原因**——它省的不是某一条，而是那条数一乘之后的量级。 3. 为什么说 Network 面板是最值得先学会的一个面板？ —— 因为**前面几节讲的抽象概念，在这里全部变成看得见的东西**：方法、状态码、头部、大小、耗时，一列一列摆在那里。**先学会看这个面板，再回去读教材里的定义，理解会快很多**——这是本课里少有的【能立刻上手试】的地方。

相关笔记