波仔
🔌 第一章 浏览器生成消息
📄 一句话概括

write() 塞进去、read() 取出来；管道双向且顺序不乱；消息从哪起到哪止由 HTTP 的 Content-Length 表达，协议栈只管原样搬运。

📝 本节和前面几节的关系

管道接通了；本篇走数据——一次 HTTP 往返的时序。

一、一来一回

浏览器 write 请求 → 服务器 read 收下 → 服务器 write 响应 → 浏览器 read 收下。 HTTP 的请求-响应各占一来一回。

二、协议栈不问内容

协议栈只管把字节原样送到对面； 【消息边界】是 HTTP 的事——靠头部的 Content-Length 等表达。

三、动手 Demo：通信阶段的一来一回

把一次往返写成时间线：

seq = ['浏览器: write(3, 请求消息)   ----请求--->',
       '服务器: read(...)            收下并找出数据',
       '浏览器: read(3)             <---响应----',
       '浏览器: 交给渲染']
for s in seq: print(s)

实跑输出：

--------------------------------------------------------------------
通信阶段的一来一回
--------------------------------------------------------------------
  HTTP 的一次往返，时序如下：

    浏览器: write(3, 请求消息)      ----请求---->
    服务器: read(...)               收下请求，
                                    找出 HTML 数据
    浏览器: read(3)                 <----响应----
    浏览器: 拿到数据，交给渲染

  规矩两条：
  1) 管道双向——写进去的都会从对面出来，顺序不乱
  2) 消息长度协议栈不问——它只管原样搬运，
     消息从哪起到哪止由 HTTP 自己的 Content-Length 表达

2026 年 HTTP/2、HTTP/3 已能在一条连接上多路复用多条流， 但那是对【管道用法】的升级——管道本身的形状没变。

30 秒实验

  1. 用 Python 本机回环写一对 client/server，各发一句话收一句话。
  2. 把发送顺序倒过来（先 read 后 write），看会发生什么（阻塞）。
  3. 在网络面板看一条请求的 Content-Length 值。

常见误区

  1. 以为协议栈理解消息内容——它只搬运字节。
  2. 以为 write 返回就是对面收到了——只是进了本端协议栈。
自测三问（点开对答案） 1. 收发数据用哪两个函数？ —— write 和 read。 2. 消息边界靠什么表达？ —— HTTP 头部（如 Content-Length），不是协议栈。 3. 协议栈搬运时改内容吗？ —— 不改，原样送到对面。

相关笔记