Booil Jung

통신 프로토콜

현대 디지털 사회의 근간을 이루는 네트워크 통신은 보이지 않는 규칙과 약속의 집합체 위에서 작동한다. 이 복잡하고 정교한 시스템의 핵심에는 ‘통신 프로토콜’이 자리 잡고 있다. 본 보고서의 제1부에서는 모든 네트워크 통신의 이론적 토대를 구축한다. 먼저 ‘프로토콜’이라는 추상적 개념을 그 구성 요소와 기능적 필수 요건으로 해부하고, 이어서 이러한 복잡한 상호작용에 구조화된 프레임워크를 제공하는 아키텍처 모델을 탐구함으로써 디지털 대화의 언어가 어떻게 구성되고 작동하는지에 대한 근본적인 이해를 도모하고자 한다.

통신 프로토콜을 단순히 ‘규칙의 집합’으로 정의하는 것을 넘어, 이 장에서는 프로토콜을 이질적인 컴퓨팅 시스템 간의 의미 있는 대화를 가능하게 하는 구조화된 언어 시스템으로 규정한다. 이를 통해 프로토콜의 본질, 핵심 구성 요소, 그리고 안정적인 통신을 위한 기본 기능들을 심도 있게 분석한다.

통신 프로토콜, 또는 통신 규약은 컴퓨터나 원거리 통신 장비와 같은 둘 이상의 통신 개체 사이에서 메시지를 주고받는 양식과 규칙의 체계이다.1 이는 단순히 데이터를 전송하는 기술적 절차를 넘어, 상호 간에 정보를 오해 없이 정확하고 효율적으로 교환하기 위한 사회적 약속과 유사한 성격을 띤다. 우리가 일상생활에서 공통된 언어와 문법을 사용하여 의사소통하듯, 서로 다른 하드웨어나 소프트웨어로 구성된 기기들도 상호 이해 가능한 ‘공통의 언어’, 즉 프로토콜이 있어야만 비로소 의미 있는 통신이 가능하다.3

프로토콜이 없다면, 네트워크를 통한 효과적인 커뮤니케이션은 거의 불가능에 가깝다. 예를 들어, A 컴퓨터가 자신만의 방식으로 정리된 10GB의 데이터를 B 컴퓨터에 전송한다고 가정해 보자. 만약 두 컴퓨터 사이에 데이터의 형식, 전송 속도, 오류 처리 방식 등에 대한 공통된 약속이 없다면, B 컴퓨터는 수신한 데이터 덩어리를 어떻게 해석해야 할지 알 수 없으며, 데이터가 잘못 해석되거나 완전히 손실될 수 있다.1 또한, B 컴퓨터의 수신 능력이 5GB에 불과하다면, A 컴퓨터가 일방적으로 10GB를 전송할 경우 데이터의 절반이 소실되는 문제가 발생한다. 프로토콜은 이러한 문제들을 사전에 방지하고 제어하는 역할을 수행한다.1

이러한 상호 운용성의 중요성 때문에, 통신 프로토콜은 국제 표준화 기구(ISO)나 전기 전자 기술자 협회(IEEE)와 같은 표준화 기관에 의해 정의되고 관리된다.1 이는 특정 제조사에 종속되지 않는 개방형 시스템 간의 연결을 보장하며, 인터넷과 같은 거대한 네트워크 생태계가 유지될 수 있는 기반이 된다. 프로토콜은 그 구현 방식이 독립적이어서 하드웨어, 소프트웨어, 또는 이 둘의 조합으로 구현될 수 있다.2

모든 통신 프로토콜은 그 복잡성과 기능에 관계없이 세 가지 핵심 요소로 구성된다. 이 세 요소는 상호 유기적으로 작용하며 프로토콜의 완전성을 보장한다.

• 구문 (Syntax): 데이터의 구조, 형식, 부호화 방식을 규정한다.6 이는 데이터가 전송, 수신, 해석될 때 일관성을 유지하게 하는 ‘문법’에 해당한다. 구문은 데이터가 어떤 순서의 비트와 바이트로 표현되는지, 메시지의 각 필드가 어디에 위치하며 얼마나 큰지를 정의한다. 예를 들어, IP 패킷 헤더에서 처음 4비트는 버전 정보, 다음 4비트는 헤더 길이를 나타내는 것처럼, 데이터 블록의 형식을 명확히 하는 것이 구문의 역할이다.8
• 의미 (Semantics): 구문에 의해 정의된 각 데이터 필드에 의미를 부여하고, 그 의미에 따라 수행해야 할 제어 동작을 규정한다.5 이는 프로토콜 언어의 ‘어휘와 의미’에 해당한다. 예를 들어, 주소 필드는 데이터의 목적지를 나타내며, 특정 플래그 비트가 1로 설정되면 연결을 요청하는 의미(SYN)를 갖는다. 또한, 오류 제어, 흐름 제어, 인증과 같은 협조 사항과 관리 정보를 정의하여 효율적이고 정확한 정보 전송을 보장한다.5
• 타이밍 (Timing): 데이터 전송의 ‘시기’와 ‘속도’를 규정한다.5 이는 대화의 ‘리듬과 순서’에 비유할 수 있다. 두 기기 간의 통신 속도를 맞추고, 메시지의 전송 순서를 제어하며, 송신 측이 수신 측의 처리 능력을 초과하지 않도록 조절하는 기능 등이 여기에 포함된다. 예를 들어, 송신자가 데이터를 보낸 후 얼마 동안 응답을 기다릴 것인지(타임아웃), 어떤 순서로 메시지를 교환하여 연결을 설정할 것인지 등을 정의한다.10

이 세 가지 기둥은 서로 분리될 수 없다. 구문 변경은 의미와 타이밍 규칙의 변경 없이는 무의미하며, 이들의 조화로운 결합을 통해서만 완전하고 기능적인 프로토콜이 탄생할 수 있다. 프로토콜 설계 및 문제 해결에 있어 이 세 가지 요소를 종합적으로 고려하는 것은 필수적이다.

프로토콜은 앞서 설명한 세 가지 핵심 요소를 바탕으로 안정적이고 효율적인 통신을 구현하기 위해 다양한 기본 기능들을 수행한다. 이러한 기능들은 계층화된 프로토콜 스택의 각 부분에 나뉘어 구현되며, 서로 협력하여 데이터의 성공적인 전달을 보장한다.

• 단편화와 재합성 (Fragmentation and Reassembly): 송신 측에서는 전송할 데이터가 네트워크가 처리할 수 있는 최대 단위(MTU, Maximum Transmission Unit)보다 클 경우, 이를 더 작은 크기의 블록(패킷 또는 프레임)으로 나눈다. 이를 단편화라 한다. 수신 측에서는 이렇게 나뉘어 도착한 블록들을 원래의 순서대로 재조립하여 완전한 데이터로 복원하는데, 이를 재합성이라 한다. 이 기능은 대용량 데이터의 효율적인 전송과 오류 관리를 용이하게 한다.5
• 캡슐화 (Encapsulation): 데이터가 송신 측의 프로토콜 스택을 따라 상위 계층에서 하위 계층으로 내려갈 때, 각 계층은 자신의 기능을 수행하는 데 필요한 제어 정보(주소, 오류 검출 부호 등)를 ‘헤더(Header)’나 ‘트레일러(Trailer)’ 형태로 데이터에 추가한다. 이렇게 데이터를 제어 정보로 감싸는 과정을 캡슐화라고 한다. 이 과정을 통해 각 계층은 하위 계층의 도움을 받아 자신의 임무를 완수할 수 있다.5
• 연결 제어 (Connection Control): 통신 세션의 생애 주기를 관리하는 기능이다. 데이터를 전송하기 전에 논리적인 통신 경로를 설정하고(연결 수립), 데이터 전송이 완료될 때까지 연결을 유지하며, 통신이 끝나면 연결을 해제한다. 이는 전화 통화와 유사한 ‘연결 지향형(Connection-Oriented)’ 서비스(예: TCP)와, 각 데이터가 독립적으로 전송되는 엽서와 같은 ‘비연결형(Connectionless)’ 서비스(예: UDP)로 나뉜다.5
• 흐름 제어 (Flow Control): 송신 측의 데이터 전송 속도가 수신 측의 데이터 처리 속도를 초과하여 데이터 유실이 발생하는 것을 방지하는 기능이다. 수신 측은 자신이 처리할 수 있는 데이터의 양을 송신 측에 알려줌으로써 데이터의 흐름을 조절한다.5
• 오류 제어 (Error Control): 데이터 전송 과정에서 발생할 수 있는 오류(데이터 손상, 손실 등)를 검출하고 정정하는 기능이다. 일반적으로 체크섬(Checksum)과 같은 기법으로 오류를 검출하고, 자동 반복 요청(ARQ, Automatic Repeat reQuest) 메커니즘을 통해 손상되거나 손실된 데이터를 재전송받아 오류를 복구한다.1
• 주소 설정 (Addressing): 데이터 패킷에 송신지와 목적지의 고유한 주소를 명기하여, 광대한 네트워크 내에서 데이터가 정확한 목적지로 전달될 수 있도록 하는 기능이다. 이는 네트워크 계층의 논리적 주소(IP 주소)와 데이터 링크 계층의 물리적 주소(MAC 주소)를 포함한다.4
• 다중화 (Multiplexing): 하나의 물리적인 통신 회선을 여러 개의 논리적인 채널로 나누어 여러 사용자가 동시에 통신할 수 있도록 하는 기술이다. 이는 한정된 네트워크 자원을 효율적으로 공유하게 함으로써 네트워크의 전체 처리량을 높이는 데 기여한다.5
• 순서 결정 (Sequencing): 연결 지향형 서비스에서, 단편화된 데이터 블록들이 네트워크의 여러 경로를 통해 전송되면서 순서가 뒤바뀌어 도착할 수 있다. 순서 결정 기능은 각 블록에 순서 번호를 부여하여, 수신 측에서 이를 원래의 순서대로 정확하게 재조립할 수 있도록 보장한다.5

네트워크 프로토콜의 복잡성을 관리하고 표준화하기 위해, 통신 기능들은 여러 개의 계층(Layer)으로 나뉜 추상적인 모델로 구조화된다. 이 장에서는 네트워크 프로토콜을 이해하는 데 가장 중요한 두 가지 개념적 모델인 OSI 7계층 모델과 TCP/IP 모델을 분석한다. 이론적 이상을 추구하는 OSI 모델과 실용적 현실을 반영하는 TCP/IP 모델의 비교를 통해, 계층화된 아키텍처의 원리와 그 중요성을 심도 있게 탐구한다.

OSI(Open Systems Interconnection) 참조 모델은 국제 표준화 기구(ISO)가 1980년대에 개발한 네트워크 통신의 개념적 모델이다.13 이 모델의 주된 목적은 서로 다른 제조업체의 통신 시스템이 원활하게 상호 작용할 수 있도록, 즉 상호 운용성을 확보하기 위한 표준 프레임워크를 제공하는 것이었다. OSI 모델은 통신에 필요한 기능들을 7개의 독립적인 계층으로 세분화하여 각 계층이 수행해야 할 역할을 명확히 정의했다. 이는 특정 프로토콜의 집합이 아닌, 네트워크 설계와 교육을 위한 이상적인 참조 모델로서 중요한 가치를 지닌다.14

• 제7계층: 응용 계층 (Application Layer)

  사용자가 네트워크 서비스에 직접 접근할 수 있도록 인터페이스를 제공한다. 이메일(SMTP), 파일 전송(FTP), 웹 브라우징(HTTP) 등 최종 사용자 애플리케이션과 관련된 서비스를 수행한다.13

• 제6계층: 표현 계층 (Presentation Layer)

  데이터의 형식을 통일하고, 응용 계층이 이해할 수 있는 형태로 데이터를 변환하는 역할을 한다. 데이터 암호화, 압축, 그리고 문자 코드 변환(예: ASCII와 EBCDIC 간의 변환)과 같은 기능이 이 계층에서 이루어진다.10

• 제5계층: 세션 계층 (Session Layer)

  양 끝단의 응용 프로그램 간의 통신 세션을 설정, 관리, 그리고 종료하는 역할을 담당한다. 대화 제어(dialogue control)를 통해 데이터 교환의 순서를 정하고, 동기화 지점(checkpoint)을 설정하여 통신 장애 발생 시 데이터 복구를 용이하게 한다.10

• 제4계층: 전송 계층 (Transport Layer)

  종단 간(end-to-end)의 신뢰성 있는 데이터 전송을 책임진다. 데이터를 세그먼트(segment) 단위로 분할하고, 각 세그먼트의 순서를 제어하며, 흐름 제어와 오류 제어를 통해 데이터가 손상 없이 정확한 순서로 목적지에 도달하도록 보장한다.13

• 제3계층: 네트워크 계층 (Network Layer)

  데이터를 목적지까지 전달하기 위한 최적의 경로를 결정(라우팅)하고, 논리적 주소(IP 주소)를 관리한다. 여러 개의 독립적인 네트워크를 연결하여 거대한 인터넷을 구성하는 핵심적인 역할을 수행하며, 데이터 단위를 패킷(packet)이라 부른다.13

• 제2계층: 데이터 링크 계층 (Data Link Layer)

  물리적으로 직접 연결된 두 노드 간의 신뢰성 있는 정보 전송을 담당한다. 물리적 주소(MAC 주소)를 사용하여 통신 대상을 식별하고, 데이터를 프레임(frame) 단위로 구성하며, 물리적 전송 매체에서 발생할 수 있는 오류를 검출하고 제어한다.13

• 제1계층: 물리 계층 (Physical Layer)

  네트워크의 물리적, 전기적 특성을 정의한다. 케이블, 커넥터, 신호 레벨 등 물리적 매체를 통해 데이터를 비트(bit) 스트림 형태로 변환하여 전송하는 역할을 한다.13

TCP/IP 모델은 미 국방부(DoD)의 연구에서 시작되어 오늘날 인터넷을 구동하는 실질적인 프로토콜 모음(protocol suite)이다.14 OSI 모델처럼 순수한 이론적 프레임워크가 아니라, 실제로 성공적으로 동작하는 프로토콜들을 기반으로 구축된 실용적인 아키텍처다. 일반적으로 4개의 계층으로 설명되지만, OSI 모델과의 비교를 용이하게 하기 위해 5계층으로 나누어 설명하기도 한다.14

• 제4계층: 응용 계층 (Application Layer)

  OSI 모델의 응용, 표현, 세션 계층의 기능을 통합한 계층이다. 사용자와 직접 상호작용하는 프로토콜들, 예를 들어 HTTP(웹), FTP(파일 전송), SMTP(이메일 전송), DNS(도메인 이름 변환) 등이 이 계층에서 동작한다.12

• 제3계층: 전송 계층 (Transport Layer)

  OSI의 전송 계층과 거의 동일한 역할을 수행한다. 종단 간 통신을 담당하며, 신뢰성 있는 연결 지향형 서비스를 제공하는 TCP(Transmission Control Protocol)와, 빠르지만 비신뢰적인 비연결형 서비스를 제공하는 UDP(User Datagram Protocol)가 대표적인 프로토콜이다.14

• 제2계층: 인터넷 계층 (Internet Layer)

  OSI의 네트워크 계층에 해당한다. 인터넷 프로토콜(IP)을 사용하여 패킷을 목적지까지 전달하기 위한 주소 지정(IP 주소)과 경로 설정(라우팅)을 책임진다. IP는 비연결형이며 최선형(best-effort) 전달 서비스를 제공한다.14

• 제1계층: 네트워크 접속 계층 (Network Access/Interface Layer)

  OSI의 데이터 링크 계층과 물리 계층의 기능을 통합한 계층이다. 물리적인 네트워크 매체(예: 이더넷 케이블, Wi-Fi)를 통해 데이터를 실제로 전송하는 데 필요한 모든 하드웨어적 요소와 프로토콜을 다룬다. 물리 주소(MAC 주소)를 사용하여 동일 네트워크 내의 장치 간 데이터 프레임을 전송한다.14

OSI 모델과 TCP/IP 모델은 네트워크 통신을 계층적으로 이해하는 공통된 목표를 가지지만, 그 구조와 철학에서 중요한 차이를 보인다. 이 차이를 이해하는 것은 이론적 지식과 실제 네트워크 환경을 연결하는 데 필수적이다.

• 구조적 차이와 개발 철학: 가장 명백한 차이는 계층의 수이다. OSI는 7개, TCP/IP는 4개의 계층으로 구성된다.16 이러한 차이는 개발 철학에서 비롯된다. OSI는 프로토콜이 개발되기 전에 이상적인 통신 기능을 정의하는 하향식(top-down) 접근 방식을 취한 규범적(prescriptive) 모델이다. 반면, TCP/IP는 이미 성공적으로 작동하던 프로토콜들을 설명하기 위해 만들어진 상향식(bottom-up) 접근의 기술적(descriptive) 모델이다.15
• 기능의 통합과 종단 간 원칙: TCP/IP 모델이 OSI의 상위 3개 계층(응용, 표현, 세션)을 하나의 응용 계층으로 통합한 것은 단순한 축약이 아니다. 이는 인터넷의 핵심 설계 철학인 ‘종단 간 원칙(End-to-End Principle)’을 반영한 결과이다. 이 원칙에 따르면, 네트워크 자체는 최대한 단순하게 유지하고, 세션 관리나 데이터 형식 변환과 같은 복잡한 기능은 양 끝단의 호스트(애플리케이션)가 책임져야 한다는 것이다. 웹 브라우저가 쿠키를 통해 세션을 관리하고 HTML을 렌더링(표현)하는 것이 그 예다. 마찬가지로, TCP/IP의 네트워크 접속 계층이 OSI의 하위 2개 계층(데이터 링크, 물리)을 통합한 것은 인터넷이 특정 물리적 네트워크 기술(이더넷, 토큰링 등)에 구애받지 않는 범용 네트워크를 지향했기 때문이다.14 IP라는 공통의 추상화 계층 위에서 동작하므로, 그 아래의 구체적인 물리적 전송 방식은 하나의 계층으로 묶어 처리할 수 있다.
• 서비스 및 프로토콜 의존성: OSI 모델은 서비스, 인터페이스, 프로토콜의 개념을 명확하게 구분하지만, TCP/IP는 이러한 구분이 상대적으로 모호하다.15 또한 OSI는 네트워크 계층에서도 연결형과 비연결형 서비스를 모두 지원하는 반면, TCP/IP의 인터넷 계층은 비연결형 서비스(IP)만을 제공한다.15

결론적으로, OSI 모델은 네트워크의 모든 가능한 기능을 체계적으로 분류하고 이해하는 데 탁월한 교육적, 이론적 도구이다. 반면, TCP/IP 모델은 현재의 인터넷이 어떻게 실제로 작동하는지를 보여주는 실용적이고 검증된 아키텍처이다. 네트워크 전문가들은 문제 해결과 설계 과정에서 두 모델을 상호 보완적으로 활용하여, 이론적 원칙을 바탕으로 실제 시스템의 동작을 분석하고 최적화한다.16

OSI 계층	TCP/IP 계층	주요 프로토콜/표준	PDU (프로토콜 데이터 단위)
7. 응용(Application)	4. 응용(Application)	HTTP, FTP, SMTP, DNS	메시지(Message) / 데이터(Data)
6. 표현(Presentation)		SSL/TLS, JPEG, MPEG	메시지(Message) / 데이터(Data)
5. 세션(Session)		NetBIOS, Sockets API	메시지(Message) / 데이터(Data)
4. 전송(Transport)	3. 전송(Transport)	TCP, UDP	세그먼트(Segment) / 데이터그램(Datagram)
3. 네트워크(Network)	2. 인터넷(Internet)	IP, ICMP, IGMP, ARP	패킷(Packet)
2. 데이터 링크(Data Link)	1. 네트워크 접속(Network Access)	Ethernet, Wi-Fi, PPP	프레임(Frame)
1. 물리(Physical)		RS-232, 케이블, 허브	비트(Bit)

표 1: OSI와 TCP/IP 모델 비교 분석. 이 표는 OSI 7계층과 실용적인 TCP/IP 4계층 모델을 비교하여 각 계층의 역할, 주요 프로토콜, 그리고 데이터 단위를 명확하게 보여준다. 13

네트워크 통신에서 데이터가 한 컴퓨터에서 다른 컴퓨터로 전달되는 과정은 계층화된 모델을 통해 체계적으로 이루어진다. 이 과정의 핵심은 캡슐화(Encapsulation)와 역캡슐화(Decapsulation)이다.

• 캡슐화 (Encapsulation) - 송신 측:

  사용자 애플리케이션에서 생성된 데이터는 프로토콜 스택을 따라 아래 방향으로 이동한다. 각 계층은 상위 계층으로부터 받은 데이터 단위(PDU, Protocol Data Unit)에 자신의 기능을 수행하기 위한 제어 정보, 즉 헤더(Header)를 추가한다. 이 과정이 바로 캡슐화이다.12

  1. 응용 계층: 사용자의 데이터가 메시지(Message) 형태로 생성된다.
  2. 전송 계층: 메시지를 받아 TCP 또는 UDP 헤더를 추가한다. 이 헤더에는 출발지 및 목적지 포트 번호, 순서 번호 등의 정보가 포함된다. 이 결과물을 TCP에서는 세그먼트(Segment), UDP에서는 데이터그램(Datagram)이라 부른다.
  3. 인터넷/네트워크 계층: 세그먼트나 데이터그램을 받아 IP 헤더를 추가한다. IP 헤더에는 출발지 및 목적지 IP 주소와 같은 라우팅 정보가 담겨 있다. 이 단위를 패킷(Packet)이라 한다.
  4. 네트워크 접속/데이터 링크 계층: 패킷을 받아 MAC 헤더와 트레일러(오류 검사를 위한 FCS 등)를 추가한다. MAC 헤더에는 다음 홉(hop)의 물리적 주소가 포함된다. 이 단위를 프레임(Frame)이라 한다.
  5. 물리 계층: 최종적으로 생성된 프레임은 전기 신호나 광 신호와 같은 비트(Bit) 스트림으로 변환되어 물리적 매체를 통해 전송된다.19

• 역캡슐화 (Decapsulation) - 수신 측:

  수신 측에서는 이 과정이 정확히 역순으로 진행된다. 데이터는 프로토콜 스택을 따라 위 방향으로 이동하며, 각 계층은 자신에게 해당하는 헤더를 제거(decapsulate)하고, 헤더의 정보를 분석하여 필요한 작업을 수행한 뒤, 나머지 데이터를 상위 계층으로 전달한다.23 이 과정을 통해 물리적 신호로 전달된 비트 스트림은 최종적으로 수신 애플리케이션이 이해할 수 있는 원래의 메시지로 복원된다.

제1부에서 다룬 이론적 기초와 아키텍처 모델을 바탕으로, 제2부에서는 현대 인터넷 통신을 실질적으로 구동하는 핵심 프로토콜들을 심층적으로 분석한다. 전송 계층의 신뢰성과 속도를 책임지는 TCP와 UDP부터, 글로벌 주소 체계와 라우팅의 근간인 IP, 그리고 사용자와 가장 가까운 응용 계층의 프로토콜에 이르기까지, 각 프로토콜의 헤더 구조, 작동 메커니즘, 그리고 글로벌 네트워크를 기능하게 하는 중요한 제어 방식들을 상세히 해부한다.

전송 계층은 종단 간(end-to-end) 데이터 전송을 책임지는 심장부와 같다. 이 장에서는 인터넷의 두 가지 주요 전송 프로토콜인 TCP와 UDP에 초점을 맞춘다. 신뢰성을 최우선으로 하는 TCP와 속도를 중시하는 UDP를 비교 분석함으로써, 네트워크 애플리케이션 설계에서 마주하는 근본적인 트레이드오프 관계를 탐구한다.

전송 제어 프로토콜(TCP)은 인터넷 프로토콜 스위트의 핵심을 이루는 연결 지향형(connection-oriented), 신뢰성(reliable) 프로토콜이다.4 TCP의 가장 중요한 임무는 하위의 비신뢰적인 인터넷 프로토콜(IP) 위에서 동작하면서, 데이터가 오류 없이, 손실이나 중복 없이, 보낸 순서대로 목적지에 전달되는 것을 보장하는 것이다.20 이러한 높은 신뢰성을 확보하기 위해 TCP는 연결 설정, 흐름 제어, 오류 제어, 혼잡 제어 등 정교하고 복잡한 메커니즘을 사용한다.

TCP의 모든 기능은 20바이트(옵션 제외) 크기의 헤더에 담긴 제어 정보를 통해 구현된다.

• Sequence Number (순서 번호): 32비트 크기의 필드로, 전송되는 데이터의 각 바이트에 부여되는 고유한 번호다. TCP는 데이터를 세그먼트라는 단위로 나누어 전송하는데, 이 순서 번호를 통해 수신 측은 세그먼트들이 원래 어떤 순서였는지 파악하고 정확하게 재조립할 수 있다. 이는 데이터의 순서 보장을 위한 핵심 요소다.31
• Acknowledgement Number (확인 응답 번호): 32비트 크기의 필드로, 수신 측이 송신 측에게 데이터를 성공적으로 수신했음을 알리는 데 사용된다. 구체적으로, ACK 번호는 수신 측이 ‘다음에 수신하기를 기대하는’ 바이트의 순서 번호를 의미한다. 예를 들어, 순서 번호 100부터 200바이트의 데이터를 수신했다면, 수신 측은 ACK 번호를 300으로 설정하여 “300번 바이트부터 보내주세요”라는 의미를 전달한다.31
• Flags (플래그): 6개의 1비트 플래그로 구성되며, TCP 연결의 상태를 제어하고 특정 동작을 지시하는 데 사용된다.
  • SYN (Synchronize): 연결 설정을 시작하기 위해 사용된다. 3-way handshake의 첫 단계에서 이 플래그가 설정된다.
  • ACK (Acknowledge): 확인 응답 번호 필드가 유효함을 나타낸다. 연결이 수립된 후의 모든 패킷에는 이 플래그가 설정된다.
  • FIN (Finish): 연결 종료를 요청하기 위해 사용된다.
  • RST (Reset): 비정상적인 상황으로 연결을 강제로 리셋할 때 사용된다. 예를 들어, 존재하지 않는 포트로 접속 시도 시 RST 패킷이 반환된다.33
  • PSH (Push): 수신 측의 TCP 버퍼에 데이터를 쌓아두지 말고 즉시 상위 애플리케이션으로 전달하라고 지시한다.33
  • URG (Urgent): 긴급 포인터 필드가 유효함을 나타내며, 우선 처리해야 할 긴급 데이터가 있음을 알린다.
• Window Size (윈도우 크기): 16비트 크기의 필드로, 흐름 제어에 사용된다. 수신 측이 현재 자신의 버퍼에 수용할 수 있는 데이터의 양(바이트 단위)을 송신 측에 알리는 역할을 한다. 이 값을 통해 송신 측은 수신 측이 감당할 수 있는 만큼만 데이터를 전송하게 된다.34

TCP는 데이터를 전송하기 전에 반드시 논리적인 연결을 설정하고, 전송이 끝나면 안전하게 연결을 해제한다.

• 3-Way Handshake (연결 설정):

  신뢰성 있는 양방향 통신을 위해 양측이 서로 통신할 준비가 되었음을 확인하고, 초기 순서 번호를 교환하는 3단계 과정이다.12

  1. SYN: 클라이언트가 서버에게 연결을 요청하는 SYN 패킷을 보낸다. 이때 클라이언트는 자신의 초기 순서 번호(Client_ISN)를 설정하여 전달한다.
  2. SYN+ACK: 서버는 클라이언트의 요청을 수락하고, 자신도 통신할 준비가 되었음을 알리는 SYN과 클라이언트의 요청을 잘 받았다는 ACK를 함께 보낸다. 서버는 자신의 초기 순서 번호(Server_ISN)를 설정하고, 확인 응답 번호는 Client_ISN + 1로 설정한다.
  3. ACK: 클라이언트는 서버의 응답을 받고, 서버의 SYN에 대한 ACK 패킷을 보낸다. 이때 확인 응답 번호는 Server_ISN + 1로 설정된다. 이 패킷이 서버에 도달하면 양방향 연결이 완전히 수립된다.31

• 4-Way Handshake (연결 종료):

  연결을 안전하게 종료하기 위한 4단계 과정이다. 한쪽이 FIN을 보내면, 상대방은 ACK로 응답한 후 자신의 데이터를 모두 보낸 뒤에 FIN을 보내고, 마지막으로 상대방의 ACK를 받음으로써 연결이 완전히 종료된다. 이 과정을 통해 양측 모두 데이터 손실 없이 통신을 마칠 수 있다.31

흐름 제어는 송신 측과 수신 측 단 둘 사이의 데이터 전송 속도를 조절하여, 빠른 송신자가 느린 수신자의 버퍼를 넘치게 하는 것을 방지하는 메커니즘이다.5 TCP는 이를 위해 슬라이딩 윈도우(Sliding Window) 기법을 사용한다.35

수신 측은 자신이 보낼 ACK 패킷의 ‘윈도우 크기’ 필드에 현재 수용 가능한 버퍼 공간의 크기를 담아 송신 측에 알린다. 송신 측은 이 윈도우 크기만큼의 데이터를 ACK 없이 연속적으로 전송할 수 있다.39 수신 측이 버퍼의 데이터를 처리하고 공간이 생기면, 다음 ACK를 보낼 때 더 큰 윈도우 크기를 광고한다. 그러면 송신 측의 윈도우가 앞으로 ‘미끄러지듯(slide)’ 이동하여 더 많은 데이터를 보낼 수 있게 된다. 이처럼 윈도우 크기는 수신 측의 상태에 따라 동적으로 조절되며, 만약 윈도우 크기가 0이 되면 송신자는 전송을 멈추고 수신 측이 다시 공간을 확보하기를 기다린다.35

오류 제어는 전송 중에 발생한 패킷 손실이나 손상을 감지하고 복구하는 기능이다. TCP는 이를 위해 자동 반복 요청(ARQ, Automatic Repeat reQuest) 기법들을 사용한다.40

• 정지-대기 ARQ (Stop-and-Wait ARQ): 가장 단순한 방식으로, 송신자가 패킷 하나를 보내고 ACK가 올 때까지 기다린다. ACK를 받으면 다음 패킷을 보낸다. 매우 비효율적이지만 오류 제어의 기본 개념을 보여준다.38
• Go-Back-N ARQ (GBN): 슬라이딩 윈도우를 사용하는 효율적인 방식이다. 송신자는 윈도우 크기만큼 패킷을 연속으로 보낼 수 있다. 만약 특정 패킷(N)에서 오류가 발생하여 타임아웃이 되거나 부정 응답(NAK)을 받으면, 송신자는 오류가 발생한 N번 패킷부터 그 이후에 보냈던 모든 패킷을 전부 재전송한다. 수신 측은 순서에 맞지 않는 패킷은 모두 폐기하기 때문에, 비효율적인 재전송이 발생할 수 있다.38
• 선택적 반복 ARQ (Selective Repeat ARQ): GBN을 개선한 방식으로, 가장 효율적이다. 수신 측은 순서가 맞지 않더라도 정상적으로 수신된 패킷을 버퍼에 저장한다. 송신 측은 오류가 발생한 패킷’만’을 선택적으로 재전송한다. 이를 통해 불필요한 재전송을 최소화하여 네트워크 효율을 극대화한다.38

혼잡 제어는 흐름 제어와 구별되는 중요한 개념이다. 흐름 제어가 송신자와 수신자 ‘사이’의 문제라면, 혼잡 제어는 송신자, 수신자, 그리고 그 사이의 모든 라우터를 포함한 ‘네트워크 전체’의 문제를 다룬다.35 네트워크에 유입되는 데이터의 양이 라우터의 처리 용량을 초과하면 패킷 손실이 발생하고, 송신자들은 이를 재전송하면서 네트워크는 더욱 혼잡해지는 ‘혼잡 붕괴(congestion collapse)’ 상태에 빠질 수 있다. TCP는 이를 방지하기 위해 네트워크 상황을 추론하고 스스로 전송 속도를 조절하는 정교한 알고리즘을 사용한다.

• AIMD (Additive Increase, Multiplicative Decrease): 혼잡 제어의 핵심 철학이다. 네트워크가 안정적일 때는 전송률을 완만하게(선형적으로) 증가시키고(합 증가), 패킷 손실로 혼잡이 감지되면 전송률을 대폭(절반으로) 감소시킨다(곱 감소). 이 방식은 여러 TCP 연결이 네트워크 자원을 공평하게 공유하도록 유도한다.35
• Slow Start (느린 시작): 연결 초기에는 네트워크의 가용 대역폭을 모르기 때문에, 전송률을 지수적으로(매 RTT마다 2배씩) 빠르게 증가시켜 신속하게 네트워크의 한계치를 탐색한다. ‘느린 시작’이라는 이름은 한 번에 최대 속도로 보내는 것이 아니라 1부터 시작한다는 의미에서 붙여졌다. 특정 임계값(threshold)에 도달하거나 패킷 손실이 발생하면 Slow Start 단계는 종료된다.35
• 빠른 재전송 (Fast Retransmit): 패킷 손실을 더 빨리 감지하는 기법이다. 수신 측이 중간에 패킷 하나를 놓치면, 그 뒤에 도착하는 패킷들에 대해 계속해서 동일한 ACK(중복 ACK)를 보낸다. 송신 측이 이 중복 ACK를 3번 수신하면, 타임아웃을 기다리지 않고 즉시 손실된 것으로 추정되는 패킷을 재전송한다.43
• 빠른 회복 (Fast Recovery): 빠른 재전송과 함께 작동한다. 타임아웃으로 인한 혼잡 감지 시에는 전송률을 1로 급격히 줄이지만, 빠른 재전송으로 인한 혼잡 감지 시에는 전송률을 절반으로만 줄이고 선형 증가 단계(AIMD)로 바로 진입한다. 이는 네트워크가 완전히 마비된 것이 아니라 일시적인 문제일 가능성이 높다고 판단하기 때문이며, 더 빠른 회복을 가능하게 한다.37

이러한 제어 메커니즘들의 복합적인 상호작용은 TCP의 본질을 보여준다. TCP는 단순히 데이터를 보내는 프로토콜이 아니라, 개별 연결의 처리량을 극대화하려는 이기적인 목표와 네트워크 전체의 안정성을 유지하려는 이타적인 목표 사이에서 균형을 잡는, 고도로 분산된 자원 관리 알고리즘이다. 이 정교한 설계 덕분에 TCP는 수십 년간 인터넷의 성장을 지탱해올 수 있었지만, 바로 이 복잡성 때문에 UDP에 비해 상대적으로 느리게 느껴지는 원인이 되기도 한다.

사용자 데이터그램 프로토콜(UDP)은 TCP와 정반대의 철학을 가진 프로토콜이다. UDP는 비연결형(connectionless), 비신뢰성(unreliable) 프로토콜로, 최소한의 기능만을 제공하는 ‘최선형(best-effort)’ 서비스를 지향한다.29

UDP는 데이터를 보내기 전에 연결을 설정하는 핸드셰이크 과정이 없다. 또한 흐름 제어, 혼잡 제어, 오류 제어, 순서 보장과 같은 TCP의 복잡한 기능들을 전혀 수행하지 않는다.3 그 결과, UDP 헤더는 출발지/목적지 포트, 길이, 체크섬 단 4개의 필드로 구성된 8바이트에 불과하여 TCP 헤더(최소 20바이트)보다 훨씬 작고 가볍다.29

이러한 단순함은 UDP의 가장 큰 장점인 ‘속도’와 ‘낮은 지연 시간(latency)’으로 이어진다. 핸드셰이크 과정이 없어 데이터 전송을 즉시 시작할 수 있고, 각종 제어 메커니즘이 없어 처리 오버헤드가 적다. 따라서 UDP는 데이터의 일부가 손실되거나 순서가 뒤바뀌더라도 실시간성이 더 중요한 애플리케이션에 매우 적합하다. 대표적인 예로 실시간 영상 스트리밍, 온라인 게임, VoIP(인터넷 전화), 그리고 DNS 조회가 있다.3 이러한 애플리케이션들은 필요한 오류 처리나 순서 재조립을 애플리케이션 계층에서 직접 구현하거나, 약간의 데이터 손실을 감수하는 방식으로 동작한다.

네트워크 애플리케이션을 개발할 때 TCP와 UDP 중 어떤 프로토콜을 선택할지는 애플리케이션의 성패를 좌우할 수 있는 중요한 설계 결정이다. 두 프로토콜의 차이점은 단순한 기능의 유무를 넘어, 신뢰성과 성능 사이의 근본적인 트레이드오프를 나타낸다.

기능	TCP (Transmission Control Protocol)	UDP (User Datagram Protocol)
연결 모델	연결 지향형 (Connection-Oriented)	비연결형 (Connectionless)
신뢰성	높음 (ACK, 재전송을 통해 순서, 무결성 보장)	낮음 (최선형 전달, ‘fire and forget’)
순서 보장	보장됨 (Sequence Number 사용)	보장되지 않음 (패킷 도착 순서 무관)
흐름 제어	지원 (슬라이딩 윈도우)	지원하지 않음
혼잡 제어	지원 (AIMD, Slow Start 등)	지원하지 않음
헤더 크기	큼 (최소 20 바이트)	작음 (8 바이트)
속도/지연	상대적으로 느림 (핸드셰이크, 제어 오버헤드)	상대적으로 빠름 (오버헤드 없음)
통신 방식	1:1 (Unicast)	1:1, 1:N(Multicast), 1:All(Broadcast) 가능
주요 사용 사례	웹(HTTP), 파일 전송(FTP), 이메일(SMTP) 등 신뢰성이 중요한 서비스	실시간 스트리밍, 온라인 게임, VoIP, DNS 등 속도와 실시간성이 중요한 서비스

표 2: TCP 대 UDP - 기능별 비교. 이 표는 개발자나 설계자가 애플리케이션의 요구사항에 따라 적절한 전송 프로토콜을 선택할 수 있도록 두 프로토콜의 핵심적인 차이점을 명확하게 대비시킨다. 30

이 표는 두 프로토콜이 상호 대체 관계가 아니라, 서로 다른 문제 영역을 해결하기 위해 존재하는 상호 보완적인 도구임을 명확히 보여준다. 신뢰성이 절대적으로 필요한 데이터 전송(예: 파일 다운로드)에 UDP를 사용하는 것은 부적절하며, 매 프레임의 실시간성이 중요한 비디오 스트리밍에 TCP를 사용하는 것은 불필요한 지연을 유발할 수 있다. 따라서 성공적인 네트워크 애플리케이션 설계는 이러한 트레이드오프를 정확히 이해하고, 서비스의 핵심 요구사항에 가장 부합하는 전송 프로토콜을 전략적으로 선택하는 것에서 시작된다.

전송 계층이 종단 간의 논리적 연결을 책임진다면, 그 아래의 네트워크 계층과 데이터 링크 계층은 데이터를 실제로 목적지까지 전달하는 물리적, 논리적 경로를 구축하는 역할을 한다. 이 장에서는 거대한 인터넷을 가로지르는 글로벌 주소 체계인 IP와, 로컬 네트워크 내에서의 최종 전달을 담당하는 MAC 주소의 중요한 역할과 이 둘의 상호작용을 탐구한다.

인터넷 프로토콜(IP)은 TCP/IP 프로토콜 스위트에서 네트워크 경계를 넘어 데이터그램을 중계하는 핵심적인 역할을 수행한다. IP의 주된 기능은 IP 주소를 기반으로 출발지 호스트에서 목적지 호스트까지 패킷을 전달하는 것이다.4

IP는 본질적으로 비연결형(connectionless)이며 최선형(best-effort) 프로토콜이다. 이는 IP가 패킷의 전달, 순서, 데이터 무결성을 보장하지 않는다는 의미다. 만약 패킷이 전송 중에 손실되거나, 순서가 뒤바뀌거나, 오류가 발생하더라도 IP 계층 자체는 이를 해결하려 시도하지 않는다. 이러한 신뢰성 확보의 책임은 상위 계층인 전송 계층(주로 TCP)에 위임된다.20 IP의 역할은 오직 주소를 보고 다음 경로로 패킷을 넘겨주는 우체부와 같다.

IPv4 헤더는 패킷을 올바르게 라우팅하고 처리하는 데 필요한 다양한 정보를 담고 있다.

• Version (버전): 4비트 필드로, IP의 버전을 나타낸다 (예: IPv4는 4, IPv6는 6). 라우터는 이 값을 보고 패킷을 어떻게 처리할지 결정한다.
• Time to Live (TTL): 8비트 필드로, 패킷의 수명을 제한하는 카운터다. 송신자가 설정한 초기값에서 시작하여, 라우터를 하나 거칠 때마다 1씩 감소한다.50 이 필드는 패킷이 네트워크에서 무한히 순환하는 것을 방지하는 결정적인 역할을 한다.
• Protocol (프로토콜): 8비트 필드로, 패킷이 담고 있는 데이터가 어떤 상위 계층 프로토콜에 속하는지를 명시한다. 예를 들어, 값이 6이면 TCP 세그먼트, 17이면 UDP 데이터그램을 의미한다. 수신 호스트는 이 값을 보고 데이터를 올바른 전송 계층 프로토콜로 전달한다.51
• Header Checksum (헤더 체크섬): 16비트 필드로, IP 헤더 자체에 대한 오류 검사를 위해 사용된다. 라우터를 거칠 때마다 TTL 값이 바뀌므로 체크섬도 매번 재계산된다. 데이터 페이로드의 오류는 검사하지 않는다.52
• Source and Destination IP Addresses (출발지 및 목적지 IP 주소): 각각 32비트(IPv4) 또는 128비트(IPv6)의 크기를 가지며, 인터넷상에서 송신 호스트와 수신 호스트를 고유하게 식별하는 논리적 주소다.

라우팅 루프는 라우팅 테이블 설정 오류 등으로 인해 패킷이 특정 라우터들 사이를 무한정 맴돌며 목적지에 도달하지 못하는 현상이다. 이러한 패킷들은 네트워크 자원을 계속해서 소모하여 심각한 성능 저하를 유발한다.

TTL 필드는 이 문제를 해결하는 간단하면서도 효과적인 메커니즘이다. 패킷이 라우터를 통과할 때마다 라우터는 TTL 값을 1씩 감소시킨다.50 만약 패킷이 루프에 빠져 계속 순환하다가 TTL 값이 0이 되면, 해당 패킷을 수신한 라우터는 패킷을 즉시 폐기한다. 그리고 일반적으로 ICMP(Internet Control Message Protocol) “Time Exceeded” 메시지를 원래의 송신자에게 보내, 경로에 문제가 있음을 알린다.51 이 메커니즘 덕분에 패킷이 네트워크상에서 영원히 떠도는 것을 방지하여 네트워크의 안정성을 유지할 수 있다.

패킷이 인터넷을 통해 성공적으로 전달되기 위해서는 논리적 주소인 IP 주소와 물리적 주소인 MAC 주소, 두 가지 주소 체계가 유기적으로 협력해야 한다. 이 둘의 역할 분담을 이해하는 것은 네트워크의 계층적 동작 원리를 파악하는 데 핵심적이다.

• IP 주소 (Layer 3): 네트워크 계층에서 사용되는 논리적 주소로, 인터넷 전체에서 종단 간 라우팅을 위해 사용된다. 사용자가 어느 네트워크에 접속하느냐에 따라 변경될 수 있는 주소다. 이는 우리가 이사하면 주소가 바뀌는 것과 같다.54
• MAC 주소 (Layer 2): 데이터 링크 계층에서 사용되는 물리적 주소로, 네트워크 인터페이스 카드(NIC)에 하드웨어적으로 고유하게 부여된 주소다. 이 주소는 동일한 로컬 네트워크(LAN) 내에서 장치 간 통신에 사용되며, 일반적으로 변경되지 않는다.54

이 두 주소는 각각 ‘전 세계적인 배송 주소(우편번호와 상세 주소)’와 ‘아파트 내의 특정 호수’에 비유할 수 있다. IP 주소는 패킷을 올바른 도시의 올바른 동네(네트워크)까지 도달하게 하고, MAC 주소는 그 동네 안에서 정확한 집(장치)으로 최종 배달하는 역할을 한다. 성공적인 배송을 위해서는 둘 다 필수적이다.55

송신 호스트가 다른 네트워크에 있는 목적지 호스트로 패킷을 보낼 때, IP 헤더에 있는 출발지 및 목적지 IP 주소는 여행 내내 변하지 않는다. 이들은 최종 출발지와 최종 목적지를 가리키기 때문이다.58

하지만 이 IP 패킷을 감싸고 있는 2계층 이더넷 프레임의 헤더에 있는 MAC 주소는 각 홉(hop)을 지날 때마다 계속해서 바뀐다. 프레임 헤더의 출발지 및 목적지 MAC 주소는 현재 노드에서 ‘다음 홉’ 노드까지만을 가리킨다.

과정은 다음과 같다:

1. 송신 호스트는 라우터(게이트웨이)로 패킷을 보내기 위해 프레임을 만든다. 이때 출발지 MAC은 자신의 MAC, 목적지 MAC은 라우터의 MAC 주소다.
2. 라우터는 프레임을 수신하여 역캡슐화하고 IP 패킷을 확인한다. 라우팅 테이블을 참조하여 다음 홉으로 보낼 경로를 결정한다.
3. 라우터는 IP 패킷을 새로운 프레임으로 다시 캡슐화한다. 이때 출발지 MAC은 현재 라우터 자신의 MAC 주소, 목적지 MAC은 다음 홉 라우터의 MAC 주소가 된다.
4. 이 과정은 패킷이 최종 목적지 네트워크에 도달할 때까지 모든 라우터에서 반복된다.26

이처럼 IP 주소는 종단 간의 여정을 안내하는 ‘여행 계획서’ 역할을 하고, MAC 주소는 각 구간을 이동하기 위한 ‘구간별 탑승권’ 역할을 한다. 이러한 역할 분리는 인터넷이 수많은 개별 네트워크의 집합체임에도 불구하고 확장성을 유지할 수 있는 핵심 원리다.

로컬 네트워크 내에서 특정 IP 주소를 가진 장치에 패킷을 보내려면 그 장치의 MAC 주소를 알아야만 프레임을 만들 수 있다. 이때 IP 주소(논리적 주소)를 MAC 주소(물리적 주소)로 변환해주는 프로토콜이 바로 주소 결정 프로토콜(ARP, Address Resolution Protocol)이다.55

호스트 A가 동일 네트워크상의 호스트 B(IP 주소는 알고 있음)에게 데이터를 보내려 하지만 B의 MAC 주소를 모를 경우, 다음과 같이 동작한다:

1. 호스트 A는 로컬 네트워크 전체에 “IP 주소 192.168.1.100을 가진 분, 당신의 MAC 주소는 무엇입니까?”라는 내용의 ARP 요청(ARP Request) 패킷을 브로드캐스트(broadcast)한다.55
2. 네트워크상의 모든 장치가 이 요청을 받지만, 오직 IP 주소 192.168.1.100을 가진 호스트 B만이 응답한다.
3. 호스트 B는 “그 IP 주소는 제 것입니다. 제 MAC 주소는 00-1A-2B-3C-4D-5E입니다”라는 내용의 ARP 응답(ARP Reply) 패킷을 호스트 A에게 유니캐스트(unicast)로 보낸다.
4. 호스트 A는 B의 MAC 주소를 획득하여 자신의 ARP 캐시 테이블에 저장해두고, 이 정보를 사용하여 B에게 보낼 이더넷 프레임을 완성하여 전송한다.64

이처럼 ARP는 3계층의 논리적 주소와 2계층의 물리적 주소 사이의 간극을 메워, IP 패킷이 최종적으로 올바른 물리적 장치에 전달될 수 있도록 하는 필수적인 가교 역할을 수행한다.

응용 계층은 사용자와 애플리케이션이 네트워크와 가장 직접적으로 상호작용하는 최상위 계층이다. 이 계층의 프로토콜들은 사용자의 요구를 네트워크 요청으로 변환하고, 네트워크로부터 받은 응답을 사용자가 이해할 수 있는 형태로 가공하여 제시하는 역할을 담당한다. 웹 브라우징부터 파일 전송, 이메일에 이르기까지 우리가 일상적으로 사용하는 대부분의 인터넷 서비스가 이 계층의 프로토콜 위에서 동작한다.

하이퍼텍스트 전송 프로토콜(HTTP)은 월드 와이드 웹(WWW)에서 데이터를 주고받기 위한 근간이 되는 프로토콜이다.65 HTTP는 클라이언트(예: 웹 브라우저)가 서버에 요청(Request)을 보내면, 서버가 그 요청을 처리하여 응답(Response)을 반환하는 클라이언트-서버, 요청-응답 모델을 따른다.5

• 무상태성 (Statelessness): HTTP의 가장 중요한 특징 중 하나는 ‘무상태’라는 점이다. 서버는 클라이언트의 각 요청을 완전히 독립적인 트랜잭션으로 취급하며, 이전 요청에 대한 어떠한 정보도 기억하지 않는다. 이러한 특성은 서버 설계를 단순화하고 부하 분산을 용이하게 하여 높은 확장성을 제공하는 장점이 있다.12 하지만 로그-인 상태 유지와 같이 상태 정보가 필요한 경우에는 쿠키(Cookie)나 세션(Session)과 같은 별도의 기술을 사용하여 상태를 애플리케이션 수준에서 관리해야 한다.65
• 연결 방식의 진화:
  • HTTP/1.0 (비연결성, Connectionless): 초기 버전의 HTTP는 요청 하나를 처리할 때마다 새로운 TCP 연결을 맺고 응답 후에는 바로 연결을 끊는 방식을 사용했다. 이는 TCP 3-way handshake의 오버헤드가 매번 발생하여 비효율적이었다.12
  • HTTP/1.1 (지속적 연결, Persistent Connections): 이 문제를 해결하기 위해 keep-alive 기능이 도입되었다. 이를 통해 하나의 TCP 연결을 재사용하여 여러 개의 요청과 응답을 주고받을 수 있게 되어, 웹 페이지 로딩 속도가 획기적으로 개선되었다.12
• 메시지 구조:
  • 요청 메시지 (Request Message): 요청의 종류를 나타내는 ‘요청 라인’(예: GET /index.html HTTP/1.1), 요청에 대한 추가 정보를 담은 ‘헤더’(예: Host: www.example.com, User-Agent: Chrome), 그리고 데이터를 서버로 전송할 때 사용하는 ‘메시지 본문’(예: POST 요청의 폼 데이터)으로 구성된다.67
  • 응답 메시지 (Response Message): 요청의 성공 여부를 나타내는 ‘상태 라인’(예: HTTP/1.1 200 OK), 응답 데이터에 대한 정보를 담은 ‘헤더’(예: Content-Type: text/html, Content-Length: 1234), 그리고 실제 요청된 자원인 ‘메시지 본문’(예: HTML 문서)으로 구성된다.65

HTTP는 이후 HTTP/2에서 다중화(Multiplexing)와 헤더 압축을 도입하고, HTTP/3에서는 전송 계층 자체를 TCP에서 QUIC으로 전환하는 등, 현대 웹의 복잡하고 동적인 요구사항을 충족시키기 위해 끊임없이 진화하고 있다.12

파일 전송 프로토콜(FTP)은 TCP 기반 네트워크에서 클라이언트와 서버 간에 컴퓨터 파일을 전송하기 위해 사용되는 표준 프로토콜이다.5 FTP의 독특한 특징은 두 개의 별도 TCP 연결을 사용한다는 점이다.

• 제어 연결 (Control Connection): 일반적으로 서버의 21번 포트를 사용하며, USER, PASS, LIST와 같은 명령어를 전송하고 서버의 응답을 수신하는 데 사용된다. 이 연결은 FTP 세션 동안 계속 유지된다.
• 데이터 연결 (Data Connection): 실제 파일 내용이나 디렉터리 목록을 전송하기 위해 사용된다. 이 연결은 데이터 전송이 필요할 때마다 새로 생성되고 전송이 끝나면 닫힌다.

데이터 연결을 설정하는 방식에 따라 FTP는 두 가지 모드로 동작한다.

• Active Mode (능동 모드):

  1. 클라이언트가 임의의 포트(N)에서 서버의 21번 포트로 제어 연결을 시작한다.

  2. 데이터 전송이 필요할 때(예: LIST 명령), 클라이언트는 PORT N+1 명령을 통해 자신이 데이터 수신을 위해 사용할 포트(N+1)를 서버에 알린다.

  3. 서버가 자신의 데이터 포트(일반적으로 20번)에서 클라이언트가 알려준 포트(N+1)로 새로운 TCP 연결을 시작한다.70

     이 방식은 클라이언트 측 방화벽이 외부로부터의 새로운 연결 요청을 차단하는 경우가 많아 현대 네트워크 환경에서는 잘 작동하지 않을 수 있다.71

• Passive Mode (수동 모드, PASV):

  1. 클라이언트가 임의의 포트에서 서버의 21번 포트로 제어 연결을 시작한다.

  2. 데이터 전송이 필요할 때, 클라이언트는 PASV 명령을 서버에 보낸다.

  3. 서버는 응답으로 자신이 데이터 전송을 위해 열어 둔 임의의 포트 번호(P)를 클라이언트에게 알려준다.

  4. 클라이언트가 자신의 임의의 포트에서 서버가 알려준 포트(P)로 데이터 연결을 시작한다.70

     이 방식은 클라이언트가 항상 외부로 나가는 연결을 시작하기 때문에 방화벽이나 NAT 환경에서 훨씬 더 안정적으로 동작한다.73

이메일 시스템은 하나의 프로토콜이 아닌, 각각 다른 역할을 하는 여러 프로토콜의 조합으로 작동한다. 핵심은 메일을 ‘보내는’ 역할과 ‘받는’ 역할이 분리되어 있다는 점이다.

• SMTP (Simple Mail Transfer Protocol): 이메일을 보내는(push) 데 사용되는 프로토콜이다. 사용자의 이메일 클라이언트(예: 아웃룩, G메일 앱)가 작성한 메일을 자신의 발신 메일 서버로 전송할 때, 그리고 인터넷상의 메일 서버들끼리 메일을 주고받을 때 SMTP가 사용된다. TCP 25번 포트를 주로 사용한다.74 비유하자면, SMTP는 편지를 우체통에 넣고 우체국에서 다른 우체국으로 배송하는 우편 시스템 전체에 해당한다.77
• POP3 (Post Office Protocol 3): 이메일을 수신(pull)하는 프로토콜 중 하나다. 메일 서버에 도착한 이메일을 사용자의 로컬 컴퓨터로 다운로드하는 역할을 한다. 기본 설정상, 이메일을 다운로드하면 서버에서는 해당 메일이 삭제된다. 이 때문에 여러 기기에서 동일한 메일함을 동기화하여 보기가 어렵다. 과거 서버 저장 공간이 부족하던 시절에 주로 사용되었다.74 이는 우체국에 도착한 편지를 집으로 가져와서 보는 것과 같아서, 일단 가져오면 우체국에는 더 이상 편지가 남아있지 않다.
• IMAP (Internet Message Access Protocol): 이메일을 접근(access)하는 현대적인 프로토콜이다. POP3와 달리 이메일을 서버에 그대로 남겨두고, 읽음/안읽음 상태, 폴더 구조 등 모든 정보를 서버와 동기화한다. 이 덕분에 사용자는 스마트폰, 노트북, 웹메일 등 여러 기기에서 항상 동일한 상태의 메일함을 볼 수 있다. 서버에 직접 접속하여 메일을 확인하는 방식이므로, 인터넷 연결이 필수적이다.74 이는 우체국 사서함에 있는 편지를 필요할 때마다 가서 확인하는 것과 같다. 편지는 계속 사서함에 보관되어 있다.

이처럼 응용 계층 프로토콜들은 하위 전송 계층의 능력과 한계를 기반으로 설계된다. FTP가 두 개의 연결을 사용하는 복잡한 구조를 갖게 된 것은 단일 TCP 연결로는 제어와 데이터 전송을 동시에 처리하기 어렵다는 한계를 극복하기 위한 시도였다. HTTP가 무상태로 설계된 것은 확장성을 우선시한 결과지만, 이는 결국 쿠키와 세션이라는 새로운 복잡성을 낳았다. 이메일 프로토콜이 송수신 기능으로 분리된 것 또한, 상시 작동하는 서버 간 통신과 간헐적으로 접속하는 클라이언트의 통신이라는 서로 다른 요구사항을 해결하기 위한 합리적인 설계였다. 결국 응용 계층 프로토콜의 아키텍처는 TCP와 UDP가 제공하는 비교적 단순한 프리미티브 위에서 어떻게 정교한 애플리케이션을 구축할 것인가에 대한 개발자들의 창의적인 해답의 역사라 할 수 있다.

TCP/IP 계층	프로토콜 이름	약어	주요 기능	사용 전송 프로토콜
응용	Hypertext Transfer Protocol	HTTP	웹 페이지 및 데이터 전송	TCP
	File Transfer Protocol	FTP	파일 전송	TCP
	Simple Mail Transfer Protocol	SMTP	이메일 송신	TCP
	Post Office Protocol 3	POP3	이메일 수신 (다운로드)	TCP
	Internet Message Access Protocol	IMAP	이메일 수신 (동기화)	TCP
	Domain Name System	DNS	도메인 이름을 IP 주소로 변환	UDP (주로), TCP
전송	Transmission Control Protocol	TCP	신뢰성 있는 연결 지향형 데이터 전송	해당 없음
	User Datagram Protocol	UDP	비신뢰성 비연결형 데이터 전송	해당 없음
인터넷	Internet Protocol	IP	논리적 주소 지정 및 라우팅	해당 없음
	Internet Control Message Protocol	ICMP	네트워크 오류 및 상태 보고	IP
	Address Resolution Protocol	ARP	IP 주소를 MAC 주소로 변환	해당 없음
네트워크 접속	Ethernet	-	유선 LAN 통신 표준	해당 없음
	Wi-Fi (IEEE 802.11)	-	무선 LAN 통신 표준	해당 없음

표 3: 주요 인터넷 프로토콜 계층별 분류. 이 표는 본 보고서 2부에서 논의된 핵심 프로토콜들을 실용적인 TCP/IP 모델에 맞춰 정리한 것이다. 각 프로토콜의 위치, 기능, 그리고 의존하는 전송 프로토콜을 명시하여 인터넷 아키텍처에 대한 구조적 이해를 돕는다. 18

인터넷의 범용 핵심 프로토콜을 넘어, 제3부에서는 특정하고 까다로운 환경에 맞춰 설계된 특수 프로토콜들을 탐구한다. 안전한 통신을 위한 암호화 프로토콜, 자원이 제한된 사물 인터넷(IoT) 환경, 극도의 저지연성을 요구하는 고성능 컴퓨팅(HPC), 그리고 마이크로초 단위의 속도가 중요한 금융 시장에 이르기까지, 각 도메인의 고유한 요구사항이 어떻게 새로운 프로토콜의 탄생을 이끌었는지 분석한다.

초기 인터넷은 신뢰를 기반으로 설계되었으나, 그 중요성이 커지면서 보안은 필수적인 요소가 되었다. 이 장에서는 데이터의 기밀성과 무결성을 보장하는 프로토콜과, 인터넷의 경로 정보를 보호하는 메커니즘을 상세히 다룬다. 전송 중인 데이터를 암호화하는 TLS부터 라우팅 인프라 자체를 보호하는 기술까지, 안전한 인터넷을 구축하기 위한 핵심적인 보안 프로토콜들을 분석한다.

SSL(Secure Sockets Layer)과 그 후속 기술인 TLS(Transport Layer Security)는 컴퓨터 네트워크를 통해 통신 보안을 제공하기 위해 설계된 암호화 프로토콜이다.78 이 프로토콜들은 일반적으로 응용 계층과 전송 계층 사이에서 동작하며, HTTP와 같은 응용 계층 프로토콜이 보내는 데이터를 암호화하여 TCP를 통해 전송한다(HTTPS가 대표적인 예). TLS는 세 가지 핵심적인 보안 기능을 제공한다.

• 암호화 (Encryption): 통신하는 양측이 공유하는 대칭키를 사용하여 데이터를 암호화함으로써, 중간에서 데이터를 가로채더라도 그 내용을 알 수 없도록 하여 기밀성(confidentiality)을 보장한다.78
• 인증 (Authentication): 공개키 기반의 디지털 인증서를 사용하여 통신 상대방의 신원을 확인한다. 일반적으로 클라이언트는 서버의 인증서를 검증하여 자신이 접속하려는 서버가 진짜인지 확인하며, 이를 통해 중간자 공격(Man-in-the-Middle attack)을 방지한다.79
• 무결성 (Integrity): 메시지 인증 코드(MAC)를 사용하여 전송 중 데이터가 위변조되지 않았음을 보장한다. 수신 측은 수신한 데이터와 MAC 값을 비교하여 데이터의 변경 여부를 탐지할 수 있다.78

TLS 세션이 시작될 때, 실제 데이터를 교환하기 전에 클라이언트와 서버는 ‘핸드셰이크(handshake)’라는 협상 과정을 거친다. 이 과정의 목표는 사용할 암호화 알고리즘을 합의하고, 서버를 인증하며, 데이터를 암호화하는 데 사용할 공유 비밀키(세션 키)를 안전하게 생성하는 것이다.81 TLS 1.2의 핸드셰이크 과정은 다음과 같다.

1. ClientHello: 클라이언트가 서버에 연결을 시작하며 ClientHello 메시지를 보낸다. 이 메시지에는 클라이언트가 지원하는 TLS 버전, 암호화 알고리즘 목록(Cipher Suites), 그리고 나중에 세션 키 생성에 사용될 무작위 바이트 문자열(Client Random)이 포함된다.80
2. ServerHello: 서버는 클라이언트의 ClientHello에 응답하여 ServerHello 메시지를 보낸다. 여기에는 클라이언트가 제시한 목록 중에서 서버가 선택한 TLS 버전과 암호화 스위트, 그리고 서버가 생성한 무작위 바이트 문자열(Server Random)이 포함된다.81
3. Certificate: 서버는 자신의 신원을 증명하기 위해 공개키가 포함된 디지털 인증서를 클라이언트에게 보낸다. 클라이언트는 이 인증서가 신뢰할 수 있는 인증 기관(CA, Certificate Authority)에 의해 발급되었는지, 유효 기간이 남았는지 등을 검증한다.79
4. ServerKeyExchange (선택 사항): 선택된 암호화 스위트가 디피-헬만(Diffie-Hellman)과 같은 키 교환 알고리즘을 사용하는 경우, 서버는 세션 키 생성을 위한 추가적인 공개키 정보를 이 메시지에 담아 보낸다.83
5. ServerHelloDone: 서버가 핸드셰이크의 초기 협상 부분을 마쳤음을 클라이언트에게 알린다.83
6. ClientKeyExchange: 클라이언트는 세션 키의 기반이 될 ‘pre-master secret’이라는 무작위 데이터를 생성한다. 그리고 서버의 인증서에서 얻은 공개키를 사용하여 이 pre-master secret을 암호화한 후 서버에게 전송한다. 이로써 오직 해당 서버의 개인키를 가진 서버만이 이 값을 복호화할 수 있다.81
7. 키 생성: 이제 클라이언트와 서버는 각자 가지고 있는 세 가지 정보, 즉 Client Random, Server Random, 그리고 pre-master secret을 조합하여 동일한 ‘master secret’을 계산해낸다. 이 master secret으로부터 실제 데이터 암호화에 사용될 대칭 세션 키가 파생된다.83
8. ChangeCipherSpec & Finished: 양측은 이제부터 암호화된 통신을 시작하겠다는 의미로 ChangeCipherSpec 메시지를 교환한다. 그 직후, 지금까지의 핸드셰이크 과정 전체의 해시값을 담은 Finished 메시지를 암호화하여 서로에게 보낸다. 상대방이 이 메시지를 성공적으로 복호화하고 해시값을 검증하면, 핸드셰이크 과정이 중간자 공격 없이 안전하게 완료되었음을 최종적으로 확인하게 된다.78

TLS 1.3은 이전 버전에 비해 속도와 보안 양면에서 상당한 개선을 이루었다.

• 속도 향상: TLS 1.3은 핸드셰이크 과정을 대폭 간소화했다. 새로운 연결을 설정하는 데 필요한 왕복 시간(RTT, Round-Trip Time)을 TLS 1.2의 2-RTT에서 1-RTT로 줄였다. 또한, 이전에 접속했던 서버에 다시 연결할 때는 0-RTT 핸드셰이크를 지원하여 거의 즉각적인 연결 재개가 가능하다. 이는 웹 페이지 로딩 시간을 크게 단축시키는 효과를 가져온다.85
• 보안 강화:
  • 취약한 암호화 제거: RC4, SHA-1과 같은 오래되고 취약점이 발견된 암호화 알고리즘과 디피-헬만 그룹을 프로토콜에서 완전히 제거하여, 잘못된 설정으로 인한 보안 위험을 원천적으로 차단했다.86
  • 핸드셰이크 암호화 확대: TLS 1.2에서는 서버 인증서 같은 정보가 평문으로 전송되었으나, TLS 1.3에서는 핸드셰이크의 더 많은 부분을 암호화하여 사용자의 프라이버시를 강화했다.87
  • 완전 순방향 비밀성(Perfect Forward Secrecy, PFS) 의무화: PFS는 서버의 장기 개인키가 유출되더라도 과거의 통신 내용은 해독할 수 없도록 보장하는 특성이다. TLS 1.3은 PFS를 제공하는 키 교환 방식(예: ECDHE)만을 사용하도록 강제하여 보안 수준을 한층 높였다.88

TLS의 역사에는 프로토콜 자체의 결함보다는 구현상의 오류나 구버전의 취약점을 이용한 공격들이 중요한 교훈을 남겼다.

• Heartbleed (2014): OpenSSL 암호화 라이브러리의 TLS ‘Heartbeat’ 확장 기능 구현에 존재했던 심각한 버그다. 공격자는 이 취약점을 이용해 서버 메모리의 내용을 임의로 읽어 들일 수 있었고, 이를 통해 서버의 개인키, 사용자 비밀번호, 세션 쿠키 등 치명적인 정보가 유출될 수 있었다.89 이는 프로토콜 설계 자체의 문제가 아니라, 특정 소프트웨어의 구현 오류가 얼마나 큰 파장을 일으킬 수 있는지를 보여준 사례다.
• POODLE (2014): ‘Padding Oracle On Downgraded Legacy Encryption’의 약자로, 오래된 SSL 3.0 프로토콜의 취약점을 이용한 공격이다. 공격자는 중간자 위치에서 클라이언트와 서버 간의 협상 과정에 개입하여, 최신 TLS 버전 대신 보안이 취약한 SSL 3.0으로 연결을 ‘다운그레이드’하도록 유도한다. 일단 SSL 3.0으로 연결되면, 패딩 오라클 공격 기법을 통해 암호화된 데이터(예: HTTP 쿠키)의 내용을 바이트 단위로 추측해낼 수 있다.89 이 공격에 대한 근본적인 해결책은 서버와 클라이언트 양쪽에서 SSL 3.0 지원을 완전히 비활성화하는 것이다.

이러한 사건들은 인터넷 보안이 정적인 상태가 아니라, 끊임없이 새로운 위협이 발견되고 그에 대응하여 프로토콜과 구현이 발전해나가는 역동적인 과정임을 보여준다. TLS 1.3이 구식 암호화 방식을 대거 제거한 것은 바로 이러한 과거의 공격들로부터 얻은 교훈을 반영한 결과다.

인터넷의 경로 정보를 교환하는 BGP(Border Gateway Protocol)는 근본적으로 신뢰에 기반하여 설계되었기 때문에, 경로 정보를 위조하는 ‘BGP 하이재킹’ 공격에 취약하다.93 BGP 하이재킹은 공격자가 자신이 소유하지 않은 IP 주소 대역을 자신의 AS(자율 시스템)에서 기원한 것처럼 허위로 광고하여, 해당 IP로 향하는 트래픽을 자신에게로 유인하는 공격이다. 이는 데이터 탈취, 서비스 중단 등 심각한 피해를 유발할 수 있다. 이러한 위협에 대응하기 위해 다음과 같은 보안 기술들이 개발되었다.

• RPKI (Resource Public Key Infrastructure): IP 주소 소유권을 암호학적으로 증명하는 시스템이다. IP 주소 할당 기관(RIR)은 IP 주소 블록의 소유자에게 해당 주소를 광고할 권한이 있음을 증명하는 디지털 인증서(ROA, Route Origin Authorization)를 발급한다. 라우터는 BGP 경로 정보를 수신했을 때, RPKI 데이터를 참조하여 해당 경로 광고가 IP 주소의 정당한 소유자로부터 온 것인지 검증(Origin Validation)할 수 있다. 이를 통해 악의적인 AS가 다른 AS의 IP 주소를 광고하는 것을 막을 수 있다.94
• BGPsec: RPKI가 경로의 ‘기원(Origin)’을 검증한다면, BGPsec은 경로의 ‘경로(Path)’ 자체를 보호하는 BGP의 보안 확장이다. BGPsec을 사용하면 경로상의 모든 AS는 다음 AS로 경로 정보를 전달할 때마다 자신의 서명을 추가한다. 수신 측은 이 서명들을 검증함으로써, AS 경로 정보가 중간에 위조되거나 삭제되지 않았음을 확인할 수 있다. 이는 경로 하이재킹을 방지하는 더 강력한 보안을 제공하지만, 모든 경유 라우터의 지원과 상당한 계산 오버헤드를 요구하여 아직 널리 보급되지는 않았다.95
• RTR (RPKI-to-Router) Protocol: 라우터가 RPKI 검증을 수행하기 위해서는 신뢰할 수 있는 RPKI 캐시(검증기)로부터 최신의 유효성 검증 데이터를 받아야 한다. RTR 프로토콜은 이 캐시와 라우터 간에 검증 데이터를 안전하고 효율적으로 동기화하기 위해 사용되는 프로토콜이다.94

범용 인터넷 프로토콜이 모든 환경에 최적인 것은 아니다. 극심한 자원 제약을 가진 사물 인터넷(IoT) 장치나, 나노초 수준의 지연 시간에도 민감한 슈퍼컴퓨터 클러스터와 같은 특수 환경은 그에 맞는 최적화된 프로토콜을 필요로 한다. 이 장에서는 이러한 특수 도메인을 위해 탄생한 프로토콜들을 살펴본다.

IoT 장치들은 배터리로 동작하고, 처리 능력과 메모리가 매우 제한적이며, 불안정하거나 대역폭이 낮은 네트워크를 사용하는 경우가 많다. 이러한 환경에서 HTTP나 TCP와 같은 전통적인 프로토콜은 너무 무겁고 비효율적일 수 있다.96 따라서 IoT 환경을 위해 특별히 설계된 경량 프로토콜들이 부상했다.

MQTT(Message Queuing Telemetry Transport)는 M2M(Machine-to-Machine) 및 IoT 통신을 위해 설계된 대표적인 경량 메시징 프로토콜이다. TCP 기반으로 동작하여 기본적인 신뢰성을 확보한다.96

• 발행-구독(Publish-Subscribe) 아키텍처: MQTT의 가장 큰 특징은 클라이언트-서버 모델이 아닌 발행-구독 모델을 사용한다는 점이다. 이 모델은 메시지를 보내는 측(Publisher)과 받는 측(Subscriber)을 완전히 분리(decouple)시킨다.

  • 발행자(Publisher): 특정 ‘토픽(Topic)’에 대한 메시지를 생성하여 중앙의 브로커(Broker)에게 보낸다. 토픽은 /home/living_room/temperature와 같이 계층적인 구조를 가질 수 있다.

  • 구독자(Subscriber): 자신이 관심 있는 토픽을 브로커에게 등록(구독)한다.

  • 브로커(Broker): 발행자로부터 메시지를 받아, 해당 토픽을 구독하고 있는 모든 구독자에게 메시지를 전달하는 중개자 역할을 한다. 브로커는 클라이언트 인증, 세션 관리 등 중앙 허브의 역할을 수행한다.99

    이 구조 덕분에 발행자와 구독자는 서로의 존재나 IP 주소를 알 필요가 없으며, 동시에 온라인 상태가 아니어도 통신이 가능하다(시간적 분리).

• 주요 특징:

  • 경량성: 메시지 헤더가 매우 작아(최소 2바이트) 네트워크 오버헤드가 적다.101
  • 서비스 품질(QoS, Quality of Service): 메시지 전달의 신뢰성 수준을 3단계로 선택할 수 있다.
    • QoS 0 (At most once): 최대 한 번 전송. 메시지를 보내기만 하고 전달 여부는 확인하지 않는다. 가장 빠르지만 메시지 유실 가능성이 있다.
    • QoS 1 (At least once): 최소 한 번 전송. 수신 확인(ACK)을 받을 때까지 재전송하여 최소 한 번의 전달을 보장한다. 메시지 중복 가능성이 있다.
    • QoS 2 (Exactly once): 정확히 한 번 전송. 4단계 핸드셰이킹을 통해 메시지가 정확히 한 번만 전달되도록 보장한다. 가장 신뢰성이 높지만 오버헤드가 크다.100
  • 보안: 전송 계층에서 TLS를 사용하여 통신을 암호화하고 클라이언트와 브로커를 인증할 수 있다.96

CoAP(Constrained Application Protocol)는 MQTT보다 더 극심한 제약 환경(예: 수십 KB의 메모리)에 있는 장치들을 위해 설계된 프로토콜이다. 오버헤드를 최소화하기 위해 UDP 위에서 동작한다.97

• RESTful 모델: CoAP는 HTTP와 유사한 요청/응답 모델과 GET, POST, PUT, DELETE와 같은 메서드를 사용한다. 이 덕분에 HTTP 프록시를 통해 기존 웹 인프라와 쉽게 연동할 수 있는 장점이 있다.105
• 주요 특징:
  • 비동기 메시지 교환: UDP 기반이므로 비동기 통신에 적합하다.
  • 경량 헤더: 헤더 크기가 작아 오버헤드가 매우 낮다.
  • 신뢰성 지원: 비신뢰적인 UDP 위에서 최소한의 신뢰성을 제공하기 위해 ‘확인형(Confirmable)’ 메시지와 ‘비확인형(Non-confirmable)’ 메시지를 구분하여 사용한다. 확인형 메시지는 수신 확인(ACK)을 요구한다.105
  • 리소스 탐색: 내장된 리소스 탐색 기능을 통해 클라이언트가 서버가 제공하는 리소스 목록을 질의할 수 있다.
  • 보안: UDP를 위한 TLS인 DTLS(Datagram Transport Layer Security)를 사용하여 통신을 보호한다.97

과학 연구, 인공지능 모델 훈련, 금융 시뮬레이션 등에 사용되는 고성능 컴퓨팅(HPC) 환경에서는 수많은 계산 노드와 스토리지 시스템 간에 방대한 양의 데이터를 극도로 빠른 속도와 낮은 지연 시간으로 교환해야 한다.106

• 인피니밴드(InfiniBand): 전통적인 이더넷 기반이 아닌, 고성능 컴퓨팅을 위해 설계된 스위치 패브릭(switched fabric) 상호 연결 표준이다. 이더넷에 비해 월등히 높은 대역폭(최신 HDR은 200Gbps, NDR은 400Gbps)과 마이크로초 이하의 매우 낮은 지연 시간을 제공한다.106

• RDMA (Remote Direct Memory Access): 인피니밴드의 핵심 기술로, 한 컴퓨터의 네트워크 어댑터가 상대방 컴퓨터의 메모리에 CPU나 운영체제(OS) 커널의 개입 없이 직접 접근할 수 있게 해주는 기술이다.106

  • 제로 카피(Zero-Copy): 전통적인 TCP/IP 통신에서는 애플리케이션 버퍼의 데이터가 커널 버퍼로, 다시 NIC 버퍼로 여러 번 복사되는 과정에서 상당한 지연이 발생한다. RDMA는 이러한 데이터 복사 과정을 완전히 제거하고, 한쪽 메모리에서 다른 쪽 메모리로 데이터를 직접 전송한다.

  • 커널 우회(Kernel Bypass): 데이터 전송 경로에서 OS 커널을 배제함으로써, 커널 스택 처리로 인한 오버헤드를 없애고 지연 시간을 획기적으로 줄인다.

    이러한 특징 덕분에 RDMA는 CPU 자원을 데이터 전송이 아닌 실제 계산에 집중시킬 수 있게 하여, 분산 AI 훈련과 같이 데이터 통신이 병목이 되는 애플리케이션의 성능을 극대화하는 데 필수적인 기술로 자리 잡았다.109 (RDMA는 RoCE(RDMA over Converged Ethernet) 프로토콜을 통해 일반 이더넷 환경에서도 사용할 수 있다.)

고빈도 매매(HFT)는 복잡한 알고리즘을 사용하여 마이크로초(백만분의 1초) 또는 나노초(십억분의 1초) 단위로 대량의 금융 상품 주문을 자동으로 실행하여, 아주 작은 시장 가격 변동에서 이익을 창출하는 거래 방식이다.111

• FIX (Financial Information eXchange): HFT 자체는 거래 전략이지만, 이 전략을 실행하기 위한 통신 언어로는 FIX 프로토콜이 널리 사용된다. FIX는 주식, 파생상품 등의 거래 주문, 체결 보고, 시장 데이터 등을 교환하기 위해 형식을 표준화한 응용 계층 메시징 프로토콜이다.114

FIX가 메시지의 ‘내용(의미)’을 정의한다면, HFT의 성공은 그 메시지를 얼마나 빨리 전달하느냐에 달려 있다. 이를 위해 HFT 기업들은 극단적인 저지연 인프라를 구축한다. 거래소의 데이터 센터 바로 옆에 서버를 배치하는 ‘코로케이션(co-location)’을 통해 물리적 전파 지연을 최소화하고, 전용 광섬유 케이블과 고도로 최적화된 TCP/IP 스택 또는 하드웨어 기반 전용 프로토콜을 사용하여 통신 지연을 나노초 단위까지 줄이려 경쟁한다.111

이러한 특수 도메인 프로토콜들은 범용 인터넷 프로토콜이 모든 문제에 대한 만병통치약이 아님을 명확히 보여준다. TCP/IP가 제공하는 ‘보편성’은 프로토콜 오버헤드, 커널 처리 지연 등 일종의 ‘세금’을 수반한다. IoT와 HPC, HFT와 같은 극한의 환경에서는 이 ‘세금’이 감당할 수 없는 비용이 된다. 따라서 이들 분야의 프로토콜들은 보편성을 과감히 포기하는 ‘거대한 타협’을 통해 특정 목표(효율성, 속도)에 대한 극단적인 최적화를 이룬다. 이는 인터넷의 핵심 프로토콜이 하나의 타협점임을 보여주며, 문제의 성격이 극단으로 치우칠 때 새로운 프로토콜이 탄생하는 필연적인 과정을 설명한다.

수십 년간 인터넷의 근간을 지탱해 온 아키텍처는 이제 새로운 도전에 직면하고 있다. 제4부에서는 현재 인터넷을 변화시키고 있는 압력들을 검토한다. 기존 아키텍처의 한계를 분석하고, 이를 극복하기 위해 개발 중인 해결책들을 살펴본다. 나아가 양자 영역의 통신부터 기술과 정책의 교차점에 이르기까지, 글로벌 커뮤니케이션의 미래를 형성할 급진적인 새로운 패러다임과 지속적인 과제들을 조망한다.

지난 수십 년간 인터넷의 신뢰성 있는 데이터 전송을 책임져 온 TCP가 현대 웹 애플리케이션 환경에서는 점차 한계를 드러내며 병목 현상의 원인이 되고 있다. 이 장에서는 TCP의 근본적인 한계, 특히 HOL 블로킹 문제를 심도 있게 분석하고, 이를 해결하기 위해 등장한 차세대 전송 프로토콜 QUIC을 탐구한다.

HOL(Head-of-Line) 블로킹은 큐(queue)의 맨 앞에 있는 패킷이 처리되지 못하면 그 뒤의 패킷들이 모두 대기해야 하는 현상을 말한다. 이 문제는 HTTP와 TCP의 상호작용 속에서 여러 단계에 걸쳐 나타났다.

• HTTP/1.1의 HOL 블로킹: HTTP/1.1에서는 하나의 TCP 연결을 통해 요청과 응답이 엄격하게 순차적으로 처리되었다. 클라이언트가 여러 개의 리소스(예: 이미지, CSS 파일)를 요청하면, 첫 번째 요청에 대한 응답이 완료될 때까지 다음 요청은 대기해야 했다. 하나의 느린 응답이 전체 파이프라인을 막는, 명백한 애플리케이션 계층의 HOL 블로킹 문제였다.116 이를 회피하기 위해 브라우저들은 보통 도메인당 6개 정도의 TCP 연결을 동시에 맺는 꼼수를 사용했지만, 이는 연결 유지 비용과 비효율적인 혼잡 제어라는 또 다른 문제를 낳았다.117
• HTTP/2의 다중화와 새로운 HOL 블로킹: HTTP/2는 ‘스트림(Stream)’이라는 개념을 도입하여 이 문제를 해결하고자 했다. 하나의 TCP 연결 내에서 여러 개의 요청과 응답(스트림)을 병렬적으로, 뒤섞어 보낼 수 있게 된 것이다(다중화, Multiplexing). 이로써 하나의 응답이 지연되더라도 다른 스트림의 응답은 전달될 수 있게 되어, 애플리케이션 계층의 HOL 블로킹은 해결되었다.118
• TCP의 HOL 블로킹: 하지만 HTTP/2의 혁신은 전송 계층에 숨어 있던 더 근본적인 문제를 드러냈다. TCP는 스트림이라는 개념을 알지 못한다. TCP에게 모든 데이터는 그저 하나의 순서 있는 바이트 스트림일 뿐이다. 따라서 HTTP/2가 아무리 여러 스트림을 병렬로 보내도, TCP 계층에서는 이들이 하나의 데이터 흐름으로 처리된다. 만약 이 과정에서 TCP 패킷 하나가 유실되면, TCP의 순서 보장 메커니즘 때문에 해당 패킷이 재전송되어 도착할 때까지 TCP 연결 전체가 멈추게 된다. 그 결과, 이미 수신 측 운영체제에 도착한 다른 스트림들의 패킷들조차 애플리케이션으로 전달되지 못하고 대기해야 한다. 이것이 바로 HTTP/2가 해결하지 못한, TCP 계층의 HOL 블로킹이다.117

QUIC(Quick UDP Internet Connections)은 구글이 개발하여 IETF에서 표준화한 새로운 전송 계층 프로토콜로, HTTP/3의 기반이 된다. QUIC은 TCP의 한계를 극복하기 위해 설계되었으며, 그 접근 방식은 혁신적이다.120

• UDP 기반 설계: QUIC은 TCP를 개선하는 대신, 의도적으로 단순하고 기능이 거의 없는 UDP 위에 구축되었다. 이 선택은 두 가지 중요한 전략적 이점을 제공한다. 첫째, 운영체제 커널에 깊숙이 구현되어 수정이 어려운 TCP 스택을 우회하고, 애플리케이션 영역(user-space)에서 프로토콜을 유연하게 구현하고 개선할 수 있게 해준다. 둘째, 인터넷 중간의 수많은 미들박스(middlebox)들이 TCP의 특정 동작을 가정하고 새로운 TCP 옵션 등을 차단하는 ‘프로토콜 경직화(ossification)’ 현상을 회피할 수 있다. UDP 패킷은 단순하여 대부분의 미들박스를 문제없이 통과하기 때문이다.123
• HOL 블로킹 해결: QUIC은 TCP와 달리 스트림 개념을 전송 계층에서 직접 구현한다. 각 스트림은 독립적인 논리적 데이터 흐름으로 취급된다. 따라서 한 스트림에서 패킷 손실이 발생하더라도, 다른 스트림의 데이터 처리는 전혀 영향을 받지 않고 계속 진행될 수 있다. 이는 TCP의 HOL 블로킹 문제를 근본적으로 해결한다.124
• 연결 설정 지연 감소: QUIC은 전송 계층 핸드셰이크와 암호화(TLS 1.3) 핸드셰이크를 통합했다. 이로 인해 새로운 연결을 설정하는 데 단 1-RTT만 소요된다. 이전에 연결했던 서버에 다시 접속할 때는 저장된 정보를 활용하여 핸드셰이크 과정 없이 즉시 데이터를 전송하는 0-RTT 연결 재개가 가능하여, TCP+TLS 조합보다 훨씬 빠른 연결 속도를 제공한다.124
• 연결 마이그레이션(Connection Migration): TCP 연결은 출발지/목적지 IP 주소와 포트 번호의 조합으로 식별된다. 따라서 사용자의 네트워크 환경이 바뀌면(예: Wi-Fi에서 LTE로 전환) IP 주소가 변경되어 기존 TCP 연결은 끊어지고 새로 맺어야 한다. 반면, QUIC 연결은 ‘연결 ID(Connection ID)’라는 고유 식별자로 관리된다. 이 덕분에 클라이언트의 IP 주소가 바뀌더라도 연결 ID만 유지되면 연결이 끊어지지 않고 원활하게 유지될 수 있다. 이는 모바일 환경에서의 사용자 경험을 획기적으로 개선한다.122

QUIC의 등장은 단순한 프로토콜 개선을 넘어선 패러다임의 전환을 의미한다. 이는 수십 년간 인터넷을 지배해 온 TCP의 기술적 한계와, 성숙한 인터넷이 겪는 배포의 어려움(프로토콜 경직화)을 동시에 해결하기 위한 전략적 선택의 결과물이다. 경직된 커널 기반의 TCP를 수정하는 대신, 가장 유연한 UDP라는 토대 위에 신뢰성, 혼잡 제어, 보안 등 필요한 기능들을 새롭게 재구축함으로써, QUIC은 미래 인터넷을 위한 더 빠르고, 더 유연하며, 더 탄력적인 전송 계층의 청사진을 제시하고 있다.

사용자가 인터넷에 접속하는 관문인 접속망(access network) 기술은 끊임없이 진화하고 있다. 특히 무선 기술의 발전은 통신 프로토콜의 혁신을 주도하고 있다. 이 장에서는 Wi-Fi와 5G 셀룰러 네트워크의 최신 프로토콜 혁신을 분석한다. 이 기술들은 제한된 공유 자원인 무선 스펙트럼을 어떻게 더 효율적으로 관리하여, 폭증하는 기기 수와 다양해지는 애플리케이션 요구사항을 만족시키는지에 초점을 맞춘다.

Wi-Fi 기술은 세대를 거듭하며 속도뿐만 아니라, 여러 장치가 동시에 접속하는 환경에서의 효율성을 높이는 방향으로 발전해왔다.

• Wi-Fi 5 (802.11ac)와 OFDM: 이전 세대 Wi-Fi는 OFDM(Orthogonal Frequency-Division Multiplexing) 기술을 사용했다. OFDM은 데이터를 여러 부반송파(subcarrier)에 나누어 전송하여 안정성을 높이는 기술이지만, 특정 시간 동안에는 전체 채널 대역폭을 단 하나의 사용자에게만 할당한다. 이는 마치 배달 트럭이 한 번에 한 집만 방문할 수 있는 것과 같아서, 작은 데이터 패킷을 보내는 여러 장치가 있을 경우 비효율적이었다.127
• Wi-Fi 6 (802.11ax)와 OFDMA: Wi-Fi 6의 핵심 혁신은 OFDMA(Orthogonal Frequency-Division Multiple Access) 의 도입이다. OFDMA는 하나의 Wi-Fi 채널을 리소스 단위(RU, Resource Unit)라는 더 작은 여러 개의 하위 채널로 분할한다. 이를 통해 액세스 포인트(AP)는 한 번의 전송 기회에 여러 사용자에게 각각 다른 RU를 할당하여 동시에 데이터를 전송할 수 있다.127 이제 배달 트럭이 여러 고객의 작은 소포들을 한 번에 싣고 동시에 배달할 수 있게 된 것이다. 이 기술은 특히 수많은 IoT 장치가 작은 데이터를 빈번하게 주고받는 밀집 환경에서 채널 사용 효율을 극대화하고 평균 지연 시간을 크게 줄여준다.129
• Wi-Fi 7 (802.11be)와 MLO (Multi-Link Operation): Wi-Fi 7의 가장 중요한 특징은 MLO(Multi-Link Operation) 이다. MLO는 하나의 장치가 2.4 GHz, 5 GHz, 6 GHz와 같은 여러 주파수 대역에 걸쳐 동시에 연결을 설정하고 데이터를 주고받을 수 있게 하는 기술이다.131
  • 주요 이점:
    • 처리량 증가 (Higher Throughput): 여러 대역의 대역폭을 합산(aggregate)하여 더 높은 최고 속도를 달성할 수 있다.133
    • 지연 시간 감소 (Lower Latency): 특정 순간에 가장 혼잡이 적은 대역을 선택하여 데이터를 전송하거나, 트래픽을 여러 링크로 분산시켜 지연 시간을 줄인다.132
    • 신뢰성 향상 (Improved Reliability): 하나의 링크(예: 5 GHz)가 심한 간섭을 겪더라도, 다른 링크(예: 6 GHz)를 통해 연결을 끊김 없이 유지할 수 있어 연결 안정성이 크게 향상된다.132

5G 네트워크는 단순히 4G/LTE보다 빠른 속도를 제공하는 것을 넘어, 초고속 데이터 전송(eMBB), 초저지연/고신뢰 통신(URLLC), 대규모 사물 통신(mMTC) 등 매우 이질적인 서비스 요구사항을 동시에 지원하도록 설계되었다.134 이를 위해 5G 프로토콜 스택은 근본적인 구조적 변화를 겪었다.

• 제어 평면(C-Plane)과 사용자 평면(U-Plane)의 분리: 5G 아키텍처의 핵심 원칙은 신호 처리를 담당하는 제어 평면과 실제 사용자 데이터 전송을 담당하는 사용자 평면을 명확하게 분리한 것이다.134

  • 제어 평면 (Control Plane): 네트워크의 ‘두뇌’에 해당하며, 모든 시그널링 트래픽을 처리한다. 여기에는 단말기의 네트워크 접속, 인증, 이동성 관리(핸드오버), 보안 키 관리, 서비스 정책 적용 등이 포함된다. 주요 프로토콜로는 RRC(Radio Resource Control), NAS(Non-Access Stratum)가 있으며, 코어망의 AMF(Access and Mobility Management Function)와 연동된다.134
  • 사용자 평면 (User Plane): 실제 사용자 데이터(웹 페이지, 동영상 스트림 등)가 흐르는 ‘고속도로’에 해당한다. 데이터 패킷의 압축, 암호화, 전달을 담당한다. 주요 프로토콜로는 PDCP(Packet Data Convergence Protocol), RLC(Radio Link Control), MAC(Medium Access Control)이 있으며, 코어망의 UPF(User Plane Function)와 연동된다.134

• 새로운 프로토콜 계층: SDAP:

  5G 사용자 평면에는 SDAP(Service Data Adaptation Protocol) 라는 새로운 계층이 추가되었다. SDAP의 핵심 역할은 다양한 서비스의 서비스 품질(QoS, Quality of Service) 요구사항을 데이터 무선 베어러(Data Radio Bearer)에 매핑하는 것이다. 예를 들어, 초저지연이 필수적인 원격 수술 데이터는 높은 우선순위의 전용 베어러로, 일반적인 웹 브라우징 데이터는 일반 베어러로 매핑한다. 이 기능은 하나의 물리적 네트워크를 여러 개의 가상 네트워크로 나누어 각각 다른 서비스 특성을 제공하는 네트워크 슬라이싱(Network Slicing)을 구현하는 데 결정적인 역할을 한다.134

Wi-Fi와 5G의 이러한 진화는 공통된 방향성을 보여준다. 즉, ‘하나의 크기가 모든 것에 맞는다(one-size-fits-all)’는 접근 방식에서 벗어나, 제한된 무선 자원을 더욱 지능적으로 분할하고 할당하는 정교한 자원 관리 메커니즘을 도입하고 있다는 점이다. Wi-Fi 6의 OFDMA와 5G의 C/U 평면 분리 및 SDAP는 모두 폭증하는 무선 기기와 다양해지는 애플리케이션의 요구에 부응하기 위한 필연적인 진화의 결과물이다.

현재 인터넷을 지배하는 TCP/IP의 호스트 중심, 점대점 통신 모델은 지난 수십 년간 놀라운 성공을 거두었지만, 그 근본적인 설계가 현대의 요구사항과 맞지 않는다는 비판도 꾸준히 제기되어 왔다. 이에 연구자들은 기존의 틀을 벗어나 백지상태(clean-slate)에서 인터넷을 새롭게 설계하려는 시도를 이어오고 있다. 이 장에서는 현재의 인터넷 아키텍처에 근본적인 도전을 제기하는 대표적인 차세대 아키텍처들을 살펴본다. 이들은 단순히 인터넷을 더 빠르게 만드는 것을 넘어, 본질적으로 더 안전하고 효율적이며 미래의 애플리케이션에 더 적합한 네트워크를 구축하는 것을 목표로 한다.

• 핵심 아이디어: 정보 중심 네트워킹(ICN)은 네트워크의 패러다임을 ‘데이터가 어디에 있는가(호스트의 IP 주소)’에서 ‘데이터가 무엇인가(콘텐츠의 이름)’로 전환하려는 혁신적인 접근 방식이다.139 현재 인터넷 트래픽의 대부분이 콘텐츠 배포(동영상, 파일 공유 등)임에도 불구하고, IP 아키텍처는 여전히 호스트 간의 대화를 위해 설계되어 있다는 구조적 불일치에서 출발한다.140
• NDN(Named Data Networking)의 동작 방식: ICN의 가장 대표적인 구현체인 NDN은 다음과 같이 동작한다.
  1. Interest 패킷: 콘텐츠를 원하는 소비자(consumer)는 /com/example/video/intro.mp4와 같이 계층적 구조를 가진 콘텐츠의 이름을 담은 Interest 패킷을 네트워크로 전송한다.
  2. 라우팅 및 PIT: 라우터들은 이 Interest 패킷을 이름 기반 라우팅 테이블(FIB)을 참조하여 데이터 소스 방향으로 전달한다. 동시에, 어떤 인터페이스로 Interest가 들어왔는지 PIT(Pending Interest Table)에 기록해 둔다.
  3. Data 패킷: Interest 패킷이 해당 데이터를 가진 노드(원본 서버 또는 중간 캐시)에 도달하면, 그 노드는 콘텐츠와 함께 생산자의 암호화 서명이 담긴 Data 패킷을 반환한다. 데이터 자체에 서명이 포함되므로, 연결이 아닌 데이터의 보안과 무결성이 보장된다.
  4. 역방향 전달 및 캐싱: Data 패킷은 PIT에 기록된 경로를 따라 Interest가 왔던 역방향으로 전달된다. 이 과정에서 경로상의 라우터들은 Data 패킷을 자신의 캐시에 저장할 수 있다. 이후 동일한 콘텐츠에 대한 다른 Interest가 도착하면, 원본 서버까지 가지 않고 가까운 캐시에서 즉시 응답할 수 있다.139

• 기대 효과: NDN은 네트워크 내 캐싱을 기본 기능으로 지원하여 콘텐츠 전송 효율을 극대화하고, 데이터 자체에 보안을 내재화하며, 멀티캐스트와 이동성을 자연스럽게 지원하는 등의 장점을 가진다.141

• 핵심 아이디어: SCION(Scalability, Control, and Isolation On Next-Generation Networks)은 높은 가용성, 보안, 그리고 라우팅 경로에 대한 명시적인 제어권을 제공하기 위해 설계된 클린슬레이트 인터넷 아키텍처다.95
• 경로 인식(Path-Awareness): BGP에서는 라우팅 경로가 네트워크에 의해 결정되고 종단점에는 불투명한 경우가 많다. 반면, SCION에서는 종단 호스트가 사용 가능한 경로 조각(path segment)들을 학습하고, 이를 조합하여 완전한 종단 간 경로를 직접 생성한다. 이렇게 생성된 경로 정보는 패킷 헤더에 직접 실려 전송된다.95
• 제어권과 투명성: 송신자와 수신자는 자신의 트래픽이 어떤 경로를 통해 전달될지 명시적으로 제어할 수 있다. 이를 통해 특정 국가나 특정 ISP를 경유하지 않도록 하거나, 지연 시간이 가장 짧은 경로를 선택하는 등 다양한 정책을 강제할 수 있다.144
• 내재된 보안: SCION은 보안을 추가 기능이 아닌 핵심 설계 원칙으로 삼는다. 경로 조각들은 암호학적으로 보호되므로, BGP에서 발생하는 접두어 하이재킹(prefix hijacking)과 같은 공격에 대해 원천적으로 면역력을 가진다.95
• 격리 도메인(Isolation Domains, ISDs): SCION은 전 세계 네트워크를 자율 시스템(AS)들의 논리적 그룹인 ISD로 구조화한다. 이를 통해 한 도메인에서 발생한 라우팅 장애나 정책 오류가 전 세계로 파급되는 것을 막고, 문제를 해당 ISD 내부에 격리시킨다.144

• 실용성: SCION은 이론에만 머무르지 않고, 스위스 은행 간 금융 네트워크(SSFN)와 같은 중요 인프라에서 실제로 운영되며 그 실효성을 입증하고 있다.144

• 개발 동기: DTN(Delay-Tolerant Networking)은 심우주 통신, 재난 지역, 극지 센서 네트워크와 같이 지연이 매우 길고, 연결이 자주 끊기며, 오류율이 높은 ‘극한(stressed)’ 환경을 위해 설계되었다. 이러한 환경에서는 종단 간 경로가 동시에 존재하지 않을 수도 있다.149
• 번들 프로토콜(Bundle Protocol, BP): DTN의 핵심으로, 다른 프로토콜 위에 동작하는 오버레이(overlay) 방식이다. 데이터는 ‘번들(bundle)’이라는 크고 독립적인 데이터 단위로 묶인다.149
• 저장-전달(Store-and-Forward): DTN의 가장 근본적인 메커니즘이다. DTN 노드(라우터)는 수신한 번들을 다음 홉으로 즉시 전달할 수 없으면, IP 라우터처럼 폐기하는 대신, 전달 가능한 경로가 생길 때까지 자신의 저장 공간에 무기한 저장한다. 그리고 기회가 생겼을 때 다음 홉으로 전달한다.149
• 관리권 이전(Custody Transfer): 중간 노드가 번들에 대한 ‘관리권’을 인수하여 최종 목적지까지의 전달 책임을 지는 선택적 기능이다. 관리권을 인수한 노드는 이전 홉에게 번들을 안전하게 삭제해도 좋다는 신호를 보내, 이전 홉의 저장 공간을 확보해준다.149
• 적용 분야: NASA의 ‘행성 간 인터넷(Interplanetary Internet)’ 프로젝트에서 시작되었으며, 현재는 군사 통신, 원격지 통신 등 지상의 특수 환경에서도 활용되고 있다.149

이러한 클린슬레이트 아키텍처들은 단순히 기존 인터넷을 개선하려는 시도를 넘어, 그 핵심 가정인 ‘호스트 간 연결’의 우위성에 근본적인 질문을 던진다. ICN은 콘텐츠 이름을, SCION은 경로를, DTN은 번들을 새로운 네트워킹의 기본 단위(primitive)로 제안한다. 이는 IP 주소라는 단일 프리미티브로는 해결하기 어려운 21세기의 주요 과제들-콘텐츠 배포, 보안, 극한 환경 통신-에 대응하기 위한 패러다임의 전환을 모색하는 것이다.

본 보고서의 마지막 장에서는 인터넷의 미래를 형성하는 거시적인 흐름과 지속적인 난제들을 종합적으로 조망한다. 기술적 진화, 사회경제적 압력, 그리고 구조적 관성 사이의 긴장 관계를 탐구하며, 프로토콜 경직화 문제부터 양자 인터넷의 등장, 망 중립성 논쟁, 그리고 프로토콜의 신뢰성을 보장하기 위한 형식 검증의 역할까지, 미래 통신 기술의 향방을 결정할 핵심적인 주제들을 다룬다.

• 정의: 프로토콜 경직화(Protocol Ossification)는 널리 배포된 네트워크 프로토콜이 점차 유연성을 잃고 새로운 기능 추가나 변경이 어려워지는 현상을 말한다. 이는 인터넷 혁신의 가장 큰 장애물 중 하나로 꼽힌다.125
• 주요 원인 - 미들박스(Middleboxes): 가장 큰 원인은 인터넷 경로상에 존재하는 수많은 미들박스(방화벽, NAT 장비, 성능 최적화 장비 등) 때문이다. 이 장비들은 특정 프로토콜의 동작 방식을 하드코딩된 규칙으로 가지고 있는 경우가 많다. 따라서 알려지지 않은 새로운 프로토콜이나 기존 프로토콜의 새로운 확장 기능(예: 새로운 TCP 옵션)을 마주치면, 이를 오류나 공격으로 오인하여 해당 트래픽을 차단하거나 변조할 수 있다.125
• 악순환 구조: 새로운 기능은 미들박스가 차단하기 때문에 널리 배포될 수 없고, 미들박스 제조사들은 널리 사용되지 않는 기능을 지원하기 위해 소프트웨어를 업데이트할 유인이 없다. 이 악순환은 결국 혁신을 가로막는다.156
• 결과: 이러한 경직화 현상으로 인해, 오늘날 인터넷에서 실질적으로 사용할 수 있는 전송 프로토콜은 TCP와 UDP뿐이며, TCP 자체의 진화조차 매우 더디게 만들었다.125
• 대응 방안:
  • 암호화: 가장 효과적인 전략이다. QUIC 프로토콜처럼 통신의 많은 부분을 암호화하면, 미들박스가 프로토콜의 내부 동작을 들여다보고 간섭하는 것을 원천적으로 차단할 수 있다.125
  • 그리징(Greasing): 프로토콜의 확장 지점(extension point)에 의도적으로 알려지지 않은 임의의 값을 주기적으로 사용하여, 네트워크 경로가 미래의 새로운 값에 대해 내성을 유지하도록 훈련시키는 기법이다.157
• 근본적 차이: 고전적인 인터넷이 0 또는 1의 상태를 갖는 비트(bit)로 정보를 전송하는 반면, 양자 인터넷은 중첩(superposition)과 얽힘(entanglement)과 같은 양자역학적 현상을 이용하여 큐비트(qubit) 형태로 정보를 전송한다.158
• 핵심 응용 - 보안: 양자 인터넷의 주된 동기는 속도가 아니라 보안이다. 양자역학은 고전적인 방식으로는 불가능한 수준의 보안을 제공할 잠재력을 가지고 있다.
  • 양자 키 분배(Quantum Key Distribution, QKD): 양자역학의 원리를 이용하여 암호화 키를 안전하게 분배하는 기술이다. 제3자가 큐비트를 관측하려는 시도는 필연적으로 양자 상태를 교란시키므로, 도청 시도가 즉시 발각된다. 이는 이론적으로 완벽하게 안전한 키 교환을 가능하게 한다.159
• 핵심 프로토콜 및 개념:
  • 양자 순간이동(Quantum Teleportation): 양자 얽힘과 고전 통신 채널을 이용하여 한 위치의 양자 상태를 다른 위치로 전송하는 기술이다.158
  • 얽힘 교환(Entanglement Swapping): 직접 상호작용 한 적이 없는 두 노드 사이에 얽힘 상태를 생성하는 기술로, 양자 중계기(quantum repeater)를 구축하는 데 필수적이다.158

• 아키텍처: 초기 양자 네트워크는 기존 인터넷을 보강하는 오버레이 형태로 구축될 가능성이 높다. 이는 큐비트를 전송하는 양자 채널(예: 전용 광섬유), 측정 결과를 실시간으로 교환하는 고전 채널, 그리고 일반 제어를 위한 비실시간 고전 채널 등 최소 세 개의 채널로 구성될 것이다.163

• 망 중립성(Network Neutrality): 인터넷 서비스 제공자(ISP)가 인터넷상의 모든 데이터를 사용자, 콘텐츠, 애플리케이션, 프로토콜 등에 따라 차별하지 않고 동등하게 취급해야 한다는 원칙이다.164

• 기술과 정책의 교차점: 이는 본질적으로 정책 논쟁이지만, 그 실행은 기술적인 수단을 통해 이루어진다. 특정 프로토콜(예: P2P 파일 공유, 인터넷 전화)의 트래픽 속도를 의도적으로 늦추거나(throttling), 차단하는 행위는 망 중립성 원칙에 위배되는 기술적 구현 사례다.165

• 제로 레이팅(Zero-Rating): ISP가 특정 애플리케이션(예: 페이스북, 교육 사이트)에서 발생하는 데이터 사용량에 대해서는 고객에게 요금을 부과하지 않는 관행이다. 이는 ‘긍정적 차별’의 한 형태로, 망 중립성 논쟁에서 뜨거운 감자다.165

• 상호접속 경제학 (피어링 대 트랜짓):

  • 트랜짓(Transit): 작은 네트워크가 더 큰 네트워크(상위 ISP)에 비용을 지불하고, 그 네트워크를 통해 전 세계 인터넷망과 트래픽을 교환하는 방식이다.167

  • 피어링(Peering): 비슷한 규모의 두 네트워크가 상호 이익을 위해 서로의 고객 간 트래픽을 무료로 교환하기로 합의하는 방식이다. 주로 인터넷 교환 지점(IXP)에서 이루어진다.167

    피어링을 할지 트랜짓을 구매할지에 대한 경제적 결정은 인터넷 트래픽의 실제 경로에 직접적인 영향을 미치며, 넷플릭스나 구글과 같은 거대 콘텐츠 제공자와 대형 ISP 간의 망 사용료 분쟁과 같은 갈등으로 이어지기도 한다.165

• 필요성: 네트워크 프로토콜은 복잡한 분산 시스템으로, 설계나 구현상의 미묘한 결함이 BGP 설정 오류로 인한 대규모 인터넷 장애나 TLS의 보안 취약점과 같은 심각한 문제로 이어질 수 있다.168
• 형식 검증(Formal Verification): 프로토콜의 설계나 구현이 원하는 속성(예: 보안, 안정성)의 형식적 명세(formal specification)를 만족하는지를 수학적 방법과 자동화된 도구(모델 체커, 정리 증명기 등)를 사용하여 증명하는 과정이다.82
• 적용 사례:
  • TLS: 모델 체킹 기법을 사용하여 TLS 핸드셰이크 프로토콜의 보안 속성을 검증하고, 비밀키가 안전하게 설정됨을 증명하는 데 사용되었다.82
  • BGP: BGP의 동작을 모델링하는 형식적 의미론(formal semantics)을 정의하여, 특정 조건 하에서의 경로 수렴을 증명하고 Bagpipe와 같은 설정 검증 도구의 정확성을 확인하는 데 활용되었다.168
  • SCION: SCION 라우터 구현은 경로 인증과 같은 상위 수준의 보안 속성뿐만 아니라, 메모리 안전성과 같은 하위 수준의 코드 속성까지 형식 검증을 거쳤다. 이는 증명 가능하게 안전한 인터넷 아키텍처를 구축하려는 중요한 진전이다.170

결론적으로, 인터넷의 미래는 기술적 진화(QUIC, Wi-Fi 7 등), 사회경제적 압력(망 중립성, 피어링 경제학), 그리고 구조적 관성(프로토콜 경직화)이라는 세 가지 힘 사이의 복잡한 상호작용에 의해 형성되고 있다. 더 나은 인터넷을 구축하기 위해서는 단순히 영리한 기술 개발을 넘어, 이러한 관성을 극복하고, 견고한 경제 모델과 건전한 정책을 수립하며, 형식 검증과 같은 새로운 방법론을 통해 시스템의 신뢰성을 확보하려는 다각적인 노력이 필요하다. 통신 프로토콜에 대한 깊이 있는 이해는, 이 복잡하고 역동적인 힘의 상호작용 속에서 기술적 아티팩트가 어떻게 탄생하고 진화하는지를 파악하는 것에서 완성된다.

1. What is Protocol? - default - 티스토리, accessed July 5, 2025, https://defaultvalues.tistory.com/35
2. 통신 프로토콜 - 위키백과, 우리 모두의 백과사전, accessed July 5, 2025, https://ko.wikipedia.org/wiki/%ED%86%B5%EC%8B%A0_%ED%94%84%EB%A1%9C%ED%86%A0%EC%BD%9C

3. 프로토콜이란 무엇인가요? 이해를 위한 가이드

   한국레노버 - Lenovo, accessed July 5, 2025, https://www.lenovo.com/kr/ko/glossary/what-is-protocol/

4. 프로토콜이란 무엇인가: 기초부터 시작하기 - velog, accessed July 5, 2025, https://velog.io/@blessoms2017/%ED%94%84%EB%A1%9C%ED%86%A0%EC%BD%9C%EC%9D%B4%EB%9E%80-%EB%AC%B4%EC%97%87%EC%9D%B8%EA%B0%80-%EA%B8%B0%EC%B4%88%EB%B6%80%ED%84%B0-%EC%8B%9C%EC%9E%91%ED%95%98%EA%B8%B0
5. [Protocol] 프로토콜 정의, 요소, 종류, 기능, 예시, accessed July 5, 2025, https://rotoma-code.tistory.com/entry/Protocol-%ED%94%84%EB%A1%9C%ED%86%A0%EC%BD%9C-%EC%A0%95%EC%9D%98-%EC%9A%94%EC%86%8C-%EC%A2%85%EB%A5%98-%EA%B8%B0%EB%8A%A5-%EC%98%88%EC%8B%9C
6. 프로토콜의 3 구성요소, accessed July 5, 2025, https://baileyworld.tistory.com/7
7. 프로토콜 - 비트(bit)주세요 - 티스토리, accessed July 5, 2025, https://standardh.tistory.com/162
8. 프로토콜을 구성하는 대표적인 세 가지 요소 - 새벽까지 - 티스토리, accessed July 5, 2025, https://night-knight.tistory.com/entry/%ED%94%84%EB%A1%9C%ED%86%A0%EC%BD%9C%EC%9D%84-%EA%B5%AC%EC%84%B1%ED%95%98%EB%8A%94-%EB%8C%80%ED%91%9C%EC%A0%81%EC%9D%B8-%EC%84%B8-%EA%B0%80%EC%A7%80-%EC%9A%94%EC%86%8C
9. 프로토콜(Protocol) - NO.1 EDI SaaS 플랫폼 커넥트 서비스 - 티스토리, accessed July 5, 2025, https://cloudedi.tistory.com/entry/%ED%94%84%EB%A1%9C%ED%86%A0%EC%BD%9CProtocol
10. [IT지식] 프로토콜(Protocol)이란? - Make_It_Count - 티스토리, accessed July 5, 2025, https://seohee-ha.tistory.com/138
11. 프로토콜(Protocol)? 그래서 그게 뭔데? - 탕구리’s 블로그, accessed July 5, 2025, https://real-dongsoo7.tistory.com/81
12. [네트워크] TCP/IP, 네트워크 계층 모델, HTTP, HTTPS - velog, accessed July 5, 2025, https://velog.io/@rsuubinn/%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC
13. 컴퓨터 네트워크: OSI 7 계층(Layer)과 TCP/IP 모델의 이해, accessed July 5, 2025, https://oobwrite.com/entry/%EC%BB%B4%ED%93%A8%ED%84%B0-%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC-OSI-7-%EA%B3%84%EC%B8%B5Layer%EA%B3%BC-TCPIP-%EB%AA%A8%EB%8D%B8%EC%9D%98-%EC%9D%B4%ED%95%B4
14. TCP/IP 모델의 이해와 OSI와 TCP/IP 비교 - 기억에서 기록까지 - 티스토리, accessed July 5, 2025, https://jjdevelop.tistory.com/5
15. OSI 모델과 TCP/IP 모델 - 체크 포인트 소프트웨어 - Check Point, accessed July 5, 2025, https://www.checkpoint.com/kr/cyber-hub/network-security/what-is-the-osi-model-understanding-the-7-layers/osi-model-vs-tcp-ip-model/
16. TCP/IP, OSI 7 계층 구조 비교 - velog, accessed July 5, 2025, https://velog.io/@moonblue/TCPIP-%EC%99%80-OSI-7%EA%B3%84%EC%B8%B5-%EA%B5%AC%EC%A1%B0-%EB%B9%84%EA%B5%90
17. OSI 7계층과 TCP/IP 4계층 비교하기 - NicoDora의 블로그 - 티스토리, accessed July 5, 2025, https://nicodora.tistory.com/entry/OSI-7%EA%B3%84%EC%B8%B5%EA%B3%BC-TCPIP-4%EA%B3%84%EC%B8%B5-%EB%B9%84%EA%B5%90%ED%95%98%EA%B8%B0
18. TCP/IP 4계층의 이해, accessed July 5, 2025, https://junu0516.github.io/posts/tcp_ip_4%EA%B3%84%EC%B8%B5/
19. TCP/IP 방식의 계층적 구조 및 네트워크 계층의 헤더 기능 - minhui study, accessed July 5, 2025, https://jeongminhee99.tistory.com/138
20. OSI 7계층과 TCP/IP 계층 비교, accessed July 5, 2025, https://kingjakeu.github.io/study/2020/08/11/OSI-TCP-IP/
21. [개념 콕] TCP/IP 4계층 - 내일배움캠프 블로그, accessed July 5, 2025, https://nbcamp.spartacodingclub.kr/blog/%EA%B0%9C%EB%85%90-%EC%BD%95-%EC%9B%B9-%EA%B0%9C%EB%B0%9C-%EC%A7%80%EC%8B%9D-%ED%8E%B8-tcpip-4%EA%B3%84%EC%B8%B5%EC%9D%98-%EA%B0%9C%EB%85%90-%EA%B3%84%EC%B8%B5%EB%B3%84-%ED%8A%B9%EC%A7%95-21175
22. [Network] TCP/IP 4계층에 대하여 - velog, accessed July 5, 2025, https://velog.io/@dyunge_100/Network-TCPIP-4%EA%B3%84%EC%B8%B5%EC%97%90-%EB%8C%80%ED%95%98%EC%97%AC
23. [데이터통신 - 3] 캡슐화와 역캡슐화, accessed July 5, 2025, https://gunjoon.tistory.com/15
24. 캡슐화와 역캡슐화 - Bruders, accessed July 5, 2025, https://bruders.tistory.com/111
25. [CS] TCP/IP 4계층 #1. 개념, 캡슐화, 비캡슐화, PDU, OSI 7계층 - Johnny’s 개발 STORY, accessed July 5, 2025, https://jhlee-developer.tistory.com/entry/CS-TCPIP-4%EA%B3%84%EC%B8%B5-1-%EA%B0%9C%EB%85%90-%EC%BA%A1%EC%8A%90%ED%99%94-%EB%B9%84%EC%BA%A1%EC%8A%90%ED%99%94-PDU-OSI-7%EA%B3%84%EC%B8%B5

26. 8장	네트워크의 전체 흐름 살펴보기, accessed July 5, 2025, https://hgggny.tistory.com/entry/8%EC%9E%A5-%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC%EC%9D%98-%EC%A0%84%EC%B2%B4-%ED%9D%90%EB%A6%84-%EC%82%B4%ED%8E%B4%EB%B3%B4%EA%B8%B0

27. 캡슐화 & 역캡슐화 - 동아리 활동 정리, accessed July 5, 2025, https://maja.tistory.com/7
28. 계층별 네트워크 프로토콜 - 지식덤프, accessed July 5, 2025, http://www.jidum.com/jidums/view.do?jidumId=415
29. [TCP/UDP] TCP와 UDP의 특징과 차이 - 망나니개발자 - 티스토리, accessed July 5, 2025, https://mangkyu.tistory.com/15
30. TCP 와 UDP의 특징과 차이, accessed July 5, 2025, https://velog.io/@dae_eun2/TCP-%EC%99%80-UDP%EC%9D%98-%ED%8A%B9%EC%A7%95%EA%B3%BC-%EC%B0%A8%EC%9D%B4
31. [TCP/UDP] TCP와 UDP의 특징과 차이 - velog, accessed July 5, 2025, https://velog.io/@devharrypmw/TCPUDP-TCP%EC%99%80-UDP%EC%9D%98-%ED%8A%B9%EC%A7%95%EA%B3%BC-%EC%B0%A8%EC%9D%B4
32. [패킷분석] TCP 통신에서 ACK ?, accessed July 5, 2025, https://ch4njun.tistory.com/41
33. 전송 계층 프로토콜 ( TCP , UDP ) 특징 및 헤더 정보 - Maker’s security - 티스토리, accessed July 5, 2025, https://maker5587.tistory.com/4
34. [HTTP Protocol] 주소창에 구글 입력 시 전체 동작과정은 어떻게 될까요? - beatmejy, accessed July 5, 2025, https://beatmejy.tistory.com/25
35. [네트워크] TCP/IP 흐름 제어 & 혼잡 제어 - 느리더라도 꾸준하게 - 티스토리, accessed July 5, 2025, https://steady-coding.tistory.com/507
36. 웹 사이트에 접속하는 과정에 대하여 - velog, accessed July 5, 2025, https://velog.io/@yange/%EC%9B%B9-%EC%82%AC%EC%9D%B4%ED%8A%B8%EC%97%90-%EC%A0%91%EC%86%8D%ED%95%98%EB%8A%94-%EA%B3%BC%EC%A0%95%EC%97%90-%EB%8C%80%ED%95%98%EC%97%AC
37. TCP의 흐름제어, 혼잡제어 - 개발자를 꿈꾸는 프로그래머 - 티스토리, accessed July 5, 2025, https://jwprogramming.tistory.com/36
38. 전송 계층 - TCP 의 모든 것 #2. 흐름제어, ARQ, Sliding Window - Back_up - 티스토리, accessed July 5, 2025, https://as-backup.tistory.com/31
39. 슬라이딩 윈도우 - 비트코기의 IT Note, accessed July 5, 2025, https://itpenote.tistory.com/377
40. velog.io, accessed July 5, 2025, https://velog.io/@qorgus31/%ED%9D%90%EB%A6%84%EC%A0%9C%EC%96%B4%EC%99%80-%EC%98%A4%EB%A5%98%EC%A0%9C%EC%96%B4
41. [컴퓨터 네트워크] 오류제어 - Physical Law - 티스토리, accessed July 5, 2025, https://physicallaw.tistory.com/83
42. 3.라우팅(포워딩, 링크상태 라우팅, Autonomous System, OSPF, 도메인간 라우팅, 도메인내 라우팅, BGP, CIDR, 방송형라우팅, 멀티캐스트 , MBONE, Mobile 네트워크의 라우팅, AD HOC 네트워크의 라우팅, 혼잡제.. - HyeopCoding - 티스토리, accessed July 5, 2025, https://hyeophyeop.tistory.com/69
43. TCP 혼잡 제어 - velog, accessed July 5, 2025, https://velog.io/@mu1616/TCPIP-%ED%98%BC%EC%9E%A1-%EC%A0%9C%EC%96%B4
44. TCP (흐름제어/혼잡제어) - velog, accessed July 5, 2025, https://velog.io/@k4minseung/TCP-%ED%9D%90%EB%A6%84%EC%A0%9C%EC%96%B4%ED%98%BC%EC%9E%A1%EC%A0%9C%EC%96%B4
45. TCP congestion control - RAINBOW-LAB - 티스토리, accessed July 5, 2025, https://rain-bow.tistory.com/entry/TCP-congestion-control
46. TCP와 UDP를 비교 설명해 주세요., accessed July 5, 2025, https://www.nossi.dev/405c51e4-778c-45a5-9920-c239f2468417
47. TCP vs UDP, 신뢰성과 속도, 당신의 선택은 - 레몬의 코드스니펫, accessed July 5, 2025, https://lemonlog.tistory.com/213
48. [침탐] 4장, 전송 계층의 헤더 기능 - 정보보호 뿜뿜 - 티스토리, accessed July 5, 2025, https://dyoerr9030.tistory.com/entry/%EC%B9%A8%ED%83%90-4%EC%9E%A5-%EC%A0%84%EC%86%A1-%EA%B3%84%EC%B8%B5%EC%9D%98-%ED%97%A4%EB%8D%94-%EA%B8%B0%EB%8A%A5
49. TCP UDP 차이: 두 프로토콜 비교 - NordVPN, accessed July 5, 2025, https://nordvpn.com/ko/blog/tcp-udp-comparison/
50. IP 헤더 읽어드립니다 - ghdwlsgur 기술블로그, accessed July 5, 2025, https://ghdwlsgur.github.io/docs/Network/IpHeader
51. [13] CH4 네트워크 계층 < 인터넷 프로토콜(IP) > - Return - 티스토리, accessed July 5, 2025, https://returnclass.tistory.com/111
52. IP 헤더 란 무엇입니까? - Hostwinds 웹 호스팅, accessed July 5, 2025, https://www.hostwinds.kr/tutorials/what-are-ip-headers
53. TTL(Time To Live) - 씨디네트웍스 - CDNetworks, accessed July 5, 2025, https://www.cdnetworks.com/ko/glossary/time-to-live/

54. MAC 주소와 IP 주소의 차이점은 무엇입니까?

    파이버로드 - Fiberroad, accessed July 5, 2025, https://fiberroad.com/ko/resources/glossary/whats-the-difference-between-mac-and-ip-addresses/

55. ARP(Address Resolution Protocol)와 MAC, IP address - my devlog; - 티스토리, accessed July 5, 2025, https://hyunah-home.tistory.com/entry/ARPAddress-Resolution-Protocol%EC%99%80-MAC-IP-address
56. 왜 IP 주소, MAC 주소 두 개나 쓰는 걸까? - Network Basic - 티스토리, accessed July 5, 2025, https://jin-network.tistory.com/46
57. [Network]IP address와 MAC address - 베스핀글로벌 테크센터 블로그, accessed July 5, 2025, https://btcd.tistory.com/74
58. 네트워크 통신과정(feat. ARP vs Routing) - ::Run it:: - 티스토리, accessed July 5, 2025, https://run-it.tistory.com/18
59. ARP 프로토콜 및 구조 총정리, accessed July 5, 2025, https://chanelcocolover.tistory.com/entry/ARP-%ED%94%84%EB%A1%9C%ED%86%A0%EC%BD%9C-%EB%B0%8F-%EA%B5%AC%EC%A1%B0-%EC%B4%9D%EC%A0%95%EB%A6%AC
60. 31.[Network] TCP/IP통신과 MAC주소의 변화, accessed July 5, 2025, https://christychoi.hashnode.dev/31network-tcpip-mac
61. Packet 전송 과정, Distance Vector & Link State Routing Protocol - 네트워크의 모든 것, All about Network™, accessed July 5, 2025, https://net-study.club/entry/Routing-%EA%B0%9C%EC%9A%94-1-Packet-%EC%A0%84%EC%86%A1-%EA%B3%BC%EC%A0%95-Distance-Vector-Link-State-Routing-Protocol
62. ARP - 목적지의 MAC 주소를 알기위한 장치, accessed July 5, 2025, https://real-dongsoo7.tistory.com/108
63. 패킷 전송(Packet Delivery)_ARP - 성목아코딩하자, accessed July 5, 2025, https://seongmok.com/60
64. Network - 스위치, ARP (packet tracer, windows) - 잇!(IT) 블로그 - 티스토리, accessed July 5, 2025, https://insoobaik.tistory.com/116
65. [Web/HTTP] Web의 3요소와 HTTP 프로토콜, 특징 - HS_dev_log - 티스토리, accessed July 5, 2025, https://innovation123.tistory.com/149
66. [간단정리] HTTP Request/Response 구조 - 넌 잘하고 있어 - 티스토리, accessed July 5, 2025, https://hahahoho5915.tistory.com/62
67. HTTP 프로토콜, 메세지, accessed July 5, 2025, https://velog.io/@gkrba1234/HTTP-%ED%94%84%EB%A1%9C%ED%86%A0%EC%BD%9C
68. HTTP 및 WEB 기본 내용 정리 - velog, accessed July 5, 2025, https://velog.io/@coin46/HTTP-%EB%B0%8F-WEB-%EA%B8%B0%EB%B3%B8-%EB%82%B4%EC%9A%A9-%EC%A0%95%EB%A6%AC
69. HTTP와 HTTPS 비교 - 전송 프로토콜 간의 차이점 - AWS, accessed July 5, 2025, https://aws.amazon.com/ko/compare/the-difference-between-https-and-http/
70. FTP 프로토콜 Passive Mode와 Active Mode - Ho_use, accessed July 5, 2025, https://xn–vj5b11biyw.kr/211
71. FTP PORT(능동) 모드와 PASV(수동) 모드 - 뭐라 씨부리 쌌노? - 티스토리, accessed July 5, 2025, https://visu4l.tistory.com/entry/FTP-PORT%EB%8A%A5%EB%8F%99-%EB%AA%A8%EB%93%9C%EC%99%80-PASV%EC%88%98%EB%8F%99-%EB%AA%A8%EB%93%9C
72. [FTP] FTP의 Active Mode와 Passive Mode 차이점 - SATAz BLOG, accessed July 5, 2025, https://sata.kr/entry/5BFTP5D20FTPEC9D9820Active20ModeEC998020Passive20Mode20ECB0A8EC9DB4ECA090
73. FTP 접속모드 에서 active mode와 passive mode의 차이점 - Life is Network - 티스토리, accessed July 5, 2025, https://mizoony.tistory.com/entry/FTP-%EC%A0%91%EC%86%8D%EB%AA%A8%EB%93%9C-%EC%97%90%EC%84%9C-active-mode%EC%99%80-passive-mode%EC%9D%98-%EC%B0%A8%EC%9D%B4%EC%A0%90
74. 네트워크 - POP3, IMAP, SMTP 개념 및 차이점 비교 - Dev Joon, accessed July 5, 2025, https://han-joon-hyeok.github.io/posts/Network-POP3-IMAP-SMTP/
75. 메일서버 개념 SMTP /POP3 / IMAP 란? - IT 기획의 길 - 티스토리, accessed July 5, 2025, https://sangbeomkim.tistory.com/143
76. [Network] SMTP & POP3 & IMAP - 베스핀글로벌 테크센터 블로그, accessed July 5, 2025, https://btcd.tistory.com/291
77. 단순 전자우편 전송 프로토콜(SMTP)이란? - Cloudflare, accessed July 5, 2025, https://www.cloudflare.com/ko-kr/learning/email-security/what-is-smtp/
78. HTTPS와 TLS - TLS 핸드세이크, accessed July 5, 2025, https://velog.io/@leesfact/HTTPS%EC%99%80-TLS-TLS-%ED%95%B8%EB%93%9C%EC%84%B8%EC%9D%B4%ED%81%AC
79. TLS(Transport Layer Security) - 토스페이먼츠 개발자센터, accessed July 5, 2025, https://docs.tosspayments.com/resources/glossary/tls
80. [인증서] SSL/TLS 란? (개념, 특징, 동작 과정, 중간자 공격(MITM)) - 니나노, accessed July 5, 2025, https://yuna-ninano.tistory.com/m/entry/%EC%9D%B8%EC%A6%9D%EC%84%9C-SSLTLS-%EB%9E%80-%EA%B0%9C%EB%85%90-%ED%8A%B9%EC%A7%95-%EC%9E%A5%EB%8B%A8%EC%A0%90-%EC%82%AC%EC%9A%A9-%EC%82%AC%EB%A1%80
81. TLS 1.2에서 핸드 쉐이크는 어떻게 동작할까? - velog, accessed July 5, 2025, https://velog.io/@developerwan/TLS-1.2%EC%97%90%EC%84%9C-%ED%95%B8%EB%93%9C-%EC%89%90%EC%9D%B4%ED%81%AC-%EC%96%B4%EB%96%BB%EA%B2%8C-%EB%8F%99%EC%9E%91%ED%95%A0%EA%B9%8C
82. (PDF) Formal verification of TLS handshake and extensions for wireless networks, accessed July 5, 2025, https://www.researchgate.net/publication/228360921_Formal_verification_of_TLS_handshake_and_extensions_for_wireless_networks
83. TLS 핸드쉐이크 (Handshake) 프로토콜 분석, accessed July 5, 2025, https://kthan.tistory.com/entry/TLS-%ED%95%B8%EB%93%9C%EC%89%90%EC%9D%B4%ED%81%AC-Handshake-%ED%94%84%EB%A1%9C%ED%86%A0%EC%BD%9C-%EB%B6%84%EC%84%9D
84. TLS 핸드셰이크란 무엇인가요? - PowerDMARC, accessed July 5, 2025, https://powerdmarc.com/ko/what-is-a-tls-handshake/

85. TLS 1.3. SSL/TLS

    by Jaewoong

    Quantum Ant - Medium, accessed July 5, 2025, https://medium.com/quantum-ant/tls-1-3-%EC%9C%A4%EC%9E%AC%EC%9B%85-7e79a05f5d79

86. TLS 1.3에 대해 알아보자, accessed July 5, 2025, https://digitalbourgeois.tistory.com/91
87. TLS 1.3 파헤치기 ( Forward Secrecy ) - lotus’ s develog - 티스토리, accessed July 5, 2025, https://flowersayo.tistory.com/124
88. 검사 및 보호를 위해 SSL 및 TLS 1.3 복호화 - F5, accessed July 5, 2025, https://www.f5.com/ko_kr/resources/library/encrypted-threats/ssl-visibility/is-tls-1-3-the-solution
89. TLS 취약점 분석과 해결 방법, accessed July 5, 2025, https://expo.hknu.ac.kr/2020/_File/bbs/8/1606185344_8263.pdf
90. POODLE 취약점 또 다시 발생… 주의! - 이스트시큐리티 알약 블로그, accessed July 5, 2025, https://blog.alyac.co.kr/218
91. POODLE 취약점 - OpenText, accessed July 5, 2025, https://www.opentext.com/file_source/OpenText/en_US/PDF/OpenText-POODLE-Vulnerability-FAQ-KO.pdf
92. 5년 전 나타난 푸들 취약점과 비슷한 취약점 두 개 추가 발견 - 보안뉴스, accessed July 5, 2025, https://m.boannews.com/html/detail.html?idx=76781
93. What is BGP Hijacking? Prevention and defense mechanisms. - Noction, accessed July 5, 2025, https://www.noction.com/blog/bgp-hijacking
94. RPKI and the RTR protocol - The Cloudflare Blog, accessed July 5, 2025, https://blog.cloudflare.com/rpki-and-the-rtr-protocol/
95. SCION Internet Architecture, accessed July 5, 2025, https://scion-architecture.net/archive/
96. IoT 메시지 프로토콜: 서비스 제공자를 위한 다음 보안 과제는? - F5, accessed July 5, 2025, https://www.f5.com/ko_kr/company/blog/iot-message-protocols-the-next-security-challenge-for-service-providers
97. IoT를 위한 표준 프로토콜 MQTT와 CoAP - 헬로티, accessed July 5, 2025, https://www.hellot.net/news/article.html?no=27478
98. MQTT Protocol 이란? - velog, accessed July 5, 2025, https://velog.io/@iamdudumon/MQTT-Protocol-%EC%9D%B4%EB%9E%80
99. Google Cloud의 독립형 MQTT 브로커 아키텍처, accessed July 5, 2025, https://cloud.google.com/architecture/connected-devices/mqtt-broker-architecture?hl=ko
100. [통신 이론] MQTT, MQTT Protocol (MQTT 프로토콜) 이란? - 1 (이론편) - 공대생의 차고, accessed July 5, 2025, https://underflow101.tistory.com/22
101. MQTT란 무엇인가요? - MQTT 프로토콜 설명 - AWS, accessed July 5, 2025, https://aws.amazon.com/ko/what-is/mqtt/
102. MQTT 프로토콜 / mosquitto를 이용한 MQTT 통신 예제 - velog, accessed July 5, 2025, https://velog.io/@ssssujini99/MQTT-%ED%94%84%EB%A1%9C%ED%86%A0%EC%BD%9C-mosquitto%EB%A5%BC-%EC%9D%B4%EC%9A%A9%ED%95%9C-MQTT-%ED%86%B5%EC%8B%A0-%EC%98%88%EC%A0%9C
103. MQTT Protocol 의 특징 및 사용 - CordCat - 티스토리, accessed July 5, 2025, https://cordcat.tistory.com/181
104. 스 마 트 과 학 관사 물 인 터 넷
105. MQTT와 CoAP - velog, accessed July 5, 2025, https://velog.io/@some94/MQTT%EC%99%80-CoAP
106. InfiniBand 이해: 종합 가이드 - AscentOptics Blog, accessed July 5, 2025, https://ascentoptics.com/blog/ko/understanding-infiniband-a-comprehensive-guide/
107. Infiniband: 고속 클러스터 및 GPU를 위한 최고의 네트워크 솔루션 - FiberMall, accessed July 5, 2025, https://www.fibermall.com/ko/blog/data-center-cooling.htm
108. InfiniBand 네트워크가 HPC 데이터 센터를 강화하는 방법 - QSFPTEK, accessed July 5, 2025, https://www.qsfptek.com/ko/qt-news/how-infiniband-networks-empower-hpc-data-center.html
109. RDMA (Remote Direct Memory Access), accessed July 5, 2025, http://black-hair.tistory.com/m/177
110. RDMA에 대하여, accessed July 5, 2025, https://dev.to/synabreu/rdmae-daehayeo-2lig

111. 고빈도 거래(HFT) Definition

     Forexpedia™ by Babypips.com, accessed July 5, 2025, https://www.babypips.com/ko/forexpedia/hft

112. AI 자산운용과 투자전략 - 메리츠증권, accessed July 5, 2025, http://home.imeritz.com/include/resource/research/WorkFlow/20241016075617074K_02.pdf

113. 암호화폐 고빈도 거래: 전략 및 실질적인 통찰력

     CoinEx Academy, accessed July 5, 2025, https://www.coinex.com/ko/academy/detail/2375-what-is-high-frequency-trading-in-crypto

114. FIX 프로토콜 기초 - 그대안의작은호수, accessed July 5, 2025, https://smallake.kr/?p=2290
115. 고빈도 매매, accessed July 5, 2025, https://bjftradinggroup.com/ko/high-frequency-trading/
116. [Network] HTTP/2 - 잼있는 블로그 - 티스토리, accessed July 5, 2025, https://shinjam.tistory.com/entry/Network-HTTP2-1
117. [HTTP/2] HTTP2에 관하여 - velog, accessed July 5, 2025, https://velog.io/@18k7102dy/HTTP2-HTTP2%EC%97%90-%EA%B4%80%ED%95%98%EC%97%AC
118. [네트워크] HTTP/2 - 밝은별 개발 블로그 - 티스토리, accessed July 5, 2025, https://brightstarit.tistory.com/4
119. HOL Blocking 이란? - velog, accessed July 5, 2025, https://velog.io/@dnr6054/HOL-Blocking
120. HTTP 2.0 소개 & 통신 기술 알아보기, accessed July 5, 2025, https://inpa.tistory.com/entry/WEB-%F0%9F%8C%90-HTTP-20-%ED%86%B5%EC%8B%A0-%EA%B8%B0%EC%88%A0-%EC%9D%B4%EC%A0%9C%EB%8A%94-%ED%99%95%EC%8B%A4%ED%9E%88-%EC%9D%B4%ED%95%B4%ED%95%98%EC%9E%90

121. TCP HOL(ko/head of line) 블로킹

     HTTP/3 explained - README, accessed July 5, 2025, https://http3-explained.haxx.se/ko/why-quic/why-tcphol

122. HTTP/3와 QUIC의 이해: 네트워크 성능 향상을 위한 기술 진화 - F-Lab, accessed July 5, 2025, https://f-lab.kr/insight/understanding-http3-and-quic
123. QUIC 프로토콜이란 - velog, accessed July 5, 2025, https://velog.io/@xylopeofficial/QUIC-%ED%94%84%EB%A1%9C%ED%86%A0%EC%BD%9C%EC%9D%B4%EB%9E%80
124. [네트워크] QUIC 프로토콜, accessed July 5, 2025, https://globalman96.tistory.com/14
125. Protocol ossification - HandWiki, accessed July 5, 2025, https://handwiki.org/wiki/Protocol_ossification
126. 웹 및 스트리밍 서비스에 대한 QUIC 프로토콜 성능 분석 - AWS, accessed July 5, 2025, https://s3.ap-northeast-2.amazonaws.com/journal-home/journal/ktccs/fullText/614/journal_ktccs_10-5_587179327.pdf
127. What Is OFDMA? How Does It Enhance 802.11ax (Wi-Fi 6)? - Huawei Technical Support, accessed July 5, 2025, https://info.support.huawei.com/info-finder/encyclopedia/en/OFDMA.html
128. Analysis of the differences between Wi-Fi 6 and Wi-Fi 5 - E3S Web of Conferences, accessed July 5, 2025, https://www.e3s-conferences.org/articles/e3sconf/pdf/2023/39/e3sconf_transsiberia2023_03020.pdf
129. The Benefits of OFDMA for Wi-Fi 6 - Qualcomm, accessed July 5, 2025, https://www.qualcomm.com/content/dam/qcomm-martech/dm-assets/documents/ofdma_white_paper.pdf
130. OFDM vs. OFDMA: The Difference - Hitron Technologies Inc., accessed July 5, 2025, https://www.hitrontech.com/blog/ofdm-vs-ofdma-the-difference/
131. support.eero.com, accessed July 5, 2025, https://support.eero.com/hc/en-us/articles/28280371079707-Wi-Fi-7-Multi-Link-Operation-MLO#:~:text=Multi%2DLink%20Operation%20(MLO)%20enables%20your%20Wi%2DFi,spectrum%20of%20all%20things%20wifi.
132. Multi-Link Operation (MLO) in UniFi Network - Ubiquiti Help Center, accessed July 5, 2025, https://help.ui.com/hc/en-us/articles/25656226682775-Multi-Link-Operation-MLO-in-UniFi-Network
133. Wi-Fi 7 multi-link operation (MLO) explained - Cisco Blogs, accessed July 5, 2025, https://blogs.cisco.com/networking/wi-fi-7s-multi-link-operation-mlo-dissection-from-packets-to-performance
134. What is the 5G protocol stack? - 5G Technology World, accessed July 5, 2025, https://www.5gtechnologyworld.com/what-is-the-5g-protocol-stack/
135. 5G Control Plane & User Plane - YouTube, accessed July 5, 2025, https://www.youtube.com/watch?v=qCpMy5jLJL8

136. The 5G New Radio (NR) protocol stack

     Layer 1

     Layer 2

     Layer 3 - Techlteworld, accessed July 5, 2025, https://techlteworld.com/5g-nr-protocol-stack-layer-1layer-2layer-3/

137. System Architecture - 5G

     ShareTechnote, accessed July 5, 2025, https://www.sharetechnote.com/html/5G/5G_RadioProtocolStackArchitecture.html

138. User Plane Protocol Stacks in LTE and 5G Networks - Apeksha Telecom, accessed July 5, 2025, https://www.telecomgurukul.com/post/user-plane-protocol-stacks-in-lte-and-5g-networks
139. AN INFORMATION‑CENTRIC NETWORKING ARCHITECTURE WITH SMALL ROUTING TABLES - ITU, accessed July 5, 2025, https://www.itu.int/dms_pub/itu-s/opb/jnl/S-JNL-VOL3.ISSUE3-2022-A55-PDF-E.pdf
140. NDN Frequently Asked Questions (FAQ) - Named Data Networking (NDN), accessed July 5, 2025, https://named-data.net/project/faq/

141. Information Centric Networking Program

     NIST, accessed July 5, 2025, https://www.nist.gov/programs-projects/information-centric-networking-program

142. Recent Advances in Information-Centric Networks (ICNs) - MDPI, accessed July 5, 2025, https://www.mdpi.com/1999-5903/15/12/392
143. RFC 7927 - Information-Centric Networking (ICN) Research Challenges - IETF Datatracker, accessed July 5, 2025, https://datatracker.ietf.org/doc/rfc7927/
144. SCION (Internet architecture) - Wikipedia, accessed July 5, 2025, https://en.wikipedia.org/wiki/SCION_(Internet_architecture)

145. Traditional Internet vs. SCION Architecture

     CodiLime, accessed July 5, 2025, https://codilime.com/blog/scion-vs-traditional-internet/

146. Next-generation secure, defined internet with SCION architecture - Cloud Computing News, accessed July 5, 2025, https://www.cloudcomputing-news.net/news/next-generation-secure-defined-internet-with-scion-architecture/
147. SCION: Network Architecture of the Next Generation - cloudscale.ch, accessed July 5, 2025, https://www.cloudscale.ch/en/news/2023/12/27/scion-network-architecture-of-the-next-generation
148. The SCION Inter-domain Routing Architecture - YouTube, accessed July 5, 2025, https://www.youtube.com/watch?v=z8zgFzytBAo
149. Delay Tolerant Networking and Cubesats - NASA Technical Reports Server (NTRS), accessed July 5, 2025, https://ntrs.nasa.gov/api/citations/20140016713/downloads/20140016713.pdf
150. Delay-tolerant networking - Wikipedia, accessed July 5, 2025, https://en.wikipedia.org/wiki/Delay-tolerant_networking
151. Delay/Disruption Tolerant Networking Overview - NASA, accessed July 5, 2025, https://www.nasa.gov/technology/space-comms/delay-disruption-tolerant-networking-overview/
152. Endpoint Naming for Space Delay/Disruption Tolerant Networking - MITRE Corporation, accessed July 5, 2025, https://www.mitre.org/sites/default/files/pdf/09_5229.pdf
153. Lecture: Introduction to Delay/Disruption Tolerant Networking (1.1) - YouTube, accessed July 5, 2025, https://www.youtube.com/watch?v=2RHzIxbBJgo
154. Protocol ossification - Wikipedia, accessed July 5, 2025, https://en.wikipedia.org/wiki/Protocol_ossification
155. Ossification - HTTP/3 explained, accessed July 5, 2025, https://http3-explained.haxx.se/en/why-quic/why-ossification
156. Ossification: a result of not even trying? - IETF, accessed July 5, 2025, https://www.ietf.org/slides/slides-semiws-ossification-a-result-of-not-even-trying-00.pdf
157. RFC 9170 - Long-Term Viability of Protocol Extension Mechanisms - IETF Datatracker, accessed July 5, 2025, https://datatracker.ietf.org/doc/html/rfc9170
158. Quantum Network Protocols 101 - Number Analytics, accessed July 5, 2025, https://www.numberanalytics.com/blog/ultimate-guide-quantum-network-protocols
159. Quantum Internet: The Future of Secure Communication - BlueQubit, accessed July 5, 2025, https://www.bluequbit.io/quantum-internet
160. Quantum Internet: Technologies, Protocols, and Research Challenges - arXiv, accessed July 5, 2025, https://arxiv.org/html/2502.01653v1
161. A Quick Guide to Quantum Communication - arXiv, accessed July 5, 2025, https://arxiv.org/html/2402.15707v1
162. Quantum network - Wikipedia, accessed July 5, 2025, https://en.wikipedia.org/wiki/Quantum_network
163. Integrating Quantum Networks and Classical Networks: the Physical Layer, accessed July 5, 2025, https://www.aliroquantum.com/blog/integrating-quantum-and-classical-networks-physical-layer
164. 망중립성 - 지식덤프, accessed July 5, 2025, http://www.jidum.com/jidums/view.do?jidumId=515
165. 망 중립성 - 나무위키, accessed July 5, 2025, https://namu.wiki/w/%EB%A7%9D%20%EC%A4%91%EB%A6%BD%EC%84%B1
166. 망중립성 논의 최근 전개 동향, accessed July 5, 2025, https://ettrends.etri.re.kr/ettrends/124/0905001561/25-4_121_129.pdf
167. Peering vs. Transit Economics - The Internet Peering Playbook, accessed July 5, 2025, http://drpeering.net/HTML_IPP/chapters/ch05-1-Peering-vs-Transit-Economics/ch05-1-Peering-vs-Transit-Economics.html
168. Formal Semantics & Verification for the Border Gateway Protocol - Dada, accessed July 5, 2025, https://dada.cs.washington.edu/research/tr/2016/08/UW-CSE-16-08-01.pdf
169. Formally Verifiable Networking - andrew.cmu.ed, accessed July 5, 2025, https://www.andrew.cmu.edu/user/liminjia/research/papers/fvn-hotnets.pdf
170. Protocols to Code: Formal Verification of a Next-Generation Internet Router - arXiv, accessed July 5, 2025, https://arxiv.org/html/2405.06074v1