프록시 사용 한도

제공업체가 제한할 수 있는 항목

어떤 한도는 일정 기간 소비하는 자원을 설명합니다. 다른 한도는 특정 순간의 부하를 제어하거나 연결 자체를 허용할지 결정합니다. 요금제가 이 중 한두 항목만 광고해도 다음 구분은 유용합니다.

제공업체는 이 규칙으로 네트워크 용량과 처리 자원을 배분하고 비용을 관리하며 원치 않는 활동을 제한합니다. 효과는 서로 다릅니다. 연결 한도를 높이면 동시에 더 많이 연결할 수 있고, 차단 대상의 접속 허용은 수행 가능한 작업을 바꿉니다. 조건 하나를 바꾼다고 나머지가 자동으로 바뀌지는 않습니다.

동시 연결

동시 연결 한도는 한꺼번에 열려 있을 수 있는 연결 수를 정합니다. 브라우저나 다른 애플리케이션은 작업 하나에 여러 연결을 열 수 있습니다. 따라서 탭, 프로필, 프로그램 스레드 수만으로 허용량 사용을 정확히 알 수 없습니다.

요청 사이에도 연결이 열려 있을 수 있고 HTTP/2는 연결 하나로 여러 요청을 전달할 수 있습니다. 분당 요청을 줄여도 점유한 연결이 반드시 해제되지는 않습니다. 동시 연결 문서에서 허용량을 차지하는 요소와 요청 수와의 차이를 설명합니다.

한도는 서로 영향을 줄 수 있습니다. 큰 응답의 전송이 길어지면 연결도 더 오래 점유될 수 있습니다. 프로그램이 새 작업을 계속 시작하면 요청 빈도가 같아도 연결 한도에 도달할 수 있습니다. 이때 병렬 작업을 늘리면 완료 처리량은 늘지 않고 대기와 실패가 늘어날 수 있습니다.

차단된 웹사이트와 앱

제공업체는 특정 웹사이트, 주소, 작업을 제한할 수 있습니다. 트래픽이 무제한이고 연결 용량이 남아도 대상이 차단 목록에 있을 수 있습니다. 같은 업체 상품끼리도 접속 조건이 다를 수 있습니다. 차단된 웹사이트와 앱 문서는 목록이 생기는 이유와 특정 자원의 접속 조건을 설명합니다.

애플리케이션은 여러 대상에 접속할 수 있어 기본 페이지는 열려도 별도 기능은 실패할 수 있습니다. 프록시 제공업체가 허용해도 대상 사이트 자체의 제한이 있을 수 있습니다. 장애를 이해하려면 먼저 어떤 자원이 안 되는지와 어느 쪽이 거부했는지 확인하세요.

차단된 포트

웹사이트가 열린다고 같은 서버의 모든 네트워크 서비스에 접속할 수 있는 것은 아닙니다. 제공업체는 웹 트래픽은 허용하면서 메일 제출 포트는 막을 수 있습니다. 여기서 중요한 것은 애플리케이션이 요청하는 목적지 포트입니다. 차단된 포트 문서에서 프록시 자체에 연결하는 포트와의 차이를 설명합니다.

전송 방식 지원도 허용 조건의 일부입니다. TCP와 UDP는 서로 다른 전달 방식이며 특정 번호의 TCP 포트에 접속할 수 있다고 같은 UDP 포트도 가능한 것은 아닙니다. 상품이 필요한 방식을 지원하고 허용해야 합니다. IP나 연결 허용량을 늘려도 없는 권한을 만들지는 못합니다.

전송량, 전송 속도, 요청 수

전송량

트래픽은 업체와 상품에 따라 무제한이거나 데이터 허용량으로 판매됩니다. 일부는 월 GB 패키지처럼 고정 데이터 양을 판매합니다. 이런 패키지는 유효 기간, 허용량 초기화 시점, 미사용 데이터 이월 여부를 확인하세요. 이는 데이터 허용량 상품의 집계 규칙이며 모든 프록시 접속의 공통 조건은 아닙니다.

저장 결과의 크기로 트래픽을 정확히 예측할 수는 없습니다. 짧은 가격이나 상품명을 추출하려고 전체 페이지를 다운로드해야 할 수 있습니다. 브라우저는 이미지, 스크립트, 다른 파일도 요청합니다. 재시도에서는 데이터를 다시 전송할 수 있습니다. 실제 애플리케이션을 측정하면 네트워크 부하를 예측하는 데 도움이 됩니다. 전송량 과금 상품이라면 업체가 어떤 바이트를 세는지도 확인하세요.

전송 속도

전송률 한도는 단위 시간에 통과할 수 있는 데이터 양을 제어합니다. 보통 Mbps 같은 초당 비트나 MB/s 같은 초당 바이트로 표시합니다. 1바이트는 8비트이므로 프로토콜 부가 데이터를 제외하면 80 Mbps는 10 MB/s에 해당합니다. 이는 속도 단위이며 GB로 표시한 월 허용량은 다른 질문에 답합니다.

광고 속도의 적용 범위가 중요합니다. 서버 포트의 정격 속도가 모든 고객이나 연결에 제공되는 속도를 뜻하지는 않습니다. 여러 전송이 하나의 허용량을 나눌 수 있습니다. 실제 속도는 경로, 대상 서버, 클라이언트 자신의 연결에도 좌우되므로 명시된 상한이 모든 다운로드의 보장 결과는 아닙니다.

전송 속도와 함께 응답 시간도 중요합니다. 바이트를 보낼 용량이 충분해도 서버가 작은 응답을 보내기 전에 애플리케이션을 기다리게 할 수 있습니다. 큰 다운로드는 지속 전송률에 민감하며, 짧은 요청이 많은 작업은 응답 지연과 허용 요청 빈도의 영향을 더 받을 수 있습니다.

요청 허용량과 요청 빈도

요청 허용량은 포함된 집계 작업 수를 정합니다. 요청 빈도 한도는 얼마나 촘촘히 보낼 수 있는지를 정합니다. 잔액이 많아도 짧은 순간에 모두 써도 된다는 뜻은 아닙니다. 전송량으로 과금하지 않는 상품에서도 두 한도는 독립적으로 존재할 수 있습니다.

무엇을 작업 하나로 세는지도 명확해야 합니다. 클릭, 페이지 방문, HTTP 요청, 완료된 수집 작업은 서로 다릅니다. 페이지 방문 하나가 많은 HTTP 요청을 만들고, 관리형 API 작업 하나에 업체의 여러 시도가 포함될 수 있습니다. 고객 허용량 차감 여부는 상품의 집계 규칙에 달려 있습니다.

빈도 제한에는 시간 창과 짧은 집중 전송의 규칙도 있습니다. 분당 한도를 60으로 나누면 평균은 나오지만 한 번에 보낸 묶음의 처리 방식은 알 수 없습니다. 허용된 작업을 시간에 걸쳐 분산하면 총량을 바꾸지 않고 빈도 한도에 맞출 수 있지만 이미 소비한 요청 허용량이 복구되지는 않습니다.

어느 계정, IP, 상품이 한도를 공유하는가

숫자는 누가 공유하는지 알아야 유용합니다. 업체는 계정, 주문, 개별 프록시 IP, 허가된 클라이언트 IP, 다른 정의된 그룹에 한도를 적용할 수 있습니다. 예를 들어 계정의 전체 전송률 허용량은 해당 계정을 쓰는 프로그램이 나눕니다. 프로그램별 출구 IP를 달리해도 각자 별도 허용량이 생기지는 않습니다.

여러 단계가 함께 적용될 수 있습니다. 프록시 IP마다 최대치를 정하고 패키지 전체에도 두 번째 최대치를 둘 수 있습니다. IP에 작업을 나누면 첫 제약에는 도움이 되지만 패키지 전체 한도는 남습니다. 클라이언트 공인 IP에 적용되는 한도 역시 그 주소로 인터넷에 나가는 여러 기기가 공유할 수 있습니다.

상품 규칙도 중요합니다. 같은 업체의 직접 프록시 연결, 관리형 수집 API, 다른 판매 네트워크는 허용량과 권한이 다를 수 있습니다. API 집계 단위는 네트워크 연결이 아니라 작업이나 결과일 수 있습니다. 계정 전용 설정을 포함해 실제 사용할 상품의 한도를 읽으세요.

한도 도달 시 동작

서비스 대응은 규칙에 따라 달라집니다. 전송률 상한에서는 제한 속도로 데이터가 계속 흐를 수 있습니다. 요청 빈도 초과 작업은 대기하거나 거부될 수 있습니다. 연결 한도에서는 기존 연결을 유지하면서 새 연결을 거부할 수 있습니다. 트래픽이나 요청 허용량 상품에서 허용량을 소진하면 갱신이나 추가 구매가 필요할 수 있으며 선택지는 업체 약관에 따릅니다.

따라서 “무제한”에는 트래픽, 요청, 연결처럼 대상이 필요합니다. 각각 하나의 항목을 설명합니다. 무제한 트래픽 요금제에도 유한한 전송 속도와 연결 한도가 있을 수 있습니다. 지속적인 과다 사용 후 허용량을 바꾸는 공정 사용 조건이 있다면 그것도 요금제의 일부입니다. 단어 하나로 전체 규칙이 정의되지는 않습니다.

일반적인 실패보다 업체의 명시적인 메시지가 유용합니다. HTTP 429는 응답 서비스가 자체 규칙상 요청 수가 너무 많다고 판단했음을 뜻합니다. 먼저 응답이 프록시 서비스와 대상 중 어디에서 왔는지 확인하세요. 시간 초과는 느린 대상이나 네트워크 장애 등 다른 원인도 있습니다. 사용 통계, 오류 내용, 시도 시간이 할당량 문제와 다른 장애를 구분하게 합니다.

거부된 작업을 계속 재전송하면 빈도 문제가 심해지고 허용량이 추가 소모될 수 있습니다. 알려진 조건을 직접 바꾸세요. 전송 빈도를 줄이고 불필요한 연결을 닫거나 소진한 허용량을 추가하거나 대상 접속 권한을 확인합니다. 일반적인 패키지 업그레이드는 해당 조건을 바꿀 때만 도움이 됩니다.

전체 작업에 한도 맞추기

필요한 결과와 마감 시간부터 정하세요. 예를 들어 HTTP 요청 6,000개를 30분 안에 보내며 평균 응답이 0.5 MB라고 가정할 수 있습니다. 평균 분당 200개 요청과 십진 단위 약 3 GB의 응답 데이터입니다. 발신 데이터, 추가 브라우저 자원, 재시도는 제외한 계산입니다. 실제 작업에서 발생하고 서비스가 집계한다면 포함해야 합니다.

이 총량만으로 필요한 연결 허용량을 알 수는 없습니다. 애플리케이션의 실제 병렬 활동과 연결 점유 시간을 테스트하세요. 같은 한도를 공유하는 다른 프로그램과 동시에 작업을 시작할 때의 순간 부하도 넣으세요. 전송량, 요청 빈도, 동시 연결은 별도로 측정해야 하며 하나의 계수가 셋 모두를 대신할 수는 없습니다.

실제 사용할 상품과 대상에서 작업 완료에 필요한 기능까지 테스트하세요. 작은 확인의 성공은 한 작업이 작동했다는 뜻입니다. 대표 실행은 지속 부하, 최고 부하, 전체 작업 자원에 관한 증거를 더합니다. 평균을 안전한 최대치로 보지 말고 테스트에서 관측한 변동에 대비한 여유를 두세요.

요구가 불명확하면 지원팀에 구체적으로 설명하세요. 상품, 대상 호스트, 목적지 포트와 전송 방식, 예상 전송량, 요청 빈도, 최대 연결 수, 정확한 오류를 제시하면 관련 허용량이나 권한을 확인할 수 있습니다. 필요한 결과는 명시된 서비스 한도와 예정 작업 부하가 맞는지 확인하는 것입니다.