응용 계층

응용 계층은 네트워크에서 사용자가 직접 사용하는 서비스들이 동작하는 계층이다. 웹 브라우징, 이메일, 파일 전송, 스트리밍 등 모든 인터넷 애플리케이션이 바로 이 응용 계층에서 작동한다.
응용 계층을 학습하는 목적
응용 계층 학습의 핵심 목표는 다음과 같다:
- 응용 계층 프로토콜의 개념적 구조와 구현 방식을 모두 이해한다.
- 전송 계층 서비스 모델(Transport-layer service model) 을 이해한다.
- 클라이언트-서버 패러다임(Client-Server paradigm) 과 피어-투-피어 패러다임(Peer-to-Peer paradigm) 을 비교 분석한다.
- HTTP, SMTP, IMAP, DNS, 영상 스트리밍 시스템, CDN 등 실제로 사용되는 응용 계층 프로토콜을 분석한다.
- 소켓 API를 활용한 네트워크 애플리케이션 프로그래밍을 실습한다.
왜 전송 계층 모델을 이해해야 하는가?
응용 계층은 소프트웨어이다. 한 호스트에서 실행되는 응용 소프트웨어는 네트워크를 통해 다른 호스트의 소프트웨어와 데이터를 주고받아야 한다. 이때 실제 연결을 담당하는 것은 전송 계층이다. 전송 계층은 응용 계층의 데이터를 받아 상대방 호스트의 응용 계층까지 논리적인 연결(logical connection) 을 만들어준다. 따라서 응용 계층을 이해하려면 그 아래 전송 계층의 지원 방식과 특징을 반드시 이해해야 한다.
네트워크의 기본 목적
네트워크의 목적은 본질적으로 단순하다: 데이터를 한 쪽에서 다른 쪽으로 전달하는 것이다. 편지를 전달한다고 생각하면, 직접 전달할 수도 있고, 우체국을 통해 간접적으로 전달할 수도 있다. 네트워크 구조에서도 이와 같은 두 가지 방식이 존재한다:
- 클라이언트-서버(Client-Server): 사용자는 편지를 우체국에 맡기고, 우체국은 이를 수신자에게 전달한다. 서버는 항상 켜져 있고 고정된 IP를 가지고 있으며, 다수의 클라이언트가 요청을 보낸다.
- 피어-투-피어(Peer-to-Peer): 사용자끼리 직접 데이터를 주고받는다. 서버 없이 네트워크 상의 각 노드가 동시에 클라이언트이자 서버 역할을 수행한다.
응용 계층에서 사용하는 대표적인 프로토콜
응용 계층에서 사용되는 대표적인 프로토콜은 다음과 같다:
- HTTP: 웹 브라우징 서비스에 사용되는 하이퍼텍스트 전송 프로토콜
- SMTP, IMAP: 이메일 송수신에 사용되는 메일 전송 프로토콜
- DNS: 도메인 이름을 IP 주소로 매핑해주는 도메인 이름 시스템
이러한 서비스들은 각자 자신만의 클라이언트 소프트웨어와 서버 소프트웨어를 필요로 하며, 애플리케이션을 설치하면 해당 기능을 담당하는 클라이언트가 내 장치에 설치된다.
응용 프로그래밍과 소켓 API
응용 계층 프로그래밍은 소켓(Socket) API를 사용하여 이루어진다. 소켓은 프로세스 간 메시지를 주고받는 문(door) 과 같은 역할을 한다. 응용 프로그래머는 데이터를 소켓을 통해 전송하거나 수신하면 되고, 그 이후의 전달 과정은 전송 계층 이하의 계층에서 처리해준다.
프로세스 통신 (Process Communication)
응용 계층은 소프트웨어지만, 이 소프트웨어는 실행될 때 프로세스라는 형태로 시스템 내에서 동작한다. 중요한 점은, 네트워크 통신은 소프트웨어 간의 통신이 아닌, 프로세스 간의 통신이라는 것이다.
- 프로세스(Process): 운영체제로부터 CPU 시간을 할당받아 실행되는 프로그램의 일부
- 따라서 네트워크에서 데이터가 오간다는 것은 프로세스 간 메시지 전달을 의미한다.
두 프로세스 간의 통신은 다음과 같이 나뉜다:
- 동일한 호스트 내에서는 운영체제의 Inter-Process Communication (IPC) 메커니즘을 통해 통신한다.
- 다른 호스트 간에는 전송 계층을 통해 통신하며, 이때 연결을 설정하는 계층이 바로 전송 계층(Transport Layer) 이다.
클라이언트 프로세스와 서버 프로세스
네트워크 통신은 항상 두 개의 프로세스 사이에서 이루어진다:
- 클라이언트 프로세스(Client Process): 통신을 시작하는 쪽
- 서버 프로세스(Server Process): 요청을 수신하고 응답하는 쪽
예를 들어 이메일을 보낼 때, 사용자 애플리케이션은 클라이언트 프로세스가 되고, 수신자의 메일 서버는 서버 프로세스가 된다.
소켓 프로그래밍 (Socket Programming)
프로세스 간 통신은 소켓(Socket) 이라는 추상화된 인터페이스를 통해 이루어진다. 소켓은 데이터를 내보내는 문(door) 과 같으며, 다음과 같은 특징이 있다:
- 하나의 프로세스는 하나 이상의 소켓을 가질 수 있다.
- 메시지는 소켓을 통해 출입하며, 다른 쪽 호스트의 소켓과 연결된다.
- 소켓 프로그래밍은 응용 계층 프로세스가 데이터를 소켓에 “던지는 것(show out the door)”으로 요약할 수 있다.
- 그 이후의 데이터 전달(라우팅, 오류 복구 등)은 전송 계층 이하의 계층이 책임진다.
즉, 소켓은 프로세스와 전송 계층 사이의 인터페이스라고 이해할 수 있다.

프로세스 식별자: IP 주소와 포트 번호
네트워크 상에서 통신하는 각 프로세스를 정확히 식별하려면 두 가지 정보가 필요하다:
- IP 주소: 호스트 자체를 식별
- 포트 번호(Port Number): 호스트 내부에서 어떤 프로세스인지 구분
예를 들어, 두 사람이 같은 집(같은 호스트)에 살고 있다면, 집 주소는 같아도 **이름(포트 번호)**으로 누구에게 보내는지를 구분해야 한다.
- HTTP 서버의 포트 번호는 80
- 메일 서버(SMTP)의 포트는 25
이러한 포트 번호는 잘 알려진 서비스에 대해 고정된 번호(well-known port)가 존재하며, 그 외의 일반 응용 프로그램은 임의의 포트 번호를 선택할 수 있다.
전송 계층 서비스 설계 시 고려 요소
응용 계층 프로세스를 설계할 때, 개발자는 자신의 앱이 어떤 전송 계층 서비스를 요구하는지를 결정해야 한다. 전송 계층(TCP 또는 UDP)을 선택할 때 고려해야 할 요소들은 다음과 같다:
- 데이터 무결성(Data Integrity)
- 중요한 메시지가 손상되면 안 되는 경우 (예: “I love you” → “I kill you”)
- 신뢰성 있는 전송이 필요하면 TCP
- 타이밍(Timing)
- 실시간 통신(VoIP, 게임 등)은 지연이 낮아야 한다
- 일부 지연 허용 시 UDP 사용 가능
- 처리량(Throughput)
- 멀티미디어, 스트리밍 등의 앱은 최소 처리량 보장이 필요
- 어떤 앱은 주어진 처리량만큼만 사용 (Elastic app: 예 – 이메일)
- 보안(Security)
- 암호화, 인증이 필요한 경우 보안 프로토콜(TLS 등)을 적용
이러한 요소들을 종합적으로 고려하여 적절한 전송 계층 서비스(TCP/UDP)를 선택하고, 필요한 경우 보안 계층과의 연동도 검토해야 한다.
네트워크 중심 장비와 응용 계층
네트워크 상에서 데이터가 흐를 때, 라우터나 스위치 같은 네트워크 장비는 응용 계층의 내용을 읽지 않는다. 그들은 오직 패킷의 **주소 정보(IP 헤더)**만을 기반으로 데이터를 전달(routing)할 뿐이다. 따라서:
- 응용 계층은 엔드 호스트에만 존재한다.
- 네트워크 장비는 사용자 애플리케이션을 실행하지 않는다.
- 응용 프로그램은 오직 사용자 호스트에서만 개발되며 실행된다.
이 구조는 계층화된 네트워크 구조(layered architecture)의 핵심 장점 중 하나로, 개발자는 다른 계층의 세부 구현을 신경 쓰지 않고 자신의 애플리케이션에 집중할 수 있다
클라이언트-서버 패러다임 vs 피어-투-피어 패러다임
응용 계층에서의 데이터 전송 방식은 크게 두 가지로 구분된다:
1. 클라이언트-서버 패러다임 (Client-Server)
- 서버는 항상 켜져 있고(Always-on), 고정된 IP 주소를 가진다.
- 다수의 클라이언트가 서버에 요청을 보내고, 서버는 응답을 준다.
- 서버는 하나의 장소에 여러 대를 모아 데이터 센터(Data Center)를 구성할 수 있다.
- 예: Netflix는 미국뿐 아니라 한국에도 서버를 두고, 점점 더 많은 사용자가 생기면 새로운 데이터 센터를 추가한다.
- 클라이언트는 일시적으로 연결될 수 있으며(IP가 고정되지 않음), 이를 동적 IP(Dynamic IP)라고 한다.

2. 피어-투-피어 패러다임 (Peer-to-Peer)
- 서버가 필요 없다. 네트워크 참여자(Peer)들이 서로 직접 통신한다.
- 각 Peer는 클라이언트이자 서버 역할을 동시에 수행할 수 있다.
- 새로운 Peer가 네트워크에 참여하면 전체 자원이 증가한다 → Self-scalable
- 예: BitTorrent 등 파일 공유 시스템
하지만 피어-투-피어 네트워크는 다음과 같은 복잡한 문제가 있다:
- 노드 간의 연결 상태가 계속 변한다.
- 어떤 노드는 더 빠른 링크를 가지고 있고, 어떤 노드는 느리다.
- 특정 Peer와 연결을 유지하다가 더 빠른 Peer가 생기면 다시 연결을 바꿔야 한다.

이런 복잡한 구성 관리를 우리가 직접 처리해야 하므로 클라이언트-서버보다 복잡한 구조를 가진다.
IP 주소와 포트 번호
데이터 센터(Data Center)와 클라이언트-서버 모델의 확장성
대형 서비스인 Netflix나 YouTube 같은 경우, 단일 서버로는 수많은 사용자의 요청을 감당할 수 없다. 이를 해결하기 위해 동일한 기능을 하는 여러 서버를 묶어서 한 장소에 배치하고, 이를 Data Center(데이터 센터) 라고 부른다.
- 예: Google이 한국에서 사용자가 많아지면 한국에도 데이터 센터를 세운다.
- 때로는 토지를 임대하거나, 개인이 지은 데이터 센터를 Google이나 Naver 같은 회사에 임대해주기도 한다.
Data Center는 클라이언트-서버 모델에서의 확장성(Scalability) 을 확보하기 위한 핵심 인프라이다.
동적 IP 주소(Dynamic IP Address)와 주소의 중요성
네트워크에서 데이터를 전달하기 위해서는 주소(Address) 가 반드시 필요하다.
즉, 우리가 인터넷 서비스를 신청할 때는 사실상 IP 주소를 구매하는 것과 같다.
정적 vs. 동적 IP 주소
- 정적 IP 주소 (Static IP): 고정된 주소, 항상 동일함.
- 동적 IP 주소 (Dynamic IP): 시간이 지남에 따라 바뀌는 주소 → 한국어로는 유동 IP (Floating IP) 라고도 부름
주소 비유
- 예를 들어 “11104”라는 학번을 가진 학생이 건국대학교에 있을 때는 식별이 가능하다.
- 하지만 이 학생이 세종대학교로 이동하면, 똑같이 “11104”를 불러도 아무도 반응하지 않는다. → 이는 해당 주소가 사설 네트워크(Private Address) 에서만 유효했기 때문
따라서 공인 IP 주소(Public IP Address) 는 글로벌하게 유일해야 하며, 주로 IPv4의 경우 32비트로 구성된다.
사설 IP 주소와 ISP
일반적으로 우리가 사용하는 노트북이나 PC는 다음과 같은 사설 IP 주소 대역을 사용한다:
- 예: 192.168.x.x → 이는 Private IP Address
- 사설 주소는 ISP(Internet Service Provider, 인터넷 서비스 제공자)들이 사전에 IP 주소 대역을 구매해서 사용자들에게 나눠주는 것이다.
IP 주소는 왜 비싸나?
- 공인 IP 주소는 한정된 자원이라 가격이 비싸다.
- 따라서 대부분의 가정용 인터넷은 유동 IP 혹은 사설 IP를 사용한다.
프로토콜의 구성 요소: Syntax, Semantics, Timing
응용 계층에서 새로운 프로토콜을 설계하려면 반드시 다음 세 가지 요소를 정의해야 한다:
1. Syntax (문법)
- 메시지의 구조: 어떤 필드를 포함하며, 필드들이 어떤 순서로, 어떤 구분자로 나뉘는가?
- 예: 처음 32비트는 송신자 주소, 그 다음 32비트는 수신자 주소 등
2. Semantics (의미)
- 각 필드가 의미하는 바
- 예: 특정 필드는 요청인지 응답인지 나타내며, 또 다른 필드는 데이터 길이를 나타낸다
3. Timing (타이밍)
- 언제 메시지를 전송하고, 응답을 언제 받아야 하는가?
- 타이밍이 어긋나면 전혀 다른 의미로 해석될 수 있다
- 예: "사랑해" 메시지를 5분 후에 받으면 오해가 생길 수 있다
이 세 가지를 명확하게 정의해야만, 프로토콜이 명확하고 상호 운용 가능한(open and interoperable) 시스템으로 작동할 수 있다.
프로토콜 문서: RFC (Request for Comments)
- 모든 공개 프로토콜은 RFC 형식의 문서로 작성된다.
- IETF(Inernet Engineering Task Force)에서 관리하며, 누구나 ietf.org에서 열람 가능하다.
- 이러한 프로토콜은 표준화된 공개 시스템이기 때문에 상호 호환성과 자유로운 사용이 가능하다.
반대로, Proprietary Protocol은 특정 기업이 소유한 프로토콜로, 공개되지 않고 사용에 제약이 있다. 예:
애플리케이션별 서비스 선택 예시
이메일 | TCP | 신뢰성이 중요, 속도는 덜 중요 |
웹 브라우징 | TCP | HTML 문서는 무결성이 필요함 |
동영상 스트리밍 | UDP or TCP | 버퍼링 허용 시 UDP, 높은 신뢰성 필요 시 TCP |
인터넷 전화 (VoIP) | UDP | 실시간성 우선, 손실 약간 허용 가능 |
온라인 게임 | UDP | 지연이 중요, 일부 손실 허용 |
파일 다운로드 | TCP | 데이터 손실 없이 정확하게 받아야 함 |
애플리케이션 설계자의 역할
응용 계층 프로그래머는 직접 전송 계층을 구현하지 않는다. 하지만 자신의 애플리케이션이 어떤 전송 계층 서비스가 필요한지 판단해야 한다.
즉, 응용 계층은 전송 계층의 다양한 서비스 모델 중에서 어떤 것을 요청할지 결정하는 책임을 가진다.
이를 가능하게 해주는 것이 바로 **계층적 네트워크 구조(layered architecture)**이며, 각 계층이 명확히 역할을 나누고 있기 때문에, 응용 계층 개발자는 자신의 관심사에만 집중할 수 있다.
주요 응용 계층 프로토콜 소개
응용 계층에서 동작하는 대표적인 프로토콜들은 다음과 같다:
1. HTTP (HyperText Transfer Protocol)
- 웹 서비스에 사용되는 가장 널리 쓰이는 프로토콜
- 클라이언트(브라우저)와 서버(웹서버) 간의 통신
- 비연결 지향(Stateless) 방식으로 작동
- 요청-응답 후 연결을 끊는다
- 메시지 구조:
- 요청(Request): GET, POST 등 메서드와 경로, 버전 포함
- 응답(Response): 상태 코드(200 OK, 404 Not Found 등)와 함께 데이터 전송
- 동작 흐름:
- 사용자가 웹 브라우저에 URL 입력
- 브라우저가 해당 서버로 GET 요청
- 서버가 응답 메시지 반환 (HTML, 이미지 등 포함)
- 브라우저가 결과를 렌더링하여 사용자에게 표시
2. SMTP (Simple Mail Transfer Protocol)
- 이메일 전송용 프로토콜
- 클라이언트 → 서버, 서버 → 서버 간 이메일 발송 전용
- 푸시 기반(Push-based) 통신
- 메시지 구조는 일반 텍스트로 구성되며, 메시지 헤더(제목, 수신자 등)와 본문 포함
- 동작 흐름:
- 사용자가 메일 클라이언트를 통해 메일 작성
- SMTP를 통해 메일 서버로 전송
- 목적지 메일 서버로 전달
- 수신자는 IMAP/POP3로 메일 읽음 (SMTP는 받는 데 사용되지 않음)
3. DNS (Domain Name System)
- 도메인 이름을 IP 주소로 변환하는 서비스
- 사용자가 기억하기 쉬운 주소(예: google.com)를 입력하면,
- DNS가 이를 IP 주소(예: 142.250.206.78)로 매핑
- *계층적 구조(Hierarchical)**로 구성된 네임 서버 시스템
- 루트 서버 → TLD 서버 → 권한 있는 네임서버
- 메시지 구조:
- 쿼리(Query): 호스트 이름을 포함
- 응답(Response): 해당 호스트의 IP 주소 포함
- DNS는 UDP 포트 53을 기본적으로 사용하지만, 일부 응답은 TCP로 전송됨 (특히 큰 응답이나 DNSSEC)
'CS 지식 > 네트워크' 카테고리의 다른 글
[네트워크] 웹 캐시와 HTTP framing (1) | 2025.04.04 |
---|---|
[네트워크] 전송계층과 HTTP와 쿠키(Cookie) (1) | 2025.04.01 |
[네트워크] 네트워크 계층 구조와 보안 입문 (0) | 2025.03.25 |
[네트워크] 네크워크 코어, 스위칭, 인터넷 아키텍처, 처리량 (0) | 2025.03.23 |
[네트워크] 인터넷의 구조와 네트워크의 종류와 발전과정 (1) | 2025.03.23 |
댓글