《深入理解Nginx:模块开发与架构解析》一3.7 发送响应

本文涉及的产品
全局流量管理 GTM,标准版 1个月
公共DNS(含HTTPDNS解析),每月1000万次HTTP解析
云解析 DNS,旗舰版 1个月
简介: 本节书摘来自华章出版社《深入理解Nginx:模块开发与架构解析》一书中的第3章,第3.7节,作者 陶辉,更多章节内容可以访问云栖社区“华章计算机”公众号查看

3.7 发送响应

请求处理完毕后,需要向用户发送HTTP响应,告知客户端Nginx的执行结果。HTTP响应主要包括响应行、响应头部、包体三部分。发送HTTP响应时需要执行发送HTTP头部(发送HTTP头部时也会发送响应行)和发送HTTP包体两步操作。本节将以发送经典的“Hello World”为例来说明如何发送响应。

3.7.1 发送HTTP头部

下面看一下HTTP框架提供的发送HTTP头部的方法,如下所示。

ngx_int_t ngx_http_send_header(ngx_http_request_t *r);

调用ngx_http_send_header时把ngx_http_request_t对象传给它即可,而ngx_http_request_t的返回值是多样的,在本节中,可以认为返回NGX_ERROR或返回值大于0就表示不正常,例如:

ngx_int_t  rc = ngx_http_send_header(r);
if (rc == NGX_ERROR || rc > NGX_OK || r->header_only) {
    return rc;
}

下面介绍设置响应中的HTTP头部的过程。
如同headers_in,ngx_http_request_t也有一个headers_out成员,用来设置响应中的HTTP头部,如下所示。

struct ngx_http_request_s {
    …
    ngx_http_headers_in_t             headers_in;
    ngx_http_headers_out_t            headers_out;
    …
};

只要指定headers_out中的成员,就可以在调用ngx_http_send_header时正确地把HTTP头部发出。下面介绍headers_out的结构类型ngx_http_headers

_out_t。
typedef struct {
    //待发送的HTTP头部链表,与headers_in中的headers成员类似
    ngx_list_t                        headers;

/响应中的状态值,如200表示成功。这里可以使用3.6.1节中介绍过的各个宏,如NGX_HTTP_OK /

ngx_uint_t                        status;
    //响应的状态行,如“HTTP/1.1 201 CREATED”
    ngx_str_t                         status_line;

/以下成员(包括ngx_table_elt_t)都是RFC1616规范中定义的HTTP头部,设置后,ngx_http_header_filter_module过滤模块可以把它们加到待发送的网络包中/

ngx_table_elt_t                  *server;
   ngx_table_elt_t                  *date;
   ngx_table_elt_t                  *content_length;
   ngx_table_elt_t                  *content_encoding;
   ngx_table_elt_t                  *location;
   ngx_table_elt_t                  *refresh;
   ngx_table_elt_t                  *last_modified;
   ngx_table_elt_t                  *content_range;
   ngx_table_elt_t                  *accept_ranges;
   ngx_table_elt_t                  *www_authenticate;
   ngx_table_elt_t                  *expires;
   ngx_table_elt_t                  *etag;

   ngx_str_t                        *override_charset;

/可以调用ngx_http_set_content_type(r)方法帮助我们设置Content-Type头部,这个方法会根据URI中的文件扩展名并对应着mime.type来设置Content-Type值/

size_t                            content_type_len;
   ngx_str_t                         content_type;
   ngx_str_t                         charset;
   u_char                           *content_type_lowcase;
   ngx_uint_t                        content_type_hash;

   ngx_array_t                       cache_control;

/在这里指定过content_length_n后,不用再次到ngx_table_elt_t content_ length中设置响应长度*/

off_t                             content_length_n;
    time_t                            date_time;
    time_t                            last_modified_time;
} ngx_http_headers_out_t;

在向headers链表中添加自定义的HTTP头部时,可以参考3.2.3节中ngx_list_push的使用方法。这里有一个简单的例子,如下所示。

ngx_table_elt_t* h = ngx_list_push(&r->headers_out.headers);
if (h == NULL) {
    return NGX_ERROR;
}
h->hash = 1;
h->key.len = sizeof("TestHead") - 1;
h->key.data = (u_char *) "TestHead";
h->value.len = sizeof("TestValue") - 1;
h->value.data = (u_char *) "TestValue";

这样将会在响应中新增一行HTTP头部:

TestHead: TestValud\r\n

如果发送的是一个不含有HTTP包体的响应,这时就可以直接结束请求了(例如,在ngx_http_mytest_handler方法中,直接在ngx_http_send_header方法执行后将其返回值return即可)。
注意 ngx_http_send_header方法会首先调用所有的HTTP过滤模块共同处理headers_out中定义的HTTP响应头部,全部处理完毕后才会序列化为TCP字符流发送到客户端,相关流程可参见11.9.1节。

3.7.2 将内存中的字符串作为包体发送

调用ngx_http_output_filter方法即可向客户端发送HTTP响应包体,下面查看一下此方法的原型,如下所示。
ngx_int_t ngx_http_output_filter(ngx_http_request_t r, ngx_chain_t in);
ngx_http_output_filter的返回值在mytest例子中不需要处理,通过在ngx_http_mytest_handler方法中返回的方式传递给ngx_http_finalize_request即可。ngx_chain_t结构已经在3.2.6节中介绍过,它仅用于容纳ngx_buf_t缓冲区,所以需要先了解一下如何使用ngx_buf_t分配内存。下面介绍Nginx的内存池是如何分配内存的。
为了减少内存碎片的数量,并通过统一管理来减少代码中出现内存泄漏的可能性,Nginx设计了ngx_pool_t内存池数据结构。本章我们不会深入分析内存池的实现,只关注内存池的用法。在ngx_http_mytest_handler处理方法传来的ngx_http_request_t对象中就有这个请求的内存池管理对象,我们对内存池的操作都可以基于它来进行,这样,在这个请求结束的时候,内存池分配的内存也都会被释放。

struct ngx_http_request_s {
    …
    ngx_pool_t *pool;
    …
};

实际上,在r中可以获得许多内存池对象,这些内存池的大小、意义及生存期各不相同。第3部分会涉及许多内存池,本章使用r->pool内存池即可。有了ngx_pool_t对象后,可以从内存池中分配内存。例如,下面这个基本的申请分配内存的方法:

void *ngx_palloc(ngx_pool_t *pool, size_t size);

其中,ngx_palloc函数将会从pool内存池中分配到size字节的内存,并返回这段内存的起始地址。如果返回NULL空指针,则表示分配失败。还有一个封装了ngx_palloc的函数ngx_pcalloc,它多做了一件事,就是把ngx_palloc申请到的内存块全部置为0,虽然,多数情况下更适合用ngx_pcalloc来分配内存。
假如要分配一个ngx_buf_t结构,可以这样做:

ngx_buf_t* b = ngx_pcalloc(r->pool, sizeof(ngx_buf_t));

这样,ngx_buf_t中的成员指向的内存仍然可以继续分配,例如:

b->start = (u_char*)ngx_pcalloc(r->pool, 128);
b->pos = b->start;
b->last = b->start;
b->end = b->last + 128;
b->temporary = 1;

实际上,Nginx还封装了一个生成ngx_buf_t的简便方法,它完全等价于上面的6行语句,如下所示。

ngx_buf_t *b = ngx_create_temp_buf(r->pool, 128);

分配完内存后,可以向这段内存写入数据。当写完数据后,要让b->last指针指向数据的末尾,如果b->last与b->pos相等,那么HTTP框架是不会发送一个字节的包体的。
最后,把上面的ngx_buf_t *b用ngx_chain_t传给ngx_http_output_filter方法就可以发送HTTP响应的包体内容了。例如:

ngx_chain_t out;
out.buf = b;
out.next = NULL;

return ngx_http_output_filter(r, &out);

注意 在向用户发送响应包体时,必须牢记Nginx是全异步的服务器,也就是说,不可以在进程的栈里分配内存并将其作为包体发送。当ngx_http_output_filter方法返回时,可能由于TCP连接上的缓冲区还不可写,所以导致ngx_buf_t缓冲区指向的内存还没有发送,可这时方法返回已把控制权交给Nginx了,又会导致栈里的内存被释放,最后就会造成内存越界错误。因此,在发送响应包体时,尽量将ngx_buf_t中的pos指针指向从内存池里分配的内存。

3.7.3 经典的“Hello World”示例

下面以经典的返回“Hello World”为例来编写一个最小的HTTP处理模块,以此介绍完整的ngx_http_mytest_handler处理方法。

static ngx_int_t ngx_http_mytest_handler(ngx_http_request_t *r)
{
    //必须是GET或者HEAD方法,否则返回405 Not Allowed
    if (!(r->method & (NGX_HTTP_GET|NGX_HTTP_HEAD))) {
        return NGX_HTTP_NOT_ALLOWED;
    }

    //丢弃请求中的包体
    ngx_int_t rc = ngx_http_discard_request_body(r);
    if (rc != NGX_OK) {
        return rc;
    }

/设置返回的Content-Type。注意,ngx_str_t有一个很方便的初始化宏ngx_string,它可以把ngx_str_t的data和len成员都设置好/

ngx_str_t type = ngx_string("text/plain");
 //返回的包体内容
 ngx_str_t response = ngx_string("Hello World!");
 //设置返回状态码
 r->headers_out.status = NGX_HTTP_OK;
 //响应包是有包体内容的,需要设置Content-Length长度
 r->headers_out.content_length_n = response.len;
 //设置Content-Type
 r->headers_out.content_type = type;

 //发送HTTP头部
 rc = ngx_http_send_header(r);
 if (rc == NGX_ERROR || rc > NGX_OK || r->header_only) {
     return rc;
 }

 //构造ngx_buf_t结构体准备发送包体
 ngx_buf_t *b;
 b = ngx_create_temp_buf(r->pool, response.len);
 if (b == NULL) {
     return NGX_HTTP_INTERNAL_SERVER_ERROR;
 }
 //将Hello World复制到ngx_buf_t指向的内存中
 ngx_memcpy(b->pos, response.data, response.len);
 //注意,一定要设置好last指针
 b->last = b->pos + response.len;
 //声明这是最后一块缓冲区
 b->last_buf = 1;

 //构造发送时的ngx_chain_t结构体
 ngx_chain_t out;
 //赋值ngx_buf_t
 out.buf = b;
 //设置next为NULL
 out.next = NULL;

/最后一步为发送包体,发送结束后HTTP框架会调用ngx_http_finalize_request方法结束请求/

return ngx_http_output_filter(r, &out);
}
相关文章
|
22天前
|
运维 持续交付 云计算
深入解析云计算中的微服务架构:原理、优势与实践
深入解析云计算中的微服务架构:原理、优势与实践
56 1
|
14天前
|
运维 监控 持续交付
微服务架构解析:跨越传统架构的技术革命
微服务架构(Microservices Architecture)是一种软件架构风格,它将一个大型的单体应用拆分为多个小而独立的服务,每个服务都可以独立开发、部署和扩展。
138 36
微服务架构解析:跨越传统架构的技术革命
|
12天前
|
机器学习/深度学习 人工智能 自然语言处理
秒级响应 + 99.9%准确率:法律行业文本比对技术解析
本工具基于先进AI技术,采用自然语言处理和语义匹配算法,支持PDF、Word等格式,实现法律文本的智能化比对。具备高精度语义匹配、多格式兼容、高性能架构及智能化标注与可视化等特点,有效解决文本复杂性和法规更新难题,提升法律行业工作效率。
|
19天前
|
存储 Linux API
深入探索Android系统架构:从内核到应用层的全面解析
本文旨在为读者提供一份详尽的Android系统架构分析,从底层的Linux内核到顶层的应用程序框架。我们将探讨Android系统的模块化设计、各层之间的交互机制以及它们如何共同协作以支持丰富多样的应用生态。通过本篇文章,开发者和爱好者可以更深入理解Android平台的工作原理,从而优化开发流程和提升应用性能。
|
21天前
|
弹性计算 持续交付 API
构建高效后端服务:微服务架构的深度解析与实践
在当今快速发展的软件行业中,构建高效、可扩展且易于维护的后端服务是每个技术团队的追求。本文将深入探讨微服务架构的核心概念、设计原则及其在实际项目中的应用,通过具体案例分析,展示如何利用微服务架构解决传统单体应用面临的挑战,提升系统的灵活性和响应速度。我们将从微服务的拆分策略、通信机制、服务发现、配置管理、以及持续集成/持续部署(CI/CD)等方面进行全面剖析,旨在为读者提供一套实用的微服务实施指南。
|
22天前
|
SQL 数据可视化 数据库
多维度解析低代码:从技术架构到插件生态
本文深入解析低代码平台,涵盖技术架构、插件生态及应用价值。通过图形化界面和模块化设计,低代码平台降低开发门槛,提升效率,支持企业快速响应市场变化。重点分析开源低代码平台的优势,如透明架构、兼容性与扩展性、可定制化开发等,探讨其在数据处理、功能模块、插件生态等方面的技术特点,以及未来发展趋势。
|
19天前
|
XML JSON JavaScript
HttpGet 请求的响应处理:获取和解析数据
HttpGet 请求的响应处理:获取和解析数据
|
21天前
|
SQL 数据可视化 数据库
多维度解析低代码:从技术架构到插件生态
本文深入解析低代码平台,从技术架构到插件生态,探讨其在企业数字化转型中的作用。低代码平台通过图形化界面和模块化设计降低开发门槛,加速应用开发与部署,提高市场响应速度。文章重点分析开源低代码平台的优势,如透明架构、兼容性与扩展性、可定制化开发等,并详细介绍了核心技术架构、数据处理与功能模块、插件生态及数据可视化等方面,展示了低代码平台如何支持企业在数字化转型中实现更高灵活性和创新。
41 1
|
21天前
|
SQL 数据可视化 数据库
多维度解析低代码:从技术架构到插件生态
本文深入解析低代码平台,涵盖技术架构、插件生态及应用价值。重点介绍开源低代码平台的优势,如透明架构、兼容性与扩展性、可定制化开发,以及其在数据处理、功能模块、插件生态等方面的技术特点。文章还探讨了低代码平台的安全性、权限管理及未来技术趋势,强调其在企业数字化转型中的重要作用。
35 1
|
22天前
|
存储 边缘计算 安全
深入解析边缘计算:架构、优势与挑战
深入解析边缘计算:架构、优势与挑战
37 0

推荐镜像

更多
下一篇
DataWorks