Chrome медленнее по сайтам https, особенно внутренним

Мы пытаемся развернуть Google Chrome в нашей корпоративной сети, но обнаруживаем, что загрузка страницы https (особенно наших внутренних) занимает в 2-4 раза больше по сравнению с IE. Кто-нибудь испытал это и нашел исправление?

Обновить

Основываясь на предложении Handyman5, я провел несколько диагностических операций в Chrome и обнаружил, что наибольшее количество времени (более 90% на каждой странице) тратится на извлечение статических файлов из Cache и рендеринг страницы. Однако, если я отключаю SSL на нашем сайте, это почти мгновенно.

Любые мысли о том, почему это будет?

Chrome имеет потрясающий встроенный диагностический инструмент «about: net-internals» , который предназначен для устранения неполадок в сети. В частности, он имеет вкладку «События», которая позволяет указать URL-адрес, а затем Chrome разбивает весь процесс его загрузки, пошагово, включая разрешение DNS, попадания в кэш и запросы элементов AJAX.

tl; dr Проверьте, как Chrome обрабатывает проверку и отзыв сертификатов.

У нас была очень похожая проблема на объекте, где я раньше работал, но с Firefox. Чтобы это было проблемой, вам нужно подтвердить, что проблема только со страницами https. Если нет, то это мало что изменит.

С Firefox (я знаю, я знаю, я могу читать, укажу на будущее), у многих людей были проблемы, в то время как у пользователей Internet Explorer (если вы можете в это поверить) их не было. Мы использовали пресловутый авторитет ipsCA, потому что они были бесплатны для образовательных учреждений, но в конечном итоге разозлили Firefox из-за их неуверенности, и проверка их сертификатов OCSP была виновником . Оказывается, браузер задерживается из-за обработки списков отзыва сертификатов из-за характера наших сертификатов SSL. Вы, как лучшие из нас, не упомянули свою версию Chrome, поэтому трудно сказать, была ли это проблемаили все еще проблема. Однако я бы проверил конфигурацию CRL в Chrome. В Firefox это облегчило проблему. Кроме того, проверьте, что ваши сертификаты находятся в хорошем состоянии, то есть если они подписаны самостоятельно. То, что отдало его в пользование, - это то, что мы отошли от самоподписанного, потому что идиотские пользователи наших сервисов много жаловались и это было бесплатно. Мы думали, что избавляем себя от головной боли, но мы сделали это еще хуже.

Мы развернули Google Chrome для внутренней поддержки специально разработанного приложения (на ASP.NET MVC), но работающего по обычному HTTP.

У нас также были проблемы с медленными страницами из-за кеша. Похоже, что Chrome вытягивал все статические файлы при каждой загрузке страницы, а не сохранял их в своем кэше. В итоге мы просто добавили заголовки expires в наше приложение, чтобы включить кеш, и это сработало.

Вы можете пойти по этому пути (изменить свои веб-приложения, указав стратегию кэширования для каждого типа файлов) или изучить дальнейшее поведение кэширования по умолчанию в Chrome.

У других, похоже, есть похожие проблемы (например, http://www.google.com/support/forum/p/Chrome/thread?tid=741fd9e03cfb7e7b&hl=en ).

Эта статья может быть полезна, так как она содержит учебник по кэшированию в Chrome: http://gent.ilcore.com/2011/02/chromes-10-caches.html

Я столкнулся с той же проблемой. После долгого поиска я обнаружил это с помощью инструмента мониторинга процесса ( https://technet.microsoft.com/en-us/sysinternals/processmonitor.aspx ). Chrome сталкивался со многими коллизиями, пытаясь записать в% TEMP%. Очистка этого каталога решила проблему для меня.

В конце концов, я не смог найти ответ здесь. Все тесты мониторинга и профилирования показывают, что Google Chrome очень медленно загружает защищенный статический контент из кэша локального клиента. Понятия не имею почему. Мы должны были заставить всех наших внутренних пользователей переключиться на IE (что и делало большинство людей с похожими проблемами в сети).

Если бэкэнд является сервером приложений на основе Java, существует распространенная ошибка Java, которая приводит к огромной задержке билетов сеанса TLS. Вы можете смоделировать ошибку, используя действительно новый openssl s_client и сообщив ему, чтобы включить / отключить тикеты сессий.

Реальный виновник - расширения JSSE и TLS с нулевыми значениями, которые билеты сеанса используют при первом запросе.

Любая вероятность того, что на вашем сервере заканчиваются случайные данные. Под Linux, если вы используете /dev/randomи исчерпываете случайные данные, ваш сервер заблокируется, и загрузка страницы будет выглядеть так, как будто она зависает.

Обычно /dev/urandomэто достаточно хорошо. Если это не так, есть какое-то оборудование, которое вы можете получить, которое будет генерировать случайные данные для вас.

Я вижу, что вы работаете с ASP .NET - я не могу комментировать, является ли это проблемой для Windows, но которую стоит посмотреть.