[Network] P2P applications

P2P 아키텍처는 client-server와는 다르게 누구든 서버가 될 수 있으면 누구든 클라이언트가 될 수 있다.

 

P2P 아키텍처는 peer들끼리 서로 서버가 되기도 클라이언트가 되기도 하면서 통신이 가능하다.

 

이를 이용한 애플리케이션의 경우 BitTorrent, Skype등이 있다.

 

파일을 분배할 때 client-server 구조와 P2P구조 중에 어떤 것이 효율적일까?

 

client-server 파일 분배

하나의 서버와 N개의 클라이언트가 있다고 하자.

 

N개의 클라이언트에게 나누어 주려면 서버는 네트워크쪽에 N번의 업로드를 하게 된다.

 

N개의 클라이언트가 파일을 받는 시간은 서버가 N개의 파일을 업로드하는 시간과 클라이언트가 가장 오랜 시간에 걸쳐 다운받는 시간 중 큰 값보다 작을 수는 없다.

 

 

P2P 파일 분배

그렇다면 P2P 구조에서는 어떨까?

 

우선 P2P 구조의 장점은 N개의 클라이언트가 파일을 받으려고 할 때 서버가 N번 파일을 업로드할 필요가 없다.

 

서버가 한 번만 업로드를 하더라도 peer들끼리 파일을 주고 받을 수 있기 때문이다.

 

N개의 클라이언트가 파일을 받는 시간은 서버가 파일 하나를 업로드 하는 시간과 클라이언트가 가장 오랜 시간에 걸쳐 다운받는 시간과 N개의 클라이언트가 모두 파일을 받는 평균 시간 중 큰 값보다 작을 수는 없다.

 

client-server 구조보다 P2P 구조가 N이 증가할수록 효율이 훨씬 좋다.

 

BitTorrent

P2P 구조로 설계된 애플리케이션의 예시는 BitTorrent이다.

 

우선 파일은 여러개의 chunk로 나눠져있다.

 

하나의 영화가 있다면 여러개의 chunk로 구성되어 있고 peer끼리 chunk를 주고 받는다.

 

peer들이 가지고 있는 chunk의 정보는 tracker에 보관이 된다.

 

영화를 다운받고 싶다면 이 tracker에게 파일 정보를 물어보게 되고 가지고 있는 peer들의 리스트를 알려준다.

 

그러면 peer들의 그룹에 들어가서 파일을 받는 것이다.

 

영화에 대한 아무런 chunk가 없는 상태에서 chunk들을 받게 될 것이다.

 

이 chunk들을 받기 시작하면 이 chunk를 받고 싶어하는 새로운 클라이언트 또한 존재할 것이다.

 

그러면 chunk들을 받기도 하면서 동시에 업로드도 하는 구조가 완성된다.

 

이 구조가 BitTorrent의 기본 구조이다.

 

그런데 chunk가 거의 없는 peer들끼리 그룹을 형성하여 파일을 나눈다면 상당히 느릴 것이다.

 

그래서 BitTorrent는 어떤 chunk를 우선적으로 분배할 것인지 결정해야한다.

 

BitTorrent는 희귀한 chunk부터 우선적으로 분배한다.

 

당연하게도 희귀한 chunk를 빠르게 복사하여 여러 명의 peer가 그 chunk를 갖고 있는 편이 효율적일 것이다.

 

 

그룹을 형성해서 chunk를 주고 받을 때 peer들 간의 속도를 계속 체크해서 가장 느린 peer를 내보내고 빠른 peer를 데려온다. (tit - for - tat)

 

효율적으로 파일을 분배하기 위해서 위 방법을 사용한다.