Heim > Backend-Entwicklung > PHP-Tutorial > Nginx-Analyse der Keepalive- und Pipeline-Anforderungsverarbeitung

Nginx-Analyse der Keepalive- und Pipeline-Anforderungsverarbeitung

WBOY
Freigeben: 2016-08-08 09:30:27
Original
1227 Leute haben es durchsucht

Originalartikel, bitte beim Nachdruck angeben: Nachdruck aus Seitenfehler

Linkadresse dieses Artikels: Nginx-Analyse der Keepalive- und Pipeline-Anfrageverarbeitung

Diesmal hauptsächlich Schauen Sie sich Nginx an. In Bezug auf die Verarbeitung von Keepalives und Pipelines ist es nicht erforderlich, die Konzepte hier vorzustellen. Schauen wir uns direkt an, wie Nginx das macht. Schauen wir uns zunächst die Verarbeitung von Keepalive an. Wir wissen, dass Keepalive in http 1.1 die Standardeinstellung ist, es sei denn, der Client gibt den Connect-Header explizit als close an. Das Folgende ist der Code für Nginx, um zu bestimmen, ob Keepalive erforderlich ist.

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

void

ngx_http_handler(ngx_http_request_t *r)

{

.........................................

        switch(r->headers_in.connection_type) {

        case0:

//如果版本大于1.0则默认是keepalive

            r->keepalive = (r->http_version > NGX_HTTP_VERSION_10);

            break;

        caseNGX_HTTP_CONNECTION_CLOSE:

//如果指定connection头为close则不需要keepalive

            r->keepalive = 0;

            break;

        caseNGX_HTTP_CONNECTION_KEEP_ALIVE:

            r->keepalive = 1;

            break;

        }

..................................

}

12 3456789101112131415161718192021
void ngx_http_handler(ngx_http_request_t *r){.... ................................ switch(r->headers_in.connection_type) { case 0://Wenn die Version größer als 1.0 ist, ist die Standardeinstellung Keepalive r - >keepalive = (r->http_version > NGX_HTTP_VERSION_10);      break; caseNGX_HTTP_CONNECTION_CLOSE://Wenn der Verbindungsheader als nah angegeben ist, nein keepalive ist erforderlich<code> r->keepalive = 0; break code>; caseNGX_HTTP_CONNECTION_KEEP_ALIVE: /code>r->keepalive = 1; break; code> <code> }............. ..... ..}

Dann wissen wir, dass Keepalive bedeutet, dass die aktuelle Verbindung nicht direkt nach der Ausführung der aktuellen http-Anfrage geschlossen wird, so dass auch die damit verbundene Verarbeitung von Nginx's Keepalive erfolgt Aufräumen in der Anfragefunktion. Die Funktion für Nginx zum Bereinigen von Anforderungen ist ngx_http_finalize_request. In dieser Funktion wird ngx_http_finalize_connection aufgerufen, um die Verbindung freizugeben, und die relevante Beurteilung von Keepalive befindet sich in dieser Funktion.

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

staticvoid

ngx_http_finalize_connection(ngx_http_request_t *r)

{

    ngx_http_core_loc_conf_t  *clcf;

    clcf = ngx_http_get_module_loc_conf(r, ngx_http_core_module);

.....................................................................

//可以看到如果设置了keepalive,并且timeout大于0,就进入keepalive的处理。

    if(!ngx_terminate

         && !ngx_exiting

         && r->keepalive

         && clcf->keepalive_timeout > 0)

    {

        ngx_http_set_keepalive(r);

        return;

    } elseif(r->lingering_close && clcf->lingering_timeout > 0) {

        ngx_http_set_lingering_close(r);

        return;

    }

    ngx_http_close_request(r, 0);

}

12 34567891011121314151617181920212223
statischvoidngx_http_finalize_connection(ngx_http_request_t *r){ ngx_http_core_loc_conf_t *clcf; clcf = ngx_http_get_module_loc_conf(r, ngx_http_core_module);............................. ................................ //Sie können Beachten Sie, dass die Keepalive-Verarbeitung gestartet wird, wenn Keepalive festgelegt ist und das Timeout größer als 0 ist. if(!ngx_terminate && !ngx_exiting && r->keepalive && clcf->keepalive_timeout > 0) { ngx_http_set_keepalive(r); return; Code> Code><code>} elseif(r->lingering_close && clcf->lingering_timeout > 0) { ngx_http_set_lingering_close(r); return; } ngx_http_close_request(r, 0);}
Aus dem Obigen können wir ersehen, dass Keepalive über ngx_http_set_keepalive festgelegt wird. Als nächstes werden wir uns diese Funktion im Detail ansehen. In dieser Funktion werden Pipeline-Anfragen nebenbei verarbeitet. Schauen wir uns also zunächst an, wie Nginx Pipeline-Anfragen unterscheidet. Es wird davon ausgegangen, dass die vom Client gelesenen Daten mehr Daten enthalten Nach dem Parsen der aktuellen Anfrage sind noch einige Daten vorhanden. Zu diesem Zeitpunkt handelt es sich um eine Pipeline-Anfrage. Ein weiterer sehr wichtiger Punkt ist http_connection. Aus dem vorherigen Blog wissen wir, dass, wenn Sie einen großen Header zuweisen müssen, dieser zuerst von hc->free übernommen wird abgegeben. Lassen Sie hc->busy es schaffen. Und dieser Puffer wird hier wiederverwendet, denn wenn der große Puffer groß ist, muss er ein zweites Mal neu zugewiesen werden. Wenn der Puffer hier wiederverwendet wird, wird eine Zuweisung reduziert.

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

    hc = r->http_connection;

    b = r->header_in;

//一般情况下,当解析完header_in之后,pos会设置为last。也就是读取到的数据刚好是一个完整的http请求.当pos小于last,则说明可能是一个pipeline请求。

    if(b->pos < b->last) {

        /* the pipelined request */

        if(b != c->buffer) {

            /*

             * If the large header buffers were allocated while the previous

             * request processing then we do not use c->buffer for

             * the pipelined request (see ngx_http_init_request()).

             *

             * Now we would move the large header buffers to the free list.

             */

            cscf = ngx_http_get_module_srv_conf(r, ngx_http_core_module);

//如果free为空,则新建

            if(hc->free== NULL) {

//可以看到是large_client_headers的个数

                hc->free= ngx_palloc(c->pool,

                  cscf->large_client_header_buffers.num * sizeof(ngx_buf_t *));

                if(hc->free== NULL) {

                    ngx_http_close_request(r, 0);

                    return;

                }

            }

//然后清理当前的request的busy

            for(i = 0; i < hc->nbusy - 1; i++) {

                f = hc->busy[i];

                hc->free[hc->nfree++] = f;

                f->pos = f->start;

                f->last = f->start;

            }

//保存当前的header_in buf,以便与下次给free使用。

            hc->busy[0] = b;

            hc->nbusy = 1;

        }

    }

Dann ist der nächste Teil die kostenlose Anfrage und das Einstellen des Keepalive-Timers.

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

    r->keepalive = 0;

    ngx_http_free_request(r, 0);

    c->data = hc;

//设置定时器

    ngx_add_timer(rev, clcf->keepalive_timeout);

//然后设置可读事件

    if(ngx_handle_read_event(rev, 0) != NGX_OK) {

        ngx_http_close_connection(c);

        return;

    }

    wev = c->write;

    wev->handler = ngx_http_empty_handler;

12 3

4

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

    if(b->pos < b->last) {

        ngx_log_debug0(NGX_LOG_DEBUG_HTTP, c->log, 0, "pipelined request");

#if (NGX_STAT_STUB)

        (void) ngx_atomic_fetch_add(ngx_stat_reading, 1);

#endif

//设置标记。

        hc->pipeline = 1;

        c->log->action = "reading client pipelined request line";

//然后扔进post queue,继续进行处理.

        rev->handler = ngx_http_init_request;

        ngx_post_event(rev, &ngx_posted_events);

        return;

    }

56789 10 1112131415
r->keepalive = 0;ngx_http_free_request(r, 0); c->data = hc;//Stellen Sie den Timer einngx_add_timer(rev, clcf ->keepalive_timeout);//Dann das lesbare Ereignis festlegenif (ngx_handle_read_event(rev, 0) != NGX_OK) {ngx_http_close_connection(c); return ;wev = c->write;wev->handler = ngx_http_empty_handler; Dann Der nächste Teil ist die Verarbeitung der Pipeline.
12 3456789101112131415 if(b->pos < b->last) {ngx_log_debug0( NGX_LOG_DEBUG_HTTP, c->log, 0, "pipelined request");#if (NGX_STAT_STUB) (void) ngx_atomic_fetch_add(ngx_stat_reading, 1);#endif//Tag festlegen. hc->pipeline = 1;c->log->action = "reading client Pipelined Request Line";//Wirf es dann in die Post-Warteschlange und fahre mit der Verarbeitung fort. Code >rev->handler = ngx_http_init_request;ngx_post_event(rev, &ngx_posted_events);return; Wenn den unteren Rand erreicht, bedeutet dies, dass es sich nicht um eine Pipeline-Anfrage handelt. Daher beginnen wir mit der Bereinigung der Anfrage und der http_connection.

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

    if(ngx_pfree(c->pool, r) == NGX_OK) {

        hc->request = NULL;

    }

    b = c->buffer;

    if(ngx_pfree(c->pool, b->start) == NGX_OK) {

        /*

         * the special note for ngx_http_keepalive_handler() that

         * c->buffer's memory was freed

         */

        b->pos = NULL;

    } else{

        b->pos = b->start;

        b->last = b->start;

    }

.....................................................................

    if(hc->busy) {

        for(i = 0; i < hc->nbusy; i++) {

            ngx_pfree(c->pool, hc->busy[i]->start);

            hc->busy[i] = NULL;

        }

        hc->nbusy = 0;

    }

12 3

4

1

2

3

4

5

6

7

8

9

//后面会详细分析这个函数

    rev->handler = ngx_http_keepalive_handler;

    if(wev->active && (ngx_event_flags & NGX_USE_LEVEL_EVENT)) {

        if(ngx_del_event(wev, NGX_WRITE_EVENT, 0) != NGX_OK) {

            ngx_http_close_connection(c);

            return;

        }

    }

567891011121314151617181920212223 24252627282930
if(ngx_pfree(c->pool, r) == NGX_OK) { hc->request = NULL; } b = c->buffer; if(ngx_pfree (c->pool, b->start) == NGX_OK) {   /* * der besondere Hinweis für ngx_http_keepalive_handler(), dass * der Speicher des C->-Puffers freigegeben wurde code> code><code> */ b->pos = NULL; code><code> } else{    b->pos = b->start; code>else code><code> b->last = b->start; ....................... ......... ................................ if(hc->busy) {    for code>(i = 0; i < hc->nbusy; i++) {    ngx_pfree(c->pool, hc->busy[i] ->start); hc->busy[i] = NULL; } hc->nbusy = 0; <code>}
Legen Sie den Keepalive-Handler fest.
12 3456789 //Diese Funktion wird später im Detail analysiert rev->handler = ngx_http_keepalive_handler ; if(wev->active && (ngx_event_flags & NGX_USE_LEVEL_EVENT)) { if(ngx_del_event(wev, NGX_WRITE_EVENT, 0) != NGX_OK) { code><code>ngx_http_close_connection(c);    return; } }
Der letzte Schritt ist die Verarbeitung von TCP-Push. Ich werde ihn hier vorerst nicht vorstellen. Als nächstes werde ich einen speziellen Blog erstellen, um die Funktionsweise von Nginx für TCP-Push vorzustellen. Dann schauen wir uns die Funktion ngx_http_keepalive_handler an. Diese Funktion verarbeitet die Keepalive-Verbindung. Dieser Handler wird aufgerufen, wenn es wieder lesbare Ereignisse auf der Verbindung gibt. Dieser Handler ist relativ einfach, er erstellt lediglich einen neuen Puffer und startet dann die Ausführung einer http-Anfrage neu (Aufruf von ngx_http_init_request).

Versuchen Sie dann, die Daten zu lesen. Wenn keine lesbaren Daten vorhanden sind, wird das Handle erneut zum lesbaren Ereignis hinzugefügt

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

    b = c->buffer;

    size = b->end - b->start;

    if(b->pos == NULL) {

        /*

         * The c->buffer's memory was freed by ngx_http_set_keepalive().

         * However, the c->buffer->start and c->buffer->end were not changed

         * to keep the buffer size.

         */

//重新分配buf

        b->pos = ngx_palloc(c->pool, size);

        if(b->pos == NULL) {

            ngx_http_close_connection(c);

            return;

        }

        b->start = b->pos;

        b->last = b->pos;

        b->end = b->pos + size;

    }

12 3

4

1

2

3

4

5

6

7

8

9

n = c->recv(c, b->last, size);

c->log_error = NGX_ERROR_INFO;

if(n == NGX_AGAIN) {

    if(ngx_handle_read_event(rev, 0) != NGX_OK) {

        ngx_http_close_connection(c);

    }

    return;

}

567

1

ngx_http_init_request(rev);

89101112131415161718192021
 b = c->buffer; size = b->end - b->start; code><code> code> if(b->pos == NULL) { /* * Der Speicher des C->-Puffers wurde durch ngx_http_set_keepalive() freigegeben.<code> * Allerdings wurden c->buffer->start und c->buffer->end nicht geändert code> // BUF b- & gt; pos = ngx_palloc (c- & gt; Pool, Größe) neu leiten ; if(b->pos == NULL) { ngx_http_close_connection(c);                                                                                                           } b->start = b->pos;                                                                                                                                                                  >pos + size; }
1234 56789 n = c->recv(c, b->last, size) ;c->log_error = NGX_ERROR_INFO;if(n == NGX_AGAIN) { if(ngx_handle_read_event(rev, 0 ) != NGX_OK) { ngx_http_close_connection(c); } <code>return;}
Wenn die Daten schließlich gelesen wurden, wird die Anfrageverarbeitung eingegeben.
1 ngx_http_init_request(rev);
Schließlich schauen wir uns die Funktion ngx_http_init_request an. Dieses Mal schauen wir uns hauptsächlich an, wie Nginx die Anfrage wiederverwendet, wenn die Pipeline angefordert wird.
Achten Sie hier auf hc->busy[0] Wir wissen bereits, dass wir den Anforderungsheader_in speichern, der zuvor nicht analysiert wurde. Dies liegt daran, dass wir möglicherweise den zweiten Header gelesen haben der Pipeline-Anfrage. Einige Header für die Anfrage.

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

//取得request,这里我们知道,在pipeline请求中,我们会保存前一个request.

    r = hc->request;

    if(r) {

//如果存在,则我们重用前一个request.

        ngx_memzero(r, sizeof(ngx_http_request_t));

        r->pipeline = hc->pipeline;

//如果nbusy存在

        if(hc->nbusy) {

//则保存这个header_in,然后下面直接解析。

            r->header_in = hc->busy[0];

        }

    } else{

        r = ngx_pcalloc(c->pool, sizeof(ngx_http_request_t));

        if(r == NULL) {

            ngx_http_close_connection(c);

            return;

        }

        hc->request = r;

    }

//保存请求

    c->data = r;

12 3

4

567891011121314151617181920212223 2425
//Holen Sie sich die Anfrage, hier wissen wir, dass wir in der Pipeline-Anfrage die vorherige Anfrage speichern werden.<code> r = hc->request; if code ><code>(r) {//Wenn vorhanden, verwenden wir die vorherige Anfrage erneut. ngx_memzero(r, sizeof(ngx_http_request_t)); r->pipeline = hc-> Pipeline;//Wenn nbusy existiert if(hc ->nbusy) {//Speichern Sie diesen Header_in und analysieren Sie ihn dann direkt darunter. r->header_in = hc->busy[0]; code> code><code>} } else{ r = ngx_pcalloc(c->pool, sizeof(ngx_http_request_t)); if(r == NULL) { ngx_http_close_connection(c); return; } hc->request = r; }//Anfrage speichern c->data = r;
Aus dem obigen Code und in Kombination mit meinem vorherigen Blog wissen wir, dass große Header hauptsächlich für die Pipeline gedacht sind, denn in der Pipeline gibt es einige Header, wenn die vorherige Anfrage mehr liest als die nächste Anfrage Beim nächsten Parsen kann es sein, dass die ursprünglich zugewiesene client_header_buffer_size überschritten wird. Zu diesem Zeitpunkt müssen wir einen Header neu zuweisen, bei dem es sich um einen großen Header handelt. Daher ist die httpconnection hier hauptsächlich für die Pipeline-Situation gedacht, und wenn es sich um eine Keepalive-Verbindung handelt keine Pipeline-Anfrage, um Speicher zu sparen, wird die vorherige Anfrage freigegeben Das Obige stellt die Analyse der Keepalive- und Pipeline-Anforderungsverarbeitung durch Nginx vor, einschließlich der relevanten Aspekte. Ich hoffe, dass es für Freunde hilfreich sein wird, die sich für PHP-Tutorials interessieren.
Verwandte Etiketten:
Quelle:php.cn
Erklärung dieser Website
Der Inhalt dieses Artikels wird freiwillig von Internetnutzern beigesteuert und das Urheberrecht liegt beim ursprünglichen Autor. Diese Website übernimmt keine entsprechende rechtliche Verantwortung. Wenn Sie Inhalte finden, bei denen der Verdacht eines Plagiats oder einer Rechtsverletzung besteht, wenden Sie sich bitte an admin@php.cn
Beliebte Tutorials
Mehr>
Neueste Downloads
Mehr>
Web-Effekte
Quellcode der Website
Website-Materialien
Frontend-Vorlage