NGINX întârzieri mari la finalizarea încărcărilor WebDAV proxy

Am un server IIS intern care rulează WebDAV, fiind utilizat direct pentru încărcarea și descărcarea fișierelor dintr-o aplicație Android.

DNS-ul meu intern rezolvă problema https://webav.mydomain.com direct la IIS (ocolind NGINX) și această comunicare internă pare să funcționeze fără probleme. Viteza de încărcare și descărcare nu sunt fantastice pentru vitezele wireless disponibile, dar sunt ceea ce m-am obișnuit în configurația mea IIS (fie din cauza limitelor hardware-ului meu sau pur și simplu a limitărilor IIS WebDAV).

Extern la rețea, adresa URL se rezolvă la IP-ul public al serverului meu NGINX. Când utilizați aplicația de la distanță, vitezele de descărcare par de asemenea acceptabile (~25 MB/s).

Vitezele de încărcare sunt însă lente. Sunt aproximativ jumătate din vitezele de descărcare. Cu toate acestea, mai important decât încetineala este că există o întârziere foarte mare la sfârșitul încărcării înainte de finalizare.

Clientul meu arată o stare de încărcare care raportează numărul de octeți încărcați și dimensiunea totală a încărcării. Când o încărcare atinge aproximativ 99% din dimensiunea totală a încărcării, rămâne acolo pentru ceva timp înainte de a fi finalizată.

Pe un fișier de 50 MB se va opri în jur de 49 MB și se va aștepta aproximativ 30 de secunde înainte de a finaliza. O încărcare de 3 GB a așteptat cel puțin 5 minute înainte de a fi finalizată cu succes.

Această problemă nu există deloc intern atunci când serverul NGINX nu este în amestec. Accept că voi avea un debit mai lent la nivel extern și chiar că hardware-ul limitat NGINX ar putea avea o limitare suplimentară. Dar nu sunt sigur de ce există o întârziere atât de mare în capacitatea NGINX de a finaliza încărcarea pe serverul IIS.

Mai jos este configurația NGINX relevantă:

în amonte webdav_backend {
        server 10.10.10.102:443;
        keepalive 100;
}

Server {
        asculta 443 ssl http2;

        nume_server webdav.mydomain.com;

        proxy_set_header Gazdă $gazdă;
        proxy_set_header X-Real-IP $adresă_la distanță;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $schema;
        proxy_set_header X-Forwarded-Protocol $schema;

        proxy_redirect dezactivat;
        proxy_buffering dezactivat;

        proxy_connect_timeout 180s;
        proxy_send_timeout 180s;
        proxy_read_timeout 180s;
        fastcgi_send_timeout 180s;
        fastcgi_read_timeout 180s;

        proxy_http_versiunea 1.1;
        proxy_set_header Conexiune „”;

        locație @proxy {
                proxy_pass https://webdav_backend;
        }

        Locație / {
                try_files $uri @proxy;
                client_max_body_size 4G;
        }

        access_log /opt/var/log/nginx/webdav.mydomain.com.remote.log remote_hosts if=$remote_hosts;
        access_log /opt/var/log/nginx/webdav.mydomain.com.access.log;
        error_log /opt/var/log/nginx/webdav.mydomain.com.error.log;
}

Așa că, după ce am postat, m-am întors pentru a încerca să captez mai multe informații.

Am observat că în timpul unei încărcări serverul meu IIS nu a primit date imediat când a început încărcarea. Pentru fișierele mai mici, cum ar fi cel de 50 MB, părea că serverul backend nu a început să primească datele până când nu a fost aproape complet, iar pentru fișierele mai mari, am observat mai multă tamponare pe client, împreună cu perioadele de inactivitate ale recepției serverului de backend a fișierelor. date.

Am observat, de asemenea, că memoria de pe serverul meu NGINX (hardware încorporat cu specificații scăzute) scade cu aproximativ 70 MB (75% din memoria disponibilă rămasă) în timp ce transferul avea loc.

Toate acestea mi-au întărit faptul că serverul NGINX încă memora în cache/bufferează datele în ciuda faptului că „proxy_buffering off” a fost specificat în configurație. Am examinat documentația și am găsit:

http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_request_buffering

Dezactivarea acestei funcții nu numai că a dus la eliminarea completă a întârzierilor, dar pare să fi îmbunătățit viteza de încărcare în general cu aproximativ 50%.