Peer-to-peer (P2P) architecture
▪ 상시 가동 서버 없음
▪ 임의의 최종 시스템이 직접 통신 # application layer 통신
# network layer를 통하면 여러 곳을 거쳐간다
▪ peer는 다른 peer에게 service를 요청하고 다른 peer에게 service를 제공합니다.
• 자체 확장성 – 새로운 peer는 새로운 service 용량과 새로운 service 요구 를 가져옵니다.
# 더 많은 용량을 가진다는 것은 더 많은 리소스를 얻는다는 것
# 더 많은 service를 제공하는 것이 아니라 성능은 저하되잠 지능적인 프로토콜이 있다--> 안정성
▪ peer가 간헐적으로 연결되고 IP 주소 변경
• 복잡한 관리 # peer가 한번 연결되면 p2p 네트워크에 그대로 유지 아무때나 떠날 수 있다. 아주 동적이다
▪ 예 : P2P 파일 공유 (BitTorrent), 스트리밍 (KanKan), VoIP (Skype)
File distribution: client-server vs P2P
Q : 하나의 server에서 N개의 peer로 파일 (크기 F)을 배포하는 데 얼마나 많은 시간이 소요됩니까?
• peer upload / download 용량은 제한된 리소스입니다.
File distribution time: client-server
▪ server transmission : N 개의 파일 사본을 순차적으로 전송 (upload)해야합니다.
• 1개 사본 발송 시간 : F / us # peer가 없다
• N 개의 사본을 보내는 시간 : NF / us
▪ client: 각 클라이언트는 파일 사본을 다운로드해야합니다.
• d_min = 최소 client 다운로드 속도 # 모든 client는 자체 다운 링크를 가짐
• 최소 client다운로드 시간 : F / dmin
u가 크면 f/d_min이 최소 배포 시간, d가 크면 NF/u_s, N이 크면 NF/u_s
File distribution time: P2P
▪ server transmission : 최소한 하나의 사본을 업로드해야합니다.
• 1개 사본 발송 시간 : F / us # 하나만 보내면 된다
▪ client : 각 client는 파일 사본을 다운로드해야합니다.
• 최소 client 다운로드 시간 : F / dmin
▪ clients : 집합체로 NF bits를 다운로드해야 함
• 최대 업로드 속도 (최대 다운로드 속도 제한)는 u_s + Sum(u_i)입니다.
# 개별적인 비트보다는 파일의 chunk가 재분배된다
peer는 소비자이자 재분자이다
최소 분배시간 D가 항상 P2P가 작은 것 은 아니다
Client-server vs. P2P: example
P2P file distribution: BitTorrent
▪ 256Kb chunk로 분할된 파일
▪ torrent 전송 / 수신 파일 chunk의 peer
▪ peer joining torrent :
• chunk가 없지만 시간이 지남에 따라 다른 peer로부터 추적됩니다.
• tracker에 등록하여 peer 목록을 가져오고 peer 하위 집합 ( "이웃")에 연결
# 50 peer 정보를 받고 50 peer에게 TCP연결을 설정한다. 연결된 peer가 이웃 peer이다.
▪ 다운로드하는 동안 peer는 다른 peer에 chunk를 업로드합니다.
▪ peer는 chunk를 교환하는 peer를 변경할 수 있습니다.
▪ churn : peer가 왔다가 갈 수 있음
▪ peer가 전체 파일을 갖게되면 (이기적으로) 떠나거나 (이타적으로) torrent에 남아있을 수 있습니다.
일부 chunk만을 가진 채로 torrent를 떠날 수 있다
tracker에 자신을 등록하고 주기적으로 자신이 아직 torrent에 있음을 알린다
BitTorrent: requesting, sending file chunks
Requesting chunks:
▪ 주어진 시간에 서로 다른 peer가 서로 다른 파일 chunk 하위 집합을 가짐
▪ 정기적으로 Alice는 각 peer에게 보유한 chunk 목록을 요청합니다.
▪ Alice가 peer에서 누락된 chunk를 요청합니다.
# 가장 드문것을 먼저 요청한다. 빨리 받고 다시 퍼트리려고
Sending chunks: tit-for-tat
▪ Alice는 현재 자신의 chunk를 가장 높은 속도로 보내는 4명의 peer에게 chunk를 보냅니다.
• 다른 peer는 Alice에 의해 질식됩니다 (그녀로부터 chunk를 받지 않음).
• 10 초마다 상위 4개 재평가
▪ 30초마다 : 무작위로 다른 peer를 선택하고 chunk 전송을 시작합니다.
•이 peer를 "낙관적으로 시작"
• 새로 선택한 peer가 상위 4위에 합류 할 수 있습니다.
BitTorrent: tit-for-tat
(1) Alice스는“낙천적으로 활성화” Bob
(2) Alice는 Bob의 상위 4개 providers 중 하나가 되었습니다. 밥 화답[응답]reciprocates
(3) Bob이 Alice의 상위 4개 providers 중 하나가 되었습니다.
Video Streaming and CDNs: context
▪ stream video traffic : 인터넷 대역폭의 주요 소비자
• Netflix, YouTube, Amazon Prime : 가정용 ISP 트래픽의 80 % (2020 년)
▪ challenge : 규모-최대 10억명의 사용자에게 도달하는 방법은 무엇입니까?
• single mega-video server가 작동하지 않음 (왜?)
# 엄청난 양의 사용자를 처리해야한다 확장 가능하지 않다 그래서 하나의 서버로 불가능하다
▪ challenge : heterogeneity이질성
▪ 사용자마다 기능이 다릅니다 (예 : 유선과 모바일, 풍부한 대역폭과 낮은 대역폭)
▪ solution: 분산된 애플리케이션 수준 인프라
다 적은 대역폭을 필요하는 인코딩 방식
Multimedia: video
▪ video: 일정한 속도로 표시되는 일련의 이미지
• 예 : 초당 24 개 이미지
▪ digital image : pixels 배열
• 비트로 표시되는 각 pixels
▪ coding : 이미지 내부와 이미지 사이에 중복성을 사용하여 이미지 encoding에 사용되는 bit 수를 줄입니다.
• 공간 (이미지 내)
• 시간 (한 이미지에서 다음 이미지로)
▪ CBR : (일정 bit rate) : 비디오 encoding 속도 고정 # 이미지 품질을 지키고 저장 공간을 절약
▪ VBR : (가변 bit rate) : 공간적, 시간적 코딩의 양이 변경됨에 따라 비디오 encoding 속도가 변경됨
# 비디오의 변화가 많은 경우 사용, 데이터 속도, bit rate의 상하한을 제한, frame변화에 따라 동적으로 변화
고품질 동영상을 볼 수 있다
▪ 예 :
• MPEG 1 (CD-ROM) 1.5Mbps
• MPEG2 (DVD) 3 ~ 6Mbps
• MPEG4 (인터넷에서 자주 사용됨, 64Kbps – 12Mbps)
Streaming stored video
Main challenges :
▪ server-client 대역폭은 네트워크 정체 수준 (사내, in access network, in network core, at video server)의 변화에 따라 시간이 지남에 따라 달라집니다.
▪ congestoin로 인한 packet loss 및 delay로 인해 재생이 지연되거나 비디오 품질이 저하됩니다.
Streaming stored video
Streaming stored video: challenges
▪ 연속 재생 제약 : client 재생이 시작되면 재생이 원래 타이밍과 일치해야합니다.
•… 그러나 네트워크 지연은 가변적 (지터)이므로 재생 요구 사항에 맞게 client 측 buffer가 필요합니다.
▪ 기타 과제 :
• client 상호 작용 : 일시 중지, 빨리 감기, 되감기, 비디오 건너 뛰기
• 비디오 패킷이 손실되거나 재전송 될 수 있습니다.
Streaming stored video: playout buffering
▪ client측 buffering 및 재생 지연 : 네트워크 추가 지연, 지연 jitter 보상compensate
# 문제:
모든 client들이 가용 대역폭이 다르다, 같은 client도 시간에 따라 다르다 그런데 똑같이 인코딩된 비디오를 전송받음
Streaming multimedia: DASH
▪ DASH: Dynamic, Adaptive Streaming over HTTP
▪ server:
• 비디오 파일을 여러 chunk로 분할
• 각 chunk저장, 서로 다른 속도로 encoding
• manifest file : 다른 chunk에 대한 URL을 제공합니다.
▪ client:
• 주기적으로 server-client 대역폭 측정
• consulting manifest, 한 번에 한 chunk요청
• 현재 대역폭에서 지속 가능한 최대 코딩 속도를 선택합니다.
• 다른 시점에서 다른 코딩 속도를 선택할 수 있습니다 (시간에 사용 가능한 대역폭에 따라 다름).
▪ client의 "intelligence": client가 결정
• chunk 요청시기 (버퍼 부족 또는 오버플로가 발생하지 않도록)
• 요청할 encoding 속도 (대역폭이 더 많을 때 더 높은 품질)
• chunk 요청 위치 (client에 "close"있거나 사용 가능한 대역폭이 높은 URL server에서 요청할 수 있음)
# client가 encoding조건(bit rate)을 선택한다
충분한 분량의 buffering video를 가지고 있고 측정된 수신 대역폭이 크다 --> 높은 품질의 video packet
적은 분량의 buffering video를 가지고 있고 측정된 수신 대역폭이 작다 --> 낮은 품질의 video packet
manifest file을 이용해서 URL과 byte-range를 지정하여 요청
streaming video = encoding + DASH + playout buffering
'컴퓨터 네트워크' 카테고리의 다른 글
컴퓨터 네트워크 Week 9-1: Transport Layer (0) | 2020.11.03 |
---|---|
컴퓨터 네트워크 Week 7-2: CDN (0) | 2020.10.17 |
컴퓨터 네트워크 Week 6-2 : Domain (0) | 2020.10.12 |
컴퓨터 네트워크 Week 6-1 : HTTP, E-mail (0) | 2020.10.12 |
컴퓨터 네트워크 Week 5-1 : (0) | 2020.10.04 |