端口号属于协议还是进程

  我们知道，在操作系统中，端口号用于标记本机中的一个进程。而在计算机网络中，运输层使用一种叫做协议端口号（protocol port number）的东西。问题是，协议端口号与进程的端口号是同一事物。那么，端口号究竟是与进程对应，还是与协议相对应呢？

  实际上，端口号是来标记一个进程的，端口号与协议本质上没有必然联系。在解释这个问题之前，让我们先回顾端口号的用途。无论是操作系统还是计算机网络中的端口号，都是用于解决进程之间通信的问题。端口号就好比手机号，它的好处在于可以以数字化的方式唯一标识一部手机。与对方通信时，输入对方的手机号总比输入对方的姓名、家庭地址等要可靠很多。因此，进程之间进行通信时，就把端口号看成是对方进程的代表，而无需获得其它更复杂、耦合性更强的信息，如进程中某数据的内存地址等等。应该说，IP 用于确定网络上的一台主机，端口号用于确定该主机上的一个进程。

  但是，这里有一个发明端口号这种方法自身无法解决的问题。如果必须知道端口号之后才能通信，然后端口号也通过通信的方式传递，那么这将是一个死循环，因为不能依靠打电话的方式来得知对方的电话号码。因此，对方的端口号必须提前得知，于是需要事先约定一些端口号。不过这是个问题，因为一个端口号只能被一个进程所使用，如果只规定一个端口号，多主机之间的互相通信将受到极大的限制。另外，通信过程中还涉及传输的数据类型，不同的数据类型，传输时的内部机制也需要不同，因此，通信过程中也需要有办法能够提前标识传输的数据类型。这可以通过规定协议来完成。如果规定传输时不同的数据类型由协议来决定，同时为每个协议规定一个默认端口号，这样一来，端口号、协议、传输的数据类型，这三者只需要知道其中一个，就可以推断出其它两个。因此，只需要对每个协议规定一个默认端口号，这就是熟知端口号（well-known port number）。

  不过，一方面，端口号是有很多个的。对于运输层 TCP，端口号为 16 位，一共可以有 65536 个（也有人认为是 65535 个，因为 0 号端口一般不使用）。为这么多端口号各自规定一个协议是不现实的。另一方面，运输层的报文中会给出端口号。因此，在传输过程中实际上不需要额外给出协议名。

  这么说的话，好像没有必要定义协议这种东西，实际的通信过程不是只用了端口号吗？其中的缘由解释起来很麻烦。首先，端口号这种东西在编程业界称为魔鬼数字，没有人喜欢背这些个无意义的数字（记协议名显然要容易很多）。另外，就通信的收发数据而言，确实是只需要端口号，但想要通信成功还要其它要素，其中一个必要条件就是提前知晓对方传输数据的数据类型。举个例子，一个人想要能听懂对方所的话，一个基本的条件就是，空气中能够传输声波。可是，光满足这个还不行，还需要双方使用同一种人类语言。计算机之间的通信也是类似的，光有端口号还不行，还要对传输数据进行编码与解码。为什么要这么做？原因有很多，其中一个就是计算机的通信链路最多只能直接传输两种数据：文本数据和二进制数据。所幸任何数据都可以用这两种数据来表示。如果想传输非文本数据，发送方必须对数据先进行编码（转化为二进制数据），再发送，然后接收方接收到数据之后，必须先解码再使用。解码的关键是知道需解码数据的数据类型。另外，数据还有格式的问题。发一篇文章，如何知道哪些是文本属于标题，哪些是段落？除此之外，通信还要很多要注意的问题。当接收方正在接收数据时，如何知道对方是否已经发完了本次要传输的数据，还是因网络问题而暂时中断传输？这些问题都可以且必须通过通信双方遵守某种协议来解决。因此协议本来就是需要存在的东西，只是通过熟知端口号来将协议与端口号之间关联了起来。

  但是，这又回到开始的问题，如何提前知道端口号？实际上，作为发送方，不需要接收方提前告知端口号，因为发送方会假设接收方使用这种端口号。这同样是提前约定的好处。前面有言，端口号与协议之间可以互相推导，然后如果发送方假设对方会接受哪种协议，那就不需要提前传递任何信息。发送方如何确定这种假设成立呢？这很简单，如果它发现使用这个与协议绑定的端口号进行通信时失败，就说明对方不同意使用这种协议，如果通信成功，就认为对方同意使用这种约定。因为这都可以事先约定，所以这不是什么碰运气的事情。

  因此，端口号是与进程相绑定的，同时它也有可能就是某个协议建议的默认值。如果使用 URL 进行通信，但是没在 URL 给出端口号，那就相当于给出的是 URL 中的协议的默认端口号。

  另外，只有进行进程间通信的进程才会拥有端口号。对于一个不进行网络连接的进程，操作系统是不会为其它分配端口号的。而且，一个进程可以占用多个端口号，但一个端口号只能被一个进程所使用。