nik*_*nik 11
该端口范围不应由程序员定义。
它由 IANA 保留，
众所周知的端口是从 0 到 1023 的端口。
未经 IANA 注册，不得使用 DCCP 众所周知的端口。注册程序在 [RFC4340] 的第 19.9 节中定义。
对于不同意见检查，
来自linuxquestions 线程（在链接中阅读更多上下文）
端口 1024 限制实际上是在咬自己的尾巴。它强制执行可能会打开安全漏洞的守护进程，从而使限制作为安全措施无效。
几个核心系统服务通过远程过程调用 (RPC) 为客户端组件提供远程接口。它们主要通过可通过通用 Internet 文件系统 (CIFS) 协议访问的命名管道端点、众所周知的 TCP/UDP 端口以及在某些情况下的临时 TCP/UDP 端口公开。从历史上看，服务中存在许多可以被匿名用户利用的漏洞。当被利用时，这些漏洞为攻击者提供了与该服务在主机上拥有的相同权限。
如今，像BitTorrent和Skype这样的协议已经通过临时端口转移到未保留的空间中，并且不会为 root 访问而烦恼。目标不仅仅是绕过这个旧的保留端口安全性；今天的协议甚至想要绕过网络边界（Skype 就是一个很好的例子）。事情会走得更远网络带宽和可用性的增加，当每个电脑用户可能会运行一个Web服务器关闭自己-而也许，在不知不觉中，是一个组成部分 僵尸网络。
我们需要这些旧方法所需的安全性，
但现在需要用更新的方法来完成。
好吧，我记得在 BSD Unix 时代的最初想法是，预计小于 1024 的端口将被保留给“众所周知的服务”，并且假设仍然是服务器相对较少，并且具有 root 权限的人会以某种方式被推定为“受信任的”。因此，您必须有权绑定套接字以侦听代表其他用户将访问的网络服务的端口。
端口 1024-4999 旨在用作“临时”端口，代表 TCP 连接的客户端。端口 5000+ 用于非根服务器。
显然，所有这些假设很快就消失了。检查 IANA TCP 端口号保留列表以了解事情的进展情况。
这个问题的一个解决方案是 RPC 端口映射器的想法。不是为每个服务保留一个 TCP 端口，该服务将在一个随机端口上启动并告诉 portmapper 守护程序它正在侦听的位置。客户会询问端口映射器“服务 X 在哪里”监听并从那里开始。我不记得有什么安全机制来保护著名的 RPC 服务免遭假冒。
我不确定这些天是否有充分的理由，但就像大多数 *nix 世界一样，事物倾向于积累而不是完全重新发明。
有人读过 Vernor Vinge 吗？我记得他在他的一部小说中写过一篇关于遥远未来的计算机系统的小说，其中包含来自远古时代的层层代码，时间仍然用自某个古老日期（1/1/1970）以来的秒数表示准确地说）。他应该不远了。