taobao / nginx-book Goto Github PK

见chapter_12.rst

会速度交由之前注册好的事件处理函数ngx_event_accept来处理

current content:
...
advice:
...
reason:
...

current content:
...返回NGX_OK也就代表给客户端的响应已经生成好了，否则返回NGX_OK就发生错误了。
advice:
否则，返回NGX_ERROR则表示发生了错误。
reason:
应该是手误，打错了。

current content:
但大多数模块在这些时刻并不需奥做写什么事情，所以都简单赋值为NULL。
advice:
但大多数模块在这些时刻并不需要做些什么事情
reason:
错别字：奥、写

current content:
phase handler: 此类型的模块也被直接成为handler模块。
advice:
此类型的模块也被直接称为handler模块。
reason:
...

current content:
...
advice:
...
reason:
...

讲 reinit_request 时提到

在某台后端服务器出错的情况，nginx会尝试另一台后端服务器。 nginx选定新的服务器以后，会先调用此函数，然后再次调用 create_request，以重新初始化upstream模块的工作状态。

貌似不会再次调用 create_request?

current content:
...ngx_str_set(str, text)
advice:
...ngx_str_set(str, text) 中的str应该传入指针，改为ngx_str_set(&str, text)
reason:
...

current content:
这个config文件的内容就是告诉nginx的编译脚本，该如何进行编译。
advice:
这个config文件实际上是一个shell脚本，在编译nginx源码的./configure阶段，会调用该config文件生成编译该扩展模块的Makefile文件，从而告诉编译脚本如何编译nginx。所以可以用写shell的方式来写config文件，并且config文件中的变量在nginx源码的auto/modules和auto/make文件中找到。
reason
刚开始读的时候，也对这里的config文件有些疑惑，比如$HTTP_MODULES是干嘛的，从哪而来的，后来终于明白，原来config就是一个shell脚本呀。大神们写的时候可能认为很简单，但是对于我们这些初入门的读者而言，希望还是解释一下的好。这个纯属个人的意见哈，原文已经写得很好了，不增加也可以。但是从一个读者的角度来说，加上一句说明更好些。

报歉了，是我看错了！尚不知如何删除这个建议，故改成这样。

current content:
然后，使用nginx的字符串会产生一些问题，
advice:
但是，使用.....
reason:
从文章组织结构来看，此处是一个转折，不应该用然后。

this is a test

current content:
...
advice:
...
reason:
...

current content:
...
advice:
...
reason:
...

current content:
...
advice:
...
reason:
...

This is a test!
...

求mobi/epub...

见chapter_12.rst

current content:
正是由于有这样的特性，当你在修改一个字符串时，你就得注意，你修改的字符串是否可以被修改，如果修改后，是否会对其它引用产生影响。
advice:
正是基于此特性，在nginx中，必须谨慎的去修改一个字符串。在修改字符串时需要认真的去考虑：是否可以修改该字符串；字符串修改后，是否会对其它的引用造成影响。
reason:

1. 汉语中多以主动句为主。
2. 这一个长句字包含两个含义：不要随意修改一个字符串，修改字符串时要思考那些？因此可以考虑拆分为两个句子。

current content:
...
advice:
...
reason:
...

current content:
...
advice:
此处当nginx_accept_disable>0时，每次请求都把该变量的值减1，也表现出nginx作者的处世态度以及其精巧的设计思维，也表现出他对nginx的良苦用心。对于一个worker进程而言，当一个请求到达时，该worker请求由于空闲连接数据小于总连接数的1/8，因此需要让出该连接。让出可以，但是也得让其他worker进程知晓，本来是该我处理的，只是因为我手头不宽裕让你你的。只有付出才会有收获，因此，该worker进程的nginx_accept_disable就减一了。这样做的一个好处，就是当其它的全部进程的空闲连接数刚开始小于1/8时，总是出让机会的进程就可以有机会优先处理到来的请求，而其他进程可以借此机会修养生息，增长体力。也就是说，对于大并发的情况，nginx采用了车轮战术（当然还得依靠上面提到的epoll技术）去对付这些大并发的请求。
reason:
...刚开始读到这个地方的时候，对没有获取accept_mutex所的进程的nginx_accept_disable变量减1很不了解，想了一段时间才发现这在nginx调优中的莫大好处。像我这种初学者的其他读者有可能初次独到此处也有疑惑，还不如就加上这一段分析呢。嘿嘿.

current content:
初探nginx架构(100%) 里面
比如，nginx在做4个字节的字符串比较时，会将4个字符转换成一个int型，再作比较，以减少cpu的指令数等等。
advice:
”会将4个字符“ --》“会将4个字节”
reason:
”字符“应该是“字节”吧

current content:
而本章介绍的upstream，将使nginx将跨越单机的限制，完成网络数据的接收、处理和转发。
advice:
...而本章介绍的upstream模块，将使nginx跨越单机的限制，完成网络数据的接收、处理和转发。
reason:
...应该是打字的手误，标记一下。呵呵。

current content:
...
advice:
...
reason:
...

原文说：“这里涉及到c语言中对结构体变量赋值操作的语法规则，在此不做介绍。”不知道具体是指那些规则，能具体说一下么？

原文给的例子是：
ngx_str_t str, str1;
str = ngx_string("hello world"); // 编译出错
str1 = ngx_null_string(); // 编译出错

我自己做了一个ngx_string的实验，代码如下：

#include <cstdio>
#include <cstring>
using namespace std;
struct test
{
    int len;
    char * data;
};
test create(char *data)
{
    test ans;
    ans.len=strlen(data);
    ans.data=data;
    return ans;
}
int main()
{
    test temp;
    temp =create("hello world");
    printf("%s\n",temp.data);
    return 0;
}

可以编译并正确输出"hello world"，用的是VS2010 IDE做的。是我哪里理解的有问题么？请指正，谢谢。

current content:
...
advice:
...
reason:
...背景介绍看不到

current content:
...
advice:
...
reason:
...

current content:
从nginx的内部来看，一个HTTP Request的处理过程设计到一下几个阶段。
advice:
“涉及”
reason:
拼写错误

current content:
初始化一个字符串为str，str必须为常量字符串， 一般只用于声明字符串变量时顺便初始化变量的值。
advice:
通过一个以'\0'结尾的普通字符串str构造一个nginx的字符串。鉴于api中采用sizeof操作符计算字符串长度，因此该api的参数必须是一个常量字符串。
reason:
看过源码，发现更合理的解释应该是用一个普通的常量字符串str构造一个nginx的字符串。如果不显示的标注构造的字符串为nginx格式，可能会造成误解。

current content:
知道整个nginx服务被停止。
advice:
直到整个nginx服务被停止。
reason:
...

current content:
...
advice:
...
reason:
...

current content:
首先是检查NGX_HTTP_GET|NGX_HTTP_HEAD|NGX_HTTP_POST，对就是客户端的请求类型，就这三种，其他一律NGX_HTTP_NOT_ALLOWED。
advice:
首先是检查客户端的http请求类型（r->method），如果请求类型为NGX_HTTP_GET|NGX_HTTP_HEAD|NGX_HTTP_POST，则继续进行处理，否则一律返回NGX_HTTP_NOT_ALLOWED从而拒绝客户端的发起的请求。
reason:
...

You can host your documentation on https://readthedocs.org/

current content:
在不考虑nginx单进城工作的情况下
advice:
单进程
reason:
...

建议别用异步非阻塞这个搭配了，异步应该没有阻塞和非阻塞之分，同步才有

用同步非阻塞吧，好理解一些

同步是是对于用户请求来讲，请求没结束，一直同步等待
非阻塞是对与nginx的epoll事件处理来讲，读文件不会阻塞整个worker进程

current content:
如果这样使用，就会有问题
advice:
如果这样使用，就会有问题，这里涉及到c语言中对结构体变量赋值操作的语法规则，在此不做介绍：
reason:
...

advice:
感谢提供这样一个开源教程，能否提供一个此书的编译说明？
reason:
我把源码clone到本地之后，但是编译不起来。
我安装了python-sphinx包，但是初次接触，报有以下错误，不知如何处理：
sphinx-build -b latex -d build/doctrees source build/latex
Making output directory...
Running Sphinx v0.6.6

Extension error:
Could not import extension number_ref (exception: No module named nodes)
make: *** [latexpdf] 错误 1

网上也没有找到相关资料，要是这里有个说明就太好了。
感谢。

nginx是不负责tcp协议的三次握手的。

这段话出现在http://tengine.taobao.org/book/chapter_02.html

current content:
当然，一个网络应用的关键组件往往一开始都会考虑通过高级开发语言编写，因为开发比较方便，但系统到达一定规模，需要更重视性能的时候，这些高级语言为了达成目标所做的结构化修改所付出的代价会使nginx的upstream模块就呈现出极大的吸引力，因为他天生就快。作为附带，nginx的配置提供的层次化和松耦合使得系统的扩展性也可能达到比较高的程度。
advice:
当然，鉴于开发成本的问题，一个网络应用的关键组件一开始往往会采用高级编程语言开发。但是当系统到达一定规模，并且需要更重视性能的时候，为了达到所要求的性能目标，高级语言开发出的组件必须进行结构化修改。此时，对于修改代价而言，nginx的upstream模块呈现出极大的吸引力，因为它天生就快。作为附带，nginx的配置系统提供的层次化和松耦合使得系统的扩展性也达到比较高的程度。
reason:
原文的句子太长了，并且有些地方写的有些绕口，因此，建议把原文的句子拆分为比较简单的多个句子。

test2

current content:
在云模型大行其道的今天，数据转发使nginx有能力构建一个网络应用的关键组件。
advice:
...数据转发是nginx有能力构建一个网络应用的关键组件。
reason:
...

current content:
...
advice:
...
reason:
...

current content:
里面包含请求所有的信息，这里不相信说明了
advice:
...这里不详细说明了。
reason:
...

current content:
...
advice:
...
reason:
...

current content:
...
advice:
...
reason:
...

current content:
如果都没有文件，就读取文件，返回内容。
advice:
如果都没有错误，则读取文件....
reason:
...

三次握手的时候，上层应用是无法感知的

“特别对于Linux，Nginx采用的是epoll的EPOLLET（边沿触发）的方法来触发事件，而不是EPOLLLT（水平触发）”

新的连接（事件）到来的时候，好像是水平触发吧，难道新的nginx版本改了？

啥是上个字段？