Steady Study

ideveloper

Front end Developer who steadily study

Feb 9, 2020 - 15 min read

이 글은 HTTP 완벽가이드 20장을 참고해 정리한 포스팅입니다.

시작하기에 앞서

HTTP 메시지의 데이터는 네트워크 통신과정에서 많은 프로토콜에 의해 통제됩니다.
HTTP가 고려하는 것은 오직 출발지(송신자)와 목적지(수신자) 뿐이지만, 미러링된 서버, 웹 프락시, 캐시 등 역시도 고려되어야 하므로 항상 단순하지만은 않습니다.
리다이렉션 기술은 HTTP 메시지의 최종 목적지를 정하는것과 관련되어있고, 보통 메시지가 프락시,캐시, 서버팜의 특정 웹서버 중 어디에서 끝나는지 판별하기 위해 사용한다고 합니다.
리다이렉션 기술은 클라이언트의 메시지를 명시적으로 요청하지 않은 곳으로 보낼 수 있습니다.

리다이렉션을 하는 이유

HTTP 애플리케이션은 언제나 아래 세가지를 원하기 때문에 리다이렉션은 현대의 웹에서는 불가피합니다.

신뢰할 수 있는 HTTP 트랜잭션의 수행
지연 최소화
네트워크 대역폭 절약

위와 같은 이유들 때문에, 웹 콘텐츠는 흔히 여러장소에 배포하게 됩니다.

이렇게 하면 한곳에서 실패한 경우 다른 곳을 이용할 수 있으므로 신뢰성 이 개선됩니다.
또한 클라이언트가 보다 가까운 리소스에 접근할 수 있게 되어 응답시간도 줄여줍니다.
또한 목적지 서버가 분산되므로 네트워크 혼잡도도 줄어들게 됩니다.

이렇게 리다이렉션이란 최적의 분산된 콘텐츠를 찾는 것을 도와주는 기법의 집합이라고 할 수 있습니다.

리다이렉션 구현에는 load-balancing(부하 균형)의 과제가 포함되는데, 왜냐하면 둘은 서로 공존하기 떄문입니다.(대부분의 리다이렉션 장치들은 몇가지 방식의 부하 균형을 포함)

리다이렉션이 필요한 곳

도메인 앨리어싱

링크 유지하기

안전하지 않은 요청에 대한 일시적인 응답

긴 요청에 대한 일시적인 응답

그 외

서버, 프락시, 캐시, 게이트웨이가 모두 공통적으로 서버의 특성을 가지고 있기 때문에 많은 리다이렉션 기법이 그들 모두에서 동작하게 됩니다.
그러나 어떤 리다이렉션 기술들은 특정 종류의 종단 만을 위해 특별히 설계되어 일반적인 적용이 불가능합니다.
복제된 서버들로 요청을 분산한다는 것은 같은 URL에 대해 여러 곳에서 온 요청들을 각각 최적의 웹 서버로 보내겠다는 것(클라이언트에 가장 가까운 것이나 부하가 가장 적은 것, 혹은 그외의 이유로 최적인 것)을 의미하게 됩니다.
프락시는 프로토콜별로 요청을 다루게 됩니다. 클라이언트 근처에 프락시 캐시가 있다면, 모든 요청이 프락시 캐시로 흘러 들어가는 것이 이상적입니다. 프락시로의 리다이렉트는 주 진입로의 트래픽을 지름길로 보내는것과 같습니다.

리다이렉션의 유형

영속적인 리다이렉션

이 리다이렉션은 영원히 지속됨을 의미합니다. 원래의 URL이 더 이상 사용되지 않아야 하며 새로운 URL을 더 선호해야 함을 시사합니다. 검색 엔진 로봇은 그들의 인덱스 내에서 리소스에 대한 연관 URL의 갱신을 촉발시킵니다.

301 Moved Permanently
- GET 메서드는 변경되지 않습니다.
- 다른 메서드들은 GET은로 변하거나 변하지 않을수도 있습니다.
308 Permanent Redirect
- 메서드와 본문은 변하지 않습니다.
- GET이 아닌 링크/동작을 지닌, 웹 사이트의 재편성.
- 명세는 메서드 변경을 허용할 의도가 없으나, 사실 상 사용자 에이전트들이 그렇게 하고 있습니다. 308 은 GET이 아닌 메서드를 사용할 때 동작의 애매모호함을 제거하고자 만들어졌습니다.

일시적인 리다이렉션

때때로 요청된 리소스는 그것의 표준 위치에서 접근할 수 없고 다른 위치에서 접근 가능한 경우가 있습니다. 이런 경우 일시적인 리다이렉트가 사용될 수 있습니다. 검색 엔진 로봇은 새로운, 일시적인 링크를 기억하지 못합니다. 일시적인 리다이렉션은 일시적인 진행율 페이지를 표시하고자 리소스를 만들고 갱신하며 삭제할 때 사용될 수 도 있습니다.

302 Found
- GET 메서드는 변경되지 않습니다.
- 다른 메서드들은 GET로 변하거나 변하지 않을수도 있습니다.
- 웹 페이지가 예측하지 못한 이유로 일시적으로 이용 불가능할 때 가 있습니다. 그런 이유로, 검색 엔진은 그들의 링크를 갱신하지 않습니다.
303 See Other
- GET 메서드는 변경되지 않습니다.
- 다른 메서드들은 GET 메서드로 변경됩니다(본문을 잃게 됩니다).
- 동작을 다시 촉발시키는 페이지 리프레시를 막기 위해 PUT 혹은 POST 뒤에 사용됩니다.
307 Temporary Redirect
- 메서드와 본문은 변경되지 않습니다.
- 웹 페이지가 예측하지 못한 이유로 일시적으로 이용 불가능할 때 가 있습니다. 그런 이유로, 검색 엔진은 그들의 링크를 갱신하지 않습니다.
- GET이 아닌 링크/동작이 사이트에서 이용 가능할 때 302보다 더 좋습니다.
- 명세에는 메서드 변경을 허용할 의도가 없으나, 실질적으로 user-agent 들이 그렇게 하고 있습니다. 307 은 GET이 아닌 메서드들을 사용하는 경우 동작의 애매모호함을 제거하기 위해 만들어졌습니다.

특수 리다이렉션

300 Multiple Choice
- 이런 경우가 많지는 않습니다: 본문의 HTML 페이지 내에 선택지가 나열됩니다. 200 OK 상태와 함께 서브될 수 있습니다.
304 Not Modified
- 캐시 리프레시: 캐시 값이 여전히 사용 가능할 정도로 신선하다는 것을 가리킵니다.

참고: https://developer.mozilla.org/ko/docs/Web/HTTP/Redirections

리다이렉션 프로토콜의 개요

리다이렉션의 목표는 HTTP 메시지를 가용한 웹서버로 가급적 빨리 보내는 것입니다. HTTP 메시지가 인터넷을 통해 그 요청이 나아가는 방향은 HTTP 애플리케이션과 라우팅 장치에 영향을 받게 됩니다. 그 예들은 아래와 같습니다.

브라우저 애플리케이션의 사용자는 브라우저가 클라이언트 메시지를 프락시 서버로 보내도록 설정 할 수 있습니다.
DNS 분석자는 메시지의 주소를 지정할때 사용될 IP 주소를 선택하게 되는데, 클라이언트의 지리적 위치에 따라 달라질 수 있습니다.
메시지는 주소가 지정된 여러 개의 패킷으로 나뉘어 네트워크를 통과하게 됩니다. 스위치와 라우터들은 패킷의 TCP/IP 주소를 검증하고 그에 근거하여 패킷을 어떻게 라우팅할 것인지 결정하게 됩니다.
웹 서버는 HTTP 리다이렉트를 이용해 요청이 다른 웹 서버로 가도록 할 수 있습니다.

위에서 설명한 브라우저 설정, DNS, TCP/IP 라우팅, 그리고 HTTP는 모두 메시지를 리다이렉트 하는 메커니즘을 제공합니다.

주의할 사항은 DNS 리다이렉션을 비롯한 대부분의 기법들이 트래픽을 보내려는 곳이 어떤 서버냐에 상관없이 사용될 수 있는 것에 반해 브라우저 설정과 같은 방법은 프락시로 향하는 리다이렉트 트래픽에서만 사용할 수 있다는 점을 유의해야 합니다.

리다이렉션 방법

메시지를 서버로 리다이렉트 하기 위해 사용되는 리다이렉션 방법

메커니즘	어떻게 동작하는가	재 라우팅의 근거	제약사항
HTTP 리다이렉션	웹 서버는 콘텐츠를 제공하기에 최적인 웹 서버로의 redirect를 클라이언트에게 보내줍니다.	라운드 로빈 부하 균형, 회전 지연 최소화, 최단 거리 선정, ..etc	느릴수 있고, 모든 트랜잭션이 추가 리다이렉트 단계를 포함하게 됩니다.또한 첫번째 웹서버가 요청 부하를 다룰 수 있어야 합니다.
DNS 리다이렉션	DNS 서버가 URL의 호스트명에 대한 응답으로 어떤 IP 주소를 사용할지 결정합니다.	라운드 로빈 부하 균형, 회전 지연 최소화, 최단 거리 선정, ..etc	DNS 서버를 설정할 필요가 있습니다.
임의 캐스트 어드레싱	여러서버가 같은 IP주소를 사용. 그 외의 라우터들은 공유된 IP주소로 향하는 패킷을 가장 가까운 서버로 보냄	라우터들은 내장된 최단거리 라우티 기능을 사용	라우터를 설정할 필요 있음, 주소가 충돌할 위험이 있음.라우팅이 바뀌고 커넥션과 연관된 패킷들이 다른 서버들로 보내진다면 TCP 커넥션이 깨질수 있습니다.
아이피 맥(MAC) 포워딩	패킷이 리다이렉트 되어야 한다면, 스위치는 그 패킷에게 서버나 프락시의 목적지 MAC 주소를 줍니다.	대역폭을 절약하고 서비스 품질을 개선합니다. load balancing	서버나 프록시는 반드시 한 홉 거리에 있어야 합니다.
IP 주소 포워딩	레이어 4(L4)스위치는 패킷의 목적지 포트를 평가하고, 리다이렉트 패킷의 IP주소를 프락시나 미러링된 서버의 IP주소로 바꿉니다.	대역폭을 절약하고 서비스 품질을 개선합니다. load balancing	서버나 프락시가 클라이언트의 IP주소를 잃어버릴 수 있습니다.

메시지를 프락시 서버로 리다이렉트하기 위해 사용되는 리다이렉션 방법

메커니즘	어떻게 동작하는가	재라우팅의 근거	제약사항
명시적인 브라우저 설정	웹 브라우저는 가까운 프락시(보통 캐시)에게 HTTP 메시지를 보내도록 설정됩니다.	대역폭을 절약하고 QOS 개선, 부하균형	브라우저의 설정 능력에 의존
프록시 자동 설정	웹브라우저는 설정 서버로부터 PAC 파일을 검색, PAC 파일은 브라우저에게 각 url에 대해 어떤 프락시를 사용해야 하는지 알려주게 됩니다.	대역폭을 절약하고 QOS 개선, 부하균형	브라우저의 설정 능력에 의존
웹 프락시 자동발견 프로토콜	웹브라우저는 설정 서버에게 PAC파일에 대한 URL을 물어봅니다. PAC만 사용할때와 달리 브라우저에 특정 설정 서버가 설정되어야 할 필요가 없습니다.	설정 서버는 HTTP 요청헤더에서 얻은 정보에 근거해 PAC 파일의 URL을 결정합니다.
웹 캐시 조직 프로토콜	라우터는 패킷의 목적지 주소를 평가하고 프락시나 미러링된 서버의 IP주소와 함께 리다이렉트 패킷을 캡슐화합니다.	대역폭을 절약하고 QOS를 개선, 부하균형(Load balancing)	반드시 이를 지원하는 브라우저를 사용해야 함
인터넷 캐시 프로토콜	프락시 캐시는 형제 캐시의 무리에게 요청받은 콘텐츠에 대해 질의 할 수있고, 캐시계층을 지원합니다.	형제 혹은 부모 캐시로부터 콘텐츠를 얻는 것은 원서버로부터 얻는것보다 빠릅니다.	콘텐츠를 요청할때 오직 URL만을 사용하기 때문에 캐시 적중이 아님에도 적중인것처럼 동작할 우려가 있음.
캐시 배열 라우팅 프로토콜	프락시 캐시 해싱 프로토콜. 캐시가 요청을 부모캐시로 전달할수 있도록 해줌	형제 혹은 부모 캐시로부터 콘텐츠를 얻는 것은 원서버로부터 얻는것보다 빠릅니다.	형제 관계의 캐시를 지원할수 없음. 모든 CARP 클라이언트는 반드시 설정에 동의해야함(그렇지 않으면 같은 URI를 다른 부모에게 되어 캐시 적중률 감소할 가능성 높음)
하이퍼텍스트 캐싱 프로토콜	참여하는 프록시 캐시는 형제 캐시의 무리에게 요청받은 콘텐츠에 대해 질의할수 있음.	형제 혹은 부모 캐시로부터 콘텐츠를 얻는 것은 원서버로부터 얻는것보다 빠릅니다.

일반적인 리다이렉션 방법

HTTP 리다이렉션

장점: 리다이렉트를 하는 서버가 클라이언트의 아이피 주소를 안다는 점
단점
- 어떤 서버로 리다이렉트 할지 결정하려면 원 서버는 상당히 많은 처리를 해야함. (때로는 거의 페이지 자체를 제공할 때 필요한 양과 같은양의 처리 필요)
- 페이지에 접근할 때마다 두 번의 왕복이 필요하기 때문에, 사용자가 더 오래 기다리게 됨
- 리다이렉트 서버가 동작하지 않으면, 사이트도 동작하지 않게 됨.

HTTP 리다이렉션

DNS 리다이렉션

DNS는 하나의 도메인에 여러 아이피 주소가 결부되는 것을 허용하며, DNS 분석자는 여러 아이피 주소를 반환하도록 설정되거나 프로그래밍 될 수 있습니다.
DNS 분석자가 어떤 ip 주소를 반환할 것인가를 결정하는 방법은 단순한것(라운드 로빈)부터 더 복잡한 방식들도 존재합니다.

DNS 라운드 로빈

가장 흔하면서 가장 단순한 리다이렉션 기법
서버에 대한 클라이언트의 상대적인 위치나 서버의 현재 상황을 고려하지 않음.

ns look up을 활용해 확인한 IP address farm

다중 주소와 라운드 로빈 주소 순환

대부분의 DNS클라이언트는 다중 주소 집합의 첫번째 주소를 사용하고, 부하균형을 위해 DNS 서버는 룩업이 끝났을때 마다 주소를 순환시킴
- 이 순환을 DNS 라운드 로빈이라 부르기도 함.

ns look up을 활용해 DNS 주소목록 순회 확인

첫번째 DNS 룩업 주소는 125.209.222.142
두번째 DNS 룩업 주소는 210.89.164.90

다른 DNS 기반 리다이렉션 알고리즘

부하 균형 알고리즘
- 가장 로드가 적은 웹서버를 목록의 가장 위에 놓음
근접 라우팅 알고리즘
- 웹서버들의 farm이 지리적으로 분산되어 있을 경우, DNS 서버가 사용자를 근처의 웹 서버로 보내는 시도를 함
결함 마스킹 알고리즘
- 네트워크의 건강 상태를 모니터링하고 장애상황을 피해 라우팅 할 수 있음.

위와 같은 복잡한 서버 추적 알고리즘을 실행하고 있는 DNS 서버는 권위있는 서버(authoritative server) 라고 불리는 dns ㄴ서버(top level domain server)입니다.

사진 참고: https://umbrella.cisco.com/blog/2014/07/16/difference-authoritative-recursive-dns-nameservers/

임의 캐스트 어드레싱

백본 라우터의 최단거리 라우팅 능력에 의지
웹 서버는 라우터 통신 프로토콜을 이용해 자신과 인접한 백본 라우터와 대화함.
- 서버는 반드시 라우터의 언어로 말해야함
아직까지는 실험적인 기법

아이피 맥 포워딩

MAC 주소 포워딩은 점 대 점으로만 가능하기 때문에, 서버나 프락시는 스위치와 한 홉 거리에 위치해야 함

홉 거리 : 홉(hop)은 컴퓨터 네트워크에서 출발지와 목적지 사이에 위치한 경로의 한 부분이다. 데이터 패킷은 브리지, 라우터, 게이트웨이를 거치면서 출발지에서 목적지로 경유한다. 패킷이 다음 네트워크 장비로 이동할 때마다 홉이 하나 발생한다. 홉 카운트(hop count)는 데이터가 출발지와 목적지 사이에서 통과해야 하는 중간 장치들의 개수를 가리킨다.

아이피 주소 포워딩

MAC 포워딩보다 좋은 점은, 목적지 서버가 한 홉거리에 있을 필요가 없다는 점.
클라이언트로부터 들어오는 TCP 커넥션을 받아주는 스위치는 그 커넥션을 관리하고 있는데,스위치는 반드시 그 커넥션을 통해 클라이언트에게 응답을 돌려줘야함. 따라서, 목적지 서버나 프락시서버로부터의 모든 응답은 반드시 그 스위치에게 돌아가야 함.

네트워크 구성요소 제어 프로토콜

네트워크 구성요소 제어 프로토콜은 아이피 패킷을 전달하는 라우터나 스위치 같은 네트워크 구성요소들이 웹서버나 프락시 캐시와 같이 애플리케이션 계층 요청을 처리하는 서버 구성요소들과 대화할수 있게 함.
부하 균형을 명시적으로 지원하지는 않지만 서버 구성요소들이 네트워크 구성요소들에게 부하균형 유지를 위한 정보를 제공함.

프락시 리다이렉션 방법

콘텐츠에 접근할때 프락시를 통할 필요가 있는 경우도 있으며(보안상의 이유), 클라이언트가 이용하면 유익한 프락시 캐시가 네트워크에 있을 수 있습니다.

웹 브라우저와 같은 클라이언트들이 프락시로 가는 길을 아는 방법은 아래와 같이 세가지가 있습니다.
- 명시적인 브라우저 설정
- 동적인 자동 설정
- 자연스러운 가로채기

명시적 브라우저 설정

대부분의 브라우저에는 프락시 서버에 접촉하기 위해 프락시 이름, 아이피 주소, 포트번호를 설정할수 있는 풀다운 메뉴 존재함.

명시적 브라우저 설정 단점

프락시가 응답하지 않더라도, 원 서버와 접촉하지 않음
- 이 경우 프락시가 다운되거나 브라우저가 잘못 설정되면 사용자는 접속 문제를 경험할 가능성 있음
네트워크의 아키텍쳐를 변경했을 때 그 변경사항을 모든 최종사용자에게 전파 하는것이 어려움
- 프락시를 추가하거나 제거하려면 프락시 설정을 변경해야 함

프락시 자동 설정

올바른 프락시 서버에 접촉하기 위해 브라우저가 동적으로 자신을 설정할수 있게 하는 방식. 이를 프락시 자동설정(Proxy Auto-configuration, PAC) 프로토콜이라고 부릅니다.
PAC에 기본으로 깔려 있는 기본 아이디어는, 브라우저들이 URL별로 접촉해야 할 프락시를 지정한 PAC파일이라 불리는 특별한 파일을 찾도록 하는것입니다.

PAC파일은 아래 함수를 반드시 정의해야 하는 자바스크립트 파일입니다.

function FindProxyForURL(url, host)

브라우저는 요청된 URL마다 아래의 함수를 호출하게 됩니다. 반환된 값은 접촉할 프락시들의 목록이거나, 브라우저가 어떤 프락시든 우회해서 원서버로 바로 가야 함을 의미하는 문자열 "DIRECT" 일 수 있습니다.

또한, PAC 프로토콜은 매우 강력한데, 자바스크립트 프로그램은 브라우저에게 dns 주소나 요일인 시각과 같은 호스트명과 관련된 여러 매개변수에 근거하여 프락시를 선택하도록 요구할수 있습니다.

return_value = FindProxyForURL(url, host);

프락시 자동 설정

웹 프락시 자동발견 프로토콜 (WPAD)

최종 사용자가 수동으로 프락시 설정을 할 필요도, 투명한 트래픽 인터셉트에 의존할 필요 없이 웹브라우저가 근처의 프락시를 찾아내어 사용할수 있게 해주는 방법을 제공하는것을 목적으로 하고 있습니다.

WPAD 알고리즘

WPAD는 적절한 PAC 파일 CURL을 결정하기 위해 여러가지 리소스 발견 기법을 사용합니다.
또한, WPAD 클라이언트는 CURL을 얻는데 성공할때까지 각각의 기법을 하나씩 시도하게 됩니다.

오늘날의 WPAD 명세는 다음의 기법을 순서대로 정의하고 있습니다. 클라이언트는 DHCP를 먼저 시도하고, 그다음이 SLP입니다. 만약 PAC파일을 발견하자 못한다면, 클라이언트는 DNS기반 매커니즘으로 옮겨가게 됩니다.

클라이언트는 이때 DNS SRV, 잘 알려진 호스트명, DNS TXT 레코드 방법을 순회하게 되는데, DNS 쿼리 QNAME은 점점 덜 구체적이게 됩니다. 또한, 모든 DNS LOOKUP은 요청 받은 리소스 종류를 가리키게 되는 wpad 접두어가 붙은 QNAME을 가지게 됩니다.

DHCP (동적 호스트 설정 프로토콜)
- 이 메커니즘이 동작하려면, WPAD 클라이언트가 질의하는 DHCP 서버는 반드시 CURL을 저장하고 있어야 함.
SLP (서비스 위치 프로토콜)
DNS에게 잘 알려진 호스트명
DNS의 SRV 레코드
TXT 레코드의 DNS 서비스 url들

ex) 실제 desktop.development.ideveloper2.dev 라는 호스트명을 찾을때