Nhật ký IIS hiển thị sc-win32-status = 64 nhưng chỉ thông qua một số mạng

Tôi có một ứng dụng ASP.NET đang chạy trên máy chủ (W2k3, IIS6, .NET 2.0). FWIW, đây là phiên bản thử nghiệm , nó chưa được chuyển vào Sản xuất . Vì vậy, nó không chạy theo SSL, cân bằng tải, v.v.

Khi tôi truy cập một trong các trang trên máy chủ của họ từ văn phòng của chúng tôi, trang sẽ bị tấn công một lần. Kiểm tra nhật ký IIS (c: WINDOWS \ system32 \ LogFiles \ W3SVC1) hiển thị GET cho trang đó, sau đó tôi nhấn một nút trên trang và tệp nhật ký hiển thị POST. Điều này dường như đang làm việc tốt cho đến nay.

Bây giờ khi tôi truy cập vào mạng của khách hàng và truy cập trang từ một trong các máy cục bộ của họ, tệp nhật ký sẽ hiển thị GET, sau đó tôi nhấn nút trên trang và nhật ký hiển thị hai POST trong cùng một giây. Cái đầu tiên hiển thị trạng thái (sc-status, sc-subsatus, sc-win32-status) 200 0 64, cái thứ hai hiển thị 200 0 0.

Trong tệp nhật ký, cả hai POST đều giống hệt nhau. Về cơ bản nhật ký trông như thế này (ngoại trừ tôi che giấu một số dữ liệu):

#Fields: ngày thời gian s-ip cs-phương thức cs-uri-thân cs-uri-query s-port cs-username c-ip cs (User-Agent) sc-status sc-subsatus sc-win32-status 
2009-08-11 20:19:32 xxxx GET /File.aspx - 80 - yyyy Mozilla / 4.0 + (tương thích; + MSIE + 8.0; + Windows + NT + 6.0; + WOW64; + Trident / 4.0; + SLCC1; + .NET + CLR + 2.0.50727; +. NET + CLR + 3.5.21022; +. NET + CLR + 3.5.30729; +. NET + CLR + 3.0.30618; + MDDR; + OfficeLiveConnector.1.4; + OfficeLivePatch .0.0) 200 0 0
2009-08-11 20:19:45 xxxx POST /File.aspx - 80 - yyyy Mozilla / 4.0 + (tương thích; + MSIE + 8.0; + Windows + NT + 6.0; + WOW64; + Trident / 4.0; + SLCC1; + .NET + CLR + 2.0.50727; +. NET + CLR + 3.5.21022; +. NET + CLR + 3.5.30729; +. NET + CLR + 3.0.30618; + MDDR; + OfficeLiveConnector.1.4; + OfficeLivePatch .0.0) 200 0 64
2009-08-11 20:19:45 xxxx POST /File.aspx - 80 - yyyy Mozilla / 4.0 + (tương thích; + MSIE + 8.0; + Windows + NT + 6.0; + WOW64; + Trident / 4.0; + SLCC1; + .NET + CLR + 2.0.50727; +. NET + CLR + 3.5.21022; +. NET + CLR + 3.5.30729; +. NET + CLR + 3.0.30618; + MDDR; + OfficeLiveConnector.1.4; + OfficeLivePatch .0.0) 200 0 0

Vấn đề là , trang đang bị tấn công hai lần. Cơ sở dữ liệu thực hiện một thao tác cho yêu cầu đầu tiên, sau đó yêu cầu thứ hai phát hiện ra rằng một hoạt động trùng lặp đang được thực hiện và đưa ra một thông báo lỗi. Người dùng nghĩ rằng hoạt động của họ thất bại, nhưng nó thực sự đã thành công.

Mô tả lỗi của sc-win32-status 64 là: "Tên mạng được chỉ định không còn khả dụng." Điều này khiến tôi tin rằng, cả hai yêu cầu POST đều hiển thị trạng thái HTTP là 200, rằng máy chủ thành công trong việc phục vụ yêu cầu, nhưng máy khách không bao giờ được thông báo và gửi lại yêu cầu.

• Làm thế nào tôi có thể khắc phục sự cố này?

• Bất kỳ ý tưởng những gì có thể gây ra hành vi này chỉ trên mạng nội bộ của họ?

• Tôi nên đề cập, điều này xảy ra ở hai trang web khách hàng riêng biệt, nhưng không xảy ra tại sáu trong số các trang web khách hàng khác của chúng tôi hoặc trong văn phòng của chúng tôi hoặc kết nối với bất kỳ khách hàng nào trong số tám khách hàng của chúng tôi trên web.

• Điều gì có thể làm cho điều này có thể tái tạo 100% thời gian trên mạng cục bộ của họ nhưng 0% thời gian ở bất cứ nơi nào khác?

Cập nhật: Tôi tìm thấy một số lượng rất nhỏ các yêu cầu POST trùng lặp có trạng thái sc-win32 là 995 thay vì 64 như báo cáo ban đầu. Mô tả lỗi của sc-win32-status = 995 là: "Thao tác I / O đã bị hủy vì thoát khỏi luồng hoặc yêu cầu ứng dụng." Điều này không có ý nghĩa gì (vì tôi có toàn quyền truy cập vào mã). Tôi vẫn không hiểu làm thế nào hoặc tại sao sự cố này xảy ra, nhưng mã lỗi mới khiến tôi tin rằng đó có thể không phải là sự cố mạng và hiện tôi đang điều tra khả năng xảy ra lỗi mã ngẫu nhiên.

Đây là sự hiểu biết của tôi về vấn đề cho đến nay:

• sc-win32-status 64 có nghĩa là tên mạng Tên được chỉ định không còn khả dụng.
• Sau khi IIS đã gửi phản hồi cuối cùng cho máy khách, thông thường, nó sẽ chờ thông báo ACK từ máy khách.
• Đôi khi, khách hàng sẽ đặt lại kết nối thay vì gửi ACK cuối cùng về máy chủ. Đây không phải là một kết nối duyên dáng, vì vậy IIS ghi lại mã 64 64.
• Nhiều khách hàng sẽ thiết lập lại kết nối khi họ hoàn thành với nó, để giải phóng ổ cắm thay vì để nó trong TIME_WAIT / CLOSE_WAIT.
• Proxy có xu hướng làm điều này nhiều hơn những người khác làm.

Cập nhật: Tôi đã tìm thấy một số thông tin thú vị ở đây và đây , vì vậy về cơ bản tôi đã viết lại trang để đảm bảo không có bất kỳ đánh dấu xấu nào, v.v. và ... vấn đề đã biến mất! Đó chỉ là một phát súng trong bóng tối, và tôi chắc chắn không thể nói điều gì đã khắc phục vấn đề, vì nó chỉ ảnh hưởng đến một số khách hàng của chúng tôi trong một số trường hợp rất cụ thể ...

Tôi gặp vấn đề tương tự khi cố gắng phục vụ các tệp nhị phân được nén từ IIS6 thông qua máy chủ proxy. Tôi đã không gặp bất kỳ vấn đề khi đi trực tiếp vào trang web.

Tôi thấy đây là nguyên nhân trong trường hợp của mình khi chạy Fiddler trên máy khách và kiểm tra phản hồi. Fiddler cảnh báo rằng phản hồi được mã hóa và sau đó phàn nàn rằng số ma thuật trên tệp gzip là không chính xác.

Tôi đã tắt nén gzip cho các tệp nhị phân trong mã của mình và sự cố đã dừng xảy ra.

Tôi không phải là chuyên gia về vấn đề này nhưng tôi đã gặp một vấn đề tương tự chỉ xảy ra khi sử dụng địa chỉ IP thay vì tên máy chủ.

Có lẽ điều đó giúp một chút ...

Chiếu.