티스토리 뷰
이번 포스트에서는 네트워크 애플리케이션에 대해 살펴보고자 한다.
애플리케이션은 우리에게 서비스를 제공함으로써 우리가 원하는 데이터를 요청하고 수신할 수 있도록 해준다.
그렇다면 애플리케이션 설계에 있어서 어떤 목적을 둬야할까?
애플리케이션의 목적
우선, 애플리케이션의 주요 역할은 종단 시스템에서 다른 종단시스템까지 통신하는 프로그램을 만드는 것이다.
예시로 웹 애플리케이션을 사용한다면 서버와 클라이언트로 생각할 수 있다.
클라이언트는 서버에게 원하는 데이터를 달라 요청하고 이에 서버는 그에 맞는 데이터를 다시금 클라이언트에게 전달하게 되는데 이러한 통신이 애플리케이션의 역할이며 목적이다.
그렇다면 우린 컴퓨터를 배우는 사람이니 이러한 애플리케이션 목적에 의한 동작 원리와 구조를 알아보자
애플리케이션 구조
먼저 애플리케이션의 구조를 개발자 관점에서 봤을 떄, 이전 포스트를 통해 배운 네트워크 구조와 사뭇 다르다.
개발자의 관점에서는 애플리케이션 구조를 설계하고 어떻게 통신할 것인지에 대해 구현해야하기 때문이다.( 네트워크는 라우터랑 뭐 알아서 다 있는데, 난 다 구현해야하네?...)
그렇기에 현대 개발자들은 클라이언트 - 서버 구조 혹은 P2P 구조 중 하나로 작성해야한다.
클라이언트 - 서버 구조
해당 구조에서,
서버는 항상 동작하고 요청을 받고 응답을 보내는 호스트며
클라이언트는 서버에 요청을 하는 호스트다.
클라이언트 <-----> 서버
이러한 모양으로 통신을 하는데 고정 IP 주소를 통해 클라이언트는 항상 켜져 있는 서버에 요청을 보낼 수 있다. (ex) www.naver.com)
그러나 하나의 서버 호스트가 모든 클라이언트의 요청에 응답하는것은 불가능하다.
그렇기에 네이버, 아마존 같은 웹사이트를 제공하는 회사에서는 데이터 센터(data center)라는 가상의 서버를 각각의 역할로 사용한다. (어느 데이터 센터는 이메일 서비스, 어느 데이터 센터는 채팅 서비스 식으로)
++ 추가적으로 ISP들은 데이터 센터로 부터 데이터를 보내기 위해 비용을 지불한다.
P2P 구조
해당 구조는 (항상 켜져있는 인프라스트럭쳐) 서버에 최소로 의존한다.
위에서 말한 클라이언트- 서버 구조는 서버의 역할이 매우 중요하다(사실 서버가 다 한다 )
그러나 P2P 구조는 피어(pear) 라는 간헐적으로 연결된 호스트쌍을 통해 클라이언트 끼리 서로 직접 통신하게 한다.
즉, P2P구조에서 서버란 !!!
피어를 통해 서비스제공자(서버)가 해당 서비스를 위한 데이터를 소유하지 않고 사용자들이 제어하는 컴퓨터라고 볼 수 있다. (서버 : 나는 너가 원하는 데이터 없는데 저기 클라이언트한테 있어 쟤 연결해줄게 달라해서 가져가 )
++ P2P 구조의 주요특성 중 하나는 자가 확장성이다. 각 피어들이 파일 요구로 작업 부하가 있지만 파일을 다른 피어들에게 분배함으로 서비스 능력을 추가한다.
애플리케이션을 개발하기에 앞서 어떤 구조가 있는지 알아봤다 그렇다면 다음으로 애플리케이션 내에서 통신하게 하는 방법 즉, 프로세스에 대해 알아보자
프로세스간 통신
운영체제에서 실제로 작동하고 통신하는 프로그램을 프로세스라고 한다.
우리가 공부하는 네트워크에서 프로세스는 종단시스템에서 실행되는 프로그램이다. 이러한 프로세스는 종단 시스템의 운영체제에 따라 규칙이 좌우되는데 우리는 이러한 것을 뒤로하고 호스트에서 실행되는 프로세스와의 통신에 대해 알아 볼 것이다.
2개의 종단 시스템에서 프로세스는 네트워크를 통한 메시지(message) 교환으로 통신한다.
채팅을 하게 된다면 이렇게 메시지가 전달 되며
(client) (client)
End System -----------------> Server --------------- > End System
원하는 데이터를 보고자 한다면 이렇게 볼 수 있다.
(client)
End System <-----------------> Server
클라이언트와 서버 프로세스
네트워크 애플리케이션은 서로 메시지를 보내는 두 프로세스로 구성된다.
각 구조에 의해 요청을 주는 입장을 클라이언트 프로세스 (client process) , 응답을 주는 입장을 서버 프로세스(server process)라고 한다.
client -> server
pear(client) -> pear (server)
즉 다시금, 두 프로세스 간의 통신에서
초기화( 다른 프로세스와 세션 시작을 위해 접속을 위해 초기화, 요청)하는 프로세스를 클라이언트라고하며
세션을 시작하기 위해 접속을 기다리는(접속 올떄까지 항상 켜져있다) 프로세스를 서버라고한다.
프로세스와 컴퓨터 네트워크 사이의 인터페이스
서버,클라이언트 프로세스는 어떻게 소통할까?
카톡 보내는 걸 보아하니 화면처럼 바로 그냥 직접적으로 서로간의 요청과 응답을 주고받을까?
그렇지 않다.
그 중간 사이에 소캣(socket)이라고 하는 인터페이스를 통해 이 두 프로세스는 소캣이라는 문을 통해 데이터를 주고받게된다.
집 문 문 집
process / socket(데이터 가진 TCP ) < ------------------> socket( 데이터를 가진 TCP ) / process
이러한 문 역할을 하는 소켓은 애플리케이션과 네트워크 사이의 API(application programming interface)라고도 한다.
소캣을 통해 애플리케이션 개발자는 소켓의 애플리케이션 계층의 모든 통제권을 갖게 됐지만 트랜스포트 계층의 통제권도 다스릴 수 있게 됐다란 말은 아니다.
프로세스 주소 배정
한 클라이언트가 어떠한 서버에 원하는 데이터를 요청하고자 한다.
그런데... 서버 주소에서 요청은 받았다만 요청자 주소를 알아야 데이터를 보내던지 하지 않을까?
그렇기에 수신 프로세스를 식별윟서 두 가지 정보를 패킷에 명시한다.
1 호스트의 주소 2 목적지 호스트 내의 수신 프로세스를 명시하는 식별자
인터넷에서 호스트는 IP 주소를 통해 식별된다.(이후에 IP에 대해 더 알아볼 거지만 지금은 간략히 32비트의 길이에 호스트 유일식별이 가능하게 해주는 녀석으로 알고 있자)
메시지가 전달되어야하는 호스트 주소를 포함해서 송신 호스트는 수신 호스트에 수행중인 수신 프로세스도 식별해야한다.
수신 호스트는 현재 우리가 쓰고 있는 휴대폰이라고 하자 (End System)
카톡(Process)에서 메시지을 보내고 답장을 기다린다. 그런데 답장을 받았는데 웬 답장이 내 메모장(Process)에 뜨면 어쩌잔말인가?
그렇다. 휴대폰 내에 존재하는 애플리케이션은 각 포트 번호를 사용하고 있기에 요청을 보낸 프로세스의 주소 (포트번호)를 포함시켜야 한다
애플리케이션이 이용 가능한 트랜스포트 프로토콜 서비스
위에서 소캣은 애플리케이션과 트랜스포트 프로토콜 간의 인터페이스(문) 이라고 설명헀다.
그런데 트랜스포트 계층 프로토콜이 애플리케이션 계층으로 전달될 때 사용되는 각 프로토콜의 특징이 여러가지 있는데
신뢰적 데이터 전송, 처리율, 시간, 보안 네 가지가 있다.
- 1 신뢰적 데이터 전송
패킷은 손실의 가능성이 있다 (ex큐지연에서 drop) .
- 2 처리율
보장된 데이터 전송량을 통해 애플리케이션에서 고를 수 있다.
- 3 시간
정해진 시간내에 데이터를 전달할 수 있는 시간 보장
- 4 보안
데이터가 중간에 가로채질 경우 암호로 인코딩하여 못 읽게 할 수 있다.
인터넷 전송 프로토콜이 제공하는 서비스
인터넷은 애플리케이션에게 2개의 전송 프로토콜 UDP(User Datagram Protocol) , TCP(Transmission Control Protocol)를 제공한다. 두 프로토콜은 애플리케이션에 다른 서비스 를 제공하기에 개발에서 가장 먼저 결정해야하는 선택지 중 하나다.
- TCP 서비스
애플리케이션 | 데이터 손실 | 대역폭 | 시간 민감성 |
파일 전송/다운로드 | 비손실 | 가변적 | 아니요 |
전자메일 | 비손실 | 가변적 | 아니요 |
웹 문서 | 비손실 | 가변적 | 아니요 |
인터넷 전화/ 비디오 콘퍼런싱 | 손실 허용 | 오디오 수 :kbps_1Mbps 비디오 : 10kbps ~ 5Mbps |
예 : 수 100ms |
저장 오디오/ 비디오 스트리밍 | 손실 허용 | 오디오 수 :kbps_1Mbps 비디오 : 10kbps ~ 5Mbps |
예: 수 초 |
상호작용 게임 | 손실 허용 | 수 kbps_10 kbps | 예 : 수 100ms |
스마트폰 메시징 | 비손실 | 가변적 | 예 또는 아니요 |
해당 프로토콜은 연결지향형 서비스와 신뢰적인 데이터 전송 서비스를 포함하고 있다.
메시지를 전송하기전에 먼저 클라이언트와 서버간의 전송 제어 정보를 교환함(3way - 핸드쉐이킹)으로써 각 서버와 클라이언트는 준비를 하여 동시에 메시지를 보낼 수 있게된다(전이중 연결 full-duplex).
+ 통신 프로세스가 오류없이 올바른 순서로 제이터를 전달하고 싶다면? - > TCP에 의존한다.
- UDP 서비스
해당 프로토콜은 비연결형 서비스와 비신뢰적인 데이터 전송 서비스를 포함하고있다.(최소의 서비스를 가진 간단한 녀석이다) 데이터가 도착하는 것을 보장하지도 , 메시지 순서를 보장하지도 않지만 원하는 속도로 하위계층(네트워크)으로 보낼 수 있다.
인기 있는 인터넷 애플리케이션, 애플리케이션 계층 프로토콜 및 하위 트랜스포트 프로토콜
애플리케이션 | 애플리케이션 계층 프로토콜 | 트랜스포트 프로토콜 |
전자메일 | SMTP | TCP |
원격 터미널 접속 | Talnet | TCP |
웹 | HTTP1.1 | TCP |
파일 전송 | FTP | TCP |
스트리밍 멀티미디어 | HTTP | TCP |
인터넷 전화 | SIP, RTP | UDP or TCP |
'Network' 카테고리의 다른 글
3.1 트랜스포트 계층 서비스 및 개요 (0) | 2022.10.21 |
---|---|
2.2 웹과 HTTP (0) | 2022.10.14 |
1.5 프로토콜 계층과 서비스 모델 (1) | 2022.10.03 |
1.4 패킷 교환 네트워크에서의 지연, 손실과 처리율 (0) | 2022.10.03 |
1.3 네트워크 코어 (0) | 2022.10.03 |