가장 빠른 P2P 파일 전송 CLI를 찾는 여정: Thruflux (오픈 알파)

Source: Dev.to

GitHub 저장소는 여기에서 확인하세요

My goal

하루는 가슴 속에 불타는 단 하나의 야망이 생겼다: 역사상 가장 빠른 파일 전송 도구를 만들고 싶었다.
이전에 스스로 진행한 웹 개발 프로젝트 경험이 있었기에, 바로 웹을 찾아 현재 존재하는 브라우저 기반 솔루션들을 조사했다.

What people use today

대부분의 사람들은 Dropbox, Google Drive 같은 상용 툴이나 Discord, Email 같은 메신저를 사용한다.
개발자들—그리고 놀랍게도 많은 비개발자들조차도—이러한 도구는 충분하지 않다. 그 한계는 잘 알려져 있다:

• 전송할 수 있는 파일의 용량 제한.
• 클라이언트‑서버 모델에 의존해 업로드가 끝나야 다른 사람이 파일을 다운로드할 수 있다.
• 클라우드에 파일을 안전하게 저장하는 데는 좋지만, 일회성 파일 공유에는 매우 부적합하다.
• 파일을 서버에 저장해야 하기 때문에 언제나 내재된 보안 문제가 있다.

Why existing P2P tools didn’t cut it

그 다음으로 P2P 파일 전송 세계를 살펴보았다. 대표적인 제로‑설정 솔루션으로는 Blip, Magic‑wormhole, croc, scp, rsync 등이 있다. 안타깝게도 이들 중 어느 것도 만족스럽지 않았다:

위 도구들은 모두 TCP 연결에 의존한다. 나는 최근 QUIC와 UDP에 관심을 갖게 되었고, 이를 활용해 기존 도구들을 능가하고자 했다.

Core focus

QUIC을 활용해 사용이 매우 간단하면서도 믿을 수 없을 정도로 빠른 CLI 전송 도구를 만든다.

나는 일곱 가지 요구사항을 정의했다:

1. QUIC + ICE를 이용한 제로‑설정 피어‑투‑피어 전송(UDP 구멍 뚫기가 TCP보다 성공 확률이 높으며, QUIC은 BBR 같은 최신 혼잡 제어 알고리즘의 혜택을 받음).
2. 다중 파일 지원 – 여러 파일을 전송하는 속도가 동일한 총 용량의 단일 파일 전송 속도와 같거나 빨라야 함.
3. 다중 수신자 – 하나의 세션이 언제든지 새로운 수신자를 받아들일 수 있어야 하며 전송을 재시작할 필요가 없음.
4. 크로스‑플랫폼 – Windows, Linux, macOS 지원.
5. 자동 재개 – 대용량 파일에 필수이며 빠르게 동작해야 함.
6. 오픈 소스.
7. 속도 최우선 – 보안은 최소한으로 유지하고, 성능을 가장 큰 장점으로 삼는다.

Language choice

Rust와 Go도 강력한 후보였지만, 나는 **C++**를 선택했다:

• 성숙한 QUIC/ICE 라이브러리 존재.
• 저수준 설정이 가능.
• 가비지 컬렉터가 없어 최대 성능을 끌어낼 수 있음.

Lessons learned

1. 스레딩 vs. 단일 스레드 – 처음엔 여러 스레드와 다중 QUIC 연결/스트림이 처리량을 극대화할 것이라 생각했다. 실제로는 단일 스레드와 단일 연결이 네트워크를 포화시켰으며, 애플리케이션 로직을 크게 단순화했다.
2. CPU 확장성 – QUIC은 CPU 성능과 코어 수에 크게 의존한다. 최근 10년 내에 출시된 합리적인 CPU(≥ 2코어)에서는 QUIC이 TCP보다 뛰어난 성능을 보였지만, 저사양 장치에서는 오히려 성능이 떨어졌다.
3. 혼잡 제어와 버퍼 – BBR을 사용했을 때 CUBIC 대비 약 4배의 처리량을 얻었다. OS UDP 버퍼 크기를 최소 8 MiB로 늘리면 추가로 약 1.3배의 속도 향상이 있었다.

Benchmark

진실의 순간: 내 도구를 기존 도구와 벤치마킹하기.

Hardware / environment

• Vultur dedicated CPU – 2 vCPU (AMD EPYC Genoa), 4 GB RAM, NVMe SSD, Ubuntu 22.04.
• 공용 인터넷을 통해 테스트: 송신자는 Chicago, 수신자는 New Jersey에 위치.
• 방법: 3회 실행의 중앙값; 시간은 전체 엔드‑투‑엔드 벽시계 시간(설정 + 전송 + 해제) 포함.
• “수신 단계”만 보고함.

Benchmark commands (wall‑clock measured with time)

# scp — single file
time scp test_10GiB.bin root@207.246.86.142:/root/

# scp — many files
time scp -r bench/

(맞춤형 QUIC 도구에 대한 추가 벤치마크 결과는 여기서 이어집니다.)

벤치마크 명령

# 원격 호스트에서 파일 표시
mark_files root@207.246.86.142:/root/

# rsync — 단일 파일
time rsync -a --info=progress2 --no-compress --whole-file --inplace \
  test_10GiB.bin root@207.246.86.142:/root/

# rsync — 다수 파일
time rsync -a --info=progress2 --no-compress --whole-file --inplace \
  benchmark_files root@207.246.86.142:/root/

# croc — 단일 파일
time CROC_SECRET="code" croc --yes

# croc — 다수 파일
time CROC_SECRET="code" croc --yes

# Thruflux — 직접 (단일 + 다수 파일)
time ./thru join --overwrite 

# Thruflux — 강제 TURN 릴레이
time ./thru join --overwrite --force-turn 

# wormhole — 단일 / 다수 파일
time wormhole receive  --accept-file

기능 매트릭스

초기 P2P 핸드셰이크가 6초 걸리더라도(scp와 rsync는 해당 없음), Thruflux는 실제 경과 시간에서 이들을 앞섭니다. 다른 P2P 도구와 비교했을 때, 특히 1000개 파일 전송에서 명확한 이점을 보입니다.

관찰 및 트레이드오프

1. CPU‑bound – Thruflux는 더 많은 CPU 파워가 필요합니다. 저사양 싱글코어 장치에서는 rsync/scp보다 약간 느릴 수 있습니다.
2. TURN relay fallback – 자체 호스팅 TURN 서버는 규모가 작고 위치가 좋지 않아 TURN을 통한 전송(예: 대칭 NAT)은 다른 도구보다 느립니다.
3. UDP restrictions – 일부 네트워크는 아웃바운드 UDP를 완전히 차단하여 QUIC을 사용할 수 없습니다.
4. Longer connection phase – 전체 ICE 교환으로 인해 지연이 증가합니다; trickle ICE로 전환하면 이를 줄일 수 있습니다.
5. Lack of verification – Thruflux는 QUIC의 내장 무결성을 신뢰합니다(TCP보다 강력). 디스크 수준의 손상은 확인되지 않으며, 드물지만 발생할 수 있습니다.
6. Join‑code entropy – PAKE가 없으므로 보안을 보완하기 위해 조인 코드는 고엔트로피여야 합니다; 사용자는 보통 복사‑붙여넣기합니다.

이러한 주의사항에도 불구하고, Thruflux는 전통적인 도구들이 어려워하는 다중 파일 시나리오에서 빛을 발합니다. 초기 결과는 고무적이며, 개선 여지는 충분합니다.

Project Status

• Alpha stage – 핵심 기능이 완성되었으며 기본 테스트가 완료되었습니다. 특히 크로스‑플랫폼 및 네트워킹 엣지 케이스에서 거친 부분이 있을 수 있습니다.
• Feedback welcome – 버그 보고, 성능 비교, 엣지‑케이스 시나리오, 그리고 건설적인 비판을 환영합니다.

빠른 시작 🚀

설치

사용

# Host files
thru host ./photos ./videos

# Share the join code with multiple peers
thru join ABCDEFGH --out ./downloads

자세한 내용은 저장소의 README를 확인하세요: