애플리케이션 계층

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

웹 애플리케이션

• 서버
• 클라이언트

라우터나 링크 계층 스위치처럼 네트워크 코어장비에서 실행되는 소프트웨어까지 작성할 필요는 없다. 하고 싶더라도 불가능하고, 네트워크 코어 장비는 애플리케이션 계층에서 기능하지않는 대신에 네트워크 계층 및 그 하위계층에서 기능한다. 아래 그림과 같이 애플리케이션은 종단 시스템(Host)에만 존재한다.

예시)

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

애플리케이션 개발자 관점에서 네트워크 구조는 고정되어 있고 해당 애플리케이션에 특정 서비스 집합을 제공한다. 반면 애플리케이션 구조는 애플리케이션 개발자가 설계하며, 또한 애플리케이션이 다양한 종단 시스템에서 어떻게 조직되어야 하는지를 알려준다.

애플리케이션의 구조 2가지

• 클라이언트 - 서버 구조
• P2P 구조

클라이언트 - 서버 구조

항상 동작하고 있는 호스트를 서버라 부르는데, 서버와의 서비스는 클라이언트라는 다른 호스트들로부터 서비스 요청을 받는다. 고전적인 예는 클라이언트 호스트에서 실행되는 브라우저에서 웹 서버로 서비스를 요청하는 웹 애플리케이션이다. 웹 서버가 클라이언트 호스트로부터 객체를 요청받으면 웹 서버는 요청된 객체를 클라이언트 호스트로 보내면서 응답한다. 클라이언트 - 서버 구조의 또 다른 특징은 서버가 고정 IP 주소라는 잘 알려진 주소를 갖는다는 점이다. 서버는 항상 동작하고 있으므로 클라이언트튼 서버 주소로 패킷을 보내서 언제든지 서버에 연결할 수 있다. 예시로는 웹, 파일 전송, 원격 로그인, 전자메일등이 있다.

P2P 구조

P2P구조에서는 항상 켜져있는 인프라스트럭처 서버에 거의 의존하지 않는다. 대신에 애플리케이션은 피어라는 간헐적으로 연결된 호스트쌍이 서로 직접 통신하게 한다. 피어는 서비스 제공자가 소유하지 않고 사용자들이 제어하는 데스크톱과 랩톱이며, 대부분의 피어들은 가정, 대학, 사무실에 위치한다. 특정 서버를 통하지 않고 피어가 통신하므로 이 구조를 피어 투 피어(peer-to-peer, P2P) 라고 한다. P2P 구조의 가장 주목할 만한 특성 중의 하나가 자가 확장성이다. 예를 들어, P2P 파일 공유 애플리케이션에서는 비록 각 피어들이 파일을 요구함으로써 작업 부하를 만들어내지만 각 피어들은 또한 파일을 다른 피어들에게 분배함으로써 그 시스템에 서비스 능력을 추가한다.

예시)

2.1.2 프로세스 간 통신

종단 시스템에서 실행되는 프로그램을 프로세스라고 하는데, 2개의 종단 시스템에서 프로세스는 컴퓨터 네트워크를 통한 메시지 교환으로 서로 통신한다. 송신 프로세스는 메시지를 만들어 네트워크로 보내고 수신 프로세스는 메시지를 받고 역으로 메시지를 보냄으로써 응답한다.

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

네트워크 애플리케이션은 네트워크에서 서로 메시지를 보내는 두 프로세스로 구성된다. 통신하는 프로세스 각 쌍에 대해 일반적으로 클라이언트의 프로세스와 서버의 프로세스 중 하나로 이름 짓는다. 웹 브라우저는 클라이언트 프로세스고, 웹 서버는 서버 프로세스다. P2P 파일 공유 시스템에서 프로세스는 파일을 올리고 또한 내려받을 수 있다.

클라이언트와 서버의 정의 : 두 프로세스간의 통신 세션에서 통신을 초기화(다른 프로세스와 세션을 시작하려고 접속을초기화)하는 프로세스를 클라이언트라 하고, 세션을 시작하기 위해 접속을 기다리는 프로세스를 서버라고 한다.

웹에서 브라우저는 웹 서버 프로세스와 접촉을 초기화한다. 그럼므로 브라우저 프로세스는 클라이언트이고 웹 서버 프로세스는 서버다. P2P 파일 공유에서 피어 A는 피어 B에게 특정 파일을 보낼 것을 요청한다. 이 특정 통신 세션의 내용에서 피어 A는 클라이언트이고 피어 B는 서버다.

프로세스와 컴퓨터 네트워크 사이의 인터페이스

프로세스는 소켓을 통해 네트워크로 메시지를 보내고 받는다. 프로세스는 집이고 소켓은 출입구라고 생각하면 된다. 소켓은 호스트의 애플리케이션 계층과 트랜스포트 계층간의 인터페이스다. 또한 소켓은 네트워크 애플리케이션이 인터넷에 만든 프로그래밍 인터페이스이므로, 애플리케이션과 네트워크 사이의 API(Application Programming Interface) 라고도 한다. 애플리케이션 개발자는 소켓의 애플리케이션 계층에 대한 모든 통제권을 갖지만, 소켓의 트랜스포트 계층에 대한 통제권을 거의 갖지 못한다. 트랜스포트 계층에 대한 애플리케이션 개발자의 통제는 (1) 트랜스포트 프로토콜의 선택, (2) 최대 버퍼와 최대 세그먼트 크기 같은 약간의 트랜스포트 계층 매개변수의 설정뿐이다. 애플리케이션 개발자가 트랜스포트 프로토콜을 선택하면, 애플리케이션은 그 프로토콜이 제공하는 전송 서비스를 사용하여 구성된다.

예시)

프로세스 주소 배정

한 호스트상에서 수행되고 있는 프로세스가 패킷을 다른 호스트에서 수행되고 있는 프로세스로 패킷을 보내기 위해서는 수신 프로세스가 주소를 갖고 있을 필요가 있다. 수신 프로세스를 식별하기 위해서는 다음과 같은 두 가지 정보가 명시되어야 한다. (1) 호스트의 주소, (2) 그 목적지 호스트 내의 수신 프로세스를 명시하는 식별자

인터넷에서 호스트는 IP 주소로 식별된다. IP주소는 32비트로 구성되며, 호스트를 유일하게 식별한다. 메시지가 전달되어야 하는 호스트의 주소를 아는 것과 더불어 송신 호스트는 수신 호스트에서 수행되고 있는 수신 프로세스(수신 소켓)도 식별해야 한다. 목적지 포트 번호가 이 목적을 위해 사용된다. 인기 있는 애플리케이션은 특정한 포트번호가 할당된다. 예를들어 웹 서버는 포트번호 80으로 식별된다.

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

인터넷을 포함해서 많은 네트워크는 하나 이상의 트랜스포트 프로토콜을 제공한다. 애플리케이션을 개발할 때는 사용 가능한 트랜스포트 프로토콜 중에서 하나를 선택해야 한다. 트랜스포트 계층 프로토콜이 그것을 이용하는 애플리케이션들에게 제공할 수 있는 서비스는 신뢰적 데이터 전송, 처리율, 시간, 보안 이라는 네가지 차원으로 분류할 수 있다.

신뢰적 데이터 전송

패킷들은 컴퓨터 네트워크내에서 손실될 수 있다.(오버플로우 등) 데이터 손실이 위험한 결과를 초래할 수 있는 애플리케이션들 지원하기 위해 프로토콜이 보장된 데이터 전송 서비스를 제공한다면 이를 신뢰적 데이터 전송(reliable data transfer) 을 제공한다고 한다. 트랜스포트 프로토콜이 이 서비스를 제공할 때, 송신 프로세스는 데이터를 소켓으로 보내고 그 데이터가 오류 없이 수신 프로세스에 도착할것이라는 확신을 갖는다.

예) 전자메일, 파일전송, 원격호스트 접속, 웹 문서 전송 등

처리율

처리율이란, 네트워크 경로를 따라 두 프로세스간의 통신 세션에서 송신 프로세스가 수신 프로세스로 비트를 전달할 수 있는 비율을 나타낸다. 다른 세션들이 네트워크 경로를 따라 개역폭을 공유하고, 이 세션들이 생겼다 없어졌다 하기 때문에 가용한 처리율은 시간에 따라 변동한다. 이러한 관찰로 트랜스포트 프로토콜이 제공할 수 있는 다른 자연적인 서비스, 즉 어느 명시된 속도에서 보장된 가용 처리율을 제공한다는 사실을 알 수 있다. 그러한 서비스로 애플리케이션은 r비트/초의 보장된 처리율을 요구할 수 있고 트랜스포트 프로토콜은 가용한 처리율이 항상 적어도 r bps임을 보장한다. 이러한 처리율 요구사항을 갖는 애플리케이션을 대역폭 민감 애플리케이션(bandwidth-sensitive application) 이라고 한다. 현존하는 많은 멀티미디어 애플리케이션들은 대역폭에 민감하다. 대역폭 민감 애플리케이션들이 특정 처리율 요구사항을 갖고 있는 반면에, 탄력적 애플리케이션(elastic application) 은 가용한 처리율을 많으면 많은대로 적으면 적은 대로 이용할 수 있다.

예)
대역폭 민감 애플리케이션 : 각종 멀티미디어
탄력적 애플리케이션 : 전자메일, 파일전송 등

시간

트랜스포트 계층 프로토콜은 또한 시간 보장(timing guarantee)을 제공할 수 있다. 처리율 보장과 마찬가지로 시간 보장은 여러 가지 형태로 나타난다. 한 가지 예는 송신자가 소켓으로 내보내는 모든 비트가 소켓에 100ms내에 도착하게 하는 것이다. 이러한 애플리케이션이 효과적으로 동작하기 위해서는 데이터 전송에 엄격한 시간 제한 조건이 요구된다.

예) 인터넷 전화, 가상 환경, 원격 회의, 다자간 게임 등

보안

마지막으로, 트랜스포트 프로토콜은 애플리케이션에 하나 이상의 보안 서비스를 제공할 수 있다. 예를 들어, 송신 호스트에서 프랜스포트 프로토콜은 송신 프로세스가 전송하는 모든 데이터를 암호화할 수 있고 수신 호스트에서 프랜스포트 프로토콜은 그 데이터를 수신 프로세스로 전달하기 전에 데이터의 암호를 해독할 수 있다. 그러한 서비스는 데이터가 송신과 수신 프로세스 사이에서 어느 정도 관찰된다 하더라도 두 프로세스 사이에 기밀성을 제공한다. 또한 트랜스포트 프로토콜은 기밀성 외에도 무결성, 종단 인증 등을 제공한다.

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

인터넷이 제공하는 애플리케이션 지원 유형을 살펴보자. 인터넷(그리고 일반적인 TCP/IP 네트워크)은 애플리케이션에게 2개의 전송 프로토콜, 즉 UDP(User datagram Protocol)와 TCP(Transmission Control Protocol)를 제공한다. 새로운 인터넷 애플리케이션을 만들 때 가장 먼저 결정해야 하는 것 중 하나는 UDP와 TCP 중 어느 것을 사용할 것인가이다.

TCP 서비스

TCP 서비스 모델은 연결지향형 서비스와 신뢰적인 데이터 전송 서비스를 포함한다. 애플리케이션이 TCP 전송 프로토콜을 사용하면, 애플리케이션은 TCP로부터 이 두 가지 서비스를 받는다.

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

• 신뢰적인 데이터 전송 서비스 : 통신 프로세스는 모든 데이터를 오류 없이 올바른 순서로 전달하기 위해 TCP에 의존한다. TCP는 애플리케이션의 한쪽이 바이트 스트림을 소켓으로 전달하면 그 바이트 스트림이 손실되거나 중복되지 않게 수신 소켓으로 전달한다.

또한 TCP는 혼잡 제어 방식, 즉 통신하는 프로세스의 직접 이득보다는 인터넷의 전체 성능 향상을 위한 서비스를 포함한다. TCP 혼잡 제어 방식은 네트워크가 혼잡 상태에 이르면 프로세스(클라이언트 또는 서버) 속도를 낮춘다. TCP 혼잡 제어는 각 TCP 연결이 네트워크 대역폭을 공평하게 공유할 수 있게끔 제한하려고 시도한다.

UDP 서비스

UDP는 최소의 서비스 모델을 가진 간단한 전송 프로토콜이다. UDP는 비연결형이므로 두 프로세스가 통신을 하기 전에 핸드셰이킹을 하지 않는다. UDP는 비신뢰적인 데이터 전송 서비스를 제공한다. 즉, 하나의 프로세스가 UDP 소켓으로 메시지를 보내면, UDP는 그 메시지가 수신 소켓에 도착하는 것을 보장하지 않는다. 게다가 수신 소켓에 도착하는 메시지들의 순서가 뒤바뀔 수도 있다.

반면에 UDP는 혼잡 제어 방식을 포함하지 않는다. 따라서 UDP의 송신 측은 데이터를 원하는 속도로 하위 계층(네트워크 계층)으로 보낼 수 있다. 그러나 실제 종단 각 처리율은 중간 링크들의 제한된 대역폭 혹은 혼잡으로 인해 이 속도보다작아질 수 있음에 유의.

인터넷 트랜스포트 프로토콜이 제공하지 않는 서비스

우리는 신뢰적 데이터 전송, 처리율, 시간, 보안이라는 네 가지 차원에서의 가능한 트랜스포트 서비스를 구성했다. TCP와 UDP가 제공하는 서비스는 무엇인가? TCP는 신뢰적 종단 간 데이터 전송을 제공한다는 것을 이미 보았다. 또한, TCP가 보안 서비스를 제공하기 위해 애플리케이션 계층에서 TLS를 통해 쉽게 강화될 수 있음을 알았다. 그러나 TCP와 UDP에 대한 간략한 기술에서 처리율 혹은 시간보장(오늘날의 인터넷 트랜스포트 프로토콜이 제공하지 않는 서비스)에 대한 언급은 빠졌다. 오늘날 인터넷은 그런 보장이 없는 경우에도 잘 동작하도록 설계되었기 때문에 시간 민감 애플리케이션들에게 만족스런 서비스를 제공할 수 있다. 다만 시간 혹은 대역폭 보장을 제공할 수는 없다.

위 그림은 몇몇 인기 있는 인터넷 애플리케이션들이 사용하는 트랜스포트 프로토콜을 나타내고 있다. 전자메일, 원격 터미널 접속, 웹, 파일 전송 모두 TCP를 사용하고 있음을 볼 수 있다. 이 애플리케이션들은 TCP가 모든 데이터가 궁극적으로 목적지에 도착하도록 보장하는 신뢰적 데이터 전송 서비스를 제공하기 때문에 주로 TCP를 선택했다. 인터넷 전화 애플리캐ㅔ이션은 보통 패킷 손실을 허용하지만 효율성을위해 최소의 전송률을 필요로 하기 때문에, 인터넷 전화 애플리케이션 개발자들은 일반적으로 UDP상에서 자신들의 애플리케이션을 수행하기를 선호하며, 그렇게 함으로써 TCP의 혼잡 제어 방식과 패킷 오버헤드(overhead)를 회피할 수 있다. 그러나 많은 방화벽(firewall)이 (대부분 형태의) UDP 트래픽을 차단하도록 설정되어 있기 때문에, 인터넷 전화 애플리케이션은 UDP 통신이 실패할 경우를 대비하여 TCP를 사용하도록 설계되어 있다.

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

애플리케이션 계층 프로토콜(application-layer protocol) 은 다른 종단 시스템에서 실행되는 애플리케이션의 프로세스가 서로 메시지를 보내는 방법을 정의한다. 애플리케이션 계층 프로토콜은 다음과 같은 내용을 정의한다.

• 교환 메시지 타입(예: 요청 메시지와 응답 메시지)
• 여러 메시지 타입의 문법(예: 메시지 내부의 필드와 필드 간의 구별 방법)
• 필드의 의미, 즉 필드에 있는 정보의 의미
• 언제 어떻게 프로세스가 메시지를 전송하고 메시지에 응답하는지 결정하는 규칙

여러 애플리케이션 계층 프로토콜은 RFC에 명시되어 있으므로 공중 도메인(public domain)에서 찾을 수 있다. 예를 들어, 웹의 애플리케이션 계층 프로토콜인 HTTP는 RFC로 얻을 수 있다. 만약 브라우저 개발자가 HTTP(HyperText Transfer Protocol) RFC의 규칙을 따른다면, 브라우저는 HTTP RFC의 규칙을 따른 어떠한 웹 서버로부터도 웹 페이지를 가져올 수 있다. 다른 많은 애플리케이션 게층 프로토콜은 독점이며(비개방적임) 공중 도메인에서 구할 수 없다. 예를 들어 스카이프는 비개방 애플리케이션 계층 프로토콜을 사용한다.

네트워크 애플리케이션과 애플리케이션 계층 프로토콜을 구별하는 것은 중요하다. 애플리케이션 계층 프로토콜은 네트워크 애플리케이션의 한 요소일 뿐이다.두 가지 예를 살펴보자. 웹은 사용자가 필요에 따라 웹 서버로부터 문서를 얻게 해주는 네트워크 애플리케이션이다. 웹 애플리케이션은 문서 포맷 표준(HTML), 웹 브라우저(예: 크롬, 마이크로소프트 인터넷 익스플로러), 웹 서버(예: 아파치, 마이크로소프트 서버), 애플리케이션 계층 프로토콜을 포함하는 여러 요소들로 구성된다. 웹 애플리케이션 계층 프로토콜, HTTP는 브라우저와 웹 서버 사이에서 교환되는 메시지의 포맷과 순서를 정의한다. 따라서 HTTP는 단지 웹 애플리케이션의 한 요소다. 또 다른 예로서, 2.6절에서 살펴볼 넷플릭스 비디오 서비스를 생각해보자. 이 서비스는 비디오를 저장, 전송하는 서버, 과금과 다른 클라이언트기능을 관리하는 서버, 클라이언트(예: 넷플릭스), 넷플릭스 서버와 클라이언트 사이에서 교환되는 메시지 포맷과 시퀀스를 정의하는 애플리케이션 게층 DASH 프로토콜 등과 같은 여러 요소들로 이루어져 있다. 따라서 DASH는 넷플릭스 애플리케이션의 한 요소일 뿐이다.

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

새로운 공중 도메인과 독점 인터넷 애플리케이션이 매일 개발되고 있다. 여기서는 백과사전식으로 많은 인터넷 애프리케이션을 다루기보다는 중요하고 인기 있는 애플리케이션에 초점을 맞추기로 한다. 이 장에서는 5개의 주요 애플리케이션 분야(웹, 전자메일, 디렉터리 서비스, 비디오 스트리밍, P2P 애플리케이션)를 자세히 다룬다. 먼저 웹을 다루는데, 웹이 매우 인기 있는 애플리케이션이라는 이유 이외에도 이것의 애플리케이션 계층 프로토콜(HTTP)이 이해하기 쉽고 간단하기 때문이다. 그리고 인터넷의 첫 번째 킬러 애플리케이션인 전자메일에 대해 논의한다. 전자메일은 한 가지가 아니라 여러 애플리케이션 계층 프로토콜을 사용한다는 관점에서 웹보다 복잡하다. 전자메일 이후에는 인터넷을 위한 디렉터리 서비스를 제공하는 DNS를 다룬다. 다음으로 P2P 파일 공유 애플리케이션을 논의한 후 CDN(content distribution network)상에서의 저장 비디오 배분을 포함하는 비디오 스트리밍 온디맨드에 대해 논의함으로써 애플리케이션에 대한 연구를 마친다.