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

> Clean Markdown view of GeekNews topic #19467. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=19467](https://news.hada.io/topic?id=19467)
- GeekNews Markdown: [https://news.hada.io/topic/19467.md](https://news.hada.io/topic/19467.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2025-02-27T14:21:21+09:00
- Updated: 2025-02-27T14:21:21+09:00
- Original source: [github.com/Hawzen](https://github.com/Hawzen/hdp)
- Points: 13
- Comments: 5

## Summary

네트워크 통신에서 TCP나 UDP가 아닌 새로운 전송 계층 프로토콜(HDP)을 사용하여 실험한 결과, OS는 루프백 인터페이스에서는 HDP 패킷을 처리할 수 있었지만, 인터넷에서는 대부분의 패킷이 차단되었습니다. 이는 DigitalOcean과 같은 클라우드 제공업체의 방화벽 정책과 NAT(Network Address Translation) 등의 네트워크 장비가 비표준 프로토콜을 차단하기 때문입니다. 따라서, 표준 프로토콜인 TCP와 UDP를 사용하는 것이 네트워크 상호 운용성과 성능 면에서 최선의 선택입니다.

## Topic Body

- 네트워크 인프라는 스위치, 브리지, 라우터, 로드 밸런서, 방화벽 등으로 구성됨  
- 운영체제는 패킷을 분류하고, 큐에 배치하며, 방화벽 규칙을 적용하는 등 네트워크 통신을 제어함  
- 그렇다면 **존재하지 않는** 전송 계층 프로토콜을 사용하면 어떻게 될까?  
- OS가 허용할까? 패킷이 실제로 전달될까? 방화벽이 차단할까?  
- 직접 실험을 진행하여 확인함  
  
### 인터넷 프로토콜 개요  
  
- 인터넷은 여러 계층의 프로토콜이 데이터를 전달하는 방식으로 동작함  
- 애플리케이션이 요청을 보내면, OS가 이를 여러 네트워크 계층의 헤더로 감싸면서 전송함  
- **전송 계층(Transport Layer)**: TCP(6), UDP(17) 등의 프로토콜이 위치함  
- IP 헤더의 `Protocol` 필드를 수정하여 **미사용된 번호**를 넣으면 어떤 일이 벌어질까?  
  
### 실험 #1: 내 PC에서 직접 테스트  
  
#### 실험 방법  
1. **HDP(가짜 프로토콜) 정의**: 기존 프로토콜과 전혀 다른 새로운 전송 계층 프로토콜 설계  
2. **서버와 클라이언트 구현**: 패킷을 송수신하는 프로그램 개발  
3. **루프백(loopback) 테스트**: OS가 자체적으로 패킷을 처리하는 방식 관찰  
  
#### 실행 과정  
```bash  
$ sudo cargo run --bin server  # 서버 실행  
$ fortune | cowsay | sudo cargo run --bin client 127.0.0.1  # 클라이언트 실행  
```  
  
#### 결과  
- 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 프로토콜 사양](https://datatracker.ietf.org/doc/html/rfc768)  
- [IP 프로토콜 번호 목록](https://en.wikipedia.org/wiki/List_of_IP_protocol_numbers)  
- [Raw 소켓의 플랫폼별 차이](https://hackaday.com/2024/09/21/when-raw-network-sockets-arent-raw-raw-sockets-in-macos-and-linux/)

## Comments



### Comment 35418

- Author: junhochoi
- Created: 2025-03-04T11:40:10+09:00
- Points: 1

https://www.saturnsoft.net/network/2019/03/21/quic-http3-1/ 를 읽어보셔도 도움이 될 것 같네요.

### Comment 35250

- Author: secret3056
- Created: 2025-02-28T16:08:23+09:00
- Points: 2

옛날 스타크래프트에서 하마치로 멀티를 할 때 IPX가 있었는데, 그 때 이게 뭘까 참 궁금했던 기억이 나네요.

### Comment 35249

- Author: secret3056
- Created: 2025-02-28T16:06:50+09:00
- Points: 1

생각해보니 NAT이 모든걸 막겠군요...IPv6가 완전히 정착하고 NAT이 없어진다면(그럴 일은 없을 것 같지만) 자신이 만든 프로토콜로 통신하는것도 가능할 수 있겠어요.

### Comment 35203

- Author: tujuc
- Created: 2025-02-27T14:42:40+09:00
- Points: 1

오호 좋은 시도군요...  
네트워크 근간을 흔드는 시도는 좋았으나, 이 세상의 모든 네트워크 장비는 TCP/UDT 에 특화된 장비만 있어서...  
  
네트워크 장비가 틀 찍어내기라는 것을 모를때... 는 가능할꺼같은데... 알고나면 내가 잘되서 내 프로토콜을 모두가 사용하도록 하겠다가 아니면 못하는 거란걸 알게되죠...

### Comment 35201

- Author: neo
- Created: 2025-02-27T14:21:21+09:00
- Points: 1

###### [Hacker News 의견](https://news.ycombinator.com/item?id=43169103) 
- TCP보다 우수하지만 채택되지 않은 오래된 프로토콜인 SCTP가 있음
  - 네트워크 하드웨어가 TCP와 UDP 외의 모든 것을 차단했기 때문임
- 다양한 전송 프로토콜을 구현한 사람으로서 IP 위에 계층을 쌓는 가장 큰 장애물은 WAN 라우터가 아닌 소비자 NAT 장치임
  - 특정 Netgear 라우터의 경우, 트래픽이 끝까지 살아남지만 첫 4바이트가 0으로 변하는 특정한 손상이 발생했음
  - 이는 TCP/UDP로 처리되었지만 실제 번역 경로는 따르지 않았다고 의심됨
- TCP나 UDP를 사용하지 않으면 통신이 어려울 것임
  - 인터넷은 TCP와 UDP를 표준으로 삼고 있음
  - 다른 프로토콜을 처리할 수 없는 장치가 많음
  - 인터넷 하드웨어를 모두 교체하는 것은 IPv4를 폐기하는 것보다 더 오래 걸릴 것임
  - 새로운 프로토콜의 큰 이점이 있어야만 모든 기업과 정부가 큰 비용을 들여 지원을 구현할 것임
- 기사의 끝이 클리프행어처럼 느껴짐
  - 왜 커스텀 프로토콜의 단일 패킷만 통과하고 나머지는 드롭되었는지 궁금함
- TCP/UDP 패킷은 OS 네트워크 스택에 의해 특정 포트를 듣는 프로세스에만 전송된다고 생각했음
  - 이는 보안 기능일 수 있으며, 권한이 없는 프로세스는 일부 포트를 들을 수 없음
  - 다른 프로세스가 모든 트래픽을 캡처할 수 있을 것이라고 기대하지 않음
  - 여러 전송 계층 프로토콜의 트래픽을 캡처할 수 있는지 몰랐음
  - 아마도 해당 시스템 호출은 높은 권한을 요구할 것임
- 인터넷 프로토콜과 라우팅 장비가 오늘날 처음부터 설계되었다면 어떻게 되었을지 궁금함
  - 훨씬 큰 패킷과 UDP 스타일의 기본 프로토콜이 HTTP를 대체했을 것임
  - 간단한 스트리밍 프로토콜이 TCP를 대체하고 비디오 재생을 지원했을 것임
  - 이 두 프로토콜이 대부분의 트래픽을 더 효율적으로 처리했을 것임
- "바퀴를 재발명한다면 어떻게 될까?"라는 가정임
- 패킷 소켓이 필요함
  - IP 네트워크는 모든 것을 전달해야 하지만 NAT가 주요 문제임
  - IPv6로 시도해보는 것이 흥미로울 것임
- TCP/UDP/IP가 모든 것을 장악하기 전의 다른 프로토콜을 사용했을 것임
- 모두 UUCP를 사용했을 것임
  - TCP/UDP 이전에 유사한 작업을 수행했음