nginx verwirft http-Paketkörperverarbeitung Beispiel für detaillierte Erklärung
http-Framework verwirft http-Anforderungspaketkörper und der vorherige Artikel „http-Framework empfängt Paketkörper“ sind zwei vom http-Framework bereitgestellte Methoden, die von jedem http-Modul aufgerufen werden, um zu bestimmen, was zu tun ist mit dem Paket machen. Ob man sich für „Verwerfen“ oder „Empfangen“ entscheidet, wird vom Modul bestimmt. Wenn das statische Ressourcenmodul beispielsweise eine Get-Anfrage vom Browser empfängt und eine bestimmte Datei anfordert, kann es den Inhalt der Datei direkt an den Browser zurückgeben. Es besteht keine Notwendigkeit, die Daten des Paketkörpers zu empfangen, und die Get-Anfrage verfügt tatsächlich nicht über einen Paketkörper. Daher ruft das statische Ressourcenmodul die vom HTTP-Framework bereitgestellte Funktion zum Verwerfen des Paketkörpers auf, um die Verarbeitung zum Verwerfen von Paketen durchzuführen.
Im Vergleich zum Empfang des Paketkörpers ist das Verwerfen des Paketkörpers viel einfacher. Zumindest ist es nicht erforderlich, den Paketkörper im Puffer „request_body“ in der http-Struktur zu speichern, und dies ist auch nicht erforderlich Überlegen Sie, ob der Paketkörper nur im Speicher oder nur im Speicher gespeichert ist. Wenn ein Problem mit der Datei usw. auftritt, verwirft das Framework diese direkt nach dem Empfang des Paketkörpers. Der verworfene Paketkörper besteht aus drei Teilen:
(1) Das http-Modul ruft zum ersten Mal die vom Framework bereitgestellte Funktion ngx_http_discard_request_body auf, um einige Initialisierungsvorgänge durchzuführen. Wenn beispielsweise nicht alle Paketkörper in einem Vorgang verworfen werden können, muss das Leseereignis erneut in epoll registriert werden, damit der Vorgang zum Verwerfen des Pakets fortgesetzt werden kann, wenn die Ausführung erneut geplant wird. Rufen Sie außerdem die eigentliche Paketverwerfungsfunktion ngx_http_read_discarded_request_body auf, um den Paketkörper zu verwerfen.
(2) Wenn nicht alle Paketkörper in einem Vorgang verworfen werden können, werden bei erneuter Planung des Ereignisses die verbleibenden Paketdaten weiterhin empfangen und dann verworfen.
(3) Tatsächliche Paketverlustverarbeitung, dh das direkte Verwerfen des Paketkörpers nach dem Empfang.
Aus der Abbildung ist ersichtlich, dass unter diesen drei Prozessen der Paketverlustprozess eine gemeinsame Funktion ist. Das heißt, unabhängig davon, ob das http-Modul die Funktion ngx_http_discard_request_body aufruft, um die Paketverlustverarbeitung zu starten, oder wenn der gesamte Paketkörper nicht in einem Zeitplan empfangen wird, ist ngx_http_discarded_request_body_handler für das Verwerfen der verbleibenden Paketkörperoperationen und die öffentliche Paketverlustfunktion ngx_http_read_discarded_request_body verantwortlich wird aufgerufen, um den Pakettext direkt zu empfangen.
1. Paketverlust-Initialisierungsprozess
ngx_http_discard_request_body ist eine Funktion, die vom http-Modul aufgerufen wird, um den Paketkörper zu verwerfen. Es handelt sich um eine transparente Operation für das Modul. Mit anderen Worten, das Modul muss diese Schnittstelle nur aufrufen, um den Paketkörper der HTTP-Anforderung zu verwerfen, ohne zu wissen, wie das HTTP-Framework diese Schnittstelle implementiert. Selbst wenn das Framework nicht alle Paketkörper in einer Planung verwirft, wird der Vorgang zum Verwerfen von Paketen erneut ausgeführt, wenn die nächste Planung ausgeführt wird. Die Module wissen dies jedoch nicht.
//功能: 丢弃http包体的首次回调函数，如果一次性不能全部接收完成并丢弃，则设置
// 读事件的回调为ngx_http_discarded_request_body_handler
ngx_int_t ngx_http_discard_request_body(ngx_http_request_t *r)
{
//需要丢弃的包体不用考虑超时问题
if (rev->timer_set)
{
ngx_del_timer(rev);
}
//包体长度小于等于0，则直接返回。表示丢弃包体
//如果已经接收过包体了，这时也不需要在接收。通常情况下get请求没有包体，因此包体长度为0
if (r->headers_in.content_length_n <= 0 || r->request_body)
{
return ngx_ok;
}
size = r->header_in->last - r->header_in->pos;
//已经预先接收了部分包体
if (size)
{
//包体未全部接收完成
if (r->headers_in.content_length_n > size)
{
r->header_in->pos += size;
r->headers_in.content_length_n -= size;
}
else
{
//包体已经全部接收
r->header_in->pos += (size_t) r->headers_in.content_length_n;
r->headers_in.content_length_n = 0;
return ngx_ok;
}
}
//设置后续读事件的回调
r->read_event_handler = ngx_http_discarded_request_body_handler;
//注册读事件回调，插入到epoll
ngx_handle_read_event(rev, 0));
//接收包体内容
if (ngx_http_read_discarded_request_body(r) == ngx_ok)
{
//表示已经接收到完整的包体了，将延迟关闭清0
r->lingering_close = 0;
}
else
{
//表示需要多次调度才能完成丢弃包体这个操作，于是把引用计数加1，防止这边在丢弃包体，而其他
//事件却已经让请求意外销毁
r->count++;
//标识为正在丢弃包体
r->discard_body = 1;
}
return ngx_ok;
}
Die Funktion ruft auch die eigentliche Paketverlustfunktion ngx_http_read_discarded_request_body auf, um mit dem Empfang des Paketkörpers zu beginnen und ihn direkt zu verwerfen.
Die Funktion ngx_http_read_discarded_request_body ist dafür verantwortlich, die Paketkörperdaten vom Client zu empfangen und dann zu verwerfen. Daher ist es für das Modul der Vorgang des Verwerfens des Paketkörpers, für das Framework ist der Vorgang des Verwerfens des Paketkörpers jedoch tatsächlich der Vorgang des Empfangens des Paketkörpers, aber die empfangenen Paketkörperdaten werden nicht an das Modul übergeben zur Verwendung. Warum muss das Framework den Paketkörper empfangen und ihn dann direkt verwerfen? Das ist nicht der Fall, es gibt einen Grund, warum es so gemacht wird. Angenommen, ein nicht robuster Client-Browser verwendet eine Blockierungsmethode, um HTTP-Paketkörperdaten an den Nginx-Server zu senden. Wenn das Nginx-Framework diese nicht empfängt, führt dies dazu, dass der Client-Browser eine Zeitüberschreitung erfährt und nicht antwortet, was dazu führt, dass der Client-Browser die Daten schließt Verbindung. . Daher muss das http-Framework von nginx zunächst die Paketkörperdaten vom Client vom Kernel empfangen, diese Daten sind jedoch für das Modul nutzlos, sodass die empfangenen Daten direkt verworfen werden.
//功能: 从内核中读取数据到nginx中，nginx不对收到的数据进行处理。相当于丢弃包体
static ngx_int_t ngx_http_read_discarded_request_body(ngx_http_request_t *r)
{
//用于接收包体的临时缓冲区
u_char buffer[ngx_http_discard_buffer_size];
for ( ;; )
{
//已经全部丢弃成功
if (r->headers_in.content_length_n == 0)
{
//设置丢弃后的读事件回调，再有读事件时，不做任何处理
r->read_event_handler = ngx_http_block_reading;
return ngx_ok;
}
//从内核中接收包体到临时缓冲区
n = r->connection->recv(r->connection, buffer, size);
//更新剩余需要接收的包体大小
r->headers_in.content_length_n -= n;
}
} 函数内部只是使用一个临时的缓冲区变量存放每次接收来自内核的包体数据。并没有把这部分数据保存到http请求结构中的request_body缓冲区。因此包体数据没有交给http模块，相当于被丢弃了。在所有包体从内核中接收完成时，设置http请求结构ngx_http_request_s的读事件read_event_handler回调设置为: ngx_http_block_reading， 表示再收到来自客户端的数据，则不进行任何处理了。因为已经接收完所有的包体数据，也就不需要理会来自客户端浏览器的其它数据。
三、丢弃剩余的包体
ngx_http_discarded_request_body_handler用于在一次调度中没有丢弃完所有包体，则该函数会表调用，用于丢弃剩余的包体。函数内部也会调用实际的丢弃包体函数，进行接收包体然后丢弃操作。nginx服务器做了一个优化处理，会设置一个总超时时间，如果超过这个时间都还没有丢弃完全部的包体，则会关闭这个连接。这是一种对服务器保护的措施，避免长时间的丢包操作占用服务器资源。
//功能: 第1次未能全部丢弃包体时，该函数被调用。之后有读事件时，该函数被调用
void ngx_http_discarded_request_body_handler(ngx_http_request_t *r)
{
//检测延迟关闭时间,如果总时长超过了lingering_time，则不再接收任何包体，这是一个总时间。
//总超时后，将直接光比连接
if (r->lingering_time)
{
timer = (ngx_msec_t) (r->lingering_time - ngx_time());
//已经到达了延迟关闭时间
if (timer <= 0)
{
//清空丢弃包体标识，表示包体已经丢弃
r->discard_body = 0;
//延迟关闭开关清0
r->lingering_close = 0;
ngx_http_finalize_request(r, ngx_error);
return;
}
}
//接收包体后丢弃
rc = ngx_http_read_discarded_request_body(r);
//表示包体已经全部丢弃
if (rc == ngx_ok)
{
r->discard_body = 0; //包体已经全部接收完
r->lingering_close = 0; //清空延迟关闭标志
ngx_http_finalize_request(r, ngx_done);
return;
}
} ngx_http_discarded_request_body_handler这个函数是怎么被事件对象调用的呢? 在前面的文章已经分析了，ngx_connection_s读事件的回调设置为ngx_http_request_handler。 因此在读事件发生时，会回调请求结构的读回调。如果还不是不清楚这个调用过程，可以参考:
static void ngx_http_request_handler(ngx_event_t *ev)
{
//如果同时发生读写事件，则只有写事件才会触发。写事件优先级更高
if (ev->write)
{
r->write_event_handler(r); //在函数ngx_http_handler设置为ngx_http_core_run_phases
}
else
{
r->read_event_handler(r); //在函数ngx_http_process_request设置为ngx_http_block_reading
}
}Das obige ist der detaillierte Inhalt vonWie man damit umgeht, dass Nginx den HTTP-Paketkörper verwirft. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!
