TCP나 UDP를 사용하지 않으면 무슨 일이 일어날까?

• 네트워크 인프라는 스위치, 브리지, 라우터, 로드 밸런서, 방화벽 등으로 구성됨
• 운영체제는 패킷을 분류하고, 큐에 배치하며, 방화벽 규칙을 적용하는 등 네트워크 통신을 제어함
• 그렇다면 존재하지 않는 전송 계층 프로토콜을 사용하면 어떻게 될까?
• OS가 허용할까? 패킷이 실제로 전달될까? 방화벽이 차단할까?
• 직접 실험을 진행하여 확인함

인터넷 프로토콜 개요

• 인터넷은 여러 계층의 프로토콜이 데이터를 전달하는 방식으로 동작함
• 애플리케이션이 요청을 보내면, OS가 이를 여러 네트워크 계층의 헤더로 감싸면서 전송함
• 전송 계층(Transport Layer): TCP(6), UDP(17) 등의 프로토콜이 위치함
• IP 헤더의 Protocol 필드를 수정하여 미사용된 번호를 넣으면 어떤 일이 벌어질까?

실험 #1: 내 PC에서 직접 테스트

실험 방법

1. HDP(가짜 프로토콜) 정의: 기존 프로토콜과 전혀 다른 새로운 전송 계층 프로토콜 설계
2. 서버와 클라이언트 구현: 패킷을 송수신하는 프로그램 개발
3. 루프백(loopback) 테스트: OS가 자체적으로 패킷을 처리하는 방식 관찰

실행 과정

결과

• OS가 HDP 패킷을 정상적으로 처리하여 루프백 인터페이스를 통해 다시 수신됨
• IP 프로토콜 번호를 변경하여 추가 테스트 진행
  • 1 (ICMP), 2 (IGMP), 6 (TCP) → 서버에서 감지되지 않음
  • 50, 51 (IPSec 관련 프로토콜) → 클라이언트에서 전송 자체가 차단됨
  • 256 (IP 프로토콜 번호 범위 초과) → socket() 호출 단계에서 오류 발생

원인 분석

• OS가 특정 프로토콜 번호를 시스템적으로 예약하여 차단하는 경우 존재
• Darwin(BSD 기반 macOS)에서는 socket() 호출 시 protocol=0을 설정하면 일부 패킷이 자동 필터링됨
• IPSec 관련 프로토콜은 보안상의 이유로 차단될 가능성이 큼
• IPv4 프로토콜 번호는 8비트이므로 0~255까지만 유효함

실험 #2: 인터넷에서 패킷 전송

실험 계획

1. DigitalOcean VPS 설정: 독일 프랑크푸르트에 있는 클라우드 서버에 실험 환경 구축
2. HDP 패킷 전송: 내 PC(사우디아라비아)에서 DigitalOcean 서버로 패킷을 송신
3. 네트워크 장비의 반응 분석: 패킷이 도착하는지, 방화벽이 차단하는지 확인

예상 결과

• HDP 패킷이 정상적으로 전달되거나, 일부 ISP 또는 DigitalOcean의 방화벽이 차단할 가능성이 있음

실제 결과

• 첫 번째 패킷만 전달되고 이후 패킷은 차단됨
• tcpdump를 사용하여 확인한 결과:
  • 내 PC에서 패킷이 정상적으로 전송됨
  • DigitalOcean 서버에서는 첫 번째 패킷만 감지됨
  • 이후 패킷은 어딘가에서 차단됨 (NAT, 방화벽, ISP 등)

원인 분석

• DigitalOcean에서는 비표준 IP 프로토콜을 지원하지 않음
• 클라우드 제공업체의 방화벽 정책이 주요 원인일 가능성이 큼
• 왜 첫 번째 패킷만 도착했는지는 불명확함

AWS에서 재실험

• AWS에서 두 대의 인스턴스를 사용하여 실험을 재진행함
• 같은 데이터센터 내에서는 HDP 패킷이 정상적으로 송수신됨
• 그러나 인터넷을 통해 전송할 경우 DigitalOcean과 동일한 첫 번째 패킷만 도착하는 문제 발생

주요 이슈

• NAT(Network Address Translation): TCP/UDP 포트 기반으로 작동하므로 HDP 같은 신규 프로토콜을 다룰 방법이 없음
• 방화벽/네트워크 필터링: 대부분의 ISP와 클라우드 제공업체는 미승인 IP 프로토콜을 차단함
• 네트워크 장비의 최적화 문제: 일부 네트워크 장비는 비표준 패킷을 무조건 삭제할 가능성이 있음

결론: TCP와 UDP를 사용하는 것이 최선

• OS 간의 네트워크 스택 구현이 다름
  • Linux, macOS, Windows에서의 socket() 동작 방식이 제각각임
• 방화벽과 NAT 장비가 비표준 프로토콜을 차단함
  • 개인 네트워크에서는 동작하더라도 인터넷에서는 거의 불가능함
• 성능 개선 효과 없음
  • UDP 기반으로 구현된 QUIC 등 이미 검증된 대안이 존재함
• TCP/UDP를 사용하자
  • 표준 프로토콜을 사용하면 포트 기반 NAT, 방화벽, 라우팅 등이 자동으로 지원됨

추가 자료

• UDP 프로토콜 사양
• IP 프로토콜 번호 목록
• Raw 소켓의 플랫폼별 차이