浅谈几种服务器端模型——同步阻塞迭代
来源:互联网 发布:日有所思夜有所梦 知乎 编辑:程序博客网 时间:2024/06/05 21:17
引言:似乎现在阻碍服务端大部分情况下都属于IO瓶颈,硬盘的转速等,而计算的瓶颈大部分云端计算采用分布式计算,如基于GFS的MapReduce模型,网格计算或者其他的一些分布式处理。所以,现在服务端的服务衡量指标基本集中在并发量,QPS,响应速度,稳定性等。其中一部分也不乏大量的计算,属于CPU密集型的,根据业务的不同应该做相应的调整。下面浅谈一下几种常用的IO模型。
理解IO 模型是网络编程的重中之重。
最简单的同步迭代IO模型:
核心代码就是这样,这里我们假设:前面的监听套接口已建立好,即已绑定套接口,并调用了listen()函数。
同步迭代IO大致如下,假设现在的模型是这样的,服务端监听客户端的连接,并通过读取fd的内容,处理后返回给客户端,类似于http机制。这里省去了一些包裹函数等。
for
(;;){
fd = accept(...);
read(fd,buf,n);
dosomtething(buf);
write(fd,buf,n);
close(fd);
}
单进程模式下,如果没有客户端到来,进程一直阻塞在 accept调用上,对于新手来说,有点难理解阻塞的概念,总的来说,就是经过accept调用,陷入内核以后,进程停止其他的工作,等待accept()返回。阻塞在accept()不可怕,如果阻塞在read()系统调用,将导致整个服务器不能对其他的客户端提供服务。
现在假设一个情景:
accept()得到一个客户端的连接,此时的fd唯一标示该连接。
现在服务器进入read()系统调用,但是此时的客户端并没有发送数据,那么服务端一直阻塞在read系统调用。此时来了一个新的连接,但是服务端不能予以相应,就是accept()函数不能被服务器调用。那么这个连接是失败的。可想而知,这样的服务器模型是有多么的低效。不过,UDP恰恰常用这种方式,因为UDP 是非面向连接的,整个过程就是两个函数
recvfrom(buf);
dosomething(buf);
sendto(buf);
因为UDP 的非面向连接性,而且采用的是费可靠传输,传输速率较TCP快。读者可以查阅相关资料,但是最好需要设置客户端的recvfrom()超时,因为在传输过程中数据丢失,会导致客户端阻塞在recvfrom()调用上。
附一张图说明read()的系统调用的阻塞:
即进程需要等待内核返回结果以后才能继续处理其他业务。
总结:同步阻塞迭代方式的IO是最简单的一种形式的IO模型,也是最低效的一种,但是研究东西都需要从最简单的开始。吸取经验。下一章讲解多进程的并发式IO模型。
- 浅谈几种服务器端模型——同步阻塞迭代
- 浅谈几种服务器端模型——同步阻塞迭代
- 浅谈几种服务器端模型——epoll
- ]浅谈几种服务器端模型——多线程并发式(线程池)
- 浅谈几种服务器端模型——多线程并发式(线程池)
- 浅谈几种服务器端模型——多进程并发式
- 浅谈几种服务器端模型——多线程并发式(线程池)
- 同步,异步,阻塞,非阻塞 和 几种网络模型
- 浅谈socket同步和异步、阻塞和非阻塞、I/O模型_php技巧
- 图像检索服务器编写问题记录——服务器端模型选择+epoll和非阻塞IO
- 浅谈同步,异步,阻塞,非阻塞
- 浅谈同步异步、阻塞非阻塞
- IO模型:同步、异步、阻塞、非阻塞
- 几种服务器端IO模型的简单介绍及实现
- 几种服务器端IO模型的简单介绍及实现
- 几种服务器端IO模型的简单介绍及实现
- socket阻塞与非阻塞、同步与异步,五种I/O模型总结
- 同步异步/阻塞非阻塞 和 5种linux网络通信模型
- Tomcat的安装与卸载
- NOIP2017 检查清单
- 计算C(2n, n)
- Luogu 3371(dijkstra堆优化)
- HELLO,21
- 浅谈几种服务器端模型——同步阻塞迭代
- Linux环境下mosquitto的安装及部分问题解决方法
- 【模板】最长公共子序列
- 【Mybatis学习】Mybatis级联之一对多
- 【51nod】1012 最小公倍数LCM
- 每日一练10.31
- Java面向对象(1)
- nodemon文件修改后自动运行node
- [App] rhel7 下 安装 JBoss7