Dass es momentan wieder geht liegt daran, dass wir HTTP 2.0 ausgeschaltet haben. Leider haben die Tests mit dem neuen WebServer aus den Linx Backports nicht zum Erfolg geführt. Wir haben aber inzwischen herausgefunden, dass Safari mit dem Keep-Alive Header in Verbindung mit HTTP 2.0 Problebe zu haben scheint.
Wir haben diesen HTTP-Header ausgebaut und HTTP 2.0 nach einigen Tests wieder angeschaltet.
Die Website ist nicht erreichbar
Anzeige
#17
geschrieben 19. Februar 2019 - 12:16
Ist die Frage, woran es wirklich liegt.
Wenn ich mir so den Verkehr anschaue, dann läuft da immer noch so einiges von externen Quellen über HTTP/2 und das bereitet keine Probleme.
Ist jetzt die Frage, woran das mit Safari liegt. Der Browser selber hat ansonsten keine Probleme mit HTTP/2. Andere Seiten mit HTTP/2 bzw. Testseiten dafür laufen einwandfrei mit iOS 12.1.4 und Safari.
Wenn ich mir so den Verkehr anschaue, dann läuft da immer noch so einiges von externen Quellen über HTTP/2 und das bereitet keine Probleme.
Ist jetzt die Frage, woran das mit Safari liegt. Der Browser selber hat ansonsten keine Probleme mit HTTP/2. Andere Seiten mit HTTP/2 bzw. Testseiten dafür laufen einwandfrei mit iOS 12.1.4 und Safari.
Ich bin kein Toilettenpapier-Hamster.
---
Ich bin ein kleiner, schnickeldischnuckeliger Tiger aus dem Schwarzwald.
Alle haben mich ganz dolle lila lieb.
---
Ich bin ein kleiner, schnickeldischnuckeliger Tiger aus dem Schwarzwald.
Alle haben mich ganz dolle lila lieb.
#18
geschrieben 19. Februar 2019 - 12:41
Wenn man im Netz sucht, gibt es Seitenweise Foren- und Blogeinträge über HTTP 2.0 Probleme im Safari https://www.google.c...+safari+problem Bei uns lag das Problem daran, dass (nur) der Safari ganz groben Mist baut, wenn wir ihm ein HTTP Keep-Alive Header senden.
Dieser besagt, dass die Verbindung zum Server für einige Zeit (in unserem Fall 3 Sekunden) offen gehalten werden soll. Sollte der Browser innerhalb von drei Sekunden weitere Daten anfordern, muss keine neue Verbindung aufgebaut werden und alles geht ein wenig schneller. Zudem entlastet es auch unseren Server, da (afaik) das Standard-Keep-Alive bei 10 Sekunden sind. So hat unser Server zu jedem Client min. 10 Sekunden eine Verbindung aufgehalten, was zu Stoßzeiten mehr Last als nötig erfordert hat.
Inzwischen (auch mit HTTP 2.0) ist das mit den zusätzlichen Verbindungen aber kein großes Problem mehr, da eh alle Daten über eine HTTP-Verbindung geschickt werden. Daher haben wir unseren HTTP Keep-Alive Header ausgebaut und überlassen wieder jedem Browser selbst wielange er eine Verbindung zu uns offen halte möchte.
Damit geht es dann auch im Safari wieder.
Entschuldigt bitte die Unannehmlichkeiten. Eigentich machen wir stets einen großen Cross-Browser-Test, bei einem Linux-Kernel-Update ist bei uns nur niemand darauf gekommen, dass es mit unterschiedlichen Browsern ein unterschiedliches Verhalten geben könnte. Danke für eure Hinweise!
Dieser besagt, dass die Verbindung zum Server für einige Zeit (in unserem Fall 3 Sekunden) offen gehalten werden soll. Sollte der Browser innerhalb von drei Sekunden weitere Daten anfordern, muss keine neue Verbindung aufgebaut werden und alles geht ein wenig schneller. Zudem entlastet es auch unseren Server, da (afaik) das Standard-Keep-Alive bei 10 Sekunden sind. So hat unser Server zu jedem Client min. 10 Sekunden eine Verbindung aufgehalten, was zu Stoßzeiten mehr Last als nötig erfordert hat.
Inzwischen (auch mit HTTP 2.0) ist das mit den zusätzlichen Verbindungen aber kein großes Problem mehr, da eh alle Daten über eine HTTP-Verbindung geschickt werden. Daher haben wir unseren HTTP Keep-Alive Header ausgebaut und überlassen wieder jedem Browser selbst wielange er eine Verbindung zu uns offen halte möchte.
Damit geht es dann auch im Safari wieder.
Entschuldigt bitte die Unannehmlichkeiten. Eigentich machen wir stets einen großen Cross-Browser-Test, bei einem Linux-Kernel-Update ist bei uns nur niemand darauf gekommen, dass es mit unterschiedlichen Browsern ein unterschiedliches Verhalten geben könnte. Danke für eure Hinweise!
#19
geschrieben 19. Februar 2019 - 12:49
Nachtrag zum Thema Safai: Der Browser legt leider auch ein sehr aggressives Wiederhol-Verhalten an den Tag und kann damit DoS-Attacken auslösen. Stellt er einen Fehler fest, versucht er es innerhalb weniger Sekunden gut und gern noch ~500 Mal die gleiche Seite erneut abzurufen.
Wir haben wahrlich nicht viele Safari-User auf der Seite und das Problem betraf nur WinFuture.de, trotzdem sind deutliche Ausschläge im Traffic des Web-Servers zu sehen:
Wir haben wahrlich nicht viele Safari-User auf der Seite und das Problem betraf nur WinFuture.de, trotzdem sind deutliche Ausschläge im Traffic des Web-Servers zu sehen:
#20
geschrieben 19. Februar 2019 - 13:24
Keep-Alive sollte doch mit HTTP/2 gar nicht mehr erforderlich sein, oder verwechsel ich da was?
Im oben verlinkten Beitrag wird vorgeschlagen, die Option proxy_hide_header Upgrade der nginx-Konfig hinzuzufügen (siehe hier).
Vielleicht geht das auch mit anderen (neueren?) nginx.
Werd mal bei mir gucken. Bild mir zwar ein, auf meinem Http2-Server auch mit Safari keine Probleme zu haben, aber nicht mehr sicher, ob ich wirklich konkret damit auch geschaut hatte.
--
Nope, tut.
Kurz, Safari und HTTP2 funktioniert erstmal, zumindest unter ganz bestimmten Umständen. Und ich seh grad, TLS 1.2, da muß ich wohl nochmal gucken.
Im oben verlinkten Beitrag wird vorgeschlagen, die Option proxy_hide_header Upgrade der nginx-Konfig hinzuzufügen (siehe hier).
Vielleicht geht das auch mit anderen (neueren?) nginx.
Werd mal bei mir gucken. Bild mir zwar ein, auf meinem Http2-Server auch mit Safari keine Probleme zu haben, aber nicht mehr sicher, ob ich wirklich konkret damit auch geschaut hatte.
--
Nope, tut.
Variable Value HTTPS on SSL_TLS_SNI nas.home-sweet-home.local SSL_SERVER_S_DN_C DE SSL_SERVER_S_DN_ST Thu SSL_SERVER_S_DN_O rms, inc. SSL_SERVER_S_DN_CN NAS Server Certificate SSL_SERVER_I_DN_C DE SSL_SERVER_I_DN_ST Thu SSL_SERVER_I_DN_L Home Sweet Home SSL_SERVER_I_DN_O rms, inc. SSL_SERVER_I_DN_Email [email protected] SSL_SERVER_I_DN_CN nas.home-sweet-home.local SSL_SERVER_SAN_DNS_0 nas.home-sweet-home.local SSL_VERSION_INTERFACE mod_ssl/2.4.38 SSL_VERSION_LIBRARY OpenSSL/1.1.1a SSL_PROTOCOL TLSv1.2 SSL_SECURE_RENEG true SSL_COMPRESS_METHOD NULL SSL_CIPHER ECDHE-ECDSA-AES256-GCM-SHA384 SSL_CIPHER_EXPORT false SSL_CIPHER_USEKEYSIZE 256 SSL_CIPHER_ALGKEYSIZE 256 SSL_CLIENT_VERIFY NONE SSL_SERVER_M_VERSION 3 SSL_SERVER_M_SERIAL 1B SSL_SERVER_V_START Aug 3 04:38:40 2017 GMT SSL_SERVER_V_END Jun 12 04:38:40 2027 GMT SSL_SERVER_S_DN CN=NAS Server Certificate,O=rms\, inc.,ST=Thu,C=DE SSL_SERVER_I_DN CN=nas.home-sweet-home.local,[email protected],O=rms\, inc.,L=Home Sweet Home,ST=Thu,C=DE SSL_SERVER_A_KEY id-ecPublicKey SSL_SERVER_A_SIG ecdsa-with-SHA512 SSL_SESSION_ID 80a3cd84008f780c1f3bbb3b35cf73c6ab27f5c94504c0b067e8261a27d8addf SSL_SESSION_RESUMED Resumed HTTP2 on H2PUSH on H2_PUSH on H2_PUSHED no value H2_PUSHED_ON no value H2_STREAM_ID 1 H2_STREAM_TAG 212-1 HTTP_USER_AGENT Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_3) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/12.0.3 Safari/605.1.15 HTTP_ACCEPT text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 HTTP_ACCEPT_LANGUAGE en-us HTTP_ACCEPT_ENCODING br, gzip, deflate HTTP_HOST nas.home-sweet-home.local SERVER_SOFTWARE Apache/2.4.38 (FreeBSD) OpenSSL/1.1.1a mod_wsgi/4.6.5 Python/2.7 PHP/7.3.1 mod_perl/2.0.10 Perl/v5.28.1 SERVER_NAME nas.home-sweet-home.local REQUEST_SCHEME https GATEWAY_INTERFACE CGI/1.1 SERVER_PROTOCOL HTTP/2.0 REQUEST_METHOD GET QUERY_STRING
Kurz, Safari und HTTP2 funktioniert erstmal, zumindest unter ganz bestimmten Umständen. Und ich seh grad, TLS 1.2, da muß ich wohl nochmal gucken.
Dieser Beitrag wurde von RalphS bearbeitet: 19. Februar 2019 - 13:35
#21
geschrieben 19. Februar 2019 - 14:00
@Ralph: wir haben unseren Nginx nicht als Proxy, daher ist die proxy_hide_header-Option für uns nicht relevant. Das Problem liegt nicht am Nginx-Webserver sondern an Safari-Browser. Daher hilft auch die allerneuste Nginx-Version nicht.
Aber wir haben es durch das ausbauen des Keep-Alive-Headers (für alle HTTP-Protokollversionen) lösen können.
Aber wir haben es durch das ausbauen des Keep-Alive-Headers (für alle HTTP-Protokollversionen) lösen können.
#22
geschrieben 19. Februar 2019 - 14:35
Hauptsache es tut.
Kenn das ja selber. Da krempelst den ganzen Kram von vorne bis hinten um, testest alles durch und es funktioniert auch alles super, und hinterher fällt dir dann irgendein eigentlich-gar-kein-Problem in den Rücken, weil du gedacht hast, naja der Test hat ja funktioniert.
Dann wollen wir mal schauen, was da jetzt rumkommt.
Nur so FYI, hab grad nochmal geschaut gehabt von wegen Safari und TLS v1.3. Das kann der augenscheinlich auch (noch) nicht. 1.2 ist bisher das Höchste der Gefühle für den Safari.
Kenn das ja selber. Da krempelst den ganzen Kram von vorne bis hinten um, testest alles durch und es funktioniert auch alles super, und hinterher fällt dir dann irgendein eigentlich-gar-kein-Problem in den Rücken, weil du gedacht hast, naja der Test hat ja funktioniert.
Dann wollen wir mal schauen, was da jetzt rumkommt.
Nur so FYI, hab grad nochmal geschaut gehabt von wegen Safari und TLS v1.3. Das kann der augenscheinlich auch (noch) nicht. 1.2 ist bisher das Höchste der Gefühle für den Safari.
#23
geschrieben 28. Februar 2019 - 15:05
Nachdem ich den Thread erst jetzt sehe meld ich mich erst jetzt - bei HTTP/2 soll AFAIK alles über so wenig Verbindungen wie möglich geschickt werden - im Gegensatz zu HTTP/1.1 wo man ja alles auf so viele CDNs und Verbindungen aufgeteilt hat wies nur geht. Daher sollte bei HTTP/2 der Keep Alive Header mmn. abgeschaltet werden.
#24
geschrieben 28. Februar 2019 - 17:06
HTTP2 benötigt kein keep-alive, weil http2 das bereits eingebaut hat. Das unterstützt nativ so Dinge wie Server Push, wo man mit http/1.1 noch nachhelfen muß.
Entsprechend gibt es den keep-alive header in http2 nicht mehr, bzw ist seine Verwendung nicht definiert. Wenn er sonst Ärger macht, kann man ihn - für http2! -- weglassen, also (a) diesen nur unter Verwendung von http/1.1 senden oder aber (b) ihn ganz weglassen, wobei ich nicht sicher bin, ob dann die Notifications der Hauptseite noch funktionieren, WENN die Inhalte per /1.1 ausgeliefert werden.
Ist natürlich die Frage, wie groß das Aufkommen über 1.1 ist und ob man das an der Stelle vernachlässigen kann.
Entsprechend gibt es den keep-alive header in http2 nicht mehr, bzw ist seine Verwendung nicht definiert. Wenn er sonst Ärger macht, kann man ihn - für http2! -- weglassen, also (a) diesen nur unter Verwendung von http/1.1 senden oder aber (b) ihn ganz weglassen, wobei ich nicht sicher bin, ob dann die Notifications der Hauptseite noch funktionieren, WENN die Inhalte per /1.1 ausgeliefert werden.
Ist natürlich die Frage, wie groß das Aufkommen über 1.1 ist und ob man das an der Stelle vernachlässigen kann.