Браузеры Webkit некорректно загружают изображения / ресурсы веб-страниц

1466
eazar001

У меня была эта проблема в течение довольно долгого времени, когда веб-сайты, просматриваемые через браузеры на основе webkit, загружали изображения непоследовательно. Под непоследовательностью я подразумеваю, что при одном пробном запуске изображение или несколько изображений будут загружаться успешно, а для других - нет. При другом пробном запуске того же самого сайта изображения, которые ранее не загружались, неожиданно загружаются - только для того, чтобы загружать ранее загруженные изображения, внезапно не загружаться. Такое поведение настолько нелинейно, что мне очень трудно найти источник проблемы. Я заметил, что эта проблема является воспроизводимой с браузерами, такими как jumanji, dwbи vimperator. Я считаю, что общий фактор среди всех этих браузеров заключается в том, что они используютwebkit, Повторная перезагрузка веб-страницы иногда приводит к тому, что все ресурсы загружаются правильно.

Вот снимок экрана описанного поведения (из веб-набора luakit): Браузеры Webkit некорректно загружают изображения / ресурсы веб-страниц

Как вы можете видеть, это два неудачных изображения, которые иллюстрируют общее поведение здесь. Я не могу повторить эту проблему с браузерами, такими как Firefox или Chrome (которые, я считаю, используют geckoи blinkсоответственно). Если я щелкну правой кнопкой мыши на изображение / элемент и открою его в новом окне, я смогу просмотреть изображение без проблем. Я использую ядро ​​Arch Linux 3.12.9-1-ck. Любая помощь / понимание того, что может происходить, будет высоко ценится. Спасибо.


ОБНОВЛЕНИЕ: Каждое испорченное изображение, когда проверяется как элемент путем отладки консоли в luakit, выводит что-то такого общего вида:

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

ОБНОВЛЕНИЕ 2: Я попытался установить luakitна виртуальной машине установку, kali-linuxкоторая у меня есть в моей системе (на основе Debian) через apt-get install luakit, и интересный результат ... Нет симптомов неразрешенных имен хостов / испорченных образов / сбойных ресурсов. Браузер также сравнительно быстрее в этой виртуальной среде.

Решение:

Следуя предложению @harrymc (используя публичный DNS Google), он полностью уничтожил все признаки плохой загрузки страниц. Согласно @harrymc, это происходит из-за неисправного / медленного DNS и / или плохой стратегии кэширования DNS. Точнее говоря, причиной этой проблемы был плохой DNS и довольно быстрый протокол тайм-аута, встроенный в webkitдвижок. Эти два фактора являются причиной катастрофы.

Более открытая мысль-арка:

Еще одним выводом является неэффективность браузеров Webkit в том, что они выдают несколько DNS-запросов для одного и того же сайта, а не запоминают первый запрос. Другой вывод заключается в том, что DNS-сервер провайдера, по-видимому, иногда не может обрабатывать несколько параллельных запросов (поскольку браузер, вероятно, обрабатывает несколько изображений параллельно через потоки), возможно, потому, что у них теперь больше клиентов, но недостаточно DNS-серверов. --harrymc

5
Я использую Arch Linux с тем же ядром, но оба `luakit` и` uzbl` (оба на основе Webkit) работают без проблем. Вы запускаете сценарий блокировки рекламы, который может вызвать это? Anko 10 лет назад 0
@ Анко, я не установил скрипт adblocker ни для `luakit`, ни для` dwb`. Имейте в виду: те же изображения, которые не будут загружаться, как на картинке выше, появятся позже, если я перезагрузлю (после неопределенного количества перезагрузок). eazar001 10 лет назад 0
По сути, у меня сложилось впечатление, что если бы это была ситуация, связанная с брандмауэром или блокировщиком рекламы, то я бы видел, как одни и те же изображения / сценарии / ресурсы блокировались снова и снова. Однако эта проблема настолько туманна для меня, что я не удивлюсь предложению какого-либо преступника. Побочные эффекты могут быть вызваны самыми неожиданными катализаторами иногда .... eazar001 10 лет назад 0
Я также озадачен. Ошибка подразумевает проблему с сетью, но правильная работа других браузеров исключает это. Просто чтобы проверить, вы можете [выполнить некоторые ручные DNS-запросы] (https://library.linode.com/linux-tools/common-commands/dig) для проблемных имен хостов, используя `dig` из пакета` dnsutils`. Anko 10 лет назад 0
Наиболее распространенная причина того, что изображения, которые существуют, не загружаются - превышено время ожидания. Я не использую ни один из ваших браузеров, но вы можете найти параметр конфигурации времени ожидания, если таковой существует. Разница с Firefox или Chrome может заключаться в том, что их параметр ожидания больше. harrymc 10 лет назад 0
@ Анко, я обязательно попробую, когда время освободится, спасибо за совет, я сообщу тебе о результатах, когда смогу. eazar001 10 лет назад 0
@harrymc, TBH, у меня тоже была эта мысль ... Я заметил, что время загрузки казалось больше, чем в браузерах, не основанных на webkit. К сожалению, я не думаю, что есть параметр, который я могу передать любому из этих исполняемых файлов браузера, хотя я буду искать альтернативы, основанные на webkit, чтобы посмотреть, предлагают ли они какую-либо опцию. eazar001 10 лет назад 0
@harrymc, но самое тревожное в этой мысли: у меня пропускная способность соединения 18 Мбит / с, и я получаю отличную среднюю производительность на здоровых веб-сайтах. Так почему же webkit, по-видимому, не работает настолько, что я получаю эти «гипотетические» тайм-ауты? Это при условии, что ваше предложение верно. Смысл сводит с ума. eazar001 10 лет назад 1

1 ответ на вопрос

3
harrymc

Из таймаута Webkit убивает долго выполняющиеся задачи :

Мы только что были вынуждены реорганизовать / перекодировать значительную часть одного из наших RIA на основе AIR из-за произвольного решения, принятого командой Webkit, ограничить все запросы XML HTTP через жестко запрограммированный скрытый тайм-аут 60 секунд. Это решение не только влияет на AIR, но и на Safari и другие браузеры, основанные на Webkit.

Хотя это не обязательно относится к вашей проблеме, оно указывает на наличие жестко заданного времени ожидания в Webkit.

Если ваша проблема связана с слишком коротким временем ожидания в Webkit, вопрос заключается в том, почему вы испытываете долгое ожидание изображений, учитывая, что у вас быстрое соединение.

В качестве первого теста я предлагаю изменить ваш DNS-сервер на Google Public DNS или OpenDNS и посмотреть, если это изменит . Если это так, то проблема в том, что ваш провайдер слишком медленно работает на DNS или использует свой собственный кеш.


Еще одна ссылка на отключение поддержки активности HTTP User-Agent :

Давняя ошибка в Safari приводит к зависанию загрузки файлов при неправильном повторном использовании соединений keepalive.

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

В Apache отключение поддержки keepalive для Webkit решает эту проблему.

Если веб-сервер Apache по-прежнему отключает keepalive для Webkit ( постоянное соединение HTTP ), это означает, что для каждого изображения требуется отдельное соединение HTTP, а Firefox и Chrome могут использовать уже существующее соединение страницы, чтобы также загружать изображения без повторного подключения. ,

Поскольку установление соединения обычно происходит довольно медленно, то это в сочетании с коротким встроенным тайм-аутом может объяснить проблему, которую Webkit имеет с изображениями.

Интересно, есть ли в ваших браузерах Webkit возможность изменения идентификатора агента пользователя ?

Например, хотя абсолютно ничего не знал о vimperator, я нашел через Google плагин UserAgentSwitcherLite .

Спасибо за ваше понимание, соответствующие ссылки и предложения до сих пор. Я дам некоторые из ваших предложений более глубокое рассмотрение как можно скорее. Тем не менее, я могу заверить вас, что я уже дал совет `User agent '; по сути я поменял его на mozilla 5.0. В любом случае, я обязательно вернусь к вам как можно скорее по этому вопросу. Еще раз спасибо. eazar001 10 лет назад 0
Я попытался изменить пользовательский агент `dwb` еще раз на строку` mozilla-gecko`, и все же - безрезультатно. Я также дам тест переключателю DNS-сервера, чтобы выяснить, может ли это раскрыть какие-либо подсказки. eazar001 10 лет назад 0
Как странно, использование общедоступного DNS-сервера Google решило мои проблемы. Я просто не понимаю, я использовал одного и того же провайдера в штате Калифорния с большой пропускной способностью, однако все это время мой DNS отвечал за все это? Итак, ваша теория - DNS-кеширование или что-то в этом роде? В любом случае ... вы заработали себе награду, и я очень хорошо потратил все 100 очков своего представителя [=. Спасибо за помощь @harrymc. eazar001 10 лет назад 0
Таким образом, проблема связана с вашим провайдером. Я предлагаю связаться со службой поддержки и спросить, почему вы получаете случайные длительные задержки по DNS-запросам. Теперь у вас есть все необходимые доказательства. В худшем случае вы можете просто остаться с DNS Google. harrymc 10 лет назад 0
Еще одним выводом является неэффективность браузеров Webkit в том, что они выдают несколько DNS-запросов для одного и того же сайта, а не запоминают первый запрос. Другой вывод заключается в том, что DNS-сервер провайдера, по-видимому, иногда не может обрабатывать несколько параллельных запросов (поскольку браузер, вероятно, обрабатывает несколько изображений параллельно через потоки), возможно, потому, что у них теперь больше клиентов, но недостаточно DNS-серверов. harrymc 10 лет назад 2

Похожие вопросы