HTTP 완벽 가이드 스터디 (6)

HTTP

HTTP 완벽 가이드 스터디 (6)

kchabin 2024. 10. 8. 15:24

https://drive.google.com/file/d/1NuuJ8Y75yRWTbgVeXqWZ3rCvdz83TsG1/view

6장.drawio

drive.google.com

웹 프락시 서버 = 중개자

클라이언트에겐 서버 역할, 서버에겐 클라이언트처럼 동작함.

개인 프락시와 공유 프락시

개인 전용 프락시

흔하진 않지만 꾸준히 사용되고 있음.
브라우저 기능 확장, 성능 개선
무료 isp 서비스를 위한 광고 운영용 작은 프락시를 사용자의 컴퓨터에서 직접 실행함.

공유 프락시

대부분 공용이며 공유된 프락시
중앙 집중형 프락시 관리가 더 비용 효율이 높고, 쉬움.
캐시 프락시 서버 → 이용자가 많을수록 유리함. ⇒ 공통된 요청에서 이득을 취하기 때문.

프락시 대 게이트웨이

프락시 : 같은 프로토콜 사용

게이트웨이 : 서로 다른 프로토콜을 사용하는 둘 이상의 애플리케이션 연결

사용 이유

어린이 필터

문서 접근 제어자

보안 방화벽

웹 캐시

대리 프락시(Surrogate Proxy)

서버 가속기
웹 서버인 것처럼 위장함.

콘텐츠 라우터

서버 A는 복제 캐시로 콘텐츠 분산을 위해 돈을 지불함.
콘텐츠 라우터는 지불한 서버의 요청은 복제 캐시로 보내지만, 서버 B의 요청은 원 서버로 보냄

트랜스 코더: 데이터의 표현 방식을 자연스럽게 변환(트랜스코딩)

이미지 크기 변환
텍스트 압축 → 웹 페이지를 스마트폰용으로 줄이기
외국어 문서로 변환

익명화 프락시

HTTP 메시지에서 신원을 식별할 수 있는 특성들을 제거 → 개인정보보호, 익명성 보장
User-Agent 헤더에서 사용자의 컴퓨터와 OS 종류 제거
어떤 사이트를 거쳐서 방문했는지 알기 어렵게 하기 위해 Referer 헤더 제거
Cookie 헤더 제거 → 프로필과 신원 정보 삭제

프락시의 위치

어떻게 네트워크에 배치되는가
어떻게 연쇄가 계층을 이루는가

프락시 서버 배치

출구(Egress) 프락시

LAN과 더 큰 인터넷 사이를 오가는 트래픽 제어용
LAN의 출구에 위치하는 프락시.
방화벽, 인터넷 요금 절약, 인터넷 트래픽 성능 개선, 성인용 콘텐츠 필터링

접근(입구) 프락시

ISP(인터넷 서비스 제공업체) 접근 프락시
고객으로부터의 모든 요청을 종합적으로 처리
캐시 프락시로 요청 사본 저장
- 사용자들의 다운로드 속도 개선(고속 접속 사용자)
- 인터넷 대역폭 비용 절감.

대리 프락시

리버스 프락시라고도 함.
네트워크의 가장 끝에 있는 웹 서버들의 바로 앞에 위치함.
보안 기능 추가 or 빠른 웹 서버 캐시를 느린 웹 서버 앞에 놓기 → 성능 개선
웹 서버의 이름과 IP 주소로 가장함. → 모든 요청이 서버가 아닌 프락시로 간다.

네트워크 교환 프락시

캐시를 이용해 인터넷 교차로의 혼잡 완화
트래픽 흐름 감시
네트워크 사이 인터넷 피어링 교환 지점들에 놓일 수 있음

프락시 계층

프락시 서버들은 부모와 자식의 관계를 가짐.

부모 : 인바운드 프락시
자식 : 아웃바운드 프락시

콘텐츠 라우팅

위 그림의 프락시 계층은 정적 → 항상 보내는 방향이 같음.

계층이 반드시 정적일 필요 x → 메시지를 다양한 프락시 서버와 원 서버들의 집합에게 보낼 수 있음.

콘텐츠 분산을 위해 돈을 지불한 웹 서버 → 가까운 캐시 서버에 객체를 반환하도록 하거나 원 서버에서 가져옴
특정 종류의 이미지에 관한 요청 → 특화된 압축 프락시에게 요청 전송. 그 프락시가 이미지를 가져와 압축하게 하여 느린 모뎀으로 접속했더라도 빠르게 클라이언트가 다운로드 할 수 있도록 함.

동적 부모 선택의 예

부하 균형

자식 프락시는 부하를 분산하기 위해 현재 부모들의 작업량 수준에 근거하여 부모 프락시를 고름

지리적 인접성에 근거한 라우팅

자식 프락시는 원 서버의 지역을 담당하는 부모를 선택할 수도 있음.

프로토콜/타입 라우팅

URI에 근거하여 다른 부모나 원 서버로 라우팅.

특정 종류의 URI를 갖고 있는 요청의 경우, 특별한 프락시 서버로 보내져 특별한 프로토콜로 처리

유료 서비스 가입자를 위한 라우팅

웹 서비스 운영자가 빠른 서비스를 위해 추가금 지불 시 라우팅

대형 캐시
성능 개선 압축엔진

클라이언트 트래픽을 프락시로 가도록 만드는 방법

클라이언트 수정

수동 or 자동 프락시 설정

바로 그리고 의도적으로 원 서버가 아닌 프락시로 HTTP 요청을 보냄

DNS namespace 수정

웹 서버의 이름과 IP 주소를 사용하는 대리 프록시

모든 요청은 서버 대신 대리 프록시로.
- DNS 이름 테이블을 수동으로 편집
- 특별한 동적 DNS 서버 → 사용할 적절한 프록시나 서버를 계산해줌.
실제 서버의 IP 주소와 이름은 변경되고, 대리 프록시에는 이전 주소와 이름이 주어짐.

웹 서버 수정

HTTP 리다이렉션 명령(305)을 클라이언트에게 반환.

클라이언트 요청을 프락시로 리다이렉트 하도록 설정함.

클라이언트 프락시 설정

수동 설정
브라우저 기본 설정
PAC
WPAD (웹 프락시 자동발견 프로토콜)

PAC

자바스크립트 PAC 파일의 URI를 브라우저에 설정해야함.

‘자동 설정’ 상자에 URI 제공

브라우저는 URI로부터 PAC 파일을 가져와서 매 접근마다 적절한 프락시 서버를 계산하기 위해 js 로직을 이용함.

.pac 확장자 사용
MIME 타입 : ‘application/x-ns-proxy-autoconfig’
FindProxyForUrl(url, host) : URI에 접근할 때 사용할 적절한 프락시 서버를 계산

WPAD

브라우저에게 알맞은 PAC 파일을 자동으로 찾아주는 알고리즘.

PAC URI를 찾기 위해 wpad 사용
주어진 uri에서 pac 파일을 가져옴
프락시 서버를 알아내기 위해 pac 파일 실행
알아낸 프락시 서버를 이용해서 요청을 처리함.

리소스 발견 기법(성공할 때까지 각 기법 하나씩 시도)

동적 호스트 발견 규약(DHCP)
서비스 위치 규약(SLP)
DNS 잘 알려진 호스트 명
DNS SRV 레코드
DNS TXT 레코드 안의 서비스 URI

프락시 요청의 특징

프락시 URI와 서버 URI 차이

클라이언트가 서버 대신 프락시로 요청을 보내면 요청 URI가 달라짐

완전한 URI를 가짐
단일 서버는 자신의 호스트 명과 포트 번호를 알고 있음
- 불필요한 발송을 피하기 위해 스킴과 호스트가 없는 부분 URI만 전송
‘스킴/호스트/포트번호 누락’ 문제
프락시가 목적지 서버와 커넥션을 맺기 위해선 완전한 URI가 필요.

⇒ 서버로는 부분 URI, 프락시로는 완전한 URI 전송.

가상 호스팅에서 일어나는 문제

가상으로 호스팅 되는 웹 서버는 여러 웹 사이트가 같은 물리적 웹 서버를 공유함.

요청이 접근하고자 하는 웹 사이트의 호스트 명을 알아야 함.
Host 헤더 요구

대리프락시

원 서버를 대신하는 프락시 서버

인터셉트 프락시

서버로 가는 요청을 가로채기 때문에, 웹 서버로 보내는 부분 URI를 얻게 됨.

다목적 프락시 서버는 요청 메시지의 완전한 URI, 부분 URI 모두 지원해야 함.

완전한 URI → 프락시는 그것을 사용해야 함.
부분 URI + 호스트 → Host 헤더로 원 서버의 이름과 포트 번호를 알아내야 함.
부분 URI, Host 헤더는 없음
- 대리 프락시 : 프락시에 실제 서버의 주소와 포트 번호가 설정되어 있을 수 있음
- 인터셉트 프락시 : 원 ip 주소와 포트번호를 사용할 수 있도록 해두었다면 사용 가능
- 모두 실패 시 에러 메시지 반환

전송 중 URI 변경

상호운용성 문제

가능한 한 관대한 프락시 → 기존에 잘 동작하던 기능들을 망가뜨리는 결과를 수반할 수 있음.
HTTP 명세는 인터셉트 프락시가 uri를 전달할 때 절대 경로를 고쳐 쓰는 것을 금지함.
- 예외: 빈 경로 → ‘ / ’ 로 교체

URI 클라이언트 자동확장과 hostname resolution

프락시의 존재 여부에 따라 요청 URI를 다르게 분석함.

프락시가 없는 경우
- 사용자가 타이핑한 uri를 갖고 그에 대응하는 ip 주소를 찾음
- 호스트가 발견되지 않는 경우, 자동화된 호스트 명의 ‘확장’ 제공
  - 접두사, 접미사 붙이기
  - 서드파티 사이트로 오타 교정 시도, 사용자가 의도했을 URI 제시
  - DNS 자동 도메인 검색.

프락시 없는 URI 분석

명시적인 프락시가 존재하지 않는 경우 부분 호스트 명을 자동으로 확장한다.

명시적인 프락시를 사용할 때의 URI 분석

인터셉트 프락시 사용

클라이언트 입장에선 프락시는 존재하지 않는 것.

DNS가 성공할 때까지 호스트 명을 자동확장하는 브라우저를 사용할 때, 동작은 프락시가 아닌 서버의 경우와 별 차이가 없음.

인터셉트 프락시를 사용하고 있는 브라우저는 죽은 서버의 IP 주소를 탐지할 수 없음.

첫 번째 접속 시도는 원 서버가 아닌 프락시 서버에 의해 종료된다.
- 클라이언트는 성공적으로 웹 서버와 대화했다고 믿지만, 웹 서버는 살아있지도 않았을 것
프락시는 죽은 서버의 dns 분석에 대해서 브라우저에서 제공하는 것과 동등한 수준의 장애 허용(fault tolerance)을 지원해야 함.
- 호스트 명 재분석
- 역방향 DNS 룩업 → 다른 IP 주소 시도

메시지 추적

캐시 프락시 서버를 많이 사용함.

프락시를 넘나드는 메시지의 흐름을 추적하고 문제점을 찾아내는 것이 필요하게 됨.

Via

메시지가 지나가는 각 중간 노드(프락시 or 게이트웨이)의 정보를 나열함.

쉼표로 구분된 경유지(waypoint)의 목록

Via: 1.1 proxy-a.irenes-isp.net, 1.0 cache.example.com

게이트웨이

via 헤더는 프로토콜 변환을 기록함.
HTTP 애플리케이션은 프락시 연쇄에서 프로토콜 능력과 변환이 있었는지를 알아챌 수 있음.

GET ftp: //http-guide.com/index.html HTTP/1.0

Via: FTP/1.0 proxy.irenes-isp.net (Traffic-Server/5.0.1-17882 [cMs f])

server 헤더와 via

원 서버에 의해 사용되는 소프트웨어를 알려줌

Server: Apache/1.3.14 (Unix) PHP/4.0.4

프락시는 Server 헤더를 수정하면 안됨. → 원 서버를 위해 존재함.
대신에 Via 항목을 추가해야 함.

host 명 가리기

프록시 서버가 네트워크 방화벽의 일부인 경우 방화벽 뒤에 숨어있는 host , port를 전달해서는 안된다.
- 방화벽 뒤의 네트워크 아키텍처에 대한 정보가 악의적인 집단에 의해 이용될 수 있기 때문임.

호스트 가명 처리

보안 경계선의 일부분인 프락시는 호스트 명을 그 호스트 명에 대한 적당한 가명으로 교체해야 함.

내부 네트워크 아키텍처의 설계와 토폴로지를 알아내기 어렵게

Via 경유지 항목들을 하나로 합칠 수 있음.
- 수신된 프로토콜 값들이 동일해야 함.

Via: 1.0 foo, 1.1 devirus.company.com, 1.1 access-logger.company.com
Via: 1.0 foo, 1.1 concealed-stuff

Trace 메서드

프락시 서버는 메시지가 전달될 때 메시지를 바꿀 수 있음.

헤더 추가, 변경, 삭제 / 본문 형식 변환
점점 프락시가 복잡해지고, 더 많은 벤더가 프락시 제품을 배치하면서 상호운용성 문제가 증가함.

→ 홉에서 홉으로 전달될 때마다 메시지의 내용이 어떻게 변하는지 편리하게 관찰할 방법 필요

프락시 흐름을 디버깅하는 데 매우 유용함.
응답 Content-Type message/http , 200 OK
- 수신한 요청 메시지를 그대로 돌려보냄

Max-Forwards

TRACE와 OPTIONS 요청의 프락시 hop 개수 제한

프락시 연쇄 테스트(무한 루프)
연쇄 중간 특정 프락시 서버들의 효과 체크

몇 번 더 다음 홉으로 전달될 수 있는지 말해주는 정수를 담고 있음.

프락시 인증

제한된 콘텐츠에 대한 요청 → 프락시

407 Proxy Authorization Required 상태 코드 + Proxy-Authenticate 헤더 필드

저작자표시 비영리 변경금지