저는 현재 MTCP(MultiPath TCP)를 WSL2에 통합하는 프로젝트를 진행하고 있는 학생입니다. 그러나 우리는 큰 문제에 직면했습니다. WSL2는 "기본" 네트워크 인터페이스만 노출하므로 MTCP의 최적 작동에는 충분하지 않습니다. 커널을 다시 컴파일하고 MTCP를 활성화해도 여러 인터페이스가 필요하기 때문에 예상대로 실행되지 않습니다. 내 질문은 제안된 MTCP 지원 네트워크 아키텍처에 대한 귀하의 생각은 무엇입니까? 더 쉬운 방법이 있습니까, 아니면 개선할 수 있는 것이 있습니까? 미리 감사드리며, 좋은 하루 보내세요 :)
아키텍처 분석은 다음과 같습니다.
서버 애플리케이션(Windows):
인터페이스 모니터: 이 구성 요소는 네트워크 인터페이스를 모니터링합니다. 클라이언트는 주기적으로 서버에 인터페이스 목록을 요청하고 이 정보를 기반으로 인터페이스를 추가하거나 제거합니다. 또는 서버는 이 정보를 WSL 파일 시스템의 파일에 쓸 수 있으며, 클라이언트는 해당 파일을 읽어 해당 인터페이스를 업데이트합니다.
TAP 인터페이스에서 패킷 수신: 클라이언트가 TAP 인터페이스를 생성한 후 서버는 데이터 패킷 수신을 담당하는 스레드를 생성합니다. 클라이언트는 인터페이스 업데이트를 통해 패킷을 보낼 적절한 포트에 대한 알림을 받습니다. 각 TAP 인터페이스는 전용 포트에 해당합니다.
NAT 패킷: 패킷 수신을 처리하는 스레드에서는 서버가 해당 IP 필드를 수정하여 NAT(Network Address Translation)를 수행합니다. 이는 TCP 패킷 수정을 단순화하는 PcapPlusPlus와 같은 라이브러리를 사용하여 단순화할 수 있습니다.
패킷 보내기: StackOverflow의 일부 스레드에서는 Windows가 원시 패킷을 직접 보내는 것을 제한한다고 제안합니다. 해당 인터페이스에 직접 데이터를 보내는 옵션을 계속 탐색 중입니다.
클라이언트 애플리케이션(WSL2):
TAP 인터페이스 생성: 클라이언트는 이에 따라 TAP 인터페이스를 생성하거나 삭제하여 인터페이스 업데이트에 반응합니다.
인터페이스 모니터링: TAP 인터페이스가 생성되면 클라이언트는 libpcap이라는 라이브러리를 사용하여 TAP 인터페이스에서 패킷을 스니핑합니다.
UDP를 통해 패킷 보내기: 각 인터페이스는 캡처된 데이터 패킷이 올바르게 전송되도록 보장하기 위해 전용 포트와 연결됩니다.
응답을 받다: 스레드는 실제 Windows 인터페이스로부터 응답을 수신하고 TAP 인터페이스에 기록됩니다.