WinFuture-Forum.de: Die Website ist nicht erreichbar - WinFuture-Forum.de

Zum Inhalt wechseln

Beiträge in diesem Forum erhöhen euren Beitragszähler nicht.
  • 2 Seiten +
  • 1
  • 2

Die Website ist nicht erreichbar

#16 Mitglied ist offline   mesios 

  • Gruppe: Administration
  • Beiträge: 3.396
  • Beigetreten: 06. Januar 02
  • Reputation: 101

geschrieben 19. Februar 2019 - 12:04

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.
0

Anzeige



#17 Mitglied ist offline   DK2000 

  • Gruppe: Administration
  • Beiträge: 18.635
  • Beigetreten: 19. August 04
  • Reputation: 1.101

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.
Nutella hat nur sehr wenig Vitamine.
Deswegen muss man davon relativ viel essen.
0

#18 Mitglied ist offline   mesios 

  • Gruppe: Administration
  • Beiträge: 3.396
  • Beigetreten: 06. Januar 02
  • Reputation: 101

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! :)
0

#19 Mitglied ist offline   mesios 

  • Gruppe: Administration
  • Beiträge: 3.396
  • Beigetreten: 06. Januar 02
  • Reputation: 101

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:

Eingefügtes Bild
0

#20 Mitglied ist offline   RalphS 

  • Gruppe: VIP Mitglieder
  • Beiträge: 8.529
  • Beigetreten: 20. Juli 07
  • Reputation: 1.029

geschrieben 19. Februar 2019 - 13:24

Keep-Alive sollte doch mit HTTP/2 gar nicht mehr erforderlich sein, oder verwechsel ich da was? :unsure:

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	admin@home-sweet-home.local
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,emailAddress=admin@home-sweet-home.local,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

"If you give a man a fish he is hungry again in an hour. If you teach him to catch a fish you do him a good turn."-- Anne Isabella Thackeray Ritchie

Eingefügtes Bild
Eingefügtes Bild
0

#21 Mitglied ist offline   mesios 

  • Gruppe: Administration
  • Beiträge: 3.396
  • Beigetreten: 06. Januar 02
  • Reputation: 101

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. :)
0

#22 Mitglied ist offline   RalphS 

  • Gruppe: VIP Mitglieder
  • Beiträge: 8.529
  • Beigetreten: 20. Juli 07
  • Reputation: 1.029

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.
"If you give a man a fish he is hungry again in an hour. If you teach him to catch a fish you do him a good turn."-- Anne Isabella Thackeray Ritchie

Eingefügtes Bild
Eingefügtes Bild
0

#23 Mitglied ist offline   Ludacris 

  • Gruppe: Moderation
  • Beiträge: 4.523
  • Beigetreten: 28. Mai 06
  • Reputation: 183

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.
0

#24 Mitglied ist offline   RalphS 

  • Gruppe: VIP Mitglieder
  • Beiträge: 8.529
  • Beigetreten: 20. Juli 07
  • Reputation: 1.029

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.
"If you give a man a fish he is hungry again in an hour. If you teach him to catch a fish you do him a good turn."-- Anne Isabella Thackeray Ritchie

Eingefügtes Bild
Eingefügtes Bild
0

Thema verteilen:


  • 2 Seiten +
  • 1
  • 2

1 Besucher lesen dieses Thema
Mitglieder: 0, Gäste: 1, unsichtbare Mitglieder: 0