본 글은 Computer Networking: a Top Down Approach의 Principles of Network Applications 챕터를 정리한 글로, 앱 계층에 대한 전반적인 설명과, 함께 사용되는 전송 계층 프로토콜, 앱 프로토콜에 대한 내용을 기반으로 작성되었습니다.

🟢 개요

• 네트워크 앱은 네트워크의 핵심으로, 인터넷의 성공을 이끈 원동력이었다.

• 네트워크 앱

  • 70-80년대: 이메일, 컴퓨터 원격 접속, 파일 전송, 인터넷 뉴스 등

  • 90년대: 웹 서핑, 검색, 전자 상거래 (이것들을 아우르는 WWW)

  • 2000년대 이후: 화상 회의, 너튜브, OTT, 온라인 게임, SNS

🟢 네트워크 앱의 원리

• 네트워크 앱의 핵심은 서로 다른 end system에서 실행되고,
  네트워크를 통해 서로 통신한다는 것이다.

• 그 예시로 호스트에서 실행되는 브라우저와 웹 서버에서 실행되는 서버 프로그램이 있다. 두 프로그램이 서로 통신한다.

• 따라서 앱을 개발할 때는 여러 end system에서 실행될 SW를 구현해야 한다.
  (각종 프로그래밍 언어로 구현 가능)

• 여기서 핵심은 라우터, 링크 스위치와 같은 네트워크 장치의 소프트웨어를 구현할 필요는 없다는 것이다.

• 이렇게 end system에만 한정하는 기본 설계 덕분에,
  네트워크 앱의 신속한 개발 및 배포가 가능하다.

🟡 네트워크 앱 아키텍처

• 고정되어 있는 네트워크 아키텍처와 다르게,
  앱 아키텍처는 앱 개발자가 설계하고, 다양한 end system에서 어떻게 구조화되는 지를 의미한다.

• 보통 두 가지 주요 아키텍처 중 하나를 선택한다.

  • 클라이언트-서버 아키텍처

  • P2P(Peer-To-Peer) 아키텍처

🟠 클라이언트-서버 아키텍처

• 서버라 불리는 상시 가동 호스트가, 클라이언트로 불리는 많은 호스트의 요청을 처리

• 클라이언트가 서로 직접 통신하지 않는다.

• 서버에 IP 주소라 불리는 고정 주소가 존재한다.

• 그렇게 잘 알려진 서버의 IP 주소로 클라이언트는 서버에 항시 연결할 수 있다.

• 대표적으로 웹, FTP, 텔넷, 이메일 등이 존재한다.

• 단일 서버로는 금방 과부하가 걸릴 수 있기 때문에,
  많은 수의 호스트를 수용하는 데이터 센터로 강력한 가상 서버를 만들어
  각종 서비스를 종합적으로 처리한다.

• 데이터 센터에는 수십만 대의 서버가 있을 수 있다.

🟠 Peer-To-Peer 아키텍처

• 데이터 센터 및 전용 서버에 대한 의존도가 거의 없거나 아예 없다.

• 대신 Peer라고 불리는 호스트 쌍간의 직접 통신이 활용된다.
  여기서 쌍을 이루는 호스트는 사용자의 데스크톱과 노트북이다.

• 예시로 torrent가 있다.

• P2P의 가장 매력적인 특징 중 하나는 자체 확장성(self-scalability) 이다.
  피어는 파일을 요청하지만, 배포 하기도 한다.
  그래서 클라이언트-서버 아키텍처와 달리 비용 효율적인데,
  다만 고도로 분산된 구조로 인해 보안, 성능, 안정성에 문제가 있다.

🟢 프로세스 통신

🟡 프로세스(Process)

• end system에서 실행되는 프로그램이 서로 통신하는 방식에 대한 이해도 필요하다.

  전문 용어로, 프로그램이 아니라 실제로는 프로세스이다.

• 프로세스는 end system내에서 실행되는 프로그램이다.

• 서로 다른 end system의 각 프로세스는 네트워크를 통해 메시지를 교환하여 통신한다.

🟠 클라이언트 및 서버 프로세스

• 네트워크 앱은 네트워크를 통해 서로 메시지를 보내는 프로세스 쌍으로 구성된다.
  (예: 브라우저 - 웹 서버의 메시지 교환, peer-to-peer에서의 피어끼리의 메시지 전송)

• 보통 프로세스 쌍은 클라이언트 프로세스-서버 프로세스로 이루어진다.
  (예: 브라우저: 클라이언트 프로세스, 웹 서버: 서버 프로세스
  파일 다운로드 피어: 클라이언트 프로세스, 업로드 피어: 서버 프로세스)

[클라이언트 및 서버 프로세스의 정의]
하나의 프로세스가 클라이언트와 서버 역할을 모두 수행할 수 있기도 하지만, 보통 통신 세션에서 통신을 시작하는 프로세스를 클라이언트라고 지정하고, 세션 시작을 위해 연락을 기다리는 프로세스를 서버라고 칭한다.

🟠 소켓: 프로세스와 네트워크 간의 인터페이스

🔴 소켓

• 대부분의 앱은 통신하는 프로세스 쌍으로 구성되며,
  각 프로세스는 서로에게 메시지를 보낸다.

• 이때, 프로세스는 소켓이라는 소프트웨어 인터페이스를 통해 네트워크에 메시지를 보낸다.

• 다른 것에 비유를 해보자면, 프로세스는 집이며 소켓은 문이다.
  집에서 메시지가 문을 통해 나가서, 다른 집의 문에 들어간다.

• 소켓은 앱 계층과 전송 계층 사이의 인터페이스이다.
  앱과 네트워크 간의 API(앱 프로그래밍 인터페이스)라고도 한다.

• 앱 개발자는 앱 계층에 속한 소켓의 모든 것을 제어할 수 있다.
  하지만 소켓의 전송 계층 측면 제어 권한은 (1) 전송 프로토콜 선택 (2) 버퍼 크기 혹은 세그먼트 크기와 같은 것을 수정하는 기능 뿐이다.

🟠 프로세스 주소 지정

• 우편물에 수신 주소가 필요하듯, 프로세스도 수신 프로세스 주소가 있어야 한다.

• 수신 프로세스를 식별하기 위해 다음 두 가지 정보가 필요하다.

  • 호스트의 주소 (IP 주소)

  • 대상 호스트의 수신 프로세스를 지정하는 식별자 (포트 번호)

• 일반적으로 호스트는 여러 네트워크 앱을 실행하기 때문에 포트 번호가 필요하다.

🟢 앱에 사용 가능한 전송(transport) 서비스

• 소켓은 앱 프로세스와 전송 계층 프로토콜 사이의 인터페이스임을 기억하자.

• 많은 네트워크는 하나 이상의 전송 계층 프로토콜을 제공하고,
  앱을 개발한다면 이 중 하나를 선택해야 한다.

• 당연히 앱의 요구 사항에 가장 잘 맞는 프로토콜을 선택하면 된다.

• 전송 계층 프로토콜이 제공할 수 있는 것은 다음과 같다.

  • 안정적인 데이터 전송 (Reliable Data Transfer)

  • 처리량(Throughput)

  • 타이밍

  • 보안

🟡 안정적인(Reliable) 데이터 전송

• 패킷은 네트워크 내에서 손실될 수 있다.
  (라우터의 버퍼 크기를 넘어서거나, 비트가 손상되어 삭제된 경우)

• 많은 앱에서 데이터 손실은 치명적인 결과를 초래한다. (금융 앱 등)

• 따라서 특정 경우에는 데이터가 정확하고 완벽하게 전달되도록 보장돼야 한다.

• 프로토콜이 이런 보장된 데이터 전송을 제공할 때,
  신뢰할 수 있는 데이터 전송을 제공한다고 한다.

• 어느 정도의 데이터 손실을 허용할 수 있는(loss-tolerant) 앱에는 심각한 장애가 아닐 수 있고, 안정적인 데이터 전송을 제공할 필요가 없다.

🟡 처리량 (Throughput)

• 송신 프로세스가 수신 프로세스에 비트를 전달할 수 있는 속도를 의미한다.

• 특정 앱에는 초당 처리량의 최소 하한선이 존재할 수도 있다.

• 이런 앱을 대역폭에 민감한(bandwidth-sensitive) 앱이라 하며,
  많은 멀티미디어 앱이 대역폭에 민감하다.

• 몇몇 앱은 적응형 기술을 통해 오디오 또는 비디오를 사용 가능한 처리량에 맞게 인코딩하기도 한다.

• 그에 비해 탄력적(elastic)인 앱은 가용 처리량 이하로 사용할 수 있다.
  이메일, 파일 전송, 웹 전송은 모두 탄력적인 앱이다.

🟡 타이밍 (Timing)

• 전송 계층은 발신자의 비트가 수신자의 소켓에 100ms 이내에 도착을 보장하는 등의 타이밍 보장을 제공할 수 있다.

• 원격 회의, 게임 등의 대화형 실시간 앱에 적합하고,
  엄격한 타이밍 제약이 있어야 효과적이다.

🟡 보안

• 전송 계층 프로토콜을 통해 프로세스가 전송하는 모든 데이터를 암호화할 수 있다.

• 수신 호스트의 전송 계층 프로토콜은 프로세스에 전달하기 전 데이터를 해독한다.

• 이러한 기밀성 외에도 데이터 무결성 및 엔드포인트 인증과 같은 서비스를 제공한다.

🟡 인터넷에서 제공하는 전송(transport) 서비스

• 일반적으로 인터넷(TCP/IP 네트워크)은 UDP와 TCP를 전송 프로토콜로 제공한다.

• 개발자가 네트워크 앱을 만들 때 가장 먼저 결정해야 할 사항 중 하나가
  UDP 와 TCP 중 하나를 선택하는 것이다.

🟠 TCP

• 연결 지향 서비스와 신뢰성 있는 데이터 전송 서비스를 제공한다.

🔴 연결 지향 서비스

• TCP는 앱 수준의 메시지가 교환되기 전에,
  클라이언트-서버 간의 전송 계층 제어 정보를 교환한다.

• 이것을 핸드셰이킹이라 부르며,
  이 단계가 끝나면 두 프로세스의 소켓 사이에 TCP 연결이 존재한다고 말한다.

• 이 연결은 두 프로세스가 동시에 서로 메시지를 보낼 수 있다는 점이서,
  전이중(full-duplex) 연결이라 칭한다.

🔴 신뢰성 있는 데이터 전송 서비스

• TCP를 사용하면 전송된 모든 데이터를 오류 없이 적절한 순서로 전달할 수 있다.

• 혼잡 제어 메커니즘으로 네트워크 혼잡을 방지하며, 송신 프로세스를 스로틀링한다.
  각 TCP연결을 네트워크 대역폭을 공정하게 나누도록 제한하기도 한다.

🟠 UDP

• 최소한의 서비스를 제공하는 단순하고 가벼운 전송 프로토콜

• 핸드셰이킹이 필요하지 않으며, 신뢰할 수 없는 데이터 전송 서비스를 제공한다.
  즉, 데이터가 도착할 것이라 보장하지 않고, 순서대로 도착하지 않을 수도 있다.

• 혼잡 제어 메커니즘이 없어 전송 측에서 원하는 속도로 데이터를 전송할 수 있다.
  (물론 중간 링크와 혼잡 등으로 인해 처리량은 설정된 속도보다 낮을 수 있다)

🟠 인터넷 전송 프로토콜이 제공하지 않는 것

• TCP는 안정적인 데이터 전송을 제공하며, TLS를 통해 보안도 제공할 수 있다.

• 다만 처리량 혹은 타이밍 보장은 불가능하다.

🟢 앱 계층 프로토콜

• 앱 계층 프로토콜은 서로 다른 end system에서 실행되는 프로세스 간에 메시지를 전달하는 방법을 정의한다.

• 정의하는 내용은 다음과 같다.

  • 교환되는 메시지의 유형 (예: 요청인지 응답인지)

  • 필드와 같은 메시지 유형을 위한 문법

  • 필드에 담긴 정보의 의미

  • 메시지를 송수신 하는 시기와 방법

• 예시로 HTTP는 브라우저와 웹 서버간에 교환되는 메시지의 형식과 순서를 정의한다.
  스마트폰과 같은 클라이언트와 스트리밍 서버에는 DASH가 쓰인다.

• 앱 계층 프로토콜은 네트워크 앱에 굉장히 중요한 역할을 하지만,
  네트워크 앱을 구성하는 것 중 하나일 뿐, 둘을 구분해서 인식할 필요가 있다.

☑️ 요약

• 네트워크 앱은 end-to-end를 기반으로 구현된다.

• 네트워크 앱은 클라이언트 아키텍처 혹은 P2P 아키텍처를 기반으로 만들 수 있다.

• 두 아키텍처 모두 서버 프로세스와 클라이언트 프로세스가 존재할 수 있으며, 이 프로세스들의 통신을 위해 소켓이 존재한다.

• 네트워크 앱에는 하나 이상의 전송 계층 프로토콜을 채택하며, 전송 계층은 안정성, 보안 등을 제공한다.

• 프로세스 간의 소통을 위해 앱 계층 프로토콜도 채택하며, 앱 계층 프로토콜은 두 프로세스가 어떤 메시지 형식으로 소통할지를 정의한다.