지난 공유기 연결이 안 된 상태에서 멀티피어 연결 최적화 시도 후 아쉬움이 남았던 부분을 프레임워크 작동 방식 관측을 통해 원인을 찾고자 함.
Wireshark: 네트워크 패킷을 실시간으로 캡처하고 분석하는 프로그램.
MultipeerFramework의 공개된 소스코드를 찾을 수 없었고, 내부 구현을 직접적으로 관찰할 방법을 찾지 못하였다. 대신 MultipeerFramework를 리버스 엔지니어링 한 아티클을 볼 수 있었는데, 해당 글에서도 Wireshark를 이용한 관측 결과를 바탕으로 프레임워크의 동작 방식을 확인하고 있었다.
본 문서에서는 필자가 직접 Wireshark를 이용해 미러링부스 앱을 관측한 결과를 정리하고자 한다.
아티클 주소: https://www.evilsocket.net/2022/10/20/Reverse-Engineering-the-Apple-MultiPeer-Connectivity-Framework/
DNS란?
Domain Name System.
IP 네트워크에서 숫자의 연속인 IP 주소 사용이 힘들기 때문에 쉽게 사용할 수 있는 도메인 주소로 변환하는 서버의 일종이다.
mDNS란?
Multicast DNS.
중앙 DNS 서버가 없는 로컬 네트워크 환경에서 같은 공유기에 연결된 ‘모든 기기’에 멀티캐스트.
실제 관측 결과, 처음 멀티피어 Browser를 작동하는 화면에서 다량의 패킷을 전송하는 모습이 발견되었다.
Source/Destination
Destination은 일반적인 mDNS 주소를 IPv4 및 IPv6 두 가지 형태로 관측할 수 있었다.
Source는 한 번 관측이 될 때마다 7개의 주소가 관측되었는데, 절반은 IPv4를 IPv6 형태로 대응한 것으로 보이며, 동일한 주소가 중복으로 관측되는 것을 제외하면 실제로는 두 가지 주소가 사용되는 것으로 보인다. 172로 시작되는 주소는 Wi-Fi 인터페이스, 169로 시작되는 주소는 AWDL을 위한 인터페이스 주소라고 한다.
시간
시간마다 7개씩 패킷을 보내고 있는데, 처음에는 1초 이내의 짧은 주기로 반복하다 3번째 사이클에선 3초, 이후로 9초, 27초, 66초로 점점 패킷을 보내는 주기가 길어지는 것을 확인할 수 있었다.
QU/QM
Info에서 우리가 정한 서비스 이름과 함께 QU, QM question을 구분하는 것을 확인할 수 있었다.
(위 약자 해석에 대해서는 AI, 아티클 등에서 조금씩 다르게 발견되었으나 핵심은 Unicast/Multicast의 구분으로 보인다.)
이는 응답 방식의 차이로, QU는 응답 기기가 패킷에 포함된 IP주소로 직접 응답, QM은 멀티캐스트 주소를 통해 응답해야한다. (RFC 6762 mDNS 표준 문서에서 확인할 수 있다고 한다.)
관측한 결과에서는 초반에는 QU, 후반에는 QM으로 보내고 있었는데, QU 질의를 요청하면 주변 기기에 영향을 주지 않고 응답을 보낼 수 있어서 QU를 사용하다가 주기가 점점 느려지기 때문에 QM으로 전환하는 것으로 보인다. (QM으로 전환하면 한 번 응답을 할 때 다른 기기에 전파되는 정보를 통해서 미래의 연결에 대해 네트워크 양을 절약할 수 있다고 한다.)
Wi-Fi 연결 없이
Wi-Fi 연결 없이 Browsing을 시도할 때는 패킷이 3개 단위로 관측되었으며, 그 주소는 169로 시작하는 주소와 IPv6형태의 주소였다.(AWDL)
