Linux网络总结之六-服务器机制与网络编程

一 迭代服务器
在客户端-服务器模式中，通常我们采用迭代式服务器，即一个进程处理一个客户端，又因为send与recv函数都是阻塞的，所以当有新的客户连接进来时，传统的迭代式服务器是无法及时作出响应的。
如图：
 
当端口57267的client连接到服务器上之后，服务器进程阻塞与57266端口的client。缓存区有了4个字节的数据。
二 并发服务器
因为recv函数是阻塞的，所以在服务器端改用多进程形式响应新的客户端链接，每当有新的TCP连接建立之后，服务端fork()出一个子进程然后用来维护通信。因为服务器端的socket、bind、listen函数都是非阻塞的，所以可以考虑将fork()放在accept()之前或者accept()之后。
1: fork()放在accept()之前，子进程只拷贝到父进程的socket描述符，子进程调用accept()产生自己的TCP连接描述符。这样继承的少，但是accept()消耗较大。
2: fork()放在accept()之后，子进程同时拷贝父进程的socket描述符与TCP连接描述符，这样子进程内部只执行发送函数，父进程要向大量子进程拷贝数据。
考虑到在Linux中，进程与线程的数量不宜过多，所以以下引入I/O复用机制。这是网络编程的核心部分。
三 同步、异步、阻塞与非阻塞
在网络模型中，往往会出现同步、异步、阻塞与非阻塞这些概念，这里我们重点了解下。
1 同步与异步
同步与异步主要是从消息通知机制角度来说的。
1.1 概念描述
所谓同步就是一个任务的完成需要依赖另外一个任务时，只有等待被依赖的任务完成后，依赖的任务才能算完成，这是一种可靠的任务序列。要么成功都成功，失败都失败，两个任务的状态可以保持一致。
所谓异步是不需要等待被依赖的任务完成，只是通知被依赖的任务要完成什么工作，依赖的任务也立即执行，只要自己完成了整个任务就算完成了。至于被依赖的任务最终是否真正完成，依赖它的任务无法确定，所以它是不可靠的任务序列。
1.2消息通知
异步的概念和同步相对。当一个同步调用发出后，调用者要一直等待返回消息（结果）通知后，才能进行后续的执行；当一个异步过程调用发出后，调用者不能立刻得到返回消息（结果）。
1.3场景比喻
比如我去银行办理业务，可能会有两种方式：
选择排队等候；
另种选择取一个小纸条上面有我的号码，等到排到我这一号时由柜台的人通知我轮到我去办理业务了；
排队等候就是同步等待消息通知，也就是我要一直在等待银行办理业务情况；
等待别人通知就是异步等待消息通知。在异步消息处理中，等待消息通知者往往注册一个回调机制，在所等待的事件被触发时由触发机制，通过某种机制找到等待该事件的人。
2 阻塞与非阻塞
2.1概念描述
阻塞与非阻塞主要是进程等待消息通知时的状态角度来说的。
2.2消息通知
如果这个线程在等待当前函数返回时，仍在执行其他消息处理，那这种情况就叫做非阻塞；
如果这个线程在等待当前函数返回时，没有执行其他消息处理，而是处于挂起等待状态，那这种情况就叫做阻塞；
2.3场景比喻
继续上面的那个例子，不论是排队还是使用号码等待通知，如果在这个等待的过程中，等待者除了等待消息通知之外不能做其它的事情，那么该机制就是阻塞的。反之就是非阻塞的。表现形式就是进程是否丢失CPU。
3 同步/异步与阻塞/非阻塞
3.1 同步阻塞形式
效率是最低的，
拿上面的例子来说，就是你专心排队，什么别的事都不做。
实际程序中：就是未对fd 设置O_NONBLOCK标志位的read/write 操作；
3.2 异步阻塞形式
如果在银行等待办理业务的人采用的是异步的方式去等待消息被触发（通知），也就是领了一张小纸条，假如在这段时间里他不能离开银行做其它的事情，那么很显然，这个人被阻塞在了这个等待的操作上面；
异步操作是可以被阻塞住的，只不过它不是在处理消息时阻塞，而是在等待消息通知时被阻塞。
比如select 函数，假如传入的最后一个timeout参数为NULL，那么如果所关注的事件没有一个被触发，程序就会一直阻塞在这个select 调用处。
3.3 同步非阻塞形式
实际上是效率低下的，
想象一下你一边打着电话一边还需要抬头看到底队伍排到你了没有，如果把打电话和观察排队的位置看成是程序的两个操作的话，这个程序需要在这两种不同的行为之间来回的切换，效率可想而知是低下的。其实就是不断进行系统调用切换进程的状态。
3.4 异步非阻塞形式
效率更高，因为打电话是你(等待者)的事情，而通知你则是柜台(消息触发机制)的事情，程序没有在两种不同的操作中来回切换。