下级分类
数据结构5 篇
计算机体系
计算机网络、数据结构与基础知识。
专题分组
下级分类
计算机网络6 分钟
ping 延迟、三次握手、 TLS/SSL 握手 延迟
这篇笔记围绕网络请求中的 RTT 成本展开，用 ping 返回的 time=44ms 说明它表示从发出到收到回复的完整往返时间，系统不会把结果除以二来显示单程延迟。正文先从广州到北京的光纤传播估算切入，指出即使理想直连往返约 22ms，真实链路还会受到骨干路由跳数、线路绕行以及电光转换等因素影响，因此 44ms 中包含明显的网络损耗。随后文章用时间线拆解 TCP 三次握手，强调真正阻塞客户端继续发送数据的是等待 SYN-ACK 返回的 1 个 RTT，第三次 ACK 不必等服务器收到后才进入下一阶段。对于 HTTP 请求，第三次 ACK 可以和 HTTP 数据捎带发送，因此一次未加密请求可近似理解为 TCP 建连 1 个 RTT 加请求响应 1 个 RTT。对于 HTTPS，请求在 TCP 之后还要完成 TLS/SSL 协商，TLS 1.3 通常再消耗 1 个 RTT，TLS 1.2 可能更多，所以 HTTPS 最快约为 3 个 RTT 加服务器处理时间。文章也说明四次挥手通常不计入一次请求的可感知耗时，因为业务代码拿到 response 时关键路径已经结束，断开连接多在后台完成，适合需要估算接口首包延迟、理解 TCP/TLS 建连成本的后端和网络学习者阅读。
3 分钟
Github Action 官方托管 与自托管区别
这篇笔记围绕 GitHub Actions 的官方托管 Runner 与 Self-hosted Runner 做取舍说明，重点回答默认机器规格、是否自动扩容、计费方式和运行环境差异。官方 Linux 标准 Runner 通常是 2 vCPU、7GB 内存、14GB SSD，Windows 标准环境也接近 2C7G，macOS 规格相对更高；这些资源不会随构建负载动态增加，任务内存不足时会失败，只有手动选择并付费配置 Larger Runners 才能提升规格。Self-hosted Runner 不消耗 GitHub Actions 每月分钟数，即使长期运行也不会在 GitHub 侧产生分钟账单，但服务器、网络和维护成本需要自行承担。对比部分指出，官方 Runner 每次任务结束后销毁虚拟机，环境纯净、维护成本低，更适合公开仓库；自托管环境持久，能保留 Docker 镜像、node_modules 等本地缓存，构建速度可能明显提升。代价是需要自己安装和维护 Docker、Git、系统环境，并定期清理磁盘，否则容易被缓存和镜像占满。安全边界尤其关键：公开仓库不应随意使用自托管 Runner，因为恶意 PR 可以修改执行脚本并控制服务器；而在内网集成测试、访问私有资源或需要自定义并发能力的场景，自托管才更有优势。
3 分钟
洛杉矶机房平均 1ms 延迟，为什么？
这篇解释围绕“洛杉矶同城机房为什么能测到约 1ms Ping”展开，把低延迟拆成物理距离、互联枢纽和链路形态三个层面。正文先用光在光纤中约 20 万公里/秒、Ping 是往返时间来估算：1ms 足够覆盖约 100 公里往返，而洛杉矶核心区域之间的实际光纤传播耗时通常只占 0.1ms 到 0.3ms，剩余时间主要来自路由器处理和排队。随后文章指出，洛杉矶的很多 IDC、运营商和海底光缆接入点会汇聚到 One Wilshire 这类西海岸重要网络枢纽，所谓不同“洛杉矶机房”在网络层面可能只是隔着几层楼或几条街。它还进一步区分了 IDC 之间的暗光纤、内网直连与普通公网绕行的差异，说明低延迟并不只取决于地图上的城市大小，而取决于实际走线和交换位置。文章最后用家庭宽带访问 IDC 作对照，提到 BRAS、计费、鉴权、NAT 等运营商环节会引入额外路径和处理成本。适合网络学习者、VPS 用户和运维人员理解同城机房延迟测试结果，避免把“洛杉矶很大”直接等同于“网络一定很远”。
数据结构11 分钟
AOE网络-介绍
这篇笔记围绕 AOE 网络梳理工程计划中的任务依赖与时间约束建模方法，说明它以有向无环图表示项目：顶点是事件，边是活动，边权是活动持续时间，源点到汇点的最长路径决定最短总工期。内容重点区分事件最早发生时间 ve、最迟发生时间 vl，以及活动的最早开始 E、最迟开始 L、最早完成时间和总时差，并给出正向取最大、逆向取最小的计算公式。拓扑排序部分解释了 Kahn 入度法和 DFS 法如何为依赖任务生成合法顺序，也说明在 AOE 网中正向推算最早时间本质上依赖拓扑序。关键路径求法采用 CPM 的“一次正推 + 一次逆推”：先从源点计算各事件 ve 和总工期，再从汇点反推 vl，最后用 E(i,j)==L(i,j) 判断关键活动。示例通过逐步计算 1 到 6 号事件的 ve、vl，展示活动 d 的最早开始和最迟开始都为 12，从而说明关键活动判定的具体过程。适合学习项目进度控制、DAG 任务编排、构建依赖分析或 Airflow、Prefect、Dagster 等调度框架底层思想的读者，用来建立从图论模型到关键路径计算的基础框架。
数据结构13 分钟
散列表-介绍
散列表是一篇面向数据结构初学者的基础笔记，围绕“如何用哈希函数把关键字直接映射到存储位置”展开，解释它为什么能在平均情况下获得接近 O(1) 的插入、删除和精确查找效率。内容先定义哈希函数、散列表、装填因子等核心概念，再梳理开放定址法、链地址法、线性探测、二次探测、双重散列以及直接定址、除留余数、数字分析、平方取中等构造哈希函数的方法。文章通过与顺序表、链表、二叉搜索树对比，突出散列表适合快速精确查找，但本质上是以空间换时间，并不强调有序遍历或范围查询。示例部分用 H(key)=key%7、表长 11、线性探测插入 8 个关键字，逐步展示冲突处理，并计算成功查找平均长度为 9/8，失败查找平均长度为 6。这里特别提醒失败查找的统计起点由哈希函数值域决定，虽然物理槽位是 0 到 10，但 key%7 只会产生 0 到 6，不能把 7 到 10 也纳入平均。最后补充数据结构哈希与 MD5、SHA、CRC32 等成熟哈希函数的目标差异，并说明它们在数据分片、URL 缩短、文件去重、跨平台实现和安全需求中的使用边界。
6 分钟
平衡二叉树AVL
这篇笔记面向正在学习数据结构和索引原理的读者，梳理 AVL 树作为自平衡二叉搜索树的基本定义、操作流程与应用价值。正文先用“任意结点左右子树高度差不超过 1”界定平衡条件，并引入高度和平衡因子 BF，说明 AVL 通过保持树高接近对数级来让查找、插入、删除稳定在 O(log n)。在基本操作部分，查找沿用普通 BST 的比较路径，不需要旋转；插入则先按 BST 规则放置新节点，再自底向上更新高度和 BF，一旦出现 |BF|>1 就在局部执行单旋或双旋。文章重点拆分 LL、RR、LR、RL 四种失衡形态：左左和右右分别用一次右旋或左旋修复，左右和右左则需要先处理子节点方向再旋转失衡节点。删除部分强调先按 BST 的叶子、单孩子、双孩子规则完成结构删除，再回溯检查平衡，且一次删除可能在多层触发旋转。最后，笔记把 AVL 的高度控制思想延伸到 B 树、B+ 树和 MySQL InnoDB、PostgreSQL、SQLite 等索引场景，帮助读者理解平衡树为什么适合动态有序且频繁增删的数据维护。
4 分钟
哈夫曼树与哈夫曼编码
这篇笔记聚焦哈夫曼树与哈夫曼编码在无损压缩中的基本原理：根据符号出现次数或概率分配变长二进制码，让高频符号更短、低频符号更长，从而降低加权平均码长。正文把哈夫曼编码定位为前缀码中的平均码长最优方案，并用带权路径长度 WPL 公式说明其目标是寻找一棵使权值与码长乘积总和最小的满二叉树。构造部分给出典型流程：统计权值，将每个符号作为单节点树放入小根堆，反复合并权值最小的两棵树，直到得到唯一根树，再按左 0 右 1 的路径生成码字。示例使用 a 到 f 的频率演示树形结构、各字符码字以及 face 被拼接成比特串的过程，同时提醒左右孩子次序不同会导致具体码字不同，但总加权码长保持一致。文章还补充了哈夫曼树的结构性质与实现代价，包括 n 个叶子对应 2n-1 个节点、小根堆构造复杂度为 O(nlogn)、解码时从根按 0/1 走到叶子再回根继续。应用场景覆盖 ZIP、GZIP、PNG、MP3、JPEG、HTTP/2 HPACK、HTTP/3 QPACK、嵌入式存储和搜索索引等，适合数据结构学习者、后端与网络开发者理解压缩算法中“最优前缀码”的基础机制。
1 分钟
关于“数据结构”类别
“数据结构”类别的核心作用是为站内相关内容提供清晰的归档边界，而不是展开某一种具体结构或算法实现。该说明需要帮助作者判断：一篇文章是否真正以数据组织方式、结构特性、使用场景或相关规则为中心，而不是仅在其他主题中顺带提及。它还强调分类应与既有类别保持区分，避免因为概念相邻、应用场景重叠或文章内容混杂而造成归类混乱。适合纳入该类别的内容，应围绕该分类存在的理由、承载的话题范围、与其他分类的差异以及后续维护规则展开。对于站点维护者而言，这类说明的价值在于统一写作和归档口径，减少重复分类、过细拆分或不必要的新建类别。读者也能据此快速理解该栏目关注的知识范围，并判断某篇技术笔记是否应被放入“数据结构”这一分类下。
计算机知识13 分钟
RTMP协议
这篇内容围绕 RTMP 协议在直播与流媒体链路中的作用展开，先说明它是 Adobe/Macromedia 设计的实时消息传输协议，运行在应用层并通常依赖 TCP 1935 端口提供可靠传输。文章把 RTMP 的使用价值放在直播场景中解释：推流端如 OBS 或推流 SDK 将音视频送入 SRS、Nginx-RTMP、Wowza 等服务器，服务器再面向观众侧转成 HTTP-FLV、HLS 或 WebRTC 等更适合播放和互动的协议。正文重点梳理了完整连接流程，从 TCP 三次握手、C0/C1/C2 与 S0/S1/S2 的 RTMP 握手，到 connect 指定 app、stream key 和认证信息，再到 createStream 获取 stream_id，最后通过 publish 或 play 进入推流、拉流阶段。数据传输部分强调 RTMP 通过 Chunk 分块与消息机制持续传递音频帧、视频帧和 metadata，并借助持久连接实现低延迟、多路复用和音视频同步。文章也补充了 RTMP URL 结构、RTMPT、RTMPS、RTMPE 等变体，以及 macOS 下可用 VLC、Live Stream Player 配合测试流地址进行验证。需要注意的是，浏览器端已不再原生适合播放 RTMP，因为 Flash 已被淘汰；同时 RTMP session 与底层 TCP 连接绑定，正常断开需经历 deleteStream、close 和 TCP 释放，异常断开或服务器踢出则会清理相关 stream。整体适合想理解直播推拉流入口协议、服务器接入流程和连接生命周期的后端、音视频与运维开发者。
4 分钟
ICMP与TCPping整理
这份笔记围绕网络连通性排查中常见的 ICMP Ping 与 TCP Ping 做对照整理，核心区别在于前者工作在网络层，通过 Echo Request/Reply 判断主机是否响应，后者工作在传输层，需要指定 IP 和端口并尝试建立 TCP 三次握手。ICMP Ping 适合内网排障、局域网测试和快速确认主机在线状态，但它只反映 ICMP 控制报文是否可达，很多云厂商或防火墙会屏蔽 ICMP，因此容易出现 ping 不通但网站、SSH 或 HTTPS 服务实际正常的假阴性。TCP Ping 更贴近真实业务访问路径，可用 tcping、hping3 或 nmap 指定端口检测 80、443、SSH 等服务端口的可达性与延迟，在互联网服务监控和业务体验评估中更有参考价值。笔记还给出北京、上海部分电信、移动、联通的常用测试 IP，以及 zstaticcdn 面向联通、移动、电信的 80 端口 TCP Ping 目标，便于做跨运营商线路对比。读者可以借此判断排查时该先测主机响应还是直接测业务端口，避免把 ICMP 被封误判为服务故障。适合运维、后端开发、站点维护者和需要做多线路网络质量测试的用户作为速查参考。