[네트워크] Chap 2.1 - Application layer

Types of applications at layer 5

Loss-sensitive(Data-tolerent, throughput-tolerant but loss에는 민감!)

e-mail, web document browsing, text messaging, Telnet, File transfer service, etc.

 

Delay-sensitive & Bandwidth-sensitive (Loss-tolerent but Delay & Bandwidth 에 둘다 민감)

real-time streaming, interactive games, Voice over IP, etc.

 

Loss-sensitive, delay-sensitive, throughput-sensitive (Loss, Delay, throughput 모두에 민감)

VoD streaming (TCP (No-loss) + DASH (HTTP 위) + Buffering)

 

---

Application architecture

Client-Server

- server한테 물어보고 목적이 끝나면 닫음

- HTTP, SMTP, DNS

 

Peer-to-Peer (P2P)

- BitTorrent (file sharing), Internet Telephony(Skype), IPTV

---

Clinet-Server paradigm

server

1. always-on host (꺼지면 안되고 항상 켜져 있어야 함)

2. permanent IP address (서버는 변하지 않는 영구적인 IP 주소를 가진다)

서버에도 IP 주소가 있어야함.
permanent하다는 것 (↔ dynamic) : public 하다는 것! (즉 내가 오늘 아침에 cnn.com에 들어갈 때 그 머신의 IP 주소하고 저녁에 들어갈 때, 내일 들어갈 때 IP 주소가 다 똑같아야 한다!)

Why does a server need a permanent and public IP address?  - DNS resolution 

- Public IP address : routable, DNS resolution, payment(or lease)
- Private IP address : non-routable, DNS cannot resolve it, free

DNS (URL → IP : 서버의 URL을 알고 있으면 서버의 IP 주소를 매핑)
=> DNS는 public 주소만 매핑시킴. 결과적으로 서버한테 가려면 먼저 DNS한테 IP를 물어보고 감. 그렇기 때문에 서버는 public하고 permanent한 IP 주소를 씀

 

 

Client

- 항상 먼저 initiate!- do not communicate directly with each other (Client끼리 대화는 하지 않음(이건 peer-to-peer 얘기)- dynamic IP address (IP 주소가 계속 바뀐다)

---

Peer-to-peer architecture

1. no always-on server (서버가 항상 켜져 있지는 않음)

2. arbitrary end systems (서로 server와 client가 됨)

3. peer request service from other peers & provide service in return to other peers 클라이언트이면서, 동시에 서버 역할을 함. 서비스 제공 & 받음

     (1) self scalability - peer들 수가 증가할수록 서버 역할을 하는 peer들도 증가 → 성능이 좋아짐!

4. peers are intermittently connected and change IP addresses (간헐적으로 연결됨, IP가 그때그때 다름)

=> Client-Server 구조에서 Client 같은 구조!

 

Concerns of P2P architectures

1. Security → open nature 때문
   (random users can be peers, 인증을 받긴 하지만 아무나 다 들어오게 하므로)
2. Reliability → peer's various computing environment (storage, memory, CPU, and link BW)
3. ISP's P2P friendly service
   →peers (servers)  in a private Network
   내가 server 역할을 할 때 server private network이 있을 때 필요한 역할을 ISP에서 해줘야함

---

Sockets

 

Socket이란?

- 프로세스는 message를 자신의 socket에 보내고, 또한 message를 자신의 socket을 통해 받는다.

- a door between application layer and transport layer (소켓은 5계층과 4계층 사이의 문과 같다)
(개발자들은 network 신경 안씀. socket만 알면 application 만들 수 있음)

- socket을 사용한다는 것 = OS 라이브러리의 function을 잘 쓴다는것

     //transport, network layer - OS (Operating System)에 포함

     //link layer, physical layer - NIC (Network Interface Card)에 포함

 

---

Addressing processes

어떤 프로세스로부터 온 메세지인지 알아야 하므로, process는 identifier가 필요!

 

identifier - IP address와 port number을 포함한다.

• IP address - host의 unique한 32-bit 주소 / host를 찾는데 씀
• Port number - host의 프로세스에 할당된 식별 번호 (16-bit) / port number를 찾는데 process를 사용
  HTTP server : 80   /   HTTPS : 443   /   mail server : 25

a process in the internet can be identified by (IP address of the host where the process is running) & (port number assigned to the process in the host)

두개의 process끼리 msg를 주고 받을 때, machine을 찾으려면 machine에 연결된 link에 부착된 IP address를, machine 안에서 해당 process를 찾기 위해서는 port number 를 알아야 함.

 

PID vs port number

PID는 port number가 아니다. PID는 OS가 local하게 할당하고 버리는 id (바뀔 수 있음).

반면 port number는 네트워크 아이디의 개념으로 변하지 않음.

 

---

Application-layer protocol에서 정의되는 것

• types of messages exchanged
  : 주고받는 메세지의 타입 (ex. request, response)
• message syntax & message semantics
  : 얼만큼의 크기에 어떤 field로 정의해서 썼는지, 어떻게 해석해야 하는지 등을 노출시키지 않음
• rules
  : 프로세스가 언제, 어떻게 메세지를 보내고 받는지. (내가 어떤 데이터를 핸들링할지, 그리고 그 데이터를 바꿔줄 때 무슨 action을 할지 알고리즘 등을 정의)

 

open protocols

- RFCs 문서에 오픈되어 있음. 

- interoperability(상호운영성)
: 예를 들어 삼성이 짠 서버하고 lg가 짠 클라이언트가 같이 잘 동작하면 interoperability가 좋은것

- ex) HTTP, STMP

 

proprietary protocols

- 표준이 안된 것도 있음 (비공개 프로토콜)

- 어떻게 돌아가는지 대충만 알지 정확하게는 모름

- ex) Skype

---

What transport service does an app need?

transport layer의 프로토콜이 application layer에 어떤 서비스를 해주는가?

즉 application이 뭘 원하는가?

 

data integrity (loss)

- No-loss & in-order = integrity가 유지된다 = reliable하다

 

timing (delay)

- Real-time 서비스, interactive한 서비스는 대부분 timing에 민감하다.

 

throughput

- 내가 보고 싶은 화질 => throughput 얘기임. (굉장히 높은 bit rate로 전송하기를 원하는 것)

 

VOD 서비스 - data integrity(loss), timing(delay), throughput 세가지를 다 요구함!

---

TCP vs UDP

TCP service (Transmission Control Protocol)

• reliable transport
  : rdt (reliable data transfer)
• connection-oriented
  : client와 server 사이에 setup이 필요
• flow control & congestion control : buffer overflow를 피하기 위해 TCP의 sending rate를 조절
  flow control
  => receiver host의 TCP receiving buffer를 봄(end-to-end 개념). sender는 receiver의 buffer를 넘치게는 보낼 수 없음.
  congestion control
  => 라우터의 output buffer를 봄. 
• does not provide
  : timing / minimum throughput guarantee / security

 

UDP service (User Datagram Protocol)

• unreliable data transfer
• connection setup 불필요 - delay가 낮다!
• does not provide
  : reliability / connection setup / flow control & congestion control

 

파일 전송, 다운로드, e-mail 등 loss가 발생하면 안되고, timing(delay)에는 민감하지 않다면? → TCP

loss를 감수하더라도 timing에 민감한 streaming 서비스, interactive 게임, 실시간 멀티 유저 게임 등 → UDP