Linux TCP实现优化的背后想法

想象一下当初为何不让多个进程/线程在一个相同的IP地址和端口上侦听，很简单，这是由于TCP/IP模型将一个端口做为一个四层复用解复用的惟一标 识，也就是一个四层地址，正如IP地址属于一个主机同样(属于一块网卡？)，一个IP/端口对属于一台主机上一个特定的进程，它只是一个保证惟一性的静态 标识。世界上不一样的主机不能有相同的IP地址，一台主机上绑定特定IP地址的不一样进程也不能有相同的端口，不然就不知道一个流到底该交给哪一个进程！
想 象一下如今为何reuseport可让之前不可能的事变成可能。很简单，在静态因素以外加入了一个动态因素，那就是将发起链接的源IP和源端口也一块儿 考虑了进来，四元组一块儿作了一个简单的hash计算，所得的结果对Listener数量取模，获取哪一个Listener要为这个链接服务。
事实 上，咱们发现，须要惟一标识的不是一个Listener，而应该是一个链接自己。TCP服务端在有客户端企图创建一个链接时才有意义。那么是什么让一个绑 定同一IP/端口的套接字只能Listen一次这么一个限制存在了这么久呢？我认为答案有两个方面，一方面是由于UNIX的进程模型，另外一方面是这个限制 在单核CPU时代工做的足够好，又能够避免不少问题。

       好吧，如今我将Listener和进程彻底分割开，我既不赞同绑定同一IP地址/端口的套接字只能Listen一次，又不赞同采用reuseport方 案，我暂且忽略了哪一个进程/线程在侦听，假设根本没有任何进程/线程侦听的概念，我只求一个链接请求到来的时候，能够成功完成三次握手，建立一个客户 socket，而这个很简单，新建立的客户socket被放入一个池中，Listen的任务就完成了，在握手完成以前，与任何进程/线程都无关联，接下来 把进程/线程考虑进来，它们来accept，也就是从一个池中获取一个客户socket来处理。事实上，我是分离了Listen和Accept，内核协议 栈只负责Listen，而进程/线程只负责Accept，问题就解决了。

杂乱不清的东西纠缠在一块儿的时候，会引入不少复杂性，避免这些复杂性的方式就是把纠缠在一块儿的东西剥离，海阔天空。同事为我这个优化取了一个很好的名字，叫作Xsocket，这里的X能够理解成两个意思，一个是“牛X”中的X，一个是“插”！！

今天感到特别累，可是却又无比的高兴，昨晚作了一个梦，感受今天会有惊喜，然而等了一天仍是未能如愿，我再也不相信缘份了，但是最终我仍是改变了想法，缘份未尽，上帝让个人惊喜来自于别处，虽然它并非我梦里的那个。阿们...