Nginx SPDY patch实现

前不久Nginx官方放出了SPDY的patch，到目前为止都还未合并进nginx源码，主要还是由于此patch还远不成熟，代码和功能都还不足够完善。个人感觉spdy patch合并进nginx源码还有些时日。本文是基于目前的patch，初窥一下nginx官方是如何在实现spdy。

上图是nginx处理一个请求的大致流程，这里只是绘制了简单的模型，实际过程还是相当的复杂的。图中红色部分即是SPDY patch的主要内容。

针对普通的http请求，nginx是采用了一个状态机来流式的解析http协议，（所谓流式解析就是“收到一个字节就解析一个字节“，不必一定要收齐多少字节才开始解析），最终将请求的所有数据存储到一个request对象中，在接下来的handler模块中，就可以处理这个request对象了。一个请求的处理工作完成后，就开始经过一层一层的filter模块将响应给发出去。

面对一个spdy请求，nginx总体处理流程和http请求一样，主要不同的地方就是请求的解析器变了，但spdy的解析结果也是完全的将数据存储到普通http使用的request对象中，并没有引入一个新的spdy request对象，这就有点像是将spdy请求透明的转化为http请求。也只有将spdy请求转化为http请求，目前的所有handler、filter模块才能够正常的工作。由于经过handler、filter模块后的响应是一个http的响应，所以必须引入一个spdy filter模块将http响应的内容组装成一个spdy的帧消息来应答客户端。

下面再继续看看SPDY解析处理过程的细节，spdy filter模块做的事情比较简单，本文就暂且忽略了。

看过nginx源码的读者应该都知道客户端发送一个请求给nginx时，nginx首先将被调用的一个函数是ngx_http_init_request，在此函数中重点关注如下代码段：

#if (NGX_HTTP_SSL)    {    ngx_http_ssl_srv_conf_t  *sscf;    sscf = ngx_http_get_module_srv_conf(r, ngx_http_ssl_module);    if (sscf->enable || addr_conf->ssl) {        if (c->ssl == NULL) {            c->log->action = "SSL handshaking";            if (addr_conf->ssl && sscf->ssl.ctx == NULL) {                ngx_log_error(NGX_LOG_ERR, c->log, 0,                              "no \"ssl_certificate\" is defined "                              "in server listening on SSL port");                ngx_http_close_connection(c);                return;            }#if (NGX_HTTP_SPDY)            if (addr_conf->spdy) {                r->spdy_stream = (void *) 1; //FIXME            }#endif            if (ngx_ssl_create_connection(&sscf->ssl, c, 0) // NGX_SSL_BUFFER) FIXME                != NGX_OK)            {                ngx_http_close_connection(c);                return;            }            rev->handler = ngx_http_ssl_handshake;        }        r->main_filter_need_in_memory = 1;    }    }#endif

由于spdy是强制ssl的，所以必须走这段逻辑，然后进入ngx_http_ssl_handshake过程完成ssl的握手认证。这些过程也只是普通的https请求需要经历步奏罢了，那么在整个ssl握手完成后，nginx是如何判断此请求时https还是spdy呢？看下面一段代码：

static voidngx_http_ssl_handshake_handler(ngx_connection_t *c){    ngx_http_request_t  *r;    r = c->data;#if (NGX_HTTP_SPDY)    r->spdy_stream = NULL; //FIXME#endif    if (c->ssl->handshaked) {        /*         * The majority of browsers do not send the "close notify" alert.         * Among them are MSIE, old Mozilla, Netscape 4, Konqueror,         * and Links.  And what is more, MSIE ignores the server's alert.         *         * Opera and recent Mozilla send the alert.         */        c->ssl->no_wait_shutdown = 1;#if (NGX_HTTP_SPDY)        {        unsigned       len;        const u_char  *data;// 这个地方就是使用TLS-NPN扩展获取spdy协议的判断，也是spdy请求的处理入口。// NPN在spdy介绍中已经提到，是google特地为spdy的部署而开发的一个tls扩展协议。        SSL_get0_next_proto_negotiated(c->ssl->connection, &data, &len);        if (len == sizeof("spdy/2") - 1            && ngx_memcmp(data, "spdy/2", sizeof("spdy/2") - 1) == 0)        {#if (NGX_STAT_STUB)            (void) ngx_atomic_fetch_add(ngx_stat_reading, -1);            (void) ngx_atomic_fetch_add(ngx_stat_requests, -1);#endif            c->data = c; //FIXME// 初始化spdy，开始真正的进入spdy处理过程。            ngx_http_init_spdy(c->read);            return;        }        }#endif        c->log->action = "reading client request line";        c->read->handler = ngx_http_process_request_line;        /* STUB: epoll edge */ c->write->handler = ngx_http_empty_handler;        ngx_http_process_request_line(c->read);        return;    }    ngx_http_close_request(r, NGX_HTTP_BAD_REQUEST);    return;}

此函数式ssl握手完成后，开始进入真正的请求数据处理的入口函数。经过SSL_get0_next_proto_negotiated识别为spdy后，就开始真正的进入spdy处理过程了。省略性的看看ngx_http_init_spdy最后的几行关键代码。

voidngx_http_init_spdy(ngx_event_t *rev){  //    。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。    一开始基本都在初始化zlib相关，为请求和响应的压缩和解压做好准备。  //// 这里挂载了事件回调函数，接下来将重点关注读事件上挂载的回调，这个过程将完成spdy请求的解析。    rev->handler = ngx_http_spdy_read_handler;    c->write->handler = ngx_http_spdy_write_handler;    ngx_http_spdy_read_handler(rev);}

在spdy请求解析过程中，读事件rev上始终挂载着ngx_http_spdy_read_handler这个回调函数，它的作用当然就是读事件发生的时候，从socket上读出数据，然后把数据交给spdy解析器。 在ngx_http_spdy_read_handler函数中有如下一代码段：

        do {// sc 是一个ngx_http_spdy_connection_t结构，抽象的是一个tcp连接。这里调用的handler// 就是此刻挂载的spdy解析器。不同的frame消息这里将会挂载不同的解析器。            rc = sc->handler(sc, &p, n);            n = end - p;            if (rc == NGX_AGAIN) {                ngx_memcpy(sc->buffer, p, NGX_SPDY_STATE_BUFFER_SIZE);                break;            }            if (rc == NGX_ERROR) {                ngx_log_error(NGX_LOG_WARN, c->log, 0, "SPDY ERROR");                ngx_http_spdy_finalize_connection(sc,                                               NGX_HTTP_INTERNAL_SERVER_ERROR);                return;            }        } while (n);

本文提到的spdy解析器，就是处理spdy不同frame的函数，不了解frame的可以看看我写的Google spdy介绍。frame处理的入口是ngx_http_spdy_process_frame：

static ngx_int_tngx_http_spdy_process_frame(ngx_http_spdy_connection_t *sc, u_char **pos,    size_t size){    u_char                  *p, flags;    size_t                   length;    uint32_t                 head;    ngx_http_spdy_stream_t  *stream;// frame的8个字节头部信息没有读完整，返回去继续等待数据。这就不是流式解析了，因为此处一定要满足8字节后才开始解析过程。    if (size < 8) {        return NGX_AGAIN;    }    p = *pos;// 将头4字节转化为一个整数再进行比较判断，因为头4字节决定了frame的类型。#if (NGX_HAVE_NONALIGNED)    head = *(uint32_t *) p;#else    head = p[0] << 24 | p[1] << 16 | p[2] << 8 | p[3];#endif// 取第5字节的flags域和最后3个字节的长度域。    flags = p[4];    length = ngx_spdy_frame_parse_len(p + 5);    sc->length = length;    sc->flags = flags;    ngx_log_debug3(NGX_LOG_DEBUG_HTTP, sc->connection->log, 0,                   "spdy process frame head:%ui f:%ui l:%ui",                   head, flags, length);    *pos += 8;// 这里就是根据frame的类型，挂载不同的frame解析器。switch中列举的case全部是control frame。这里有如此之多的TODO，就可以看出spdy patch的代码还不完善。    switch (head) {    case NGX_SPDY_SYN_STREAM_HEAD:        sc->handler = ngx_http_spdy_process_syn_stream;        return NGX_OK;    case NGX_SPDY_SYN_REPLY_HEAD:        //TODO log        return NGX_ERROR;    case NGX_SPDY_RST_STREAM_HEAD:        sc->handler = ngx_http_spdy_process_rst_stream;        return NGX_OK;    case NGX_SPDY_SETTINGS_HEAD:        //TODO        sc->handler = ngx_http_spdy_skip_frame;        return NGX_OK;    case NGX_SPDY_NOOP_HEAD:        if (flags != 0 || length != 0) {            //TODO log            return NGX_ERROR;        }        return NGX_OK;    case NGX_SPDY_PING_HEAD:        sc->handler = ngx_http_spdy_process_ping;        return NGX_OK;    case NGX_SPDY_GOAWAY_HEAD:        //TODO        sc->handler = ngx_http_spdy_skip_frame;        return NGX_OK;    case NGX_SPDY_HEADERS_HEAD:        //TODO log        return NGX_ERROR;    }// 到此说明收到的frame不是control frame，而是data frame，所以下面开始data frame的逻辑。    head = ntohl(head);// 判断control和data frame的标志位是否是0，不是0此时就是非法的，需要忽略此frame消息。    if (head >> 31) {        //TODO version & type check        ngx_log_debug1(NGX_LOG_DEBUG_HTTP, sc->connection->log, 0,                       "spdy unknown frame %ui", head);        sc->handler = ngx_http_spdy_skip_frame;        return NGX_OK;    }// 根据头中的sid判断此data frame属于哪个stream。     stream = ngx_http_spdy_get_stream_by_id(sc, head);    if (stream == NULL || stream->request->discard_body) {        sc->handler = ngx_http_spdy_skip_frame;        return NGX_OK;    }    if (stream->half_closed) {        //TODO log && error handling        return NGX_ERROR;    }// 挂载data frame解析器，开始着手解析data frame。    sc->stream = stream;    sc->handler = ngx_http_spdy_process_data_frame;    return ngx_http_spdy_process_data_frame(sc, pos, size - 8); //FIXME}

到此处就完成frame的判断，这是所有frame的入口之处，接下去就是执行一个frame解析器解析具体的frame了。SYN_STREAM control frame正是创建一个stream，开始发起一个请求，下面就看看这个frame的处理过程，其他的frame就不在本文分析了。

static ngx_int_tngx_http_spdy_process_syn_stream(ngx_http_spdy_connection_t *sc, u_char **pos,    size_t size){    u_char                    *p;    ngx_uint_t                 sid, prio, index;    ngx_http_cleanup_t        *cln;    ngx_http_request_t        *r;    ngx_http_spdy_stream_t    *stream;    ngx_http_spdy_srv_conf_t  *sscf;// 这里又一个需要收齐数据才能处理的地方，这里的10个字节就是Stream-ID, Associated-To-Stream-ID以及优先级等。    if (size < 10) {        return NGX_AGAIN;    }    p = *pos;    sc->length -= 10;    *pos += 10;// 解析stream id和stream的优先级。    sid = ngx_spdy_frame_parse_sid(p);    prio = p[5] >> 2;    ngx_log_debug2(NGX_LOG_DEBUG_HTTP, sc->connection->log, 0,                   "spdy SYN_STREAM frame sid:%ui prio:%ui", sid, prio);    sscf = ngx_http_get_module_srv_conf(sc->default_request,                                        ngx_http_spdy_module);// sscf->concurrent_streams是配置文件里指定的每个连接上允许的最大并发stream个数。    if (sc->processing == sscf->concurrent_streams) {        ngx_http_spdy_send_rst_stream(sc, sid, NGX_SPDY_REFUSED_STREAM);        sc->handler = ngx_http_spdy_skip_headers;        return NGX_OK;    }// 创建好普通的http request对象。    r = ngx_http_spdy_create_request(sc);    if (r == NULL) {        return NGX_ERROR;    }// 创建一个新的stream。    stream = ngx_pcalloc(r->pool, sizeof(ngx_http_spdy_stream_t));    if (stream == NULL) {        return NGX_ERROR;    }    r->spdy_stream = stream;    stream->id = sid;    stream->request = r;    stream->connection = sc;    stream->priority = prio;// 注意此处，flags域设置了FIN_FLAG就表示此stream不会收到data frame了，也就是一个普通http get操作，没有body数据。所以此处将stream设置为half close状态。    stream->half_closed = sc->flags & NGX_SPDY_FLAG_FIN;。。。。。。。。。。。。。。。。。。。。。。。。    sc->stream = stream;// 解析来开始解析headers了。    sc->handler = ngx_http_spdy_process_headers;    return NGX_OK;}

现在开始解析headers，具体的解析过程这里不做分析，有兴趣的读者可以对照spdy协议draft文档去分析代码。我们就看看ngx_http_spdy_process_headers最后几行代码：

static ngx_int_tngx_http_spdy_process_headers(ngx_http_spdy_connection_t *sc, u_char **pos,    size_t size){    int                         z;    ngx_buf_t                  *buf;    ngx_int_t                   rc;    ngx_uint_t                  last;    ngx_table_elt_t            *h;    ngx_connection_t           *c;    ngx_http_request_t         *r; 。。。。。。。。。。。。。。。。。。。。。。。。。。。。。    sc->processing++;// 这里将要开始执行这个请求了，下面详细看看其过程。    ngx_http_spdy_run_request(r);// 这个frame处理完成后，就重置spdy解析器为frame判断入口回调函数，准备处理下一个frame。    sc->handler = ngx_http_spdy_process_frame;    return NGX_DONE;}static voidngx_http_spdy_run_request(ngx_http_request_t *r){    ngx_uint_t                  i;    ngx_list_part_t            *part;    ngx_table_elt_t            *h;    ngx_connection_t           *fc;    ngx_http_header_t          *hh;    ngx_http_core_main_conf_t  *cmcf;// 根据spdy的请求数据去构造普通http的请求行，这就是前面提到的spdy到http的转化过程。    if (ngx_http_spdy_construct_request_line(r) != NGX_OK) {        ngx_http_spdy_finalize_request(r, NGX_HTTP_INTERNAL_SERVER_ERROR);        return;    } 。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。    r->http_state = NGX_HTTP_PROCESS_REQUEST_STATE;// 处理header，也是在转化spdy到http。    if (ngx_http_process_request_header(r) != NGX_OK) {        return;    }    if (r->plain_http) {        ngx_log_error(NGX_LOG_INFO, fc->log, 0,                      "client sent plain HTTP request to HTTPS port");        ngx_http_spdy_finalize_request(r, NGX_HTTP_TO_HTTPS);        return;    }#if (NGX_STAT_STUB)    (void) ngx_atomic_fetch_add(ngx_stat_reading, -1);    r->stat_reading = 0;    (void) ngx_atomic_fetch_add(ngx_stat_writing, 1);    r->stat_writing = 1;#endif    r->write_event_handler = ngx_http_core_run_phases;// 开始执行请求，主要执行所有的phases阶段，这里就开始进入了普通http请求的流程了。// 接下去就是经过所有的handler，filter等模块流程。    ngx_http_core_run_phases(r);    ngx_http_run_posted_requests(fc);}

总结：

spdy patch的实现还是非常的清晰，主要目标就两个：1、是解析spdy frame，2、是转化为了http request。从代码可以看出此patch仅仅是一个初步的实现，还有很多的地方没有完善，后面nginx官网在实现上指不定还有大的调整也不奇怪。当然，spdy的server push等复杂又强大功能在此patch中根本还没有一点实现。