학교
[컴퓨터 네트워크] 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 구조의 세 개의 요소
Root: DNS 쿼리의 출발점으로부터 최상위 서버
Top Level Domain: .com, .org, .net과 같은 최상위 도메인을 관리
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는 파일을 다운로드할 뿐 아니라 업로드에도 참여하여 네트워크 전체의 배포 속도가 증가한다.
