[bookCrush/httpPerfectGuide] chapter20_ 고석진

chapter_20/고석진.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: 요청자가 측정한 원 서버로의 왕복시간 
+
+
+
+
+
+
+
+
+
+
+
+
+
+