Chapter2: Application Layer-2

흰제비갈매기 2024. 7. 3. 00:00

2024. 7. 3. 00:00

SMTP: closing observations

SMTP: 주요 특징 및 마무리 설명

Persistent Connections
- SMTP는 지속적인 연결을 사용한다.
Message Format
- Message(헤더 및 본문)는 7 bit ASCII 형식이어야 한다.
- Message 끝은 CRLF.CRLF로 구분한다.

HTTP와의 비교

HTTP와 SMTP의 차이점
- HTTP: 'pull' 프로토콜. client가 server에서 데이터를 요청하여 가져온다.
- SMTP: 'push' 프로토콜. server가 client로 데이터를 보낸다.
- 둘 다 ASCII command/response interaction 및 status code를 사용한다.
객체 전송 방식
- HTTP: 각 object는 자체 response message에 encapsulate 된다.
- SMTP: 여러 object는 multipart message로 전송된다.

Mail message format

SMTP(Simple Mail Transfer Protocol): 이메일 메시지를 교환하기 위한 프로토콜로, RFC 531에 정의되어 있다. HTTP와 유사하게 동작한다.
RFC 822: 이메일 메시지의 문법을 정의한다. HTML과 비슷하게 메시지의 형식을 규정한다.
헤더 라인(Header Lines):
- To : 수신자.
- From : 발신자
- Subject : 주제
- 이 라인들은 이메일 메시지 본문 내에서 SMTP MAIL FROM:, RCPT TO: 명령과 구분된다.
본문(Body): 메시지 본문은 ASCII 문자로만 구성된다.

Mail Access Protocols

이메일 접근 프로토콜

SMTP: e-mail message를 receiver's server로 전달하고 저장하는 역할을 한다.
mail access protocol: 서버에서 이메일을 검색하는 역할을 한다.

IMAP(Internet Mail Access Protocol)
- RFC 3501에 정의되어 있다.
- 메시지는 서버에 저장되며, IMAP은 저장된 메시지의 검색, 삭제, 폴더 관리 기능을 제공한다.
HTTP
- Gmail, Hotmail, Yahoo! Mail 등은 웹 기반 인터페이스를 제공한다.
- 이메일을 전송하기 위해 SMTP를 사용하며, IMAP(또는 POP)을 사용하여 이메일 메시지를 검색한다.

The Domain Name System DNS

DNS: Domain Name System

식별자(Identifiers)
- 사람들은 여러 가지 식별자를 가지고 있다. 예를 들어 SSN, 이름, Passport 등이 있다.
- internet host와 router도 IP 주소(32bit)와 name(e.g. cs.umass.edu)을 가지고 있다.

DNS의 역할
- IP address와 name 간의 매핑을 처리한다.
- 이 매핑을 통해 사람이 이해하기 쉬운 이름을 IP 주소로 변환하고 그 반대의 경우도 처리할 수 있다.

분산 데이터베이스(Distributed DataBase)
- DNS는 많은 name server로 구성된 계층적(hierarchy) 분산 데이터베이스이다.
- application layer protocol로 구현되어 있으며, host와 name server 간의 통신을 통해 이름을 resolve하고 주소를 변환한다.

인터넷의 핵심 기능
- DNS는 인터넷의 핵심 기능 중 하나로, application layer protocol로 구현되어 있다.
- 네트워크의 'edge'에 복잡성이 존재한다.

DNS: services, structure

DNS Service

호스트 이름을 IP 주소로 변환
- DNS는 도메인 이름을 IP 주소로 변환하는 서비스이다.
- e.g. www.google.com을 172.217.164.110으로 변환
호스트 별칭(host aliasing)
- 여러 별칭을 사용할 수 있다.
- e.g. www.ibm.com와 같은 별칭을 사용하여 더 긴 공식 이름을 대신할 수 있다.
메일 서버 별칭(host aliasing)
- DNS는 메일 서버의 별칭도 제공한다.
부하 분산(load distribution)
- 여러 IP 주소가 하나의 도메인 이름에 대응할 수 있다.
- 복제된 웹 서버를 사용하여 부하를 분산한다.
Q. 왜 DNS를 중앙 집중화를 피하는가?
- 단일 장애 지점(single point of failure)
  - 중앙 집중화된 DNS 서버가 장애를 겪으면 전체 시스템이 영향을 받게 된다.
- 트래픽 볼륨(traffic volume)
  - 중앙 집중화된 서버는 모든 DNS 쿼리를 처리해야 하기에 트래픽이 집중되고 서버 과부하가 발생할 수 있다.
- 멀리 떨어진 중앙 집중형 데이터베이스(distant centralized database)
  - 중앙 집중화된 데이터베이스는 지리적으로 멀리 떨어진 사용자에게 지연 시간을 증가시킬 수 있다.
  - 분산형 구조는 더 가까운 서버에서 쿼리를 처리할 수 있어 성능이 향상된다.
- 유지보수(maintenance)
- 스케일링 문제를 해결하기 위해
  - e.g. Comcast의 DNS 서버는 하루에 600억 개의 DNS 쿼리를 처리한다.
분산 데이터베이스
- DNS는 분산 계층 구조로 구성된다.
- 여러 이름 서버가 계층적으로 배치되어 있다.

Thinking about the DNS

거대한 분산 데이터베이스(Humongous distributed database)
- 약 10억 개의 간단한 레코드가 포함되어 있다.
수많은 쿼리 처리(Handles many trillions of queries/day)
- 읽기 작업이 쓰기 작업보다 훨씬 많다.
- 성능이 중요하다. 거의 모든 인터넷 거래는 DNS와 상호작용하며, 밀리초 단위의 응답 시간이 중요하다.
조직적으로, 물리적을 분산화됨(Organizationally, Physically decentralized)
- 수백만 개의 조직이 각자의 레코드를 관리한다.
탄탄함(Bulletproof)
- 신뢰성과 보안이 뛰어나다.

DNS: a distributed, hierarchical database

루트 DNS 서버(Root DNS Servers)
- 최상위에 위치하며, .com, .org, .edu 등의 최상위 도메인(TLD) 서버로 쿼리를 전달한다.

최상위 도메인(TLD) 서버(Top-Level Domain Server)
- 각 TLD에 대한 정보를 가지고 있으며, 특정 TLD에 속한 권한 있는 DNS 서버로 쿼리를 전달한다.
- e.g. .com, .org, .edu 등

권한 있는 DNS 서버(Authoritative DNS Servers)
- 특정 도메인 이름에 대한 최종 IP 주소 정보를 가지고 있다.
- e.g. amazon.com, pbs.org, nyu.edu 등의 서버

예
- 클라이언트가 www.amazon.com의 IP 주소로 요청하는 과정
1. client가 root server에 query를 보낸다.
2. root server가 .com TLD server 주소를 client에게 전달한다.
3. client는 .com TLD server에 query를 보낸다.
4. .com TLD server가 amazon.com Authoritative DNS server 주소를 client에게 전달한다.
5. client가 amazon.com Authoritative DNS server에 qeury를 보낸다.
6. amamzon.com Authoritative DNS server는 www.amazon.com의 IP 주소를 client에게 전달한다.
7. client는 IP 주소를 받는다.

DNS: root name servers

역할
- 루트 네임 서버는 도메인 이름을 해결하지 못하는 경우 마지막으로 연결할 수 있는 공식적인 연락처이다.
- 인터넷 기능에서 매우 중요한 역할을 한다. 인터넷은 루트 네임 서버 없이는 제대로 작동할 수 없다.

DNSSEC
- DNSSEC는 보안을 제공하며, 인증과 메시지 무결성을 보장한다.

ICANN
- 인터넷 할당 번호 관리 기관(Internet Corporation for Assigned Names and Numbers)이 root DNS domain을 관리한다.

전 세계에 분포된 루트 네임 서버
- 전 세계에 13개의 논리적 루트 네임 서버가 있으며, 각 서버는 여러 번 복제되어 있다. 미국에만 약 200개의 서버가 존재한다.
- 지도에는 루트 네임 서버의 분포가 시각적으로 표시되어 있다.

Top-Level Domain, and Authoritative Servers

Top-Level Domain(TLD) Server
- .com, .org, .net, .edu, .aero, .jobs,. museums와 같은 최상위 도메인 및 국가 도메인(e.g. .cn, .uk, .fr, .ca, .jp)을 담당한다.
- Network Solutions: .com 및 .net TLD의 권한 있는 레지스트리
  - Educause: .edu TLD의 권한 있는 레지스트리

Authoritative DNS Servers(권한 있는 DNS 서버)
- organization 자체 DNS 서버로서, 조직의 네임드 host에 대한 host name을 IP 주소로 매핑하는 기능을 제공한다.
- organization이나 서비스 제공자가 maintaine 할 수 있다.

Local DNS name servers

host가 DNS query를 만들 때
- Local DNS server로 query를 보낸다.
- Local DNS server는 name-address translation pair의 Local cache에서 response를 반환하거나(가능한 경우), DNS hierarchy 구조로 request을 전달하여 해결한다.

Local DNS 서버의 역할
- local cache에서 최근의 name-address translation pair을 반환할 수 있다.(다만, 이 정보가 오래되었을 수도 있다)
- 계층 구조로 request을 전달하여 해결한다.
- ISP마다 Local DNS name server를 가지고 있으며, 이를 찾는 방법은 다음과 같다.
  - MacOS: scutil --dns
  - Windows: ipconfig /all

계층 구조에서의 위치
- local DNS 서버는 엄격하게 말하면 계층 구조에 속하지 않는다.

DNS name resolution: iterated query

DNS 이름 해석:반복 쿼리

예시 시나리오:
- host가 반복 쿼리
  - enginerring.nyu.edu의 host가 gaia.cs.umass.edu의 IP 주소를 요청할 때

iterated query:
- Client가 request을 보낸 server는 요청된 이름을 모를 경우, 다음으로 문의할 server의 이름을 응답을 보낸다.
- "이 이름은 모른다. 그러니까 이 서버에 물어봐라"

DNS name resolution: recurisve query

예시 시나리오:
- host가 반복 쿼리
  - enginerring.nyu.edu의 host가 gaia.cs.umass.edu의 IP 주소를 요청할 때

Recursive query:
- 요청한 이름의 해석을 담당하는 name server가 최종 응답을 찾기 위해 다른 name server와 통신한다.
- 계층 구조 상위 레벨에서 큰 부하가 발생할 수 있다.
  - 모든 recursive query에 대해 상위 계층 DNS server들은 여러 번의 쿼리와 응답을 처리해야한다.

Caching, Updating DNS Records

DNS 캐싱(DNS Caching)
- name server가 mapping을 학습하면, 이를 Cache에 저장한다.
- Cache 항목은 일정 시간이 지나면 만료(TTL)된다.
- TLD server는 일반적으로 local name server에 Cache되므로 root name server는 자주 방문되지 않는다.

Cache된 항목의 한계
- 캐시된 항목이 오래(Out-Of-Date) 되었을 수 있다.(최선을 다한 이름-주소 변환)
- host의 IP 주소가 변경되면, 모든 TTL이 만료될 때까지 인터넷 전역에서 알지 못할 수 있다.

업데이트 및 알림 메커니즘
- IETF 표준으로 제안된 업데이트/알림 메커니즘이 있다.(RFC 2136)

주요 요점

DNS 캐싱은 성능 향상과 트래픽 감소에 도움이 되지만, 캐시된 데이터가 만료되기 전까지 최신 정보가 아닐 수 있다.
TTL(Time To Live)은 캐시 항목이 유효한 기간을 정의한다.
업데이트 매커니즘은 DNS 레코드가 변경될 때 네트워크 전역에 알리기 위한 표준이다.

DNS records

DNS Record는 DNS 서버가 해당 패킷을 받았을 때 어떤식으로 처리할지를 나타내는 지침을 말한다.
간단히 말하면 DNS 상에서 도메인에 관한 설정을 하기 위해 사용되는 일련의 설정 문자라고 보면 된다.
DNS Record에서는 서버가 요청에 응답하는 방법에 대한 다양한 구문과 명령이 포함되어 있다.

DNS Record를 공부해야 하는 이유는 만일 개인 도메인을 구입하기 위해 도메인 업체 사이트에 접속해서 도메인과 내 서버 IP와 연결하려면 해당 정보가 필요하기 때문이다.

이 밖에 실 서비스의 도메인을 관리하기 위해서는 레코드의 각 특징에 대해 알아둘 필요가 있다.

DNS는 resource records(RR)를 저장하는 distributed database이다. 각 RR은 네 가지 필드로 구성된다.

형식(RR Format)
- (name, value, type, ttl) 로 구성된다.

DNS Recode의 종류
- Type = A:: DNS에 저장되는 정보의 타입으로 도메인 주소와 서버의 IP 주소가 직접 매핑시키는 방법이다. 도메인 tistroy.com을 예로 들면, A record는 '티스토리 도메인은 IP 주소 121.53.105.234에 연결되어 있다.라고 말하는 역할을 한다고 보면 된다
  - A 레코드는 반드시 domain과 IP 간의 일대일 매칭이 될 필요는 없다.
  - 도메인 매핑 설정에 따라서 일대다/다대일이 될 수 있다.
  - 이름(name): 호스트 이름
  - 값(value): IP 주소
- Type = NS(Name Server): NS 레코드는 네임 서버 레코드로 도메인에 대한 네임서버의 권한을 누가 관리하고 있는지 알려주는 레코드이다. 쉽게 말해, example.co.kr 이라는 도메인을 cafe24 업체에서 구입해서 사용하고 있다고 하면, example.co.kr 도메인을 관리하는 네임서버는 당연히 cafe24가 되게 된다.
  - 이름(name): 도메인 이름(e.g. foo.com)
  - 값(value): 해당 도메인의 권한 있는 name server의 host 이름
- Type = CNAME(Canonical Name record):: CName 레코드는 도메인 별명 레코드라고 부르며, 도메인 주소를 또 다른 도메인 주소로 이중 매핑시키는 형태의 DNS 레코드 타입이다. 쉽게 말하면 도메인 주소로 연결한 부분에 다시 한번 도메인 주소로 연결하는 방식이다.
  - 예를 들어 daum.net 도메인이 있다고 했을 때, 이 도메인의 CNAME을 daum2.net으로 정해, 브라우저에 daum2.net을 입력하면 daum.net로 접근되는 형식이다.
  - 이름(name): 별칭 이름(www.ibm.com)
    - 값(value): 실제 이름(servereast.backup2.ibm.com)
- Type = MX(Mail Exchanger):: MX 레코드는 메일 서버 레코드이며, 해당 도메인과 연동되어 있는 메일서버를 확인하는 데 사용하는 레코드이다. 즉, MX 레코드가 해당 도메인에 설정되어 있어야, 해당 도메인을 이메일 주소로 사용할 수 있다는 뜻이다.
  - 이름(name): 메일 서버와 연결된 도메인 이름
  - 값(value): 메일 서버의 이름

예

 Type = A:
     name: www.example.com
     value: 192.0.2.1

 Type = NS:
     name: example.com
     value: ns1.example.com

 Type = CNAME:
     name: www.example.com
     value: servereast.backup2.example.com

 Type = MX:
     name: example.com
     value: mail.example.com

DNS protocol messages

DNS의 query와 reply message, 둘 다 같은 format을 가진다.

메시지 헤더
- 식별자: response와 request를 일치시키기 위해 사용되는 16bit 숫자
- 플래그: 여러 플래그가 포함되어 있다.
  - query 또는 response flag
  - recursion 요청 플래그
  - recursion 사용 가능 플래그
  - authoritative(권위 있는) reply 플래그

questions(질문) 수: 포함된 질문 수
- quesition section: host name, type filed 등을 포함
answer(응답) 수: 포함된 응답 리소스 레코드(RR)의 수
- answer section: query에 대한 리소스 레코드가 포함
authority(권위) RR 수: 권위 서버에 대한 리소스 레코드의 수
- authority section: authority server에 대한 리소스 레코드
additional RR 수: 추가 정보 섹션의 리소스 레코드 수
- addtional info section: 아마 쓰일 수 있는 "helpful"한 additional info
참조: RR(Resource Records)는 query에 대한 응답으로 제공되는 정보이다. 이름, 값, 타입, TTL field를 포함한다.

Inserting records into DNS

도메인 이름 등록
- "Network Utopia"라는 새로운 스타트업의 도메인 이름 networkuptopia.com을 DNS registrar(등록 기관)(e.g. Network Solutions)에 등록한다.
- 권위 있는 이름 서버(기본 및 보조)의 이름과 IP 주소를 제공한다.

등록기관의 역할
- 등록기관은 .com 최상위 도메인(TLD) 서버에 NS 및 A 레코드를 삽입한다.
- e.g.
  - NS Record: (networkutopia.com, dns1.networkutopia.com, NS)
  - A Record: (dns1.networkutopia.com, 212.212.212.1, A)

authoritative server 생성
- local에 IP 주소 212.212.212.1을 가진 권위 있는 서버를 생성한다.
- www.networkutopia.com에 대한 A 레코드를 생성한다.
- networkutopia.com에 대한 MX 레코드를 생성한다.

이 과정은 도메인 이름을 DNS에 등록하고, 도메인 이름에 대한 다양한 유형의 레코드를 설정하는 전형적인 절차를 설명한다. 이를 통해 도메인 이름이 인터넷 상에서 인식되고, 이메일 및 웹 트래픽이 해당 도메인으로 올바르게 라우팅될 수 있게 한다.

DNS Security

DDoS 공격(DDoS attack)

루트 서버에 트래픽 폭탄(bombard root servers with traffic)
- not successful to date: 지금까지 로트 서버에 대한 DDoS 공격이 성공하지 못했다.
- traffic filtering: 트래픽 필터링을 통해 비정상적인 트래픽을 차단한다.
- 로컬 DNS 서버가 TLD 서버의 IP를 캐시하여 루트 서버 우회 가능: 로컬 DNS 서버가 최상위 도메인(TLD) 서버의 IP 주소를 캐시함으로써, 루트 서버를 우회하여 직접 TLD 서버에 접근할 수 있다.
TLD 서버에 트래픽 폭탄(bombard TLD Servers)
- potentially more dangerous: TLD 서버에 대한 공격은 잠재적으로 더 큰 위험을 초래할 수 있다.

리다이렉트 공격(Redirect attack)

중간자 공격(man-in-middle):
- DNS 쿼리를 가로챔(intercept DNS queries): 중간자 공격자는 DNS 쿼리를 가로채고 변조된 응답을 보낼 수 있다.
DNS 중독(DNS poisoning):
- 가짜 응답을 DNS 서버에 보내서 캐시하게 함: 공격자는 DNS 서버에 가짜 응답을 보내 이를 캐시하게 함으로써, 사용자가 잘못된 IP 주소로 리다이렉트 되게 할 수 있습니다.

DDoS에 DNS 악용(Exploit DNS for DDoS)

위조된 소스 주소로 쿼리 보내기(send queires with spoofed source address)
- 타켓 IP 주소를 위조하여 쿼리를 보냄으로써, 대량의 응답 트래픽이 타켓 서버로 보내져 DDoS 공격을 유발할 수 있다.
증폭 필요(requires amplification):
- 작은 쿼리로 큰 응답을 유발하는 증폭 기법을 사용하여 공격의 효과를 극대화할 수 있다.

DNSSEC(DNS Security Extensions)

DNSSEC는 DNS에 대한 인증 및 무결성을 제공하여 DNS 중독과 같은 공격을 방지하는 데 사용된다.
RFC 4033은 DNSSEC의 표준을 정의

P2P application

Peer-to-peer(P2P) architecture

항상 켜져 있는 서버가 없음: P2P 아키텍처는 항샹 켜져 있는 중앙 서버가 필요하지 않는다.
임의의 종단 시스템 간 직접 통신: 임의의 종단 시스템(peer)이 서로 직접 통신한다.
peer 간 service 요청 및 제공: peer는 다른 peer로부터 서비스를 요청하여, 다른 peer에게 서비스를 제공한다. 이를 통해 자체 확장성이 이루어진다.
- 새로운 peer가 추가될 때마다 새로운 서비스 용량과 새로운 서비스 요구가 발생한다.
  - 간헐적 연결 및 IP 주소 변경: peer는 간헐적으로 연결되며 IP주소가 변경될 수 있다.
- 이러한 특성으로 인해 관리가 복잡해진다.

예시

파일 공유: BitTorrent와 같은 파일 공유 서비스
스트리밍: KanKan과 같은 스트리밍 서비스
VoIP: Skype와 같은 인터넷 전화 서비스

File distribution: client-server vs P2P

Q. 'F' 크기의 파일을 하나의 서버에서 N개의 peer에게 배포하는 데 얼마나 시간이 걸리는가?

옵션1: 단일, 큰 "mega-server"를 사용하는 경우 => 이 솔루션은 확장되지 않음
- 단일 장애 지점(single point of failture): 서버가 다운되면 전체 시스템이 작동하지 않음
- 네트워크 혼잡 지점(point of network congestion): 많은 사용자가 한 서버에 접속하면 혼잡이 발생함
- 원거리 클라이언트에게 긴 경로(long path to distant client): 서버와 클라이언트 간의 거리가 멀면 전송 시간이 길어짐
- 출발지 링크를 통해 여러 비디오 복사본 전송(multiple copies of video sent over outgoing link): 서버는 여러 클라이언트에게 각각의 비디오 복사본을 전송해야함

파일 배포의 두 가지 방식 비교

클라이언트-서버 모델: 중앙 서버가 모든 파일을 클라이언트에게 전송
P2P 모델: 파일을 받은 클라이언트가 다른 클라이언트에게 파일을 전송하여 분산 처리

주요 요소
- 서버 업로드 용량(us): 서버가 데이터를 업로드 할 수 있는 속도
- peer 다운로드 용량(di): 각 피어가 데이터를 다운로드할 수 있는 속도
- peer 업로드 용량(ui): 각 피어가 데이터를 업로드할 수 있는 속도
네트워크
- network with abundant bandwidth: 네트워크 자체는 대역폭이 충분하여 병목 현상이 발생하지 않음을 가정

File distribution time: client-server

client-server model에서 파일을 배포하는 데 걸리는 시간을 설명한다. 주어진 파일 크기 F를 N명의 client에게 배포하는 상황을 다루고 있다.

서버 전송(server transmission)

순차적으로 N개의 파일 복사본 전송
- 서버는 각 클라이언트에게 파일을 업로드 해야한다.
- 하나의 복사본을 전송하는 데 걸리는 시간: F/u_s
- N개의 복사본을 전송하는 데 걸리는 총 시간: NF/u_s

클라이언트 전송(client transmission)

각 클라이언트는 파일 복사본을 다운로드해야 함
- 최소 클라이언트 다운로드 속도: d_min
- 클라이언트가 파일을 다운로드하는 데 걸리는 최소 기간: F / d_min

파일 배포 시간 공식(File Distribution Time Formula)

클라이언트-서버 접근 방식을 사용하여 N명의 클라이언트에게 F 크기 파일을 배포하는데 걸리는 시간

D_c-s >= max(NF/u_s , F/d_min)

NF/u_s: 서버가 N명의 클라이언트에게 파일을 전송하는 데 걸리는 시간
F/d_min: 각 클라이언트가 파일을 다운로드하는 데 걸리는 최소 시간

결론

client-server 모델에서 파일 배포 시간은 N의 크기에 선형적으로 증가한다.
즉, client의 수가 증가할수록 서버가 각 클라이언트에게 파일을 전송하는 데 걸리는 시간이 선형적으로 증가한다.

File distribution time: P2P

P2P(Peer-to-Peer) 모델에서 파일을 배포하는 데 걸리는 시간을 설명한다. 주어진 파일 크기 F를 N명의 클라이언트에게 배포하는 상황을 다루고 있다.

서버 전송(server transmission)

최소 하나의 복사본 업로드 필요
- 서버는 최소한 하나의 파일 복사본을 업로드해야 한다.
- 하나의 복사본을 전송하는 데 걸리는 시간: F/u_s

클라이언트 다운로드(client download)

각 클라이언트는 파일 복사본을 다운로드해야함
- 최소 클라이언트 다운로드 속도: d_min
- 클라이언트가 파일을 다운로드하는 데 걸리는 최소 시간: F/d_min

클라이언트 업로드(clients upload)

클라이언트는 총 NF 비트를 다운로드 해야함
- 최대 업로드 속도(최대 다운로드 속도를 제한하는 속도): u_s + ∑u_i

파일 배포 시간 공식(File Distribution Time Formula)

P2P 접근 방식을 사용하여 N명의 클라이언트에게 파일 F를 배포하는 데 걸리는 시간
- F/u_s: 서버가 하나의 파일 복사본을 업로드하는 데 걸리는 시간
- F/d_min: 각 클라이언트가 파일을 다운로드하는 데 걸리는 최소 시간
- NF/u_s+∑u_i: 모든 클라이언트가 파일의 총 NF 비트를 다운로드하는 데 걸리는 시간

결론(Conclusion)

P2P 모델에서 파일 배포 시간은 N의 크기에 선형적으로 증가한다.
하지만, P2P 모델에서는 새로운 peer가 추가될 때마다 추가적인 서비스 용량을 제공하기에, 서비스 용량도 선형적으로 증가한다.

Client-server vs P2P: example

축:

X축: 파일을 받는 클라이언트의 수
Y축: 최소 배포 시간

조건:

클라이언트 업로드 속도(u): 일정
파일 크기(F) / 업로드 속도(u) = 1시간: 파일을 업로드하는 데 걸리는 시간
서버 업로드 속도(u_s) = 10u: 서버의 업로드 속도는 클라이언트 업로드 속도의 10배
최소 클라이언트 다운로드 속도(d_min) >= 서버 업로드 속도(u_s): 최소한 서버의 업로드 속도만큼의 다운로드 속도를 가져야함

위의 그래프는 P2P 모델이 클라이언트-서버 모델보다 파일 배포에 있어 더 효율적임을 시각적으로 보여준다. 특히 클라이언트가 많아질수록 P2P 모델의 장점이 더 두드러진다. P2P 모델에서는 클라이언트들이 서로 파일을 공유하므로, 네트워크 자원의 활용도가 높아지고 배포 시간이 단축된다.

P2P모델이 클라이언트-서버 모델보다 파일 배포에 더 효율적인 이유는 다음과 같다.

분산된 자원 활용: C-S는 모든 파일이 중앙 서버에서 client로 전송된다. 이는 서버의 업로드 대역폭에 큰 부담을 준다. 허나 P2P에서는 파일을 다운로드한 클라이언트들이 다시 다른 클라이언트들에게 파일을 전송하기에 서버의 부담이 크게 줄고, 네트워크 총 업로드 대역폭이 증가한다.
확장성: C-S는 클라이언트 수가 증가함에 따라 서버의 부담이 선형적으로 증가한다. 많은 클라이언트들이 동시에 파일을 요청하면 서버가 병목현상을 겪게 된다. P2P에서는 새로운 클라이언트가 추가될 때마다 그 클라이언트가 다른 클라이언트들에게 파일을 공유하므로, 네트워크의 자원이 자연스럽게 확장된다. 결과적으로 클라이언트 수가 증가해도 배포 효율성이 유지된다.
병목 현상 감소: C-S에서는 중앙 서버가 모든 클라이언트들에게 파일을 전송하므로, 서버의 업로드 용량이 병목 현상이 될 수 있다. P2P에서는 여러 클라이언트가 동시에 파일을 공유하므로, 병목 현상이 분산되고 완화된다. 네트워크 전체의 자원을 더 효과적으로 활용할 수 있다.
낮은 비용: C-S에서는 고성능 서버와 대역폭이 필요하며 많은 비용이 들 수 있다. P2P에서는 각 클라이언트가 자원을 공유하기에 서버의 필요성이 줄어들고, 비용이 절감된다.
호율적인 대역폭 사용: C-S에서는 서버와 클라이언트 간의 대역폭만 사용된다. P2P에서는 클라이언트 간에도 직접 파일을 전송하므로, 네트워크의 대역폭을 더 효율적으로 사용할 수 있다.

P2P file distribution: BitTorrent

파일 분할

파일은 256KB chunck로 분할됨: 큰 파일은 더 작은 256KB 단위의 청크로 나뉜다. 이 파일의 조각은 더 쉽게 공유하고 다운로드할 수 있도록 한다.

peer 간 chunck 전송

토랜트 내의 peer들은 파일 청크를 송수신함: 각 pear는 파일의 일부 peer를 다른 peer들과 교환한다.

트래커(tracker)

트래커의 역할: tracker는 torrent에 참여하는 peer들을 추적한다. tracker는 각 peer가 가지고 있는 file chunck 정보를 관리하고, 새로운 피어가 네트워크에 참여할 때 다른 peer들의 리스트를 제공한다
- 트래커는 중앙 서버 역할을 하지만 파일 데이터를 직접 전송하지 않는다. 대신, peer들이 서로를 찾고 연결할 수 있도록 돕는다.

토렌트(torrent)

토렌트의 정의: 토렌트는 파일 청크를 교환하는 peer들의 그룹이다. 이 그룹 내에서 각 peer는 파일 chunck를 다운로드하고 업로드 한다.

예시

Alice가 네트워크에 참여하는 과정
- Alice가 토렌트에 도착한다.
- Alice는 트래커로부터 peer들의 리스트를 얻는다.
- Alice는 토랜트 내의 peer들과 file chunck를 교환하기 시작한다.

P2P file distribution: BitTorrent

peer joining torrent(피어가 토렌트에 참여하는 과정)
- 청크가 없음(has no chuncks): 새로운 peer는 처음에는 file chunck를 하나도 가지고 있지 않는다.
- 다른 peer들로부터 청크를 축적(will accumulate them over time from other peers): 시간이 지나면서 다른 peer들로부터 file chunck를 다운로드 받아 축적하게 된다.
- 트래커에 등록하여 피어 목록을 얻음(registers with tracker to get list of peers) : tracker에 등록하여 peer list를 얻음: tracker에 등록하여 이웃 피어들의 목록을 얻는다.
- 이웃 peer들과 연결(connects to subset of peers 'neightbors'): peer 목록에서 일부 peer들과 연결

while downloading(다운로드 중)
- 업로드(uploads chuncks to other peers): 다운로드하는 동안, 피어는 자신이 다운로드한 파일 청크를 다른 피어들에게 업로드한다.

peer may change peers(피어 변경)
- 청크를 교환하는 피어를 변경할 수 있음(with whom it exchanges chuncks): peer는 청크를 교환하는 다른 피어들을 변경할 수 있다.

churn(혼잡)
- 피어는 왔다가 사라질 수 있음(peers may come and go): 피어들은 네트워크에 참여하거나 떠날 수 있음

once peer has entire file(파일 전체를 받은 후)
- 이기적으로 떠날 수 있음(selfishly leave): peer가 파일 전체를 다운로드한 후에 네트워크를 떠날 수 있다.
- 이타적으로 남아있을 수 있음(altruishtically remain in torrent): pper는 이타적으로 네트워크에 남아 다른 peer들에게 파일을 계속 업로드할 수도 있다.

BitTorrent:requesting, sending file chuncks

Requesting chuncks(파일 청크 요청)

다양한 peer가 서로 다른 file chunck를 가짐
- 각 peer는 서로 다른 file chunck의 하위 집합을 가지고 있다.

주기적으로 peer들에게 file chunck 목록을 요청
- Alice는 주기적으로 각 peer에게 그들이 가지고 있는 file chunck 목록을 요청한다.

부족한 청크를 요청. 드문 청크를 우선 요청
- Alice는 자신이 가지고 있지 않은 부족한 청크를 요청한다.
- 이 때, 드문 청크를 우선적으로 요청한다. 이는 네트워크 전체의 균형을 맞추고 모든 청크가 고르게 배포되도록 돕는다.

sending chuncks: tit-for-tat(파일 청크 전송: 티트포텟)

최고 속도로 청크를 보내주는 four peer에게 chunck 전송:
- Alice는 현재 자신에게 가장 높은 속도로 chunck를 보내주는 네 pear에게 chunck를 전송
- 이 외의 peer들은 Alice에게 청크를 받지 못한다. 이를 choking이라고 한다.

매 10초마다 상위 네 피어 재평가
- Alice는 매 10초마다 상위 네 피어를 재평가하여 변경할 수 있다.

매 30초마다 무작위로 새로운 피어를 선택하여 chunck 전송 시작
- Alice는 매 30초마다 무작위로 새로운 피어를 선택하여 청크 전송을 시작한다.
- 이를 optimistically unchoke라고 하며, 선택된 새로운 피어는 상위 네 피어에 합류할 가능성이 있다.

BitTorrent: tit-for-tat

Alice가 Bob을 optimistically unchoke한다.
Alice가 Bob의 상위 4대 공급자 중 하나가 됨(Alice becomes one of Bob's top-four providers)
Bob이 Alice의 상위 4대 공급자 중 하나가 됨(Bob becomes one of Alice's top-four providers)

효과

높은 업로드 속도(higher upload rate)
- peer들은 더 나은 거래 파트너를 찾기 위해 노력하며, 이를 통해 file을 더 빨리 받을 수있다.
- Alice와 Bob은 서로에게 높은 업로드 속도로 청크를 전송함으로써 파일 전송 속도를 극대화한다.

Video Streaming and content distribution networks

Video Streaming and CDNs:context(Content Delivery Network)

비디오 스트리밍 트래픽(stream video traffic)
- 인터넷 대역폭의 주요 소비자(major consumer of internet bandwidth)
  - Netflix, youtube, amazon prime 등의 스트리밍 서비스는 2020년 residential ISP traffic의 80%를 차지한다.
  - 이는 비디오 스트리밍이 인터넷 트래픽의 큰 부분을 차지하고 있음을 보여준다.

도전 과제(Challenges)
1. 규모(Scale)
  - 약 10억 명의 사용자에게 도달하려면 어떻게 해야 하는가?
  - 단일 mega-video server는 작동하지 않는다.
  - 이유: 단일 서버는 많은 사용자를 동시에 처리할 수 없기에 네트워크 병목 현상이 발생할 수 있다.
2. 이질성(heterogeneity)
  - 사용자들의 다양한 능력(e.g. 유선 대 모바일, 대역폭 풍부 대 대역폭 부족)을 처리해야한다.
  - 각 사용자는 서로 다른 네트워크 환경과 장치를 사용하고 있기에, 이를 고려한 전송 방법이 필요하다.

해결책(solution)
- 분산된 어플리케이션 레벨 인프라(distributed, application-level infrastructure)
  - 문제 해결을 위해서는 분산된 인프라가 필요하다.
  - CDN은 이러한 분산된 인프라의 좋은 예시로, 여러 서버에 컨텐츠를 분산시켜 사용자에게 가까운 위체에서 컨텐츠를 제공함으로써 대역폭 사용을 최적화하고, 사용자 경험을 향상시킨다.

Multimedia: video

비디오의 기본 개념
- 비디오(video): 일정한 속도로 연속적인 이미지가 표시되는 시퀀스이다.
  - e.g. 1초에 24장의 이미지가 표시된다.
- 디지털 이미지(digital image): 픽셀 배열로 구성된다.
  - 각 픽셀은 bit로 표현된다.
Coding
- 코딩의 목적: 이미지 내의, 이미지 간의 중복성을 사용하여 이미지 인코딩에 사용되는 비트 수를 줄인다.
  - 공간적 중복성(spatial redundancy): 이미지 내의 중복성
  - 시간적 중복성(temporal redundancy): 한 이미지에서 다음 이미지로의 중복성

시간 코딩(temporal conding) 예제
- 시간적 코딩의 예(temporal coding example)
  - i + 1 프레임에서 완전한 프레임을 보내는 대신, i 프레임과 차이점만 전송한다.
  - 예를 들어, 연속된 이미지 프레임 간의 차이점만 전송하여 데이터 양을 줄인다
- 프레임 예시(Frame Example)
  - 프레임 i와 프레임 i + 1
    - 프레임 i: 원본 이미지
    - 프레임 i + 1: 이전 프레임과의 차이점만 인코딩된 이미지.

비디오 인코딩 방식
1. CBR(Constant Bit Rate)
  - 고정 비트율(constant bit rate): 비디오 인코딩 속도가 고정되어 있다.
  - 특징: 특정한 비트율로 인코딩하여 예측가능한 네트워크 대역폭 사용과 일정한 품질을 제공한다.

2. **VBR(Varaible Bit Rate)**
    - **가변 비트율(variable bit rate)**: 비디오 인코딩 속도가 공간적, 시간적 코딩 변화량에 따라 달라진다.
    - 특징: 인코딩 비트율이 변화하여 복잡한 장면에서는 높은 비트율을 사용하고, 단순한 장면에서는 낮은 비트율을 사용하여 효율성을 높인다.

<br><br>


- **예제**
    - MPEG(Moving Picture Experts Group) 1(CD-ROM): 1.5 Mbps의 비트율을 사용
    - MPEG 2(DVD): 3-6 Mbps의 비트율을 사용
    - MPEG 4(인터넷 사용): 64 Kbps에서 12 Mbps까지 다양한 비트율을 사용하며, 인터넷 스트리밍에 자주 사용된다.

Streaming stored video

간단한 시나리오(Simple Scenario)
- 비디오 서버(video server): 저장된 비디오 파일이 있는 서버
- 인터넷(internet): 비디오 서버와 클라이언트 간의 네트워크 경로
- 클라이언트(client): 비디오를 스트리밍하여 재생하는 장치

주요 과제(Main Challenge)
1. 서버-클라이언트 대역폭 변동(server-to-client bandwidth will vary)
  - 시간에 따라 네트워크 혼잡 수준이 변함에 따라 서버에서 클라이언트로의 대역폭이 변동한다.
  - 혼잡은 여러 위치에서 발생할 수 있다.
    - 가정 내(in house): 가정 내 네트워크 환경의 변동
    - 접속 네트워크(in access network): 인터넷 서비스 제공자(ISP)와의 접속 경로에서 발생하는 혼잡
    - 네트워크 코어(in network core): 인터넷 백본 네트워크에서 발생하는 혼잡
    - 비디오(at video server): 서버 자체의 대역폭 및 성능 문제
2. 패킷 손실 및 지연(pacekt loss and delay)
  - 네트워크 혼잡으로 인한 패킷 손실 및 지여는 비디오 재생의 지연을 초래하거나 비디오 품질 저하를 초래한다.
  - 패킷 손실(packet loss): 데이터 패킷이 전송 도중 손실되는 현상. 비디오 스트리밍 시, 손실된 패킷은 재생 품질을 저하시킬 수 있다.
  - 지연(delay): 데이터 패킷이 목적지에 도달하는 데 걸리는 시간이 지연되는 현상. 이는 비디오 재생의 끊김을 유발할 수 있다.

<br><br>
<br><br>

아래의 그림은 저장된 비디오를 스트리밍하는 과정을 시각적으로 설명한다. 주요 단계와 관련된 네트워크 지연 및 데이터 전송을 보여준다.

주요단계

비디오 녹화(video recorded)
- 비디오가 초당 30 frame의 속도로 녹화된다.
- 그래프의 왼쪽에서 계단 모양의 선이 비디오가 시간에 따라 기록되는 누적 데이터를 나타낸다.

비디오 전송(video sent)
- 녹화된 비디오 데이터가 서버에서 클라이언트로 전송된다.
- network delay가 존재하며, 이는 고정된 값으로 가정한다.
- 그래프에서 빨간색 선은 서버가 클라이언트로 비디오 데이터를 전송하는 속도를 나타낸다.

비디오 수신 및 재생(video received, played out at client)
- client는 네트워크 지연 후 비디오 데이터를 수신하고 재생한다.
- client는 초당 30 frame의 속도로 비디오를 재생한다.
- 그래프에서 파란색 선은 client가 비디오 데이터를 수신하고 재생하는 과정을 나타낸다.

스트리밍 동작(Streaming Operation)
- 스트리밍 중(streaming): 이 시점에서 클라이언트는 비디오의 초반 부분을 재생하고 있으며, 서버는 여전히 비디오의 후반 부분을 전송하고 있다.
  - 클라이언트는 버퍼링을 통해 초반 데이터를 미리 받아 두고, 이후 데이터를 계속해서 받아 재생한다.

Streaming stored video: challenges

저장된 비디오를 스트리밍하는 과정에서 직면하는 주요 도전 과제를 설명한다.

지속적인 재생 제약(Continuous Playout Constraint)
- 재생 시작 후 원래 타이밍과 일치해야 함
  - 클라이언트가 재생을 시작하면, 재생은 원래 타이밍과 일치해야 한다.
  - 이는 사용자가 비디오를 시청할 때 끊김 없이 자연스럽게 재생되도록 하는 것을 의미한다.
- network delay의 변동성(Jitter)
  - 네트워크 지연은 변동될 수 있다. 이를 Jitter라고 한다.
  - 이러한 변동성을 맞추기 위해 client-side buffer가 필요하다.
  - 클라이언트 측 버퍼는 데이터의 변동성을 흡수하여, 일정한 재생을 유지하도록 도와준다.

기타 도전 과제(Other Challenge)
- 클라이언트 상호작용(Client Interactivity)
  - 사용자는 비디오를 일시정지(Pause), 빨리 감기(Fast-forward), 되감기(Rewind), 특정 부분으로 이동(Jump throught video)할 수 있어야 한다.
- 비디오 패킷 손실 및 재전송(Video Packets MayBe Lost, Retransmitted)

Streaming stored video: playout buffering

아래의 그림은 저장된 비디오 스트리밍 과정에서 재생 버퍼링이 어떻게 작동하는지를 시각적으로 설명한다. 네트워크 지연과 지터(Jitter, 지연 변동)를 보상하기 위해 클라이언트 측 버퍼링과 재생 지연을 사용하는 방법을 보여준다.

비디오 전송(video transmission)
- 고정 비트율 비디오 전송(constant bit rate video transmission)
  - 서버는 고정 비트율로 비디오 데이터를 전송한다.
  - 그래프에서 빨간색 계단선으로 나타낸다.

네트워크 지연(Network Delay)
- 변동 네트워크 지연(variable network delay)
  - 네트워크 지연은 일정하지 않고 변동될 수 있다.
  - 그래프에서 네트워크 지연으로 인해 클라이언트가 데이터를 수신하는 속도가 변동하는 것을 보여준다.

비디오 수신 및 버퍼링(Video Reception and Buffering)
- 클라이언트 비디오 수신(client video recpetion)
  - 클라이언트는 서버로부터 비디오 데이터를 수신한다.
  - 그래프에서 검은색 계단선으로 나타낸다.
- 버퍼링된 비디오(buffered video)
  - 클라이언트는 수신된 비디오 데이터를 재생하기 전에 버퍼링한다.
  - 버퍼링된 데이터는 지연 변동을 흡수하여 일정한 재생을 보장한다.

비디오 재생(Video Playout)
- 고정 비트율 비디오 재생(constant bit rate video playout at client)
  - 클라이언트는 버퍼링된 데이터를 일정한 비트율로 재생한다.
  - 그래프에서 파란색 계단선으로 나타낸다.

재생 지연(Playout Delay)
- 클라이언트 재생 지연(client playout delay)
  - 클라이언트는 네트워크 지연과 지터를 보상하기 위해 재생을 약간 지연시킨다.
  - 이는 클라이언트 측 버퍼링이 필요한 이유 중 하나이다.

Streaming multimedia: DASH

DASH(Dynamic, Adaptive Steaming over HTTP) 프로토콜을 사용한 멀티미디어 스트리밍의 개념과 작동 방식을 설명한다.

DASH란 무엇인가?
- DASH는 Dynamic, Adaptive, Streaming over HTTP의 약자로, HTTP를 통한 동적 적응 스트리밍을 의미한다.
  - Dynamic: 네트워크 상태에 따라 스트리밍 비트레이트를 동적으로 조정
  - Adaptive: 클라이언트의 네트워크 상황에 맞추어 최적의 비디오 품질을 제공
  - Streaming over HTTP: HTTP 프로토콜을 사용하여 비디오 스트리밍을 수행

서버(Server)
- 비디오 파일을 여러 청크로 나눔(divides video file into multiple chuncks)
- 각 청크는 각각 다른 속도로 인코딩되고 저장된다.(each chunck stored, encoded at different rates)
- 매니페스트 파일 제공(manifest file)
  - 매니페스트 파일은 각 청크에 대한 URL을 제공한다.
  - 클라이언트는 이 매니페스트 파일을 사용하여 필요한 청크를 요청한다.

클라이언트(Client)
- 주기적으로 서버-클라이언트 대역폭 측정(periodically measures server-to-client bandwidth)
- 매니페스트 파일을 참조하여 한 번에 하나의 청크 요청(consulting manifest, requests one chunk at a time)
  - 현재 대역폭에 따라 최대 코딩 비트레이트 선택(choose maximum coding rate sustainable given current bandwidth)
  - 다른 시간대에 다른 코딩 비트레이트 선택 가능(can choose different coding rates at different points in time)

Intelligence at Client: client는 다음을 결정한다.
1. 청크를 언제 요청할지 결정(when to request chunk)
  - 클라이언트는 버퍼가 고갈되거나 넘치지 않도록 적절한 시점에 청크를 요청해야한다.
  - 버퍼 고갈(buffer starvation): 버퍼에 충분한 데이터가 없어서 재생이 중단되는 상황
  - 버퍼 오버플로우(buffer overflow): 버퍼에 너무 많은 데이터가 쌓여서 새로운 데이터를 저장할 공간이 없는 상황
2. 어떤 인코딩 버퍼 레이트를 요청할지 결정(what encoding rate to request)
  - 클라이언트는 현재 사용 가능한 대역폭에 따라 더 높은 품질의 비디오를 요청할 수 있다.
  - 더 높은 대역폭이 사용 가능할 때 더 높은 품질 요청(higher quality when more bandwidth available): 클라이언트는 더 많은 대역폭이 사용 가능할 때 더 높은 인코딩 비트 레이트를 선택하여 더 좋은 품질의 비디오를 스트리밍할 수 있다.
3. 어디서 청크를 요청할지 결정(where to request chunk)
  - 클라이언트는 자신과 "가까운" URL 서버 또는 높은 가용 대역폭을 가진 서버에서 청크를 요청할 수 있다.
  - 가까운 서버(close to client): 클라이언트와 물리적으로 가까운 서버는 일반적으로 더 짧은 응답 시간을 가진다.
  - 높은 가용 대역폭(high available bandwidth): 클라이언트는 현재 높은 대역폭을 제공할 수 있는 서버를 선택할 수 있다.

스트리밍 비디오의 구성요소(Streaming Video = Encoding + DASH + Playout Buffering)
- 인코딩(Encoding): 비디오를 다양한 비트 레이트로 인코딩하여 여러 청크로 나눈다.
- DASH: 클라이언트가 네트워크 상태에 따라 적응적으로 청크를 요청하는 프로토콜
- 재생 버퍼링(Playout Buffering): 네트워크 지연과 지터를 보상하기 위해 클라이언트 측에서 버퍼링을 사용하여 일정한 재생을 유지한다.

Content distribution networks(CDNs)

도전 과제(Challenge): 수백만 개의 비디오 중에서 선택된 콘텐츠를 수십만 명의 동시 사용자에게 어떻게 스트리밍할 것인가?

단일, Large "Mega-Server": 해결책 안됨
- 단일 장애 지점(Single Point of Failure)
- 네트워크 혼잡 지점(Point of Network Congestion)
- 먼 거리의 클라이언트까지 긴 경로(Long Path to Distant Clients)
- 나가는 링크로 비디오의 여러 복사본 전송(Multiple Copies of Video Sent Over Outgoing Link)
  - 동일한 비디오의 여러 복사본을 여러 사용자에게 동시에 전송해야 하므로, 서버의 업로드 대역폭이 크게 소모된다.

지리적으로 분산된 여러 사이트에 여러 복사본 저장 및 제공(Store/Serve Multiple Copies of Videos at Multiple Geographically Distributed Sites, CDN)
- CDN(Content Distribution Network): 비디오 컨텐츠의 여러 복사본을 다양한 지리적 위치에 분산하고 저장하고 제공하는 네트워크
1. Enter Deep: access network 깊숙이 CDN 서버를 배치
  - 사용자에게 더 가까운 위치에 CDN 서버를 배치하여 네트워크 지연을 줄인다.
  - e.g. Akamai는 2015년 기준으로 120개국 이상에 240,000대의 서버를 배치했다.
2. Bring Home: access network 근처(그러나 내부는 아닌)에 큰 cluster 배치
  - Limelight와 같은 회사는 더 적은 수(수십 개)의 큰 클러스터를 배치하여 관리한다.
  - 이러한 클러스터는 접속 네트워크 근처에 위치하여 접근성을 높인다.

CDN의 작동 방식(How CDNs Work)

컨텐츠 저장(Content Storage)
- CDN 노드에 컨텐츠 복사본 저장(stores copies of content at CDN nodes)
  - 예를 들어, Netflix는 MadMen의 복사본을 여러 CDN 노드에 저장한다.
  - 이러한 방식으로 컨텐츠가 여러 위치에 분산되어 저장된다.

구독자의 요청(Subscriber Request)
- 구독자가 CDN으로부터 컨텐츠 요청(subscriber requests content from CDN)
  - 구독자가 content를 요청하면, CDN은 구독자를 가까운 복사본으로 안내한다.
  - 구독자가 가까운 CDN 노드에서 컨텐츠를 가져온다.

네트워크 경로 혼자 시 대체 복사본 선택(Altername Copy Selection)
- 네트워크 경로가 혼잡한 경우 다른 복사본 선택(may choose different copy if network path congested)
  - 네트워크 경로가 혼잡할 경우, CDN은 구독자가 다른 경로의 다른 복사본으로 선택하도록 안내할 수 있다.
  - 이를 통해 네트워크 혼잡을 피하고 더 빠르게 컨텐츠를 제공할 수 있다.

CDNs와 OTT(Over the Top)

OTT란 무엇인가?
- OTT(Over the Top): 인터넷을 통해 제공되는 컨텐츠 서비스를 의미한다. 예를 들어, Netflix와 같은 서비스가 이에 해당합니다.
  - 인터넷 호스트 간 통신 서비스(Internet host-host communication as a service): OTT 서비스는 인터넷을 통해 호스트 간의 통신을 서비스로 제공한다.

CDN의 역할(Role of CDN)
- CDN 노드에 컨텐츠 복사본 저장(Stores copies of content at CDN nodes)
  - e.g. Netfilx는 "MadMen"의 복사본을 여러 CDN 노드에 저장한다.
  - 여러 위치에 컨텐츠를 저장하여 사용자에게 더 가까운 곳에서 컨텐츠를 제공할 수 있다.

OTT 도전 과제(OTT Challenges): 혼잡한 인터넷 대처(Coping with a Congested Internet)
- 어떤 CDN 노드에서 컨텐츠를 가져올 것인가?(From which CDN node to retrieve content?)
  - 사용자 요청 시, 최적의 CDN 노드를 선택하여 컨텐츠를 가져와야 한다.
- 혼잡 시 시청자의 행동(Viewer behavior in presence of congestion)
  - 네트워크가 혼잡할 때, 시청자가 어떻게 행동할 것인지 예측해고 대처해야한다.
- 어떤 컨텐츠를 어떤 CDN 노드에 배치할 것인가?
  - 효율적인 컨텐츠 전송을 위해 각 CDN 노드에 어떤 컨텐츠를 배치할지 결정해야 한다.

CDN content access: a closer look

절차(Procedure)

Bob이 비디오 URL을 받음(클라이언트 요청)
- Bob은 netcinema.com 웹 페이지에서 비디오 URL(http://netcinema.com/6Y7B23V)을 받는다.

Bob의 local DNS server를 통해 URL을 확인(DNS 확인)
- Bob의 local DNS 서버에 http://netcinema.com/6Y7B23V의 DNS 요청을 보낸다.

netcinema의 DNS가 CNAME을 반환(CNAME 반환)
- netcinema의 권한 있는 DNS 서버가 CNAME(http://KingCDN.com/NetC6y&B23V)을 반환한다.
- CNAME은 해당 컨텐츠가 kingCDN에 저장되어 있음을 나타낸다.

kingCDN의 권한 있는 DNS 서버로 요청 전달(request forwarded to KingCDN's authoritative DNS)
- Bob의 Local DNS 서버는 KingCDN의 권한 있는 DNS 서버로 요청을 전달한다.

KingCDN 서버의 IP 주소 반환(최종 IP 주소 확인,returns IP address of KingCDN server)
- KingCDN의 권한 있는 DNS 서버가 KingCDN 서버의 IP 주소를 반환한다.

kingCDN 서버에서 비디오 요청(컨텐츠 스트리밍, request video from KingCDN server)
- Bob은 KingCDN 서버로부터 HTTP를 통해 비디오를 요청하고 스트리밍을 시작한다.

Case study: Netflix

Netflix 계정 관리(Bob manages Netflix account)
- Bob은 Netflix 등록 및 계정 서버를 통해 자신의 계정을 관리한다.

Netflix 비디오 탐색(Bob browses Netflix video)
- Bob은 Netflix 웹사이트나 앱을 통해 원하는 비디오를 탐색한다.

매니페스트 파일 요청 및 반환(Manifest file, requested returned for specific video)
- Bob이 특정 비디오를 선택하면, 매니페스트 파일 요청되는 반환된다.
- 매니페스트 파일에는 비디오의 여러 버전에 대한 정보와 해당 파일들이 저장된 위치(CDN 서버)가 포함되어 있다.

DASH 서버 선택 및 스트리밍 시작(DASH server selected, contacted, streaming begins)
- DASH 서버가 선택되고 연결되며, 스트리밍이 시작된다
- Bob의 기기는 네트워크 상태에 따라 최적의 비디오 품질을 선택하여 스트리밍을 시작한다.

Amazon 클라우드(Amazon cloud)
- 비디오의 여러 버전이 Amazon 클라우드에 업로드되고, 이 버전들이 CDN 서버에 복사된다.
CDN servers
- 여러 CDN 서버에 비디오 복사본이 저장되어 있어, 사용자에게 가장 가까운 서버에서 비디오를 제공할 수 있다.
- 이를 통해 네트워크 지연을 최소화하고 스트리밍 성능을 최적화한다.

Socket programming with UDP and TCP

Socket programming

목표: 소켓을 사용하여 통신하는 클라이언트/서버 어플리케이션을 구축하는 방법을 배우는 것
Socket: 어플리케이션 프로세스와 end-end trasport protocol 사이의 문 역할

Socket Programming

두 가지 소켓 유형(Two Socket Types)

UDP(User Datagram Protocol)
- 특징: 신뢰할 수 없는 데이터그램 전송
- 설명: 데이터그램을 전송할 때 신뢰성, 순서 보장 및 흐름 제어가 제공되지 않는다. 즉, 데이터가 손실되거나 순서가 뒤바뀔 수 있다
- 용도: 실시간 어플리케이션(e.g. 비디오 스트리밍, 온라인 게임)에서 주로 사용된다.

TCP(Transmission Control Protocol)
- 특징: 신뢰할 수 있는 바이트 스트림 지향 전송(reliable, byte stream-oriented)
- 설명: 데이터 전송의 신뢰성, 순서 보장 및 흐름 제어를 제공한다. 데이터가 올바른 순서로 도착하고 손실되지 않도록 보장
- 용도: 파일 전송, 이메일, 웹 브라우징 등에서 주로 사용된다.

어플리케이션 예제(Application Example)

클라이언트가 키보드로부터 데이터 읽기: 클라이언트는 키보드에서 문자열 데이터를 읽어 서버로 전송한다.

서버가 데이터를 수신하고 대문자로 변환: 서버는 클라이언트로부터 데이터를 수신한 후, 해당 문자열을 대문자로 변환

서버가 수정된 데이터를 클라이언트로 전송: 서버는 수정된 데이터를 클라이언트로 다시 전송한다.

클라이언트가 수정된 데이터를 수신하고 화면에 표시: 클라이언트는 수정된 데이터를 수신하여 화면에 표시

Socket programming with UDP

Features of UDP

연결 없음(No Connection)
- 클라이언트와 서버 간의 "연결"이 없음(No "connection" between client & server)
  - 데이터 전송 전에 연결을 설정하지 않는다.
  - handshaking 과정이 없다. : 데이터를 전송하기 전에 연결을 설정하거나 확인하는 과정이 없다.

데이터 전송 방법(Data Transmission Method)
- Sender
  - 각 패킷에 명시적으로 IP 목적지 주소와 포트 번호를 첨부한다.
  - IP 목적지 주소와 포트 번호 첨부
- Receiver
  - 수신한 패킷에서 보낸 쪽의 IP 주소와 포트 번호를 추출한다.

데이터 전송의 신뢰성(Reliability of Data Transmission)
- 전송된 데이터는 손실되거나 순서가 뒤바뀔 수 있다.
  - 데이터가 전송되는 동안 손실되거나 순서가 뒤바뀔 수 있다.
  - UDP는 신뢰성, 순서 보장, 흐름 제어 등의 기능을 제공하지 않는다.

어플리케이션 관점(Application Viewpoint)

UDP는 신뢰할 수 없는 데이터그램 전송을 제공(UDP provides unreliable transfer of groups of bytes "datagrams")
- UDP는 클라이언트와 서버 간에 바이트 그룹("datagram")을 신뢰할 수 없는 방식을 전송
- 데이터가 손실되거나 순서가 뒤바뀔 수 있지만, 이로 인해 실시간 애플리케이션에서는 높은 성능을 제공할 수 있다.

Client/Server Socket interaction: UDP

서버 측 과정(Server Side Process)

소켓 생성(Create Socket)
- 서버 소켓 생성: 'serverSocket = socket(AF_INET, SOCK_DGRAM)'
  - AF_INET: IPv4 인터넷 프로토콜 사용
  - SOCK_DGRAM: 데이터그램 소켓(UDP)을 사용
데이터그램 수신(Read Datagram)
- 데이터그램을 서버 소켓에서 읽기:'read datagram from serverSocket'
  - 클라이언트가 보낸 데이터그램을 수신한다.

3. **응답 작성 및 전송(Write Reply)** - 클라이언트 주소와 포트 번호를 지정하여 응답 작성: 'write reply to **serverSocket** specifying client address, port number' - 클라이언트로 응답을 전송한다.

클라이언트 측 과정(Client Side Process)

소켓 생성(Create Socket)
- 클라이언트 소켓 생성: clientSocket = socket(AF_INET, SOCK_DGRAM)
  - AF_INET: IPv4 인터넷 프로토콜 사용
  - SOCK_DGRAM: 데이터그램 소켓(UDP)을 사용
데이터그램 생성 및 전송(Create and Send Datagram)
- 서버 IP와 포트 번호로 데이터그램 생성 후 전송: 'Create Datagram with server IP and prot=x; send datagram via clientSocket'
  - 서버의 IP 주소와 포트 번호를 지정하여 데이터그램을 생성하고 전송
데이터그램 수신(Read Datagram)
- 클라이언트 소켓에서 데이터그램 읽기: 'Read Datagram from clientSocket'
  - 서버가 보낸 응답 데이터그램을 수신
소켓 닫기(Close Socket)
- 클라이언트 소켓 닫기: 'close clientSocket'
  - 데이터 통신이 완료되면 클라이언트 소켓을 닫는다.

Example App: UDP Client

Python UDP 클라이언트(Python UDP Client): Python을 사용하여 UDP 클라이언트를 구현하는 예제

소켓 라이브러리 포함(Include Python's socket library)
- 'from socket import *': python의 소켓 라이브러리를 포함

서버 이름 및 포트 번호 설정(Set Server Name and Port Number)
- 'serverName = hostname' : 서버의 호스트 이름을 설정
- 'serverPort = 12000' : 서버의 포트 번호를 설정

UDP 소켓 생성(Create UDP Socket)
- 'clientSocket = socket(AF_INET, SOCK_DGRAM)'
  - AF_INET: IPv4 인터넷 프로토콜을 사용
  - SOCK_DGRAM: UDP 소켓을 사용한다.

사용자 입력 받기(Get User Keyboard Input)
- 'message = raw_input('Input lowercase sentence:')
  - 사용자로부터 소문장 문장을 입력받습니다.

서버 이름과 포트를 메시지에 첨부하여 소켓에 전송(Attach Server Name and Port to Message and Send into Socket)
- 'clientSocket.sendto(message.encdoe(), (serverName, serverPort))'
  - 메시지를 UTF-8로 인코딩하고, 서버 이름과 포트 번호를 지정하여 소켓을 통해 전송
소켓에서 응답 문자 읽기(Read Reply Characters from Socket into String)
- 'modifiedMessage, serverAddress = clientSocket.recvfrom(2048)':
  - 서버로부터 수신된 응답 메시지를 읽고, 서버 주소를 받습니다.
  - 2048은 버퍼 크기를 의미한다.

수신된 문자열 출력 및 소켓 닫기(Print Out Received String and Close Socket)
- 'print modifiedMessage.decode()'
  - 수신된 메시지를 UTF-8로 디코딩하여 출력한다.
- clientSocket.close()
  - 클라이언트 소켓을 닫는다.

Example App: UDP Server

Python UDP Server

소켓 라이브러리 포함(Include Python's Socket Library)
- 'from socket import *': Python의 소켓 라이브러리를 포함한다.

서버 포트 번호 설정(Set Server Port Number)
- 'serverPort = 12000' : 서버가 사용할 포트 번호를 설정한다.

3. **UDP 소켓 생성(Create UDP Socket)** - 'serverSocket = socket(AF_INET, SOCK_DGRAM)' - 'AF_INET': IPv4 인터넷 프로토콜을 사용한다. - 'SOCK_DGRAM': UDP 소켓을 사용한다.

소켓을 로컬 포트 번호에 바인딩(Bind Socket to Local Port Number)
- 'serverSocket.bind(("", serverPort))'
  - 서버 소켓을 로컬 포트 번호(12000)에 바인딩한다.
  - 빈 문자열 '""'은 모든 네트워크 인터페이스에서 수신을 허용한다.

서버 준비 상태 출력(Print Server Ready Message)
- 'print("the server is ready to receive")'
  - 서버가 준비되었음을 알리는 메시지를 출력

무한 루프를 실행(Loop Forever)
- while True:
  - 서버는 무한 루프를 실행해서 계속해서 클라이언트의 요청을 처리한다.

UDP 소켓에서 메시지를 읽고 클라이언트 주소 얻기(Read from UDP Socket into Message, Getting Client's Address)
- 'message, clientAddress = serverSocket.recvfrom(2048)'
  - 클라이언트로부터 메시지를 수신하고, 클라이언트의 주소(IP와 포트 번호)를 얻는다.
  - 2048은 버퍼의 크기를 의미

메시지를 대문자로 변환(Convert Message to Uppercase)
- modifiedMessage = message.decode().upper()
  - 수신된 메시지를 UTF-8로 디코딩하고, 대문자로 변환

변환된 메시지를 클라이언트로 전송(Send Uppercase String Back to Client)
- 'serverSocket.sendto(modifiedMessage.encode(), clientAddress)'
  - 변환된 메시지를 UTF-8로 인코딩하여 클라이언트의 주소로 전송

Socket Programming with TCP

Client Must Contact Server(클라이언트가 서버에 연락해야함)

Server Process Must First Be Running(서버 프로세스가 먼저 실행 중이어야 함)
- 서버는 클라이언트의 연결 요청을 수락할 준비가 되어 있어야 한다.
Server Must Have Created Socket That Welcomes Client's Contact(서버가 클라이언트의 연락을 환영하는 소켓을 생성해야 함)
- 서버는 클라이언트의 요청을 수락할 수 있는 소켓을 생성해야 한다.

Client Contacts Server By(클라이언트가 서버에 연락하는 방법)

Creating TCP Socket(TCP 소켓 생성)
- 클라이언트는 서버 프로세스의 IP 주소와 포트 번호를 지정하여 TCP 소켓을 생성
When Client Creates Socket(클라이언트가 소켓을 생성할 때)
- 클라이언트의 TCP는 서버의 TCP와 연결을 설정한다.

When Contacted by Client(서버가 클라이언트로부터 연락을 받으면)

Server TCP Creates New Socket for Server Process to Communicate with Taht Particular Client(서버 TCP는 특정 클라이언트와 통신하기 위해 새로운 소켓을 생성함)
- 서버는 여러 클라이언트와 동시에 통신할 수 있도록 새로운 소켓을 생성
- Allows Server to Talk with Multiple Client(여러 클라이언트와 통신 가능)
- Source Port Numbers Used to Distinguish Clients(소스 포트 번호를 사용하여 클라이언트를 구분)
  - 각 클라이언트는 고유한 소스 포트 번호를 사용하여 구분된다.

어플리케이션 관점(Application Viewpoint)

TCP Provides Reliable, In-Order Byte-Stream Transfer(TCP는 신뢰할 수 있는 순차적 바이트 스트림 전송을 제공함)
- TCP는 클라이언트와 서버 간에 신뢰할 수 있고 순서가 보장된 바이트 스트림 전송을 제공
- 파이프 역할(Pipe): TCP 연결은 클라이언트와 서버 간의 파이프 역할을 한다.

Client/Server Socket Interaction: TCP

서버 측 과정

소켓 생성(Create Socket)
- 'serverSocket = socket()'
  - 서버는 수신 요청을 위해 포트 번호 'x'에 소켓을 생성
수신 연결 요청 대기(Wait for Incoming Connection Request)
- 'connectionSocket = serverSocket.accept()`
  - 서버는 클라이언트로부터 연결 요청을 기다린다.
  - 연결 요청이 오면, accept() method를 통해 새로운 소켓 'connectionSocket'을 생성하여 클라이언트와 통신을 시작
요청 읽기(Read Request)
- 'read request from connectionSocket'
  - 클라이언트로부터 요청을 'connectionSocket'을 통해 읽는다.
응답 작성 및 전송(Write Reply)
- 'write reply to connectionSocket'
  - 클라이언트에게 응답을 작성하여 connectionSocket을 통해 전송한다.
연결 소켓 닫기(Close Connection Socket)
- 'close connectionSocket'
  - 통신이 끝나면 connectionSocket을 닫는다.

클라이언트 측 과정(Client Side Process)

소켓 생성 및 연결(Create Socket and Connect)
- clientSocket = socket()
  - 클라이언트는 서버의 호스트 ID와 포트 번호 'x'에 연결하기 위해 소켓을 생성
- connect to hostid, port=x
  - 생성된 소켓을 서버의 호스트 ID와 포트 번호에 연결한다.
요청 전송(Send Request)
- send request using clientSocket
  - 클라이언트는 clientSocket을 사용하여 서버에 요청을 전송한다.
응답 수신(Read Reply)
- read reply from clientSocket
  - 서버로부터 응답을 clientSocket을 통해 수신한다.
클라이언트 소켓 닫기(Close Client Socket)
- close clientSocket
  - 통신이 끝나면 clientSocket을 닫는다.

Example app: TCP client

소켓 라이브러리 포함
- from socket import *
  - Python의 소켓 라이브러리를 포함한다.
서버 이름 및 포트 번호 설정
- serverName = 'servername'
  - 서버의 호스트 이름을 설정
- serverPort = 12000
  - 서버의 포트 번호를 설정
TCP 소켓 생성
- clientSocket = socket(AF_INET, SOCK_STREAM)
  - AF_INET: IPv4 인터넷 프로토콜을 사용
  - SOCK_STREAM: TCP 소켓을 사용한다.
서버에 연결
- clientSocket.connect((serverName, serverPort))
  - 서버의 호스트 이름과 포트번호를 지정하여 TCP 연결을 설정한다.
사용자 입력 받기
- sentence = raw_input('Input lowercase sentence')
  - 사용자로부터 소문자 문장을 입력받는다.
메시지 전송
- clientSocket.send(sentence.encode())
  - 입력된 문장을 UTF-8로 인코딩하여 서버로 전송한다.
응답 수신
- modifiedSentence = clientSocket.recv(1024)
  - 서버로부터 응답을 수신합니다.
  - 1024는 버퍼 크기를 의미한다.
응답 출력 및 소켓 닫기
- print('From Server: ', modifiedSentence.decode())
  - 서버로부터 수신한 응답을 UTF-8로 디코딩하여 출력합니다.
- clientSocket.close()
  - 클라이언트 소켓을 닫는다.

Example app: TCP server

serverSocket.bind(('', serverPort))
- 서버 소켓을 지정된 포트 번호에 바인딩한다.
- 빈 문자열 '""'은 모든 네트워크 인터페이스에서 수신을 허용한다.
serverSocket.listen(1)
- 서버는 들어오는 연결 요청을 대기한다.
- '1'은 대기열의 최대 연결 수를 설정한다.

Chapter 2: Summary

important Themes

중앙 집중식 vs 분산형
- 중앙 집중식: 하나의 중앙 서버가 모든 클라이언트 요청을 처리
- 분산형: 여러 서버가 요청을 분산 처리
무상태 vs 상태 유지
- 무상태: 각 요청이 독립적이며, 서버는 이전 요청의 상태를 유지하지 않음
- 상태 유지: 서버가 이전 요청의 상태를 유지하여 연속적인 요청을 처리
확장성
- 시스템이 증가하는 요청을 처리할 수 있는 능력
- 시스템의 성능을 저하시키지 않으면서 더 많은 클라이언트와 데이터를 처리할 수 있어야 함
신뢰성 vs 비신뢰성 메시지 전송
- 신뢰성: 데이터가 손실되지 않고, 순서대로 정확하게 전달됨
- 비신뢰성: 데이터 손실 가능성, 순서 보장 없음
네트워크 엣지의 복잡성
- 네트워크 말단 장치들이 더 많은 처리와 기능을 수행하게 되는 경향

'학교수업 > 컴퓨터망' 카테고리의 다른 글

Chapter4: Network Layer-Data Plane (0)	2024.07.04
Chapter3: Transport Layer-2 (0)	2024.07.04
Chapter3: Transport Layer (0)	2024.07.03
Chapter2: Application Layer (0)	2024.07.01
Chapter1: Introduction (0)	2024.06.30

흰제비갈매기

Chapter2: Application Layer-2

SMTP: closing observations

Mail message format

Mail Access Protocols

The Domain Name System DNS

DNS: Domain Name System

DNS: services, structure

Thinking about the DNS

DNS: a distributed, hierarchical database

DNS: root name servers

Top-Level Domain, and Authoritative Servers

Local DNS name servers

DNS name resolution: iterated query

DNS name resolution: recurisve query

Caching, Updating DNS Records

DNS records

DNS protocol messages

Inserting records into DNS

DNS Security

P2P application

Peer-to-peer(P2P) architecture

File distribution: client-server vs P2P

File distribution time: client-server

File distribution time: P2P

Client-server vs P2P: example

P2P file distribution: BitTorrent

P2P file distribution: BitTorrent

BitTorrent:requesting, sending file chuncks

BitTorrent: tit-for-tat

Video Streaming and content distribution networks

Video Streaming and CDNs:context(Content Delivery Network)

Multimedia: video

Streaming stored video

Streaming stored video: challenges

Streaming stored video: playout buffering

Streaming multimedia: DASH

Content distribution networks(CDNs)

CDN content access: a closer look

Case study: Netflix

Socket programming with UDP and TCP

Socket programming

Socket Programming

Socket programming with UDP

Client/Server Socket interaction: UDP

Example App: UDP Client

Example App: UDP Server

Socket Programming with TCP

Client/Server Socket Interaction: TCP

Example app: TCP client

Example app: TCP server

Chapter 2: Summary

'학교수업 > 컴퓨터망' 카테고리의 다른 글

+ Recent posts

티스토리툴바