Appearance
TCP 术语表
同一个数据对象在不同的网络层里往往有不同的叫法。这份术语表按照层次进行了整理，建议大家在分析抓包文件或阅读官方文档时，先确认当前讨论的究竟是哪一层。
数据单位与分层
| 术语 | 层次 | 定义 | 相关术语 |
|---|---|---|---|
| Frame（帧） | 链路层 | 链路层数据传输的基本单位。常见的以太网帧包含了源/目标 MAC 地址、EtherType、载荷（Payload）以及校验字段。 | MAC、Ethernet、Wi-Fi |
| Packet（包） | 通用称呼 | 一个通用的宽泛称呼，泛指网络中的数据包，具体指代哪一层的数据取决于上下文。 | Frame、Datagram、Segment |
| IP Datagram（IP 数据报） | 网络层 | 网络层的数据单位（IPv4 或 IPv6），由源 IP、目标 IP 以及上层传递下来的载荷组成。 | 路由、TTL、Hop Limit |
| TCP Segment（TCP 报文段） | 传输层 | 传输层的数据单位，由 TCP 首部和 TCP 载荷拼接而成。 | Seq、Ack、Flags、Window |
| Payload（载荷） | 相对概念 | 当前层剥离掉自身首部后，真正要交给上层的“核心数据”。TCP 的载荷通常是应用层的数据或 TLS 加密后的字节。 | Header、封装 |
| Encapsulation（封装） | 跨层 | 数据自上而下传递时，每一层都会给它加上本层控制首部的过程。 | 解封装、协议栈 |
| Byte Stream（字节流） | TCP 服务 | 一串连续且有序的字节流。在 TCP 中没有“消息边界”的概念，应用程序可以按任意大小随意读写。 | 消息边界、部分读取 |
| Application Message（应用消息） | 应用层 | 应用程序所定义的具有完整业务语义的数据单位，比如一次 HTTP 请求，或者一条聊天内容。 | 分帧、长度前缀、TLV |
| Framing（分帧） | 应用层 | 由于 TCP 只提供无边界的字节流，应用层必须自己通过特定方式（如长度前缀或分隔符）来划分出每一条完整的消息，这个过程叫做分帧。 | 固定长度、分隔符、长度字段 |
地址、端点与连接
| 术语 | 层次 | 定义 | 观察方式 |
|---|---|---|---|
| IP Address | 网络层 | 用于在网络中标识某台设备或逻辑端点的地址，是跨网段路由转发的基础。 | Get-NetIPAddress、ip address、IP 首部 |
| Port（端口） | 传输层 | 一个 16 位的数字编号，主机会根据它把收到的 TCP/UDP 流量准确地分发给对应的应用程序。 | Socket 地址、TCP 首部 |
| Ephemeral Port（临时端口） | 操作系统 | 当客户端主动发起连接时，操作系统自动分配的一个短暂使用的本地端口。 | 四元组、系统连接表 |
| Socket | API/操作系统 | 操作系统提供的一种抽象，代表一个通信端点。在代码层面，它通常表现为一个文件描述符或句柄。 | 程序变量、文件描述符或句柄 |
| Endpoint（端点） | 通用 | 网络通信中的某一端。在 TCP 语境下，通常用“IP 地址 + 端口号”来精确定位一个端点。 | 本地/远端 Socket 地址 |
| Listening Socket（监听 Socket） | API/操作系统 | 服务端经过 bind 和 listen 调用后产生的一种特殊 Socket，它只在后台被动等待并接受新连接，不主动发送数据。 | LISTEN 状态 |
| Connected Socket（已连接 Socket） | API/操作系统 | 已经成功建立连接的 Socket，它绑定了本地与远端的完整地址信息，可以正常收发数据。 | ESTABLISHED 等连接状态 |
| Connection（连接） | TCP | 并非一条物理连线，而是通信双方在内存中共同维护的一套状态机，包含了序列号、窗口大小、各类计时器以及缓冲区等信息。 | 四元组、状态机、抓包 |
| Four-tuple（四元组） | TCP 查找 | “源 IP、源端口、目标 IP、目标端口”这四个元素的组合，TCP 靠它来唯一标识并查找一条连接。 | 系统连接表、抓包 |
| Client（客户端） | 应用角色 | 在某次通信中，主动发起连接或发送请求的一方。 | connect、初始 SYN |
| Server（服务端） | 应用角色 | 在特定端口上监听，被动接受连接并处理客户端请求的一方。 | listen、accept |
| Wildcard Address（通配地址） | Socket 绑定 | 特指 IPv4 的 0.0.0.0 或 IPv6 的 ::，绑定它意味着服务端愿意接收本机所有网卡（IP）上发来的流量。 | 监听地址 |
| Loopback（回环） | 主机网络 | 主机内部专用的虚拟网络接口，流量不会离开本机。IPv4 最常用 127.0.0.1，IPv6 是 ::1。 | 回环接口抓包 |
序列、确认与可靠性
| 术语 | 定义 | 关键点 |
|---|---|---|
| ISN（Initial Sequence Number） | 建立连接时，单方向随机生成的一个起始序列号。 | 双方各自选择；SYN 标志本身也会消耗一个序列号 |
| Seq（Sequence Number） | 序列号。用来标记当前报文段第一个字节在整体数据流中的具体位置。 | 给字节位置编号；握手阶段的 SYN 会携带 ISN；达到 32 位上限后会回绕 |
| Ack（Acknowledgment Number） | 确认号。只有当 ACK 标志位置为 1 时才有效，代表接收方“接下来期望收到的第一个字节”的位置。 | 表达连续前缀的接收进度 |
| Cumulative ACK（累计确认） | TCP 并不是收到一个包就确认一个，而是一个 Ack 值能代表“在这个序号之前的所有连续数据我都收到了”。 | 网络缺口会让 Ack 值停留在缺口起点 |
| Delayed ACK（延迟确认） | 接收方收到数据后不立刻回复，而是稍微等一会儿，把多个 ACK 合并，或者搭应用层数据的“顺风车”一起发走。 | 会影响 ACK 的数量和小消息的时序 |
| Duplicate ACK（重复 ACK） | 接收方反复发送相同的 Ack 值。 | 这通常意味着网络中出现了丢包、乱序，或者窗口大小发生了变化 |
| SACK（Selective Acknowledgment） | 选择性确认。利用 TCP 选项字段精确告诉发送方“哪些不连续的数据块已经收到了”。 | 让发送方的重传更加精准 |
| D-SACK | SACK 的一种特殊用法，用来告诉发送方“这段数据我收重了”。 | 有助于排查伪重传或严重的网络乱序 |
| Retransmission（重传） | 发送方再次发送某段数据。 | 可由等待 Ack 超时（RTO）、快速恢复或 RACK 等机制触发 |
| RACK | 一种基于时间的丢包探测算法，它利用报文发送时间和确认反馈来推断丢包。 | 对少量在途数据、网络乱序等场景适应性极强 |
| TLP（Tail Loss Probe） | 尾部丢包探测。当最后几个包发出去却迟迟等不到 ACK 时，主动发一个探测包去“催促”反馈。 | 与 RACK 配合，避免漫长地等待 RTO 超时 |
| RTT（Round-Trip Time） | 往返时延。一个数据包从发出去到收到对应 ACK 所经历的总时间。 | 受网络路径、设备排队情况以及端点处理速度的综合影响 |
| SRTT（Smoothed RTT） | 平滑后的 RTT。TCP 会对采集到的多个 RTT 样本进行加权平滑处理。 | 用于稳定计时器（如 RTO）的计算 |
| RTO（Retransmission Timeout） | 重传超时时间。如果在这个时间内心跳或数据仍未被确认，TCP 就会触发重传。 | 由 SRTT 动态计算得出，并受限于系统设定的最小值和指数退避规则 |
| Checksum（校验和） | 用于检测 TCP 首部、数据及 IP 伪首部在传输过程中是否被损坏的差错校验值。 | 现代网卡通常会开启硬件卸载，导致在本机抓包时经常会看到未计算的校验和 |
窗口、流量与拥塞
| 术语 | 层次 | 定义 | 关系 |
|---|---|---|---|
| Send Buffer（发送缓冲区） | 操作系统 | 内核维护的一块内存，专门存放应用程序写进来但还没发送，或者发出去但还没被对方确认的字节。 | 部分写入、可写事件、内存 |
| Receive Buffer（接收缓冲区） | 操作系统 | 内核维护的一块内存，存放 TCP 刚刚收到但应用程序还没来得及读走的字节。 | 它的剩余空间直接决定了 rwnd 的大小 |
rwnd（接收窗口） | TCP 流量控制 | 接收方通过 TCP 首部告诉发送方“我还能再接收多少数据”，以此来保护自己的接收缓冲区不被撑爆。 | 保护接收端缓冲能力 |
| Window Scale | TCP 扩展 | 窗口缩放因子。为了突破原生 16 位窗口字段（最大 64KB）的限制，双方会在握手时协商一个倍数，将真实窗口成倍放大。 | 扩展原字段的表达范围 |
| Sliding Window（滑动窗口） | TCP 模型 | TCP 的核心模型。随着接收方不断确认新数据，发送方允许发送的序号范围也会像窗户一样不断向右滑动。 | Seq、Ack、rwnd、cwnd |
| Zero Window | TCP 流量控制 | 零窗口。接收方缓冲区彻底满了，宣告窗口为 0。此时发送方必须暂停发送新数据，并进入探测流程。 | 发送方暂停常规新数据并进入窗口探测流程 |
| Persist Timer | TCP 流量控制 | 坚持计时器。在零窗口期间，为了防止窗口更新包在路上丢失导致双方“死锁”，发送方会靠它来定期发起窗口探测。 | 防止窗口更新丢失后双方长期等待 |
cwnd（拥塞窗口） | TCP 拥塞控制 | 发送方自行推算出的一个“网络拥堵程度”指标，用来限制在途数据量。 | 真实发送速度受限于 rwnd 和 cwnd 中的较小值 |
ssthresh | TCP 拥塞控制 | 慢启动阈值。区分 TCP 处于“慢启动”还是“拥塞避免”阶段的一道门槛，拥塞事件会使其下调。 | 拥塞事件会影响其取值 |
| Flight Size | TCP 发送状态 | 在途数据量。已经发出去但在天上飞着、还没收到 ACK 的总数据大小。 | 受到 cwnd 限制，有时可能比 cwnd 还要小 |
| Slow Start（慢启动） | 拥塞控制阶段 | 慢启动阶段。新建连接或严重丢包后，拥塞窗口会呈指数级爆炸式增长，用来快速探测网络的极限容量。 | 初始传输与部分恢复场景 |
| Congestion Avoidance（拥塞避免） | 拥塞控制阶段 | 拥塞避免阶段。当窗口增长到 ssthresh 附近时，为了防止撑爆网络，窗口增长策略会从指数级放缓为线性级。 | Reno、CUBIC 等算法有不同增长曲线 |
| Fast Retransmit（快速重传） | 丢包恢复 | 快速重传。不等漫长的 RTO 超时，只要连续收到 3 个重复 ACK，发送方立刻重传缺失的数据。 | 常与快速恢复配合 |
| Fast Recovery（快速恢复） | 拥塞控制/恢复 | 快速恢复。紧跟在快速重传之后的阶段，TCP 会适当减小窗口并尽量保持数据流的平稳运转。 | 算法细节依实现与规范 |
| ECN | 网络层与传输层 | 显式拥塞通知。路由器如果发现快排满包了，就在 IP 头上打标记；接收方看到后通过 TCP 标志告诉发送方降速。 | ECE、CWR、AE |
| Pacing | 发送实现 | 平滑发送。在微观时间尺度上把报文均匀地发出去，避免瞬间爆发大流量，更好地配合拥塞控制。 | 降低突发，配合拥塞控制 |
容量、时延与尺寸
| 术语 | 定义 | 计算或观察 |
|---|---|---|
| Bandwidth（带宽） | 整条链路在单位时间内“理论上”最多能塞进多少数据。 | bit/s (bps)、Mbit/s、Gbit/s |
| Throughput（吞吐量） | 在实际网络环境中，单位时间内真实传输过去的数据量。 | 字节数除以持续时间 |
| Goodput（有效吞吐） | 把 TCP 首部、重传浪费的带宽以及协议开销统统扣除后，应用程序真正拿到手的数据传输速率。 | 扣除首部、重传和协议开销 |
| Latency（延迟） | 一个数据包或一次操作从开始到完成所耗费的时间。 | 单向延迟、RTT、请求总耗时 |
| BDP（Bandwidth-Delay Product） | 带宽时延乘积，即带宽和 RTT 的乘积。它反映了网络路径在某一时刻“最多能容纳多少在途数据”。 | 统一单位后计算为 bit 或 byte |
| MTU | 最大传输单元。数据链路层允许承载的最大网络层数据报大小，以太网常见为 1500 字节。 | 实际环境依物理接口与 VPN 等隧道而定 |
| PMTU | 路径最大传输单元。数据包从源端到目标端所经过的所有路由设备中，那个最小的 MTU 瓶颈值。 | 路径中最小限制决定 |
| MSS | 最大报文段长度。建立连接时双方在 SYN 包里声明的值，代表自己能接收的最大 TCP 载荷大小。 | 通常从 MTU 减去网络层和传输层首部开销估算 |
| Fragmentation（分片） | 如果 IP 数据报比链路的 MTU 还要大，路由器（IPv4）或端点机器就会把它强行拆成几个小片段再发。 | IPv4 路由器在条件允许时可参与；IPv6 由端点处理 |
| PMTUD | 路径 MTU 发现机制。通过给 IP 包设置“不分片”标志并结合 ICMP 报错信息，动态探测真实的 PMTU 大小。 | 利用 ICMP 反馈与发送策略调整 |
| PMTU Black Hole | PMTU 黑洞。网络中丢弃了超大报文，却又未将 ICMP 报错发回源端，导致“小包能通，大包死活发不过去”的诡异现象。 | 小报文成功、大报文停滞是常见线索 |
生命周期与关闭
| 术语 | 定义 | 观察点 |
|---|---|---|
| Three-Way Handshake（三次握手） | TCP 建立连接的经典三步走流程（SYN、SYN+ACK、ACK），主要用于同步双方的初始序列号并协商参数。 | 抓包、SYN-SENT、SYN-RECEIVED、ESTABLISHED |
| FIN | 结束标志。当发送方已经没有数据要传了，就会发一个带有 FIN 标志的控制包，宣告自己这一侧的发送任务结束。 | 占一个序列号位置 |
| EOF | 遇到文件尾。当缓冲区里的数据被读完且收到了对端的 FIN 后，应用层读取接口会返回长度为 0 的结果，代表读取结束。 | 缓冲数据读取完成后 recv 返回长度为0，Python 中为 b'' |
| Half-Close（半关闭） | 一方发了 FIN 完成了发送任务，但另一方还没发 FIN，此时网络中仅允许在一个方向上继续传输数据。 | shutdown(SHUT_WR)、FIN、继续读取 |
| Half-Open Connection（半开连接） | 一方的机器因为异常丢失了连接状态，而另一方还保留着连接状态并误以为通信依然正常。 | 主机重启、路径中断、状态超时 |
| RST | 重置标志。带有这个标志的报文代表“立刻强行切断连接”，通常出现在端口未监听、连接已失效或系统异常时。 | Connection refused、reset 错误、RST 抓包 |
| TIME-WAIT | 主动关闭方在发完最后一个 ACK 后必须保留一段时间的短期状态，用来拦截迟到的旧报文并确保最终 ACK 顺利送达。 | 隔离迟到报文并支持最终 ACK 场景 |
| CLOSE-WAIT | 接收方在收到对端 FIN 后进入的状态。此时内核正在等待本地应用程序调用 close 来彻底释放资源。 | 应用 EOF 处理和资源释放 |
| Graceful Close（有序关闭） | 双方斯斯文文地互发 FIN 包，确保所有已发送数据都被正常按语义处理完毕再断开连接。 | FIN/ACK、半关闭、EOF |
| Abortive Close（中止式关闭） | 粗暴关闭。不按套路出牌，直接丢弃接收缓冲区的数据并发一个 RST 包强制断开连接。 | 常见表现为 RST，具体受平台和选项影响 |
应用协议与工程
| 术语 | 定义 | 例子 |
|---|---|---|
| Length Prefix（长度前缀） | 一种极其常见的分帧手段：首部先带上几个字节来声明整条后续消息体的长度。 | 4字节大端长度 + Payload |
| TLV | Type-Length-Value。一种经典且灵活的数据编码格式，由类型、长度、具体值组成，极利于扩展。 | 选项、扩展属性 |
| Magic | 魔数。协议首部几个约定俗成的固定字节，用来让程序快速验证并拦截错接的协议或错位的报文。 | 快速发现错协议或错位解析 |
| Request ID | 请求 ID。每次业务逻辑请求都会带上的一个全局唯一标识，方便关联日志、去重和溯源。 | 关联日志、响应、去重和结果查询 |
| Deadline（截止时间） | 绝对截止时间。限制一整串连贯操作允许使用的总时间，剩余的时间预算会被后续环节共享消费。 | 多次读写共享剩余预算 |
| Timeout（超时） | 超时时间。在某个单一环节死等到了设定的时间边界依然没结果，系统直接报错返回控制权。 | 连接、读取、写入、空闲、请求总超时 |
| Retry（重试） | 重试机制。第一次没成功，在满足策略时再次尝试传输或业务逻辑。 | 指数退避、随机抖动、次数上限 |
| Idempotency（幂等性） | 幂等性。无论一个动作被执行了一次还是重复执行了无数次，最终产生出的业务结果都是完全一致的。 | 请求 ID 去重、幂等键 |
| Backpressure（背压） | 当下游处理不过来时，能把这种容量限制往上传递，迫使上游生产者减速。 | 有限队列、暂停读取、并发上限 |
| High-Water Mark（高水位） | 高水位线。一旦缓冲或队列的数据积压达到了这个危险刻度，就会触发各种限流或保护动作。 | 暂停生产、暂停读、拒绝新请求 |
| Keepalive | TCP 保活机制。TCP 针对长期空闲连接的探测机制，闲置太久时内核会发探测包确认对方存活。 | 空闲时间、间隔、次数 |
| Heartbeat（心跳） | 应用层心跳。应用程序周期性发送的专用消息，用于验证远端程序不仅存活还能正常处理业务。 | Ping/Pong、租约续期 |
| Health Check（健康检查） | 健康检查。负载均衡等组件用来定期验证后端服务是否依然满足特定可用条件的探测机制。 | 连接检查、协议检查、依赖检查 |
网络路径与观察
| 术语 | 定义 | 分析提示 |
|---|---|---|
| NAT | 网络地址转换。默默修改数据包 IP 或端口并记录映射关系的网络设备。 | NAT 前后抓到的四元组截然不同 |
| Stateful Firewall（状态防火墙） | 状态防火墙。不仅看 IP 和端口，还会深度跟踪并按照当前 TCP 连接状态来放行或拒绝流量。 | 关注空闲超时与双向路径 |
| Layer 4 Load Balancer | 四层负载均衡。只按照传输层信息分发流量。可能是直接转发、NAT 或终止传输连接。 | 可以转发、NAT 或终止传输连接，依产品架构而定 |
| Layer 7 Proxy | 七层代理。比如 Nginx，会彻底解析应用层协议并代为建立上游连接。 | 客户端侧与后端侧通常是两条独立 TCP 连接 |
| Capture Point（抓包点） | 捕获工具观察数据的位置。是在主机网卡、回环口、还是代理的前后？它直接决定了你能看到什么。 | 主机接口、回环、镜像口、代理前后 |
| Packet Loss in Capture（捕获丢帧） | 抓包工具自己因为性能原因未保存下经过观察点的全部报文。 | Sequence gap、接口统计、drop counter |
| Checksum Offload | 校验和卸载。现在的系统常把校验和计算交给网卡硬件，导致在本机发送端抓包时常看到未计算的值。 | 发送端抓包可能显示未完成值 |
| TSO/GSO | 硬件/软件分段卸载。主机把超大数据块直接交给底层驱动分段，导致本机抓包可能出现超大的 TCP 报文段。 | 本机抓包可能出现超大 TCP Segment |
| LRO/GRO | 接收聚合。接收端的底层为了减轻 CPU 压力，在交给上层前把多个小包偷偷合并成了大包。 | 主机内部抓包可能呈现合并结果 |
| TCP Stream Index | TCP 流索引。Wireshark 为了方便整理，给当前会话分配的内部编号。 | 只在该捕获文件上下文内有意义 |
| Analyzer Inference（分析器推断） | Wireshark 等分析器根据已捕获的上下文生成的解释提示。 | 只是工具猜测，需结合原始字段和捕获完整性复核 |
协议对比术语
| 术语 | 定义 |
|---|---|
| UDP Datagram | UDP 数据报。一种保留单次发送边界的无连接传输协议，不保证可靠与顺序，把控制权交给应用层。 |
| QUIC Connection | QUIC 连接。基于 UDP 搭建的用户态安全传输层协议，它融合了加密并原生支持多路复用与连接平滑迁移。 |
| QUIC Stream | QUIC 流。QUIC 连接内部切分出的“虚拟通道”，仅仅保证这条独立通道内的字节流是有序交付的。 |
| Head-of-Line Blocking | 队头阻塞。因为前面有一个包丢失或迟到，导致后面所有已收到的包只能排队死等的现象；TCP 的有序范围覆盖整个字节流，极易踩坑。 |
| TLS Record | TLS 记录。TLS 协议对明文进行分块、认证和加密后的基本单位，与底层的 TCP 报文段和上层的应用消息独立。 |
| HTTP/2 Stream | HTTP/2 流。为了解决并发问题，在一条 TCP 连接中切分出的多个逻辑请求流，由 HTTP/2 专属的帧头部标识。 |