一、TCP 给应用程序的四条承诺

1.5 说过"电脑本身不上网，程序才上网"。那么程序找 TCP 要了什么？四条：

二、TCP 报文段首部：可靠机制的零件清单（本节第一张图）

TCP 把要干的事全写在自己这 20 字节的头上。对照 3.6：这是"数据段（Segment）"三个字的实物——往里装一层 TCP 头，数据包就升级成了数据段。

两个值得单独拎出来的观察：

三、可靠是怎么实现的：四大支柱

支柱一：按字节编号（不是按包编号）

这是最容易想当然的一处偏差。

TCP 给数据流里的每一个字节都编了号，序号字段填的是"本报文段里第一个字节的编号"。

假设从 1000 开始发 Hello（5 个字节）：

字节编号:   1000 1001 1002 1003 1004
内容:        H    e    l    l    o

这一个报文段的序号 = 1000，长度为 5。下一个段就从 1005 接着编。

为什么按字节编，不按"第几个包"编？ 因为报文段长度是变的（受 MTU 限制，3.4），如果按包编号，重传时长度一变，编号的含义就全乱了。按字节编，编号就与"数据本身"绑死——重传第 1000~1004 这一段，编号永远是 1000，一目了然。

支柱二：累积确认

确认号 = 我下一个期望收到的字节编号。这句话有两层意思：

这就是累积确认——一个数字确认了一大批字节，比"每个包回一次"省得多。

反过来，发送方只要收到 ACK，就知道 ACK 号之前的东西可以放心扔掉副本了（不用再留着等重传）。TCP 的内存就是这么省下来的。

支柱三：超时重传 + 快速重传

没收到确认 = 没送到（3.5 的核心思想），那怎么知道"该重传了"？两条路：

快速重传的巧思：如果 2000 号那个段丢了，但它后面的 2000+、2000+ 都到了，接收方每收到一个"后面的段"就回一次"我还在等 2000"——发三次，发送方就明白不是晚到了，是真丢了，立刻重传，不必等超时闹钟响。

支柱四：滑动窗口——不"发一个等一个"（本节第二张图）

这是本节最该带走的一张图。

如果有个人问你"TCP 怎么保证可靠"，十有八九你答"发一个等一个"，然后把 TCP 的效率想得极差。 实际不是这样：

第二张图上半部分就是"停等"的样子——每个数据段后面拖着一段空转；下半部分是滑动窗口：窗口是一次允许在途、还没被确认的字节数，四个段连着发出去，收到累积确认后窗口整体右移，接着发 5、6。

一句话区别：停在"等"，滑在"窗"——TCP 用窗口允许"边走边等"，把等待时间用别的工作填上了。

四、别把两种"控制"混成一个

这是本节最容易滑过去的一处，两者都叫"窗口"，但管的完全不是一回事：

发送方实际能发出的量 = min（接收窗口，拥塞窗口）——两个都满足才敢发。这条式子值得记：网络状态差时，即使接收方说"我还能吃很多"，发送方也会自己收着发。

五、字节流没有"消息边界"——本节最坑人的一条

现在说开头那个"从没提过、却天天在坑你"的性质。

TCP 承诺的是"字节不丢、不乱、不重"，但它压根不记得"你分了几次交给我"。

你送三次：   "你好"       "在吗"        "再见"
             ↓ TCP 不管你怎么切的，它只看见一串连续的字节 ↓
对面收到：   "你好在吗再见"      ← 它不知道该在哪里断开

这叫粘包（其实不是"包粘了"，是TCP 根本没有包的概念）。反过来也可能：你送一次的一大块，对面要 read 好几次才收全，这叫拆包。

六、TCP 的代价：为什么不是所有应用都用它

既然可靠，为什么还要 UDP？（3.3 的对比表在这里落地）

一句话：TCP 是"不许错"的协议，UDP 是"不许等"的协议。要哪个，看业务最怕什么。

七、动手 Demo32：看 TCP 的可靠机制在干什么

1. 看本机的重传账本 netstat -s -p tcp 找「重新传输的段」/ Segments Retransmitted 那一项。
2. 平时应当很小甚至为 0（线路干净）

3. 下载一个大文件的同时再跑一遍，这个数字会开始涨——这就是 TCP 在偷偷补丢失的段，你在下载界面里看不到任何异常

4. 看 TCP 的参数底牌 netsh int tcp show global 重点看两项：

5. 「接收窗口自动调优级别」（Receive Window Auto-Tuning）—— Windows 的动态窗口开关，本节第三·四支柱的实物

6. 「拥塞控制提供程序」—— Windows 默认在跑哪种拥塞控制算法（如 cubic / ctcp）

7. 本节最实证的一步：亲手制造"粘包"（收 13.2 旧账）

在 13.2 的 Demo23 基础上改两行——

java // 客户端：连续写两次 OutputStream os = socket.getOutputStream(); os.write("A".getBytes()); os.flush(); os.write("B".getBytes()); os.flush(); java // 服务端：只读一次 byte[] buf = new byte[1024]; int len = is.read(buf); System.out.println("一次读到 " + len + " 字节：" + new String(buf, 0, len)); 在 127.0.0.1 上跑，大概率打印"一次读到 2 字节：AB"——你写两次，对面读一次。 - 这就是"TCP 是字节流，没有消息边界"的铁证（第五支柱） - 想让它变成两次？给第二次 write 前加个 Thread.sleep(50)，或者调 socket.setTcpNoDelay(true)

1. 30 秒实验：数一数你有多少条连接在跑 netstat -an | findstr ESTABLISHED 数一数条数。每一条背后都是一套独立的序号、确认号、窗口、计时器在跑——TCP 的"可靠"是一条连接一本账，不是全局一本账。这也解释了 3.17 那个"客户端临时号池只有 16384 个"为什么是个天花板。

八、几条实战规矩

1. 永远不要假设"一次 write 对应一次 read"

这是本节最实用的一条。代码写成"我发一条，对面就收到一条"是迟早要出 bug 的。要按"读到字节流、按自己定的边界去切"来写。

2. 发文字必须定边界，别用裸 read()

要在 Java 里传文本，老老实实 BufferedReader.readLine()；要传对象或自定义格式，先说长度最稳。

3. 实时性场景关掉 Nagle

socket.setTcpNoDelay(true);

少一次攒包的延迟，代价是包数变多。游戏、远程桌面、实时对战该关。

4. TCP 的"顺序"只在同一条连接内成立

两条不同的连接之间没有任何先后保证。所以多线程开两条连接各发一半数据，对面收到的顺序可能交叉——要保序就得挤在同一条连接里。

5. 连不上的那个报错，和 TCP 的标志位有关

Connection refused（13.2 的规矩一）——技术底细是 TCP 回了 RST：客户端发 SYN 敲门，那头端口上没有程序在听，操作系统直接回一个 RST（"重来，这连接作废"），Java 就抛了异常。

所以"Connection refused"其实是好消息——它说明网络是通的、对方主机活着，只是那个端口没人守。真正可怕的是一直没反应（SYN 发出去石沉大海，最后超时）——那才可能是网络或防火墙的问题。

九、常见误区

1. ❌ "TCP 的序号是按包编号的" → 按字节编号，序号填的是"本报文段第一个字节的编号"；这是重传能精确补缺的前提
2. ❌ "ACK 2000 = 收到了 2000 号字节" → 是"2000 之前的全收到了，从 2000 开始还没收到"，差一个字节就会判错重传范围
3. ❌ "TCP 是发一个等一个" → 那是停等协议。TCP 用滑动窗口，窗口内多个段同时在途，边发边等确认
4. ❌ "窗口大小是固定值" → 由接收方动态填，可能变小甚至报 0；这才是流量控制
5. ❌ "窗口就是拥塞控制" → 两个不同的东西：窗口是接收方说的（对面累不累），拥塞控制是网络状况决定的（路上堵不堵）；实际发送量取两者较小值
6. ❌ "TCP 会帮我保留消息边界" → 不保留，TCP 是纯字节流，根本没有"包/消息"这个概念；边界要应用层自己定（粘包问题的全部根源）
7. ❌ "TCP 保证数据一定送达" → 它只保证"在连接存活期间尽力重传"。对方进程崩了、断网太久，TCP 最终会放弃并报错——可靠性是有边界的
8. ❌ "TCP 更先进，UDP 迟早淘汰" → 取舍不同：TCP 不许错、UDP 不许等。视频通话、直播、DNS 查询、游戏都用 UDP，且活得很好
9. ❌ "有了 TCP，下层丢包也无所谓" → TCP 的重传只对丢失的少量数据有效；大面积丢包时它只能降速（拥塞控制），网络真堵了，TCP 也救不回速度

十、下一步学什么

• ☑ 3.19 用TCP对数据进行分割处理（序列号、ACK号） —— ✅ 已完成 → 用TCP对数据进行分割处理（序列号、ACK号）：本节说"序号按字节编"，那一节看 10000 字节真被切成 7 段、号怎么一路递推上去
• ☐ 3.20（按教材顺序） —— 报个标题接着走：按教材脉络，接下来大概率是 UDP（不可靠但快的那一半）、DNS 与域名（把名字换成 IP），或 第三章小结。等你报标题。

相关笔记

• 用TCP对数据进行分割处理（序列号、ACK号） —— 下一节：本节挑出的"序号、确认号"两个字段，在那一节看它们真干活的现场（切段、编号、重复 ACK）
• 接收和传输数据的规则（使用TCP/IP进行通信） —— 本节的操作手册版：握手、确认、重传、窗口、挥手的完整流程，本节拆的是它背后的零件
• 为驱动应用程序而做准备的网络分层（传输层与应用层） —— "TCP 保价快递 vs UDP 同城闪送"的最早出处，本节把 TCP 这半边彻底拆开
• 根据端口号分配数据到应用程序（端口号、已知端口号） —— 端口号就是 TCP 头里的源/目的端口两个字段；"临时号池 16384 个"的上限在本节有了另一重解释
• 数据的称谓（信息、数据段、数据包、数据帧） —— "数据段 Segment"就是本节这张头的实物；加 TCP 头 = 升级成数据段
• 数据的发送和接收（IP、IP数据包、路由） —— 对照阅读：IP 头有"总长度"和"首部校验和只管头"，TCP 头没有总长度、校验和却管上数据
• 收发数据时的规则（数据打包） —— "包 = 头部 + 数据"的最早出处；MTU 决定了每个数据段最长能装多少
• 负责传输数据的网络分层（网络接口层与网际层） —— "IP 尽力而为、丢了不补"挖的坑，本节看到 TCP 拿四个字段把它填平
• 数据是否成功传输给接收方（ICMP） —— 对比：IP 出问题靠 ICMP 报信但不修复，TCP 出问题自己补——"只报告不修复"的反面
• 网络的网络（互联网） —— 逐跳接力、线路不可靠，正是 TCP 存在的全部理由
• TCP通信 —— 本节收的最大一笔旧账：为什么 readLine() 要套缓冲、为什么必须 shutdownOutput()、为什么 byte[1024] 一次拉不完
• UDP通信 —— 对照面：无连接、无确认、无窗口，换来的是一次一个数据报、边界清清楚楚