HTTP 프록시 모듈로 리버스 프록시 서버 구성

리버스 프록시 및 포워드 프록시

발췌: https://cloud.tencent.com/developer/article/1418457

정방향 프록시

정방향 프록시(forward proxy) : 클라이언트와 타겟 서버 사이의 서버(프록시 서버)로, 타겟 서버로부터 콘텐츠를 얻기 위해 클라이언트는 프록시 서버에 요청을 보내고 타겟을 지정한 다음 프록시 서버는 대상 서버를 전송합니다. 요청을 전달하고 획득한 콘텐츠를 클라이언트에 반환합니다.

실제로 "프록시 서버"는 "클라이언트"가 "대상 서버"와 상호 작용하는 프록시 역할을 합니다.

순방향 프록시 서버를 통해 대상 서버에 액세스함으로써 대상 서버는 실제 클라이언트가 누구인지 알지 못하며 자신에게 액세스하는 사람이 프록시라는 사실조차 알지 못합니다.

순방향 프록시의 목적

접근 제한 돌파

프록시 서버를 통해 자신의 IP 접근 제한을 뚫고 해외 사이트, 교육 네트워크 등을 방문할 수 있습니다.

액세스 속도 향상

일반적으로 프록시 서버는 대용량 하드 디스크 버퍼를 설정하고 요청된 응답의 일부를 버퍼에 저장하고 다른 사용자가 동일한 정보에 다시 액세스할 때 해당 정보를 버퍼에서 직접 꺼내 사용자에게 전달하므로 프록시 서버의 성능을 향상시키기 위해 액세스 속도.

클라이언트의 실제 IP 숨기기

인터넷 사용자도 이러한 방식으로 자신의 IP를 숨기고 공격을 피할 수 있습니다.

리버스 프록시

리버스프록시(Reverse Proxy) : 인터넷상에서 접속요청을 수락한 후 내부망의 서버로 요청을 전달하고 서버에서 얻은 결과를 인터넷상에서 접속을 요청하는 클라이언트에게 반환하는 프록시 서버를 말하며, 이때 프록시 서버는 외부에서 리버스 프록시 서버 역할을 합니다.

리버스 프록시는 실제로 "클라이언트"와 상호 작용하는 "대상 서버"의 프록시 역할을 하는 "프록시 서버"입니다.

리버스 프록시 서버를 통해 대상 서버에 액세스할 때 클라이언트는 실제 대상 서버가 누구인지 모르거나 프록시라는 사실조차 알고 있습니다.

리버스 프록시의 목적

서버의 실제 IP 숨기기

리버스 프록시를 사용하면 서버의 IP 주소를 클라이언트에서 숨길 수 있습니다.

로드 밸런싱

리버스 프록시 서버는 로드 밸런싱을 수행할 수 있으며 모든 실제 서버의 로드 조건에 따라 다른 실제 서버에 클라이언트 요청을 분배할 수 있습니다.

액세스 속도 향상

역방향 프록시 서버는 액세스 속도를 향상시키기 위해 단기간에 많은 액세스 요청이 있는 정적 컨텐츠 및 동적 컨텐츠에 대한 캐싱 서비스를 제공할 수 있습니다.

보안을 제공하다

리버스 프록시 서버는 웹 기반 공격(예: DoS/DDoS)으로부터 웹 사이트를 보호하고 맬웨어 문제를 쉽게 해결할 수 있도록 애플리케이션 레이어 방화벽 역할을 할 수 있습니다. 또한 백엔드 서버에 대한 통합 암호화 및 SSL 암호화를 제공할 수 있습니다.

순방향 프록시와 역방향 프록시의 차이점

정방향 프록시 서버와 역방향 프록시 서버는 클라이언트와 실제 서버 사이에 위치하지만 이들이 하는 일은 클라이언트의 요청을 서버에 전달한 다음 서버의 응답을 클라이언트에 전달하는 것이지만 여전히 약간의 차이가 있습니다. 둘.

1. 정방향 프록시는 실제로 클라이언트의 프록시이며 클라이언트가 액세스할 수 없는 서버 리소스에 액세스하도록 도와줍니다. 리버스 프록시는 서버의 프록시로 , 서버가 로드 밸런싱, 보안 보호 등을 수행하도록 돕습니다.

2. 정방향 프록시는 일반적 으로 자체 시스템에 프록시 소프트웨어를 설치하는 것과 같이 클라이언트에서 설정합니다 . 리버스 프록시는 일반적 으로 자체 시스템 클러스터에 리버스 프록시 서버를 배포하는 것과 같이 서버에 의해 설정됩니다 .

3. 정방향 프록시에서 서버는 실제 클라이언트가 누구인지 알지 못하며 자신을 방문하는 사람을 실제 클라이언트라고 생각합니다. 리버스 프록시 에서 클라이언트는 실제 서버가 누구인지 알지 못하며 방문하는 실제 서버라고 생각합니다.

4. 정방향 프록시와 역방향 프록시의 역할과 목적이 다릅니다. 정방향 프록시는 주로 액세스 제한 문제를 해결하는 데 사용됩니다. 리버스 프록시는 로드 밸런싱, 보안 보호 및 기타 기능을 제공합니다. 둘 다 액세스 속도를 향상시킬 수 있습니다.

Nginx 리버스 프록시 서버

Nginx는 높은 동시성과 높은 부하 용량을 가지고 있으며 일반적으로 정적 파일 서비스를 클라이언트에 직접 제공하는 프런트 엔드 서버 역할을 합니다.

그러나 Apache, Tomcat 및 기타 서버에서 처리할 Nginx에 배치하기에 적합하지 않은 복잡하고 변경 가능한 비즈니스가 있습니다. 따라서 Nginx는 정적 웹 서버 또는 리버스 프록시 서버로 사용할 수 있습니다.

클라이언트가 HTTP 요청을 보내면 Nginx는 즉시 업스트림 서버로 전달하지 않고 먼저 사용자의 요청을 완전히 수신하고 Nginx는 서버의 하드 디스크 또는 메모리에 앉은 다음 업스트림 서버에 대한 연결을 시작하여 캐시된 클라이언트 요청은 서버에 전달됩니다. Squid와 같은 다른 리버스 서버는 클라이언트 요청을 수신하고 서버로 전달하는 방법을 사용합니다.

장점: 서버의 부하를 줄이고 Nginx 서버에 최대한 부담을 줍니다.

단점: 요청 처리 시간 연장, 요청된 콘텐츠를 캐시하는 데 사용되는 메모리 및 디스크 공간 증가

서버 부하를 줄여야 하는 이유:

일반적으로 클라이언트와 프록시 서버는 공용 네트워크를 사용하며 네트워크 속도는 상대적으로 느리고 요청을 완료하는 데 오랜 시간이 걸립니다. 프록시 서버와 업스트림 서버는 일반적으로 인트라넷을 사용하며 전송 속도가 빠릅니다. 클라이언트가 HTTP 패킷 수신을 시작하지 않을 때(예: 1GB 파일 업로드) Squid와 같은 역방향 프록시 서버가 업스트림 서버에 연결하면 TCP 패킷을 수신할 때마다 2Kb가 되고, 이를 업스트림으로 전달하고, 1GB 패킷을 수신하는 전체 프로세스 동안 서버는 항상 이 연결을 유지해야 하므로 업스트림 서버의 처리 용량에 대한 요구 사항을 제시합니다.

그러나 Nginx는 전체 클라이언트 요청을 수락한 후 업스트림과 연결을 설정합니다.내부 네트워크로 인해 포워딩이 매우 빠르므로 업스트림과의 연결 시간이 매우 짧습니다.

부하 분산 구성

업스트림 블록

업스트림 이름 {…}

구성 블록: http

업스트림 블록은 역방향 프록시에서 proxy_pass에 편리한 업스트림 서버 클러스터를 정의합니다.

upstream backend {
    
    
	server backend1.example.com;
	server backend2.example.com;
	server 1.2.3.4:80;
}

server {
    
    
	location / {
    
    
		proxy_pass http://backend;
	}
}

서버 블록

서버 이름 [매개변수];

구성 블록: 업스트림

server는 도메인 이름, IP 주소 포트, UNIX 핸들 등이 될 수 있는 업스트림 서버의 이름을 정의합니다.

weight=number: 이 업스트림 서버로 전달되는 가중치를 설정합니다. 기본값은 1입니다.

max_fails=숫자: fail_timeout과 함께 사용되며, fail_timeout 기간 내에 현재 업스트림 서버로의 전달 실패 수가 숫자를 초과하는 경우 현재 fail_timeout 기간 내에 서버를 사용할 수 없는 것으로 간주하도록 지정합니다. max_fails는 기본적으로 1이며, 0으로 설정하면 실패 횟수를 확인하지 않음을 의미합니다.

fail_timeout=time: fail_timeout은 해당 기간 동안 포워딩 실패 횟수를 나타내며, 업스트림 서버를 일시적으로 사용할 수 없는 것으로 간주하여 역방향 프록시 기능 최적화에 사용됩니다. 업스트림 서버와의 연결 설정 시간 제한, 업스트림 서버에서 응답을 읽는 시간 제한 등과 관련이 없습니다. fail_timeout 기본값은 10초입니다.

down: 업스트림 서버가 영구적으로 오프라인임을 나타내며 ip_hash 구성 항목이 사용될 때만 사용됩니다.

백업: ip_hash 구성 항목을 사용할 때 유효하지 않습니다. 업스트림 서버가 할당 서버일 뿐이며 모든 비 백업 업스트림 서버가 실패한 후에만 요청이 업스트림 서버로 전달됨을 나타냅니다.

upstream backend {
    
    
	server baidu.com;
	server 1.2.3.4:80;
	server 3.4.54.5:90  weight=6;
	server 1.2.3.4:80  max_fails=3 fail_timeout=30s;
	server unix:/tmp/backend3;
}

ip_hash

특정 사용자의 요청이 항상 고정된 업스트림 서버로 떨어지기를 바랍니다. ip_hash 원칙은 먼저 클라이언트 IP 주소를 기반으로 키를 계산한 다음 키가 모듈로 업스트림 클러스터 수입니다.

ip_hash 및 weight 구성은 동시에 사용할 수 없으며, 업스트림 클러스터의 한 서버를 일시적으로 사용할 수 없는 경우 구성을 직접 삭제할 수 없지만 포워딩 전략의 일관성을 보장하기 위해 매개변수 플래그를 다운해야 합니다.

upstream backend {
    
    
	ip_hash;
	server baidu.com;
	server 1.2.3.4:80;
	server 3.4.54.5:90;
	server 1.2.3.4:80  down;
	server unix:/tmp/backend3;
}

로깅 시 지원되는 변수

부하 분산 중 일부 정보를 access.log 로그에 기록해야 하는 경우 로그 형식을 정의할 때 부하 분산 기능에서 제공하는 변수를 사용할 수 있습니다.

변수 이름	중요성
$upstream_addr	요청을 처리하는 업스트림 서버의 주소
$upstream_cache_status	캐시 적중 여부, 값 범위 표시: MISS, EXPIRED, UPDATING, STAL, HIT
$upstream_status	업스트림 서버에서 반환한 응답의 HTTP 응답 코드
$upstream_response_time	밀리초 단위로 정확한 업스트림 서버의 응답 시간
KaTeX 구문 분석 오류: 위치 14에서 '_' 다음에 예상되는 그룹: upstream_http_̲ HEADER	HTTP 헤더(예: $upstream_http_host)

로그 형식은 다음과 같이 정의할 수 있습니다.

log_format timing '$remote_addr - $upstream_addr - $upstream_response_time'