[Web] Redirect, Proxy와 Forward의 개념과 차이점

이번에 단축 URL 서비스를 개발하면서 "요청을 전달" 하는 방식에 대해 딥다이브 해보았습니다. 웹 기술에서 요청을 전달하는 방식을 생각하면 세 가지가 떠오릅니다. 리다이렉트, 프록시, 포워드. 이 글에서는 이 redirect, proxy, forward의 특징과 차이점에 대해 알아보겠습니다.

 

---

 

Redirect: 경로 재지정

리다이렉트는 RFC 7231에서 정의한 3xx 코드를 활용해 요청의 경로를 바꿔 다시 요청할 것을 알리는 통신 방식입니다.

https://www.rfc-editor.org/rfc/rfc7231.html

RFC 7231: Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content

 

한 줄 비유:

어떤 회사의 제품을 샀고, AS를 받으려 합니다. 이 때 그 회사로 메일을 보냈는데 "AS문의는 service@company.co 로 보내주세요" 라는 메일을 받고, 그 쪽으로 다시 메일을 보내는 것과 유사합니다.

 

Redirection의 특징

리다이렉트와 관련된 서버와 클라이언트의 동작은 RFC 규격을 따릅니다. 

아래는 RFC7231에 정의된 서버와 클라이언트의 동작 규격의 원문 중 일부입니다. (서버는 SHOULD로 강한 권고, 클라는 MAY로 결정권 및 사용자 보호를 추구합니다.)

301 Moved Permanently
The server SHOULD generate a Location header field in the response containing a preferred URI reference for the new permanent URI.
...
The user agent MAY use the Location field value for automatic redirection.

 

 

서버는 리다이렉트를 할 때, 해당 자원이 다른 URI에 있다는 것을 나타내 3xx 상태코드로 응답하며, 그 위치를 `Location` 헤더를 통해 알립니다. 이 때 사용되는 3xx 상태 코드는 주로 301, 302, 307, 308을 사용합니다. (각각 상태 코드에 대한 더 많은 내용은 별도의 글로 정리하겠습니다.)

 

응답을 받은 클라이언트(브라우저)는 해당 주소로 새로운 요청을 보냅니다. 이 때의 요청은 이전 요청과 별개의 새 요청입니다.

또한 브라우저가 직접 새 주소로 요청을 보내기 때문에 브라우저상의 URL이 바뀝니다.

 

이를 간단히 나타내면 아래와 같습니다.

1. 클라이언트 -> 서버(A)
   요청 전송
2. 서버(A) -> 클라이언트
   응답 전송 (HTTP 3xx + Location: 서버B)
3. 클라이언트 -> 서버(B)
   요청 전송 (새로운 HTTP Message)

 

---

 

Proxy: 요청을 중계

프록시 또한 상태 코드와 동작 방식이 RFC 규격에 정의돼있긴 합니다. 그러나 그 친구는 보안상의 이유로 공식적으로 Deprecated 되었습니다. 이 글에서는 305 Use Proxy가 아닌 우리가 사용하고 있는 프록시의 개념을 설명하는 글이므로 이 내용 또한 별개의 글로 다루도록 하겠습니다.

 

한 줄 비유:

어떤 회사의 제품을 샀고, AS를 받으려 합니다. 이 때 그 회사로 메일을 보냈는데, 메일을 받은 사람이 실무자에게 "이런 메일이 왔는데 처리 바랍니다"라는 메일을 보내고, 그 답장을 기반으로 다시 고객에게 답장하는 것과 유사합니다.

 

Proxy의 특징 (Reverse Proxy)

프록시를 하는 서버(A)는, 클라이언트의 요청을 받으면 자신(A)이 클라이언트가 되어 그 요청을 처리할 서버(B)에게 클라이언트의 요청을 바탕으로 새 HTTP Message를 생성하여 요청을 전송합니다. 그리고 요청의 결과가 만들어져 응답을 전송할 때, 요청을 처리한 것이 사실은 B서버라는 사실을 알리지 않습니다. 결과적으로 클라이언트 입장에서는 A서버로 요청을 보냈고 A서버로부터 응답을 받을 뿐입니다.

 

이 과정을 간단히 나타내보겠습니다.

1. 클라이언트 -> 서버(A)
   요청 전송
2. 서버(A) -> 서버(B)
   클라 요청 기반으로 새 요청 전송
3. 서버(B) -> 서버(A)
   응답 전송
4. 서버(A) -> 클라이언트
   서버B의 응답을 기반으로 응답 전송

 

---

 

 

Forward: 단일서버 내 라우팅 이동

포워드는 HTTP 규격이 아닌 웹 앱 프레임워크 내부의 개념입니다. 스프링 등 WAS에서 어떠한 요청을 받고, 다른 라우팅으로 그 요청에 대한 제어를 위임하는 기능을 포워드라고 합니다.

 

Forward의 특징

제어의 위임같은 건 모두 서버 내에서 일어나는 일이기 때문에, 클라이언트는 포워드와 관련된 어떤 것도 알 수 없습니다. 또한 라우팅 간에 전달되는 것은 서버의 메모리 상에 있는 객체이기 때문에, 서버 외부의 어떤 통신과도 맥락을 공유하지 않습니다.

 

한 줄 비유:

어떤 회사의 제품을 샀고, AS를 받으려 합니다. 이 때 그 회사로 메일을 보냈는데, 메일을 받은 사람이 같은 사무실 내 직원에게 업무를 모종의 방식으로 인계하는 것과 유사합니다.

 

1. 클라이언트 -> 서버
   `GET /abc` 요청 전송
2. 서버 내부
   `GET /xyz` 라우팅으로 요청을 전달
3. 서버 -> 클라이언트
   응답 전송