가장 빠른 P2P 파일 전송 CLI를 찾아서: Thruflux (Open Alpha)

Source: Dev.to

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

Source: …

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을 사용했을 때 약 4배의 처리량 향상을 얻었다.

ughput은 CUBIC과 비교했을 때. OS UDP 버퍼 크기를 최소 8 MiB까지 늘리면 추가로 약 1.3×의 속도 향상이 발생했습니다.

벤치마크

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

하드웨어 / 환경

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

벤치마크 명령 (실시간은 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

기능 매트릭스

초기 6초 P2P 핸드쉐이크가 있더라도(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는 전통적인 도구가 어려워하는 다중 파일 시나리오에서 빛을 발합니다. 초기 결과는 고무적이며, 개선할 여지가 충분합니다.

프로젝트 상태

• 알파 단계 – 핵심 기능이 완료되었으며 기본 테스트가 진행되었습니다. 특히 크로스‑플랫폼 및 네트워킹 엣지 케이스에서 거친 부분이 있을 수 있습니다.
• 피드백 환영 – 버그 보고, 성능 비교, 엣지‑케이스 시나리오 및 건설적인 비판을 매우 소중히 여깁니다.

빠른 시작 🚀

설치

사용

# Host files
thru host ./photos ./videos

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

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