Skip to content

Latest commit

 

History

History
200 lines (154 loc) · 12 KB

06.proxies-qna.md

File metadata and controls

200 lines (154 loc) · 12 KB
Raw

질문과 답변

Q. 프락시는 다음 부모 프락시들의 부하 수준을 어떻게 알 수 있나

A1

  • L4
    • TCP/UDP port 기반 라우팅
    • NAT 처럼 동작하며 content 를 확인할 수 없음
  • L7
    • Application level
    • 최상단 레이어 기반으로 동작하기 때문에 다양한 정책의 load balancing 가능
  • load balancing algorithm
    • Round Robin
      • rotating lit 에 기반해 forwarding
      • 서버의 부하 상태 체크하지 않음
    • Least Connection Method
      • active connection 이 가장 적은 서버로 forwarding
    • Least Response Time Method
      • 응답 지연이 가장 적은 서버로 forwarding
    • Least Bandwidth Method
      • 현재 traffic 이 가장 적은 서버로 forwarding
    • Hashing Methods
      • incoming packet data 의 hash 에 기반한 forwarding

A2

  • L2, L3, L4, L7은 OSI 7계층 중 스위칭이 일어나고 있는 계층에 따라 결정된다.
  • L3 이하의 스위치에서는 Mac 주소(L2), IP 주소(L3) 계층에서 동작하기 때문에, 실질적으로는 로드 밸런싱을 하기 어렵다.
  • L4에서는 TCP/IP 프로토콜을 기반으로, IP 주소 + 포트 번호 기반 스위칭을 지원한다.
    • 라운드 로빈 방식: 오는 대로 순차적으로 세션을 맺어준다.
    • 최소 커넥션: 가장 적은 오픈 세션을 가진 서버로 맺어준다.
    • 응답 시간: 서버와 직접 통신해보면서 응답 시간이 빠른 쪽으로 많은 세션을 할당해준다.
    • 해시: 특정 클라이언트는 특정 서버로만 할당시킨다. (cf. minimum missis: 서버 다운시 해시 재할당이 이루어진다.)
    • 대역폭: 서버들과의 대역폭을 고려해서 분산한다.
  • L7 HTTP 애플리케이션 계층에서 동작하므로 애플리케이션 수준에서 IP 주소 + 포트 번호 + 패킷 내용 기반 스위칭이 가능하다.
    • 쿠키: 쿠키 정보를 분석하여 지속 커넥션을 유지한다.
    • 컨텍스트 스위칭: 클라이언트가 요청한 리소스에 대해 컨텍스트를 전환할 수 있다. (예: 이미지 리소스 요청에 대해 이미지 서버로 옮겨준다.)
    • 콘텐츠 재작성: 전달받은 요청을 변환해서 재전송한다.

A3

  • 자식 프락시는 부하를 분산하기 위해 현재 부모들의 작업량 수준에 근거하여 부모 프락시를 고른다.
  • 작업량 수준은 여러가지가 있다
    • transaction이 fail한 횟수를 카운트, 그 횟수가 많으면 해당 proxy를 특정 시간동안 unavailable로 두고 다른 proxy에 요청을 전달함.
    • 특정 시간마다(5초) ping을 보내, communication error, timeout을 체크.
  • recover된 서버에게는 slow start를 적용.

ref

Q. 현대 브라우저 환경에서 via 헤더를 사용해 어떤 일들을 할까

A1

  • X-Forwarded-For 헤더와의 차이
    • XFF 헤더는 original source IP 를 얻기 위한 목적
    • Via 헤더는 프록시를 통한 통신 과정에서 프로토콜의 변화, 프록시의 hostname 등 더 세부적인 정보들을 가지고 디버깅이 주된 목적
  • 디버깅이나 문제가 있는 프록시를 찾기 위한 목적인 만큼 Via 헤더에 대해서는 브라우저의 역할이 크지는 않을 것으로 생각됨

A2

  • via는 메시지가 지나는 각 중간 노드의 정보를 나열.
  • 중간 노드를 지날 때 마다, via 목록의 끝에 추가됨.
  • Q - via가 있다는 걸 어떻게 알아서 추가할까?
  • via header는 request, response에 모두 추가됨.
    • forward, reverse proxy들에 의해 추가.
  • 메시지 포워딩 추적, request loop 막기, sender의 protocol capability를 알기 위해 사용됨.
  • via 헤더가 없으면, proxy에게 origin server가 gzip compressed 된 데이터를 넘기지 않을 수 있음.
  • proxy가 처리를 못할 거라고 생각하기 때문.
  • via 헤더에 identify를 해주어야.

A3

  • 1) 일반적으로 메시지가 어떤 중개자를 거쳐왔는지를 표시함
  • 2) 요청 루프에 빠지는 것을 방지함
  • 3) 요청/응답 체인을 통해 사용할 수 있는 프로토콜을 확인함 ex. 특정 프록시를 거쳐 갔을 때 프로토콜 버전이 다운그레이드 된 것을 확인함

ref

Q. DHCP, SLP, DNS SRC 레코드, DNS TXT 레코드 안의 서비스 URI 에 대해

A1

DHCP

  • IP 주소와 TCP/IP 설정을 클라이언트에 제공해주는 프로토콜

  • 동적으로 생성된 IP 주소를 임대하고 사용 후 반납하는 구조

  • DHCP 서버

    • 일정한 범위의 IP 주소를 생성하여 클라이언트에 할당
    • 할당된 IP 주소들을 관리

  • DHCP 클라이언트

    • DHCP 로부터 할당받은 IP 주소와 TCP/IP 설정들을 사용해 다른 호스트와 통신

      SLP

  • 복잡한 static configuration 없이 네트워크 서비스를 찾는 프로토콜

  • SLP 역할

    • 클라이언트 어플리케이션의 network service location informaton 요청에 응답
    • 서비스 통지
    • 유저와 서비스를 그룹으로 구성
    • 서버 장애 관리 및 복구

  • Drictory Agent

    • Optional agent
    • SA 로부터 오는 서비스 통지를 캐싱하여 저장/관리하는 역할
    • UA 의 서비스 요청을 처리
    • SA와 UA 가 자신을 찾을 수 있도록 주기적으로 통지를 함

  • Service Agent

    • 네트워크 서비스의 서비스 통지를 유지
    • DA 가 없으면 UA 의 요청에 대해 multicast 로 응답
    • DA 가 있으면 서비스를 지원하는 scope 의 DA 에 등록/해제

  • User Agent

    • user application 을 대신해 scope 식별, DA 및 service 알림을 조회

  • Scope

    • 관리, 토폴로지 또는 다른 조직 방식으로 배열 된 UA 및 SA의 그룹

  • Service Advertisement

    • 서비스 정보에 대해 기술하는 attribute/value 쌍으로 이루어진 리스트 URL

    • 유효시간이 정해져 있음

      DNS SRV 레코드

  • 특정 서비스에 대한 hostname과 port 번호 정보

  • 동일 hostname 에 있는 여러 서비스를 SRV 레코드에 기록해놓고 찾는 식으로 사용할 수 있음

    SRV Record field

DNS record type 종류

A2

  • WPAD(Web Proxy Autodiscovery Protocol) 명세가 정의하는 것들.
  • WPAD?
    • DHCP 혹은 DNS discovery를 이용, 사용자가 설정 파일의 URL 위치를 알 수 있도록 하는 방법 중 하나.
    • client가 자동으로 캐시 서비스를 설정해, 더 빠르게 컨텐츠를 전달받을 수 있게 함.
    • 브라우저는 자동으로 설정파일을 다운로드 받아, 특정 URL 혹은 호스트에 대한 proxy 설정을 하게 됨.
    • 실제 설정 파일 포멧은 PAC(Proxy Auto config format)이 사용됨. - https://mudfish.net/docs/ko/vpn/features/wpad/pac.html
  • findProxyForURL을 이용, 어떤 proxy를 설정할 것인지를 정할 수 있다.(이건 수동설정인가?..)

DHCP(Dynamic Host Configuration Protocol)

  • dhcp server가 각 디바이스에 동적으로 ip 주소를 할당, 해당 ip 주소로 다른 네트워크와 통신할 수 있게 하는 네트워크 관리 프로토콜.
  • 각 컴퓨터에 대해 자동으로 ISP를 통해 ip를 할당하게 함.
  • client는 DHCPINFORM query를 날리고, DHCP 서버는 PAC 파일의 정보가 담긴 세팅을 리턴. client는 PAC파일을 다운로드.

SLP(service location procol)

  • DHCP가 실패하면 SLP를 사용.
  • LAN에서 서비스를 찾을 수 있게 하는 프로토콜.
  • 각 서비스는 URL이 있음.
    • 서비스 중, Directory Agent(DA)가 서비스 정보를 캐싱하는 데 사용됨.

DNS records

  • 위 두가지가 실패하면 여기로 넘어옴.
  • DNS SRV record(DNS service record) - DNS에서 위치를 정의하는 명세.
    • _service._proto.name. TTL class SRV priority weight port target.
  • wpad.dat 이란 파일 이름으로 있어야 함. - [wpad.blabla.com/wpad.dat](http://wpad.blabla.com/wpad.dat) 으로 요청할 것.

A3

현재의 WPAD 명세는 다음과 같은 기법을 순서대로 정의한다.

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

20.5.3장에 WPAD 프로토콜에 대한 자세한 설명이 있다.

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

  • 웹브라우저가 근처의 프락시를 찾아내어 사용할 수 있게 해주는 방법
  • HTTP 클라이언트가 PAC 파일의 위치를 알아내고 그 파일을 이용해서 적절한 프락시 서버의 이름을 알아낼 수 있게 해줌
  • 최종 사용자가 수동으로 프락시 설정을 할 필요 없음
  • 투명 트래픽 인터셉트에 의존할 필요 없음

WPAD 클라이언트

1) DHCP를 먼저 시도한다. DHCP 서버가 PAC 파일이 있는 CURL(설정 URL)을 가지고 있어야 한다.

2) 실패하면 SLP(서비스 위치 프로토콜)를 시도한다.

3) 실패하면 DNS 기반 매커니즘으로 옮겨간다. 잘 알려진 호스트 명부터 SRV 레코드, 서비스 URI까지 구체적인 정보부터 알아내려고 시도하다가 실패하면 덜 구체적인 정보라도 취하려고 한다.

ref