목차
2.5 P2P 파일 분배 125
👩👩👧👧2.5 P2P 파일 분배
p2p
- 항상 켜져 있는 인프라스트럭처 서버에 최소한으로（혹은 전혀 안 함）의존
- 간헐적으로 연결되는
호스트 쌍들（피어)서로 직접 통신 - 피어는 서비스 제공자가 소유x -> 사용자가 제어하는 데스크톱과 랩톱，스마트폰이 소유
- 브람 코헨(Bram Cohen)이 개발
- 커다란 파일을 한 서버에서 다수의 호스트(피어)로 분배하는 P2P 애플리케이션 가정
- ㄴ 리눅스 운영체제의 새로운 버전, 기존 운영체제,애플리케이션을 위한 소프트웨어 패치（patch）, MP3 음악파일, MPEG 비디오 파일
- 각 피어는 수신한 파일의 임의의 부분을 다른 피어들에게
재분배-> 서버의 분배 프로세스를 도움.- <-> 클라이언트-서버의 파일 분배 : 서버는 파일 복사본을 각 피어들에게 보내야 함.
= 서버에게 커다란 부하를 주고 많은 양의 서버 대역폭을 소비
- <-> 클라이언트-서버의 파일 분배 : 서버는 파일 복사본을 각 피어들에게 보내야 함.
- p2p 구조의
자가 확장성
🎊 P2P 구조의 확장성
: F 사이즈의 파일을 한 서버로 부터 N개의 peer들이 파일의 복사본을 얻는 데 걸리는 시간(분배 시간)
- client-server VS P2P
가정
- us : 서버의 파일을 네트워크로 업로드하는 속도
- ui : i번째 피어의 네트워크로 업로드하는 속도
- di : i번째 피어의 네트워크로 다운로드하는 속도
- -> 전송속도가 더 낮은 쪽(bottleneck이 걸리는 쪽)이 파일을 다운받는 전송 속도를 결정
- F : 파일크기
- N : 파일의 복사본을 얻는 피어 수
client-server
- 서버의 파일 업로드 시간
- N개의 파일 복사본들을 N개의 피어 각각에게 전송 = NF bit
- 한 복사본당 서버에서 네트워크로 업로드 하는데 걸리는 시간 : F/us
- N 개의 복사본들을 보내기 위해 N번 업로드 하는데 걸리는 시간(파일 분배 시간) : NF/us
- 클라이언트의 파일 다운로드 시간
- 다운로드 속도가 가장 느린 곳이 전체 속도를 결정
- 최소 분배 시간 : F/dmin
- 전체시간 : max(파일 업로드 시간(NF/us), 파일 다운로드 시간(F/dmin))
- 클라이언트의 수 N에 따라 선형적으로 속도 증가
P2P
- 서버의 파일 업로드 시간
- 분배 처음에는 서버에만 파일이 존재 = 네트워크 상에는 파일이 없다.
- 파일이 피어 커뮤니티에 도달할 수 있도록, 적어도 한번은 서버에서 업로드를 해야 한다.
- ㄴ= 네트워크로 파일의 각 비트 보내기 = F/us
- 서버가 한번 보낸 비트는 서버가 다시 보낼 필요 없다.
- 피어들끼리 파일(비트)을 재분배하기 때문
- 클라이언트의 파일 다운로드 시간
- 모든 클라이언트들이 다운받아야 하므로 가장 다운속도가 느린곳에 의해 결정
- 최소 분배 시간 : F/dmin
- 시스템의 전체 파일의 업로드 용량
- 한번 파일을 다운로드 한 후로는 클라이언트가 서버 역할 가능
- 한 파일 전체 다운로드할 필요 x -> 어느 정도(chunk) 다운로드 하면 전달 가능
- 전체 업로드 속도 = 원래 서버의 업로드 속도 + 각 피어의 업로드 속도
- N개의 피어 모두 파일을 다운받아야 하므로 총 필요한 비트 수는 NF 비트
- = NF/(전체 업로드 속도 = 서버 업로드 속도 + 각 피어의 업로드 속도)
- 전체 시간 : max(서버의 파일 업로드 시간, 클라이언트의 파일 다운로드 시간, 시스템 전체 파일의 업로드 시간)
- 클라이언트의 수 N이 커짐 = 업로드 해주는 클라이언트도 커짐 -> 선형시간증가x 낮은 속도로 증가한다. -> 자가확장성
- 클라이언트가 많을수록 효율적
- 안정성 문제 : client-server에서 서버는 24시간 열려 있지만, P2P의 경우 파일을 제공하는 피어들이 꺼져 있으면 파일을 다운받지 못한다.
BitTorrent
- 파일 분배를 위한 인기 있는 P2P 프로토콜
토렌트(torrent): 파일을 주고받는 peer의 모임- 토렌트에 참여한 peer들 끼리 같은 크기의 chunk들을 주고받는다.
- 파일이 256kb의 청크로 나누어 진다.(일반적인 크기)
- 기본 동작 : 피어가 처음 토렌트 가입 -> 해당 피어는 청크가 없음 -> 시간이 지남에 따라 청크를 쌓음 -> 청크 다운로드 + 다른 피어들에게 청크 업로드 -> 토렌트 떠나기 -> 재가입 가능
- 한 피어가 전체(일부) 파일을 얻었을 때 행동
1. 이기적 : 파일 받기만하고 토렌트 떠나기
2. 이타적 : 토렌트에 남아서 다른 피어들로 청크 업로드
비트 토렌트 동작 과정
트래커(tracker): 인프라스트럭처 노드- 일종의 서버 역할
- 한 피어가 토렌트에 가입할 때 트래커에 자신을 등록하고 주기적으로 자신이 아직 토렌트에 있음을 알린다.
- 토렌트에 참여(=파일분배)하는 피어들을 트래킹(추적) 한다.
동작 과정
- newPeer : 토렌트에 가입
- 트래커 : 참여하고 있는 피어 집합에서 임의로 피어들의 부분집합(50개)을 선택 후, newPeer에게 이 50개 피어들의 IP 주소 전달
- newPeer : 해당 목록에 있는 모든 피어와 동시에 TCP 연결을 설정
- 이웃 피어 : newPeer가 성공적으로 TCP 연결을 설정한 모든 피어
- 피어의 이웃 피어들은 시간에 따라 변동됨.
- 각 피어는 서로 다른 파일 청크들의 일부를 가짐.
- 주기적으로 newPeer는 현재 갖고 있지 않은 청크에 대해 (TCP 연결을 통해) 이웃 피어들 각각에게 그들이 갖고 있는 청크 목록 요구
- 만약 newPeer가 N개의 이웃을 갖고 있다면, N개의 청크 목록을 얻음
- 청크 요청 방식 :
rarest first-> 희귀한 chunk 부터 먼저 요청- 가지고 있는 peer가 적은 chunk 먼저 요청 = peer들은 떠날수도 있으니까
- -> 토렌트에 각 청크의 복사본 수가 (대략적으로) 동일
- 청크 응답(전송) 방식 :
현명한 교역(trading) 알고리즘- 가장 빠른 속도로 newPeer에게 데이터를 제공하는 이웃에게 우선순위를 주는 것
- newPeer 또한 요청 받으면 보내줘야 함.
- 상위 우선순위를 가진 4개의 peer에게 청크를 보냄으로써 보답
- 10초마다 속도 우선순위 속도 재계산한 후, 집합 수정
- 활성화(unchoked) : 위 집합에 속한 4개의 peer
- 낙관적 활성화(optimistically unchoked): 30초마다 임의로 피어 하나(새로운 교역 파트너 peerB)를 추가로 선택하여 peerB에게 청크를 보내는데, 이때 해당된 peerB
- peerB의 입장에서 newPeer는 우선순위집합에 해당될 수 있음
- 비활성화(choked) :위 5개 피어(4개의 '상위’ 피어와 하나의 탐색(probing) 피어) 외의 어떠한 청크도 받지 않는 모든 이웃 피어
TFT(tit-for-tat): 기술한 교역을 위한 보상 방식- 위에서 말한 현명한 교역 알고리즘을 말하는 듯
- 이 보상 방식은 회피할 수 있지만 있어야 되는 듯 ^^
- 비트토렌트 생태계는 매우 성공적이며，수십만 개의 토렌트에서 동시에 수백만의 피어들이 능동적으로 파일을 공유하고 있다.
- 비트토렌트가 TFT(혹은 그 변형) 없이 설계되었다면，대부분의 사용자들은 ‘무임승차칙free-rider)’이기 때문에 비트토렌트는 지금 존재하지도 않았을 것.
- 비트토렌트는 여기서는 논의하지 않은 조각(pieces，미니청크), I파이프라이닝(pipelining)，무작위 우선 선택(rand아n first selection), 마지막 게임 모드(endgame mode), 안티스너빙(anti-snubbing) 등 기법을 가짐.
- +) DHT(Distributed Hast Table)
- P2P의 다른 애플리케이션
- 데이터베이스 레코드가 P2P 시스템 피어에 분산되어 있는 단순한 데이터베이스
- 이는 다양하게 구현되어 있으며(예: 비트토렌트) 광범위한 연구 대상
인생 살자.