기초컴퓨터네트워크 08 (P2P, CDN, Video Streaming)

TonyHan·2021년 3월 30일

네트워크

21) 기초컴퓨터네트워크

목록 보기

8/30

=== P2P applications ===

1. Pure P2P architecture

지금까지는 클라이언트-서버 방식이다. 이번에는 P2P 방식의 구조를 보자

순수한 P2P는 서버가 어떠한 개입도 하지 않는다.
end systems 간 직접통신한다.
peer은 가끔 켜지고, IP 가 자주 바뀐다.
example
- file distribution (BitTorrent)
- streaming (KanKan)
- Volp (Skype)

(요약)

순수한 P2P는 서버가 어떠한 개입도 하지 않는다.
end systems 간 직접통신한다.
peer은 가끔 연결되고, IP 가 자주 바뀐다.

File dirstribution: client-server vs. P2P

size F인 파일을 N개의 peer로 distribute하는 상황이라고 하자

네트워크에서는 충분한 대역폭이 있어서 buttleneck이 걸리지 않고 오로지 접근하는 부분에서 buttleneck이 걸린다고 하자

그래서 서버에 있는 파일이 네트워크로 업로드 될때 Us는 서버에서 네트워크로 보내는 전송 속도이다. di는 다운로드 전송 속도이다. 그렇다면 Us나 di중 더 전송속도가 느린쪽이 전체 파일다운받는데의 속돌르 결정한다.

(요약)
이거 계산하는 문제 나옴

File distribution time: client-server

server transmission : 클라이언트 - 서버 모델에서 파일을 N개의 클라이언트로 보내는 시간 계산
- time to send one copy: F / us
- time to send N copies: (N * F) / us 서버는 client를 위해 네트워크로 N번 파일을 전송해주어야 한다.
client : 각 클라이언트는 복사된 파일을 받아야 한다.
- dmin = 가장 속도가 다운로드 속도가 느린 컴퓨터
- max client download time: F / dmin

client-server model에서 속도는 둘중에 시간이 더 많이 걸리는 쪽이 buttleneck이기 때문에 전체에 파일을 보내는 시간을 결정할 수 있다. 추가적으로 NF/us는 N의 갯수가 증가할 수록 결국에는 걸리는 시간이 될 것이다.

(요약)
서버가 각각의 클라이언트들에게 각각 데이터를 보내야한다.

time to send one copy: F / us
time to send N copies: (N * F)

dmin = 가장 속도가 다운로드 속도가 느린 컴퓨터
max client download time: F / dmin

그래서 cliend-server간의 다운로드 시간은 두개의 성분중 더 큰 값보다 크다.

N에 따라서 선형적으로 증가

File distribution time: P2P

파일을 가지고 있는 피어가 네트워크로 파일을 보내야 한다.
- time to send one copy: F / us
클라이언트
- max client download time: F / dmin 가장 다운로드 속도가 느린컴퓨터를 기준으로 계산가능
clients : 파일을 한 번 보내고 나면 다른 클라이언트의 bandwidth도 이용가능하다.

유일한 차이점은 세번째의 모든 클라이언트들의 업로드 속도도 함께 고려해주어야 한다.
이 중 가장 큰 것이 bottleneck이다. 분자도 크지만 분모도 클라이언트가 증가함에 따라 지연시간이 linear하지 않게 증가한다.

(요약)

최소 하나의 copy만 업로드하면 되기 때문에 F/us로 계산 가능하다

Client-server vs. P2P: example

위와 같이 P2P는 클라이언트가 증가하더라도 속도가 안정적이다. 대신에 보안에 취약하다.

P2P file distribution: BitTorrent

BitTorrent는 256KB의 chunk들로 파일이 나뉘어진다.
그래서 peer들은 file chunk를 주거니 받거니한다.

torrent : 시스템에 접속해서 파일을 주고받는 피어들을 torrent라고 부른다.
tracker : 약간의 서버와 같은 역활로, 파일이 어떤 peer에서 distribution에 참여하고 있는지 알려준다.

P2P file distribution: BitTorrent

torrent에 참가하는 peer

처음에는 chunk가 없지만 파일 chunk들이 점차 쌓이게 된다.
자신도 tracker에 등록하게 된다. 같은 torrent에 참가하고 있는 peer들(neighbors)에게 connection을 맺어 파일을 다운받게 된다.
다운로드 받고 있는 동안에, peer은 chunk를 다른 피어들에게 업로드
다운로드 받다가 peer을 바꿀수도 있다.
churn : 피어가 계속 바뀌는 상태
다운로드를 다 받으면 peer이 떠나거나 토렌트에 계속 남을 수도 있다.

BitTorrent: requesting, sending file chunks

chunk를 보내달라고 요청
- peer 마다 다른 chunk를 가지고 있을 수 있다.
- 주기적으로 자신에게 없는 chunk의 리스트를 다른 peer들에게 물어본다.
- 이때 파일의 희귀한 부분을 우선적으로 요청을 보낸다.
chunks 보내기: tit-for-tat
- 나에게 데이터를 가장 많이 준, 가장 빠른 속도로 준 사람 4명을 선택해서 보내준다.
  - 다른 peer들에게는 chunk를 보내지 않음 (do not receive chunks from her)
  - re-evaluate top 4 every 10 seconds : 10초에 한 번씩 peer 변경
- 30초 마다 랜덤하게 peer을 선택, starts sending chunks
  - "optimistically unchoke" this peer
  - newly chosen peer may join top 4

(요약)
request chunk에서 보면

서로 다른 피어들은 파일의 다른 청크들을 가지고 있다.
피어들한테 청크 리스트를 요청하고 다운로드할 수 있게 요청

sending chunks : tit-for-tat

자신에게 가장 높은 속도 4명에게 청크보냄
내가 다른 놈들에게 보내는 것을 끊을 수도 있다
매 30초마다 랜덤하게 피어를 뽑는다. 4명이 아닌 다른 거. 그러면 걔한테 얼마의 속도로 보내는지 확인해서 top4업데이트

BitTorrent: tit-for-tat

처음에는 각자의 torrent간에만 통신

그러다 중간에 Alice가 그냥 랜덤하게 Bob에게 보낸다.
그랬더니 속도가 보다 빠르면 top4 안에 Bob이 추가되고
Bob도 Alice를 top4에 포함한다.

즉 계속해서 더 나은 파트너를 찾는다. 그래서 파일을 더 빠르게 받을 수 있도록 노력한다.

=== video streaming and content distribution networks ===

1. Video Streaming and CDNs: context

가장 많은 트래픽은 동영상 트래픽이 제일 많다.

single meag-video server로는 이를 감당할 수 없다.
heterogeneity : 동영상을 보는 사람들이 bandwidth(전송속도)가 모두 다르다.

분산 + application-level에서 조직화로 이 문제를 해결하고 이다. (content distribution networks)

Multimedia: video

video : image의 sequence이다.
digital image : arra of pixels

예를들어 720x480 픽셀에 각 픽셀마다 bit가 정해져 있다.
coding: redundancy(감쇄)를 사용
- spatial (within image) : 프레임의 같은 부분에 대한 정보를 줄이기
- temporal (from one image to next) : 프레임사이의 달라지지 않은 부분 압축
  이를 처리한 것이 코덱이다.
CBR(constrant bit rate) : encoding(압축) rate가 고정됨, 처음부터 끝까지 1MBp/s로 인코딩
VBR(variable bit rate) : video encoding rate를 변화, 특정파트는 bit rate가 낮고/높고

(요약)
여러가지 데이터 압축기술이 존재하는데 그냥 그렇구나하고 넘기면 된다.

프레임과 프레임 사이에 바뀐 데이터가 없으면 프레임 차이값만 보내주어서 데이터 복원하기

비디오가 크게 두가지로 나뉨. 화면에 따라서 압축률이 달라짐.

CBR(constrant bit rate) : encoding(압축) rate가 고정됨, 처음부터 끝까지 1MBp/s로 인코딩
VBR(variable bit rate) : video encoding rate를 변화, 특정파트는 bit rate가 낮고/높고

Streaming stored video

만약 비디오를 스트리밍한다면

Streaming multimedia: DASH

DASH: Dynamic, Adaptive Streaming over HTTP : HTTP를 사용하여 multimedia 출력
server
– divides video file into multiple chunks : 하나의 비디오를 chunk로 분리
– each chunk stored, encoded at different rates : 각 chunk를 저장하고 다른 비율로 encoding
– manifest file(관리하기 위한 파일): provides URLs for different chunks(chunk의 위치를 저장하고 있는 파일 서버에 저장)
client
- periodically measures server-to-client bandwidth : 주기적으로 서버와 클라이언트의 bandwidth를 계산
- consulting manifest, requests one chunk at a time
  - chooses maximum coding rate sustainable given current bandwidth
  - can choose different coding rates at different : 시간과 상황에 따라서 coding 비율이 다른 chunk를 받아올 수 있다. (depending on available bandwidth at time)

"intelligence" at client: client determines client가 언제 어떤 청크를 request할지를 결정한다.
- when to request chunk (so that buffer starvation or overflow does not occur)
- what encoding rate to request (higher quality when more bandwidth
  available) 요청할때 encoding 비율도 결정
- where to request chunk (can request from URL server that is "close" to client or has high available bandwidth) 어디에서 chunk를 받을지도 결정

(요약)

DASH: Dynamic, Adaptive Streaming over HTTP : HTTP를 사용하여 multimedia 출력 -> 사실상 TCP
server
– 하나의 비디오를 chunk로 분리
– 각 chunk를 저장하고 다른 비율로 encoding
– manifest file(관리하기 위한 파일): chunk의 위치를(URL) 저장하고 있는 파일 서버에 저장
client
- 주기적으로 서버와 클라이언트의 bandwidth를 계산
- consulting manifest, requests one chunk at a time
  - 시간과 상황에 따라서 coding 비율이 다른 chunk를 받아올 수 있다. (depending on available bandwidth at time)
"intelligence" at client:client가 언제 어떤 청크를 request할지를 결정한다.
- 언제 청크를 받아올지
- 요청할때 encoding 비율도 결정
- 어디에서 chunk를 받을지도 결정

Content distribution networks

challenge: how to stream content (selected from millions of
videos) to hundreds of thousands of simultaneous users?
option 1: single, large "mega-server" 메가서버를 써서 스트리밍
- 서버가 고장나면 답없음
- point of network congestion 특정 지점의 네트워크 혼잡
- long path to distant clients 먼거리에 있는 사용자가 사용 불가
- multiple copies of video sent over outgoing link 같은 영상이 계속 복사될 수 이음
option 2: store/serve multiple copies of videos at multiple geographically distributed sites (CDN) 영상 분산처리
- enter deep: push CDN servers deep into many access networks 유저들에게 가깝게 CDN서버를 기업에 두는 방법
  - close to users
  - used by Akamai, 1700 locations
- bring home: smaller number (10's) of larger clusters in POPs near (but not within) access networks : access망 밖에 두어서 갯수는 적지만 매우 크게 만드는 방법
  - used by Limelight

(요약)

option 2: store/serve multiple copies of videos at multiple geographically distributed sites (CDN) 영상 분산처리
- enter deep: 유저들에게 가깝게 CDN서버를 기업에 두는 방법
- bring home: POPs(라우터가 모여있는 point of peers) near (but not within) access networks : access망 밖에 두어서 갯수는 적지만 매우 크게 만드는 방법

Content distribution networks (CDNs)

NETFLIX 서버에 chunk 위치를 물어봄
최대한 가까운쪽에서 manifest file을 받을려고 함
만약에 해당 network path에 혼잡이 발생시 다른 네트워크에서 받아옴

CDN content access: a closer look

CDN용 회사가 따로 존재

Bob (client) requests video http://netcinema.com/6Y7B23V
- video stored in CDN at http://KingCDN.com/NetC6y&B23V

밥이 영상을 보기 위해 netcinema에서 영상을 선택
url을 가져오기 위해 local DNS server에 물어봄
DNS server은 authoritative DNS를 알려주고 CDN주소를 알려줌
local DNS는 KingCDN쪽 authoritatie DNS에 질문하고 아까 받은 CDN 주소를 물어봄
local DNS에서 사용자에게 CDN 위치를 알려줌
사용자는 CDN 위치를 알아내어서 연결

Case study: Netflix

넷플릭스 계정 관리
아마존 클라우드에서 넷플릭스 비디오 선택
아마존 서버에서 Manifest file을 반환
CDN으로부터 영상을 DASH한다.

Chapter 2: Summary

application architectures
- client-server
- P2P
application service requirements
- reliability, bandwidth (throughput), delay
  바로 아래쪽 transport에서 위의 것들을 지원
Internet transport service model
- connection-oriented and reliable: TCP
- unreliable, datagrams: UDP
specific protocols
- HTTP
- SMTP, POP, IMAP
- DNS
- P2P: BitTorrent
video streaming, CDNs
protocols
- typical request/reply message exchange 한쪽에서 요청하고 응답하는 형태
  - client requests info or service
  - server responds with data, status code
- message formats
  - headers: fields giving info about data : 데이터에 대한 정보
  - data: info (payload) being communicated
important themes
- control vs. messages : 같은 호스트 내에서는 메세지를 안써도 됨, 서로 다른 노드들간에는 메세지를 사용
  - in-band, out-of-band
centralized vs. decentralized : 시스템 구성
stateless vs. stateful : 어떤 protocol이 기존 사용자 정보를 기억할지 안할지지
reliable vs. unreliable message transfer : TCP와 UDP 차이
"complexity" at network "edge" : 중요한 기능을 edge에서 서비스 해줄 수 있도록(DNS)

TonyHan

신촌거지출신개발자(시리즈 부분에 목차가 나옵니다.)

이전 포스트

기초컴퓨터네트워크 07 (electronic mail - SMTP, POP3, IMAP)

다음 포스트

기초컴퓨터네트워크 08 (P2P, CDN, Video Streaming)

21) 기초컴퓨터네트워크

=== P2P applications ===

1. Pure P2P architecture

File dirstribution: 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 chunks

BitTorrent: tit-for-tat

=== video streaming and content distribution networks ===

1. Video Streaming and CDNs: context

Multimedia: video

Streaming stored video

Streaming multimedia: DASH

Content distribution networks

Content distribution networks (CDNs)

CDN content access: a closer look

Case study: Netflix

Chapter 2: Summary

기초컴퓨터네트워크 07 (electronic mail - SMTP, POP3, IMAP)

기초컴퓨터네트워크 09 (ch. 3 : Transport Layer - TCP, UDP)

0개의 댓글