☰

런타임 들어오고 나가는 트래픽 없음

tag-icon • tag-icon linux networking netstat wireshark traffic
런타임 들어오고 나가는 트래픽 없음

아무것도 실행되지 않는 시스템에서(적어도 내가 아는 바는 아님) 들어오고 나가는 트래픽을 수신하면 다음 출력이 인쇄됩니다.

192.168.1.1              => all-systems.mcast.net             0b     26b     19b
                         <=                                   0b      0b      0b
192.168.1.2              => 224.0.0.251                     128b     26b     19b
                         <=                                   0b      0b      0b

(가끔 26b나 128b만 표시되는 것이 아니라 실제 메시지가 전송되는 것처럼 큰 숫자로 점프하는 경우도 있습니다.)

무슨 뜻이에요?

192.168.1.1은 게이트웨이, 내 라우터입니다

192.168.1.2는 나, 나의 기계

그런데 all-systems.mcast.net은 누구입니까? 224.0.0.251은 누구입니까? 더 중요한 것은 패킷이 전송되는 이유는 무엇입니까?

이것을 찾았습니다: https://davidsimpson.me/2015/11/16/why-is-my-machine-contacting-all-systems-mcast-net/ 하지만 DLNA 서버가 실행되고 있지 않습니다. 그럼 누구에게 방송해야 하나요?

마지막(중요한) 질문은 다음과 같습니다. 192.168.1.2 무언가에 연락하는 것은 이해할 수 있고 192.168.1.1 나에게 연락하는 것은 이해할 수 있지만 192.168.1.1 모든 시스템에 연락하는 것이 왜 표시되는지 이해하지 못합니다. 내 컴퓨터를 모니터링하면 내 라우터에서 들어오는 트래픽이 표시되지만 나에게 전송되지는 않습니까? 이런 걸 보면 안 되겠죠?

내가 사용하는 유틸리티는 다음과 같습니다.

   iftop - display bandwidth usage on an interface by host

유틸리티 tcptrack 및 netstat에는 아무 것도 표시되지 않았습니다. 그렇다면 유일한 합리적인 설명은 이 유틸리티가 해당 트래픽을 담당한다는 것입니다.

이슈 업데이트

따라서 이 멀티캐스트는 분명히 내 시스템의 커널과 내 라우터에 통합되어 있으며 매우 기본적인 질문 및 답변 시스템인 타이머가 60초마다 작동합니다. 나는 그 이유를 잘 이해하지 못하며 몇몇 좋은 사람들이 나에게 그것을 설명하려고 노력한 후에도 나는 결코 이해하지 못할 것 같습니다. 그래서 나는 그것을 끄고 싶다. 가능합니까?

답변1

표시되는 이러한 패킷은 일반 멀티캐스트 서비스입니다(프로세스는 브로드캐스트 패킷과 유사하지만 그 자체는 브로드캐스트가 아닙니다). 네트워크의 출력 트래픽도 (일반적으로) 무시할 수 있습니다.

실제로 자신이 생성한 트래픽뿐만 아니라 네트워크상의 다른 컴퓨터가 생성한 주소에서 발생한 트래픽도 볼 수 있습니다.

  • 224.0.0.1은 all-systems.mcast.net입니다.

기본적으로 모든 (Linux) 서버는 정기적으로 네트워크의 224.0.0.1로 멀티캐스트하여 근처 라우터에 멀티캐스트 호출이 가능함을 보고합니다. 이러한 패킷은 Linux 커널에서 전송되어야 합니다.

  • 224.0.0.251은 mDNS입니다.

224.0.0.251의 경우 Avahi/zeroconf는 이를 서비스 공지 및 검색에 사용합니다.

Avahi는 멀티캐스트 DNS/DNS-SD 서비스 검색을 위한 시스템을 포함하는 무료 제로 구성 네트워킹(zeroconf) 구현입니다.

바라보다Cisco - 멀티캐스트 소개

당신은 또한 볼 수 있습니다TLDP - TCP/IP를 통한 멀티캐스트 HOWTO

클래스 D 주소 - 멀티캐스트 주소/224.0.0.0 - 239.255.255.255

o 224.0.0.1은 모든 호스트 그룹입니다. 그룹을 ping하면 네트워크의 모든 멀티캐스트 가능 호스트가 응답해야 합니다. 왜냐하면 각 멀티캐스트 가능 호스트는 시작 시 모든 멀티캐스트 가능 인터페이스에서 그룹에 참여해야 하기 때문입니다.

작동하지 않는 패킷을 보려면 브로드캐스트 및 멀티캐스트 패킷/안내를 들어야 합니다. 이는 일반적으로 모든 스테이션으로 전송되기 때문입니다. 여기서 다루지 않을 미묘한 차이가 있습니다. 내가 링크한 소개를 참조하세요.

마지막으로 iftop트래픽을 확인하는 동안 트래픽 생성에 대한 책임은 없습니다.

또한 서버가 속한 멀티캐스트 그룹을 볼 수도 있습니다.

netstat -g

마지막으로 일반 사용자/사용자가 프로그램을 실행하지 않는다고 해서 시스템이 실행 중이라는 의미는 아닙니다.아무것도 없다. Linux는 백그라운드에서 많은 관리 작업을 수행하는 다중 사용자/멀티 태스킹 시스템입니다.

답변2

멀티캐스트 IP 트래픽에는 일반 유니캐스트 또는 브로드캐스트 트래픽과 다른 규칙이 있습니다. 멀티캐스트 IP 주소는 소스 주소로 사용되지 않으며 항상 대상 주소로만 사용됩니다. 멀티캐스트를 보내는 시스템은 일반 IP 주소를 소스 주소로 사용합니다. 각 멀티캐스트 IP 주소에는멀티캐스트 그룹: 이 멀티캐스트 주소로 전송된 모든 내용은 이 그룹에 속한 모든 호스트에서 수신됩니다. (또는 이것이 이론입니다. 실제로 멀티캐스트 트래픽은 서브넷이나 조직 외부로 멀티캐스트를 라우팅하도록 특정 조치를 취하지 않는 한 기본적으로 이러한 제한에서 중지되는 경향이 있습니다.)

호스트의 일부 소프트웨어가받다트래픽을 멀티캐스팅할 때 호스트 커널에 "이 멀티캐스트 IP 주소로 전송된 멀티캐스트를 수신하고 싶습니다"라고 알려줍니다. 그런 다음 커널은 수신할 멀티캐스트 주소 목록에 멀티캐스트 IP 주소를 추가하고 IGMP 보고 메시지를 발행합니다. "이 멀티캐스트 IP로 주소가 지정된 멀티캐스트 트래픽을 수신하고 싶습니다." IGMP 보고서 자체는 멀티캐스트 IP 메시지입니다. Linux에서 IGMP는 커널 수준에서 처리되므로 이를 담당하는 프로세스를 볼 수 없습니다.

멀티캐스트 가능 라우터는 또한 주기적으로(보통 60초마다) 다음과 같은 IGMP 쿼리 메시지를 보냅니다. 기본적으로 "이 네트워크 세그먼트의 모든 시스템에: 여전히 멀티캐스트 트래픽에 관심이 있는 경우 즉시 보고하십시오." 224.0.0.1 = all-systems.mcast.net으로 전송된 IP 메시지. 아마도 라우터가 보내는 내용일 것입니다. 이 주소의 DNS 이름에서 알 수 있듯이 모든 멀티캐스트 가능 호스트는 항상 224.0.0.1로 주소가 지정된 멀티캐스트 트래픽을 수신해야 합니다.

멀티캐스트 가능 호스트는 다음 두 가지 상황에서 IGMP 보고서를 보내야 합니다.

  • 특정 멀티캐스트 IP로 주소가 지정된 트래픽 수신을 시작하거나 중지하려는 경우
  • IGMP 쿼리 메시지를 수신한 경우.

일반적으로 호스트의 커널은 이를 자동으로 처리합니다. Linux에서는 이를 사용하여 cat /proc/net/igmp시스템이 현재 각 네트워크 인터페이스에서 수신 대기 중인 멀티캐스트 IP를 확인할 수 있습니다. 불행하게도 멀티캐스트 IP는 16진수로 보고되며 바이트 순서는 일반적인 IP 주소 형식과 반대입니다. 예를 들어 224.0.0.1은 "010000E0"으로 표시되고 224.0.0.251은 "FB0000E0"으로 표시됩니다.

멀티캐스트를 지원하는 라우터는 자신이 속한 각 네트워크 세그먼트에 IGMP 쿼리를 보내고 응답으로 받은 IGMP 보고서를 추적합니다. 이는 특정 멀티캐스트 IP 주소에 대한 멀티캐스트 트래픽을 한 네트워크 세그먼트에서 다른 네트워크 세그먼트로 라우팅해야 하는지 여부를 아는 방법입니다.

예외: IGMP 쿼리가 네트워크 세그먼트에서 이루어지고 이미 라우터보다 소스 IP 주소가 낮은 다른 소스가 있는 경우 라우터는 쿼리를 보내지 않고 수신만 합니다. 그러나 라우터 간의 멀티캐스트 트래픽을 조정하기 위해 일부 멀티캐스트 라우팅 프로토콜을 사용하여 다른 IGMP 쿼리 소스와 통신하려고 시도할 수도 있습니다.

멀티캐스트 가능 호스트가 세 번의 연속 IGMP 쿼리(즉, 180초)에 응답하지 않으면 라우터는 호스트가 더 이상 멀티캐스트 트래픽에 관심이 없다고 가정합니다. 이렇게 하면 호스트가 재부팅되거나 전원이 꺼지거나 네트워크 연결이 끊어지는 경우 불필요한 멀티캐스트 스트림이 지워집니다.

간단한 홈 Wi-Fi 네트워크에서 멀티캐스트는 유용성이 제한됩니다. Wi-Fi 네트워크의 모든 호스트 그룹은 멀티캐스트를 사용하든 단순 브로드캐스트를 사용하든 관계없이 모든 사람의 공유 무선 대역폭을 계속 소비합니다. 그러나 유선 또는 메시 Wi-Fi 네트워크에서 멀티캐스트를 사용하면 스위치 및/또는 AP가 IGMP 메시지를 모니터링하여 특정 멀티캐스트 패킷을 특정 스위치 포트나 Wi-Fi 장치로 전송해야 하는지 여부를 이해할 수 있습니다. 이는 특정 멀티캐스트에 관심이 없지만 스위치/AP에서 더 많은 작업을 수행해야 하는 사용자를 위해 대역폭을 절약합니다. 이 기능을 "IGMP 스누핑"이라고 합니다.

관련 정보