Webkit-Browser laden Webseitenbilder / -ressourcen uneinheitlich

1694
eazar001

Ich habe dieses Problem schon seit geraumer Zeit, bei dem Websites, die mit Webkit-basierten Browsern aufgerufen werden, Bilder inkonsistent laden. Mit inkonsistent meine ich, dass bei einem Testlauf ein oder mehrere Images erfolgreich geladen werden, nur um andere zu haben, die dies nicht tun. Bei einem weiteren Testlauf derselben Website werden die Bilder, die zuvor nicht geladen wurden, plötzlich geladen - nur um die Bilder zu haben, die zuvor geladen wurden, und plötzlich nicht geladen. Dieses Verhalten ist so nicht linear, dass ich extreme Schwierigkeiten habe, die Ursache des Problems herauszufinden. Ich stelle fest, dass dieses Problem mit Browsern replizierbar ist wie jumanji, dwbund vimperator. Ich glaube, dass alle diese Browser gemeinsam benutzenwebkit. Ein wiederholtes Neuladen der Webseite führt manchmal zu einem Ergebnis, bei dem alle Ressourcen korrekt geladen werden.

Hier ist ein Screenshot des beschriebenen Verhaltens (vom Webkit-basiert luakit): Webkit-Browser laden Webseitenbilder / -ressourcen uneinheitlich

Wie Sie sehen, handelt es sich dabei um zwei fehlerhafte Bilder, die das allgemeine Verhalten hier veranschaulichen. Ich kann dieses Problem nicht mit Browsern replizieren wie Firefox oder Chrom (was ich glaube verwenden geckound blinkjeweils). Wenn ich mit der rechten Maustaste auf das Bild / Element klicke und es in einem neuen Fenster öffne, kann ich das Bild problemlos anzeigen. Ich verwende den Arch Linux-Kernel 3.12.9-1-ck. Jede Hilfe / Einsicht in was geschehen könnte, wäre sehr dankbar. Vielen Dank.

UPDATE: Jedes defekte Bild, das durch Debuggen der Konsole in luakit als Element geprüft wird, gibt etwas von dieser allgemeinen Form aus:

GET [web address here] Cannot resolve hostname [domain here]

UPDATE 2: Ich habe versucht, die Installation luakitauf einer Virtualbox-Installation durchzuführen kali-linux, die ich auf meinem System (debian-basiert) über habe apt-get install luakit, und ein interessantes Ergebnis ... Keine Symptome von nicht aufgelösten Hostnamen / beschädigten Images / ausgefallenen Ressourcen. Das Browsen ist in dieser virtuellen Umgebung auch vergleichsweise schneller.

Lösung:

Dem von @harrymc vorgeschlagenen Vorschlag (unter Verwendung des öffentlichen DNS von Google) wurden alle Symptome eines schlechten Ladens der Seite vollständig aufgehoben. Laut @ harrymc ist dies auf fehlerhaftes / langsames DNS und / oder schlechte DNS-Caching-Strategien zurückzuführen. Was dieses Problem verursacht hat, war insbesondere ein schlechter DNS-Wert und ein scheinbar voreiliges Timeout-Protokoll, das in die webkitEngine integriert ist. Diese beiden Faktoren sind ein Rezept für eine Katastrophe.

Ein offenerer Gedankenbogen:

Eine weitere Schlussfolgerung ist die Ineffizienz von Webkit-Browsern, da mehrere DNS-Abfragen für dieselbe Website ausgegeben werden, anstatt sich an die erste Abfrage zu erinnern. Eine weitere Schlussfolgerung ist, dass der DNS-Server des ISP anscheinend manchmal nicht mehrere parallele Anforderungen verarbeiten kann (da der Browser wahrscheinlich mehrere Bilder parallel über Threads verarbeitet), möglicherweise weil er jetzt mehr Clients, aber nicht genügend DNS-Server hat. --harrymc

5
Ich führe Arch Linux mit dem gleichen Kernel, aber sowohl luakit als auch uzbl (beide auf Webkit-Basis) funktionieren problemlos. Führen Sie ein Script zum Blockieren von Anzeigen aus, das dies verursachen könnte? Anko vor 10 Jahren 0
@Anko, ich habe weder ein Adblocker-Skript für luakit noch für dwb installiert. Denken Sie daran: Die gleichen Bilder, die nicht wie in der Abbildung oben geladen werden, werden später angezeigt, wenn ich neu lade (nach einer unbestimmten Anzahl von Nachladungen). eazar001 vor 10 Jahren 0
Mein Eindruck der Sache war im Wesentlichen, dass ich, wenn es sich um eine Firewall-bezogene Situation oder um einen Werbeblocker handelt, die gleichen Bilder / Skripts / Ressourcen immer wieder blockieren würde. Dieses Problem ist jedoch für mich so neblig, dass mich der Vorschlag eines Täters nicht überraschen würde. Nebenwirkungen können manchmal durch die unwahrscheinlichsten Katalysatoren ausgelöst werden .... eazar001 vor 10 Jahren 0
Ich bin auch verwirrt. Der Fehler impliziert ein Netzwerkproblem, aber das Funktionieren anderer Browser schließt dies aus. Um zu überprüfen, könnten Sie [problematische Hostnamen ausführen] (https://library.linode.com/linux-tools/common-commands/dig) für die problematischen Hostnamen verwenden, indem Sie `dig` aus dem` dnsutils`-Paket verwenden. Anko vor 10 Jahren 0
Die häufigste Ursache dafür, dass Bilder nicht geladen werden, ist die Wartezeit überschritten. Ich verwende keinen Ihrer Browser, aber Sie könnten nach einem Konfigurationsparameter für die Wartezeit suchen, falls vorhanden. Der Unterschied zu Firefox oder Chrome kann darin bestehen, dass der Wait-Parameter größer ist. harrymc vor 10 Jahren 0
@Anko, ich werde es definitiv versuchen, wenn die Zeit frei wird, danke für den Rat, ich werde Sie über die Ergebnisse informieren, wenn ich kann. eazar001 vor 10 Jahren 0
@ harrymc, TBH, eigentlich hatte ich auch diesen Gedanken ... Ich bemerkte, dass Ladezeiten länger waren als Browser, die nicht auf Webkits basieren. Leider glaube ich nicht, dass es einen Parameter gibt, den ich an diese ausführbaren Dateien des Browsers übergeben kann, obwohl ich nach webkit-basierten Alternativen suchen werde, um zu sehen, ob die Option die Option bietet. eazar001 vor 10 Jahren 0
@ harrymc, das Beunruhigendste an diesem Gedanken ist jedoch: Ich habe einen Durchsatz von 18 Mbps und erhalte eine gute durchschnittliche Fallleistung auf gesunden Websites. Warum scheint das Webkit anscheinend nicht mehr so ​​gut zu funktionieren, dass ich diese "hypothetischen" Timeouts bekomme? Vorausgesetzt, Ihr Vorschlag ist wahr. Die Implikation ist irritierend. eazar001 vor 10 Jahren 1

1 Antwort auf die Frage

3
harrymc

Von Webkit aus verursacht das Zeitlimit lange laufende Aufgaben :

Wir waren gerade gezwungen, einen erheblichen Teil eines unserer AIR-basierten RIAs zu refactor / recodieren, weil das Webkit-Team eine willkürliche Entscheidung getroffen hat, alle XML-HTTP-Anforderungen über ein hart codiertes, verstecktes Timeout von 60 Sekunden einzuschränken. Diese Entscheidung betrifft nicht nur AIR, sondern auch Safari und andere Browser, die auf Webkit basieren.

Obwohl dies nicht unbedingt auf Ihr Problem bezogen ist, weist dies auf das Vorhandensein eines fest codierten Timeouts in Webkit hin.

Wenn Ihr Problem damit zusammenhängt, dass Timeouts in Webkit zu kurz sind, stellt sich die Frage, warum lange Wartezeiten auf Bilder auftreten, wenn Sie eine schnelle Verbindung haben.

Als ersten Test empfehle ich, Ihren DNS-Server in Google Public DNS oder OpenDNS zu ändern und zu prüfen, ob dies einen Unterschied macht. Wenn dies der Fall ist, besteht das Problem darin, dass Ihr ISP auf DNS zu langsam ist oder einen eigenen Cache verwendet.

Eine weitere Referenz zum Deaktivieren von HTTP Keepalive durch User-Agent :

Ein seit langem bestehender Fehler in Safari führt dazu, dass Dateiuploads hängen bleiben, wenn Keepalive-Verbindungen nicht ordnungsgemäß wiederverwendet werden.

https://bugs.webkit.org/show_bug.cgi?id=5760

Durch Deaktivieren der Keepalive-Unterstützung für Webkit wird dieses Problem in Apache gelöst.

Wenn der Apache-Webserver weiterhin Keepalive für Webkit ( persistente HTTP-Verbindung ) deaktiviert, bedeutet dies, dass für jedes Image eine separate HTTP-Verbindung erforderlich ist, während Firefox und Chrome die bereits vorhandene Verbindung der Seite verwenden können, um die Images auch ohne erneute Verbindung herunterzuladen .

Da der Verbindungsaufbau normalerweise sehr langsam ist, kann dies in Verbindung mit einem kurzen integrierten Timeout das Problem erklären, das Webkit mit Bildern hat.

Ich frage mich, ob Ihre Webkit-Browser die Möglichkeit haben, die Benutzeragentenidentität zu ändern .

Während ich zum Beispiel absolut nichts über Vimperator wusste, fand ich über Google das Plugin UserAgentSwitcherLite .

Vielen Dank für Ihre Einsicht, relevante Links und Vorschläge. Ich werde einige Ihrer Vorschläge durch ASAP vertiefen. Ich kann Ihnen jedoch versichern, dass ich dem Vorschlag des "User-Agents" bereits einen Vorschlag gemacht habe. Ich habe es in Mozilla 5.0 geändert. Wie auch immer, ich werde mich so schnell wie möglich bei Ihnen melden. Danke noch einmal. eazar001 vor 10 Jahren 0
Ich habe versucht, den 'dwb'-User-Agent noch einmal in eine `Mozilla-Gecko'-Zeichenfolge zu ändern, und trotzdem - ohne Erfolg. Ich werde auch einen DNS-Server-Switch testen, um zu sehen, ob sich daraus Hinweise ergeben können. eazar001 vor 10 Jahren 0
Wie seltsam, mit dem öffentlichen DNS-Server von Google wurden meine Probleme gelöst. Ich verstehe es einfach nicht, ich habe den gleichen ISP im ganzen Bundesstaat Kalifornien mit großem Durchsatz verwendet, aber die ganze Zeit war mein DNS für all das verantwortlich? Also ist deine Theorie DNS-Caching oder so ähnlich? So oder so ... Sie haben sich eine Prämie verdient und ich habe alle 100 Punkte meines Vertreters sehr gut ausgegeben [=. Vielen Dank für die Hilfe @ harrymc. eazar001 vor 10 Jahren 0
Das Problem ist daher bei Ihrem Internetdienstanbieter bewiesen. Ich empfehle Ihnen, sich mit ihrem Support in Verbindung zu setzen und zu fragen, warum bei DNS-Abfragen gelegentlich lange Verzögerungen auftreten. Sie haben jetzt alle notwendigen Beweise. Im schlimmsten Fall können Sie einfach bei Googles DNS bleiben. harrymc vor 10 Jahren 0
Eine weitere Schlussfolgerung ist die Ineffizienz von Webkit-Browsern, da mehrere DNS-Abfragen für dieselbe Website ausgegeben werden, anstatt sich an die erste Abfrage zu erinnern. Eine weitere Schlussfolgerung ist, dass der DNS-Server des ISP anscheinend manchmal nicht mehrere parallele Anforderungen verarbeiten kann (da der Browser wahrscheinlich mehrere Bilder parallel über Threads verarbeitet), möglicherweise weil er jetzt mehr Clients hat, aber nicht genügend DNS-Server. harrymc vor 10 Jahren 2

Verwandte Probleme