Hi there!

I am a student studying computer science.

컴퓨터 네트워크

컴퓨터 네트워크 Week 7-1 : P2P application

만능성구 2020. 10. 13. 23:28
728x90

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

728x90