系统与基础设施saminiir.com编辑精选
动手写一个 TCP/IP 协议栈
Let's code a TCP/IP stack (2016)
2016 — 2025，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
这是 saminiir 的系列教程，从零开始用 C 实现一个用户态 TCP/IP 协议栈，本篇（第一篇）讲以太网帧的收发与 ARP 地址解析。后续文章依次覆盖 IPv4/ICMPv4、TCP 三次握手、TCP 数据流与 socket API、TCP 重传。
为什么经久不衰：它把抽象的协议栈拆成可一步步动手实现的模块，是理解网络底层细节最实在的入门实践，所以多年来反复被推荐。
HN 评论精选
ARP 只是开胃菜，真正的重头戏是后续几篇 TCP 相关文章，并附上系列全部链接。
ARP 挺有意思，但可以说是 TCP/IP 协议栈里最不好玩的部分。这里是该系列的其他文章（链接：IPv4/ICMPv4、TCP 握手、TCP 数据流与 socket API、TCP 重传）。
vajrabum查看英文原文
ARP's fun but it's arguably the least fun bit of the TCP/IP stack. Here are the other articles from the series. https://www.saminiir.com/lets-code-tcp-ip-stack-2-ipv4-icmpv4/ https://www.saminiir.com/lets-code-tcp-ip-stack-3-tcp-handshake/ https://www.saminiir.com/lets-code-tcp-ip-stack-4-tcp-data-flow-socket-api/ https://www.saminiir.com/lets-code-tcp-ip-stack-5-tcp-retransmission/
ARP 是嵌入式网络教学的好起点，但作为完整实现还缺应答查询、重试、静态表、表项老化、防欺骗和 uint8_t 等细节。
实现 ARP 是进入网络与底层报文处理的绝佳入门，我培训实时/嵌入式程序员时常把它当第一个任务。要让这个 ARP 实现更完整，还缺几点：1. 应答上层的 IP→MAC 查询；2. MAC 缺失时主动发 ARP 请求（含重试）；3. 静态 ARP 配置（防 ARP 欺骗）；4. ARP 表项老化，否则很快就撞上“ARP 转换表无空闲空间”的错误（表也远不止 32 项）；5. 忽略未经请求的 ARP 应答（同样有助于防欺骗）；6. 报文结构用 uint8_t 而非 unsigned char。做得很棒！
dkopi查看英文原文
Implementing ARP is an awesome introduction to networking and low level packet processing. This was often the first task I would give out during training for Real Time / Embedded programmers A few things I'm missing for this to be a more complete ARP implementation: 1. Answer Ip to Mac conversion requests from the above stack 2. Send an ARP Request if the mac is missing (+Retries) 3. Static ARP configurations (To prevent ARP spoofing attacks) 4. ARP entry aging. Otherwise you'll run really quickly into "ERR: No free space in ARP translation table\n" (And of course a much larger cache than 32 entries) 5. Ignore unsolicited ARP replies (Helps prevent ARP spoofing attacks as well) 6. use uint8_t instead of "unsigned char" for packet structures. Awesome work!
提醒 unsigned char 并非在所有平台都是 8 位，报文结构体应改用 uint8_t 以保证可移植性。
这个话题之前在本站讨论过也吵过，但我还是冒险说一句：在用户态 TCP/IP 栈的语境里这几乎不是问题（我想 Linux 也不跑在字节非 8 位的机器上），但它很好地说明了这一层编程常见的坑。建议对 `unsigned char dmac[6];` 谨慎些，因为有好几款高性能的非老旧处理器上 unsigned char 并不是 8 位（比如 AD 的 SHARC 上是 32 位）。你用了 packed 属性，想必以后想通过 DMA 直接填充，在那样的平台上结果就不对了。建议像下面几行用 uint16_t 那样改用 uint8_t。
notalaser查看英文原文
This is a discussion that has happened here before and has generated its share of sparks, but I'll risk it :-). It is hardly a problem in the context of a userspace TCP/IP stack (I don't think Linux runs on any machine with non 8-bit bytes); it's just a good illustration about the kind of pitfalls that programming at this level sometimes poses. I would suggest being a little more careful with this: > unsigned char dmac[6]; because there are several platforms, all of them high-performance, non-legacy processors, where unsigned char is not 8 bits :-). E.g. on AD's SHARC, it's 32. You're declaring the struct with __attribute__((packed)), so I assume you're going to want to fill it automatically through DMA at some point in the future. On such a platform, it won't have the expected results. A colleague got bit by this, on a device that's sitting on my desk right now, and it's not a vintage piece of equipment from the 60s. I would suggest using uint8_t instead, just like you're using uint16_t a few lines below.
批评 C/Linux 内核式的缩写命名风格抬高阅读门槛，不是以人为本的写法。
我从 C/C++ 转来，在 Java 世界工作了五年，必须承认 C 代码尤其是 Linux 内核代码里的命名“约定”和变量缩写对我来说是道很高的门槛。为什么把名字写全这么难？我们都推崇 Linux 的各种哲学（保持简单、只做一件事等），但我觉得这种代码风格不是为人类读者写的，而是出于程序员“怎么最短、怎么少敲几个字符”的视角。这种额外的负担显得不必要且让人疏远。
splittingTimes查看英文原文
Coming from C/C++ and Having worked for 5 years within the java world now, i must admit that the naming "conventions" and variable abbreviation in c code or more specifically Linux kernel code form a high entry barrier for me. Why is it so hard to write things out? We all look up to the various Linux philosophies (keep it simple, do one thing, etc), but to me it feels that this kind of code style is not written with a human reader in mind, but comes from the programmer perspective of "what is the shortest way and type as few characters as possible." This kind of overhead seems so unnecessary and alienating.
历次讨论
同类还值得读
TTY 揭秘（2008）
The TTY demystified (2008)
经典文章深入剖析了 Unix/Linux 中 TTY 子系统的工作原理，包括线路规程、终端驱动、信号与控制字符等机制。
系统与基础设施上首页 11 次 · 2009–2025linusakesson.net编辑精选为什么 GNU grep 这么快
Why GNU grep is Fast
FreeBSD 邮件列表上一篇广为流传的帖子，解释 GNU grep 为什么快：核心在于 Boyer-Moore 字符串搜索算法配合精心优化的内部循环和 I/O，让程序在搜索时“…
系统与基础设施上首页 9 次 · 2010–2022lists.freebsd.orgXplain：为普通人讲解 X11
Xplain – Explaining X11 for the rest of us
《Xplain》是作者（HN 用户 Jasper_）写的一系列 X11 长文，用他在浏览器中重建的 X11 绘图模型做交互演示，讲解 X11 的绘图模型与窗口系统设计。
系统与基础设施上首页 6 次 · 2013–2020magcius.github.io编辑精选旋风教程：为 Linux 创建极小 ELF 可执行文件（1999）
A Whirlwind Tutorial on Creating Really Teensy ELF Executables for Linux (1999)
breadbox 写于 1999 年的经典教程，主题是如何为 Linux 手工构造并裁剪出体积极小的 ELF 可执行文件。
系统与基础设施上首页 6 次 · 2007–2025muppetlabs.comPostgreSQL 内部原理
The internals of PostgreSQL
《The Internals of PostgreSQL》是一本免费在线书籍，系统讲解 PostgreSQL 的内部实现，包括查询处理、并发控制、WAL、缓冲区管理等核心机制。
系统与基础设施上首页 5 次 · 2017–2025interdb.jp编辑精选