系统与基础设施ssh.com
SSH 如何获得 22 号端口
How SSH got port number 22
2017 — 2019，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
这个页面讲述了 SSH 协议创始人 Tatu Ylonen 在发布 SSH 1.0 时，向 IANA 的 Joyce K. Reynolds 发邮件请求分配端口，IANA 很快将 22 号端口分配给了 SSH。故事本身简单，但评论补充了历史背景：在 TCP 之前的 NCP 协议使用奇偶端口对，导致知名服务占用了奇数端口，22 号偶数端口恰好空闲。
为什么经久不衰：它经久不衰是因为它展示了互联网早期个人通过一封简单邮件就能影响标准制定的时代，而端口 22 如今已成为 SSH 的代名词，简短故事背后是协议演进的活历史。
HN 评论精选
NCP 的奇偶端口惯例导致知名服务占用奇数端口，22 号偶数端口因此空闲。
一个更有趣的故事是为什么较老的服务主要使用奇数端口号（例如 21=FTP，23=telnet，为什么当时 22 号端口是空闲的？）。原来是因为在 TCP 发明之前的协议 NCP 使用奇偶端口对，偶数用于“传出”数据，奇数用于“传入”。所以传入服务的知名端口号都是奇数。
rwmj查看英文原文
A more interesting story is why are the older services using mainly odd port numbers (ie. 21 = FTP, 23 = telnet, why was port 22 free at that time?). It turns out because the protocol which preceded the invention of TCP, called NCP, used even-odd pairs of port numbers, with even for "outgoing" data and odd for "incoming". So the well-known port numbers for incoming services were all odd. Sources: https://en.wikipedia.org/wiki/Network_Control_Program http://www.pcvr.nl/tcpip/introduc.htm
WKS 记录曾被考虑用于端口分配，但因实用性差而被废弃，反映了早期 DNS 服务发现机制的失败。
这里有个小插曲：数字最好在 1-255 范围内，以便用于名称服务器中的 WKS 字段。知名服务（WKS）记录让主机在 DNS 中公布哪些服务可用，列出分配的端口号中哪些对 TCP 或 UDP 连接开放。这从未真正流行起来，因为很少有人使用它们，更少有人保持更新，而且检查 WKS 相比直接尝试连接几乎没有实际好处。它们早在 1989 年就通过 RFC 1123 被废弃，但似乎到 1990 年代中期至少还有人认为它们相关。
mjn查看英文原文
Minor side bit here, > The number should preferably be in the range 1-255 so that it can be used in the WKS field in name servers. Well-known service (WKS) records let hosts advertise in DNS which services a given machine made available, by listing which of the assigned port numbers were open for TCP or UDP connections. This never really caught on, as few people used them, even fewer kept them up to date, and checking WKS provided very little real benefit over just attempting a connection. They had been deprecated already in 1989 through RFC 1123 [1], but it seems that by the mid-1990s at least some people still considered them relevant. [1] "An application SHOULD NOT rely on the ability to locate a WKS record containing an accurate listing of all services at a particular host address, since the WKS RR type is not often used by Internet sites. To confirm that a service is present, simply attempt to use it." https://www.ietf.org/rfc/rfc1123.txt
FTP 使用两个端口源于 NCP 单工协议的历史遗留，说明旧协议设计如何影响至今。
我个人觉得 FTP 使用两个端口（20 和 21）的原因更有趣：首先 FTP 很老，早于 TCP，最初运行在 NCP 上。第二，与 TCP 或 UDP 不同，NCP 不是双工的：它是单工协议，使用两个端口地址建立两个连接进行双向通信。每个应用层应用或协议保留一个奇端口和一个偶端口。TCP 和 UDP 标准化后，每个应用需要两个单工端口减少为一个双工端口。所以 FTP 最初依赖的传输层需要两个端口，当迁移到新传输层时，为了简单起见保留了两个端口的使用。几十年后这个设计仍然存在。
throw0101a查看英文原文
Personally I find how/why FTP uses two ports, 20 and 21, to be more interesting: So the first thing to know is the FTP is 'old', in that it predates TCP and originally ran on NCP: > The original specification for the File Transfer Protocol was written by Abhay Bhushan and published as RFC 114 on 16 April 1971. Until 1980, FTP ran on NCP, the predecessor of TCP/IP.[2] The protocol was later replaced by a TCP/IP version, RFC 765 (June 1980) and RFC 959 (October 1985), the current specification. * https://en.wikipedia.org/wiki/File_Transfer_Protocol The second thing to know is that, unlike TCP or UDP, NCP was not duplex: > NCP preceded the Transmission Control Protocol (TCP) as a transport layer protocol used during the early ARPANET. NCP was a simplex protocol that utilized two port addresses, establishing two connections, for two-way communications. An odd and an even port were reserved for each application layer application or protocol. The standardization of TCP and UDP reduced the need for the use of two simplex ports for each application down to one duplex port.[1] * https://en.wikipedia.org/wiki/Network_Control_Program So the original transport layer that FTP relied on necessitated two ports, and when the move to a newer transport layer occurred the use of two ports was carried over for simplicity's sake. And several decades later that design still exists.
类似经历说明早期互联网通过简单邮件就能请到关键人物帮忙，体现那个时代的开放与直接。
所以故事的关键是“我不得不给一位互联网偶像发邮件，她立刻回复并做了我要求的事”。我深有同感。我在 Sendmail 工作时负责公司的 DNS，包括 Sendmail.org。我要做的第一件事是找辅助 DNS。我们的创始人说“给他朋友 Paul 发邮件”。结果这位朋友是 Paul Vixie，BIND 的发明者，他几分钟内就回复说他已经设置了 a-root 来辅助我运行的域名。当时我 22 岁，第一份工作，就在和关键互联网基础设施的发明者邮件往来，而他依赖我运行的数据库作为真相来源。
jedberg查看英文原文
So the crux of the story is “I had to email an internet icon and she mailed me back right away having done what I asked”. I can sympathize. When I worked at Sendmail I was tasked with running DNS for the company, which included Sendmail.org. The first thing I had to do was find a secondary DNS. Our founder said to “email his friend Paul”. It turned out his friend was Paul Vixie, the inventor of BIND, who responded in just a couple minutes that he had set up a-root to secondary the domains I was running. Here I was, 22 years old at my first job, emailing with the inventor of critical internet infrastructure who was relying on a database I ran as a source of truth.
历次讨论
同类还值得读
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编辑精选