From 06dfe057407a96b67666a521cf2e720350f64688 Mon Sep 17 00:00:00 2001 From: Olaf Date: Sun, 16 Feb 2020 23:34:00 +0900 Subject: [PATCH] =?UTF-8?q?[bookCrush/httpPerfectGuide]=20chapter20=5F=20?= =?UTF-8?q?=EA=B3=A0=EC=84=9D=EC=A7=84?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- .../\352\263\240\354\204\235\354\247\204.md" | 201 ++++++++++++++++++ 1 file changed, 201 insertions(+) create mode 100644 "chapter_20/\352\263\240\354\204\235\354\247\204.md" diff --git "a/chapter_20/\352\263\240\354\204\235\354\247\204.md" "b/chapter_20/\352\263\240\354\204\235\354\247\204.md" new file mode 100644 index 0000000..cadbb8e --- /dev/null +++ "b/chapter_20/\352\263\240\354\204\235\354\247\204.md" @@ -0,0 +1,201 @@ +# HTTP + +## 20.4 일반적인 리다이렉션 방법 + +### 20.4.1 HTTP 리다이렉션 + +몇몇 웹 사이트는 HTTP 리다이렉션을 이용해 간단하게 부하를 분산한다. +요청을 처리하는 서버는 가용한 것들 중 부하가 가장 ㅈ거은 콘텐츠 서버를 찾아서 브라우저의 요청을 그 서버로 리다이렉트한다. + +- 어떤 서버로 리다이렉트할지 결정하려면 원 서버는 상당히 많은 처리를 해야한다. +- 페이지에 접근할 때마다 두 번의 왕복이 필요하여, 사용자가 더 오래 기다리게된다. +- 리다이렉트 서버가 고장나면, 사이트도 고장난다. + +### 20.4.2 DNS 리다이렉션 + +DNS 는 하나의 도메인에 여러 아이피 주소가 결부되는 것을 허용하며, DNS 분석자가 어떤 아이피 주소를 반환할 것인가를 결정하는 방법은 단순한 라운드로빈부터 복잡한 여러 +서버의 로드를 검사해서 로드가 가장 적은 서버의 아이피 주소를 반환하는 것까지 다양하다. + +- DNS 라운드로빈: DNS 라운드 로빈은 웹 서버 팜 전체에 대한 부하의 균형을 유지하기 위해 DNS 호스트명 분석 기능을 사용한다. 순수한 부하 균형 전략이며, +서버에 대한 클라이언트의 상대적인 위치나 서버의 현재 스트레스를 고려하지 않는다. + +- 다중 주소와 라운드 로빈 주소 순환: 부하 균형을 위해, 대부분의 DNS 서버는 룩업이 끝났을 때마다 주소를 순환시킨다. +이 주소 순환을 DNS 라운드 로빈이라 부르기도한다. + +- 부하 균현을 위한 DNS 라운드 로빈: DNS 순환은 서버들 간의 부하 균형을 유지해준다. 만약 DNS 가 주소를 순환시키지 않는다면, 대부분의 클라이언트가 +목록의 첫 번쨰 서버를 선택할 것이고, 그 서버가 대부분의 부하를 받게 될것이다. + +- DNS 캐싱의 효과: DNS 룩업의 결과는 애플리케이션, 운영체제, 몇몇 기초적인 자식 DNS 서버에 의해 기억되어 재사용될 수 있다. 호스트 하나에 대해 +한 번의 DNS 룩업을 수행한 뒤, 그 주소를 몇번이고 다시 사용한다. + +- 부하 균형 알고리즘: 웹 서버의 로드를 추적하고 가장 로드가 적은 웹 서버를 목록의 가장 위에 놓는다. +- 근접 라우팅 알고리즘: DNS 서버는 사용자를 근처의 웹 서버로 보내는 시도를 할 수 있다. +- 결함 마스킹 알고리즘: DNS 서버는 네트워크의 건강 상태를 모니터링하고 요청을 정전이나 기타 장애를 피해서 라우팅 할 수 있다. + +### 20.4.3 임의 캐스트 어드레싱 + +임의 캐스트 어드레싱에서, 여러 지리적으로 흩어진 웹 서버들은 정확히 같은 아이피 주소를 갖고 클라이언트의 요청을 클라이언트에서 가장 +가까운 서버로 보내주기 위해 백본 라우터의 최단거리 라우팅 능려에 의지한다. +이 방법이 동작하는 방식 중 하나는 각 웹 서버에게 자신의 인접한 백본 라우터를 향하는 라우터라고 광고하는 것이다. + +분산 임의 캐스트의 동작을 위해, 서버는 반드시 라우터의 언어로 말해야 하고 라우터는 일어날 수 있는 주소 충돌을 반드시 +다룰 수 있어야 한다. + +### 20.4.4 아이피 맥 포워딩 + +MAC 포워딩을 지원하는 레이어-4 스위치는 보통 요청을 여러 프락시 캐시로 보낼 수 있고 그들 사이의 부하 균형을 유지할 수 있다. +비슷하게 HTTP 트래픽은 대체 HTTP 서버로도 전달될 수 있다. +MAC 주소 포워딩은 점 대 점으로만 가능하기 때문에, 서버나 프락시는 스위치와 한 홉 거리에 위치해야 한다. + +### 20.4.5 아이피 주소 포워딩 + +아이피 주소 포워딩에서, 스위치나 다른 레이어 4를 이해하는 장비는 들어오는 패킷에 대해 TCP/IP 어드레싱을 검증하고 패킷을 +목적지 맥 주소가 아니라 목적지 아이피 주소의 변경에 따라 라우팅한다. + +맥 포워딩보다 좋은 점 하나는 목적지 서버가 한홉 거리에 있을 필요가 없다는 것이다. +라우팅 대칭성이라는 문제가 있다. 클라이언트로부터 들어오는 TCP 커넥션을 ㅂ다아주는 스위치는 커넥션을 관리하고 있다. +스위치는 반드시 그 커넥션을 통해 클라이언트에게 응답을 돌려주어야 한다. + +### 20.4.6 네트워크 구성요소 제어 프로토콜 + +네트워크 구성요소 제어 프로토콜은 아이피 패킷을 전달하는 라우터나 스위치 같은 네트워크 구성요소들이 웹 서버나 프락시 +캐시와 같이 애플리케이션 계층 요청을 처리하는 서버 구성요소들과 대화할 수 있게 해준다. +NECP 는 예외에 대한 개념을 지원한다. SE는 특정 출발지 아이피 주소가 서비스 할 수 없다고 판단할 수 있으며, +그러한 경우 그 주소들을 NE로 보낼 수 있다. 그러면 NE는 그 아이피 주소로부터의 요청을 원 서버로 전달할 수 있다. + +## 20.5 프락시 리다이렉션 방법 +### 20.5.1 명시적 브라우저 설정 + +사용자들이 직접 브라우저의 설정을 변경해서 프락시를 사용하도록 하는 대신, 미리 설정이 다 +되어 있는 브라우저를 다운 받도록 한다. 이렇게 다운 받은 브라우저들은 접촉할 프락시의 주소를 알고있다. + +- 프락시들을 사용하도록 설정된 브라우저들은 프락시가 응답하지 않더라도 원 서버와 접촉하지 않는다 +- 네트워크 아키텍처를 변경했을 때 변경사항을 모든 최종사용자에게 전파하는 것이 어렵다. + +### 20.5.2 프락시 자동 설정 + +특정 프락시에 접촉하기 위한 브라우저의 명시적인 설정은 네트워크 아키텍처의 변화를 제한하는데, +브라우저에 개입하여 설정을 변경하는 주체가 사용자이기 때문이다.올바른 프락시 서버에 접촉하기 위해 브라우저가 동적으로 자신을 설정할 수 있게 하는 자동 설정 +방법은 이 문제를 해결한다. +이 방법은 실제로 존재하며 프락시 자동설정 프로토콜이라고 불린다. PAC + +PAC 프로토콜은 상당히 강력하다. 자바스크립트 프로그램은 브라우저에게 DNS 주소나 서브넷, 심지어 요일이나 시각과 같은 +호스트 명과 관련된 여러 매개변수에 근거하여 프락시를 선택하도록 요구할 수 있다. + +### 20.5.3 웹 프락시 자동발견 프로토콜 +웹 프락시 자동발견 프로토콜은 최종 사용자가 수동으로 프락시 설정을 할 필요도, 투명한 트래픽 인터셉트에 의존할 필요도 없이 웹 브라우저가 근처의 프락시를 +찾아내어 사용할 수 있게 해주는 방법을 제공하는 것을 목적으로 하고 있다. +웹 프락시 자동발견을 위해 프로토콜을 정하는 일반적인 문제는 선택할 수 있는 발견 프로토콜이 여러 가지 존재하다는것과 +프락시 사용에 대한 설정이 브라우저들마다 차이가 있다는 것 때문에 복잡해진다. + +- PAC 파일 자동발견: WPAD 는 HTTP 클라이언트가 PAC 파일의 위치를 알아내고 파일을 이용해서 적절한 +프락시 서버의 이름을 알아낼 수 있게 해준다. WPAD는 직접적으로 프락시 서버의 이름을 알아내지는 않는데, 그렇게 하면 PAC 파일에 +의해 제공되는 추가적인 기능들이 활용될 수 없기 때문이다. + +- WPAD 알고리즘: WPAD 는 적절한 PAC 파일 CURL 을 결정하기 위해 여러 가지 리소스 발견 기법들을 사용한다. + - DHCP 동적 호스트 설정 프로토콜 + - SLP 서비스 위치 프로토콜 + - DNS 에게 잘 알려진 호스트 명 + - DNS 의 SRV 레코드 + - TXT 레코드의 DNS 서비스 URL 들 + +- DHCP 를 이용한 CURL 발견: WPAD 클라이언트가 질의하는 DHCP 서버는 반드시 CURL 을 저장하고 있어야한다. WPAD 클라이언트는 DHCP 질의를 DHCP 서버에 보냄으로써CURL 을 얻는다. +CURL은 DHCP 옵션코드 252에 들어있다. WPAD 클라이언트가 자신의 초기화 과정에서 이미 DHCP 질의를 했다면, DHCP 서버는 이미 그 값을 제공했을 수도 있다.클라이언트가 +OS의 API를 통해 그 값을 얻을 수 없다면, DHCPINFORM 메시지를 DHCP 서버에게 보내 질의하여 그 값을 얻는다. + +- DNS A 레코드 룩업: 알맞은 프락시 서버의 IP 주소들이 WPAD 클라이언트들이 질의할 수 있는 DNS 서버에 반드시 저장되어 있어야한다. +WPAD 클라이언트는 A 레코드 룩업을 DNS 서버로 보내 CURL 을 얻는다. 룩업이 성공하면 적절한 프락시 서버의 IP 주소를 얻는다. + +- PAC 파일 가져오기: CURL 이 생성되면, WPAD 클라이언트는 보통 CURL 로 GET 요청을 만든다. 이때 자신이 다룰 수 잇는 적절한 CFILE 포맷 정보가 담긴 +Accept 헤더를 포함해야한다. CURL 결과가 리다이렉트라면, 리다이렉트가 향하는 곳이 클라이언트의 최종 목적지다 + +- 언제 WPAD 를 실행하는가 + - 웹 클라이언트가 시작될 때 + - 클라이언트 호스트의 아이피 주소가 변경됭 네트워킹 스택으로부터 업급이 있을 때마다 + +## 20.6 캐시 리다이렉션 방법 +### 20.6.1 WCCP 리다이렉션 + +시스코 시스템즈는 웹 라우터들이 웹 트래픽을 프락시 캐시로 리다이렉트 할 수 있도록 하기 위해 캐시 조직 프로토콜을 개발했다. WCCP 는 라우터들과 +캐시들 사이의 대화를 관리하여 라우터가 캐시를 검사하고 특정 종류의 트래픽을 특정 캐시로 보낼 수 있게 해준다. + +- WCCP 리다이렉션 동작 + - 네트워크가 필요하다. 네트워크에는 WCCP 를 사용할 수 있는 라우터와 다른 캐시와 의사소통 할 수 있는 캐시가 포함되어야 한다. + - 라우터들의 집합과 대상이 되는 캐시들이 WCCP 서비스 그룹을 구성한다. + - HTTP 트래픽을 리다이렉션하도록 설정되어 있다면, 서비스 그룹의 라우터는 HTTP 요청을 서비스 그룹의 캐시로 보낸다. + - HTTP 요청이 서비스 그룹의 라우터에 도착했을 때 라우터는 그 요청을 처리 하기 위해 서비스 그룹의 캐시중 하나를 선택한다. + - 라우터는 요청 패킷을, 캐시의 아이피 주소와 함께 캡슐화 하거나 아이피 맥 포워딩을 하여 캐시로 보낸다. + - 캐시가 요청을 처리할 수 없다면, 패킷은 평범하게 포워딩되기 위해 라우터로 돌아온다. + - 서비스 그룹의 구성원들은 지속적으로 다른 구성원들의 가용성을 확인하기 위해 하트비트 메시지를 교환한다. + + - WCCP 부하균형: WCCP 라우터는 라우팅뿐만 아니라 여러 수신 서버 간의 부하 균형을 유지할 수 있다. WCCP 라우터와 그들의 수신 서버들은 그들이 살아 있고 + 동작중임을 다른 장비들이 알 수 있도록 하트비트 메시지를 서로 교환한다. 하트비트 메시지를 보내지 않게 되었다면, WCCP 라우터는 트래픽 요청을 + 그 노드로 리다이렉트하는 대신 인터넷으로 바로 보낸다. 노드가 다시 정상화되면, WCCP 라우터는 다시 하트비트 메시지를 받고 노드로 요청 트래픽을 보내기 시작한다 + + ## 20.7 인터넷 캐시 프로토콜 + + 인터넷 캐시 프로토콜은 캐시들이 형제 캐시에서 일어난 캐시 적중을 찾아볼 수 있도록 해준다. 캐시가 HTTP 메시지에서 요청한 콘텐츠를 갖고 있지 않다면 + 캐시는 근처의 형제 캐시중 그 콘텐츠를 갖고 있는 것이 있는지 찾아보고 만약 있다면 원 서버에 질의하는 것보다 + 비용이 더 들지 않을 것을 기대하며 캐시에서 콘텐츠를 가져온다. + + - OP 코드: ICP 메시지의 의미를 서술하는 8 비트 값이다 + - 버전: ICP 프로토콜의 버전 번호를 서술한다 + - 메시지 길이: ICP 메시지의 총 길이를 바이트 단위로 나타낸것 + - 요청번호: 캐시는 동시에 여러 요청과 응답을 추적하기 위해 요청 번호를 사용한다 + - 옵션: 32비트 ICP 옵션 필드는 ICP의 동작을 변경하는 플래그를 담고 있는 비트 벡터이다. + - 옵션 데이터: 32 비트 옵션 데이터는 옵션 기능을 위해 예약되어 있다. 형제로부터 원 서버까지의 왕복 시간 측정값을 담아 놓는데 쓰인다 + - 발송자 호스트 주소: 메시지 발송자의 32 비트 아이피 주소를 담고 있는 필드 + - 페이로드: 페이로드의 콘텐츠는 메시지의 형태에 따라 달라진다. + + ## 20.8 캐시 배열 라우팅 프로토콜 + + 프락시 서버는 사용자 개개인으로부터의 요청을 가로채어 요청한 웹 객체의 캐시된 사본을 제공함으로써 인터넷으로 향하는 트래픽을 대폭 줄여준다. + 그러나 사용자의 증가에 따라 대량의 트래픽은 프락시 서버 자체에 과도한 부하를 줄 수 있다 + 부하를 분산하기 위해 사용하는 프락시 서버를 여러대로 늘리는 것이다. + 캐시 배열 라우팅 CARP 는 프락시 서버의열이 클라이언트의 시점에서는 마치 하나의 논리적인 캐시처럼 보이도록 관리해주는 + 마이크로소프트와 넷스케이프 커뮤니케이션이 제안한 표준이다. + CARP 는 ICP 의 대안이다. CARP 와 ICP 둘 다 관리자가 여러 대의 프락시 서버를 사용하여 성능을 개선할 수 있게 해준다. + + ## 20.9 하이퍼텍스트 캐싱 프로토콜 + + 하이퍼텍스트 캐싱 프로토콜은 형제들이 URL 과 모든 요청 및 응답 헤더를 사용하여 서로에게 문서의 존재 여부에 대한 질의를 할 수 있도록 + 해줌으로써 적중이 아님에도 적중으로 잘못 처리될 확률을 줄인다. + 더 나아가 HTCP 는 형제 캐시들이 서로의 캐시 안에 있는 선택된 문서의 추가 및 삭제를 모니터링하고 요청할 수 있게, 그리고 서로의 캐시된 + 문서에 대한 캐싱 정책을 변경할 수 있게 해준다. + + - 헤더: 32비트 메시지 길이, 8 비트 주 프로토콜 버전, 8 비트 부 프로토콜 버전으로 이루어져있다. + - 데이터: HTCP 메시지를 포함한다. + + ### 20.9.1 HTCP 인증 + + HTCP 메시지의 인증 부분은 선택적이다. + + - 인증길이: 메시지의 인증 영역이 몇 바이트인지 담고 있는 16 비트 숫자이다. + - Sig 시간: 서명이 생성된 시각을 세계표준시이후로 경과한 초 단위의 시간으로 32비트다 + - Sig 만료: 서명이 만료될 시각을 세계 표준시 이후로 경과한 초 단위의 시간으로 표현한 32 비트다 + - 키 값: 공유된 비밀의 이름을 담은 문자열이다 + - 서명: 출발지와 목적지의 아이피 주소와 포트, 메시지의 주/부 HTCP 버전 + + ### 20.9.2 캐싱 정책 설정 + + - Cache-Vary: 이 헤더는 응답 Vary 헤더를 덮어쓴다 + - Cache-Location: 프락시 캐시의 목록은 객체의 사본을 가질 수 도 있다. + - Cache-Policy: 여러 요청자에 대한 공유 x "no-share", 콘텐츠는 쿠키와 캐싱의 결과에 따라 변할 수 있으므로 권하지 않음을 의미하는 "no-cache-cookie" + - Cache-Flags: 요청자는 객체의 캐싱 정책을 수정했으며, 객체는 특별히 취급되어야 할 수 도 있다. + - Cache-Expiry: 요청자가 알게 된 문서의 실제 만료 일시 + - Cache-MD5: 요청자가 계싼한 객체의 MD5 체크썸 + - Cache-to-Origin: 요청자가 측정한 원 서버로의 왕복시간 + + + + + + + + + + + + + +