- Principles of network
- Web & HTTP
- E-mail, SMTP, IMAP
- DNS
- P2P applications
- Video streaming and CDNs
- Socket programming with UDP & TCP
Email, SMTP, IMAP
Email
Email의 3가지 주요 구성요소
- user agent
- mail server
- simple mail transfer protocol: SMTP
User Agent (a.k.a mail reader)
User agent는 mail 메세지를 작성하고, 수정하며, 읽는 작업을 수행할 수 있으며, 그 예로 outlook이나 iphone mail client 등이 있다. User agent를 통해 들어오고, 나가는 메세지는 서버 상에 저장된다.
Mail server
- Mail box : user에게 들어오는 메세지 저장
- Message queue : 전송이될 메세지들의 큐
- SMTP protocol : Mail server 사이에서 메세지를 보내는데 필요한 규칙
- host는 client이자 server로 동작할 수 있다.
Email RFC 821
Email은 TCP를 이용해서 reliable transfer를 수행하고, 25번 포트를 통해 메세지를 전송한다. 이때, client처럼 동작하는 sending server에서 receiving server로 direct하게 메세지를 전달하며, 이 과정은 3 페이즈로 구성된다. Handshaking, message transfer, closure. 이때 HTTP처럼 command(ASCI text), response(status code and phrase)가 들어오며 메세지는 7비트 ASCI로 작성된다.
Email scenario
- Alice는 user agent를 이용해서 bob@someschool.edu에게 보낼 이메일 메세지를 작성한다.
- Alice의 user agent는 그녀의 mail server로 메세지를 보내고, 해당 서버의 message queue에 위치하게 된다.
- SMTP의 client적 측면은 Bob의 mail server와 TCP connection을 열게 된다.
- SMTP client는 Alice의 메세지를 TCP connection을 통해 전달한다.
- Bob의 mail server는 해당 메세지를 수신하여 bob의 mailbox에 저장한다.
- Bob은 그의 user agent를 이용해 메세지를 읽게 된다.
SMTP는 RFC 821에 의해 정의된 email message 교환 과정에 필요한 protocol이다. (HTTP) RFC822는 email message의 syntax를 정의한다.(HTML)
Mail access protocol
- SMTP : email message를 receiver의 server로 보내기까지 배달, 저장 과정에 해당하는 protocol
- Mail access protocol : server로부터 검색하는 protocol
- IMAP : Internet Mail Access Protocol로, 서버에 저장된 메세지를 IMAP을 이용해 검색, 삭제, 폴더 관리 등이 가능하다.
- HTTP : gmail, hotmail, yahoo!mail 등의 웹 기반 인터페이스를 SMTP와 IMAP 위에 제공하여 메일 메세지를 검색하고 전송할 수 있게 한다.
SMTP : closing observation
HTTP와 비교
- HTTP : pull / SMTP : push
- 두 방법 모두 ASCII command/response interaction, status code를 가지고 있음.
- HTTP는 각 object를 response message안에 encapsulate.
- SMTP는 여러 object를 multipart message로 보냄.
- SMTP는 persistent connection 기반.
- SMTP는 message를 7bit ASCII로 작성하도록 요구.
- SMTP server는 CRLF.CRLF를 이용해 메세지의 끝을 알려야 함.
DNS
DNS (Domain Name System)
Process 간의 통신을 수행하기 위해선 port 번호 외에 machine 자체의 주소가 필요하다. 우린 IPv4와 같은 32bit IP address를 통해 datagram의 통신을 수행하고, 이 과정에서 cse.postech.ac.kr와 같은 host name을 통해 internet host, router등을 구별한다.
Domain Name System
- 여러 dns server(name server)들의 hierarchy 위에 구현된 distributed database이다.
- host가 address/name translation을 위해 name을 resolve할 때 distributed database를 query하도록 허용해주는 application-layer protocol이다.
- Note : 핵심 인터넷 기능 중 하나로, DNS가 application-layer protocol로 구현되어 있음을 알아야 함.
- DNS는 network edge의 complexity 요소 중 하나.
DNS: services, structure
DNS Services
- hostname IP address translaiton
- host aliasing
- canonical(공식 이름), alias names(별칭)
IP주소 찾기 : host alias name → host canonical name → IP address
- alias name: 많은 사람들이 기억하기 쉬운 host name (www.his-lab.org)
- canonical name: alias name으로 알려진 서버의 진짜 host name (www.google.com)
- mail server aliasing
- domain 이름으로 메일 서버의 호스트 이름 찾기
- hwang@postech.ac.kr로 메일을 보낼 때 "postech.ac.kr"은 domain 이름이지 mail server의 host name이 아니다.
- "postech.ac.kr" -> "sniper.postech.ac.kr" -> "141.223.5.78" -> TCP connection
- load distribution
- replicated Web servers: Many IP addresses correspond to one name
- 하나의 domain 이름은 여러 분산된 서버를 기반으로 이루어진다.
Q. Why not centralize DNS?
- Centralized DNS의 장점
- Centralized DNS의 단점
- single point of failure : 하나가 고장나면 전체 실패
- traffic volume이 커짐
- distant centralized database : 거리가 멀수록 속도 저하
- Doesn't scale! : 규모가 커지지 않아 확장성이 낮다.
- 하나의 .kr DNS server는 초당 최대 30K의 query를 처리하는 것이 한계이다.
DNS: a distributed hierarchical database
- Root -> TLD server들의 host name과 그에 맵핑 되는 IP addr들
- Top Level Domain (TLD) -> Authoritative domain server들의 host name과 그에 맵핑 되는 IP addr들
- Authoritative -> Canonical name들과 맵핑되는 IP주소들을 가짐
만약 Client가 www.amazon.com의 IP 주소를 찾고자 한다면,
1. client queries root server to find .com DNS server
2. client queries .com DNS server to get amazon.com DNS server
3. client queries amazon.com DNS server to get IP address for www.amazon.com
여기서 보면 알 수 있듯이 TLD의 경우 국가 단위, 일반 단위로 나눠진다.
DNS root name server
공식적으로 이름을 확인할 수 없는 name server의 최후의 접촉지점. 매우 중요한 인터넷 기능 중 하나로, ICANN (Internet Corporation for Assigned Names and Numbers)에서 관리한다. 전 세계적으로 13개의 logical root name server가 존재하며, 각 server들이 복제되어 세계 곳곳에 흩어져 있다.
TLD : Top-Level Domain server
TLD는 generic TLD(a.k.a gTLD, e.g .com, .org, .net, .edu, .aero, .jobs, .museums)와 모든 top-level country domain(country code TLD, a.k.a ccTLD, e.g .kr, .cn, .uk, .fr, .ca, .jp)을 담당한다.
Authoritative server
Authoritative DNS server는 기관 개인의 DNS server로, 기관의 명명된 이름에 맞춰 authoritative hostname의 IP mapping을 제공한다. 이는 기관 혹은 service provider를 통해 유지보수 될 수 있다.
- authoritatie naeservers for postech.ac.kr
- ns.postech.ac.kr
- ns2.postech.ac.kr
Local DNS name server
Local DNS name server는 계층 구조에 엄격하게 속해있지 않는 것으로, ISP(residential ISP, company, university 등)마다 하나씩 가지고 있으며 deault name server라고 불리기도 한다. Host가 DNS query를 만들 때 query는 자신의 local DNS server로 보내진다. 이곳에서는 최근 name-to-address translation pair들의 local cache를 가지고 있고, proxy처럼 동작해 query를 계층구조로 집어넣는다.
Client에서 querying을 시도하면, local dns name server로 접근하게 된다.
DNS name resolution : iterative query
예를 들어, engineering.nyu.edu에 있는 host가 gaia.cs.umass.edu의 IP 주소를 알아내고자 하는 상황이 있다. 이때, iterative query 방식의 경우 local server를 통해 root server -> tld server -> authoritative server 각각에 한 번씩 접속하며 최종 목적지로 도달하게 된다.
- Client가 local dns server에 질문
- local dns server가 root dns server와 통신, .edu를 다루는 TLD dns server의 IP주소를 받아옴
- local dns server가 TLD dns server와 통신해서 umass.edu를 다루는 authoritative dns server의 IP 주소를 받아옴
- local dns server가 authoritative dns server와 통신해서 최종 gaia.cs.umass.edu의 IP 주소를 알아냄.
DNS name resolution : recursive query
마찬가지의 예제에 대해서, recursive query의 경우 상위 계층의 서버가 대량의 name resolution을 담당하는 방식으로 진행된다.
Bonus : dig demo
이 예제는 cse.postech.ac.kr의 IP 주소를 알아내는 과정을 다룬다.
dig NS . (여기서 . 이 root server)
첫 answer section은 13개의 root server, additional serction을 통해 IP 주소를 확인할 수 있다.
여기서 특정 root server를 고른다.
그 후, cse.postech.ac.kr를 입력했을 때 이에 관련된 TLD server 리스트를 확인할 수 있다.
위에서 특정 TLD server를 선택하니 2개의 authoritative server를 확인할 수 있다.
그 중 하나의 authoritative server를 고르면 최종 answer에서 141.223.5.78의 IP 주소를 얻게 된다.
DNS records
DNS는 기본적으로 client의 request를 받아 그에 따른 resource record를 기록하는 분할 데이터베이스이다. 이때, RR은 4가지 요소로 구성되는 tuple format(name, value, type, ttl)을 따른다.
- Name : 상징적인 이름
- Value : 그 이름에 대한 값
- Type : 각 유형을 나타냄
- TTL : DNS caching 정보의 유지시간
Type 별 의미
- type=A (Address Record)
- name is host name
- value is IP address
- type=NS (Name server)
- name is domain (e.g., foo.com)
- value is hostname of authoritative name server for this domain
- type=MX (Mail eXchanger)
- value is name of mailserver associated with name
- type=CNAME (Canonical Name)
- name is alias name for some canonical(the real) name
- value is canonical name
+) 과제 추가 내용
- type=SOA (Start Of Authority)
- 인가된 DNS 영역(Zone)의 시작을 나타냄.
- 모든 영역(Zone)은 정확히 하나의 SOA 레코드 만을 갖게됨
Caching, Updating DNS records
- 한 번 name server가 mapping을 배우면, caching을 할 수 있게 된다.
- Cache entry는 TTL이 지나면 timeout이 된다.
- TLD server는 local name server에 cache되어 있다.
- 따라서 root name server는 자주 방문하지 않는다.
- Cache entry는 out-of-date일 수 있다. (즉, 최신 버전이 아닐 수 있다.)
- Best-effort name-to-address 방식이기 때문에 노력은 하지만 결과를 보장하지 않는다는 것.
- 만약 name host가 IP 주소를 바꿔도, TTL을 초과하기 전까진 알 수 없다.
- update/notify 메커니즘은 IETF에 의해 명시된다. (RFC 2136)
DNS protocol messages
DNS의 query와 reply message는 모두 같은 형식을 가지고 있다.
- Message header
- Message body
- questions
- query를 해야하는 name, type 영역
- answers
- query에 대한 response로 RRs를 전달
- authority
- authoritative server에 대한 기록
- additional info
Inserting records into DNS
예를 들어 his-lab.org라는 사이트를 만들고자 한다.
- DNS registrar에 his-lab.org 이름을 기록한다.
- (e.g., Google domains, Gabia, cafe24, ...)
- authoritative name server(primary, secondary)들의 이름과 IP 주소를 제공한다.
- registrar가 NS, A RRs 를 .com TLD server에 추가한다.
- his-lab.org, NS ns-cloud-b1.googledomains.com
- his-lab.org, NS ns-cloud-b2.googledomains.com
- ns-cloud-b1.googledomains.com, A 216.239.32.107
- ns-cloud-b2.googledomains.com, A 216.239.34.107
- IP 주소를 이용해 authoritative name server를 local하게 만든다.
- type A record for www.his-lab.org
- type MX record for his-lab.org