컴퓨터 네트워크는 네트워크 애플리케이션들을 위해 존재한다. 이 장에서는 네트워크 애플레케이션의 개념과 구현에 대해 알아보도록 하자. 우선은 애플리케이션에 필요한 네트워크 서비스, 클라이언트와 서버, 프로세스, 전송 계층 인터페이스 등 애플리케이션 계층의 핵심 개념들에 대해 알아보고 나서, 웹, 이메일, DNS, P2P 파일 분산, 비디오 스트리밍 등의 네트워크 애플리케이션의 디테일들에 대해 알아본다.
1. Network Application Architectures
애플리케이션 아키텍처는 이전에 배웠던 네트워크의 아키텍처와는 다르다. 애플리케이션 개발자의 입장에서 보면, 네트워크 아키텍처는 고정되어 있고 애플리케이션에 구체적인 서비스를 제공하는 역할을 할 뿐이다. 이와 달리 애플리케이션 아키텍처는 애플리케이션 개발자가 설계하며, 애플리케이션이 어떻게 여러 종단 시스템에 걸쳐 구성되어야 하는지를 말한다. 애플리케이션 아키텍쳐를 선택할 때, 애플리케이션 개발자는 보통 자주 쓰이는 두 아키텍처 패러다임인 클라이언트-서버 구조와 P2P(peer-topeer) 구조 중 하나를 고른다.
Client-Server Architecture
클라이언트-서버 아키텍처에는 항상 켜져있는 호스트인 서버가, 다른 많은 호스트들, 그러니까 클라이언트들로부터 오는 요청들을 받아 서비스한다. 대표적인 예로는 클라이언트 호스트의 브라우저로부터의 요청들을 서비스하는 웹 서버 애플리케이션이 있다.
클라이언트-서버 구조에서 클라이언트들은 서로 직접 통신을 하지 않으며, 잘 알려진 고정된 IP 주소를 가지고 있는 서버를 통해 간접적으로 통신한다. 서버가 고정된, 잘 알려진 IP 주소를 가지고 있고, 또 항상 켜져있는 덕에 클라이언트는 서버의 IP 주소에 패킷을 보냄으로써 서버와 연결할 수 있게 된다. 클라이언트-서버 구조를 사용하는 잘 알려진 애플리케이션에는 웹, FTP, 텔넷, 이메일 등이 있다.
클라이언트-서버 애플리케이션의 경우, 하나의 서버 호스트가 클라이언트들로부터 오는 모든 요청을 처리하지 못할 수도 있기 때문에, 데이터 센터를 이용하기도 한다.
P2P Architecture
P2P 구조에서는 클라이언트-서버 구조와 달리 전용(dedicated) 서버에 거의 의존하지 않는다. 대신 이 구조에서 호스트는 다른 호스트(peer)와 간헐적으로, 직접 연결을 맺는다. 전용 서버를 거치지 않고 피어끼리 직접 통신하기 때문에 이러한 구조를 peer-to-peer, P2P 구조라 부른다. BitTorrent, Kunlei, Skype 등, 트래픽이 많이 발생하는 애플리케이션의 경우 P2P 아키텍처를 많이 사용한다.
P2P 구조의 가장 강력한 특징 중 하나는 자체-확장성(self-scalability)이다. 예를 들어 P2P 파일 공유 애플리케이션에서, 각 피어는 파일을 요청함으로써 워크로드를 생성함과 동시에 파일을 다른 피어에 분산시킴으로써 시스템에 서비스 capacity를 추가하기도 한다. P2P는 비용상으로도 효율적이다. 데이터센터를 이용해야 할 수도 있는 클라이언트-서버와 달리, 큰 서버 인프라나 서버 대역폭이 필요하지 않기 때문이다. 다만 P2P 애플리케이션의 경우 고도로 분산되어 있어 보안, 성능, 신뢰성 문제를 해결하는 데 어려움이 있다.
Combined Architecutre
물론 위 두 구조를 혼합한 형태도 있다. 예를 들어, 인스턴트 메신저들 중 일부는 사용자 IP 추적을 위해 서버를 사용하기는 하지만, 사용자 간 메시지는 서버를 거치지 않고 직접 상대에게로 보내진다.
2. Processes Communicating
네트워크 애플리케이션을 만드려면 여러 종단 시스템에서 실행되는 프로그램들이 어떻게 서로 통신을 할 수 있는지에 대해 알아야 한다. 서로 다른 두 종단 시스템의 프로세스들은 컴퓨터 네트워크를 통해 메시지를 교환해 서로 통신하는데, 송신 프로세스는 메시지를 만들어 네트워크로 보내고, 수신 프로세스는 이 메시지를 받아 그에 맞는 메시지를 다시 보낸다.
Client and Server Processes
네트워크 애플리케이션에는 네트워크를 통해 서로에게 메시지를 보내는 프로세스의 쌍들이 있다. 예를 들어 웹 애플리케이션에서 클라이언트 브라우저 프로세스는 웹 서버 프로세스와 메시지를 교환하고, P2P 파일 공유 시스템에서 파일은 한 피어의 프로세스에서 다른 피어의 프로세스로 전송된다. 각 통신 프로세스 쌍에 대해, 보통 한 쪽 프로세스는 클라이언트, 다른 프로세스는 서버라 부른다. 웹의 경우, 브라우저가 클라이언트, 웹 서버가 서버 프로세스가 되고, P2P 파일 공유의 경우 파일을 다운로드 쪽이 클라이언트, 파일을 업로드하는 쪽이 서버가 된다.
사실 P2P의 경우, 한 프로세스가 클라이언트도, 서버도 될 수 있다. P2P 파일 공유 시스테의 프로세스는 파일을 업로드할 수도, 다운로드 할 수도 있기 때문이다. 따라서 통신 세션에서의 서버와 클라이언트는 다음과 같이 정의하는 게 더 정확하다.
한 프로세스 쌍 사이의 통신 세션의 맥락에서, 통신을 시작하는 프로세스를 클라이언트, 누군가가 접속해 세션을 시작해주기를 기다리는 프로세스를 서버라 한다.
웹의 경우, 브라우저 프로세스가 웹 서버 프로세스와의 통신을 시작하므로 브라우저가 클라이언트가 되고 웹 서버 프로세스가 서버가 된다. P2P 파일 공유의 경우, 특정 파일을 보내달라 요청하는 피어가 클라이언트, 그에 응답해 파일을 보내주는 피어가 서버가 된다.
Interface Between the Process and the Computer Network
프로세스는 소켓(socket)이라 불리는 소프트웨어 인터페이스를 통해 네트워크로 메시지를 보내고 받는다.
위 그림은 인터넷을 통해 통신하는 두 프로세스의 소켓 통신을 보여주고 있다. 이 그림에서와 같이 소켓은 호스트의 애플리케이션-계층과 전송-계층 사이에 위치하는 인터페이스고, 그렇기 때문에 소켓은 애플리케이션과 네트워크 사이의 API라고도 불린다. 네트워크 애플리케이션은 소켓 인터페이스 위에 만들어지기 때문이다.
애플리케이션 개발자는 소켓의 애플리케이션-계층 쪽의 모든 것들을 제어하는 한편, 소켓의 전송-계층 쪽에 대해서는 거의 제어를 하지 않는다. 애플리케이션 개발자가 전송-계층에 대해 할 수 있는 일은 고작 해야 (1) 전송 프로토콜을 선택하는 일과 (2) 버퍼와 세그먼트의 최대 크기와 같은 몇몇 전송-계층 파라미터를 수정하는 일 정도 밖에 없다. 애플리케이션 개발자가 전송 프로토콜을 선택하고 나면, 애플리케이션은 그 프로토콜이 제공하는 전송-계층 서비스를 이용해 만들어진다.
Addressing Processes
한 호스트에서 실행되는 프로세스에서 다른 호스트에서 실행되는 프로세스로 패킷을 보낼 때, 수신 프로세스는 주소를 가지고 있어야 한다. 수신 주소의 식별을 위해서는 두 종류의 정보가 필요한데, (1) 호스트의 주소와 (2) 목적지의 호스트 내의 해당 수신 프로세스를 지정하는 식별자다.
인터넷에서, 호스트는 IP 주소를 통해 식별된다. IP 주소에 대해서는 나중에 4장에서 자세히 다루게 될 것이고, 지금은 해당 호스트를 유일하게 지정할 수 있는 32-bit 크기라는 것 정도만 알아두자. 보통 한 호스트 내에서는 많은 네트워크 애플리케이션이 실행될 수 있기 때문에, 호스트가 누구인지를 알게 되고 나면, 이제는 수신 프로세스가 누구인지를 알아야 한다. 목적지의 포트(port) 번호가 이 역할을 한다. 유명한 애플리케이션은 특정 포트 번호를 가지고 있기도 하는데, 예를 들어 웹 서버의 경우 80번, (SMTP 프로토콜을 사용하는) 메일 서버의 경우 25번 포트를 사용한다.
3. Transport Services Available to Applications
애플리케이션은 소켓을 통해 전송 계층으로 메시지를 밀어 넣고, 소켓의 다른 쪽에 있는 전송 계층의 프로토콜은 수신 프로세스의 소켓으로 메시지를 밀어 넣는다.
인터넷을 포함한 많은 네트워크들은 하나 이상의 전송 프로토콜들을 제공하기 때문에, 애플리케이션을 개발할 때에는 그 중 하나를 선택해야만 한다. 이러한 선택은 어떤 기준으로, 어떻게 내릴 수 있을까?
Reliable Data Transfer
1장에서 말한 것과 같이, 패킷은 컴퓨터 네트워크에서 손실이 될 수도 있다. 파일 전송, 이메일 등 패킷 손실이 끔찍한 결과를 일으킬 수 있는 애플리케이션의 경우, 애플리케이션의 한쪽 종단에서 보내진 데이터가 애플리케이션의 다른 종단으로 제대로, 완벽히 도달함이 보장되어야 한다.
만약 프로토콜이 이러한 서비스를 제공한다면, 프로토콜이 신뢰할 수 있는 데이터 전송(reliable data transfer)을 제공한다고 말한다. 전송-계층 프로토콜이 애플리케이션에 제공할 수 있는 한 가지 주요 서비스 중 하나가 바로 이 프로세스 간의 신뢰할 수 있는 데이터 전송이다. 전송 프로토콜이 이 서비스를 제공한다면, 송신 프로세스는 그저 자신의 데이터를 소켓으로 밀어넣기만 하면 되고, 데이터가 오류없이 수신 프로세스에 도착할 것임을 확신할 수 있게 된다.
전송-계층 프로토콜이 이러한 서비스를 제공하지 않으면, 송신 프로세스에서 보낸 데이터의 일부는 수신 프로세스에 도착하지 않을 수도 있다. 어느 정도의 데이터 손실은 감안할 수 있는 애플리케이션을 loss-tolerant application이라 부르는데, 대표적으로는 멀티미디어 애플리케이션이 있다. 멀티미디어 애플리케이션의 경우 데이터 손실이 일어나도 오디오나 비디오에 큰 결함을 일으키지는 않기 때문이다.
Throughput
처리량(throughput)은 네트워크 경로를 따르는 두 프로세스의 통신 세션의 맥락에서, 송신 프로세스에서 수신 프로세스로 비트를 보내는 속도를 말한다. 다른 세션들도 네트워크 경로의 대역폭을 공유하고, 이 세션들은 생기거나 사라지기 때문에, 처리량은 시간에 따라 변동하기도 한다. 따라서 전송-계층 프로토콜은 특정 속도 이상의 처리량을 보장하는 서비스를 제공할 수 있어야 한다. 애플리케이션은 bits/sec의 처리량을 이 서비스에 요청하고, 전송 프로토콜은 처리량이 항상 bits/sec임을 보장한다.
일정 수준 이상의 처리량을 필요로 하는 애플리케이션들이 있는데, 이러한 애플리케이션을 bandwidth-sensitive application이라 부른다. 예를 들면 인터넷 전화 애플리케이션의 경우 음성을 32kbps로 인코딩해, 이 데이터를 네트워크에 보내며, 수신 애플리케이션도 이 데이터를 이 속도로 받아야만 한다. 만약 전송 프로토콜이 이 처리량을 제공하지 못하면 애플리케이션은 (예를 들면) 16kbps로 음성을 인코딩하거나, (16kbps의 음성 인코딩은 거의 쓸모가 없기 때문에) 전송을 포기하게 된다. 어떤 멀티미디어 애플리케이션들은 현재 사용할 수 있는 처리량에 맞도록 디지털화된 음성이나 비디오를 인코딩하는 테크닉을 사용하기는 하지만, 현대의 많은 멀티미디어 애플리케이션들은 bandwidth-sensitive하다.
이와 달리 처리량을 현재 제공될 수 있는 것에 맞게 이용하는 애플리케이션도 있는데, 이를 elastic application이라 한다. 이메일, 파일 전송 등은 elastic application들이다.
Timing
전송-계층 프로토콜은 타이밍도 보장할 수 있어야 한다. 예를 들면 송신자가 소켓으로 보내는 모든 비트가 수신자 소켓에 적어도 100 msec보다는 빨리 도착해야 하는 경우를 생각할 수 있다. 이런 서비스는 인터넷 전화, 가상 환경, 원격 회의, 멀티플레이어 게임 등등과 같이, 인터랙티브한 실시간 애플리케이션에게 꼭 필요하다. 실시간 애플리케이션이 아닌 경우에도 딜레이가 적은 것이 더 선호되기는 하지만, 그렇게 타이트한 제한이 있지는 않다.
Security
전송 프로토콜은 애플리케이션에 하나 이상의 보안 서비스도 제공할 수 있다. 예를 들어 송신 호스트에서 전송 프로토콜은 송신 프로세스가 보내는 모든 데이터를 암호화하고, 수신 호스트에서는 해당 데이터를 복호화해 수신 프로세스로 보낼 수 있다. 이러한 서비스를 통해, 각 종단 프로세스는 해당 데이터를 주고 받을 수 있으면서도, 두 프로세스 사이에서의 기밀성 또한 보장될 수 있다.
4. Transport Services Provided by the Internet
지금까지는 조금 일반적인 얘기를 해왔다면, 이제는 인터넷(정확히는 TCP/IP 네트워크)에서 제공되는 두 전송 프로토콜, UDP와 TCP에 대해 알아보자. 이 두 프로토콜은 애플리케이션에 서로 다른 서비스 집합을 제공한다. 네트워크 애플리케이션을 개발할 때에는 우선 애플리케이션의 요구 사항들에 따라 TCP와 UDP 중 하나를 선택해야 할 것이다.
TCP Services
TCP 서비스 모델에는 연결-기반 서비스와 신뢰할 수 있는 데이터 전송 서비스가 포함되어 있다. TCP를 전송 프로토콜로 선택한 애플리케이션의 경우, TCP가 제공하는 그 두 서비스를 이용할 수 있다.
- Connection-oriented Service
TCP의 경우, 애플리케이션 레벨의 메시지가 흐르기 전에 서버와 클라이언트가 전송-계층 컨트롤 정보를 교환한다. 핸드셰이킹(handshaking)이라 부르는 이 과정에서 두 프로세스는 패킷 교환을 위한 준비를 한다.
핸드셰이킹이 끝나면 두 프로세스의 소켓 사이에 TCP 연결(TCP connection)이 생겼다고 말한다. 이 연결은 전이중 연결로, 두 프로세스는 서로에게 동시에 메시지를 보낼 수 있다. 애플리케이션이 메시지 전송을 마치고 나면 연결은 끊어진다.
3장에서 연결-기반 서비스와 그 구현에 대해 더 자세히 알아보게 될 것이다.
- Reliable data transfer service
TCP를 사용하는 경우, 서로 통신하는 프로세스들은 모든 데이터가 오류없이, 제대로 된 순서로 전달됨을 믿을 수 있다. 송신 프로세스는 자신이 소켓으로 보낸 바이트 스트림이 수신측 소켓에 누락, 혹은 중복없이 도착함을 믿을 수 있다.
TCP는 혼잡-제어 메커니즘도 제공한다. 네트워크가 혼잡할 때 송신 프로세스(클라이언트 혹은 서버)에 감속(throttle)을 거는 메커니즘이다.
UDP Services
UDP는 부가 기능이 없는, 최소의 서비스만을 제공하는 경량화된 전송 프로토콜이다. UDP는 연결-기반이 아니기 때문에(connectionless), 두 프로세스 사이의 통신이 시작하기 전에 핸드셰이킹 과정은 일어나지 않는다. UDP는 신뢰성 있는 데이터 전송 서비스를 제공하지 않기 때문에, 전송된 메시지가 수신 측에 도달함을 보장할 수 없고, 송신 측에서 보낸 데이터가 수신 측에 순서대로 도착함을 보장할 수도 없다.
UDP에는 혼잡-제어 메커니즘도 없기 때문에, 송신측의 UDP는 그 아래의 네트워크 계층으로 자기가 원하는 속도로 데이터를 밀어넣는다.
Services Not Provided by Internet Transport Protocols
전송 프로토콜을 신뢰할 수 있는 데이터 전송, 처리량, 타이밍, 보안의 네 차원에서 이야기했는데, TCP와 UDP는 이 서비스들 중 어떤 것을 제공할까? 앞서 봤듯 TCP는 신뢰성 있는 데이터 전송 서비스를 제공한다. TCP와 함께 SSL을 사용하면 애플리케이션에 보안 서비스도 제공할 수 있다.
오늘날의 인터넷 전송 프로토콜에서 타이밍 서비스는 제공되지 않는다. 그럼에도 타이밍이 중요한 실시간 애플리케이션들이 제대로 실행될 수 있는 이유는, 이 애플리케이션들이 그러한 보장이 없더라도 대부분의 경우 잘 돌아가도록 설계됐기 때문이다. 물론 아무리 설계가 좋아도 딜레이가 너무 심해지거나 end-to-end 처리량이 너무 제한되는 경우는 대처하기 어렵다.
아래는 유명한 인터넷 애플리케이션들이 사용하는 전송 프로토콜들이다. TCP를 쓰는 애플리케이션들은 TCP가 데이터 전송의 신뢰성을 제공하기 때문에 TCP를 선택한다. 인터넷 전화 애플리케이션의 경우, 데이터 손실에 대한 내성이 있으면서 속도가 중요하기 때문에 보통 UDP를 사용한다. 하지만 많은 방화벽들이 보통 UDP 트래픽은 막도록 설정되어 있기 때문에, 인터넷 전화의 경우 UDP 통신이 실패하는 경우를 위해 TCP 연결도 사용한다.
5. Application-Layer Protocols
네트워크 프로세스들이 소켓을 통해 서로 통신함을 알게 됐다. 그렇다면 이렇게 교환되는 메시지들은 어떻게 만들어지는 걸까? 메시지의 필드들은 무슨 의미일까? 프로세스는 언제 메시지를 보낼까? 애플리케이션-계층의 프로토콜이 서로 다른 종단 시스템에서 실행되는 애플리케이션 프로세스들이 어떻게 서로에게 메시지를 보내야 하는지를 정의한다.
구체적으로, 애플리케이션-계층의 프로토콜은 다음을 정의한다.
- 교환될 메시지의 타입. 예를 들면 요청 메시지인지, 응답 메시지인지.
- 여러 메시지 타입의 신택스. 예를 들면 메시지 내 필드 및 그 필드가 어떻게 설명되는지.
- 각 필드의 정보가 어떤 의미인지.
- 언제 어떻게 프로세스가 메시지를 보내고 메시지에 응답하는지.
HTTP 등의 몇몇 애플리케이션-계층 프로토콜은 RFC에 공개되어 있는 한편, 어떤 것들은 독점적으로, 공개되어 있지 않기도 하다.
Network Application and Application-layer protocols
애플리케이션-계층 프로토콜은 네트워크 애플리케이션의 한 부분이다.
예를 들어 사용자가 웹 서버로부터 원하는 문서를 가져올 수 있게 하는 클라이언트-서버 애플리케이션인 웹의 경우, 웹 애플리케이션에는 문서 형식 표준(HTML), 웹 브라우저, 웹 서버, 애플리케이션-계층 프로토콜 등이 포함되어 있으며, 웹의 애플리케이션-계층 프로토콜인 HTTP에는 브라우저와 웹 서버 사이에서 교환되는 메시지의 형식 및 순서가 정의되어 있다. 다시 말해 HTTP는 웹 애플리케이션의 한 부분이다.
