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

네트워크 애플리케이션 개발의 중심은 다른 위치의 종단 시스템에서 동작하고 네트워크를 통해 서로 통신하는 프로그램을 작성하는 것이다.

예를 들어, 웹 애플리케이션에는 서로 통신하는 서버(웹 서버 프로그램)와 클라이언트(사용자 호스트에서 실행되는 브라우저 프로그램)로 구별되는

두 가지 프로그램이 있다.

중요한 것은 우리가 라우터나 링크 계층 스위치처럼 네트워크 코어 장비에서 실행되는 소프트웨어까지 작성할 필요는 없다는 점이다.

(그렇게 하고 싶더라도 네트워크 코어 장비는 애플리케이션 계층에서 기능하지 않기 때문에 그렇게 할 수 없다.)

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

애플리케이션 구조는 네트워크 구조와 분명히 다르다.

애플리케이션 개발자 관점에서 네트워크 구조는 고정되어 있고, 해당 애플리케이션의 특정 서비스 집합을 제공한다.

반면, 애플리케이션 구조는 애플리케이션 개발자가 설계하며, 애플리케이션이 여러 종단 시스템에서 어떻게 조직되어야 하는지를 알려준다.

잘 알려진 애플리케이션 구조 2가지

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

항상 동작하고 있는 서버가 존재하고, 클라이언트라는 다른 호스트들로부터 서비스 요청을 받는다.

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

서버는 잘 알려진 고정 IP 주소를 갖는다.

서버가 클라이언트로부터 오는 모든 요청에 더 응답하는 것이 불가능할 때,많은 수의 호스트를 갖춘 데이터 센터가 강력한 가상의 서버를 생성하는 역할로 사용된다. 보통, 10만개 정도의 서버를 갖추고 있다.

P2P 구조

항상 켜져있는 인프라스트럭처 서버에 최소로 의존한다. (혹은 의존하지 않는다.)

대신에 애플리케이션은 peer라는 간헐적으로 연결된 호스트 쌍이 서로 직접 통신하게 한다.

peer는 흔히 알려진 클라이언트(개인 데스크톱과 랩톱 등등)이다.

자가 확장성을 가진다. 예를 들어, 파일 공유 애플리케이션에서는 각 피어들이 파일을 요구하여 작업 부하가 생기지만각 피어들은 파일을 다른 피어들에게 분배하여 시스템에 서비스 능력을 갖춘다.

데이터 센터 등이 필요 없으므로 비용 효율적이다.

2.1.2 프로세스 간 통신

실제 통신하는 것은 프로그램이 아니라, 실행되고 있는 프로그램인 프로세스이다.

2개의 종단 시스템에서 프로세스는 컴퓨터 네트워크를 통한 메시지 교환으로 서로 통신한다.

송신 프로세스는 메시지를 만들어서 보내고 수신 프로세스는 메시지를 받고 역으로 메시지를 보냄으로써 응답한다.

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

네트워크 애플리케이션은 네트워크에서 서로 메시지를 보내는 두 프로세스로 구성된다.

클라이언트와 서버 프로세스를 다음과 같이 정의한다.

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

간단히 말하면, 요청을 보내는 쪽의 프로세스를 보통 클라이언트라고 하고, 요청을 받는 쪽을 서버라고 한다.

당연히 P2P 구조에서 봤듯이, 클라이언트도 서버 프로세스가 될 수 있고, 서버도 클라이언트 프로세스가 될 수 있다.

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

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

네트워크에서 프로세스를 집이라 한다면, 소켓은 마치 문과 같은 존재이다.

위 그림에 보이듯이, 소켓은 호스트의 애플리케이션 계층과 트랜스포트 계층간의 인터페이스다.

네트워크 애플리케이션이 인터넷에 만든 프로그래밍 인터페이스이므로, 애플리케이션과 네트워크 사이의 API라고도 한다.

애플리케이션 개발자는 소켓의 애플리케이션 계층에 대한 모든 통제권을 갖지만, 소켓의 트랜스포트 계층에 대한 통제권은 거의 갖지 못한다.

애플리케이션 개발자의 트랜스포트 계층에 대한 통제

트랜스포트 프로토콜을 선택

최대 버퍼와 최대 세크먼트 크기 같은 약간의 매개변수 설정

프로세스 주소 배정

프로세스가 다른 수행되고 있는 다른 패킷으로 프로세스를 보내기 위해서는 수신 프로세스가 주소를 갖고 있어야 한다.

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

호스트의 주소 즉, IP 주소가 필요하다.

호스트 내의 수신 프로세스를 명시하는 식별자 즉, port 번호가 필요하다. 더 자세한 내용은 3장에서 다룬다.

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

송신 측의 애플리케이션은 소켓을 통해 메시지를 보내고,
트랜스포트 프로토콜은 네트워크를 통해 그 메시지를 수신 프로세스의 소켓으로 이동시킬 책임이 있다.

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

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

신뢰적 데이터 전송(data integrity)

처리율(throughput)

시간(timing)

보안(security)

신뢰적 데이터 전송(data integrity)

1장에서 보았듯이, 패킷들은 컴퓨터 네트워크 내에서 손실될 수 있다.

이러한 데이터 손실은 위험한 결과를 초래할 수 있다.

만약 프로토콜이 보장된 데이터 전송 서비스를 제공한다면 신뢰적 데이터 전송이라고 한다.

트랜스포트 프로토콜이 이 서비스를 제공할 때, 송신 프로세스는 데이터를 소켓으로 보내고 그 데이터가 오류 없이 수신 프로세스에 도착할 것이라는 확신을 갖는다.

트랜스포트 프로토콜이 이 서비스를 제공하지 않을 때 송신 프로세스가 보낸 데이터는 전혀 도착하지 않을 수 있다.

이러한 애플리케이션을 손실 허용 애플리케이션(실시간 비디오/오디오 애플리케이션 등이 대표적)이라고 한다.

처리율(throughput)

다른 세션들이 네트워크 경로를 따라 대역폭을 공유하고, 이 세션들이 생겼다 없어졌다 하기 때문에 가용한 처리율은 시간에 따라 변한다.

트랜스포트 프로토콜은 어느 명시된 속도에서 보장된 가용 처리율을 제공한다.

처리율 요구사항을 갖는 애플리케이션은 대역폭 민감 애플리케이션이라 하고, 현존하는 많은 멀티미디어 애플리케이션은 대역폭에 민감하다.

(너무 처리율이 낮으면 전화같은 서비스가 불가능하다.)

반대로 요구사항이 없는 애플리케이션을 탄력적 애플리케이션(elastic apps)이라고 한다.

시간(timing)

트랜스포트 프로토콜은 시간 보장을 제공할 수 있다.

예를 들어, 송신자가 소켓으로 내보내는 모든 비트가 수신자의 소켓에 100ms 내에 도착하게 할 수 있다.

실시간 애플리케이션에 주로 사용된다.

보안(security)

송신 호스트에서 트랜스포트 프로토콜은 모든 데이터를 암호화할 수 있고, 수신 호스트에서 트랜스포트 프로토콜은 모두 해독할 수 있다.

보통 TCP를 애플리케이션 계층에서 강화하여 TLS로 보안 서비스를 제공한다. (자세한 내용은 8장에서 다룬다.)

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

1️⃣ TCP 서비스

TCP 전송 프로토콜은 다음 세 가지 서비스를 제공한다.

연결 지향형 서비스

애플리케이션 계층 메시지를 전송하기 전에 TCP는 클라이언트와 서버가 서로 전송 제어 정보를 교환하게 한다.

이 핸드 셰이킹(handshaking) 과정이 클라이언트와 서버에 패킷이 곧 도달할테니 준비하라고 알려주는 역할을 한다.

핸드셰이킹 단계를 지나면, TCP 연결이 두 프로세스의 소켓 사이에 존재한다고 말한다.

이 연결은 두 프로세스가 서로에게 동시에 메시지를 보낼 수 있기에 전이중 연결이라고 한다. (3장에서 더 자세히 다룬다.)

신뢰적인 데이터 전송 서비스

통신 프로세스는 모든 데이터를 오류 없이 올바른 순서로 전달하기 위해 TCP에 의존한다.

TCP는 애플리케이션의 한 쪽이 바이트 스트림을 소켓으로 전달하면, 그 바이트 스트림이 손실되거나 중복되지 않게 수신 소켓으로 전달한다.

혼잡 제어 방식

네트워크가 혼잡 상태에 이르면 프로세스의 속도를 낮추는 방법 (또한, 3장에서 자세히 다룬다.)

2️⃣ UDP 서비스

UDP는 최소의 서비스 모델을 가진 간단한 전송 프로토콜이다.

UDP는 비연결형으로 핸드셰이킹 과정이 없고, 비신뢰적인 데이터 전송 서비스를 제공하여 데이터가 전달되는 것을 보장하지 않는다.

UDP는 또한 혼잡 제어 방식을 포함하지 않아 프로세스의 속도 저하 없이 네트워크를 이용할 수 있다.

그러나 혼잡으로 인해 종단 간 처리율이 낮아져서 속도가 오히려 더 낮아질 수 있다.

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

TCP와 UDP는 처리율 혹은 시간 보장 서비스를 제공하지 않는다.

시간 민감 애플리케이션 같은 경우에는 이러한 처리율 및 시간 지연에 잘 대처할 수 있도록 설계되어 있다.

그러나 지연이 과도할 때는 보장이 없기 때문에 한계가 있다.

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

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

이는 다음과 같은 내용을 정의한다.

교환 메시지의 타입

여러 메시지 타입의 문법(syntax)

필드의 의미, 즉 필드에 있는 정보의 의미(semantics)

언제, 어떻게 프로세스가 메시지를 전송하고 메시지에 응답하는지를 결정하는 규칙

여러 애플리케이션 계층 프로토콜은 RFC에 명시되어 있어 공중 도메인에서 찾을 수 있다.

예를 들어, 만약 브라우저 개발자가 HTTP 규칙을 따른다면, HTTP 규칙을 따른 어떠한 웹 서버로부터도 웹페이지를 가져올 수 있다.

다른 많은 애플리케이션 계층 프로토콜은 독점이며 공중 도메인에서 찾을 수 없다.

애플리케이션 계층 프로토콜은 네트워크 애플리케이션의 한 요소일 뿐이다.

예를 들어, 웹 애플리케이션은 문서 포맷 표준, 웹 브라우저, 웹 서버, 웹 애플리케이션 계층 프로토콜(HTTP)을 포함하는 여러 요소들로 구성된다.

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

이 책에서는 중요하고 인기 있는 5개의 애플리케이션 분야에 초점을 맞춘다.

전자메일

디렉터리 서비스

비디오 스트리밍

P2P 애플리케이션

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