[네트워크] P2P applications

oldshoe·2024년 4월 18일

목록 보기

12/34

Peer-to-peer(P2P) architecture

P2P는 항상 켜져있는 서버가 없다.
(서버를 사용하는 P2P도 있긴 한데 서버의 역할이 클라이언트와의 통신이 아닌 peer들을 관리하기 위한 서버)
각 end system(클라이언트, peer)끼리 직접적으로 소통한다.
peer들은 항상 켜져있는 것도 아니고 IP 주소도 고정이 아니다.

P2P File distribution VS client-server File distribution

F 사이즈의 파일을 한 서버로부터 N개의 peer들에게 distribute하는데 얼마나 시간이 걸릴까?
-> peer의 업로드/다운로드 용량은 정해져있음

us : 서버의 파일을 네트워크로 업로드 하는데 걸리는 전송 속도(업로드 속도)
di : 네트워크에서 클라이언트로 파일을 보내는 속도(다운로드 속도)
-> 전송속도가 더 낮은 쪽(bottleneck이 걸리는 쪽)이 파일을 다운받는 전송 속도를 결정

File distribution time : client-server

서버 전송 시간 : N개의 파일 복사본들을 순차적으로 보내야 한다.
-> 한 카피 당 서버에서 네트워크로 업로드 하는데 걸리는 시간 : F/us
-> N개의 카피면? : NF/us
클라이언트 다운받는 시간
* dmin = 클라이언트가 다운로드 하는 속도
-> 클라이언트들이 동시에 다운받을 때는 가장 다운 속도가 느린 곳에서 bottleneck이 발생하기 때문에 다운로드 속도가 가장 느린 곳이 전체 속도를 결정 : F/dmin
전체 시간
-> 파일 업로드 시간과 파일 다운로드 시간 중 max 값이 전체 시간

File distribution time : P2P

서버 전송 시간
-> 처음에는 서버에만 파일이 존재, 네트워크 상에는 파일이 없음(파일을 가지고 있는 서버일 뿐)
-> 클라이언트들이 파일을 요청하면 일단은 한 번은 서버에서 가져와야함
-> F/us
클라이언트 다운받는 시간
-> 모든 클라이언트들이 다운 받아야 하므로 가장 다운 속도가 느린 곳에 의해 결정
-> F/dmin
한 번 파일을 다운로드하면, 클라이언트들의 업로드 bandwidth를 사용할 수 있음
-> 클라이언트가 서버 역할을 하는 것
-> 한 파일을 다 다운로드 한 후 전달이 가능한 것이 아니라 어느 정도 다운로드 하면 그 때부터는 다운받은 부분들을 전달할 수 있게 됨
-> 원래 서버의 업로드 속도 + 클라이언트들의 업로드 속도의 합 = 전체 업로드 속도
-> 이 때는 N개의 클라이언트가 모두 파일을 다운받아야 하므로 총 필요한 bit 수는 NF bit
-> 이 때 걸리는 시간 = NF / (서버 업로드 속도 + 클라이언트 업로드 속도의 합)
전체 시간
-> (한 파일에 대한) 서버 업로드 시간, 클라이언트 다운 받는 시간, 전체 파일에 대한 업로드 시간 중 max 값이 전체 시간

Example

클라이언트가 많아질수록 P2P는 효율적이다.
그러나 클라이언트-서버 구조면 서버가 24시간 열려있어서 시간이 좀 걸리더라도 안정적이지만, P2P의 경우 파일을 제공하는 클라이언트들이 꺼져있을 수도 있어서 파일을 다운 받지 못한다.

BitTorrent

chunk : 파일이 256Kb의 chunk로 나눠진 것(크기는 설정에 따라 달라질 수 있음)
torrent : 파일을 주고받는 peer
tracker : 일종의 서버 역할 -> 어떤 peer들이 어떤 파일 distribution에 참여하고 있는지 추적
-> tracker를 통해 peer의 리스트를 받고, torrent의 peer들과 파일을 주고 받음
torrent에 peer들이 참여하는 과정
-> 처음에는 chunk가 없음. 하지만 시간이 지나면서 다른 peer들로부터 축적됨
-> tracker에 등록되고 주변 peer들(neighbor)과 커넥션을 맺어서 파일을 다운로드
다운로드 받는 동안에도 chunk들을 다른 peer들에게 업로드 해줄 수 있음
파일을 다운로드 하는 중에도 다운받는 peer를 바꿀 수도 있음
-> 용어로 churn이라고 하는데, 다이나믹하게 peer가 바뀌는 것을 말함
peer가 파일 전체를 갖게 되면 떠나거나 torrent에 남아 있을 수 있음

Requesting chunks

peer들이 가지고 있는 chunk들이 다를 수도 있다. 그래서 주기적으로 각각의 peer들에게 어떤 chunk를 가지고 있는지 물어본다. (chunk list 요청)

그 방식은 다음과 같다.
rarest first : 희귀한 chunk부터 먼저 요청한다. (가지고 있는 peer가 적은 chunk 먼저 요청, peer들이 떠날 수도 있기 때문에)

Sending file chunks

chunk 보내기(tit-for-tat)
요청을 받으면 보내줘야 한다. (우선순위를 갖고 보내줌)
그 우선순위는 자신에게 가장 높은 속도로 chunk를 보내주고 있는 peer들(많은 데이터를 주는 peer들)일수록 높다.
그 중 상위 네 명의 peer에게 보낸다. 다른 peer들은 자신으로부터 데이터를 못 받는다.
그리고 10초마다 상위 4명의 peer를 갱신한다.
30초마다 랜덤으로 peer를 고르고 chunk를 보내준다. (상위 네 명 말고)
새롭게 선택된 peer가 상위 4 peer에 들어올 수도 있다.
자신도 랜덤으로 받아서 누군가의 상위 4 peer가 될 수도 있다.