服务由端口号区分，端口号位于 TCP 标头中，并且给定的服务（HTTP、FTP、TIME）将在服务器上有一个进程侦听给定的端口号。（具体来说，连接处于 LISTEN 状态，请参阅p23 上的RFC 768图 6）。就像客户端进程知道要联系哪个主机（通常是因为有人要求或配置它）一样，它知道服务器的端口号是什么，因为它将是所谓的“众所周知的端口号”。操作系统知道其配置的这些部分。

对于主要服务（网络、邮件、telnet、ssh 等），分配是按惯例完成的：“众所周知的端口号”是通过记录每个人在 1972 年使用的内容来建立的：“我们想要编目其他套接字应该是众所周知的，所以我们会很感激有一个便条或电话......” RFC 322。请记住，当时尚不清楚哪些服务将变得重要，或者互联网是否会以它的方式发展。到 1994 年，它已演变为“指定编号”列表的一部分，最后发布为RFC 1700。甚至这也失控了，因此被在线注册表所取代。维基百科有一个不错的总结. 如今，大多数过去可能有自己的套接字编号的事情，例如 whois，今天都可以通过 XML/HTTP 或类似的方式来完成。

在给定的系统中，端口号可能是硬编码的或使用操作系统特定的机制进行查找。例如，伯克利套接字软件是大多数互联网实现的模型，它提供了一个getservbyname()库调用，它通常会查找文件/etc/services；其他操作系统也有类似的机制。

大多数情况下，应用程序协议（TCP 的下一个上层）由 TCP 的目标端口号标识。例如 HTTP 使用端口 80，FTP 使用端口 21，SMTP 默认使用端口 25。

每个服务通常都有一个众所周知的端口，对于某些服务，这将是 IANA 分配的端口号，对于其他服务，它将是服务作者选择的端口号。在后一种情况下，不同服务之间当然可能存在冲突，但在实践中通常不会有太大问题，因为每个服务器通常只运行少数服务。大多数客户端和服务器应用程序还提供了一种选择非默认端口的方法。

正常的客户端和服务器软件只是假设对方将使用预期的协议。如果不是，则连接可能会因某种错误而失败。

扫描和嗅探工具必须对所使用的协议进行有根据的猜测。一旦您拥有少量数据包，大多数协议就相当独特。