답변:
당신의 혼란은 합리적입니다-그들은 종종 같은 것입니다. 그러나 항상 그런 것은 아닙니다. 로드 밸런서를 언급 할 때 매우 구체적인 사항, 즉로드를 분산시키기 위해 둘 이상의 웹 서버에서 인바운드 요청의 균형을 조정하는 서버 또는 장치를 말합니다. 그러나 리버스 프록시에는 일반적으로 여러 가지 기능이 있습니다.
로드 밸런싱 : 위에서 설명한
캐싱 : 웹 서버의 컨텐츠를 캐싱하여 웹 서버의로드를 줄이고 웹 서버에서 데이터를 가져 오지 않고도 정적 컨텐츠를 요청자에게 다시 리턴 할 수 있습니다.
보안 : 인터넷에서 직접 액세스하지 못하게하여 웹 서버를 보호 할 수 있습니다. 웹 서버를 난독 처리하여 간단한 방법으로이 작업을 수행하거나 악의적 인 코드를 찾는 인바운드 요청을 실제로 검토하는 활성 구성 요소가 더있을 수 있습니다.
SSL 가속 : SSL 사용시; 암호화를 처리하는 워크로드가 웹 서버에서 오프로드되도록 SSL 세션의 종료 지점으로 사용될 수 있습니다.
나는 이것이 대부분을 포괄한다고 생각하지만 내가 놓친 몇 가지 다른 기능이있을 것입니다. 기능이 너무 일반적으로 함께 번들로 제공되기 때문에 장치 나 소프트웨어가로드 밸런서 / 리버스 프록시로 판매되는 것을 보는 것은 드문 일이 아닙니다.
또한 리버스 프록시는 웹 서버에만 해당됩니다.
그러나로드 밸런서는 다른 많은 프로토콜을 처리 할 수 있습니다. 요즘 웹 (HTTP)은 큰 아이디어이지만 DNS, 메일 (SMTP, IMAP) 등과 같은 것들도로드 밸런싱 될 수 있습니다. 오늘날 대부분의 사람들이 "인터넷"또는 "IP 네트워크"를 생각하는 것은 웹을 생각하는 것입니다. 더 모호하거나 틈새 시장이 될 수있는 더 많은 자료가 있습니다.
최종 결과 (서버간에 요청을 분배)는 다양한로드 밸런서와 리버스 프록시간에 동일하지만 요청을 분배하는 데 사용되는 방법이 다릅니다.
일부로드 밸런서는 DNS를 사용하여 트래픽의 균형을 조정하여 요청을 효과적으로 리디렉션하는 라운드 로빈에서 동일한 이름을 다른 IP로 확인합니다. 이는 데이터 센터 또는 다른 물리적 위치간에 요청을로드 밸런싱 할 때 유용 할 수 있습니다. 제공 한 TTL을 준수하기 위해 클라이언트 DNS 서버의 도움을 받으므로 "인스턴트"장애 조치가 필요한 경우이 방법은 적합하지 않습니다. 시스코의 GSS (Global Site Selector)는 DNS 기반로드 밸런싱의 좋은 예입니다.
다른로드 밸런서는 가상 IP로 향하는 패킷 헤더를 팜에있는 서버의 실제 IP로 다시 작성하여 작동합니다. 실시간로드 밸런싱과 거의 즉각적인 페일 오버를 제공합니다. 이에 대한 예로는 Cisco의 CSM (Content Switching Module)이 있습니다.
위의 두 가지 예에서 클라이언트와 서버간에 TCP 대화가 있습니다.
리버스 프록시는 웹 서버 대신 요청을 수락 한 다음 해당 요청을 웹 서버로 에코하고 클라이언트로 리턴하여 선택적으로 유사한 요청에 따라 결과를 캐싱함으로써 작동합니다.
클라이언트는 실제로 웹 서버에 대한 연결을 설정하지 않습니다. 오히려 대화는 프록시와 클라이언트 사이에서 엄격하게 이루어집니다.
역방향 프록시는 클라이언트의 요청을 받아 이를 수행 할 수있는 서버에 전달 하고, 역방향 프록시 뒤에 서버가 프로토콜의 다소 다른 기능 또는 다른 프로토콜과 통신 할 수 있다는 것을 의미 클라이언트에 대한 서버의 응답 (반환 ).
로드 밸런서는 해당 클라이언트 선택한 서버에서 응답을 반환 각각의 경우에, 서버 그룹 사이에서 들어오는 클라이언트 요청을 배포합니다.