Application Layer - 4. e-mail, DNS, video streaming

1. Mail access protocols

e-mail(Electronic Mail in the Internet)을 보낼때는 SMTP 프로토콜을 사용한다.
1. email client A가 SMTP를 사용해서 sender's mail server로 메일을 보낸다.
2. sender side mail server가 receiver side mail server에게 SMTP로 메일을 보낸다.
3. email client B는 자신의 메일 서버로부터 mail access protocol을 사용해서 메일을 확인한다. 오늘날에는 gmail, naver mail, office 365처럼 http를 사용해서 client가 자신의 mail server를 확인할 수 있도록 한다.

2. DNS

internet을 사용하는 host, router들은 모두 datagram addressing을 위해 IP address를 갖는다고 했다. IPv4의 경우는 32bit, IPv6의 경우는 128bit로 되어있다.
하지만 사람 입장에서는 이 bit 문자열을 외우기 쉽지 않다.
그래서 domain name system을 사용한다. IP address에 domain name을 mapping하는 것이다.

nslookup명령어를 사용하면 domain name으로부터 ip address를 알 수 있다.
처음에 나오는 Server, Address는 DNS서버의 것이다.
그 다음줄에 우리가 요청한 도메인 이름이 보인다.
그 도메인 이름이 대표하고 있는 수많은 서버들중 나에게 실제로 응답을 준 서버의 이름이 canonical name이다.
이어서 실제 나에게 응답을 준 서버의 이름, address가 나온다.

host 명령어를 사용한 예시이다.

DNS 덕분에 이렇게 mapping한 domain name으로부터 IP address를 변환할 수 있다.
오늘날 DNS는 internet의 핵심 기능인데 application layer protocol인 이유는 end-to-end principle 때문이다. (complexity는 모두 network의 edge에 존재해야 한다)

DNS가 제공하는 서비스는 다음과 같다.
- hostname, IP address 변환
- host aliasing : www.google.com이라는 도메인 이름은 하나지만 실제로는 수십,수백개의 서버가 있을 것이다. 즉 이름은 하나인데 IP address가 여러개인 것이다. 여러개의 실제 서버 중 내 요청에 응답하는 서버의 이름을 canonical name이라고 하고 www.google.com같은 대표이름을 alias name이라고 한다.
- load distribution : 하나의 도메인 name이 많은 ip address들을 대표하기 때문에 여러 서버들로 부하를 분배하기 쉽다.

3. DNS: a distributed, hierarchical database

DNS는 분산된 database로 구현된다. 한곳에 centralize되지 않는 이유가 있는데
1. single point of failure : 서버에 문제가 생겨서 꺼지면 아무도 인터넷을 사용할수 없다.
2. traffic volume : 만약 서버가 한개면 전 세계의 모든 사용자들의 요청이 한 곳으로 집중된다.
따라서 한개의 중앙화된 DNS서버를 만드는 것 보다 여러개의 dns 서버를 만드는 것이 훨씬 낫다.

dns 서버는 이렇게 hierarchical한 구조로 되어있다.
root아래 com, org, edu, kr, jp 등등 dns 서버 아래 각각 dns 서버를 두고 있다.

만약 client가 amazon.com의 ip주소를 알고 싶다면?
1. root dns 서버를 통해 .com dns 서버 주소를 찾는다.
2. .com dns 서버를 통해 amazon.com dns 서버 주소를 찾는다.
3. amazon.com dns 서버를 통해 www.amazon.com의 ip 주소를 찾는다.

root name 서버는 전세계에 총 13개밖에 없다. 이 13개들이 여러곳으로 복제되어 사용된다.
root name 서버를 거치고나면 Top level domain(TLD) server로 내려간다.(.com, .org, .net, .uk, .kr, .fr 등등)
그 다음으로 authoritative dns 서버로 내려간다. naver.com, google.com 같은 organization의 dns서버이다.

host(nsl2.cau.ac.kr)가 gaia.cs.umass.edu의 ip 주소를 원한다고 해보자. 두가지 approach가 있다.
Iterative query approaches

local DNS서버가 모르는 domain의 경우
2,3. (local DNS 서버가) root DNS서버에게 질문 -> .edu DNS 서버 주소 알려줌
4,5. (local DNS 서버가) .edu DNS서버에게 질문 -> umass.edu DNS 서버 주소 알려줌
6,7. (local DNS 서버가) umass.edu DNS서버에게 질문 -> gaia.cs.umass.edu의 주소 알려줌
대부분의 일을 local DNS server가 수행한다.
Recursive query approaches

요청한 상위 계층 dns서버가 하위 계층으로부터 정보를 얻어서 client에게 전달해주는 방식이다.
요청이 많아졌을때 상위 계층이 상당한 load를 부담할 수 있기 때문에 추천하는 방식은 아니다.

4. DNS: caching, updating, inserting records

dns 요청 결과를 local dns server가 caching을 통해 기억하고 있을 수 있다.
*참고로 caching이 local dns server에서만 이루어지는 것은 아니다. web browser, device에서도 caching이 이루어진다.
실제로 TLD dns 서버 주소는 local dns server가 caching을 통해 이미 알고 있다. 따라서 root dns server는 자주 방문되지 않는다.
업체를 통해 mycompany.com이라는 주소를 dns 서버에 등록하면 전 세계 어디서든 mycompany.com을 통해 접속이 가능하다.

5. Video Streaming

video traffic은 internet bandwidth의 주 소비자이다.
netflix, youtube를 통한 동영상 스트리밍이 downstream residential ISP traffic의 약 37, 16퍼센트를 차지한다. 지금은 그 수치가 더 높아졌다.

어떻게 하면 stream content를 수십, 수백명의 사용자에게 동시에 제공할 수 있을까?

하나의 엄청난 규모의 mega 서버를 사용하는 방법은 그닥 좋은 선택지가 아니다.
고장이 나서 서버가 멈추면 모든 사용자가 서비스를 제공받지 못한다(single point of failure)
한 곳으로의 트래픽이 쏠릴 수 있고 유럽 같이 먼 지역에서는 latency가 더 크다.
만약 동일한 영상을 동시에 10명이 보고 있다면 서버에서는 동일한 데이터를 10번 반복해서 링크를 통해 보내야 한다.

그래서 고안한 방법이 지리적으로 분산된 곳에 original server를 복사한 replicated server들을 두고 복사한 video들을 지역 단위로 store/serve하는 것이다.
이를 Content distribution networks(CDN)이라고 한다.

실제로 youtube, netflix같은 global 기업은 전세계 곳곳에 서버를 구축해서 video streaming을 제공하고 있다. 하지만 여력이 부족한 기업의 경우는 서버를 세계 곳곳에 구축해둔 Akamai 같은 업체를 통해서 CDN서비스를 제공 받을 수도 있다.