在Unix系统上，拒绝绑定到没有root权限的进程的tcp端口<1024。
最初的原因是什么，它仍然有效？
例如http服务器不需要root权限来提供html页面。
Unix用户需要确定它以root权限运行的进程/协议是什么？
谢谢
该端口范围不应该被程序员定义。
它由IANA保留 ，
众所周知的港口是那些从0到1023。
DCCP已知端口不应在没有IANA注册的情况下使用。 注册程序在[RFC4340]第19.9节中定义。
对于不同的意见检查，
从一个linuxquestions线程 （阅读链接更多的上下文）
1024端口实际上是咬在尾巴上。 它迫使守护进程的做法，可能会打开安全漏洞，作为安全措施使限制无效。
几个核心系统服务通过远程过程调用（RPC）为客户端组件提供远程接口。 它们通常通过通用互联网文件系统（CIFS）协议，众所周知的TCP / UDP端口以及某些情况下的临时TCP / UDP端口可访问的命名pipe道端点公开。 从历史上看，匿名用户可以利用的服务存在很多漏洞。 当被利用时，这些漏洞会给攻击者提供与服务在主机上相同的权限。
如今，像BitTorrent和Skype这样的协议已经通过短暂的端口转移到了无保留的空间，不用担心root权限。 目标不是绕过这个旧的保留端口安全 ; 现在的协议要绕过networking边界 （Skype就是一个很好的例子）。 随着networking带宽和可用性的增加，情况将会进一步恶化，因为每个计算机用户都可能会自己closuresnetworking服务器 – 也许 不知不觉地 成为 僵尸networking的 一部分 。
我们需要这些旧方法所需的安全性
但现在需要用更新的方法来完成。
那么，我记得BSD Unix时代的最初想法是，端口<1024预计将被保留用于“众所周知的服务”，并假设服务器将是相对较less的，具有root权限的人将会被推定为在某种程度上是“可信”的。 所以你必须有权限绑定一个套接字来监听一个代表其他用户可以访问的networking服务的端口。
端口1024-4999旨在用作代表TCP连接的客户端的“短暂”端口。 端口5000+用于非根服务器。
很明显，所有这些假设都很快就出来了。 查看IANA TCP端口号预留列表，看看事情有多高。
这个问题的一个解决scheme是RPC portmapper的想法。 服务不是为每个服务保留一个TCP端口，而是在随机端口上启动，并告诉portmapper守护进程正在监听的端口。 客户端会询问portmapper“服务X在哪里”，然后从那里继续。 我不记得有哪些安全机制来保护已知的RPC服务免受模仿。
我不确定这些天有没有好的理由，但是像大多数* nix世界的事物往往会积累起来而不是完全重新发明。
任何人都阅读Vernor Vinge？ 我记得他在他的一本小说中写了一个远在未来的计算机系统，里面包含了古代以来的代码层次和时间层，时间仍然以古代date之后的秒数来表示（1970年1月1日准确地说）。 他可能并不遥远。
在过去，普通用户用来loginUnix机器。 所以你不希望普通用户设置一个伪造的ftp服务或者其他东西。
这些日子里，典型的用法是只有pipe理员和一些其他信任的人login到服务器，所以如果今天重做模型，<1024限制可能不存在。
这是一个历史的惯例。
很久以前，系统的数量要小得多。 也没有DNS，FTP站点要求您的匿名密码是您的电子邮件地址，并没有垃圾邮件。
这基本上是一个暗示的“君子协定”。 系统pipe理得很好，如果有人搞砸了，你知道该和谁说话，或者如果他们很费劲，从networking上启动就意味着离线。
今天，TCP / IP的一切，这是不提供安全了。
接受系统密码的服务在特权端口上运行是有意义的; 这意味着使用shell账户的用户不能在同一个端口上设置“假”服务来捕获人们的login细节，或者通过在相同的端口上设置非function服务来拒绝访问。
如果你有一个多用户盒子，并且一个非特权用户能够设置一个stream氓ssh守护进程，他们可以捕获其他用户的密码并访问他们的账户（当然，他们必须这样做，合法的ssh守护进程已closures，可能用于维护或在系统启动或closures期间）
不接受系统密码的事情并不重要，尽pipe在多用户盒子上用户之间共享诸如Web服务器之类的东西存在主要的安全问题（如共享主机提供商已经发现的那样）