C++博客-ifeng-随笔分类-linux

FastCGI运行模型学习总结

冷锋 — Thu, 05 Jan 2012 08:58:00 GMT

FastCGI的工作原理

1、Web Server启动时载入FastCGI进程管理器（IIS ISAPI或Apache Module)

2、FastCGI进程管理器自身初始化，启动多个CGI解释器进程(可见多个php-cgi)并等待来自Web Server的连接。

3、当客户端请求到达Web Server时，FastCGI进程管理器选择并连接到一个CGI解释器。Web server将CGI环境变量和标准输入发送到FastCGI子进程php-cgi。

4、FastCGI子进程完成处理后将标准输出和错误信息从同一连接返回Web Server。当FastCGI子进程关闭连接时，请求便告处理完成。FastCGI子进程接着等待并处理来自FastCGI进程管理器(运行在Web Server中)的下一个连接。在CGI模式中，php-cgi在此便退出了。

在上述情况中，你可以想象CGI通常有多慢。每一个Web请求PHP都必须重新解析php.ini、重新载入全部扩展并重初始化全部数据结构。使用FastCGI，所有这些都只在进程启动时发生一次。一个额外的好处是，持续数据库连接(Persistent database connection)可以工作。

这个很容易找到。也容易理解，但是继续google之后，发现自己的概念又模糊了。

比如有些例子用

spawn-fcgi

/usr/local/bin/spawn-fcgi -a 127.0.0.1 -p 9000 -C 5 -u root -g root -f /usr/bin/php-cgi

参数含义如下

-f 指定调用FastCGI的进程的执行程序位置，根据系统上所装的PHP的情况具体设置
-a 绑定到地址addr
-p 绑定到端口port
-s 绑定到unix socket的路径path
-C 指定产生的FastCGI的进程数，默认为5（仅用于PHP）
-P 指定产生的进程的PID文件路径
-u和-g FastCGI使用什么身份（-u 用户 -g 用户组）运行，Ubuntu下可以使用www-data，其他的根据情况配置，如nobody、apache等

刚看到FastCGI原理的时候，我想象中的运行模型是，前端的反向代理服务器如Nginx收到请求，然后转发给cgi进程，这个cgi进程有N个，从而实现并发处理。但是接下来搜索到的C语言实现的FastCGI应用的例子好像又把这个模型给否定了。并且fastcgi是语言无关的，难道你要用python写并发？

#include "fcgi_stdio.h"
#include
int count;
void initialize(void)
{
    count=0;
}
void main(void)
{
initialize();

while (FCGI_Accept() >= 0)   {
   printf("Content-type: text/html“r“n"
     "“r“n"
     "FastCGI Hello! (C, fcgi_stdio library)"
     "

FastCGI Hello! (C, fcgi_stdio library)

"
     "Request number %d running on host %s“n",
     ++count, getenv("SERVER_HOSTNAME"));
    }
}

这个代码看不出来有任何并发处理的部分。比如fork什么的。

另外一种模型就是有一种叫做FastCGI进程管理器的进程，就像上面说的是管理fastcgi进程的进程，请求转发到管理器的时候，由它来进行选择相应的应用进程，卡就卡在这了，这个管理器是怎么来选择进程的啊，假如我有N个不同逻辑的可执行文件，它怎么知道要转发给哪个进程呢，google到的fastcgi配置都是针对反向代理的后端也即管理器设置的，没有发现有针对不同逻辑发给不同的应用进程的部分。

继续狂搜，还是无果，都是类似的文章。网上搜索不到的问题，要么就是很难很偏，要么就是很简单，简单到不值一提，很显然，我属于后者。转换思路，开始考虑假如要自己来实现这个功能的话该怎么办。一步步地推理，在结合搜索到的文章，大概理清了思路，我的理解如下，不对的地方请指正。

1.有一个CGI进程管理器，这个管理器一般是用第3方的fastcgi开发套件，比如上面提到的spawn-fcgi ，用它可以启动指定可执行文件的N个实例，关于之前选择进程的疑问，这里可以得到解释，那就是多个进程只是同一个可执行文件的实例，假如你想把不同的模块分开生成可执行文件的话估计就得再启动多一个管理器了吧。

2.假如你是用python写的fastcgi的应用程序，那么当你用管理器启动了100个实例的时候，也就相当于启动了100个python解析器，如果是用C等静态语言写的话那还好，只是跟你写的程序大小有关。

可能是没有接触过CGI程序的原因，让我对这基本的模型都纠结了一下午，希望这篇文章能帮些初学者。

冷锋 2012-01-05 16:58 发表评论

服务器多线程方案的选择

冷锋 — Sun, 20 Nov 2011 14:35:00 GMT

最近想写个多线程模型的服务器，但是一直纠结要选哪种方式，参考了memcached，但是觉得不完美.

备选方案，当然这些都是NIO

1.一个IO线程，专门处理连接读写数据，一个逻辑线程，专门处理数据。

2.一个IO线程，一个线程池，可任意配置线程池的数量。

先考虑1，假设连接层用epoll的ET模式实现，当IO线程发生可读事件时，必须把接收缓冲区的数据全部收完，一直read直到发生EAGAIN错误，否则就必须自己在上层维护一个可读队列。

方法a:每收到一个协议包，就转发给逻辑处理.处理完再接着收取剩下的包。但是TCP是无边界的，有可能收到0.5个或者2.5个包，这时你得为每个连接准备个buf,并且每收到个包都要跟逻辑线程同步加锁一次,还有个很大的弊端就是，连接层已经跟逻辑协议相关了，这似乎不是很好。

方法b:IO线程把所有数据都收完再通知逻辑线程。当然这样也无法避免收到半个协议包的情况，所以我是想维护一个recv到的数据队列，IO线程把每次收到的包都丢到这个队列。

a,b2种方法都面临着send的麻烦，现在send也有以下方案.

方法a.每次需要write的时候就直接send发不完的就加到发送队列中去。在发送前必须要先判断一下队列是不是空，如果不为空就必须先处理队列，剩余数据待可读事件发生时再处理，于是脑子中又出现一大堆锁了。有2个线程可能对socket进行写操作。

方法b.每次需要send的时候都直接把数据丢到发送队列去，等到可读事件到来时再尽量把队列都发送完。但是响应可能没那么迅速了。

这两种方法都必须为每个数据包增加一个标识TCP连接的字段，因为socket fd是可以重复使用的，比如用户A连接分配的socket是100，逻辑线程正在为A处理数据，但是用户A断开连接了，同时立即有另外个用户连接进来并且分配的socket是100，这时悲剧就发生了。

再考虑下线程池的2种情况.

a.主线程负责IO，包括处理连接，读写，把读到的数据加入recv队列，子线程把需要写的加入send队列.

这个方案有个很大的缺陷：无法保证先到的请求先返回，这是很致命的，只能通过客户端来确保收到前一个请求的结果以后再发送下一个请求。

b.主线程只负责监听连接，收到连接到来事件后，通知线程池去accept连接，因此每个连接的数据都会由同一个线程处理，也就保证了顺序，但是这样的话子线程就必须承担起IO的任务了，这样好像就有些分工不清了，这个是memcached中用的方案.

PS:用epoll的ET模式需要一直recv,这样有可能是使得活跃的连接占用了全部带宽，因此需要在上层对连接进行限速，因此也就需要维护可读事件了。

纠结好几天了，第一次写多线程服务器，一直为选方案纠结啊，我本人倾向于线程池，毕竟可以利用多核的优势啊。不知道大家实际上用的都是什么方案呢，非常想知道，请指教。
再PS：做了个小测试，nginx+memcached,下载一个700多K的文件，开100个线程，每个线程下载100次，全部命中跟全部不命中的情况几乎没有差别，这是为什么呢？难道linux系统本身就已经有cached了吗？

冷锋 2011-11-20 22:35 发表评论

有关TCP和UDP 粘包消息保护边界(转)

冷锋 — Fri, 11 Nov 2011 02:22:00 GMT

在socket网络程序中，TCP和UDP分别是面向连接和非面向连接的。因此TCP的socket编程，收发两端（客户端和服务器端）都要有一一成对的socket，因此，发送端为了将多个发往接收端的包，更有效的发到对方，使用了优化方法（Nagle算法），将多次间隔较小且数据量小的数据，合并成一个大的数据块，然后进行封包。这样，接收端，就难于分辨出来了，必须提供科学的拆包机制。

对于UDP，不会使用块的合并优化算法，这样，实际上目前认为，是由于UDP支持的是一对多的模式，所以接收端的skbuff(套接字缓冲区）采用了链式结构来记录每一个到达的UDP包，在每个UDP包中就有了消息头（消息来源地址，端口等信息），这样，对于接收端来说，就容易进行区分处理了

保护消息边界和流

那么什么是保护消息边界和流呢?

保护消息边界，就是指传输协议把数据当作一条独立的消息在网上

传输,接收端只能接收独立的消息.也就是说存在保护消息边界,接收

端一次只能接收发送端发出的一个数据包.

而面向流则是指无保护消息保护边界的,如果发送端连续发送数据,

接收端有可能在一次接收动作中,会接收两个或者更多的数据包.

我们举个例子来说,例如,我们连续发送三个数据包,大小分别是2k,

4k , 8k,这三个数据包,都已经到达了接收端的网络堆栈中,如果使

用UDP协议,不管我们使用多大的接收缓冲区去接收数据,我们必须有

三次接收动作,才能够把所有的数据包接收完.而使用TCP协议,我们

只要把接收的缓冲区大小设置在14k以上,我们就能够一次把所有的

数据包接收下来.只需要有一次接收动作.

这就是因为UDP协议的保护消息边界使得每一个消息都是独立的.而

流传输,却把数据当作一串数据流,他不认为数据是一个一个的消息.

所以有很多人在使用tcp协议通讯的时候,并不清楚tcp是基于流的

传输,当连续发送数据的时候,他们时常会认识tcp会丢包.其实不然,

因为当他们使用的缓冲区足够大时,他们有可能会一次接收到两个甚

至更多的数据包,而很多人往往会忽视这一点,只解析检查了第一个

数据包,而已经接收的其他数据包却被忽略了.所以大家如果要作这

类的网络编程的时候,必须要注意这一点.

结论：

根据以上所说，可以这样理解，TCP为了保证可靠传输，尽量减少额外

开销（每次发包都要验证），因此采用了流式传输，面向流的传输，

相对于面向消息的传输，可以减少发送包的数量。从而减少了额外开

销。但是，对于数据传输频繁的程序来讲，使用TCP可能会容易粘包。

当然，对接收端的程序来讲，如果机器负荷很重，也会在接收缓冲里

粘包。这样，就需要接收端额外拆包，增加了工作量。因此，这个特

别适合的是数据要求可靠传输，但是不需要太频繁传输的场合（

两次操作间隔100ms，具体是由TCP等待发送间隔决定的，取决于内核

中的socket的写法）

而UDP，由于面向的是消息传输，它把所有接收到的消息都挂接到缓冲

区的接受队列中，因此，它对于数据的提取分离就更加方便，但是，

它没有粘包机制，因此，当发送数据量较小的时候，就会发生数据包

有效载荷较小的情况，也会增加多次发送的系统发送开销（系统调用，

写硬件等）和接收开销。因此，应该最好设置一个比较合适的数据包

的包长，来进行UDP数据的发送。（UDP最大载荷为1472，因此最好能

每次传输接近这个数的数据量，这特别适合于视频，音频等大块数据

的发送，同时，通过减少握手来保证流媒体的实时性）

冷锋 2011-11-11 10:22 发表评论

一致性hash算法

冷锋 — Tue, 18 Oct 2011 05:49:00 GMT

http://hbluojiahui.blog.163.com/blog/static/31064767201098114026211/

冷锋 2011-10-18 13:49 发表评论

mysql字符串转义函数

冷锋 — Mon, 17 Oct 2011 03:43:00 GMT

在mysql插入数据表，如果数据中带有'\“会造成语法错误，这个不用解释，你懂的，因此需要写个转义函数，一开始想直接用string的replace，但是这个方法要调用3次

放在服务端感觉效率太低了，于是用C写了个，感觉还可以，时间复杂度跟需要转义字符的个数无关，如果源串没有匹配的话不需要copy操作.
//转义函数,‘转成\'

bool ConverToDBStr( const char* src,char*dst )
{
    int i = -1;//记录上次匹配的位置
    int dOffset = 0;//目标字符串游标
    int nCopy = 0;//本次需要成 copy的字节数
    const char*p = src;
    while( *p )
    {
        if( *p=='\\'||*p=='\''||*p=='"' )
        {
            nCopy = p-src-i-1;
            memcpy( dst+dOffset,src+i+1,nCopy );
            dOffset+=nCopy;
            *(dst+Offset)='\\';
            *(dst+dOffset+1)=*p;
            dOffset+=2;
            i = p-src;
        }
        p++;
    }
    if( dOffset>0 )//有匹配到，copy最后的字符串
    {
        memcpy( dst+dOffset,src+i+1,p-src-i );
        return true;
    }
    return false;

}
可以看到，这个函数稍微改动下就可以实现replace

冷锋 2011-10-17 11:43 发表评论

nginx笔记

冷锋 — Fri, 30 Sep 2011 01:45:00 GMT

ngx_connection_t,抽象的连接，在core模块的ngx_event_process_init 函数中预先分配好。ngx_event_process_init预分配connects，read\write 事件的数组，

并依次初始化，并依次初始化各连接的链表关系，也就是在data上存下一个connection的指针
cycle->connections =
        ngx_alloc(sizeof(ngx_connection_t) * cycle->connection_n, cycle->log);
    if (cycle->connections == NULL) {
        return NGX_ERROR;
    }
.

c = cycle->connections;
.
    do {
        i--;

        c[i].data = next;
        c[i].read = &cycle->read_events[i];
        c[i].write = &cycle->write_events[i];
        c[i].fd = (ngx_socket_t) -1;
        next = &c[i];
#if (NGX_THREADS)
        c[i].lock = 0;
#endif
    } while (i);
    cycle->free_connections = next;
    cycle->free_connection_n = cycle->connection_n;

//初始化linsten socket，并设置listen的处理函数为 rev->handler = ngx_event_acceptex;
Rev->accept=1;
for (i = 0; i < cycle->listening.nelts; i++) {

        c = ngx_get_connection(ls[i].fd, cycle->log);

        if (c == NULL) {
            return NGX_ERROR;
        }
}（结构体部分成员）

struct ngx_connection_s {
    void               *data;
    ngx_event_t        *read;//读事件处理
    ngx_event_t        *write;//写事件处理
    ngx_socket_t        fd;//连接对应的socket
    ngx_listening_t    *listening;/

    ngx_log_t          *log;

    ngx_pool_t         *pool;

         //平台相关的读写，对应socket的send,recv
        ngx_recv_pt         recv;
    ngx_send_pt         send;

    struct sockaddr    *sockaddr;//地址
    socklen_t           socklen;
    ngx_str_t           addr_text;
}

ngx_get_connection:从freeconnect队头取出一个connection,并将socket绑定此connection

在上层应用（比如HTTP），使用ngx_handle_read_event(ngx_event_t *rev, ngx_uint_t flags)加入读事件。

在ngx_epoll_process_events函数中，
if (flags & NGX_POST_EVENTS) {
                ngx_locked_post_event(wev, &ngx_posted_events);

            } else {
                wev->handler(wev);
            }

如果带有NGX_POST_EVENTS标记，就把事件投递到队列中不立即处理。
在ngx_process_events_and_timers 中，会在每个循环调用ngx_event_process_posted(cycle, &ngx_posted_events);不断取出事件队列进行处理。
NGX_POST_EVENTS是为了进行耗时操作前先释放进程锁，放入队列稍后再处理(用进程锁应该是避免N个进程accept导致的惊群，新版linux已经不会出现这个问题)。
  if (ngx_posted_events) {
        if (ngx_threaded) {
            ngx_wakeup_worker_thread(cycle);

        } else {
            ngx_event_process_posted(cycle, &ngx_posted_events);
        }
    }

冷锋 2011-09-30 09:45 发表评论

EPOLL下的accept(转载)

冷锋 — Thu, 29 Sep 2011 09:08:00 GMT

摘要: （转载者注：看完这个，再回头看看nginx源码，发现它在accept时用的是LT模式，read,write时是ET模式）不知道是谁第一个犯了错，在网上贴出所谓epoll通用框架的代码。注意看accpet的处理：1epfd = epoll_create(10);2 3struct sockaddr_in clientaddr;4struct sockaddr_in se... 阅读全文

冷锋 2011-09-29 17:08 发表评论

nginx源码简单分析

冷锋 — Tue, 27 Sep 2011 03:26:00 GMT

由于工作需要，分析了nginx的连接层事件处理模块，只是初步的大体分析。

mian函数(nginx.c)里面做一些初始化的工作，最主要的部分，是调用ngx_init_cycle，ngx_master_process_cycle（主进程循环），
ngx_init_cycle主要是做一些初始化的工作，包括调用ngx_open_listening_sockets打开socket端口监听等。
ngx_master_process_cycle函数中，先设置一下需要阻塞的信号，然后是调用ngx_start_worker_processes函数创建worker进程，然后进入一个死循环。里面应该是管理worker进程的，主循环里面调用了sigsuspend函数挂起等待信号，具体怎么管理还没研究。

ngx_start_worker_processes：调用ngx_spawn_process，循环创建N个worker进程
ngx_spawn_process：调用socketpair创建用于父子进程通信的socket,里面进行了一大堆socket参数设置，然后调用worker进程的主循环ngx_worker_process_cycle，
然后主进程设置进程表相应信息。
ngx_worker_process_cycle：先调用ngx_worker_process_init初始化进程，里面应该是设置成守护进程等等，有初始化模块信息，关闭对等socket的其中一个channel,其中比较关键的是调用ngx_add_channel_event。里面调用ngx_get_connection返回一个free的ngx_connection_t,最关键的是ngx_add_conn，其对应到epoll模块的ngx_epoll_add_connection，在这里就是添加相应的监听socket进监听队列，并设置连接为激活状态，可以看到这里epoll是用的ET模式。

接下来在ngx_worker_process_cycle中，检查是否配置了多线程模式，如果有，就创建多线程，我只关注多进程，因此先无视它，关键点是调用ngx_process_events_and_timers函数，
ngx_process_events_and_timers：调用ngx_process_events和ngx_event_process_posted，
ngx_process_events对应是ngx_epoll_process_events，这里会调用epoll_wait，就跟平常的epoll使用一样。
ngx_event_process_posted(cycle, &ngx_posted_accept_events);处理accept队列中所有事件，ngx_posted_accept_events没有找到初始化的地方，估计是编译脚本自动生成的，估计会对应到ngx_event_accept函数进行处理，里面就是普通的accept操作，返回fd,并生成一条ngx connection,然后调用ngx_add_conn加入epoll监听队列。
至此，整个流程完成。
虽然还有很多地方不懂，但总算了解了大体流程了。以上分析不保证正确，仅供参考，仅作为个人学习笔记，欢迎指正。

冷锋 2011-09-27 11:26 发表评论