NGINX-QUIC + Brotli + Google PageSpeed

  • Vielleicht ist es keine eine Frage, aber vielleicht hat der ein oder andere mal mit dem Gedanken gespielt QUIC bzw. HTTP/3 auszuprobieren.


    NGINX


    Natürlich brauchen wir noch ein entsprechendes Systemctl Skript (z.B. unter "/lib/systemd/system/"):

    Danach nochmal kurz Systemctl reloaden und NGINX starten:

    Code
    1. systemctl daemon-reload
    2. systemctl enable nginx
    3. systemctl start nginx


    Eure entsprechenden Konfigurationsdateien passt ihr wie folgt an:

    Code
    1. listen 443 http3 quic reuseport;
    2. listen 443 ssl http2;
    3. add_header alt-svc 'h3-27=":443"; ma=86400, h3-28=":443"; ma=86400, h3-29=":443"; ma=86400, h3=":443"; ma=86400';
    4. add_header Alt-Svc 'quic=":443"';
    5. add_header QUIC-Status $quic;
    6. quic_retry on;
    7. ssl_early_data on;


    Hinweis

    Leider ist es notwendig BoringSSL für QUIC-Support zu nutzen, weshalb OCSP Stapling nicht unterstützt wird.

    Es gibt zwar einen Patch auf GitHub, jedoch habe ich noch keinen Versuch unternommen diesen anzuwenden.

  • aber vielleicht hat der ein oder andere mal mit dem Gedanken gespielt QUIC bzw. HTTP/3 auszuprobieren

    Hab ich. ;)


    Aber leider sind die Einsatzmöglichkeiten momentan noch sehr eingeschränkt. Eigentlich kann man nur HTTP/3 und Chrome verwenden. Das ist nur so Semi-interessant.


    Trotzdem danke für die Anleitung! Vielleicht mach ich doch mal einen Container damit.

  • Da sind mir zu viele "-dev" dabei. aber wird ja sowieso jeden Monat eine neue Sau durchs Dorf getrieben ;(. Und statische Dateien sind sowieso nicht wirklich das große Problem. Bei manchen Hostern wäre man ja schon froh, wenn man mittlerweile HTTP/2 hätte. Aber immerhin scheinen ja wenigstens gut 70% der verwendeten Browser mittlerweile HTTP/3 zu unterstützen.

  • Eigentlich kann man nur HTTP/3 und Chrome verwenden.

    Geht bei Firefox, Edge und Chrome für Android mittlerweile auch:

    https://caniuse.com/http3


    Es wird also langsam interessanter.


    Da sind mir zu viele "-dev" dabei. aber wird ja sowieso jeden Monat eine neue Sau durchs Dorf getrieben ;(. Und statische Dateien sind sowieso nicht wirklich das große Problem. Bei manchen Hostern wäre man ja schon froh, wenn man mittlerweile HTTP/2 hätte. Aber immerhin scheinen ja wenigstens gut 70% der verwendeten Browser mittlerweile HTTP/3 zu unterstützen.

    Das muss so, schließlich compilen wir hier.


    Worum man sich aber tatsächlich kümmern muss, ist NGINX-QUIC regelmäßig zu aktualisieren.

    Hierfür führst du das obige Skript einfach nur wieder aus und das wars.

    Aktuell ist der Tree noch nicht für den produktiven Einsatz freigegeben (laut NGINX wird das ganze dann in "Mainline" integriert).


    Mit kleineren Anpassungen an der NGINX und PHP-FPM Config kommst du ohne weiteres auf die gleiche Performance wie mit Apache MPM.

    Das gibt sich also nicht viel (da kommt es einfach mehr auf FPM an).


    Aber wie gesagt - wirklich für den produktiven Einsatz ist es offiziell noch nicht, deshalb abwarten.

    Ansonsten, falls es unbedingt "production ready" sein muss, mal Caddy anschauen.


    Habe damit noch nicht so viel Erfahrung um ehrlich zu sein, aber vom Grundprinzip her klingt das ganze nicht schlecht.

  • Ansonsten wäre vielleicht mal ein Blick auf Caddy lohnenswert. Den benutzen wir auf Terraconia und dort habe ich auch QUIC bzw. HTTP/3 in der Config aktiviert. Man sieht in den Logs, dass vor allem die Chromium basierten Browser dieser Welt auch Gebrauch davon machen. Ich selbst nutze Firefox, daher kann ich zur Geschwindigkeit keine Aussage treffen. Fakt ist aber, dass noch keine Probleme gemeldet worden, daher gehe ich davon aus, dass es stabil nutzbar ist (sofern korrekt implementiert).


    Was nginx betrifft - das sind solche Sachen, bei denen ich keine Experimente machen würde. Sofern die nginx Maintainer es noch nicht implementiert haben, würde ich auch keine Klimmzüge machen, um es rein zu bekommen.

  • Mit kleineren Anpassungen an der NGINX und PHP-FPM Config kommst du ohne weiteres auf die gleiche Performance wie mit Apache MPM.

    Das gibt sich also nicht viel (da kommt es einfach mehr auf FPM an).

    =O:huh: Jetzt hast du gerade mein Weltbild erschüttert. Ich höre hier den ganzen Tag (und nachts mit Beleuchtung), wieviel besser und schneller nginx ist als Apache. Und jetzt schafft man es immerhin, auf die gleiche Performance zu kommen. Da bin ich jetzt aber schon einigermaßen desillusioniert :wacko:.

  • =O:huh: Jetzt hast du gerade mein Weltbild erschüttert. Ich höre hier den ganzen Tag (und nachts mit Beleuchtung), wieviel besser und schneller nginx ist als Apache. Und jetzt schafft man es immerhin, auf die gleiche Performance zu kommen. Da bin ich jetzt aber schon einigermaßen desillusioniert :wacko:.

    Nginx ist am Ende immer noch besser in Puncto WAF :) https://github.com/bunkerity/bunkerized-nginx

  • Was nginx betrifft - das sind solche Sachen, bei denen ich keine Experimente machen würde. Sofern die nginx Maintainer es noch nicht implementiert haben, würde ich auch keine Klimmzüge machen, um es rein zu bekommen.

    Die genutzte Repo ist eine offizielle von NGINX. Einfach mal dazu einlesen:

    https://www.nginx.com/blog/our…uic-http-3-support-nginx/


    tab NGINX ist wesentlich schneller bei statischen Inhalten und hoher Last (Stichwort Concurrency).

    Die Performance der dynamischen Inhalte (ich gehe in der Annahme aus, dass wir hier primär über PHP reden) hängt schlichtweg von PHP-FPM ab, womit NGINX wiederum nichts am Hut hat.


    Vor einigen Jahren soll das wohl nicht so das Gelbe vom Ei gewesen sein, jedoch ist FPM mittlerweile stark verbessert worden.


    Deshalb - das erste was man machen sollte, ist es die Anzahl der Startserver für FPM in der www.conf hochzusetzen. Das verbessert die TTFB (Time to first byte) enorm.


    Ich komme mit obigen Stack und ein paar weiteren kleineren Spielereien auf eine TTFB von konstant unter 50ms, im Idealfall habe ich schon 30ms gemessen (Shopware 6).