컴퓨터 네트워킹 하향식 접근 - Ch.2 애플리케이션 계층

컴퓨터 네트워킹 하향식 접근 | 최종원 - 교보문고

책 구매 또는 완독이 부담스럽다면 아래 레포지토리를 참고해도 충분할 것이다. 복습용도로 봐도 매우 유용

Computer-Networking_A-Top-Down-Approach/Chapter_2 at main · IT-Book-Organization/Computer-Networking_A-Top-Down-Approach

Ch.2 애플리케이션 계층

총평

네트워크 공부엔 끝이 없는 것 같다. 수많은 개념들이 유기적으로 거미줄처럼 뻗어나간달까..

그래서 가장 자주 쓰이는 용어들(프로세스, 서버, 클라이언트, 소켓 등)부터 제대로 깊이 이해해야겠다고 생각했다.

아래 `하위 챕터 요약`을 읽어보면 알겠지만 읽어보면 당연한 뜻인데 당연하지 못하게 용어의 진짜 의미를 파악하지 않고 피상적으로 공부해왔다.

이제는 확실히 짚고넘어가야될 개념 위주로 정리했다.

비전공자에게 알려줘도 이해할 수 있도록 깊이 공부해봐야겠다.

 

좀 황당했던 건 

트랜스포트 프로토콜이 애플리케이션에 제공할 수 있는 4가지 서비스(신뢰성, 처리율, 시간, 보안)을 알려줘놓고는 정작 실제로 제공되는 서비스는 TCP의 신뢰성 보장 말곤 없었다.

이론만 그럴싸하고 TCP에서 딱 하나 보장해주는 건데 왜 저렇게 거창하게 써놓은 건지 이해가 안됐다. 이론서인데 전개 방식이 소설책 같음. 내가 해석을 잘못 한 건가? 미국 교과서 특인가?

 

그래서 애플리케이션 계층에서 트랜스포트 계층에서 해결 못한 처리율, 시간, 보안을 보장하기 위한 솔루션들이 많이 발전했다는 것을 알 수 있었다.

ex) TCP 보안 문제를 TLS로 보완

하위 챕터 요약

책에 없는 내용도 있을 수 있음

심화 내용 없음

언제 읽든 읽고 바로 이해되도록 최대한 쉽게 씀

내용이 너~~무 많아서 2-3, 2-4, 2-5, 2-6, 2-7 하루 1개씩 업뎃 예정

 

Written with Gemini 3 Pro 🤖

1. 네트워크 애플리케이션의 원리

네트워크 애플리케이션 개발은 서로 다른 종단 시스템에서 동작하는 프로그램(서버, 클라이언트 등)을 작성하는 것이다.

코어 장비는 애플리케이션 계층에서 기능하지 않으므로 개발자는 종단 시스템 간의 논리적 통신 구현에만 집중하면 된다.

 

P2P 구조는 항상 켜져 있는 인프라 서버에 최소로 의존하며 간헐적으로 연결된 피어들이 서로 직접 통신하는 방식이다.

피어가 작업을 요청함과 동시에 서비스를 분배하는 주체가 되어 시스템의 처리 능력을 스스로 높이는 자가 확장성(Self-scalability)이 핵심 특징이다.

 

프로세스는 각 종단 시스템에서 현재 실제로 실행되고 있는 프로그램을 의미하며, 통신은 서로 다른 호스트에서 동작하는 프로세스들이 컴퓨터 네트워크를 통해 메시지를 교환함으로써 이루어진다.

 

클라이언트 프로세스는 두 프로세스 간의 통신 세션에서 세션을 시작하기 위해 접속을 초기화하는 프로세스이다.

서버 프로세스는 세션을 시작하기 위해 접속을 기다리는 프로세스이다.

 

프로세스는 소켓(socket)을 통해 네트워크로 메시지를 주고 받는다.

 

소켓은 호스트의 애플리케이션 계층과 트랜스포트 계층간의 인터페이스다.

애플리케이션과 네트워크 사이의 API라고 할 수 있다.

 

IP 주소는 네트워크상에서 메시지를 수신할 호스트를 식별하기 위해 필요하며, 포트 번호는 해당 호스트 내에서 실행 중인 특정 수신 프로세스를 지정하기 위해 필요하다.

애플리케이션 프로세스는 소켓을 인터페이스로 활용하여 네트워크로 메시지를 송수신한다.

프로세스 간 통신은 송신 프로세스가 소켓을 통해 메시지를 내보내면 네트워크를 거쳐 수신 측 소켓을 통해 상대방 프로세스로 전달되는 흐름이다.

 

트랜스포트 프로토콜이 애플리케이션에 제공할 수 있는 4가지 서비스(이상적 이론, 실제로는 TCP만 신뢰성 보장 😑)

• 신뢰적 데이터 전송(Data Integrity): 패킷 손실이 발생할 수 있는 환경에서도 데이터가 오류 없이 수신 프로세스에 도착하도록 보장하는 서비스이다.
• 처리율(Throughput): 멀티미디어처럼 대역폭에 민감한 애플리케이션을 위해 네트워크 상태와 무관하게 일정 수준 이상의 전송 속도를 보장해 주는 것이다.
• 시간(Timing): 실시간 상호작용이 필요한 애플리케이션을 위해 송신된 데이터가 수신 측에 특정 시간 내에 도착하도록 보장하는 서비스이다.
• 보안(Security): 송신 측에서 데이터를 암호화하여 보내고 수신 측에서 이를 해독함으로써 데이터의 기밀성을 지키는 기능이다.

TCP, UDP 핵심 요약

• TCP: 클라이언트와 서버가 핸드셰이킹을 통해 연결을 먼저 맺는 연결 지향형 프로토콜로, 데이터의 순서와 신뢰성을 보장하며 네트워크 혼잡 시 속도를 조절하는 혼잡 제어(3장에서 자세히) 기능을 제공한다.
• UDP: 핸드셰이킹 과정이 없는 비연결형 프로토콜로 데이터의 신뢰성을 보장하지 않으며, 혼잡 제어 기능이 없어 네트워크 상황과 관계없이 데이터를 전송할 수 있다.

TCP와 UDP는 처리율이나 전송 시간 지연에 대한 보장 서비스를 제공하지 않는다(보안 포함). 시간 민감 애플리케이션은 이에 최대한 대처하도록 설계되지만, 근본적인 보장이 없으므로 지연이 과도해지면 서비스 품질 유지에 한계가 있다.

 

트랜스포트 계층에서 제공되지 않는 서비스를 애플리케이션 계층에서 어떻게 보완해주는가 👇

 

- 처리율

 

• 데이터 압축(Compression): 네트워크 대역폭을 물리적으로 늘릴 수는 없으니 애플리케이션이 데이터를 보내기 전에 압축하여 용량을 줄임으로써 낮은 처리율에서도 원활하게 전송되도록 한다.
• 적응형 비트레이트(Adaptive Bitrate): 현재 가용한 대역폭을 실시간으로 감지하여, 대역폭이 부족하면 즉시 미디어 품질(화질/음질)을 낮춰 끊김을 방지한다.
• 다중 소스 다운로드(P2P 등): 하나의 서버에서만 받는 게 아니라, P2P처럼 여러 소스(피어)로부터 동시에 데이터를 쪼개 받아 전체적인 전송 속도를 높인다.
• CDN 활용: 물리적으로 멀어서 느린 서버 대신 사용자와 가까운 캐시 서버에서 데이터를 가져와 전송 속도를 높인다.

 

- 시간

 

• 버퍼링(Buffering): 수신 측에서 데이터를 바로 재생하지 않고 잠시 모아두었다가 재생한다. 도착 시간이 불규칙해도(Jitter) 버퍼에 쌓아둔 데이터 덕분에 끊김 없이 보여줄 수 있다.
• 적응형 비트레이트(Adaptive Bitrate): 네트워크 속도가 느려지면 애플리케이션이 스스로 화질을 낮춰서 데이터를 적게 받는다.
• UDP 사용: 실시간성이 매우 중요한 게임이나 화상 통화는 TCP의 재전송 과정(지연 유발)을 피하기 위해 데이터가 좀 깨지더라도 속도가 빠른 UDP를 사용하여 지연을 최소화한다.
• CDN 활용: 물리적인 거리를 줄이기 위해 사용자와 가까운 CDN에 콘텐츠를 두어 지연 시간을 단축한다.

- 보안

 

• TLS/SSL 암호화: TCP 소켓으로 데이터를 내려보내기 직전에 애플리케이션 계층에서 암호화(Encryption)를 수행한다. 중간에서 패킷을 가로채도 내용을 알 수 없도록 한다. (ex - HTTP → HTTPS)
• 사용자 인증(Authentication): 트랜스포트 계층은 사용자가 누구인지 관심이 없으므로 애플리케이션 계층에서 아이디/비밀번호나 토큰을 이용해 접속 권한을 확인한다.
• 무결성 검사(Integrity Check): 데이터가 전송 도중 위변조되지 않았는지 확인하기 위해 애플리케이션 단에서 전자 서명이나 해시(Hash) 값을 비교하여 검증한다.

 

애플리케이션 계층 프로토콜에 정의된 내용

• 교환하는 메시지의 타입과 문법(구조)
• 필드 정보의 의미(시맨틱스)
• 프로세스가 언제 어떻게 메시지를 전송하고 응답할지 결정하는 규칙

이 책은 중요하고 인기 있는(근거가 뭐지?) 5개의 애플리케이션 분야를 나눠서 설명한다.

• 웹
• 전자메일
• 디렉터리 서비스
• 비디오 스트리밍
• P2P 애플리케이션

2. 웹과 HTTP

온디맨드(On-demand)는 라디오나 TV 방송처럼 정해진 시간표에 따라 일방적으로 정보를 받는 것이 아니라, 사용자가 원하는 시점에 직접 요청하여 즉시 데이터를 받아보는 방식을 의미한다.

웹에서 링크를 클릭하거나 주소를 입력해 원하는 페이지만 골라 보는 것이 대표적인 온디맨드 방식이다.

 

웹 서버는 HTML 파일이나 이미지 같은 데이터(객체)를 저장하고 있으며, 각 파일마다 고유한 URL 주소가 할당되어 있어 클라이언트가 주소만 알면 수많은 파일 중 원하는 것을 정확히 지목해 가져올 수 있다.

 

TCP(Transmission Control Protocol) 연결이 맺어진 후 클라이언트와 서버는 각자의 소켓 인터페이스를 통해 메시지를 주고받는다.

이때 HTTP는 데이터 신뢰성 확보를 위한 복잡한 과정을 TCP에 위임함으로써 애플리케이션 로직에만 집중할 수 있다는 것이 네트워크 계층 구조의 장점이다.

 

비지속 연결(Non-persistent Connection) vs 지속 연결(Persistent Connection)

• 비지속 연결
  • HTTP 1.0에서 사용하는 방식으로 각 요청/응답 쌍마다 별도의 TCP 연결을 매번 새롭게 생성하고 종료하는 구조이다.
  • 객체 하나를 전송받을 때마다 3-way handshake 과정을 거쳐야 하므로 매번 2RTT의 지연 시간이 발생하고 서버에 큰 부하를 주는 단점이 있다.

• 지속 연결
  • HTTP/1.1의 기본 모드로 서버가 응답을 보낸 후에도 TCP 연결을 끊지 않고 유지하여 여러 객체를 하나의 연결로 연속해서 주고받는 방식이다.
  • 반복적인 연결 설정 비용을 아낄 수 있으며, 특히 파이프라이닝을 통해 앞선 요청의 응답을 기다리지 않고 연속적으로 요청을 보낼 수 있어 효율적이다.

HTTP 요청 메시지 포맷

• 사람이 읽을 수 있는 ASCII 텍스트로 작성되며, 각 줄은 CR(Carriage Return)과 LF(Line Feed)로 구분된다(응답 메시지도 동일).
• 요청 라인 (Request Line)
  • 수행할 동작을 나타내는 방식(Method), 대상 URL, HTTP 버전 필드
• 헤더 라인 (Header Lines)
  • Host(호스트 명), Connection(지속/비지속 연결 여부), User-agent(브라우저 정보) 등 서버가 요청을 처리하는 데 필요한 부가 정보
• 방식 (Method)
  • GET(데이터 요청), POST(폼 입력 데이터 전송), HEAD(디버깅용, 객체 없이 응답), PUT(파일 업로드), DELETE(파일 삭제) 등
• 개체 몸체 (Entity Body)
  • GET 방식에서는 비어 있음
  • POST 방식에서는 사용자가 폼에 입력한 데이터 등을 서버로 보낼 때 사용

HTTP 응답 메시지 포맷

• 상태 라인 (Status Line)
  • HTTP 버전과 요청 처리 결과를 나타내는 상태 코드(예: 200, 404) 및 상태 메시지(예: OK, Not Found)
• 상태 코드 (Status Code)
  • 200 OK(성공), 301 Moved Permanently(영구 이동), 400 Bad Request(요청 오류), 404 Not Found(파일 없음) 등 요청의 성공 여부를 숫자로 표현
• 헤더 라인 (Header Lines)
  • Connection(연결 유지 여부), Date(응답 생성 시간), Server(서버 소프트웨어 정보), Last-Modified(객체 마지막 수정 시간) 등의 메타데이터 정의
  • 콘텐츠 정보 헤더
    • Content-Length: 전송되는 객체의 바이트 수
    • Content-Type: 객체의 미디어 타입(ex - text/html)
• 개체 몸체 (Entity Body)
  • 헤더 다음에 오는 실제 데이터 영역
  • 클라이언트가 요청한 HTML 파일이나 이미지 등의 데이터

🍪 쿠키

HTTP 서버는 상태를 유지하지 않는 비상태 프로토콜이므로, 사용자 접속 제한이나 맞춤형 콘텐츠 제공을 위해 사용자를 식별하는 수단으로 쿠키를 사용한다.

브라우저가 웹 서버에게 HTTP 요청 메시지를 전달하면

웹 서버는 유일한 식별 번호를 만들고 이 식별 번호로 인덱싱되는 백엔드 데이터베이스 안에 엔트리를 만든다.

서버가 HTTP 응답 메시지 응답 헤더에 고유 식별 번호를 담아 전달하면(`Set-cookie: {식별 번호}`)

브라우저가 이를 저장해 두었다가 이후 재요청 시 해당 식별 번호를 헤더에 포함(`Cookie: {식별 번호}`)해 보냄으로써 서버가 사용자를 인식하는 원리이다.

 

웹 캐시 (프록시 서버)

웹 캐시는 기점 서버(Origin Web Server)를 대신하여 클라이언트의 HTTP 요청을 직접 처리하는 개체이다.

자체 저장 공간에 최근 브라우저에서 호출된 객체의 사본을 저장 및 보존한다.

브라우저가 웹 캐시와 TCP 연결을 설정하고 HTTP 요청을 보내면, 웹 캐시는 요청된 객체의 사본이 내부에 저장되어 있는지 확인한다.

만약 저장되어 있다면 즉시 클라이언트에게 객체를 전송하여 응답 시간을 단축시킨다.

저장되어 있지 않다면 웹 캐시가 기점 서버와 새로운 TCP 연결을 맺고 객체를 요청해 받아온 뒤, 이를 로컬 저장소에 복사하고 클라이언트에게 전달한다.

이 과정에서 웹 캐시는 클라이언트에게는 서버 역할, 기점 서버에게는 클라이언트 역할을 동시에 수행한다.

클라이언트와 캐시 간의 고속 LAN 연결을 활용하여 응답 시간을 줄이고, 웹 트래픽 강도를 낮추어 전체적인 네트워크 병목 현상을 해결한다.

일반적으로 웹 캐시는 ISP(대학, 기업, 가정용)가 구입하고 설치한다.

 

HTTP2

HTTP/2는 HTTP/1.1의 느린 응답 속도를 개선하기 위해 등장했다.

특히 HOL 블로킹 문제와 비효율적인 다중 TCP 연결 방식을 해결하는 데 집중한다.

• HOL 블로킹(Head of Line Blocking)
  • 하나의 통신 통로에서 먼저 요청된 용량이 큰 데이터(ex - 비디오)가 전송될 때까지 뒤따르는 작은 데이터들이 기다려야 하는 지연 현상
• 해결책
  • TCP 혼잡 제어
    • 네트워크 병목 구간에서 여러 연결이 대역폭을 공평하게 나눠 쓰도록 각 연결의 데이터 전송 속도를 스스로 조절하는 메커니즘
  • 프레이밍(Interleaving)
    • 하나의 큰 메시지를 작은 단위(프레임)로 잘게 쪼개고 순서를 섞어 전송한 뒤, 수신 측에서 다시 원래대로 조립하는 기술
    • 프레이밍 서브 계층은 프레임을 바이너리 인코딩
      • 바이너리 포맷
        • 메시지를 사람이 읽는 텍스트가 아닌 컴퓨터가 처리하기 쉬운 이진 코드로 변환하여 전송하는 방식
        • 데이터 크기가 줄고 컴퓨터가 해석(파싱)하는 속도가 훨씬 빨라짐
  • 메시지 우선순위화
    • 클라이언트가 요청마다 1~256 사이의 가중치를 부여해 데이터의 중요도를 지정하는 기술
    • 서버는 가중치가 높은 데이터 프레임을 먼저 전송하여 애플리케이션 성능 최적화
  • 서버 푸시
    • 클라이언트가 먼저 요청하지 않아도 웹 페이지 로딩에 꼭 필요할 것이라고 예측되는 리소스(CSS, 이미지 등)를 서버가 알아서 미리 보내주는 기능

이런 해결책 덕분에 하나의 TCP 연결로도 큰 데이터 대기 없이 여러 요청을 동시에 처리할 수 있다.

3. 인터넷 전자메일

 

4. DNS: 인터넷의 디렉터리 서비스

 

5. P2P 파일 분배

 

6. 비디오 스트리밍과 콘텐츠 분배 네트워크

 

7. 소켓 프로그래밍: 네트워크 애플리케이션 생성