[컴퓨터 네트워크] Chapter2. Application Layer (Part 2) - (2)

[4] DNS : a distributed, hierarchical database (분산된 계층적 데이터베이스)

1) 클라이언트가 www.amazon.com에 대한 IP 주소를 원할 때

• 클라이언트가 root server를 쿼리하여 .com DNS server를 찾는다.
• 클라이언트가 .com DNS server를 쿼리하여 amazon.com DNS server를 쿼리한다.
• 클라이언트가 amazon.com DNS server를 쿼리하여 www.amazon.com의 IP 주소를 얻는다.

2) DNS 구조의 세 개의 요소

1. Root
   : DNS 쿼리의 출발점으로부터 최상위 서버
2. Top Level Domain
   : .com, .org, .net과 같은 최상위 도메인을 관리
3. Authoritative
   : 특정 도메인의 최종 DNS 정보를 제공하는 서버

[5] DNS : root name servers

1) 이름을 확인할 수 없는 name server의 공식 최후의 수단 연락처

2) 인터넷의 중요한 구성요소이다.

• 인터넷은 DNS 없이는 작동할 수 없다.
• DNSSEC - 보안 (인증 및 메세지 무결성) 제공

3) ICANN (Internet Corporation for Assigned Names and Numbers)

: ICANN(인터넷 주소 자원 관리 기구)가 root DNS domain을 관리한다.

4) 전 세계 논리적 root name server 각 server가 여러 번 복제됨(미국의 경우 최대 200개 서버)

: root 서버는 물리적으로 여러 지역에 분산되어 있어서, 인터넷 트래픽의 부하를 줄이고, 중복성을 확보한다.

[6] TLD : authoritative servers (권한이 있는 서버)

1) Top-Level Domain (TLD) servers (최상위 도메인(TLD) 서버)

• .com / .org / .net / .edu / .aero / .jobs / .museums 및 모든 최상위 국가 도메인을 담당한다.
  • 최상위 국가 도메인 (.cn / .uk / .fr / .ca / .jp)
• 네트워크 솔루션 : .com / .net TLD에 대한 권한이 있는 레지스트리
  • 레지스트리란?
• 교육기관 : .edu TLD

2) Authoritative DNS servers (권한이 있는 DNS 서버)

• 조직 자체의 DNS 서버로, 조직의 named host에 대한 IP 매칭에 권한이 있는 host name을 제공한다.
• 조직 또는 서비스 제공업체에서 유지 관리 가능하다.

3) 추가 내용

• GTLD (Generic TLD)
• CCTLD(Countery Code TLD)

[7] Local DNS name servers (로컬 DNS 네임 서버)

1) 엄격하게 계층에 속하지 않는다.

2) 각 ISP(주거용 ISP, 회사, 대학)에는 하나씩 있다.

3) 'default name server'라고도 한다.

4) host가 DNS query를 하면, local DNS server로 query가 전송된다.

• 최신의 name-to-address 변환 쌍의 local 캐시가 있다. (하지만 오래되었을 수 있고, 이로 인해 잘못된 정보를 반환할 수 있다.)
• 프록시 역할을 하며, query를 계층 구조로 전달한다.

[8-1] DNS name resolution : iterated query (DNS name 확인 : 반복 쿼리)

1) 예시

: enginerring.nyu.du의 host가 gaia.cs.umass.edu의 IP 주소를 원한다.

2) Iterated query

• 연락한 서버가 연락할 서버 이름으로 응답한다.
• 비유 : "이 이름은 모르지만, 이 서버에 물어보세요"

3) 정리

: 클라이언트는 여러 DNS 서버를 반복해서 쿼리해 최종적으로 IP 주소를 얻는다.

[8-2] DNS name resolution : recursive query (DNS name 확인 : 재귀 쿼리)

1) 예시

: enginerring.nyu.du의 host가 gaia.cs.umass.edu의 IP 주소를 원한다.

2) Iterated query

• 연락처 이름에 이름 해결의 부담을 준다.

3) 정리

: 서버가 요청된 정보를 모르면, 클라이언트에게 다음으로 물어볼 서버의 주소를 알려준다. 그리고 클라이언트는 이를 반복하여 원하는 정보를 얻는다.

4) Q. 계층 구조의 상위 레벨에서 과부하가 걸리나요?

[9] Exercise

1) 가정

• 클라이언트와 local DNS server간의 RTT는 RTT_l이고, local DNS server과 다른 DNS server 간의 RTT는 RTT_r라고 가정하자.
• 캐싱을 수행하는 DNS 서버가 없다고 가정하자.

2) 문제

a. 시나리오 A의 총 응답시간은 얼마인가요?

: RTT_l + 3 * RTT_r

• 클라이언트가 로컬 DNS 서버에 쿼리를 보내고, 로컬 DNS 서버가 상위 서버로 쿼리를 전달하는 과정을 모두 포함한 시간이다.

b. 시나리오 B의 총 응답시간은 얼마인가요?

: RTT_l + 3 * RTT_r

c. 이제 요청된 이름에 대한 DNS 레코드가 local DNS server에 캐시되어 있다고 가정한다. 두 시나리오의 총 응답 시간은 얼마일까?

: RTT_l

• 캐시된 정보가 로컬 DNS 서버에 있을 때는 상위 DNS 서버에 쿼리를 보낼 필요가 없으므로 응답 시간이 크게 줄어든다.

[10] 캐싱, DNS 레코드 업데이트

1) 일단 (모든) name server가 매핑을 학습하면, 매핑을 캐시한다.

• 캐시 항목은 일정 시간 후 시간 초과된다. (사라진다.) : TTL(Time To Live)
• TLD 서버는 일반적으로 local name server에 캐시된다.
  • 따라서 root name server는 자주 방문하지 않는다.
  • 이것을 통해 RTT_r를 줄여주는 효과를 볼 수 있다.

2) 캐시된 항목이 오래되었을 수 있다. (최선을 다해 이름에서 주소로 변환)

• name host가 IP 주소를 변경하면, 모든 TTL이 만료될 때까지 인터넷 전체에 알려지지 않을 수 있다.

3) 업데이트/알림 매커니즘 제안 IETF vywns

• RCF 2316

[11] DNS records

1) DNS : 리소스 레코드 (RR)를 저장하는 분산 데이터베이스

2) Type의 종류

(1) type = A

• name : hostname
• value : IP address

(2) type = NS

• name : domain (e.g. : foo.com)
• value : 도메인의 퀀한 있는 name server의 Host name

(3) type = CNAME

• name : 일부 정식(실제) 이름의 별칭 이름
  • www.ibm.com is really servereast.backup2.ibm.com
• value : canonical (정식 이름)

(4) type = MX

• value : 이름과 연결된 mail server의 이름

3) Type의 종류의 요약

• Type A: 도메인 이름을 IP 주소로 매핑.
• Type NS: 도메인 이름을 권한 있는 이름 서버로 매핑.
• Type CNAME: 도메인의 별칭을 다른 도메인으로 매핑.
• Type MX: 도메인을 메일 서버로 매핑.

[12] DNS 프로토콜 메세지

: DNS query and reply message 형식은 모두 동일하다.

1) message header

• identification (식별) : 쿼리의 경우 16비트, 쿼리에 대한 회신은 동일한 # 사용
• flags
  • 쿼리 또는 응답
  • 원하는 재귀
  • 재귀 사용 가능
  • reply는 권한이 있음

2) 종류

(1) questions : 클라이언트가 요청한 domain name, query의 유형 필드

(2) answers : query에 대한 응답의 RRs (RR : 응답 레코드)

(3) authority : 권한 있는 서버에 대한 레코드

(4) additional info : 사용할 수 있는 추가 '유용한' 정보

[13] DNS에 레코드 삽입

1) 예시

: 신규 스타트업 "네트워크 유토피아"

2) 과정

(1) DNS 등록 기관 (예 : 네트워크 솔루션)에 networkuptopia.com이라는 이름을 등록한다.

• 이름, 권한 있는 name server (기본 및 보조)의 IP 주소 제공
• 등록 기관이 .com TLD 서버에 NS, A's RR을 삽입한다.
  • (networkutopia.com, dns1.networkutopia.com, NS)
  • (dns1.networkutopica.com, 212.212.212.1, A)

5. P2P applications

[1] Peer-to-peer (P2P) 아키텍처

:P2P(Peer-to-Peer) 시스템은 모든 참여자가 동등한 위치에서 데이터를 주고받을 수 있는 분산 아키텍처이다. 서버 없이도 참여자(peer) 간에 직접 통신이 이루어진다.

1) 특징

• 상시 가동 서버 없음
• 임의의 end system이 직접 통신
• peer가 다른 peer에게 서비스를 요청하고, 다른 peer에게 대가로 서비스를 제공
  • 자체 확장성 : 새로운 peer는 새로운 서비스 용량과 새로운 서비스 수요를 가져온다.
    (네트워크에 더 많은 peer가 참여할수록 네트워크의 용량이 자연스럽게 증가한다.
• peer는 간헐적으로 연결되고, IP 주소를 변경한다.
  • 복잡한 관리
• 예시 : P2P 파일 공유 (비트로렌트), 스트리밍 (칸칸), VoIP(스카이프), 블록 체인

[2-0] 파일 배포 : client-server vs P2P

1) Q. 한 서버에서 N 개의 peer에게 파일 (크기 F)을 배포하는데 걸리는 시간은 얼마나 걸리나요?

• peer 업로드/다운로드 용량은 제한된 리소스이다.
  

[2-1] 파일 배포 시간 : client-server

1) 서버 전송

: N개의 파일 사본을 순차적으로 전송(업로드) 해야 한다.

• 복사본 하나 전송하는 데 걸리는 시간 : F/U_s
  • F는 파일 크기, U_s는 서버의 업로드 속도를 의미
• N개의 복사본을 전송하는 데 걸리는 시간 : N * F/U_s

2) 클라이언트

: 각 클라이언트는 파일 사본을 다운로드해야 함
-> 모든 클라이언트가 동시에 다운로드할 때 가장 느린 클라이언트가 완료하는 시간이 가장 오래 걸린다.

• d_min : 최소 클라이언트 다운로드 시간
• 최대 클라이언트 다운로드 시간 : F/d_min

3) 정리

: client server 접근 방식을 사용하여 F를 N 클라이언트에 배포하는 시간

• N * F/u_s의 경우 N 만큼 선형적으로 증가한다.

[2-2] 파일 배포 시간 : P2P

1) 서버 전송

: 사본을 하나만 업로드해야 한다.
-> 파일 전체를 업로드할 필요 없이 단 한 사본만 업로드하면 된다. (피어(peer)들이 다운로드한 파일의 일부를 다른 피어들에게 다시 업로드하기 때문)

• 복사본 하나 전송하는 데 걸리는 시간 : F/U_s

2) 클라이언트 (단수)

: 각 클라이언트는 파일 사본을 다운로드해야 함

• 최대 클라이언트 다운로드 시간 : F/d_min

3) 클라이언트 (다수)

: 엉덩이 집계는 NF bits를 다운로드해야 한다.

• mas upload rate(limiting mas download rate) : us + u_i의 합 (시그마)

4) 정리

: client server 접근 방식을 사용하여 F를 N 클라이언트에 배포하는 시간

• N * F/u_s의 경우 N 만큼 선형적으로 증가한다.
• u_i의 합(시그마)의 경우 각 피어가 서비스 용량을 제한함에 따라 다음과 같이 증가한다.

5) P2P의 장점

: 각 peer는 파일을 다운로드할 뿐 아니라 업로드에도 참여하여 네트워크 전체의 배포 속도가 증가한다.

---