seongw00 님의 블로그

[네트워크]무선 매체 프로토콜의 진화 과정

seongw00 — Fri, 5 Jun 2026 14:33:40 +0900

유선 네트워크 환경에서는 전송 매체(구리선, 광섬유 등)가 물리적으로 격리되어 있어 신호의 감쇄가 적고 충돌 감지가 명확합니다. 반면, 무선 네트워크는 개방된 공기를 매체로 공유하므로 신호 감쇄, 다중 경로 간섭, 그리고 전송 거리의 제한으로 인한 독특한 물리적 현상들이 발생합니다.

본 장에서는 공유 무선 매체의 자원 효율을 극대화하기 위해 발전해 온 ALOHAnet, CSMA/CA, 그리고 전 세계 표준인 IEEE 802.11(Wi-Fi) 기술의 심층 메커니즘과 핵심 프로토콜 구조를 분석합니다.

1. ALOHAnet: 임의 접속(Random Access)의 효시와 수학적 모델

1970년대 하와이 대학교의 노먼 에이브람슨(Norman Abramson) 교수가 개발한 ALOHAnet은 지리적으로 단절된 섬들 간의 데이터 통신을 위해 중앙 컴퓨터와 단말 시스템을 무선 주파수로 연결한 최초의 패킷 교환 무선 네트워크입니다. 현대 대다수 무선 경쟁 기반 프로토콜의 이론적 모태가 됩니다.

1) PureALOHA의 메커니즘과 한계

Pure ALOHA는 완전히 중앙 통제가 없는 지극히 단순한 임의 접속(Random Access) 방식을 취합니다.

동작 원리: 송신 노드는 데이터 패킷이 생성되면 채널의 상태(사용 중 여부)를 확인하지 않고 즉시 전송을 수행합니다.
충돌 회피 및 재전송: 패킷을 전송한 노드는 제한 시간(Timeout) 내에 수신측으로부터 ACK(Acknowledgment) 프레임이 도착하는지 확인합니다. 만약 ACK가 도착하지 않으면 데이터 충돌(Collision)이 발생한 것으로 판단합니다.
이진 백오프의 원형: 충돌을 인지한 노드들이 동시에 재전송을 시도하면 재충돌이 발생하므로, 각 노드는 임의의 무작위 시간(Random Delay) 동안 대기한 후 패킷을 재전송합니다.

기술 심층: 취약 시간(Vulnerable Time)과 처리율(Throughput)

패킷의 전송 시간을 T 라고 할 때, 하나의 패킷이 충돌 없이 안전하게 전송되기 위해서는 해당 패킷 전송 시작 전 T 시간부터 전송이 끝나는 시점까지 다른 어떤 노드도 패킷을 전송하지 않아야 합니다. 따라서 Pure ALOHA의 취약 시간(Vulnerable Time)은 2T가 됩니다.

네트워크 전체의 평균 패킷 발생률을 G (시도된 총 트래픽)라고 할 때, 충돌 없이 전송에 성공할 확률은 포아송 분포를 따르며, 채널 처리율 G는 다음과 같은 수식으로 정의됩니다.
S = G•e^{-2G}
이 함수가 최댓값을 갖는 지점은 G=0.5 일 때이며, 이때의 최대 채널 처리율은 약 18.4%에 불과합니다. 즉, 전체 무선 대역폭의 80% 이상이 충돌로 인해 낭비됨을 의미합니다.

2) Slotted ALOHA (슬롯 알로하)의 시간 동기화

Pure ALOHA의 극심한 채널 낭비를 개선하기 위해 1972년 로버트 메칼프(Robert Metcalfe) 등은 시간을 일정한 크기의 시간 슬롯(Time Slot, 길이 T)으로 분할하는 Slotted ALOHA를 제안합니다.

동작 원리: 모든 노드는 중앙 클록 신호에 의해 엄격하게 시간 동기화가 이루어집니다. 패킷이 언제 발생하든 상관없이, 전송은 반드시 다음 시간 슬롯의 시작점(Slot Boundary)에서만 실행될 수 있습니다.
개선점: 이로 인해 패킷의 일부분만 겹쳐서 전체 데이터가 손실되는 '부분 충돌(Partial Collision)'이 완전히 배제됩니다. 오직 동일한 슬롯 시작점에 두 개 이상의 노드가 동시에 진입할 때만 충돌이 발생합니다.

기술 심층: 슬롯 알로하의 수학적 개선

Slotted ALOHA의 경우, 다른 패킷이 전송 중인 해당 슬롯 안에서만 충돌 가능성이 존재하므로 취약 시간은 T로 줄어듭니다. 이에 따른 처리율 S는 다음과 같습니다.
S = G•e^{-G}
이 함수는 G=1 일 때 최댓값을 가지며, 최대 채널 처리율은 약 36.8%로 Pure ALOHA 대비 정확히 2배 향상됩니다. 그러나 여전히 63.2%의 대역폭 낭비가 존재하여 대규모 무선 자원 관리에는 한계가 있었습니다.

2. CSMA/CA: 무선 환경을 위한 충돌 회피 알고리즘

ALOHA의 무분별한 전송 방식에서 탈피하여, 유선 이더넷(IEEE 802.3)에서 성공을 거둔 CSMA(Carrier Sense Multiple Access) 개념이 무선으로 확장되었습니다. 전송 전 채널을 먼저 감지하는 LBT(Listen Before Talk) 철학의 시작입니다.

1) 왜 무선에서는 CSMA/CD를 사용할 수 없는가?

유선 이더넷은 충돌을 감지하는 CSMA/CD(Collision Detection)를 사용하지만, 무선 LAN 환경에서는 다음 두 가지 치명적인 물리적 한계 때문에 CD(충돌 감지)가 불가능합니다.

자가 신호 감쇄 (Self-Attenuation): 안테나에서 신호를 방출할 때, 송신 노드 자신의 송신 신호 강도가 안테나로 되돌아오는 다른 노드의 수신 신호 강도보다 수만~수십만 배 강합니다. 따라서 자신이 송신하는 중에는 외부의 충돌 신호를 물리적으로 감지할 수 없습니다.
숨겨진 노드 문제 (Hidden Node Problem): 송신 노드의 전파 도달 범위 밖에 있는 제3의 노드가 데이터를 전송하여 수신 노드 측에서 충돌이 발생하더라도, 송신 노드는 이를 전혀 알지 못합니다.

따라서 무선 통신에서는 충돌을 감지(Detection)하는 것이 아니라, 처음부터 충돌을 최대한 회피(Avoidance)하는 CSMA/CA 메커니즘을 정립하게 됩니다.

2) CSMA/CA의 3단계 충돌 회피 매커니즘

CSMA/CA는 정교한 타이머와 가상 감지 기법을 융합하여 채널 경쟁을 제어합니다.

① 1단계: IFS (Inter-Frame Space)를 통한 우선순위 제어

채널이 비어있는(Idle) 상태가 되더라도, 무선 노드들은 즉시 전송하지 못하고 프레임의 성격에 따라 규정된 최소 대기 시간인 IFS 동안 대기해야 합니다. 이를 통해 MAC 계층 수준에서 프레임 간의 우선순위를 부여합니다.

SIFS (Short IFS): 가장 짧은 대기 시간으로 최고 우선순위를 가집니다. ACK, CTS 프레임 등 즉각적인 흐름 제어 응답에 적용되어 다른 노드가 채널을 가로채기 전에 먼저 전송할 수 있도록 보장합니다.
DIFS (Distributed IFS): 일반적인 비동기 데이터 프레임을 전송하기 위해 모든 노드가 기본적으로 대기해야 하는 시간입니다.
EIFS (Extended IFS): 이전 프레임 전송에 오류가 발생했을 때, 다른 노드들에게 충분한 동기화 리커버리 시간을 주기 위해 사용하는 가장 긴 대기 시간입니다.

② 2단계: 이진 백오프 (Binary Exponential Backoff)와 Contention Window

DIFS 시간이 지난 후에도 여러 노드가 동시에 전송을 시작하면 충돌이 발생합니다. 이를 막기 위해 임의의 난수 대기 시간을 도입합니다.

각 노드는 [0, CW] 범위 내에서 임의의 정수(슬롯 카운터)를 무작위로 선택합니다. 여기서 CW는 경쟁 윈도우(Contention Window)입니다.
채널이 Idle 상태인 동안에는 매 슬롯 타임(Slot Time)마다 이 카운터를 1씩 감소(Count Down)시킵니다.
카운트다운 도중 다른 노드가 채널을 점유하면, 즉시 카운트다운을 중지하고 타이머를 동결(Freeze)합니다.
다른 노드의 전송이 끝나고 다시 DIFS만큼 시간이 흐르면, 동결되었던 남은 카운트 값부터 다시 다운을 시작합니다. 카운터가 0에 도달한 노드가 비로소 채널 점유권을 획득하고 프레임을 전송합니다.
CW의 가변성: 초기 CW는 CW_min에서 시작하지만, 전송 실패(충돌)가 발생할 때마다 CW 크기를 2배씩 지수적으로 증가(CW_max까지)시켜 다음 경쟁 시 충돌 확률을 낮춥니다. 전송에 성공하면 다시 CW_min으로 초기화됩니다.

③ 3단계: 가상 캐리어 감지(Virtual Carrier Sensing)와 RTS/CTS 프로토콜

물리적 안테나의 한계를 극복하기 위해 소프트웨어적으로 채널 점유를 감지하는 기법입니다. 무선망의 오랜 난제인 두 가지 물리 현상을 해결합니다.

숨겨진 노드 문제 (Hidden Node Problem): 기지국(AP)을 중심으로 양쪽에 위치한 노드 A와 B가 서로의 존재를 모른 채 AP에게 동시에 데이터를 보내 충돌이 발생하는 현상입니다.
노출된 노드 문제 (Exposed Node Problem): 노드 B가 노드 A와 통신 중일 때, B의 전파 범위 내에 있는 노드 C가 D에게 데이터를 보내고 싶어도 B의 신호를 감지하여 채널이 사용 중이라 오판하고 전송을 포기하는 대역폭 낭비 현상입니다.

이 문제를 완전하게 제어하기 위해 RTS/CTS 핸드셰이킹 기법을 도입합니다.

[송신 노드] ------------ RTS (Request to Send) -----------> [수신 노드 (AP)]
[송신 노드] <------------ CTS (Clear to Send) ------------ [수신 노드 (AP)]
                                                               |
                                                   주변 모든 노드에게 브로드캐스트
                                                   (NAV 설정 유도 -> 침묵)

RTS (Request to Send): 송신 노드는 데이터 전송 전, 수신 노드(AP)에게 전송 시간 정보가 포함된 제어 프레임을 전송합니다.
CTS (Clear to Send): 수신 노드(AP)는 RTS를 정상 수신하면 주변의 모든 노드가 들을 수 있도록 허가 프레임(CTS)을 브로드캐스팅합니다.
NAV (Network Allocation Vector): CTS를 수신한 주변의 모든 노드(숨겨진 노드 포함)는 프레임 내에 명시된 시간 동안 채널이 사용 중이라고 판단하는 NAV 타이머를 구동하여 물리적 감지 결과와 관계없이 전송을 완전히 중단(침묵)합니다.

3. IEEE 802.11: 무선 LAN(Wi-Fi)의 표준 아키텍처 및 진화

IEEE 802.11 규격은 OSI 7계층 모델 중 물리 계층(PHY)과 데이터 링크 계층의 MAC 부계층을 정의하는 표준 기술입니다. 흔히 사용하는 Wi-Fi는 이 표준을 준수하는 제품 간의 상호 호환성을 인증하는 브랜드명입니다.

1) 802.11 MAC 계층의 이중 작동 모드

DCF (Distributed Coordination Function): CSMA/CA 기반의 분산 제어 방식입니다. 중앙의 통제 없이 모든 노드가 동등한 입장에서 경쟁하여 채널을 획득하며, 모든 Wi-Fi 제품의 필수 기본 모드입니다.
PCF (Point Coordination Function): 중앙의 AP가 마스터가 되어 각 노드에게 순서대로 기회를 부여하는 폴링(Polling) 기반의 비경쟁 방식입니다. 실시간 비디오/음성 처리를 위해 설계되었으나 구현 복잡성으로 인해 현대 규격에서는 스케줄링 기반 기술로 대체되었습니다.

2) 802.11 표준의 세대별 도약과 핵심 실무 기술

802.11 표준은 주파수 가용성과 안테나 제어 기술을 극대화하며 비약적으로 성장했습니다.

802.11n (Wi-Fi 4): MIMO 도입
여러 개의 안테나를 동시에 사용하여 다중 데이터 스트림을 전송하는 공간 다중화(Spatial Multiplexing)와 채널 본딩(Channel Bonding)을 도입하여 최대 600Mbps의 시대를 열었습니다.
802.11ac (Wi-Fi 5): 다운링크 공간 분할
안테나의 빔포밍(Beamforming) 기술을 활용해 하나의 AP가 동시에 여러 단말기에게 독립 패킷을 전송하는 MU-MIMO(Multi-User MIMO)를 도입했습니다.
802.11ax (Wi-Fi 6 / 6E): 밀집 환경(High-Density) 최적화
기존 OFDM의 점유 한계를 극복하기 위해 주파수를 자원 단위(RU)로 쪼개어 동시 대규모 접속을 지원하는 OFDMA(직교 주파수 분할 다중 접속)를 채택했습니다. 무작위 백오프 경쟁 오버헤드를 줄이고, 주파수 간섭 식별을 위한 BSS Coloring 기술을 적용했습니다.
802.11be (Wi-Fi 7): 초고속·초저지연의 완성
2.4GHz, 5GHz, 6GHz 대역을 결합하여 멀티 트랙으로 송수신하는 MLO(Multi-Link Operation)와 4096-QAM 초고밀도 변조 방식을 결합하여 대기 시간을 유선 LAN 수준으로 하락시켰습니다.

4. 핵심 기술 총비교

비교 항목	Pure ALOHA	Slotted ALOHA	CSMA/CA (802.11 DCF)	OFDMA (802.11ax 이후)
기반 철학	제어 없음 (발생 즉시 전송)	시간 슬롯 동기화 후 전송	LBT (보내기 전 청취 및 회피)	스케줄링 기반 다중 접속
물리적 감지	없음 (감지 불가능)	없음 (감지 불가능)	수행함 (Carrier Detection)	AP가 동기화 프레임 통제
가상 감지(NAV)	없음	없음	있음 (RTS/CTS 핸드셰이킹)	스케줄링 체계로 고도화
최대 이론 처리율	약 18.4%	약 36.8%	환경에 따라 가변 (~70%)	경쟁 배제로 90% 이상 효율화
실무적 위상	무선 패킷 네트워크의 모태	위성 통신 및 이더넷의 원형	현대 Wi-Fi 하위 호환의 기본

[네트워크]EDNS Client Subnet (ECS)

seongw00 — Sun, 31 May 2026 03:43:11 +0900

1. 개요 (Overview)

EDNS Client Subnet(ECS)은 DNS(Domain Name System) 쿼리에 클라이언트의 IP 서브넷(Subnet) 정보를 포함하여 전송할 수 있도록 지원하는 DNS 확장 프로토콜(Extension Mechanisms for DNS)입니다.

기존 DNS가 '요청을 보낸 DNS 서버'의 위치를 기준으로 응답했다면, ECS는 '실제 요청을 보낸 사용자(Client)'의 위치를 기반으로 가장 가까운 서버의 IP를 반환할 수 있도록 돕습니다. 주로 글로벌 서비스의 GSLB(Global Server Load Balancing) 및 CDN(Content Delivery Network) 최적화에 핵심적으로 사용됩니다.

2. 등장 배경: 기존 DNS의 한계

ECS가 등장하기 전, GSLB나 CDN은 사용자의 위치를 파악하기 위해 네임서버(Authoritative DNS)에 인입된 요청의 출발지 IP를 확인했습니다. 하지만 이 방식에는 치명적인 문제가 있었습니다.

Recursive DNS 서버 기준의 처리: 네임서버가 보는 IP는 실제 사용자의 IP가 아니라, 사용자가 거쳐 온 Public/ISP의 Recursive DNS(전달자) IP입니다.
지리적 미스매치(Mismatch) 발생: 만약 한국에 있는 사용자가 구글 Public DNS(8.8.8.8, 미국 또는 타 지역 노드)나 별도의 VPN DNS를 사용한다면, GSLB는 사용자가 미국에 있다고 오판하여 미국 서버의 IP를 반환하게 됩니다. 결과적으로 사용자는 엄청난 네트워크 지연(Latency)을 겪게 됩니다.

3. ECS의 동작 원리 (How it Works)

ECS는 DNS 쿼리의 패킷 구조를 확장하여, 클라이언트의 실제 IP 주소 중 앞부분(서브넷 마스크, 보통 IPv4의 경우 /24 Prefix)을 포함하여 네임서버로 전달합니다. privacy 보호를 위해 전체 IP(192.168.1.45) 대신 대략적인 지역을 알 수 있는 서브넷(192.168.1.0/24)만 보냅니다.

sequenceDiagram
    autonumber
    actor Client as 사용자 (KTLine, 서울)
    participant RecDNS as Public DNS (예: 8.8.8.8)
    participant AuthDNS as GSLB / 네임서버

    Client->>RecDNS: DNS Query (www.example.com)
    Note over RecDNS: 클라이언트가 서울 IP임을 확인<br/>ECS 옵션 추가 (/24 서브넷)
    RecDNS->>AuthDNS: DNS Query + [ECS: 사용자 서브넷 정보 포함]
    Note over AuthDNS: "아, 미국 DNS가 보냈지만<br/>실제 사용자는 서울이구나!"
    AuthDNS->>RecDNS: 서울 CDN Edge 서버 IP 반환
    RecDNS->>Client: 서울 CDN Edge 서버 IP 전달

사용자 요청: 사용자가 특정 도메인을 요청합니다.
서브넷 추가: ECS를 지원하는 Recursive DNS(예: Google Public DNS, Cloudflare 등)는 사용자의 IP 서브넷 정보를 DNS 쿼리의 EDNS0 OPT 레코드에 삽입합니다.
네임서버 판단: 지리적 기반 라우팅을 수행하는 네임서버(GSLB)는 이 서브넷 정보를 보고, 미국 DNS 서버와 통신하고 있더라도 실제 사용자와 가장 인접한 리전(서울)의 서버 IP를 찾아 응답합니다.

4. EDNS Client Subnet의 장단점

장점 (Advantages)

네트워크 지연 시간(Latency) 최소화: 사용자가 전 세계 어디에 있든 가장 물리적·네트워크적으로 가까운 CDN Edge나 데이터 센터로 연결됩니다.
Public DNS 활용성 극대화: 8.8.8.8이나 1.1.1.1 같은 고성능 Public DNS를 사용하더라도 대형 포털이나 OTT 서비스 이용 시 속도 저하가 발생하지 않습니다.

단점 및 고려사항 (Disadvantages & Challenges)

개인정보 보호(Privacy) 이슈: 사용자의 대략적인 위치(서브넷) 정보가 중간 DNS 서버들을 거쳐 최종 네임서버까지 전달되므로, 프라이버시 민감 관점에서 논쟁이 있습니다. (이를 이유로 Apple의 iCloud Private Relay 등 일부 보안 서비스는 ECS를 의도적으로 제한합니다.)
DNS 캐시 효율 저하 (Cache Fragmentation): 기존에는 www.example.com에 대한 캐시를 하나만 들고 있으면 모든 사용자에게 줄 수 있었습니다. 하지만 ECS를 쓰면 서브넷별(지역별)로 캐시를 따로 관리해야 하므로, Recursive DNS 서버의 메모리 부담이 커지고 캐시 적중률(Hit Rate)이 떨어질 수 있습니다.

5. 결론

EDNS Client Subnet(ECS)은 DNS의 '전달자(DNS 서버)' 주소 대신 '실제 발신자(클라이언트)'의 서브넷 주소를 GSLB에 전달하여, 사용자 맞춤형 최적의 라우팅 경로를 제공하는 기술입니다. 현대 글로벌 인프라와 CDN 환경에서 사용자 경험(UX) 향상을 위한 필수적인 축으로 자리 잡고 있습니다.

[네트워크]SNI(Server Name Indication) 필드 차단이란?

seongw00 — Sun, 31 May 2026 03:14:55 +0900

인터넷 패러다임이 HTTP에서 HTTPS로 전환되면서, 네트워크상의 데이터는 강력하게 보호받기 시작했습니다. 하지만 보안의 강화는 역설적으로 '네트워크 관리와 통제'의 난이도를 높였습니다. 악성코드 유포 사이트, 기업 기밀 유출 경로, 불법 콘텐츠 허브 등이 HTTPS의 암호화 장벽 뒤로 숨어버렸기 때문입니다.

이러한 상황에서 네트워크 관리자와 통신사(ISP)가 암호화된 트래픽을 효율적으로 선별하고 차단하기 위해 도입한 핵심 기술이 바로 SNI(Server Name Indication) 필드 차단입니다. 본 장에서는 SNI 차단의 기반이 되는 웹 프로토콜의 진화 과정을 살펴보고, 차단 기술의 상세 메커니즘과 우회 기술 간의 기술적 공방을 심층적으로 다뤄보고자 합니다.

1. 사전 기반 지식: 웹 프로토콜의 진화와 가상 호스팅

SNI 차단을 완벽히 이해하기 위해서는 먼저 HTTP/1.1의 가상 호스팅(Virtual Hosting)과 HTTPS의 TLS 핸드셰이크 메커니즘을 명확히 정리해야 합니다.

1.1 IP 주소의 한계와 가상 호스팅 (HTTP Request Header: Host)

과거 인터넷 초기에는 하나의 물리적 서버(하나의 IP 주소)가 하나의 도메인(웹사이트)만 서비스하는 것이 일반적이었습니다. 그러나 웹사이트의 수가 폭발적으로 증가하면서 IPv4 주소 고갈 문제와 서버 자원 낭비 문제가 대두되었습니다.

이를 해결하기 위해 탄생한 개념이 가상 호스팅(Virtual Hosting)입니다. 하나의 IP 주소를 가진 서버가 여러 개의 도메인(예: company.com, blog.net, shop.org)을 동시에 서비스하는 기술입니다.

HTTP/1.1 표준에서는 이를 구현하기 위해 Host 헤더를 필수 항목으로 지정했습니다.

사용자가 브라우저에 주소를 입력하면, 브라우저는 DNS를 통해 IP를 얻은 뒤 서버와 TCP 연결을 맺습니다.
그 후 보낼 HTTP 요청 메시지 헤더에 Host: company.com을 명시합니다.
웹 서버(Apache, Nginx 등)는 이 Host 헤더를 읽고, 동일한 IP 내에서 어떤 웹사이트의 데이터를 반환할지 결정합니다.

1.2 HTTPS의 등장과 가상 호스팅의 충돌

보안성 강화를 위해 HTTP에 암호화 프로토콜인 TLS(Transport Layer Security)를 얹은 HTTPS가 표준화되면서 중대한 기술적 모순이 발생했습니다.

HTTPS 통신은 TCP 연결이 수립된 직후, HTTP 요청을 보내기 전에 안전한 암호화 채널을 구축하는 TLS 핸드셰이크(Handshake) 단계부터 시작합니다.

클라이언트가 서버에 "암호화 통신을 시작하자"며 Client Hello 메시지를 보냅니다.
서버는 자신의 신원을 증명할 SSL/TLS 인증서(Certificate)를 클라이언트에 보냅니다.
클라이언트는 인증서를 검증한 뒤 암호화 키를 생성하고, 이후부터 모든 HTTP 데이터를 암호화합니다.

여기서 문제가 발생합니다. 서버가 인증서를 보내는 시점(2단계)은 아직 HTTP 요청이 발생하기 전이므로, 서버는 사용자가 어떤 도메인(Host 헤더) 접속을 원하는지 전혀 모르는 상태입니다. 하나의 IP에 여러 도메인이 얹혀 있는 가상 호스팅 서버라면, "수많은 사이트 중 어떤 사이트의 인증서를 꺼내서 보내주어야 하는가?"에 대한 딜레마에 빠지게 됩니다. 잘못된 인증서를 보내면 브라우저에는 '보안 경고(인증서 오류)'가 발생하게 됩니다.

2. SNI(Server Name Indication) 프로토콜의 탄생

이 문제를 해결하기 위해 2003년 IETF(인터넷 표준 기구)는 TLS 1.0의 확장 규격(RFC 3546, 이후 RFC 6066으로 개정)으로 SNI(서버 이름 표시) 기술을 제안했습니다.

2.1 SNI의 기본 메커니즘

원리는 간단합니다. 서버가 인증서를 고를 수 있도록, 클라이언트가 TLS 핸드셰이크의 첫 번째 패킷인 Client Hello의 확장(Extension) 필드에 접속하고자 하는 도메인 이름을 미리 적어서 보내는 것입니다.

동작 방식: 사용자가 https://example.com에 접속하려 할 때, Client Hello 패킷 내부의 Server Name 필드에 명시적으로 example.com이라는 문자열을 삽입하여 전송합니다.
결과: 서버는 이 SNI 필드를 먼저 읽고, 해당 도메인에 정확히 매칭되는 SSL/TLS 인증서를 선택하여 클라이언트에 응답할 수 있게 되었습니다. 이로써 HTTPS 환경에서도 하나의 IP 주소로 수백 개의 암호화된 가상 호스팅 사이트를 안정적으로 운영할 수 있게 되었습니다.

3. SNI 필드 차단의 메커니즘과 동작 원리

SNI는 가상 호스팅 문제를 훌륭히 해결했지만, 보안 측면에서 치명적인 아킬레스건을 남겼습니다. 바로 Client Hello 패킷이 송신되는 시점은 암호화 키를 교환하기 전이기 때문에, SNI 필드에 적힌 도메인 정보가 평문(Plaintext)으로 전송된다는 점입니다.

네트워크 관리자나 ISP(통신사)는 이 약점을 이용해 HTTPS 트래픽을 정교하게 통제하는 SNI 필드 차단 기술을 개발했습니다.

3.1 차단 프로세스 (5단계)

SNI 필드 차단은 일반적인 방화벽보다 훨씬 정교한 패킷 분석 기술인 DPI(Deep Packet Inspection, 심층 패킷 분석) 장비를 기반으로 동작합니다.

TCP 3-Way Handshake 수립: 클라이언트와 서버 간의 기본적인 네트워크 연결(L4 Layer에서 진행)이 성립됩니다.
TLS Client Hello 감시 (L7 Layer 분석): 클라이언트가 서버로 TLS 통신 시작 패킷을 보냅니다. 네트워크 중간에 위치한 DPI 장비는 이 패킷을 캡처하여 L7(Application Layer) 영역까지 뜯어봅니다.
SNI 평문 문자열 추출: DPI 장비는 Client Hello 내 확장 필드에 노출된 Server Name(예: illegal-site.com) 문자열을 추출합니다.
블랙리스트(Blacklist) 매칭: 추출한 도메인을 정부(방송통신심의위원회 등)나 기업 보안 정책에 의해 지정된 '차단 대상 데이터베이스(DB)'와 실시간으로 대조합니다.
연결 강제 차단 (TCP RST 또는 리다이렉트): 만약 일치하는 도메인이 있다면, DPI 장비는 서버인 척 가장하여 클라이언트에게 TCP RST(Reset) 패킷을 보내 연결을 강제로 끊어버립니다.
- 또는 클라이언트에게 차단 안내 웹페이지(예: warning.or.kr)의 IP로 접속하라는 가짜 응답을 보내 브라우저 화면을 전환시킵니다.

3.2 타 차단 기술과의 비교 분석

네트워크 통제 기술의 발전 과정을 이해하면 SNI 차단의 위치를 더 명확히 알 수 있습니다.

IP 주소 차단: 특정 서버의 IP 전체를 막는 방식입니다. 가상 호스팅 환경에서 이 방식을 쓰면, 유해 사이트 하나를 막으려다 같은 IP를 쓰는 수많은 정상 사이트까지 무고하게 차단되는 '과잉 차단(Collateral Damage)' 문제가 발생합니다.
DNS 차단: 사용자가 도메인을 조회할 때 DNS 서버가 가짜 IP를 알려주는 방식입니다. 사용자가 구글(8.8.8.8)이나 클라우드플레어(1.1.1.1) 같은 해외 통설 DNS를 설정하거나, DNS 패킷 자체를 암호화하는 DoH/DoT 기술을 쓰면 쉽게 우회됩니다.
SNI 필드 차단: IP가 같아도 도메인 단위로 정밀 타격이 가능하며, DNS를 우회하여 서버와 직접 IP 통신을 시도하더라도 핸드셰이크 과정에서 무조건 걸려들기 때문에 훨씬 강력합니다.

4. 관련 핵심 네트워크 프로토콜 및 기술 용어 정리

SNI 차단을 논할 때 실무 및 전공 시험에서 반드시 출제되는 핵심 기술적 키워드들입니다.

DPI (Deep Packet Inspection, 심층 패킷 분석): 네트워크 패킷의 헤더(IP, Port)뿐만 아니라 데이터가 담긴 페이로드(Payload) 내부의 콘텐츠와 프로토콜 정보까지 분석하는 고성능 패킷 처리 기술입니다.
TCP RST (Reset) 패킷: TCP 헤더의 플래그 중 하나로, 연결 상태에 이상이 있거나 강제로 세션을 종료해야 할 때 보내는 패킷입니다. SNI 차단 장비는 이 패킷을 양방향으로 쏘아 클라이언트와 서버가 서로 '상대방이 연결을 끊었다'고 믿게 만듭니다.
TLS 1.3: 2018년에 제정된 최신 암호화 프로토콜 표준입니다. 핸드셰이크 과정을 기존 2-RTT에서 1-RTT로 단축하여 속도를 높였고, 기존 TLS 1.2에서 평문으로 노출되던 많은 필드들을 암호화 영역으로 격하했습니다. 그러나 이 TLS 1.3조차도 첫 번째 Client Hello 내의 SNI 필드는 평문으로 남겨두었습니다.

5. SNI 차단의 한계와 차세대 보안 기술: ESNI에서 ECH까지

창과 방패의 싸움처럼, 암호화 도메인 정보를 훔쳐보려는 차단 기술에 맞서 이를 완전히 숨기려는 웹 표준 기술이 계속해서 진화하고 있습니다.

5.1 ESNI (Encrypted SNI)

DPI 장비가 SNI를 읽지 못하도록 아예 SNI 필드를 암호화해서 보내자는 아이디어로 출발한 기술입니다.

원리: 웹 서버는 자신의 공개키 정보를 DNS 레코드(TXT 레코드)에 미리 등록해 둡니다. 클라이언트는 DNS를 통해 서버의 공개키를 먼저 받아온 뒤, 이 키로 SNI 필드를 암호화하여 Client Hello를 보냅니다.
한계: SNI 필드는 숨겼지만, Client Hello 메시지 내의 다른 필드(예: ALPN 프로토콜 목록, 키 교환 파라미터 등)는 여전히 평문으로 남았습니다. 정교한 DPI 장비는 이 주변 정보들의 '지문(Fingerprint)'을 분석하여 어떤 사이트로 가는지 유추해 내는 트래픽 분석(Traffic Analysis) 공격으로 ESNI를 무력화했습니다. 결국 ESNI는 표준화되지 못하고 사장되었습니다.

5.2 ECH (Encrypted Client Hello)

ESNI의 실패를 거울삼아 탄생한 최종 진화형 기술이 현재 인터넷 표준으로 자리 잡아가고 있는 ECH입니다.

원리: 일부 필드만 암호화하던 ESNI와 달리, ECH는 Client Hello 메시지 자체를 두 개로 쪼갭니다.
1. Inner Client Hello (내부 메시지): 진짜 가고자 하는 도메인(SNI)을 포함한 모든 핵심 정보가 들어있으며, 서버의 공개키로 전체 암호화됩니다.
2. Outer Client Hello (외부 메시지): DPI 장비가 읽을 수 있는 평문 메시지입니다. 하지만 여기에는 검열을 피하기 위해 클라우드플레어 같은 대형 CDN 업체의 대표 도메인 등 '가짜 혹은 공통 목적지 정보'를 적어 둡니다.
결과: 네트워크 중간에서 패킷을 훔쳐보는 검열 장비는 오직 외부 메시지(Outer)만 볼 수 있으므로, 사용자가 그 안의 진짜 목적지(Inner)로 가는지 전혀 알 수 없습니다.

6. 결론 및 생각해볼 점

SNI 필드 차단은 네트워크 자원의 효율적 통제와 유해 환경 차단이라는 '공익적/관리적 목적'과, 개인의 통신 자유 및 프라이버시 침해라는 '보안적/인권적 가치'가 정면으로 충돌하는 지점에 있습니다.

현재 직장인들이 사용하는 사내 보안 솔루션(DLP, 방화벽) 역시 사내 기밀 유출을 막기 위해 SNI 차단이나 더 나아가 SSL Inspection(인증서 프록시를 통한 복호화) 기술을 적극적으로 활용하고 있습니다. 향후 ECH 기술이 전면 도입되어 SNI 차단이 기술적으로 완전히 불가능해질 때, 기업과 국가는 새로운 네트워크 통제 거버넌스를 어떻게 구축해야 할지 고민해야 할 시점이라고 생각합니다.

[Trouble Shooting]Docmost 2 Outline Auto Migration

seongw00 — Mon, 4 May 2026 13:44:23 +0900

낭만인프라에서 사용하던 Docmost를 Outline으로 전환하게 됐다. 문서 수가 적지 않아서 수동으로 옮기는 건 처음부터 배제했고, Python으로 자동화 스크립트를 짜서 한 번에 이전하기로 했다. 결론부터 말하면 스크립트 자체는 단순했는데, 인프라 구조 때문에 예상보다 시간이 많이 걸렸다.

환경 소개

우리 팀 인프라는 WireGuard VPN으로 구성된 172.16.0.x 폐쇄망 위에 서비스들이 올라가 있다. 서버 접근은 Teleport(tsh)를 통해서만 가능하고, Outline은 AWS EC2 위에 Docker로 올라가 있으며 Teleport 앱으로 등록되어 있다. 이 구조가 나중에 핵심 원인이 된다.

스크립트 구조

스크립트의 동작 방식은 단순하다.

로컬 디렉토리를 재귀적으로 순회
폴더는 Outline 문서로 생성 (계층 구조 유지)
마크다운 파일은 내용을 읽어 documents.create API로 업로드
마크다운 내 이미지 경로를 찾아 attachments.create API로 업로드 후 URL 치환
이미지가 있으면 documents.update로 내용 갱신

import os
import requests
import time
import re

API_KEY = "ol_api_..."
BASE_URL = "api url"
COLLECTION_ID = "Collection UUID"
PARENT_DOC_ID = "Parent UUID"
ROOT_DIR = r"현재 내 컴퓨터에 위치한 파일의 경로"

def migrate(local_path, outline_parent_id):
    for item in os.listdir(local_path):
        if item == 'files': continue
        full_path = os.path.join(local_path, item)
        if os.path.isdir(full_path):
            new_id = create_outline_doc(item, f"# {item}", outline_parent_id)
            if new_id:
                migrate(full_path, new_id)
        elif item.endswith(".md"):
            title = os.path.splitext(item)[0]
            with open(full_path, 'r', encoding='utf-8') as f:
                content = f.read()
            doc_id = create_outline_doc(title, content, outline_parent_id)
            if doc_id:
                refined = process_markdown_content(content, os.path.dirname(full_path), doc_id)
                if refined != content:
                    update_outline_doc(doc_id, title, refined)
            time.sleep(1.5)

트러블슈팅

1. ModuleNotFoundError: No module named 'requests'

가장 단순한 오류. Python 환경에 requests가 설치되어 있지 않았다.

pip install requests

2. FileNotFoundError: 경로를 찾을 수 없음

WSL에서 스크립트를 실행했는데 ROOT_DIR이 Windows 경로(C:\Users\...)로 설정되어 있었다. WSL에서는 Windows 드라이브가 /mnt/c/... 형식으로 마운트되기 때문에 경로를 바꿔줘야 한다.

# 변경 전
ROOT_DIR = r"C:\Users\user\Desktop\xxxx"

# 변경 후
ROOT_DIR = "/mnt/c/Users/user/Desktop/xxxx"

반대로 Windows PowerShell에서 실행하면 WSL 경로(/mnt/c/...)를 못 찾는다. 실행 환경에 맞게 경로를 설정해야 한다.

3. HTTP 405 Method Not Allowed (1차)

http://도메인ip주소:포트번호/api/documents.create로 POST 요청을 보냈더니 405가 반환됐다. 원인은 Outline 컨테이너 환경변수에 설정된 FORCE_HTTPS=true였다.

HTTP로 요청하면 Outline이 HTTPS로 리다이렉트하는데, 문제는 POST 요청이 리다이렉트될 때 GET으로 변환된다는 점이다. GET으로 변환된 요청이 documents.create 엔드포인트에 도달하면 해당 엔드포인트는 POST만 허용하므로 405가 반환된다.

# 변경 전
BASE_URL = "http://도메인ip주소:포트번호/api"

# 변경 후
BASE_URL = "https://도메인ip주소/api"

4. SSLCertVerificationError: self-signed certificate

HTTPS로 변경하니 이번엔 SSL 인증서 오류가 발생했다. 내부망에서 자체 서명 인증서(self-signed certificate)를 사용하고 있기 때문이다. verify=False로 SSL 검증을 비활성화하고, urllib3 경고도 함께 꺼줬다.

import urllib3
urllib3.disable_warnings(urllib3.exceptions.InsecureRequestWarning)

# 모든 requests 호출에 verify=False 추가
response = requests.post(url, headers=headers, json=payload, verify=False)

5. HTTP 404 - Outline이 아닌 Phase 페이지가 반환됨

SSL 문제를 해결하고 나니 이번엔 404가 반환됐는데, 응답 본문을 보니 Outline이 아니라 Phase(시크릿 관리 서비스)의 HTML 페이지였다.

원인을 파악하기 위해 서버의 Nginx 설정을 확인했다.

docker exec phase-nginx cat /etc/nginx/conf.d/default.conf

확인 결과, 172.XX.XX.XX:443에 올라간 Nginx는 Phase 전용이었다. 모든 요청을 Phase frontend(http://frontend:3000)로 라우팅하고 있었고, Outline 관련 설정은 전혀 없었다. Outline은 이 Nginx와 무관하게 별도로 0.0.0.0:3000에 떠 있었다.

docker ps
# outline-outline-1   0.0.0.0:3000->3000/tcp
# phase-nginx         0.0.0.0:80->80/tcp, 0.0.0.0:443->443/tcp

6. HTTP 405 Method Not Allowed (2차) - 근본 원인 분석

그렇다면 172.XX.XX.XX:3000으로 직접 요청하면 되지 않을까 생각했다. 그런데 서버 내부에서 curl로 직접 때려봐도 똑같이 405가 반환됐다.

curl -v -X POST http://172.XX.XX.XX:3000/api/documents.create \
  -H "Authorization: Bearer ol_api_..." \
  -H "Content-Type: application/json" \
  -d '{"title":"test","collectionId":"..."}'

# 결과: HTTP/1.1 405 Method Not Allowed
# Allow: GET, HEAD

라우트 자체가 문제인지 확인하기 위해 Outline 컨테이너 안에서 소스코드를 직접 분석했다.

# 라우트 등록 확인
grep -n "documents.create" /opt/outline/build/server/routes/api/documents/documents.js
# → router.post("documents.create", ...) 정상 등록 확인

# API 마운트 확인
grep -n "api" /opt/outline/build/server/services/web.js
# → app.use(koaMount("/api", api)) 정상 마운트 확인

# 실제 등록된 라우트 목록 확인 (Node.js로 직접 조회)
docker exec outline-outline-1 node -e "
const api = require('/opt/outline/build/server/routes/api/index.js');
const dispatch = api.default.middleware[10];
const routes = dispatch.router.stack.filter(r => r.path && r.path.includes('create'));
routes.forEach(r => console.log(r.methods, r.path));
"
# → [ 'POST' ] /documents.create 정상 등록 확인

코드상으로는 완벽했다. 그런데 브라우저 Network 탭에서 웹 UI가 보내는 요청 헤더를 분석하다가 결정적인 단서를 발견했다.

# 웹 UI 요청 헤더
Host: docs.~~~.xxxx.!!!

# curl 요청 헤더
Host: 172.XX.XX.XX:3000

그리고 docs.console.nangman.cloud에 직접 HTTPS 요청을 보내봤더니 302 리다이렉트가 반환됐다.

curl -sk -v https://docs.console.nangman.cloud/api/documents.create 2>&1 | grep Location

# 결과
Location: https://console.nangman.cloud:443/web/launch/docs.console.nangman.cloud

Outline이 Teleport 프록시 뒤에 있었던 것이다. 브라우저에서는 Teleport 세션 쿠키가 있어서 정상적으로 접근되지만, 스크립트에서 직접 요청하면 Teleport 인증을 통과하지 못하고 로그인 페이지로 리다이렉트된다. 172.XX.XX.XX:3000으로 직접 때려도 405가 나오는 이유는 아직 명확히 파악하지 못했지만, 어쨌든 올바른 접근 방법은 Teleport를 통하는 것이었다.

7. tsh proxy app으로 터널링

Teleport CLI를 사용하면 로컬 포트를 Teleport 앱으로 터널링할 수 있다. 먼저 앱에 로그인하고, 로컬 프록시를 실행한다.

# 앱 목록 확인
tsh app ls
# docs   HTTP   docs.~~~.xxxx.!!!

# 앱 로그인
tsh app login docs

# 로컬 프록시 실행 (터미널 1에서 유지)
tsh proxy app docs -p 8080
# Proxying connections to docs on 127.0.0.1:8080

이렇게 하면 http://127.0.0.1:8080으로 Outline API에 직접 접근할 수 있다. Teleport가 인증을 대신 처리해주기 때문에 API 키만 있으면 된다.

BASE_URL = "http://127.0.0.1:8080/api"

8. collectionId / parentDocumentId Invalid UUID

연결은 됐는데 이번엔 validation_error: collectionId: Invalid UUID 오류가 발생했다.

Outline URL에 표시되는 ID와 API에서 사용하는 ID가 다르다. URL에 보이는 inVlbSKlUN은 urlId이고, API에서 요구하는 건 실제 UUID 형식(xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx)이다.

# 컬렉션 UUID 조회
curl http://127.0.0.1:8080/api/collections.list -X POST \
  -H "Authorization: Bearer ol_api_..." \
  -H "Content-Type: application/json" \
  -d "{}"

# 특정 문서 UUID 조회 (urlId로 조회 가능)
curl http://127.0.0.1:8080/api/documents.info -X POST \
  -H "Authorization: Bearer ol_api_..." \
  -H "Content-Type: application/json" \
  -d "{\"id\":\"FQk08rqtub\"}"

조회 결과에서 id 필드 값을 사용하면 된다. urlId는 URL 표시용이고, id가 실제 UUID다.

9. 이미지 업로드 400 Bad Request

문서 업로드는 성공했는데 이미지 업로드에서 400이 반환됐다. attachments.create API에 documentId를 query parameter로 전달했는데, 이 API는 multipart form data로 받아야 한다.

# 잘못된 방법 - query parameter로 전달
response = requests.post(url, headers=headers, files=files, params={"documentId": doc_id})

# 올바른 방법 - form data로 전달
response = requests.post(url, headers=headers, files=files, data={"documentId": doc_id})

params는 URL 쿼리스트링(?documentId=...)으로 붙고, data는 multipart form body에 포함된다. Outline의 attachments.create는 후자를 요구한다.

10. 429 Too Many Requests

이미지가 많은 문서에서 연속으로 업로드 요청을 보내면 429 rate limit 오류가 발생했다. Outline 설정에서 RATE_LIMITER_ENABLED=true, RATE_LIMITER_REQUESTS=1000으로 설정되어 있었는데, 짧은 시간에 요청이 몰리면 걸리는 것 같았다.

# 이미지 업로드 간 딜레이
time.sleep(3)

# 문서 생성 간 딜레이
time.sleep(1.5)

최종 동작 흐름 정리

모든 문제를 해결한 후 최종적으로 동작하는 흐름은 다음과 같다.

터미널 1: tsh proxy app docs -p 8080 실행 후 유지
터미널 2: python auto-migration.py 실행
스크립트가 http://127.0.0.1:8080/api로 요청 → Teleport가 Outline으로 프록시
문서 생성 → 이미지 업로드 → 문서 내용 업데이트 순으로 처리

# 최종 설정값
API_KEY = "ol_api_..."
BASE_URL = "http://127.0.0.1:8080/api"
COLLECTION_ID = "COLLECTION_ID" 
PARENT_DOC_ID = "PARENT_DOC_ID"  #
ROOT_DIR = r"C:\Users\user\Desktop\XXXXXX"

마무리

단순해 보이는 마이그레이션 스크립트 하나 돌리는 데 이렇게 많은 시간이 소모될 줄 몰랐다. Outline 소스코드까지 직접 분석하면서 라우트 등록, 미들웨어 순서, koa-router 동작 방식까지 뒤졌는데, 결국 문제는 코드가 아니라 인프라 구조였다.

인프라 구조를 먼저 파악하고 시작했으면 훨씬 빨랐을 것 같다. 앞으로 비슷한 작업을 할 때는 서비스 앞단에 어떤 프록시나 게이트웨이가 있는지 먼저 확인하는 습관을 들여야겠다.

[네트워크]Wi-Fi 7의 핵심 기술 정리: 차세대 무선 통신 표준

seongw00 — Wed, 15 Apr 2026 16:06:28 +0900

1. 들어가며

우리는 무선 네트워크가 당연한 시대에 살고 있습니다. 그러나 이 기술이 언제, 어디서 시작되었는지, 이전의 기술과 차이가 무엇인지는 모른채 단순히 "빠르다"라고 생각합니다. 이번 글을 작성하며 이 기술이 무엇인지, 왜 빠른지, 어떤 기술적 차이가 이전과의 격차를 만들어 냈는지를 알아보고자 합니다.

2. Wi-Fi 7이란?

(왼: wifi7 TM, 오: ASUS의 wifi 7 설명 이미지)

WiFi 7 (IEEE 802.11be)는 1997년부터 시작된 802.11 표준의 7세대 규격입니다. WiFi 6/6E의 모든 이점을 갖추고 있으며, 320MHz 대역폭과 4K-QAM 등 기존의 여러 표준을 새로운 수준으로 확장했습니다. 또한, Multi-Link Operation(MLO), Multi-Resource Units (MRU), Puncturing 등 혁신적인 기능을 도입하였습니다.

단순히 속도만 빨라진 것이 아니라, 지연 시간을 획기적으로 줄이고 연결의 안정성을 극대화하는 데 초점을 맞췄습니다.

쉽게 비유하자면, Wi-Fi 6가 '차선을 늘린 것'이라면 Wi-Fi 7은 '차선도 늘리고, 속도 제한도 풀고, 여러 차선을 동시에 달릴 수 있게 만든 것'이라고 볼 수 있습니다.

3. Wi-Fi 7 의 핵심 기술들

①4K-QAM이란?

4096-QAM(4K-QAM)은 Wi-Fi 7에서 도입된 최첨단 데이터 변조 방식으로, 무선 신호 하나에 담을 수 있는 데이터의 양을 극대화한 기술입니다. 쉽게 비유하자면, '한 번에 나르는 트럭의 적재 용량을 촘촘하게 늘리는 것'과 같습니다.

여기서 QAM(직교 진폭 변조)이란 무선 전파의 진폭(Amplitude)과 위상(Phase)을 변화시켜 데이터를 표현하는 방식입니다. 여기서 숫자가 높을수록 한 번의 신호 전송(심볼)에 더 많은 비트(Bit)를 담을 수 있습니다.

Wi-Fi 6 (1024-QAM): 한 번에 10비트 전송
Wi-Fi 7 (4096-QAM): 한 번에 12비트 전송

Wi-Fi 7은 변조 방식을 4096-QAM으로 상향하며 물리 계층의 효율을 극대화했습니다. 1024-QAM이 한 심볼당 10비트를 전송했다면, 4096-QAM은 12비트를 전송하여 약 20%의 처리량 향상을 가져옵니다.

다만, 데이터 밀도가 높아진 만큼 외부 노이즈에 민감해질 수 있다는 물리적 특성이 있습니다. 따라서 4K-QAM은 고성능 데이터 처리가 필요한 근거리 통신 환경에서 비약적인 속도 체감을 제공합니다.

② Multi-Link Operation(MLO)란?

ASUS의 MLO 설명 사진

가장 핵심적인 변화는 다중 링크 운용(MLO)입니다. 기존에는 단일 밴드(2.4GHz, 5GHz, 6GHz 중 하나)만 사용 가능했으나, MLO는 여러 대역을 동시에 활용합니다.

1) MLO의 주요 동작 방식

대역폭 통합 (Aggregation): 여러 주파수 대역을 하나처럼 묶어 사용합니다. 예를 들어 5GHz와 6GHz를 동시에 사용하여 데이터 처리량(Throughput)을 비약적으로 높입니다.
실시간 전환 (Seamless Switching): 특정 대역에 간섭이 발생하거나 신호가 약해지면, 끊김 없이 즉시 다른 대역으로 데이터 패킷을 보냅니다. 사용자는 연결이 전환되는 것을 체감하지 못할 정도로 빠릅니다.

2) 핵심 이점

초저지연(Low Latency): 데이터가 비어 있는 채널을 실시간으로 찾아 보내기 때문에 지연 시간이 획기적으로 줄어듭니다. 이는 실시간 게임, VR/AR, 화상 회의에 필수적입니다.
신뢰성 강화: 주변의 무선 간섭이 심한 환경에서도 다중 링크가 연결을 지탱해주므로 연결이 끊기는 현상이 거의 발생하지 않습니다.
효율적 자원 활용: 가용한 모든 스펙트럼을 낭비 없이 사용하여 네트워크 밀집 지역에서도 안정적인 성능을 유지합니다.

3) 기술적 동작 형태

1. 기존 방식의 한계 (Non-STR)
- 현상: 5GHz로 데이터를 보내는 동안에는 6GHz로 데이터를 받을 수 없어 대기 시간이 발생합니다.
- 비유: 입과 귀가 하나뿐이라 말을 하는 동안에는 상대방의 말을 동시에 들을 수 없는 것과 같습니다.
2. STR( Simultaneous Transmit and Receive )의 동작 원리 및 특징
- 동시성: 5GHz 링크로는 클라우드에 데이터를 업로드하면서, 동시에 6GHz 링크로는 제어 명령이나 영상을 다운로드할 수 있습니다.
- 지연 시간(Latency) 제거: 한쪽 링크가 송신 중이라도 수신을 위해 기다릴 필요가 없으므로 응답 속도가 비약적으로 빨라집니다.
- 효율성: 매 순간 가용한 모든 링크의 자원을 독립적으로 100% 활용할 수 있습니다.

③ Multi-Resource Units (MRU)란?

1) 기존 방식(Wi-Fi 6)의 문제점

Wi-Fi 6의 OFDMA 방식은 대역폭을 RU라는 조각으로 나누어 여러 사용자에게 배분했습니다. 하지만 '1단말 1RU' 원칙 때문에 다음과 같은 낭비가 발생했습니다.

채널 차단(Blocking): 만약 80MHz 채널 중간에 아주 작은 간섭(노이즈)이 발생하면, 그 간섭이 포함된 RU뿐만 아니라 인접한 깨끗한 대역까지 한꺼번에 사용하지 못하는 경우가 많았습니다.
비유: 4차선 도로 중 2차선에 작은 공사가 있으면, 안전을 이유로 3,4차선 전체를 막아버리는 비효율과 같습니다.

2) MRU의 동작 원리 (Wi-Fi 7)

Wi-Fi 7의 MRU는 Preamble Puncturing 기술과 결합하여 주파수를 훨씬 유연하게 관리합니다.

간섭 우회: 전체 대역 중 노이즈가 있는 특정 부분(Punctured subchannel)만 정밀하게 도려냅니다.
자원 결합: 노이즈를 피해서 남은 깨끗한 주파수 조각(RU)들을 하나의 단말기에 모두 할당하여 커다란 데이터 통로를 만들어줍니다.

4.캡스톤 프로젝트(실무 관점에서)

① 기존 환경 (Wi-Fi 6)의 한계점

상황: 로봇이 두 대의 카메라로 고해상도 영상을 Jetson Nano로 보내고, 이를 인프라 서버로 실시간 스트리밍 중.
문제 발생:
1. 주변에 다른 작업자의 스마트폰(2.4GHz)이나 무선 장비 간섭이 발생.
2. 로봇이 이동하며 AP와 멀어지거나 장애물에 가려짐.
결과: 영상 프레임 드랍(뚝뚝 끊김), 제어 명령 지연(Latency) 발생으로 인해 로봇이 장애물에 충돌하거나 비상 정지.

② Wi-Fi 7 도입 후의 변화 (MLO & MRU 적용)

MLO 가동: 2.4 GHz, 5GHz, 6GHz 대역을 동시에 연결. 고주파수(5/6GHz)가 벽에 막혀 약해지면, 즉시 투과력이 좋은 2.4GHz 링크가 채널로 데이터 패킷을 분산 전송하여 실시간성 유지
MRU & Puncturing 가동: 주변에 다른 무선 노이즈가 특정 주파수를 점유하더라도, 해당 구간만 'Puncturing'으로 비우고 남은 조각 채널들을 'MRU'로 묶어 로봇에게 할당.
결과: 고화질 영상이 지연 시간 없이 안정적으로 전송되며, 로봇 제어 명령이 즉각 반영됨.

5. 결론

Wi-Fi 7은 무선 통신의 불확실성을 기술적으로 보완한 표준입니다. 특히 실시간성과 신뢰성이 중요한 산업용 IoT 및 로봇 분야에서 유선 인프라를 대체할 수 있는 강력한 대안이 될 것입니다.

[네트워크]ECMP(Equal-Cost Multi-Path)의 원리와 부하 분산 알고리즘

seongw00 — Mon, 6 Apr 2026 13:39:31 +0900

1. 개요: 왜 ECMP인가?

IEEE 802.1aq 프로토콜을 이용한 ECMP 애니메이션 - 위키백과

전통적인 라우팅 방식은 목적지까지 가는 경로가 여러 개 있더라도, 그중 비용(Metric)이 가장 낮은 단 하나의 최적 경로(Best Path)만 선택합니다. 하지만 이 방식은 나머지 가용 경로들을 '놀게' 만든다는 치명적인 단점이 있습니다.

ECMP(Equal-Cost Multi-Path)는 목적지까지의 비용이 동일한 경로가 여러 개 존재할 때, 이 경로들을 모두 활용하여 데이터를 분산 전송하는 기술입니다.

ECMP의 주요 이점

대역폭 확장: 1Gbps 회선 4개를 ECMP로 묶으면 논리적으로 4Gbps의 효과를 냅니다.
가용성(Redundancy): 특정 경로에 장애가 발생해도 남은 경로로 즉시 우회되어 서비스 중단을 방지합니다.
비용 효율성: 고가의 단일 대용량 회선 대신, 저렴한 다중 회선을 묶어 성능을 극대화할 수 있습니다.

2. 네트워크 계층별 패킷의 여정과 ECMP의 위치

패킷이 우리 집 PC에서 Google 서버까지 가는 여정을 통해 ECMP가 어디서 발생하는지 이해해야 합니다.

(1) 집 ~ 에지 라우터 (Access/Aggregation 구간)

이 구간은 보통 '외길'입니다. 우리 집 광케이블은 특정 국사(CO)의 장비에 물리적으로 묶여 있기 때문입니다. 여기서는 경로 선택권이 거의 없으므로 ECMP보다는 트래픽을 하나로 모으는 집선(Aggregation)이 주된 역할입니다.

(2) 코어망 (Core Network 구간)

엣지 라우터를 지나 통신사 코어망에 진입하면 네트워크는 그물망(Mesh) 구조가 됩니다. 이때부터 라우터들은 3계층(L3) 수준에서 ECMP를 수행합니다.

동작: 라우팅 프로토콜(OSPF, BGP)이 지도를 공유하고 최단 경로들을 미리 계산해 둡니다.
결정: ex)A로 가려면 1번 라우터와 2번 라우터 둘 다 비용이 같으므로 둘 다 사용한다

3. 핵심 동작 원리: 핑(Ping)이 아니라 지도(Map)다

많은 이들이 라우터가 실시간으로 핑을 날려 길을 찾는다고 오해하지만, 실제로는 훨씬 체계적입니다.

광고(Advertisement): 라우터들은 멀티캐스트(Multicast)를 통해 자신의 연결 상태를 광고합니다.
지형도(Topology) 완성: 모든 라우터는 수집된 정보를 바탕으로 전체 네트워크 지도를 그립니다.
수학적 계산: 다익스트라(Dijkstra) 알고리즘 등을 통해 최단 경로를 미리 계산하여 FIB(Forwarding Table)라는 하드웨어 칩에 구워둡니다.
전송: 패킷이 들어오면 계산하는 게 아니라, 이미 칩에 있는 정보를 보고 바로 던집니다.

가.LPM(Longest Prefix Match)의 핵심 원리: "구체적일수록 좋다"

라우터는 패킷을 어디로 보낼지 결정할 때, 라우팅 테이블의 '네트워크 주소'와 '패킷의 목적지 IP'를 비교합니다. 이때 여러 개가 동시에 매칭된다면 가장 많이 겹치는(Prefix가 긴) 쪽을 선택합니다.

예시 시나리오: 라우팅 테이블에 다음과 같은 세 가지 경로가 있다고 가정해 봅시다.

192.168.0.0/16 (광역시 단위 이정표)
192.168.1.0/24 (동네 단위 이정표)
192.168.1.10/32 (특정 집 번지수)

만약 목적지 IP가 *192.168.1.10*인 패킷이 들어온다면?

1, 2, 3번 경로에 모두 해당하지만, 라우터는 가장 구체적인 3번(/32) 경로를 선택합니다. 이것이 바로 LPM입니다.

나. 왜 LPM이 필요한가?

네트워크는 거대한 망에서 작은 망으로 쪼개지는 계층적 구조를 가집니다.

효율성: 모든 IP 주소를 라우팅 테이블에 일일이 적을 수 없으므로, 보통은 짧은 마스크(예: /8, /16)로 뭉뚱그려서 경로를 관리합니다.
예외 처리: 하지만 특정 서버나 특정 대역만 다른 길로 보내야 할 때가 있습니다. 이때 마스크를 더 길게(Prefix를 크게) 잡아서 라우팅 테이블에 넣으면, LPM 원칙에 의해 해당 트래픽만 따로 뽑아내어 처리할 수 있습니다.

다. Administrative Distance (관리 거리)

라우터가 "어떤 라우팅 정보가 더 믿음직한가?"를 결정하는 '신뢰도 점수'라고 이해하면 쉽습니다

상황: 목적지까지 가는 길을 OSPF도 알려주고, BGP도 알려준다면?
AD의 역할: 각 프로토콜에는 정해진 AD 값이 있습니다. 숫자가 낮을수록 더 믿음직한 경로로 간주합니다.
주요 AD 값 (Cisco 기준):
- Directly Connected (직접 연결): 0 (가장 믿음직함)
- Static Route (정적 경로): 1
- OSPF: 110
- BGP: 20 (External), 200 (Internal)

ECMP와의 상관관계: ECMP가 작동하려면 AD 값이 동일해야 합니다. 만약 하나는 OSPF(110)이고 하나는 Static(1)이라면, 라우터는 당연히 AD가 낮은 Static 경로만 선택하고 ECMP는 일어나지 않습니다.

라. LPM,AD와 ECMP의 관계

1순위 (LPM): 라우터는 먼저 가장 긴 마스크를 가진 경로들을 찾습니다.
2순위 (AD): 마스크 길이가 같다면, AD(신뢰도)가 낮은 프로토콜을 선택합니다.
3순위 (Metric): 마스크와 AD가 모두 같다면, 비용(Metric)이 낮은 경로를 찾습니다.
최종 (ECMP): 마스크, AD, Metric이 모두 동일한 경로가 2개 이상일 때, 비로소 ECMP가 가동되어 부하 분산을 시작합니다.

즉, LPM은 ECMP가 끼어들기 훨씬 전 단계에서 수행되는 '예선전'과 같습니다.

4. 부하 분산(Load Balancing) 알고리즘 상세

ECMP의 핵심은 "어떤 기준으로 패킷을 나눌 것인가?"입니다.

(1) IP Modulo (나머지 연산)

가장 단순하고 가벼운 방식입니다.

원리: (Source IP + Dest IP) % 경로 수 = 경로 번호
장점: 계산 리소스가 매우 적게 듭니다.
단점: IP 주소 패턴에 따라 특정 경로로 트래픽이 쏠리는 불균형이 발생할 수 있습니다.

(2) IP Hash (해시 방식) - 추천 방식

현대적인 네트워크 장비(Palo Alto 등)에서 가장 선호하는 방식입니다.

원리: 5-Tuple(L3 IP + L4 Port + Protocol) 정보를 해시 함수에 넣어 무작위 숫자를 생성합니다.
장점: 포트 번호까지 참조하므로, 같은 IP 간의 통신이라도 여러 세션으로 정밀하게 쪼갤 수 있습니다.
중요성: 동일 세션은 항상 같은 경로를 타게 하여 패킷 순서 뒤바뀜(Out-of-Order)을 방지합니다.

(3) Round Robin (라운드 로빈)

순서대로 번갈아 가며 패킷을 보냅니다.

장점: 물리적으로 완벽하게 50:50 분산이 가능합니다.
단점: 패킷 순서가 뒤섞여 TCP 성능이 급격히 저하될 위험이 커서 실무에서는 신중히 사용해야 합니다.

(4) Weighted Round Robin (가중치 기반 RR)

회선 대역폭이 서로 다를 때(예: KT 10G, SK 1G) 사용합니다.

원리: 성능이 좋은 경로에 가중치를 높게 주어 더 많은 세션을 할당합니다.

5. 실무 적용: Firewall Virtual Router와 ECMP

방화벽 장비 내부에 논리적으로 구현된 Virtual Router(가상 라우터)에서 ECMP를 설정할 때는 특히 세션 유지(Sticky Session) 기능이 중요합니다.

방화벽은 보안상 "나갔던 길로 들어와야" 통신을 허용하는 상태 기반 검사(Stateful Inspection)를 하기 때문입니다. 만약 ECMP가 패킷을 잘못 분산시켜 왕복 경로가 비대칭(Asymmetric)이 되면 방화벽이 이를 공격으로 오해하고 차단할 수 있습니다. 따라서 방화벽에서의 ECMP는 고도의 세션 관리 능력이 필수입니다.

6. 결론 및 고찰

ECMP는 현대 네트워크의 성능과 안정성을 지탱하는 필수 기술입니다. 하지만 단순히 '길을 여러 개 쓴다'는 개념을 넘어, 패킷의 순서를 보장하기 위한 해싱 메커니즘과 비대칭 라우팅에 대한 깊은 이해가 동반되어야 합니다.

성공적인 인프라 설계를 위해서는 무조건적인 분산보다는 서비스의 특성(Short flow vs Elephant flow)에 맞는 적절한 알고리즘을 선택하는 안목이 필요하다고 생각합니다.

[네트워크]수리카타룰

seongw00 — Wed, 1 Apr 2026 11:59:24 +0900

수리카타는 오픈소스 기반의 IDS(침입 탐지 시스템), IPS(침입 방지 시스템) 및 NSM(네트워크 보안 모니터링) 엔진입니다. 수만 개의 규칙(Rule)을 기반으로 실시간 트래픽을 분석하며, 멀티스레딩을 지원하여 고속 네트워크 환경에서도 강력한 성능을 발휘합니다.

쉽게 비유하자면, 공항 입출국장에서 검사하는 '반입 금지 물품 리스트'라 할 수 있습니다. "가방 안에 반입 금지 물품이 있으면(조건) 경보(혹은 압수)를 해라(액션)"라고 적힌 지침서와 같습니다.

1. 룰의 기본 구조

수리카타 룰은 한 줄의 긴 문장으로 구성되며, 크게 액션(Action) 헤더(Header)와 옵션(Options)으로 나뉩니다.

Action | Header | Options

예시: alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS 80 (msg:"GET 탐지"; content:"GET"; sid:1000001;)

Action (액션): 매칭됐을 때 할 일 (예: alert 경고, drop 차단, pass 통과)
Header (헤더): 대상 설정 (프로토콜, IP 주소, 포트 번호, 방향 등)
Options (옵션): 구체적인 탐지 내용 (로그 메시지, 특정 문자열(content), 룰 ID(sid) 등)

① 액션(Action): “어떤 행동을 할 것인가?”

가장 먼저 나오는 Action은 조건이 일치했을 때 수리카타가 취해야 할 행동을 정의합니다. 단순히 '막는다'를 넘어 상황에 맞는 선택이 필요합니다.

Action	설명	주요 용도
alert	로그를 남기고 알람을 생성합니다.	IDS 모드의 기본 액션. 패킷은 그대로 통과됩니다.
drop	패킷을 즉시 차단하고 로그를 남깁니다.	IPS 모드에서 공격을 실시간으로 방어할 때 사용합니다.
pass	해당 패킷을 검사하지 않고 통과시킵니다.	신뢰하는 IP나 특정 트래픽을 검사 대상에서 제외(화이트리스트)할 때 유용합니다.
reject	패킷을 차단한 후, 송신자에게 거절 메시지를 보냅니다.	TCP라면 RST 패킷을, UDP라면 ICMP Port Unreachable을 보내 연결을 강제 종료합니다.
rejectsrc	reject와 같지만, 패킷을 보낸 원본(Source) 쪽으로만 거절 메시지를 보냅니다.	공격자에게 연결이 끊겼음을 명확히 알릴 때 사용합니다.
rejectdst	패킷의 목적지(Destination) 쪽으로만 거절 메시지를 보냅니다.	내부 사용자가 유해 사이트에 접속할 때 브라우저 연결을 끊는 용도로 쓰입니다.

② 헤더(Header): "누가 어디로 가는가?"

Action: 매칭 시 행동 (alert, drop, pass, reject)
Protocol: 분석할 프로토콜 (tcp, udp, http, dns, tls 등)
- L4: tcp, udp, icmp
- L7: http, dns, tls, smb, nfs 등 (Suricata의 진정한 강점)
IP & Port: 출발지와 목적지 정보를 정의합니다.
- 변수 사용 가능
  - $HOME_NET: 보호 대상 내부 망.
  - $EXTERNAL_NET: 외부 인터넷 망.

Direction: 트래픽의 방향을 지정합니다. (-> 단방향, <> 양방향)

③ 옵션(Options): "무엇을 찾는가?"

괄호 ( ) 안에 세미콜론으로 구분하여 상세 조건을 적습니다.

msg: 로그에 출력될 설명입니다.
content: 패킷 페이로드에서 찾을 특정 문자열이나 헥사(Hex) 값입니다.

sid / rev: 룰의 고유 ID와 수정 버전입니다.

2. 주요 특징

서명(Signature) 기반 탐지: 이미 알려진 공격 패턴(해킹 툴의 특이한 문자열, 비정상적인 패킷 구조 등)을 데이터베이스화하여 탐지합니다.
프로토콜 인식: 단순히 포트 번호만 보는 게 아니라 HTTP, DNS, TLS 등 실제 프로토콜의 내용을 깊이 있게 분석(Deep Packet Inspection)하여 룰을 적용합니다.
유연성: 사용자가 자신의 네트워크 환경에 맞춰 직접 룰을 작성하거나, Emerging Threats(ET) 같은 커뮤니티에서 배포하는 최신 룰셋을 가져와 사용할 수 있습니다.

3. 고급 옵션과 상태 제어

단순한 문자열 매칭은 오탐(False Positive)이 많습니다. 이를 해결하기 위한 핵심 기술들을 살펴보겠습니다.

✅ Flow 키워드: 세션의 맥락(Context) 인지

수리카타는 단순 패킷 분석기가 아니라 세션 추적기입니다.

flow:established: TCP 3-way Handshake가 정상적으로 완료된 세션만 검사합니다. 비정상적인 스캔이나 스푸핑 패킷을 걸러낼 수 있습니다.
flow:to_server / from_client: 클라이언트가 서버에 보낸 요청인지 확인합니다.
flow:to_client / from_server: 서버가 클라이언트에 보내는 응답인지 확인합니다.

✅ Sticky Buffers: 성능 최적화

패킷의 전체 페이로드(payload)를 검색하는 것은 CPU 자원을 매우 많이 소모합니다. 특정 영역만 검사하여 효율을 극대화합니다.

http.uri: GET/POST 요청의 경로만 검사.
http.user_agent: 브라우저 정보만 검사.
tls.sni: 암호화된 트래픽이라도 초기 핸드쉐이크 시의 도메인 주소(SNI)는 평문이므로 이를 탐지 가능.

✅ PCRE (정규표현식): 정교한 패턴 매칭

문자열 매칭(content)으로 한계가 있을 때 Perl 호환 정규표현식을 사용합니다.

예: pcre:"/[0-9]{4}-[0-9]{4}/"; (특정 패턴의 카드 번호나 학번 탐지 가능)

4. 왜 중요한가?

인프라 보안 및 모니터링 관점에서 Suricata 룰은 핵심적인 역할을 합니다.

IDS(침입 탐지 시스템): 룰에 걸리는 트래픽이 있으면 관리자에게 알람을 보냅니다.
IPS(침입 방지 시스템): drop 액션을 사용해 악성 트래픽을 실시간으로 차단합니다.
트래픽 가시성: 특정 룰을 통해 내부 망에서 외부로 나가는 수상한 통신을 잡아낼 수 있습니다.

5. Question

Q. 수만 개의 룰이 있을 때 어떻게 CPU 부하를 줄일 것인가?
- 네트워크 패킷은 1초에도 수만 개가 쏟아집니다. 수리카타가 가진 룰이 3만 개라면, 패킷 하나하나를 3만 번 대조해야 할까? 그런 상황이 된다면 CPU가 버티지 못하고 패킷 유실(Drop)이 발생할 것입니다.
A. 이러한 문제를 해결하는 마법이 바로 MPM 알고리즘입니다.

1) MPM(다중 패턴 매칭)이란?

단일 패턴 매칭(예: C언어의 strstr)이 "이 문장에 'admin'이 있나?"를 찾는 것이라면, MPM은 "이 문장에 우리가 가진 3만 개의 금지어 중 하나라도 있나?"를 단 한 번의 스캔으로 찾아내는 기술입니다.

2) 핵심 알고리즘: 아호-코라식 (Aho-Corasick)

수리카타가 기본적으로 사용하는 대표적인 MPM 알고리즘입니다.

원리: 모든 룰의 키워드(content)를 트리 구조(Trie)로 미리 엮어둡니다.
장점: 패킷의 데이터를 처음부터 끝까지 딱 한 번만 읽으면, 그 안에 포함된 수천 개의 패턴을 동시에 찾아낼 수 있습니다. 룰의 개수가 늘어나도 탐색 속도가 급격히 느려지지 않는 이유입니다.

3) 성능을 높이는 룰 설계 전략

단순히 알고리즘이 좋다고 끝이 아닙니다. 룰을 작성할 때 엔진이 더 빨리 일하게 만드는 최적화 기법이 필요합니다.

최적화 기법	설명	왜 성능이 좋아지는가?
Fast Pattern	룰 내에서 가장 독특하고 긴 문자열을 지정	MPM 단계에서 이 패턴이 없으면 나머지 복잡한 검사를 즉시 생략함
Sticky Buffer	http.uri, http.host 등 위치 지정	패킷 전체(Payload)가 아닌 특정 영역만 스캔하여 데이터 읽기 범위 축소
Flow Bit	이전 패킷의 상태를 기억	이미 검증된 세션은 복잡한 검사를 건너뛰도록 논리 흐름 제어

4) 하드웨어 가속과 멀티스레딩

수리카타는 Snort와 달리 설계 단계부터 멀티스레딩(Multi-threading)을 지원합니다.

CPU 친화성: 각 CPU 코어에 특정 네트워크 큐(Queue)를 할당하여 병렬 처리합니다.
Hyperscan 활용: 인텔에서 개발한 고성능 정규표현식 매칭 라이브러리인 Hyperscan을 수리카타에 연동하면, 하드웨어 레벨에서 가속되어 성능이 비약적으로 향상됩니다.

6. 마치며

수리카타 룰을 공부하며 느낀 점은, 단순히 보안 도구를 '설치'하는 것보다 내 인프라 환경에 맞춰 '최적화'하는 능력이 훨씬 중요하다는 것입니다. 수만 개의 룰 사이에서 서비스 지연을 최소화하기 위해 MPM 알고리즘을 이해하고, Sticky Buffer를 활용해 탐지 정확도와 처리 속도의 균형을 맞춰가는 과정은 엔지니어로서 매우 가치 있는 고민이었습니다. 앞으로 제가 운영할 서버 환경에서도 '보안'과 '성능'이라는 두 마리 토끼를 잡는 엔지니어가 되고 싶습니다.

[네트워크]QUIC 프로토콜

seongw00 — Mon, 16 Mar 2026 20:16:59 +0900

1. 들어가며 (Introduction)

학습 계기: wireshark로 구글과 접속을 확인하던 도중 익숙하지 않은, QUIC라는 것을 발견했다. 해당 내용을 조금 더 찾아보니 새로운 통신 프로토콜 방법이라고 하여, 이번에는 위 내용을 조금 더 알아가보고자 한다.

2. QUIC이란 무엇인가?

핸드셰이크 레이턴시 비교 / QUIC와 TCP 스트림 구조 차이

정의: Quick UDP Internet Connections의 약자로, 구글에서 개발한 범용 목적의 UDP 기반의 차세대 전송 계층(Transport Layer) 통신 프로토콜이며 IETF에서 표준화한 프로토콜입니다. 2021년 5월, RFC 9000으로 표준화되며 차세대 인터넷의 핵심 기술로 자리 잡았습니다.
핵심 특징:
- UDP 기반: TCP의 3-Way Handshake 과정을 생략하거나 단축합니다.
- 연결 전이(Connection Migration): 와이파이에서 LTE로 바뀌어도 연결이 끊기지 않습니다.
- 멀티플렉싱: 하나의 연결에서 여러 스트림을 처리해도 홀오브라인 블로킹(HoL Blocking)이 발생하지 않습니다.

3. 핵심 메커니즘: TCP와의 차이점

① HoL(Head-of-Line) 블로킹 해제 (독립적 스트림)

TCP의 한계: 모든 데이터를 하나의 순차적인 바이트 스트림으로 간주한다. 패킷이 딱 하나만 유실되어도 커널의 TCP 버퍼가 멈추고 모든 스트림이 대기하는 병목이 발생한다.
QUIC의 해결: 전송 계층에서부터 여러 스트림을 독립적으로 관리함. 특정 스트림의 패킷이 소실되어도, 나머지 정상적인 스트림은 중단 없이 목적지에 도달함.

② 레이턴시 혁신 (Handshake & User Space)

0-RTT / 1-RTT 연결: TCP는 연결(1-RTT) 후 보안(1-2-RTT)이 순차적으로 발생하지만, QUIC은 연결과 보안 설정을 한 번에 처리하여 첫 연결은 1-RTT, 재연결은 0-RTT(대기 시간 없음)를 달성함.
사용자 공간(User Space) 혼잡 제어: 기존 TCP 혼잡 제어는 OS 커널에 박혀 있어 알고리즘 수정이 매우 어려움(커널 업데이트 필요). QUIC은 이를 어플리케이션(사용자) 공간으로 끌어올려, 서비스 특성에 맞는 최적의 알고리즘을 빠르게 적용할 수 있는 유연성을 확보함.

③ 전방 오류 정정 (FEC, Forward Error Correction)

메커니즘: 데이터 패킷과 함께 일종의 '에러 정정용 패킷'을 추가로 보냄.
효과: 일부 패킷이 유실되더라도 재전송 요청을 보내기 전에 수신 측에서 유실된 데이터를 스스로 복구함. 네트워크 환경이 불안정한 상황에서 재전송으로 인한 지연을 방지하는 핵심 기술임.

④연결 전이 (Connection Migration):

와이파이에서 LTE로 네트워크 환경이 바뀌어 IP 주소가 변경되어도, QUIC은 'Connection ID'를 사용하므로 연결을 끊지 않고 유지합니다.

4. 학습 중 마주친 질문 (Troubleshooting & Q&A)

Q: UDP 기반이면 DDoS 공격에 취약하지 않을까?

A: 맞습니다. 이를 QUIC Flood 공격이라고 합니다.

보안 리스크: 공격자가 가짜 소스 IP 주소로 대량의 QUIC 연결 요청(Hello 패킷)을 보내 서버 자원을 고갈시킬 수 있습니다.
대응 방안: 인프라 엔지니어는 QUIC 트래픽의 패턴을 분석하고, 암호화되지 않은 초기 패킷을 검사하거나, 비정상적인 연결 요청을 차단하는 전용 방화벽 설정이 필요합니다.

Q: 왜 굳이 UDP 위에서 구현했을까?

A: TCP는 OS 커널 깊숙이 구현되어 있어 수정과 배포가 매우 느립니다. 반면 UDP는 데이터만 실어 나르는 단순한 통로이기에, 그 위(사용자 공간)에서 프로토콜을 구현하면 OS 업데이트 없이도 새로운 기능을 빠르게 적용할 수 있기 때문입니다.

Q: UDP는 신뢰성이 없는데 어떻게 오류 정정을 할까?

A: UDP는 단순히 데이터를 실어 나르는 바구니 역할만 할 뿐, 실제 오류 검출과 복구(FEC 등)는 그 위에서 동작하는 QUIC 엔진이 직접 수행합니다. 이를 통해 TCP 수준의 신뢰성을 확보하면서도 속도는 더 높였습니다.

패킷이 안 오면 QUIC이 서버에게 재전송을 요청합니다. 즉, 신뢰성 보장 로직을 커널(TCP)이 아닌 앱(QUIC)에서 구현한 것입니다. 이는 커널의 제약을 벗어나기 위함입니다.

TCP: 오류 정정 로직이 윈도우나 리눅스 커널 깊숙이 박혀 있습니다. 이걸 수정하려면 OS를 업데이트해야 하는데, 전 세계 사람들의 OS를 동시에 바꿀 수는 없습니다. (이를 'Ossification' 즉, 골화 현상이라고 합니다.)
QUIC: UDP는 아무 기능이 없어서, 그 위에 구글이나 IETF가 최신 오류 정정 알고리즘을 코드로 짜서 브라우저에 넣어버리면, OS 업데이트 없이도 즉시 더 빠르고 안전한 통신이 가능해집니다.

5. 결론 및 향후 과제

결론: QUIC은 단순한 속도 향상을 넘어, '커널의 제약'과 'TCP의 순차적 전송'이라는 해묵은 과제를 UDP라는 자유로운 도화지 위에 해결한 결과물임.
Next Step: 실제 서비스 환경에서 TCP와 QUIC의 응답 속도 차이 데이터 측정해보기.

[네트워크]CloudFront(CDN)에 대해서

seongw00 — Mon, 16 Mar 2026 02:56:27 +0900

OSI 7계층을 공부하며 실습을 위해 터미널을 열었습니다. 당연히 dig를 치면 바로 IP 주소가 나오고, 와이어샤크에 그 IP를 넣으면 패킷이 잡힐 줄 알았습니다. 하지만 현실은 달랐습니다. aws.amazon.com/ko/는 조회가 안 되고, 겨우 찾아낸 주소는 IP가 아닌 또 다른 도메인 이름이었습니다. 이러한 과정 속에서 발견한 CloudFront의 메커니즘과 계층별 통신의 디테일을 공유하고자 이 글을 작성하게 되었습니다.

CloudFront

1. 별칭(CNAME)의 정체

aws.amazon.com을 조회했을 때 나타난 복잡한 도메인 주소들이 나옵니다. 그것이 바로 CloudFront가 동작하고 있다는 가장 확실한 증거입니다. AWS는 직접 IP를 알려주는 대신, CloudFront라는 '중간 전달자'를 거치게 설계되어 있습니다.

2. CloudFront(CDN)란 무엇인가?

CDN은 Content Delivery Network의 약자로, 콘텐츠를 사용자에게 더 빨리 전달하기 위해 전 세계에 거점을 둔 캐시 서버 망입니다.

핵심 원리 (Caching): 원본 서버(Origin)에 있는 데이터를 전 세계 곳곳의 엣지 로케이션(Edge Location)에 복사해 둡니다.
비유: 한국에 있는 맛집(원본 서버) 음식을 먹으려고 매번 한국에 오는 대신, 우리 집 앞 편의점(엣지 서버)에 입점된 밀키트를 사 먹는 것과 같습니다.

3. 왜 CloudFront를 써야 할까? (인프라적 이점)

지연 시간(Latency) 최소화: 물리적 거리가 가까운 엣지 서버에서 데이터를 가져오므로 웹사이트 로딩 속도가 비약적으로 향상됩니다.
보안 강화 (Shield & WAF): 실제 서버의 IP를 숨길 수 있고, DDoS 공격 같은 대규모 트래픽을 엣지 단계에서 먼저 흡수하여 방어합니다.
트래픽 분산: 모든 부하가 메인 서버로 몰리는 것을 방지해 서버 비용을 절감하고 가용성을 높입니다.

4. 실습과의 연결: OSI 계층으로 보는 CloudFront

단계	동작 원리	관련 계층
DNS 조회	사용자와 가장 가까운 엣지 서버 IP를 할당 (CNAME 체인 확인)	L3 (Network)
연결 수립	사용자 <-> 엣지 서버 간의 빠른 TCP 연결	L4 (Transport)
데이터 전송	캐싱된 콘텐츠 전송 및 HTTPS 암호화 처리	L7 (Application)

5. 엣지 로케이션보다 실제 서버가 더 가까운 경우

한가지 의문점이 드는 부분은 “CDN(CloudFront)을 사용하면 무조건 속도가 빨라질까?”였다. “실제 서버(Origin)가 바로 옆에 있다면 어떻게 될까?”에 대한 궁금증을 인프라 관점에서 풀어보고자 합니다.

5.1) 물리적 거리보다 중요한 '경로의 원칙'

결론부터 말하면, 실제 서버가 아무리 가까워도 클라이언트는 항상 엣지 로케이션(Edge Location)과 통신합니다.

이유: DNS 조회 결과가 이미 엣지 로케이션의 IP를 가리키고 있기 때문입니다. 클라이언트는 실제 서버의 존재를 모른 채 엣지 서버를 '최종 목적지'로 알고 데이터를 요청합니다.
이점: 실제 서버의 IP를 숨겨 보안을 강화(보안 계층 유지)하고, 모든 트래픽을 CDN의 최적화된 네트워크 경로 안에서 통제할 수 있습니다.

5.2) 캐시 히트(HIT) vs 캐시 미스(MISS)

성능의 핵심은 엣지 서버에 데이터가 '있느냐 없느냐'에 달려 있습니다.

Cache HIT: 엣지 서버에 이미 데이터가 있는 상태입니다. 실제 서버가 멀든 가깝든 엣지 서버가 즉시 응답하므로 가장 빠릅니다.
Cache MISS: 엣지 서버에 데이터가 없는 상태입니다. 엣지 서버가 실제 서버(Origin)에 데이터를 가지러 갔다 와야 하므로, 이때는 실제 서버가 가까울수록 유리하지만, CDN을 거치지 않는 것보다 단계가 하나 더 추가되어 속도가 약간 떨어질 수 있습니다.

5.3) 캐시 미스는 언제 발생할까?

홈페이지 정보는 항상 캐시에 머물 것 같지만, 다음과 같은 상황에서 '미스'가 발생합니다.

최초 접속: 해당 지역 엣지 서버에 아무도 접속한 적이 없어 데이터가 아직 복사되지 않았을 때.
TTL(Time To Live) 만료: 캐시에는 유효 기간이 있습니다. 이 시간이 지나면 엣지 서버는 데이터를 지우고 다시 오리진 서버에 최신 정보를 요청합니다.
데이터 업데이트: 서버의 파일이 바뀌었더라도 CDN은 자동으로 알지 못합니다. 이때 TTL이 만료될 때까지 기다리거나, '캐시 무효화(Invalidation)'를 실행해야 합니다.

5.4) 캐시 무효화(Invalidation)

새로운 코드를 배포했는데 사용자들에게 예전 화면이 보인다면?

문제: 전 세계 엣지 서버의 캐시가 아직 살아있기 때문입니다.
해결: CloudFront Invalidation(무효화)을 실행합니다. 이는 전 세계 엣지 서버에 "지금 들고 있는 캐시 다 버리고, 오리진 서버에서 새로 가져와!"라고 명령을 내리는 과정입니다.

6. 마무리

CloudFront의 메커니즘은 단순히 속도를 높이는 기술을 넘어, 보안과 효율이라는 두 마리 토끼를 잡기 위한 인프라 엔지니어들의 정교한 설계가 녹아있음을 보여줍니다. OSI 7계층을 검증하기 위해 와이어샤크를 사용했고, ip 주소를 확인하던 과정에서 생긴 의문 하나를 통해 해결해 나아간 이번 과정이 좋은 기초체력이 되기를 바랍니다.

[네트워크] OSI L2/L3/L4/L7 계층별 핵심과 통신흐름

seongw00 — Sun, 15 Mar 2026 20:34:58 +0900

OSI 7계층 모델

오픈 시스템 상호 연결(OSI,Open System Interconnection) 모델은 네트워크 통신 기능을 7개의 계층으로 나누는 개념적 프레임워크입니다. 다양한 하드웨어 및 소프트웨어 기술이 모든 상황과 장소에서 일관되게 작동해야 하기 때문에 네트워크를 통해 데이터를 전송하는 것은 복잡합니다. OSI 7계층 모델은 이러한 환경에서 컴퓨터 네트워크 프로토콜 디자인과 통신을 계층으로 나누어 설명함으로서, 계층별로 모든 기술은 특정 기능을 제공하고 해당 기능을 수행해야 네트워킹에 유용하게 사용할 수 있습니다. 상위 계층의 기술은 기본 구현 세부 사항에 대해 걱정할 필요 없이 하위 수준 기술을 사용할 수 있으므로 추상화의 이점을 누릴 수 있습니다.

그 중 클라우드 및 네트워크 인프라 환경에서 엔지니어가 직접 제어하고 설계하는 핵심은 L2,3,4,7입니다. 1계층(물리)은 자동화되어 있고, 5·6계층은 애플리케이션에 통합되었기 때문입니다.

I. 데이터 링크 계층(L2)

물리 계층(L1)을 통해 송수신되는 정보의 오류를 관리하고, 안전한 정보의 전달을 수행하도록 돕는 계층입니다. 인접한 네트워크 노드 간의 신뢰성 있는 데이터 전송을 보장하는 것이 핵심 목적입니다.

1. 주요 역할과 기능

데이터 링크 계층은 '이웃 교통 경찰'과 같은 역할을 하며, 다음과 같은 구체적인 기능을 수행합니다.

프레이밍(Framing): 네트워크 계층에서 받은 데이터 패킷을 '프레임(Frame)'이라는 단위로 캡슐화합니다. 프레임의 시작과 끝을 구분하여 비트 스트림을 의미 있는 단위로 나눕니다.
물리적 주소 지정(Physical Addressing): 프레임 헤더에 송신자와 수신자의 *물리적 주소(MAC 주소)를 추가합니다. 이는 IP 주소와 달리 장치 고유의 '평면적(Flat)' 주소입니다.
에러 제어(Error Control): 물리 계층에서 발생할 수 있는 오류를 감지하고 수정합니다. 주로 CRC(순환 중복 검사) 방식을 사용하여 데이터의 무결성을 확인하고, 손상된 프레임은 폐기하거나 재전송을 요청합니다.
흐름 제어(Flow Control): 송신 측과 수신 측의 데이터 처리 속도 차이로 인해 수신 측의 버퍼가 넘치지 않도록 데이터 전송량을 조절합니다.
매체 접근 제어(Medium Access Control): 여러 장치가 동일한 통신 매체를 공유할 때, 충돌을 방지하고 누가 언제 매체를 사용할지 결정합니다.

*MAC주소란? 컴퓨터나 스마트폰 등 네트워크에 연결 가능한 모든 하드웨어(NIC, 랜카드)에 제조사에서 부여하는 전 세계 유일한 물리적 고유 식별 번호입니다.

2. 두 개의 서브계층 (IEEE 802 표준 기준)

데이터 링크 계층은 더 세부적으로 두 개의 계층으로 나뉩니다.

LLC (Logical Link Control, 논리 링크 제어): 상위 계층인 네트워크 계층과의 인터페이스 역할을 하며, 흐름 제어 및 오류 제어 기능을 담당합니다.
MAC (Medium Access Control, 매체 접근 제어): 물리적인 매체에 접근하기 위한 제어 및 주소 지정(MAC 주소)을 담당합니다. (예: 이더넷의 CSMA/CD, 와이파이의 CSMA/CA)

3. 대표적인 장비 및 프로토콜

주요 장비: L2 스위치(Switch), 브리지(Bridge), *네트워크 인터페이스 카드(NIC)
주요 프로토콜:
- 이더넷(Ethernet): 가장 대중적인 유선 LAN 표준
- IEEE 802.11 (Wi-Fi): 무선 LAN 표준
- PPP (Point-to-Point Protocol): 두 지점 간의 직접 연결
- HDLC: 고속 데이터 연결 제어

*NIC: 컴퓨터를 유무선 LAN에 연결하여 네트워크 데이터를 주고받을 수 있게 하는 물리적 하드웨어 장치

II. 네트워크 계층(L3)

여러 개의 노드를 거칠 때마다 경로를 선택하고, 데이터를 목적지까지 가장 안전하고 빠르게 전달하는 계층입니다. 서로 다른 네트워크 간의 통신을 가능하게 하는 것이 핵심입니다.

1. 주요 역할과 기능

네트워크 계층은 '내비게이션' 혹은 '우체국 물류 시스템'과 같은 역할을 하며, 다음과 같은 기능을 수행합니다.

라우팅(Routing): 데이터를 목적지까지 보낼 최적의 경로를 설정합니다. 다양한 라우팅 알고리즘을 사용하여 효율적인 길을 찾아냅니다.
호스트 주소 지정(Addressing): 네트워크 내의 모든 호스트가 고유하게 식별될 수 있도록 논리적인 주소를 할당합니다. 대표적으로 * IP 주소가 여기에 해당합니다.
패킷 포워딩(Forwarding): 수신한 패킷을 적절한 출력 인터페이스를 통해 다음 **노드로 전달하는 실제적인 동작을 수행합니다.
단편화 및 재조립(Fragmentation & Reassembly): 데이터 전송 시 하위 계층(L2)의 최대 전송 단위(MTU)보다 패킷이 클 경우, 이를 작은 단위로 나누고 목적지에서 다시 합칩니다.

*IP 주소는 논리주소에 해당하며 L2에서 나온 MAC 주소와는 다른 개념입니다.

**노드? 여기서 노드란 패킷이 최종 목적지 까지 가는 경로에 있는 라우터를 의미합니다. 패킷이 출발지에서 목적지까지 한 번에 갈 수 없는 경우가 대부분이기 때문에 라우터를 이용하고, 이때 "목적지(IP)로 가려면 어느 통로(인터페이스)로 나가서 어떤 장치(다음 라우터)에게 줘야 하는가?"를 결정합니다.

2. 데이터 단위 및 특징

데이터 단위: 이 계층에서 취급하는 정보의 단위는 패킷(Packet)입니다.
비연결성 통신: 대표적인 프로토콜인 IP는 수신자의 확인 없이 패킷을 전송하는 비연결형(Connectionless) 방식을 취하며, 신뢰성 있는 연결은 상위 계층(L4)에서 담당합니다.

3. 대표적인 장비 및 프로토콜

주요 장비: 라우터(Router), L3 스위치
주요 프로토콜:
- IP (IPv4, IPv6): 네트워크 계층의 핵심 프로토콜로 주소 지정과 라우팅을 담당합니다.
- ICMP: 오류 보고 및 네트워크 상태 진단(예: ping 명령)에 사용됩니다.
- IGMP: 멀티캐스트 그룹 관리용 프로토콜입니다.
- 라우팅 프로토콜: OSPF, RIP, BGP 등 경로 최적화를 위해 라우터 간 정보를 교환하는 프로토콜입니다.

III.전송계층(L4)

양 끝단(End-to-End; 종단간 통신이라고도 한다)의 사용자들이 신뢰성 있는 데이터를 주고받을 수 있도록 해 주어, 상위 계층들이 데이터 전달의 유효성이나 효율성을 신경 쓰지 않게 해 주는 계층입니다.

1. 주요 역할과 기능

전송 계층은 다음과 같은 핵심 기능을 수행합니다.

프로세스 간 통신(다중화): 특정 컴퓨터 내의 여러 프로그램 중 어느 프로그램으로 데이터를 보낼지 결정합니다. 이를 위해 포트(Port) 번호를 사용합니다.
신뢰성 있는 전송: 패킷이 손실되거나 순서가 바뀌었을 때 이를 바로잡습니다. (주로 TCP의 역할)
흐름 제어(Flow Control): 송신 측과 수신 측의 데이터 처리 속도 차이를 해결하여 수신 측 버퍼가 넘치지 않게 조절합니다.
혼잡 제어(Congestion Control): 네트워크 선로가 정체될 때 데이터 전송 속도를 줄여 네트워크 붕괴를 막습니다.
분할 및 재조립: 상위 계층의 메시지를 전송하기 적당한 크기인 세그먼트(Segment) 단위로 나누고, 받는 쪽에서 다시 합칩니다.

2. 데이터 단위 및 식별자

데이터 단위: 세그먼트(Segment) (UDP의 경우 데이터그램이라고 부르기도 함)
식별자: 포트(Port) 번호 (예: HTTP는 80, HTTPS는 443 등)

3. 대표적인 프로토콜: TCP vs UDP

전송 계층에서 가장 중요한 것은 이 두 프로토콜의 차이점입니다.

구분	TCP (Transmission Control Protocol)	UDP (User Datagram Protocol)
성격	연결 지향형 (3-way handshaking)	비연결형
특징	신뢰성 높음, 순서 보장, 흐름/혼잡 제어	속도 빠름, 오버헤드 적음, 순서 보장 안 됨
용도	웹 브라우징(HTTP), 파일 전송(FTP), 이메일	실시간 스트리밍, 온라인 게임, VoIP

IV. 응용 프로그램 계층(L7)

사용자가 네트워크 서비스에 접근할 수 있도록 인터페이스를 제공하는 계층입니다. 우리가 흔히 사용하는 웹 브라우저, 이메일 프로그램 등이 이 계층의 프로토콜을 사용하여 데이터를 주고받습니다.

1. 주요 역할과 기능

응용 계층은 '서비스의 입구'와 같으며, 다음과 같은 역할을 수행합니다.

네트워크 가상 단말기: 원격 서버에 접속하여 작업할 수 있는 환경을 제공합니다.
파일 전송, 접근 및 관리: 서로 다른 시스템 간에 파일을 주고받고 관리하는 기능을 제공합니다.
우편 서비스: 전자 우편(E-mail)의 발신 및 수신을 지원합니다.
디렉터리 서비스: 분산 데이터베이스 소스에 접근하여 전역적인 정보를 제공합니다.

2. OSI 7계층 vs TCP/IP 모델

OSI 모델: 5계층(세션), 6계층(표현), 7계층(응용)이 엄격하게 분리되어 있습니다.
TCP/IP 모델: 이 세 계층의 기능을 하나로 묶어 '응용 계층(Application Layer)' 하나로 처리합니다. 실제 우리가 사용하는 인터넷 환경은 대부분 이 통합된 방식을 따릅니다.

3. 대표적인 프로토콜

우리가 일상에서 가장 많이 접하는 프로토콜들이 모두 여기에 모여 있습니다.

HTTP / HTTPS: 웹 페이지를 주고받을 때 사용
FTP: 파일 전송 시 사용
SMTP / POP3 / IMAP: 이메일 전송 및 수신 시 사용
DNS: 도메인 이름(https://seongw00.tistory.com/)을 IP 주소로 변환할 때 사용
SSH / Telnet: 원격 시스템에 안전하게 접속할 때 사용
DHCP: 호스트에 IP 주소를 자동으로 할당할 때 사용

데이터의 이동: 캡슐화(Encapsulation)와 역캡슐화(De-encapsulation)

네트워크 통신은 데이터를 겹겹이 포장해서 보내고, 받는 쪽에서 하나씩 뜯어보는 과정입니다. 각 계층에서 데이터가 어떻게 변하고 이동하는지 단계별로 살펴보겠습니다.

1. 송신 측: 데이터를 포장하는 과정 (Top-Down)

사용자가 보낸 원본 데이터가 하위 계층으로 내려가면서 각 계층의 제어 정보(Header)를 덧붙입니다.

1.1) L7 (Application Layer) - 데이터 생성

동작: 사용자가 웹 브라우저에 https://seongw00.tistory.com/를 입력합니다.
데이터: HTTP Request 메시지가 생성됩니다.
상태: 순수한 Data 그 자체입니다.

1.2) L4 (Transport Layer) - 전송 방식 결정

동작: 데이터 앞에 TCP 헤더를 붙입니다. (TCP 3-way handshake로 연결이 확립된 상태)
추가 정보:
- Source Port: 내 브라우저가 임시로 쓰는 포트 (예: 51234)
- Destination Port: 서버의 서비스 포트 (예: 443)
- Sequence Number: 데이터 조각의 순서 번호
상태: Segment (데이터 + L4 헤더)

1.3) L3 (Network Layer) - 주소지 기록

동작: 세그먼트 앞에 IP 헤더를 붙입니다.
추가 정보:
- Source IP: 내 컴퓨터의 IP 주소
- Destination IP: 서버의 IP 주소
상태: Packet (세그먼트 + L3 헤더)

1.4) L2 (Data Link Layer) - 물리적 통로 확보

동작: 패킷 앞에 Ethernet 헤더, 뒤에 FCS(오류 검출용)를 붙입니다.
추가 정보:
- Source MAC: 내 컴퓨터 랜 카드의 물리 주소
- Destination MAC: 내 공유기 혹은 게이트웨이 라우터의 MAC 주소
상태: Frame (패킷 + L2 헤더/트레일러)

2. 중간 과정: 라우팅 (Hop-by-Hop)

데이터가 인터넷을 지날 때, 라우터들은 L3(IP) 헤더를 보고 길을 찾습니다.

흥미로운 점은 다음 목적이 장비로 가기 위해, 라우터를 거칠 때마다 L2(MAC) 주소는 계속 바뀐다는 것입니다.
하지만 L3(IP) 주소와 L4(Port) 정보는 최종 목적지까지 변하지 않고 유지됩니다.

3. 수신 측: 포장을 뜯는 과정 (Bottom-Up)

서버에 도착한 프레임은 역순으로 헤더를 검사하며 올라갑니다.

L2 (Data Link): "이 프레임의 목적지 MAC이 내 랜 카드 주소가 맞나?" 확인 후 헤더를 뜯어내고 패킷을 위로 보냅니다.
L3 (Network): "이 패킷의 목적지 IP가 내 IP가 맞나?" 확인 후 헤더를 뜯어내고 세그먼트를 위로 보냅니다.
L4 (Transport): "오류 없이 순서대로 왔나? 8080번 포트를 쓰는 앱이 누구지?" 확인 후 TCP 헤더를 뜯어내고 순수한 데이터를 앱에 전달합니다.
L7 (Application): 서버 애플리케이션(예: Spring Boot)이 /status 요청을 읽고 응답을 준비합니다.

데이터의 이동: 캡슐화(Encapsulation)와 역캡슐화(De-encapsulation)

와이어샤크를 활용한 계층별 통신 검증

1. 패킷 캡처 준비

로컬 테스트: PC에서 브라우저를 켜고 특정 사이트에 접속하는 과정을 캡처합니다.
필터 설정: 상단 필터창에 http 또는 목적지 서버의 IP를 입력합니다. (예: ip.addr == [서버IP]/google.com을 이용)

필자는 ip.addr 로 조회가 잘 되지 않아 보안연결을 시작하는 클라이언트를 필터링 했다.

2. 패킷 선택 및 상세 분석창 확인

캡처된 리스트 중 하나를 클릭하면 하단에 상세 분석(Packet Details) 창이 뜹니다. 여기서 계층 구조를 그대로 확인할 수 있습니다.

1. Frame (L2 - Data Link):

Ethernet II 섹션을 열어보면 Source MAC 주소와 Destination MAC 주소를 확인할 수 있습니다.

2. Internet Protocol (L3 - Network):

그 아래 Internet Protocol Version 4 섹션을 클릭합니다.
Source IP와 Destination IP가 정확히 찍혀 있는지 확인합니다.

3. Transmission Control Protocol (L4 - Transport):

Transmission Control Protocol 섹션을 클릭합니다.
여기서 Source Port와 Destination Port를 확인할 수 있습니다.
TCP라면 *[SYN], [SYN, ACK], [ACK]로 이어지는 3-way handshake 과정도 패킷 리스트에서 직접 볼 수 있습니다.

4. Hypertext Transfer Protocol (L7 - Application):

가장 아래에 있는 Hypertext Transfer Protocol 섹션을 클릭합니다.
실제로 우리가 요청한 GET /status HTTP/1.1 같은 메시지와 헤더 정보가 텍스트로 보입니다.

마무리

OSI 7계층이 실제 패킷과 도메인 체인으로 어떻게 구현되어 있는지 확인했습니다. 이 지식은 단순히 시험을 위한 것이 아니라, 인프라 장애라는 전장에서 가장 강력한 무기가 됩니다.

서비스 장애가 발생했을 때 L7 애플리케이션 코드부터 열어보기보단, Bottom-Up(하향식) 접근법을 선택할 수 있습니다.

L3 단계: ping을 날려 목적지 IP까지의 물리적 통로가 살아있는지 확인하고,
L4 단계: telnet이나 nc로 서비스 포트가 열려 있는지, TCP 핸드쉐이크가 정상인지 체크하며,
L7 단계: 그제야 비로소 HTTP 응답 코드와 애플리케이션 로그를 분석하며 문제의 본질을 파고듭니다.

dig 결과에서 본 CNAME의 미로나 와이어샤크의 복잡한 패킷들은 결국 이 계층들이 완벽하게 맞물려 돌아가고 있음을 증명하는 증거들입니다. 인프라를 설계하고 운영한다는 것은, 이 보이지 않는 계층들 사이에 신뢰의 다리를 놓는 과정입니다. 지금의 내용이 앞으로 마주할 인프라 장애를 해결하는 기초체력이 되기를 바랍니다.