nginx rejette l'exemple de traitement du corps du package http explication détaillée
Le framework http rejette le corps du package de requête http et l'article précédent Le framework http reçoit le corps du package sont deux méthodes fournies par le framework http, qui sont appelées par chaque module http pour déterminer quoi faire avec le paquet. Le choix de rejeter ou de recevoir est déterminé par le module. Par exemple, si le module de ressources statiques reçoit une requête get du navigateur et demande un certain fichier, il peut renvoyer directement le contenu du fichier au navigateur. Il n’est pas nécessaire de recevoir les données du corps du package et la requête get n’aura pas réellement de corps de package. Par conséquent, le module de ressources statiques appellera la fonction de suppression du corps du paquet fournie par le framework http pour effectuer le traitement de suppression des paquets.
Par rapport au processus de réception du corps du package, l'opération de suppression du corps du package est beaucoup plus simple. Au moins, il n'est pas nécessaire de stocker le corps du package dans le tampon request_body de la structure http, et il n'est pas nécessaire de le faire. Déterminez si le corps du package est uniquement stocké en mémoire ou uniquement en mémoire. Lorsqu'il y a un problème avec le fichier, etc., le framework le supprime directement après avoir reçu le corps du package. Le corps du paquet rejeté se compose de trois parties :
(1) Le module http appelle pour la première fois la fonction ngx_http_discard_request_body fournie par le framework pour effectuer certaines opérations d'initialisation. Par exemple, si tous les corps de paquet ne peuvent pas être supprimés en une seule opération, l'événement de lecture doit être à nouveau enregistré dans epoll, afin que l'opération de suppression de paquet puisse être poursuivie lorsque l'exécution est à nouveau planifiée. De plus, appelez la fonction de suppression de paquets réelle ngx_http_read_discarded_request_body pour supprimer le corps du paquet.
(2) Si tous les corps de paquet ne peuvent pas être supprimés en une seule opération, lorsque l'événement est à nouveau programmé, les données de paquet restantes continueront d'être reçues puis rejetées.
(3) Traitement réel de la perte de paquets, c'est-à-dire élimination directe du corps du paquet après l'avoir reçu.
On peut voir sur la figure que parmi ces trois processus, le processus de perte de paquets est une fonction courante. C'est-à-dire que si le module http appelle la fonction ngx_http_discard_request_body pour démarrer le traitement de la perte de paquets, ou lorsque l'intégralité du corps du paquet n'est pas reçu dans un calendrier, ngx_http_discarded_request_body_handler est responsable de l'abandon des opérations restantes du corps du paquet, et la fonction publique de perte de paquets ngx_http_read_discarded_request_body sera appelé pour recevoir directement le corps du paquet.
1. Processus d'initialisation de suppression des paquets
ngx_http_discard_request_body est une fonction appelée par le module http pour supprimer le corps du paquet. C'est une opération transparente pour le module. En d’autres termes, le module n’a besoin que d’appeler cette interface pour éliminer le corps du paquet de requête http, sans savoir comment le framework http implémente cette interface. Même si le framework ne supprime pas tous les corps de paquets lors d'une seule planification, l'opération de suppression de paquets sera effectuée à nouveau lors de l'exécution de la planification suivante, mais les modules ne le savent pas.
//功能: 丢弃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; }
La fonction appellera également la fonction de perte de paquets réelle ngx_http_read_discarded_request_body pour commencer à recevoir le corps du paquet et le supprimer directement.
La fonction ngx_http_read_discarded_request_body est chargée de recevoir les données du corps du paquet du client, puis de les éliminer. Par conséquent, pour le module, il s'agit de l'opération de suppression du corps du package, mais pour le framework, l'opération de suppression du corps du package est en fait l'opération de réception du corps du package, mais les données du corps du package reçues ne sont pas transmises au module. pour utilisation. Pourquoi le framework doit-il recevoir le corps du package, puis le supprimer directement, n'est-ce pas inutile ? Ce n’est pas le cas, il y a une raison pour laquelle c’est fait de cette façon. Supposons qu'un navigateur client peu robuste utilise une méthode de blocage pour envoyer les données du corps du paquet http au serveur nginx. Si le framework nginx ne les reçoit pas, le navigateur client expirera et ne répondra pas, ce qui entraînera la fermeture du navigateur client. connexion. . Par conséquent, le framework http de nginx doit d'abord recevoir les données du corps du package du client depuis le noyau, mais ces données sont inutiles pour le module, donc les données reçues seront directement rejetées.
//功能: 从内核中读取数据到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 } }
Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!