Sự cố bắt tay SSL? (là: Trang web bị treo, chỉ xóa bộ nhớ cache của trình duyệt giúp)

Question

Vui lòng xem ở phần cuối, vì tôi liên tục cập nhật dữ liệu điều tra mới nhất. Hiện tại, tôi cần trợ giúp với nhật ký WireShark phía máy chủ.

Tôi gặp sự cố lạ với ứng dụng web ASP.NET MVC. Rất ít người dùng gặp phải các hình thức hết thời gian chờ sau khi đăng bài và do đó sau khi nhấp vào, việc gửi nó chỉ kéo dài mãi mãi và không chuyển sang trang tiếp theo. Điều kỳ lạ là, điều này được giải quyết bằng cách xóa bộ nhớ cache của trình duyệt. Tôi không hiểu hai thứ này có thể liên quan như thế nào. Ngoài ra, một người dùng báo cáo rằng nó xảy ra trong FireFox 3+, nhưng không xảy ra trong FireFox 1.5 và 2.0. Tôi và nhiều người dùng không thể tái tạo điều này, trên IE, bất kỳ FireFox và cả Linux/Windows.

Làm cách nào và tại sao bộ nhớ cache của trình duyệt có thể ảnh hưởng đến quá trình xử lý POST?

OK Tôi đã kiểm tra với người dùng và FireBug. Tôi thấy yêu cầu POST và không thành công sau khi hết thời gian chờ. Máy chủ không nhận được yêu cầu - ít nhất, không phải là OnBeforeExecuting của bộ điều khiển cơ sở nơi tôi ghi nhật ký, cũng như trong các tệp nhật ký IIS. Câu trả lời trống. Ngoài ra, một khi yêu cầu mất nhiều thời gian nhưng cuối cùng đã được thực hiện - và trên máy chủ tôi thấy rằng phải mất rất ít thời gian để thực thi.

Theo tôi thấy điều này xảy ra đối với các yêu cầu AJAX được thực hiện bằng plugin Biểu mẫu jQuery. Tôi đã thử thiết lập bộ nhớ cache: sai trong các tham số, không thành công.

Thực ra, tôi đã thử mà không có AJAX, gửi đơn giản - giống nhau. Tôi cũng có thể thấy rằng plugin dạng jQuery DOES gọi $ .ajax() và trả về. Tôi thấy rằng nó bắt đầu yêu cầu POST. Nhưng tôi không thấy yêu cầu này trên máy chủ trong bản ghi IIS, cho đến khi, đôi khi, trong một phút sau đó - và đôi khi nó bị hủy trong ngăn FireBug .Net.

Điều thú vị là xóa bộ nhớ cache/cookie/biểu mẫu của FireFox & dữ liệu bài giúp - cho một lần thử, bài đăng tiếp theo cũng bị treo.

Ngoài ra, các yêu cầu gửi thông tin về các thành phần đã chọn dưới dạng GUID. Khi các thành phần không được chọn, nó có vẻ hoạt động tốt. Các thành phần thực sự là các hộp kiểm ẩn được kiểm tra bởi JavaScript (không phải tại thời điểm gửi, trước đó). Đây là thông số "được chọn" trong dữ liệu POST. Có vẻ như khi không có thành phần nào được chọn, nó không treo, mặc dù tôi chỉ thử một lần, có thể sẽ điều tra thêm sau.

Bất kỳ suy nghĩ nào có thông tin bổ sung này?

Request info: 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.8) Gecko/20100722 Firefox/3.6.8 (.NET CLR 3.5.30729; .NET4.0C) 
Accept: */* 
Accept-Language: en-us,en;q=0.5 
Accept-Encoding: gzip,deflate 
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 
Keep-Alive: 115 
Connection: keep-alive 
Content-Type: application/x-www-form-urlencoded; charset=UTF-8 
X-Requested-With: XMLHttpRequest 
Content-Length: 1288 
Pragma: no-cache 
Cache-Control: no-cache 

dữ liệu POST

trật tự = 842f2988-abff-413c-a092-9dde00a8b9a8 & chọn = f98c9ad8-49e0-4a9f-9966-9d3d01203aa5_a1d659c0-b8ec-4f91-ba2f-9d3d01203a4c & chọn = f98c9ad8-49e0 -4a9f-9966-9d3d01203aa5_d6e1984e-227d-4bd0-b8d2-9d3d01203a4d & chọn = f98c9ad8-49e0-4a9f-9966-9d3d01203aa5_0b7cbc1a-35f1-4db8-856b-9d3d01203a4c & chọn = f98c9ad8-49e0-4a9f-9966-9d3d01203aa5_0cc7ef9b-085f-4b50 -acdb-9d3d01203a4c & được chọn = f98c9ad8-49e0-4a9f-9966-9d3d01203aa5_ad273397-ed5d-49bb-b181-9d3d01203a4c & chọn = f98c9ad8-49e0-4a9f-9966-9d3d01203aa5_b5fbf67f-202f-464b-a9e4-9d3d01203a4c & chọn = f98c9ad8-49e0-4a9f-9966-9d3d01203aa5_ae275579-8163-4f6b-9d36-9d3d01203a4c & chọn = f98c9ad8-49e0-4a9f-9966- 9d3d01203aa5_73fa066c-0467-4bc6-aa91-9d3d01203a4c & chọn = f98c9ad8-49e0-4a9f-9966-9d3d01203aa5_5020b52f-baa2-4aea-be10-9d3d01203a4d & chọn = f98c9ad8-49e0-4a9f-9966-9d3d01203aa5_8b2cd95a-c014-4c83-9ec6-9d3d01203a4d & selected = f98c9ad8-49e0-4a9f-9966-9d3d01203aa5 & gửi = Thêm + Tới + Suite

Cài đặt WireShark. Thật khó để sử dụng mà không cần điều khiển trực tiếp (người dùng từ xa theo lệnh của tôi) nhưng tôi có thể thấy rằng ngay lập tức sau khi nhấp vào gửi, một yêu cầu TCP được gửi đến địa chỉ IP của máy chủ. Vì vậy, trình duyệt thực hiện một yêu cầu.

Yêu cầu người dùng từ xa cộng tác với hỗ trợ CNTT/mạng để kiểm tra xem yêu cầu có được gửi từ máy khách/đến máy chủ hay không.

Và đây là một vấn đề rất giống nhau, không may mà không có câu trả lời: https://stackoverflow.com/questions/3355000/my-iis-server-wont-serve-ssl-sites-to-some-browsers

Dưới đây là Wireshark log từ máy chủ. Quá trình gửi bắt đầu, sau đó một số thay đổi về cypher/bắt tay SSL xảy ra (trong 90 giây!), Sau đó sau khi yêu cầu thời gian dài cuối cùng không thành công.

No.  Time  Source    Destination   Protocol Info 

    1 0.000000 11.22.33.44   192.168.1.9   TCP  [TCP segment of a reassembled PDU] 

    2 0.000114 11.22.33.44   192.168.1.9   TLSv1 Application Data 

    3 0.000394 192.168.1.9   11.22.33.44   TCP  https > 50950 [ACK] Seq=1 Ack=2305 Win=64690 Len=0 

    4 97.611245 192.168.1.9   11.22.33.44   TCP  https > 50950 [RST, ACK] Seq=1 Ack=2305 Win=0 Len=0 

    5 97.752530 11.22.33.44   192.168.1.9   TCP  50958 > https [SYN] Seq=0 Win=8192 Len=0 MSS=1459 WS=2 SACK_PERM=1 

    6 97.752612 192.168.1.9   11.22.33.44   TCP  https > 50958 [SYN, ACK] Seq=0 Ack=1 Win=16384 Len=0 MSS=1460 WS=0 SACK_PERM=1 

    7 97.778024 11.22.33.44   192.168.1.9   TCP  50958 > https [ACK] Seq=1 Ack=1 Win=17508 Len=0 

    8 97.784462 11.22.33.44   192.168.1.9   TLSv1 Client Hello 

    9 97.785107 192.168.1.9   11.22.33.44   TLSv1 Server Hello, Change Cipher Spec, Encrypted Handshake Message 

10 97.813970 11.22.33.44   192.168.1.9   TLSv1 Change Cipher Spec, Encrypted Handshake Message 

11 97.814082 11.22.33.44   192.168.1.9   TLSv1 Application Data 

12 97.814208 192.168.1.9   11.22.33.44   TCP  https > 50958 [ACK] Seq=123 Ack=2555 Win=64647 Len=0 

13 227.535270 192.168.1.9   11.22.33.44   TCP  https > 50958 [RST, ACK] Seq=123 Ack=2555 Win=0 Len=0 

Answer 1

Từ những gì tôi phát hiện ra, có vẻ như AVG vấn đề. Khi tôi bật tính năng LinkScanner và Shield trực tuyến (cả hai), các yêu cầu POST từ Chrome và Safari (không hoạt động) bắt đầu hoạt động.

Answer 2

Tôi rất muốn khuyên bạn nên sử dụng wireshark trên cả máy chủ và máy khách và xem dữ liệu nào thực sự được gửi. Tôi đã chạy vào các lỗi lạ tương tự như thế này, và nhìn thấy giao tiếp thực tế giữa mỗi khách hàng và máy chủ luôn luôn là instructive. Tôi sẽ bắt đầu với kết thúc máy chủ. Nắm bắt các gói dữ liệu, sau đó sử dụng "theo dõi dòng tcp" trên POST.
Wireshark Download
Using Wireshark

Answer 3

Tôi gặp sự cố rất giống nhau (nhưng nó không giải quyết ngay cả sau khi xóa bộ nhớ cache của trình duyệt). Ngay cả khi cài đặt lại Windows cũng không giải quyết được. Cuối cùng thấy rằng đó là tường lửa Sygate đáng tin cậy của tôi đã được thêm một số dữ liệu cho mỗi yêu cầu bài viết (để chặn pop-up hoặc như vậy, từ sự hiểu biết hạn chế của tôi) đã gây ra vấn đề. Tôi tắt Sygate và hiện đang trên tường lửa Windows Firewall, và vấn đề đã biến mất.

Answer 4

Tôi gặp sự cố tương tự khi trình duyệt mac không tải trang SSL từ máy chủ Win2k3 chạy IIS 6.0. Cập nhật khung .net đã khắc phục sự cố Firefox và Camino, nhưng không khắc phục được sự cố Safari. Tắt Trình quét trực tuyến AVG đã khắc phục sự cố Safari của tôi, nhưng trình quét liên kết chưa được cài đặt. Tìm thấy bài đăng này và nó đã khắc phục sự cố của tôi.

cảm ơn