P2P의 개념

1. P2P 구조

 

앞서 인터넷을 통해 여러 서비스를 이용할 때, 기본적으로 서버 - 클라이언트 모델을 살펴보았다. 서버가 서비스를 제공하고 클라이언트는 서비스를 이용하는 서버 - 클라이언트 모델은 가장 기본적이면서도 널리 사용되는 통신 모델이다.

 

하지만, P2P (Peer 2 Peer) 모델도 실생활에서 심심치않게 찾아볼 수 있다.

 

P2P는 서버가 컨텐츠를 제공하는 것이 아니라 임의의 end system 들끼리 직접 컨텐츠를 송/수신하는 구조이다.

대표적으로 파일을 공유하는 서비스인 BitTorrent, 음성 서비스를 제공하는 Skype, 스트리밍 서비스를 제공하는 Kankan 등이 P2P 모델을 이용한다.

 

 

 

2. P2P의 역사

 

1980년대에 Usenet이라는 서비스가 P2P의 시초라고 볼수도 있겠지만, 제대로된 P2P 서비스는 1990년대 말 서비스를 시작한 Napster부터라고 볼 수 있다. 기껏해봐야 20년의 역사를 가지고 있는 P2P 모델의 역사를 살펴보자.

 

• Napster

P2P의 가장 초기 모델이라고 볼 수 있다. 1999년 서비스를 시작한 Napster는 당시 대학생들을 중심으로 유행해 Napster를 통해 음악을 공유하는 것이 성행했으나, 이후 저작권 관련 분쟁으로 인해 2001년 서비스를 종료하게 된다.

 

Napster의 동작 방식은 다음과 같다.

 

1) 중앙에 서버를 하나 두고

2) 어느 Peer가 어떤 파일을 원하는지 서버가 파악하고

3) 서버가 해당 파일을 가지고 있는 Peer를 파악해 매칭해준다.

4) 매칭된 Peer끼리 직접 파일을 주고 받는다.

 

파일을 주고받을때는 P2P 형식으로 주고받지만, 어쨌든 중앙 서버가 '피어 매칭' 이라는 핵심적인 기능을 수행하므로 서버가 고장나면 전체 서비스가 다운된다는 단점이 있다.

 

 

• Gnutella

앞서 살펴본 Napster가 중앙형이라면, Gnutella는 분산형 서비스이다. 하나의 서버가 모든 것을 알기보다 하나의 Peer가 몇개의 Peer들이 가진 파일을 알고 있고, 그 Peer들도 몇개의 Peer들이 가진 파일을 아는 구조이다.

 

즉 다단계처럼 뻗어나가 결국 모든 Peer들이 연결되는 형태이다.

 

Gnutella의 동작방식은 다음과 같다.

 

1) 어느 Peer가 어떤 파일을 원하면 자신이 알고있는 Peer에게 쿼리를 날린다.

2) 쿼리를 받은 Peer는 자기가 해당 파일을 가지고 있으면 쿼리를 날린 Peer에게 알려주고, 자기가 해당 파일이 없으면 자신이 알고있는 Peer에게 또다시 쿼리를 날린다.

3) 그렇게 어느 Peer가 파일을 가지고 있는지 알게되면, 그 중 하나의 Peer를 선택해 파일을 받는다.

4) 파일 전송에는 HTTP 프로토콜이 사용된다. (GET 메소드 사용)

 

이 방식은 중앙 서버가 없으므로, 서버가 고장나 전체 서비스가 다운되는 문제는 없지만 Peer가 너무 많으면 속도가 느려진다는 단점이 있다.

 

 

• KaZaA

Gnutella와 유사하지만, 사용자가 많으면 오래 걸리는 단점 극복을 위해 각 Peer 중 Group leader를 뽑고, 하위 부하 Peer들을 관리하는 형태이다.

 

그룹 내에서는 바로 파일을 공유하며, 다른 그룹에 속한 Peer가 파일을 가지고 있으면, Group leader를 통해 매칭된다.

 

 

• BitTorrent

파일을 통채로 전송하던 앞선 방법과는 다르게, 파일을 256KB의 청크로 쪼갠다.

 

Tracker라는 녀석이 각 Peer를 훑어 누가 어떤 파일의 청크를 가지고 있는지 파악한다. 그리고 각 청크들을 다운로드 하는 도중에 Peer들은 자신이 가진 청크들을 다른 Peer에게 업로드한다.

이처럼 다운로드를 하면서 바로 업로드를 할 수 있기 때문에 굉장히 효율적인 방법이라고 할 수 있다.

 

청크들을 전송할 때 rare is first 원칙이 적용되는데, 이는 Peer들이 적게 가지고 있는 청크일수록 우선순위를 두고 전송되는 원칙이다. 그래야 해당 청크의 복사본이 늘어나 파일 공유가 수월해지기 때문이다.

 

또한, tit-for-tat (눈에는 눈 이에는 이) 원칙도 적용되는데, 이는 업로드를 많이 한 Peer일수록 다운로드에 우선순위를 부여함으로써 서로 공유하기 매끄러운 환경을 만들어 준다.

 

 

 

3. P2P환경에서의 파일 분배 시간

 

$ u_{s} $ : 서버가 단위시간당 업로드하는 양

$ d_{min} $ : 가장 다운로드 속도가 느린 클라이언트가 다운로드하는 속도

 

Q. 일반적인 '서버 - 클라이언트 모델' 에서 N명의 사용자가 F 크기의 파일을 공유하는데 걸리는 시간은 얼마일까?

 

우선, '클라이언트-서버' 모델에서 서버는 N개의 파일을 완전히 다 올려야 한다. 이 때 걸리는 시간이 $ \frac{F * N}{u_{s}} $ 이다.

또한, 가장 성능이 안좋은 클라이언트가 파일 하나를 받는데 걸리는 시간이 $ \frac{F}{d_{min}} $ 이다.

 

따라서 결국 총 걸리는 시간은 아래 수식과 같다.

 

CS Distribution time

 

위의 수식과 같다. 서버는 N개의 F 크기 파일을 업로드해야 하고, 클라이언트는 F 크기의 파일을 다운 받아야 하므로 서버와 클라이언트의 성능 중 낮은 성능을 기준으로 공유 시간이 결정된다.

 

 

Q. 그렇다면, P2P 모델에서 N명의 사용자가 F 크기의 파일을 공유하는데 걸리는 시간은 얼마일까?

 

우선, P2P 모델에서 서버는 하나의 파일을 완전히 다 올려야 공유가 시작된다. 따라서 이 때 걸리는 시간이 $ \frac{F}{u_{s}} $ 이다.

또한, 가장 성능이 안좋은 클라이언트가 파일 하나를 받는데 걸리는 시간이 $ \frac{F}{d_{min}} $ 이다.

마지막으로, 총 N개의 F 크기 파일이 업로드되는데 걸리는 시간은 $ \frac{N * F}{u_{s} + \sum_{i=1}^N u_{s}} $ 이다.

 

따라서 결국 총 걸리는 시간은 아래 수식과 같다.

 

P2P Distribution time

 

여기서 한가지 눈여겨 볼 것은 총 N개의 F 크기 파일을 업로드 할 경우, P2P 모델에서는 사용자(N)이 증가할 때 분자와 함께 분모도 증가한다는 것이다. 이 말은 사용자가 많아질수록 업로드할 파일의 크기도 증가하지만, 업로드되는 속도 또한 증가한다는 의미이다.

사용자가 많아지면 업로드 속도는 그대로지만, 업로드할 파일의 크기가 늘어나는 전통적인 '클라이언트-서버' 모델과는 다른 부분이다.

 

따라서 사용자가 증가함에 따라 전체 파일을 분배하는데 걸리는 시간은 아래 그림과 같이 나타난다.

 

CS / P2P Minimum Distribution Time

 

 

오늘 배운 내용을 정리해보면,

 

1. P2P는 Peer들끼리 파일을 공유하는 모델이다.

 

2. P2P는 중앙서버를 둔 Napster부터 시작하여 파일을 청크단위로 쪼개는 BitTorrent 까지 발전하였다.

 

3. P2P 모델에서는 사용자가 많을수록 파일 분배 속도 또한 빨라진다.

 

위 내용은 공부하며 정리한 것으로, 오류가 있을 수 있습니다.