From 770b4557bd0aa54fee42f57d060c7c2fa795cedb Mon Sep 17 00:00:00 2001 From: Olaf Date: Sun, 9 Feb 2020 10:10:04 +0900 Subject: [PATCH 1/3] =?UTF-8?q?[WIP]=20[bookCrush/httpPerfectGuide]=20chap?= =?UTF-8?q?ter19=5F=20=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" | 162 ++++++++++++++++++ 1 file changed, 162 insertions(+) create mode 100644 "chapter_19/\352\263\240\354\204\235\354\247\204.md" diff --git "a/chapter_19/\352\263\240\354\204\235\354\247\204.md" "b/chapter_19/\352\263\240\354\204\235\354\247\204.md" new file mode 100644 index 0000000..7850410 --- /dev/null +++ "b/chapter_19/\352\263\240\354\204\235\354\247\204.md" @@ -0,0 +1,162 @@ +# HTTP + +## 19.2 WebDAV 와 공동 저작 + +웹 분산 저작과 버저닝은 웹 배포 공동 작업에 대한 또 다른 영역을 개척했다. +이메일을 사용하거나 분산 파일 공유를 함께 사용할 떄도 있다. +이 방식은 프로세스에 대한 제어를 거의 할 수 없어서 불편하고 에러가 많은 것으로 알려져있다. + +### 19.2.1 WebDAV 메서드 + +- PROPFIND: 리소스의 속성을 읽는다. +- PROPPATCH: 한 개 이상의 리소스에 대해 한 개 이상의 속성을 설정한다. +- MKCOL: 콜렉션을 생성한다. +- COPY: 특정 원본지에서 특정 목적지로 리소스나 리소스의 집합을 복사한다. 목적지가 같은 기기에 있을 필요는 없다. +- MOVE: 특정 소스에서 특정 목적지에 리소스나 리소스의 집합을 이동시킨다. 목적지가 같은 기기에 있을 필요는 없다. +- LOCK: 하나 이상의 리소스를 잠근다 +- UNLOCK: 기존에 잠겨있는 리소스를 잠금 해제한다. + +### 19.2.2 WebDAV 와 XML + +WebDAV 의 메서드는 요청과 응답 관련 정보를 모두 잘 다루어야 한다. +HTTP는 보통 이 정보를 메시지 헤더에 담아 전달한다. +하지만 헤더에만 정보를 담아 전송하는 것은, 하나의 요청에 있는 여러 개의 리소스나 계층 관계에 있는 리소스들에 대한 정보를 +헤더에 선택적으로 기술하기 어려운 점 등의 한계가 있다. + +WebDAV 는 이 문제를 해결하기 위해 XML 을 지원한다. 용도는 아래와 같다 + +- 데이터를 어떻게 처리 할지 명령 포맷 +- 서버의 복잡한 응답을 표현하는데 사용 +- 콜렉션 리소스를 처리하는데 사용 +- 데이터 자체를 표현할 수 있는 포맷 + +WebDAV 는 "DAV:" 라는 별도의 XML namespace 를 정의한다. + +### 19.2.3 WebDAV 헤더 + +- DAV: WebDAV 를 제공하는 서버와 통신할 떄 사용한다. WebDAV 에서 지원하는 모든 리소스는 OPTIONS 요청에 대한 응답에 이 헤더를 포함해야한다. +- Depth: 여러 수준의 계층 구조로 분류된 리소스에 WebDAV 를 사용하기 위한 중요한 요소다. +- Destination: COPY 나 MOVE 메서드가 목적지 URL 을 식별하는데 쓰인다. +- if: 정의되어 있는 상태 토큰은 lock 토큰뿐이다. if 헤더는 조건 집합을 정의한다. 조건이 맞지 않다면 해당 요청은 실패한다. +- lock-token: 제거되어야 할 잠금을 명시하는 용도로 UNLOCK 메서드에서 사용한다. LOCK 메서드에 대한 응답은 lock 토큰에 대한 필요한 정보를 전달하는 Lock-Token 헤더를 포함한다 +- Overwrite: 대상을 덮어쓸 것인지 아닌지를 기술하는 데 쓰이며 COPY 나 MOVE 메서드에서 사용한다. +- Timeout: 클라이언트가 필요한 잠금 타임아웃 값을 기술하는 데 사용하는 요청 헤더다. + +### 19.2.4 WebDAV 잠금과 덮어쓰기 방지 + +A 와 B 가 함께 작업할 때 서로의 작업물을 덮어씌울 수 있는 위험이 있다. +이 문제를 개선하기 위해 WebDAV 는 잠금 이라는 개념을 지원한다. 완벽한 해결책은 아니다. +완벽한 해결책을 만드려면 버저닝과 메시징을 지원해야 한다. + +- 리소스나 콜렉션에 대한 배타적 쓰기 잠금 +- 리소스나 콜렉션에 대한 공유된 쓰기 잠금 + +배타적 쓰기 잠금은 잠금 소유자만 쓸 수 있게 보장한다. 이 잠금 혀식은 잠재적인 충돌을 완벽히 제거한다. +공유된 쓰기 잠금은 여러 사람으로 이루어져 있는 그룹이 하나의 문서에서 작업 할 수 있게 한다. + +잠금을 수행하려면, 저자를 식별하는 메커니즘을 필요한다. WebDAV는 다이제스트 인증을 요구한다. +잠금이 승인되면, 서버는 도메인 전체에서 유일한 토큰을 클라이언트에 반환한다. +명세에서는 이를 opaquelocktoken 잠금 토큰 URI 스킴이라고 부른다. +쓰기를 하려면 정확한 사용자와 잠금 토큰이 모두 결정되어야 한다. + +### 19.2.5 LOCK 메서드 + +WebDAV 의 강력한 기능은 한개의 LOCK 요청으로 여러 개의 리소스를 잠글 수 있다는 것이다. +WebDAV의 잠금은 클라이언트가 서버에 연결되어 있지 않아도 된다. + +- : 전송된 XML 에는 기본 요소로 lockInfo 를 가진다. +- : 잠금 형식을 가리킨다. 현재는 단 한 개의 "write" 만 있다. +- : 배타적 잠금인지 공유된 잠금인지를 가리킨다. +- : 현재 잠금을 가지고 있는 사람이 기술되어 있는 필드다 +- : URI 스킴에서 opaquelocktoken 이라 부르는 토큰으로 잠금을 식별하는데 사용한다. +- Depth 헤더와 같은 값을 가진다 +- : 잠금에 대한 타임아웃을 가리킨다 +- opaquelocktoken 스킴: 언제든 모든 리소스에 유일한 토큰을 제공하기 위해 설계되었다. 유일성을 보장하기 위해서 UUID 매커니즘을 사용한다 +- XML 요소: 활성화되어 있는 잠금을 찾는 매커니즘을 제공한다. +- 잠금 갱신과 Timeout 헤더: 잠금을 갱신하려면, 클라이언트는 If 헤더에 잠금 토큰과 함께 잠금 요청을 다시 보내야 한다. + +### 19.2.6 UNLOCK 메서드 + +리소스에 있는 잠금을 제거한다. +리소스 관리 요청에서, WebDAV 에서 UNLOCK 를 성공하기 위한 두 가지 조건이 있다. +다이제스트 인증을 성공적으로 완료하는 것과 Lock-Token 헤더에 보내는 잠금 토큰이 맞는지 검사하는 것이 바로 그것이다. + +[참고]:(https://docs.microsoft.com/en-us/previous-versions/office/developer/exchange-server-2003/aa143146(v%3Dexchg.65)) + +### 19.2.7 속성과 META 데이터 + +속성에는 저작자의 이름, 수정 날짜, 내용 등급 등과 같은 리소스의 정보를 기술한다. +HTML 의 META 태그는 콘텐츠 일부로써 그 정보들을 포함하는 매커니즘을 제공한다. + +문서가 편집될 때, 새로운 저작자를 반영하여 갱신해야한다. WebDAV 용어로 그런 동적 수정 속성을 'live' 속성이라고한다. +거의 변하지 않는 Content-Type 과 같은 정적 속성을 'dead' 속성이라고한다. + +속성의 발견과 수정을 지원하기 위해, WebDAV는 PROPFIND 와 PROPPATCH 라는 두 가지 새로운 메서드를 포함해 HTTP 를 확장한다 + +### 19.2.8 PROPFIND 메서드 + +주어진 파일이나 파일 그룹의 속성을 읽는 데 사용한다. + +- 모든 속성과 그 값을 요청한다. +- 선택된 속성과 그 값의 집합을 요청한다 +- 모든 속성의 이름을 요청한다 + +- : PROPFIND 메서드로부터 반환될 속성들을 기술한다. +- : 반환될 모든 속성의 이름과 값을 기술한다. +- : 반환될 속성 이름의 집합을 기술한다. +- : 요소의 하위 요소다. 반환될 값의 속성을 기술한다. +- : 여러 응답을 담는 컨테이너 +- 리소스의 URI 를 가리킨다 +- : 특정 요청에 대한 HTTP 상태 코드를 기술한다 +- : 요소 한 개와 요소 한개로 이루어져 있는 집합이다. + +### 19.2.9 PROPPATCH 메서드 + +특정 리소스의 여러 속성을 설정하거나 제거하는 원자적 매커니즘을 제공한다. +원자성은 모든 요청이 성공하거나 모든 요청이 무효화 되거나, 둘 중 하나만 수행하는 것을 보장한다. + +- : PROPPATCH 의 기본 XML 요소 +- : 설정할 속성을 기술한다 +- : 제거할 속성을 기술한다. + +[참고](https://docs.microsoft.com/en-us/previous-versions/office/developer/exchange-server-2003/aa142976(v%3Dexchg.65)) + +### 19.2.10 콜렉션과 이름공간 분리 + +콜렉션은 사전에 정의한 계층에 있는 리소스들의 논리적 혹은 물리적 그룹이다. +파일시스템의 디렉터리 같이 다른 리소스들의 컨테이너처럼 동작한다. 콜렉션은 다른 콜렉션을 포함한다. +WebDEV 는 XML namespace 메커니즘을 사용한다. 전통적인 namespace 와 달리 XML namespace 파티션들은 충돌이 절대 생기지 않게 하고 +명확한 구조적 제어 기능을 제공한다. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + From 8d294ff5af387c88a3e9d63fd79b74efc4234ec2 Mon Sep 17 00:00:00 2001 From: Olaf Date: Sun, 9 Feb 2020 22:36:25 +0900 Subject: [PATCH 2/3] =?UTF-8?q?Update=20=EA=B3=A0=EC=84=9D=EC=A7=84.md?= 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" | 44 +++++++++++++++++++ 1 file changed, 44 insertions(+) diff --git "a/chapter_19/\352\263\240\354\204\235\354\247\204.md" "b/chapter_19/\352\263\240\354\204\235\354\247\204.md" index 7850410..216d7b8 100644 --- "a/chapter_19/\352\263\240\354\204\235\354\247\204.md" +++ "b/chapter_19/\352\263\240\354\204\235\354\247\204.md" @@ -128,8 +128,52 @@ HTML 의 META 태그는 콘텐츠 일부로써 그 정보들을 포함하는 매 WebDEV 는 XML namespace 메커니즘을 사용한다. 전통적인 namespace 와 달리 XML namespace 파티션들은 충돌이 절대 생기지 않게 하고 명확한 구조적 제어 기능을 제공한다. +### 19.2.11 MKCOL 메서드 +MKCOL 메서드는 클라이언트가 지어된 URL 에 해당하는 콜렉션을 서버에 생성하게 한다. +- 콜렉션을 생성할 목적으로 PUT 이나 POST 를 사용하려면, 클라이언트는 요청 안에 추가적인 정보를 더해 보는 식으로 자체적인 프로토콜을 만들어야한다. +즉석으로 프로토콜을 정의하는 것은 번거롭고 오류를 발생시키기 쉽다. +- 대부분의 접근 제어 메커니즘은 메서드의 타입에 기반해 동작한다. 몇 가지 메서드만이 저장소에 있는 리소스를 생성하고 삭제할 수 있다. + +### 19.2.12 DELETE 메서드 + +디렉터리를 지우려고 한다면, Depth 헤더가 필요할 것이다. +Depth 헤더가 기술되어 있지 않으면, DELETE 메서드는 Depth 헤더가 무한으로 설정되어 있다고 가정할 것이다. +이는 디렉터리와 그 하위에 있는 모든 디렉터리가 지워진다는 뜻이다. + +콜렉션을 제거하려 할 때, 콜렉션이 누군가에 의해 잠겨 있어서 지울 수 없는 경우가 언제든지 생길 수 있다. +이 경우 콜렉션 자체는 지워지지 않을 것이며 서버는 207 Multi-Status 상태 코드를 반환한다. + +### 19.2.13 COPY 와 MOVE 메서드 + +MKCOL 과 마찬가지로, COPY 및 MOVE 작업을 할 수 잇는 다른 방법이 있다. +COPY 메서드의 대안은, 리소스에 GET 요청을 보내고, 리소스를 다운 받은 다음, PUT 요청과 함께 서버에 리소스를 다시 올리는 것이다. +MOVE도 이와 유사한 방식의 대안이 있다. +그러나 이런 방식은 다단계 콜렉션에 대한 COPY나 MOVE 작업을 할 때 발생하는 모든 문제를 고려해 봤을 때, 확장이 쉽지 않다는 문제가 있다. +COPY 와 MOVE 메서드는 요청 URL 을 원본의 위치 정보로 사용하고 목적지인 Destination HTTP 헤더의 값을 목적지 정보로 사용한다. + +COPY나 MOVE 가 콜렉션을 처리할 때는 Depth 헤더에 영향을 받는다. 헤더가 없다면 무한대 깊이로 가정하고 수행된다. + +- overwrite 헤더의 영향: Overwrite 헤더는 TF 로 설정하였고 목적지가 존재한다면, COPY나 MOVE 작업을 수행하기 전에 무한대 값을 가진 Depth와 함께 DELETE가 목적지 리소스에 수행될것이다. +- COPY/MOVE의 속성: 콜렉션이나 요소를 복사하면, 기본적으로 그것들의 모든 속성도 복사된다. 하지만 요청은 작업에 대한 추가 정보를 기술한 XML 본문을 포함할 수 있다. 반드시 모든 속성이 성공적으로 복사되어야 한다고 기술하거나, 어떤 속성만 복사하려고 하는지 기술할 수 있다. +- 잠긴 리소스와 COPY/MOVE: 리소스가 현재 잠겨 있으면, COPY와 MOVE 모두 목적지로 잠겨있는 리소스를 이동하거나 복사하는 것이 금지된다. +이 두가지 모두 현재 잠겨 있는 콜렉션 아래를 목적지로 하는 COPY나 MOVE가 수행될 경우, 복사 혹은 이동된 리소스도 잠기게된다 + +### 19.2.14 향상된 HTTP/1.1 메서드 + +WebDAV 는 HTTP 메서드인 DELETE, PUT, OPTIONS 의 의미를 수정했다. +GET 과 HEAD 의 의미는 바뀌지 않고 그대로 두었다. + +- PUT 메서드: WebDEV 가 PUT 메서드를 따로 정의하지는 않지만, PUT 메서드는 저작자가 공용 사이트에 콘텐츠를 전송하는 유일한 방법이다. +if 헤더에 기술되어 있는 잠금 토큰이 리소스에 있는 것과 일치한다면, PUT 작업이 수행되어야 한다. +- OPTIONS 메서드: 보통 WebDAV 를 사용하는 클라이언트가 보내는 첫 요청에 쓰인다. 클라이언트는 OPTIONS 메서드를 사용해서 WebDAV 서버가 어떤 것들을 제공하는지 알아볼 수 있다. + - Class 1 지원: 서버는 RFC 2518 의 모든 절에 있는 MUST 요구사항을 지원해야한다. 리소스가 Class 1 수준만 지원한다면, DAV 헤더의 값으로 1 을 보낼 것이다. + - Class 2 지원: Class 1 요구사항 모두 지원하는 것에 더해 LOCK 메서드를 지원한다. LOCK 와 함께, Class 2 를 지원하려면 Timeout 과 Lock-Token 헤더를 지원해야 하고 XML 요소를 지원해야한다. + +### 19.2.15 WebDAV 의 버전 관리 + +수정한 것이 유실되는 문제를 완벽히 막으려면, 잠금과 버저닝이 필수다. 버저닝과 관련된 일반적인 기능중 일부는, 이전 문서의 버전을 저장하고 접근하는 것과 변경 기록과 벼녁ㅇ에 대해 자세한 내용이 기술된 주석을 관리하는 것이다. RFC 3253 에서 WebDAV에 추가되었다. From 830fba21c8829a106bb0fb44684caaeb41f217cd Mon Sep 17 00:00:00 2001 From: Olaf Date: Sun, 9 Feb 2020 23:34:11 +0900 Subject: [PATCH 3/3] =?UTF-8?q?Update=20=EA=B3=A0=EC=84=9D=EC=A7=84.md?= 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" | 54 ++++++++++++++++++- 1 file changed, 52 insertions(+), 2 deletions(-) diff --git "a/chapter_19/\352\263\240\354\204\235\354\247\204.md" "b/chapter_19/\352\263\240\354\204\235\354\247\204.md" index 216d7b8..1136978 100644 --- "a/chapter_19/\352\263\240\354\204\235\354\247\204.md" +++ "b/chapter_19/\352\263\240\354\204\235\354\247\204.md" @@ -173,8 +173,58 @@ if 헤더에 기술되어 있는 잠금 토큰이 리소스에 있는 것과 일 ### 19.2.15 WebDAV 의 버전 관리 -수정한 것이 유실되는 문제를 완벽히 막으려면, 잠금과 버저닝이 필수다. 버저닝과 관련된 일반적인 기능중 일부는, 이전 문서의 버전을 저장하고 접근하는 것과 변경 기록과 벼녁ㅇ에 대해 자세한 내용이 기술된 주석을 관리하는 것이다. RFC 3253 에서 WebDAV에 추가되었다. - +수정한 것이 유실되는 문제를 완벽히 막으려면, 잠금과 버저닝이 필수다. 버저닝과 관련된 일반적인 기능중 일부는, 이전 문서의 버전을 저장하고 접근하는 것과 변경 기록과 변경에 대해 자세한 내용이 기술된 주석을 관리하는 것이다. RFC 3253 에서 WebDAV에 추가되었다. + +# 20 장 + +## 리다이렉션과 부하 균형 + +HTTP 메시지의 데이터는 많은 프로토콜에 의해 통제된다. HTTP 가 고려하는 것은 여정의 출발지와 목적지 뿐이지만, +미러링된 서버, 웹 프락시, 캐시가 함께 하는 HTTP 메시지의 목적지는 항상 단순하지 않다. +리다이렉션 기술은 메시지가 프락시, 캐시, 서버 팜의 특정 웹 서버 중 어디에서 끝나는지 판별하기 위해 사용한다. +리다이렉션 기술은 클라이언트의 메시지를 명시적으로 요청하지 않은 곳으로 보낼 수 있다. + +## 20.1 왜 리다이렉트인가 ? + +- 신뢰할 수 있는 HTTP 트랜잭션의 수행 +- 지연 최소화 +- 네트워크 대역폭 절약 + +한 곳에서 접근에 실패한 경우 다른곳을 이용할 수 있으므로 신뢰성이 개선된다. +클라이언트가 가까운 리소스에 접근할 수 있게 되어 콘텐츠를 더 빨리 받게 된다. +목적지 서버가 분산되므로 네트워크 혼잡도 줄어든다. + +## 20.2 리다이렉트 할 곳 + +웹 서버는 IP 별로 요청을 다룬다. 똑같이 복제된 서버들로 요청을 분산한다는 거은 같은 URL 에 대해 여러곳에서 온 요청들을 +각각 최적의 웹 서버로 보내겠다는 것을 의미한다. +프락시는 프로토콜별로 요청을 다룬다. 프락시 이웃의 모든 HTTP 트래픽은 프락시를 거쳐야 한다. 모든 요청이 프락시 캐시로 흘러 들어가는 것이 이상적이다. +왜냐하면 캐시는 자주 찾는 문서를 저장하여 클라이언트에게 직접 제공하기 때문에 원 서버로의 더 오래 걸리고 비용이 드는 통신을 피할 수 있기 떄문이다. + +## 20.3 리다이렉션 프로토콜의 개요 + +리다이렉션의 목표는 HTTP 메시지를 가용한 웹 서버로 가급적 빨리 보내는 것이다. +HTTP 메시지가 인터넷을 통해 나아가는 방향은 그 메시지가 오고 거쳐가고 향하는 HTTP 애플리케이션과 라우팅 장치에 영향을 받는다. + +- 브라우저 애플리케이션의 사용자는 브라우저가 클라이언트 메시지를 프락시 서버로 보내도록 설정할 수 있다. +- DNS 분석자는 메시지의 주소를 지정할 떄 사용될 아이피 주소를 선택한다. +- 메시지는 주소가 지정된 여러 개의 패킷으로 나뉘어 네트워크를 통과한다. 스위치와 라우터들은 패킷의 TCP/IP 주소를 검증하고 그에 근거하여 패킷은 어떻게 라우팅 할 것인지 결정한다. +- 웹 서버는 HTTP 리다리엑트를 이용해 요청이 다른 웹서버로 가도록 할 수 있다. + +| 매커니즘 | 동작 | 재 라우팅 근거 | 제약사항 | +|---|---|---|---| +|HTTP 리다이렉션 | 콘텐츠 제공하기에 최적인 웹 서버를 선택해줄 첫번 째 서버로 간다. | 라운드로빈 부하 균형, 회전 지연 최소화, 최단 거리 선정 | 크릴 수 있다 | +| DNS 리다이렉션 | DNS 서버가 URL 의 호스트 명에 대한 응답으로 어떤 IP 주소를 사용할지 결정한다 | 라운드 로빈 부하균형, 회전지연 최소화, 최단거리 선정 | DNS 서버를 설정해야 한다 | +| 임의 캐스팅 어드레신 | 여러 서버가 같은 IP 주소를 사용한다. 각 서버는 백본 라우터인 척 한다. 그 외의 라우터들은 공유된 IP 주소로 향하는 패킷을 가장 가까운 서버로 보낸다 | 라우터들은 내장된 최단거리 라우팅 기능을 사용한다 | 라우터를 갖고 설정해야한다. 라우팅이 바뀌고 커넥션과 연관된 패킷들이 다른 서버들로 보내진다면 수립된 TCP 커넥션이 깨질수도있다 | +| 아이피맥 포워딩 | 스위치나 라우터 같은 네트워크 요소가 패킷의 목적지 주소를 읽는다. 만약 패킷이 리다이렉트되어야 한다면, 스위치는 패킷에게 서버나 프락시의 목적지 MAC 주소를 준다 | 대역폭을 절약하고 QOS 를 개선한다. | 서버나 프락시는 반드시 한 홉 거리에 있어야한다 | +| IP 주소 포워딩 | 레이어4 스위치는 패킷의 목적지 포트를 평가하고, 리다이렉트 패킷의 아이피 주소를 프락시나 미러링된 서버의 아이피 주소로 바꾼다 | 대역폭을 절약하고 QOS 를 개선한다 | 서버나 프락시가 클라이언트의 IP 주소를 읽어버릴 수 있다 | +|명시적인 브라우저 설정| 가까운 프락시에게 HTTP 메시지를 보내도록 설정 | 대역폭을 절약하고 QOS 를 개선 | 브라우저의 설정 능력에 의존 | +| 프락시 자동설정 | PAC 파일을 검색한다 PAC ㅍ일은 브라우저에게 각 URL에 대해 어떤 프락시를 사용해야 하는지 알려준다 | 대역폭을 절약하고 QOS 를 개선한다 부하균형 | 브라우저는 반드시 설정된 서버로 질의를 보내도록 설정 | +| 웹 프락시 자동발견 프로토콜 | PAC 파일에 대한 URL 을 물어본다. PAC만 사용할 때와는 달리 브라우저에 특징 설정 서버가 설정되어야 할 필요가 있다 | 설정 서버는 HTTP 요청 헤더에서 얻은 정보에 근거해 PAC 파일의 URL 을 결정한다| | +| 웹 캐시 조직 프로토콜 | 라우터는 패킷의 목적지 주소를 평가하고 프락시나 미러링된 서버의 아이피 주소와 함께 리다이렉트 패킷을 캡슐화한다 | 대역폭을 절약하고 QOS 를 개선한다 | 반드시 WCCP 를 지원하는 브라우저를 사용해야한다 | +| 인터넷 캐시 프로토콜 | 프락시 캐시는 형제 캐시의 무리에게 요청 받은 콘텐츠에 대해 질의할 수 있다. 캐시 계층을 지원한다 | 형제 혹은 부모 캐시로부터 콘텐츠를 얻는 것은 원 서버로 부터 얻는 것보다 빠르다 | 콘텐츠를 요청할 때 오직 URL 만을 사용하기 때문에 캐시 적중이 아님에도 적중인 것처럼 동작 할 때가 있다 | +| 캐시 배열 라우팅 프로토콜 | 프락시 캐시 해싱 프로토콜. 캐시가 요청을 부모캐시로 전달할 수 있도록 해준다 분산된 캐시들의 무리는 하나의 큰 캐시처럼 동작한다 | 현제 혹은 부모 캐시로부터 콘텐츠를 얻는게 원 서버로부터 얻는 것보다 빠르다 | CARP 는 형제 관계를 지원할 수 없다 | +| 하이퍼텍스트 캐싱 프로토콜 | 프락시 캐시는 형제 캐시의 무리에게 요청받은 콘텐츠에 대해 질의할 수 있다 | 형제 혹은 부모 캐시로부터 콘텐츠를 얻는게 원서버로부터 얻는것보다 빠르다 |