I/O复用知识前瞻

　　

说到IO复用，让我们先说说IO吧。I/O也就是Input/Output的缩写，是最基本的计算机术语之一，IO是完成点对点通信也就是数据交换时常常会说到的东西。
　　
因为本人的通信工程背景，我想先和大家分享一下，对于我，提起IO我最先想到的东西。首先就是IO信道的工作模式有单工(simplex)，半双工(half-duplex)，双工(duplex)这样三种工作模型。插一句，每次看到或者说起duplex的时候，总是会想起杜蕾斯这个我们熟知的国际大品牌，总觉得英语是这么写的，刚刚一查发现是另外一个词durex。好吧，杜蕾斯要是双工的话。那么我们的socialsm，就无法完成生的计划，死的随机的伟大事业，不是么？
　　
好吧，不贫嘴了。单行道，双向单车道，双向双车道就是其的一种实现。计算机中，有很多的IO，其作用是完成点对点之间的通信。计算机中，有着大量的IO，换句话说就是有着很多的数据需要完成通信或者说数据迁移交换。所以，研究IO模型的解决方案是非常重要的，不管是我们在运维工作上需要深入理解，就算是软件开发和硬件开发中，只要是有数据交换的场景时，我们就会大量的使用这些思想来进行解决方案的优化。
　　
因为资源永远是有限的，而人们的需求确实无限的。人类是贪婪的，也是最吝啬的，总是想着花最少的资源来完成最大的效益。这是人类之所以不断进步的原因，同时也是现在国内很多人每天带口罩的原因吧。唉，不吐槽了，话说其实巴黎也是有雾霾的。一个月总有那么一次，很规律。不过对于环境的治理，法国政府采用，本周如果说有雾霾，那么本周末巴黎全境的公共交通一律免费。据说，法国政府这么一个周末，就要支付百万级的费用来补贴给相应的运输公司。不对，怎么感觉还是吐槽呢。
好吧言归正传，说到IO复用，还会让我想起一些我们在电话网中使用的一些复用模型，比如说什么分时复用，分频复用等等吧。在我的理解就是，当我们完成对数据流方向的方案确定之后（也就是双工，半双工，单工），在每个信道上的多个不同的数据，完成并发传输时候的解决方案，我就不很细致的说了，大家请自己某歌一下。不管想说一个事，不知道大家知道不知道CDMA，WCDMA，CDMA2000这些通信协议制式，不过中国移动自主研发的3G制式，很多人都认为是TDCDMA，其实正确的写法是TDSCDMA。就当科普一下了，翻译很绕口，叫做时分同步的码分多址技术（Time Division-Synchronous Code Division Multiple Access），看见了吧，其实复用模型也是可以多级嵌套的。人类呀，总是那么贪婪。。。。
　　
好了，大概我能想到的关于IO的一点知识就是这么多了，要是再想到什么以后补充。下面我们进入正题，IO复用模型和阻塞模型。
　　
什么是阻塞呢，也就是等待，就像是我们到银行或者是其他类似的行业（服务响应比较慢，或者用户很多的服务）时，经常需要排队，其实是一个道理。而如果真的想要解决这个问题，我们可以通过深入的研究IO复用模型。此后，我会很多的利用到银行办理业务的具象实例来帮助大家理解。因为馬哥是在讲解web service的时候进行讲解的，所以我们先说一个关于此服务的例子。我们都知道web服务是基于TCP的80端口套接字，进行数据交互的，（用银行的例子就是，你想去办理银行服务，应该去相关的银行分理处进行办理，并且银行的大门只有一个，通常情况下，没有后门），在没有进行复用或者其他很多高大上的解决方案的时候，我们只能是一个请求一个请求的进行响应，所以很多的请求会在网卡的监听端口进行排队等待（是的，就像是我们在银行都要排队一样）。这个时候，就出现了阻塞。这会极大的影响用户体验，所以我们需要指定相应的策略提高用户体验。
　　
在这里提一下，服务器响应web请求的过程。首先网卡接受到用户的请求报文，内核一看是web服务请求，问问端口们，你们哪个在监听这种报文呀，80举手，给我吧。然后经过内核的分发，80端口通过将报文由内核空间传递给用户空间中指定的响应进程进行处理响应，响应结束之后，采用与上面讲的过程逆向将响应报文传递给客户端。
好的前瞻结束，接下来会对于多种IO模型，进行更加细致的剖析。

本文出自 “臭老王的Linux世界” 博客，转载请与作者联系！