클라이언트-서버 방식에서는 원본 서버가 모든 수신자에게 데이터를 업로드한다. P2P(Peer-to-Peer) 방식에서는 파일을 받은 참여자도 다른 참여자에게 조각을 업로드해 전체 배포 용량에 기여한다. 참여자가 늘수록 공급자 서버의 업로드만 늘려야 하는 구조와 다르다는 점이 핵심이다.
P2P가 중앙 구성 요소를 전혀 쓰지 않는다는 뜻은 아니다. BitTorrent도 peer 발견에 tracker를 쓸 수 있고, 메타데이터 배포를 웹에 의존할 수 있다. 데이터 전달 경로가 peer 사이로 분산된다는 점과 제어·발견 기능의 중앙화 여부를 나눠 봐야 한다.
클라이언트-서버 배포의 병목
크기가 F인 파일을 N개 클라이언트에 배포한다고 가정하자. 서버 업로드 속도가 u_s, 가장 느린 클라이언트의 다운로드 속도가 d_min이면 이상적인 환경에서도 배포 시간은 다음 두 조건보다 짧을 수 없다.
서버가 N개 사본을 올리는 시간: N × F / u_s
가장 느린 클라이언트가 한 사본을 받는 시간: F / d_min
D_client-server ≥ max(NF/u_s, F/d_min)
수신자가 늘면 서버가 보내야 할 총량 N × F도 선형으로 증가한다. CDN과 여러 원본 서버로 병목을 분산할 수 있지만, 기본 모델에서는 공급자가 업로드 용량을 마련한다.
P2P에서는 수신자가 공급자가 된다
P2P에서는 원본 서버가 적어도 파일 한 사본을 올려야 하고, 각 peer도 한 사본을 받아야 한다. 동시에 원본 서버와 peer의 업로드 용량을 합친 만큼 전체 데이터를 나눠 보낼 수 있다.
D_P2P ≥ max(
F/u_s,
F/d_min,
NF/(u_s + Σu_i)
)
u_i는 각 peer의 업로드 속도다. 이 식은 프로토콜 오버헤드, peer 이탈, 조각 가용성, 네트워크 경로와 연결 제한을 무시한 이론적 하한이다. 실제 완료 시간을 그대로 예측하는 공식은 아니다. 그래도 참여자가 업로드 용량을 더한다는 확장성의 차이는 잘 보여 준다.
BitTorrent 배포를 이루는 요소
BEP 3의 기본 모델에서 파일 배포는 다음 요소로 구성된다.
- metainfo: 파일 이름, 크기, piece 정보와 tracker 주소 등을 담는
.torrent데이터 - infohash: metainfo의
info부분을 식별하는 해시 - swarm: 같은 콘텐츠를 주고받는 peer 집합
- seeder: 필요한 콘텐츠 전체를 가진 peer
- leecher: 아직 필요한 piece가 남아 있는 peer
- tracker: 특정 torrent에 참여한 peer의 연락처를 알려 주는 서비스
tracker는 파일 본문을 중계하는 서버가 아니다. peer를 발견하도록 돕는다. BEP 5의 DHT를 지원하면 trackerless torrent에서도 분산 해시 테이블로 peer 연락처를 찾을 수 있다. 현실의 클라이언트는 tracker, DHT, peer exchange 같은 여러 발견 경로를 함께 쓸 수 있다.
파일을 piece와 block으로 나누는 이유
BitTorrent는 파일 집합을 고정 크기의 piece로 나누고 각 piece의 무결성을 검증한다. 전송 요청은 piece보다 작은 block 단위로 이루어질 수 있다.
파일 집합
├─ piece 0 ─ block 0, block 1, ...
├─ piece 1 ─ block 0, block 1, ...
└─ piece 2 ─ block 0, block 1, ...
조각으로 나누면 한 peer가 받은 piece를 완료 전에 전체 파일을 기다리지 않고 다른 peer에 제공할 수 있다. 서로 다른 peer에게 병렬로 block을 요청할 수도 있다. piece 검증에 실패하면 그 데이터를 신뢰하지 않고 다시 받아야 한다.
해시는 전송 중 변조나 손상을 찾는 데 도움을 주지만 콘텐츠 게시자의 신원까지 증명하지는 않는다. 신뢰할 수 없는 웹사이트에서 받은 magnet link나 .torrent라면 공격자가 만든 다른 콘텐츠의 해시일 수 있다. 배포 출처와 서명 정책을 별도로 확인한다.
rarest-first와 choking은 무엇을 해결할까
모든 peer가 같은 인기 piece만 먼저 받으면 희귀한 piece를 가진 peer가 떠난 뒤 swarm 전체가 완성본을 만들지 못할 수 있다. BitTorrent의 rarest-first 전략은 자신이 연결한 peer들 사이에서 덜 흔한 piece를 우선 선택해 가용성을 퍼뜨린다.
전송 상대도 무제한으로 열어 두지 않는다. 기본 프로토콜은 choking과 unchoking으로 업로드 대상을 조절한다. 다운로드에 기여하는 peer를 우대하고, 일부 상대를 주기적으로 탐색하는 optimistic unchoke를 사용한다. 흔히 tit-for-tat이라고 설명하지만, 실제 선택 기준과 주기는 클라이언트 구현과 확장에 따라 달라질 수 있다.
P2P가 언제 유리하고 무엇이 어려운가
| 항목 | 클라이언트-서버 | P2P |
|---|---|---|
| 공급 용량 | 서버·CDN이 제공 | 서버와 참여 peer가 함께 제공 |
| 콘텐츠 통제 | 중앙에서 버전·접근을 관리하기 쉬움 | peer가 데이터를 보유해 회수·정책 집행이 어려움 |
| 가용성 | 서버 인프라와 복제 정책에 좌우 | seeder와 piece 가용성에 좌우 |
| 방화벽·NAT | 클라이언트의 outbound 연결 중심 | inbound 도달성과 peer 연결 품질이 영향을 줌 |
| 관측성 | 서버 로그에서 흐름을 모으기 쉬움 | 다수 peer 경로를 한곳에서 보기 어려움 |
| 개인정보 | 서비스에 접속 정보가 보임 | swarm 참여자에게 IP·port가 노출될 수 있음 |
같은 대용량 파일을 동시에 많은 사용자에게 배포하고 참여자의 업로드를 활용할 수 있다면 P2P가 유리할 수 있다. 반대로 접근 통제, 삭제 요구, 일관된 지연 시간, 중앙 관측성이 중요하면 서버·CDN 방식이 단순하다.
문제를 확인하는 순서
- metainfo 또는 magnet URI가 의도한 infohash인지 확인한다.
- tracker 응답과 DHT가 peer를 찾는지 분리한다.
- 연결된 peer 수보다 필요한 piece를 가진 peer가 있는지 본다.
- NAT·방화벽 때문에 inbound 연결이 제한되는지 확인한다.
- 다운로드뿐 아니라 업로드 제한이 프로토콜 참여를 막지 않는지 본다.
- 콘텐츠 해시 검증 실패와 디스크 오류를 구분한다.
P2P의 “분산”은 모든 책임이 사라지는 마법이 아니다. peer 발견, 메타데이터 신뢰, 조각 가용성, 네트워크 도달성이라는 새로운 운영 문제로 바뀐다.
참고 자료
'배움과 성장 > 네트워크·보안' 카테고리의 다른 글
| 전송 계층 멀티플렉싱·역다중화: 포트와 소켓으로 이해하기 (0) | 2023.03.31 |
|---|---|
| TCP·UDP 소켓 프로그래밍: Python 클라이언트·서버 흐름 (0) | 2023.03.31 |
| DNS Record 종류와 조회법: A·AAAA·CNAME·MX·NS·TXT·PTR (0) | 2023.03.31 |
| DNS 루트 서버 운영 비용은 누가 내나: 독립 운영기관의 재원 구조 (0) | 2023.03.31 |
| DNS 루트 서버는 13대가 아니다: 13개 식별자와 Anycast 위치 (0) | 2023.03.31 |
댓글