동시 연결 수

연결의 의미와 작동 원리

네트워크 연결은 두 프로그램이 데이터를 주고받으려고 설정하는 통신 경로입니다. 예를 들어 브라우저는 웹 서버에 연결해 페이지를 요청하고 내용을 받습니다. 연결은 교환 경로를 제공하고 요청과 응답은 그 경로로 보내는 메시지입니다.

일반적인 TCP 연결을 살펴보겠습니다. 애플리케이션이 서버 IP와 필요한 서비스의 포트에 접속합니다. 양쪽이 제어 메시지를 교환해 연결을 설정합니다. 이후 데이터는 패킷이라는 작은 단위로 이동합니다. TCP는 전달을 추적하고 유실 데이터를 재전송하며 수신자에게 올바른 순서로 제공합니다. 연결이 존재하는 동안 양쪽 모두 교환 정보를 유지합니다.

일반적인 TCP 프록시에서는 애플리케이션이 먼저 프록시 서버에 연결합니다. 프록시는 대상 웹사이트에 별도 연결을 만들고 두 연결 사이에서 데이터를 양방향으로 전달합니다. 따라서 클라이언트와 대상 양쪽의 통신을 유지합니다.

애플리케이션은 요청을 보내고 응답을 받은 뒤 같은 연결로 다른 교환을 할 수 있습니다. 예를 들어 페이지를 받았다고 반드시 연결이 닫히는 것은 아닙니다. 브라우저가 후속 요청을 위해 유지할 수 있습니다. 필요가 없어지면 한쪽이 닫고 오류나 시간 초과로 끝날 수도 있습니다. 닫히기 전까지 계속 데이터를 보내지 않아도 연결은 존재할 수 있습니다.

프로그램은 한 연결로 데이터를 받으면서 다른 연결의 응답을 기다리고 세 번째는 다음 요청용으로 유지하는 등 여러 연결을 동시에 둘 수 있습니다. 이것이 동시 연결입니다. 수치는 프로그램 시작 후 누적 요청 수가 아니라 그 순간 열려 있는 통신 채널 수를 나타냅니다.

제한이 측정하는 것

열린 연결은 해당 허용량의 한 자리를 차지합니다. 닫힌 뒤 서비스가 집계에서 제거하면 그 자리를 다시 사용할 수 있습니다. 현재 활동에 대한 제한이므로 상한에 도달해도 월별 연결 잔액을 소모한 것은 아닙니다.

고객의 허용량에 연결을 어떻게 집계하는지는 서비스의 별도 규칙입니다. 프록시에서 네트워크 구간이 둘이라고 할당량 두 단위를 자동으로 소모하는 것은 아닙니다.

데이터를 적게 전송해도 열린 연결은 서버 자원을 사용하므로 업체가 제한합니다. 응답을 기다리는 연결도 유지해야 합니다. 수를 통제하면 지원하기로 한 작업에 충분한 용량을 남기는 데 도움이 됩니다.

같은 서비스에 여러 제한이 적용될 수 있습니다.

따라서 무제한 트래픽만으로 동시 연결 수는 알 수 없습니다. 새 연결을 여는 속도에도 별도 제한이 있을 수 있습니다. 빠르게 열고 닫으면 어느 순간에도 열린 연결이 적더라도 그 제한에 도달할 수 있습니다.

스레드 수와 연결 수가 다른 이유

애플리케이션의 스레드나 워커 수는 작업 구성 방식을 설명합니다. 프록시가 집계할 연결 수를 확실히 알려 주지는 않습니다. 작업 하나가 여러 서버에 접속할 수 있고, 비동기 스크립트는 네트워크 작업마다 별도 운영체제 스레드를 만들지 않고도 많은 작업을 관리할 수 있습니다.

모든 HTTP 요청에 새 연결이 필요한 것도 아닙니다. 클라이언트는 기존 연결을 재사용할 수 있고 HTTP/2는 한 연결에서 여러 요청을 동시에 처리할 수 있습니다. 따라서 요청 수와 연결 수는 다릅니다.

업체의 용어도 중요합니다. ‘스레드’나 ‘세션’ 제한이 열린 연결 또는 처리 중 요청을 뜻할 수 있습니다. 관련 요청의 프록시 IP를 유지하는 고정 세션이 반드시 네트워크 연결 하나를 뜻하지는 않습니다. 실제 서비스가 무엇을 집계하는지가 중요한 정의입니다.

어떤 프로그램이 허용량을 공유하나요?

제한은 계정, 구매 패키지, 개별 프록시 IP, 특정 게이트웨이에 적용될 수 있습니다. 계정이나 패키지 제한이라면 이를 쓰는 모든 프로그램과 기기의 연결을 합산하세요. IP 목록을 여러 컴퓨터에 나눠도 컴퓨터마다 별도 할당량이 생기지는 않습니다.

IP별 제한은 분배가 다릅니다. 바쁜 주소 하나는 상한에 도달해도 다른 주소에는 여유가 있을 수 있습니다. 서비스에 더 낮은 공유 제한이 없다면 작업 일부를 두 번째 주소로 옮기면 도움이 됩니다. 패키지에 전체 허용량과 이용자별·클라이언트 IP별의 더 작은 할당량이 함께 있을 수도 있습니다.

인증을 허용하는 클라이언트 IP 수는 또 다른 설정입니다. 어느 네트워크가 프록시에 접속할 수 있는지를 제어하며 열 수 있는 연결 수를 정하지 않습니다. 공인 IP 하나 뒤의 여러 기기는 접속 규칙과 그 IP에 연결된 연결 할당량을 함께 쓸 수 있습니다.

웹사이트에 보이는 프록시 IP를 바꿔도 계정 전체의 연결 허용량이 초기화되지는 않습니다. 고정 세션 이름이나 프로토콜을 바꿔도 자동으로 용량이 늘지 않습니다. 제한은 업체가 집계에 쓰는 계정, 패키지, 엔드포인트에 계속 적용됩니다.

연결이 쌓이는 이유

기존 연결이 닫히는 속도보다 새 연결이 빠르게 열리면 쌓입니다. 페이지 로딩, 파일 다운로드, 여러 네트워크 작업의 병렬 실행 중 발생할 수 있습니다. 일부 연결은 전송 중이거나 응답을 기다리는데 애플리케이션이 추가 연결을 여는 것입니다. 이 연결들이 동시에 집계돼 프록시 연결 한도를 모두 채울 수 있습니다.

응답이 느리면 연결을 더 오래 차지합니다. 프로그램이 같은 속도로 새 작업을 시작하면 미완료 작업이 쌓입니다. 병렬 활동을 고정 수준으로 유지하면 웹사이트가 느릴수록 보통 분당 완료 작업이 줄어듭니다. 두 상황 모두 프록시 패키지 변경 없이 발생할 수 있습니다.

긴 다운로드와 시간 초과를 기다리는 연결도 같은 영향을 줄 수 있습니다. 따라서 열린 연결은 많은데 전송 속도는 낮을 수 있습니다. 데이터를 옮기는 대신 기다리는 시간이 많기 때문입니다.

요청 사이에 일부 연결은 의도적으로 유지됩니다. 보통 keep-alive라고 합니다. 매번 새 연결 설정을 피하지만 열린 연결을 집계하는 서비스에서는 유휴 연결도 자리를 차지할 수 있습니다. 애플리케이션 풀에 반환된 연결은 재사용 가능 상태이며 프록시에서 반드시 닫힌 것은 아닙니다.

연결 정리 오류는 별도 문제입니다. 자체 스크립트뿐 아니라 완제품 소프트웨어에서도 생길 수 있습니다. 예를 들어 응답을 읽다가 오류가 나자 기존 응답을 마치거나 닫지 않고 새 요청을 시작할 수 있습니다. 기존 연결은 점유된 채 새 연결만 계속 열리면 유용한 작업 증가 없이 허용량을 소진할 수 있습니다. 성공한 요청뿐 아니라 오류와 취소 뒤의 정리도 확인해야 하는 이유입니다.

올바르게 정리하면 적합한 연결을 재사용하거나 불필요한 연결을 닫을 수 있습니다. 시간 제한은 버려진 작업이 끝없이 기다리지 않게 합니다. 모든 재사용을 끄는 것은 일반적인 해결책이 아닙니다. 연결 설정 작업과 새 연결 생성 빈도를 늘릴 수 있습니다. 목표는 재사용 가능한 연결 수를 통제하고 불필요한 연결을 제대로 반환하거나 닫는 것입니다.

작동하다 멈추고 다시 작동하는 것처럼 보이는 이유

부하가 높을 때 간헐적으로 실패한다면 연결 제한을 먼저 확인할 필요가 있습니다. 어떤 주소는 작동하고 다른 주소는 실패하다 잠시 후 양상이 바뀝니다. 애플리케이션 입장에서는 목록의 서로 다른 부분이 번갈아 끊기는 것처럼 보일 수 있습니다.

공유 허용량이 꽉 찬 것이 한 설명입니다. 기존 연결은 계속되지만 새 연결은 거부되거나 기다릴 수 있습니다. 앞선 연결이 닫히면 일부 새 시도가 통과합니다. 빈자리가 다시 차면 다른 시도가 실패합니다. 고장 난 IP가 정해져 있는 것이 아니라 같은 허용량을 두고 경쟁해 결과가 바뀌는 것입니다.

이 동작을 스로틀링이라고도 합니다. 여기서는 새 연결의 수용을 제한하며 이미 설정된 모든 연결의 속도를 반드시 낮추지는 않습니다. 정확한 응답은 서비스에 따라 다릅니다. 명확한 한도 메시지, 연결 거부, 클라이언트 시간 초과 등이 있을 수 있습니다. 대기열은 보장되지 않습니다.

이 설명을 확인하려면 오류와 연결 수를 비교하고 같은 할당량을 공유하는 프로그램 전체의 병렬 활동을 일시적으로 줄이세요. 한도 아래에서 실패가 멈추고 다시 차면 재발한다면 연결 상한이 원인일 가능성이 큽니다. 비슷한 중단이 대상 사이트나 네트워크에서도 발생할 수 있습니다. 시간 초과나 HTTP 429, 502, 503 응답만으로 프록시 연결 한도 도달을 입증할 수는 없습니다. 오류의 출처와 문구가 중요합니다.

한도 안에서 유용한 작업을 유지하는 방법

실제 필요한 사이트와 동작으로 시작하세요. 병렬 활동을 조금씩 늘리고 성공 결과, 응답 시간, 연결 최고치를 관찰하세요. 빠른 페이지의 짧은 테스트는 로그인, 큰 응답, 느린 엔드포인트가 포함된 전체 실행을 대표하지 못할 수 있습니다.

1. 모든 프로그램에 공통 연결 예산을 배분하세요. 다른 활동과 짧은 급증을 위한 여유를 남기세요. 같은 패키지를 여러 프로세스가 쓸 때 각각에 전체 허용량을 주면 동시 실행 시 과부하가 날 수 있습니다.
2. 작업과 연결을 모두 통제하세요. 연결 풀은 재사용할 연결을 보관합니다. 크기 설정이 절대 상한인지 나중에 보관할 수인지 확인하세요. 일부 클라이언트는 대기 모드를 켜지 않으면 추가 연결을 엽니다. 작업 실패 때도 응답 정리와 시간 제한을 유지하세요.
3. 실행 시작과 재시도를 분산하세요. 모든 브라우저를 한꺼번에 시작하거나 실패 요청을 즉시 모두 반복하면 다시 최고치가 생깁니다. 재시도 횟수를 제한하고 간격을 점차 늘리며 같은 작업량 예산 안에 포함하세요. 시간 초과가 제출한 동작의 실패를 증명하지도 않으므로 구매나 갱신 동작의 반복에는 주의가 필요합니다.
4. 완료한 작업을 측정하세요. 워커 증가는 성공 처리량이 늘 때만 유용합니다. 주로 대기와 오류만 늘면 낮은 설정이 같은 작업을 더 빨리 끝낼 수 있습니다. 대시보드가 기간 평균을 표시하면 짧은 최고치는 앱의 오류 시각 기록보다 덜 보일 수 있습니다.

브라우저 작업은 불필요한 다운로드를 피해서도 네트워크 활동을 줄일 수 있습니다. 작업에 필요 없는 이미지나 동영상 차단은 도움이 될 수 있지만 스크립트 제거는 동작 자체를 망칠 수 있습니다. 의도한 작업이 여전히 올바르게 끝나는지로 판단하세요.

더 높은 한도가 도움이 되는 경우

애플리케이션이 연결을 올바르게 관리하면서 필요한 작업량이 지속적으로 업체 상한에 도달할 때 추가 연결 용량이 유용합니다. 작은 허용량을 두고 경쟁하지 않으면서 더 많은 작업을 함께 실행할 수 있습니다.

구매로 실제 도달한 한도가 높아져야 합니다. IP별 제한은 작업을 분산할 때 IP 추가로 도움이 될 수 있습니다. 공유 패키지 제한이라면 새 패키지나 추가 옵션이 공유 허용량을 높여야 합니다. IP 수만 늘었다고 그렇게 된다는 증거는 아닙니다.

다른 상한도 있습니다. 클라이언트 풀이 더 작거나 컴퓨터의 네트워크 자원이 부족하거나 대상이 요청을 제한할 수 있습니다. 모바일 연결 하나의 가용 대역폭도 허용 프록시 연결 수와 별개입니다. 동시 연결을 더 구매해도 이런 제한이 없어지거나 연결을 계속 누수시키는 스크립트가 고쳐지지는 않습니다.

실제 목표는 실패를 낮게 유지하면서 정상 최고 부하를 감당할 여유를 확보하는 것입니다. 이를 확인한 뒤 연결 허용량을 더하면 애플리케이션 수리를 미루는 수단이 아니라 유용한 용량 확장이 됩니다.