HTTP

HTTP 완벽 가이드 (20)

kchabin 2025. 3. 18. 02:08

HTTP 메시지의 데이터는 여정 중에 많은 프로토콜에 의해 통제된다.

  • 리다이렉션 기술 → HTTP 메시지의 최종 목적지를 결정하는 네트워크 도구, 기법, 프로토콜
  • 메시지가 프락시, 캐시, 서버 팜의 특정 웹 서버 중 어디에서 끝나는지 판별하기 위한 용도
  • 리다이렉션 기법, load-balancing

리다이렉션은 피할 수 없는 현실

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

→ 여러 장소에 웹 콘텐츠 배포

  • 한 곳이 실패하면 다른 곳을 이용 → 신뢰성 개선
  • 가까운 리소스에 접근하여 빨리 받게 됨 → 응답시간도 줄여줌
  • 목적지 서버 분산 → 네트워크 혼잡도 감소

리다이렉션 구현 ↔ 부하균형 : 서로 공존

  • 들어오는 메시지의 부하를 서버들의 집합에게 분산
  • 어떤 방식의 부하 균형이든 리다이렉션을 포함 → 들어오는 메시지는 반드시 어떤 식으로든 부하를 공유하는 서버들 중 하나에 전달되어야 함.

리다이렉트 할 곳

서버, 프락시, 캐시, 게이트웨이 → 클라이언트 관점에서 모두 서버라고 볼 수 있음.(요청을 받아 처리)

  • 대부분의 리다이렉션 기법이 동작하나, 어떤 기술들은 특정 종류의 종단만을 위해 특별히 설계되어 일반적인 적용이 불가능하다. → 일반적 기법 / 특화적 기법

웹 서버

IP별로 요청을 다룸

  • 같은 URL에 대해 여러 곳에서 온 요청들을 각각 최적의 웹 서버로 보냄

프락시

프로토콜별로 요청을 다룸.

  • 프락시 이웃의 모든 HTTP 트래픽은 프락시를 거쳐야 함. → 이상적
  • 클라이언트 근처에 프락시 캐시 존재 = 모든 요청이 프락시 캐시로 가는 것이 이상적.
    • 자주 찾는 문서를 저장하여 클라이언트에게 직접 제공함.
    • 주 진입로의 트래픽을 근처에 있는 지름길로 빨아들임.

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

목표 : HTTP 메시지를 가용한 웹 서버로 가급적 빨리 보내기

메시지가 인터넷을 통해 나아가는 방향은 그 메시지가 오고, 거쳐가고, 향하는 HTTP 애플리케이션과 라우팅 장치에 영향을 받는다.

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

HTTP 리다이렉션

  • 최적인 웹 서버를 선택해줄 첫번째 웹 서버로 요청 전송
  • 선택한 서버로의 HTTP 리다이렉트를 보내줌
  • 클라이언트는 선택된 서버에게 재요청

DNS 리다이렉션

  • 도메인 이름 → 아이피 주소
  • DNS 분석자
    • 클라이언트의 운영체제
    • 클라이언트의 네트워크에 있는 DNS server
    • 원격 DNS 서버
  • DNS 라운드 로빈
    • DNS 호스트 명 분석 기능 → 웹 서버 팜 전체에 대한 부하의 균형
    • 순수한 부하 균형 전략
    • 서버에 대한 클라이언트의 상대적인 위치나 서버의 현재 스트레스를 고려하지 않음
% nslookup www.cnn.com
Name:    cnn.com
Addresses:  207.25.71.5, 207.25.71.6, 207.25.71.7, 207.25.71.8
          207.25.71.9, 207.25.71.12, 207.25.71.20, 207.25.71.22, 207.25.71.23
          207.25.71.24, 207.25.71.25, 207.25.71.26, 207.25.71.27, 207.25.71.28
          207.25.71.29, 207.25.71.30, 207.25.71.82, 207.25.71.199, 207.25.71.245
          207.25.71.246
Aliases:  www.cnn.com
  • www.cnn.com은 실제로 20개의 구분된 아이피 주소 농장
    • 일반적인 경우라면 각각 다른 물리적 서버로 해석되었을 것

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

  • 대부분의 DNS 클라이언트 → 다중 주소 집합의 첫번째 주소 사용
  • 부하 균형 → 대부분의 DNS 서버는 룩업이 끝났을 때마다 주소를 순환시킴 → DNS fkdnsem fhqls
% nslookup www.cnn.com
Name:    cnn.com
Addresses:  207.25.71.5, 207.25.71.6, 207.25.71.7, 207.25.71.8
          207.25.71.9, 207.25.71.12, 207.25.71.20, 207.25.71.22, 207.25.71.23
          207.25.71.24, 207.25.71.25, 207.25.71.26, 207.25.71.27, 207.25.71.28
          207.25.71.29, 207.25.71.30, 207.25.71.82, 207.25.71.199, 207.25.71.245
          207.25.71.246

% nslookup www.cnn.com
Name:    cnn.com
Addresses:  207.25.71.6, 207.25.71.7, 207.25.71.8, 207.25.71.9
          207.25.71.12, 207.25.71.20, 207.25.71.22, 207.25.71.23, 207.25.71.24
          207.25.71.25, 207.25.71.26, 207.25.71.27, 207.25.71.28, 207.25.71.29
          207.25.71.30, 207.25.71.82, 207.25.71.199, 207.25.71.245, 207.25.71.246
          207.25.71.5

% nslookup www.cnn.com
Name:    cnn.com
Addresses:  207.25.71.7, 207.25.71.8, 207.25.71.9, 207.25.71.12
          207.25.71.20, 207.25.71.22, 207.25.71.23, 207.25.71.24, 207.25.71.25
          207.25.71.26, 207.25.71.27, 207.25.71.28, 207.25.71.29, 207.25.71.30
          207.25.71.82, 207.25.71.199, 207.25.71.245, 207.25.71.246, 207.25.71.5
          207.25.71.6

DNS 룩업의 첫 번째 주소가 바뀌는 것을 볼 수 있음

부하 균형을 위한 DNS 라운드 로빈

  • DNS 순환 → 서버들 간의 부하 균형 유지
    • 안하면, 첫번째 서버가 대부분의 부하를 받게 됨

DNS 캐싱의 효과

  • DNS 주소 순환 → 완벽 x
    • DNS 룩업의 결과가 앱, 운영체제, 자식 DNS 서버 등에 의해 기억됨 → 재사용
    • 호스트 하나에 대한 한 번의 DNS 룩업 → 해당 주소 재사용
    • DNS 룩업 비용 감소, 같은 클라이언트와 계속 대화를 선호하는 서버
  • 비슷한 요청을 하는 클라이언트의 수가 어느 정도 이상만 된다면, 부하는 모든 서버에 걸쳐 상대적으로 잘 분산될 것

임의 캐스트 어드레싱

백본 라우터의 shortest-path routing 능력에 의존 → 클라이언트에 가장 가까운 서버에 요청 전송

  • 각 웹 서버가 이웃한 백본 라우터에게 자신이 라우터라고 광고하는 방법.
  • 라우터 통신 프로토콜 이용
  • anycast address를 목표로 하는 패킷을 받으면, 가장 가까운 라우터가 해당 ip address를 받을 것으로 보인다. → 서버는 자기가 그 주소를 위한 라우터라고 광고할 거고, 백본 라우터는 서버에 그 패킷을 전송

실험적인 이유

  • 라우터 언어로 대화해야 함
  • 라우팅 누수(route leaks) → 주소 충돌
  • 분산 임의 캐스트는 자신의 백본 네트워크를 제어하는 콘텐츠 제공자들을 위한 솔루션이 될 수 있음.

아이피 맥 포워딩

이더넷 네트워크 → HTTP 메시지 = 주소가 붙은 데이터 패킷 형태로 보내짐

  • 출발지/목적지 IP 주소, TCP 포트 번호 → Layer-4 주소
  • MAC 주소(Media Access Control) - Layer-2 장비가 이해함. 보통 스위치나 허브

특정 MAC 주소의 패킷을 받아서 나가는 특정 MAC 주소로 포워딩

 

  • 스위치는 맥 주소 MAC3에서 오는 모든 트래픽을 맥 주소 MAC4로 보내도록 프로그래밍 됨

 

  • 모든 웹 트래픽은 MAC3 → MAC6 프로그래밍 됨
  • 요청한 콘텐츠가 캐시 안에 있고 신선하면 제공
    • 원서버로 전송 → 스위치는 MAC6로부터의 80번 포트 요청을 게이트웨이(MAC6)로 보냄
  • L4 스위치는 보통 요청을 여러 프락시 캐시로 보냄 → 부하 균형 유지
  • 비슷하게 HTTP 트래픽은 대체 HTTP 서버로도 전달될 수 있음.
  • MAC 포워딩 : 점 대 점으로만 가능
    • 서버나 프락시는 스위치와 한 hop 거리에 위치해야 함.

아이피 주소 포워딩

들어오는 패킷에 대해 TCP/IP addressing을 검증 → 패킷을 목적지 아이피 주소의 변경에 따라 라우팅함.

  • 목적지 서버가 한 홉 거리에 있을 필요 없음 → MAC포워딩보다 좋은 점
  • 스위치에서 업스트림의 위치를 판별할 수만 있으면 일반적인 레이어-3 종단간 인터넷 라우팅이 패킷을 올바른 위치로 보내줌.
    • Network Address Translation, NAT

라우팅 대칭성 문제

클라이언트와 커넥션을 관리하는 스위치. 스위치는 반드시 그 커넥션을 통해 응답을 클라이언트에게 돌려주어야 함.

→ 목적지 서버나 프락시로부터의 모든 응답은 반드시 그 스위치에게 돌아가야 함

 

 

완전 NAT

  • 패킷의 출발지 ip 주소를 스위치의 ip 주소로 바꿈
    • 스위치-서버 간 네트워크 설정 관계 x, 응답 패킷을 스위치로
    • 목적지와 출발지 아이피 주소 양쪽을 번역해주는 장치 → 완전 NAT

<aside> 💡

proxy는 결국 서버와 클라이언트 사이의 있는 모든 것? 스위치도 프록시?

허브 : 브로드 캐스트 방식. MAC 주소 모름 스위치 : 허브 단점 보완 장비

  • 데이터 패킷의 출발지와 목적지 인식 가능 → 원하는 호스트로 데이터 전송 가능
  • 맥 주소 저장

게이트웨이 : 서로 다른 네트워크 상의 통신 프로토콜을 적절히 변환해주는 역할

</aside>

반 NAT

클라이언트의 ip 주소로 출발지 주소가 그대로

  • 서버는 클라이언트의 ip 주소를 얻을 수 있음.
  • 단점 : 클라이언트와 서버 사이의 네트워크 전체에 약간의 통제가 필요함.

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

  • NE, SE 간 대화 가능

지원하는 패킷 전달 방식

  • MAC 포워딩
  • GRE 캡슐화
  • NAT

출발지 ip 서비스 불가능 판단 → NE로 그 주소들을 전송.

NE는 그 아이피 주소로부터의 요청을 원 서버로 전달할 수 있음.

  • SE가 예외를 식별
    • *서비스 엔진(SE)**은 특정 소스 IP 주소에서 들어오는 요청을 처리할 수 없다고 판단할 수 있음.
    • 이는 로드 밸런싱, 보안 정책, 콘텐츠 제한 등의 이유 때문일 수 있음.
  • NE가 예외 트래픽을 처리
    • *네트워크 엣지(NE)**는 SE로부터 예외로 지정된 IP 주소 목록을 전달받음.
    • 이러한 IP에서 오는 요청을 자체적으로 처리하는 대신, 원본 서버(origin server)로 직접 전달함.

프록시 리다이렉션

  1. 보안상의 이유
  2. 캐시된 콘텐츠
    1. 요청한 콘텐츠가 없는 프록시 캐시 → 클라이언트를 다른 캐시로 리다이렉트

명시적인 브라우저 설정

브라우저의 풀다운 메뉴 : 프락시 이름, ip 주소, 포트번호 설정

  • 미리 설정이 다 되어있는 브라우저를 사용자가 다운받도록 함.
  • 다운 받은 브라우저들은 접촉할 프락시의 주소를 알고 있음.

단점

  1. 프락시가 응답하지 않더라도 원 서버와 접촉하지 않음.
  2. 네트워크 아키텍처 변경 사항을 모든 최종사용자에게 전파하는 것이 어려움.

프락시 자동설정

명시적 설정의 단점인 네트워크 아키텍처의 변화 제한을 브라우저가 동적으로 자신을 설정할 수 있게 하는 방법으로 해결

  • PAC, Proxy Auto-configuration
  • PAC 파일 : 브라우저들이 URL별로 접촉해야 할 프록시를 지정한 파일
  • 재시작할 때마다 PAC 파일(js)을 가져옴
function FindProxyForURL(url, host) //반드시 정의해야하는 함수.

요청된 URL마다 브라우저는 다음 함수를 호출한다.

return_value = FindProxyForURL(url_of_request, host_in_url);

PROXY proxy1.domain.com; PROXY proxy2.domain.com

DIRECT : 프락시를 우회해서 원 서버로 바로 가야 함

Web Proxy Autodiscovery Protocol

웹 브라우저가 근처의 프락시를 찾아내어 사용할 수 있게 해주는 방법 제공

  • WPAD는 프락시 서버를 알아내는 PAC URL을 알아냄

 

  • WPAD를 이용해 PAC 파일 CURL을 찾는다
  • URL에 해당하는 PAC 파일을 가져온다
  • 프록시 서버를 알아내기 위해 그 PAC 파일을 실행한다
  • 반환한 프락시 서버에게 HTTP 요청을 보냄

WPAD 알고리즘

  • DHCP(Dynamic Host Configuration Protocol, 동적 호스트 설정 프로토콜)
  • SLP(Service Location Protocol)
  • DNS에게 잘 알려진 호스트명
  • DNS의 SRV 레코드
  • TXT 레코드의 DNS 서비스 URL들

 

클라이언트는 가능한 한 가장 구체적인 설정 정보를 찾되, 그러지 못한 경우에는 덜 구체적인 정보라도 취한다.

  • 모든 DNS 룩업은 요청 받은 리소스 종류를 가리키는 “wpad” 접두어가 붙은 QNAME을 갖는다.

DHCP를 이용한 CURL 발견

  1. WPAD 클라이언트는 DHCP 서버에 질의(DHCP Query)를 보냄
  2. DHCP 서버가 DHCP 옵션 코드 252를 설정해두었다면, 이 값으로 PAC 파일이 위치한 URL을 포함한 응답을 반환
  3. 클라이언트는 응답에서 PAC 파일 URL을 추출하여 해당 파일을 다운로드하고, 이를 이용해 프록시 설정을 자동으로 구성

만약 클라이언트가 부팅 과정에서 이미 DHCP를 통해 IP 정보를 가져왔고, WPAD 정보도 함께 받아왔다면, 추가 질의 없이 바로 해당 정보를 사용할 수 있다. 하지만, 이 정보가 운영체제 API에서 접근할 수 없는 경우, 클라이언트는 DHCPINFORM 메시지를 보내 다시 DHCP 서버에서 옵션 252 값을 요청할 수도 있다.

DNS A 레코드 룩업

QNAME=wpad.TGTDOM., QCLASS=IN, QTYPE=A

내가 다룰 수 있는 CFILE(PAC파일) 포맷 정보가 담긴 Accept 헤더를 GET 요청에 포함.

Accept: application/x-ns-proxy-autoconfig
  • CURL 결과가 리다이렉트라면, 그 리다이렉트가 향하는 곳이 클라이언트의 최종 목적지임

CURL 요청 처리 웹 서버

프록시 서버 자체 WPAD 요청 처리

1️⃣ 클라이언트가 http://wpad.example.com/proxy.pac 요청

2️⃣ 웹 서버(혹은 프록시 서버)가 PAC 파일을 제공

3️⃣ PAC 파일 내부의 FindProxyForURL(url, host) 함수에서

  • 클라이언트의 IP 주소, 서브넷, User-Agent, 네트워크 위치 등을 확인
  • 가장 가까운 프록시 서버를 선택 (PROXY proxyA.example.com:8080; PROXY proxyB.example.com:8080; DIRECT)4️⃣ 클라이언트가 PAC 파일의 설정에 따라 proxyA.example.com에 연결5️⃣ 프록시 A가 트래픽을 분석 후,
  • 직접 처리할 수도 있고,
  • 다른 프록시 서버로 리다이렉트할 수도 있음 (예: proxyB.example.com)

PAC 파일이 클라이언트에서 동적으로 프록시 선택 가능

  • PAC 파일 자체도 클라이언트에서 프록시를 동적으로 선택하는 기능을 가질 수 있다.
    • 네트워크 거리, 응답 속도(Fitness Metrics) 계산 → 가장 가까운 프록시 서버 선택
    • CARP(Cache Array Routing Protocol) : 캐시 서버 간 부하 분산 수행
  • 단순한 고정된 프록시 리스트가 아니라, 실시간으로 가장 적합한 프록시 서버를 선택할 수 있는 유연한 구조를 가질 수 있음.

WPAD를 사용하면 프록시 설정을 정적으로 할당하는 게 아니라, 다양한 조건을 반영해 "가장 적절한" 프록시를 선택할 수 있다는 점이 핵심

캐시 리다이렉션

  • 신뢰성 높고, 고성능, 콘텐츠 지각 디스패칭 → 복잡함

WCCP

시스코시스템즈 → 웹 라우터들이 웹 트래픽을 프락시 캐시로 리다이렉트할 수 있도록 캐시 조직 프로토콜을 개발함.

WCCP2 → 오픈

WCCP 동작

 

 

  • 네트워크 → WCCP 사용 가능 라우터, 다른 캐시와 의사소통할 수 있는 캐시 포함
  • WCCP 서비스 그룹 설정
    • 어떤 트래픽이 어디로 어떻게 보내지는지
    • 캐시들 사이의 부하 분산
  • HTTP 트래픽 리다이렉션 설정 : 라우터는 요청을 그룹의 캐시로 전송함.
  • 요청이 들어오면 라우터는 캐시 중 하나를 선택함
    • 기준 : 요청 아이피 주소의 해시값, 마스크/값 집합 짝짓기(pairing) 스킴 중 하나

mask/value pairing scheme

  • 마스크를 사용하여 특정 비트 패턴을 추출하고, 그 결과 값(value)과 비교하여 데이터를 분류하는 방식
  • 네트워크 부하 분산(IP 기반 라우팅, WCCP), 캐시 시스템, 데이터베이스 샤딩 등에 활용됨
  • 마스크는 특정 비트 필드를 선택하는 역할, 값은 해당 패턴이 매칭되는 조건 의미
  • IP 주소와 서브넷 마스크 AND 연산
    • IP 주소: 192.168.1.34
      • 192 → 11000000
      • 168 → 10101000
      • 1 → 00000001
      • 34 → 00100010
      따라서, 192.168.1.34는 이진수로 11000000.10101000.00000001.00100010입니다.
    • 서브넷 마스크: 255.255.255.0
      • 255 → 11111111
      • 255 → 11111111
      • 255 → 11111111
      • 0 → 00000000

📌 예제: HTTP 요청 URL을 기반으로 부하 분산

마스크 (Mask) 값 (Value) 대상 캐시 서버

0xFF000000 0x0A000000 (10.0.0.0) 캐시 서버 1
0xFF000000 0x0B000000 (11.0.0.0) 캐시 서버 2

👉 동작 방식:

  1. 사용자가 10.1.2.3 주소로 HTTP 요청을 보냄.
  2. 10.1.2.3 & 0xFF000000 = 0x0A000000 (10.0.0.0)
  3. 10.0.0.0은 캐시 서버 1에 해당하므로 해당 서버로 트래픽 전송.
  4. 만약 11.2.3.4 요청이라면, 11.0.0.0 과 매칭되어 캐시 서버 2로 보냄. </aside>

Internet Cache Protocol

 

형제 캐시에서 일어난 캐시 적중을 찾을 수 있도록 함.

  • 캐시에게 그 요청 콘텐츠가 없을 경우, 근처의 형제 캐시 중 그 콘텐츠를 갖고 있는 것이 있는지 찾아보고 만약 있다면 가져옴
  • 원 서버보다 저비용 기대
  • 일종의 캐시 클러스터링 프로토콜
  • 한 차례 이상의 ICP 질의를 통해 최종 목적지를 결정할 수 있다는 점에서 리다이렉션 프로토콜.
  • 객체 발견 프로토콜
  • ICP 메시지 : 파싱하기 쉽도록 네트워크 바이트 순서에 따라 32비트 크기로 맞춰진 구조체
  • UDP → 신뢰할 수 없음 → 타임아웃으로 데이터 그램 손실 감지 필요

 

플래그

  1. ICP_FLAG_HIT_OBJ : 문서 데이터가 ICP 응답으로 돌아오는 것을 가능하게 할 것인지
  2. ICP_FLAG_SRC_RTT : 형제 캐시가 측정한 원 서버로의 왕복 시간에 대한 추정 요청
  • Option Data에 위 측정값을 담아둠

캐시 배열 라우팅 프로토콜(CARP)

대량의 트래픽은 프록시 서버 자체에 과도한 부하를 줄 수 있다.

  • 부하를 분산하기 위해 사용하는 프록시 서버를 여러 대로 늘려서 해결한다.
  • 프록시 서버 배열이 클라이언트의 시점에서는 마치 하나의 논리적인 캐시처럼 보이도록 관리해줌
  • ICP의 대안
    • ICP 프로토콜로 연결된 프록시 서버들 각각은 프록시 서버들 전체에 걸친 웹 객체에 대한 중복된 엔트리가 허용되는 독립적인 캐시임
  • CARP는 각 구성요소 서버가 전체 캐시된 문서의 일부만 갖고 있는 하나의 큰 서버처럼 동작함.
  • 웹 객체의 URL에 해시 함수 적용 → 웹 객체를 특정 프록시 서버에 매핑함.
  • 하나의 웹 객체는 하나의 프록시 서버에만 속함.
    • 프록시 서버 각각을 폴링하지 않고도 한 번의 검색으로 그 객체의 위치를 결정할 수 있음.

단점

  • 한 서버가 고장 → 해시 함수 수정, 콘텐츠 재배치 → 고비용 가능성
    • ICP 프록시 서버는 중복 콘텐츠 → 재배치 필요 x
  • ICP 프로토콜만 수행하는 기존 프록시 서버는 CARP 무리에 쉽게 포함될 수 없을 것이라는 점.

장점

  • ICP에서 그룹안에 있는 웹 객체를 찾아내기 위해 자주 생성되는 프록시 간 트래픽 감소시킴
  • 중복된 웹 캐시에 대한 사본의 중복을 피함 → 집합적으로 웹 객체를 더 많이 보관할 수 있음.

HTCP

ICP는 0.9 버전 타겟팅 → URL만 전송함 → 정확한 응답을 가져오지 못하는 결과

  • 형제들이 URL과 모든 요청 및 응답 헤더를 사용하여 서로에게 문서의 존재 여부에 대한 쿼리를 할 수 있도록 해줌
  • 비적중으로 잘못 처리될 확률 감소시키기
  • 더 나아가, 형제 캐시들이 서로의 캐시 안에 있는 선택된 문서의 추가 및 삭제를 모니터링하고 요청할 수 있게
    • 서로의 캐시된 문서에 대한 캐싱 정책을 변경함
저작자표시 비영리 변경금지

'HTTP' 카테고리의 다른 글

HTTP 완벽 가이드 (21)  (0) 2025.03.18
HTTP 완벽 가이드 (19)  (0) 2025.03.18
HTTP 완벽 가이드 (18)  (0) 2025.03.18
HTTP 완벽 가이드 (17)  (0) 2025.03.18
HTTP 완벽 가이드 (16)  (0) 2025.03.18

'HTTP'의 다른글

  • 현재글HTTP 완벽 가이드 (20)

관련글

티스토리툴바