www.ebay.com Chrome 샘플

-       HTTP 1.1 버전으로 www.ebay.com URL로 GET 요청을 보낸다.

-       커넥션은 keep-alive로 유지하길 원한다.

-       상향된 프로토콜을 사용하는 서버일 경우, 프로토콜을 업그레이드한다. HTTP 요청 > HTTPS 응답

-       클라이언트 브라우저 정보를 보내고, 어떤 형식의 MIME Type을 가진 컨텐츠를 선호하는지 가중치와 함께 명시한다.

-       클라이언트에서 원하는 데이터 인코딩 알고리즘과, 언어도 명시한다.

-       HTTP/1.1 버전을 사용하며, 해당 리소스의 위치가 변경되었음을 알리는 상태코드 301을 반환했다.

-       클라이언트에서 요청한 리소스는 응답 시 스니핑이 불가능하다.

-       XSS 공격 방지를 위해 브라우저 내장 필터를 사용한다.

-       해당 URL 내의 프레임은 오리진이 같을 경우에만 허용한다.

-       리디렉션 URL은 https://www.ebay.com/

-       리디렉션 응답 메시지로 컨텐츠를 가지고 있지 않다.

-       HTTP 1.1의 connection은 keep-alive를 기본으로 설정되어 있으며, 일정 시간 동안 요청이 없을 경우, 서버에서 일방적으로 커넥션을 종료한다.

www.daum.net Chrome 샘플

-       GET 메소드를 이용하여 https://www.daum.net/ URL을 입력하여 정상적으로 동작을 완료하고 200 응답 코드를 받음.

-       해당 호스트의 IP는 203.133.167.16이고 https 프로토콜 포트인 443번 포트로 연결됨

-       Referrer는 해당 리소스를 요청할 때, 참조되는 URL을 의미하며, 어디서부터 요청 연쇄가 시작되었는지 확인할 수 있다.

-       현재 referrer 정책은 no-referrer-when-downgrade로, user-agent인 브라우저에게 해당 정책이 없다고 알리는 기본 값이다. 프로토콜의 보안 레벨이 동일할 때, 해당 URL이 referrer로서 보내진다.

-       클라이언트가 받길 원하는 MIME type과 선호도(가중치)를 나열하여 서버 측에서 리소스를 원활하게 응답할 수 있도록 Accept 헤더에 명시한다.

-       전송받을 수 있는 인코딩 알고리즘은 3가지이며, 언어 또한 가중치로 선호도를 표시할 수 있다.

-       가중치는 선호도를 의미하므로 절대적인 값은 아니다.

-       데이터 송수신을 위한 커넥션을 유지한다.

-       서버에서 클라이언트 식별을 위해 쿠키 값들을 전송한다.

-       서버의 도메인 네임과 포트는 www.daum.net이고, 명시되지 않은 포트는 URL의 프로토콜 포트 기본 값을 사용한다.

-       요청하는 서버가 향상된 버전의 사이트로 리디렉트 가능하도록 설정한다. HTTP 요청을 HTTPS로 리디렉션

-       User-agent 헤더에서 클라이언트의 브라우저 정보를 표시한다.

-       해당 리소스의 캐시된 사본을 클라이언트로 보내기 전에 오리진 서버에 검사 요청을 보내야 하고, 요청이나 응답 메시지를 저장하지 않는다.

-       서버 측에서 커넥션을 닫았다.

-       본문 컨텐츠 전송 시 사용된 인코딩 알고리즘은 gzip이며 컨텐츠는 ko-KR 언어를 사용한다. 컨텐츠의 길이는 49874 bytes, MIME type은 html 문서, charset은 UTF-8 인코딩을 사용한다.

-       응답 메시지는 Date 헤더에 표시된 날짜에 생성되었고, Expires에 명시된 일시에 만료되어, 재검사가 필요해진다.

-       p3p (Platform for Privacy Preferences): W3C에서 개발한 프라이버시 보호 관련 표준 기술. P3p를 적용한 사이트에서는 http 헤더 또는 xml 파일을 통해 해당 사이트에서 취급하는 개인정보 레벨, 성격 등을 브라우저에 알린다.

-       CP는 적용할 압축 정책을 의미하며, p3p 정책이 3글자로 압축되어 나열되어 있고, p3p 공식 페이지에서 확인 가능하다. 규정으로 강제하고 있는 항목은 아니다. 또한 페이지 내에 HTML 태그로 설정 가능하다.

-       Pragma는 http/1.0 일반 헤더로, cache-control과 기능이 같다. http/1.0 클라이언트를 위해 헤더에 포함되었다.

-       Vary는 서버의 응답 메시지에 영향을 줄 수 있는 클라이언트의 요청 메시지 내의 헤더를 의미한다. 다음 요청 시 클라이언트는 Accept-encoding (클라이언트가 받을 수 있는 인코딩) 값을 포함시킨다.

-       익스플로러 호환성 보기는 10을 기준으로 최신 표준 모드로 렌더링.

-       X-ua-device-type: 클라이언트 장비는 pc를 사용한다.

Internet Explorer - www.amazon.com 샘플

-       Cache-control: no-cache는 캐시된 사본을 사용자에게 보이기 전에 서버에 재검증 요청

-       Pragma: HTTP/1.0 ~ 1.1 버전의 cache-control 헤더가 생기기 이전에 사용하던 헤더이다. No-cache 필드 인자는 cache-control: no-cache와 동일.

-       Server 헤더는 서버의 소프트웨어적인 정보를 담고 있지만, 보안 및 기타 이유로 이를 감추고 싶을 때, xml의 http Connector 설정에 server=”” 형태로 문자열 대체하여 표시하는 것이 가능하다.

-       Set-cookie: session-id는 현재 세션의 사용자를 식별하기 위해 사용되며, URI 형식으로 클라이언트에서 생성된다. 응답 시, 요청과 같은 값을 반환해야 한다.

-       Strict-transport-security: includeSubDomains는 현재 도메인의 서브 도메인도 정책 적용을 의미하고, preload는 (HSTS의 HTTPS로 제공되면서 크롬에 하드 코딩된) 사전 로드 사이트 목록에 포함하는 것으로 간주하는 지시자이다.

-       Vary: 요청 사용자의 특징에 따라 서로 다른 응답을 위한 헤더. 동일 URL도 명시 조건에 따라 다른 종류의 컨텐츠를 캐싱하고 제공한다. User-agent를 감지해서 해당 형식에 맞게 제공. (ex. 모바일, 데스크탑)

-       Via: 해당 메시지가 거쳐온 중개자를 나열하며, 프록시에 의해 추가된다. 1.1은 HTTP 프로토콜 버전, CloudFront 호스트를 거쳐 왔음을 의미.

-       X-amz-cf-id: CloudFront에서 추가된 헤더. 오리진에 전달 전 요청을 식별하기 위해 고유한 암호화 문자열 추가.

-       X-cache: CDN에서 추가된 헤더로, 비표준 헤더. CloudFront에 캐시된 컨텐츠가 없었음을 의미.

-       X-content-type-options: nosniff는 요청된 컨텐츠 타입(MINE type)을 브라우저에서 렌더링 시 강제하는 옵션

-       X-ua-compatible: IE=edge는 익스플로러 호환성보기, 현재 설정된 값은 최신 모드로, 지정된 DOCTYPE에 상관없이 IE8 이상 버전에서 항상 최신 표준 모드로 렌더링 함을 의미.         

HTTP Response 헤더 샘플

크롬 https://www.google.com

-       alt-svc: alternative service. 해당 리소스가 다른 프로토콜/호스트/포트 조합으로 접근이 가능할 때 다른 서비스가 가능하다고 알림.

n  대체 서비스가 새로 생성된 이후의 max-age는 30일(2592000초)이고 기본값은 24시간이다.

n  현재 서버가 QUIC 프로토콜를 지원하며, 클라이언트에서 QUIC 통신이 가능하면 UDP:443 포트를 사용하라고 알림. v 파라미터는 quic 지원 버전을 의미

-       Cache-control: private는 단일 사용자를 위한 응답으로서, 캐시가 공유 캐시에 저장되지 않고, 사설 캐시에서는 저장이 가능하다는 의미. max-age보다 오래된 캐시는 보내지 않으며 0일 경우 항상 새로 요청한다.

-       Content-encoding: 본문의 미디어 타입에 적용되는 추가적인 인코딩을 의미. br은 Brotli 알고리즘

-       Content-Type: 본문의 컨텐츠 타입을 MIME 형식으로 나타낸 것. 텍스트 형식의 html 문서 타입을 나타내고 있고, 문자 인코딩은 UTF-8을 사용한다.

-       date: 메시지가 생성된 날짜와 시간

-       expires: 응답 메시지가 최신이 아니라고 판단할 날짜와 시간을 표시. Cache-control 헤더가 메시지에 포함되어 있으면 expires 헤더는 무시된다. 0, -1 등 유효한 날짜 표시형식이 아닐경우, 만료된 것으로 판단.

-       Server: 요청을 처리하는 오리진 서버의 소프트웨어 정보. Gws는 구글 웹 서버

-       Set-cookie: 서버에서 클라이언트로 보내는 쿠키 정보. 키-값 쌍으로 구분한다. 1p_jar는 구글 광고 쿠키로, 사용자 추적 및 광고 타게팅 목적의 쿠키이다.

-       Status: 요청에 대한 상태코드로, 200은 요청이 정상적으로 작동했음을 의미

-       Strict-transport-security: max-age 만큼 설정된 시간동안 해당 응답을 받은 사이트에 대해서 클라언트는 https 접속을 강제한다.

-       X-frame-options: clickjacking 문제를 해결하기 위해 사용되며, 페이지를 표시하는 프레임(iframe, frame)을 어떻게 사용할 것인가에 대해 명시. Same origin은 페이지에 프레임을 사용할 수 있지만, 같은 원본 서버의 페이지만 가능하다는 뜻.

-       X-xss-protection: xss 공격 시도 시 브라우저의 내장 필터를 통해 방지 하는 헤더. Cross site scripting은 HTTP 관련 취약점 공격으로, 페이지, 메일 등에 악성 스크립트를 삽입하여 비정상적으로 페이지를 로드해, 사용자를 방해하거나 쿠키, 개인 정보 등을 특정 사이트로 전송하는 방법.

크롬 브라우저 HTTP Header 샘플 - https://www.google.com

-       콜론으로 시작하는 헤더들은 HTTP/2에서 사용되는 가상 헤더(Pseudo or Virtual)이다. authority는 해당 URI의 권한을 가진 도메인을 명시한다.
요청 메소드는 GET, 경로는 ‘/’, https 프로토콜을 사용한다.

-       accept 요청 헤더는 클라이언트가 사용 가능한 MIME Type들이 나열되며, 서버로부터 받을 Content-Type 협상에 사용된다.

-       ‘;’으로 구분된 q 값들은, quality value라 하며, 우선순위 가중치를 숫자로 명시하지만 절대적인 값은 아니다.

-       accept-encoding: 클라이언트가 이해 가능한 컨텐츠의 압축 알고리즘.

-       cache-control: 캐시 제어를 위한 헤더. max-age에 지정된 시간보다 오래된 캐시는 보내지 않고, 0으로 지정 시 항상 새로 요청한다. no-cache의 경우 캐시를 하지 않고 모든 것을 새로 요청한다.

-       cookie: 서버로부터 이전에 저장된 쿠키 정보들을 나열. 세션과 관련된 정보들로 구성. NID는 브라우저에서 사용되는 고유 ID 환경설정 쿠키로 사용자 관련 정보를 기억하기 위해 사용한다.

-       upgrade-insecure-requests: 보안 URL(HTTPS)이 아닌 일반 HTTP 요청을 HTTPS를 통해 응답을 받은 것처럼 처리하도록 설정하는 헤더

-       user-agent: 클라이언트의 소프트웨어, 운영체제 등의 정보 명시.
HTTP 요청 헤더에서 user-agent의 항목이 Mozilla로 시작하고 비슷하게 나열되는 이유는 초기 웹에서 브라우저마다 컨텐츠를 다르게 다루었기 때문에 이를 방지하기 위해 스푸핑/클로킹을 하는 것이다.

-       x-client-data: googleweblight.com에서 사용되는 실험용 헤더

Cross-Origin Resource Sharing (CORS)

한 도메인에서 로드되어 다른 도메인에 있는 리소스와 상호 작용하는 클라이언트 웹 어플리케이션에 대한 방법을 정의한 표준

HTTP 요청은 기본적으로 Cross-Site HTTP Request가 가능하다.

-       Cross-Site HTTP Request
<img> 태그로 다른 도메인의 파일을 가져오거나, <link> 태그로 다른 도메인의 css를 가져오거나, <script> 태그로 다른 도메인의 자바스크립트 라이브러리를 가져오는 것이 가능하다.

실행 중인 웹 상에서 다른 서버의 자원에 접근할 권한을 갖도록 브라우저에 알리기 위해 추가 HTTP 헤더를 사용하는 방식. 뉴스 기사 사이트에 유튜브 영상이 업로드 되어있어 해당 동영상 컨텐츠를 받아와야 하는 경우 사용된다. CORS 헤더를 포함하지 않으면 보안 상의 이유(Same origin policy: 하나의 origin에서 로드된 문서나 스크립트가 다른 출처 자원과 상호작용하지 못하도록 제약)로 요청을 제한한다.

브라우저가 요청 내용을 분석하여 4가지 방식 중 하나로 서버에 요청한다.

-       Simple Request: 다음 3가지 조건을 모두 만족하는 경우

n  GET, HEAD, POST 중 하나의 메소드 사용

n  POST일 경우 Content-Type이 다음 중 하나 사용

u  application/x-www-form-urlencoded (데이터 파일 전송 시 사용되는 타입)

u  multipart/form-data (바이너리 데이터 전송 시 사용되는 타입)

u  text/plain (일반 텍스트 데이터, 미지정 시 디폴트)

n  커스텀 헤더 없음

-       Preflight Request: Simple Request 조건에 해당하지 않으면 브라우저가 요청하는 방식. OPTIONS 메소드를 먼저 사용하여 실제(actual) 요청에 사용할 메소드를 결정하고 안전하게 전송되도록 한다

n  GET, HEAD, POST 외의 다른 방식으로 요청 가능

n  다른 Content-Type 가능

n  커스텀 헤더 사용 가능

예비 요청으로, 예비 요청/응답 후 본 요청/응답(Actual)한다.

-       Request with Credential: HTTP Cookie와 HTTP Authentication 정보를 인식하는 요청
요청 시 Credential 요청을 보내며, 서버는 헤더에 Access-Control-Allow-Credentials: true를 포함한다. Access-Control-Allow-Origin 헤더에는 구체적인 도메인이 온다.

-       Request without Credential: CORS 요청은 기본적으로 Non-Credential 요청이다.

-       CORS 관련 Response 헤더

-       CORS 관련 Request 헤더

Cache

캐시는 네트워크 자원 낭비, 대역폭, 로드 밸런스, 거리에 따른 지연 등 웹 컨텐츠를 보다 효율적으로 운영하기 위해 사용되는 장치이다. HTTP 요청 메시지를 받아 메시지를 파싱하고 로컬 사본이 있는지 검색한다. 사본을 찾았을 경우에는 캐시된 메시지의 헤더 값을 참조하여 조건에 맞는 캐시 리소스인지 확인하고, 클라이언트에 응답한다. 마지막으로 로그 파일과 캐시 사용에 대한 통계를 갱신한다. 캐시에는 모든 사본이 존재하는 것은 아니기 때문에, cache hit, cache miss로 나뉜다.

원본 서버 콘텐츠가 변경될 수 있기 때문에, GET If-Modified-Since 헤더 등을 사용하여 오리진 서버에 재검사를 수행한다.

l  Revalidation hit: 서버로부터 304 Not Modified를 응답 받아 최신임을 확인

l  Revalidation miss: 서버로부터 콘텐츠와 200 OK 응답을 받은 경우로, 사본이 최신이 아님을 확인

l  Entity delete: 리소스가 삭제되었다면, 404 Not Found 응답을 받고, 캐시는 사본을 삭제한다.

또한 캐시 효율을 가늠하는 기준으로 캐시 적중률과 바이트 적중률을 사용할 수 있다. 각 %로 표시되며 100에 가까울수록 캐시 효율이 좋다고 본다. 특히 바이트 단위는 좀더 디테일한 적중률을 알 수 있다. 클라이언트에서 응답 메시지가 캐시 된 것인지 아닌지 판별하는 방법은, 응답 메시지의 Age 헤더나 Date 헤더를 확인하는 방법이 있다.

RFC 2227에서 HTTP를 위한 간단한 cache-hit 측정과 사용량 제한을 정의한다. HTTP에 특정 URL에 대한 cache-hit 횟수를 정기적으로 서버에 돌려주는 Meter 헤더를 추가한다. 또한, 서버에 보고 전까지 캐시에 리소스 제공 횟수나, 처리시간을 제어할 수 있다.

-       Private cache
개인 전용 캐시로 그리 큰 공간을 필요로 하지 않기 때문에 브라우저에 내장되어 있다. 디스크와 메모리에 캐시해 놓고, 사용자가 캐시 사이즈와 설정을 수정 가능하게 허용한다.

-       Public cache (Proxy cache)
공유된 프록시 서버로, 로컬 캐시에서 문서를 제공하거나, 사용자 입장에서 서버에 접근한다. 모든 요청 중에 중복된 요청이 있다면 그만큼 트래픽을 줄일 수 있다.

-       프록시 캐시 계층 구성: 클라이언트들 주변에는 작은 레벨 1 캐시를 위치시키고, 상위 네트워크 위쪽에 레벨 2 캐시를 위치시키는 방식이다. 단, 캐시 계층이 깊어지면 프록시 연쇄가 길어지고, 각 중간 프록시는 성능 저하가 발생하게 된다. 고성능 프록시 서버들의 경우 이에 해당하지 않는다.

-       캐시 네트워크, 컨텐츠 라우팅, 피어링
URL 등 기준을 잡고 특정 캐시 또는 원본 서버를 선택하도록 유도하거나 우회하는 방법을 사용하거나, HTTP 확장을 통해 ICP, HTCP 등의 프로토콜을 이용해 피어링 구성을 하는 방법도 있다.

캐시 컨트롤 헤더

캐시 컨트롤 우선순위

1.     Cache-Control: no-store: 어떤 것도 캐싱 하지 않음. 이전 캐시 존재 시 삭제

2.     Cache-Control: no-cache: 사본을 클라이언트로 전달하지 않지만 캐시가 존재할 수 있음
2-1. Pragma: no-cache: HTTP/1.0+ 하위호환성을 위해 HTTP/1.1에 포함.

3.     Cache-Control: must-revalidate: 캐시 사용 이전에 재검사, 만료 리소스 사용 금지

4.     Cache-Control: max-age: 리소스가 최신이라고 판단할 최대 시간

5.     Expire: Deprecated. 실제 만료 시간 명시.

6.     캐시 스스로 휴리스틱(체험적인) 방법으로 결정: max age를 계산하는 방식을 캐시 스스로 결정하며, 계산된 시간이 24시간을 초과할 경우, Heuristic Expiration 경고 헤더를 응답 헤더에 추가한다.
6-1. LM 인자 알고리즘: 리소스의 최근 변경 일시를 알 때 사용 가능하며, 얼마나 자주 바뀌는지에 대한 추정에 사용한다.
  - 캐시의 마지막 변경이 오래 전이라면, 안정적인 리소스로 판단하고 앞으로 바뀔 가능성도 낮으니, 더 오래 보관해도 안전하다
  - 최근에 변경된 캐시는 자주 변경될 확률이 높기 때문에, 재검사 전 짧은 기간만 캐시한다.
  - 최근 변경 일시가 없는 리소스는 디폴트 값으로 유지 시간을 설정(ex. 한 시간, 하루 등)

기본적으로 응답 메시지는 만들어진 시간부터 지금까지의 시간을 헤더에 포함한다. Date 또는 Age 헤더를 기반으로 하며, 나이 계산은 응답 메시지가 캐시에 도착한 나이에 캐시에 머무른 시간을 더해주면 된다.

l  Clock Skew: 시간 동기화 문제로, 프록시, 클라이언트, 서버가 각기 시간 동기화가 제대로 이루어져 있지 않은 경우 발생하며, age가 부정확하거나 음수로 계산되기도 한다.

HTTP/1.1은 캐시나 프록시 통과시, Age 헤더에 상대적인 나이를 누적해서 더하는 방법을 사용한다. 추가된 헤더를 인식하지 못하는 장치를 거칠 경우 해당 헤더가 삭제되거나 수정되지 않을 수도 있다. 이 상대 나이는 Date 기반 나이와 별도로 계산되어, 더 큰 값을 선택한다. 또, 요청 시간, 응답을 받은 시간을 계산하여 네트워크 지연을 보수적으로 교정한다.

Authentication

HTTP는 사용자 인증에 자체 인증요구/응답 프레임워크를 제공한다.

-       인증 프로토콜, 헤더
제어 헤더를 통해 타 인증 프로토콜에 맞추어 확장 가능한 프레임워크를 제공한다.

n  기본 인증
클라이언트에서 요청이 오면, 서버는 401 Unauthorized 상태코드와 함께 WWW-Authenticate 헤더와 설명을 반환한다. 이 헤더에는 realm 라는 보안 영역(문서 집합) 지시자가 있는데, 해당 서버에서 정의한 영역으로 접근 가능한 영역에 대한 정보이다. 클라이언트는 브라우저에서 정보를 입력 받아, base-64로 인코딩하여 Authentication 헤더에 기술하고 다시 요청한다.

u  프록시에서의 기본 인증
407 상태코드, Proxy-Authenticate, Proxy-Authorization, Proxy-Authentication-Info 헤더 사용

기본 인증은 일반적인 환경에서 접근을 제어하거나, 노출되어도 치명적이지 않은 경우에 주로 사용한다.

n  다이제스트(digest-요약) 인증
기본 인증 대체를 위해 설계되었다. 비밀번호를 fingerprint 또는 digest 형식으로 전송하여 원 비밀번호가 무엇인지 알 수 없게 한다.

u  MD5: 무한한 입력 값을 유한 범위의 압축으로 변환. 사용자:영역:비밀번호를 사용

u  Nonce: 재전송 방지를 위해 비밀번호에 섞어 변환 값도 바뀌게 하는 것

u  MD5-sess: MD5 해시값에 nonce와 클라이언트 nonce를 연결한 것

-       사전 인가
클라이언트 측에서 다음 난스를 알고 있어 다이제스트 요청/인증요구 단계를 생략하여 메시지 횟수를 줄일 수 있다.

n  첫 인증 성공 시, Authentication-Info 헤더에 다음 난스를 미리 제공

n  WWW-Authenticate 헤더에 stale=true 값을 넣어 제한적으로 nonce를 재사용

n  공유된 비밀키에 기반하여 클라이언트와 서버가 순차적으로 같은 nonce를 생성하도록 시간적으로 동기화된 알고리즘 사용

-       Quality of Protection (qop 옵션)
WWW-Authenticate 헤더에 추가되는 필드로, 클라이언트와 서버가 어떤 보호 기법을 어느 정도 수준으로 사용할 것인지 명시한다.

n  auth: 인증

n  auth-int: 인증 및 메시지 무결성 보호

-       다이제스트 인증에서 그 값이 적절치 않거나 요구된 지시자가 빠진 경우, 또한 uri 지시자가 요청한 리소스와 같지 않은 경우, 400 Bad Request를 반환한다. 또한 로그인이 실패했음을 기록한다.

-       Protection Space
접근한 서버의 루트 URL과 결합하여 보호 공간을 정의한다.

n  기본 인증에서 요청 URI와 하위 경로 모두 같은 보호 공간으로 가정한다.

n  다이제스트 인증에서는 WWW-Authenticate 헤더의 domain 필드를 정의한다.

Proxy

Web Proxy

-       개인 프록시: 클라이언트에서 직접 실행되는 형태

-       공용 프록시: 대부분의 공유된 프록시. 중앙 집중 형태

-       게이트웨이는 클라이언트/서버 간 서로 다른 프로토콜을 연결해 준다.

보안 개선, 성능 향상, 비용 절약, 트래픽 감시 등의 기능 수행

-       접근 제어 프록시: 문서, 인터넷 접근 등 제어. 제한된 컨텐츠에 대한 요청에 대하여 407 Proxy Authorization Required 상태코드와 Proxy-Authenticate 헤더를 반환하고, 클라이언트는 Proxy-Authenticate 헤더에 인증 정보를 담아 다시 요청한다.

-       보안 방화벽: 어플리케이션 레이어 프로토콜 트래픽 제어

-       웹 캐시

-       대리 프록시(Surrogate): SSL 가속기

-       컨텐츠 라우터: 트래픽 조건, 컨텐츠 종류에 따라 요청을 특정 웹 서버로 유도

-       트랜스코더: 이미지 변환, 텍스트 압축, 언어 치환 등

-       Anonymizer: 클라이언트 식별 특성들을 제거하여 익명성 보장. 헤더 정보 제거로 구현

Proxy arrangement

-       Egress 프록시: 로컬과 인터넷 사이의 트래픽 제어를 위해 로컬 네트워크 출구에 위치. 방화벽, 트래픽 요금 및 성능 개선, 필터링 목적

-       Ingress 프록시: 모든 요청을 종합 처리하기 위해 ISP 접근 지점에 위치. 속도 개선 및 대역폭 비용 감소 목적

-       Surrogate: SSL 가속기는 웹 서버 바로 앞 단에 위치해, 서버로의 요청을 모두 처리. 웹 서버 성능 개선 목적

-       네트워크 교환 프록시: 캐시를 이용해 혼잡을 완화, 트래픽 감시 목적

Proxy Layer

프록시 연쇄 구성으로, 다수의 프록시를 거쳐 요청이 처리되는 구조. 프록시는 서로 부모-자식 관계를 가지며, 서버에 가까운 프록시(인바운드)를 부모라 칭한다. 또한 프록시 레이어 내의 프록시들 은 동적으로 경로가 설정될 수 있으며, 로드 밸런스, 지리적 인접성, 프로토콜/타입, 유료 서비스(향상된 속도의 서비스 가입자를 위한) 등의 방식을 사용할 수 있다.

프록시의 트래픽 처리 방법

-       클라이언트 수정: 브라우저에서 프록시 사용 여부 설정

n  수동 설정

n  브라우저 기본 설정

n  프록시 자동 설정: 자바스크립트 실행. Proxy Auto-Configuration 파일에 대한 URI 제공

u  .pac 확장자를 가지며 MIME 타입은 application/x-ns-proxy-autoconfig 이다.

u  URI 접근 시 서버를 계산해 주는 FindProxyForUrl(url,host) 함수 정의

n  Web Proxy AutoDiscovory Protocol: 자동 설정 파일을 가지고 있는 설정 서버(PAC URI)를 찾는 프로토콜

-       네트워크 수정: 네트워크에서 트래픽을 프록시로 유도

-       DNS 네임 스페이스 수정: 대리 프록시가 웹 서버의 IP와 주소를 자신이 직접 사용. DNS 네임 테이블 수동으로 편집하거나 동적 DNS 서버를 이용하여 조정.

-       웹 서버 수정: 웹 서버에서 프록시로 리디렉션 명령 리턴

프록시 URI는 서버 URI와 다르다. 클라이언트에서 서버로의 요청 메시지는 스킴, 호스트, 포트번호가 없는 부분 URI를 가진다. 하지만 클라이언트에서 프록시로의 요청은 완전한 URI를 갖는다. 프록시는 서버와 커넥션이 필요하기 때문에 완전한 URI가 필요하다. 가상 호스트의 경우도 마찬가지이다.

프록시에서는 부분 URI도 지원해야 하는데, Host 헤더를 기반으로 완전 URI를 추출하거나, 과거 이력에서 참조하는데, 어떤 방법으로도 완전한 URI를 찾지 못한다면 클라이언트로 에러 메시지를 보낸다.

Via 헤더는 쉼표로 구분된 waypoint 목록으로, 거쳐간 프록시 정보를 담고 있다.

Server 헤더는 원본 서버에 의해 사용되는 소프트웨어를 알려주며, 프록시는 이를 수정하면 안된다.

HTTP/1.1 TRACE 메소드를 사용해서 프록시가 요청 메시지를 수정하는 것을 추적하여 프록시 흐름을 디버깅할 수 있다.

Web Server

Connection Sequence

1.     클라이언트 커넥션 수락
클라이언트에서 웹 서버로 TCP 커넥션을 요청하면, 서버는 커넥션을 맺고 여기에서 IP 주소를 추출하여 클라이언트를 확인한다. 커넥션은 커넥션 리스트에 추가되고 모니터링 된다. 서버는 언제든지 거절하거나 닫을 수 있다.

A.     클라이언트 식별
Reverse DNS를 사용하여 클라이언트 IP를 클라이언트 호스트명으로 변환하도록 설정한다. 클라이언트 호스트 명을 구체적인 접근 제어와 로깅을 위해 사용하며, hostname lookup은 시간이 걸릴 수 있어 웹 트랜잭션이 느려질 수 있기 때문에, hostname resolution을 꺼 두거나 특정 컨텐츠에 대해서만 켜 놓는다.
아파치에서는 HostnameLookups 설정 지시자를 사용한다.

B.      ident
IETF ident 프로토콜을 지원하는 서버는 identd를 실행하는 클라이언트의 신원을 확인 가능하다. 하지만 조작이 쉽고, 이를 사용하는 클라이언트가 많지 않아 잘 동작하지 않는다. 또한 방화벽에서도 ident 트래픽을 막아 놓는다.
아파치에서는 IdentityCheck 지시어로 사용 가능하며 가용 정보가 없으면 ‘-‘으로 채운다.

2.     요청 메시지 수신
커넥션에 데이터가 도착하면, 데이터를 읽어 요청 메시지를 파싱한다. 요청 메시지 컴포넌트는 CRLF를 기준으로 구분하며, 파싱된 데이터가 어느정도 이해가 가능한 분량이 될 때까지 메모리에 임시 저장한다.

A.     단일 스레드 웹 서버
한 번에 하나의 요청을 처리하며, 완료되어야 다음 커넥션이 처리된다. 처리 도중 다른 커넥션은 무시되므로 로드가 적은 서버나 진단도구에서만 적당하다.

B.      멀티프로세스와 멀티스레드 웹 서버
여러 개의 요청을 처리하기 위해 복수의 프로세스 / 스레드를 할당한다. Worker pool 시스템으로 스레드를 미리 생성 가능하다. 프로세스나 스레드 최대 개수에는 제한을 걸어 부하를 줄여야 한다.

C.      다중 I/O 서버
대량의 커넥션 지원을 위해 사용하며, 커넥션을 다중화 한다. 많이 사용되는 아키텍처이며, 커넥션에 대해 조금씩 작업을 수행하여 리소스 낭비가 적다.

D.     다중 멀티스레드 웹 서버
멀티 스레드, 커넥션 다중화를 결합한 아키텍처이다.

3.     리소스 매핑, 접근

A.     Docroot
여러 종류의 리소스 매핑을 지원하는 웹 서버의 가장 단순한 형태는, 서버의 파일 시스템 및 파일 이름을 URI로 사용하는 것이다.
/item/sample.jpg를 요청 받으면, 서버에 설정된 docroot를 기준으로 /usr/local/httpd/html/item/sample.jpg를 반환하는 형식이다.
httpd.conf 설정 파일에 DocumentRoot를 설정할 수 있다.

                         i.         가상 호스팅 docroot
분리된 docroot를 설정하여 한 웹 서버에서 여러 개의 사이트를 호스팅 한다. URI, Host 헤더에서 얻은 IP 주소, 호스트명 등을 이용해 식별한다.

                        ii.         사용자 홈 dir docroot
/~사용자명/index.html (실제위치=/home/사용자/public_html) 과 같은 URI 형식으로 해당 사용자의 개인 docroot를 가리킬 수도 있다.

B.      디렉터리
디렉터리를 가리키는 URI 요청 시 다음과 같은 액션을 취할 수 있다.

                         i.         에러 반환

                        ii.         Index 파일 반환

                       iii.         디렉터리 탐색 내용을 담은 HTML 페이지 반환

대부분의 서버는 요청 URL에 대응하는 디렉터리 안에서 index.html(index.html) 파일을 찾는다.
아파치에서는 DirectoryIndex 지시자를 사용 가능하다.

C.      동적 컨텐츠 리소스 매핑
실행 가능한 경로명을 포함한 URI로 요청을 받으면 대응하는 디렉터리에서 프로그램을 찾아 실행을 시도한다. cgi, java-servlet, ASP 등이 있다.

D.     Server-Side Includes (SSI)
웹 페이지 내에서 다른 파일 내용을 읽어 삽입하는 방법. 모든 페이지에 공통적인 내용이나 코드 최적화를 위해 사용하며, 클라이언트로 응답하기 전에 처리한다.

E.      접근 제어
IP 기반으로 제어하거나, 비밀번호를 요구

4.     응답

A.     응답 엔터티
본문의 MIME 타입과 관련된 Content-Type, Content-Length 헤더와 본문을 응답 메시지에 포함 시킨다.

B.      MIME 타입 결정

                         i.         mime.types
파일 이름의 확장자 사용하여 타입 구분. 확장자 별 MIME 타입이 명시된 파일 탐색

                        ii.         magic typing
파일의 내용을 검사해서 알려진 패턴에 대한 테이블(매직 파일)에서 찾는 방법. 표준 확장자 없이 이름 지어진 경우에 사용된다.

                       iii.         Explicit typing
확장자나 내용에 상관없이 MIME 타입을 갖도록 설정

                       iv.         Type negotiation
한 리소스가 여러 종류의 형식에 속하도록 설정하는 방식. 특정 파일이 특정 타입을 가지게 하도록 설정 가능.

C.      리디렉션

                         i.         영구 이전: 301 Moved Permanently

                        ii.         임시 이전: 303 See Other, 307 Temporary Redirect

                       iii.         URL 증강: 상태 정보를 내포한 새 URL로 리디렉트하고, 트랜잭션 간 상태를 유지하는 방법.

                       iv.         부하 균형: 부하가 덜 심한 서버로 리디렉트. 303, 307

                        v.         클라이언트 정보를 가진 타 서버로 리디렉선

                       vi.         디렉터리 이름 정규화: 클라이언트 요청에서 빠진 / 문자를 서버에서 동작 가능하게 추가한 URI로 리디렉트

     5. 로깅
        트랜잭션 완료 후 수행 결과에 대해 로그파일 기록.

DNS

네트워크 상의 도메인 네임을 IP 주소에 매핑해 주는 시스템으로, 초기에 호스트 네임 별로 IP 주소 정보를 시스템 안의 hosts.txt 파일로 관리하던 것이 관리 대상이 증가하고, 기술의 발달에 따라 분산 구조로 관리가 가능하도록 개발된 시스템이다.
DNS 도메인 네임은 a-z, A-Z, 0-9, 하이픈(-) 문자만 허용한다.

DNS Components

-       TLD: Top Level Domain. 루트 도메인 하위의 상위 도메인

-       SLD: Second Level Domain. 도메인 등록 조직, 국가 등 소속 기관의 성격으로 분류. gTLD의 하위 도메인일 경우, 최종 사용자가 정의한 도메인을 등록하여 사용한다.

-       Third Level Domain: SLD 하위 도메인으로, gTLD를 제외하고 최종 사용자에 의해 정의된 도메인

Sub Domain: 사용 목적에 따라 최종 사용자에 의해 정의된 도메인. a.b.com의 경우 a 가 서브 도메인에 해당한다.

Name Server

  도메인 네임 스페이스에 대한 정보를 저장하는 호스트. 일반적으로 네임 스페이스에 대한 정보를 파일 형태로 가지고 있고, 해당 존에 대한 권한을 가지고 있다. 마스터/슬레이브 구성의 네임 서버의 경우, 보조 네임 서버에서 마스터 네임 서버의 존 파일을 읽어 서비스 한다. 또한 캐싱 기능으로 TTL 값을 이용한다. 한번 들어온 질의에 대하여 응답을 저장해 두고, 같은 질의 시 해당 응답을 돌려준다.

Zone

네임 스페이스 내부의 일부분으로, 해당 존의 네임 서버는 도메인 파일이 아닌 존 파일을 읽는다.

Resolver 
   OS에 포함된 네트워크 소켓 라이브러리에 포함된 프로그램으로, 브라우저 등 DNS 클라이언트의 요청을 네임 서버로 전달하고, 메인 네임과 IP 주소를 받아 클라이언트에 제공하는 기능을 수행.

-       Recursive DNS
일반적인 재귀적 네임 서버. 클라이언트로 최종 결과값을 반환하며, 리졸버로부터 질의 요청이 들어온 경우, 네임 서버가 직접 탐색하여 결과를 반환한다.

-       Iterative DNS
루트 네임서버, 일부 TLD 네임 서버의 형태. 자신이 직접 관리 하지 않는 질의는 응답이 가능한 네임 서버 목록으로 응답하는 방식.

-       PQDN (Partially Qualified Domain Name): 호스트 네임으로 시작하지만 루트 도메인까지 명시되지 않은 도메인.

-       FQDN (Fully Qualified Domain Name): 호스트 네임부터 네임 스페이스의 루트까지 표시된 도메인 네임. DNS 존 파일에서는 PQDN과 구분하기 위해 도메인 끝에 마침표를 붙여 FQDN임을 식별한다.

DNS zone, 도메인 네임과 관련된 정보를 갖는 레코드로, 각 값들이 이름과 값으로 바인딩 된다. 이 정보들이 DNS 네임 서버 내에 레코드 집합으로 구성된다. DNS 쿼리에 대해 1개 이상의 레코드 값을 포함한 DNS 메시지를 응답한다.

-       AXFR (Authoritative Zone Transfer)
마스터 네임 서버에서 보조 네임 서버로 전체 존 파일을 전송하는 것

-       IXFR (Incremental Zone Transfer)
존 파일의 이전 값과 비교하여 변경된 부분만 전송하는 것. 권한 서버가 요청 받은 내용이 부족할 경우 무시되고 AXFR 응답을 보낸다.

리소스 레코드는 도메인 네임에 설정할 수 있는 데이터 타입이다. 도메인 네임을 키 값으로 하여 이를 도메인 네임에 필요한 데이터를 설정하는데, 사전에 정의된 데이터 타입과 포맷으로 해야 한다. 도메인 네임과 IP 주소 매치를 위해 사용된다. 

  -A 리소스 레코드: Host Address란 의미로 도메인 네임에 매치되는 IPv4를 정의한다. 

Ø  Class: IN(InterNet) 외에도 있지만 현재 대부분 IN사용
  TTL: 요청된 리소스 리코드는 TTL에 명시된 시간 소요 후 삭제되어 재요청이 필요. 생략 시 SOA 리소스 레코드에 정의된 default TTL 적용 

Ø  NS (Name Server) 리소스 레코드: 도메인 존의 네임서버를 정의. 

Ø  CNAME 리소스 레코드: Canonical Name. 도메인 네임에 별칭을 매치. 해당 도메인 네임에 대한 리소스 레코드를 동일하게 접근하여 사용하므로, 정보를 CNAME이 상속받는다. 
   ex) www.naver.com IN CNAME naver.com 참조 시 naver.com 리소스 레코드를 참조하여 정보를 반환한다. 

-SOA 리소스 레코드: Start of a zone Of Authority. 존에 대한 권한 시작을 의미. 하나의 도메인 존에 반드시 하나의 SOA가 존재하는 특수 레코드로, 도메인 존의 default 설정과 마스터 네임 서버 지정 등에 사용된다. 

Name: 상위 도메인 존에게 위임 받은 도메인 존의 도메인 네임 
  마스터 네임 서버: NS 리소스 레코드와 A 리소스 레코드를 통해 도메인 존에 대한 리소스 레코드 생성, 변경, 삭제 등의 권한을 위임 받음
  Responsible person: 도메인 존 관리 담당자 메일 주소 
  Serial: 도메인 존 파일에 대한 버전 정보. 정보 변경 시 증가. 이 값을 기반으로 슬레이브 네임 서버가 마스터 네임서버의 최신 리소스 레코드 정보를 획득한다. 
  Refresh: 슬레이브 네임 서버가 마스터 네임서버에 도메인 존 파일 버전을 질의하는 초단위 시간으로, 해당 시간만큼 대기 후 마스터에 질의 
  Retry: 슬레이브 네임 서버가 마스터 네임 서버에 질의 실패 시 재시도 하는 초 단위 시간으로 Refresh 보다 작은 값 작성 
  Expire: 슬레이브 네임 서버가 질의 실패 시 마스터로부터 얻은 정보의 유효 시간 초 단위 작성. 해당 도메인 존에 대한 질의 무시 
  Minimum: 도메인 존 파일에 있는 리소스 레코드들의 default TTL 값 작성(초 단위) 

SOA 끝 필드의 각 설정 값들은 기본 초 단위이며, D, H, W로 각각 일, 시간, 주로 작성 가능하다.

-MX 리소스 레코드: 수신 메일  서버를 정의. 호스트명이나 도메인 네임으로만 정의가 가능하다. IP 주소 입력 시 도메인으로 인식하여 존재하지 않는 도메인이 되어버린다. 레코드 입력 시 마지막에 .을 붙인 FQDN을 사용한다.