“Backconnect(백커넥트)“은 프록시 문서에 정의 없이 등장하는 용어 중 하나이다. 대개 이를 작성한 사람들이 이 용어가 한때 낯설었다는 사실을 잊었기 때문이다. 이 용어는 하나의 아키텍처를 설명하며, 그 아키텍처를 이해하고 나면 나머지 제품 특성도 이해가 된다. 왜 설정할 주소가 단 하나뿐인지, 왜 타겟팅 정보가 사용자 이름(username)에 담기는지, 왜 HTTP 클라이언트가 겉으로는 아무 문제 없어 보이면서도 조용히 로테이션을 깨뜨릴 수 있는지 말이다.
이름의 유래
과거 모델은 목록이었다. 프록시 세트를 구매하면 주소와 포트가 담긴 파일을 받았고, 코드는 각각에 직접 연결했다. 이를 관리하는 것은 사용자의 몫이었다. 어떤 것이 살아있는지, 어떤 것이 어떤 타겟에서 차단되었는지, 부하를 어떻게 분산할지, 목록이 바뀌면 어떻게 할지 등이다.
백커넥트는 이를 뒤집는다. 사용자는 단일 게이트웨이 주소에 연결하고, 게이트웨이가 자신을 대신해 네트워크 내 수많은 노드 중 하나를 통해 외부로 다시 연결한다. 사용자는 종료(exit) 주소를 미리 알 수 없고 목록을 관리할 필요도 없는데, 라우팅 결정이 요청 시점에 제공자 측에서 이루어지기 때문이다. 이것이 핵심 개념이다. 하나의 안정적인 정문과 여러 개의 회전하는 뒷문.
실무에서 “백커넥트 프록시”, “로테이팅 프록시”, “게이트웨이 프록시”는 오늘날 거의 같은 의미로 사용되며, 백커넥트는 아키텍처를 강조하고 로테이팅은 그로 인한 동작을 강조한다.
단일 요청에서 일어나는 일
구체적으로, 클라이언트가 백커넥트 게이트웨이를 통해 요청을 보낼 때:
- 클라이언트는 게이트웨이
p.shifter.io:443에 연결을 열고 사용자 이름과 비밀번호로 인증한다. - 게이트웨이는 사용자 이름을 파싱하는데, 여기에는 신원 이상의 정보가 담겨 있다. 국가, 지역, 도시, ASN에 대한 타겟팅 플래그와 세션 식별자, TTL이 그 안에 인코딩되어 있다.
- 게이트웨이는 현재 사용 가능한 풀에서 해당 조건에 맞는 종료 노드를 선택한다. “사용 가능한”이 핵심어인 이유는, 제공자가 풀을 구축하고 갱신하는 방법에서 다루듯 이 풀 자체가 지속적으로 교체되는 모집단이기 때문이다.
- 게이트웨이는 그 노드를 통해 요청을 전달하므로, 타겟은 사용자나 게이트웨이의 주소가 아니라 해당 노드의 레지덴셜 주소를 보게 된다.
- 응답은 같은 경로로 되돌아온다.
세션 식별자를 지정했다면, 게이트웨이는 그 매핑을 기억하고 해당 식별자를 가진 후속 요청들을 TTL이 만료되거나 노드가 탈락할 때까지 같은 노드로 라우팅한다. 지정하지 않았다면, 다음 요청은 독립적으로 선택된 종료 노드를 받는다.
이것이 타겟팅 정보가 사용자 이름에 담기는 이유이다. 엔드포인트가 단 하나뿐이므로, 요청별 지시사항은 터널이 수립되기 전에 프록시 프로토콜이 제공하는 유일한 요청별 필드를 통해 전달되어야 한다.
# same host and port, different behaviour, expressed entirely in the username
curl -x customer-USERNAME:PASSWORD@p.shifter.io:443 https://ipinfo.io/json
curl -x customer-USERNAME-country-de:PASSWORD@p.shifter.io:443 https://ipinfo.io/json
curl -x customer-USERNAME-country-de-sid-abc123-ttl-600:PASSWORD@p.shifter.io:443 https://ipinfo.io/json코드에서 바뀌는 점
이 아키텍처로부터 세 가지 실질적인 결과가 따라오며, 그중 첫 번째가 이 제품에서 가장 많은 혼란을 일으킨다.
로테이션은 요청 단위가 아니라 연결 단위로 일어난다. 종료 노드는 게이트웨이로의 터널이 수립될 때 선택된다. 최신 HTTP 클라이언트는 연결을 유지하고 재사용하므로, 클라이언트가 하나의 풀링된 연결로 10개의 요청을 보내면 그 10개 모두 같은 종료 노드를 통해 나가며, 마치 로테이션이 고장 난 것처럼 보인다. 그러나 이는 고장이 아니라, 클라이언트가 설계된 대로 동작하는 것이다. 해결책과 진단법은 IP not rotating에 나와 있으며, 짧게 요약하면 별도의 프로세스로 실행되는 curl 루프는 로테이션이 되지만 공유된 세션 객체는 그렇지 않다는 것이다.
관리할 IP 목록도, 탓할 IP도 없다. 상태(health)는 차단 목록에 추가할 수 있는 주소의 속성이 아니라, 타겟과 지리적 조건을 합친 경로(route)의 속성이자 세션의 속성이다. 이는 모니터링과 장애 처리 방식 자체를 재구성하며, 자세한 내용은 대규모 프록시 상태 모니터링에 나와 있다.
설정은 정적이고, 동작은 동적이다. 호스트와 포트는 절대 바뀌지 않으므로, 작업을 로테이팅 미국 종료 노드에서 고정된 독일 노드로 전환하는 것은 재배포가 아니라 문자열 변경만으로 가능하다. 이것이 다중 시장 데이터 수집을 인프라 프로젝트가 아니라 설정의 문제로 만드는 이유이다.
백커넥트 대 포트 목록 모델
과거 모델은 여전히 존재하며, 업계가 왜 이동했는지 설명해준다는 점에서 비교는 유용하다.
포트 목록 방식에서는 자신의 주소를 알고 있었는데, 이는 장점처럼 들리지만 대체로 그렇지 않다. 생존 여부 확인, 부하 분산, 교체 작업을 떠안게 되고, 용량은 수요에 따라 유연하게 변하는 것이 아니라 고정된 포트 수였다. 가격 책정도 같은 형태를 따라 작업 단위가 아니라 포트당 과금되었는데, 이는 포트당 과금 시대가 끝난 이유에서 다룬 모델이다.
백커넥트에서는 종료 노드를 미리 아는 대신 이를 관리할 필요가 없어진다. 용량은 몇 개의 포트를 구매했는지가 아니라 대역폭과 동시성의 문제가 되며, 로테이션은 직접 구현해야 하는 것이 아니라 하나의 파라미터가 된다.
여전히 과거 방식이 유리한 경우는 같은 주소가 진짜로 지속되어야 할 때인데, 이것이 바로 고정 ISP 프록시가 존재하는 이유이며 ISP 대 레지덴셜에서 다룬다.
백커넥트 게이트웨이 내부의 스티키 세션
스티키 세션은 있는 그대로 이해할 가치가 있다. 이는 사용자가 소유하는 할당이 아니라 게이트웨이가 보유하는 매핑이다.
식별자를 선택하면 게이트웨이는 이를 종료 노드와 연결하고, 그 식별자를 가진 요청들은 TTL이 만료될 때까지 같은 경로를 따른다. 노드는 실제 가정용 기기이기 때문에 TTL이 만료되기 전에 사라질 수도 있으며, 이 때문에 스티키 세션은 임대(lease)가 아니라 최선의 노력(best effort)에 가깝다. 시퀀스 도중 주소가 바뀌는 것을 정상적인 이벤트가 아니라 오류로 취급하는 코드는 제공자와 무관한 이유로 불안정하게 동작할 것이다. 이 동작은 스티키 대 로테이팅에서, 근본적인 교체 원리는 로테이션 작동 방식에서 다룬다.
결론
백커넥트는 하나의 엔드포인트에 연결하면 그것이 다시 여러 곳으로 연결되어, 현재 사용 가능한 것 중에서 요청별로 종료 노드를 선택한다는 의미이다. 이 아키텍처 때문에 호스트와 포트가 단 하나뿐이고, 국가, 도시, 세션, TTL이 사용자 이름에 인코딩되며, 주소 목록을 관리할 필요가 없다. 이는 또한 이 제품에서 가장 흔한 혼란의 원인도 설명해준다. 로테이션은 연결이 수립되는 시점에 결정되므로, 풀링된 연결을 재사용하는 HTTP 클라이언트는 모든 요청을 같은 종료 노드로 보내고 마치 로테이션이 실패하는 것처럼 보인다. 종료 노드를 일시적인 것으로, 세션을 할당이 아닌 매핑으로, 상태를 경로의 속성으로 취급하면 이 아키텍처는 더 이상 놀랍지 않게 된다.
그 게이트웨이는 레지덴셜 프록시로 향하는 전체 인터페이스이다. 하나의 호스트, 하나의 자격 증명 쌍으로 로테이션, 지리적 위치, 세션 동작이 요청별로 표현되며 포트당이 아니라 GB당 과금된다. 용어가 낯설다면 용어집에서 나머지를 확인할 수 있다.