高性能并发Web服务器实现核心内幕

高性能并发 Web 服务器实现核心内幕 ideawu 百度服务器研发高级工程师 http://www.ideawu.net/

内容简介
Not Apache/Lighttpd/Nginx source code
理论 , 基础 , 通用代码 ( 核心内幕 )
如何进化
高性能 Web 服务器实现核心内幕
高性能网络服务器的实现原理
Web 服务器的实现
socket 基础 , 先学会走再学会飞

理论结合实践 , 实践结合理论
“ 理论要结合实践” , 是对理论的贬低吗 ?
Linus 不喜欢低级的试错
别告诉我哪个对 ( 错 ), 告诉我那一个为什么对 ( 错 )
理论和实践
理论不结合实践 - 书呆子
实践不结合理论 - 业余者
理论结合实践 - 科学家
实践结合理论 - 专业者
阅读了 XX 源码的人普通码农一楼掌握了理论的人二楼能进行理论创新的人三楼

最原始的网络服务器
网络 IO 的基础
ssize_t read(int fd, void *buf, size_t count);
ssize_t write(int fd, const void *buf, size_t count);
特点 : 阻塞
一次性服务
无协议
短连接
如何重复服务 ?
serv = tcp_socket(); listen(serv); sock = accept(serv); read(sock, data); write(sock, data); close(sock)

网络协议
协议包含两个部分
语法 ( 报文格式 )
语义 ( 指令的处理 , 交互时序等 )
最重要的 TCP 协议是流式协议 , 但几乎所有的应用协议都是基于报文的协议
TCP 的”粘包”和”分包”
报文分隔
用连接关闭来表示报文结束 . 如 , HTTP/1.0 的响应
固定长度的报文 . 如 , TFTP 的数据报文 .
带自描述长度的固定长度首部的变长报文 . 如 IP 包 , TCP 分段 , nshead( 是协议吗 ? ).
带结束符 . 如 , 行协议 , HTTP 协议 . 逐字节解析和数据转义的影响 .
二进制 , 固定长度底层文本 , 带结束符高层

带有协议的网络服务器
如何读取报文 ?
尽可能多地读取 (read) 数据到用户缓冲区中 , 即使是固定长度报文 , 也不要读取指定长度 .
判断用户缓冲区中的数据是否包含至少一个报文
Packet 是协议的报文
能不能使用 TCP 报文的格式 ? UDP? IP? ICMP?
serv = tcp_socket(); listen(serv); sock = accept(serv); packet_read(sock, packet); packet_write(sock, packet); close(sock)

单个连接的连续服务 ( 长连接 )
在一个循环里不断得读取请求 , 处理 , 然后发送响应 .
serv = tcp_socket();
listen(serv);
sock = accept(serv);
while(1){
packet_read(sock, request);
if(request == EXIT){
break;
}
response = handle_packet(request);
packet_write(sock, response);
}
close(sock)

可以处理多个连接的网络服务器
在外层加一个循环
while(1){
while(1){
break;
}
// close(sock); // 短连接
}
close(sock); // 长连接
}
缺点 : 必须等一个连接关闭或者退出后 , 才能处理下一个连接 , 不是并发服务器 .

并发网络服务器
并发服务器是指 , 同时处理多个请求的服务器 . 并发的原理 :
多核 ( 多线程 , 多进程 )
分片 ( 请求处理的切分 )
并发的基本实现 – 避免阻塞 ( 解阻塞 )!
使用非阻塞的接口来替代
IO 多路复用
找出阻塞的地方 , 委托出去 .
委托给操作系统内核 sendfile()
委托给多线程 / 多进程 ( 后面不讨论多进程 )
委托给网络服务
委托有时候也叫做 " 异步 ".

阻塞
while(1){
// 可能阻塞
while(1){
// 可能阻塞
break;
}
// 可能阻塞
// 可能阻塞
}
close(sock);
}
至少要有一个阻塞 , 所以可以在 accept() 之后进行“解阻塞” .
奇迹 => ...

原始多线程并发网络服务器
while(1){
// 可能阻塞
RUN_IN_NEW_THREAD{
while(1){
// 可能阻塞
packet_read(sock, packet);
if(packet == EXIT){
break;
}
// 可能阻塞
response = handle_packet(packet);
// 可能阻塞
}
close(sock);
}
}
"RUN_IN_NEW_THREAD" 表示创建线程 , 这个线程叫做 " 工作线程 ".

原始多线程并发网络服务器 ( 续 )
缺点 :
线程的数量无法得到控制 .
如果是短连接 , 创建线程的成本可能相对请求处理的成本更大
要解决的问题 :
如何控制线程的数量 ?
如何避免创建线程对性能的影响

线程池并发网络服务器
初始化时创建线程池
主进程中 accept() 之后 , 把 socket 传给工作线程
但又带来了一个问题 : 虽然可以不断地接受连接 , 但毕竟工作线程有限 , 还是会出现连接排队等线程的情况 . 当连接数少时是线程等连接 , 但当连接数多时是连接等线程 .
怎么解决 ?
调优工作线程的数量 .
硬件问题 , 不是软件所能解决的 , 增加机器 .
改变服务器架构 , to be continued...

IO 多路复用 (IO Multiplex)
前面的架构瓶颈在哪 ?
把 IO 委托给操作系统内核
操作系统告知是否可读或者可写
轮询等通知 (select, epoll, kqueue)
可读 / 写表示只能最多成功调用一次 read/write 而不阻塞
IO 多路复用只能解决 IO 阻塞 , 阻塞的类型还有很多种 !

IO 多路复用函数介绍
前面的架构瓶颈在哪 ?
基本 IO 多路复用函数 :
int select(int n, fd_set *readfds, fd_set *writefds, fd_set *exceptfds, struct timeval *timeout);
简化 :
(rfds_out, wfds_out) = select(rfds_in, wfds_in, timeout);
功能 : 判断 rfds_in 和 wfds_in 两个列表中的 socket 连接 , 只要有至少一个可读或者可写 , 就返回 . 或者超时返回 .
rfds_in: 要测试的是否可读的 socket 列表
wfds_in: 要测试的是否可写的 socket 列表
rfds_out: 返回可读的 socket 列表
wfds_out: 返回可写的 socket 列表
timeout: 超时时间 , -1 表示不永超时

回顾避免阻塞 ( 解阻塞 ) 的方法 :
使用非阻塞的接口来替代
IO 多路复用
找出阻塞的地方 , 委托出去 .
委托给操作系统内核 sendfile()
委托给多线程 / 多进程 ( 后面不讨论多进程 )
如 Apache/Lighttpd/Niginx 把请求通过 fastcgi( 网络 ) 委托给 php-cgi 进程 ( 网络服务器 ).
委托给网络服务 , 这是一个递归过程

HTTP 服务器 (Web 服务器 )
报文解析 : 实现 packet_read()
用抓包工具抓一个 HTTP 请求报文和一个 HTTP 响应报文
对照着 RFC
上面两步就是理论结合实践 , 实践结合理论
语义实现 : 实现 handle_packet()
静态文件
大文件
小文件
脚本处理 , 以 php 为例
CGI
FastCGI
Apache mod_php
相对来说 , 报文的发送比较通用 .

Web 服务器的一般架构
Web 服务器将客户端的请求委托给 PHP FastCGI 进程 ( 是一个独立的网络服务 ) 处理
Web 服务器从 FastCGI 进程读取数据后 , 返回给浏览器
如果不是独立的 FastCGI 服务 , 也可以是嵌入到 Web 服务器内的线程 / 进程 ( 如 Apache mod_php).

报文解析
http://www.ideawu.net/person/pyhttp/
使用 Python 的基本 socket 接口和字符串处理能力 , 实现了基本的 HTTP 协议报文的解析和协议实现 .
为 IO 复用预留了接口

静态文件请求的处理
文件 IO 会阻塞
委托给线程
避免文件 IO - 内存缓存
委托给操作系统 – sendfile()

CGI
多进程
用环境变量来传递请求的 HTTP 报头信息和服务器信息
用 stdin 传递请求的 HTTP 报体
用 stdout 发送响应报头 ( 部分 ) 和报体
缺点 :
由于使用环境变量来通信 , 扩展性受限
一个进程的生命周期只处理一个请求

FastCGI
委托给网络

补充话题
IO 多路复用模型中 , 为什么不能用标准 IO 库的行读取函数 fgets() 来读取 HTTP 的首部 .
因为 fgets() 调用可能多于一次 read(), 是可阻塞的
文本协议和二进制协议如何取舍
报文的格式只是协议的其中一项内容 , 语义是另一项更重要的内容 .
文本协议总是优于二进制协议 ( 除了少数情况 )
应该更关注的是 , 报文是定长报文还是变长报文 !
参考 HTTP, 报头 ( 元数据部分 ) 是文本 , 报体可以是二进制数据 .
另外 , 冒号分隔的 key-value 行文本报头格式 , 是最简单最通用的报文格式 .
把 "TCP/IP 协议详解 - 卷 1", "Unix 网络编程 - 卷 1", " 计算机网络 " 这几本书好好看一遍 !

FAQ IT 牛人 http://www.udpwork.com/

FIN Thanks

http://www.ideawu.net	1626
http://www.cnblogs.com	617
http://www.cqumzh.cn	14
http://static.slidesharecdn.com	3
http://xianguo.com	2
http://www.slideshare.net	1
http://reader.youdao.com	1
http://reader.googleusercontent.com	1
http://cache.baidu.com	1

高性能并发Web服务器实现核心内幕

by ideawu on Apr 29, 2011

Accessibility

Categories

Tags

Upload Details

Usage Rights

9 Embeds 2,266

Statistics

高性能并发Web服务器实现核心内幕 — Presentation Transcript