2-1. Principles of network applications

Network Apps

 

Loss-sensitive applications(내용 생략/변조되면 곤란한 application)

 

- e-mail

- web

- text messaging

- remote login

- P2P file sharing

 

Delay-sensitive applications(지연되면 곤란한 application)

 

- multi-user network games => game 하는데 속도 느리면 진행이 불가

- voice over IP(ex. Skype)

- streaming stored video(YouTube, Hulu, Netflix) => 영화볼 때 자꾸 끊기면 안 됨

- real-time video conferencing

 

이 delay-sensitive app 들 중 streaming stored video 와 real-time video conferencing 같이 비디오 관련 애플리케이션들은 비디오의 traffic의 volume이 크기 때문에 bandwidth가 중요한 "bandwidth-sensitive applications" 이기도 하다.

 

 

이제부터 우리가 볼 application 계층은... 

end system에만 있기 때문에 설치하기 위해서 core부분의 변화를 요구하지 않는다.

따라서 다양한 앱들을 빨리 설치할 수 있을 뿐더러 웹서버의 프로세스와 웹브라우저의 프로세스가 원활히 교류할 수 있는 것이다.

 

 

Possible structure of applications

 

1. Client-Server

 

Server: 항상 켜져있으며, client가 접속하도록 permanent한 IP 주소를 가진다. 

Client: 항상 server을 통해 client끼리 소통하며 dynamic한(매번 바뀌는) IP 주소를 가진다. server와 달리 노트북을 끄면 연결이 끊겨 꺼진다.

 

- HTTP : 웹 application의 프로토콜

- SMTP : 이메일 프로토콜

- DNS : 사용자의 도메인 네임을 컴퓨터가 식별할 수 있는 IP주소로 변환하는 프로토콜

 

 

2. Peer-to-Peer(P2P)

 

항상 켜져 있는 server가 있는 게 아니라 client들은 server을 거치지 않고 직접 소통한다.

그렇기 때문에 client들은 client역할을 할 수도, server역할을 할 수도, 둘 역할을 동시에 할 수도 있다.

각 peer들은 각자의 infrastructure을 가지고 있기 때문에 infrastructure을 설치하는 비용을 줄일 수 있다.(self-scalability)

하지만 Client-Server 구조와 달리 항상 연결되지 않으며 IP주소가 계속 바뀌기 때문에 관리가 불편하다는 단점이 있다.

 

 

- Bit Torrent(file sharing) : 유저들끼리 자신의 file을 나눠 보는 프로토콜

- Internet Telephony(Skype) : 사용자가 서버가 될 수도, 클라이언트가 될 수도 있는

- IPTV

 

Processes communicating

 

Process: host에서 실행되고 있는 프로그램

client process(컨택을 거는 process)와 server process(컨택을 기다리는 process)가 소통하면서 app이 운영된다.

이때 Client-Server 구조에서는 client process와 server process가 각각 client와 server에 존재하지만

P2P 구조에서는 둘 다 같은 host 내에 존재한다는 차이점이 있다.

 

따라서 Client-Server구조에서는 프로토콜에 따라 server host와 client host가 서로 메시지를 주고받는 것이고,

P2P 구조에서는 inter-process 소통이 진행되는 것이다.

 

 

Socket

 

socket은 application 계층과 transport 계층 중간에 위치해, 두 계층이 메시지를 주고받을 때 문 역할을 한다.

 

1. sender application계층의 process가 socket을 통해 메시지를 transport계층에 보낸다.

2. 패킷이 인터넷을 거쳐 destination에 도착한다.

3. transport계층에서 socket을 통해 application계층에 도착한다.

 

그래서 관여하는 총 socket의 개수는 sender의 socket, receiver의 socket 이렇게 2개다.

 

 

 

Addressing Processes

 

당연한 소리지만 프로세스 패킷이 전달되려면 receiver의 주소가 필요하다.

때문에 프로세스는 자신의 몸에 자신의 목적지 정보가 담겨 있는 identifier을 달고 다닌다.

 

identifier에는 IP address와 port 번호가 담겨 있다.

 

IP address

 

형태:  000.000.000.000

 

32비트 주소체계를 사용하고 8bit씩 4자리다.

 

 

Port 번호

 

각 프로토콜마다 쓰는 port번호가 정해져야 한다.

HTTP처럼 유명한 프로토콜의 port번호는 잘 알려져 있다. 유명한 프로토콜의 포트 번호 몇 개를 적어봤다.

 

- HTTP : 80

- HTTPS : 443

- SMTP(Simple Mail Transfer Protocol) : 25

- SSH : 22

- DNS : 53

- Skype : 23339

(HTTP, SMTP: 누구나 접근 가능한 open protocols,

Skype: 단일조직이나 개인이 독점하는 통신프로토콜 proprietary protocol)

 

그렇다면 예를 들어

gaia.cs.umass.edu라는 서버로 HTTP 프로토콜의 메시지를 보낸다고 가정할 때 IP주소와 port번호는 무엇일까?

 

IP주소는 128.119.245.12(wireshark 등을 통해 확인 가능) => 좀 더 자세히....

HTTP 프로토콜 메시지이므로 port 번호는 80일 것이다.

 

 

Application protocol defines

 

 

- 메시지의 역할(request/response)

- 메시지 구문

- 메시지 의미

- 메시지를 언제 어떻게 보내거나 받을 건지

 

 

Transport service의 이상과 현실

 

 

이상(app이 요구하는 것)

 

- data integrity(loss에 대비)

: reliable한(loss가 없는) transactions 

 

- timing(delay에 대비)

: delay가 적은, 그리고 delay 변화도 적은 transactions

 

- throughput

: email, FTP, Web transfer같은 앱의 경우에는 throughput이 크게 상관 없지만

multimedia같은 경우에는 효율성을 위해 최소한의 throughput만을 요구

 

- security

: encryption(암호화)

 

 

현실(현재 제공하는 것)

 

이상적인 요구사항을 모두 충족하기 어렵다는 한계 때문에 application의 종류별로 중요한 사항에 초점이 맞춰져 있다.

 

 

예컨대 stored audio/video 같은 경우에는 실시간 비디오 스트리밍 앱보다 상대적으로 time sensitivity가 루즈해도 괜찮다.

그래서 들쑥날쑥한 delay를 보완하기 위해 버퍼링을 이용한다. 그렇게 되면 delay의 변화를 잘 못 느끼기 때문에 사용자가 느끼는 품질 저하를 줄일 수 있게 되는 것이다.

 

Internet transport protocols services (TCP vs UDP)

 

계층별 protocol들

 

그중 transport계층의 TCP와 UDP 프로토콜에 대해 볼 것이다. 

 

TCP

- 연결지향형

- reliability 중요시

(flow control: transport계층에서 application계층으로 올려보낼 때 buffer에 일단 데이터가 저장되는데 과잉 저장 방지,

congestion control: traffic intensity 강한데 계속 traffic 보내면 loss 발생하므로 필요)

- timing, throughput guarantee, security 제공 안 함

- 패킷에 대한 응답 필요하므로(application에서 요구하는 throughput이 뭐건 간에 네트워크가 혼잡하면 throughput 확 낮춤) 속도 느림

 

 

UDP

- 비연결형

- reliability 제공하지 않음

- timing, throughput guarantee, security 제공 안 함

- 응답이 필요 없이 패킷 내보내므로 속도 빠름

 

 

TCP는 높은 신뢰성을 제공하는 대신 연속성(속도)이 낮고, UDP는 높은 연속성(속도)을 가지는 대신 신뢰성은 보장하지 못한다.

안전한 application 운영을 위해서는 TCP 가 낫지만 최근에는 multimedia가 부착된 application들이 많이 사용되기 시작하면서 UDP의 중요성이 커졌다. 

one-time transaction에서는 TCP의 단계 모두 하면 오래 걸려 비효율적이므로 UDP를 사용하고

smart application에서는 reliability가 중요하므로 자신의 application 계층에서 구현해놓기 때문에 굳이 TCP 단계를 거칠 필요가 없다.

 

 

위의 표를 통해 application별 사용 protocol 을 살펴보자.

reliability가 중요한, 즉 loss가 발생하면 곤란한 초록색 application들은 TCP를,

delay가 자주 일어나면 곤란한 보라색 application들은 기본적으로 UDP를 사용하되, UDP 사용이 불가할 경우 TCP로 DNS switch 가 일어난다.

 

 

**DNS switch

 

DNS message가 길어지면 하나의 UDP segment에 다 담기 힘들다.

때문에 여러 개이 UDP segment에 나누어 담아야 하는데 그러면 받는 측에서 reassemble해야 함. 근데 그럴 수 없기 때문에 DNS switch를 하여 TCP를 사용한다.