顾名思义，终端留给外部的接口（个人YY，非官方解释），是不同设备间通信的桥梁。

人有强烈和外部沟通的欲望，各种硬件设备也是一样，它们会想尽一切办法和外部沟通，当然和人一样 ，既有有身体上的沟通（感觉好污），也有精神上的沟通。

身体上用来沟通的我们可以叫做物理端口，比较常见的像电脑的网孔，USB端口这些。

计算机本身留给外部的接口是比较统一的，比如USB端口。但是生产硬件设备的厂家这么多，而且经常会有一些新的硬件设备冒出来，一个USB端口是要如何才能适应这繁多的外设呢？靠的是驱动（这名字好熟悉），驱动是外部硬件设备跟计算机之间交流时的翻译。

计算机表示：对不起，我只说普通话，你说的鸟语我不懂，你想和我沟通，先请一个你们国家会说普通话的翻译（驱动）。

再来说说精神上的沟通。

既然是精神上的沟通，那自然是看不到的，我们可以叫做虚拟端口。这种形式的沟通在计算机上最常见的表现就是网络数据的收发。通过之前的文章我们知道，计算机中有很多的服务，这些服务运行在各自的进程当中，很多服务都和外部有沟通的需求。

很显然，我们不能为每个服务都开一个物理网络端口，一般情况下，所有的服务发的数据都是从一个物理网络端口发出去的，当然，外部回应的数据包也都是从这一个网孔挤进来的。

那么问题来了，如果数据都挤在一起收发，服务怎么知道哪个回来的数据才是自己需要的？为了解决这个问题，计算机有了虚拟端口这个概念，一个服务想和外部进行信息互通时，需要先绑定一个端口号，不需要真实打孔，用一个数字表示就好，这个服务在发数据包的时候带上自己的端口号，同时还要指定目标服务的端口号。计算机收到数据包时，会根据数据包中标明的端口号，将数据放到对应服务声明端口的缓冲区中，等待服务取走数据包。

仔细想想，这里还有问题，服务进程拿到一部分数据后开始处理，如果处理时间很长，而又不断的有新数据来，缓冲区的数据会越来越大，以致溢出丢失，这个是我们不希望的，所以这里又牵出一个设计上的问题，之前的文章讲过进程和线程，一个进程中可以有很多个线程，一般会设计一个特殊的监听线程负责监听绑定的端口，如果有数据过来，监听线程就会把这个数据从缓冲区取出来丢给其它的线程去处理，自己则回过头来继续监听这个端口，这样就避免了由于处理数据占用时间太长，缓冲区数据无法及时取出导致的堆积问题。可以想象公司是进程，员工是公司里的线程，前台员工则是监听线程，现在有源源不断的数据包裹送到了公司（这画面太美我不敢看）。