Chrome chậm trên các trang https, đặc biệt là các trang nội bộ

Chúng tôi đang cố gắng triển khai Google Chrome trên mạng công ty của mình, nhưng chúng tôi thấy rằng phải mất 2-4 lần để tải trang https (đặc biệt là trang nội bộ của chúng tôi) so với IE. Có ai có kinh nghiệm này và tìm thấy một sửa chữa?

Cập nhật

Dựa trên đề xuất của Handyman5, tôi đã chạy một số chẩn đoán trong Chrome và thấy rằng lượng thời gian lớn nhất (hơn 90% trên mỗi trang) đã được sử dụng để kéo các tệp tĩnh từ Cache và hiển thị trang. Tuy nhiên, nếu tôi tắt SSL trên trang web của chúng tôi, điều này gần như ngay lập tức.

Bất kỳ suy nghĩ về lý do tại sao điều này sẽ được?

Chrome có một công cụ chẩn đoán tích hợp tuyệt vời, "about: net-internals" , được thiết kế để giúp khắc phục sự cố mạng. Cụ thể, nó có tab "Sự kiện" cho phép bạn chỉ định URL và sau đó Chrome chia nhỏ toàn bộ quá trình tải, từng bước, bao gồm độ phân giải DNS, lần truy cập bộ đệm và yêu cầu thành phần AJAX.

tl; dr Kiểm tra cách Chrome xử lý kiểm tra và thu hồi chứng chỉ.

Chúng tôi đã có một vấn đề rất giống nhau tại một cơ sở mà tôi từng làm việc trước đây, nhưng với Firefox. Để đây là một vấn đề, bạn cần xác nhận sự cố chỉ với các trang https. Nếu không, nó sẽ làm cho sự khác biệt nhỏ.

Với Firefox (tôi biết, tôi biết, tôi có thể đọc, sắp phát hành), một nhóm người gặp vấn đề trong khi người dùng Internet Explorer (nếu bạn có thể tin điều đó) thì không. Chúng tôi đã sử dụng cơ quan ipsCA khét tiếng vì chúng miễn phí cho các tổ chức giáo dục, nhưng cuối cùng đã khiến Firefox nổi giận với sự xấu hổ của họ và việc kiểm tra OCSP về certs của họ là thủ phạm . Hóa ra trình duyệt bị trì hoãn vì xử lý Danh sách thu hồi chứng chỉ vì bản chất của các chứng chỉ SSL của chúng tôi. Rõ ràng, với tư cách là người giỏi nhất trong chúng tôi, đã không đề cập đến phiên bản Chrome của bạn, vì vậy thật khó để nói đó có phải là sự cố khônghoặc vẫn là một vấn đề. Tuy nhiên, tôi sẽ kiểm tra cấu hình CRL trong Chrome. Làm như vậy trong Firefox giảm bớt vấn đề. Ngoài ra, hãy kiểm tra certs của bạn ở trạng thái tốt, đó là nếu chúng tự ký. Những gì đã cho nó sử dụng là chúng tôi đã chuyển khỏi tự ký vì những người dùng dịch vụ ngốc của chúng tôi đã than vãn rất nhiều và nó hoàn toàn miễn phí. Chúng tôi nghĩ rằng chúng tôi đã tự cứu mình một cơn đau đầu, nhưng chúng tôi làm cho nó tồi tệ hơn.

Chúng tôi đã triển khai Google Chrome trong nội bộ, để hỗ trợ một ứng dụng được phát triển tùy chỉnh (trên ASP.NET MVC) nhưng chạy trên HTTP bình thường.

Chúng tôi cũng gặp sự cố với các trang chậm vì bộ đệm. Có vẻ như Chrome đã kéo tất cả các tệp tĩnh trên mỗi lần tải trang và không lưu chúng vào bộ đệm. Chúng tôi đã kết thúc đơn giản bằng cách thêm các tiêu đề hết hạn vào ứng dụng của mình để buộc bộ nhớ cache và điều đó đã hoạt động.

Bạn có thể đi theo tuyến đường đó (sửa đổi các ứng dụng web của mình để chỉ định chiến lược bộ đệm cho từng loại tệp) hoặc điều tra thêm hành vi bộ đệm ẩn mặc định của Chrome.

Những người khác dường như có vấn đề tương tự (ví dụ: http://www.google.com/support/forum/p/Chrom/thread?tid=741fd9e03cfb7e7b&hl=vi ).

Bài viết này có thể hữu ích vì nó cung cấp một đoạn mồi về bộ nhớ đệm Chrome: http://gent.ilcore.com/2011/02/chromes-10-caches.html

Tôi đã chạy vào cùng một vấn đề. Sau khi tìm kiếm trong một thời gian dài, tôi phát hiện ra với công cụ theo dõi quá trình ( https://technet.microsoft.com/en-us/sysi INTERNals / Processmonitor.aspx ) Chrome đã gặp phải nhiều xung đột khi cố gắng ghi vào% TEMP%. Xóa thư mục này đã giải quyết vấn đề cho tôi.

Cuối cùng, tôi không thể tìm thấy câu trả lời ở đây. Tất cả các thử nghiệm giám sát và định hình cho thấy Google Chrome rất chậm trong việc tải nội dung tĩnh an toàn từ bộ đệm của máy khách cục bộ. Không biết tại sao. Chúng tôi đã phải cho tất cả người dùng nội bộ của mình chuyển sang IE (đó là điều mà hầu hết những người gặp vấn đề tương tự trên web đã làm).

Nếu phụ trợ là máy chủ ứng dụng dựa trên java, có một lỗi java phổ biến khiến Vé phiên TLS gây ra độ trễ rất lớn. Bạn có thể mô phỏng lỗi bằng cách sử dụng openssl s_client thực sự mới và bảo nó kích hoạt / vô hiệu hóa vé phiên.

Thủ phạm thực sự là các phần mở rộng JSSE so với TLS với các giá trị null, mà vé phiên sử dụng theo yêu cầu đầu tiên.

Bất kỳ khả năng nào máy chủ của bạn hết dữ liệu ngẫu nhiên. Trong Linux nếu bạn sử dụng /dev/randomvà hết dữ liệu ngẫu nhiên, máy chủ của bạn sẽ chặn và tải trang sẽ trông như bị treo.

Thông thường /dev/urandomlà đủ tốt. Nếu đó không phải là trường hợp có một số phần cứng bạn có thể nhận được sẽ tạo dữ liệu ngẫu nhiên cho bạn.

Tôi thấy bạn đang chạy ASP .NET - Tôi không thể nhận xét về vấn đề đó là một vấn đề trên Windows, nhưng rất đáng để xem xét.