6장. 프락시

프락시 서버 : 중개자
클라이언트 - 프락시 - 서버
- HTTP메시지를 정리하는 중개인 처럼 동작한다

이 장에서는 ...

프락시 기능에 대한 특별한 지원
프락시 서버를 사용할 때 보게 될 몇 가지 교묘한 동작
HTTP 프락시 서버의 모든 것

이 장에서 다룰 내용

HTTP 프락시와 웹 게이트웨이를 비교하고 HTTP 프락시가 어떻게 배치되는지 그림으로 보여주면서 설명
몇 가지 유용한 활용방법을 보여준다
프락시가 실제 네트워크에 어떻게 배치되어 있는지 그리고 트래픽이 어떻게 프락시 서버로 가게 되는지 설명한다
브라우저에서 프락시를 사용하려면 어떻게 설정해야 하는지 보여준다
HTTP 프락시 요청이 서버 요청과 어떻게 다른지,
- 그리고 프락시가 어떻게 브라우저의 동작을 미묘하게 바꾸는지 보여준다
일련의 프락시 서버들을 통과하는 메시지 경로를, Via 헤더와 TRACE 메서드를 이용해 기록하는 방법을 설명한다
프락시에 기반한 HTTP 접근 제어를 설명한다
어떻게 프락시가 클라이언트와 서버 사이에서 각각의 다른 기능과 버전들을 지원하면서 상호작용 할 수 있는지 설명한다

6.1 웹 중개자

웹 프락시 서버 : (클라이언트의 입장에서) 트랜잭션을 수행하는 중개인
웹 프락시가 없다면 => 클라이언트는 HTTP 서버와 직접 이야기 한다
웹 프락시가 있다면 => 클라이언트는 HTTP 서버와 이야기 하는 대신, 자신의 입장에서 서버와 대화해주는 프락시와 이야기 한다
프락시 서버가 제공하는 좋은 서비스?
프락시 서버는 웹 서버이기도 하고 웹 클라이언트 이기도 하다

프락시는 웹 클라이언트에서 볼 때 서버처럼 동작하면서 요청 메세지를 받고 응답 메세지를 돌려준다
프락시는 웹 서버에서 볼 때 클라이언트 처럼 동작하면서 웹 요청 메세지를 보내고 웹 응답 메세지를 받는다

6.1.1 개인 프락시와 공유 프락시

공용 프락시

여러클라이언트가 공유
대부분의 프락시가 공용이며 공유된 프락시
중앙 집중형 프락시를 관리하는게 더 비용효율이 높고 쉽다
프락시를 이용하는 사용자가 많을 수록 공통된 요청에서 이득을 취할 수 있음

개인프락시

하나의 클라이언트만을 위한 프락시

ISP(Internet service provider) **인터넷 서비스 제공자(Internet service provider; ISP)는 인터넷에 접속하는 수단을 제공하는 주체를 가리키는 말이다.** 그 주체는 영리를 목적으로 하는 사기업인 경우가 대다수이나 비영리 공동체가 주체인 경우도 있다.

ISP는 일반적으로 인터넷에서 이용 가능한 모든 것에 대한 접근권을 사용자에게 부여하는 액세스 포인트나 게이트웨이 역할을 한다.

KT, SKT, LG유플러스
출처 : 위키백과

6.1.2 프락시 vs. 게이트웨이

그림 6-2

프락시 : 같은 프로토콜을 사용하는 둘 이상의 애플리케이션을 연결
게이트웨이 : 서로 다른 프로토콜을 사용하는 둘 이상을 연결
그림 6-2b는 HTTP 프론트엔드와 POP 이메일 백엔드를 연결
- Naver메일, Daum메일과 같은 웹 기반 이메일 프로그램은 HTTP 이메일 게이트웨이다

메일 관련 프로토콜 : POP, SMTP - https://help.naver.com/support/contents/contents.help?serviceNo=2342&categoryNo=2284 - https://m.blog.naver.com/PostView.naver?isHttpsRedirect=true&blogId=sung_mk1919&logNo=221402277615 - https://www.hanbiro.com/temp/print_view.php?bid=spammail&no=1

실질적으로 프락시와 게이트웨이의 차이점은 모호하다
상용 프락시 서버는 SSL 보안 프로토콜, SOCKS 방화벽, FTP 접근 그리고 웹 기반 애플리케이션을 지원하기 위해 게이트웨이 기능을 구현한다.
- 게이트웨이 : 8장

프락시 vs. 게이트웨이

둘 다 내부 네트워크를 인터넷으로 라우팅
게이트웨이 : 프록시 = '문' : '벽'
프록시 서버는 허용된 커넥션만 걸러주지만, 게이트웨이는 어떠한 필터링도 해주지 않는다.
출처 : https://coding-start.tistory.com/342

6.2 왜 프락시를 사용하는가?

프락시 서버 : 실질적이고 유용한 것이라면 무슨 일이든 함
- 보안 개선
- 성능 향상
- 비용 절약
- 트래픽 감시

어린이 필터

부적절한 사이트의 접근을 강제로 거부

문서 접근 제어자

접근 제어 전략을 구현하고 감사 추적(audit trail)
필터랑 비슷한데 비밀번호를 묻는 차이가 있는 것 같다

보안 방화벽

조직 안에 들어오는 프로토콜의 흐름을 통제

웹 캐시

인기 있는 문서의 로컬 사본을 관리
- 프락시에 있는 데이터는 언제 갱신될까?
  - 각 서비스마다 다를 것 같다
  - https://docs.oracle.com/cd/E19438-01/819-3161/agcache.html

대리 프락시

웹 서버인 것 처럼 위장
- 리버스프락시 == 서버 가속기
리버스 프락시로 불리는 이들은 진짜 웹 서버 요청을 받지만 웹 서버와는 달리 요청 받은 콘텐츠의 위치를 찾아내기 위해 다른 서버와 커뮤니케이션을 함
공용 콘텐츠에 대한 느린 웹 서버의 성능을 개선하기 위해 사용될 수 있다
콘텐츠 라우팅기능과 결합되어 주문형 복제 콘텐츠의 분산 네트워크를 만들기 위해 사용될 수 있다

콘텐츠 라우터

CDN - 넷플릭스, 라이브러리 등
- CDN 위키백과
- CDN 이란
인터넷 트래픽 조건과 콘텐츠의 종류에 따라 요청을 특정 웹 서버로 유도
사용자나 콘텐츠 제공자가 더 높은 성능을 위해 돈을 지불했다면 콘텐츠 라우터는 요청을 가까운 복제 캐시로 전달할 수 있음

트랜스코더

콘텐츠를 클라이언트에게 전달하기 전에 본문 포맷을 수정할 수 있다
- 트랜스코딩
  - e.g.
    - 크기를 줄이기 위해 GIF를 JPG로 변환
    - 텍스트 파일 압축
    - 문서를 외국어로 변환(유튜브 : 외국비디오 제목을 한글로 변환되어 표시 - 유튜브 코리아에서 변환)

익명화(Anonymizer) 프락시

신원을 식별할 수 있는 특성들을 제거함으로써 개인 정보 보호와 익명성 보장
- e.g., IP주소, From 헤더, Referer헤더, 쿠키, URI 세션 아이디, 사용자의 OS 종류
그러나 신원 정보를 제거하게 되면 사용자의 브라우징 경험의 질이 떨어지게 될 수 있고, 심지어 몇몇 웹 사이트는 적절히 동작하지 않을 수 있다

6.3 프락시는 어디에 있는가?

6.3에서 다룰 내용

어떻게 프락시가 네트워크에 배치되는가
어떻게 프락시의 연쇄가 계층을 이루는가
어떻게 트래픽이 올바르게 프락시를 찾아가는가

6.3.1 프락시 서버 배치

출구(Egress == Exit) 프락시

e.g.
- 회사 : 해커를 막는 방화벽
- 학교 : 부적절한 사이트 차단

접근(입구) 프락시

ISP는 사용자들의 다운속도 개선 및 인터넷 대역폭 비용을 줄이기 위해 캐시 프락시를 사용해 많이 찾는 문서들의 사본을 저장

대리 프락시(리버스 프락시)

네트워크의 가장 끝에 있는 웹 서버들의 바로 앞에 위치
웹서버로 향하는 모든 요청을 처리하고 필요할 때만 웹 서버에게 자원을 요청
웹 서버에 보안 기능을 추가
빠른 웹 서버 캐시를 느린 웹 서버의 앞에 놓음으로써 성능을 개선

네트워크 교환 프락시

캐시를 이용해 인터넷 교차로의 혼잡을 완화
트래픽 흐름을 감시
네트워크 사이의 인터넷 피어링 교환 지점들에 놓임
- 피어링(영어: Peering)은 인터넷 서비스 제공자끼리 서로 네트워크를 연결하고 트래픽을 교환하는 것을 의미한다.

6.3.2 프락시 계층

그림 6-12 : 정적 계층
프락시들은 프락시 계층이라고 불리는 연쇄를 구성할 수 있다.
부모와 자식 관계
- 서버쪽에 가까울 수록 부모(인바운드 프락시)
- 클라이언트에 가까울 수록 자식(아웃 바운드 프락시)

프락시 계층 콘텐츠 라우팅

프락시 계층은 동적으로 매 요청에 따라 바뀔 수 있다
동적 부모 선택의 몇 가지 예
- 부하 균형
  - 자식 프락시는 부하를 분산하기 위해 현재 부모들의 작업량 수준에 근거하여 부모 프락시를 고른다
- 지리적 인접성에 근거한 라우팅
  - 자식 프락시는 원 서버의 지역을 담당하는 부모를 선택할 수도 있다
- 프로토콜/타입 라우팅
  - 어떤 자식 프락시는 URI에 근거하여 다른 부모나 원 서버로 라우팅 할 수 있다
  - 어떤 특정 종류의 URI를 갖고 있는 요청의 경우, 특별한 프락시 서버로 보내져 특별한 프로토콜로 처리될 수도 있다
- 유료 서비스 가입자를 위한 라우팅
  - 웹 서비스 운영자가 빠른 서비스를 위해 추가금을 지불했다면, 그들의 URI는 대형 캐시나 성능 개선을 위한 압축 엔진으로 라우팅 될 수 있다

6.3.3 어떻게 프락시가 트래픽을 처리하는가

그림 6-14
클라이언트 트래픽이 프락시로 가도록 만드는 방법 네 가지

클라이언트를 수정한다(그림 6-14a)

만약 클라이언트가 프락시를 사용하도록 설정되어 있다면, 클라이언트는 HTTP 요청을 프락시로 보낸다

네트워크를 수정한다(그림 6-14b)

네트워크 인프라를 가로채서 웹 트래픽을 프락시로 가도록 조정하는 기법
이 가로챔(intercept)은 일반적으로 HTTP 트래픽을 지켜보고 가로채어 클라이언트 모르게 트래픽을 프락시로 보내는 스위칭 장치와 라우팅 장치를 필요로 한다 : 인터셉트 프락시

DNS 이름공간을 수정한다(그림 6-14c)

웹 서버 앞에 위치하는 대리프락시는 웹 서버의 이름과 IP주소를 자신이 직접 사용한다
DNS 이름 수정 방법들
- DNS 이름 테이블을 수동으로 편집
- 사용할 적절한 프락시나 서버를 계산해주는 특별한 동적 DNS 서버를 이용

웹 서버를 수정한다(그림 6-14d)

HTTP 리다이렉션 명령을 클라이언트에게 돌려줌으로써 클라이언트의 요청을 프락시로 리다이렉트 하도록 설정할 수 있음(20장)

6.4 클라이언트 프락시 설정

현대 브라우저는 프락시를 사용할 수 있도록 설정할 수 있음
브라우저는 프락시를 설정하는 여러가지 방법을 제공
- 수동 설정
  - 프락시를 설정하겠다고 명시적으로 설정
- 브라우저 기본 설정
  - 브라우저 배포자가 미리 프락시를 설정할 수 있음
- 프락시 자동 설정(Proxy auto-configuration, PAC)
  - .PAC 파일에서 자바스크립트로 된 코드를 읽어서 프락시를 지정할 수 있는 것 같다(20장)
  - PAC(자동 프록시 구성 스크립트)를 사용하여 성능 최적화
  - .pac 확장자, MIME타입 : 'application/x-ns-proxy-autoconfig'
- WPAD 프락시 발견
  - 대부분의 브라우저는 자동설정 파일을 다운받을 수 있는 '설정 서버'를 자동으로 찾아주는, 웹 프락시 자동발견 프로토콜(WPAD : Web Proxy Autodiscovery Protocol)을 제공
  - WPAD 프로토콜이 구현된 클라이언트가 하게 될 일
    - PAC URI를 찾기 위해 WPAD를 사용한다
    - 주어진 URI에서 PAC 파일을 가져온다
    - 프락시 서버를 알아내기 위해 PAC 파일을 실행한다
    - 알아낸 프락시 서버를 이용해서 요청을 처리한다

6.5 프락시 요청의 미묘한 특징들

프락시 요청의 URI는 서버 요청과 어떻게 다른가
인터셉트 프락시와 리버스 프락시는 어떻게 서버 호스트 정보를 알아내기 어렵게 만드는가
URI 수정에 대한 규칙
프락시는 브라우저의 똑똑한 URI 자동완성이나 호스트 명 확장 기능에 어떻게 영향을 주는가

6.5.1 프락시 URI는 서버 URI와 다르다

웹서버와 웹프락시 문법은 서로 같지만 한가지 예외가 있음
- 클라이언트가 프락시 대신 서버로 요청을 보내면 요청의 URI가 달라짐

// 클라이언트가 웹 서버로 요청을 보낼 때
GET /index.html HTTP/2.0
user-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/96.0.4664.45 Safari/537.36

// 클라이언트가 프락시로 요청을 보낼 때
GET https:www.ark-inflearn.shop/index.html HTTP/2.0
user-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/96.0.4664.45 Safari/537.36

프락시로 요청을 보낼 땐, 요청줄은 완전한 URI를 갖는다
원래 HTTP 설계에서 클라이언트는 서버와 직접 대화
- 가상호스팅, 프락시 대비 없었음
예전엔 URL스킴, 도메인 등을 보내지 않았다면 요즘엔 URI전체를 명시하는 것으로 바뀜

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

그림 6-15

'스킴/호스트/포트번호' 누락 문제는 가상으로 호스팅 되는 웹 서버가 직면한 것과 같은 문제다

가상으로 호스팅 되는 웹 서버는 여러 웹 사이트가 같은 물리적 웹 서버를 공유
요청 -> 부분 URI/index.html 로 오면, 가상으로 호스팅되는 웹 서버는 그 요청이 접근하고자 하는 웹 사이트의 호스트 명을 알 필요가 있다(5장의 docroot, 18장의 가상호스팅)
프락시에서 문제 해결 : 오나전한 URI를 갖도록 함
가상 호스팅 되는 웹 서버에서 문제 해결 : Host 헤더를 요구

6.5.3 인터셉트 프락시는 부분 URI를 받는다

클라이언트는 항상 프락시와 대화하고 있는 것을 알고 있는 것은 아니다
- 몇몇 프락시는 클라이언트에게 보이지 않을 수 있기 때문
인터셉트 프락시는 클라이언트에게서 서버로 가는 트래픽을 가로채기 때문에 웹 서버로 보내는 부분 URI를 받아도 원서버로 전달이 가능하다(그림 6-15d)

6.5.4 프락시는 프락시 요청과 서버 요청을 모두 다룰 수 있다

트래픽이 프락시 서버로 리다이렉트 될 수 있는 여러 방법이 존재하기 때문에, 다목적 프락시 서버는 요청 메세지의 완전한 URI와 부분 RUI를 모두 지원해야 한다
완전한 URI가 주어졌다면, 프락시는 그것을 사용해야 한다
부분 URI가 주어졌고, Host 헤더가 있다면, Host 헤더를 이용해 원 서버의 이름과 포트 번호를 알아내야 한다
부분 URI가 주어졌으나 Host 헤더가 없다면, 다음의 방법으로 원 서버를 알아내야 한다
- 프락시가 원 서버를 대신하는 대리 프락시라면, 프락시에 실제 서버의 주소와 포트번호가 설정되어 있을 수 있다
- 이전에 어떤 인터셉트 프락시가 가로챘던 트래픽을 받았고, 그 인터셉트 프락시가 원 IP 주소와 포트번호를 사용할 수 있도록 해두었다면, 그 IP 주소와 포트번호를 사용할 수 있다(20장)
- 모두 실패했다면, 프락시는 원 서버를 알아낼 수 있는 충분한 정보를 갖고 있지 못 한 것이므로 반드시 에러 메세지(보통 사용자에게 Host 헤더를 지원하는 현대적인 웹브라우저로 업그레이드 하라는 것)를 반환해야 한다

6.5.5 전송 중 URI 변경

일반적으로 프락시 서버는 가능한 한 관대하도록 애써야 한다
특히 HTTP명세는 일반적인 인터셉트 프락시가 URI를 전달할 때 절대 경로를 고쳐 쓰는 것을 금지한다. 유일한 예외는 빈 경로를 '/'로 교체하는 것뿐이다

6.5.6 URI 클라이언트 자동확장과 호스트 명 분석(Hostname Resolution)

브라우저는 프락시의 존재 여부에 따라 요청 URI를 다르게 분석한다
- 프락시가 없다 -> 사용자가 타이핑한 URI를 가지고 그에 대응하는 IP 주소를 찾는다
- 호스트명 발견 -> 그에 대응하는 IP주소들을 연결에 성공할 때 까지 시도
- 호스트명 발견X -> 호스트명의 짧은 약어를 타이핑한 것을 보고 자동화된 호스트명의 확장을 제공
  - yahoo -> www.yahoo.com
  - 몇몇 브라우저는 해석할 수 없는 URI를 서드파티 사이트로 넘기는데, 이 사이트는 오타 교정을 시도하고 사용자가 의도했을 URI를 제시(크롬 -> 구글)
- 대부분 시스템에서 DNS는 사용자가 호스트 명의 앞 부분만 입력하면 자동으로 도메인을 검색하도록 설정
  - oreilly.com host7을 입력하면 그 도메인의 DNS는 자동으로 host7.oreilly.com를 찾아본다

6.5.7 프락시 없는 URI 분석(URI Resolution)

그림 6-16 브라우저는 명시적인 프락시가 존재하지 않는 경우 부분 호스트 명을 자동으로 확장한다
사용자는 'oreilly'를 브라우저의 URI창에 입력
브라우저는 'oreilly'를 호스트 명으로 사용하고 기본 스킴을 'http://'로 기본 포트를 '80'으로, 기본 경로를 '/'로 간주 -> 실패
브라우저는 호스트 명을 자동으로 확장한 후 DNS에 'www.oreilly.com'의 주소 분해(resolve)를 요청 -> 성공

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

만약 명시적 프락시를 사용한다면, 브라우저는 URI 확장을 수행할 수 없음
이러한 이유로, 몇몇 프락시는 www...com 자동확장이나 지역 도메인 접미사 추가 같은 흉내내려고 시도한다
- 그러나 프락시들은 광범위하게 공유되고 있기 때문에 개개인들 각각에 알맞은 도메인 접미사를 알아내는 것은 불가능할 것이다

6.5.9 인터셉트 프락시를 이용한 URI 분석

6.6 메시지 추적

그림 6-19 접근 프락시와 CDN 프락시는 두 단계의 프락시 계층을 만든다

프락시가 흔해지면서 서로 다른 스위치와 라우터를 넘나드는 IP 패킷의 흐름을 추적하는 것 못지않게 프락시를 넘나드는 메시지의 흐름을 추적하고 문제점을 찾아내는 것도 필요한 일이 되었다

6.6.1 Via 헤더

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

Via: 1.1 proxy-62.irenes-isp.net, 1.0 cache.joes-hardware.com

첫 번째 프락시 : HTTP/1.1프로토콜, proxy-62.irenes-isp.net 이라 불림
두 번째 프락시 : HTTP/1.0을 구현, cache.joes-hardware.com으로 불림

Via 문법

프로토콜 이름
프로토콜 버전
노드 이름
노드 코멘트
자세한 설명은 생략 : 책 참고

Via 요청과 응답 경로

요청과 응답은 보통 같은 TCP 커넥션을 오가므로, 응답 메세지는 요청과 같은 경로를 되돌아간다
만약 요청 메시지가 A, B, C,를 지나간다면, 그에 대한 응답 메시지는 C, B, A를 지나간다
즉, 응답의 Via헤더는 요청 Via헤더와 반대이다

Via와 게이트웨이

몇몇 프락시는 서버에게 비 HTTP 프로토콜을 사용할 수 있는 게이트웨이 기능을 제공한다
Via 헤더는 이러한 프로토콜 변환을 기록하므로 HTTP 애플리케이션은 프락시 연쇄에서 프로토콜 능력과 변환이 있었는지를 알아 챌 수 있다

Sever헤더와 Via 헤더

Server: Apache/1.3.14 (Unix) PHP/4.0.4
Server: Netscape-Enterprise/4.1
Server: Microsoft-IIS/5.0

Server 응답 헤더는 원 서버에 의해 사용되는 소프트웨어를 알려준다
응답 메세지가 프락시를 통과할 때 프락시는 Server 헤더를 수정해서는 안된다
Server헤더는 원서버를 위해 존재한다
대신 프락시는 Via 항목을 추가해야 한다

Via가 개인정보 보호와 보안에 미치는 영향

Via문자열 안에 정확한 호스트 명이 들어가기를 원하지 않는 경우
- 호스트 명을 그 호스트에 대한 적당한 가명으로 교체
- 프락시는 정렬된 일련의 Via 경유지 항목들을 하나로 합칠 수 있다
  - 합치기 전 : Via: 1.0 foo, 1.1 devirus.company.com, 1.1 access-longger.company.com
  - 합친 후 : Via: 1.0 foo, 1.1 concealed-stuff
  - 여러 경유지들이 모두 같은 조직의 통제하에 있고 호스트가 이미 가명으로 교체되지 않은 이상 그들에 대한 항목들을 합쳐서는 안 된다
  - 수신된 프로토콜 값이 서로 다른 항목들도 합쳐서는 안된다

6.6.2 TRACE 메서드

프락시 서버는 메세지가 전달될 때 메세지를 바꿀 수 있다
- 헤더 추가 or 변경 or 삭제
HTTP/1.1의 TRACE 메서드는 요청 메세지를 프락시의 연쇄를 따라가면서 어떤 프락시를 지나가고 어떻게 각 프락시가 요청 메세지를 수정하는지 관찰/추적할 수 있도록 해준다
- TRACE는 프락시 흐름을 디버깅하는데 매우 유용하다
- 그러나 대부분 막혀있다

Max-Forwards

일반적으로 TREACE 메시지는 중간에 프락시들이 몇 개나 있든 신경쓰지 않고 목적지 서버로의 모든 경로를 여행한다
TRACE나 OPTIONS 요청의 프락시 홉(hop) 개수를 제한하기 위해 Max-Forwards 헤더를 사용할 수 있다
- 무한루프에 빠지지 않는지, 프락시 연쇄를 테스트하거나, 중건ㅇ의 특정 프락시 서버들의 효과를 체크할 때 유용하다

6.7 프락시 인증

프락시는 접근 제어 장치로서 제공될 수 있음
HTTP는 사용자가 유효한 접근 권한자격을 프락시에 제출하지 않는 한 콘텐츠에 대한 요청을 차단하는 프락시 인증이라는 메커니즘을 정의
제한된 콘텐츠에 대한 쵸엉 -> 자격 요구 : 407 Proxy Authorization Required 상태코드
- 클라이언트는 요구되는 자격을 Proxy-Authorization 헤더 필드에 담아서 요청을 다시 보내고
- 유효하면 통과, 유효하지 않다면 다시 407 응답
HTTP인증 메커니즘 : 12장

6.8 프락시 상호 운용성

6.8.1 지원하지 않는 헤더와 메서드 다루기

프락시 서버는 넘어오는 헤더 필드들을 모두 이해하지 못할 수도 있다.
프락시는 이해할 수 없는 헤더필드는 반드시 그대로 전달해야 하며, 같은 이름의 헤더 필드가 여러개 있는 경우에는 그들의 상대적인 순서도 반드시 유지해야 한다.

6.8.2 OPTIONS: 어떤 기능을 지원하는지 알아보기

HTTPS OPTIONS 메서드는 서버나 웹 서버의 특정 리소스가 어떤 기능을 지원하는지 클라이언트가 알아볼 수 있게 해준다
만약 OPTIONS 요청의 URI가 다음과 같이 별표(*)라면, 요청은 서버 전체의 능력에 대해 묻는 것이 된다

// 요청
OPTIONS * HTTP/1.1

// 응답
HTTP/1.1 200 OK
Allow: GET, PUT, POST, HEAD, TRACE, OPTIONS

성공한다면, OPTIONS 메서드는 서버에서 지원하거나 지정한 리소스에 대해 가능한 선택적인 기능들을 헤더 필드를 포함한 200 OK 응답을 반환한다
- Allow 헤더를 통해 서버가 지원하는 메서드를 열거한다.

참고

HTTP 완벽가이드
https://velog.io/@code_newb/%ED%94%84%EB%9D%BD%EC%8B%9C
https://www.slideshare.net/HyeonSeokChoi/http-6
피어링

Author And Source

이 문제에 관하여(6장. 프락시), 우리는 이곳에서 더 많은 자료를 발견하고 링크를 클릭하여 보았다 https://velog.io/@gth1123/6장.-프락시

우수한 개발자 콘텐츠 발견에 전념 (Collection and Share based on the CC Protocol.)

6장. 프락시

6장. 프락시

이 장에서는 ...

이 장에서 다룰 내용

6.1 웹 중개자

6.1.1 개인 프락시와 공유 프락시

공용 프락시

개인프락시

6.1.2 프락시 vs. 게이트웨이

6.2 왜 프락시를 사용하는가?

어린이 필터

문서 접근 제어자

보안 방화벽

웹 캐시

대리 프락시

콘텐츠 라우터

트랜스코더

익명화(Anonymizer) 프락시

6.3 프락시는 어디에 있는가?

6.3에서 다룰 내용

6.3.1 프락시 서버 배치

출구(Egress == Exit) 프락시

접근(입구) 프락시

대리 프락시(리버스 프락시)

네트워크 교환 프락시

6.3.2 프락시 계층

프락시 계층 콘텐츠 라우팅

6.3.3 어떻게 프락시가 트래픽을 처리하는가

클라이언트를 수정한다(그림 6-14a)

네트워크를 수정한다(그림 6-14b)

DNS 이름공간을 수정한다(그림 6-14c)

웹 서버를 수정한다(그림 6-14d)

6.4 클라이언트 프락시 설정

6.5 프락시 요청의 미묘한 특징들

6.5.1 프락시 URI는 서버 URI와 다르다

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

6.5.5 전송 중 URI 변경

6.5.6 URI 클라이언트 자동확장과 호스트 명 분석(Hostname Resolution)

6.5.7 프락시 없는 URI 분석(URI Resolution)

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

6.5.9 인터셉트 프락시를 이용한 URI 분석

6.6 메시지 추적

6.6.1 Via 헤더

Via 문법

Via 요청과 응답 경로

Via와 게이트웨이

Sever헤더와 Via 헤더

Via가 개인정보 보호와 보안에 미치는 영향

6.6.2 TRACE 메서드

Max-Forwards

6.7 프락시 인증

6.8 프락시 상호 운용성

6.8.1 지원하지 않는 헤더와 메서드 다루기

6.8.2 OPTIONS: 어떤 기능을 지원하는지 알아보기

참고

Author And Source

좋은 웹페이지 즐겨찾기