为什么TCP编程里要设计成分为欢迎套接字和连接套接字？

美丽而迷人的海南岛亚龙湾，坐落着一奢华五星酒店L，到酒店前台check-in之后，接下来会有一位24小时客房管家会全面接手客人的接待任务，会给客人戴上花环，

送上温润的湿巾，还有纯正的椰汁，等客人稍事休息后，会引领客人到酒店房间，途中介绍早餐餐厅、中式餐厅、西式餐厅的位置及服务时间，还会介绍几个游泳池的位置，以及做精油SPA的特色及服务流程，说着说着就来到了房间，会一一介绍房间设施的使用，到最后还会有结束辞：有什么需要帮助您的，请直接一键呼叫我，预祝大家入住愉快！然后甜甜地站在一边，然后车小胖拿出早就准备好的小费递了过去…

24小时管家服务熟知客户的入住时间、离店时间、行李的托运、餐厅预约、SPA预约、送机服务、房间使用过程中的任何问题，这是1对1的VIP服务，让客人有宾至如归的超凡体验。让我们再来看看经济型的快捷酒店的入住流程。

你来到快捷酒店的前台，办理完身份核验及押金之后，前台给你一张房卡，房间号302，然后你就拖着行李去了房间，至于其它服务没有，至于你什么时候离店，只要押金够多，随便你住到什么时候。

上文中的奢华酒店L的前台充当TCP 监听端口（Listening Socket），新的客人（incoming new TCP connection)入住手续全部由前台处理，如果前台不光要处理入住手续，还要帮客人介绍服务，记录一些客人状态信息（TCP连接状态、接收发送字节流的序号），会耗费很多CPU时间，当有新的客人入住时，前台如果还喋喋不休（监听进程忙）地忙于上一位客人的解释工作，那新的客人就无法及时入住，这不是一个好的体验。

于是就有了一对一的客房管家服务，一旦前台办理了入住手续（Accept），就创建（Fork）一个新的连接Socket，这个Socket拥有完整的TCP五元组，即：

客户的IP + 客户的端口号 + TCP + 酒店的IP + 酒店的端口号（和listening端口相同）

这个Socket只提供唯一一位客人的连接请求。

咱们再来看看监听Socket是什么样的？

* + * + TCP + 酒店的IP + 酒店的端口号

有同学肯定已经发现了，前面的两项怎么变成了星号？是什么意思呢？意思是这个socket 可以接受来自任何客户IP、任何端口号的连接请求（类似酒店前台，只服务新的接入连接）。

而UDP则类似快捷酒店，只提供一个前台服务（Listening Socket），因为不需要记录客户状态信息（UDP 是无状态的），所以一个监听端口号足矣：

* + * + UDP + 快捷酒店的IP + 快捷酒店的端口号 具体过程是 服务器先开始创建socket（监听套接字），然后进行bind，listen，最后进行accept，accept返回得到已连接的套接字（此套接字区别于监听套接字）。
自然要问的是：为什么要有两种套接字？
原因很简单，如果使用一个描述符的话，那么它的功能太多，使得使用很不直观，同时在内核确实产生了一个这样的新的套接字描述符，代表与客户端建立的连接，然而监听套接字依然在服务器上原来的那个端口上listen()。
总结一下就是：监听套接字只负责接收连接请求，将I/O操作转接给已连接套接字上，来进行read，write操作。