[日常]nginx与网络事件模型

Nginx 的特点:
1.处理静态文件
2.反向代理加速
3.fastCGI,简单的负载均衡和容错
4.模块化的结构
5.分阶段资源分配技术，使得它的 CPU 与内存占用率非常低,保持 10,000 个没有活动的连接，它只占 2.5M 内存
6.支持内核 Poll 模型，能经受高负载的考验,有报告表明能支持高达 50,000 个并发连接数
7.采用 master-slave 模型,能够充分利用 SMP 的优势，且能够减少工作进程在磁盘 I/O 的阻塞延迟。当采用 select()/poll() 调用时，还可以限制每个进程的连接数
8.强大的 Upstream 与 Filter 链,有点像 Unix 的管道
9.采用了一些 os 提供的最新特性如对 sendfile (Linux2.2+)，accept-filter (FreeBSD4.1+)，TCP_DEFER_ACCEPT (Linux 2.4+)的支持

Nginx 架构:
1.默认采用多进程后台模式启动,可以手动配置成单进程前台模式用于调试,进程数一般和cpu内核数相同,太多进程会导致竞争cpu资源,带来不必要的上下文切换
2.发送kill -HUP pid的信号给master进程,master进程会从新加载配置文件,启动新的worker进程,退出老的worker进程,也是-s reload所做的
3.在master进程建立好需要listen的 socket,然后fork出子进程,子进程抢accept_mutex的互斥锁,抢到的子进程进行 accept处理
4.每个子进程采用异步非阻塞事件处理, select/poll/epoll/kqueue的系统调用,设置超时时间,当事件没准备好时,放到 epoll 里面,事件准备好了,我们就去读写,当读写返回 EAGAIN(再试一次)时，我们将它再次加入到 epoll 里面,线程还是只有一个,在请求间进行不断的循环切换,这里的切换没有代价,只要内存够大就行
5.apache那种简单的多线程,每个请求会独占一个工作线程，当并发数上到几千时，就同时有几千的线程在处理请求占用内存大,线程间上下文切换占用的cpu开销大
6.事件处理通常包含,网络信号(异步非阻塞),信号,定时器(放在一颗维护定时器的红黑树里面)

nginx的connection
1.主进程监听端口创建socket,fork出子进程,子进程互斥锁竞争accept新的连接,三次握手建立连接以后,异步非阻塞读写事件处理,nginx或客户端主动关掉连接
2.每个进程都有连接数的限制,ulimit -n,超过时创建socket会失败
3.nginx能建立的最大连接数 worker_连接数*worker_进程数;作为反向代理时则为worker_连接数*worker_进程数 /2 ,nginx也要请求另外的处理服务占用一个连接
4.利用accept_mutex锁来平衡每个worker进程的连接数

nginx与keepalive
1.http1.0和http1.1都支持长连接,默认1.0是关闭的,1.1是打开的
2.http1.0需要指定Connection:keep-alive表示使用长连接,响应头中会包含content-length,客户端依据这个长度表示接收完成,否则会一直接收数据
3.http1.1不需要指定connection,响应头中Transfer-encoding 为 chunked则会是流式传输,每块会包含当前块的长度;如果非chunked则要有content-length,否则会一直接收直到服务端主动断开
4.keepalive_timeout 来配置超时时间,如果为0则会直接关闭,默认65秒

1. prefork 中没有线程的概念，是多进程模型，一个进程处理一个连接；稳定；响应快。其缺点是在连接数比较大时就非常消耗内存。
2. worker 是多进程多线程模型，一个进程有多个线程，每个线程处理一个连接。与prefork相比，worker模式更节省系统的内存资源。不过，需要注意worker模式下的Apache与php等程序模块的兼容性。
3. event 是worker模式的变种，它把服务进程从连接中分离出来,在开启KeepAlive的场合下相对worker模式能够承受更高的并发负载,不能很好的支持https的访问
4.apache使用mod_php的话,不能使用worker模式,不是线程安全的