Logo

1장 더 빠른 이유: 4가지 핵심 메커니즘

FileBolt의 속도 이점은 전송, 병렬 청크, 글로벌 토폴로지 및 다중 소스 스케줄링의 조합에서 비롯됩니다. 이 장에서는 최대 처리량을 향상시키는 메커니즘과 패킷 손실 또는 네트워크 전환 시 안정성과 복구 가능성을 향상시키는 메커니즘을 감사 가능한 방식으로 설명합니다.

1.1 설계 목표(속도 보기)

  • 목표 A: 대역폭 한도에 접근합니다. 일반적인 조건에서는 사용 가능한 대역폭을 포화시키십시오.
  • 목표 B: 안정적인 처리량. 손실, 지터, 네트워크 전환 및 높은 지역 간 RTT가 발생하는 상황에서 사용 가능한 처리량을 갑자기 중단하지 않고 유지하세요.
  • 목표 C: 복구 가능한 오류. 오류가 발생하면 소량의 데이터만 재전송하도록 비용을 제한하고 0%에서 다시 시작하지 않도록 하세요.

1.2 전송 계층 최적화: HTTP/3(QUIC)

  • 클라이언트 및 에지 수신은 HTTP/3(QUIC)을 선호해야 합니다(SHOULD). 브라우저, 네트워크 또는 미들박스가 이를 지원하지 않는 경우 시스템은 자동으로 HTTP/2/HTTP/1.1로 대체되어야 합니다. 가용성을 유지하기 위해.
  • 패킷 손실 시 QUIC의 전송 및 혼잡 제어는 종종 엔드투엔드 처리량에 대한 HOL 차단의 영향을 줄여 안정성을 향상시킬 수 있습니다(결과는 네트워크 상태에 따라 다름).
  • 0-RTT/더 빠른 핸드셰이크 경로는 특정 조건에서 세션 재개 기능입니다. 조건이 충족되면 시스템이 이점을 얻을 수 있지만 이를 유일한 성능 수단으로 의존해서는 안 됩니다.

확인 방법

  • 브라우저 DevTools(예: 네트워크/프로토콜, UI는 브라우저에 따라 다름)에서 요청이 h3(HTTP/3)을 사용하는지 아니면 h2/h1로 대체되는지 관찰할 수 있습니다.
  • 동일한 네트워크 조건에서 h3과 비h3 연결 설정 및 처리량 안정성(특히 RTT/손실이 높은 경우)을 비교하면 눈에 띄게 다를 수 있습니다.

1.3 극도의 동시성: 청크 스트리밍(Chunked Streaming)

  • 시스템은 대용량 파일을 논리적으로 여러 청크로 분할해야 합니다. 각 청크는 업로드/재시도/복구를 위한 최소 단위입니다(2장 참조).
  • 클라이언트는 제한된 동시성(예: 여러 병렬 파이프라인)으로 여러 청크를 전송하여 대역폭 한도에 더 가까워지고 단일 연결 지터에 대한 민감도를 줄여야 합니다.
  • 클라이언트는 재개 가능한 전송을 지원해야 합니다. 복구 시 완료된 청크를 건너뛰고 누락된 청크만 가져와서 전체 파일 재전송을 방지해야 합니다(2장 참조).
  • 동시성 및 청킹은 단일 요청 차단(헤드 오브 라인 및 재전송 대기 포함)으로 인한 대기를 크게 줄입니다. 그러나 특정 네트워크 현상을 "완전히 제거"한다고 주장해서는 안 됩니다. 목표는 영향을 줄이고 안정적인 처리량을 향상시키는 것입니다.

확인 방법

  • 네트워크 패널에서는 동시에 여러 개의 병렬 업로드/다운로드 요청을 관찰할 수 있습니다(청크 동시성).
  • 네트워크 연결을 끊거나 페이지를 새로 고친 후 전송 재개는 0%에서 다시 시작되어서는 안 됩니다(누락된 청크만 완료됨).

1.4 토폴로지 이점: Anycast 최근접 에지 액세스(에지 네트워크)

  • 시스템은 지역 간 홉으로 인해 발생하는 RTT 및 대기 시간/지터를 줄이기 위해 Anycast/에지 수신을 통해 가장 가까운 노드로 사용자 요청을 라우팅해야 합니다.
  • 가장 가까운 가장자리 액세스는 병렬 청킹의 전반적인 효율성을 향상시킵니다. RTT가 낮을수록 일반적으로 각 동시 흐름의 유효 처리량 한도가 높아져 링크가 더 쉽게 포화됩니다.
  • 인프라가 발전함에 따라 엣지 적용 범위와 위치 수가 변경될 수 있습니다. 외부적으로는 이를 "가장자리 적용 범위/가장 가까운 수신"으로 설명하고 숫자를 엄격한 보장이 아닌 지침으로 취급합니다.

확인 방법

  • Traceroute 또는 브라우저 연결 정보를 사용하면 더 가까운 수신에서 연결이 종료되는 것을 종종 관찰할 수 있습니다(방법은 환경에 따라 다름).
  • 지역 간 비교(예: US‐EU / JP‐US)에서는 일반적으로 RTT 감소가 가장 눈에 띕니다.

1.5 다중 소스 동시성: 지능형 스케줄링(다중 소스)

  • 시스템은 링크 품질 신호(처리량, 지연 시간, 오류율 등)를 기반으로 동적인 선택을 해야 합니다. 따라서 서로 다른 청크를 더 나은 여러 노드/배치에 할당할 수 있습니다. 단일 지점 혼잡이 전체 처리량에 미치는 영향을 줄입니다.
  • 다운로드 시 클라이언트는 "다중 소스 풀" 가속 효과를 위해 여러 소스에서 동시에 다양한 청크를 가져올 수 있습니다. 다중 소스를 사용할 수 없는 경우 자동으로 단일 소스 다운로드로 저하되어야 합니다. 가용성을 유지합니다(3장 참조).
  • 이것을 "AI"라고 마케팅하는 경우 일정 및 의사 결정을 위한 알고리즘 시스템으로 구성하고 모호한 주장을 피하기 위해 입력/출력 및 성능 저하 동작을 명확하게 정의하는 것이 가장 좋습니다.

확인 방법

  • 다운로드하는 동안 다양한 소스/연결의 동시 요청을 관찰할 수 있습니다(구현 및 브라우저 가시성에 따라 다름).
  • 혼잡이나 손실이 있는 경우 다중 소스 동시성은 종종 안정적인 처리량을 제공합니다. 조건이 충족되지 않으면 자동으로 성능이 저하되지만 계속 사용할 수 있습니다.

1.6 이것이 다음 장과 어떻게 연결되는지

  • 2장에서는 "청킹, 동시성, 멱등성 및 재개 가능한 업로드"를 구현 가능한 흐름 및 제약 조건(MUST/SHOULD/MAY)으로 확장하고 업로드 속도와 안정성을 직접 결정하는 이유를 설명합니다.
  • 3장에서는 "병렬 다운로드, 복구 및 재조립"에 대해 설명하고 약한 네트워크에서 중복 다운로드로 인한 속도 손실을 방지하는 방법을 설명합니다.
  • 4장에서는 성능 및 복구 가능성(객체 대 상태 계층, TTL/삭제 의미 체계)과 관련된 최소 저장소 모델만 유지합니다.