DNS: Domain Name System
BIND: DNS 구현해놓은 소프트웨어
* DNS
- 서버에 접속하기 위해서는 IP주소와 포트번호가 필요
- IP주소 기억하기 어려움 -> DNS가 도메인 네임을 IP주소로 변환시켜줌
- 웹 브라우저는 입력된 도메인 네임과 매핑된 IP주소 모름 -> DNS에 물어본다
- 일종의 distributed한 데이터베이스 (여러 계층 구조로 구현)
- application layer protocol
- edge에서 구현
* DNS service
- hostname-to-IP-address 변환
- host aliasing (별명만 알아도 ㄱㅊ)
- mail server aliasing (메일 서버 별명만 알아도 ㄱㅊ)
- load distribution (부하분산 -> 한 도메인에 여러 ip주소 매핑)
* distributed, hierarchial database
- Root, TLD(Top Level Domain), Authoritative
- 루트에서 직접 ip주소 알려주는게 아니라 답을 알만한 애를 소개시켜줌
* root name server
- 가장 상위 서버로 13개의 logical root name server 존재(원본)
- local name server에게 물어보고 만약 없으면 여기로 넘어옴
- TLD 서버의 주소를 알려줌
- DNSSEC: 보안 제공, ICANN에서 root DNS domain 관리함
* TLD, authoritative servers
- TLD: .com, .org, .net, .edu, ... coutnry domains(CCTLD)
- authoritative: 실제 개인 도메인과 IP 주소의 관계가 기록/저장/변경되는 서버
그래서 권한의 의미인 Authoritative가 붙음, 일반적으로 도메인/호스팅 업체의
‘네임서버’를 말하지만, 개인 DNS 서버 구축을 한 경우에도 여기에 해당
* Local DNS name server (호스트가 가장 먼저 접근하는 DNS 서버)
- 위 3개의 DNS 서버를 매번 거친다면 효율이 구데기일 수밖에 없으니, 한 번 거친 후
얻은 데이터를 일정 기간(TTL/Time to Live) 동안 캐시라는 형태로 저장해 두는 서버
- 대표적인게 KT/LG/SK와 같은 ISP(통신사) DNS 서버가 있음
- 계층 구조에 꼭 속해있지는 않음
* DNS name resolution: iterated query (가장 일반적인 형태)
- 답 알만한 애를 소개시켜줌
- 클라이언트가 local dns server 주소는 이미 알고 있음
* DNS name resolution: recursive query (거의 사용 안함)
- 내가 답을 모르면 직접 물어봐줌 (부담 커짐)
* caching DNS information
- 어떤 네임 서버든지 새로운 매핑을 알게 되면 캐싱함
- TTL이 지나면 지워버림 (바뀔 수 있기 때문에)
- TLD 서버는 local name server에 캐싱해둠 (root에 접근 안하기 때문에 response time 감소)
* 문제점: 잘못된 정보가 존재할 수 있음
ex) TTL이 일주일인데 일주일 사이에 정보가 바뀌었으면 잘못된 정보를 캐시하고 있는거임
DNS records
resoruce record(RR)을 분산 데이터베이스에 저장해둠
RR format: (name, value, type, ttl) = 질문, 답, 질문 유형, 유효기간
- A: 질문 = hostname, 답 = ip 주소
- NS: 질문 = domain, 답 = 이 도메인의 authoritative name server의 hostname
- CNAME: 질문 = alias name, 답 = canonical name
- MX: 답 = 메일 서버의 이름
DNS protocol message (query, reply 같은 포맷 가짐)
헤더 총 12byte
- identification: 16비트 for qury
- flag: query or reply, reply is authoritative
Getting your info to DNS
- authoritative name server의 ip주소와 host name을 TLD 서버에 등록
(networkutopia.com, dns1.networkutopia.com, NS)
(dns1.networkutopia.com, 212.212.212.1, A)
- 메일 서버도 등록
(networkutopia.com, mail2.networkutopia.com, MX)
(mail2.networkutopia.com, 메일서버의 ip주소, A)
DNS security
- DDos attacks
루트 서버에 대한 공격은 실패 (로컬 서버에서 tld 서버 캐시하고 있어서 루트에 접근 안함)
TLD 서버에 대한 공격은 좀 더 성공적
- Spoofing attacks (위조)
DNS 쿼리를 가로채서 위조된 답을 리턴 (캐시를 오염시킴)
DNSSEC으로 암호화하긴 하지만 시간 넘 오래걸림
- DNS의 문제점
DNS 캐시 업데이트, reply 제공할 때 어떤 인증, 암호화도 사용하지 않음
Video Streaming and CNDs (content distribution networks)
video traffic: 양이 너무 많고 사용자들의 bandwidth가 다 다름
-> distributed, application-level infrastructure로 해결
* Streaming stored video (ex. 유튜브, 이미 저장되어 있는 비디오 보내줌)
- 서버와 클라이언트의 bandwidth가 계속 변화 -> 혼잡 정도도 계속 변화
- packet loss, delay로 인한 dealy playout, poor video quality
- client-side buffer: 서버가 보낸 내용을 저장해두고 delay 때문에 보내오는게 없을 때
시간을 벌어줌 (매우 중요)
1) video recorded (constant rate, 저장된 비디오니까)
2) video sent (delay jitter(variance))
3) video received, played out at client
* DASH (Dynamic, Adaptive Streaming over HTTP) <- 유튜버 등에서 채택
- 서버
비디오 파일을 여러 chunk로 나눔
각각의 chunk들을 저장하고 다른 rate로 인코딩하여 파일로 저장
파일은 다양한 CDN 노드에 저장 (사용자에게 최적화된 걸로 제공할 수 있음)
manifest file(설명서): 5분, 20개, 고/중/일반, -1/-2/-3, 어디에 저장(ulr)
- 클라이언트
주기적으로 bandwidth 측정
manifest를 이용하여 서버에 특정 chunk를 요청함
상황에 따라 화질 바꾸면서 chunk를 서버에 요청
- intelligence at clinet
클라이언트가 언제 청크를 요청할지, 어떤 화질로 요청할건지, 어떤 서버로부터
청크를 받을 건지 결정함
Streaming video = encoding + DASH + playout buffering
Content distribution networks (CDNs)
store/serve multiple copies of videos at multiple geographically
distributed sites (CDN, 서버를 분산)
- enter deep (client에 최대한 가깝게)
- bring home (방대한 서버를 숫자를 줄여서, POP에(point of presence, IXP)
넷플리스가 매드맨이라는 영화를 여러 CDN 노드에 분산시켜 저장해둠
구독자가 서버에 접속해서 영화 요청하면 넷플릭스는 manifest 파일 보내줌
(manifest 파일에는 각각의 chunk가 어떤 url에 있는지 알려줌)
이 파일을 보고 클라이언트가 가장 최선의 선택을 함
=> 유저가 많으면 한 서버로부터 데이터 서비스가 불가능하니까 여러군데 서비스를 분산시켜 놓고
사용자가 manifest 파일을 통해 그 url에서 데이터를 다운받을 수 있도록 함
Socket Programming 😐
* Socket Programming with UDP
UDP: 클라이언트-서버 사이에 연결 설정 없음, lost, out-of-order가능
-> unrelialble transfer 제공
* Socket Programming for TCP
- 클라이언트와 서버는 반드시 연결되어야 함 (일대일)
- 서버는 클라이언트의 연결을 받기 위해 새로운 소켓을 만들어야함 (ip주소, 포트 번호 이용)
- 즉 웰컴 소켓은 소켓간의 연결만 처리
-> reliable, in-order byte stream transfer 제공
