프록시 서버와 리버스 프록시 서버의 차이점은 무엇입니까?

이전 답변은 정확했지만 너무 간결했습니다. 몇 가지 예를 추가하려고합니다.

우선, "프록시"라는 단어는 누군가 또는 다른 누군가를 대신하여 행동하는 것을 의미합니다.

컴퓨터 영역에서 우리는 다른 컴퓨터를 대신하여 작동하는 한 서버에 대해 이야기하고 있습니다.

내게 필요한 옵션의 목적을 위해 토론을 웹 프록시로 제한하지만 프록시 아이디어는 웹 사이트에만 국한되지 않습니다.

앞으로 프록시

웹 프록시에 대한 대부분의 논의는 "전달 프록시"로 알려진 프록시 유형을 나타냅니다.

이 경우 프록시 이벤트는 "전달 프록시"가 원래 요청자를 대신하여 다른 웹 사이트에서 데이터를 검색하는 것입니다.

3 대의 컴퓨터 이야기 (1 부)

예를 들어, 인터넷에 연결된 세 대의 컴퓨터를 나열하겠습니다.

• X = 컴퓨터 또는 인터넷의 "클라이언트"컴퓨터
• Y = 프록시 웹 사이트 proxy.example.org
• Z = 방문하려는 웹 사이트, www.example.net

일반적으로 하나는 X --> Z.

그러나 일부 시나리오에서는 다음과 같이 체인 Y --> Z을 대신 하는 것이 좋습니다 .XX --> Y --> Z

X가 정방향 프록시 서버를 사용하려는 이유 :

정방향 프록시 서버의 (매우) 부분 사용 목록은 다음과 같습니다.

• 1) X는 Z에 직접 액세스 할 수 없으므로

  • a) X인터넷 연결을 통해 관리 권한을 가진 사람이 사이트에 대한 모든 액세스를 차단하기로 결정했습니다 Z.

    • 예 :

      • 스톰 웜 바이러스는 사람들을 방문하도록 familypostcards2008.com유도하여 확산되어 시스템 관리자가 사이트에 대한 액세스를 차단하여 사용자가 실수로 자신을 감염시키는 것을 방지합니다.

      • 대기업의 직원이 너무 많은 시간을 낭비하고 facebook.com있기 때문에 경영진은 업무 시간 동안 액세스가 차단되기를 원합니다.

      • 지역 초등학교는 playboy.com웹 사이트에 대한 인터넷 액세스를 허용하지 않습니다 .

      • 정부는 뉴스 게시를 제어 할 수 없으므로와 같은 사이트를 차단하여 뉴스에 대한 액세스를 대신 제어합니다 wikipedia.org. TOR 또는 FreeNet을 참조하십시오 .

  • b) 관리자 Z가 차단했습니다 X.

    • 예 :

      • Z의 관리자는 X로부터의 해킹 시도를 발견하여 X의 IP 주소 (및 / 또는 netrange)를 차단하기로 결정했습니다.

      • Z는 포럼 웹 사이트입니다. X포럼을 스팸하고 있습니다. Z는 X를 차단합니다.

프록시 재발급

3 대의 컴퓨터 이야기 (2 부)

이 예에서는 인터넷에 연결된 세 대의 컴퓨터를 나열합니다.

• X = 컴퓨터 또는 인터넷의 "클라이언트"컴퓨터
• Y = 리버스 프록시 웹 사이트 proxy.example.com
• Z = 방문하려는 웹 사이트, www.example.net

일반적으로 하나는 X --> Z.

그러나 일부 시나리오에서는 관리자가 Z직접 액세스를 제한하거나 허용하지 않고 방문자가 Y를 먼저 통과하도록하는 것이 좋습니다. 따라서 이전과 Y --> Z마찬가지로을 대신하여 데이터를 검색하고 X있으며 다음과 같은 체인이 있습니다 X --> Y --> Z.

이번에는 "전달 프록시"와 다른 점은 사용자 X는 자신이 액세스 Z하고 있음을 알기 때문 X입니다 Y. 서버 Z는 클라이언트에게 보이지 않으며 리버스 프록시 만 Y외부에서 볼 수 있습니다. 리버스 프록시는 클라이언트 측에 프록시 구성이 필요하지 않습니다.

고객 X은 자신과 통신하고 있다고 생각 하지만 Y( X --> Y) 현실은 Y모든 통신 을 전달하는 것입니다 ( X --> Y --> Z다시).

Z가 리버스 프록시 서버를 설정하려는 이유 :

• 1) Z는 웹 사이트의 모든 트래픽이 Y를 먼저 통과하도록하고 싶습니다.
  • a) Z에는 수백만 명의 사람들이보고 싶어하는 대규모 웹 사이트가 있지만 단일 웹 서버가 모든 트래픽을 처리 할 수는 없습니다. 따라서 Z는 많은 서버를 설정하고 인터넷에 리버스 프록시를 설정하여 사용자가 Z를 방문하려고 할 때 가장 가까운 서버로 사용자를 보냅니다. 이는 CDN (Content Distribution Network) 개념의 작동 방식의 일부입니다.
    • 예 :
      • Apple Trailers 는 Akamai를 사용합니다
      • Jquery.com은 CloudFront CDN ( sample )을 사용하여 JavaScript 파일을 호스팅합니다 .
      • 기타
• 2) Z의 관리자는 서버에서 호스팅되는 콘텐츠에 대한 보복에 대해 걱정하며 주 서버를 공개적으로 공개하고 싶지 않습니다.
  • a) "캐나다 약국 (Canadian Pharmacy)"과 같은 스팸 브랜드의 소유자는 수천 대의 서버를 보유하고 있지만 실제로는 대부분의 웹 사이트가 훨씬 적은 수의 서버에 호스팅되어있는 것으로 보입니다. 또한 스팸에 대한 악용 불만은 주 서버가 아닌 공용 서버 만 종료합니다.

위 시나리오에서 Z를 선택할 수 있습니다 Y.

게시물의 주제로 연결되는 링크 :

컨텐츠 전달 네트워크

• CDN 목록
  • http://www.mytestbox.com/miscellaneous/content-delivery-networks-cdn-list/
  • http://blog.streamingmedia.com/the_business_of_online_vi/2008/01/updated-list-of.html

정방향 프록시 소프트웨어 (서버 측)

• PHP 프록시
• CGI 프록시
• phproxy (판매 중단)
• 글리프
• 인터넷 검열 위키 : 웹 프록시 목록
• 오징어 (분명히 역 프록시로 작동 할 수 있음)

HTTP 용 리버스 프록시 소프트웨어 (서버 측)

• Apache mod_proxy (HTTP의 정방향 프록시로도 작동 가능)
• nginx (hulu.com, 스팸 사이트 등에서 사용)
• HA 프록시
• 캐디 웹 서버
• 빛
• perlbal (실시간 저널 용)
• 포트 퓨전
• 파운드
• 니스 캐시 ( FreeBSD 커널 전문가가 작성 )
• 휴식

TCP 용 리버스 프록시 소프트웨어 (서버 측)

• 균형
• 대리자
• 펜
• 포트 퓨전
• 순수한로드 밸런서 (웹 사이트 기능 상실)
• 파이썬 디렉터

또한보십시오:

• Wikipedia-컨텐츠 전달 네트워크
• 위키 백과-카테고리 : Reverse_proxy
• Wikipedia-로드 밸런싱
• Wikipedia-확장 성

한 쌍의 간단한 정의는 다음과 같습니다.

전달 프록시 : 요청자 (또는 서비스 소비자)를 대신하여 행동

리버스 프록시 : 서비스 / 콘텐츠 제작자를 대신하여 행동합니다.

아래 다이어그램이 매우 유용하다는 것을 알았습니다. 인터넷을 통한 클라이언트에서 서버 로의 순방향 및 역방향 프록시 설정 아키텍처를 보여줍니다 . 이 이미지는 qyb2zm302의 답변 과 다른 답변을 더 잘 이해하는 데 도움이됩니다 .

F5 의 DevCentral 에서이 비디오 를 볼 수도 있습니다Peter Silva .

사진 출처 : Quora . 그러나 Martijn Pieters에 따르면이 이미지는 Pulse Secure Community 또는 Julien Pauli 사이트 에서 가져온 것일 수 있습니다. developpez.com (프랑스어)에서 .

그것은 고전 속담을 생각 나게했다.

그림은 1000 단어의 가치가 있습니다.

정방향 프록시 대 역방향 프록시 (2012)는 의 차이점을 매우 명확하게 설명합니다.

qyb2zm302 님의 답변 은 프록시의 응용 프로그램을 훌륭하게 자세히 설명하지만 정방향 및 역방향 프록시 간의 기본 개념에 대해 설명합니다. 리버스 프록시의 경우 X → Y → Z, X는 Z가 아닌 Y에 대해 알고 있습니다.

프록시는 단순히 커뮤니케이션을위한 중개인입니다 (요청 + 응답). 클라이언트 <-> 프록시 <-> 서버

• 클라이언트 프록시 : ( client <-> proxy ) <-> server

프록시는 클라이언트를 대신하여 작동합니다. 클라이언트는 체인에 관련된 세 가지 머신에 대해 알고 있습니다. 서버는 그렇지 않습니다.

• 서버 프록시 : 클라이언트 <-> ( 프록시 <-> 서버 )

프록시는 서버를 대신하여 작동합니다. 클라이언트는 프록시에 대해서만 알고 있습니다. 서버는 전체 체인을 알고 있습니다.

전진 과 후진 은 단순히 클라이언트 와 서버 프록시에 대해 혼란스럽고 관점에 의존하는 이름 인 것 같습니다 . 나는 명백한 의사 소통을 위해 전자를 후자에게 버릴 것을 제안한다.

물론, 문제를 더 복잡하게하기 위해 모든 머신이 클라이언트 나 서버 만있는 것은 아닙니다. 상황이 모호한 경우 프록시가있는 위치와 터널링하는 통신을 명시 적으로 지정하는 것이 가장 좋습니다.

일부 다이어그램이 도움이 될 수 있습니다.

전달 프록시

리버스 프록시

차이점은 주로 배포에 있습니다. 웹 전달 및 역방향 프록시는 모두 동일한 기본 기능을 갖습니다. 다양한 형식의 HTTP 요청에 대한 요청을 수락하고 일반적으로 오리진 또는 연락 서버에 액세스하여 응답을 제공합니다.

완전한 기능을 갖춘 서버에는 일반적으로 액세스 제어, 캐싱 및 일부 링크 매핑 기능이 있습니다.

정방향 프록시는 클라이언트 컴퓨터를 구성하여 액세스하는 프록시입니다. 클라이언트는 프록시 기능 (리디렉션, 프록시 인증 등)에 대한 프로토콜 지원이 필요합니다. 프록시는 사용자 환경에는 투명하지만 응용 프로그램에는 투명하지 않습니다.

리버스 프록시는 웹 서버로 배치되고 웹 서버처럼 작동하는 프록시입니다. 단, 프로그램 및 디스크의 컨텐츠를 로컬로 작성하는 대신 요청을 원래 서버로 전달합니다. 클라이언트의 관점에서 그것은 이다 사용자 경험을 완전히 투명하므로, 웹 서버.

실제로 단일 프록시 인스턴스는 서로 다른 클라이언트 모집단에 대해 정방향 및 역방향 프록시로 동시에 실행될 수 있습니다.

프록시 : 클라이언트를 대신하여 요청합니다 . 따라서 서버는 응답을 프록시에 반환하고 프록시는 응답을 클라이언트에 전달합니다. 실제로 서버는 클라이언트가 누구인지 (클라이언트의 IP 주소) "학습"하지 않습니다. 프록시 만 알 수 있습니다. 그러나 클라이언트는 본질적으로 서버로 향하는 HTTP 요청을 형식화하기 때문에 서버를 잘 알고 있지만 프록시로 전달합니다.

리버스 프록시 : 서버를 대신하여 요청을 수신하고 있습니다. 요청을 서버로 전달하고 응답을 수신 한 다음 클라이언트에 응답을 리턴합니다. 이 경우 클라이언트는 실제 서버 (서버의 IP 주소)를 누구도 "학습"하지 않습니다 (일부 예외 제외). 프록시 만 알 수 있습니다. 리버스 프록시의 구성에 따라 서버는 실제 클라이언트를 알거나 알 수 없습니다.

가장 좋은 설명은 다음 과 같습니다.

잠시 정방향 프록시 클라이언트를 대신하여 프록시 ( 또는 요청하는 호스트 ) 하는 리버스 프록시 서버를 대신하여 프록시.

실제로 정방향 프록시 는 클라이언트 의 ID를 숨기고 역방향 프록시 는 서버의 ID를 숨 깁니다.

프록시 서버는 나가는 네트워크 요청을 인터넷을 통해 불필요하게 관련없는 다양한 공용 리소스에 프록시 (및 선택적으로 캐시)합니다. 리버스 프록시는 인터넷에서 들어오는 요청을 캡처 (및 선택적으로 캐시)하여 일반적으로 고 가용성을 위해 다양한 내부 개인 자원으로 분배합니다.

구름 플레어 에는이를 자세히 설명하는 이미지가 포함 된 훌륭한 기사가 있습니다.

여기를 확인하십시오 : 리버스 프록시 란 무엇입니까? | 프록시 서버 설명

프록시 (전달 프록시) :

LAN의 컴퓨터가 인터넷에 액세스하는 프록시 서버에 연결될 때 인터넷에 노출되는 서버 만 포함됩니다. 외부 사람들은 컴퓨터에 직접 액세스 할 수 없습니다. 정방향 프록시는 다운로드를 캐싱하여 사용자의 인터넷 액세스를 향상시킬 수 있습니다. 또한 특정 사이트에 대한 액세스를 제한하는 데 사용될 수 있습니다. 또한 프록시 서버에만 공용 주소가 필요하며 연결하는 클라이언트는 필요하지 않습니다.

리버스 프록시 :

리버스 프록시는 포워드 프록시와 반대입니다. 대신 연결된 서버 대신 프록시 역할을합니다. 사용자는 원격 서버에 직접 액세스하는 대신 리버스 프록시를 통해 적절한 서버로 연결됩니다. 리버스 프록시에만 SSL 인증서가 필요하고 하나의 공용 IP 주소 만 필요하며 들어오는 사용자의로드 밸런싱을 처리하여 전반적인 사용자 경험을 향상시킬 수 있습니다.

이미지 소스 : 응용 프로그램 요청 라우팅을 사용하여 전달 프록시 작성

아파치 관점 에서 내가 이해 한 것은 프록시는 사이트 x가 사이트 y를 프록시하면 x가 y를 반환한다는 것을 의미한다는 것입니다.

리버스 프록시는 y에 대한 모든 참조가 x가되도록 y의 응답이 조정됨을 의미합니다.

사용자가 프록시가 관련되어 있다고 말할 수 없도록 ...

내 이해에 따라 ...

우선 모든 사람이 알고 있듯이 프록시는 "다른 사람을 대표 할 권한"을 의미합니다. 이제 정방향 프록시와 역방향 프록시라는 두 가지가 있습니다.

전달 프록시

"Google"에 액세스하고 "Google"에 차례로 접속하여 특정 요청에 응답 할 서버 수가 n 개라고 가정합니다.

이제이 경우 Google에 무언가를 요청하고 Google이 IP 주소를 보지 못하게하려면 아래 설명 된대로 전달 프록시를 사용합니다.

A → B → C

이제 여기에 A가 있고 B를 통해 요청을 보냅니다. 따라서 C는 요청이 A가 아닌 B에서 온 것으로 생각합니다. 이러한 방식으로 클라이언트 IP 주소가 외부 세계에 노출되지 않도록 할 수 있습니다.

리버스 프록시

이제이 경우 이해를 돕기 위해 동일한 대리 프록시 사례를 사용합니다. 여기에 Google에 무언가를 요청한 후 응답을 얻기 위해 하나의 요청을 앱 서버 또는 다른 프록시 서버로 보냅니다. 따라서 아래 설명 된대로 이런 일이 발생합니다.

A → B → C

C → D

C ← D

A ← B ← C

위의 다이어그램에서 요청이 A가 아닌 B에서 C로 전송되었음을 알 수 있습니다. 그러면 C에서 D로 요청이 한 번 전송됩니다. 유사하게 응답은 D에서 C로 이동 한 다음 B 및 A로 이동합니다.

위의 다이어그램은 두 프록시가 동일한 방식으로 작동하지만 클라이언트 측 프록시가 클라이언트 정보를 숨기는 반면 서버 측 프록시는 서버 측 정보를 숨기는 것이 중요하지만 컨텍스트는 중요하다고 말합니다.

정방향 프록시 는 클라이언트 익명 성을 부여합니다 (즉, Tor 생각 ).

리버스 프록시는 백엔드 서버의 익명 성을 부여합니다 (즉, DMZ 뒤에있는 서버 생각).

다음은 리버스 프록시 (로드 밸런서)의 예입니다.

클라이언트는 website.com을 서핑하고 히트 한 서버에서 리버스 프록시가 실행되고 있습니다. 리버스 프록시는 Pound 입니다. Pound는 요청을 받아서 그 뒤에있는 세 개의 애플리케이션 서버 중 하나로 보냅니다. 이 예에서 Pound는로드 밸런서입니다. 즉, 세 응용 프로그램 서버 간의로드 균형을 조정하는 것입니다.

응용 프로그램 서버는 웹 사이트 컨텐트를 클라이언트에 다시 제공합니다.

정방향 프록시 는 사용자에게 서비스를 제공 합니다 . 사용자 가 서버에 액세스하는 데 도움이됩니다 .

역방향 프록시 역할을 서버 :이 보호하는 서버 에서 사용자를 .

프록시가없는 경우

클라이언트 측과 서버 측에서 보는 방법은 동일합니다.

클라이언트-> 서버

대리

클라이언트 쪽에서 :

클라이언트-> 프록시-> 서버

서버 측에서 :

클라이언트-> 서버

리버스 프록시

클라이언트 쪽에서 :

클라이언트-> 서버

서버 측에서 :

클라이언트-> 프록시-> 서버

따라서 클라이언트 사용자가 설정 한 경우 프록시라고하며 서버 관리자가 설정 한 경우 리버스 프록시라고 생각합니다.

설정 목적과 이유가 다르기 때문에 데이터를 다른 방식으로 처리하고 다른 소프트웨어를 사용합니다.

   User side          |      Server side
client  <->  proxy  <-->  reverse_proxy <-> real server

사용자 관점에서 보면 : 프록시 또는 리버스 프록시 서버 로 요청을 보낼 때 :

• 프록시 - 두 가지 인수 가 필요합니다 :
  
  1) 얻을 것과 2) 중간을 사용할 프록시 서버
  
  

• 리버스 프록시 - 하나의 인수 가 필요합니다 .
  
  1) 가져올 내용

리버스 프록시는 사용자에게 알려지지 않은 다른 서버에서 컨텐츠를 가져 와서 리버스 프록시 서버에서 시작된 것처럼 결과를 리턴합니다 .

이전 답변의 대부분은 훌륭하지만 제 의견으로는 둘을 차별화하는 "역방향"품질을 충분히 다루는 데는 전혀 도움이되지 않습니다. 그러기 위해서는 본질적으로 동일한 것 (프록시)의 "역"특성을 시각화 할 수있는 방법이 제공되어야하며 잘 추상화 된 방식으로 제공되어야합니다.

프록시 (암시 적으로 "앞으로 프록시")은 어느 하나 개의 원격 서버에 여러 개의 로컬 클라이언트를 연결 :

c--
   |--p--s
c--

역방향 프록시는 어떤 하나의 원격 클라이언트 (방법 레이아웃 반전 통지)에 여러 개의 로컬 서버를 연결 :

s--
   |--p--c
s--

프록시 작업의 실용성과 관련하여 중요하지는 않지만 개념을 중요하지 않은 (특정 개념으로) 세부적으로 추상화해야한다는 개념을 실제로 제대로 이해하려면 관점의 문제입니다. 이러한 세부 사항에는 두 시나리오 모두에서 여러 클라이언트가 여러 서버에 연결하고, 클라이언트와 서버가 실제로 로컬 또는 원격이 아닐 수 있으며, 인터넷 클라우드가있는 위치 또는 클라이언트와 서버 사이에 어떤 가시성이 있는지에 대한 현실이 있습니다.