首先让我们回顾一下子我们之前都讲了那些
最开始我们将了一下子
其中简要提到了三次握手与四次挥手,但是不是很详尽,于是我转载了一篇
然后在第一篇博文中,我们讲解了socket的API接口,详情请见
好了现在我们有了基础了,基本的API也知道了,但是客户端和服尤其务器的框架是什么样的,有哪些服务器的框架呢
于是就有了
好了,现在我们可以专心的写服务器了,当然也是由浅入深了
阻塞I/O : 迭代型 -=> 多进程 -=> 多线程 -=> 线程池
好了前面我们了解的服务器框架其实本质都是阻塞I/O类型的,从开始的迭代型,到后来为了能提升性能,提高并发性,因此改成了多进程,但是进程的开销还是很大的,因此我们又设计出了多线程的方式,但是随着性能的提升,传统的accept方式其阻塞性质开始成为性能瓶颈,因此我们使用了多个线程同时accept的方式来提高并发处理的能力。
但是其本质没有偏离阻塞I/O的基本很特性,其原因就是我们的API接口均是阻塞型的,没有请求就死等,没有连接就耗着。
因此提出了select模型
connect
、accept
、recv
或recvfrom
这样的阻塞程序)默认为阻塞模式。可以通过多进程或者多线程技术进行优化处理。阻塞模式下,进程或是线程执行到这些函数时必须等待某个事件的发生,如果事件没有发生,进程或线程就被阻塞(死等在被阻塞的地方),函数不会立即返回
EINPROGRESS
,Windows的错误号为WSAEWOULDBLOCK
)。但功能强大。它能够监视我们需要监视的文件描述符的变化情况——读写或是异常。非阻塞non-block模式下,进程或线程执行此函数时不必非要等待事件的发生,一旦执行肯定返回,以返回值的不同来反映函数的执行情况,如果事件发生则与阻塞方式相同,若事件没有发生则返回一个代码来告知事件未发生,而进程或线程继续执行,所以非阻塞模式效率较高
为了解决这个问题,提出了进行I/O操作的一些I/O模型。
linux下最常见的三种就是select
模式,poll
模式,epoll
模型,当然也还有一些异步的或者事件驱动型的服务器模型。
同样windows下的Winsock也提供了一些I/O模型,常用的有有五种:select
, WSAAsyncSelect
,WSAEventSelect
,Overlapped
,Completion
等。
来源: http://lib.csdn.net/article/linux/37797