fpcc的专栏

正如前面反复分析阐述的，任何技术都其产生的时代背景和当时的意义，而Nagle算法也是如此。其在通信延时较低的场景下几乎没有什么意义。因为其靠ACK返回来进行判定传输发送的一个前提，所以比如在局域网中，回复非常快，其实就没有办法触发此算法了。而且在有些场合下需要快速的传输，也会禁止此算法。所以开发者一定要把算法的应用场景和技术内涵搞清楚，才能对相关的算法进行准确的应用，而不是自己想怎么样就怎么样。实践出真知！

通过分析TIME_WAIT和CLOSE_WAIT的机制和产生的相关原因，就已经明白了二者的真正的意图和各种情况下的处理应对方式。这恰恰说明了，要想从根本上解决问题，一定要掌握问题的本质，并结合实际的应用场景有针对性的进行处理（调优）。凡事有好的一面，就会有不好的一面，这是基础的哲学问题。做为开发者要做的，就是尽量在开发的实际环境中扬长避短，解决实际问题而不是引入新的问题。一定不能学会只转移问题而不解决问题的风格！

这篇文章本来不想写的。可是，在网上经常看到有人问这个是异步还是同步，甚至有的还会因为这个互相杠。其实没有意义，是与不是，多看看源码。可能不同的版本，或者同一版本在不同的OS上，都有所不同。不必非要纠结是同步还是异步，达到目的即可。真正想明白同步异步，还是要明白适用的场景和设计的目的以及思想。不要光盯着学习资料或者书本，深入到源码中去，自然就明白了。这正是“从代码中来，到代码中去”。

epoll的应用，不管是库还是自己开发，基本上都是各种线程（池）应用紧密的绑定在一起。那么如何处理各种事件的实时动作以及数据和命令的快速分发解析，都是一个非常重要的问题。再加上实际场景各种情况都有可能发生，这就需要开发者能把程序设计的尽量弹性容错性高。针对epoll的缺点，增加适当的限流和控制机制，确保程序的整体的安全性。学习别人的应用，最重要是学会其设计的思想和技术实现手段。融会贯通，方能真正的把知识学到自己的头脑里，自己大脑的东西才是自己的。

对于一些复杂的网络通信模型，其实仅仅明白上层的应用，是无法在实际的项目解决各种异常问题的。主动的去学习其中内在的原理并清楚运行的流程，对于解决实际问题有着非常大的帮助。这就是知其然又知其所以然的好处。与诸君共勉。建议大家手头有一份Linux内核的源码，尽量新一些！

学习epoll可以明显看到技术栈升级的过程。这也再次证明，技术的发展，更多是在前面技术的基础上不断延革的，而技术革命本身就是一种小概率事件。技术革命更类似于基因突变，而正常的技术进步更类似于生物的自然进化。万物相同，确实如此。

poll模式可以理解成一个从select优化的中间状态，改进了急需改进的问题但效率并未从根本上做出革命性的提高。这就给了大牛们继续创新和研究的空间，然后就引出来了后面的epoll和io_uring。所以说，有需求就有前进的动力！

虽然在现代的高并发网络通信中，几乎已经看不到select模式的身影，但这并不代表着它的作用很小。正如前面反复所讲，最合适的才是最好的。一个并发量不大，安全要求又高的场景下，可能一个普通程序员用Select模式就能搞定。但非要上一些epoll之类的“高端大气上档次”的模型，未必是一件好事情。开发者习惯的东西未必是一个全面的知识，select模式既可以用在服务端也可以用在客户端，这估计让许多初学者可能跌了一下眼镜。虽然大多是在讲服务端编程时学习select模型，但这不代表着他只能应用在服务端。

在实际的开发中，有时候儿需要两个设备的时钟同步，而且要求的精度相对较高。那么解决这种同步的方式有很多种，比较常见的就包括本文提到的IEEE1588标准协议。这个协议早期是在工业上应用的，后来才引入到了以太网中。在实际的开发场景中，多是在嵌入式中使用，毕竟一般也是硬件对时钟有很强的同步需求。而在更上层的软件上，一般底层做好时钟同步，而其本身只需要用就可以了。不过为了同步的快捷和方便，嵌入式中对同步往往不会是在以太网的全协议栈上进行即更多可能是在链路层等中直接进行时钟的同步（可能由硬件实现）。

我们分析完成了一般网络通信的原理和相关的IO通信的机制，已经基本明白了网络通信到底是怎么一回事，以及其相关的难点和重点。国内的教科书往往有一个重要的问题，就是从来不连贯的讲述一个知识点，而是将这些知识点打乱并且乱序讲解。这样做很难让一个人把网络通信的相关知识融会贯通。换句话说，基本上靠自觉把相关的体系建立起来的可能性极小。这也是本系列一开篇并没有像传统的书本把网络基础知识大讲一通，然后再搞几个IO模型举几个例子，基本上这书就过去了。

面对问题，最主要的是分析问题产生的原因，找出解决的方法，实现解决的过程即分析问题，解决问题，验证结果。如果没有一套理论体系来支持，那么只能是尝试，反复不断的尝试或者说有经验者在经验的指导下的尝试。如果是科学研究碰触到的全新的领域，如此做法，未尝不是一种好的办法。但如果是在既有的知识体系中，再做如此行为，就有些盲目努力的感觉了。时事不同，则指导思想不同。与时俱进，实事求是罢了！

很多学习网络编程的都是从SOCKET开发开始，一点点的扩展，然后才考虑各种机制、模型等。这就无法从整体上进行网络编程的把控。一开始就陷入了细节的泥潭。本系列文章一开始先从宏观上对网络编程进行分析说明，然后再开始一个个细节的网络知识的学习，这样就更好的知道了各种编程模式的适应性。更容易理解对网络编程的细节的处理的不同导致的适应场景的不同。一个是无目的的学习，一个是有放矢的学习。见仁见智吧。

在Windows平台上，网络高并发的开发，重点以游戏居多。其它的当然也可以做，毕竟IOCP可不是白给的。其实游戏行业是一个非常好的方向，开发者如果有兴趣的话可以深入的学习研究。当人们吃饱饭的时候儿，精神食粮就提到了必须的日程上来。至于游戏对青少年的影响，就看大环境了。已经好多年不在Windows上进行编程了，以后的网络编程重要分析也是以类Linux平台为主。

实事求是，与时俱进，理论联系实际，实践是检验真理的唯一标准…，这些理论每个人可能都会脱口而出。但真正的应用环节呢？可能绝大多数人会有意无意的找各种借口，陈陈相因，因循守旧，更别提创新意识了。只有在实践中深入分析掌握了现有技术的优劣，才可能知晓应用场景下的各种技术不足，才可能产生创新意识。网络编程中这种例子特别多（如io_uring,dpdk），毕竟实际应用的在不断提高对网络技术的要求。而更可怕的是，这种要求不但没有降低还在不断的提高。

计算机初始是没有什么用户空间内核空间之说的。这两个是从有了OS之后才出现的。这两个概念本来属于操作系统的相关概念，为什么拿到网络编程之中进行介绍呢？最主要的原因在于，网络编程是少有几个在开发者中经常遇到用户态和内核态显示交互的场景。那么为什么会有用户空间和内核空间的划分呢？也很简单。首先弄明白一件事，编程的主要目的是什么？是通过控制计算机的CPU来处理各种IO或相关操作来达到某种需求。而实际情况是，不管是CPU还是各种硬件或者IO操作等，其具有相当的专业性和复杂性，这就无形中为编程处理立起了一道无形墙。