tìm ra lý do cho việc ngắt kết nối Ổ cắm Web xảy ra

Question

Tôi đang sử dụng các ổ cắm Web Jetty trong Ứng dụng của tôi với Jetty 7 làm Máy chủ của chúng tôi.

Trong ứng dụng của chúng tôi, dữ liệu sẽ liên tục chảy trong mỗi 1 giây thông qua Web Socket và theo thiết kế ứng dụng của chúng tôi, nếu Socket không hoạt động trong 4 phút thì Socket sẽ bị ngắt kết nối. Ngay bây giờ, chúng tôi đang gặp phải sự cố ngắt kết nối web trong Ứng dụng của chúng tôi, tôi không thể tìm ra lý do cho lý do ngắt kết nối Socket Web, điều này là do Ổ cắm không hoạt động trong 4 phút hoặc Đã xảy ra sự cố ở cấp độ mạng (ý tôi là cân bằng tải, tường lửa --etc)

đối với mỗi ngắt kết nối, bên Jetty mã lý do như năm 1006 (chrome)

Xin vui lòng cho tôi biết làm thế nào tôi có thể tìm ra nguyên nhân thực tế cho ngắt kết nối đã xảy ra?

Có cách nào tôi có thể theo dõi lưu lượng truy cập socket web không?

Tôi đã thử sử dụng tab Websocket của trình gỡ lỗi Chrome để theo dõi lưu lượng truy cập, nhưng khi nó bị ngắt kết nối, tôi không có kết cục về dữ liệu nào có trong Websocket tại thời điểm đó?

Hãy chia sẻ ý tưởng của bạn về cách xử lý trường hợp này là cách tìm hiểu lý do tìm kiếm WebSocket là gì?

Answer 1

1006 là chấm dứt bất thường. Đôi khi bạn sẽ nhận được thông báo này với thông báo "Phản hồi bắt tay chưa hoàn tất". Bạn có thể sử dụng TCP Mon hoặc Wireshark để theo dõi lưu lượng ổ cắm và xem các tiêu đề đang được truyền đi.

Tôi cũng thấy điều này nếu máy chủ không được thiết lập để nhận dữ liệu lớn trên kết nối. Bạn sẽ thấy một cái gì đó như "kết nối đóng cửa, trạng thái = 1006, Lý do = EOF". Jetty giới hạn kích thước của thông điệp mà máy chủ có thể nhận được. Nếu bạn cố gắng gửi một tin nhắn lớn hơn kích thước này, Jetty sẽ đóng kết nối. Bạn có thể tăng giới hạn kích thước thư trên một kết nối bằng cách sử dụng setMaxBinaryMessageSize và setMaxTextMessageSize của đối tượng Connection. http://download.eclipse.org/jetty/stable-7/apidocs/org/eclipse/jetty/websocket/WebSocket.Connection.html

Hy vọng điều này sẽ hữu ích.

Answer 2

Các nhà phát triển Jetty HIGHLY khuyên bạn nên nâng cấp lên Jetty 9 khi làm việc với WebSockets. (bố, tôi là một committer Jetty)

Jetty 7 và 8 thực hiện phiên bản đầu của WebSocket nháp, và tùy thuộc vào trình duyệt, bạn sẽ nhận được hành vi rất khác nhau của WebSocket.

trình duyệt với sự hỗ trợ tiền cuối cùng cho WebSocket (mà Jetty 7 và 8 sẽ làm việc với)

• Safari 5.x (hoặc sớm hơn)
• Opera 12.x (hoặc sớm hơn)
• Opera Mini (tất cả các phiên bản)
• Chrome 13.x (hoặc sớm hơn)
• Firefox 10.x (hoặc sớm hơn)
• IE 9.x (hoặc sớm hơn)
• Trình duyệt Android (mọi phiên bản)
• Trình duyệt Blackberry (phiên bản trước 10.x)
• Bất kỳ cây cầu Shockwave/Flash WebSocket hiện có nào.

Bắt đầu với Jetty 9, tất cả hỗ trợ cho các phiên bản nháp của WebSocket đã bị xóa chỉ có lợi khi làm việc với phiên bản RFC-6455 được phát hành.

Hiện tại, với sự cố mã 1006 của bạn.

Đó là local side only close status code, bắt nguồn và được báo cáo bởi Chrome. Tùy thuộc vào phiên bản Chrome của bạn, lý do lỗi 1006 của bạn có thể thuộc hàng tá lý do khác nhau. Gần như tất cả đều đun sôi xuống cả hai vấn đề kết nối hoặc giao thức.

Với Jetty 7 và 8, có nhiều thời gian chờ khác nhau và kiểm tra nhàn rỗi (một số ở đầu nối, một số ở lớp Endpoint, một số ở lớp Kết nối, thậm chí một số trong lớp HTTP và nhiều hơn nữa trong các lớp WebSocket) có thể theo cách của bạn và chấm dứt, một cách khắc nghiệt, kết nối mà không cần phải bắt tay với WebSocket.

Điều này đã được giải quyết trong Jetty 9. Có 2 lần hết giờ, bắt tay và không hoạt động.

Nếu sự cố là giao thức liên quan, bạn có thể thấy mã lỗi 1006 Chấm dứt bất thường/không sạch (chỉ ở phía địa phương) hoặc vi phạm giao thức 1002.

Tại thời điểm này, bạn có thể nâng cấp lên Jetty 9, với giao thức tốt hơn, hết thời gian chờ, kết nối, đóng và thông báo lỗi. Hoặc bạn có thể bật tất cả các bản sửa lỗi trên Jetty phía máy chủ 7/8 và hy vọng bạn thấy một StackTrace cho biết nguyên nhân của vấn đề ở phía máy chủ.