[컴퓨터 네트워크]-Application layer_P2P

 Application layer_프롤로그에서 application 계층은 client-server paradigm과 Peer-to-peer architecture가 존재한다고 했다. 이번 정리글에서는 그 중 Peer to Peer, P2P방식에 대해서 정리해보려고 한다.

---

1. Clinet-server paradigm vs. P2P Architecture

 우리가 지금까지 배웠던 방식은 Client-server paradigm에 기반했다. 먼저, client-server paradigm과 P2P 방식의 차이점부터 알아보자. 

 

-Client-server paradigm

 만약, 크기가 F인 파일을 N명의 peer들에게 분배하려면 Clinet-server paradigm에서는 얼마나 많은 시간이 들까?

 

위의 그림과 같은 상황이라고 하자. network에서의 bandwidth는 엄청나게 커서 여기서 걸리는 시간은 고려하지 않아도 된다(엄청 짧을 것이기 때문에).

 

서버가 업로드하는 용량을 us, 클라이언트들이 clinet-server paradigm에서는 거의 업로드할 일이 없지만 업로드하는 용량를 di, 다운로드 용량를 ui라고 하자. 

 

그럼, F 크기의 파일을 N명의 clinet에게 분배하는데 걸리는 시간은 다음과 같이 나타낼 수 있다.

 즉, F에 대한 N개의 복사본을 보내는데 걸리는 시간은 NF/us이고, 다운로드 받는 시간 중, 가장 대역폭이 작은 친구가 제일 오래 걸릴 것이기 때문에 F/dmin으로 표현하고, 그거에 대한 최댓값이 걸리는 총 시간이 될 것이다. 이렇게 되면, 사용자 N이 늘면 늘수록 걸리는 시간은 linear하게 증가함을 알 수 있다.

 

-P2P architecture

그렇지만, P2P 방식은 어떨까? 위의 상황과 똑같은 상황이라고 가정하면, clinet들이 전부 다 server 역할도 동시에 하게 된다.

 

 즉 client는 다운로드 받음과 동시에 업로드도 같이하게 되는데, 일단 기본적으로 서버가 F를 업로드 한 번을 하고 클라이언트가 다운로드 하는 시간은 clinet-server 패러다임과 같다. 

 

 그렇지만, 이 때, 클라이언트는 업로드도 하기 때문에, 총 걸리는 시간을 고려하면, NF에 대해서 모든 사용자의 업로드 용량을 나눠준 다음식도 포함해야 된다.

 

결국 이 식도, 시간이 N에 따라 linear하게 증가하긴 하지만, 그 만큼 ui의 합도 커지기 때문에 증가량은 clinet-server paradigm 방식보다 낮다는 것을 알 수 있다.

---

2. BitTorrent

 P2P Architecture의 대표적인 예시는 BitTorrent이다. 즉, 영화 다운로드 플랫폼이라고 생각하면 되는데, 이 BitTorrent는 기본적으로 다운로드만 받을 수 없게 하고, 다운로드만 받기 설정 시 매우 느린 속도로 다운로드 서비스를 이용하게 만들었다. 

 

 이곳에서는 모든 파일들이 256Kb의 chuck들로 쪼개져 있고, peer들은 파일 chuck들에 대해 주고 받을 수 있다.

Bit Torrent 네트워크에 접근하는 방법

 

 위에서 Alice가 이 network에 접근해서 영화를 다운받으려고 하고 있다. P2P 네트워크에 접근한다라는 것은 나의 peer를 찾는 일이다. 그렇지만,  여러 peer들이 존재하고, 어느 peer와 처음으로 연결할지 막막할 수도 있다. 이 때, tracker라는 존재가 peer를 찾는 일을 도와준다. 즉, 클라이언트 Alice는 tracker에 접근하면 peer를 알려준다는 것이다.

 

 이 때, 만약 찾아준 peer가 만약 너무 많은 peer들이 존재한다면, alice의 연결을 거부할 수도 있는데, 이 때는 또 tracker가 도와주게 된다. 이제, Alice는 peer를 찾았고, 원하는 영화를 다운받을 준비가 된 것이다.

 

 Alice가 네트워크에서 peer를 다 찾고, 준비된 상태이다. 처음에는 당연히 내려받을 chunk가 존재하지 않는다. 그렇지만 시간이 지남에 따라 다른 peer들로부터 내려받을 chunk가 생기게 된다.

 

 다운로드를 하는 동안, peer는 동시에 본인이 가지고 있는 chunk들을 다른 peer들에게 업로드를 해야한다. peer끼리는 서로 변할 수 있고, 다운로드가 끝나면 이기적으로 네트워크를 떠날 수 있다.

 

-Requesting Chunks

 이제 조금 더 자세히 어떻게 chunk들을 주고 받는지 알아보려고 한다.

 

 주어진 시간에, 서로 다른 peer들로 부터 한 파일에 관련된 서로 다른 chunk들이 존재한다. 즉, 한 영화에 대한 chunk들을 한 peer에서만 다운받을 수 없다는 것이다. 

 

 만약 Alice가 요청한 chunk가 1~10이라고 가정해보자. 이 때, 6을 제외한 1,2,3,4,5,7,8,9,10이 현재 peer들로 부터 받을 수 있다고 하면, Alice는 6에 대한 chunk를 받기 위해 6을 가진 peer에게 제일 먼저 접근해서 6을 먼저 받고 나머지 1~10을 받는다.

 

 이때, Alice는 4명의 peer들로 부터 chunk를 받았다면, Alice는 응당 4명의 peer들에게 본인이 가지고 있는 chunk들을 보내야 한다.

 

-Sending Chunks

 Alice는 위에서 영화 파일에 대한 chunk를 받는 동시에 연결된 4명의 peer들에게 그녀의 chunk들을 보낸다. chunk들을 보낼 때, Alice는 highest rate로 보낸다. 즉, 최대한 빠른 속도로 보낸다는 것이다.

 

 그럼 항상 똑같은 4명의 peer들에게만 보내는것이냐? 만약, Alice가 영화 받는 상황에서처럼, Alice만 가지고 있는 chunk를 다른 사용자는 못받는 상황이 나올 수 있지 않냐? 라는 질문이 생길 수 있다. 이런 상황이 choked된 상황이라고 하는것인데, Alice와 4명의 peer들은 서로서로 chok된 상태인 것이다.

 

 이에 대한 해결책은 10초마다 상위 4명의 속도를 가진 peer를 바꾸는 것이다. 10초마다, highest rate로 Alice로부터 chunk를 받는 4명에 대해서, 만약 한 명이 느려졌다면, 그 한 명의 peer와는 연결을 끊고 다른 속도가 높은 peer로 바뀌게 된다.

 

 또, 속도가 4명이 가장 빠른채로 유지된다면 30초마다 random하게 다른 peer를 선택해서 highest rate로 chunk를 보내게 된다. 다음 그림을 살펴보자.

Alice와 Bob 예시

 Alice가 30초가 지나 random하게 Bob이라는 친구를 선택해서 그녀가 가능한 최대의 속도로 데이터를 보냈다고 가정하면, Alice는 Bob의 최상위 4명으로 바뀐다. 그럼 Bob은 Alice를 받아들이고, Bob또한 Alice의 최상위 4명으로 바뀌는 것이다.