프록시 두 개로 파일 하나를 더 빨리 내려받을 수 있을까?

각각 여유 대역폭이 있는 두 개의 프록시 출구는 다운로드 속도를 두 배로 높이는 쉬운 방법처럼 보인다. 하지만 일반적인 프록시 풀은 그렇게 동작하지 않는다.

클라이언트는 선택한 한 프록시를 통해 연결을 연다. 그 프록시가 다음 연결을 연다. 프록시 목록에서 다른 주소를 풀에 추가하면 앞으로의 연결에 선택지가 하나 더 생길 뿐, 이미 진행 중인 바이트 스트림에 두 번째 프록시를 이어 붙이지는 않는다.

연결 단위의 일반적인 멀티 WAN 부하 분산도 같은 한계를 가진다. 서로 다른 연결을 여러 링크에 나눠 전체 용량을 높이거나 경합을 줄일 수 있다. 다른 방식이 여러 경로를 명시적으로 제공하지 않는 한 하나의 연결은 하나의 연결로 남는다.

병렬 다운로드가 다른 문제일 때

클라이언트는 한 파일의 서로 다른 구간을 별도 연결로 요청해 로컬에서 조립할 수 있다. 클라이언트가 이 구성을 지원하고 서버가 요청을 허용한다면 하나 이상의 경로를 쓸 수 있다.

여기에는 조건이 따른다. 구간은 같은 표현을 설명해야 하고, 서버의 응답은 요청한 오프셋과 맞아야 하며, 객체의 변경이 뒤섞인 파일을 만들어서는 안 된다. 인증, 서버 제한, 출구별 정책도 병렬 구간 요청을 부적절하게 만들 수 있다. 완전한 다운로드 열 번은 한 번의 다운로드 조각 열 개가 아니다.

클라이언트까지의 마지막 경로는 여전히 중요하다. 빠른 출구 여러 개라도 포화된 접속 회선 하나로 그 회선이 감당할 수 있는 것보다 많은 데이터를 보낼 수는 없다.

멀티패스에는 실제 지원이 필요하다

Multipath TCP는 끝점과 네트워크 구성이 지원할 때 여러 하위 흐름으로 하나의 연결을 실어 나를 수 있는 명시적 전송 기법이다. 서로 무관한 HTTP나 SOCKS 프록시 두 개를 나열하는 것만으로 켜지지는 않는다.

느린 전송에서는 먼저 한계가 클라이언트 회선, 프록시, 다음 경로, 목적지 중 어디에 있는지 파악한다. 풀은 연결 분산에 유용하다. 한 파일의 속도가 두 배가 된다는 주장은 자체 기법과 증거가 필요한 별개 기능으로 다뤄야 한다.