2. Application layer

---

해당 챕터의 목표를 다시 불러와보자.

• application layer protocol의 conceptual, implementation 관점 공부
  • transport-layer service model들
  • client-server paradigm
  • peer-to-peer paradigm
• popular application-layer protocol들이나 infrastructure들을 지원하는 protocol들 공부
  • HTTP, SMTP, IMAP
  • DNS
  • Video streaming systems, CDNs
• Socket API

---

Domain Name System(DNS)

---

• DNS란 Host name을 IP 주소로 Mapping해주는 directory service이다.
• 많은 name server들의 계층 구조(tree)로 구현된 분산 database.
  • scalability, maintain 간편
• Host가 분산 DB에 host name으로 질의해서 IP주소를 획득하는 application-layer protocol임
  • host, DNS server들은 name/address translation을 위해 소통한다.
  • application-layer protocol로써 구현된 core network function임
    • Core는 단순하게, 복잡한 function은 Edge로
    • core는 매우 바쁘기 때문에 복잡한 function을 구현하면 매우 느려짐

---

DNS services, structure

DNS services

• hostname-to-IP address translation
• host aliasing
  • canonical, alias names
• mail server aliasing
• load distribution
  • replicated web server
    • traffic 분산을 목적으로 물리적으로 서버 여러 대에 하나의 서버 파일을 복사해서 작동시키는데, 각각은 IP주소를 가짐
    • 이를 하나의 name(ex naver.com)에 대응시킴으로써 load 분산 가능

Distributed Domain Name System

• 단일 중앙 집중식 DNS를 사용하지 않는 이유
  • single point of failure (하나의 오류로 전체 서비스가 정지)
  • traffic volume (수십억 traffic을 감당해야됨)
  • centralized database가 멀리 떨어져 있음
  • 유지보수
• DNS에서 신경써야 하는 것들
  • trillions of queries/day (거의 모든 internet transaction이 DNS와 상호작용)
  • reliability
  • security

DNS Structure

Root DNS server

• name 서버의 contact-of-last-resort(최후의 연락 수단, 아무것도 모를 때 접근하는 최상위 서버)로, name resolve를 할 수 없다.
  • 이걸 할 수 있으면 root가 다하니까 centralized database인게 되는거지...
• Root DNS server는 아주 중요한 internet function
  • DNSSEC: authentication, message integrity 등의 security를 제공
• ICANN(Internet Coporation for Assigned Names and Numbers)가 이 Root DNS domain을 관리한다.
• Server farm형식으로 총 13개의 root server가 전세계에 존재하고, 각 서버는 수차례 복제되어 cluster 형식으로 존재한다. (미국에만 200개가 존재)

Top-Level Domain(TLD) server

• .com, .org, .net이나 .cn, .uk, .kr, .fr 같은 top-level의 contry domain을 담당
• .com이나 .net TLD같은 권위있는 registry들은 Network solution으로써 사용됨
• Educause: .edu TLD

Authoritative DNS server

• 조직이나 서비스 제공자가 관리한다.
• 각 조직의 named host들을 위해 authoritative hostname에서 IP로의 mapping을 제공.

Local DNS Name server

• Host가 DNS 쿼리를 날리면, 그 쿼리는 일단 local DNS server에 보내진다.
  • local cache에 있으면 그걸 반환해주고, 없으면 계층적 DNS 구조에 쿼리를 보낸다.
  • 각 ISP들은 local DNS name server를 가지고 있다.
• local DNS server는 DNS hierarchy에 포함되지 않는다.

---

DNS Name resolution

Iterated query

• 연결된 서버가 새로 연결할 서버의 이름을 알려준다.

Recursive query

• 연결된 name server로 name resoultion 책임을 넘긴다.
• 모든 query가 Root DNS server를 거치기 때문에 상위 계층의 DNS server의 overhead가 심해진다.

---

Caching DNS Information

• name server가 한 번 mapping하는 것을 배우면, 해당 mapping을 캐싱한다.
• 이후 cached된 mapping을 사용해서 바로바로 응답한다.
  • caching은 response time이 향상시킨다.
  • cache에는 TTL(Time to live)속성을 추가할 수 있는데, 해당 시간이 지나면 cache entries는 timeout된다. (지워짐)
  • TLD server는 local name server들에 보통(늘) cache되어 있음.
• cache-entrie가 out-of-date가 될 수 있음
  • named host가 IP를 변경하는 경우, 모든 TTL들이 만료되기 전까지 해당 변경이 internet 전체에 알려지지 않을 수 있음.
  • name-to-address translation에서도 best-effort! (그놈의 최선..)

---

DNS Security

DDoS attacks

• root server를 traffic으로 공격하는 것
  • Traffic filtering 덕분에 현재까지 성공한 적은 없다.
  • local DNS server들은 TLD 서버의 IP들을 cache하는데, 덕분에 Root server 우회를 허용한다.

Spoofing attacks

• DNS 쿼리를 가로채고 가짜 replie를 보내는 것
  • DNS cache에 독을 탔다!!
  • DNSSEC authentication service가 이를 방지

---

P2P applications

---

• 언젠가 추가 예정

---

Video Streaming and content distribution network

---

Video Streaming과 CDNs: Context

• stream video traffic은 대부분의 internet bandwidth을 사용함
  • Netflix, Youtube, Amazon Prime..: residential ISP traffic의 80%를 사용한다.

Challenge: Scale - 어떻게 1Billion user가 reach할까

+ heterogeneity(이질성)은 어떻게 커버?

• different user들은 다른 capability를 갖는다.
• wired vs mobile

Solution

distributed, Application-level infrastructure!

---

Multimedia: video

• video는 일정한 속도로 보여지는 이미지 sequence이다.
  • 24 images/sec
• 거기에 digital image는 pixel들의 array인데, 각 pixel은 bit로 표현된다.
• 많은 pixel들을 계속 표현하기에는 데이터가 많이 필요하다.
  • 이미지 encoding에 사용되는 bit수를 줄이기 위해서 image내부와 image 사이에서의 redundancy(중복성)을 사용한다.
  • Spatial 중복 (image 내에서 비슷한 pixel끼리의 중복)
  • temporal 중복 (image들 사이에서 비슷한 장면끼리의 중복)

Encoding 방식

CBR (Constant Bit Rate)

: 고정된 video encoding rate

VBR (Variable Bit Rate)

: spatial, temporal coding changes의 총량에 맞춰 video encoding rate가 변한다.

• MPEG4: 64kbps - 12 Mbps로 가장 많이 사용되는 방식임

---

Streaming Stored Video

• Main challenge
  • server-to-client bandwidth는 network congestion level이 변함에 따라 시간별로 다양하다.
  • Congestion으로 인한 packet loss, delay로 인해 재생이 delay되거나, 비디오 품질이 저하됨.
• Continuous playout constraint: client video가 재생되는 동안, playout timing은 original timing과 match되어야만 함.
  • 그러나 network delay들이 가변적이기 때문에(jitter), client-side buffer를 두어 continuous playout constraint를 매치시킨다.
• 또다른 challenge들:
  • client interactivity: pause, fast-forward, rewind, jump through video등은 어떻게 처리?
  • video packet들은 loss되거나 retransmit될 수 있음

• Client-side buffering and playout delay
  • network-added delay와 delay jitter(delay 변화량)에 대한 보상
  • very large buffer를 쓰면, 처음 재생되기까지 대기시간이 늘어난다.
    • 또한 사용자가 jump등으로 조작할 때마다 똑같이 대기해야됨

Streaming Multimedia: DASH(Dynamic, Adaptive, Streaming over HTTP)

• client가 bandwidth를 측정하고 chunk 파일을 요구하는 방식, client에게 부담이 감

Server

• video file을 multiple chunk로 나눈다.
• 각 chunk들은 multiple different rate로 encoding되어 저장
• 다른 encoding rate들은 다른 파일에 저장됨.
• manifest file: different chunk들을 위해 URL들을 제공
  • 파일 각각의 encoding rate와 각 chunk를 어디에 요청할지 기록되어 있음

Client

• 가장 먼저 manifest file을 요청한다.
• 지속적으로 server-to-client bandwidth을 측정한다.
  • server에서 이걸 측정하려면, 모든 client를 고려해야되니까 오버헤드가 말이 안됨
  • Core need to be simple
• manifest파일을 보고 해당 url로 chunk를 요청함.
  • 현재 주어진 bandwidth을 보고 지속가능한 최대의 coding rate를 선택
  • 시간에 따라 다른 coding rate의 chunk file을 받을 수 있다.
    (각 시간마다 적절한 bandwidth에 따라)

intelligence at client: client가 결정한다.

• 언제 chunk를 요청할지 (buffer가 비거나 overflow하는 일 없도록)
• 어떤 encoding rate를 요청할지 (더 높은 bandwidth가 가능하면 더 높은 품질로..)
• 어디에 chunk를 요청할지 (사실 간단하게 네트워크 상에서 가장 가까운 놈을 고르게 된다.)

Streaming Video = Encoding + DASH + playout buffering

Content Distribution Networks (CDNs)

: 동시에 수백, 수천 명의 유저가 stream content 요청시 어떻게 대응할지에 대한 해결책

• single large mega-server는 delay, latency도 높고, scalability가 낮다.

• 지역적으로 분산된 장소에 여러 개의 video 복사본을 저장하고 제공한다.

  • enter deep: 서버를 세계 곳곳에 있는 네트워크에 연결시키는 방식

    • user와 가깝다.
    • 수많은 작은 server를 연결시키는 방식임

  • bring home: 적은 수의 large cluster들을 ISP 근처(PoP, Point of Presence)에 세우고, 네트워크에 접속시킨다.

  • CDN이란 결론적으로 CDN node들에 Content의 cope를 저장

  • 구독자가 content를 요청하면, provider는 manifest를 return

    • manifest를 이용해서, client는 가능한 가장 빠른 rate의 content를 탐색함
    • 가장 가까운 곳의 파일을 받지만, 너무 많은 트래픽이 있다면 그 다음 장소에 요청
    • network path가 혼잡하다면, 다른 rate나 copy를 요청할 수 있음.

• OTT: Over the Top

  • 인터넷을 통해서 각종 미디어 콘텐츠를 제공함
  • 이 서비스를 위한 network part는 가려져있음 (그래서 구름 위에 있다는 뜻)
  • OTT 도전과제: edge로부터 혼잡한 internet에 대한 대처
    • 어떤 CDN node에 어떤 content를 둘지
    • 어떤 CDN node에서 content를 어떤 rate로 검색할지

CDN caching 방식

• Pull caching: request가 발생했을 때, CDN을 거쳐서 origin server로 요청됨.

  • 모든 request는 manifest 파일을 통해서 CDN으로 가며, CDN에서 miss시 CDN은 해당 content를 origin server에서 받아옴
  • Youtube의 방식

• Push caching: request가 발생하기 전에 contents provider가 Content를 미리 CDN에 가져다 둠.

  • Netflix의 방식

• 왜 둘은 각각 해당 방식을 선택했을까?

  • Youtube는 contents가 너무 많아서 어떤 콘텐츠를 CDN에 Push할지 결정할 수 없다
  • 반면 Netflix는 어떤 contents가 인기있을지 예측 가능하기 때문에 미리 가져다 놓을 수 있는 것!
  • 또한 Youtube는 content-provider가 무수한 youtuber들로 너무 많아서 origin server를 거칠 수 밖에 없는 구조지만, Netflix는 Netflix만 content를 제공한다.

---

Socket Programming with UDP, TCP

---

Socket Programming

• 목표: socket을 사용해서 client-server application을 만드는 방법을 배우는 것
• socket: application 프로세스와 end-end-transport protocol 사이의 door

Recall:

• 두 transport service들을 위한 두가지 socket type이 존재한다
  • UDP: unreliable datagram
  • TCP: reliable, byte stream-oriented

UDP Socket programming

• UDP: client와 server 사이에 connection이 없다.
  • connection initializing인 handshaking 과정이 없다.
  • sender는 각 Packet에 목적지 IP 주소와 port 번호를 명시해야 한다.
  • receiver는 받은 packet에서 ip 주소와 port 번호를 추출한다.
• UDP는 전송된 데이터가 loss되거나 순서가 뒤바뀔 수 있음 (unreliable)
• UDP에는 size 제한도 없음, 하지만 어차피 다른 layer에 size 제한이 있기 때문에 large data를 보내지 못한다.

• 위 그림에서 UDP는 client-server process 사이에서 datagram으로 byte 그룹을 unreliable하게 보내고 있음을 확인할 수 있다.
• UDP에서는 client의 모든 packet에 serverName과 serverPort를 명시한다.

TCP Socket Programming

• Client는 반드시 server와 연결되어야 함
  • server process는 반드시 먼저 동작하고 있어야 하며, 미리 socket을 만들어 놨어야함.
• Client는 TCP socket에 IP 주소와 포트번호를 명시한 다음 생성하고, sokect이 만들어지면 client TCP가 server TCP와 연결을 구축함.
• client와 연결되면 server TCP는 특정 client와 소통하기 위해 server process에 새로운 socket을 생성함
  • 다수의 client와 통신할 수 있도록 해줌
  • source port number는 client를 구분하기 위해서 사용됨

• 위 그림에서 TCP는 client-server 사이에 reliable하고 in-order인 byte-stream transfer를 제공하는 모습을 확인할 수 있음.

---