[Computer Networking a Top-Down Approach CH2] 2.1 네트워크 애플리케이션의 원리 노트필기

본 포스팅은 아주대학교 최영준 교수님의 컴퓨터 네트워크 강의와
Computer Networking a Top-Down Approach를 참고하여 작성했습니다. 

 

챕터2에서는 현대 사회에서 컴퓨터 네트워크가 존재해야 하는 주요 이유 중 하나인, 네트워크 애플리케이션에 대해 배운다. 

네트워크 애플리케이션이란 네트워크를 통해 데이터를 주고받으며 동작하는 소프트웨어를 의미한다. 우리들이 자주 쓰는 대부분의 앱들은 네트워크를 이용한다. 이 애플리케이션들은 인터넷이나 다른 네트워크 연결을 이용해서 사용자 간의 상호작용을 가능하게 하고, 데이터를 처리하거나 전송하는 다양한 기능을 제공한다. 대표적인 네트워크 애플리케이션의 예로는 웹 브라우저(크롬, 파이어폭스), 이메일 클라이언트(지메일, 아웃룩), 파일 전송 애플리케이션(FTP, 클라우드 스토리지), 그리고 메신저 프로그램(카카오톡, 디스코드) 등이 있다. 

이러한 애플리케이션들은 클라이언트-서버 모델 또는 P2P 모델을 사용해서 동작하며, 클라이언트가 서버에 데이터를 요청하고 서버가 그 요청에 응답하는 방식으로 작동한다. 이 장에서는 이러한 네트워크 애플리케이션의 개념과 구현 측면을 살펴보겠다.

 

⭕2.1 네트워크 애플리케이션의 원리

네트워크 애플리케이션을 위한 통신

 

네트워크 애플리케이션 개발의 핵심은 다른 위치의 end system(가장자리 노드)에서 동작하고 네트워크를 통해 서로 통신하는 프로그램을 작성하는 것이다. 

 

예를 들어, 웹 애플리케이션에는 서로 통신하는 서버와 클라이언트 두 가지 프로그램이 있는데,

사용자의 호스트(스마트폰, 노트북 등)에서 실행되는 브라우저 프로그램과

웹 서버 호스트에서 실행되는 웹 서버 프로그램이다. 

 

2.6절에서 배울 넷플릭스 같은 온디맨드 비디오(VOD, Video on Demand) 애플리케이션에는 

사용자의 스마트폰 등에서 실행되는 넷플릭스 제공 프로그램과

넷플릭스 서버 호스트에서 실행되는 넷플릭스 서버 프로그램이 존재한다.

 

이 서버들은 종종 데이터 센터에 위치하게 된다. 

 

우리가 새로운 애플리케이션을 개발할 때는 여러 end system에서 실행되는 소프트웨어를 작성해야 한다. 중요한 것은 우리가 라우터나 링크 계층 스위치처럼 네트워크 코어 장비에서 실행되는 소프트웨어까지 작성할 필요는 없다는 점이다. 네트워크 코어 장비는 애플리케이션 계층에서 기능하지 않는 대신에 네트워크 계층 및 그 하위 계층에서 기능한다. 

 

이와 같이 end system에만 애플리케이션 소프트웨어가 존재한다는 기본 설계 방식은 인터넷 애플리케이션들이 빠르고 널리 발전하는 원동력이 되었다. 

 

🔴 2.1.1 네트워크 애플리케이션 구조

애플리케이션 구조는 애플리케이션 개발자가 설계하며, 애플리케이션 구조를 선택할 때,   클라이언트-서버 구조, P2P 구조 중 하나로 선택할 수 있다.

<네트워크 애플리케이션 구조>
- 클라이언트-서버 구조
- P2P 구조

 

클라이언트 - 서버 구조 (clint-server architecture)

클라이어트 서버 구조(아키텍처)는 서버와 클라이언트가 서로 명확하게 역할을 나누어, 데이터를 요청하고 제공하는 과정을 수행하는 구조를 말한다. 이 구조는 웹 브라우징, 파일 전송, 이메일 등 대부분의 네트워크 애플리케이션에서 사용된다. 

클라이언트(서비스를 사용하는 사용자 or 사용자의 단말기)

• 서버로 요청을 보내고, 응답(리소스)를 받는 호스트
• 클라이언트는 서버 주소(ip주소)로 패킷을 보내서 언제든지 서버에 연결할 수 있음
• 클라이언트끼리 서로 직접 통신하지 않음
• 예를 들어, 웹 브라우저(크롬, 파이어폭스) 등은 웹 서버에 접속하여 웹페이지를 요청하는 클라이언트 역할

서버(서비스를 제공하는 컴퓨터)

• 항상 동작하고 있음
• 영구적인 IP주소를 가지고 있음
• 클라이언트의 요청에 따라 적절한 응답(리소스)를 전달해주는 호스트
• 필요에 따라 데이터베이스에 요청을 보내고 회신 받은 응답(리소스)를 활용할 수 있음
• 예를 들어, 웹 서버는 웹페이지 파일을 저장하고 있다가, 클라이언트(웹 브라우저)가 요청하면 그 웹페이지를 제공함

+ 데이터 베이스

• 리소스를 저장하는 공간(일종의 서버임)
• 서버의 요청에 따라 적절한 응답(리소스)를 꺼내 서버에게 전달

 

클라이언트 - 서버 구조 (clint-server architecture)

 

서버-클라이언트 간의 통신 과정

• 1) 클라이언트 요청: 클라이언트가 서버에 데이터를 요청해. 예를 들어, 웹 브라우저에서 URL을 입력하면 클라이언트가 웹 서버에 그 페이지에 대한 요청을 보냄.
• 2) 서버 응답: 서버는 요청을 처리하고, 필요한 데이터를 클라이언트에게 응답으로 보내. 웹 서버는 요청한 HTML 파일, 이미지, 자바스크립트 파일 등을 브라우저로 전송함.
• 3) 클라이언트가 데이터 처리: 클라이언트는 서버로부터 받은 데이터를 처리해 화면에 보여주거나 다른 작업을 진행함.

서버-클라이언트 구조의 예시

• 웹 브라우저와 웹 서버: 브라우저(클라이언트)가 웹 서버에 요청을 보내면, 서버가 해당 웹페이지를 응답함.
• 이메일 시스템: 이메일 클라이언트(예: Outlook, Gmail 앱)가 메일 서버에 접속하여 이메일을 보내거나 받아오는 구조.
• 파일 전송: 클라이언트가 파일 서버에 접속하여 파일을 다운로드하거나 업로드하는 FTP 서비스.

** 참고로 웹과 인터넷을 동의어로 착각하는 경우가 있는데 엄밀히 말하면 다른 개념이다.

웹은 전자 파일 전송 등과 같이 인터넷 통신망을 이용해서 동작하는 하나의 '서비스'일 뿐이다. 

인터넷은 전 세계적으로 연결된 네트워크의 집합체로  모든 네트워크가 연결되어 있는 기반 인프라 라고 볼 수 있다. 

 

비유하자면, 인터넷은 전 세계를 연결하는 도로망(인프라)이고, 웹은 그 도로망 위를 달리는 차량(서비스)이라고 생각할 수 있다.

 

 

때론, 클라이언트-서버 구조에서 하나의 서버 호스트가 자신의 클라이언트로부터 오는 모든 요청에 다 응답하는 것은 불가능하다. 예를 들어,  인기 있는 웹사이트가 하나의 서버로만 요청을 처리한다면 이에 맞춰 서버가 신속하고 제대로 작동하지 못할 수 있다. 이러한 이유로 많은 수의 호스트를 갖춘 데이터 센터가 강력한 가상의 서버를 생성하는 역할로 사용된다. 

 

구글과 같은 검색 엔진, 아마존과 같은 인터넷 상거래, 지메일과 같은 웹 기반 전자메일, 인스타 같은 소셜 미디어 네트워킹 서비스들은 하나 이상의 데이터 센터를 사용한다. 보통 하나의 데이터 센터는 전력이 공급되고 관리되어야 하는 10만 개 정도의 서버를 갖추고 있다. (구글은 전 세계적으로 분산된 19개의 데이터 센터를 보유하고 있다.)

 

 

P2P 구조(Peer-to-peer)

P2P 구조는 서버가 컨텐츠를 제공하는 것이 아니라 임의의 end system들끼리 직접 컨텐츠를 송/수신하는 구조이다. 이 구조에서는 중앙 서버가 필요하지 않고, 모든 노드가 서버이자 클라이언트 역할을 동시에 수행한다. 

 

예를 들어, 파일을 다운로드하거나 공유할 때, 파일이 여러 컴퓨터에 나뉘어 저장되어 있다고 생각해보자. P2P 네트워크에서는 파일의 일부를 여러 컴퓨터에서 동시에 받을 수 있다. 이렇게 하면 다운로드 속도가 빨라지고, 서버 하나에만 의존하지 않아도 된다. 

 

대표적으로는 파일을 공유하는 서비스인  BitTorrent, 음성 서비스를 제공하는 Skype, 스트리밍 서비스를 제공하는 Kankan 등이 P2P 모델을 이용한다. BitTorrent를 생각해보면 파일을 중앙 서버에서 받는 것이 아니라, 파일을 가지고 있는 여러 사용자로부터 동시에 받아오는 방식이다. 이렇게 하면 파일을 빠르게 받고 네트워크의 부하를 분산시킬 수 있다. 

 

이 구조의 장점은 서버에 부담을 줄이고 네트워크가 더욱 확장 가능하게 하지만, 보안 문제와 데이터 관리가 어려워질 수 있다는 단점도 있다. 

 

P2P 구조의 특징

책 본문에 나와있는 P2P 구조의 특징을 정리하면 다음과 같다. 

• No always-on server (항상 켜져 있는 서버가 없음): P2P 구조에서는 중앙 서버에 의존하지 않고, 피어들이 직접 통신한다. 피어는 흔히 알려진 클라이언트(개인 데스크톱 랩톱 등등)이다.
• Arbitrary end systems directly communicate (임의의 종단 시스템들이 직접 통신): 피어들은 서로 직접 연결되어 데이터를 주고받으며, 중앙 서버 없이 네트워크를 형성한다.
• Peers request service from other peers, provide service in return to other peers (피어들이 서로 서비스 요청 및 제공): 각 피어는 다른 피어로부터 서비스를 요청하고, 동시에 다른 피어에게 서비스를 제공한다.
• Self scalability (자체 확장성): 새로운 피어가 네트워크에 참여하면, 새로운 서비스 용량을 제공함과 동시에 새로운 서비스 요청도 발생합니다. 즉, 네트워크가 확장될수록 그 성능도 함께 향상될 수 있다. (=P2P 모델에서는 사용자가 많을수록 파일 분배 속도 또한 빨라진다. 
• Peers are intermittently connected and change IP addresses (피어들이 간헐적으로 연결되고 IP 주소가 변경됨): 피어들은 항상 연결되어 있지 않고, 때때로 연결이 끊기거나 IP 주소가 바뀔 수 있다.
• Complex management (복잡한 관리): 피어들이 계속해서 연결과 연결 해제를 반복하고, IP 주소도 변경되기 때문에 네트워크 관리가 복잡해질 수 있으며 보안, 성능,신뢰성 면에서 도전을 맞이하고 있다. 
• + 비용효율적 : 이 구조는 일반적으로 상당한 서버 인프라스트럭처와 서버 대역폭을 요구하지 않으므로 비용 효율적이다.(데이터 센터의 클라이언트-서버 설계와는 대조적임)

🔴 2.1.2 프로세스 간 통신

클라이언트와 서버 프로세스

• 운영체제 용어에서 실제 통신하는 것은 프로그램이 아니라 프로세스다. 
• 프로세스란? 호스트 컴퓨터 내에서 실행 중인 프로그램을 의미한다. 
• 같은 호스트 내에서의 프로세스 간 통신 : 같은 호스트(= 같은 컴퓨터) 내의 두 프로세스는 IPC(inter-process communication) 이라는 매커니즘을 사용해 통신한다. 이는 운영체제에 의해 정의된다. 
• 다른 호스트 간의 프로세스 통신 : 서로 다른 프로세스는 메시지를 교환함으로써 통신한다.
• 클라이언트 프로세스는 통신을 시작하는 프로세스, 즉, 어떤 서비스를 요청하는 역할을 한다.
• 서버 프로세스는 연락을 기다리는 프로세스다, 즉, 클라이언트의 요청이 있을 때까지 대기하고, 요청을 받으면 응답한다. 
• 참고로, 앞에서 언급했듯이, P2P 구조에서는 각 피어들이  클라이언트이면서 동시에 서버로서 작동할 수 있다.  

프로세스와 컴퓨터 네트워크 사이의 인터페이스 - 소켓(socket)

앞서 서로 다른 호스트 간의 프로세스 통신에는 메시지가 쓰인다고 했다. 

이 메시지가 바로 소켓이다. 

• 프로세스는 소켓을 통해 네트워크로 메시지를 보내고 받는다. 
• 프로세스는 집이고, 소켓은 문으로 비유할 수 있다. 프로세스가 메시지를 다른 호스트의 프로세스로 보내고 싶을 때, 출입구(소켓) 바깥 네트워크로 메시지를 밀어낸다. 
• 위 그림은 인터넷에서 통신하는 두 프로세스 사이의 소켓 통신을 보여준다. (프로세스가 사용하는 하위 전송 프로토콜이 TCP 프로토콜이라고 가정한다.) 그림에서 보다싶이, 소켓은 호스트의 애플리케이션 계층과 트랜스포트 계층 간의 인터페이스(서로 다른 두 부분이 소통할 수 있게 해주는 다리 역할)이다. 
• 네트워크 애플리케이션이 인터넷에 만든 프로그래밍 인터페이스이므로, 애플리케이션과 네트워크 사이에 API(Application Programming Interface)라고도 한다.
• Application process는 개발자가 제어하고, transport, network, link, physical 계층은 운영체제에 의해 제어됨. 소켓은 이 계층 사이에서 데이터를 전달하는 역할을 하는 것이다.

 

프로세스 주소 배정

• 메시지를 받으려면, 프로세스에는 고유한 식별자(identifier)가 필요하다. 이 식별자는 프로세스를 네트워크 상에서 정확하게 찾고 식별하는 역할을 한다. 
• 인터넷에서 호스트는 IP주소로 식별된다. IP주소는 32비트로 구성된다. 
• 하지만 호스트의 IP 주소만으로는 프로세스를 식별할 수 없다. 그 이유는 한 호스트에서 여러 개의 프로세스가 동시에 실행될 수 있기 때문이다. 
• 따라서 프로세스를 정확하게 식별하기 위해서는 IP 주소와 포트번호가 모두 필요하다.

++ 더 자세히 말하자면(이후 장에서 배울 예정) TCP/IP에서 1-2계층에서는 MAC address로 판별하고, 3계층에서는 IP address로 판별한다. 이렇게 MAC과 IP를 사용해서 목적지(컴퓨터, 테블릿, 핸드폰)까지 도달했으나, 이제 목적지 안에 어떤 프로그램(어플리케이션)한테 가야 하는데 이때 어디로 가야 할지를 알려주는 게 바로 port 번호이다. 데이터를 받을 프로세스가 어떤것인지 알아야 전송됩니다. 그때 필요한 번호가 Port 넘버인 것이다.

 

더 쉽게 예를 들자면, 만약 포트번호가 없다면 인터넷 창이 2개가 있다고 했을 때, 1번 인터넷 창에서 구글에 들어갔는데 2번 인터넷 창에서 구글이 켜질 수도 있다는 것이다. 이처럼 디바이스에 있는 여러 프로세스 중 자기가 가야 할 프로세스를 구분하기 위해 필요한 게 포트번호이다.  

🔴 2.1.3 애플리케이션이 이용 가능한 트랜스포트 서비스

• 응용 계층 프로토콜(application,pro,session)이 정의하는것을 각각 예시로 설명하면 다음과 같다.  
• 메시지 유형(요청&응답) 
  • 예시1: HTTP에서는 요청(request)과 응답(response) 두 가지 메시지 유형이 있다. 클ㄹ라이언트(웹 브라우저)가 서버에 메시지를 보내고 서버는 여기에 응답한다.
  • 예시2 : DNS에서는 클라이언트가 도메인 이름 -> ip주소 변환 요청하는 쿼리(query)를 보내고 서버가 해당 ip 주소를 응답으로 돌려준다.
• 메시지 문법
  • 예시 : HTTP에서는 GET 요청의 문법이 "GET /path HTTP/1.1" 형태로, 요청하려는 라소스의 경로와 프로토콜 버전이 포함된다.
• 메시지 의미
  • 예시1: HTTP에서 200 OK라는 응답 코드는 요청이 성공적으로 처리되었다는 의미를 가지고, 404 Not Found는 요청한 리소스가 서버에 없다는 의미이다.
  • 예시2: DNS에서 NXDOMAIN 응답 코드는 요청한 도메인이 존재하지 않음을 나타낸다.
• 전송 규칙
  
  • 예시1: HTTP에서는 클라이언트가 서버에 요청을 보내면, 서버는 그 요청을 처리한 후 응답을 돌려준다. 이때, 요청이 끝나기 전까지 클라이언트는 응답을 기다다. 만약 응답 시간이 너무 길면 타임아웃이 발생할 수 있다.
  • 예시2 : FTP에서는 파일 전송을 시작하기 전에 먼저 제어 연결을 설정하고, 이후 데이터 전송이 완료되면 연결을 종료한다.

 

인터넷을 포함한 많은 네트워크는 트랜스포트 프로토콜을 하나 이상 제공한다. 

트랜스포트 프로토콜이 그것을 이용하는 애플리케이션에게 제공할 수 있는 4가지 서비스를 소개한다. 

 

• 신뢰적 데이터 전송(data Integrity) 
  • 파일 전송, 웹 트랜잭션 같은 앱들은 100프로 신뢰할 수 있는 데이터 필요로 함
  • 반면, 오디오 스트리밍 같은 앱들은 어느 정도의 데이터 손실을 허용할 수 있음
• 타이밍(timing) 
  • 인터넷 전화나 실시간 게임같은 앱들은 실시간 연결이 중요하므로 딜레이가 적어야 함 
• 처리율( Throughput)
  • 멀티미디어 앱들은 최소한의 처리양이 필요. 예를 들어,유튜브 같은 동영상 스트리밍 서비스는 일정한 대역폭이 확보되어야 함
  • 반면, 엘라스틱 앱은 처리량에 크게 의존 X, 어떤 네트워크 환경에서도 성능 저하는 좀 있어도 중단없이 유연하게 데이터 전송하고 처리함. 이런 앱 들은 대역폭이 부족해도 사용 가능한 리소스에 맞게 동작 가능
• 보안 ( Security)
  • 암호화, 데이터 무결성 등의 보안 사항이 중요한 앱도 있음

이처럼 각 애플리케이션이 요구하는 전송 서비스의 속성에 따라, 필요한 전송 계층의 기능이 다를 수 있음. 이를 바탕으로 개발자는 애플리케이션마다 적합한 전송 프로토컬과 설정을 선택해야 한다. 

 

다양한 앱에서 필요한 대표적인 전송 소비스 요구사항은 다음과 같다. 

 

앱	데이터 손실	처리량	시간 민감도
파일 전송	허용 X	엘라스틱(네트워크 대역폭에 따라 전송 속도 달라져도 괜춘)	없음(전송 시간 길어져도 문제 안됨)
이메일	허용 X	엘라스틱	없음
웹 문서	허용 X	엘라스틱	없음
실시간 오디오/비디오	일부 허용	오디오 : 5kbps ~ 1Mbps 비디오 : 10kbps ~ 5Mbps	매우 중요(수백 밀리초 이내의 지연 수준)
저장된 오디오/비디오	일부 허용	위와 동일	없음(즉시 재생 필요 X)
인터랙티브 게임	일부 허용	낮은 대역폭으로도 충분	중요(몇 초 이내의 응답 필요)
텍스트 메시징	허용 X	엘라스틱	때에 따라 다름

 

🔴 2.1.4 인터넷 전송 프로토콜이 제공하는 서비스

 

TCP 서비스

애플리케이션 계층 메시지를 전송하기 전에 TCP는 클라이언트와 서버가 서로 전송 제어 정보를 교환하게 한다. -> 핸드 셰이킹(handshaking)
이 핸드 셰이킹(handshaking) 과정이 클라이언트와 서버에 패킷이 곧 도달할테니 준비하라고 알려주는 역할을 한다.
핸드셰이킹 단계를 지나면, TCP 연결이 두 프로세스의 소켓 사이에 존재한다고 말한다.
이 연결은 두 프로세스가 서로에게 동시에 메시지를 보낼 수 있기에 전이중 연결이라고 한다. (3장에서 더 자세히 다룰 예정)

 

 

• 신뢰성 있는 전송 (Reliable transport): 송신 프로세스에서 수신 프로세스로 데이터가 손실되지 않고 순서대로 정확하게 도착하도록 보장
• 흐름 제어 (Flow control): 수신 측이 감당할 수 없을 정도로 많은 데이터를 송신 측에서 보내지 않도록 조절
• 혼잡 제어 (Congestion control): 네트워크가 혼잡할 경우, 송신 측에서 데이터를 천천히 전송하도록 조절
• 제공하지 않는 기능: 타이밍, 최소 처리량 보장, 보안 같은 기능은 제공하지 X
• 연결 지향적 (Connection-oriented): 클라이언트와 서버 간에 데이터 전송을 시작하기 전에 연결을 설정하는 과정이 필요

 

UDP 서비스

UDP는 최소의 서비스 모델을 가진 간단한 전송 프로토콜이다.
UDP는 비연결형으로 핸드셰이킹 과정이 없고, 비신뢰적인 데이터 전송 서비스를 제공하여 데이터가 전달되는 것을 보장하지 않는다. 또한, 혼잡 제어 방식을 포함하지 않아 프로세스의 속도 저하 없이 네트워크를 이용할 수 있다.
그러나 혼잡으로 인해 종단 간 처리율이 낮아져서 속도가 오히려 더 낮아질 수 있다

 

• 비신뢰성 있는 전송 (Unreliable data transfer): 송신 프로세스에서 수신 프로세스로 데이터를 전송하지만, 데이터가 손실되거나 순서가 뒤바뀔 수 있으며, 수신 여부도 보장하지 X
• 제공하지 않는 기능: 신뢰성, 흐름 제어, 혼잡 제어, 타이밍, 처리량 보장, 보안, 연결 설정 등의 기능은 제공하지 X

 

인터넷 트랜스포트 프로토콜이 제공하지 않는 서비스(+TCP의는보안 서비스 제공??)

TCP는 신뢰적 데이터 전송(data Integrity) , 타이밍(timing) , 처리율( Throughput), 보안 ( Security) 중 신뢰적 데이터 전송은 제공한다. 또한 보안에 대해서도, TCP 자체가 보안 기능을 제공하는 건 아니지만 TLS(SSL 후속 버전)와 같은 별도의 보안 프로토콜을 TCP 위에 사용해서 보안 기능을 제공한다. (예를 들어, HTTPS(HTTP over TLS)는 HTTP 트래픽을 암호화하기 위해 TCP와 TLS를 함께 사용한다. )

 

 TCP나 UDP가 기본적으로 보안을 제공하지 않기 때문에 SSL을 사용하여 암호화, 데이터 무결성, 인증과 같은 보안 기능을 추가해야 한다. SSL(현재는 SSL보다 더 강력한 버전인 TLS이 사용됨)은 응용 계층에서 동작하며, SSL 소켓 API를 통해 암호화된 통신을 쉽게 구현할 수 있다.

 

 

하지만, TCP와 UDP 모두 처리율 혹은 타이밍(시간 보장)에 대해서는 보장하지 않는다. 하지만 그렇다 해서 시간에 민감한 어플이 인터넷에서 수행될 수 없다는 의미는 아니다. 시간 민감 어플들은 프로토콜 자체의 보장은 없어도 이러한 처리율 및 시간 지연에  잘 대처할 수 있도록 설계가 되어있다. 그럼에두 불구하고, 지연이 과도할 때는 보장이 없기 때문에 한계가 있다. 

 

즉, 인터넷은 시간 민감 어플에게 만족스런 서비스를 제공할 수 있으나. 시간 혹은 처리율(대역폭) 보장을 할 순 없다.

 

요약하자면:

• TCP는 신뢰성 있는 전송과 흐름/혼잡 제어가 필요할 때 사용됨 (예: 파일 전송, 이메일.)
• UDP는 속도가 중요하고, 일부 데이터 손실을 감수할 수 있는 상황에서 사용됨 (예: 실시간 비디오 스트리밍, 게임)
• TCP는 자체적으로는 보안 기능을 제공하지 않지만 SSL(TLS) 사용해서 보안 기능 추가 가능
• TCP와 UDP 모두 처리율(대역폭) 혹은 시간 보장 서비스는 제공 X

 

유명한 인터넷 어플의 애플리케이션 계층 프로토콜 & 하위 프로토콜

 

 

🔴 2.1.5 애플리케이션 계층 프로토콜

애플리케이션 계층 프로토콜은 다른 종단 시스템에서 실행되는 애플리케이션의 프로세스가 서로 메시지를 보내는 방법을 정의한다고 헸다. 

교환 메시지의 타입
여러 메시지 타입의 문법(syntax)
필드의 의미, 즉 필드에 있는 정보의 의미(semantics)
언제, 어떻게 프로세스가 메시지를 전송하고 메시지에 응답하는지를 결정하는 규칙

여러 애플리케이션 계층 프로토콜은 RFC에 명시되어 있어 공중 도메인에서 찾을 수 있다.
예를 들어, 만약 브라우저 개발자가 HTTP RFC 규칙을 따른다면, HTTP RFC 규칙을 따른 어떠한 웹 서버로부터도 웹페이지를 가져올 수 있다.
다른 많은 애플리케이션 계층 프로토콜은 독점이며(비개방) 공중 도메인에서 찾을 수 없다.

예를 들어 스카이프는 비개발 애플리케이션 계층 프로토콜을 이용한다.

 

 

네트워크 앱 VS 애플리케이션 계층 프로토콜

네트워크 애플리케이션과 애플리케이션 계층 프로토콜을 구별하는 것은 중요하다. 

애플리케이션 계층 프로토콜은 네트워크 애플리케이션의 한 요소일 뿐이다. 네트워크 애플리케이션이 데이터를 주고받기 위해 사용하는 규칙과 규격일 뿐이다.
예를 들어, 웹 애플리케이션은 문서 포맷 표준, 웹 브라우저, 웹 서버, 웹 애플리케이션 계층 프로토콜(HTTP)을 포함하는 여러 요소들로 구성된다.

 

🔴 2.1.6 이 책에서 다루는 네트워크 애플리케이션

앞으로 다음 5개의 애플리케이션 분야에 초점을 맞출 것이다

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