[컴퓨터 네트워크] Chap2. Application Layer(2)

아래는 연세대학교 컴퓨터 네트워크 수업을 듣고 정리한 내용입니다.

(간략하게 정리하였기에 부족한 점이 있을 수 있습니다)

2.4 DNS

• IP 주소와 www.yahoo~를 mapping 해주는 system → DNS
• Distributed database(분리된 데이터베이스)
  • 많은 네임 서버의 계층구조에 구현되어있다.
• Application Layer Protocol
  • host와 name server가 name을 해결하기위해서(address/name translation) 서로 커뮤니케이션을 한다.
  • edge에 이러한 기능을 넣어서 core의 역할을 간단하게 한다.

DNS Services

• Host Name을 IP 주소로 변환해준다.
• host aliasing
  • 외부에서는 하나의 서버처럼 보이지만, 실제로는 여러 개의 서버를 활용한다.
  • 즉, 하나의 서버가 여러가지 이름을 가질 수 있다.
• mail server aliasing
• load distribution
  • 복제된 Web Servers: 여러 IP 주소들이 하나의 이름에 대응할 수 있다.

왜 DNS는 distributed 되어있을 까? (Centralize가 되면 안되나?)

• single point of failure
  • 한 곳에서 문제가 생겨도 다른 곳에서는 문제가 안생기도록 구현
• 유지 보수 측면
• 거리 측면
• 거대한 양의 traffic을 핸들링해야하므로

 

DNS: a distributed, hierarchical database

만약 사용자가 www.amazon.com에 접속하고 싶다면?

1. 먼저 com DNS server를 찾기위해서 root server에게 query를 던진다.
2. 그렇게 찾아온 com DNS server에게 query를 던져서 amazon.com DNS server를 찾는다.
3. amazon.com DNS Server에게 www.amazon.com의 IP 주소 값을 받기위해서 query를 받는다.

 

DNS: Root name Servers

• local name 서버와 맞닿아있는 server
  • local name 서버 - 호스트가 DNS 쿼리를 만들 때 보내지는 server
  • 쉽게 말해서 host(유저)와 연결된 server라고 생각하면 될듯!..
• name 매핑을 알 수 없다면 authoritative name server와 접촉을 한다.
• mapping을 받고
• local name server(client)에게 mapping된 값을 보내준다.
• 전세계의 몇 안된다.

 

DNS: TLD, authoritative servers

TLD servers(Top-Level domain)

• com, org, net, edu와 uk, fr, ca, jp와 같은 나라의 도메인을 관장한다.
• Network Solutions의 경우 → .com TLD
• Edu → .edu TLD

authoritative DNS Servers

• 조직의 자신만의 DNS 서버를 가지고 있고, providing authoritative hostname to IP Mappings for organization’s named hosts
• 조직이나 서비스 제공자가 관장을 한다.

 

Local DNS name server

• DNS 계층구조에 딱 들어가 있는 것은 아니다.
• 각각의 ISP가 한 개씩 가지고 있다.
  • 가정용 ISP, 기업, 대학
  • default name server 라고도 불린다.
• host가 DNS 쿼리를 만들 때, 해당 쿼리가 보내지는 서버이다.
  • 즉, host가 바로 root server에게 쿼리를 보내는 것이 아니라 local server에게 보내고 하는 것이다.
  • local server는 cache를 가지고 있다. → proxy처럼 행동한다.

Iterated query - 반복쿼리

1. host가 local DNS server에게 쿼리를 던진다.
2. local DNS Server는 root DNS Server에게 쿼리를 던지고 response를 받는다.
3. local DNS Server는 Top Level Domain Server에게 쿼리를 던지고 response를 받는다.
4. local DNS Server는 authoritative DNS Server에게 쿼리르 던지고 IP 주소를 받는다.
5. 그렇게 받은 IP 주소를 host에게 알려준다.

→ “나는 이 값을 모르는데? 얘한테 한번 물어봐!”

즉, 실제 행동대장은 local DNS server인 것이다.

 

 

recursive query - 재귀 쿼리

• 자신의 다음 레벨의 server에게 타고 타고 들어가서 쿼리를 던지는 것!
• root server가 일을 너무 많이 한다.

 

DNS: caching, updating records

• 한번 mapping을 했으면, 해당 local name server는 cache 값을 던져준다. → Local name server에서 TDL의 값을 cache한다.
  • 그러나, 유통기한(TTL)이 존재한다.
  • TLD server가 local name server에서 주로 cache가 되므로 root name server는 자주 방문되지 않는다.
• 만약 name host가 IP 주소를 변경했다면, Web은 TTL이 만료되기 전까지는 해당 사실을 모른다.
  • RFC 2136 규약에 의해서 해당 사실을 업데이트하거나 알려주는 메커니즘이 제안되었다.

DNS records

• 분산된 데이터베이스는 RR(resource records)를 저장한다.
  • RR format: (name, value, type, ttl)
• 계층관계 간의 서로 query를 던질 때 같이 던지는 정보 값
• 각각의 server는 정보를 저장하고 있는 database이라는 것을 잊지말자!.. → 쿼리를 던지면 저장된 데이터를 넘겨주는 것!
• type=A
  • name - host name
  • value - IP address
• type=NS
  • name - domain(ex. amazon.com)
  • value - hostname of authoritative name server
• type=CNAME
  • name - 진짜 이름의 alias name이 들어간다.
  • value - 진짜 이름이 들어간다.
• type=MX
  • value - name과 연관된 mailserver의 이름이 들어간다.

DNS protocol, messages

• query나 reply나 동일한 format을 활용한다.
• message header
  • identification - 16 bit
  • flags - query or reply
• answers
  • RR값이 들어가게 된다.

 

P2P architecture

• 항상 켜져있는 server가 없다.
• 임의의 end system들이 서로 직접 소통을 한다.
• 각각의 peer들은 간혈적으로 연결이 되고, IP 주소를 변경한다.
• 예시
  • file distribution → 파일 전송 (BitTorrent)
  • Streaming
  • VoIP → Skype

 

File distribution time: P2P

• 일단 서버는 파일을 한번만 올리면 된다. → F/us
• 한번 서버가 파일을 upload하면 client들의 upload bandwidth를 활용할 수 있다.
  • 한 파일을 다 다운로드 한 후 전달이 가능한 것이 아니라 어느 정도(chunk) 다운로드 하면 그때부터는 다운받은 부분들을 전달 할 수 있게 된다.
  • 원래 서버의 업로드 속도 + 클라이언트들의 업로드 속도의 합 = 전체 업로드 속도
  • 근데 모든 클라이언트가 모두 파일을 다운로드 받아야하므로 총 필요한 비트 수 → NF
  • 따라서 NF/ (us + ui합)
• client - server는 N이 증가하면 linear하게 증가한다.
• P2P는 N이 증가하면 업로드해주는 peer들이 늘어나므로 그만큼 시간이 줄어든다. → linear하게 증가되지는 않는다.

 

P2P file distribution: BitTorrent

• file들은 256Kb 단위로 나뉘어진다.(chunk)
• 각각의 peer들은 file chunk를 서로 보내고 전달받는다.
• tracker
  • 현재 참여하고 있는 peer들이 누가있는 지를 체크한다.
  • 그래서 새로 들어온 peer들에게 현재 참여중인 peer list(neighbors)를 전달해준다.
• torrent
  • file chunk를 서로 교환하는 peer들의 그룹
• 각각의 peer들은 client의 역할과 server 역할을 동시에 한다.
  • downloading을 하면서, 다른 peer들에게 uploading을 하기도 한다.
• churn
  • peer들은 임의로 탈퇴하고 가입할 수 있다.
  • peer가 해당 파일을 다 가지게 된다면, torrent에서 떠나거나 아니면 계속 거기에 있을 수도 있다.

 

BitTorrent: requesting, sending file chunks

• requesting chunks
  • 여러 사람들에게 chunks를 받아오는 데, 현재 torrent에서 가장 적게 있는 것부터 peer들에게 받아오게 된다.
    • rarest first
• sending chunks: tit-fot-tat
  • alice는 자신에게 가장 많은 chunks를 준 peer들에게 우선적으로 준다.(4명)
  • 매 10초마다 top4를 다시 계산한다.
  • 그리고 매 30초마다 random하게 한명을 뽑아서 chunk를 보내준다. → top 4가 된다.
    • optimistically unchoke

 

Video streaming and CDNs: context

challenge

• 대역폭의 대부분을 차지하고 있다.
• 수많은 유저들을 가지고 있다.
• heterogeneity
  • 사용자가 매우 많이 다양해졌다.

solution

• 분산된 application level infrastructure

 

 

Multimedia: Video

• 수많은 이미지를 보여줘야된다.
• coding을 잘해야된다.
  • spatial
    • 하나의 이미지에서 중복되는 것은 각각 보내는 것이 아니라 한개만 보내는 것
  • temporal
    • 이미지와 그 다음 이미지 중에서 서로 다른 점만을 보낸다!..

Streaming stored video

• HTTP를 활용해서 video를 보내주었다.
• DASH(Dynamic, Adaptive Streaming over HTTP)
  • 하나의 인코딩된 영상을 보내주는 것이 아니라, 사용자의 상태에 따라서 여러 인코딩된 영상을 보내주는 것
  • server
    • video file을 여러 chunk로 나눈다.
    • 각각의 chunk들은 여러 방식으로 인코딩된 버전을 가지고 있다.
    • manifest file - 서로 다른 chunk의 URL을 제공한다.
      • client는 가장 먼저 server에게 이 파일을 요청하는 것!
  • client
    • 주기적으로 client-server간의 bandwidth를 체크한다.
      • 그리고 manifest file을 통해서 아래의 상황을 결정한다. (intelligent)
        • 언제 chunk를 요청할 지를 정한다.
          • buffer 결핍이나 overflow가 발생하지 않는다.
        • 어떤 encoding rate를 요청할 지 결정한다.
          • 대역폭이 가능하다면, 더 높은 encoding rate를 요구한다.
        • 어디에 chunk를 요청할 지 정한다.
          • client에게 가까운 URL server에게 요청할 지, 더 높은 대역폭을 가지고 있는 server에게 요청할 지 결정한다.
    • manifest file을 참고하여 chunk를 요청한다.
      • 현재 대역폭에서 가능한 최고로 좋은 coding rate를 요청한다.

 

Content distribution networks → streaming content!

• 동시에 수 많은 유저들에게 어떻게 stream content를 보내줄 수 있을까?
• 옵션 1 - 하나의 큰 server
  • 한 곳에서 문제가 생기면 다른 곳에서도 문제가 생긴다.
  • network congestion이 생길 수 있다. → 체증이 생길 수 있다.
  • 멀리 있는 client들에게는 너무 긴 시간이 걸린다.
  • 수 많은 video의 복사본들이 나가는 링크에 보내진다.
  • → 즉, 해결할 수 없다.
• 옵션 2 - 수 많은 CDN (지리학적으로 분산되어있는 site)에 수 많은 비디오들의 복사본들을 저장하고 있는다.
  • enter deep
    • CDN server들을 수 많은 access network에 넣어둔다.
      • 서버 클러스터를 세계 곳곳의 접속 네트워크에 구축하는 방식
      • kt network 망 안에 Disney server를 넣어두는 것!
    • user들에게 매우 가깝다.
    • 유지 비용이 크다.(유지보수가 쉽지 않다.)
  • bring home
    • 적은 수의 핵심지점에 큰 규모의 서버 클러스터를 구축하는 방식이다.(access network 근처에 구축한다.)
      • 클러스터를 IXP에 배치한다.

CDN

• CDN node에 content의 복사본을 저장한다.
• subscriber는 자신에게 가깝거나, congestion이 적은 CDN에 content를 요청한다.

 

 

CDN content access: a closer look

• 유저는 OTT 서비스 web page에서 비디오 url을 받는다.
• 해당 비디오 url을 통해서 local DNS server에게 IP 주소가 무엇인지 물어본다.
• local DNS Server는 netcinema의 authoratative DNS server에게 물어봤는데, 해당 server가 KingCDN URL을 던져준다.(canonical) - 실제 URL 주소를 알려준다!
• local DNS Server는 해당 kingCDN url을 통해서 최종적으로 CDN authoritative DNS server에게 IP 주소를 전달받는다. 그리고 해당 IP 주소를 client에게 전달한다. (DNS system)
• 그리고 client는 IP 주소를 통해서 CDN 서버에 접근하여 video를 request한다.(HTTP)

 

NetFlix의 경우

• Amazon cloud에 client가 접근을 한다. 그래서 Amazon Cloud에게 manifest flie을 전달받는다.
• Amazon cloud는 CDN server들에게 여러 가지 영상 copy들을 업로드해놓는다.
• Client는 Amazon cloud에게 받은 manifest file을 통해서 근처 CDN 서버에게서 원하는 content를 받아온다.
  • DASH를 통해서 받아온다.(manifest file)
  • Dynamic, Adaptive Streaming HTTP