Chapter2 - Application Layer(2)

2.3 electronic mail

세 가지 주요 구성

• user agents (= mail reader)
• Mail servers(메일을 가지고 있는 서버, SMTP로 메시지 주고받음.)
• SMTP
  -> 메일 서버들이 메일을 보낼 때 사용하는 프로토콜
  -> 클라이언트 : 메세지 보냄 / 서버 : 메세지 받음

2.3.1 SMTP

• 신뢰적 데이터 전송을 위해 TCP를 사용한다.
• Direct transfer : sending 서버가 receiving 서버로 직접 전달한다.
• 세 단계의 전달 과정을 거친다.
  -> handshaking : tcp connection open
  -> transfer to messages : 메세지 전송
  -> closure : connection 해제
• 클라이언트가 command를 보내면 서버가 response 해준다.(HTTP 처럼)
• 메세지는 7-bit의 아스키 형태로 전달 되어야 한다.

사용자 간 메일 서버를 거쳐서 메시지를 주고받는 과정

HTTP vs SMTP

공통점

두 프로토콜 모두, 한 호스트에서 다른 호스트로 파일을 전송하는데 이용되며 지속 가능한 연결을 사용한다.

둘다 아스키 형태의 command/response를 사용한다. status code를 사용한다.

 

차이점

• HTTP는 pull(서버에서 data를 가져오는 방식),
  SMTP는 push(클라이언트에서 서버 쪽으로 파일을 보냄) 프로토콜 방식을 사용한다.
• SMTP는 메시지가 7bit 아스키 포맷이어야 하지만, HTTP는 제한이 없다.
• HTTP는 객체에 캡슐화 방식을, SMTP는 포트를 따로 하여 한 메시지로 만든다.

Mail message format
메일의 실제 내용 -> 헤더와 바디로 구성되어 있다.

• 헤더 : subject -> 제목 / to, from은 smtp 커맨드랑 별도로 실제(데이터 속에 들어가는) 보내는사람, 받는 사람임(smtp에서는 보내는 서버, 받는 서버의 서버에 대한 정보)
• 바디 : 아스키코드로 되어있는 내용

 

2.3.2 Mail access protocols

• SMTP : user agent가 메일을 보내기 위해 자기의 메일 서버에 접속할 때, 메일 서버들 사이에서 메세지를 교환할 때 사용하는 프로토콜
• mail access protocol : 자신의 메일 서버로부터 받은 메일을 가져올 때 사용하는 프로토콜
  -> POP : 제일 먼저 사용된 프로토콜. Authorization(유저네임, 패스워드 확인 등 권한부여), download 기능
  -> IMAP : pop에 기능 약간 추가. 메일 관리를 위한 폴더 등
  -> 요즘은 그냥 웹을 이용하여 메일을 본다.(그저 http 사용)

POP3 and IMAP

POP3

• stateless하며, 매우 간단한 메일 접속 프로토콜로, 매우 한정된 기능을 가진다.
• "다운로드"와 "삭제"가 기본 모드로 한 번 읽으면 다시 읽지 못한다.(pc로 읽으면 휴대폰으로는 다시 못 본다)
• 사용자에게 원격 폴더를 생성하거나 폴더에 메시지를 할당하는 수단을 제공하지 않는다.

IMPA

• 사용자가 폴더를 생성하고, 메시지를 옮기고 삭제할 수 있다.
• stateful함 -> 폴더 보고있다가 끄면 다음에 들어왔을 때 그 폴더부터 볼 수 있음

 

2.4 DNS

DNS : domain name system

인터넷 호스트도 마찬가지로 식별 수단이 필요하며, 이에 대한 식별자는 호스트 네임(host name)이다. 

하지만 호스트 네임은 가변 길이의 문자들로 구성되어 있기 때문에 라우터가 처리하기 어려움이 있어 IP 주소로도 식별된다. IP 주소는 4바이트로 구성되고 계층구조이기 때문에 주소를 왼쪽부터 오른쪽까지 조사하면 호스트의 위치에 대한 자세한 정보를 얻을 수 있다. 하지만 기억하기는 어렵다.

 

따라서 우리는 이러한 선호 차이를 절충하기 위해, 호스트 네임을 IP 주소로 변환해 주는 디렉터리 서비스가 필요했고, 이것이 인터넷 DNS의 주요 임무이다.

 

DNS 서버

• 네임 서버들의 계층구조로 구현된 분산 데이터베이스
• 애플리케이션 레이어 프로토콜.

DNS가 제공하는 서비스들

• 호스트 네임 -> IP 주소
• 호스트 에일리어싱 : 정식 호스트네임(canonical) 외로 사본(alias name) 또는 별칭을 가질 수 있다.
• 메일 서버 에일리어싱
• 부하 분산 : 인기 있는 사이트는 여러 서버에 중복되어 있어서 다른 IP 주소를 할당시켜 부하를 분배시킨다.

왜 중앙화 되지 않은 여러개의 DNS를 사용하는가

• 문제가 발생 시 중앙화 되어있다면, 한 방에 가버릴 수 있다.
• 트래픽량을 감소시킬 수 있다.
• 거리 상의 문제 (만약 미국에 집중되어있다면, 우리는 쓰기 힘들 것이다.)
• 유지 보수 중에 다른 곳으로 쓸 수 있게 해준다.

DNS 구조 - distributed, hierarchical database (분산되고 계층적 구조)

• 루트 DNS 서버(루트서버도 한개가 아니라 여러개 존재)
• 최상위 레벨 도메인(TLD) 서버
• 책임 DNS 서버

서버 찾아서 들어가는 흐름

1. 먼저 루트 서버 중 하나에 접속한다.

2. 루트 서버는 메인 com을 갖는 TLD 서버 IP 주소를 보낸다.

3. 이후 우리는 TLD 서버 중 하나에 접속하고, 서버는 도메인 naver.com 이 가진 책임 서버의 IP 주소를 보낸다.

4. 우리는 책임 서버 중 하나로 접속하고 서버는  www.naver.com IP 주소를 보낸다.  

 

DNS : root name servers

• 가장 상위 name server
• 처음에는 local name server에 물어보는데 만약 없다면 root name server로 연결해 준다.
• 직접적인 ip 주소를 알려주는 것이 아니라 하위 서버의 주소를 알려준다.

TLD, authoritative servers

보통 com, org, net, edu, kr, uk 등 기업, 기관, 대학, 각 나라를 대표하는 도메인 서버이다.

 

Local DNS name server

• 계층구조에 꼭 속해있거나 그런것은 아니다.
• 기관마다 있을 수 있다.(회사, 대학, residention ISP 등) -> default name server 라고도 부른
  다.
• 호스트가 DNS 쿼리를 보내면, 쿼리는 local DNS server로 전달된다.
  -> 만약 캐쉬 사용으로 ip 주소를 이미 알고 있으면 바로 반환한다.
  -> 프록시, 계층구조로의 포워딩 역할을 수행한다.

 

DNS : caching, updating records

• 어떤 네임 서버든지 새로운 매핑을 알게 되면 캐싱한다.
  -> 어느정도 시간(TTL)이 지나면 지워버린다.(바뀔수 있기 때문)
  -> TLD 서버는 보통 local name server에 캐싱해 놓는다.(루트 네임에 대한 트래픽을 감소시킨다.)
• 문제점 : 잘못된 기간이 있을 수 있다.
  -> 만약 TTL이 일주일인데, 일주일 사이에 정보가 바뀌었으면 잘못된 정보를 TTL의 남은 기간동안 가지고 있게 된다.
• 새로운 서버와 변경점에 대한 업데이트와 알려주는 메커니즘을 IETF 표준으로 정의해 두었다.
  -> RFC 2136으로 문서화 되어 있다.

 

2.5 P2P applications

pure P2P architecture

p2p는 클라이언트-서버와 함께 통신망의 종류이다. 보통 대용량 파일을 다운로드할 때 p2p를 이용한다고 하는데, 예를 들어 토렌트를 이용해 영화, 드라마를 다운로드하여 보는 경우가 이에 해당한다.

아무튼 p2p 구조의 특징은 간단히 생각해서 클라이언트-서버 구조와 반대라고 알면 된다.

 

p2p 특징

• 항상 서버가 켜져있지 않다.
• end system(device) 끼리 직접적으로 소통을 한다.
• 피어들(각 end system)은 IP 주소가 바뀔 수 있다.

 

File distributuion : client-server vs P2P

F 사이즈의 파일을 한 서버로 부터 N개의 peer들에게 distribute 하는데 얼마나 시간이 걸릴까?

• us : 서버의 파일을 네트워크로 업로드 하는데 걸리는 전송 속도(업로드 속도)
• di : 네트워크에서 클라이언트로 파일을 보내는 속도(다운로드 속도)

-> 전송속도가 더 낮은 쪽(bottleneck이 걸리는 쪽)이 파일을 다운받는 전송 속도를 결정한다.

 

File distribution time : client-server

• 서버 전송 시간 : N개의 파일 복사본들을 순차적으로 send(upload) 해야 한다.
  -> 한 카피당 서버에서 네트워크로 업로드 하는데 걸리는 시간 : F/us
  -> N 개의 카피들을 보내기 위해서는 N번 업로드 해야한다 : NF/us
• 클라이언트 다운받는 시간
  -> 클라이언트들이 동시에 다운받으려 할 때 가장 다운 속도가 느린 곳에서 bottleneck이 발생하기 때문에 다운로드 속도가 가장 느린 곳이 전체 속도를 결정한다. : F/dmin
• 전체시간
  -> 파일 업로드 시간과 파일 다운로드 시간 중 오래 걸리는 시간이 파일을 distribute 할 때 걸리는 시간
  

  

  
  -> 클라이언트의 수가 늘어나면 N이 증가한다. -> N에 따라 linear 하게 속도 증가

 

File distribution time : P2P

• 서버 전송 시간
  -> 클라이언트들이 파일을 요청하는 상황에서 일단 한번은 서버에서 업로드를 해야 한다.
  = F/us
• 클라이언트 다운받는 시간
  -> 모든 클라이언트들이 다운받아야 하므로 가장 다운속도가 느린곳에 의해 결정
  =  F/dmin
• 한번 파일을 다운로드 한 후로는 클라이언트들의 업로드 bandwidth를 사용 가능하다.
  -> 클라이언트가 서버 역할을 하는 것.
  -> 한 파일을 다 다운로드 한 후 전달이 가능한 것이 아니라 어느 정도(chunk) 다운로드 하면 그때부터는 다운받은 부분들을 전달 할 수 있게 된다.
  -> 즉 원래 서버의 업로드 속도 + 클라이언트들의 업로드 속도의 합 = 전체 업로드 속도
  -> 이 때 N개의 클라이언트가 모두 파일을 다운받아야 하므로 총 필요한 비트 수는 NF 비트
  -> 이 때 걸리는 시간 = NF/(서버 업로드 속도 + 클라이언트들의 업로드 속도의 합)
• 전체 시간
  -> (한 파일에 대한)서버 업로드 시간, 클라이언트 다운받는 시간, 전체 파일에 대한 업로드 시간 중 가장 큰 시간이 파일을 distribute 하는데 걸리는 시간이다.
  

  

  
  -> 클라이언트가 늘어나면 N이 커지지만, 그만큼 업로드 해주는 클라이언트 역시 많아지므로 linear 하게 증가가 아닌 낮은 속도로 증가한다.

client-server vs P2P : example

둘을 비교한것.

• 클라이언트가 많을수록 P2P가 효율적이다.
• 단점
  -> 안정성 문제 : 서버는 24시간 열려 있기 때문에 시간이 좀 걸리더라도 안정적이지만, P2P의 경우 파일을 제공하는 클라이언트들이 꺼져 있으면 파일을 다운받지 못한다.

 

P2P file distribution : BitTorrent

비트 토렌트는 네트워크적 관점에서 p2p 활용의 좋은 예이다. 주로 대용량 파일을 공유할 때 쓰이며 여기서 각 파일들은 256kb의 청크들로 나뉘고 각 피어들은 이 청크들을 주고받게 된다. 

중요한 것은 한 파일에 대한 청크들이 각 피어들에 나뉘어져있어서, 다운로드할 때 현재 가지고있지 않은 청크들을 각 피어들에게 요청해 동시에 받게 된다. 이게 P2P의 가장 큰 장점이다.

 

과정은 다음과 같다.

• 서버는 토렌트(파일을 주고받는 peer들)에 참가한 피어들을 트래킹(추적) 하고, 피어들의 리스트를 만든다.
• 유저 pc는 서버에게 각 피어들의 청크 리스트를 받는다.
• 유저는 피어들에게 요청을 하고, 각 피어들은 그룹을 이뤄 청크들을 주고 받는다.

비트 토렌트의 주요 용어들

• rarest first : 가장 희소성 있는 청크를 먼저 받아 공유한다. (다다익선이기 때문)
• peer churn : 피어들은 임의로 탈퇴하거나 가입할 수 있다.
• selfishly, altruistically : 각각 이기적, 이타적이라는 뜻으로 피어들의 특징을 설명할 때 쓰인다.

 

BitTorrent : requesting, sending file chunks

chunk 요청

• peer들이 가지고 있는 chunk들이 다를 수 있으므로, 주기적으로 각각의 peer들에게 어떤 chunk를 가지고 있는지 물어본다.(chunk list 요청)
•  요청 방식 : rarest first -> 희귀한 chunk 부터 먼저 요청한다. (가지고 있는 peer가 적은 chunk 먼저 요청, peer들이 떠날수도 있으니까)

chunk 보내기(tit-for-tat)

비트 토렌트에서 청크를 보낼 때 쓰이는 용어로, 간단히 말하면 이기적인 피어에게 복수한다는 의미이다.

각 피어들은 주고받는 과정에서 10초마다 주변 피어들 중 가장 전송률이 높은 top4를 선정하고

이를 3번 지속해 30초마다 이기적인 피어 대신 이타적 피어들로 교체를 한다.

 

이때 교체 방법은 "choked"에서 "unchoked"로 바꾸는 방법으로

choked는 청크를 안주는 것을 의미하고 unchoked는 그의 반대가 되겠다.

 

비트토렌트는 이러한 방식으로 높은 업로드 속도를 유지할 수 있게 된다.

2.6 video streaming and content distribution networks

Video Streaming and CDNs: context

Internet bandwidth의 주 소비자는 video traffic으로, 넷플릭스, 유튜브는 각각 ISP 트래픽의 37%, 16% 를 사용함

그럼 이들은 어떻게 그런 수많은 유저들을 관리할 수 있는 것일까?

 

이들은 그에 대한 해답으로 분산 구조, 애플리케이션에 따른 다양한 구조를 갖는 방식을 사용하였다.

 

multimedia: video

• 비디오 : 일정한 비율로 보여지는 이미지들의 sequence
• 디지털 이미지 : 픽셀 array
  -> 각각의 픽셀들은 비트로 표현된다.
• 코딩(coding) : redundancy(중복)을 사용해 이미지의 비트수를 줄인다.
  -> spatial : 한 이미지 내의 같은(비슷한) 부분에 대한 정보를 줄임(압축)
  -> temporal : 이전 이미지와 달라지지 않은 부분을 줄임(압축)
• CBR(constant bit rate) : 처음부터 끝까지 예를들어 1mbps의 rate로 인코딩 한다.(비트 레이트 일관되게 유지)
• VBR(variable bit rate) : 하나의 동영상 내에서도 시간에 따라 어떤 파트는 비트 레이트가 높게 어떤 파트는 비트 레이트가 낮게 한다.(다이나믹한 씬에서는 비트레이트 높임)

Streaming stored video

streaming multimedia : DASH(Dynamic, Adaptive, Streaming over HTTP, HTTP기반의 스트리밍)

 

보통 영상은 HTTP 서버에 특정 URL을 가지고 저장되어있어, 우리가 영상을 볼 때

클라이언트는 서버와 TCP 연결을 만들어 최대한 빠르게 전송하며 재생을 시작한다.

 

하지만 이 HTTP 스트리밍은 큰 단점이 있는데, 바로 클라이언트의 대역폭이 각자 다름에도 불구하고

모두에게 똑같은 인코딩 된 영상을 보내준다는 것이다.

 

이러한 문제점을 해결하기 위해 DASH라는 방식이 개발되었다.

DASH에서 영상들은 여러 가지 다른 버전으로 인코딩 되며 각각 다른 버전은 비트, 품질 등의 차이점을 갖게 된다.

따라서 낮은 대역폭의 유저는 낮은 품질을 받고, 높은 대역폭의 유저는 높은 품질을 받게 된다.

품질뿐만 아니라 bit rate도 대역폭에 따라 나뉘어 받는다.

 

또한 DASH를 이용하는 경우 HTTP 서버는 다 다른 URL를 가지고 있고, 각 버전별 URL을 제공하는 manifest file을 가지고 있다. 따라서 처음에 클라이언트는 서버에 manifest file을 요청해 버전 정보를 받는다.

이후 특정 URL을 지정한 후 각 chunk들을 요청해 받게 된다.

 

Content distribution networks (CDN)

문제점 : 수많은 시청자가 있으면 어떻게 서비스 할 것인가?

해결책 >  서버를 분산시킴(CDN)

-> enter deep : 엑세스 망 안쪽에 CDN 서버를 놓음(더 유저에 가깝게)
-> bring home : 엑세스 망 바깥족에 CDN서버를 놓음(개수는 적고 딜레이는 크지만 더 넓은 지역 커버 가능)

컨텐츼의 복사본들을 CDN 노드들에 저장한다.

클라이언트는 파일을 받을 때 가장 가까운 CDN을 택한다. 단, 그 CDN에 파일이 없거나 혼잡이 심할 경우 다른 CDN을 선택할 수 있다.

CDN content access : a closer look

-> netcinema.com은 어떤 영화가 있는지 보여준다.(클라이언트는 여기에 비디오 요청)
-> CDN 전문 회사로 부터 서비스를 받을 수 있다.(실제 비디오는 kingCDN.com의 CDN에 저장되어 있음, 실제 스트리밍 하는 사이트)

동작과정
1. 사용자가 netcinema.com에서 동영상을 고름 -> 동영상의 url을 얻음
2. 이 url을 가져오기 위해 local dns서버에 url의 ip주소가 뭔지 물어봄
3. local dns 서버가 netcinema의 dns서버를 알려줌 -> netcinema는 어떤 url을 반환해 줘서 이쪽으로 가라고 알려줌
4. 그 url을 찾기 위해 kingCDN의 DNS 서버에 어디있는지 물어봄 -> 해당 url의 컨텐츠가 있는 서버를 반환해서 알려줌
5. 알게된 서버에서 http를 통해 스트리밍함

정리하자면 웹사이트 따로, 스트리밍하는 서버가 따로 있어서 Dns 서버를 이용하여 다른쪽 url을 돌려 줌으로써 거기로 가서 사용자가 거기의 서비스를 활용할 수 있도록 해 준다.

예시 Netflix

넷플릭스 - 계정관리, 영화관리
아마존 클라우드 - 실제 데이터 스트리밍
-> 넷플릭스에 로그인 하고
-> 아마존 클라우드에서 영화 고르고 manifest 파일을 받고
-> 아마존 클라우드의 CDN 서버로 가서
-> 그쪽으로 부터 스트리밍을 받는다.

정리
유저가 많으면 한 서버로 부터 데이터 서비스가 불가능하니까 여러 군데 서비스를 분산 시켜 놓고 사용자가 매니패스트 파일을 통해 그 url에서 데이터를 다운받을 수 있도록 한다.