Làm thế nào để phát hiện nếu mạng đang bỏ các gói UDP?

Tôi có một ứng dụng truyền phát video chạy tốt trong văn phòng của mình nhưng thất bại thảm hại tại địa điểm của khách hàng. Triệu chứng là cứ sau vài giây, tôi ngừng nhận gói UDP trong 2 giây, sau đó luồng lại tiếp tục như thể không có gì sai.

Tôi đã chạy http://www.pingtest.net/ tại vị trí khách hàng và nó đã trở lại tuyệt vời. Không có gói bị rơi và độ trễ thấp. Sự khác biệt duy nhất tôi nhận thấy giữa hai địa điểm của chúng tôi là ping google.cathời gian chờ tại địa điểm của họ nhưng hoạt động tại địa điểm của tôi.

Làm cách nào để kiểm tra xem mạng tôi đang chặn các gói UDP đến chưa? Có cách nào để tôi cách ly người đang đánh rơi các gói không?

networking udp

— Gili
nguồn

Âm thanh như một vấn đề tường lửa đối với tôi. Bạn có bất kỳ tường lửa phần mềm hoặc phần cứng?

— Pitto

Bạn không thể hỏi khách hàng cấu hình mạng của họ được đặt thành gì?

— Ramhound

@Ramhound, lý tưởng là không. Tôi không muốn phải đào sâu vào cài đặt bộ định tuyến của khách hàng tiềm năng mỗi lần tôi muốn dùng thử sản phẩm của mình :)

— Gili

Các bạn, xin vui lòng giải thích phiếu bầu tiêu cực của bạn, nếu không tôi không thể trả lời.

— Gili

Câu trả lời:

Bạn có thể thử thiết lập kết nối UDP với netcat.

Trên máy A bên ngoài mạng của người tiêu dùng chạy:

nc -u -l -p 1234            # if using netcat-traditional
nc -u -l 1234               # if using netcat-openbsd (as pointed out by @JamesHaigh)

Lưu ý -uhướng dẫn netcat sử dụng UDP. (Và cũng cần lưu ý rằng, có các phiên bản khác nhau netcat, có cần -ptham số hay không; được đưa ra là các biến thể cho hai phiên bản phổ biến nhất (?), Cả hai đều có trong Debian.)

Về vị trí của người tiêu dùng : nc -u [addr of machine A] 1234.

Cố gắng gửi gửi một số văn bản, hoặc thậm chí tốt hơn sử dụng các đường ống để gửi một tệp giữa cả hai vị trí và thực hiện một khác biệt sau đó.

— mpy
nguồn

Lệnh từ xa của bạn không thành công cho tôi. Trang này nói, vì -l, VIỆT It is an error to use this option in conjunction with the -p, -s, or -z options., vì vậy tôi đã sửa lệnh thành một lệnh mà tôi đã thử nghiệm để làm việc. Ngoài ra, tôi đã thay đổi 'ip' thành 'addr' vì tên máy chủ cũng có thể được sử dụng và theo nghĩa là một 'địa chỉ'.

— James Haigh

@JamesHaigh: Tôi đồng ý với bạn về điểm addrso với ip. Nhưng bây giờ với lệnh của bạn, tôi gặp lỗi: listen needs -p arg(Tôi cũng đã kiểm tra các lệnh của mình được đưa ra trong câu trả lời ;)). Có nhiều nc khác nhau, nếu bạn cung cấp thêm một số chi tiết như phiên bản nc và / hoặc bản phân phối của bạn, tôi sẽ thêm một ghi chú vào câu trả lời của tôi.

— mpy

Ồ đúng rồi, thật xấu hổ vì chúng không tương thích lẫn nhau! :-( Ok, vì vậy máy từ xa của tôi là Debian. Lệnh mặc định nclà symlink /bin/nc -> /etc/alternatives/nc -> /bin/nc.openbsdđược cung cấp bởi gói Debian netcat-openbsd. Máy Ubuntu cục bộ của tôi cũng có nc.openbsdmặc định. Tôi cũng không chấp nhận -l -p. Tôi cũng đã cài đặt ncattrên cả hai máy từ nmapgói Ubuntu / Debian. máy Debian cũ hơn, ncattừ chối -l -p, nhưng ncattrên Ubuntu chấp nhận cả hai cách. Mặc dù phiên bản Debian phải là cổ vì nó khó chịu không có --sctptùy chọn .: - /

— James Haigh

Ps distro của bạn là gì và ncbiến thể? Tôi nhận thấy rằng cũng có một netcat-traditionalgói '', nhưng tôi đã không thử nó.

— James Haigh

@JamesHaigh: Tôi thực sự sử dụng netcat-traditional(v 1.10-38) vì nó vận chuyển với debian. Cảm ơn gợi ý của bạn, tôi đã đưa cả hai biến thể vào câu trả lời.

— mpy

ở phía máy chủ, thiết lập máy chủ CẬP NHẬT với

iperf -s -u

ở phía khách hàng, kiểm tra kết nối UDP với

iperf -u -c <IP Address of Server>

— ckarrie
nguồn

Đây là câu trả lời thực sự. Nó đòi hỏi phải có máy chủ truy cập ở phía bên kia. Nhưng nó cung cấp cho bạn thông tin phản hồi mất gói trực tiếp. Và bạn cũng có thể sử dụng nó để kiểm tra băng thông TCP.

— DragonFax

Các netcatlệnh trong câu trả lời của mpy rất hữu ích cho mục đích chẩn đoán, nhưng tôi đang bổ sung câu trả lời đó bằng một cách tiếp cận khác cho vấn đề tiềm ẩn của bạn.

Có thể đáng để làm cho ứng dụng của bạn rơi trở lại SCTP hoặc thậm chí TCP. Tôi thực sự tìm thấy câu hỏi này bởi vì tôi đang tìm cách từ chối các gói UDP đến từ người dùng bằng cách sử dụng nhiều hơn phần chia sẻ của đường xuống khi bị tắc nghẽn, vì không giống như SCTP và TCP, UDP không có kiểm soát tắc nghẽn, rất khó để ưu tiên đường xuống giao thông.

Cả SCTP và TCP đều có kiểm soát tắc nghẽn và chơi tốt với QoS, nhưng SCTP có lợi ích bổ sung so với TCP mà nó được thiết kế cho các ứng dụng phát trực tuyến thời gian thực, làm cho nó thay thế tốt cho cả TCP và UDP. Trong thực tế, SCTP là tốt nhất của cả hai giao thức vận chuyển phổ biến nhất.

Không nên có một dự phòng tồi, thay vì chỉ dựa vào UDP. Ngay cả khi bạn chỉ quay lại với TCP, thì ít nhất bạn có thể nói nó đang hoạt động, có thể chỉ là không tối ưu.

— James Haigh
nguồn