UDP를 통해 RTSP 비디오 패킷을 보내는 서버(카메라)가 있습니다. 고객 사이트에서는 여러 홉을 거치는데, 그 중 하나는 이상한 패킷 또는 5개의 패킷을 삭제하는 신뢰할 수 없는 WiFi 링크일 수 있습니다. 일반적으로 이것은 눈에 띄지 않지만 때로는 몇 초 동안 스트림을 중단하고 고객을 불행하게 만듭니다. (저도 알고 있습니다. 그들의 cr*p 네트워크가 어느 정도 우리의 문제라는 것을 알고 있습니다...)
시뮬레이션된 의심스러운 연결로 테스트하는 동안 tc
이상한 상황을 발견했습니다.반품방향(패킷이 자동으로 삭제됩니다.), RTSP 클라이언트(Live555 Wis-Streamer)가 계속 작동하더라도 몇 초 후에 카메라에서 스트리밍되는 UDP 패킷이 중지됩니다.믿다UDP 패킷을 파이프 아래로 행복하게 뿌리고 있습니다.
UDP 패킷이 승인되지 않고 물리적 링크가 절대 손실되지 않기 때문에 이는 이상한 일입니다. 따라서 우리 시스템은 패킷이 체인의 비트 버킷으로 삭제되고 있다는 것을 알 수 없으며 스트리머는 아무도 알 수 없습니다. 이를 수신합니다(스트리밍 세션 시간 초과는 나중에 만료되지 않음).
편집: 우리는 ARPing을 봅니다(누가 <고객>) 이 시점에서 UDP 패킷은 더 이상 들어오지 않지만 그 전에는 스택에 연결이 끊어졌음을 알리는 패킷이 없습니다.
그래서 두 가지 질문이 있습니다.
- 네트워크 스택이 연결에 문제가 있음을 알 수 있는 다른 메커니즘이 있습니까?
- 특정 상황에서 네트워크 스택이 자동으로 패킷을 삭제합니까?
테스트 설정 시연:
정상 상태, 양방향 연결:
Our server <==> Switch <==> TC <==> Switch <==> PC
| |
Wireshark <-- TAP |
|
Wireshark <----------------------- TAP
오류 상태, TC는 서버로 반환된 패킷을 삭제합니다.
Our server --> Switch --> TC <==> Switch <==> PC
| |
Wireshark <-- TAP |
|
Wireshark <----------------------- TAP
답변1
연결이 끊어지면 ICMP 대상에 연결할 수 없는 패킷을 수신하여 연결이 끊어졌음을 알려야 합니다. 이는 정상적인 IP 동작입니다.
ICMP 패킷을 모니터링하고 표시할 수 있는 도구가 있습니다. 다른 도구를 사용하여 선택 기준을 충족하는 모든 트래픽을 덤프하거나 캡처할 수 있습니다.
패킷을 삭제하려면 사용자 정의 프록시 서버를 사용하는 것이 더 나을 수도 있습니다.
답변2
글쎄, ARP 테이블이 점점 더 이상해지고 있는 것 같습니다. (우리가 UDP를 미친 듯이 스트리밍하더라도 이로 인해 ARP 시간 초과가 발생하지 않으며 정상적인 작동 시 TCP 트래픽이 더 드물어집니다.) 시간 초과를 늘리면 문제가 발생하는 것을 방지할 수 있습니다. 약 2분 미만의 "중단"(이 시점에서 RTSP 클라이언트 세션 시간이 초과됨):
ARP gc_staletime extended from 60sec to 360sec
ARP base_unreachable time extended from 30sec to 240sec
불행하게도 Busybox에서 사용할 수 있는 명령이 없었기 때문에 상당한 탐색이 필요했지만 arp
현재로서는 우리가 처리하려는 상황에 대해 신뢰할 수 있는 것 같습니다.
저는 여전히 네트워크 스택이 어떻게 작동하는지 이해하고 싶습니다. 현재 ARP 테이블/항목이 오래되어 패킷 전송이 중지되지만 패킷 전송을 시도하는 코드 체인에서 더 이상 오류가 발생하지 않는 것 같습니다.