-> 블로그 이전

[Network] 애플리케이션 계층 : P2P

2022. 2. 12. 16:13Major`/컴퓨터 네트워크

P2P (Peer to Peer)

- Always-on 서버가 없다

- 임의의 end system끼리 서로 통신하는 구조이다

  • end system = peer

- peer들은 인터넷에 간헐적으로 연결되고, 유동 IP 주소를 보유하고 있다

  • ex) 비트토렌트 (파일 분배) / Skype (화상전화) / ...

파일 분배

클라이언트 - 서버 구조

  1. Server가 Client의 수(N)만큼 파일을 분배한다 
  2. Client는 해당 파일을 다운로드 한다

 

1. Server 업로드 

  • 파일 복사본 N개를 업로드한다 (파일 크기 : F / Server 업로드 속도 : Us)

>> N개 복사본 업로드 시간 : NF/Us  

 

2. Client 다운로드 

  • 각 Client들은 Server가 업로드한 파일을 다운로드한다
  • 이 때, 다운로드 속도는 Client 중 다운로드 속도가 가장 느린 속도를 기준으로 한다 (파일 크기 : F / Client 다운로드 속도 : Dmin) 

>> 다운로드 시간 : F/Dmin  

 

∴  C-S 구조로 파일 F를 N개의 Client에 분배하는 시간 : Dc-s ≥ Max(NF/Us, F/dmin) 

  • Client의 수가 점차적으로 증가할 수록 분배 시간 Dc-s는 결국 Server가 업로드하는 시간에 비례해서 증가한다

 

P2P 구조

  1. Server가 파일 하나를 분배 
  2. 각 Client(Peer)들은 해당 파일을 다운로드 
  3. Client(Peer)들은 해당 파일을 업로드

 

1. Server 업로드 

  • 파일 하나를 업로드한다 (파일 크기 : F / Server 업로드 속도 : Us) 

>> 파일 업로드 시간 : F/Us 

 

2. Client(Peer) 다운로드 

  • 각 Client(Peer)들은 Server가 업로드한 파일을 다운로드한다

>> 다운로드 시간 : F/Dmin  

 

3. Client(Peer) 업로드 

  • Client(Peer)들은 파일을 업로드한다
  • System상에서 전체 업로드 속도 = 파일 업로드 속도(Us) + 각 Peer 업로드 속도(Ui

>> 전체 업로드 시간 : NF/(Us + ∑Ui) 

 

∴ P2P 구조로 파일 F를 N개의 Client(Peer)에 분배하고 업로드 되는 시간 : DP2P ≥ Max(F/Us, F/Dmin, NF/(Us + ∑Ui)) 

  • ∑Ui는 결국 NUi로 표현할 수 있기 때문에 DP2P는 Dc-s에 비해 특정 시간에 비례하지 않는다 


파일 분배 (비트토렌트)

1. 파일을 256KB의 청크(Chunk)로 분할한다

2. Peer들은 해당 청크를 서로 송수신한다 

 

구조

▶ 토렌트 (Torrent)

- 파일의 청크를 교환하는 Peer들의 그룹

- 각 파일마다 토렌트는 구분되어 있다

  • Torrent 1 : 파일 X를 교환하는 Peer들의 그룹
  • Torrent 2 : 파일 Y를 교환하는 Peer들의 그룹

 

▶ 트래커 (Tracker)

- 토렌트에 join하려는 새로운 Peer에게

  • "너가 원하는 파일을 exchange하고 있는 토렌트는 ~~~~ 이다"라는 것을 새로운 Peer에게 알려준다

- 각 토렌트별로 속해있는 Peer들을 추적한다

 

 

과정 :: 토렌트에 join하려는 새로운 Peer (파일 X 교환을 원함)

1. 트랙커에게 접근해서 파일 X를 교환하고 있는 토렌트의 정보를 입수

2. 해당 토렌트에 연결 (새로 가입)

3. 토렌트의 Peer들로부터 청크를 받는다

4. 청크를 받음과 동시에 다른 Peer에게 업로드도 한다

 

 

청크 교환 방식

▶ 청크 가져오기 (다른 Peer로부터 청크 받기)

1. 토렌트내의 각 Peer들은 해당 파일의 청크 일부분을 보유하고 있다

2. 자신이 가지고 있지 않은 청크에 대해서 다른 Peer에게 해당 청크를 요청한다

  • 이때, 가장 희귀한 청크부터 요청한다
    • 왜냐하면 해당 청크를 보유하고 있는 Peer에게 변동이 발생할 수 있기 때문 :: Peer Churn 
    • Peer Churn : 나에게 청크를 공유해주는 Peer가 사라지는 경우

 

▶ 청크 보내기 (다른 Peer에게 청크 업로드) :: 청크 되갚기

"나한테 청크를 잘 공급해주는 Peer에 대해서 나도 해당 Peer에게 청크를 잘 공급해줘야겠다" 

  • Selfish Peer들이 살아남지 못하도록 만든다
  • Selfish Peer : 청크를 공급만 받고, 업로드를 안하는 Peer

 

1. 10초마다 나한테 청크를 잘 공급해주는 4개의 Peer를 선택한다

  • 해당 4개의 Peer에 대해서 나도 열심히 공급을 해준다

>> but, 이러면 해당 4개의 Peer한테만 계속해서 공급을 하는 문제점이 발생한다

 

2. 30초마다 임의로 Peer하나를 선택해서 해당 Peer에게도 청크를 공급해준다

  • 이러면 소외되는 Peer를 줄일 수 있다

※ Example) 

Torrent 1 : (Peer @, Peer 1, Peer 2, Peer 3, Peer 4)

  • Peer @ ↔ Peer(1, 2, 3, 4) :: 청크를 교환하고 있다

Torrent 2 : (Peer #, Peer 5, Peer 6, Peer 7, Peer 8)

  • Peer # ↔ Peer(5, 6, 7, 8)  :: 청크를 교환하고 있다

>> 이러면 토렌트끼리만 청크를 공유하기 때문에 확장성이 좋지않다

 

이렇게 Peer @가 임의로 Peer #를 선택해서 청크를 보내게 된다면

  1. 업로드 속도가 훨씬 빨라진다
  2. 원하는 파일을 훨씬 빨리 얻을 수 있다