네트워크 애플리케이션 개발의 중심은 다른 위치의 종단 시스템에서 동작하고 네트워크를 통해 서로 통신하는 프로그램을 작성하는 것이다.
예를 들어 웹 애플리케이션에서는 서로 통신하는 서버(웹 서버 프로그램)와 클라이언트(사용자 호스트에서 실행되는 브라우저 프로그램)로 구별되는 두 가지 프로그램이 있다.
애플리케이션 개발할 때는 여러 종단 시스템에서 실행되는 소프트웨어를 작성해야함. 중요한 것은 우리가 라우터나 링크 계층 스위치처럼 네트워크 코어 장비에서 실행되는 소프트웨어까지 작성할 필요는 없다는 점이다.
(네트워크 코어 장비는 네트워크 계층 및 그 하위 계층에서 기기능하기에 직접 개발하고 싶더라도 불가능하다.)
2.1.1 네트워크 애플리케이션 구조
애플리케이션 구조는 네트워크 구조(5가지 계층으로 구성되어 있는 인터넷 아키텍처)와 다르다.
애플리케이션 개발자 관점에서 네트워크 구조는 고정되어 있고 해당 애플리케이션에 특정 서비스 집합을 제공한다.
반면, 애플리케이션 구조는 애플리케이션 개발자가 설계하며, 애플리케이션이 다양한 종단 시스템에서 어떻게 조직되어야 하는지를 알려준다.
잘 알려진 애플리케이션 구조 2가지
 |  |
|---|---|
| 클라이언트-서버 구조 | P2P구조 |
- 클라이언트-서버 구조
서버: 항상 동작하고 있는 호스트- 서버와의 서비스는
클라이언트라는 다른 호스트들로부터 서비스 요청을 받는다. - 웹 서버가 클라이언트 호스트로부터 객체를 요청받으면 웹 서버는 요청된 객체를 클라이언트 호스트로 보내면서 응답한다.
- 클라이언트-서버 구조에서 클라이언트는 서로 직접적으로 통신하지 않는다는 점에 주목할 필요가 있다.
- 서버가 고정 IP주소라는 잘 알려진 주소를 갖는다.
- 서버는 항상 동작하고 있으므로 클라이언트는 서버 주소로 패킷을 보내서 언제든지 서버에 연결할 수 있다.
- 웹, 파일 전송, 원격 로그인, 전자메일이 있다.
- 클라이언트-서버 애플리케이션에서 하나의 서버 호스트가 자신의 클라이언트로부터 오는 모든 요청에 다 응답하는 것은 불가능하다.
- 데이터 센터가 강력한 가상의 서버를 생성하는 역할로 사용된다. (많은 호스트 수를 갖춤.)
- P2P 구조
- 항상 켜져 있는 인프라스트럭처 서버에 최소로 의존한다.(혹은 전혀 의존하지 않는다.)
- 애플리케이션은
피어라는 간헐적으로 연결된 호스트 쌍이 서로 직접 통신하게 한다. 피어는 서비스 제공자가 소유하지 않고 사용자들이 제어하는 데스크톱과 랩톱이며, 대부분의 피어들은 가정, 대학, 사무실에 위치한다.- 특정 서버를 통하지 않고 피어가 통신하므로 이 구조를 피어 투 피어라고 한다.
- 파일 공유 애플리케이션인 비트토랜토가 있다.
- 가장 주목할 만한 특성 중의 하나가 자가 확장성이 있다는 것이다.
- P2P 파일 공유 애플리케이션에서는 비록 각 피어들이 파일을 요구함으로써 작업 부하를 만들어내지만 각 피어들은 또한 파일을 다른 피어들에게 분배함으로써 그 시스템에 서비스 능력을 추가한다.
- 비용 또한 효율적이다. 상당한 서버 인프라스트럭처와 서버 대역폭을 요구하지 않기 때문이다.
- 미래 P2P 애플리케이션들은 이들의 고도의 분산 구조 특성으로 인해 보안, 성능, 신뢰성 면에서 커다란 도전을 맞이하고 있다.
2.1.2 프로세스 간 통신
운영체제 용어에서 실제 통신하는 것은 프로그램이 아니라 프로세스다.
프로세스는 종단 시스템에서 실행되는 프로그램이다. 통신 프로세스가 같은 종단 시스템에서 실행될 때 그들은 서로 프로세스 간에 통신한다.
프로세스 간의 통신을 위한 규칙은 종단 시스템의 운영체제에 의해 좌우된다.
(해당 책에서는 다른 호스트에서 실행되는 프로세스와의 통신이 관심 대상.)
2개의 종단 시스템에서 프로세스는 컴퓨터 네트워크를 통한 메시지 교환으로 서로 통신한다.
송신 프로세스는 메시지를 만들어서 네트워크로 보낸다(수신 프로세스는 메시지를 받고 역으로 메시지를 보냄으로써 응답한다.)
클라이언트와 서버 프로세스
네트워크 애플리케이션은 네트워크에서 서로 메시지를 보내는 두 프로세스로 구성된다.
통신하는 프로세스 각 쌍에 대해 일반적으로 클라이언트의 프로세스와 서버의 프로세스 중 하나로 이름 짓는다.
프로세스 간의 통신 세션 내용에서 여전히 한 프로세스를 클라이언트라 하고 다른 프로세스를 서버라고 부를 수 있다.
클라이언트와 서버의 프로세스를 아래와 같이 정의할 수 있다.
두 프로세스 간의 통신 세션에서 통신을 초기화(다른 프로세스와 세션을 시작하려고 접속을 초기화)하는 프로세스를 클라이언트라 하고, 세션을 시작하기 위해 접속을 기다리는 프로세스를 서버라 한다.
웹에서 브라우저는 웹 서버 프로세스와 접촉을 초기화한다. 그러므로 브라우저 프로세스는 클라이언트이고 웹 서버 프로세스는 서버다.
프로세스와 컴퓨터 네트워크 사이의 인터페이스
프로세스는 소켓을 통해 네트워크로 메시지를 보내고 받는다.
프로세스와 소켓의 이해를 돕는 비유를 생각해보자.
프로세스는 집이고 소켓은 출입구로 비유된다. 프로세스가 메시지를 다른 호스트의 프로세스로 보내고 싶을 때, 그것은 출입구(소켓) 바깥 네트워크로 메시지를 밀어낸다. 이 송신 프로세스는 네트워크를 거쳐 목적지 프로세스의 출입구로 메시지를 보내기 위해 송신 프로세스의 출입구 뒤편에 전송 구조가 있다고 가정한다.
메시지가 목적지 호스트에 도착하면 메시지는 수신 프로세스의 출입구를 거치고 수신 프로세스는 메시지를 처리한다.
소켓은 호스트의 애플리케이션 계층과 트랜스포트 계층 간의 인터페이스이다.
또한 소켓은 네트워크 애플리케이션이 인터넷에 만든 프로그래밍 인터페이스이므로, 애플리케이션과 네트워크 사이의 API라고도 한다.
애플리케이션 개발자는 소케스이 애플리케이션 계층에 대한 모든 통제권을 갖지만, 소켓의 트랜스포트 계층에 대한 통제권은 거의 갖지 못한다.
트랜스포트 계층에 대한 애플리케이션 개발자의 통제는 1. 트랜스포트 프로토콜의 선택 2. 최대 버퍼와 최대 세그먼트 크기와 같은 약간의 트랜스포트 계층 매개변수의 설정뿐이다.
프로세스 주소 배정
한 호스트상에서 수행되고 있는 프로세스가 패킷을 다른 호스트에서 수행되고 있는 프로세스로 패킷을 보내기 위해서는 수신 프로세스가 주소를 갖고 있을 필요가 있다.
수신 프로세스를 식별하기 위해서는 다음과 같은 두 가지 정보가 명시되어야 한다.
1. 호스트의 주소 2. 그 목적지 호스트 내의 수신 프로세스를 명시하는 식별자
인터넷에서 호스트는 IP주소로 식별된다. IP주소는 32비트로 구성되며, 호스트를 유일하게 식별한다.
메시지가 전달되어야 하는 호스트의 주소를 아는 것과 더불어 송신 호스트는 수신 호스트에서 수행되고 있는 프로세스(수신 소켓)도 식별해야 한다.
이 정보는 일반적으로 한 호스트가 많은 네트워크 애플리케이션을 수행할 수 있기 때문인데, 목적지 포트 번호가 이 목적을 위해 사용된다.
인기 있는 애플리케이션은 특정한 포트 번호가 할당된다.
예시- 웹 서버: 80번, 메일 서버(SMTP 프로토콜 사용): 25번
2.1.3 애플리케이션이 이용 가능한 트랜스포트 서비스
소켓이 애플리케이션 프로세스와 트랜스포트 프로토콜 간의 인터페이스라는 것을 기억하자.
송신 측의 애플리케이션은 그 소켓을 통해 메시지를 보낸다. 그 소켓의 반대편에서 트랜스포트 프로포콜은 네트워크를 통해 그 메시지를 수신 프로세스의 소켓으로 이동시킬 책임이 있다.
트랜스포트 계층 프로토콜이 그것을 이용하는 애플리케이션들에게 제공할 수 있는 서비스는 무엇인가? 가능한 서비스들을 넓은 범위에서 신뢰적 데이터 전송, 처리율, 시간, 보안이라는 네 가지 차원으로 분류할 수 있다.
신뢰적 데이터 전송
패킷들은 컴퓨터 네트워크 내에서 손실될 수 있다. 예를 들어 패킷은 라우터의 버퍼에서 오버플로되거나, 패킷의 비트가 잘못되면 호스트 혹은 라우터에 의해 버려질 수 있다.
이러한 애플리케이션을 지원하기 위해 한 애플리케이션이 보낸 데이터가 올바르고 완전히 다른 애플리케이션에 전달되도록 보장하기 위해 무엇인가 조취를 취해야 한다.
만약 프로토콜이 보장된 데이터 전송 서비스를 제공한다면 이를 신뢰적 데이터 전송을 제공한다고 한다.
트랜스포트 계층 프로토콜이 애플리케이션에 제공할 수 있는 한 가지 중요한 서비스는 프로세스 간 신뢰적 데이터 전송이다. 트랜스포트 프로토콜이 이 서비스를 제공할 때, 송신 프로세스는 데이터를 소켓으로 보내고 그 데이터가 오류 없이 수신 프로세스에 도착할 것이라는 확신을 갖는다.
트랜스포트 계층 프로토콜이 신뢰적 데이터 전송을 제공하지 않을 때, 송신 프로세스가 보낸 데이터는 수신 프로세스에 전혀 도착하지 않을 수 있다. 이것은 손실 허용 애플리케이션의 경우, 즉 어느 정도의 데이터 손실을 참아낼 수 있는 실시간 오디오/비디오 혹은 저장 오디오/비디오 같은 멀티미디어 애플리케이션에서는 받아들여질 수 있다.
처리율
네트워크 경로를 따라 두 프로세스간의 통신 세션에서 송신 플세스가 수신 프로세스로 비트를 전달할 수 있는 비율을 나타낸다.
트랜스포트 프로토콜이 제공할 수 있는 다른 자연적인 서비스, 즉 어느 명시된 속도에서 보장된 가용 처리율을 제공한다. 트랜스포트 프로토콜은 가용한 처리율이 항상 적어도 r bps임을 보장한다.
처리율 요구사항을 갖는 애플리케이션은 대역폭 민감 애플리케이션이라고 한다.
어떤 멀티미디어 애플리케이션들은 현재 가용한 처리율에 맞는 속도로 디지털화된 음성 혹은 비디오를 인코딩하는 적응적 코딩 기법을 사용할 수도 있지만, 현존하는 많은 멀티미디어 애플리케이션은 대역폭에 민감하다.
대역폭 민감 애플리케이션들이 특정 처리율 요구사항을 갖고 있는 반면에, 탄력적 애플리케이션은 가용한 처리율을 많으면 많은 대로 적으면 적은 대로 이용할 수 있다. 전자메일, 파일 전송, 웹 전송이 융통성 있는 애플리케이션이다. 대역폭은 많으면 많을수록 좋다
시간
트랜스포트 계층 프로토콜은 시간 보장을 제공할 수 있다.
시간 보장은 여러 가지 형태로 나타날 수 있지만, 한 가지 예는 송신자가 소켓으로 내보내는 모든 비트가 수신자의 소켓에 100ms 내에 도착하게 하는 것이다. 그런 서비스는 인터넷 전화, 원격회의와 같은 실시간 상호작용 애플리케이션에 매력적이다.
이러한 애플리케이션이 효과적으로 동작하기 위해서는 데이터 전송에 엄격한 시간 제한 조건이 요구된다.
비실시간 애플리케이션의 경우 낮은 지연이 항상 높은 지연보다 선호되지만 종단 간 지연에 엄격한 제약을 받는 것은 아니다.
보안
트랜스포트 프로토콜은 애플리케이션에 하나 이상의 보안 서비스를 제공할 수 있다. 트랜스포트 프로토콜은 기밀성외에도 다른 보안 서비스를 제공하는데, 데이터 무결성과 종단 인증등이 포함된다.
2.1.4 인터넷 전송 프로토콜이 제공하는 서비스
이제부터 인터넷이 제공하는 애플리케이션 지원 유형을 살펴보자.
인터넷(그리고 일반적인 TCP/IP 네트워크)은 애플리케이션에게 2개의 전송 프로토콜 즉, UDP와 TCP를 제공한다.
TCP 서비스
TCP 서비스 모델은 연결지향형 서비스와 신뢰적인 데이터 전송 서비스를 포함한다.
- 연결지향형 서비스
- 애플리케이션 계층 메시지를 전송하기 전에 TCP는 클라이언트와 서버가 서로 전송 제어 정보를 교환하게 한다. =>
핸드셰이킹 과정 - 핸드셰이킹 과정이 클라이언트와 서버에 패킷이 곧 도달할 테니 준비하라고 알려주는 역할을 한다.
- 핸드셰이킹 단계를 지나면, TCP 연결이 두 프로세스의 소켓 사이에 존재한다고 말한다.
- 해당 연결은 두 프로세스가 서로에게
동시에메시지를 보낼 수 있기에 전이중 연결이라고 한다. - 애플리케이션이 메시지 전송을 마치면 연결을 끊어야 한다.
- 애플리케이션 계층 메시지를 전송하기 전에 TCP는 클라이언트와 서버가 서로 전송 제어 정보를 교환하게 한다. =>
- 신뢰적인 데이터 전송 서비스
- 통신 프로세스는 모든 데이터를 오류 없이 올바른 순서로 전달하기 위해 TCP에 의존한다.
- TCP 애플리케이션의 한쪽이 바이트 스트림을 소켓으로 전달하면 그 바이트 스트림이 손실되거나 중복되지 않게 수신 소켓으로 전달한다.
TCP는 혼잡 제어 방식, 즉 통신하는 프로세스의 직접 이득보다는 인터넷의 전체 성능 향상을 위한 서비스를 포함한다.
네트워크가 혼잡 상태에 이르면 프로세스(클라이언트 혹은 서버) 속도를 낮춘다.
TCP 혼잡 제어는 각 TCP 연결이 네트워크 대역폭을 공평하게 공유할 수 있게끔 제한하려고 시도한다.
UDP 서비스
최소의 서비스 모델을 가진 간단한 전송 프로토콜이다. UDP는 비연결형이므로 두 프로세스가 통신을 하기 전에 핸드셰이킹을 하지 않는다. UDP는 비신뢰적인 데이터 전송 서비스를 제공한다.
즉, 하나의 프로세스가 UDP 소켓으로 메시지를 보내면, UDP는 그 메시지가 수신 소켓에 도착하는 것을 보장하지 않는다. 수신 소켓에 도착하는 메시지들의 순서가 뒤바뀔 수도 있다.
UDP는 혼잡 제어 방식을 포함 하지 않는다.
따라서 UDP의 송신 측은 데이터를 원한느 속도로 하위 계층으로 보낼 수 있다.
인터넷 트랜스포트 프로토콜이 제공하지 않는 서비스
TCP는 신뢰적 종단 간 데이터 전송을 제공한다. 또한 TCP가 보안 서비스를 제공하기 위해 애플리케이션 계층에서 TLS를 통해 쉽게 강화도리 수 있음을 알았다.
오늘날의 인터넷은 때로 시간 민감 애플리케이션들에게 만족스런 서비스를 제공할 수 있으나 시간 혹은 대역폭 보장을 제공할 수는 없다.
인터넷 전화 애플리케이션은 보통 패킷 손실을 허용하지만 효율성을 위해 최소의 전송률을 필요로 하기 때문에, 인터넷 전화 애플리케이션 개발자들은 일반적으로 UDP상에서 자신들의 애플리케이션을 수행하기를 선호하며, 그렇게 함으로써 TCP의 혼잡 제어 방식과 패킷 오버헤드를 회피할 수 있다. UDP 통신이 실패할 경우를 대비하여 TCP를 사용하도록 설계되어 있다.
2.1.5 애플리케이션 계층 프로토콜
네트워크 프로세스는 소켓으로 메시지를 보냄으로써 통신한다.
이 메시지는 어떻게 구성되는가? etc
애플리케이션 계층 프로토콜은 다른 종단 시스템에서 실행되는 애플리케이션의 프로세스가 서로 메시지를 보내는 방법을 정의한다.
애플리케이션 계층 프로토콜은 아래와 같은 내용을 정의한다.
- 교환 메시지 타입(ex. 요청 메시지와 응답 메시지)
- 여러 메시지 타입의 문법(ex. 메시지 내부의 필드와 필드 간의 구별 방법)
- 필드의 의미, 즉 필드에 있는 정보의 의미
- 언제, 어떻게 프로세스가 메시지를 전송하고 메시지에 응답하는지 결정하는 규칙
네트워크 애플리케이션과 애플리케이션 계층 프로토콜을 구별하는 것은 중요하다. 애플리케이션 계층 프로토콜은 네트워크 애플리케이션의 한 요소일 뿐이다.
웹은 사용자가 필요에 따라 웹 서버로부터 문서를 얻게 해주는 네트워크 애플리케이션이다.
웹 애플리케이션은 문서 포맷 표준(HTML), 웹 브라우저, 웹 서버, 애플리케이션 계층 프로토콜을 포함하는 여러 요소들로 구성된다. 웹 애플리케이션 계층 프로토콜, HTTP는 브라우저와 웹 서버 사이에서 교환되는 메시지의 포맷과 순서를 정의한다.
따라서 HTTP는 웹 애플리케이션의 한 요소이다
