만약에 내가 굉장히 새로운 네트워크 응용 프로그램에 대한 아이디어가 있다고 생각해보자. 그 응용 프로그램은 굉장히 좋은 영향을 줄 수 있는 프로그램이 될 텐데 그렇다면... 그 아이디어를 어떻게 실세계의 네트워크 응용프로그램으로 바꿀 수 있을까??
네트워크 응용프로그램 개발의 핵심
은
1) 다른 종단 시스템에서 동작하고
2) 네트워크 위에서 서로 다른 종단 시스템과 통신할 수 있는 프로그램을 작성하는 것이다.
ex) 사용자의 호스트 <-> 서버의 서버 호스트 / 넷플릭스를 제공하는 유저 단계에서의 프로그램 <-> 네트워크 서버의 서버 호스트
아래 그림은 위 2개의 예시를 일반적으로 표현한 그림이다.
그렇기 때문에 새로운 애플리케이션을 만들 때 다양한 종단 시스템에서 동작하는 SW
를 작성해야 한다.
중요한 건 그런 애플리케이션을 라우터, 스위치와 같은 네트워크 코어 장치에 작성할 필요가 없다는 것이다.
왜냐하면, 네트워크 코어 장치들
은 응용 계층에서 기능을 수행하지 않고 더 낮은 계층의 기능을 수행
하기 때문이다.
이런 기본적인 구조가 네트워크 응용 프로그램을 광범위하고 빠르게 발전할 수 있도록 했다.
1. Network Application Architectures
SW 코딩을 하기 전에 응용프로그램에 대한 전체적인 그림
을 그려야 한다. 그리고, 응용프로그램의 구조와 네트워크의 구조는 서로 다르다는 걸 명심하라. 응용프로그램 개발자의 관점에서 네트워크 구조
는 각 계층이 무슨 역할을 하는지 정해져 있지만 응용 프로그램
은 개발자에 의해서 디자인되고 다양한 종단 시스템 위에서 어떻게 구조되는지를 지정할 수 있다.
현대에 와서 많이 사용하고 있는 응용 프로그램 구조는 client-server 구조
와 P2P(Peer-To-Peer) 구조
다.
- client-server 구조 :
항상 켜져 있는 호스트(서버)
가수많은 호스트(클라이언트)
로 부터 요청을 받으면 그 요청에 대해서 응답하는 구조.
특징
1) client 끼리 통신하지 않는다.
2) 서버가 고정되고 잘 알려져 있는 IP 주소를 갖고 있고 항상 켜져 있기 때문에 클라이언트는 서버의 주소에 패킷을 전송함으로써 언제든지 서버에 접속할 수 있다.
ex) Web, FTP, Telnet, e-mail
만약 서버PC가 1대 밖에 없다면 수많은 클라이언트들의 요청을 감당할 수 없을 것이다. 그래서 그런 서버 PC 들을 모아서 많은 클라이언트를 감당할 수 있는 data center
를 만들기도 한다.
ex) 구글, 아마존, 이베이 등등 이 데이터 센터를 갖고 있다.
- P2P 구조 : 호스트끼리 통신하는 구조. 이때, 서로를 각각 peer라고 한다.
peers
는 특정 서비스 제공자에 속해 있는 것이 아니라 사용자에 의해서 이용되는 호스트
를 의미한다.
이 구조는 서버를 지나지 않기 때문에 Peer-To-Peer(P2P)
라는 명칭을 붙였다. 대표적인 서비스로 BitTorrent 가 있다.
특징 : P2P 구조는 self-scalability(자기 확장성)을 갖고 있다는 점이다.
ex) P2P 파일 공유 애플리케이션
각각의 peer가 파일을 요청함으로써 작업 부하(workload)를 만들어내지만서비스의 용량
을 다른 peer에게 파일을 전달함
으로써 용량을 늘려가는 방식을 사용할 수 있다.
하지만, 보안, 성능, 신뢰성 측면에서 분명한 한계를 보이는 구조인 것은 명확하다.
2. Process Communicating
응용 프로그램을 만들기 전에 알아야 하는 두 번째 내용은 프로그램이 다른 프로그램과 어떻게 통신하는지
에 대한 내용이다.
물론, OS 관점에서는 프로그램이 아니라 프로세스
다. 여기서 프로세스란 종단 시스템에서 동작하고 있는 프로그램으로 생각할 수 있다.
여기서는 서로 다른 호스트
에 있는 프로세스들이 어떻게 통신하는지에 대해 살펴볼 것이다.
서로 다른 호스트에 있는 프로세스는 네트워크
를 통해 메시지
를 전달함으로써 통신한다.
송신하는 쪽에서는 메시지를 만들어서 보내고 수신하는 쪽에서는 메시지를 받아서 이에 대한 응답을 보낸다.
위의 2.1 그림이 그런 과정을 표현한 그림이다.
Client and Server Processes
네트워크 응용 프로그램은 메시지
를 네트워크를 통해 전송하는 프로세스의 쌍으로 구성되어 있다.
이때, 2개의 프로세스 중 하나를 client
라고 하고 다른 하나를 server
라고 한다.
ex) 웹 : 클라이언트 브라우저 프로세스 <-> 웹 서버 프로세스 와 메시지를 교환
P2P 파일 시스템 : 파일이 한 쪽에서 다른 한 쪽으로 전달됨
예시를 보면 알 수 있듯이 프로세스는 클라이언트
가 될 수도 있고 서버
가 될 수도 있다.
P2P 파일 공유 프로세스는 파일을 업로드 / 다운로드 할 수 있듯이.
이렇듯, 프로세스는 클라이언트 또는 서버가 될 수 있지만 명확하게 하나는 client
다른 하나는 server
라고 명시한다.
정의는 아래와 같다.
프로세스의 쌍 사이에 통신하는 과정에서
- client : 통신을 시작하는 프로세스
- server : 세션을 시작하기 위해 접속을 기다리는 프로세스
ex1) 웹
- client : 브라우저 프로세스. 왜냐하면, 접속을 시작하기 때문이다.
- server : 웹 서버 프로세스.
ex2) P2P : A가 B에게 파일을 요청한 상황
- client : A
- server : B
The Interface Between the Process and the Computer Network
앞서 얘기한 것 처럼 프로세스 쌍
은 서로 메시지를 주고 받으면서 통신하다고 했다.
메시지는 네트워크를 통해 전달되는데 프로세스는 소켓(socket)
이라고 부르는 SW 인터페이스 통해 메시지를 주고받는다.
ex) 프로세스를 집 / 소켓을 문 이라 하자.
프로세스가 메시지를 다른 프로세스로 보내려고 할 때, 메시지
를 문(소켓)
으로 밀어넣는다.
전송하는 측에서는 목적지로 데이터를 전송해줄 전송 인프라(transport infrastructure)
가 있다고 가정하고 메시지를 보낸다.
메시지가 목적지에 도착하면, 목적지 프로세스의 문(소켓)
을 지나 메시지가 전달된다.
아래 그림은 인터넷을 통한 두 프로세스 사이의 소켓 통신을 표현했다.
그림에서 볼 수 있듯이 소켓
은 응용 계층
과 전송 계층
사이의 인터페이스이다. 그래서 API(Application Programming Interface)
라고도 불린다. 왜냐하면, 소켓
이 네트워크 응용 프로그램과 함께 만들어지기 때문이다.
Addressing Processes
우편 보낼 때 목적지의 주소
가 필요하듯이 프로세스가 패킷을 전송할 때 목적지 프로세스의 주소
가 필요하다.
목적지 프로세스를 확인하기 위해서 2가지 정보가 필요하다.
1) 해당 호스트의 주소
2) 목적지 호스트에서 수신받은 프로세스를 확인할 수 있는 식별자(identifier)
인터넷에서는 호스트의 주소를 IP주소
로 규정한다. 그리고 그 호스트에 있는 수많은 프로세스 중 목적지 프로세스를 식별하기 위해서 포트 번호
를 이용한다. (IP주소는 chapter 4 / 포트 번호는 chapter 3에서 자세히 다룰 예정이다.)
3. Transport Services Available to Applications
앞서, 소켓
은 응용 프로세스
와 전송 프로토콜
사이의 인터페이스라고 했다.
전송 측 응용 프로세스는 소켓
을 통해 메시지를 보낸다.
반대쪽 전송 계층 프로토콜은 수신 측 프로세스의 소켓에 메시지를 전달하는 역할을 수행한다.
이렇듯, 응용 프로그램을 개발할 때 메시지를 전달하기 위해서 전송계층 프로토콜
을 반드시 하나 선택해야 한다.
전송계층 프로토콜에서 제공하는 서비스 중 개발하고자 하는 응용프로그램에 적합한 서비스가 있는 프로토콜을 선택하면 되겠다.
이는 마치 여행 갈 때 기차를 타고 갈 지
차를 타고 갈 지
와 같은 운송수단을 선택하는 것이라 보면 되겠다.
기차로 이동했을 때 장단점 / 차로 이동했을 때 장단점을 고려해서 운송수단을 선택하면 된다.
그렇다면, 전송계층 프로토콜
이 응용프로그램에 제공할 수 있는 서비스는 무엇인지 4가지 방면으로 살펴보겠다 .
(reliable data transfer, throughput, timing, and security)
Reliable data transfer
chapter 1에서 다룬 것 처럼 패킷
은 여러 가지 이유로 손실될 수 있다.(router에서 overflow, host 또는 router에 의해 버려짐 등)
많은 응용프로그램에서 패킷 손실
은 치명적인 결과를 불러올 수 있다.
그래서, 전송된 패킷이 손실되지 않고 전송되었다
는 걸 보장
해줘야 한다.
이렇게 패킷이 손실되지 않았다는 걸 보장하면서 데이터가 전송되는 걸 reliable data transfer
라고 한다.
전송계층 프로토콜이 이러한 서비스를 제공한다면 데이터가 수신 측 까지 오류 없이 전달된다는 가정
하에 전송 측 프로세스
는 소켓에 데이터를 전달만 해주면 된다.
물론, 멀티미디어 응용프로그램의 경우 loss-tolerant applications
라고 해서 어느 정도의 데이터 손실을 용인해준다. 데이터 손실이 일시적인 오류만 발생시키기 때문이다.
Throughput
chapter 1에서 throughput의 개념을 다룬적이 있다.throughput
이란 네트워크 경로 상의 두 프로세스 사이의 통신 세션에서 전송 측 프로세스
가 수신 측 프로세스
에 전송할 수 있는 비트값의 전송률
을 의미한다.
다른 세션들은 네트워크 경로에 따라 대역폭(bandwidth)
을 공유할 수 있고 이런 세션들은 왔다갔다(coming and going) 하기 때문에 이용할 수 있는 throughput
은 시간에 따라 바뀐다.
이런 상황에서 전송 계층 프로토콜
은 일정한 throughput을 보장
하는 서비스를 제공할 수 있다.
응용 프로그램이 r bits/sec
의 throughput을 요청한다면 전송계층 프로토콜이 r bits/sec
의 throughput을 보장해주는 서비스이다.
이렇게 throughput
을 보장하는 서비스는 많은 응용 프로그램에 유용하다.
이렇게 일정한 thorughput
을 요구하는 응용프로그램을 bandwidth-sensitive application
이라 한다.
많은 멀티미디어 응용프로그램이 bandwidth sensitive
하다. 왜냐하면, 음성 또는 영상을 제공할 때 어느 정도의 품질을 보장해줘야 하기 때문이다.
대역폭에 민감한 애플리케이션은 특정 처리량을 요구하지만, 탄력적인 애플리케이션(elastic application)
은 사용 가능한 처리량에 따라 많은 양 또는 적은 양의 처리량을 활용할 수 있다. 전자 메일, 파일 전송 및 웹 전송은 모두 탄력적인 애플리케이션이다.
Timing
전송 계층 프로토콜은 시간
을 보장해줄 수 있다.
ex) 송신 측에서 소켓에 밀어넣는 비트 들이 100ms 도 안되서 수신 측 소켓에 도착하는 걸 보장
때문에 인터넷 전화, 가상환경, 여러 명이 하는 게임 등과 같은 실시간 상호작용 응용프로그램
에서는 이러한 서비스를 많이 찾는다. 데이터 전송에 있어 서로 데이터를 주고 받는데 걸리는 시간이 굉장히 작아야 하기 때문이다.
Security
전송 계층 프로토콜은 보안
기능도 제공한다.
ex) 전송 측 host
에서 전송계층 프로토콜이 송신 측 프로세스가 전달
하는 모든 데이터를 암호화할 수 있다.
그러면, 수신 측 host
에서 전송계층 프로토콜이 수신 측 프로세스
에 암호화된 데이터가 전달되기 전에 모든 데이터를 복호화할 수 있다.
이 밖에도 여러 가지 보안 서비스를 제공하는데 이에 대해서는 Chapter 8에서 다루도록 하겠다.
4. Transport Services Provided by the Internet
지금까지는 컴퓨터 네트워크가 일반적으로 제공할 수 있는 전송 서비스에 대해서 살펴봤다.
좀 더 구체적으로 들어가서 인터넷이 제공하는 전송 서비스
에 대해서 살펴보자.
인터넷에서는 UDP, TCP 프로토콜을 사용할 수 있다. 때문에 응용프로그램을 만들 때 어떤 프로토콜을 사용할 지 선택해야 한다.
각 프로토콜이 어떤 서비스를 제공하는지 살펴보자.
- 주요한 응용프로그램들의 요구사항을 정리한 표
TCP Services : 연결 지향 서비스
와 신뢰성 있는 데이터 전송 서비스
응용프로그램이 TCP
를 호출하면 응용 프로그램은 TCP로 부터 아래의 2가지 서비스를 받게 된다.
- 연결 지향 서비스 (Connection-oriented service)
1) Handshaking 과정
을 통해서 client와 server에게 패킷이 들어온다는 걸 알려준다.
2) 이후에 TCP connection이 두 프로세스의 소켓 사이에 존재하게 된다.
이 연결은 두 프로세스가 연결을 통해 동시에 메시지를 전달할 수 있다는 점에서 쌍방향 통신(Full Duplex)
이다.
응용 프로그램이 메시지를 전송을 끝냈다면 연결을 끊는다. 이에 대해서는 chapter 3에서 자세히 다룬다.
- 신뢰성 있는 데이터 전송 서비스 (Reliable data transfer service)
TCP를 이용해서 통신하면 한쪽에서 데이터를 보냈을 때 오류와 중복이 없고 적절한 순서를 지키면서 다른 한쪽으로 데이터를 전송할 수 있다.
또한 TCP는 혼잡 제어(congestion-control)
기능도 지원한다.
전송 측과 수신 측 사이의 네트워크가 혼잡해질 때 송신 측에서 전송되는 데이터를 막아버림으로써 혼잡을 제어한다.
마찬가지로 chapter 3에서 자세히 다룬다.
UDP Services
UDP
는 간단하고 최소한의 서비스를 제공하는 프로토콜이다.
또한, 비연결성(connectionless)이라는 특징을 갖고 있다. 그래야 통신하는 두 프로세스가 handshake 하는 과정을 갖지 않기 때문이다.
UDP는 신뢰성을 보장하지 않는 데이터 전송 서비스
를 제공한다. 즉, UDP 소켓을 통해 메시지를 보내면 도착한다는 보장이 없는 거다.
게다가 메시지가 도착하더라도 순서가 보장되지 않는다.
UDP는 혼잡 제어
기능을 지원하지 않는다. 그래서 전송 측은 언제든지 데이터를 아래 계층으로 전송시킬 수 있다.
Services Not Provided by Internet Transport Protocols
지금까지 전송 프로토콜의 4가지 서비스 신뢰성 있는 데이터 전송
, throughput
, 시간 보장(timing)
, 보안(security)
를 다뤘다.
그리고 TCP에서는 신뢰성 있는 데이터 전송
을 할 수 있다는 걸 다뤘고 응용계층에서 TLS를 통해 보안 서비스를 제공할 수 있다는 것도 다뤘다.
여기서 throughput
이랑 timing
에 대해서는 다루지 않았는데 해당 서비스들은 전송계층 프로토콜에서 제공하지 않는 서비스들이다.
하지만 시간에 민감한 응용프로그램
(ex. 인터넷 전화)들은 잘 동작해왔다. 단지 프로토콜에서 관련 서비스를 지원하지 않았을 뿐이다.
- 인터넷 응용프로그램에서 사용되는 전송 계층 프로토콜
5. Application-Layer Protocols
지금까지 네트워크 프로세스들은 소켓에 메시지를 전송하면서 통신한다고 했다.
그렇다면,
- 메시지들은 어떤 구조로 이뤄져 있을까.
- 메시지에 있는 다양한 필드들의 의미는 무엇일까
- 언제 프로세스가 메시지를 전송할까
이 질문의 답을 얻기 위해서 응용 계층 프로토콜
에 대해서 알아야 한다.
응용 계층 프로토콜은
서로 다른 종단 시스템에서 동작하는 응용 프로그램의 프로세스가 어떻게 서로에게 메시지를 전달하는지 정의한다.
구체적으로 말하면 다음과 같은 내용들을 정의한다.
- 메시지의 타입 (ex. 요청 메시지, 응답 메시지)
- 다양한 메시지 타입의 구문
- 필드의 의미
- 언제 어떻게 프로세스가 메시지를 전송하고 응답하는지에 대한 규칙
여기서 네트워크 응용프로그램
과 응용 계층 프로토콜
을 구분하는 것이 중요하다. 응용 계층 프로토콜
은 단지 응용 프로그램
의 부분이다.
ex) Web : client-server 응용프로그램 ⇒ 사용자가 웹서버로 부터 문서를 얻을 수 있도록 서비스한다.
Web 응용프로그램
은 HTML이라는 표준 문서 형식, 웹 브라우저, 웹 서버, 응용 계층 프로토콜로 구성되어 있다.
즉, 응용계층 프로토콜은 Web 응용프로그램
을 이루는 부분 중 하나다.
6. 이 책에서 다룰 네트워크 응용프로그램
새로운 응용 프로그램은 매일매일 발전되고 있어서 많이 사용하고 중요한 응용 프로그램만 다룰 것이다.
이번 챕터에서 Web / 이메일 / directory service(DNS) / 비디오 스트리밍 / P2P 를 다룰 것이다.
'COMPUTER NETWORKING A Top-Down app 8th' 카테고리의 다른 글
[Network] 2-4. DNS - The Internet's Directory Service (0) | 2023.08.02 |
---|---|
[Network] 2-2. The Web and HTTP (0) | 2023.07.18 |
[Network] 2. Application Layer (0) | 2023.07.04 |
[Network] 1-6. Networks Under Attack (0) | 2023.06.15 |
[Network] 1-5. Protocol Layers and Their Service Models (0) | 2023.06.11 |