https 사이트, 특히 내부 사이트보다 느린 Chrome

Google은 회사 네트워크 전체에 Chrome을 배포하려고하지만 IE와 비교하여 https 페이지 (특히 자체 내부 페이지)를로드하는 데 2-4 배 더 오래 걸리는 것으로 나타났습니다. 누구든지 이것을 경험하고 수정을 찾았습니까?

최신 정보

Handyman5의 제안에 따라 Chrome에서 일부 진단을 실행했으며 캐시에서 정적 파일을 가져 와서 페이지를 렌더링하는 데 가장 많은 시간 (각 페이지에서 90 % 이상)이 소요되고 있음을 발견했습니다. 그러나 우리 사이트에서 SSL을 끄면 거의 즉각적입니다.

왜 이것이 될지에 대한 생각?

Chrome에는 네트워크 문제를 해결하는 데 도움 이되는 멋진 내장 진단 도구 인 'about : net-internals' 가 있습니다. 특히 URL에는 URL을 지정할 수있는 '이벤트'탭이 있으며 Chrome은 DNS 확인, 캐시 적중 및 AJAX 요소 요청을 포함하여 URL을로드하는 전체 프로세스를 단계별로 분류합니다.

tl; dr Chrome에서 인증서 확인 및 해지를 처리하는 방법을 확인하십시오.

우리는 이전에 일했던 시설에서 비슷한 문제를 겪었지만 Firefox와 관련이있었습니다. 이것이 문제가 되려면 https 페이지에만 문제가 있는지 확인해야합니다. 그렇지 않다면 별 차이가 없습니다.

파이어 폭스 (알다시피, 내가 읽을 수 있고 앞으로 나올 수 있음)를 사용하면 많은 사람들이 Internet Explorer 사용자들 (믿을 수 있다면)이 그렇지 않은 동안 문제를 겪었습니다. 우리는 악명 높은 ipsCA 권한을 교육 기관에 무료로 제공했기 때문에 사용 했지만 결국 그늘에서 Firefox를 화나게했고 인증서에 대한 OCSP 검사는 범인 이었습니다. SSL 인증서의 특성으로 인해 인증서 해지 목록 처리로 인해 브라우저가 지연되고있는 것으로 나타났습니다. 분명히 우리 중 최고로서 Chrome 버전을 언급하지 않았으므로 문제 인지 말하기가 어렵습니다.또는 여전히 문제입니다. 그러나 Chrome에서 CRL 구성을 확인합니다. Firefox에서 그렇게하면 문제가 완화되었습니다. 또한 인증서에 문제가 없는지, 즉 자체 서명 된 인증서인지 확인하십시오. 우리가 사용하는 것은 우리 서비스의 바보 사용자가 많이 휘두르고 무료이기 때문에 자체 서명에서 멀어졌습니다. 우리는 우리 자신을 두통으로 구하고 있다고 생각했지만 악화 시켰습니다.

Google은 내부적으로 Chrome을 배포하여 ASP.NET MVC에서 맞춤 개발 애플리케이션을 지원하지만 일반 HTTP에서 실행되도록했습니다.

캐시 때문에 페이지가 느려지는 문제도있었습니다. Chrome이 모든 페이지로드에서 모든 정적 파일을 가져 와서 캐시에 저장하지 않은 것 같습니다. 결국 캐시를 강제로 실행하기 위해 만료 헤더를 앱에 추가하는 것이 끝났습니다.

이 경로를 내려가거나 (웹 애플리케이션을 수정하여 각 유형의 파일에 대한 캐싱 전략을 지정) Chrome의 기본 캐싱 동작을 자세히 조사 할 수 있습니다.

다른 사람들도 비슷한 문제가있는 것 같습니다 (예 : http://www.google.com/support/forum/p/Chrome/thread?tid=741fd9e03cfb7e7b&hl=ko ).

이 도움말은 Chrome 캐싱에 대한 입문서를 제공하므로 유용 할 수 있습니다. http://gent.ilcore.com/2011/02/chromes-10-caches.html

나는 같은 문제에 부딪쳤다. 오랫동안 검색 한 후 프로세스 모니터 도구 ( https://technet.microsoft.com/en-us/sysinternals/processmonitor.aspx )를 사용하여 Chrome에서 % TEMP %에 쓰려고 많은 충돌이 발생했습니다. 이 디렉토리를 지우면 문제가 해결되었습니다.

결국 여기에서 답을 찾지 못했습니다. 모든 모니터링 및 프로파일 링 테스트에 따르면 Chrome이 로컬 클라이언트 캐시에서 보안 정적 컨텐츠를로드하는 속도가 매우 느립니다. 왜 그런지 모르겠다. 우리는 모든 내부 사용자가 IE (웹에서 비슷한 문제를 가진 대부분의 사람들이 수행 한 IE)로 전환해야했습니다.

백엔드가 Java 기반 응용 프로그램 서버 인 경우 TLS 세션 티켓으로 인해 상당한 지연이 발생하는 일반적인 Java 버그가 있습니다. 정말 새로운 openssl s_client를 사용하고 세션 티켓을 활성화 / 비활성화하도록 지시하여 버그를 시뮬레이션 할 수 있습니다.

실제 원인은 null 값을 가진 JSSE vs. TLS 확장이며 세션 티켓은 첫 번째 요청에 사용됩니다.

서버에 임의의 데이터가 부족할 가능성이 있습니다. Linux /dev/random에서 임의의 데이터 를 사용 및 소진하면 서버가 차단되고 페이지로드가 중단 된 것처럼 보입니다.

일반적으로 /dev/urandom충분합니다. 그렇지 않은 경우 임의의 데이터를 생성하는 하드웨어가있을 수 있습니다.

ASP .NET을 실행하고 있음을 알았습니다 .Windows에서는 문제가 될 수 있지만 살펴볼 가치는 있습니다.