├── .gitignore ├── README.md ├── chapter_01 ├── README.md ├── chap1_고석진.md ├── chap1_고현주.md ├── chap1_김준형.md ├── chap1_이보라.md └── src_고현주 │ ├── Untitled-14689cf8-8f93-4671-b99a-3fd53f8b6f91.png │ ├── Untitled-8eaf825b-be0f-409f-acd3-805db21da132.png │ ├── Untitled-9a56ba46-0225-4903-ace2-8f5662ed4345.png │ ├── Untitled-ab2b6473-36de-411b-8e1f-6b204bbcb76d.png │ └── Untitled-fe95f6f3-8925-4dc9-881d-5190a87c993e.png ├── chapter_02 ├── README.md ├── chap2_고석진.md └── chap2_이보라.md ├── chapter_03 ├── README.md ├── chap3_고석진.md └── chap3_이보라.md ├── chapter_04 ├── README.md └── chap4_고석진.md ├── chapter_05 ├── README.md └── chap5_고석진.md ├── chapter_06 ├── README.md ├── chap6_고석진.md └── chap6_이보라.md ├── chapter_07-2 ├── README.md └── chapter_7-2_고석진.md ├── chapter_07 ├── README.md └── chap7_고석진.md ├── chapter_08 ├── README.md └── chapter_8_고석진.md ├── chapter_09 ├── README.md ├── chapter_9_2_고석진.md └── chapter_9_고석진.md ├── chapter_10 └── README.md ├── chapter_11 ├── README.md └── 고석진.md ├── chapter_12 ├── README.md └── 고석진.md ├── chapter_13 ├── README.md └── 고석진.md ├── chapter_14 ├── README.md └── chapter_14_고석진.md ├── chapter_15 ├── README.md └── 고석진.md ├── chapter_16 ├── README.md └── 고석진.md ├── chapter_17 ├── README.md └── 고석진.md ├── chapter_18 └── README.md ├── chapter_19 └── README.md ├── chapter_20 └── README.md ├── chapter_21 └── README.md └── images ├── 1-1.png ├── 1-10.png ├── 1-11.png ├── 1-12.png ├── 1-13.png ├── 1-14.png ├── 1-15.png ├── 1-2.png ├── 1-3.png ├── 1-4.png ├── 1-5.png ├── 1-6.png ├── 1-7.png ├── 1-8.png ├── 1-9.png ├── 2-1.png ├── 2-2.png ├── 2-3.png ├── 2-4.png ├── 2-5.png ├── 2-6.png ├── 3-1.png ├── 3-10.png ├── 3-11.png ├── 3-12.png ├── 3-13.png ├── 3-14.png ├── 3-15.png ├── 3-2.png ├── 3-3.png ├── 3-4.png ├── 3-5.png ├── 3-6.png ├── 3-7.png ├── 3-8.png ├── 3-9.png ├── 4-1.png ├── 4-10.png ├── 4-11.png ├── 4-12.png ├── 4-13.png ├── 4-14.png ├── 4-15.png ├── 4-16.png ├── 4-17.png ├── 4-18.png ├── 4-19.png ├── 4-2.png ├── 4-20.png ├── 4-21.png ├── 4-3.png ├── 4-4.png ├── 4-5.png ├── 4-6.png ├── 4-7.png ├── 4-8.png ├── 4-9.png ├── 5-1.png ├── 5-10.png ├── 5-11.png ├── 5-2.png ├── 5-3.png ├── 5-4.png ├── 5-5.png ├── 5-6.png ├── 5-7.png ├── 5-8.png ├── 5-9.png ├── 6-1.png ├── 6-10.png ├── 6-11.png ├── 6-12.png ├── 6-13.png ├── 6-14.png ├── 6-15.png ├── 6-16.png ├── 6-17.png ├── 6-18.png ├── 6-19.png ├── 6-2.png ├── 6-20.png ├── 6-21.png ├── 6-22.png ├── 6-23.png ├── 6-24.png ├── 6-25.png ├── 6-26.png ├── 6-3.png ├── 6-4.png ├── 6-5.png ├── 6-6.png ├── 6-7.png ├── 6-8.png └── 6-9.png /.gitignore: -------------------------------------------------------------------------------- 1 | .DS_Store 2 | 3 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # http 완벽가이드 스터디 2 | 3 | - 5장: 2019.2.3 ~ 2.24 (4주) 4 | - 4장: 2019.1.6 ~ 1.20 (3주) 5 | - 3장: 2019.11.11 ~ 12.09 (4주) 6 | - 2장: 2019.9.2 ~ 10.27 (7주) 7 | - 1장: 2019.8.1 ~ 8.26 (4주) 8 | 9 | --- 10 | 11 | ### ING 12 | 13 | - deadLine: 2020년 2월 10일 월요일 자정 14 | - todo: 19장 배포 시스템 (2.5 ~ 3) + 20장 리다이렉션과 부하 군형 (1 ~ 3) 15 | 16 | --- 17 | 18 | ## 사전 읽어보시는 글 19 | 20 | 1. 글은 해당 chapter 폴더의 README파일의 본인 이름 옆에 link해주시면됩니다. 21 | 2. 블로그로 작성하신 분들은 블로그 link, 마크다운으로 올리신 분은 마크다운 파일첨부하시고, 해당 파일 link 22 | 3. master에서 바로 작성하지 마시고, 서로 피드백을 위해서 branch 생성하여 pr로 올려주세요. (branch 이름 규칙은 아래 2번) 23 | 24 | ### 컨벤션 25 | 26 | #### 파일 관리 27 | 28 | 1. 마크다운 파일은 `chap1_김나영.md`으로 생성해주세요. 29 | 2. 아래 정리글 링크에서는 해당 글 옆에 `- 글제목`로 작성해주세요 30 | > 예: 1. 김나영 - [글 제목](https://feel5ny.github.io/2019/07/07/Joylog_003/) 31 | 3. ☀️ 마크다운으로 올려주시는 분들 중 최종본이 마크다운이실 경우, 해당 폴더 경로로 링크부탁드립니다 :) 32 | > 예: 1. 김나영 - [글제목](/chapter_2/README.md) 33 | 4. 마크다운에 포함된 asset들은 폴더를 생성해서 해당 폴더에 옮기신 후, 마크다운에 링크해주세요. 34 | > 폴더 이름은 `src_김나영` 이렇게 지어주세요. 35 | 5. 공유이미지 사용은 [아래](#shared_images)를 확인해주세요 36 | 37 | #### PR 38 | 39 | 1. PR 올리실때 브랜치 생성은 master에서 `chap1_김나영`으로 생성해주세요. 40 | - PR 생성 후에는 몇번째 챕터 관련한 pr인지 label을 붙여주세요! 41 | > 여러가지 챕터 pr이 산발적으로 올라오는 것을 정리하기위해 라벨링합니다. 42 | 2. PR 올리실때 제목은 `[bookCrush/httpPerfectGuide] chap1_김나영` 으로 생성해주세요. 43 | 44 | > 개인이 갖고 있는 다른 repo의 PR과 혼란을 막기위해 prefix를 붙입니다. 45 | 46 | 47 | 48 | ### 공유 이미지 49 | 50 | - http글과 관련된 이미지들중 공유할만한 이미지들은 `/images`에 올려주시면됩니다. 51 | > 원서 이미지도 순차적으로 업로드가 진행되고 있습니다. 52 | > 원서 이미지 업로드 컨벤션: `Figures A-B. description` --> `A-B.png` 53 | - 파일명은 chapter1관련 이미지의 경우 `1-1.jpg`형식으로 되어있습니다. 마지막 숫자의 다음숫자로 명명하여서 올려주세요. 54 | > 마지막 파일이 `1-1.jpg`라면, `1-2.jpg`로 올리기 55 | - 올려주실때는 pr로 올려주시면 바로 승인하겠습니다. 56 | > pr 제목: `[bookCrush/httpPerfectGuide] chap1_공용이미지 추가` 57 | -------------------------------------------------------------------------------- /chapter_01/README.md: -------------------------------------------------------------------------------- 1 | # [1장] HTTP:웹의 기초 / HTTP 개관 2 | 3 | ## 정리 글 링크 4 | 5 | 1. 고석진 6 | 2. 고현주 7 | 3. 구유림 - [HTTP 완벽 가이드 [1-1] - HTTP 개관](https://yurimkoo.github.io/http/2019/07/30/http-the-definitive-guide-1-1.html) 8 | 4. 김나영 - [HTTP 개관](https://feel5ny.github.io/2019/08/03/HTTP_001/) 9 | 5. 김준형 - [HTTP - 1장](https://junjangsee.github.io/2019/07/29/network/network-01/) 10 | 6. 류지환 - [1장](https://www.notion.so/jeewhan/HTTP-44ffe78ad77d4e7e94a7b3cfdc435eb6) 11 | 7. 이동규 - [HTTP 완벽가이드 스터디 #1](https://brainbackdoor.tistory.com/120) 12 | 8. 이종진 - [HTTP란?](https://jongjineee.github.io/2019/07/18/http-opening.html) 13 | 9. 이보라 - [HTTP 완벽가이드 1장](./chap1_이보라.md) 14 | 10. 이강호 15 | 11. 홍유정 - [[HTTP완벽가이드] 01. HTTP 개관](https://youjung-hong.github.io/2019-08-07/01-HTTP-%EA%B0%9C%EA%B4%80/) 16 | 12. 한재우 - [HTTP 완벽가이드 1장](https://bebiangel.github.io/2019/08/03/http-guide-chap1/) 17 | -------------------------------------------------------------------------------- /chapter_01/chap1_고석진.md: -------------------------------------------------------------------------------- 1 | # HTTP 2 | 3 | ## 1.1 HTTP 4 | 5 | HTTP 는 이미지, HTML 페이지, 텍스트 파일등을 웹서버로부터 빠르고 정확하게 웹브라우저로 옮겨준다. 신뢰성 있는 데이터 전송 프로토콜을 사용하기 때문에 전송 중 손상되거나 꼬이지 않음을 보장한다. 6 | 7 | ## 1.2 웹 클라이언트와 서버 8 | 9 | 웹 서버는 HTTP 프로토콜로 의사소통을 하기 때문에 HTTP 서버라고 불린다. 10 | 클라이언트는 서버에게 HTTP 요청을 보내고 서버는 요청된 데이터를 HTTP 응답으로 돌려준다. 11 | 12 | ## 1.3 리소스 13 | 14 | 웹 서버는 웹 리소스를 관리하고 제공한다. 이미지, 동영상, 워드파일 등등 어떠한 콘텐츠 소스도 리소스가 될 수 있따. 15 | 16 | ### 1.3.1 미디어 타입 17 | 18 | HTTP 는 웹에서 전송되는 객체 각각에 MIME 타입이라는 데이터 포맷 라벨을 붙인다. 19 | 20 | - MIME 타입은 각기 다른 전자메일 시스템 사이에서 메시지가 오갈 때 겪는 문제점을 해결하기 위해 설계되었다. HTTP 에서도 멀티미디어 콘텐츠를 기술하고 라벨을 붙이기 위해 채택되었다. 21 | 22 | 웹브라우저는 서버로부터 객체를 돌려받을 때, 다룰 수 있는 객체인지 MIME 타입을 통해 확인한다. 23 | 24 | - HTML ⇒ text/html 25 | - plain ASCII 텍스트 ⇒ text/plain 26 | - JPEG ⇒ image/jpeg 27 | - GIF ⇒ image/gif 28 | 29 | ### 1.3.2 URI 30 | 31 | 웹 서버 리소스는 각자 이름을 갖고 있기 때문에, 클라이언트는 관심 있는 리소스를 지목할 수 있다. 서버 리소스 이름은 URI 또는 통합 자원 식별자 라고 불린다. 32 | 33 | URI 는 URL 과 URN 두 가지가 있다. 34 | 35 | ### 1.3.3 URL 36 | 37 | 통합 자원 지시자는 리소스 식별자의 가장 흔한 형태다. 특정 서버의 리소스에 대한 구체적인 위치를 서술한다. 38 | 39 | - URL 의 첫 번째 부분은 스킴이라고 불린다. 사용되는 프로토콜을 서술한다. ex. http:// 40 | - 두 번째 부분은 인터넷 주소를 제공한다. ex. www.naver.com 41 | - 마지막 부분은 웹 서버의 리소스를 가리킨다. ex. /specials/index.html 42 | 43 | ### 1.3.4 URN 44 | 45 | 유니폼 리소스 (URN) 은 콘텐츠를 이루는 리소스에 대해 리소스의 위치에 영향 받지 않는 유일무이한 이름 역할을 한다. 위치 독립적인 URN 은 리소스가 옮겨지더라도 문제없이 동작한다. 46 | 47 | 아직은 실험중인 단계이다. 48 | 49 | ## 1.4 트랜잭션 50 | 51 | HTTP 트랜잭션은 요청 명령과 응답 결과로 구성되어 있다. 이 상호작용은 HTTP 메시지라고 불리는 정형화된 데이터 덩어리를 통해 이루어진다. 52 | 53 | ### 1.4.1 메서드 54 | 55 | HTTP 메서드는 여러 가지의 요청 명령을 지원한다. 모든 HTTP 요청 메시지는 한 개의 메서드를 갖는다. 56 | 57 | - GET: 클라이언트에서 지정한 리소스를 받는다 58 | - PUT: 클라이언트에서 서버로 보낸 데이터를 지정한 이름의 리소스로 저장 59 | - DELETE: 리소스를 서버에서 삭제 60 | - POST: 클라이언트 데이터를 서버 게이트웨이 애플리케이션으로 보냄 61 | - HEAD: 지정한 리소스에 대한 응답에서 HTTP 헤더 부분만 받음 62 | 63 | ### 1.4.2 상태 코드 64 | 65 | HTTP 응답 메세지는 상태 코드와 함께 반환됩니다. 66 | 67 | - 200: 정상적으로 반환 68 | - 302: 다른 곳에서 리소스를 가져가라 69 | - 404: 리소스를 찾을 수 없다. 70 | 71 | ## 1.5 메세지 72 | 73 | HTTP 메세지는 단순한 줄 단위의 문자열이다. 클라이언트에서 서버로 보낸 메세지를 요청 메세지라고 부른다. 74 | 서버에서 클라이언트로 가는 메세지를 응답 메세지라고 부른다. 75 | 76 | - 시작줄: 요청이라면 무엇을 해야하는지, 응답이라면 무슨일이 일어났는지 나타낸다. 77 | - 헤더: 이름과 하나의 값으로 구성된다. 78 | - 본문: 요청의 본문은 서버로 데이터를 실어 보내며, 응답의 본문은 클라이언트로 데이터를 반환한다. 79 | 80 | ## 1.6 TCP 커넥션 81 | 82 | TCP 커넥션을 이용하여 메세지가 옮겨진다. 83 | 84 | ### 1.6.1 TCP/IP 85 | 86 | HTTP 는 네트워크 통신의 핵심적인 세부사항에 대해서 신경 쓰지 않고 TCP/IP 프로토콜에게 맡긴다. 87 | 88 | TCP 는 다음을 제공한다. 89 | 90 | - 오류 없는 데이터 전송 91 | - 순서에 맞는 전달 92 | - 조각나지 않는 데이터 스트림 93 | 94 | ### 1.6.2 접속, IP 주소, 포트번호 95 | 96 | HTTP 클라이언트가 서버에 메세지를 전송할 수 있게 되기 전에, 인터넷 프로토콜 주소와 포트번호를 사용해 클라이언트와 서버 사이에 TCP/IP 커넥션을 맺어야한다. 97 | 98 | ## 1.8 웹의 구성요소 99 | 100 | - 프락시: 클라이언트와 서버 사이에 위치한 HTTP 중개자 101 | - 캐시: 많이 찾는 웹페이지를 클라이언트 가까이에 보관하는 HTTP 창고 102 | - 게이트웨이: 다른 애플리케이션과 연결된 특별한 웹 서버 103 | - 터널: 단순 HTTP 통신을 전달하기만 하는 특별한 프락시 104 | - 에이전트: 자동화된 HTTP 요청을 만드는 준지능적 웹클라이언트 105 | 106 | ### 1.8.1 프락시 107 | 108 | HTTP 프락시 서버는 보안, 어플리케이션 통합, 성능 최적화를 위한 중요한 구성요소이다. 109 | 클라이언트와 서버 사이에 위치하여, 클라이언트의 모든 HTTP 요청을 받아 서버에 전달한다. 110 | 111 | - 프락시는 주로 `보안`을 위해 사용된다 112 | - 요청과 응답을 필터링한다. 113 | 114 | ### 1.8.2 캐시 115 | 116 | 웹 캐시와 캐시 프락시는 자주 찾는 것의 사본을 저장해 두는 특별한 종류의 HTTP 프락시 서버다. 117 | 클라이언트는 멀리 떨어진 웹 서버보다 근처의 캐시에서 훨 씬 더 빨리 문서를 다운 받을 수 있다. 118 | 119 | ### 1.8.3 게이트웨이 120 | 121 | 게이트웨이는 다른 서버들의 중개자로 동작하는 특별한 서버이다. 122 | 주로 HTTP 트래픽을 다른 프로토콜로 변환하기 위해 사용한다. 123 | 124 | ### 1.8.4 터널 125 | 126 | 두 커넥션 사이에서 raw 데이터를 열어보지 않고 그대로 전달해주는 HTTP 어플리케이션이다. 127 | 주로 비 HTTP 데이터를 하나 이상의 HTTP 연결을 통해 그대로 전송해주기 위해 사용한다. 128 | 129 | ### 1.8.5 에이전트 130 | 131 | 사용자 에이전트는 사용자를 위해 HTTP 요청을 만들어주는 클라이언트 프로그램이다. 132 | 133 | -------------------------------------------------------------------------------- /chapter_01/chap1_고현주.md: -------------------------------------------------------------------------------- 1 | # I.HTTP: 웹의 기초_01.HTTP 개관 2 | 3 | 들어가기 전에, 이 글은 `HTTP 완벽 가이드` 책을 읽고 이해한 내용을 정리한 글입니다. 4 | 5 | # 1장 HTTP 개관 6 | 7 | 이 챕터에서는 다음 항목들에 대해 정리합니다. 8 | 9 | - 얼마나 많은 클라이언트와 서버가 통신하는지 10 | - 리소스가 어디서 오는지 11 | - 웹 트랜잭션이 어떻게 동작하는지 12 | - HTTP 통신을 위해 사용하는 메세지의 형식 13 | - HTTP 기저의 TCP 네트워크 전송 14 | - 여러 종류의 HTTP 프로토콜 15 | - 인터넷 곳곳에 설치된 다양한 HTTP 구성요소 16 | 17 | ## HTTP 18 | 19 | HTTP는 이미지, HTML 문서, 텍스트, 동영상 등을 웹 브라우저로 옮겨줍니다. HTTP는 데이터 전송 프로토콜을 사용하는데, 이 프로토콜은 신뢰성이 높기 때문에 사용자는 HTTP를 통해 받은 정보들이 전송 중에 파괴되거나 중복되거나 변조될 것을 걱정하지 않아도 됩니다. 20 | 21 | ## 클라이언트와 서버 22 | 23 | 위에서 이야기한 이미지, HTML 문서, 텍스트, 동영상 등의 리소스들은 웹 서버에 있습니다. 웹 서버(이하 HTTP 서버)는 HTTP 클라이언트가 보낸 데이터를 저장하고, HTTP 클라이언트가 요청한 데이터를 제공해줍니다. 24 | 25 | 웹 브라우저(HTTP 클라이언트)가 서버에 HTTP 객체를 요청하면 서버가 보내준 리소스를 웹 브라우저가 처리해줍니다. 예를 들어, 크롬에서 [http://theeeeeng.github.com](https://theeeeeng.github.com) 링크로 접근하면, 크롬은 [http://theeeeeng.github.com](https://theeeeeng.githumb.com) 서버로 HTTP 요청을 보냅니다. 요청받은 서버는 요청받은 객체를 찾고, 성공했다면 요청받은 객체의 타입, 길이 등의 정보와 함께 HTTP 응답에 실어서 클라이언트로 전송합니다. 26 | 27 | ## 리소스 28 | 29 | 웹 서버는 리소스를 관리하고 제공합니다. 웹 리소스의 예시로는 HTML, 이미지, 동영상 등이 있는데, 반드시 정적 파일일 필요는 없습니다. 동적 리소스는 사용자가 누구인지, 어떤 정보를 보여줄지 에 따라 리소스에 다른 내용들을 포함할 수 있습니다. 30 | 31 | > MIME 타입 32 | 33 | 웹 서버는 모든 HTTP 객체 데이터에 MIME 타입을 붙입니다. 브라우저는 서버로부터 객체를 돌려받을 때, 다룰 수 있는 객체인지 MIME 타입을 통해 확인할 수 있는데, 대부분의 브라우저는 보편적인 타입 수백 가지를 다룰 수 있다고 합니다. 34 | 35 | MIME 타입은 `주 타입`/`부 타입` 으로 이루어진 문자열 라벨입니다. 예를 들면, 36 | 37 | - text/html 38 | - text/plain 39 | - image/jpeg 40 | - image/gif 41 | 42 | 이런 형태의 MIME 타입 외에도 다양한 형태가 있습니다. 43 | 44 | > URI, URL, URN 45 | 46 | 웹 서버 리소스는 각자 이름을 갖고 있기 때문에, 클라이언트는 원하는 리소스를 지목할 수 있습니다. 서버 리소스 이름은 URI로 불리는데, 정보 리소스를 고유하게 식별하고 위치를 지정할 수 있습니다. 47 | 48 | 예를 들어 [https://github.githubassets.com/images/icons/emoji/octocat.png](https://github.githubassets.com/images/icons/emoji/octocat.png) 는 [https://github.githubassets.com](https://github.githubassets.com/images/icons/emoji/octocat.png) 서버에 있는 이미지 리소스에 대한 URI 입니다. 49 | 50 | URI에는 URL(uniform resource locator), URN(uniform resource name) 두 가지 종류가 있습니다. 51 | 52 | **URL**은 리소스 식별자의 가장 흔한 형태로 특정 서버의 리소스에 대한 구체적인 위치를 서술하며, 대부분의 URL은 세가지로 구성됩니다. 53 | 54 | - `스킴(scheme)` 리소스에 접근하기 위해 사용되는 프로토콜을 서술합니다. ex)https:// 55 | - `서버의 인터넷 주소` ex)[github.githubassets.com](https://github.githubassets.com/images/icons/emoji/octocat.png) 56 | - `웹 서버의 리소스` ex)[/images/icons/emoji/octocat.png](https://github.githubassets.com/images/icons/emoji/octocat.png) 57 | 58 | **URN**은 컨텐츠를 이루는 리소스에 대해, 그 리소스의 위치에 영향받지 않는 유일무이한 이름 역할을 합니다. 예를 들어 `urn:ietf:rfc:2141` 이라는 URN은 인터넷 표준문서 'RFC 2141' 가 어디에 있거나 상관없이 그것을 지칭하기 위해 사용할 수 있습니다. 59 | 60 | ## HTTP 트랜잭션 61 | 62 | HTTP 트랜잭션은 요청 명령과 응답 메세지로 구성되어 있습니다. 63 | 64 | > HTTP Method 65 | 66 | HTTP는 여러가지 종류의 요청 명령을 지원하는데, 이 명령들을 HTTP Method라고 합니다. 각각의 HTTP 요청 메세지는 한 개의 Method를 갖는데, 이 메소드를 통해 어떤 동작이 취해져야 하는지를 서버에게 요청할 수 있습니다. 예를 들면, 67 | 68 | - `GET` 서버에서 클라이언트로 지정한 리소스를 보내라 69 | - `PUT` 클라이언트에서 서버로 보낸 데이터를 지정한 이름의 리소스로 저장하라 70 | - `DELETE` 지정한 리소스를 서버에서 삭제하라. 71 | - `POST` 클라이언트 데이터를 서버 게이트웨이 어플리케이션으로 보내라. 72 | - `HEAD` 지정한 리소스에 대한 응답에서, HTTP 헤더 부분만 보내라. 73 | 74 | > Status Code 75 | 76 | 모든 HTTP 응답 메세지는 상태 코드와 함께 반환됩니다. 서버는 이 상태 코드를 통해 클라이언트에게 요청이 성공했는지 아니면 다른 조치가 필요한지 알려줍니다. 77 | 78 | 예를 들면, 79 | 80 | - `200` 성공적으로 요청되었습니다. 81 | - `404` 해당 리소스를 찾을 수 없습니다. 82 | 83 | 상태 코드를 보낼 때는 사유 구절도 함께 보낼 수 있는데, 설명을 위해서 포함된 것이기 때문에 실제로 응답을 처리할 때는 코드만 사용됩니다. `[코드] [사유 구절]` 형태로 나타나는데 예를 들면, 84 | 85 | - 200 OK 86 | - 200 Document attached 87 | - 200 Success 88 | 89 | 위와 같은 형태로 사유구절을 보낼 수가 있습니다. 90 | 91 | > 메시지 92 | 93 | HTTP 메시지는 단순한 문자열의 일반 텍스트입니다. 웹 클라이언트에서 웹 서버로 보낸 HTTP 메시지를 **요청 메시지**, 서버에서 클라이언트로 보낸 메시지를 **응답 메시지**라고 합니다. 94 | 95 | HTTP 요청/응답 메시지의 형식은 비슷합니다. 96 | 97 | 요청/응답 메세지는 `시작줄/헤더/본문`으로 구성되어 있습니다. 98 | 99 | [https://github.com/theeeeeng](https://github.com/theeeeeng) 서버로 요청한 내용과 응답 내용을 예시로 설명하겠습니다. 100 | 101 | ### 시작줄 102 | 103 | 요청 일 때는 무엇을 해야 하는지, 응답 일 때는 무슨 일이 일어났는지 나타냅니다. 104 | 105 | - 요청 시작줄 106 | 107 | ![](Untitled-14689cf8-8f93-4671-b99a-3fd53f8b6f91.png) 108 | 109 | - 응답 시작줄 110 | 111 | ![](Untitled-9a56ba46-0225-4903-ace2-8f5662ed4345.png) 112 | 113 | ### 헤더(Header) 114 | 115 | 여러 개의 필드로 구성되며 요청 또는 응답의 상세 설명을 나타낼 수 있습니다. 116 | 117 | - 요청 헤더 118 | 119 | ![](Untitled-8eaf825b-be0f-409f-acd3-805db21da132.png) 120 | 121 | - 응답 헤더 122 | 123 | ![](Untitled-fe95f6f3-8925-4dc9-881d-5190a87c993e.png) 124 | 125 | ### 본문 126 | 127 | 필요에 따라 어떤 종류의 데이터든 들어갈 수 있습니다. 요청 일 때는 웹 서버로 데이터를 보내는 역할을 하고, 응답 일 때는 클라이언트로 데이터를 반환하기도 합니다. 128 | 129 | - 요청 본문 130 | 131 | 해당 요청에서는 없음 132 | 133 | - 응답 본문 134 | 135 | ![](Untitled-ab2b6473-36de-411b-8e1f-6b204bbcb76d.png) 136 | 137 | ## TCP 커넥션 138 | 139 | > TCP/IP 140 | 141 | HTTP는 어플리케이션 계층 프로토콜입니다. HTTP는 네트워크 통신의 핵심적인 세부사항에 대해 신경 쓰지 않는 대신, 대중적이고 신뢰성 있는 인터넷 전송 프로토콜인 TCP/IP 에게 맡깁니다. 142 | 143 | TCP는 다음을 제공합니다. 144 | 145 | - 오류 없는 데이터 전송 146 | - 순서에 맞는 전달(데이터는 언제나 보낸 순서대로 도착한다) 147 | - 조각나지 않는 데이터 스트림(언제든 어떤 크기로든 보낼 수 있다) 148 | 149 | TCP/IP 는 TCP와 IP가 층을 이루는 패킷 교환 네트워크 프로토콜의 집합입니다. TCP/IP는 각 네트워크와 하드웨어의 특성을 숨기고, 어떤 종류의 컴퓨터나 네트워크든 신뢰성 있는 의사소통을 하게 합니다. 150 | 151 | TCP 커넥션이 맺어지면, 클라이언트와 서버 간에 교환되는 메세지가 없어지거나 손상되거나 순서가 뒤바뀌어 수신되는 일은 결코 없습니다. 152 | 153 | 네트워크 개념상, HTTP 프로토콜은 TCP 위의 계층으로 HTTP는 자신의 메세지 데이터를 전송하기 위해 TCP를 사용합니다. 마찬가지로, TCP는 IP 위의 계층입니다. 154 | 155 | > 접속, IP 주소와 포트번호 156 | 157 | HTTP 클라이언트가 서버에 메세지를 전송하기 전에, IP 와 포트번호를 사용해 클라이언트와 서버 사이에 TCP/IP 커넥션을 맺어야합니다. 158 | 159 | [http://0.0.0.0:8080/index.html](http://0.0.0.0:8080/index.html) URL 에서 **IP는 0.0.0.0** 이고, **포트번호는 80**입니다. 160 | 161 | 우리가 접속하는 대부분의 URL에는 숫자로 된 IP 주소가 없는데, 이는 IP 주소에 대한 이해하기 쉬운 형태인 호스트 명(도메인)을 사용하기 때문입니다. 162 | 163 | 또한, 포트번호가 별도로 보이지 않는데, **기본값이 80**으로 별도의 포트번호가 없다면 80번 포트를 사용하는 것입니다. 164 | 165 | 웹 브라우저는 다음과 같은 순서로 HTTP를 이용해서 서버의 HTML 리소스를 사용자에게 보여줍니다. 166 | 167 | 1. 브라우저는 서버의 URL에서 호스트 명을 추출합니다. 168 | 2. 브라우저는 서버의 호스트 명을 IP로 변환합니다. 169 | 3. 브라우저는 URL에서 포트번호를 추출합니다. 170 | 4. 브라우저는 서버와 TCP 커넥션을 맺습니다. 171 | 5. 브라우저는 서버에 HTTP 요청을 보냅니다. 172 | 6. 서버는 브라우저에 HTTP 응답을 돌려줍니다. 173 | 7. 커넥션이 닫히면, 브라우저는 문서를 보여줍니다. 174 | 175 | ## 프로토콜 버전 176 | 177 | HTTP 프로토콜은 여러가지 버전이 있습니다. 178 | 179 | - HTTP/0.9 180 | 181 | 원래 간단한 HTML 객체를 받아오기 위해 만들어졌으며 오직 GET 메소드만 지원하고, 멀티미디어 컨텐츠에 대한 MIME 타입이나, HTTP 헤더, 버전 번호는 지원하지 않았습니다. 182 | 183 | - HTTP/1.0 184 | 185 | 처음으로 널리 쓰이기 시작한 버전이며 버전 번호, HTTP 헤더, 추가 메서드, 멀티미디어 객체 처리를 추가했습니다. 시각적인 면이 많은 웹 페이지와 상호작용하는 폼을 실현했고, www 를 대세로 만들었다고 합니다. 186 | 187 | - HTTP/1.0+ 188 | 189 | 오래 지속되는 **keep-alive** 커넥션, 가상 호스팅 지원, 프락시 연결 지원 등의 많은 기능이 추가되었습니다. 190 | 191 | - HTTP/1.1 192 | 193 | 현재의 HTTP 버전으로 성능 최적화, HTTP 설계의 구조적 결함 보완, 잘못된 기능 제거에 집중했습니다. 194 | 195 | - HTTP/2.0 196 | 197 | HTTP/1.1의 성능 문제를 개선하기 위해 만들어졋으며 설계가 진행 중인 프로토콜입니다. 198 | 199 | ## 웹의 구성요소 200 | 201 | > 프락시 202 | 203 | 프락시는 클라이언트와 서버 사이에 위치하며, 클라이언트의 HTTP 요청을 받아서 필요에 따라 요청을 수정한 뒤, 서버에 전달합니다. 프락시는 주로 보안을 위해 사용되는데, 요청과 응답을 필터링 하는 등 웹 트래픽 흐름 중 신뢰할 만한 흐름을 전달합니다. 204 | 205 | > 캐시 206 | 207 | 웹 캐시와 캐시 프락시는 HTTP 프락시 서버의 한 종류로, 자주 찾는 문사들의 사본을 저장해둡니다. 때문에, 클라이언트가 같은 문서를 요청하면 캐시가 갖고 있는 사본을 받을 수 있기 때문에 훨씬 더 빨리 문서를 다운 받을 수 있습니다. HTTP는 캐시를 효율적으로 동작하게 하고, 캐시된 콘텐츠를 최신 버전으로 유지하면서 프라이빗한 정보를 보호하기 위해 많은 기능을 정의합니다. 208 | 209 | > 게이트웨이 210 | 211 | 게이트웨이는 주로 HTTP 트래픽을 다른 프로토콜로 변환하기 위해 사용됩니다. 게이트웨이는 언제나 스스로가 리소스를 갖고있는 진짜 서버인 것처럼 요청을 다루기 때문에 클라이언트는 자신이 게이트웨이와 통신하고 있는지 진짜 서버와 통신하고 있는지 알지 못합니다. 212 | 213 | > 터널 214 | 215 | 터널은 두 커넥션 사이에서 raw 데이터를 열어보지 않고 그대로 전달해주는 HTTP 어플리케이션입니다. HTTP 터널은 주로 비 HTTP 데이터를 하나 이상의 HTTP연결을 통해 그대로 전송해주기 위해 사용됩니다. 216 | 217 | 예를 들어, 암호화된 SSL 트래픽을 HTTP 커넥션으로 전송함으로써 웹 트래픽만 허용하는 사내 방화벽을 통과시키는 터널이 있습니다. HTTP/SSL 터널은 HTTP 요청을 받아들여 목적지의 주소와 포트번호로 커넥션을 맺어서 이후부터는 암호화된 SSL 트래픽을 HTTP 채널을 통해 목적지 서버로 전송할 수 있게 됩니다. 218 | 219 | > 에이전트 220 | 221 | 사용자를 위해 HTTP 요청을 만들어주는 클라이언트 프로그램으로, 예를 들어 검색 봇과 같이 사람의 통제 없이 스스로 웹을 돌아다니며 HTTP 트랜잭션을 일으켜서 콘텐츠를 받아오기도 합니다. 222 | -------------------------------------------------------------------------------- /chapter_01/chap1_김준형.md: -------------------------------------------------------------------------------- 1 | # HTTP 2 | `HTTP(Hypertext Transfer Protocol)`은 `WWW(World Wide Web)`에서 통신하는데 사용하는 프로토콜 프로그램입니다. 3 | 즉, 전 세계의 웹 브라우저, 서버, 웹 애플리케이션은 **모두** `HTTP`를 통해서 대화를 하게 되어있습니다.
4 | 현재 셀 수 없이 많은 이미지, HTML 페이지, 텍스트 파일, 동영상 등 쉴틈없이 인터넷에서 움직이고 있습니다. 5 | 이런 상황에서 HTTP는 전 세계에 이 정보들을 **빠르고, 간편하고, 정확하게** 각 PC의 브라우저로 옮겨줄 수 있습니다.
6 | 정말 신기하기도 하고 의아한 점은 이러한 많은 정보들을 전송 중 **꼬이거나 손상되지 않는다**는 점입니다. 7 | 그렇기 떄문에 개발자 입장에서는 HTTP를 사용함으로써 전송에러를 걱정하지 않고 개발을 할 수 있다는 것입니다.! 👍👍
8 | 그러면 이렇게 좋은 HTTP는 어떻게 웹 트래픽을 전송하는지 알아보도록 하겠습니다.
9 |
10 | 11 | # 웹 클라이언트와 서버 12 | 웹 컨텐츠들이 존재하는 `웹 서버`는 HTTP로 의사소통 하기 때문에 `HTTP 서버`라고 불립니다. 13 | HTTP `서버`는 데이터들을 저장하고 있다가 HTTP `클라이언트` 측에서 요청하면 그에 맞는 데이터를 보내게 됩니다. 14 | > HTTP 클라이언트(웹 브라우저) : "야 네이버! default file(ex. index.html) 페이지 내놔!!!" 15 | 요청 대상 - www.naver.com
16 | HTTP 서버(Naver 서버) : "드..드리겠습니다.. 여기 HTTP 포맷, 300자로 이루어진 문서입니다.." 17 | 요청 결과 - www.naver.com/index.html 18 | 19 | 위 예시가 WWW의 기본 구성 요소입니다. 20 | 현재 Chrome, Explorer 등 많은 `브라우저들`을 사용중일텐데 이 것이 바로 `HTTP 클라이언트`입니다.
21 |
22 | 23 | # 리소스 24 | 웹 서버는 웹 리소스를 관리하고 제공하는 역할을 합니다. 여기서 `웹 리소스`는 웹 컨텐츠의 원천입니다. 즉 원조의 역할을 합니다. 😀 25 | 웹 리소스는 가장 단순하게는 웹 서버 파일 시스템의 `정적 파일`입니다. 26 | > 정적 파일 : 텍스트, HTML, 워드, JPEG 이미지 등의 파일을 포함합니다. 27 | 28 | 하지만 웹 리소스가 꼭 정적 파일일 필요는 없습니다. 때로는 요청에 따라 컨텐츠를 생산하는 프로그램이 될 수도 있는데 사용자가 누구인지에 따라, 어떤 정보를 요청했으며, 언제 요청했는지 까지 파악하여 다른 컨텐츠를 생성하기도 합니다.
29 | 즉 `리소스`는 정적, 동적, 게이트웨이 등 **모든 종류의 컨텐츠**를 포함하는 것입니다.
30 |
31 | 32 | ## 미디어 타입 33 | 인터넷은 엄청 많은 데이터를 가지고 있어 웹에서 전송된 객체 각각에 `MIME` 타입이라는 데이터 포멧 라벨을 붙이게 됩니다. 여기서 MIME이란 무엇인지 알아볼까요? 34 | MIME(Multipurpose Internet Main Extensions)은 다목적 인터넷 메일 확장 이라는 뜻을 가지고 있으며, 다른 전자메일 사이에서 오가는 문제를 해결하기 위해 설계되었습니다. 35 | 이 방식을 `HTTP`에서도 채택하여 `멀티미디어 콘텐츠`를 기술하고 `라벨`을 붙이기 위해 채택하게 되었습니다.
36 | **웹 브라우저**는 **서버**에서 객체를 받을 때 MIME 타입을 붙여서 받게 됩니다. 표현 방식은 `주 타입 / 부 타입`으로 나누어져 있습니다. 37 | 설명만 들으면 잘 이해가 안될 수도 있으니 구체적인 예를 보겠습니다‼
38 | * HTML : text/html 39 | * plain ASCII : text/plain 40 | * JPEG : image/jpeg 41 | * GIF : image/gif 42 | 43 | 위처럼 각 멀티미디어 콘텐츠에 MIME 타입을 붙여 **웹-서버간** 객체를 주고 받게 됩니다.
44 |
45 | 46 | ## URI 47 | 웹 서버 리소스는 각자의 이름을 가지고 있어 클라이언트는 관심있는 리소스를 지목할 수 있습니다. 48 | **서버 리소스** 이름은 `통합 자원 식별자` 혹은 `URI`로 불립니다. URI는 우편주소와 같은 개념으로 고유하게 식별하고 위치를 지정할 수 있습니다. 49 | 예를들어 junjang의 블로그의 네트워크에 관련된 글에 대한 리소스의 URI 형식은 아래와 같습니다. 50 |
51 | 52 | > https://junjangsee.github.io/2019/07/29/network/network-01/ 53 | 54 | URI에는 두 가지가 있는데 `URL, URN`입니다. 이 두가지에 대해 살펴보겠습니다.
55 |
56 | 57 | ### URL 58 | URL(통합 자원 지시자)는 리소스 식별자의 가장 **흔한** 형태입니다. URL은 특정 서버의 리소스에 대한 구체적인 위치를 서술하고 있어 정확한 접근을 할 수 있도록 해줍니다. 59 | 여러가지 예시를 통해 URL의 구체적인 위치를 알아보겠습니다. 60 |
61 | 62 | > http://www.naver.com/index.html - naver홈페이지의 URL 63 | > http://www.ROKA.com/datepick?date=190804 - 국방부 홈페이지에서 190804에 입영하는 URL 64 | 65 | 위 처럼 이런 표준 포멧을 따르고 있습니다. 66 | - URL의 첫 부분은 **스킴(scheme)**인데, 여기선 리소스에 접근하기 위한 프로토콜을 서술합니다.(보통은 http://를 사용합니다.) 67 | - 두 번째 부분은 **인터넷 주소**를 서술합니다.(www.naver.com) 68 | - 마지막 부분은 **리소스**를 가르킵니다.(/hoguk/hoguki.gif) 69 | 70 |
71 | 72 | ### URN 73 | URN(유니폼 리소스 이름)은 하나의 리소스에 대해 그 리소스의 **위치에 영향을 받지 않는** `유일무이한 역할`을 합니다. 74 | 그래서 독립적인 URN은 어디로 옮기더라도 이상없이 동작합니다. 즉, `이름`만 동일하게 유지한다면 여러종류의 프로토콜로 접속해도 이상 없습니다. 75 | URN은 현재 아직 실험 중인 상태이고 효율적으로 사용하기 위해선 인프라의 도움이 필요한데 그런 인프라의 부재로 현재 더뎌지고 있는 상태입니다. 76 | 때문에 현재로서는 URL과 URI를 같은 의미로서 사용할 것입니다.
77 |
78 | 79 | # 트랜잭션 80 | `HTTP 트랜잭션`은 클라이언트와 웹 서버가 리소스를 주고받기 위해서 `요청명렁(클라이언트 -> 서버)`과 `응답 결과(서버 -> 클라이언트)`로 구성되어 있습니다. 이 상호작용이 어떻게 이루어지는지 알아보겠습니다.
81 |
82 | 83 | ## 메소드 84 | HTTP는 `HTTP 메소드`라고 불리는 여러가지의 요청 메소드를 지원합니다. 모든 HTTP 요청 메시지는 하나의 HTTP 메소드를 가집니다. 이 메소드는 서버가 어떤 동작을 취해야하는지 알려주는 역할을 합니다.(군대에서 일과시작 전 일과분류 받는 느낌입니다... 메소드 - 소대장, 서버 - 용사들) 85 | 가장 흔히 사용되는 5가지의 종류를 살펴보겠습니다.
86 | 87 | * GET : 서버에서 클라이언트로 지정한 리소스를 보냅니다. 88 | * PUT : 클라이언트에서 서버로 보낸 데이터를 지정한 이름의 리소스로 저장합니다. 89 | * DELETE : 지정한 리소스를 서버에서 삭제합니다. 90 | * POST : 클라이언트 데이터를 서버 게이트웨이 애플리케이션으로 보냅니다. 91 | * HEAD : 지정한 리소스에 대한 응답에서, HTTP 헤더 부분만 보냅니다. 92 | 93 |
94 | 95 | ## 상태 코드 96 | HTTP의 응답에 대해서는 무조건 `상태 코드`를 함께 반환하게 되어있습니다. 개발을 하다보면 흔히 보는 **200, 404** 등이 상태 코드에 해당됩니다.
97 |
98 | 99 | ## 웹페이지는 여러 객체로 이루어질 수 있다. 100 | 애플리케이션은 하나의 작업을 수행하기 위해 여러 HTTP 트랜잭션을 수행합니다. 예를 들어, 하나의 웹페이지를 띄울 때 첨부된 이미지, HTML의 뼈대, 자바 애플릿 등을 가져오기 위해 추가로 HTTP 트랜잭션을 수행합니다. 이처럼 하나의 웹페이지는 **여러가지의 리소스**로 구성됩니다.
101 |
102 | 103 | # 메시지 104 | HTTP 메시지는 두 종류로 이루어져 있습니다. 웹 클라이언트에서 서버로 보내는 `요청 메시지`, 서버에서 웹 클라이언트로 가는 `응답 메시지` 외에 HTTP 메시지는 없습니다. 105 | 이런 메시지에는 세 부분으로 이루어집니다. 106 | * 시작줄 : 요청에서는 무엇을, 응답이라면 무슨 일이 일어났는지 나타냅니다. 107 | * 헤더 : 0개 이상으로, 쌍점(:)으로 표현되며 **이름: 값** 으로 구성됩니다. 그리고 빈 줄로 끝납니다. 108 | * 본문 : 요청의 본문은 웹 서버로 데이터를 **보내며**, 응답의 본문은 클라이언트로 데이터를 **반환**합니다. 109 | 110 |
111 | 112 | # TCP 커넥션 113 | 이제 TCP(전송 제어 프로토콜) 커넥션을 통해 한 곳에서 다른 곳으로 옮겨가지는 알아보겠습니다.
114 |
115 | 116 | ## TCP/IP 117 | HTTP는 애플리케이션 계층 프로토콜이며 네트워크의 세부적인 사항에 대해서는 일절 관여하지 않습니다. 대신 **대중성, 신뢰성** 두 가지를 담당하는 **인터넷 전송 프로토콜** `TCP/IP`에게 맡깁니다. TCP/IP는 아래의 3가지를 제공합니다. 118 | * 오류 없는 데이터 전송 119 | * 순서에 맞는 전달(보낸 순서대로 전달) 120 | * 조각나지 않는 데이터 스트림 121 | 122 | TCP/IP는 TCP, IP가 층을 이루는 패킷 교환 네트워크 프로토콜의 집합입니다. 각 하드웨어의 특성을 숨기고, 어떤 종류의 컴퓨터나 네트워크든 모두 신뢰성 있게 의사소통 하도록 해줍니다. HTTP는 메시지를 전송하기 위해 TCP를 사용합니다. 이와 비슷하게 TCP는 IP의 위의 계층입니다.
123 | 124 | > HTTP > TCP > IP 125 | 126 |
127 | 128 | ## 접속, IP 주소, 포트 번호 129 | 먼저 HTTP 클라이언트가 서버에 메시지를 전송할 수 있도록 **인터넷 프로토콜(IP) 주소**와 **포트번호**를 사용해 클라이언트와 서버 사이에 TCP/IP 커넥션을 맺어주어야 합니다. 130 | TCP는 포트번호를 필요로 합니다. 131 | 그런데 이런 정보를 도대체 어디서 가져와야 할까요? 일일이 알아내서 입력해주어야 할까요? 🤔
132 | 133 | 바로 URL에서 가져올 수 있습니다. 바로 예시를 보겠습니다. 134 | * http://207.200.83.29:80/index.html : IP와 포트번호를 가진 경우 135 | * http://www.netscape.com:80/index.html : 호스트명(도메인)과 포트번호를 가진 경우 136 | * http://www.netscape.com/index.html : 둘 다 없는 경우 - 기본 포트번호는 80으로 세팅됩니다. 137 | 138 | 이런 URL을 가지고 TCP/IP 커넥션을 하여 쉽게 통신할 수 있습니다. 그렇다면 클라이언트와 서버간의 통신을 어떤 **순서**를 통해 하는지 살펴보겠습니다. 139 | 140 | 1. 웹브라우저는 서버의 URL에서 호스트명을 추출합니다. 141 | 2. 웹브라우저는 서버의 호스트명을 IP로 변환합니다. 142 | 3. 웹브라우저는 URL에서 포트번호를 추출합니다. 143 | 4. 웹브라우저는 웹 서버와 TCP 커넥션을 맺습니다. 144 | 5. 웹브라우저는 서버에 HTTP 요청을 보냅니다. 145 | 6. 서버는 웹 브라우저에 HTTP 응답을 반환홥니다. 146 | 7. 커넥션이 닫히면, 웹브라우저는 문서를 보여줍니다. 147 | 148 | 위와 같이 일련의 순서를 통해 HTML 리소스를 최종적으로 보여줍니다.
149 |
150 | 151 | # 프로토콜 버전 152 | 오늘날 사용하는 HTTP 프로토콜의 버전에는 여러가지가 있습니다. 하나하나 살펴보겠습니다. 153 | * HTTP/0.9 : 심각한 디자인 결함으로 GET 메소드만 지원했으며 MIME 타입, HTTP 헤더, 버전 번호를 지원하지 않았고 금방 1.0으로 대체되었습니다. 154 | * HTTP/1.0 : 널리 사용하기 시작한 버전으로 HTTP 헤더, MIME 타입, 추가 메소드, MIME 타입을 추가했습니다. 155 | * HTTP/1.0+ : 1990년 인터넷이 급성장 하면서 'Keep-alive' 커넥션, 가상 호스팅, 프록시 연결 등 많은 기능을 추가하였습니다. 156 | * HTTP/1.1 : HTTP 설계의 구조적 결함 교정, 성능 최적화, 잘못된 기능 제거를 하였고 더 복잡한 웹 애플리케이션과 배포를 지원합니다. 현재의 HTTP 버전입니다. 157 | * HTTP/2.0 : 1.1의 성능 문제를 개선하기 위해 구글의 SPDY 프로토콜을 기반으로 설계가 진행중인 프로토콜입니다. 158 | 159 |
160 | 161 | # 웹의 구성요소 162 | 이 주제에서는 프록시, 캐시, 게이트웨이, 터널, 에이전트에 대해 살펴보겠습니다.
163 |
164 | 165 | ## 프록시 166 | `웹 보안, 애플리케이션 통합, 성능 최적화`의 중요한 역할을 수행합니다. 167 | 서버와 서버 **사이**에 위치하며 클라이언트의 모든 HTTP 요청을 받아 서버에 전달합니다. 이는 사용자를 대신해서 서버에 접근하는 의미로 주로 **보안**을 위해 사용됩니다. 168 | 즉, 모든 웹 트래픽 흐름 속에서 신뢰할 만한 **중개자** 역할을 합니다. 또한 `필터링` 역할을 수행하며 원하는 리소스만 받아낼 수도 있습니다.
169 |
170 | 171 | ## 캐시 172 | 캐시는 자신을 거쳐 가는 문서들 중 자주 찾는 것의 사본을 저장해둡니다. 그래서 클라이언트가 해당 문서를 요청하면 그 캐시가 가지고 있는 문서를 가져올 수 있습니다. 173 | 캐시에 저장해둔 문서는 클라이언트와 가깝게 위치하고 있어 멀리 떨어진 웹 서버보다 훨씬 빠르게 문서를 전달할 수 있습니다.
174 |
175 | 176 | ## 게이트웨이 177 | 다른 서버를 중개하는 역할을 하는 특별한 서버로 주로 HTTP 트래픽을 다른 프로토콜로 변환하기 위해 사용됩니다. 자기 자신이 언제나 리소스를 가지고 있는 진짜 서버인 것처럼 요청을 다룹니다. 178 | 그래서 클라이언트는 자신이 게이트웨이와 통신하고 있음을 알아채지 못하게 됩니다.
179 |
180 | 181 | ## 터널 182 | 터널은 두 커넥션 사이에서 날(raw) 데이터를 열어보지 않고 그대로 전달해주는 HTTP 애플리케이션입니다. HTTP 터널은 주로 비 HTTP 데이터를 하나 이상의 HTTP 연결을 통해 그대로 전송해주기 위해 사용됩니다. 183 | 대표적으로 **암호화된 SSL 트래픽**을 **HTTP 커넥션으로 전송함**으로써 웹 트래픽만 허용하는 사내 방화벽을 통과시키는 것이 있습니다.
184 |
185 | 186 | ## 에이전트 187 | 에이전트는 사용자를 위해 HTTP 요청을 만들어주는 클라이언트 프로그램입니다.
188 |
-------------------------------------------------------------------------------- /chapter_01/chap1_이보라.md: -------------------------------------------------------------------------------- 1 | # HTTP 개관 2 | 목표: HTTP 빠르게 훑어보기 3 | 4 | ## 1.1 HTTP: 인터넷의 멀티미디어 배달부 5 | - HTTP: 신뢰성 있는 데이터 전송 프로토콜로, `배달부` 역할을 함 6 | - 출발지: 웹 서버 (== HTTP 서버) 7 | - 목적지: 웹 브라우저 8 | - 배달하는 것: 웹 콘텐츠(이미지, HTML 페이지, 텍스트 파일, 동영상, 음성파일, 자바 애플릿 등) 9 | 10 | 11 | ## 1.2 웹 클라이언트와 서버 12 | 13 | ![](../images/1-2.png) 14 | 15 | [그림 1-1 웹 클라이언트와 웹 서버] 16 | 17 | 웹브라우저가 서버에게 HTTP 객체를 요청하고, 서버는 요청받은 객체를 찾고, 성공했다면 그것의 타입, 길이 등의 정보와 함께 HTTP 응답에 실어 클라이언트에게 보냄 18 | 19 | ## 1.3 리소스 20 | - 웹 리소스란: 웹에 콘텐츠를 제공하는 모든 것 21 | - 웹 리소스 관리 주체: 웹 서버 22 | - 웹 리소스는 웹 콘텐츠의 원천임 23 | - 웹 리소스 종류 24 | - 정적 파일: 텍스트 파일, HTML 파일, 워드 파일, PDF, 이미지 파일, 동영상 파일 등 25 | - 동적 콘텐츠: 소프트웨어 프로그램이 만들어내는 컨텐츠로, 요청자의 신원, 요청 내용, 요청 일시 등에 따라 컨텐츠가 변함(동적으로 생성됨) 26 | 27 | ![](../images/1-2.png) 28 | 29 | [그림 1-2 웹 리소스란 웹에 콘텐츠를 제공하는 모든 것을 말한다.] 30 | 31 | ### 1.3.1 미디어 타입 32 | - MIME 타입 33 | - Multipurpose Internet Mail Extensions, 다목적 인터넷 메일 확장 34 | - 웹을 통해 전송되는 HTTP 객체에 붙이는 이름표로, 자료형(data type) 정보가 담김 35 | - 사선(/)으로 주 타입과 부 타입을 구분함 36 | - 예시: 37 | - HTML로 작성된 텍스트 문서: text/html 38 | - plain ASCII 텍스트 문서: text/plain 39 | - JPEG 이미지: image/jpeg 40 | - 파워포인트 파일(*.ppt): application/vnd.mspowerpoint 41 | - [MIME 타입 전체 목록](https://developer.mozilla.org/ko/docs/Web/HTTP/Basics_of_HTTP/MIME_types/Complete_list_of_MIME_types) 42 | 43 | ![](../images/1-3.png) 44 | 45 | [그림 1-3 웹 서버는 데이터 콘텐츠와 함께 MIME 타입을 보내준다.] 46 | 47 | ### 1.3.2 URI 48 | - Uniform Resource Identifier, 통합 자원 식별자 49 | - 서버에 저장된 리소스 각각에 지정된 고유한 이름으로, 위치정보도 포함함(우편물 주소와 유사). 클라이언트는 원하는 리소스를 지목할 때 이 이름을 사용함 50 | - 예시: 51 | - 웹서버에 있는 이미지 리소스: http://www.joes-hardware.com/specials/saw-blade.gif 52 | - 종류 53 | - URL 54 | - Uniform Resource Locator, 통합 자원 지시자 55 | - 특정 서버의 한 리소스에 대한 구체적인 위치를 서술하며, 1) 프로토콜, 2) 서버의 인터넷 주소, 3) 웹 서버의 리소스로 구성됨 56 | - URN 57 | - Uniform Resource Name, 통합 자원 이름 58 | - 콘텐츠를 이루는 한 리소스에 대해, 그 리소스의 위치에 영향받지 않는 유일무이한 이름 역할을 함(실험 중이고 아직 채택되진 않은 상태임) 59 | - 오늘날 대부분의 URI는 URL이므로, URI와 URL이 동격으로 쓰임 60 | - 자세한 내용은 2장에서 다룸 61 | 62 | ![](../images/1-4.png) 63 | 64 | [그림 1-4 URL은 프로토콜, 서버, 리소스를 명시한다.] 65 | 66 | ## 1.4 트랜잭션 67 | - 클라이언트와 웹 서버가 HTTP를 이용해 리소스를 주고받는 (상호 작용) 방법 68 | - 요청 명령과 응답 결과로 구성됨 69 | - 요청 명령: 클라이언트가 서버로 보냄 70 | - 응답 결과: 서버가 클라이언트에게 돌려주는 결과 71 | - `HTTP 메시지`라고 불리는 정형화된 데이터 덩어리를 이용해 이루어짐 72 | 73 | ![](../images/1-5.png) 74 | 75 | [그림 1-5 HTTP 트랜잭션은 요청과 응답 메시지로 구성되어 있다.] 76 | 77 | ### 1.4.1 메서드 78 | - 요청 명령의 종류로, 서버에게 어떤 동작이 취해져야 하는지 말해줌 79 | - 모든 HTTP 요청 메시지는 한 개의 메서드를 갖음 80 | - 주요 메서드 81 | 82 | | HTTP메서드 | 설명 | 관련 DB 쿼리 | 83 | | --- | --- | --- | 84 | | `GET` |서버에서 클라이언트로 지정한 리소스를 보내라.|READ/SELECT| 85 | | `PUT` |클라이언트에서 서버로 보낸 데이터를 지정한 이름의 리소스로 저장하라.|UPDATE| 86 | | `DELETE` |지정한 리소스를 서버에서 삭제하라.|| 87 | | `POST` |클라이언트 데이터를 서버 게이트웨이 애플리케이션으로 보내라.|CREATE/INSERT| 88 | | `HEAD` |지정한 리소스에 대한 응답에서, HTTP 헤더 부분만 보내라.|| 89 | 90 | ### 1.4.2 상태 코드 91 | - 클라이언트에게 요청이 성공했는지 아니면 추가 조치가 필요한지 알려주는 세 자리 숫자 92 | - 모든 HTTP 응답 메시지는 상태 코드와 함께 전송됨 93 | - 텍스트로 된 사유 구절(reason phrase)도 함께 전송됨 94 | - 주요 상태 코드 95 | 96 | | HTTP 메서드 | 설명 | 97 | | --- | --- | 98 | | 200 | 좋다. 문서가 바르게 반환되었다. | 99 | | 302 | 다시 보내라. 다른 곳에 가서 리소스를 가져가라. | 100 | | 404 | 없음. 리소스를 찾을 수 없다. | 101 | 102 | - 자세한 내용은 3장에서 다룸 103 | 104 | ### 1.4.3 웹페이지는 여러 객체로 이루어질 수 있다 105 | - 페이지 하나를 구성하려면 대량의 HTTP 트랜잭션을 수행해야 함 106 | 107 | ![](../images/1-6.png) 108 | 109 | [그림 1-6 웹페이지는 첨부된 리소스들에 대해 각각 별개의 HTTP 트랜잭션을 필요로 한다.] 110 | 111 | ## 1.5 메시지 112 | - HTTP 메세지는 단순한 줄 단위의 문자열임. 113 | - 종류: 114 | - 요청 메시지: 웹 클라이언트에서 웹 서버로 보낸 메시지 115 | - 응답 메시지: 서버에서 클라이언트로 가는 메시지 116 | - 구성: 117 | - 시작 줄 118 | - 메시지의 첫줄 119 | - 요청이라면 무엇을 해야 하는지, 응답이라면 무슨 일이 일어났는지 나타냄 120 | - 헤더 121 | - 시작 줄 다음에 이어지는 필드 122 | - 각 헤더 필드는 쉬운 구문분석을 위해 콜론(:)으로 구분되어있는 하나의 이름과 하나의 값으로 구성됨 123 | - 빈 줄로 끝남 124 | - 본문 125 | - 빈 줄 다음에 들어가는 내용 126 | - 어떤 종류의 데이터든 들어갈 수 있음 127 | - 텍스트를 비롯한 임의의 이진 데이터도 가능함 128 | - 이미지, 비디오, 오디오 트랙, 응용 소프트웨어 등 129 | 130 | ## 1.5.1 간단한 메시지의 예 131 | 132 | ![](../images/1-8.png) 133 | 134 | [그림 1-8 http://www.joes-hardware.com/tools.html에 대한 GET 트랜잭션의 예] 135 | 136 | - 간단한 HTTP 메시지를 주고받는 트랜잭션 137 | - 요청 138 | - 리소스: http://www.joes-hardware.com/tools.html 139 | - 메서드: GET 140 | - 로컬 리소스: /tools.html 141 | - 요청 프로토콜: HTTP/1.0 142 | - 응답 143 | - HTTP 버전 번호: HTTP/1.0 144 | - 상태 코드: 200(성공) 145 | - 사유 구절: OK 146 | - 응답 헤더 필드 영역 147 | - Content-length(응답 본문 길이) 148 | - Content-type(문서의 MIME 타입) 149 | - 응답 본문 150 | 151 | ## 1.6 TCP 커넥션 152 | - Transmission Control Protocol, 전송 제어 프로토콜 153 | - 어떻게 HTTP 메시지가 TCP 커넥션을 통해 한 곳에서 다른 곳으로 전송되는지 154 | 155 | ### 1.6.1 TCP/IP 156 | 157 | ### 1.6.2 접속, IP 주소 그리고 포트번호 158 | 159 | ### 1.6.3 텔넷을 이용한 실제 예제 160 | 161 | ## 1.7 프로토콜 버전 162 | - HTTP/1.1: 현재 HTTP 버전 163 | - HTTP/2.0: HTTP/1.1 성능 문제를 해결하기 위해 설계가 진행 중임 164 | 165 | ## 1.8 웹의 구성요소 166 | 167 | - 프락시: 클라이언트와 서버 사이에 위치한 HTTP 중개자 168 | - 캐시: 많이 찾는 웹페이지를 클라이언트 가까이에 보관하는 HTTP 창고 169 | - 게이트웨이: 다른 애플리케이션과 연결된 특별한 웹 서버 170 | - 터널: 단순히 HTTP 통신을 전달하기만 하는 특별한 프락시 171 | - 에이전트: 자동화된 HTTP 요청을 만드는 준 지능적(semi-intelligent) 웹 클라이언트 172 | 173 | ### 1.8.1 프락시 174 | - 클라이언트와 서버 사이에서 클라이언트의 모든 HTTP 요청을 받아 (요청을 수정한 후) 서버에 트래픽을 전달해주는 `중개 서버` 175 | - 보안, 애플리케이션 통합, 성능 최적화를 수행함 176 | - `보안` 177 | - 신뢰할 만한 중개자 역할을 함 178 | - 요청과 응답을 필터링 함 179 | 180 | ![](../images/1-11.png) 181 | 182 | [그림 1-11 프라시는 클라이언트와 서버 사이에서 트래픽을 전달한다.] 183 | 184 | ### 1.8.2 캐시 185 | - 성능 향상을 목적으로 자주 찾는 문서의 사본을 저장해 두는 특별한 종류의 HTTP 프락시 서버 186 | - 캐싱키술 187 | 188 | ![](../images/1-12.png) 189 | 190 | [그림 1-12 캐시 프락시는 성능 향상을 위해 자주 찾는 문서의 사본을 저장해둔다.] 191 | 192 | ### 1.8.3 게이트웨이 193 | - 다른 서버들의 중개자로 동작하는 특별한 서버 194 | - HTTP 트래픽을 다른 프로토콜로 변환하기 위해 사용됨 195 | 196 | ![](../images/1-13.png) 197 | 198 | [그림 1-13 HTTP/FTP 게이트웨이] 199 | 200 | ### 1.8.4 터널 201 | - 두 커넥션 사이에서 날(raw) 데이터를 열어보지 않고 그대로 전달해주는 HTTP 어플리케이션 202 | - 주로 비 HTTP 데이터를 하나 이상의 HTTP 연결을 통해 그대로 전송해주기 위해 사용됨 203 | 204 | ![](../images/1-14.png) 205 | 206 | [그림 1-14 비 HTTP 네트워크 너머로 데이터를 전달하는 터널(HTTP/SSL 터널)] 207 | 208 | ### 1.8.5 에이전트 209 | - 사용자 에이전트라고도 불리며, 사용자를 위해 HTTP 요청을 만들어주는 클라이언트 프로그램 210 | - 예시: 사람의 통제 없이 스스로 웹을 돌아다니며 HTTP 트랜잭션을 일으키고 콘텐츠를 받아오는 크롤러 211 | 212 | ![](../images/1-15.png) 213 | 214 | [그림 1-15 자동화된 검색 엔진 스파이더는 전 세계의 웹페이지를 수집하는 에이전트이다.] 215 | 216 | 217 | ## 1.9 시작의 끝 218 | 219 | ## 1.10 추가 정보 220 | 221 | ### 1.10.1 HTTP 프로토콜에 대한 정보 222 | - HTTP Pocket Reference: HTTP에 대한 간략한 설명을 담은 책 223 | - https://www.w3.org/Protocols/: HTTP 프로토콜에 대한 정보가 있음 224 | - https://www.ietf.org/rfc/rfc2616.txt: HTTP/1.1 공식 명세서 225 | ### 1.10.2 역사적 시각 226 | ### 1.10.3 기타 월드 와이드 웹 정보 227 | 228 | -------------------------------------------------------------------------------- /chapter_01/src_고현주/Untitled-14689cf8-8f93-4671-b99a-3fd53f8b6f91.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bookcrush/httpPerfectGuide/f038fb52319dba3dfb2b9eb34a987b8cd8564a97/chapter_01/src_고현주/Untitled-14689cf8-8f93-4671-b99a-3fd53f8b6f91.png -------------------------------------------------------------------------------- /chapter_01/src_고현주/Untitled-8eaf825b-be0f-409f-acd3-805db21da132.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bookcrush/httpPerfectGuide/f038fb52319dba3dfb2b9eb34a987b8cd8564a97/chapter_01/src_고현주/Untitled-8eaf825b-be0f-409f-acd3-805db21da132.png -------------------------------------------------------------------------------- /chapter_01/src_고현주/Untitled-9a56ba46-0225-4903-ace2-8f5662ed4345.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bookcrush/httpPerfectGuide/f038fb52319dba3dfb2b9eb34a987b8cd8564a97/chapter_01/src_고현주/Untitled-9a56ba46-0225-4903-ace2-8f5662ed4345.png -------------------------------------------------------------------------------- /chapter_01/src_고현주/Untitled-ab2b6473-36de-411b-8e1f-6b204bbcb76d.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bookcrush/httpPerfectGuide/f038fb52319dba3dfb2b9eb34a987b8cd8564a97/chapter_01/src_고현주/Untitled-ab2b6473-36de-411b-8e1f-6b204bbcb76d.png -------------------------------------------------------------------------------- /chapter_01/src_고현주/Untitled-fe95f6f3-8925-4dc9-881d-5190a87c993e.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bookcrush/httpPerfectGuide/f038fb52319dba3dfb2b9eb34a987b8cd8564a97/chapter_01/src_고현주/Untitled-fe95f6f3-8925-4dc9-881d-5190a87c993e.png -------------------------------------------------------------------------------- /chapter_02/README.md: -------------------------------------------------------------------------------- 1 | # [2장] HTTP:웹의 기초 / URL과 리소스 2 | 3 | ## 정리 글 링크 4 | 5 | 1. 고석진 6 | 2. 고현주 - https://dev-junior.tistory.com/6 7 | 3. 구유림 - [HTTP 완벽 가이드 [1-2] - URL과 리소스](https://yurimkoo.github.io/http/2019/08/08/http-the-definitive-guide-1-2.html) 8 | 4. 김나영 - [URL과 리소스](https://feel5ny.github.io/2019/08/09/HTTP_002/) 9 | 5. 김준형 - [HTTP - 2장](https://junjangsee.github.io/2019/08/11/network/network-02/) 10 | 6. 류지환 - [2장 URL과 리소스 : URL의 포맷, URL이 가르키는 리소스 형식, URN으로의 발전과정](https://www.notion.so/jeewhan/2-URL-URL-URL-URN-bca9ea444d5046e39e8b24cfc1971b17) 11 | 7. 이강호 - [HTTP - 2장](https://www.notion.so/chapter2-URL-7d3991ca001f4f639da8809cb1c55f00) 12 | 8. 이동규 - [HTTP 완벽가이드 스터디 #2](https://brainbackdoor.tistory.com/122) 13 | 9. 이보라 - [HTTP 완벽가이드 2장](./chap2_이보라.md) 14 | 10. 이종진 - [HTTP 완벽가이드::URL](https://jongjineee.github.io/2019/08/09/http-url.html) 15 | 11. 홍유정 - [[HTTP완벽가이드] 02. URL과 리소스](https://youjung-hong.github.io/2019-08-07/02-URL%EA%B3%BC-%EB%A6%AC%EC%86%8C%EC%8A%A4/) 16 | 12. 한재우 - [HTTP 완벽가이드 2장](https://bebiangel.github.io/2019/08/11/http-guide-chap2/) 17 | 18 | -------------------------------------------------------------------------------- /chapter_02/chap2_고석진.md: -------------------------------------------------------------------------------- 1 | # URL 과 리소스 2 | 3 | ## 2.1 인터넷의 리소스 탐색하기 4 | 5 | URL 은 인터넷의 리소스를 가리키는 표준이름입니다. 6 | 리소스가 어디에 있고 어떻게 접근 할 수 있는지 알려줍니다. 7 | 8 | - URL: URI 라고 불리는 더 일반화된 부류의 부분집합 (대부분은 스킴//서버위치/경로의 구조를 가집니다) 9 | - URI: URL 과 URN 으로 구성된 종합적인 개념 10 | - URN: 리소스가 어디에 존재하든 상관없이 이름만으로 리소스 식별이 가능 11 | 12 | https://www.naver.com/webtoon/index.html 이라는 주소가 있을때 13 | 14 | - https 는 `URL의 스킴` 입니다. 웹 클라이언트가 리소스에 어떻게 접근하는지 알려줍니다. 15 | - www.naver.com 은 `서버의 위치` 입니다. 리소스가 어디에 호스팅 되어 있는지 알려줍니다. 16 | - /webtoon/index.html 은 `리소스의 경로` 입니다. 17 | 18 | ## 2.2 URL 문법 19 | 20 | URL 문법은 스킴에 따라서 달라진다. 대부분의 URL 스킴의 문법은 일반적으로 9개 부분으로 나뉜다. 21 | 22 | ```text 23 | <스킴>://<사용자이름>:<비밀번호>@<호스트>:<포트>/<경로>;<파라미터>?<질의>#<프래그먼트> 24 | ``` 25 | 26 | | | 설명 | 기본값 | 27 | | ---------- | --------------------------------------------------------------------------- | ------------------ | 28 | | 스킴 | 어떤 프로토콜을 사용하여 서버에 접근해야하는지 | 없음 | 29 | | 사용자이름 | 리소스 접근을 위한 사용자 이름이 필요 할 수 있다. | anonymous | 30 | | 비밀번호 | 사용자의 비밀번호, 이름에 : 으로 이어서 표시 | 이메일주소 | 31 | | 호스트 | 호스팅명이나 IP 주소 | | 32 | | 포트 | 서버가 열어놓은 포트, HTTP 기본 포트는 80 | 스킴에 따라 다르다 | 33 | | 경로 | 리소스가 서버내 어디에 있음을 가리킨다. | | 34 | | 파라미터 | 특정 스킴들에서 입력 파라미터를 기술하는 용도 | | 35 | | 질의 | 스킴에서 애플리케이션에 파라미터를 전달하는 용도, URL 끝에 "?" 로 구분한다 | | 36 | | 프래그먼트 | 리소스의 조각이나 일부분을 가리키는 이름, URL 의 끝에서 "#" 문자로 구분한다 | | 37 | 38 | ## 2.2.1 스킴: 사용할 프로토콜 39 | 40 | 스킴은 주어진 리소스에 어떻게 접근하는지 알려주는 중요한 정보다. URL 을 해석하는 애플리케이션이 어떤 프로토콜을 사용하여 리소스를 요청해야 하는지 알려준다. 41 | 42 | ## 2.2.2 호스트와 포트 43 | 44 | URL 의 호스트와 포트 컴포넌트는 리소스를 호스팅하고 있는 장비와, 접근할 수 있는 서버가 어디에 있는지 정보를 제공해준다. 45 | 46 | ## 2.2.3 사용자 이름과 비밀번호 47 | 48 | 많은 서버가 데이터에 접근을 허용하기 전에 사용자 이름과 비밀번호를 요구한다. 49 | 50 | - ftp:ftp.prep.ai.mit.eud/pub/gnu: 사용자 이름이나 비밀번호 컴포넌트가 없이 표준 스킴, 호스트, 경로만 있다. 51 | - ftp:anonymous@ftp.prep.ai.mit.eud/pub/gnu: 사용자 이름이 `anonymous` 이다. '@' 문자는 URL로부터 사용자 이름과 비밀번호 컴포넌트를 분리한다. 52 | - ftp:anonymous:my_passwd@ftp.prep.ai.mit.eud/pub/gnu: 사용자이름 `anonymous` 과 비밀번호 `my_passwd` 를 ':' 로 분리하여 기술 53 | 54 | ## 2.2.4 경로 55 | 56 | URL 의 경로 컴포넌트는 리소스가 서버의 어디에 있는지 알려준다. '/' 문자를 기준으로 경로조각으로 나뉜다. 57 | 58 | ## 2.2.5 파라미터 59 | 60 | 많은 스킴이 객체에 대한 호스트 및 경로 정보만으로는 리소스를 찾지 못한다. 어떤 포트를 사용하고 있는지, 이름과 비밀번호를 명시했는지 등등 많은 정보를 요구한다. 61 | 62 | HTTP URL 에서의 경로 컴포넌트는 경로조각으로 나눌 수 있다. 각 조각은 자체 파라미터를 가질 수 있다. 63 | 64 | ``` 65 | http://www.joes-hardware.com/hammers;sale=false/index.html;graphics=true 66 | ``` 67 | 68 | hammers 와 index.html 이라는 두 개의 경로 조각이 있다. hammers는 sale 파라미터를 가지고, index.html 은 graphics 란 파라미터를 가진다. 69 | 70 | ## 2.2.6 질의 문자열 71 | 72 | 데이터베이스 같은 서비스들은 요청받을 리소스 형식의 범위를 좁히기 위해서 질문이나 질의를 받을 수 있다. 73 | '&' 로 나뉜 '이름=값' 쌍 형식으로 표현할 수 있다. 74 | 75 | ## 2.2.7 프래그먼트 76 | 77 | 리소스에 대한 URL 은 텍스트 문자 전체를 가리키지만, 이상적으로 리소스 내부의 특정 절을 가리 킬 수 있어야 한다. 78 | 프래그먼트를 이용하면 HTML 같은 리소스 형식들은 본래 수준보다 더 작게 나뉠 수 있다. 79 | 80 | 프래그먼트는 '#' 문자에 이어서 온다. 81 | 82 | ``` 83 | http://www.joes-hardware.com/tools.html#drills 84 | ``` 85 | 86 | 위의 주소는 tools.html 웹페이지의 일부를 가리친다. 그 부분을 drills 라고 기술한다. 87 | 88 | ## 2.3 단축 URL 89 | 90 | 상대 URL 은 리소스 안에 있는 리소스를 간결하게 기술하는데 사용할 수 있다. 사용자가 기억하고 있는 URL 일부를 입력하면 나머지 부분을 자동으로 입력해주는 URL 자동 확장 기능을 지원한다. 91 | 92 | ## 2.3.1 상대 URL 93 | 94 | URL 은 상대, 절대 두 가지로 나뉜다. 95 | 96 | - 절대 URL: 리소스에 접근하는데 필요한 모든 정보를 가지고 있다. 97 | - 상대 URL: 모든 정보를 담고 있지 않다. 상대 URL 로 리소스에 접근하는데 필요한 정보를 얻기 위해서는 기저라고 하는 다른 URL 을 사용해야한다. 98 | 99 | ```html 100 | 101 | ``` 102 | 103 | html 문서 내부에 ./hammers.html URL 을 가리키는 하이퍼링크가 있다. 이것이 상대 URL 이다. 104 | 105 | ``` 106 | http://www.joes-hardware.com/tools.html 107 | ``` 108 | 109 | 위의 주소가 기저 URL 일 때, 이 기저 URL 을 바탕으로 정보를 추측할 수 있다. 110 | 111 | ``` 112 | http://www.joes-hardware.com/hammers.html 113 | ``` 114 | 115 | - 기저 URL: 기저 URL 은 상대 URL 의 기준이 된다. 116 | - 리소스에서 명시적으로 제공: 리소스들은 URL을 명확하게 기술하기도 한다. 117 | - 리소스를 포함하고 있는 기저 URL: 상대 URL 기저 URL 이 명시되지 않은 리소스에 포함된 경우 해당 리소스 URL을 기저 URL 로 사용할 수 있다. 118 | - 기저 URL 이 없는 경우: 이런 경우는 절대 URL 만으로 이루어져 있다는 뜻이다. 불완전하거나 깨진 URL 일 수도 있다. 119 | - 상대 참조 해석하기: 상대 URL 과 기저 URL 을 각각의 컴포넌트 조각으로 나누는 것 120 | 121 | ## 2.3.2 URL 확장 122 | 123 | 브라우저들은 URL 을 입력한 다음이나 입력하고 있는 동안에 자동으로 URL 을 확장한다 124 | 125 | - 호스트명 확장: 'yahoo' -> 'www.yahoo.com' or 추가적인 몇가지 URL 제시 126 | - 히스토리 확장: 과거에 사용자가 방문했던 URL 을 저장해 놓는 것 127 | 128 | ## 2.4 안전하지 않은 문자 129 | 130 | 안전한 전송이란 정보가 유실될 위험 없이 URL을 전송할 수 있다는 것을 의미한다. 131 | 어떤 인터넷 프로토콜을 통해서든 안전하게 전송될 수 있도록 URL 을 설계하는 것은 중요하다 132 | 133 | ## 2.4.1 URL 문자 집합 134 | 135 | 컴퓨터 시스템은 보통 US-ASCII 문자 집합을 사용해왔다. US-ASCII 의 경우 만들어진 지 오래된 문자 집합이기 때문에 적은 수의 문자만을 포함하고 있다. 136 | 그렇기 때문에 전 세계 사람들이 사용하는 언어를 지원하기에는 무리가 있다. 137 | 이런 문제점을 해결하기 위해 URL에 이스케이프 문자열을 쓸 수 있게 설계하였다. 138 | 139 | ## 2.4.2 인코딩 체계 140 | 141 | 안전한 문자 집합을 이용하는 경우 표현의 한계를 넘기 위해, URL 에 있는 안전하지 않은 문자들을 표현할 수 있는 인코딩 방식이 고안되었다. 142 | 안전하지 않은 문자를 % 으로 시작해 두개의 16 진수 숫자로 이루어진 이스케이프 문자(-, '', %)로 바꾼다. 143 | 144 | ## 2.4.3 문자 제한 145 | 146 | 몇몇 문자는 URL 내에서 특별한 의미로 예약되어있다. 다른 용도로 사용하려면 인코딩 해야되는 문자들이다 147 | 148 | | 문자 | 선점 및 제한 | 149 | | ----- | ---------------------------------------------------------------------------- | 150 | | % | 인코딩된 문자에 사용할 이스케이프 토큰으로 선점 | 151 | | / | 경로 세그먼트를 나누는 용도 | 152 | | . | 경로 컴포넌트에서 선점 | 153 | | .. | 경로 컴포넌트에서 선점 | 154 | | # | 프래그먼트의 구획 문자로 선점 | 155 | | ? | 질의 문자열의 구획 문자로 선점 | 156 | | ; | 파라미터의 구획 문자로 선점 | 157 | | : | 스킴, 사용자 이름/ 비밀번호, 호스트/포트의 구획 문자로 선점 | 158 | | \$, + | 선점 | 159 | | @ & = | 특정 스킴에서 특별한 의미가 있기 때문에 선점 | 160 | | {} | \ ~ [] ` | 게이트웨이와 같은 전송 에이전트에서 불안전하게 다루기 떄문에 제한 | 161 | | <> "" | 안전하지 않음. URL 범위 밖에서 역할이 있는 문자이기 떄문에 반드시 인코딩 | 162 | 163 | ## 2.5 스킴의 바다 164 | 165 | - http: 일반 URL 포맷을 지키는 하이퍼 텍스트 전송 프로토콜 기본 포트는 80 을 사용한다. 166 | - https: http 와 거의 같다. 커넥션의 양 끝단에서 암호화를 한다. 기본 포트는 443 이다. 167 | - mailto: 이메일 주소를 가리킨다. 표준 URL 과는 다른 포맷을 가진다. 168 | - ftp: 파일 전송 프로토콜 169 | - rtsp, rtspu: 실시간 스트리밍 프로토콜 170 | - file: 파일 공유 시스템에서 바로 접글 할 수 있는 파일들을 나타낸다. 171 | - news: 특정 문서나 뉴스 그룹에 접근하는데 사용한다. 172 | - telnet: 대화형 서비스에 접근하는데 사용된다. 173 | -------------------------------------------------------------------------------- /chapter_02/chap2_이보라.md: -------------------------------------------------------------------------------- 1 | # URL과 리소스 2 | - 목표 3 | - URL 문법 4 | - 각 URL 컴포넌트의 의미와 역할 5 | - 단축 URL(상대 URL, 확장 URL) 6 | - 인코딩과 문자 규칙 7 | - 공통 URL 스킴 8 | - URN 이해하기 9 | 10 | ## 2.1 인터넷의 리소스 탐색하기 11 | - URL 12 | - Uniform Resource Locator, 통합 자원 지시자 13 | - 인터넷의 `리소스`를 가리키는 `표준 이름` 14 | - 브라우저가 정보를 찾는데 필요한 리소스의 위치를 가리킴 15 | - 애플리케이션이 리소스에 접근할 수 있는 방법을 제공함 16 | - 구조: `스킴://서버위치/경로` 17 | - [URI](../chapter_1/chap1_이보라.md#132-uri)의 부분집합임 18 | 19 | - 예시 20 | - URL: http://www.joes-hardware.com/seasonal/index-fall.html 21 | - 스킴: http 22 | - 서버위치: www.joes-hardware.com 23 | - 경로: /seasonal/index-fall.html 24 | 25 | ![](../images/2-1.png) 26 | 27 | [그림 2-1 URL이 브라우저, 컴퓨터, 서버, 서버 파일 시스템의 어디에 위치하고 어떻게 연결되는지 보여준다.] 28 | 29 | ## 2.2 URL 문법 30 | 31 | URL 문법은 스킴에 따라서 달라진다. 대부분의 URL 스킴의 문법은 일반적으로 9개 부분으로 나뉜다. 32 | 33 | ``` 34 | <스킴>://<사용자이름>:<비밀번호>@<호스트>:<포트>/<경로>;<파라미터>?<질의>#<프래그먼트> 35 | ``` 36 | 37 | | 컴포넌트 | 설명 | 기본값 | 38 | | --- | --- | --- | 39 | | **스킴** | 리소스를 가져오려면 어떤 프로토콜을 사용하여 서버에 접근해야 하는지를 가리킴 | 없음 | 40 | | 사용자이름 | 몇몇 스킴은 리소스에 접근 하기 위해 사용자 이름이 필요함 | anonymous | 41 | | 비밀번호 | 사용자의 비밀번호를 가리키며, 사용자 이름에 콜론(:)으로 이어서 기술함 | 이메일주소 | 42 | | **호스트** | 리소스를 호스팅하는 서버의 호스트 명이나 IP 주소 | 없음 | 43 | | 포트 | 리소스를 호스팅하는 서버가 열어놓은 포트 번호. 많은 스킴이 기본 포트를 가지고 있음(HTTP 기본 포트는 80임) | 스킴에 따라 다름 | 44 | | **경로** | 이전 컴포넌트와 빗금으로 구분함. 리소스가 서버 내 어디에 있는지를 가리킴. 경로 컴포넌트의 문법은 서버와 스킴에 따라 다름 | 없음 | 45 | | 파라미터 | 특정 스킴들에서 입력 파라미터를 기술하는 용도로 사용됨. 파라미터는 이름/값을 쌍으로 가짐. 다른 파라미터나 경로의 일부와 세미콜론(;)으로 구분하여 기술하며, 여러 개를 가질 수 있음 | 없음 | 46 | | 질의 | 스킴에서 애플리케이션(데이터베이스, 게시판, 검색엔진, 기타 인터넷 게이트웨이)에 파라미터를 전달하는 데 쓰임. URL 끝에 "?"로 구분함 | 없음 | 47 | | 프래그먼트 | 리소스 조각이나 일부를 가리키는 이름. URL이 특정 객체를 가리킬 경우에 프래그먼트 필드는 서버에 전달되지 않음. 이는 클라이언트에서만 사용됨. URL 끝에서 "#" 문자로 구분함 | 없음 | 48 | 49 | ## 2.2.1 스킴: 사용할 프로토콜 50 | 51 | - URL을 해석하는 애플리케이션이 어떤 **프로토콜** 을 사용하여 리소스를 요청해야 하는지 알려줌 52 | - 주어진 리소스에 어떻게 접근하는지 알려주는 중요한 정보 53 | - 알파벳으로 시작해야 하고 URL의 나머지 부분들과 첫 번째 콜론(:)으로 구분함 54 | 55 | ## 2.2.2 호스트와 포트 56 | 57 | - 리소스를 호스팅하고 있는 장비와 그 장비 내에서 리소스에 접근할 수 있는 서버가 어디 있는지 알려줌 58 | - 호스트: 접근하려고 하는 리소스를 가지고 있는 인터넷상의 호스트 장비 59 | - 포트: 서버가 열어놓은 네트워크 포트를 가리킴 60 | - TCP 프로토콜을 사용하는 HTTP는 기본 포트로 80을 사용함 61 | 62 | ## 2.2.3 사용자 이름과 비밀번호 63 | - 데이터 접근 허용 권한 부여에 사용됨 64 | - 예: FTP 서버 65 | - ftp://ftp.prep.ai.mit.edu/pub/gnu 66 | - 사용자 이름이나 비밀번호 컴포넌트 없이 표준 스킴, 호스트, 경로만 있음 67 | - 사용자 이름이나 비밀번호 컴포넌트가 없는 경우 68 | - 사용자 이름 기본값: anonymous 69 | - 비밀번호 기본값: 브라우저마다 다름(IE: IEUser, 크롬: chrome@example.com) 70 | - ftp://anonymous@ftp.prep.ai.mit.edu/pub/gnu 71 | - 사용자 이름이 anonymous임. '@' 문자는 URL로부터 사용자 이름과 비밀번호 컴포넌트를 분리함 72 | - ftp://anonymous:my_passwd@ftp.prep.ai.mit.edu/pub/gnu 73 | - 사용자 이름(anonymous)과 비밀번호(my_passwd)를 콜론(:)으로 분리하여 기술함 74 | 75 | ## 2.2.4 경로 76 | - 서버가 리소스의 위치를 찾는 데 사용하는 정보(리소스가 서버의 어디에 있는지 알려줌) 77 | - 계층적 파일 시스템 경로와 유사한 구조를 가짐 78 | - '/' 문자를 기준으로 경로 조각으로 나뉨 79 | 80 | ## 2.2.5 파라미터 81 | - 애플리케이션이 서버에 정확한 요청을 하는 데 필요한 입력 파라미터를 받는 데 사용함 82 | - 많은 스킴이 객체에 대한 호스트 및 경로 정보만으로는 리소스를 찾지 못함 83 | - 서버가 어떤 포트를 열어놓고 있는지, 84 | - 리소스에 접근하기 위해 이름과 비밀번호를 명시했는지 등의 정보가 필요함 85 | - 이름/값 쌍의 리스트 86 | - 세미콜론(;)으로 URL 나머지 부분들과 구분함 87 | - 예시: 88 | - ftp://prep.ai.mit.edu/pub/gnu;type=d 89 | - 파라미터: type=d 90 | - http://www.joeshardware.com/hammers;sale=false/index.html;graphics=true 91 | - 파라미터: sale=false, graphics=true 92 | 93 | ## 2.2.6 질의 문자열 94 | - 데이터베이스 같은 서비스들은 요청받을 리소스 형식의 범위를 좁히기 위해서 질문이나 질의를 받을 수 있음 95 | - 물음표(?) 우측의 값 96 | - '&'로 나뉜 '이름=값' 쌍 형식의 문자열 97 | - 예시: 98 | - http://www.joes-hardware.com/inventorycheck.cgi?item=12731&color=blue 99 | - 질의 문자열: item=12731&color=blue 100 | 101 | ![](../images/2-2.png) 102 | 103 | [그림 2-2 URL 질의 컴포넌트는 게이트웨이 애플리케이션으로 전달된다.] 104 | 105 | ## 2.2.7 프래그먼트 106 | - 리소스의 특정 부분을 가리킬 수 있도록 해줌 107 | - 샵(#) 우측의 값 108 | - 예시: 109 | - 큰 한 개의 텍스트 문서에서 내부의 특정 절을 가리키려는 경우 110 | - HTML 문서에 있는 특정 이미지 111 | - http://www.joes-hardware.com/tools.html#drills 112 | - 프래그먼트: drills 113 | 114 | ![](../images/2-3.png) 115 | 116 | [그림 2-3 서버는 객체를 전체 단위로만 전송하기 때문에 URL 프래그먼트는 클라이언트에서만 사용된다.] 117 | 118 | ## 2.3 단축 URL 119 | - 리소스 안에 있는 리소스를 간결하게 기술하는 데 사용됨 120 | 121 | ## 2.3.1 상대 URL 122 | - URL은 절대 URL과 상대 URL로 나뉨 123 | - 절대 URL: 리소스에 접근하는데 필요한 모든 정보를 가지고 있음 124 | - 상대 URL 125 | - `URL을 짧게 표기하는 방식`으로 모든 정보를 담고 있진 않음 126 | - 프래그먼트나 URL의 일부임 127 | - 스킴, 호스트, 다른 컴포넌트들을 모두 입력하지 않아도 됨 128 | - 기저(base) URL과 상대 URL을 조합해 리소스에 접근하는데 필요한 정보(절대 URL)를 얻음 129 | - 기저 URL: 상대 URL의 기준이 되는 URL 130 | - 예시: 131 | - 기저 URL: http://www.joes-hardware.com/ 132 | - 상대 URL: ./hammers.html 133 | - 새로운 절대 URL: http://www.joes-hardware.com/hammers.html 134 | 135 | ![](../images/2-4.png) 136 | 137 | [그림 2-4 기저 URL의 사용] 138 | 139 | 140 | - URL을 처리하는 브라우저 같은 애플리케이션은 상대 ULR과 절대 URL 간에 상호 변환을 해줌 141 | 142 | ![](../images/2-5.png) 143 | 144 | [그림 2-5 상대 URL을 절대 URL로 변환하기] 145 | 146 | ## 2.3.2 URL 확장 147 | 148 | - 브라우저는 URL을 입력한 다음이나 입력하고 있는 동안에 자동으로 URL 을 확장해줘 사용자가 빠르게 URL을 입력하도록 해줌 149 | - 호스트명 확장: 입력한 호스트 명을 전체 호스트 명으로 확장해줌 150 | - 예시: 'yahoo'를 입력하면 'www.yahoo.com'를 만들어줌 151 | - 히스토리 확장: 과거에 사용자가 방문했던 URL 기록을 저장해 놓았다가 URL을 입력하면 입력된 URL의 앞글자들을 포함하는 완결된 형태의 URL을 선택하게 해줌 152 | - 예시: 'http://joes-'를 입력하면 'http://www.joes-hardware.com'을 보여줌 153 | 154 | ## 2.4 안전하지 않은 문자 155 | - 안전한 전송: 정보가 유실될 위험 없이 URL을 전송할 수 있다는 것을 의미함 156 | 157 | 158 | ## 2.4.1 URL 문자 집합 159 | 160 | ## 2.4.2 인코딩 체계 161 | 162 | ## 2.4.3 문자 제한 163 | 164 | 165 | ## 2.5 스킴의 바다 166 | 167 | 168 | 169 | 170 | -------------------------------------------------------------------------------- /chapter_03/README.md: -------------------------------------------------------------------------------- 1 | # [3장] HTTP:웹의 기초 / HTTP 메세지 2 | 3 | ## 정리 글 링크 4 | 5 | 1. 고석진 6 | 2. 고현주 - [HTTP 완벽가이드 I.HTTP: 웹의 기초_03.HTTP 메세지](https://dev-junior.tistory.com/7) 7 | 3. 구유림 - [HTTP 완벽 가이드 [1-3] - HTTP 메시지 - (1) 8 | ](https://yurimkoo.github.io/http/2019/08/08/http-the-definitive-guide-1-3-1.html) / [HTTP 완벽 가이드 [1-3] - HTTP 메시지 - (2) 9 | ](https://yurimkoo.github.io/http/2019/08/08/http-the-definitive-guide-1-3-2.html) 10 | 4. 김나영 - [HTTP메세지/개요](https://feel5ny.github.io/2019/08/15/HTTP_003_01/), [HTTP메세지/메서드](https://feel5ny.github.io/2019/08/16/HTTP_003_02/), [HTTP메세지/상태코드](https://feel5ny.github.io/2019/08/17/HTTP_003_03/), [HTTP메세지/헤더](https://feel5ny.github.io/2019/08/18/HTTP_003_04/) 11 | 5. 김준형 - [HTTP - 3장](https://junjangsee.github.io/2019/08/18/network/network-03/) 12 | 6. 류지환 - [3장 HTTP 메시지 : 콘텐츠가 담기는 HTTP 메시지](https://www.notion.so/jeewhan/3-HTTP-HTTP-04821c3217ca4944adf111c0259ae878) 13 | 7. 이강호 [HTTP 메세지](https://www.notion.so/Chapter-3-HTTP-9ceda876d2864d2492ea8a2b92b340b1) 14 | 8. 이동규 - [HTTP 완벽가이드 스터디 #3](https://brainbackdoor.tistory.com/123) 15 | 9. 이보라 - [HTTP 완벽가이드 3장](./chap3_이보라.md) 16 | 10. 이종진 - [HTTP 완벽가이드::MESSAGE](https://jongjineee.github.io/2019/08/18/http-message.html) 17 | 11. 홍유정 - [[HTTP완벽가이드] 03. HTTP 메시지](https://youjung-hong.github.io/2019-08-18/03-HTTP-%EB%A9%94%EC%8B%9C%EC%A7%80/) 18 | 12. 한재우 - [HTTP 완벽가이드 3장](https://bebiangel.github.io/2019/08/18/http-guide-chap3/) 19 | 20 | ## 2장 정리글 리뷰 team 21 | 시작이후에 들어오신 이보라, 홍유정, 이강호님 팀 분들은 1장,2장까지도 리뷰 부탁드립니다. 22 | - 고현주, 김준형, 이종진, 이동규 23 | - 구유림, 류지환, 이보라, 한재우 24 | - 김나영, 홍유정, 고석진, 이강호 25 | -------------------------------------------------------------------------------- /chapter_03/chap3_고석진.md: -------------------------------------------------------------------------------- 1 | # HTTP 2 | 3 | ## 3.1 메시지의 흐름 4 | 5 | HTTP 메세지는 애플리케이션 간에 주고받은 데이터의 블록들이다. 메시지의 내용과 의미를 설명하는 텍스트 메타 정보와 선택적으로 데이터가 올 수 있다. 6 | 7 | ### 3.1.1메시지는 원 서버 방향을 인바운드로 하여 송신된다 8 | 9 | 메시지가 원 서버로 향하는 것은 인바운드로 이동하는 것이고, 모든 처리가 끝난 뒤에 메시지가 사용자 에이전트로 돌아오는 것은 아웃바운드이다. 10 | 11 | ### 3.1.2 다운스트림으로 흐르는 메세지 12 | 13 | 모든 메세지는 다운스트림으로 흐른다. 메시지의 발송자는 수신자의 업스트림이다. 14 | 15 | ## 3.2 메시지의 각 부분 16 | 17 | 각 메세지는 시작줄, 헤더 블록, 본문 세 부분으로 이루어진다. 18 | 시작줄은 어떤 메시지인지 서술하며, 헤더 블록은 속성, 본문은 데이터를 담고있다. 19 | 20 | ### 3.2.1 메시지 문법 21 | 22 | 메시지는 요청 메시지와 응답 메시지로 나누어진다. 23 | 24 | // 요청 메시지 형식 25 | 26 | <메서드> <요청 URL> <버전> 27 | <헤더> 28 | <엔터티 본문> 29 | 30 | // 응답 메시지 형식 31 | 32 | <메서드> <상태 코드> <사유 구절> 33 | <헤더> 34 | <엔터티 본문> 35 | 36 | - 메서드: 서버가 리소스에 대해 수행해주길 바라는 동작 37 | - 요청 URL: 요청 대상이 되는 리소스를 지칭하는 URL 38 | - 버전: 메시지에서 사용하는 HTTP 버전 39 | - 상태코드: 성공, 에러등을 나타내는 세 자리의 숫자 40 | - 사유 구절: 숫자로 된 상태 코드의 의미를 사람이 이해할 수 있게 설명해주는 문구 41 | - 헤더들: 이름, 콜론, 선택적인 공백, 값, CRLF 가 순서대로 나타나는 0 개 이상의 헤더들 42 | - 엔터티 본문: 데이터 블록을 포함한다. 43 | 44 | ### 3.2.2 시작줄 45 | 46 | 메세지의 시작줄은 무엇을 해야 하는지 말해준다. 47 | 48 | - 요청줄: 서버에서 어떤 동작이 일어나야 하는지 설명해주는 메서드와 동작에 대한 대상을 지칭하는 요청 URL 이 들어있다 49 | - 응답줄: 응답 메시지에서 쓰인 HTTP 의 버전, 숫자로 된 상태 코드, 수행 상태에 대해 설명해주는 텍스트 사유구절 50 | - 메서드: 서버에게 무엇을 해야하는지 말해준다. 51 | - 상태코드: 클라이언트에게 무엇이 일어났는지 말해준다. (100 - 정보, 200 - 성공, 300 - 리다이렉션, 400 - 클라이언트 에러, 500 - 서버에러) 52 | - 사유구절: 상태 코드에 대한 글로 된 설명을 제공한다. 53 | - 버전 번호: 응답, 요청 메세지 모두에 기술된다. 자신이 따르는 프로토콜 버전을 상대방에게 말해주기 위한 수단이 된다. 54 | 55 | ### 3.2.3 헤더 56 | 57 | 헤더 필드는 요청과 응답 메시지에 추가 정보를 더한다. 58 | 59 | - 일반 헤더: 요청과 응답 양쪽에 모두 나타낼 수 있다. 60 | - 요청 헤더: 요청에 대한 부가 정보를 제공 61 | - 응답 헤더: 응답에 대한 부가 정보를 제공 62 | - Entity 헤더: 본문 크기와 콘텐츠, 리소스 그 자체를 서술 63 | - 확장 헤더: 명세에 정의되지 않은 새로운 헤더 64 | 65 | ### 3.2.4 엔터티 본문 66 | 67 | HTTP 메세지는 이미지, 비디오, HTML 문서 등 여러 종류의 디지털 데이터를 실어 나를 수 있다. 68 | 69 | ## 3.3 메서드 70 | 71 | ### 3.3.1 안전한 메서드 72 | 73 | GET, HEAD 메서드는 안전한 메서드이다. 이는 HTTP 요청의 결과로 서버에 어떤 작용도 없음을 의미한다. 74 | 75 | ### 3.3.2 GET 76 | 77 | 서버에게 리소스를 달라고 요청하기 위해 쓰인다. 78 | 79 | ### 3.3.3. HEAD 80 | 81 | GET 처럼 행동하지만, 서버는 응답으로 헤더만 돌려준다. 82 | 83 | - 응답의 상태 코드를 통해, 개체의 존재 유무를 알 수 있다. 84 | = 리소스가 변경되었는지 검사 할 수 있다. 85 | 86 | ### 3.3.4 PUT 87 | 88 | 서버가 요청의 본문을 가지고 요청 URL 의 이름대로 새 문서를 만들거나, 이미 URL 이 존재한다면 본문을 사용해서 교체하는 것이다. 89 | 90 | ### 3.3.5 POST 91 | 92 | 서버에 입력 데이터를 전송하기 위해 설계 93 | 94 | ### 3.3.6 TRACE 95 | 96 | 클라이언트에게 자신의 요청이 서버에 도달했을 때 어떻게 보이게 되는지 알려준다. 97 | 주로 진단을 위해서 사용된다. 98 | 99 | ### 3.3.7 OPTIONS 100 | 101 | 웹 서버에게 여러 가지 종류의 지원 범위에 대해 물어본다. 서버에게 특정 리소스에 대해 어떤 메서드가 지원되는지 물어볼 수 있다. 102 | 103 | ### 3.3.8 DELETE 104 | 105 | 서버에게 요청 URL 로 지정한 리소스를 삭제할 것을 요청한다. 106 | 107 | ## 3.4 상태 코드 108 | 109 | ### 3.4.1 100-109: 정보성 상태 코드 110 | 111 | #### 100(Continue) 112 | 113 | 클라이언트는 나머지를 계속이어서 보내야 함을 의미한다. 114 | 100-Continue 는 최적화를 위한 것이다. 클라이언트 애플리케이션은 100-Continue 를 서버가 다루거나 사용할 수 없는 큰 엔터티를 서버에게 보내지 않으려는 목적으로만 사용해야 한다. 115 | 116 | 프락시가 다음 홉 서버들에 대한 상태 몇 가지와 그들이 지원하는 HTTP 버전을 기억해둔다면, 100-continue 응답을 기대한 요청을 더 잘 다룰 수 있게 되므로 프락시에게 이득이 된다. 117 | 118 | #### 101(Switching Protocols) 119 | 120 | 클라이언트가 Upgrade 헤더에 나열한 것 중 하나로 서버가 프로토콜을 바꾸었음을 의미한다. 121 | 122 | ### 3.4.2 200-299: 성공 상태 코드 123 | 124 | | 상태코드 | 사유구절 | 의미 | 125 | | -------- | ----------------------------- | ----------------------------------------------------------------------- | 126 | | 200 | ok | 요청은 정상이고, 엔터티 본문은 요청된 리소스를 포함하고 있다. | 127 | | 202 | accepted | 요청은 받아들여졌으나 서버는 아직 어떤 동작도 수행하지 않았다. | 128 | | 203 | non-authoritative Information | 엔터티 헤더가 아닌 리소스의 사본에서 왔다. | 129 | | 204 | no content | 응답 메시지는 헤더와 상태줄을 포함하지만 엔터티 본문은 포함하지 않는다. | 130 | | 205 | reset content | 브라우저에게 현재 페이지에 있는 HTML 폼에 채워진 모든 값을 비우라고한다 | 131 | | 206 | partial content | 부분 혹은 범위 요청이 성공했다 | 132 | 133 | ### 3.4.3 300-399: 리다이렉션 상태 코드 134 | 135 | | 상태코드 | 사유구절 | 의미 | 136 | | -------- | ------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------- | 137 | | 300 | multiple choices | 클라이언트가 여러 리소스를 가리키는 URL 을 요청한 경우, 그 리소스의 목록과 함께 반환한다 | 138 | | 301 | moved permanently | 요청한 URL이 옮겨졌을 때 사용한다. | 139 | | 302 | found | 301 상태코드와 같다. 그러나 클라이언트는 location 헤더로 주어진 URL을 리소스를 임시로 가리키기 위한 목적으로 사용해야한다. | 140 | | 303 | see other | 리소스를 다른 URL에서 가져와야 한다고 말해주고자 할때 쓰인다 | 141 | | 304 | not modified | 헤더를 이용해 조건부 요청을 만들 수 있다. | 142 | | 305 | use proxy | 리소스가 반드시 프락시를 통해서 접근되어야 함을 나타내기 위해 사용한다. | 143 | | 307 | temporary redirect | 301 상태코드와 같다. 그러나 클라이언트는 location 헤더로 주어진 URL을 리소스를 임시로 가리키기 위한 목적으로 사용해야한다. 이후 요청에서는 원래 URL을 사용해야 한다. | 144 | 145 | ### 3.4.4 400-499: 클라이언트 에러 상태 코드 146 | 147 | | 상태코드 | 사유구절 | 의미 | 148 | | -------- | ------------------------------- | ------------------------------------------------------------------------------------------------------- | 149 | | 400 | bad request | 잘못된 요청 | 150 | | 401 | unauthorized | 인증하라고 요구하는 내용의 응답을 적절한 헤더와 함께 반환한다. | 151 | | 402 | payment required | 현재 사용되지 않고있다. | 152 | | 403 | forbidden | 요청이 서버에 의해 거부되었음을 알려주기 위해 사용 | 153 | | 404 | not found | 요청한 URL을 찾을 수 없음을 알려주기 위해 사용 | 154 | | 405 | method not allowed | 지원하지 않는 메서드로 요청을받았을 때 사용 | 155 | | 406 | not aceeptable | 어떤 종류의 엔터티를 받아들이고자 하는지에 대해 매개변수로 명시할 수 있다. | 156 | | 407 | proxy authentication required | 401 상태코드와 같으나, 리소스에 대해 인증을 요구하는 프락시 서버를 위해 사용한다 | 157 | | 408 | request timeout | 요청을 완수하기에 시간이 너무 많이 걸리는 경우, 서버는 408 코드를 반환하고 응답하고 연결을 끊을 수 있다 | 158 | | 409 | confilct | 리소스에 대해 일으킬 수 있는 몇몇 충돌을 지칭하기 위해 사용 | 159 | | 410 | gone | 404와 비슷하나 서버가 한때 그 리소스를 가지고 있었다는 점이 다르다 | 160 | | 411 | length required | 서버가 요청 메시지에 content-length 헤더가 있을 것을 요구한다 | 161 | | 412 | precondition failed | 조건부 요청을 했는데 그중 하나가 실패했을 때 사용한다 | 162 | | 413 | request entity too large | 한계의 크기를 넘은 요청을 클라이언트가 보냈을때 | 163 | | 414 | request uri to long | 한계의 길이를 넘은 요청 url 이 포함된 클라이언트가 보냈을때 | 164 | | 415 | unsupported media type | 서버가 이해하거나 지원하지 못하는 내용 유형의 엔터티를 클라이언트가 보넀을 때 사용 | 165 | | 416 | requested range not satisfiable | 요청 메시지가 리소스의 특정 범위를 요청했는데, 그 범위가 잘못되었거나 맞지 않을때 | 166 | | 417 | expectation failed | 요청에 포함된 expect 요청 헤더에 서버가 만족시킬 수 없는 기대가 담겨있는 경우 사용 | 167 | 168 | ### 3.4.5 500-599: 서버 에러 상태 코드 169 | 170 | | 상태코드 | 사유구절 | 의미 | 171 | | -------- | -------------------------- | --------------------------------------------------------------------------------------------------- | 172 | | 500 | internal sever error | 서버가 요청을 처리할 수 없게 만드는 에러를 만났을 때 사용 | 173 | | 501 | not implemented | 클라이언트가 서버의 능력을 넘은 요청을 했을 때 (지원 x 메서드 등) | 174 | | 502 | bad gateway | 가짜 응답에 맞닥뜨렸을 때 사용 | 175 | | 503 | service unavailable | 현재는 요청을 처리할 수 없지만 나중에는 가능함을 의미 | 176 | | 504 | gateway timeout | 408과 비슷하지만 응답을 기다리다 타임아웃이 발생한 게이트웨이나 프락시에서 온 응답이라는점이 다르다 | 177 | | 505 | http version not supported | 지원하지 않으려고 하는 버전의 프로토콜로 된 요청을 받았을 때 | 178 | 179 | ## 3.5 헤더 180 | 181 | 헤더와 메서드는 클라이언트와 서버가 무엇을 하는지 결정하기 위해서 사용된다. 182 | 183 | - 일반헤더: 서버, 클라이언트 양쪽에서 사용, 메시지를 보내는 다른 애플리케이션들을 위해 다양한 목적으로 사용 184 | - 요청 헤더: 요청 메시지를 위한 헤더, 서버에게 클라이언트가 받고자 하는 데이터의 타입이 무엇인지와 같은 정보를 제공 185 | - 응답 헤더: 응답 메세지는 클라이언트에게 정보를 제공하기 위한 자신만의 헤더를 가지고 있다. 186 | - 엔터티 헤더: 본문에 대한 헤더를 말한다. 본문에 들어있는 데이터의 타입이 무서인지 말해줄 수 있다. 187 | - 확장 헤더: 비표준 헤더다. 188 | 189 | ### 3.51 일반 헤더 190 | 191 | 메시지에 대한 아주 기본적인 정보를 제공한다. 192 | 193 | - connection: 클라이언트와 서버가 요청/응답 연결에 대한 옵션을 정할 수 있게 해준다. 194 | - date\*: 메시지가 언제 만들어졌는지에 대한 날짜와 시간을 제공 195 | - mime-version: 발송자가 사용한 mime 의 버전을 알려준다. 196 | - trailer chunked transfer: 인코딩으로 인코딩된 메시지의 끝 부분에 위치한 헤더들의 목록을 나열한다. 197 | - trasfer-encoding: 전송을 위해 어떤 인코딩이 적용되었는지 말해준다. 198 | - upgrade: 새 버전이나 프로토콜을 알려준다. 199 | - via: 어떤 중개자로부터 왔는지 알려준다. 200 | 201 | #### 일반 캐시 헤더 202 | 203 | - cache-control: 메시지와 함께 캐시 지시자를 전달하기 위해 사용한다. 204 | - pragma: 메시지와 함꼐 지시자를 전달하는 또 다른 방법. 캐시에 국한되지 않는다. 205 | 206 | ### 3.5.2 요청 헤더 207 | 208 | 요청 메시지에서만 의미를 갖는 헤더다.최초 발생한곳에서 누가 혹은 무엇이 그 요청을 보냈는지, 클라이언트의 선호나 능력에 대한 정보를 준다. 209 | 210 | - client-ip, from, host, referer, os, user agent 등 ... 211 | 212 | #### accept 관련 헤더 213 | 214 | 서버에게 자신의 선호와 능력을 알려 줄 수 있다. 서버는 이 정보를 활용해서 무엇을 보낼 것인가에 대한 처리를 할 수 있다. 215 | 216 | - accept: 보내도 되는 미디어의 종류 217 | - accept - charset, encoding, language, te: 보내도되는 문자집합, 인코딩, 언어, 전송코딩 218 | 219 | #### 조건부 요청 헤더 220 | 221 | 요청에 몇몇 제약을 넣을 수 있다. 222 | 223 | - expect: 요청에 필요한 서버의 행동을 열거 224 | - if-match: 문서의 엔터티 태그가 주어진 엔터티 태그와 일치하는 경우에만 문서를 가져온다. 225 | - if-modified-since: 주어진 날짜 이후에 리소스가 변경되지 않았다면 요청을 제한 226 | - if-none-match: 문서의 엔터티 태그가 주어진 엔터티 태그와 일치하지 않는 경우에만 문서를 가져온다. 227 | - if-range: 특정 범위에 대한 요청을 할 수 있게 해준다. 228 | - if-unmodified-since: 주어진 날짜 이후에 리소스가 변경되었다면 요청을 제한한다. 229 | - range: 특정 범위에 대한 요청 230 | 231 | #### 요청 보안 헤더 232 | 233 | HTTP는 자체적으로 요청을 위한 간단한 인증요구/응답 체계를 갖고 있다. 234 | 235 | - authorization: 클라이언트가 서버에게 제공하는 인증 그 자체에 대한 정보를 담고있다. 236 | - cookie: 클라이언트가 서버에게 토큰을 전달할 때 사용한다. 237 | - cookie2: 요청자가 지원하는 쿠키의 버전을 알려줄 때 사용한다. 238 | 239 | #### 프락시 요청 헤더 240 | 241 | 프락시의 기능을 돕기 위해 몇몇 헤더들이 정의되었다. 242 | 243 | - max-forwards: 프락시나 게이트웨이로 전달될 수 있는 최대 횟수 244 | - proxy-authorization: 프락시에서 인증을 할 때 쓰인다. 245 | - proxy-connect: 프락시에서 연결을 맺을 때 쓰인다. 246 | 247 | ### 3.5.3 응답 헤더 248 | 249 | 클라이언트에게 부가 정보를 제공한다. 250 | 251 | - age: 응답이 얼마나 오래되었는지 252 | - public: 특정 리소스에 대해 지원하는 요청 메서드의 목록 253 | - retry-after: 현재 리소스가 사용불가일때 언제 가능해지는지 날짜 혹은 시각 254 | - server: 서버 애플리케이션의 이름과 버전 255 | - title: html 문서에서 주어진 것과 같은 제목 256 | - warning: 사유 구절에 있는 것보다 더 자세한 경고 메세지 257 | 258 | #### 협상 헤더 259 | 260 | 서버가 협상 가능한 리소스에 대한 정보를 운반하는 몇 가지 헤더들이 있다. 261 | 262 | - accept-ranges: 범위의 형태 263 | - vary: 응답에 영향을 줄 수 있는 헤더들의 목록 264 | 265 | #### 응답 보안 헤더 266 | 267 | 인증요구 헤더 268 | 269 | - proxy-authenticate: 프락시에서 클라이언트로 보낸 인증요구의 목록 270 | - set-cookie: 서버가 클라이언트를 인증할 수 있도록 클라이언트 측에 토큰을 설정하기 위해 사용 271 | - www-authenticate: 서버에서 클라이언트로 보낸 인증요구의 목록 272 | 273 | ### 3.5.4 엔터티 헤더 274 | 275 | 엔터티와 그것의 내용물에 대한, 개체의 타입부터 시작해서 주어진 리소스에 대해 요청 할 수 있는 유요한 메서드들까지 광범위한 정보를 제공한다. 276 | 277 | - allow: 수행될 수 있는 요청 메서드들을 나열한다. 278 | - location: 클라이언트에게 엔터티가 실제로 어디에 위치하고 있는지 말해준다. 279 | 280 | #### 콘텐츠헤더 281 | 282 | 엔터티의 콘텐츠에 대한 구체적인 정보를 제공한다. 283 | 284 | - content-base: 기저 url 285 | - content-encoding: 적용된 인코딩 286 | - content-language: 적절한 언어 287 | - content-length: 본문의 길이나 크기 288 | - content-location: 리소스의 위치 289 | - content-md5: md5 체크섬 290 | - content-range: 범위를 바이트 단위로 표현 291 | - content-type: 어떤 종류의 객체인지 292 | 293 | #### 엔터티 캐싱 헤더 294 | 295 | 언제 어떻게 캐시가 되어야 하는지에 대한 지시자를 제공 296 | 297 | - etag: 엔터티 태그 298 | - expires: 엔터티가 더 이상 유효하지 않아 원본을 다시 받아와야 하는 일시 299 | - last-modified: 가장 최근 엔터티가 변경된 일시 300 | -------------------------------------------------------------------------------- /chapter_03/chap3_이보라.md: -------------------------------------------------------------------------------- 1 | # HTTP 메시지 2 | - 목표 3 | - 메시지가 어떻게 플러가는가 4 | - HTTP 메시지의 세 부분(시작줄, 헤더, 개체 본문) 5 | - 요청과 응답 메시지의 차이 6 | - 요청 메시지가 지원하는 여러 기능(메서드)들 7 | - 응답 메시지가 반환하는 여러 상태 코드들 8 | - 여러 HTTP 헤더들은 무슨 일을 하는가 9 | 10 | 11 | ## 3.1 메시지의 흐름 12 | - HTTP 메시지 13 | - HTTP 애플리케이션 간에 주고받은 `데이터의 블록` 14 | - 메시지의 내용과 의미를 설명하는 `메타 정보`로 시작하고, 선택적으로 `데이터`가 올 수 있음 15 | - 메시지는 클라이언트, 서버, 프락시 사이를 흐름 16 | - 메시지가 흘러가는 방향에 따라 '인바운드', '아웃바운드', '업스트림', '다운스트림'으로 나뉨 17 | 18 | ### 3.1.1 메시지는 원 서버 방향을 인바운드로 하여 송신된다 19 | - 인바운드 20 | - 메시지가 원 서버로 향하는 것 21 | - 아웃바운드 22 | - (모든 처리가 끝난 후에) 메시지가 사용자 에이전트로 돌아오는 것 23 | 24 | ![](../images/3-1.png) 25 | 26 | [그림 3-1 원 서버로 인바운드로 이동하고 클라이언트로 아웃바운드로 복귀하는 메시지] 27 | 28 | ### 3.1.2 다운스트림으로 흐르는 메시지 29 | - 모든 메시지는 (요청 메시지, 응답 메시지인지와 상관 없이) 다운스트림으로 흐름 30 | 31 | ![](../images/3-2.png) 32 | 33 | [그림 3-2 모든 메시지는 다운스트림으로 흐른다.] 34 | 35 | - 메시지의 발송자는 수신자의 업스트림임 36 | - 그림 3-2 37 | - 요청에선 프락시 1이 프락시 3의 업스트림 38 | - 응답에선 프락시 3이 프락시 1의 업스트림 39 | 40 | 41 | ## 3.2 메시지의 각 부분 42 | - 어떤 메시지인지를 서술하는 `시작줄`, 속성을 나타내는 `헤더 블록`, 데이터를 담고있는 `본문`으로 나뉨 43 | 44 | ![](../images/3-3.png) 45 | 46 | [그림 3-3 HTTP 메시지의 세 부분] 47 | 48 | - 시작줄과 헤더블록은 줄 단위로 구분함 49 | - 각 줄은 두 글자의 줄바꿈 문자열(`CRLF`)로 끝남 50 | - 본문은 데이터 덩어리로, 선택사항임 51 | - 텍스느타 이진 데이터를 포함할 수 있고 비어있을 수도 있음 52 | 53 | ### 3.2.1 메시지 문법 54 | - 모든 HTTP 메시지는 요청 메시지나 응답 메시지로 분류됨 55 | - 요청 메시지 56 | - 웹 서버에 어떤 동작을 요구함 57 | - 응답 메시지 58 | - 요청의 결과를 클라이언트에게 돌려줌 59 | - 두 메시지의 구조는 기본적으로 같음 60 | 61 | ![](../images/3-4.png) 62 | 63 | [그림 3-4 요청과 응답 메시지를 포함한 HTTP 트랜잭션] 64 | 65 | - 형식 66 | 67 | | | 요청 메시지 | 응답 메시지 | 68 | | --- | --- | --- | 69 | |시작줄|<메서드> <요청 URL> | <상태 코드> <사유 구절>| 70 | |헤더|<헤더>|<헤더>| 71 | |(빈 줄)||| 72 | |본문|<엔터티 본문>|<엔터티 본문>| 73 | 74 | ### 3.2.2 시작줄 75 | - 모든 HTTP 메시지는 시작줄로 시작함 76 | - 요청 메시지의 시작줄(요청줄)은 무엇을 해야하는지, 응답 메시지의 시작줄(응답줄)은 무슨 일이 일어났는지를 말해줌 77 | - 요청줄 78 | - [메서드](#33-헤더): 서버에서 어떤 동작이 일어나야 하는지를 설명함 79 | - 요청 URL: 동작(메서드)에 대한 대상을 지칭함 80 | - HTTP 버전: 클라이언트가 어떤 HTTP 버전으로 말하고 있는지 서버에게 알려줌 81 | - 응답줄 82 | - HTTP 버전: 응답 메시지에 쓰인 HTTP 버전 83 | - [상태 코드](#34-상태-코드): 숫자로 구성 84 | - 사유 구절: 상태 코드에 대한 글로된 설명을 제공함 85 | - 요청줄과 응답줄의 모든 필드는 공백으로 구분 86 | - 예시: 87 | 88 | ![](../images/3-5.png) 89 | 90 | [그림 3-5 요청과 응답 메시지의 예] 91 | 92 | - 요청 메시지 93 | - 메서드: GET 94 | - 요청 URL: /test/hi-there.txt 95 | - HTTP 버전: HTTP/1.1 96 | - 응답 메시지 97 | - HTTP 버전: HTTP/1.0 98 | - 상태 코드: 200 99 | - 사유 구절: OK 100 | 101 | ### 3.2.3 헤더 102 | - 시작줄 다음에 오고, 0개, 1개 혹은 여러개의 HTTP 헤더가 옴 103 | - 요청과 응답 메시지에 추가 정보를 더해줌 104 | - 이름/값 쌍의 목록 105 | - 문법: 이름, 콜론(:), 공백(없어도 됨), 필드 값, CRLF가 순서대로 옴 106 | 107 | | 헤더의 예 | 설명 | 108 | | --- | --- | 109 | |Date: Tue, 3 Oct 1997 02:16:03 GMT|서버가 응담을 만들어 낸 시각| 110 | |Content-length: 15040 |15,040바이트의 데이터를 포함한 엔터티 본문| 111 | |Content-type: image/gif|엔터티 본문은 GIF 이미지다| 112 | |Accept: image/gif, image/jpeg, text/html |클라이언트는 GIF, JPEG 이미지와 HTML을 받아들일 수 있다.| 113 | 114 | - 헤더를 여러 줄로 나누는 것도 가능함 115 | - 추가 줄 앞에는 최소 하나의 스페이스 혹은 탭 문자가 와야함 116 | - 예시: 117 | - 헤더의 완전한 값: 'Test Server Version 1.0' 118 | ```text 119 | HTTP/1.0 200 OK 120 | Content-Type: image/gif 121 | Content-Length: 8572 122 | Server: Test Server 123 | Version 1.0 124 | ``` 125 | 126 | ### 3.2.4 엔터티 본문 127 | - HTTP 메시지의 화물로, HTTP가 수송하게 됨 128 | - 이미지, 비디오, HTML문서, 소프트웨어 애플리케이션, 신용카드 트랜잭션, 전자 우편 등 여러 종류의 디지털 데이터를 실어 나를 수 있음 129 | 130 | ### 3.2.5 버전 0.9 메시지 131 | - HTTP 프로토콜의 초기버전(0.9)에서 쓰이던 메시지 형식 132 | 133 | 134 | ## 3.3 메서드 135 | - 요청의 시작줄에 있으며, 서버에게 무엇을 해야 하는지 말해줌 136 | - 많이 쓰이는 HTTP 메서드 137 | | 메서드 | 설명 | 메시지 본문이 있는가? | 138 | | --- | --- | --- | 139 | | GET | 서버에서 어떤 문서를 가져온다. | 없음 | 140 | | HEAD | 서버에서 어떤 문서에 대한 헤더만 가져온다. | 없음 | 141 | | POST | 서버가 처리해야 할 데이터를 보낸다. | 있음 | 142 | | PUT | 서버에 요청 메시지의 본문을 저장한다. | 있음 | 143 | | TRACE | 메시지가 프락시를 거쳐 서버에 도달하는 과정을 추적한다. | 없음 | 144 | | OPTIONS | 서버거 어떤 메서드를 수행할 수 있는지 확인한다. | 없음 | 145 | | DELETE | 서버에서 문서를 제거한다. | 없음 | 146 | 147 | 148 | 149 | ## 3.3.1 안전한 메서드 150 | - HTTP 요청의 결과로 인해 서버에서 일어나는 일이 아무것도 없는 메서드 151 | - GET, HEAD 메서드가 안전한 메서드에 속함 152 | 153 | ### 3.3.2 GET 154 | - 가장 많이 쓰이는 메서드로 서버에게 리소스를 달라고 요청할 때 쓰임 155 | 156 | ![](../images/3-7.png) 157 | 158 | [그림 3-7 GET의 예] 159 | 160 | ### 3.3.3 HEAD 161 | - GET처럼 동작하지만, 응답 메시지에 헤더만 있음(본문 없음) 162 | - 리소스를 가져오지 않고도 타입 등의 정보를 알아낼 수 있음 163 | - 응답 상태 코드를 보고 개체가 존재하는지 확인할 수 있음 164 | - 리소스가 변경되었는지 여부를 확인할 수 있음 165 | - 서버 개발자들은 GET과 HEAD의 헤더가 정확히 일치하도록 구현해야 함 166 | 167 | ![](../images/3-8.png) 168 | 169 | [그림 3-8 HEAD의 예] 170 | 171 | ### 3.3.4 PUT 172 | - 서버에 문서를 씀 173 | - 요청 본문을 가지고 요청 URL의 이름대로 새 문서를 만들거나, 이미 URL이 존재한다면 본문을 사용해서 교체함 174 | - 콘텐츠 변경이 수반되기 때문에 많은 웹서버가 PUT을 수행하기 전에 비밀번호를 입력해서 로그인을 하도록 요구함 175 | 176 | ![](../images/3-9.png) 177 | 178 | [그림 3-9 PUT의 예] 179 | 180 | ### 3.3.5 POST 181 | - 서버에 입력 데이터를 전송하기 위해 설계된 메서드 182 | > POST는 서버에 데이터를 보내기 위해 사용함. PUT은 서버에 있는 리소스(예: 파일)에 데이터를 입력하기 위해 사용함 183 | - HTML 폼을 지원하기 위한 용도로 주로 사용됨 184 | 185 | ![](../images/3-10.png) 186 | 187 | [그림 3-10 POST의 예] 188 | 189 | ### 3.3.6 TRACE 190 | - 클라이언트에게 자신의 요청이 서버에 도달했을 때 어떻게 보이게 되는지 알려주는 메서드 191 | - 진단을 위해 주로 사용됨 192 | 193 | ![](../images/3-11.png) 194 | 195 | [그림 3-11 TRACE의 예] 196 | 197 | ### 3.3.7 OPTIONS 198 | - 웹 서버에게 여러 가지 종류의 지원 범위에 대해 물어봄 199 | - 특정 리소스에 대해 어떤 메서드가 지원되는지 물어볼 수 있음 200 | - 리소스에 실제로 접근하지 않고도 어떤 접근 방식이 최선인지 확인할 수 있음 201 | - 예시: 202 | - `Allow: GET, POST, PUT, OPTIONS` 203 | 204 | ![](../images/3-12.png) 205 | 206 | [그림 3-12 OPTIONS의 예] 207 | 208 | ### 3.3.8 DELETE 209 | - 웹 서버에게 요청 URL로 지정한 리소스를 삭제할 것을 요청함 210 | - 삭제가 수행되는것은 보장받지 못함 211 | 212 | ![](../images/3-13.png) 213 | 214 | [그림 3-13 DELETE의 예] 215 | 216 | ### 3.3.8 확장 메서드 217 | - HTTP/1.1 명세에 정의되지 않은 메서드로, 개발자가 필요에 따라 설계할 수 있음 218 | 219 | 220 | ## 3.4 상태 코드 221 | - 상태 코드의 종류 222 | 223 | | 전체 범위 | 정의된 범위 | 분류 | 224 | | --- | --- | --- | 225 | | 100-199 | 100-101 | 정보 | 226 | | 200-299 | 20-206 | 성공 | 227 | | 300-399 | 300-305 | 리다이렉션 | 228 | | 400-499 | 400-415 | 클라이언트 에러 | 229 | | 500-599 | 500-505 | 서버 에러 | 230 | -------------------------------------------------------------------------------- /chapter_04/README.md: -------------------------------------------------------------------------------- 1 | # [4장] HTTP:웹의 기초 / 커넥션 관리 2 | 3 | ## 정리 글 링크 4 | 5 | 1. 고석진 6 | 2. 고현주 - [I.HTTP: 웹의 기초_04.커넥션 관리](https://dev-junior.tistory.com/8) 7 | 3. 구유림 - [HTTP 완벽 가이드 [1-4] - 커넥션 관리](https://yurimkoo.github.io/http/2019/08/23/http-the-definitive-guide-1-4.html) 8 | 4. 김나영 - [TCP 커넥션과 성능](https://feel5ny.github.io/2019/08/26/HTTP_004_01/), [TCP 커넥션의 종류](https://feel5ny.github.io/2019/09/04/HTTP_004_02/) 9 | 5. 김준형 - [HTTP 4장](https://junjangsee.github.io/2019/08/24/network/network-04/) 10 | 6. 류지환 - [4장 커넥션 관리 : HTTP에서 관리하는 TCP 커넥션에 동작방식, 대한 오해, 잘못 작성된 규칙](https://www.notion.so/jeewhan/4-HTTP-TCP-b5a367c48cf841ed878c49dcd1fac0bd) 11 | 7. 이강호 12 | 8. 이동규 13 | 9. 이보라 14 | 10. 이종진 - [HTTP 완벽가이드::Connection](https://jongjineee.github.io/2019/08/18/http-connection.html) 15 | 11. 홍유정 16 | 12. 한재우 - [HTTP 완벽가이드 4장](https://bebiangel.github.io/2019/08/25/http-guide-chap4/) 17 | 18 | ## 3장 정리글 리뷰 team 19 | 20 | - 고현주, 구유림, 이강호 21 | - 김준형, 류지환, 김나영 22 | - 이종진, 이보라, 홍유정 23 | - 이동규, 한재우, 고석진 24 | -------------------------------------------------------------------------------- /chapter_04/chap4_고석진.md: -------------------------------------------------------------------------------- 1 | # HTTP 2 | 3 | 4 | ## 4.1 TCP 커넥션 5 | 6 | 모든 HTTP 통신은 패킷 교환 네트워크 프로토콜들의 계층화된 집합인 TCP/IP 를 통해 이루어진다. 7 | 커넥션이 맺어지면 클라이언트와 서버 컴퓨터 간에 주고받는 메시지들은 손실 혹은 손상되거나 순서가 바뀌지 않고 안전하게 전달된다. 8 | 9 | ### 4.1.1 신뢰할 수 있는 데이터 전송 통로인 TCP 10 | 11 | TCP 커넥션은 인터넷을 안정적으로 연결해준다. 12 | TCP 는 HTTP 에게 신뢰할 만한 통신 방식을 제공한다. 13 | 14 | ### 4.1.2 TCP 스트림은 세그먼트로 나뉘어 IP 패킷을 통해 전송된다. 15 | 16 | HTTP 가 메시지를 전송하고자 할 경우, 현재 연결되어 있는 TCP 커넥션을 통해서 메시지 데이터의 내용을 순서대로 보낸다. 17 | TCP 는 세그먼트라는 단위로 데이터 스트림을 잘게 나누고, 세그먼트를 IP 패킷이라고 불리는 봉투에 담아서 인터넷을 통해 데이터를 전달한다. 18 | 19 | IP 패킷들은 다음의 정보들을 담고있다 20 | 21 | - IP 패킷 헤더 22 | - TCP 세그먼트 헤더 23 | - TCP 데이터 조각 24 | 25 | ### 4.1.3 TPC 커넥션 유지하기 26 | 27 | TCP 는 포트 번호를 통해서 여러 개의 커넥션을 유지한다. 28 | TCP 커넥션은 네 가지 값으로 식별한다. 29 | 30 | ``` 31 | <발신지 IP 주소, 발신지 포트, 수신지 IP 주소, 수신지 포트> 32 | ``` 33 | 34 | 여러 커넥션들은 같은 목적지 포트 번호를 가리킬 수 있다. 35 | 36 | ## 4.2 TCP의 성능에 대한 고려 37 | 38 | HTTP 트랜잭션의 성능은 아래 계층인 TCP 성능에 영향을 받는다. 39 | 40 | ### 4.2.1 HTTP 트랜잭션 지연 41 | 42 | HTTP 트랜잭션을 지연시키는 원인은 여러 가지가 있다. 43 | 44 | - 만약 URI 에 기술되어 있는 호스트에 방문한 적이 최근에 없다면, DNS 이름 분석 인프라를 사용하여 URI 에 있는 호스트 명을 IP 주소로 변환하는데 수십 초의 시간이 걸릴 것 이다. 45 | - 클라이언트는 TCP 커넥션 요청을 서버에게 보낼 것인데, 커넥션 설정 시간은 새로운 TCP 커넥션에서 항상 발생한다. 수백 개의 HTTP 트랜잭션이 만들어지면 소요시간은 크게 증가할 것이다. 46 | - 요청 메시지가 인터넷을 통해 전달되고 서버에 의해서 처리되는 시간이 소요된다. 47 | - 웹 서버가 HTTP 응답을 보내는 것 역시 시간이 소요된다. 48 | 49 | ### 4.2.3 TCP 커넥션 핸드셰이크 지연 50 | 51 | 새로운 TCP 커넥션을 열 때면, TCP 소프트웨어는 커넥션을 맺기 위한 조건을 맞추기 위해 연속으로 IP 패킷을 교환한다. 52 | HTTP 트랜잭션이 아주 큰 데이터를 주고받지 않는 평범한 경우에는, SYN/SYN+ACK 핸드셰이크가 눈에 띄는 지연을 발생시킨다. 53 | 54 | ### 4.2.4 확인응답 지연 55 | 56 | TCP 는 성공적인 데이터 전송을 보장하기 위해서 자체적인 확인 체계를 가진다. 57 | 요청과 응답 두 가지 형식으로만 이루어지는 HTTP 동작 방식은, 확인 응답이 송출 데이터 패킷에 편승할 기회를 감소시킨다. 58 | 편승할 패킷을 찾으려고 하면 해당 방향으로 송출될 패킷이 많지 않기 때문에, 확인응답 지연 알고리즘으로 인한 지연이 자주 발생한다. 59 | 60 | ### 4.2.5 TCP 느린 시작 61 | 62 | TCP 의 데이터 전송 속도는 TCP 커넥션이 만들어진 지 얼마나 지났는지에 따라 달라질 수 있다. 63 | 시간이 지나면서 자체적으로 튜닝되어서, 처음에는 커넥션의 최대 속도를 제한하고 데이터가 성공적으로 전송됨에 따라서 속도 제한을 높여나간다. 64 | 65 | ### 4.2.6 네이글 알고리즘과 TCP_NODELAY 66 | 67 | TCP 세그먼트는 40 바이트 상당의 플래그와 헤더를 포함하여 전송하기 때문에, TCP 가 작은 크기의 데이터를 포함한 많은 수의 패킷을 전송한다면 네트워크 성능은 크게 떨어진다. 68 | 69 | 네이글 알고리즘은 패킷을 전송하기 전에 많은 양의 TCP 데이터를 한 개의 덩어리로 합친다. 70 | 71 | 네이글 알고리즘은 아래와 같은 문제를 발생시킨다. 72 | 73 | - 크기가 작은 HTTP 메세지는 패킷을 채우지 못하기 때문에, 앞으로 생길지 생기지 않을지 모르는 추가적인 데이터를 기다리며 지연될 것이다. 74 | - 확인응답 지연과 함께 쓰일 경우 형편없이 동작한다. 75 | 76 | ### 4.2.7 TIME_WAIT의 누적과 포트 고갈 77 | 78 | 특정 커넥션이 생성되고 닫힌 다음, 그와 같은 IP 주소와 포트 번호를 가지는 커넥션이 2분 이내에 또 생성되는 것을 막아준다. 79 | 80 | ## 4.3 HTTP 커넥션 관리 81 | 82 | ### 4.3.1 흔히 잘못 이해하는 Connection 헤더 83 | 84 | connection 헤더에는 세 가지 종류의 토큰이 전달될 수 있기 때문에 다소 혼란스러울 수 있다. 85 | 86 | - HTTP 헤더 필드 명은, 이 커넥션에만 해당되는 헤더들을 나열한다. 87 | - 임시적인 토큰 값은, 커넥션에 대한 비표준 옵션을 의미한다. 88 | - close 값은 커넥션이 작업이 완료되면 종료되어야 함을 의미한다. 89 | 90 | ### 4.3.2 순차적인 트랜잭션 처리에 의한 지연 91 | 92 | 순차적으로 요청을 로드하는 방식의 단점은, 특정 브라우저의 경우 객체를 화면에 배치 하려면 객체의 크기를 알아야 하기 때문에, 93 | 모든 객체를 내려받기 전까지는 텅 빈 화면을 보여준다는 것이다. 94 | 95 | HTTP 커넥션의 성능을 향상시킬 수 있는 여러 기술이 있다. 96 | 97 | - 병렬 커넥션: 여러 개의 TCP 커넥션을 통한 동시 HTTP 요청 98 | - 지속 커넥션: 커넥션을 맺고 끊는 데서 발생하는 지연을 제거하기 위한 TCP 커넥션의 재활용 99 | - 파이프라인 커넥션: 공유 TCP 커넥션을 통한 병렬 HTTP 요청 100 | - 다중 커넥션: 요청과 응답들에 대한 중재 101 | 102 | ## 4.4 병렬 커넥션 103 | 104 | HTTP 는 클라이언트가 여러 개의 커넥션을 맺음으로써 여러 개의 HTTP 트랜잭션을 병렬로 처리할 수 있게 한다. 105 | 106 | ### 4.4.1 병렬 커넥션은 페이지를 더 빠르게 내려받는다 107 | 108 | 단일 커넥션의 대역폭 제한과 커넥션이 동작하지 않고 있는 시간을 활용하면, 객체가 여러 개 있는 웹페이지를 더 빠르게 내려받을 수 있을 것이다. 109 | 110 | ### 4.4.2 병렬 커넥션이 항상 더 빠르지는 않다 111 | 112 | 제한된 대역폭 내에서 각 객체를 전송받는 것은 느리기 때문에 성능상의 장점은 거의 없어진다. 113 | 또한 다수의 커넥션은 메모리를 많이 소모하고 자체적인 성능 문제를 발생시킨다. 114 | 115 | ### 4.4.3 병렬 커넥션은 더 빠르게 느껴질 수 있다. 116 | 117 | 실제로 페이지를 더 빠르게 내려받는 것은 아니지만 화면에 여러 개의 객체가 동시에 보이면서 내려받고 있는 상황을 볼 수 있기 떄문에 사용자는 더 빠르게 내려받고 있는 것처럼 느낄 수 있다. 118 | 119 | ## 4.5 지속 커넥션 120 | 121 | HTTP/1.1 을 지원하는 기기는 처리가 완료된 후에도 TCP 커넥션을 유지하여 앞으로 있을 HTTP 요청에 재사용할 수 있다. 122 | 처리가 완료된 후에도 계속 연결된 상태로 있는 TCP 커넥션을 지속 커넥션이라고 부른다. 123 | 지속 커넥션을 재사용함으로써, 커넥션을 맺기 위한 준비작업에 따르는 시간을 절약할 수 있다. 124 | 125 | ### 4.5.1 지속 vs 병렬 커넥션 126 | 127 | 병렬 커넥션에는 아래와 같은 단점이 있다. 128 | 129 | - 트랜잭션마다 새로운 커넥션을 맺고 끊기 때문에 시간과 대역폭이 소요된다. 130 | - 새로운 커넥션은 TCP 느린 시작 때문에 성능이 떨어진다. 131 | - 실제로 연결할 수 있는 병렬 커넥션의 수에는 제한이 있다. 132 | 133 | 지속 커넥션의 장단점은 아래와 같다 134 | 135 | - 커넥션을 맺기 위한 사전작업과 지연을 줄여주고, 튜닝된 커넥션을 유지하며, 커넥션의 수를 줄여준다. 136 | - 하지만 지속 커넥션을 잘못 관리할 경우, 연결된 상태로 있는 커넥션들이 쌓이게된다. 137 | 138 | 지속 커넥션과 병렬 커넥션을 함께 사용하는것이 가장 효과적이다. 139 | 140 | ### 4.5.2 HTTP/1.0+ 의 keep alive 커넥션 141 | 142 | keep-alive 커넥션은 커넥션을 맺고 끊는 데 필요한 작업이 없어서 시간이 단축되었다는 장점이 있다. 143 | 144 | ### 4.5.3 keep-alive 동작 145 | 146 | HTTP/1.0keep-alive 커넥션을 구현한 클라이언트는 커넥션을 유지하기 위해서 요청에 connection: keep-alive 헤더를 포함시킨다. 147 | 요청을 받은 서버는 다음 요청도 이 커넥션을 통해 받고자 한다면, 응답 메시지에 같은 헤더를 포함시켜 응답한다. 148 | 응답에 keep-alive 헤더가 없으면, 클라이언트는 서버가 keep-alive 를 지원하지 않으며, 응답 메시지가 전송되고 나면 서버 커넥션을 끊을 것이라 추정한다. 149 | 150 | ### 4.5.4 keep-alive 옵션 151 | 152 | keep-alive 의 동작은 keep-alive 헤더의 쉼표로 구분된 옵션들로 제어할 수 있다. 153 | 154 | - timeout 파라미터는 keep-alive 응답 헤더를 통해 보낸다. 커넥션이 얼마나 유지될 것인지를 의미한다. 155 | - max 파라미터는 몇 개의 HTTP 트랜잭션을 처리할 떄까지 유지될 것인지를 의미한다. 156 | 157 | ``` 158 | Connection: Keep-Alive 159 | Keep-Alive: max=5, timeout=120 160 | ``` 161 | 162 | ### 4.5.5 Keep-Alive 커넥션 제한과 규칙 163 | 164 | - HTTP/1.0 에서 기본적으로 사용되지 않는다. 165 | - 커넥션을 계속 유지하려면 모든 메시지에 Connection: Keep-Alive 헤더를 포함해 보내야한다. 166 | - 커넥션이 끊어지기 전에 텐터티 본문의 길이를 알 수 있어야 커넥션을 유지할 수 있다. 167 | - 프락시와 게이트웨이는 Connection 헤더의 규칙을 철저히 지켜야한다. 168 | 169 | ### 4.5.6 Keep-Alive 와 멍청한 프락시 170 | 171 | 프락시는 Connection 헤더를 이해하지 못해서 해당 헤더들을 삭제하지 않고 요청 그대로를 다음 프락시에 전달한다. 172 | 멍청한 프락시들이 Connection 헤더에 대한 처리 없이 요청을 그대로 웹서버에 메시지를 전송했을 때 173 | 174 | 클라이언트는 이 헤더를 통해 프락시가 커넥션을 유지하는 것에 동의했다고 추정한다. 175 | 서버는 프락시가 자신에게 커넥션을 유지하기를 요청한 것으로 알고 있기 떄문에 커넥션을 끊지 않는다. 176 | 이런 잘못된 통신 떄문에 브라우저는 자신이나 서버가 타임아웃이 나서 커넥션이 끊길 때까지 기다린다. 177 | 178 | ### 4.5.7 Proxy Connection 살펴보기 179 | 180 | 클라이언트 요청이 중개서버를 통해 이어지는 경우 모든 헤더를 무조건 전달하는 문제를 해결하기 위해 proxy-connection 이라는 헤더를 사용한다. 181 | 프락시가 proxy-connect 헤더를 무조건 전달하더라도 웹 서버는 그것을 무시하기 때문에 별 문제가 되지 않는다. 182 | 영리한 프락시는 해당 헤더를 받아 connection 헤더로 바꿈으로써 원하던 효과를 얻게 한다. 183 | 184 | ### 4.5.8 HTTP/1.1의 지속 커넥션 185 | 186 | HTTP/1.1 에서는 keep-alive 커넥션을 지원하지 않는 대신, 설계가 더 개선된 지속 커넥션을 지원한다. 187 | HTTP/1.1 클라이언트는 응답에 Connection: close 헤더가 없으면 응답 후에도 HTTP/1.1 커넥션을 계속 유지하자는 것으로 추정한다. 188 | 189 | ### 4.5.9 지속 커넥션의 제한과 규칙 190 | 191 | - 클라이언트가 Connection: close 헤더를 포함해 보냈으면, 클라이언트는 그 커넥션으로 추가적인 요청을 보낼 수 없다. 192 | - 커넥션에 모든 메시지가 자신의 길이 정보를 정확히 가지고 있을 때에만 커넥션을 지속시킬 수 있다. 193 | - HTTP/1.1 프락시는 클라이언트와 서버 각각에 대해 별도의 지속 커넥션을 맺고 관리해야한다. 194 | - 서버의 과부하를 방지하기 위해서, 넉넉잡아 두 개의 지속 커넥션만을 유지해야 한다. 195 | 196 | ## 4.6 파이프라인 커넥션 197 | 198 | 파이프라인 커넥션은 keep-alive 커넥션의 성능을 더 높여준다. 199 | 여러 개의 요청은 응답이 도착하기 전까지 큐에 쌓인다. 200 | 첫 번째 요청이 전달되면 두 번째, 세 번째 요청이 전달되는데, 이는 대기 시간이 긴 네트워크 상황에서 네트워크상의 왕복으로 인한 시간을 줄여서 성능을 높여준다. 201 | 202 | - HTTP 응답은 요청 순서와 같게 와야한다. 203 | - HTTP 클라이언트는 커넥션이 지속 커넥션인지 확인하기 전까지는 파이프라인을 이어서는 안된다. 204 | - HTTP 클라이언트는 POST 요청같이 반복해서 보낼 경우 문제가 생기는 요청은 파이프라인을 통해 보내면 안 된다. 205 | 206 | ## 4.7 커넥션 끊기에 대한 미스터리 207 | ### 4.7.1 마음대로 커넥션 끊기 208 | 209 | 클라이언트, 서버, 프락시는 언제든지 TCP 전송 커넥션을 끊을 수 있다. 210 | 하지만 서버가 그 유휴상태에 있는 커넥션을 끊는 시점에, 서버는 클라이언트가 데이터를 전송하지 않을 것이라고 확신하지 못한다. 211 | 클라이언트는 그 요청 메시지를 보내는 도중에 문제가 생긴다. 212 | 213 | ### 4.7.2 Content-Length 와 Truncation 214 | 215 | 각 HTTP 응답은 본문의 정확한 크기 값을 가지는 Content-Length 헤더를 가지고 있어야 한다. 216 | 클라이언트나 프락시가 커넥션이 끊어졌다는 HTTP 응답을 받은 후, 실제 전달된 엔터티의 길이와 Content-Length 의 값이 일치하지 않거나 Content-Length 자체가 존재하지 않으면 217 | 수신자는 데이터의 정확한 길이를 서버에게 물어봐야 한다. 218 | 219 | ### 4.7.3 커넥션 끊기의 허용, 재시도, 멱등성 220 | 221 | 커넥션은 에러가 없더라도 언제든 끊을 수 있다. 222 | 커넥션이 끊어 졌을 때에 적절히 대응할 수 있는 준비가 되어 있어야한다. 223 | 한 번 혹은 여러 번 실행됐는지에 상관없이 같은 결과를 반환한다면 트랜잭션은 멱등하다고 한다. 224 | 비멱등인 메서드나 순서에 대해 에이저느가 요청을 다시 보낼 수 있도록 기능을 제공한다 하더라도 자동으로 재시도하면 안 된다. 225 | 226 | ### 4.7.4 우아한 커넥션 끊기 227 | 228 | TCP 커넥션의 양쪽에는 데이터를 읽거나 쓰기 위한 입려 큐와 출려 큐가 있다. 229 | 230 | - 전체 끊기와 절반 끊기: close() 를 호출하면 TCP 커넥션의 입력 채널과 출력 채널의 커넥션을 모두 끊는다. 개별적으로 끊을라면 shutdown() 을 호출하면 된다. 231 | - TCP 끊기와 리셋 에러: 단순한 HTTP 애플리케이션은 전체 끊기만 사용할 수 있다. 하지만 파이프라인 지속 커넥션을 사용할 때, 기기들에 예쌍치 못한 쓰기 에러를 발생하는 것을 예방하기 위해 절반 끊기를 사용해야한다. 232 | - 우아하게 커넥션 끊기: 자신의 출력 채널을 먼저 끊고 다른 쪽에 있는 기기의 출력 채널이 끊기는 것을 기다리는 것이다 233 | 234 | 235 | 236 | 237 | 238 | 239 | 240 | 241 | 242 | -------------------------------------------------------------------------------- /chapter_05/README.md: -------------------------------------------------------------------------------- 1 | # [5장] HTTP:아키텍처 / 웹서버 2 | 3 | - 마감일: 9월 9일 월요일 자정 4 | - todo: 5장 정리본, 4장 pr 리뷰 5 | 6 | ## 정리 글 링크 7 | 8 | 1. 고석진 9 | 2. 고현주 - [II.HTTP 아키텍처\_01.웹 서버](https://dev-junior.tistory.com/9) 10 | 3. 김나영 - [웹 서버](https://feel5ny.github.io/2019/09/07/HTTP_005/) 11 | 4. 김준형 - [HTTP - 5장](https://junjangsee.github.io/2019/09/08/network/network-05/) 12 | 5. 류지환 - [5장 웹 서버 : 웹 서버 아키텍처](https://www.notion.so/jeewhan/5-67c1246d4f064dbfa407a6af2cbf8006) 13 | 6. 이강호 14 | 7. 이동규 - [HTTP 완벽 가이드 5 - web server](https://github.com/brainbackdoor/bbd-http-web/blob/master/docs/server/README.md) 15 | 8. 이보라 16 | 9. 한재우 - [HTTP 완벽가이드 5장](https://bebiangel.github.io/2019/09/08/http-guide-chap5/) 17 | 18 | ## 4장 정리글 리뷰 team 19 | 20 | - 고현주, 김준형 21 | - 고석진, 류지환 22 | - 홍유정, 김나영 23 | - 이보라, 한재우 24 | - 이강호, 이동규 25 | -------------------------------------------------------------------------------- /chapter_05/chap5_고석진.md: -------------------------------------------------------------------------------- 1 | # HTTP 2 | 3 | ## 웹서버 4 | 5 | "웹서버"라는 용어는 웹 서버 소프트웨어와 웹페이지 제공에 특화된 장비 양쪽 모두를 가리킵니다. 6 | 모든 웹서버는 리소스에 대한 HTTP 요청을 받아서 콘텐츠를 클라이언트에게 돌려줍니다. 7 | 8 | ## 5.1.1 웹 서버 구현 9 | 10 | 웹 서버는 HTTP 및 그와 관련된 TCP 처리를 구현한 것 입니다. 자신이 제공하는 리소스를 관리하고 웹 서버를 설정, 통제, 확장하기 위한 관리 기능을 제공합니다. 11 | TCP 커넥션 관리에 대한 책임을 운영체제와 나눠 갖습니다. 12 | 13 | ## 5.1.2 다목적 소프웨어 웹 서버 14 | 15 | 다목적 소프트웨어 웹 서버는 네트워크에 연결된 표준 컴퓨터 시스템에서 동작합니다. 16 | 아파치, W3C의 직소 같은 오픈 소스 소프트웨어를 사용할 수도 있고, 마이크로소프트나 아이플래닛의 웹 서버 같은 상용 소프트웨어를 이용할 수도 있습니다. 17 | 18 | ## 5.1.3 임베디드 웹 서버 19 | 20 | 일반 소비자용 제품에 내장될 목적으로 만들어진 작은 웹 서버입니다. 21 | 22 | ## 5.3 웹 서버가 하는 일 23 | 24 | 1. 커넥션을 맺습니다. 25 | 2. 요청을 받습니다. 26 | 3. 요청을 처리합니다. 27 | 4. 리소스에 접근합니다. 28 | 5. 응답을 만듭니다. 29 | 6. 응답을 보냅니다. 30 | 7. 트랜잭션을 로그로 남깁니다. 31 | 32 | ## 5.4 클라이언트 커넥션 수락 33 | 34 | 클라이언트가 이미 서버에 대해 열려있는 지속적 커넥션을 갖고 있다면, 클라이언트는 요청을 보내기 위해 그 커넥션을 사용할 수 있습니다. 35 | 그렇지 않다면 새 커넥션을 열 필요가 있습니다. 36 | 37 | ## 5.4.1 새 커넥션 다루기 38 | 39 | 클라이언트가 웹 서버에 TCP 커넥션을 요청하면. 웹 서버는 커넥션을 맺고 TCP 커넥션에서 IP 주소를 추출하여 커넥션 맞은편에 어떤 클라이언트가 있는지 확인합니다. 40 | 커넥션이 맺어지면 서버는 커넥션 목록에 추가합니다. 클라이언트의 IP 나 호스트명이 인가되지 않은 악의적인 것으로 판단된다면 언제든 커넥션을 끊을 수 있습니다. 41 | 42 | ## 5.4.2 클라이언트 호스트 명 식별 43 | 44 | 웹 서버는 역방향 DNS 를 사용하여 클라이언트의 IP 주소를 클라이언트의 호스트 명으로 변환하도록 설정되어 있습니다. 45 | 클라이언트 호스트명을 구체적인 접근 제어와 로깅을 위해 사용할 수 있습니다. 46 | 호스트명 룩업은 많은 시간이 걸릴 수 있어 웹 트랜잭션을 느려지게 할 수 있습니다. 47 | 48 | ## 5.4.3 ident 를 통해 클라이언트 사용자 알아내기 49 | 50 | ident 프로토콜은 서버에게 어떤 사용자 이름이 HTTP 커넥션을 초기화했는지 찾아낼 수 있게 해줍니다. 51 | 널리 쓰이는 일반 로그 포맷의 두 번째 필드는 각 HTTP 요청의 ident 사용자 이름을 담고있습니다. 52 | 53 | ident 는 조직 내부에서는 잘 사용할 수 있지만, 공공 인터넷에서는 여러 이유로 잘 동작하지 않습니다. 54 | 55 | - 많은 클라이언트 PC 는 identd 신원확인 프로토콜 데몬 소프트웨어를 실행하지 않습니다. 56 | - HTTP 트랜잭션을 유의미하게 지연시킵니다. 57 | - 방화벽이 ident 트래픽을 막는 경우가 많습니다. 58 | - ident 프로토콜은 아전하지 않고 조작하기 쉽습니다. 59 | - 가상 IP 주소를 잘 지원하지 않습니다. 60 | - 프라이버시 침해에 우려가 있습니다. 61 | 62 | ## 5.5 요청 메세지 수신 63 | 64 | 커넥션에 데이터가 도착하면, 웹 서버는 네트워크 커넥션에서 데이터를 읽어 들이고 파싱하여 요청 메시지를 구성합니다. 65 | 66 | - 요청줄을 파싱하여 요청 메서드, 지정된 리소스의 식별자, 버전 번호를 찾습니다. 67 | - 메세지 헤더들을 읽습니다. 68 | - 헤더의 끝을 의미하는 CRLF로 끝나는 빈 줄을 찾습니다. 69 | - 요청 본문이 있다면, 읽어들입니다. 70 | 71 | ## 5.5.1 메시지의 내부 표현 72 | 73 | 몇몇 웹 서버는 요청 메시지를 쉽게 다룰 수 있도록 내부의 자료 구조에 저장합니다. 헤더는 속도가 빠른 룩업 테이블에 저장되어 각 필드에 신속하게 접근 할 수 있습니다. 74 | 75 | ## 5.5.2 커넥션 입력/출력 처리 아키텍쳐 76 | 77 | 웹 서버들은 항상 새 요청을 주시하고 있습니다. 78 | 79 | - 단일 스레드 웹서버: 한 번에 하나씩 요청을 처리합니다. 트랜잭션이 완료되면, 다음 커넥션이 처리됩니다. 처리 도중에 다른 커넥션은 무시됩니다. 성능 문제가 있기 때문에 로드가 적은 서버나 진단 서버 같은 간단한 작업에 적합합니다. 80 | 81 | - 멀티 프로세스와 멀티 스레드 웹 서버: 여러 요청을 동시에 처리하기 위해 여러 개의 프로세스 혹은 고효율 스레드를 할당합니다. 수많은 프로세스나 스레드는 너무 많은 메모리나 시스템 리소스를 소비합니다. 최대 갯수에 제한을 거는 것이 좋습니다. 82 | 83 | - 다중 I/O 서버: 대량의 커넥션을 지원하기 위해, 많은 웹 서버는 다중 아키텍처를 채택했습니다. 모든 커넥션은 동시에 활동을 감시당합니다. 커넥션의 상태가 바뀌면 해당 커넥션에 대해 작은 양의 처리가 수행됩니다. 작업 수행은 실제로 해야 할 일이 있을 때만 수행됩니다. 리소스를 낭비하지 않습니다. 84 | 85 | - 다중 멀티스레드 웹 서버: 몇몇 시스템은 자신의 컴퓨터 플랫폼에 올라와 있는 CPU 여러 개의 이점을 살리기 위해 멀티스레딩과 다중화를 결합합니다. 열려있는 커넥션을 감시하고 커넥션에 대해 조금씩 작업합니다. 86 | 87 | ## 5.6 요청 처리 88 | 89 | 요청을 받으면 요청으로부터 메서드, 리소스, 헤더, 본문을 얻어내어 처리합니다. 90 | 91 | ## 5.7 리소스의 매핑과 접근 92 | 93 | 웹 서버가 클라이언트에 콘텐츠를 전달하려면, 그전에 요청 메시지의 URI에 대응하는 알맞은 콘텐츠나 콘텐츠 생성기를 웹서버에서 찾아서 식별해야합니다. 94 | 95 | ## 5.7.1 Docroot 96 | 97 | 리소스 매칭의 가장 단순한 형태는 요청 URI 를 웹 서버의 파일 시스템 안에 있는 파일 이름으로 사용하는 것입니다. 98 | 파일 시스템의 특별한 폴더를 웹 콘텐츠를 위해 예약해둡니다. 이 폴더를 루트 또는 Docroot 라고 부릅니다. 99 | 100 | - 가상 호스팅된 docroot: URI나 Host 헤더에서 얻은 IP 주소나 호스트 명을 이용해 올바른 문서 루트를 식별합니다. 하나의 웹 서버 위에서 두 개의 사이트가 분리된 컨텐츠를 갖고 호스팅 되도록 할 수 있습니다. 101 | 102 | - 사용자 홈 디텍터리 docroots: /, ~ 다음에 사용자 이름이 오는 것으로 시작하는 URI 는 사용자의 개인 문서 루트를 가리킵니다. 103 | 104 | ## 5.7.2 디렉터리 목록 105 | 106 | 파일이 아닌 디렉터리를 가리키는 요청을 받을 수도 있습니다. 대부분의 웹 서버는 디렉터리 URL 을 요청했을 때 다음과 같이 몇 가지 다른 행동을 취하도록 설정 할 수 있습니다. 107 | 108 | - 에러를 반환합니다. 109 | - 디렉터리 대신 특별한 색인 파일을 반환합니다. 110 | - 디렉터리 내용을 담은 HTML 페이지를 반환합니다. 111 | 112 | ## 5.7.3 동적 콘텐츠 리소스 맵핑 113 | 114 | 웹 서버는 URI를 동적 리소스에 매핑할 수도 있습니다. 애플리케이션 서버라고 불리는 것들은 웹 서버를 복잡한 백엔드 애플리케이션과 연결하는 일을 합니다. 115 | 애플리케이션 서버는 그에 대한 동적 콘텐츠 생성 프로그램이 어디에 있는지, 그리고 어떻게 프로그램을 실행하는지 알려줄 수 있어야 합니다. 116 | 117 | ## 5.7.4 서버사이드 인클루드 118 | 119 | 서버는 콘텐츠에 변수 이름이나 내장된 스크립트가 될 수 있는 어떤 특별한 패턴이 있는지 검사를 받습니다. 120 | 특별한 패턴을 변수 값이나 실행 가능한 스크립트의 출력 값으로 치환됩니다. 121 | 122 | ## 5.7.5 접근 제어 123 | 124 | 리소스에 접근 제어를 할당 할 수 있습니다. 125 | 126 | ## 5.8 응답 만들기 127 | 128 | 리소스를 식별하면, 요청 메서드로 서술되는 동작을 수행한 뒤 응답 메세지를 반환합니다. 129 | 응답 메세지는 상태 코드, 헤더, 본문을 포함합니다. 130 | 131 | ## 5.8.1 응답 엔터티 132 | 133 | 응답 본문 생성한다면, 그 내용을 메시지와 함께 돌려보냅니다. 다음의 내용을 포함합니다. 134 | 135 | - MIME 타입을 서술하는 Content-Type 헤더 136 | - 길이를 서술하는 Content-Length 헤더 137 | - 실제 응답 본문의 내용 138 | 139 | ## 5.8.2 MIME 타입 결정하기 140 | 141 | 서버에게는 응답 본문의 MIME 타입을 결정해야 하는 책임이 있습니다. 142 | 143 | - mime.types: MIME 타입을 나타내기 위해 파일 이름의 확장자를 사용 할 수 있습니다. 리소스의 MIME 타입을 계산하기 위해 확장자별 MIME 타입이 담겨 있는 파일을 탐색합니다. 144 | - 매직 타이핑: 파일의 내용을 검사해서 알려진 패턴에 대한 테이블에 해당하는 패턴이 있는지 찾아 볼 수 있습니다. 145 | - 유형 명시: 특정 파일이나 디렉터리 안의 파일들이 파일 확장자나 내용에 상관없이 어떤 MIME 타입을 갖도록 설정할 수 있습니다. 146 | - 유형 협상: 리소스가 여러 종류의 문서 형식에 속하도록 설정할 수 있습니다. 147 | 148 | ## 5.8.3 리다이렉션 149 | 150 | 성공 메세지 대신 리다이렉션 응답을 반환할 수 있습니다. 151 | 152 | - 리소스가 옮겨진 경우: 리소스 이름이 바뀌었다고 클라이언트에게 새로운 북마크를 갱신 할 수 있다고 알려줍니다. 301 moved Permanently 상태 코드를 반환합니다. 153 | - 임시로 리소스가 옮겨진 경우: 나중에는 원래 URL로 찾아오고 북마크도 갱신하지 않기를 원합니다. 303 see other, 307 temporary redirect 상태 코드를 반환합니다. 154 | - URL 증강: 문맥 정보를 포함시키기 위해 재 작성된 URL로 리다이렉트합니다. 303 see other, 307 temporary redirect 상태 코드를 반환합니다. 155 | - 부하 균형: 부하가 덜 걸린 서버로 리다이렉트 할 수 있습니다. 303 see other, 307 temporary redirect 상태 코드를 반환합니다. 156 | - 친밀한 다른 서버가 있을 때: 어떤 사용자에 대한 정보를 가질 수 있습니다. 클라이언트에 대한 정보를 갖고 있는 다른 서버로 리다이렉트 할 수 잇습니다. 303 see other, 307 temporary redirect 상태 코드를 반환합니다. 157 | - 디렉터리 이름 정규화: URI 를 요청하는데 / 을 빠뜨렸다면 정상 작동할 수 있도록 / 를 추가한 URI 로 리다이렉트합니다. 158 | 159 | ## 5.9 응답 보내기 160 | 161 | 서버는 커넥션 상태를 추적해야 하며 지속적인 커넥션은 특별히 주의해서 다룰 필요가 있습니다. 162 | 지속적인 커넥션이라면, 서버가 Content-Length 헤더를 바르게 계산하기 위해서 특별한 주의를 필요로 하는 경우나, 클라이언트 응답이 언제 끝나는지 알 수 없는 경우에 163 | 커넥션은 열린 상태를 유지합니다. 164 | 165 | ## 5.10 로깅 166 | 167 | 트랜잭션이 어떻게 수행되었는지에 대한 로그를 로그 파일에 기록합니다. 168 | -------------------------------------------------------------------------------- /chapter_06/README.md: -------------------------------------------------------------------------------- 1 | # [6장 - 1] HTTP:아키텍처 / 프락시 chap1 - chap5 2 | 3 | - 마감일: 9월 22일 월요일 자정 4 | - todo: 6장 chap1 - chap5까지의 정리본, 5장 pr 리뷰 5 | 6 | ## 정리 글 링크 7 | 8 | 1. 고석진 9 | 2. 고현주 - [HTTP 6-1 프락시](https://dev-junior.tistory.com/10) 10 | 3. 김나영 - [프록시1](https://feel5ny.github.io/2019/09/22/HTTP_006/) 11 | 4. 김준형 - [HTTP 6-1](https://junjangsee.github.io/2019/09/22/network/network-06/) 12 | 5. 류지환 13 | 6. 이강호 - [chapter6 정리](https://www.notion.so/Chapter-6-f3805c1d43b54c11b9a03c8782b273fb) 14 | 7. 이동규 - [HTTP 완벽가이드 스터디 #6 -a Proxy Server](https://brainbackdoor.tistory.com/128) 15 | 8. 이보라 - [HTTP 완벽가이드 6장](./chap6_이보라.md) 16 | 9. 한재우 - [HTTP 완벽가이드 6장](https://bebiangel.github.io/2019/09/22/http-guide-chap6/) 17 | 18 | ## 5장 정리글 리뷰 team 19 | 20 | - 고현주, 이동규 21 | - 고석진, 한재우 22 | - 홍유정, 이강호 23 | - 김준형, 류지환 24 | - 이보라, 김나영, 이혜승 25 | -------------------------------------------------------------------------------- /chapter_06/chap6_고석진.md: -------------------------------------------------------------------------------- 1 | # HTTP 2 | 3 | ## 프락시 4 | 5 | 프락시는 클라이언트와 서버 사이에 위치하여 그들 사이의 HTTP 메시지를 정리하는 중개인처럼 동작합니다. 6 | 7 | ## 6.1 웹 중개자 8 | 9 | 클라이언트 입장에서 프락시 서버는 트랜잭션을 수행하는 중개인 입니다. 10 | 프락시가 있다면 클라이언트는 프락시 서버와 없다면 직접 HTTP 서버와 통신합니다. 11 | HTTP 프락시를 만든다면 클라이언트와 서버 양쪽 규칙 모두를 주의 깊게 따라야 합니다. 12 | 13 | ### 6.1.1 개인 프락시와 공유 프락시 14 | 15 | 하나의 클라이언트만 사용하는 프락시를 개인 프락시, 여러 클라이언트가 사용하는 프락시는 공용 프락시라고 부릅니다. 16 | 17 | - 공용 프락시: 대부분의 프락시는 공용이며 공유된 프락시 입니다. 중앙 집중형 프락시를 관리하는게 더 비용효율이 높고 쉽습니다. 18 | - 개인 프락시: 클라이언트 컴퓨너테어 직접 실행되는 형태로 종종 사용되고있습니다. 19 | 20 | ### 6.1.2 프락시 대 게이트웨이 21 | 22 | 프락시는 같은 프로토콜을 사용하는 둘 이상의 애플리케이션을 연결합니다. 23 | 게이트웨이는 서로 다른 프로토콜을 사용하는 둘 이상을 연결하고 서로 다른 프로토콜로 말하더라도 트랙잭션을 완료할 수 있또록 도와주는 프로토콜 변환기처럼 동작합니다. 24 | 25 | ## 6.2 왜 프락시를 사용하는가 ? 26 | 27 | 보안을 개선, 성능 향상, 비용 절약, 모든 HTTP 트래픽을 들여다보고 건드릴 수 있습니다. 28 | 부가적인 가치를 주는 여러 유용한 웹 서비스를 구현하기 위해 사용합니다. 29 | 30 | - 보안 방화벽: 보안을 강화하기 위해 프락시 서버를 사용합니다. 조직 안에 들어오거나 나가는 프로토콜의 흐름을 네트워크의 한 지점에서 통제합니다. 31 | - 웹 캐시: 인기 있는 문서의 로컬 사본을 관리하고 해당 문서에 대한 요청이 오면 빠르게 제공합니다. 32 | - 대리 프락시: 웹 서버인 것처럼 위장합니다. 대리 혹은 리버스 프락시라고 불립니다. 이는 진짜 웹 서버 요청을 받지만 웹 서버와는 달리 요청 받은 콘텐츠의 위치를 찾아내기 위해 다른 서버와 커뮤니케이션을 시작합니다. 웹 서버의 성능 개선을 위해 사용되고 콘텐츠 라우팅 기능과 결합되어 주문형 복제 콘텐츠의 분산 네트워크를 만들기 위해 사용될 수 있습니다. 33 | - 익명화 프락시: HTTP 메시지에서 신원을 식별할 수 있는 (IP 주소, Form 헤더, Referer 헤더, 쿠키, 세션 아이디) 등을 제거함으로써 개인 정보 보호와 익명성 보장에 기여합니다. 34 | 35 | ## 6.3 프락시는 어디에 있는가 ? 36 | ### 6.3.1 프락시 서버 배치 37 | 38 | - 출구 프락시: 로컬 네트워크와 더 큰 인터넷 사이를 오가는 트래픽을 제어하기 위해 프락시를 로컬 네트워크의 출구에 박아 넣을 수 있습니다. 39 | - 접근 프락시: 모든 요청을 종합적으로 처리하기 위해 프락시는 ISP 접근 지점에 위치하기도 합니다. 40 | - 대리 프락시: 웹 서버의 바로 앞에 위치하여 웹 서버로 향하는 모든 요청을 처리하고 필요할 때만 웹 서버에게 자원을 요청 할 수 있다. 보안 기능을 추가하거나 웹 서버 캐시를 느린 웹 서버의 앞에 놓음으로써 성능을 개선할 수도 있습니다. 41 | - 네트워크 교환 프락시: 캐시를 이용해 인터넷 교차로의 혼잡을 완화하고 트래픽 흐름을 감시하기 위해 네트워크 사이의 인터넷 피어링 교환 지점들에 놓을 수 있습니다. 42 | 43 | ### 6.3.2 프락시 계층 44 | 45 | 메시지는 원 서버에 도착할 때 까지 프락시와 프락시를 거쳐 이동합니다. 46 | 프락시 계층에서 프락시 서버들은 부모와 자식의 관계를 갖습니다. 인바운드 (서버와 가까운 쪽) 을 부모, 아웃바운드 (클라이언트 가까운 쪽) 을 자식이라고 부릅니다. 47 | 48 | ### 프락시 계층 콘텐츠 라우팅 49 | 50 | 프락시 계층은 정적입니다. 프락시 1은 항상 2로 2는 3으로 보냅니다. 그러나 계층이 반드시 정적이어야 하는 것은 아닙니다. 51 | 52 | - 부하 균형: 자식 프락시는 부하를 분산하기 위해 현재 부모들의 작업략 수준에 근거하여 부모 프락시를 고릅니다. 53 | - 지리적 인접성에 근거한 라우팅: 자식 프락시는 원 서버의 지역을 담당하는 부모를 선택할 수도 있습니다. 54 | - 프로토콜/타입 라우팅: URI 에 근거하여 다른 부모나 원 서버로 라우팅 할 수 있습니다. 55 | 56 | ### 6.3.3 어떻게 프락시가 트래픽을 처리하는가 57 | 58 | - 클라이언트를 수정: 많은 웹 클라이언트들은 수동 혹은 자동 프락시 설정을 지원합니다. 프락시 설정이 되어 있다면, HTTP 요청을 원 서버가 아닌 프락시 서버로 보냅니다. 59 | - 네트워크를 수정: 네트워크 인프라를 가로채서 웹 트래픽을 프락시로 가도록 조정할 수 있습니다. 60 | - DNS 이름 공간을 수정: DNS 이름 테이블을 수동으로 편집하거나 사용할 적절한 프락시나 서버를 계산해주는 특별한 동적 DNS 서버를 이용해서 조정될 수 있습니다. 61 | - 웹 서버를 수정: 웹 서버는 HTTP 리다이렉션 (응답 코드 305) 를 클라이언트에게 돌려줌으로써 요청을 프락시로 리다이렉트 하도록 설정할 수 있습니다. 62 | 63 | ## 6.4 클라이언트 프락시 설정 64 | 65 | - 수동 설정: 프락시 사용을 명시적으로 설정합니다. 66 | - 브라우저 기본 설정: 브라우저를 소비자에게 전달하기 전에 프락시를 미리 설정해 놓을 수 있습니다. 67 | - 프락시 자동 설정: 자바스크립트 프락시 자동 설정파일에 대한 URI를 제공할 수 있습니다. 68 | - WPAD 프락시 발견: 자동설정 파일을 다운받을 수 있는 '설정 서버'를 자동으로 찾아주는 웹 프락시 자동 발견 프로토콜을 제공합니다. 69 | 70 | ## 6.5 프락시 요청의 미묘한 특징들 71 | 72 | ### 6.5.1 프락시 URI 는 서버 URI 랑 다르다 73 | 74 | 클라이언트가 웹 서버로 요청을 보낼 때 요청중은 다음의 예와 같이 스킴, 호스트, 포트번호가 없는 부분 URI 를 가집니다. 75 | 76 | ```text 77 | GET /index.html HTTP/1.0 78 | User-Agent: SuperBrowserv1.3 79 | ``` 80 | 81 | 클라이언트가 프락시로 요청을 보낼 때, 요청줄은 완전한 URI 를 가집니다. 82 | 83 | ```text 84 | GET http://www.marys-antiques.com/index.html HTTP/1.0 85 | User-Agent: SuperBrowser v1.3 86 | ``` 87 | 88 | 단일 서버는 자신의 호스트 명과 포트번호를 알고 있으므로, 클라이언트는 불필요한 정보 발송을 피하기 위해 부분 URI 만 사용했었습니다. 89 | 프락시는 목적지 서버와 커넥션을 맺어야 하기 때문에 완전한 URI 를 요구합니다. 90 | 91 | ### 6.5.2 가상 호스팅에서 일어나는 같은 문제 92 | 93 | - 명시적인 프락시는 요청 메시지가 완전한 URI 를 갖도록 함으로써 문제를 해결합니다. 94 | - 가상으로 호스팅 되는 웹 서버는 호스트와 포트에 대한 정보가 담겨 있는 HOST 헤더를 요구합니다. 95 | 96 | ### 6.5.3 인터셉트 프락시는 부분 URI 를 받는다 97 | 98 | 몇몇 프락시는 클라이언트에게 보이지 않기 때문에 자신이 프락시와 대화하고 있음을 항상 알고 있지 못합니다. 99 | 클라이언트는 자신이 웹 서버와 대화하고 있다고 생각하고 완전한 URI 를 보내지 않을 수도 있습니다. 100 | 101 | ### 6.5.4 프락시는 프락시 요청과 서버 요청을 모두 다룰 수 있다 102 | 103 | 트래픽이 프락시 서버로 리다이렉트 될 수 있는 여러 가지 방법이 존재하기 때문에, 다목적 프락시 서버는 요청 메시지의 완전한 URI 와 부분 URI 를 모두 지원해야 합니다. 104 | 105 | - 완전한 URI 가 주어졌다면, 프락시는 그 주소를 이용해야 합니다. 106 | - 부분 URI 가 주어졌고 Host 헤더가 있다면, Host 헤더를 이용해 원 서버의 이름과 포트번호를 알아냅니다. 107 | - 부분 URI 이지만 Host 헤더가 없다면 108 | - 프락시가 원 서버를 대신하는 대리 프락시라면, 프락시에 실제 서버의 주소와 포트번호가 설정되어 있을 수 있습니다. 109 | - 인터셉터 프락시가 원 IP주소와 포트번호를 사용할 수 있도록 해두었다면 사용할 수 있습니다. 110 | 111 | ### 6.5.5 전송 중 URI 변경 112 | 113 | 요청 URI 의 변경에 많은 신경을 써야합니다. 사소한 URI 변경이라도 다운스트림 서버와 상호운용성 문제를 일으킬 수 있습니다. 114 | 115 | ### 6.5.6 URI 클라이언트 자동확장과 호스트명 분석 116 | 117 | 브라우저는 프락시의존재 여부에 따라 요청 URI 를 다르게 분석합니다. 프락시가 없다면 사용자가 타이핑한 URI 를 가지고 그에 대응하는 IP 주소를 찾습니다. 118 | 호스트가 발견되지 않는다면 119 | 120 | - www 접두사와 .com 접미사를 붙입니다. 121 | - 해석할 수 없는 URI 를 서드파티 사이트로 넘기기도 합니다. 오타 교정을 시도하고 사용자가 의도했을 URI 를 제시합니다. 122 | - DNS 는 사용자가 호스트 명의 앞부분만 입력하면 자동으로 도메인을 검색하도록 설정되어있습니다. 123 | 124 | ### 6.5.7 프락시 없는 URI 분석 125 | 126 | 1. 사용자가 'olaf' 를 브라우저 URI 창에 입력했다면, olaf 를 호스트명으로 http:// 를 기본 스킴으로 80 을 기본포트로 간주합니다. 127 | 2. 브라우저는 호스트 olaf 를 찾습니다. -> 실패합니다 128 | 3. 호스트명을 자동으로 확장한 후 DNS 에 www.olaf.com 의 주소 분해를 요청합니다. 129 | 4. www.olaf.com 으로 연결합니다. 130 | 131 | ### 6.5.8 명시적인 프락시를 사용할 때의 URI 분석 132 | 133 | 명시적인 프락시가 있는 경우 부분 호스트 명을 자동 확장하지 않습니다. 브라우저창에 olaf 라고 타이핑 했을때 프락시는 'http://olaf/' 라고 보냅니다. 134 | 135 | ### 6.5.9 인터셉터 프락시를 이용한 URI 분석 136 | 137 | 호스트명 분석은 보이지 않는 인터셉트 프락시와 함께일 때 달라집니다. 클라이언트의 입장에서 프락시는 존재하지 않는 것이기 때문입니다. 138 | DNS 가 성공할 때까지 호스트 명을 자동확장하는 브라우저를 사용할 때, 동작은 프락시가 아닌 서버의 경우 별 차이가 없습니다. 139 | 그러나 서버로의 커넥션이 만들어졌을 때는 차이가 발생합니다. 140 | 141 | 142 | 143 | 144 | 145 | 146 | 147 | 148 | -------------------------------------------------------------------------------- /chapter_06/chap6_이보라.md: -------------------------------------------------------------------------------- 1 | # 프락시 2 | - 목표 3 | - HTTP 프락시와 웹게이트를 비교하여 HTTP 프락시가 어떻게 배치되는지 그림으로 보여주면서 설명한다. 4 | - 프락시의 활용 방법 5 | - 프락시가 실제 네트워크에 어떻게 배치되는지, 트래픽이 어떻게 프락시 서버로 가는지 설명한다. 6 | - 브라우저에서 프락시를 사용하려면 어떻게 설정해야 하는지 보여준다. 7 | - HTTP 프락시 요청이 서버 요청과 어떻게 다른지, 프락시가 어떻게 브라우저의 동작을 미묘하게 바꾸는지 보여준다. 8 | - 일련의 프락시 서버들을 통과하는 메시지의 경로를 Via 헤더와 TRACE 메서드를 이용해 기록하는 방법을 설명한다. 9 | - 프락시에 기반한 HTTP 접근 제어를 설명한다. 10 | - 프락시가 어떻게 클라이언트와 서버 사이에서 각각의 다른 기능과 버전들을 지원하면서 상호작용 할 수 있는지 설명한다. 11 | 12 | 13 | ## 6.1 웹 중개자 14 | - 웹 프락시 서버 15 | - 클라이언트 입장: 트랜잭션을 수행하는 중개인 16 | - HTTP 프락시 서버는 웹 서버이기도 하고 웹 클라이언트이기도 하다. 17 | - 웹 클라이언트 관점에서 서버처럼 동작함: 요청 메시지를 받고 응답 메시지를 돌려줌 18 | - 웹 서버 관점에서 클라이언트처럼 동작함: 웹 요청 메시지를 보내고 웹 응답 메시지를 받음 19 | 20 | ![](../images/6-1.png) 21 | 22 | [그림 6-1 프락시는 서버이면서 동시에 클라이언트여야 한다.] 23 | 24 | ### 6.1.1 개인 프락시와 공유 프락시 25 | - 개인 프락시 26 | - 하나의 클라이언트가 독점적으로 사용하는 프락시 27 | - 공유 프락시 28 | - 여러 클라이언트가 공유하는 프락시 29 | - 대부분의 프락시가 공유 프락시임 30 | 31 | ### 6.1.2 프락시 vs. 게이트웨이 32 | - 프락시 33 | - 같은 프로토콜을 사용하는 둘 이상의 애플리케이션을 연결함 34 | - 게이트웨이 35 | - 서로 다른 프로토콜을 사용하는 둘 이상의 애플리케이션을 연결함 36 | - 프로토콜이 서로 다르더라도 서로 간의 트랜잭션을 완료할 수 있도록 해주는 프로토콜 변환기처럼 동작함 37 | - 실제 둘의 차이는 모호함 38 | 39 | ![](../images/6-2.png) 40 | 41 | [그림 6-2 프락시는 같은 프로토콜로 말하고 게이트웨이는 서로 다른 프로토콜을 연결해준다.] 42 | 43 | 44 | ## 6.2 왜 프락시를 사용하는가? 45 | - 실질적이고 유용한 것이라면 무슨 일이든 함 46 | - 보안, 성능, 비용, 트래픽 감시 및 처리 등의 기능을 함 47 | - 예시 48 | - 어린이 필터: 성인 콘텐츠 차단 49 | - 문서 접근 제어자: 웹 리소스에 대한 단일 접근 제어 전략을 구사, 감사 추적 50 | - 보안 방화벽: 조직 안에 들어오거나 나가는 응용 레벨 프로토콜의 흐름을 네트워크의 한 지점에서 통제함 51 | - 웹 캐시: 인기 있는 문서의 로컬 사본을 관리하고 해당 문서에 대한 요청이 오면 빠르게 제공함 52 | - 대리 프락시(Surrogate): 웹 서버인 것처럼 위장함. 웹 요청을 받지만, 웹 서버와는 달리 요청받은 콘텐츠의 위치를 찾아내기 위해 다른 서버와 커뮤니케이션함. 공용 콘텐츠에 대한 느린 웹 서버의 성능을 개선하기 위해 사용됨(서버 가속기) 53 | - 콘텐츠 라우터: 인터넷 트래픽 조건과 콘텐츠의 종류에 따라 요청을 특정 웹 서버로 유도함 54 | - 트랜스코더: 콘텐츠를 클라이언트에게 전달하기 전에 본문 포맷(데이터 표현 방식)을 수정함(트랜스코딩). 예: GIF to JPG, 파일 압축, 언어 변환 등 55 | - 익명화 프락시(Anonymizer): HTTP 메시지에서 신원을 식별할 수 있는 특성들(IP주소, From헤더, Referer헤더, 쿠키, URI 세션 아이디 등)을 제거해 개인 정보 보호와 익명성 보장에 기여함 56 | 57 | ![](../images/6-3.png) 58 | 59 | [그림 6-3 어린이를 보호하는 인터넷 필터] 60 | 61 | ![](../images/6-4.png) 62 | 63 | [그림 6-4 중앙화된 문서 접근 제어] 64 | 65 | ![](../images/6-5.png) 66 | 67 | [그림 6-5 보안 방화벽] 68 | 69 | ![](../images/6-6.png) 70 | 71 | [그림 6-6 웹캐시] 72 | 73 | [](../images/6-7.png) 74 | 75 | [그림 6-7 대리 프락시 웹캐시] 76 | 77 | [](../images/6-8.png) 78 | 79 | [그림 6-8 콘텐츠 라우팅] 80 | 81 | ![](../images/6-9.png) 82 | 83 | [그림 6-9 콘텐츠 트랜스코더] 84 | 85 | ![](../images/6-10.png) 86 | 87 | [그림 6-10 익명화 프락시] 88 | 89 | 90 | ## 6.3 프락시는 어디에 있는가? 91 | - 프락시가 어떻게 네트워크에 배치되는가? 92 | - 어떻게 프락시의 연쇄가 계층을 이루는가? 93 | 94 | ### 6.3.1 프락시 서버 배치 95 | - 프락시가 어떻게 네트워크에 배치되는가? 96 | - 사용 목적에 따라 배치 방법이 달라짐 97 | - 출구 프락시 98 | - 접근(입구) 프락시 99 | - 대리 프락시 100 | - 네트워크 교환 프락시 101 | 102 | ![](../images/6-11.png) 103 | 104 | [그림 6-10 (a) 개인 LAN 출구 프락시, (b) ISP 접근 프락시, (c) 대리 프락시, (d) 네트워크 교환 프락시] 105 | 106 | ### 6.3.2 프락시 계층 107 | - 어떻게 프락시의 연쇄가 계층을 이루는가? 108 | - 프락시가 이루는 연쇄 구조 109 | - 다음번 인바운드 프락시(서버에 가까운 쪽)를 부모라고 부르고 다음번 아웃바운드 프락시(클라이언트에 가까운 쪽)를 자식이라고 부름 110 | 111 | ![](../images/6-12.png) 112 | 113 | [그림 6-12 3단계 프락시 계층. 프락시 2는 프락시 3의 자식 프락시이며, 프락시 3은 프락시 2의 부모 프락시임] 114 | 115 | - 프락시 계층은 정적일 수도 있고 동적일 수도 있음 116 | - 동적 부모 선택의 유형 117 | - 부하 균형 118 | - 지리적 인접성에 근거한 라우팅 119 | - 프로토콜/타입 라우팅 120 | - 유료 서비스 가입자를 위한 라우팅 121 | 122 | ![](../images/6-13.png) 123 | 124 | [그림 6-13 프락시 계층은 동적으로 매 요청에 따라 바뀔 수 있다.] 125 | 126 | ### 6.3.3 어떻게 프락시가 트래픽을 처리하는가 127 | - 클라이언트 트래픽이 프락시로 가도록 만드는 방법 128 | - 클라이언트를 수정함(a): 인터셉트 프락시 129 | - 네트워크를 수정함(b) 130 | - DNS 이름 공간을 수정함(c) 131 | - 웹 서버를 수정함(d): 웹 서버에서 HTTP 요청을 프락시로 리다이렉트 함 132 | 133 | ![](../images/6-143.png) 134 | 135 | [그림 6-14 웹 요청을 프락시로 보내는 다양한 방법] 136 | 137 | 138 | ## 6.4 클라이언트 프락시 설정 139 | - 모던 브라우저에서 프락시를 설정하는 방법 140 | - 수동 설정 141 | - 브라우저의 메뉴를 이용해 설정 142 | - 브라우저 기본 설정: 브라우저 벤더나 배포자가 설정 143 | - 프락시 자동 설정(Proxy auto-configuration, CPA): 자바스크립트 프락시 자동 설정 파일에 대한 URI를 제공함 144 | - 프락시 설정을 그때그때 상황에 맞게 계산해주는 자바스크립트 함수가 적절한 프락시 서버를 선택해줌 145 | - 자바스크립트 PAC 파일의 URI를 브라우저에 설정해주어야 함 146 | - *.pac 147 | - MIME 타입: 'application/x-ns-proxy-autoconfig' 148 | - 각 PAC파일엔 반드시 URI에 접근할 때 사용할 적절한 프락시 서버를 계산해주는 FindProxyForUrl(url, host)라는 함수를 정의해야 함 149 | - 웹 프락시 자동발견 프로토콜(Web Proxy Autodiscovery Protocol ,WPAD) 150 | - 브라우저에게 알맞는 PAC 파일을 자동으로 찾아주는 알고리즘 151 | 152 | 153 | # 6.5 프락시 요청의 미묘한 특징들 154 | - 프락시 요청의 URI는 서버 요청과 어떻게 다른가 155 | - 인터셉트 프락시와 리버스 프락시는 어떻게 서버 호스트 정보를 알아내기 어렵게 만드는가 156 | - URI 수정에 대한 규칙 157 | - 프락시는 브라우저의 똑똑한 URI 자동완성이나 호스트 명 확장 기능에 어떻게 영향을 주는가 158 | 159 | ### 6.5.1 프락시 URI는 서버 URI와 다르다 160 | - 웹 서버와 웹 프락시 메시지의 문법은 서로 같지만, 한 가지 예외가 있음 161 | - 클라이언트가 프락시 대신 서버로 요청을 보내면 요청의 URI가 달라짐 162 | - 클라이언트 to 웹서버: 요청 줄이 스킴, 호스트, 포트 번호가 없는 부분 URI임 163 | ``` 164 | GET /index.html HTTP/1.0 165 | USER-Agent: SuperBrowser v1.3 166 | ``` 167 | - 클라이언트 to 프락시: 요청줄이 완전한 URI임 168 | ``` 169 | GET http://www.marys-antique.com/index.html HTTP/1.0 170 | USER-Agent: SuperBrowser v1.3 171 | ``` 172 | 173 | ### 6.5.2 가상 호스팅에서 일어나는 같은 문제 174 | - 6.5.1에서 부분 URI가 쓰이는 것과 같은 문제임 175 | 176 | ### 6.5.3 인터셉트 프락시는 부분 URI를 받는다 177 | 178 | ### 6.5.4 프락시는 프락시 요청과 서버 요청을 모두 다룰 수 있다 179 | 180 | ### 6.5.5 전송 중 URI 변경 181 | 182 | ### 6.5.6 URI 클라이언트 자동확장과 호스트명 분석(Hostname Resolution) 183 | 184 | ### 6.5.7 프락시 없는 URI 분석(URI Resolution) 185 | 186 | ### 6.5.8 명시적인 프락시를 사용할 때의 URI 분석 187 | 188 | ### 6.5.9 인터셉트 프락시를 이용한 URI 분석 189 | 190 | 191 | ## 6.6 메시지 추적 192 | 프락시가 점점 흔해지면서, 서로 다른 스위치와 라우터를 넘나드는 IP 패킷의 흐름을 추적하는 것 못지않게 프락시를 넘나드는 메시지의 흐름을 추적하고 문제점을 찾아내는 것도 중요해짐 193 | 194 | ### 6.6.1 Via 헤더 195 | - Via 헤더 필드는 메시지가 지나는 각 중간 노드의 정보를 나열함. 메시지가 또 다른 노드를 지날 때마다, 중간 노드는 Via 목록의 끝에 추가됨. 196 | 197 | - Via 문법 198 | - 쉼표로 경유지 목록을 구분함 199 | - 각 경유지는 개별 프락시 서버나 게이트웨이 홈을 나타냄 200 | - 중간 노드의 프로토콜과 주소에 대한 정보가 담김 201 | 202 | ```text 203 | // 2개의 경유지에 대한 Via 헤더 204 | Via: 1.1 proxy-62.irenes-isp.net, 1.0 cache.joes-hardware.com 205 | ``` 206 | 207 | - 헤더 형식 구문 208 | ```text 209 | Via = "Via" ":" 1#( waypoint ) 210 | waypoint = ( received-protocol received-by [ comment ] ) 211 | received-protocol = [ protocol-name "/" ] protocol-version 212 | received-by = ( host [ ":" port ] ) | pseudonym 213 | ``` 214 | - 프로토콜 이름: 중개자가 받은 프로토콜 215 | - 프로토콜 버전: 수신한 메시지의 버전 216 | - 노드 이름: 중개자의 호스트와 포트 번호 217 | - 노드 코멘트: 중개자 노드를 서술하는 선택적인 코멘트 218 | - Via 요청과 응답 경로: 요청 메시지와 응답 메시지 모두 프락시를 지나므로 둘 다 Via 헤더를 가짐 219 | - Via와 게이트웨이 220 | - Server 헤더와 Via 헤더 221 | - Via가 개인정보 보호와 보안에 미치는 영향 222 | 223 | ### 6.6.2 TRACE 메서드 224 | 프락시 서버는 메시지가 전달될 때 메시지를 바꿀 수 있음(헤더가 추가되거나, 변경되거나, 삭제될 수 있으며, 본문이 다른 형식으로 변환될 수 있음). 변경 방식은 벤더마다 다른데, 이를 추적하기 위한 방법으로 TRACE 메서드를 사용함 225 | 226 | HTTP/1.1의 **TRACE 메서드**는 요청 메시지를 프락시의 연쇄를 따라가면서 어떤 프락시를 지나가고 프락시가 요청 메시지를 수정하는지 관찰/추적할 수 있게 해줌 --> 프락시 흐름을 디버깅하는 데 유용함 227 | 228 | TRACE 요청이 목적지 서버에 도착했을 때, 서버는 전체 요청 메시지를 HTTP 응답 메시지의 본문에 포함해 송신자에게 그대로 돌려보냄 229 | 230 | ![](../images/6-23.png) 231 | 232 | [그림 6-23 TRACE 응답은 수신한 요청 메시지를 그대로 돌려보낸다.] 233 | 234 | ## 6.7 프락시 인증 235 | 프락시는 접근 제어 장치로도 사용됨. HTTP는 사용자가 유효한 접근 권한 자격을 프락시에 제출하지 않는 한 콘텐츠에 대한 요청을 차단하는 프락시 인증이라는 메커니즘을 정의함 236 | 237 | ## 6.8 프락시 상호운용성 238 | 클라이언트, 서버, 벤더마다 HTTP 명세를 다르게 구현할 수 있음 239 | 240 | ### 6.8.1 지원하지 않는 헤더와 메서드 다루기 241 | 넘어오는 헤더 필드를 이해하지 못할 때 그대로 전달함 242 | 243 | ### 6.8.2 OPTIONS: 어떤 기능을 지원하는지 알아보기 244 | HTTP OPTIONS 메서드는 서버나 웹 서버의 특정 리소스가 어떤 기능을 지원하는지 클라이언트(혹은 프락시)가 알아볼 수 있게 해준다. 245 | 246 | ![](../images/6-26.png) 247 | 248 | [그림 6-26 서버가 지원하는 메서드를 찾기 위해 OPTIONS 사용하기] 249 | 250 | ### 6.8.3 Allow 헤더 251 | - Allow 엔터티 헤더 필드는 요청 URI에 의해 식별되는 자원에 대해 지원되는 메서드들이나 서버가 지원하는 모든 메서드를 열거함 252 | - Allow 헤더는 새 리소스가 지원했으면 하는 메서드를 추천하기 위해 요청 헤더로 사용될 수 있음 253 | 254 | -------------------------------------------------------------------------------- /chapter_07-2/README.md: -------------------------------------------------------------------------------- 1 | # [7장-2] HTTP:아키텍처 / 캐시 chap7 - chap12 2 | 3 | - 마감일: 10월 7일 월요일 자정 4 | - todo: 7장 chap7 - chap12까지의 정리본, 6장 pr 리뷰 5 | - 브랜치명 **chap7-2\_김나영** 6 | 7 | ## 정리 글 링크 8 | 9 | 1. 고석진 10 | 2. 고현주 - [7장 캐시_2](https://dev-junior.tistory.com/11) 11 | 3. 김나영 - [캐시의 원리와 제어방법](https://feel5ny.github.io/2019/10/05/HTTP_007-2/) 12 | 4. 김준형 - [HTTP 7-2장](https://junjangsee.github.io/2019/09/29/network/network-07/) 13 | 5. 류지환 14 | 6. 이강호 15 | 7. 이동규 - [HTTP 완벽가이드 스터디 #7 - Cache](https://brainbackdoor.tistory.com/129) 16 | 8. 이보라 17 | 9. 한재우 - [HTTP 완벽가이드 7장](https://bebiangel.github.io/2019/10/06/http-guide-chap7-2/) 18 | 19 | ## [6장-7장] 정리글 리뷰 team 20 | 21 | - 고현주, 이강호 22 | - 이동규, 김나영 23 | - 고석진, 류지환 24 | - 김준형, 김나영 25 | - 한재우, 이보라 26 | -------------------------------------------------------------------------------- /chapter_07-2/chapter_7-2_고석진.md: -------------------------------------------------------------------------------- 1 | # HTTP 2 | 3 | ## 7.7 캐시 처리 단계 4 | 5 | HTTP GET 메시지 하나를 처리하는 기본적인 캐시 처리 절차는 7 단계로 나누어져 있다. 6 | 7 | ### 7.7.1. 요청 받기 - 네트워크로 부터 도착한 요청 메시지를 받는다. 8 | 9 | 데이터를 읽어들인다. 고성능 캐시는 여러 개의 들어오는 커넥션들로부터 데이터를 동시에 읽어들이고 전체가 도착하기 전에 트랜잭션 처리를 한다. 10 | 11 | ### 7.7.2. 파싱 - 메시지를 파싱하여 URL 과 헤더들을 추출한다. 12 | 13 | 메시지를 여러 부분으로 파싱하여 헤더 부분을 조작하기 쉬운 자료구조에 담는다. 14 | 15 | ### 7.7.3. 검색 - 로컬 복사본이 있는지 검사하고, 사본이 없다면 사본을 받아온다. 16 | 17 | URL 을 알아내고 그에 해당하는 로컬 사본이 있는지 검사한다. 18 | 만약 문서를 가져올 수 없다면 상황이나 설정에 따라서 원 서버나 부모 프락시에서 가져오거나 혹은 실패를 반환단다. 19 | 20 | ### 7.7.4. 신선도 검사 - 캐시된 사본이 충분히 신선한지 검사하고, 신선하지 않다면 변경사항이 있는지 서버에게 물어본다. 21 | 22 | HTTP 는 캐시가 일정 기간 동안 서버 문서의 사본을 보유할 수 있도록 해준다. 23 | 이 기간동안은 문서는 신선한 것으로 간주되고 캐시는 서버와의 접촉 없이 문서를 제공할 수 있다. 24 | '신선하지 않은 경우' 에는 어떤 변경이 있었는지 검사하기 위해 서버와 재검사를 해야한다. 25 | 26 | ### 7.7.5. 응답 생성 - 응답 메시지를 만든다 27 | 28 | 캐시된 응답을 원 서버에서 온 것처럼 보이게 하기 위해 서버 응답 헤더를 토대로 응답 헤더를 생성한다. 29 | 캐시가 Date 헤더를 조정해서는 안된다. 30 | 31 | ### 7.7.6. 발송 - 응답을 클라이언트에게 돌려준다. 32 | 33 | 헤더가 준비되면 클라이언트에게 돌려준다. 프락시 캐시는 클라이언트와의 커넥션을 유지할 필요가 있다. 34 | 코성능 캐시는 종종 로컬 저장장치와 네트워크 I/O 버퍼 사이에서 문서의 콘텐츠 복사를 피함으로써 데이터를 효과적으로 전송하기 위해 노력한다 35 | 36 | ### 7.7.7 로깅 - 로그파일에 트랜잭션에 대해 서술한 로그 하나를 남긴다. 37 | 38 | 트랜잭션이 완료된 후 캐시는 통계 캐시 적중과 부적중 횟수에 대한 통계를 갱신하고 로그 파일에 요청 종류, URL 그리고 무엇이 일어났는지를 알려주는 항목을 추가한다. 39 | 40 | ## 7.8 사본을 신선하게 유지하기 41 | 42 | 캐시된 사본 모두가 서버의 문서와 항상 일치하는 것은 아니다. HTTP 는 어떤 캐시가 사본을 갖고 있는지 서버가 기억하지 않더라도, 캐시된 사본이 서버와 43 | 충분히 일치하도록 유지할 수 있게 해주는 단순한 메커니즘을 갖고 있다. 이를 문서만료와 서버 재검사라고 부른다. 44 | 45 | ### 7.8.1 문서 만료 46 | 47 | HTTP 는 Cache-Control 과 Expires 라는 헤더를 이용하여 원 서버가 문서에 유효기간을 붙일 수 있게 해준다. 48 | 캐시된 문서가 만료되면 캐시는 반드시 서버와 문서에 변경된 것이 있는지 검사해야한다. 49 | 50 | ### 7.8.2 유효기간과 나이 51 | 52 | 서버는 응답 본문과 함께 하는, HTTP/1.0+ Expires 나 HTTP/1.1 Cache-Control:max-age 응답 헤더를 이용해서 유효기간을 명시한다. 53 | 54 | - Cache-Control:max-age: 문서의 최대 나이를 정의한다. 문서가 처음 생성된 이후부터 계산 55 | - Expires: 절대 유효기간을 정의 56 | 57 | ### 7.8.3 서버 재검사 58 | 59 | 문서가 만료되었다는 것은, 원 서버에 현재 존재하는것과 다르다는 것을 의미하지는 않는다. 검사할 시간이 되었음을 뜻한다. 60 | 61 | - 검사결과 변경되었다면 새로운 사본을 가져와 저장하고 클라이언트에게 보내준다. 62 | - 변경되지 않았따면 새 만료인을 포함한 새 헤더들만 가져와 갱신한다. 63 | 64 | ### 7.8.4 조건부 메서드와의 재검사 65 | 66 | HTTP의 조건부 메서드는 재검사를 효율적으로 만들어준다. 서버가 갖고 있는 문서가 캐시가 갖고 있는 것과 다른 경우에만 객체 본문을 보내달라고 하는 것이다. 67 | HTTP는 다섯 가지 조건부 요청 헤더를 정의한다. 'if' 라는 접두어로 시작한다. 68 | 69 | - if-modified-since: 문서가 주어진 날짜 이후로 수정되었다면 요청 메서드를 처리한다. 70 | - if-none-match: 마지막 변경된 날짜를 맞춰보는 대신, 문서에 대한 일련번호와 같이 동작하는 특별한 태그를 제공할 수 있다. 태그가 서버에 있는 문서의 태그와 다를 때만 수행한다. 71 | 72 | ### if-modified-since: 날짜 재검사 73 | 74 | IMS 요청으로 줄여부른다. IMS 요청은 서버에게 리소스가 특정 날짜 이후로 변경된 경우에만 요청한 본문을 보내달라고한다. 75 | 76 | - 만약 문서가 주어진 날짜 이후에 변경되었다면, IMS 는 참이고 새 문서가 새로운 만료 날짜와 헤더들과 함께 제공된다. 77 | - 문서가 주어진 날짜 이후에 변경되지 않았다면 조건은 거짓이고, 서버는 작은 304 Not Modififed 응답 메시지를 클라이언트에게 돌려준다. 78 | 79 | ### if-none-match: 엔터티 태그 재검사 80 | 81 | 최근 변경 일시 재검사가 행해지기 어려운 상황이 몇가지 있다. 82 | 83 | - 내용에는 아무런 변화가 없더라도 변경시각은 바뀔 수 있다. 84 | - 전 세계의 캐시들이 데이터를 다시 읽어들이기엔 사소한 것일 수도 있다. 85 | - 어떤 서버들은 갖고 있는 페이지에 대한 최근 변경 일시를 정확하게 판별할 수 없다. 86 | - 1초보다 작은 간격으로 갱신되는 문서를 제공하는 서버들에게는, 변경일에 대한 1초의 정밀도는 충분하지 않을 수 있다. 87 | 88 | 캐시가 객체에 대한 여러 개의 사본을 갖고 있는 경우, 그 사실을 서버에게 알리기 위해 하나의 if-none-match 헤더에 여러 개의 엔터티 태그를 포함 할 수 있다. 89 | 90 | ```text 91 | If-None-Match: "v2.6" 92 | If-None-Match: "v2.4", "v2.5", "v2.6" 93 | If-None-Match: "foobar", "A34FAC0065", "Profiles in Courage" 94 | ``` 95 | 96 | ### 7.8.7 약한 검사기와 강한 검사기 97 | 98 | 서버가 갖고 있는 캐시에 대해 최신인지 확인하기 위해 엔터티 태그를 사용한다. 태그와 최근 변경일시는 둘 다 캐시 검사기다. 99 | HTTP/1.1 은 비록 콘텐츠가 조금 변경되었더라도 "그 정도면 같은것" 이라고 서버가 주장할 수 있도록 해주는 약한 검사기를 지원한다. 100 | 강한 검사기는 콘텐츠가 바뀔때마다 바뀐다. 101 | 102 | 원서버는 서로 다른 두 엔터티에 대해 강한 엔터티 태그 값을 재활용해서는 안되며, 약한 엔터티 태그 값이라고 할지라도 서로 의미가 다른 두 엔터티에 대해서는 재활용해서는 안된다는 것에 주의해라. 103 | 104 | ### 7.8.8 언제 엔터티 태그를 사용하고 언제 Last-Modified 일시를 사용하는가 105 | 106 | HTTP/1.1 클라이언트는 만약 서버가 엔터티 태그를 반환했다면, 엔터티 태그 검사기를 사용해야 한다. 107 | 서버가 Last-Modified 값만을 반환했다면, 클라이언트는 If-Modified-Since 검사를 사용할 수 있다. 108 | 109 | HTTP/1.1 원 서버는 가능하다면 엔터티 태그 검사기를 보내야 하며, 이점이 있다면 강한 엔터티 태그 대신 약한 엔터티 태그를 보낼 수도 있다. (Last-Modified 값을 보내는 것도 선호) 110 | HTTP/1.1 캐시나 서버가 IMS 와 엔터티 태그 조건부 헤더를 모두 받았다면 304 를 반환해서는 안된다. 111 | 112 | ## 7.9 캐시 제어 113 | 114 | HTTP 는 문서가 만료되기 전까지 얼마나 오랫동안 캐시될 수 있게 할 것인지 서버가 설정할 수 있는 여러가지 방법을 정의한다. 115 | 116 | - Cache-Control: no-store, no-cache, must-revalidate, max-age 헤더를 응답에 첨부 할 수 있다. 117 | - Expires: 날짜 헤더를 응답에 첨부할 수 있다. 118 | 119 | ### 7.9.1 no-cache, store 응답 헤더 120 | 121 | HTTP/1.1 은 신선도를 관리하기 위해, 객체를 캐시하는 것을 제한하거나 캐시된 객체를 제공하는 여러가지 방법을 제공한다. 122 | no-cache, store 헤더는 캐시가 검증되지 않은 캐시된 객체로 응답하는 것을 막는다. 123 | 124 | 'no-cache' 가 표시된 응답은 응답의 사본을 만드는 것을 금지한다. 로컬 저장소에는 저장이 가능하나 서버와 재검사를 하지 않고서는 캐시에서 클라이언트로 제공될 수 없을 뿐이다. 125 | 126 | ### 7.9.2 Max-Age 응답 헤더 127 | 128 | Cache-Control: max-age 헤더는 신선하다고 간주되었던 문서가 서버로부터 온 이후로 흐른 시간이고, 초로 나타낸다. 129 | 서버는 최대 나이먹음을 0 으로 설정함으로써, 캐시가 매 접근마다 문서를 캐시하거나 리프레시하지 않도록 요청할 수 있다. 130 | 131 | ### 7.9.3 Expires 응답 헤더 132 | 133 | 초 단위의 시간 대신 실제 만료 날짜를 명시한다. 134 | 몇몇 서버는 항상 만료되도록 하기 위해 Expires:0 응답 헤더를 돌려보내지만, 이는 문법 위반이다. 135 | 136 | ### 7.9.4 Must-Revalidate 응답 헤더 137 | 138 | 성능을 개선하기 위해 신선하지 않은 객체를 제공하도록 설정될 수 있다. 139 | 응답헤더는 캐시가 객체의 신선하지 않은 사본을 원 서버와의 최초의 재검사 없이는 제공할 수 없음을 의미한다. 140 | 신선도 검사를 시도했을 때 원 서버가 사용할 수 없는 상태라면, 캐시는 반드시 504 Gateway Timeout error 를 반환해야한다. 141 | 142 | ### 7.9.5 휴리스틱 만료 143 | 144 | max-age, expires 헤더 중 어느 것도 포함하지 않고 있다면, 캐시는 경험적인 방법으로 최대 나이를 계산할 것 이다. 145 | 146 | - LX 인자 알고리즘: 문서가 최근 변경 일시를 포함하고 있다면 사용 할 수 있다. 문서가 얼마나 자주 바뀌는지에 대한 추정에 사용한다. 147 | 148 | 캐시는 일반적으로 신선도에 대한 아무런 단서가 없는 문서에 대해 기본 신선도 유지기간을 설정한다. (보통 한시간, 하루) 캐시가 클라이언트에게 데이터를 제공할 때마다 신선한지 검사하도록 강제한다. 149 | 150 | ### 7.9.6 클라이언트 신선도 제약 151 | 152 | 웹 브라우저는 브라우저나 프락시 캐시의 신선하지 않은 콘텐츠를 강제로 갱신시켜주는 리프레시나 리로드 버튼을 갖고 있다. 153 | 클라이언트는 문서를 최신으로 유지할 필요가 있는 애플리케이션을 더 엄격하게 할 수 있다. 154 | 155 | - max-stale: 신선하지 않은 문서라도 자유롭게 제공할 수 있다. 156 | - min-fresh: 신선한 문서만을 받아들인다. 157 | - max-age: s 초보다 오랫동안 캐시된 문서를 반환할 수 없다. 158 | - no-cache: 재검사하기 전에는 받아들여지지 않는다. 159 | - no-store: 저장소에서 문서의 흔적을 최대한 빨리 삭제해야한다. 문서에는 민감한 정보가 포함되어있기 때문이다. 160 | - only-if-cached: 캐시에 들어있는 사본만 원한다. 161 | 162 | ## 7.10 캐시 제어 설정 163 | 164 | ### 7.10.1 아파치로 HTTP 헤더 제어하기 165 | 166 | - mod_headers: 개별 헤더들을 설정할 수 있게 해준다. 개별 HTTP 헤더를 제어할 수 있는 지시어를 이용해 아파치 설정 파일에 설정을 추가할 수 있다. 헤더들을 연결시키기 위해 아파치의 정규 식과 필터를 조합하여 사용할 수 있다. 167 | 168 | ```text 169 | 170 | Header set Cache-control no-cache 171 | 172 | ``` 173 | 174 | - mod_expires: 만료 날짜가 담긴 expires 헤더를 자동으로 생성하는 프로그램 로직을 제공한다. 175 | - mod_cern_meta: HTTP 헤더들의 파일을 특정 객체와 연결시켜준다. 176 | 177 | ### 7.10.2 HTTP-EQUIV 를 통한 HTML 캐시 제어 178 | 179 | HTTP 서버 응답 헤더는 문서의 만료와 캐시 제어 정보를 돌려주기 위해 사용된다. 웹 서버는 제공할 문서에 올바른 캐시 제어 헤더들을 부여하기 위해 설정 파일들과 상호작용한다. 180 | 상호작용 없이 쉽게 HTTP 헤더를 부여할 수 있도록 하기위해 태그를 정의했다. 181 | 182 | ```html 183 | 184 | ``` 185 | 186 | 이 기능을 지원하는 웹 서버나 프락시는 거의 없다. 서버의 부하를 가중시키고, 설정값이 정적이고, HTML 을 제외한 다른 타입의 파일은 지원하지 않기 때문이다. 187 | 188 | 189 | 190 | -------------------------------------------------------------------------------- /chapter_07/README.md: -------------------------------------------------------------------------------- 1 | # [6장-7장] HTTP:아키텍처 / 프락시 chap6 - 캐시 chap6 2 | 3 | - 마감일: 9월 30일 월요일 자정 4 | - todo: 6장 chap6 - 7장 chap6까지의 정리본, 6장 pr 리뷰 5 | 6 | ## 정리 글 링크 7 | 8 | 1. 고석진 9 | 2. 고현주 - [HTTP 7.캐시](https://dev-junior.tistory.com/11) 10 | 3. 김나영 - [프락시](https://feel5ny.github.io/2019/09/22/HTTP_006/), [캐시-1](https://feel5ny.github.io/2019/09/30/HTTP_007-1/) 11 | 4. 김준형 - [HTTP 7-1장](https://junjangsee.github.io/2019/09/29/network/network-07/), [HTTP 6-2장](https://junjangsee.github.io/2019/09/22/network/network-06/) 12 | 5. 류지환 13 | 6. 이강호 14 | 7. 이동규 - [HTTP 완벽가이드 스터디 #6 - Proxy Server](https://brainbackdoor.tistory.com/128) 15 | 8. 이보라 16 | <<<<<<< HEAD:chapter_7/README.md 17 | 9. 이혜승 18 | 10. 홍유정 19 | 11. 한재우 - [HTTP 완벽가이드 7장](https://bebiangel.github.io/2019/09/29/http-guide-chap7/) 20 | ======= 21 | 9. 한재우 22 | >>>>>>> master:chapter_07/README.md 23 | 24 | ## 6장 정리글 리뷰 team 25 | 26 | - 고현주, 이보라 27 | - 이동규, 한재우 28 | - 고석진, 이강호 29 | - 김준형, 김나영 30 | - 류지환, 김나영 31 | -------------------------------------------------------------------------------- /chapter_07/chap7_고석진.md: -------------------------------------------------------------------------------- 1 | # HTTP 2 | 3 | ## 6.6 메시지 추적 4 | 5 | 프락시가 점점 흔해지면서, 서로 다른 스위치와 라우터를 넘나드는 IP 패킷의 흐름을 추적하는 것 못지 않게 프락시를 넘나드는 메시지의 흐름을 추적하고 문제점을 찾아내는 것도 필요한 일이 되었다. 6 | 7 | ### 6.6.1 Via 헤더 8 | 9 | Via 헤더 필드는 메시지가 지나는 가 중간 노드의 정보를 나열한다. 10 | 메시지의 전달을 추적하고, 메시지 루프를 진단하고, 요청을 보내고 그에 대한 응답을 돌려주는 과정에 관여하는 모든 메시지 발송자들의 프로토콜을 다루는 능력을 알아보기 위해 사용된다. 11 | 12 | Via 문법 13 | 14 | ```text 15 | Via = "Via":" { waypoint } [", "{ waypoin } ...] 16 | waypoint = ( received-protocol received-by [ comment ] ) 17 | received-protocol = [ protocol-name "/" ] protocol-version 18 | receved-by = ( host [ ":" prot ] ) | pseudnym 19 | ``` 20 | 21 | - 프로토콜 이름: 프로토콜이 만약 HTTP 라면 프로토콜 이름은 없어도 된다. 프로토콜 이름은 버전 앞에 "/" 로 구분되어 붙는다. 22 | - 프로토콜 버전: 버전의 포맷은 프로토콜에 달려있다. 버전은 via 필드에 포함되므로, 애플리케이션들은 자신 이전의 모든 중개자들이 어떤 버전을 다룰 수 있는지 알 수 있다. 23 | - 노드 이름: 정보 보호를 이유로 진짜 호스트 명을 밝히고 싶지 않을때 가명으로 대체 할 수 있다. 24 | - 노드 코멘트: 중개자 노드를 서술하는 선택적인 코멘트, 벤더나 버전 정보를 포함 25 | - Via 요청과 응답 경로: 요청 메시지와 응답 메시지 모두 프락시를 지나므로 둘 모두 Via 헤더를 가진다. 응답의 Via 헤더는 언제나 요청 Via 헤더의 반대다 26 | - Via 게이트웨이: 서버에게 비 HTTP 프로토콜을 사용할 수 있는 게이트웨이 기능을 제공한다. 선택적 코멘트는 프락시 서버의 브랜드, 버전 번호, 몇 가지 벤더 진단 정보를 포함한다. 27 | - Server 헤더와 Via 헤더: Server 응답 헤더 필드는 원 서버에 의해 사용되는 소프트웨어를 알려준다. 28 | - Via 가 개인정보 보호와 보안에 미치는 영향: 호스트 명이 노출되기 원치 않는다면 호스트명을 가명으로 교체해야한다. 프락시는 정렬된 일련의 via 유지 항목들을 하나로 합칠 수 있다. 경유지들이 모두 같은 조직의 통제하에 있고 호스트가 이미 가명으로 교체되지 않은 이상 그들에 대한 항목들을 합쳐서는 안된다. 프로토콜 값이 서로 다른 항목들도 합쳐서는 안된다. 29 | 30 | ## 6.6.2 TRACE 메서드 31 | 32 | 프락시 서버는 메시지가 전달될 때 멤시지를 바꿀 수 있다. 헤더가 추가되거나, 변경되거나, 삭제될 수 있으며, 본무니 다른 형식으로 변환될 수 있다. 33 | HTTP/1.1 의 TRACE 메서드는 요청 메시지를 프락시의 연쇄를 따라가면서 어떤 프락시를 지나가고 프락시가 요청 멤시지를 수정하는지 관찰/추적할 수 있게 해준다. 34 | 35 | - Max-Forwards: TRACE 와 OPTIONS 요청의 프락시 홉 개수를 제한하기 위해 Max-Forwards 헤더를 사용할 수 있는데, 이는 전달되는 메시지가 무한 루프에 빠지지 않는지 프락시 연쇄를 테스트하거나 연쇄 중간의 특정 프락시 서버들의 효과를 체크할 때 유용하다. 36 | 37 | ## 6.7 프락시 인증 38 | 39 | HTTP 는 사용자가 유요한 접근 권한 자격을 프락시에 제출하지 않는 한 콘텐츠에 대한 요청을 차단하는 프락시 인증이라는 매커니즘을 정의하고 있다. 40 | 41 | ## 6.8 프락시 상호운용성 42 | 43 | 서로 다른 프로토콜을 구현했을 수도 있고 이상한 동작을 할 수도 있는 클라이언트와 서버 사이를 중개해야 한다. 44 | 45 | ### 6.8.1 지원하지 않는 헤더와 메서드 다루기 46 | 47 | 프락시는 이해할 수 없는 헤더 필드는 반드시 그대로 전달해야 하며, 같은 이름의 헤더 필드가 여러 개 있는 경우에는 그들의 상대적인 순서도 반드시 유지해야 한다. 48 | 만약 프락시가 어떤 메서드와 친숙하지 않다면, 가능한 한 그 메시지를 다음 홉으로 전달하려 시도해야한다. 49 | 50 | ### 6.8.2 OPTIONS: 어떤 기능을 지원하는지 알아보기 51 | 52 | HTTP OPTIONS 메서드는 서버나 웹 서버의 특정 리소스가 어떤 기능을 지원하는지 클라이언트가 알아볼 수 있게 해준다. 53 | 54 | ### 6.8.3 Allow 헤더 55 | 56 | Allow 엔터티 헤더 필드는, 요청 URI 에 의해 식별되는 자원에 대해 지원되는 메서드들이나 서버가 지원하는 모든 메서드를 열거한다. 57 | Allow 헤더는 새 리소스가 지원했으면 하는 메서드를 추천하기 위해 요청 헤더로 사용될 수 있다. 58 | 59 | ## 캐시 60 | 61 | 웹 캐시는 문서의 사본을 자동으로 보관하는 HTTP 장치이다 62 | 요청이 캐시에 도착했을 때 로컬 사본이 존재한다면 문서는 원 서버가 아니라 캐시로부터 제공된다. 63 | 64 | - 캐시는 네트워크의 병목을 줄여준다. 65 | - 불필요한 데이터 전송을 줄여준다. 66 | - 원 서버에 대한 요청을 줄여준다. 67 | - 거리로 인한 지연을 줄여준다. 68 | 69 | ## 7.1 불필요한 데이터 전송 70 | 71 | 똑같은 바이트들이 네트워크를 통해 계속 반복적으로 이동할때 불필요한 데이터 전송이 일어난다. 72 | 데이터 전송은 값비싼 네트워크 대역폭을 잡아먹고, 전송을 느리게 만들며, 웹 서버에 부하를 준다. 73 | 캐시를 이용하면, 첫 번째 응답은 캐시에 보관된다. 74 | 75 | ## 7.2 대역폭 병목 76 | 77 | 캐시는 또한 네트워크 병목을 줄여준다. 원격 서버보다 로컬 네트워크 클라이언트에 더 넓은 대역폭을 제공한다. 78 | 클라이언트들이 서버에 접근할때의 속도는 경로에 있는 가장 느린 네트워크의 속도와 같다. 79 | 캐싱을 이용한다면 성능을 대폭 개선할 수 있을 것이다. 80 | 81 | ## 7.3 갑작스런 요청 쇄도 82 | 83 | 캐싱은 갑작스런 요청 쇄도에 대처하기 위해 특히 중요하다. 84 | 불필요한 트래픽 급증은 네트워크와 웹 서버의 심각한 장애를 야기시킨다. 85 | 86 | ## 7.4 거리로 인한 지연 87 | 88 | 대역포이 문제가 되지 않더라도 거리가 문제가 될 수 있다. 89 | 모든 네트워크 라우터는 인터넷 트래픽을 지연시킨다. 빛의 속도 그 자체가 유의미한 지연을 유발한다. 90 | 91 | ## 7.5 적중과 부적중 92 | 93 | 캐시가 세상 모든 문서의 사본을 저장하지는 않는다. 94 | 캐시에 요청이 도착했을 떄 그에 대응하는 사본이 있다면 그를 이용해 요청이 처리될 수 있다. 95 | 이를 캐시 적중이라고 부른다. 사본이 없다면 원 서버로 전달되기만 할 뿐이다. 이를 캐시 부적중 이라고 부른다. 96 | 97 | ### 7.5.1 재검사 98 | 99 | 원 서버 컨텐츠를 변경 될 수 있기 때문에, 캐시는 반드시 사본이 최신인지 점검이 필요하다. 100 | 재검사가 필요할때 원 서버에 작은 재검사 요청을 보낸다. 콘텐츠가 변경되지 않았다면 서버는 304 Not Modified 응답을 보낸다. 101 | 102 | - 재검사 적중: 만약 서버 객체가 변경되지 않았다면, 서버는 클라이언트에게 작은 HTTP 304 Not Modified 응답을 보낸다. 103 | - 재검사 부적중: 서버 객체가 캐시된 사본과 다르다면, 서버는 콘텐츠 전체와 함께 평범한 HTTP 200 응답을 클라이언트에게 보낸다. 104 | - 객체삭제: 서버 객체가 삭제되었다면, 서버는 404 Not Found 응답을 돌려보내며 사본을 삭제한다. 105 | 106 | ### 7.5.2 적중률 107 | 108 | 캐시가 요청을 처리하는 비율을 캐시 적중률 혹은 문서 적중률이라고 부른다. 109 | 110 | ### 7.5.3 바이트 적중률 111 | 112 | 문서들이 모두 같은 크기인 것은 아니기 때문에 문서 적중률이 모든 것을 말해주지 않는다. 113 | 어떤 사람들은 바이트 단위 적중률 측정값을 더 선호한다 114 | 바이트 단위 적중률은 캐시를 통해 제공된 모든 바이트의 비율을 표현한다. 115 | 이 측정값은 트래픽이 절감된 정도를 포착한다. 116 | 117 | ### 7.5.4 적중과 부적중의 구별 118 | 119 | HTTP 는 클라이언트에게 응답이 캐시 적중이었는지 원 서버 접근인지 말해줄 수 있는 방법을 제공하지 않는다. 120 | 두 경우 모두 응답이 200 으로 내려간다. 클라이언트 응답이 캐시 헤더에서 왔는지 알아내는 한 가지 방법은 Date 헤더를 이용하는 것이다. 121 | 응답의 Date 헤더 값을 현재 시각과 비교하여, 응답의 생성일이 더 오래 되었다면 캐시된 것임을 알아낼 수 있다. 122 | 123 | ## 7.6 캐시 토폴로지 124 | 125 | 한 명에게만 할당된 캐시를 개인 전용 캐시라 부른다. 공유된 캐시는 공용 캐시라고 부른다. 126 | 127 | ### 7.6.1 개인 전용 캐시 128 | 129 | 개인 전용 캐시는 많은 에너지나 저장 공간을 필요로 하지 않으므로 작고 저렴할 수 있다. 브라우저는 개인 전용 캐시를 내장하고 있다. 130 | 브라우저는 자주 쓰이는 문서를 개인용 컴퓨터의 디스크와 메모리에 캐시해 놓고, 사용자가 캐시 사이즈와 설정을 수정할 수 있도록 허용한다. 131 | 132 | ### 7.6.2 공용 프락시 캐시 133 | 134 | 공용 프락시 캐시는 프락시 캐시라고 불리는 특별한 종류의 공유된 프락시 서버다. 135 | 개인 전용 캐시는 같은 문서를 네트워크를 거쳐 여러번 가져온다. 136 | 공유된 공용 캐시는 자주 찾는 객체를 단 한번만 가져와 모든 요청에 대해 공유된 사본을 제공하므로써 네트워크 트래픽을 줄인다. 137 | 138 | ### 7.6.3 프락시 캐시 계층들 139 | 140 | 작은 캐시에서 캐시 부적중이 발생했을 때 부모 캐시가 트래픽을 처리하도록 하는 계층을 만드는 방식이 합리적인 경우가 많다. 141 | 캐시 계층이 깊다면 요청은 캐시의 긴 연쇄를 따라가게 될 것이다. 트락시 연쇄가 길어질수록 중간 프락시는 현저한 성능 저하가 발생할 것 이다. 142 | 143 | ### 7.6.4 캐시망, 콘텐츠 라우팅, 피어링 144 | 145 | 캐시망의 프락시 캐시는 복잡한 방법으로 서로 대화하여, 어떤 부모 캐시와 대화할 것인지 아니면 요청이 캐시를 완전히 우회해서 원 서버로 바로 가도록 할 것인지에 대한 커뮤니케이션을 동적으로 결정한다. 146 | 147 | 선택적인 피어링을 지원하는 캐시는 형제 캐시라고 불린다. HTTP 는 형제 캐시를 지원하지 않기 때문에 인터넷캐시 프로토콜(ICP)나 하이퍼텍스트 캐시 프로토콜같은 것들을 이용해 HTTP 를 확장했다. 148 | 149 | -------------------------------------------------------------------------------- /chapter_08/README.md: -------------------------------------------------------------------------------- 1 | # [8장] HTTP:아키텍처 / 통합점: 게이트웨이, 터널, 릴레이 2 | 3 | - 마감일: 10월 14일 월요일 자정 4 | - todo: 8장 통합점: 게이트웨이, 터널, 릴레이 5 | 6 | ## 정리 글 링크 7 | 8 | 1. 고석진 9 | 2. 고현주 - [8장 통합점: 게이트웨이, 터널, 릴레이](https://dev-junior.tistory.com/13) 10 | 3. 김나영 11 | 4. 김준형 - [HTTP - 8장](https://junjangsee.github.io/2019/10/13/network/network-08/) 12 | 5. 류지환 13 | 6. 이강호 14 | 7. 이동규 - [HTTP 완벽가이드 스터디 #8 - G/W, Tunnel](https://brainbackdoor.tistory.com/130) 15 | 8. 이보라 16 | 9. 한재우 - [HTTP 완벽가이드 8장](https://bebiangel.github.io/2019/10/13/http-guide-chap8/) 17 | 18 | ## [8장] 정리글 리뷰 team 19 | 20 | - 고현주, 이동규 21 | - 이보라, 류지환 22 | - 김나영, 이강호 23 | - 김준형, 한재우 24 | - 고석진, 김나영 25 | -------------------------------------------------------------------------------- /chapter_08/chapter_8_고석진.md: -------------------------------------------------------------------------------- 1 | # HTTP 2 | 3 | ## 게이트웨이 4 | 5 | - 게이트웨이: 서로 다른 프로토콜과 애플리케이션 간의 HTTP 인터페이스이다. 6 | - 애플리케이션 인터페이스: 서로 다른 형식의 웹 애플리케이션이 통신하는데 사용한다. 7 | - 터널: HTTP 커넥션을 통해서 HTTP 가 아닌 트래픽을 전송하는데 사용한다. 8 | - 릴레이: 단순한 HTTP 프락시로, 한 번에 한 개의 홉에 데이터를 전달하는데 사용한다. 9 | 10 | ## 8.1 게이트웨이 11 | 12 | 웹에 복잡한 리소스를 올려야 할 필요가 생기면서, 모든 리소스를 한 개의 애프리케이션으로만 처리할 수 없다는 것은 분명해졌다. 13 | 이 문제를 해결하기 위해 인터프리터 같이 리소스를 받기 위한 경로를 안내하는 역할을 하는 게이트웨이를 고안해냈다. 14 | 15 | - 리소스와 애플리케이션을 연결하는 역할을 한다. 16 | - 요청을 받고 응답을 보내는 포털 같이 동작하는데, 동적인 콘텐츠를 생성하거나 데이터베이스에 질의를 보낼 수 있다. 17 | - HTTP 트래피글 다른 프로토콜로 자동으로 변환하여, HTTP 클라이언트가 다른 프로토콜을 알 필요 없이 서버에 접속할 수 있게 하기도 한다. 18 | 19 | ### 8.1.1 클라이언트 측 게이트웨이와 서버 측 게이트웨이 20 | 21 | 웹 게이트웨이는 한쪼에서는 HTTP 로 통신하고 다른 한쪽에서는 HTTP 가 아닌 다른 프로토콜로 통신한다. 22 | 클라이언트 측 프로토콜과 서버 측 프로토콜을 / 으로 구분해 기술한다. 23 | 24 | ``` 25 | <클라이언트 프로토콜>/<서버 프로토콜> 26 | ``` 27 | 28 | - 서버 <-> 클라 (HTTP 프로토콜 통신) / 서버 <-> 서버 (외래 프로토콜) 29 | - 클라 <-> 서버 (HTTP) / 클라 <-> 클라 (외래 프로토콜) 30 | 31 | ## 8.2 프로토콜 게이트웨이 32 | 33 | 게이트웨이에 HTTP 트래픽을 바로 보낼 수 있다. 브라우저에 명시하거나, 게이트웨이를 대리 서버(리버스 프락시)로 설정할 수 있다. 34 | 35 | ### 8.2.1 HTTP/*: 서버 측 웹 게이트웨이 36 | 37 | 서버 측 웹 게이트웨이는 클라이언트로부터 HTTP 요청이 원 서버 영역으로 들어오는 시점에 클라이언트 측의 HTTP 요청을 외래 프로토콜로 전환한다. 38 | 39 | (FTP 커네션을 통해서 객체를 가져올 때) 40 | - USER 와 PASS 명령을 보내서 서버에 로그인한다. 41 | - 서버에서 적절한 디렉터리로 변경하기 위해 CWD 명령을 내린다. 42 | - 다운로드 형식을 ASCII 로 설정한다. 43 | - MDTM 으로 문서의 최근 수정 시간을 가져온다. 44 | - PASV 로 서버에게 수동형 데이터 검색을 하겠다고 말한다. 45 | - RETR 로 객체를 검색한다. 46 | - 제어 채널에서 반환된 포트로 FTP 서버에 데이터 커넥션을 맺는다. 47 | - 객체를 받는대로 HTTP 응답에 실어서 클라이언트에 전송한다. 48 | 49 | ### 8.2.2 HTTP/HTTPS: 서버 측 보안 게이트웨이 50 | 51 | 모든 웹 요청을 암호화함으로써 개인 정보 보호와 보안을 제공하는데 게이트웨이를 사용할 수 있다. 52 | 클라이언트는 일반 HTTP 를 사용하여 웹을 탐색 할 수 있지만, 게이트웨이는 자동으로 사용자의 모든 세션을 암호화할 것이다. 53 | 54 | ### 8.2.3 HTTPS/HTTP: 클라이언트 측 보안 가속 게이트웨이 55 | 56 | HTTPS/HTTP 게이트웨이는 웹 서버의 앞단에 위치하고, 보이지 않는 인터셉트 게이트웨이나 리버스 프락시 역할을 한다. 57 | 게이트웨이는 보안 HTTPS 트래픽을 받아서 복호화하고, 웹 서버로 보낼 일반 HTTP 요청을 만든다. 58 | 59 | 게이트웨이와 원 서버 간의 암호화하지 않은 트래픽을 전송하기 때문에, 게이트웨이와 원 서버 간에 있는 네트워크가 안전한지 확인을 하고 사용해야한다. 60 | 61 | ## 8.3 리소스 게이트웨이 62 | 63 | 게이트웨이의 가장 일반적인 형태인 애플리케이션 서버는 목적지 서버와 게이트웨이를 한 개의 서버로 결합한다. 64 | 애플리케이션 서버는 HTTP 를 통해서 클라이언트와 통신하고 서버 측에 있는 애플리케이션 프로그램에 연결하는 서버 측 게이트웨이다. 65 | 66 | ### 8.3.1 공용 게이트웨이 인터페이스 67 | 68 | 공용 게이트웨이 인터페이스 (CGI) 는 최초의 서버 확장이자 지금까지도 가장 널리 쓰이는 서버 확장이다. 69 | 웹에서 동적인 HTML, 신용카드, 데이터베이스 질의 등을 제공하는데 쓰인다. 70 | 서버와 CGI 애플리케이션 간에 진행되는 처리 단계를 감춘다. 클라이언트가 CGI 애플리케이션이 무언가를 하고 있다는 것을 알 수 있는 유일한 단서는 URL 에 있는 'cgi' 혹은 '?' 같은 것들 뿐이다. 71 | 72 | CGI 는 모든 요청마다 새로운 프로세스를 만드는데 따르는 부하가 꽤 크고 사용하는 서버의 성능을 제한하며 서버 장비에 부담을 준다. 73 | 이런 문제를 해결하기 위해 데몬으로 동작하는 Fast CGI 가 개발되었다. 74 | 75 | ### 8.3.2 서버 확장 API 76 | 77 | - 서버자체의 동작을 바꾸고 싶거나 78 | - 서버의 처리능력을 최고치로 끌어 올리고자 할 때 79 | 80 | 이러한 두 가지 필요성에 서버 개발자는 웹 개발자가 자신의 모듈을 HTTP 와 직접 연결할 수 있는 강력한 인터페이스인 서버 확장 API 를 제공하였다. 81 | 확장 API 는 프로그래머가 자신의 코드를 서버에 연결하거나 서버의 컴포넌트를 자신이 만든 것으로 교체해버릴 수 있게 하였다. 82 | 83 | ## 8.4 애플리케이션 인터페이스와 웹 서비스 84 | 85 | 애플리케이션을 연결하면서 생기는 까다로운 이슈 중 하나는, 데이터를 교환하려는 두 애플리케이션 사이에서 프로토콜 인터페이스를 맞추는 일이다. 86 | 87 | 웹 서비스는 SOAP 을 통해 XML 을 사용하여 정보를 교환한다. XML 은 데이터 객체를 담는 데이터를 생성하고 해석하는 방식을 제공한다. 88 | SOAP 는 HTTP 메시지에 XML 데이터를 담는 방식에 관한 표준이다. 89 | 90 | ## 8.5 터널 91 | 92 | 웹 터널은 HTTP 프로토콜을 지원하지 않는 애플리케이션에 HTTP 애플리케이션을 사용해 접근하는 방법을 제공한다. 93 | 웹 터널을 사용하면 HTTP 커넥션을 통해서 HTTP 가 아닌 트래픽을 전송할 수 있고, 다른 프로토콜을 HTTP 위에 올릴 수 있다. 94 | 95 | ### 8.5.1 CONNECT 로 HTTP 터널 커넥션 맺기 96 | 97 | 웹 터널은 HTTP 의 CONNECT 메서드를 사용하여 커넥션을 맺는다. 98 | CONNECT 메서드는 터널 게이트웨이가 임의의 목적 서버와 포트에 TCP 커넥션을 맺고 클라이언트와 서버 간에 오는 데이터를 무조건 전달하기를 요청한다. 99 | 100 | - 클라이언트 -> 게이트웨이 CONNECT 요청 (터널 연결 요청 - SSL 433 포트) 101 | - TCP 커넥션 생성 102 | - 게이트웨이 -> 클라이언트에게 200 connection Established 응답 전송하여 연결되었음을 알림 103 | - 터널 연결 104 | - 양방향 데이터 전달 105 | 106 | #### CONNECT 요청 107 | 108 | 요청 URI 는 호스트명이 대신하며 콜론에 이어 포트를 기술한다. 109 | 110 | ``` 111 | CONNECT xxxx:443 HTTP/1.0 112 | User-agent: xxx 113 | ``` 114 | 115 | #### CONNECT 응답 116 | 117 | 클라이언트는 요청을 전송한 다음, 게이트웨이의 응답을 기다린다. 일반 HTTP 메시지와 같이 200 응답 코드는 성공을 뜻한다. 118 | 119 | ``` 120 | HTTP/1.0 200 Connection Established 121 | ``` 122 | 123 | 일반적인 응답과 달리 Content-Type 헤더를 포함할 필요는 없다. 124 | 125 | ### 8.5.2 데이터 터널링, 시간, 커넥션 관리 126 | 127 | 터널을 통해 전달되는 데이터는 게이트웨이에서 볼 수 없어서, 게이트웨이는 패킷의 순서나 흐름에 대해 어떤 가정도 할 수 없다. 128 | 129 | 클라이언트는 성능을 높이기 위해 CONNECT 요청을 보낸 다음, 응답을 받기전에 터널 데이터를 전송할 수 있다. 130 | 게이트웨이는 네트워크 I/O 요청이 헤더 데이터만을 반환해줄 거라고 가정할 수 없어서, 게이트웨이는 커넥션이 맺어지는 대로 헤더를 포함해서 읽어들인 모든 데이터를 서버에 전송해야한다. 131 | 요청 후에 터널을 통해 데이터를 전송한 클라이언트는 인증요구나 200 외의 응답이 와을 때 요청 데이터를 다시 보낼 준비가 되어 있어야한다. 132 | 커넥션이 끊긴 한쪽에 아직 전송하지 않은 데이터는 버려진다. 133 | 134 | ### 8.5.3 SSL 터널링 135 | 136 | 웹 터널은 원래 방화벽을 통해서 암호화된 SSL 트래픽을 전달하려고 개발되었다. 137 | SSL 같이 암호화된 프로토콜은 정보가 암호화되어 있기 때문에 낡은 방식의 프락시에서는 처리되지 않는다. 138 | 터널을 사용하면 SSL 트래픽을 HTTP 커넥션으로 전송하여 80 포트의 HTTP 만을 허용하는 방화벽을 통과시킬 수 있다. 139 | 이는 악의적인 트래픽이 사내로 유입되는 경로가 될 수도 있다. 140 | 141 | ### 8.5.4 SSL 터널링 vs HTTP/HTTPS 게이트웨이 142 | 143 | HTTPS 프로토콜은 다른 프로토콜과 같은 방식으로 게이트웨이를 통과할 수 있다. 144 | 원격 HTTPS 서버와 SSL 세션을 시작하는 게이트웨이를 두고 클라이언트 측의 HTTPS 트랜잭션을 수행하는 방식이다. 145 | 응답은 프락시가 받아서 복호화하고 난 후에 HTTP 를 통해 클라이언트로 전송한다. 146 | 147 | (단점) 148 | - 클라이언트-게이트웨이 사이에는 보안이 적용되지 않은 일반 HTTP 커넥션이 맺어져있다. 149 | - 프락시가 인증을 담당하고 있기 때문에, 클라이언트는 원격 서버에 SSL 클라이언트 인증을 할 수 없다. 150 | - 게이트웨이는 SSL 을 완벽히 지원해야한다. 151 | 152 | -> 이 상황에서 SSL 터널링을 사용하면 프락시에 SSL 을 구현할 필요가 없다. 153 | 프락시 서버는 트랜잭션의 보안에는 관여하지 않고 암호화된 데이터를 그대로 터널링할 뿐이다. 154 | 155 | ### 8.5.5 터널 인증 156 | 157 | 프락시 인증 기능은, 클라이언트가 터널을 사용할 수 있는 권한을 검사하는 용도로 터널에서 사용할 수 있다. 158 | 159 | ### 8.5.6 터널 보안에 대한 고려사항들 160 | 161 | 터널 게이트웨이는 통신하고 있는 프로토콜이 터널을 올바른 용도로 사용하고 있는지 검증할 방법이 없다. 162 | 터널의 오용을 최소화하기 위해서, 게이트웨이는 HTTPS 전용 포트인 443 같이 잘 알려진 특정 포트만을 터널링할 수 있게 허용해아한다. 163 | 164 | ## 8.6 릴레이 165 | 166 | HTTP 릴레이는 명세를 오나전히 준수하지는 않는 간단한 HTTP 프락시다. 167 | 커넥션을 맺기 위한 HTTP 통신을 한 다음, 바이트를 맹목적으로 전달한다. 168 | 단순 맹목적 릴레이를 구현하는데 관련된 더 일반적인 문제 중 하나는, 맹목적 릴레이가 Connection 헤더를 제대로 처리하지 못해서 keep-alive 커넥션이 행에 걸리는 것이다. 169 | 여러 문제를 예방하기 위해서 HTTP 를 제대로 준수하는 프락시를 사용하는게 좋다. 170 | 171 | 172 | 173 | 174 | 175 | 176 | 177 | 178 | 179 | 180 | 181 | 182 | 183 | 184 | 185 | 186 | 187 | 188 | 189 | 190 | 191 | 192 | 193 | 194 | 195 | 196 | 197 | 198 | 199 | 200 | -------------------------------------------------------------------------------- /chapter_09/README.md: -------------------------------------------------------------------------------- 1 | # [9장] HTTP:아키텍처 / 웹로봇 chap1 - chpa4 2 | 3 | - 마감일: 10월 21일 월요일 자정 4 | - todo: 9장 웹로봇 chap1 - chap4, 8장 리뷰 5 | 6 | ## 정리 글 링크 7 | 8 | 1. 고석진 9 | 2. 고현주 - [9장 웹 로봇](https://dev-junior.tistory.com/14) 10 | 3. 김나영 11 | 4. 김준형 - [HTTP - 9장](https://junjangsee.github.io/2019/10/20/network/network-09/) 12 | 5. 류지환 13 | 6. 이강호 14 | 7. 이동규 - [HTTP 완벽가이드 스터디 #9 - web robot](https://github.com/brainbackdoor/bbd-http-web/blob/master/docs/webrobot/README.md) 15 | 8. 이보라 16 | 9. 한재우 - [HTTP 완벽가이드 9장](https://bebiangel.github.io/2019/10/19/http-guide-chap9/) 17 | 18 | ## [8장] 정리글 리뷰 team 19 | 20 | - 이보라, 고현주 21 | - 이강호, 한재우 22 | - 고석진, 김준형 23 | - 김나영, 류지환 24 | - 고현주, 김나영 25 | -------------------------------------------------------------------------------- /chapter_09/chapter_9_2_고석진.md: -------------------------------------------------------------------------------- 1 | # HTTP 2 | 3 | ## 9.5 로봇 에티켓 4 | - 1. 신원 식별 5 | - 로봇의 신원을 밝히라: User-Agent 를 이용하여 웹 서버에게 로봇의 이름을 밝혀라 6 | - 기계의 신원을 밝혀라: DNS 엔트리를 가진 기계에서 실행된다는 것을 확실히 해서, 웹 사이트가 로봇의 IP 주소를 호스트 명을 통해 역방향 DNS 를 할 수 있도록 해라 7 | - 연락처를 밝혀라: HTTP 폼 필드를 사용해서 연락할 수 있는 이메일 주소를 제공하라 8 | - 2. 동작 9 | - 긴장하라: 로봇이 노련해지기 전까지는 운영자들을 고용해서 감시하라 10 | - 대비하라: 로봇이 여행을 떠나기전에 조직에 사실을 알려둬라 11 | - 감시와 로그: 로봇이 정상적으로 동작하는지 진행상황을 추적하고 기본적인 검사가 가능하도록 진단과 로깅 기능을 풍부하게 갖춰야한다. 12 | - 배우고 조정하라: 크롤링 할 때마다 새로운 것을 배우게 된다. 로봇을 조정하고 개선하라 13 | - 3. 스스로를 제한하라 14 | - URL 을 필터링하라: 이해할 수 없거나 관심 없는 데이터를 참조하고 있다면 무시하는 것이 좋다. 15 | - 동적 URL 을 필터링하라: 보통 로봇은 동적인 게이트웨이로부터의 콘텐츠를 크롤링할 필요가 없다. 16 | - Accept 관련 헤더로 필터링: HTTP accept 관련 헤더들을 이용하여 콘텐츠를 이해할 수 있는지 말해주어야한다. 17 | - robots.txt 에 따르라: 방문 웹 사이트의 robots.txt 를 따라야한다. 18 | - 스스로를 억제하라: 한 사이트에 총 접근 횟수를 제한해야한다. 19 | - 4. 루프와 중복을 견뎌내기, 그리고 그 외의 문제들 20 | - 모든 응답 코드 다루기: 모든 리다이렉트와 에러를 포함한 모든 HTTP 상태 코드를 다룰 수 있도록 준비되어 있어야한다. 21 | - URL 정규화하기: 모든 URL 을 표준화된 형식으로 변경하여 중복된 URL 을 제거하라 22 | - 적극적으로 순환 피하기: 순환을 감지하고 피하기위해 노력하라 23 | - 함정을 감시하라: 의도적이고 악의적인 순환을 피하기위해 함정을 감시하라 24 | - 블랙리스트를 관리하라: 함정, 깨진 사이트등을 블랙리스트로 추가하고 다시는 방문하지 않도록 해라 25 | - 5. 확장성 26 | - 대역폭 이해하기: 얼마나 많은 네트워크 대역폭이 사용 가능한지, 요구되는 시간에 로봇 작업을 끝마치는데 얼마나 필요할지 이해하라. 27 | - 시간 이해하기: 작업을 끝내는데 얼마나 많은 시간이 필요한지 이해하고, 소요된 시간이 추정한 것과 맞는지 간단히 검사해보라 28 | - 분할 정복: 대규모 크롤링을 하는 상황에서는 멀티프로세서 서버든 서로 협력하는 여러 개의 작은 컴퓨터등 하드웨어들이 더 필요할 수 있다. 29 | - 6. 신뢰성 30 | - 철저하게 테스트하라: 풀어놓기전 내부에서 철저하게 테스트하라 31 | - 체크포인트: 체크포인트/재시작 기능을 처음부터 설계하라 32 | - 실패에 대한 유연성: 실패에 대비하여 로못을 실패가 발생했을 때도 계속 동작할 수 있도록 설계하라 33 | - 7. 소통 34 | - 준비하라: 로봇에 대한 정책 안내 페이지를 만들고 robots.txt 를 만드는 법에 대한 설명도 포함하라 35 | - 이해하라: 로봇 차단 규칙 표준에 대해 설명하고, 그래도 만족하지 못한다면 블랙리스트에 추가하라 36 | - 즉각 대응하라: 불만을 갖게되는 요소에 대해서 즉각 대응하라 37 | 38 | ## 9.6 검색엔진 39 | 40 | 웹 로봇을 가장 광범위하게 사용하는 것은 인터넷 검색엔진이다. 41 | 웹 크롤러들은 먹이를 주듯 검색엔진에게 웹에 존재하는 문서들을 가져다 주어서, 검색엔진이 어떤 문서에 어떤 단어들이 존재하는지에 대한 색인을 생성할 수 있게 한다. 42 | 43 | ### 9.6.1 넓게 생각하라 44 | 45 | 초창기에 검색엔진은 단순한 데이터베이스였다. 급격히 웹이 성장하면서 수십억개의 페이지에 접근을 해야하니 단순한 데이터베이스 형식으로는 동작이 어려워졌다. 46 | 47 | ### 9.6.2 현대적인 검색엔진의 아키텍쳐 48 | 49 | 검색엔진들은 가지고 있는 웹페이지들에 대해 '풀 텍스트 색인'이라고 하는 복잡한 로컬 데이터베이스를 생성한다. 50 | 51 | 검색엔진 크롤러들은 웹페이지를 수집 -> 풀텍스트 색인 추가한다. 사용자들은 핫봇이나 구글 같은 웹 검색 게이트웨이를 통해 풀 텍스트 색인에 대한 질의를 보낸다. 52 | 53 | ### 9.6.3 풀 텍스트 색인 54 | 55 | 풀 텍스트 색인은 단어 하나를 입력받아 그 단어를 포함하고 있는 문서를 즉각 알려줄 수 있는 데이터베이스이다. 56 | 이 문서들은 색인이 생성된 후에는 검색할 필요가 없다. 57 | 58 | ### 9.6.4 질의 보내기 59 | 60 | HTML 폼을 사용자가 채우고 브라우저가 폼을 GET / POST 요청을 이용해서 게이트웨이로 보낸다 61 | 게이트웨이는 검색 질의를 추출하고 웹 UI 질의를 풀텍스트 색인을 검색할 때 사용되는 표현식으로 변환한다. 62 | 63 | ### 9.6.5 검색 결괄릊 얼려하고 보여주기 64 | 65 | 검색엔진은 문서들이 주어진 단어와 가장관련이 많은 순서대로 결과 문서에 나타날 수 있도록 문서들 간의 순서를 알 필요가 있다. 66 | 이것은 관련도 랭킹 알고리즘이라 불리며, 검색 결과의 목록에 점수를 매기고 정렬하는 과정이다. 67 | 웹 크롤링하는 과정에서 수집된 통계 데이터를 실제로 사용한다. 68 | 69 | ### 9.6.6 스푸핑 70 | 71 | 웹 사이트를 찾을 때 검색 결과의 순서는 중요하다. 72 | 웹 마스터에게는 자신이 만든 사이트가 그 자신을 가장 잘 설명하는 단어로 검색한 결과의 상단에 노출되도록 만들 동기가 충분하다. 73 | 74 | 많은 페이지들이 특정 단어에 대한 가짜 페이지를 생성하거나 검색엔진의 관련도 알고리즘을 잘 속일 수 있는 게이트웨이를 만들어 사용한다. 75 | 76 | ## HTTP/2.0 77 | 78 | ## 10.1 HTTP/2.0의 등장 배경 79 | 80 | HTTP/1.0 의 메시지 포맷은 구현의 단순성과 접근성에 주안점을 두고 최적화되었다. 81 | 그러다 보니 성능은 어느 정도 희생시키지 않을 수 없었다. 커넥션 하나를 통해 요청 하나를 보내고 그에 대해 응답 하나만을 받는 HTTP 의 82 | 메시지 교환 방식은 단순하지만 응답을 받아야만 다음 요청을 보낼 수 있기 때문에 회전 지연을 피할 수 없었다. 83 | 84 | ## 10.2 개요 85 | 86 | HTTP/2.0 은 서버와 클라이언트 사이의 TCP 커넥션 위에서 동작한다. 이때 TCP 커넥션을 초기화하는 것은 클라이언트다. 87 | 프레임들에 담긴 요청과 응답은 스트림을 통해 보내진다. 한 개의 스트림이 한쌍의 요청과 응답을 처리한다. 88 | 하나의 커넥션 위에 여러 개의 스트림이 동시에 만들어질 수 있으므로, 여러 개의 요청과 응답을 동시에 처리하는 것이 가능하다. 89 | 90 | 기존 애플리케이션들과 호환성을 유지하기 위해 요청과 응답 메시지의 의미를 HTTP/1.0 과 같도록 유지하고있다. 91 | 92 | ## 10.3 HTTP/1.1 과의 차이점 93 | 94 | ### 10.3.1 프레임 95 | 96 | 모든 메시지는 프레임에 담겨 전송된다. 프레임은 8바이트 크기의 헤더로 시작하며 최대 16383 바이트 크기의 페이로드가 온다. 97 | 98 | - R: 예약된 2비트 필드, 값의 의미가 정의되어 있지 않으며, 0 이어야한다. 받는 쪽에서는 이 값을 무시한다. 99 | - 길이: 페이로드의 길이를 나타내는 14비트 무부호 정수, 프레임 헤더는 포함되지 않는다. 100 | - 종류: 프레임의 종류 101 | - 플래그: 8 비트 플래그, 플래그 값의 의미는 프레임의 종류에 따라 다르다 102 | - R: 예약된 1 비트 필드, 첫번째 R 과 같다. 103 | - 스트림 식별자: 31비트 스트림 식별자, 특별히 0은 커넥션 전체와 연관된 프레임을 의미한다. 104 | 105 | ### 10.3.2 스트림과 멀티플렉싱 106 | 107 | 스트림은 커넥션을 통해 클라이언트와 서버 사이에서 교환되는 프레임들의 독립된 양방향 시퀀스다. 108 | 클라이언트는 스트림을 만들어 HTTP 요청을 보낸다. 요청을 받은 서버는 요청과 같은 스트림으로 응답을 보낸다. 스트림을 닫는다. 109 | 110 | HTTP/2.0 은 여러 개의 스트림이 동시에 열릴 수 있다. 뿐만 아니라 스트림은 우선순위도 가질 수 있다. 111 | 모든 스트림은 31 비트의 무부호 정수로 된 고유한 식별자를 갖는다. 112 | 서버와 클라이언트는 스트림을 상대방과 협상 없이 일방적으로 만든다. 113 | 이는 스트림을 만들 때 협상을 위해 TCP 패킷은 주고받느라 시간을 낭비하지 않아도 됨을 의미한다. 114 | 커넥션에서 한번 사용한 스트림 식별자는 다시 사용할 수 없다. 115 | WINDOW_UPDATE 프레임을 이용한 흐름 제어를 통해 스트림들이 서로 간섭해서 망가지는 것을 막아준다. 116 | 117 | ### 10.3.3 헤더 압축 118 | 119 | HTTP/1.1 에서 헤더는 아무런 압축 없이 그대로 전송되었다. 요즘에는 웹페이지 하나를 보기 위해 수십에서 많으면 수백 번의 요청을 보내기 때문에, 헤더의 크기가 회전 지연과 대역폭 양쪽 모두에 실직적인 영향을 끼치게 되었다. 120 | 이를 개선하기 위해 HTTP/2.0 은 메시지의 헤더를 압축하여 전송한다. 121 | 122 | ### 10.3.4 서버 푸시 123 | 124 | 서버가 하나의 요청에 대해 응답으로 여러 개의 리소스를 보낼 수 있도록 해준다. 이 기능은 서버가 클라이언트에서 어떤 리소스를 요구할 것인지 미리 알 수 있는 상황에서 유리하다. 125 | 리소스를 푸시하려는 서버는 먼저 클라이언트에게 자원을 푸시할 것임을 PUSH_PROMISE 프레임을 보내어 미리 알려주어야 한다. 클라이언트가 프레임을 받게 되면 해당 프레임의 스트림은 클라이언트 입장에서는 예약됨 상태가 된다. 126 | 127 | - 서버 푸시를 사용하기로 했더라도, 중간의 프락시가 서버로부터 받은 추가 리소스를 클라이언트에게 전달하기 않을 수 있다. 128 | - 서버는 오직 안전하고, 캐시 가능하고, 본문을 포함하지 않은 요청에 대해서만 푸시를 할 수 있다. 129 | - 푸시할 리소스는 클라이언트가 명시적으로 보낸 요청과 연관된 것이어야 한다. 130 | - 클라이언트는 서버가 푸시한 리소스를 동일 출처 정책에 따라 검사해야한다. 131 | - 서버 푸시를 끄고 싶다면 SETTINGS_ENABLE_PUSH 를 0 으로 설정한다. 132 | 133 | ## 10.4 알려진 보안 이슈 134 | 135 | ### 10.4.1 중개자 캡슐화 공격 136 | 137 | HTTP/2.0 메시지를 중간 프락시가 HTTP/1.1 메시지로 변환할 때 메시지의 의미가 변질될 가능성이 있다. 138 | HTTP/1.1 과 달리 2.0 은 헤더 필드의 이름과 값을 바이너리로 인코딩한다. 이는 HTTP/2.0 이 헤더 필드로 어떤 문자열이든 사용할 수 있게 해준다. 139 | 이는 정상적인 .0 요청이나 응답이, 불법적이거나 위조된 HTTP/1.1 메시지로 번역되는 것을 유발할 수 있다. 140 | 141 | ### 10.4.2 긴 커넥션 유지로 인한 개인정보 노출 우려 142 | 143 | HTTP/2.0 은 사용자가 요청을 보낼 때의 회전 지연을 줄이기 위해 클라이언트와 서버 사이의 커넥션을 오래 유지하는 것을 염두에 두고 있다. 144 | 이것은 개인 정보의 유출에 악용될 가능성이 있다. 어떤 사용자가 브라우저를 사용할 때, 그 사용자는 이전에 브라우저를 사용했던 사용자가 무엇을 했는지 알아낼 가능성도 있다. 145 | 146 | 147 | 148 | 149 | 150 | 151 | -------------------------------------------------------------------------------- /chapter_09/chapter_9_고석진.md: -------------------------------------------------------------------------------- 1 | # HTTP 2 | 3 | ## 웹 로봇 4 | 5 | 웹 로봇은 사람과의 상호작용 없이 연속된 웹 트랜잭션들을 자동으로 수행하는 소프트웨어 프로그램이다. 6 | 웹 사이트를 돌아다니면서 컨텐츠를 가져오고, 하이퍼링크를 따라가고, 발견한 데이터를 처리한다. 7 | 8 | ## 9.1 크롤러와 크롤링 9 | 10 | 웹 크롤러는 페이지를 순회하며 (페이지 내부 링크 포함) 재귀적으로 모든 데이터를 가져오는 방식으로 동작하는 로봇이다. 11 | 12 | ### 9.1.1 루트 집합 13 | 14 | 크롤러가 방문을 시작하는 URL 들의 초기 집합을 루트 집합이라고 부른다. 15 | 일반적으로 좋은 루트 집합은 크고 인기있는 웹사이트, 새로 생성된 페이지들의 목록, 자주 링크되지 않는 페이지들의 목록이다. 16 | 17 | ### 9.1.2 링크 추추롸 상대 링크 정상화 18 | 19 | 크롤러들은 간단한 HTML 파싱을 해서 이들 링크들을 추출하고 상대 링크를 절대 링크로 변환할 필요가 있다. 20 | 21 | ### 9.1.3 순환 피하기 / 9.1.4 루프와 중복 22 | 23 | 웹을 크롤링 할 때 무한루프에 빠지지 않도록 주의해야한다. 24 | 반보되는 순환을 피하기 위해서 반드시 어디를 방문했는지 알아야한다. 25 | 26 | - 순환은 크롤러를 루프에 빠뜨려서 꼼짝 못하게 만들 수 있다. 27 | - 같은 페이지를 반복하여 가져온다면 웹 서버의 부담이 된다. 28 | 29 | ### 9.1.5 빵 부스러기의 흔적 30 | 31 | 로봇은 어떤 URL 이 방문했던 곳인지 빠르게 결정하기 위해 검색 트리나 해시 테이블을 필요로 할 것 이다. 32 | 수억 개의 URL 은 많은 공간을 차지한다. 33 | 34 | - 트리와 해시 테이블: 복잡한 로봇이라면 방문한 URL 을 추적하기 위해 검색 트리나 해시 테이블을 사용했을 수도 있다. 35 | - 느슨한 존재 비트맵: 공간 사용을 최소화하기 위해, 대규모 크롤러들은 존재 비트 배열과 같은 느슨한 자료 구조를 사용한다. 36 | - 체크 포인트: 로봇 프로그램이 갑작스럽게 중단될 경우를 대비해, 방문한 URL 의 목록이 디스크에 저장되었는지 확인한다. 37 | - 파티셔닝: 웹이 성장하면서 한 대의 컴퓨터에서 하나의 로봇이 크롤링을 완수하는 것은 불가능해졌다. 각각이 분리된 한 대의 컴퓨터인 로봇들이 동시에 일하고 있는 농장을 이용한다. 38 | 39 | ### 9.1.6 별칭과 로봇순환 40 | 41 | URL 이 별칭을 가질 수 있는 이상 어떤 페이지를 이전에 방문했었는지 말해주는게 쉽지 않을 때도 있다. 42 | 한 URL 이 또 다른 URL 에 대한 별칭이라면, 그 둘이 서로 달라 보이더라도 사실은 같은 리소스를 가리키고 있다. 43 | 44 | ### 9.1.7 URL 정규화하기 45 | 46 | 웹 로봇은 URL 들을 표준 형식으로 '정규화' 함으로써 다른 URL 과 같은 리소스를 가리키고 있음이 확실한 것들을 미리 제거하려 시도한다. 47 | 48 | - 포트 번호가 명시되지 않았다면, 호스트 명에 ':80' 을 추가한다. 49 | - 모든 %xx 이스케이핑된 문자들을 대응되는 문자로 변환한다. 50 | - # 태그들을 제거한다. 51 | 52 | ### 9.1.8 파일 시스템 링크 순환 53 | 54 | 파일 시스템의 심벌릭 링크는 아무것도 존재하지 않으면서도 끝없이 깊어지는 디렉터리 계층을 만들 수 있기 떄문에 에러를 유발 할 수 있다. 55 | 56 | 1. GET http://www.foo.com/index.html => /index.html => subdir/index.html 57 | 2. http://www.foo.com/subdir/index.html => /index.html 반복 58 | 59 | ### 9.1.10 루프와 중복 피하기 60 | 61 | - URL 정규화: 표준 형태로 변환함으로써, 같은 리소스를 가리키는 중복된 URL 이 생기는 것을 일부 회피한다. 62 | - 너비 우선 크롤링: 방문할 URL 들을 웹 사이트들 전체에 걸쳐 너비 우선으로 스케줄링하면 순환의 영향을 최소화할 수 있다. 63 | - 스로틀링: 일정 시간 동안 가져올 수 있는 페이지의 숫자를 제한한다. 64 | - URL 크기 제한: 일정 길이를 넘는 URL 의 크롤링을 거부 할 수 있다. 65 | - URL/사이트 블랙리스트: 문제를 일으키는 사이트나 URL 이 발견될 때마다 블랙리스트에 추가한다. 66 | - 패턴 발견: 파일시스템의 심벌리 링크를 통한 순환과 그와 비슷한 오설정들은 일정 패턴을 따르는 경향있다. 반복되는 구성요소를 갖고 있는 URL 을 크롤링하는 것을 거절한다. 67 | - 콘턴츠 지문: 로봇이 이전에 보았던 체크섬을 가진 페이지를 가져온다면 해당 페이지는 크롤링 하지 않는다. 68 | - 사람 모니터링: 문제를 예방하기 위해 사람의 모니터링에 더욱 의존한다. 69 | 70 | ## 9.2 로봇의 HTTP 71 | 72 | 로봇 또한 HTTP 명세의 규칙을 지켜야한다. 73 | 74 | ### 9.2.1 요청 헤더 식별하기 75 | 76 | 로봇들은 신원 식별 헤더 (User Agent HTTP 헤더) 를 구현하고 전송한다. 77 | 로봇 구현자들은 로봇의 능력, 신원, 출신을 알려주는 기본적인 몇 가지 헤더를 사이트에게 보내주는 것이 좋다. 78 | 79 | - User Agent: 서버에게 요청을 만든 로봇의 이름을 말해준다. 80 | - From: 로봇의 사용자/관리자의 이메일 주소를 제공한다. 81 | - Accept: 서버에게 어떤 미디어 타입을 보내도 되는지 말해준다. 82 | - Referer: 현재의 요청 URL 을 포함한 문서의 URL 을 제공한다. 83 | 84 | ### 9.2.2 가상 호스팅 85 | 86 | 로봇 구현자들은 Host 헤더를 지원할 필요가 있다. Host 헤더를 포함하지 않으면 로봇이 어떤 URL 에 대해 잘못된 콘텐츠를 찾게 만든다. 87 | 88 | ### 9.2.3 조건부 요청 89 | 90 | 로봇이 검색하는 콘텐츠의 양을 최소화하는 것(변경이 일어났을때만 가져온다던가 .. )은 상당히 의미 있는 일이다. 91 | 92 | ### 9.2.4 응답 다루기 93 | 94 | 웹 탐색이나 서버와의 상호작용을 해보려고 하는 로봇들은 여러 종류의 HTTP 응답을 다룰 줄 알 필요가 있다. 95 | 96 | - 상태코드: 모든 로봇은 200, 404 와 같은 HTTP 상태 코드를 이해해야한다. 97 | - 엔터티: HTTP 헤더에 임베딩된 정보를 따라 로봇들은 엔터티 자체의 정보를 찾을 수 있다. 98 | 99 | ### 9.2.5 User-Agent 타겟팅 100 | 101 | 웹 사이트들은 여러 기능을 지원할 수 있도록 브라우저의 종류를 감지하여 그에 맞게 컨텐츠를 제공한다. 102 | 사이트 관리자들은 로봇의 요청을 다루기 위한 전략을 세워야한다. 103 | 104 | ## 9.3 부적절하게 동작하는 로봇들 105 | 106 | - 폭주하는 로봇: 로봇은 사람보다 훨씬 빠르게 HTTP 요청을 만들 수 있다. 빠른 네트워크 위에서 동작한다. 107 | - 오래된 URL: 로봇들은 존재하지 않는 URL 에 대한 요청을 많이 보낼 수 있다. 존재하지 않는 페이지에 대한 접근 에러가 쌓일 수 있다. 108 | - 길고 잘못된 URL: 크고 의미 없는 URL 을 요청 할 수 있다. 109 | - 호기심이 지나친 로봇: 사적인 데이터에 대한 URL 을 얻어 데이터를 인터넷 검색엔진이나 어플맄이션을 통해 쉽게 접근할 수 있도록 만들 수도 있다. 110 | - 동적 게이트웨이 접근: 로봇은 게이트웨이 애플리케이션의 콘텐츠에 대한 URL로 요청을 할수도 있다. 111 | 112 | ## 9.4 로봇 차단하기 113 | 114 | 로봇의 접근을 제어하는 정보를 저장하는 파일의 이름을 따서 robots.txt 라고 부른다. 115 | xxx/index.html 에 대한 정보를 다운받으려고 할 때 먼저 접근 권한을 확인하기 위해 robots 파일을 검사한다. 116 | 117 | ### 9.4.1 로봇 차단 표준 118 | 119 | - 0.0 (1994.06): 로봇 배제 표준 지시자를 지원하는 마틴 코스터의 오리지널 robots.txt 메커니즘 120 | - 1.0 (1996.11): 웹 로봇 제어 방법 지시자ㅢ 지원이 추가된 마틴 코스터의 IETF 초안 121 | - 2.0 (1996.11): 로봇 차단을 위한 확장 표준 정규식과 타이밍 정보를 포함한 숀 코너의 확장 널리 지원되지는 않는다. 122 | 123 | ### 9.4.2 웹 사이트와 robots.txt 파일들 124 | 125 | URL 을 방문하기전 웹 사이트에 robots.txt 파일이 존재한다면 로봇은 반드시 그 파일을 가져와야 한다. 126 | 127 | - robots.txt 가져오기: robots.txt 파일이 존재한다면 서버는 그 파일은 text/plain 으로 반환한다. 404 상태 코드로 응답한다면 로봇의 접근을 제한하지 않는 것으로 간주하고 어떤 파일이든 요청하게 될 것 이다. 128 | - 응답코드: 129 | - 200 으로 응답하면 로봇은 응답의 컨테츠를 파싱하여 규칙을 얻고 그 규칙을 따라야한다. 130 | - 404 라면 규칙이 존재하지 않는다고 판단하고 제약없이 사이트에 접근한다. 131 | - 401/403 으로 응답하면 접근은 완전히 제한되어 있다고 가정한다. 132 | - 503 은 리소스 검색을 뒤로 미룬다. 133 | - 3XX 리소스가 발견될 때 까지 리다이렉트한다. 134 | 135 | ### 9.4.3 robots.txt 파일 포맷 136 | 137 | robots.txt 파일의 줄은 빈 줄, 주석 줄, 규칙 줄 세가지 종류가 있다. 규칙줄은 HTTP 헤더처럼 생겼고 (<필드>:<값>) 패턴 매칭을 위해 사용된다. 138 | 139 | ```text 140 | User-Agent: slurp 141 | User-Agent: webcrawler 142 | Disallow: /private 143 | 144 | User-Agent: * 145 | Disallow: 146 | ``` 147 | 148 | - User-Agent 줄: 로봇의 레코드는 하나 이상의 User-Agent 줄로 시작한다. 만약 로봇이 대응하는 User-Agent 줄을 찾지 못하였고 와일드 카드를 사용한 줄도 찾지 못했다면 어떤 제한도 없다 149 | - Disallow 와 Allow 줄들: 특정 로봇에 대해 어떤 URL 경로가 명시적으로 금지되어 있고 명시적으로 허용되는지 기술한다. 150 | - Disallow/Allow 접두매칭 151 | - 어떤 규칙 경로가 빈 문자열이라면, 그 규칙은 모든 URL 경로와 같아야한다. 152 | - * 는 특별한 의미를 갖지 않는다. 153 | - Disallow/Allow 규칙이 경로에 적용되면, 그 경로의 시작부터 규칙 경로의 길이만큼의 문자열이 규칙 경로와 같아야한다. 154 | 155 | ### 9.4.4 그 외에 알아둘 점 156 | 157 | - 명세 발전에 따라 User-Agnet, Disallow, Allow 외에 다른 필드를 포함할 수 있다. 이해 못하는 필드는 무시된다. 158 | - 하위 호환성을 위해 여러줄 작성은 할 수 없다. 159 | - 주석은 파일의 어디든 허용된다. 160 | - 0.0 버전은 Allow 줄을 지원하지 않았다. 161 | 162 | ### 9.4.5 robots.txt 의 캐싱과 만료 163 | 164 | 매 요청마다 robots.txt 를 가져온다면 효율적이지 못하다. 로봇은 주기적으로 robots.txt 를 가져와서 그 결과를 캐시한다. 165 | 로봇은 HTTP 응답의 Cache-Control 과 Expires 헤더에 주의를 기울여야 한다. 166 | 167 | ### 9.4.7 HTML 로봇 제어 META 태그 168 | 169 | ```text 170 | 171 | ``` 172 | 173 | - NOINDEX: 이 페이지를 처리하지 말고 무시 174 | - NOFOLLOW: 이 페이지가 링크한 페이지를 크롤링하지 마라 175 | - INDEX: 페이지 인덱싱 허용 176 | - FOLLOW: 링크한 페이지 크롤링 허용 177 | - NOARCHIVE: 페이지 캐시를 위한 로컬 사본을 만들면 안된다 178 | - ALL: INDEX, FOLLOW 와 같다 179 | - NONE: NOINDEX, NOFOLLOW 와 같다 180 | - 검색엔진 META 태그 181 | - DESCRIPTION: 웹 페이지의 짧은 요약을 정의 182 | - KEYWORDS: 키워드 검색을 돕는다. 183 | - REVISIT-AFTER: 지정된 만큼의 날짜가 지난 이후에 다시 방문해야 한다고 지시 184 | 185 | ``` 186 | 다음주에 계속 ... 187 | 188 | ## 9.5 로봇 에티켓 189 | 190 | - 1. 신원 식별 191 | - 로봇의 신원을 밝히라: User-Agent 를 이용하여 웹 서버에게 로봇의 이름을 밝혀라 192 | - 기계의 신원을 밝혀라: DNS 엔트리를 가진 기계에서 실행된다는 것을 확실히 해서, 웹 사이트가 로봇의 IP 주소를 호스트 명을 통해 역방향 DNS 를 할 수 있도록 해라 193 | - 연락처를 밝혀라: HTTP 폼 필드를 사용해서 연락할 수 있는 이메일 주소를 제공하라 194 | - 2. 동작 195 | - 긴장하라: 로봇이 노련해지기 전까지는 운영자들을 고용해서 감시하라 196 | - 대비하라: 로봇이 여행을 떠나기전에 조직에 사실을 알려둬라 197 | ``` 198 | 199 | -------------------------------------------------------------------------------- /chapter_10/README.md: -------------------------------------------------------------------------------- 1 | # [9장/10장] HTTP:아키텍처 / 웹로봇 chap5 - chpa6, http/2.0 2 | 3 | - 마감일: 10월 28일 월요일 자정 4 | - todo: 5 | - 9장 웹로봇 chap5 - chpa6 6 | - 10장 http/2.0 7 | 8 | ## 정리 글 링크 9 | 10 | 1. 고석진 11 | 2. 고현주 12 | 3. 김나영 13 | 4. 김준형 - [HTTP - 9장](https://junjangsee.github.io/2019/10/20/network/network-09/), [HTTP - 10장](https://junjangsee.github.io/2019/10/27/network/network-10/) 14 | 5. 류지환 15 | 6. 이강호 16 | 7. 이동규 - [HTTP 완벽가이드 스터디 #10 - http/2.0](https://github.com/brainbackdoor/bbd-http-web/tree/feat/http2/docs/http2) 17 | 8. 이보라 18 | 9. 한재우 - [HTTP 완벽가이드 10장](https://bebiangel.github.io/2019/10/27/http-guide-chap10/) 19 | 20 | ## [9장] 정리글 리뷰 team 21 | 22 | - 고현주, 이강호 23 | - 이보라, 이동규 24 | - 류지환, 이강호 25 | - 김준형, 한재우 26 | - 고석진, 김나영 27 | -------------------------------------------------------------------------------- /chapter_11/README.md: -------------------------------------------------------------------------------- 1 | # [11장] HTTP:식별, 인가 보안 / 클라이언트 식별과 쿠키 2 | 3 | - 마감일: 11월 18일 월요일 자정 4 | - todo: 5 | - 11장 클라이언트 식별과 쿠키 6 | 7 | ## 정리 글 링크 8 | 9 | 1. 고석진 10 | 2. 고의성 - [클라이언트 식별과 쿠키](https://abelog.netlify.com/http/%ED%81%B4%EB%9D%BC%EC%9D%B4%EC%96%B8%ED%8A%B8-%EC%8B%9D%EB%B3%84%EA%B3%BC-%EC%BF%A0%ED%82%A4/) 11 | 3. 김나영 - [클라이언트 식별](https://feel5ny.github.io/2019/11/15/HTTP_011_01/), [쿠키 🍪](https://feel5ny.github.io/2019/11/16/HTTP_011_02/) 12 | 4. 류지환 13 | 5. 이승규 - [클라이언트 식별과 쿠키](https://ideveloper2.dev/blog/2019-11-16--%ED%81%B4%EB%9D%BC%EC%9D%B4%EC%96%B8%ED%8A%B8-%EC%8B%9D%EB%B3%84%EA%B3%BC-%EC%BF%A0%ED%82%A4//) 14 | 6. 한재우 - [HTTP 완벽가이드 11장](https://bebiangel.github.io/2019/11/10/http-guide-chap11/) -------------------------------------------------------------------------------- /chapter_11/고석진.md: -------------------------------------------------------------------------------- 1 | # HTTP 완벽가이드 2 | 3 | ## 클라이언트 식별과 쿠키 4 | 5 | ### 11.1 개별 접촉 6 | 7 | HTTP 는 익명으로 사용하며 상태가 없고 요청과 응답으로 통신하는 프로토콜이다. 8 | 웹 서버는 요청을 보낸 사용자를 식별하거나 방문자가 보낸 연속적인 요청을 추적하기 위해 약간의 정보를 이용할 수 있다. 9 | 10 | - 개별 인사: 온라인 쇼핑이 개인에게 맞춰져 있는 것처럼 느끼게 하려고 사용자에게 특화된 환영 메시지나 페이지 내용을 만든다. 11 | - 사용자 맞춤 추천: 고객의 흥미를 학습하여 좋아할 것으로 예상되는 제품을 추천할 수 있다. 12 | - 저장된 사용자 정보: 쇼핑을 편하게 할 수 있게 저장된 사용자 정보를 사용할 수 있다. 13 | - 세션 추적: 위와 같은 사이트와의 상호작용을 위해서는 사용자에게서 오는 HTTP 트랜잭션을 식별할 방법이 필요하다. 14 | - 사용자 식별 관련 정보를 전달하는 HTTP 헤더 15 | - IP 주소로 사용자를 식별 16 | - 사용자 로그인 인증을 통한 사용자 식별 17 | - URL 에 식별자를 포함하는 기술인 뚱뚱한 URL 18 | - 식별 정보를 지속해서 유지하는 강력하면서도 효율적인 기술인 쿠키 19 | 20 | ### 11.2 HTTP 헤더 21 | 22 | | Form | 요청 | 사용자의 이메일 주소 | 23 | |-----------------|------|------------------------------------------| 24 | | User-Agent | 요청 | 사용자의 브라우저 | 25 | | Referer | 요청 | 사용자가 현재 링크를 타고 온 근원 페이지 | 26 | | Authorization | 요청 | 사용자 이름과 비밀번호 | 27 | | Client-ip | 확장 | 클라이언트의 IP 주소 | 28 | | X-Forwarded-For | 확장 | 클라이언트의 IP 주소 | 29 | | Cookie | 확장 | 서버가 생성한 ID 라벨 | 30 | 31 | - Form 헤더에는 사용자 이메일 주소를 포함한다. 악용될 여지가 있어 Form 헤더를 보내는 브라우저는 많지 않다. 로봇이나 스파이더는 웹 사이트에 항의메일을 보낼 수 있도록 Form 헤더에 이메일 주소를 기술한다. 32 | - User-Agent 헤더는 사용자가 쓰고있는 브라우저의 이름과 버전 정보, 운영체제에 대한 정보를 포함한다. 33 | - Referer 헤더는 유입하게 한 웹페이지의 URL 을 가리킨다. 사용자 자체 식별은 불가하지만 사용자의 취향을 파악하는데 도움을 준다. 34 | 35 | ### 11.3 클라이언트 IP 주소 36 | 37 | 클라이언트 IP 주소로 사용자를 식별하는 방식은 다음과 같은 약점을 가지고있다. 38 | 39 | - 클라이언트 IP는 사용자가 아닌, 사용자가 사용하는 컴퓨터를 가리킨다. 40 | - 동적으로 IP 주소를 할당 받을 경우 사용자는 매번 새로운 IP 주소를 할당 받는다 41 | - 보안을 강화하기 위해 많은 사용자가 네트워크 주소 변환 방화벽을 통해 인터넷을 사용한다 42 | - HTTP 프락시와 게이트웨이는 원 서버에 새로운 TCP 연결을 한다. 43 | 44 | ### 11.4 사용자 로그인 45 | 46 | 웹 서버는 사용자 이름과 비밀번호로 인증할 것을 요구해서 사용자에게 명시적으로 식별 요청을 할 수 있다. 47 | 웹 사이트 로그인이 더 쉽도록 HTTP 는 WWW-Authenticate 와 Authorization 헤더를 사용해 웹 사이트에 사용자 이름을 전달하는 자체적인 체계를 가지고 있다. 48 | 49 | 서버에서 접근전 로그인을 시키고자 한다면 401 Login Required 응답 코드를 브라우저에 보낼 수 있다. 50 | 51 | ### 11.5 뚱뚱한 URL 52 | 53 | URL 은 URL 경로의 처음이나 끝에 어떤 상태 정보를 추가해 확장한다. 54 | 뚱뚱한 URL 은 아래와 같은 문제점이 있다. 55 | 56 | - 못생긴 URL: 뚱뚱한 URL 은 사용자에게 혼란을 준다. 57 | - 공유하지 못하는 URL: 뚱뚱한 URL 은 사용자와 세션에 대한 상태 정보를 포함한다. 공유시 정보 노출에 위험이 있다. 58 | - 캐시를 사용할 수 없음: URL이 달라지기 때문에 기존 캐시에 접근할 수 없다. 59 | - 서버 부하 가중: 서버는 뚱뚱한 URL 에 해당하는 HTML 페이지를 다시 그려야 한다. 60 | - 이탈: 의도치 않게 뚱뚱한 URL 세션에서 이탈했을때 이전 정보가 초기화된다. 61 | - 세션 간 지속성의 부재: URL 을 북마킹 하지 않는이상 로그아웃하면 모든 정보를 잃는다. 62 | 63 | ## 11.6 쿠키 64 | 65 | 쿠키는 사용자를 식별하고 세션을 유지하는 방식 중에서 현재까지 가장 널리 사용하는 방식이다. 66 | 쿠키는 캐시와 충돌할 수 있어서 대부분의 캐시나 브라우저는 쿠키에 있는 내용물을 캐싱하지 않는다. 67 | 68 | ### 11.6.1 쿠키의 타입 69 | 70 | 크게 세션쿠키 / 지속 쿠키 두 가지 타입으로 나눌 수 있다. 71 | 세션 쿠키는 사용자가 사이트를 탐샐할 때, 관련한 설정과 신호 사항들을 저장하는 임시 쿠키다. 브라우저를 닫으면 삭제된다. 72 | 지속 쿠키는 삭제되지 않고 더 길게 유지될 수 있다. 디스크에 저장되어 브라우저를 닫거나 재시작하더라도 남아있다. 73 | Expires 혹은 Max-Age 가 없으면 세션쿠키가된다. 74 | 75 | ### 11.6.2 쿠키는 어떻게 동작하는가 76 | 77 | 쿠키는 이름=값 형태의 리스트를 가진다. 리스트는 Set-Cookie 혹은 Set-Cookie2 같은 HTTP 응답 헤더에 기술되어 사용자에게 전달된다. 78 | 브라우저는 서버로부터 온 쿠키 컨텐츠를 브라우저 쿠키 데이터베이스에 저장한다. 79 | 80 | ### 11.6.3 쿠키 상자: 클라이언트 측 상태 81 | 82 | 쿠키의 기본적인 발상은 브라우저가 서버 관련 정보를 저장하고, 사용자가 해당 서버에 접근할 떄마다 그 정보를 함께 전송하게 하는 것이다. 83 | 브라우저는 쿠키 정보를 저장할 책임이 있는데, 이 시스템을 클라이언트 측 상태라고한다. 쿠키 명세에서 이것의 공식적인 이름은 HTTP 상태 관리 체계이다. 84 | 85 | #### 구글 크롬 쿠키: 구글 크롬은 Cookies 라는 SQLite 파일에 쿠키를 저장한다. 86 | 87 | - creation_utc: 쿠키가 생성된 시점 88 | - host_key: 쿠키의 도메인 89 | - name: 쿠키의 이름 90 | - value: 쿠키의 값 91 | - path: 쿠키와 관련된 도메인에 있는 경로 92 | - expire_utc: 쿠키의 파기 시점 93 | - secure: 쿠키를 SSL 커넥션일 경우에만 보낼지 여부 94 | 95 | 96 | ### 11.6.4 사이트마다 각기 다른 쿠키들 97 | 98 | 브라우저는 쿠키를 모든 사이트에 보내지 않는다. 99 | 100 | - 쿠키를 모두 전달하면 성능이 저하된다. 101 | - 서버에 특화된 이름을 가지고 있기 때문에 대부분의 사이트에서는 무의미한 값이다 102 | - 잠재적인 개인정보 문제를 일으킬 수 있다. 103 | 104 | 보통 브라우저는 쿠키를 생성한 서버에게만 쿠키에 담긴 정보를 전달한다. 105 | 106 | #### 쿠키 Domain 속성 107 | 108 | 서버는 쿠키를 생성할 때 Set-Cookie 응 답 헤더에 Domain 속성을 기술해서 어떤 사이트가 쿠키를 읽을 수 있는지 제어할 수 있다. 109 | 110 | ```text 111 | Set-cookie: user="mary17"; domain="xxxxx.com" 112 | ``` 113 | 114 | #### 쿠키 Path 속성 115 | 116 | 웹 사이트 일부에만 쿠키를 적용할 수도 있다. URL 경로의 앞부분을 가리키는 Path 속성을 기술해서 해당 경로에 속하는 페이지에만 쿠키를 전달한다. 117 | 118 | ```text 119 | Set-cookie: pref=compact; domain="xxxxx.com"; path=/autos/ 120 | ``` 121 | 122 | ### 11.6. 쿠키 구성요소 123 | 124 | 현재 사용되는 쿠키 명세에는 Version 0 쿠키와 Version 1 쿠키가 있다. Version1 쿠키는 0 쿠키의 확장으로 널리 쓰이지는 않는다. 125 | 126 | ### 11.6.6 Version 0 넷스케이프 쿠키 127 | 128 | ```text 129 | Set-Cookie: name=value [; expires=date] [; path=path] [; domain=domain] [; secure] 130 | Cookie: name1=value1 [; name2=value2] 131 | ``` 132 | 133 | - 이름=값: Set-Cookie: customer=Mary 134 | - Expires: 선택적인 속성, 쿠키의 생명주기를 가리키는 날짜 문자열을 기술 135 | - Domain: 선택적인 속성, 이 속성에 기술된 도메인을 사용하는 서버 호스트 명으로만 쿠키를 전송한다. 136 | - Path: 선택적인 속성, 서버에 있는 특정 문서에만 쿠키를 할당할 수 있다. 137 | - Secure: 선택적인 속성, 쿠키는 HTTP 가 SSL 보안 연결을 사용할 때만 쿠키를 전송한다. 138 | 139 | #### Version 0 Cookie 헤더 140 | 141 | 클라이언트가 서버에 요청을 보낼 때는 Domain, Path, Secure 필터들이 현재 요청하려고 하는 사이트에 들어 맞으면서 아직 파기되지 않은 쿠키들을 함께 보낸다. 모든 쿠키는 Cookie 헤더에 한데 이어 붙여 보낸다. 142 | 143 | ```text 144 | Cookie: seesion-id=002-1145265; session-id-time=1007884800 145 | ``` 146 | 147 | ### 11.6.7 Version1 RFC 2965 쿠키 148 | 149 | RFC 2965 쿠키 표준은 워 버전인 넷스케이프 표준보다 좀 더 복잡하며, 모든 브라우저나 서버가 완전히 지원하지 않는다. 150 | 추가된 변경사항은 아래와 같다. 151 | 152 | - 쿠키마다 목적을 설명하는 설명문이 있다. 153 | - 파기 주기에 상관없이 강제 삭제가 가능하다 154 | - 날짜 값 대신에 초 단위의 상대 값으로 쿠키의 생명주기를 결정할 수 있는 Max-age 155 | - URL 의 포트번호로도 쿠키를 제어할 수 있다. 156 | - 호환되는 버전 번호 157 | - 도메인 포트 경로 필터가 있으면 Cookie 헤더에 담겨 되돌려 보낸다 158 | - 키워드 구별을 위해 Cookie 헤더에 $ 접두어가 있다. 159 | 160 | #### Version1 Set-Cookie2 헤더 161 | 162 | Version1 쿠키 표준에는 넷스케이프 표준보다 더 많은 속성이 있다. 163 | 164 | - 이름=값: 필수 속성, $는 예약 문자이므로 쿠키 이름은 $ 로 시작하면 안된다. 165 | - Version: 쿠키 명세의 버전을 가리키는 정수 값 166 | - Comment: 선택적인 속성, 서버가 쿠키를 사용하려는 의도를 기술한다. 167 | - CommentURL: 선택적인 속성, 쿠키를 사용하는 목적과 정책에 대해 상세히 기술된 웹 페이지 링크를 제공한다. 168 | - Discard: 선택적인 속성, 클라이언트 프로그램이 종료될 때 클라이언트가 해당 쿠키를 삭제한다. 169 | - Domain: 선택적인 속성, 기술된 도메인에 해당하는 서버 호스트들에게만 쿠키를 전송한다. 170 | - Max-Age: 선택적인 속성, 쿠키의 생명주기를 초 단위로 산정한 정수 값 171 | - Path: 선택적인 속성, 특정 문서에만 쿠키를 할당 할 수 있다. 172 | - Port: 선택적인 속성, 값이 없이 속성으 ㅣ키워드만 기술할 수도 있고, 적용될 포트 한 개 이상을 콤마로 구분하여 기술할 수 있다. 173 | - Secure: 선택적인 속성, HTTP가 SSL 보안 연결을 사용할 때만 쿠키가 전송된다. 174 | 175 | #### Version1 Cookie 헤더 176 | 177 | Version1 Cookie 는 전송하려는 각 쿠키에 추가 정보를 담는데, 추가 정보에는 해당 쿠키가 가지고 있던 필터 중에서 현재의 사이트에 들어맞는 필터를 기술한다. 178 | 서버가 응답과 함께 전송했던 Set-Cookie2 헤더에 있는 Domain, Port, Path 같은 속성중에서, 들어맞는 필터를 함께 기술하여 쿠키를 전송해야한다. 179 | 180 | #### Version 1 Cookie2 헤더와 버전 협상 181 | 182 | Cookie2 요청 헤더는 각기 다른 쿠키 버전을 지원하는 클라이언트와 서버 간에 호환성을 협상하는 용도로 사용한다. 183 | Cookie2 헤더는 사용자 에이전트가 새로운 형식의 쿠키를 지원하며, 해당 쿠키 표준의 버전 정보를 서버에 제공한다. 184 | 185 | 만약 클라이언트가 같은 쿠키를 Set-Cookie 와 Set-Cooki2 헤더에 기술해서 모두 보내면 이전 방식인 Set-Cookie 헤더를 무시한다. 186 | 187 | ### 11.6.8 쿠키와 세션 추적 188 | 189 | 쿠키는 웹 사이트에 수차례 트랜잭션을 만들어내는 사용자를 추적하는데 사용한다. 190 | 전자상거래 웹 사이트는 사용자가 온라인 쇼핑을 하는 중에도 그들의 쇼핑카드를 유지하려 세션 쿠키를 사용한다. 191 | 192 | ### 11.6.9 쿠키와 캐싱 193 | 194 | 쿠키 트랜잭션과 관련된 문서를 캐싱하는 것은 주의해야한다. 이전 사용자의 쿠키가 다른 사용자에게 할당돼버리거나, 누군가의 개인 정보가 다른 이에게 노출되는 최악의 상황이 일어날 수도 있다. 195 | 196 | - 캐시되지 말아야 할 문서가 있다면 표시하라 197 | - Set-Cookie 헤더를 캐시하는 것에 유의하라: 캐시가 요청마다 원 서버와 재검사시켜 클라이언트로 가는 응답에 set-cookie 헤더 값을 기술할 수 있다. 198 | - Cookie 헤더를 가지고 있는 요청 주의하라: 요청이 Cookie 헤더와 함께 오면, 결과 컨텐츠가 개인정보를 담고 있을 수도 있다. 199 | 200 | ### 11.6.10 쿠키, 보안 그리고 개인정보 201 | 202 | 개인정보를 다루거나 사용자를 추적하는 기술은 잘못된 의도로 사용될 수 있기 때문에 항상 조심해야한다. 203 | 쿠키에 대한 부정적인 여론이 많기는 하지만, 제공하는 개인정보를 누가 받는지 명확히 알고 사이트의 개인정보 정책에만 유의한다면 쿠키에 관련한 위험성보다 세션 조작이나 트랜잭션상의 편리함이 더 크다 204 | 205 | 206 | 207 | 208 | 209 | 210 | 211 | 212 | 213 | 214 | 215 | 216 | 217 | -------------------------------------------------------------------------------- /chapter_12/README.md: -------------------------------------------------------------------------------- 1 | # [12장] HTTP:식별, 인가 보안 / 기본인증 2 | 3 | - 마감일: 11월 25일 월요일 자정 4 | - todo: 5 | - 12장 기본인증 - 13장 다이제스트 인증 (chap1 - chap3) 6 | 7 | ## 정리 글 링크 8 | 9 | 1. 고석진 10 | 2. 고의성 11 | 3. 김나영 - [기본인증](https://feel5ny.github.io/2019/11/23/HTTP_012_01/), [다이제스트 인증](https://feel5ny.github.io/2019/11/24/HTTP_012_02/) 12 | 4. 류지환 13 | 5. 이승규 - [기본 인증, 다이제스트 인증](https://ideveloper2.dev/blog/2019-11-23--%EA%B8%B0%EB%B3%B8-%EC%9D%B8%EC%A6%9D-%EB%8B%A4%EC%9D%B4%EC%A0%9C%EC%8A%A4%ED%8A%B8-%EC%9D%B8%EC%A6%9D/) 14 | 6. 한재우 - [HTTP 완벽가이드 12장](https://bebiangel.github.io/2019/11/24/http-guide-chap12/) 15 | -------------------------------------------------------------------------------- /chapter_12/고석진.md: -------------------------------------------------------------------------------- 1 | # HTTP 2 | 3 | ## 기본 인증 4 | 5 | ## 12.1 인증 6 | ### 12.1.1 HTTP의 인증요구/응답 프레임워크 7 | 8 | HTTP 는 사용자 인증을 하는 데 사용하는 자체 인증요구/응답 프레임워크를 제공한다. 9 | 웹 애플리케이션이 HTTP 요청 메시지를 받으면, 서버는 요청을 처리하는 대시넹 사용자가 누구인지를 알 수 있게 개인정보를 요구하는 '인증요구'로 응답할 수 있다. 10 | 11 | ### 12.1.2 인증 프로토콜과 헤더 12 | 13 | HTTP 는 필요에 따라 고쳐 쓸 수 있는 제어 헤더를 통해, 다른 인증 프로토콜에 맞추어 확장할 수 있는 프레임워크를 제공한다. 14 | 15 | - 요청(GET): 첫 번째 요청에는 인증 정보가 없다. 16 | - 인증요구(401 Unauthorized): WWW-Authenticate 헤더, 사용자에게 이름과 비밀번호를 제공하라는 지시의 의미로 401 상태 정보와 함께 요청을 반려한다. 17 | - 인증(GET): Authorization 헤더, 인증 알고리즘과 사용자 이름 비밀번호를 기술한 Authorization 헤더를 같이 보낸다. 18 | - 성공(200 OK): Authentication-Info: 인증 정보가 정확하면, 서버는 문서와 함께 응답한다. 19 | 20 | ### 12.1.3 보안 영역 21 | 22 | 웹 서버는 보안 영역(realm) 그룹으로 나눈다. 보안 영역은 저마다 다른 사용자 권한을 요구한다. 23 | 24 | ``` 25 | HTTP/1.0 401 Unauthorized 26 | WWW-Authenticate: Basic relam="Corporate Financials" 27 | ``` 28 | 29 | ## 12.2 기본 인증 30 | 31 | 기본 인증은 원래 HTTP/1.0 에 기술되어 있었지만, HTTP 인증의 상세 내용을 다루는 RFC 2617 로 옮겨졌다. 32 | 기본 인증에서 웹 서버는 클라이언트의 요청을 거부하고 유효한 사용자 이름과 비밀번호를 요구할 수 있다. 33 | 서버는 200 대신 401 상태 코드와 함께, 클라이언트가 접근하려고 했던 보안 영역을 WWW-Authenticate 에 기술해서 응답하여 인증요구를 시작한다. 34 | 브라우저는 사용자가 입력한 정보를 Authorization 요청 헤더 안에 암호화해서 서버로 보낸다. 35 | 36 | ### 12.2.1 기본 인증의 예 37 | 38 | - 인증요구 (서버에서 클라이언트): realm 은 요청받은 문서 집합의 이름을 따옴표로 감싼 것으로, 이 정보를 보고 어떤 비밀번호를 사용해야하는지 알 수 있다. 39 | `WWW-Authenticate" Basic realm=따옴표로 감싼 문서 집합 정보` 40 | - 응답 (클라이언트에서 서버로): 사용자 이름과 비밀번호는 콜론으로 잇고, base-64 로 인코딩해서 사용자 이름과 비밀번호에 쉽게 구게문자를 포함할 수 있게 하고, 네트워크 트래픽에 사용자 이름과 비밀번호가 노출되지 않게한다. 41 | `Authoization: Basic base-64 로 인코딩한 사용자 이름과 비밀번호` 42 | 43 | ### 12.2.2 Base-64 사용자 이름/비밀번호 인코딩 44 | 45 | HTTP 기본 인증은 사용자 이름과 비밀번호를 콜론으로 이어서 합치고, base-64 인코딩 메서드를 사용해 인코딩한다. 46 | base-64 인코딩은 8 비트 바이트로 이루어져 있는 시퀀스를 6 비트 덩어리의 시퀀스로 변환환다. 47 | base-64 는 바이너리, 텍스트, 국제 문자 데이터 문자열을 받아서 전송할 수 있게, 그 문자열을 전송가능한 문자인 알파벳으로 변환하기 위해 발명됐다. 48 | 서버나 네트워크를 관리하면서 뜻하지 않게 사용자 이름과 비밀번호가 노출되는 문제를 예방하는데 도움이된다. 49 | 50 | ### 12.2.3 프락시 인증 51 | 52 | 프락시 서버에서 접근 정책을 중앙 관리 할 수 있기 때문에, 리소스전체에 대해 통합적인 접근 제어를 하기 위해서 프락시 서버를 이용하면 좋다. 53 | 54 | ## 12.3 기본 인증의 보안 결함 55 | 56 | 1. 기본 인증은 사용자 이름고 ㅏ비밀번호를 쉽게 디코딩할 수 있는 형식으로 네트워크에 전송된다. 모든 HTTP 트랜잭션을 SSL 암호화 채널을 통해 보내거나, 보안이 더 강화된 다이제스트 인증 같은 프로토콜을 사용하는 것이 좋다. 57 | 2. 읽기 힘든 사용자 이름과 비밀번호를 캡처한ㄷ 아므, 그것을 그대로 원 서버에 보내서 인증에 성공하고 서버에 접근 할 수 있다. 58 | 3. 메세지의 인증 헤더를 건드리지는 않지만, 다른 부분을 수정해서 트랜잭션의 본래 ㅡ이도를 바꿔버리는 프락시나 중개자가 중간에 개입하는 경우, 기본 인증은 정상적인 동작을 보장하지 않는다. 59 | 4. 가짜 서버의 위장에 취약하다. 60 | 61 | 62 | 63 | 64 | 65 | 66 | 67 | 68 | -------------------------------------------------------------------------------- /chapter_13/README.md: -------------------------------------------------------------------------------- 1 | # [14장] HTTP:식별, 인가 보안 / 보안 HTTP 2 | 3 | - 마감일: 12월 09일 월요일 자정 4 | - todo: 5 | - 14장 보안HTTP (chap7 - chap10) 6 | 7 | ## 정리 글 링크 8 | 9 | 1. 고석진 10 | 2. 고의성 11 | 3. 김나영 - [다이제스트 인증(2) - 실제 다이제스트 인증과 보안](https://feel5ny.github.io/2019/12/01/HTTP_013_02/), [HTTPS 이해를 위한 디지털 암호학](https://feel5ny.github.io/2019/12/01/HTTP_014_01/) 12 | 4. 류지환 13 | 5. 이승규 - [기본 인증, 다이제스트 인증](https://ideveloper2.dev/blog/2019-11-23--%EA%B8%B0%EB%B3%B8-%EC%9D%B8%EC%A6%9D-%EB%8B%A4%EC%9D%B4%EC%A0%9C%EC%8A%A4%ED%8A%B8-%EC%9D%B8%EC%A6%9D/) , [보안 HTTP](https://ideveloper2.dev/blog/2019-11-30--%EB%B3%B4%EC%95%88-http/) 14 | 6. 한재우 - [HTTP 완벽가이드 13장](https://bebiangel.github.io/2019/11/24/http-guide-chap13/) 15 | -------------------------------------------------------------------------------- /chapter_13/고석진.md: -------------------------------------------------------------------------------- 1 | # HTTP 2 | 3 | ## 다이제스트 인증 4 | 5 | 다이제스트 인증은 기본 인증과 호환되는 더 안전한 대체재로서 개발되었다. 6 | 7 | ## 13.1 다이제스트 인증의 개선점 8 | 9 | - 비밀번호를 평문으로 전송하지 않는다. 10 | - 인증 체결을 가로채서 재현하려는 악의적인 사람들을 차단한다. 11 | - 메시지 내용 위조를 막는 것도 가능하다. 12 | 13 | 다이제스트 인증이 가장 안전한 프로토콜은 아니다. 안전한 HTTP 트랜잭션을 위한 많은 요구사항을 만족하지 못한다. 14 | 15 | ### 13.1.1 비밀번호를 안전하게 지키기 위해 요약 사용하기 16 | 17 | 비밀번호를 보내는 대신, 클라이언트는 비밀번호를 비가역적으로 뒤섞은 지문 혹은 요약을 보낸다. 18 | 클라이언트 서버는 둘 다 비밀번호를 알고 있기 때문에 비밀번호가 대응하는지 검사가 가능하다 19 | 20 | ### 13.1.2 단방향 요약 21 | 22 | 인기있는 요약 함수 중 하나인 MD5는 임의의 바이트 배열을 원래 길이와 상관없이 128 비트로 요약한다. 23 | 만약 비밀번호를 모른다면 서버에게 보내줄 알맞은 요약을 추측하기 위해 많은 시간을 소모하게 될 것이다. 24 | 128비트의 MD5 출력은 32글자의 16진수 문자로 표현되며, 각 문자는 각각 4 비트의 값을 의미한다. 25 | 26 | ### 13.1.3 재전송 방지를 위한 난스 사용 27 | 28 | 비밀번호를 모른다고 해도 요약을 가로채서 서버로 몇 번이고 재전송할 수 있다. 29 | 이런 재전송 공격을 방지하기 위해서 서버는 클라이언트에게 난스라고 불리는 특별한, 자주 바뀌는 증표를 건네준다. 30 | 저장된 비밀번호 요약은 특정 난스 값에 대해서만 유효하고, 비밀번호 없이 공격자가 올바른 요약을 계산하는 것은 가능하지 않다. 31 | 32 | ### 13.1.4 다이제스트 인증 핸드셰이크 33 | 34 | HTTP 다이제스트 인증 프로토콜은 기본 인증에서 사용하는 것과 비스한 헤더를 사용하는, 강화된 버전의 인증이다. 35 | 36 | - 1단계에서 서버는 난스값을 계산한다. 37 | - 2단계에서 서버는 난스를 WWW-Authenticate 인증요구 메시지에 담아, 서버가 지원하는 알고리즘 목록과 함께 클라이언트에 전송한다. 38 | - 3단계에서 클라이언트는 알고리즘을 선택하고 데이터에 대한 요약을 계산한다. 39 | - 4단계에서 클라이언트는 Authorization 메시지에 요약을 담아 서버에게 돌려준다. 40 | - 5단계에서 서버는 요약, 선택한 알고리즘, 그 외 보조 데이터들을 받고, 클라이언트가 했던 그대로 요약을 계산한다. 41 | 42 | ## 13.2 요약 계산 43 | 44 | 다이제스트 인증의 핵심은 공개된 정보, 비밀 정보, 시한부 난스 값을 조합한 단방향 요약이다. 45 | 46 | ### 13.2.1 요약 알고리즘 입력 데이터 47 | 48 | - 단방향 해시 함수H(d)와 요약 함수 KD(s,d) 여기서 s는 비밀을 d는 데이터를 의미한다. 49 | - 비밀번호 등 보안 정보를 담고 있는 데이터 덩어리, A1 이라 칭한다. 50 | - 요청 메시지의 비밀이 아닌 속성을 담고 있는 데이터 덩어리, A2라 칭한다. 51 | 52 | ### 13.2.2 H(d)와 KD(s,d) 알고리즘 53 | 54 | RFC2617 에서 제안된 두 알고리즘은 MD5와 MD5-sess이며, 만약 알고리즘이 정해지지 않았다면 MD5가 기본값이다 55 | 56 | ``` 57 | H(<데이터>) = MD5(<데이터>) 58 | KD(<비밀>,<데이터>) = H(연결(<비밀>:<데이터>)) 59 | ``` 60 | 61 | ### 13.2.3 보안 관련 데이터 (A1) 62 | 63 | - A1: 데이터 덩어리는 사용자 이름, 비밀번호, 보호 영역, 난스와 같은 비밀 보호 정보로 이루어져 있다. 64 | A1은 H, KD, A2 와 마찬가지로 요약을 계산하기 위해 사용된다. 65 | 66 | - MD5: 모든 요청마다 단방향 해시를 실행한다. A1은 사용자 이름, 영역, 비밀번호를 콜론으로 연결한 것이다. 67 | 68 | - MD5-sess: 사용자 이름, 영역, 비밀번호에 대한 해시를 계산한 결과 뒤에 현재 난스와 클라이언트 난스를 붙인 것이 A1 이 된다. WWW-Authenticate 핸드셰이크를 할 때 단 한번만 수행한다 69 | 70 | ### 13.2.4 메시지 관련 데이터 (A2) 71 | 72 | URL, 요청 메서드, 메시지 엔터티 본문과 같은 메시지 자체의 정보를 나타낸다. 73 | A2 는 메서드, 리소스, 메시지의 위조를 방지하기 위해 사용된다. 74 | RFC 2617은 선택된 보호 수준에 따른 A2 의 사용법을 정의한다 75 | 76 | - HTTP 요청 메서드와 URL 만 포함하는 것이다. 기본값이기도 한 qop="auth" 일 때 사용된다. 77 | - 메시지 무결성 검사를 제공하기 위해 메시지 엔터티 본문을 추가하는 것이다. qop="auth-int" 일 때 사용된다. 78 | 79 | ### 13.2.5 요약 알고리즘 전반 80 | 81 | RFC 2617 은 주어진 H, KD, A1, A2 요약을 계산하는 두 가지 방법을 정의한다. 82 | 83 | - RFC 2069 와 호환을 염두에 둔 것으로, qop 옵션이 빠졌을 때 사용된다. 비밀 정보와 난스가 붙은 메시지 데이터의 해시를 이용해 요약을 계산한다. 84 | - qop 가 'auth' 일 때와 'auth-int' 일 때 모두 사용된다. 이것은 난스 횟수, qop, c 난스 데이터를 요약에 추가한다 85 | 86 | ### 13.2.6 다이제스트 인증 세션 87 | 88 | 보호 공간을 위한 WWW-Authenticate 인증요구에 대한 클라이언트 응답은, 보호 공간에 대한 인증 세션을 싲가하게 한다. 89 | 인증 세션은 클라이언트가 보호 공간의 다른 서버로부터 또 다른 WWW-Authenticate 를 받을 때까지 지속된다. 90 | 클라이언트는 사용자 이름, 비밀번호, 난스, 난스 횟수, 요청에 들어갈 Authorization 헤더를 만들기 위해 사용될 인증 세션과 연관된 값들을 기억해야한다. 91 | 92 | 난스가 만료되면 감수하고 오래된 Authorization 헤더 정보를 받아들이는 것을 택할 수 있다. 아니면 다시 요청을 보내도록 새 난스 값과 함께 401 응답을 반환할 수도 있다. 93 | 94 | ### 13.2.7 사전인가 95 | 96 | 일반적인 인증에서는 요청은 트랜잭션이 완료되기 전에 요청/인증요구 사이클을 필요로 한다. 97 | 클라이언트가 다음 난스가 무엇이 될지 미리 알고 있어서, 서버가 물어보기전에 올바른 Authorization 헤더를 생성할 수 있다면, 요청/인증요구 사이클은 98 | 생략할 수 있다. 클라이언트가 요청 받기 전에 Authorization 헤더를 계산할 수 있다면 클라이언트는 요청/인증요구 단계를 거치지 않고 미리 Authorization 헤더를 서버에 제공한다. 99 | 100 | 다이제스트 인증은 여러 안전한 기능을 유지하면서 사전 인가를 할 수 있는 몇가지 방법을 제안한다. 101 | 102 | - 서버가 다음 난스를 Authentication-info 성공 헤더에 담아서 미리 보낸다. 103 | - 서버가 짧은 시간 동안 같은 난스를 재사용하는 것을 허용한다. 104 | - 클라이언트와 서버가 동기화되어 있고 예측 가능한 난스 생성 알고리즘을 사용한다. 105 | 106 | #### 다음 난스 미리 생성하기 107 | 108 | 서버는 Authentication-info 성공 헤더를 통해 다음 난스 값을 미리 제공할 수 있다. 109 | 인증이 성공했을 때 200 OK 응답과 함께 이 헤더를 미리 보낸다. 110 | 111 | ``` 112 | Authentication-Info: nextnonce=<난스값> 113 | ``` 114 | 115 | #### 제한된 난스 재사용 116 | 117 | 연속된 난스를 미리 생성하는 것 외의 또 다른 방법은 난스를 제한적으로 재사용하는 것이다. 예를 들어 서버는 한 난스를 다섯번 혹은 10초간 118 | 재사용 할 수 있도록 허락 할 수 있다. 119 | 120 | #### 동기화된 난스 생성 121 | 122 | 제 3자가 쉽게 예측할 수 없는 공유된 비밀키에 기반하면서 클라이언트와 서버가 순차적으로 같은 난스를 생성할 수 있도록 시간적으로 동기화된 난스 생성 알고리즘을 사용하는 것도 가능하다. 123 | 124 | ### 13.2.8 난스 선택 125 | 126 | RFC 2617 은 다음과 같은 가상의 난스 공식을 제안했다. 127 | 128 | ``` 129 | BASE64(타임스탬프 H(타임스탬프":" ETag ":" 개인키)) 130 | ``` 131 | 132 | 타임 스태프는 서버에서 생성된 시간 혹은 아무것이나 반복 불가능한 값이고, ETag 는 요청된 엔터티에 대한 ETage 헤더값이며, 개인 키는 서버만이 알고 있는 값이다. 133 | 134 | 135 | 클라이언트 인증 헤더의 난스와 일치하지 않거나 타임스탬프가 오래되었다면 요청을 거절한다. 136 | ETag 를 포함하면 갱신된 리소스에 대한 재요청을 방지한다. 137 | 138 | ### 13.2.9 상호 인증 139 | 140 | RFC 2617 은 클라이언트가 서버를 인증할 수 있도록 다이제스트 인증을 확장했다. 141 | 서버가 공유된 비밀 정보에 근거한 올바른 응답 요약을 생성할 수 있도록, 클라이언트 난스 값을 제공함으로써 가능해진다. 이후 서버는 이 요약을 Authentication-info 헤더를 통해 클라이언트에 전달한다. 142 | 상호 인증은 qop 지시자가 존재할 떄는 항상 수행하여야 하고, 없다면 수행하지 않아야한다. 143 | 144 | ## 13.3 보호 수준 향상 145 | 146 | qop 필드는 요약 헤더의 세 가지 헤더 WWW-Authenticate, Authorization, Authentication-Info 에 모두 존재할 수 있다. 147 | qop 필드는 클라이언트와 서버가 어떤 보호 기법을 어느 정도 수준으로 사용할것인지 협살할 수 있게 해준다. 148 | RFC 2617은 기본적으로 두 가지 초기 보호수준 값을 정의하고있다. 하나는 인증을 의미하는 "auth" 이고 다른 하나는 인증 및 메시지 무결성 보호를 의미하는 "auth-int" 이다 149 | 150 | ### 13.3.1 메시지 무결성 보호 151 | 152 | 무결성 보호가 적용되었을 때(qop="auth-init") 계산되는 H(엔터티 본문)는 메시지 본문의 해시가 아닌 엔터티 본문의 해시이다. 153 | 이것은 송신자에 의해 어떠한 전송인코딩이 적용되기도 전에 먼저 계산되고 그 후 수신자에 의해 제거된다. 154 | 155 | ### 13.3.2 다이제스트 인증 헤더 156 | 157 | 기본, 다이제스트 인증 프로토콜 양쪽 모두 WWW-Authenticate 헤더에 담겨 전달되는 인증요구와, Authorization 헤더에 담겨 전달되는 인가 응답을 포함한다. 158 | 다이제스트 인증은 여기에 선택정인 Authentication-Info 헤더를 추가했다. 159 | 160 | | realm | 사용자 이름과 비밀번호가 어디 사용될 것인지 알려주기 위해 사용자에게 보여질 문자열 | 161 | |-----------|-------------------------------------------------------------------------------------------------------------------------------------| 162 | | nonce | 401 응답이 만들어질 때마다 유일하게 생성되어야 하는 서버에 특화된 데이터 문자열 | 163 | | domain | 보호될 공간을 정의한 따옴표로 감싸진 URI들의 공백으로 분리된 목록 | 164 | | opaque | 서버에 의해 정의된 데이터의 문자열, 클라이언트는 같은 보호 공간의 URI에 대한 다음번 요청에서 Authorizaiton 허더에 이 값을 담아 반환 | 165 | | stable | 클라이언트로부터의 이전 요청이 nonce 값이 신선하지 않아서 거부되었음을 의미하는 플래그 | 166 | | algorithm | 다이제스트와 체크섬을 생성할 때 사용하는 알고리즘, 기본 값은 MD5 | 167 | | qop | 선택적, 서버가 지원하는 보호 수준을 의미 | 168 | 169 | 170 | | username | 특정 realm에서의 사용자 이름 | 171 | |-----------|---------------------------------------------------------------------------------------------------------| 172 | | realm | WWW-Authenticte 헤더에 담겨 클라이언트에게 넘겨진 releam | 173 | | nonce | WWW- Authenticate 헤더에 담겨 클라이언트에게 넘겨진 nonce | 174 | | uri | 요청 URI에서의 URI, 프락시에 의해 요청이 변경될 수 있기 때문에 존재 | 175 | | response | 다이제스트 값, 사용자가 비밀번호를 알고 있음을 증명 | 176 | | algorithm | 다이제스트와 체크섬을 생성할 때 사용하는 알고리즘, 기본 값은 MD5 | 177 | | opaque | 서버에 의해 정의된 데이터의 문자열, 같은 보호 공간의 URI에 대한 다음번 요청에서 값을 그대로 넣어서 반환 | 178 | | cnonce | qop 지시자가 보내진 경우만 포함. 메시지 무결성 보호를 제공 | 179 | | qop | 클라이언트가 메세지에 적용한 “보호 수준”의 정도 | 180 | | nc | qop 지시자가 보낸 경우에만 포함. 클라이언트가 이 요청의 nonce값과 함께 보낸 요청들의 횟수 합계 | 181 | 182 | | nextnonce | 미래의 인증 응답 시에 클라이언트가 사용해주기를 서버가 원하는 nonce | 183 | |-----------|------------------------------------------------------------------------------------------| 184 | | qop | 서버에 의해 응답에 적용된 ‘보호 수준”의 정도 | 185 | | rspauth | response auth를 의미. 선택적인 응답 다이제스트가 들어있으며 이를 이용해 상호 인증을 지원 | 186 | | cnonce | 응답 대상인 클라이언트의 요청에 들어있는 값과 반드시 같아야 함 | 187 | | nc | 응답 대상인 클라이언트 요청에 들어있는 값과 반드시 같아야 함 | 188 | 189 | 190 | ## 13.4 실제 상황에 대한 고려 191 | ### 13.4.1 다중 인증 요구 192 | 193 | 서버는 한 리소스에 대해 여러 인증을 요구할 수 있다. 서버가 클라이언트의 능력을 모른다면, 서버는 기본 및 다이제스트 인증요구를 모두 보낼 것이다. 194 | 다양한 인증 옵션을 제공하는 경우 '가장 허약한 연결부분'에 대한 보안 우려가 있다는 것은 명확하다. 195 | 서버는 기본 인증을 제한적으로만 사용해야 할 것이며, 관리자는 사용자에 보안 수준이 다른 여러 시스템에서 같은 비밀번호를 사용하는 것의 위험성에 대해 경고해야 할 것 이다. 196 | 197 | ### 13.4.2 오류 처리 198 | 199 | 다이제스트 인증에서, 지시자나 그 값이 적절하지 않거나 요구된 지시자가 빠져 있는 경우 알맞은 응답은 400 Bad Request 이다. 200 | 요청의 요약이 맞지 않으면, 로그인이 실패했음을 기록해 두는 것이 좋다. 반복된 실패는 공격자가 비밀번호 추측을 시도하고 있음을 의미한다. 201 | 인증 서버는 반드시 'uri' 지시자가 가리키는 리소스가 요청줄에 명시된 리소스와 같음을 확인해야한다. 202 | 만약 다르다면 400 Bad Request 에러를 반환하는 것이 좋다. 203 | 204 | ### 13.4.3 보호 공간 205 | 206 | 영역 값은, 접근한 서버의 루트 URL 과 결합되어, 보호 공간을 정의한다. 207 | 영역은 서버의 보호된 리소스들을 자신만의 인증 제도와 인가 데이터베이스 어느 한 쪽 혹은 양쪽 모두를 가진 보호 영역의 집합으로 분할할 수 있도록 해준다. 208 | 여역값은 일반적으로 원 서버에 의해 할당되는 문자열이며 인증 제도에 추가적인 의미를 더한다. 209 | 210 | - 기본 인증에서 클라이언트는 요청 URI 와 그 하위의 모든 경로는 같은 보호 공간에 있는 것으로 가정한다. 클라이언트는 이 공간에서 서버로부터의 또 다른 인증 요구를 기다리지 않고 미리 리소스에 대한 인가를 받을 수 있다. 211 | - 다이제스트 인증에서 인증요구의 WWW-Authencate: domain 필드는 보호 공간을 보다 엄밀하게 정의한다. domain 필드는 작은따옴표로 묶인 URI 의 공백으로 분리된 목록이다 212 | 213 | ### 13.4.4 URI 다시 쓰기 214 | 215 | 프락시는 가리키는 리소스의 변경 없이 구문만 고쳐서 URI 를 다시 쓰기도 한다. 216 | 217 | - 호스트 명은 정규화되거나 IP 주소로 대체될 수 있다. 218 | - 문자들은 % excape 형식으로 대체될 수 있다. 219 | - 특정 원 서버로부터 가져오는 리소스에 영향을 주지 않는, 타입에 대한 추가 속성이 URI의 끝에 붙거나 중간에 삽입될 수 있다. 220 | 221 | ### 13.4.5 캐시 222 | 223 | - 만약 원 서버의 응답이 'must-revalidate' Cache-Control 지시자를 포함한 경우 캐시는 그 응답의 엔터티를 다음 요청에 대한 응답을 위해 활용할 것이다. 224 | 그러나 원 서버가 새 요청을 인증할 수 있도록, 우선 그 요청의 헤더를 이용해서 재검사를 수행해야한다. 225 | - 원 서버의 응답이 'public' Cache-Control 지시자를 포함한 경우, 응답 엔터티는 그다음에 오는 임의의 요청에 대한 응답으로 반환될 수 있다. 226 | 227 | ## 13.5 보안에 대한 고려사항 228 | 229 | ### 13.5.1 헤더 부당 변경 230 | 231 | 헤더 부당 변경에 대해 항상 안전한 시스템을 제공하기 위해서, 양 종단 암호화나 헤더에 대한 디지털 서명이 필요할 것이다. 232 | 다이제스트 인증은 쉽게 조작할 수 없는 인증 제도를 제공하는 것에 초점을 맞추고 있으나 반드시 그 보호를 데이터에까지 확장하는 것은 아니다. 233 | 보호 수준에 대한 정보는 WWW-Authenticate 와 Authorization 헤더에만 담겨있다. 234 | 235 | ### 13.5.2 재전송 공격 236 | 237 | 재전송 공격이란 어떤 트랙잭션에서 엿들은 인증 자격을 다른 트랜잭션을 위해 사용하는 것을 말한다. 238 | 서버가 재전송된 자격을 승인해버렸다는 것은, 틀림없이 같은 난스 값을 반복해서 사용한 것이다. 239 | 재전송 공격을 완전히 피할 수 있는 한 방법은 매 트랜잭션마다 유일한 난스 값을 사용하는 것이다. 240 | 241 | ### 13.5.3 다중 인증 메커니즘 242 | 243 | 서버가 다중 인증 제도를 지원할 때 WWW-Authenticate 헤더를 통해 선택지를 제공할 것이다. 244 | 클라이언트에게 가장 강력한 인증 메커니즘을 선택해야 할 의무가 있는 것은 아니기 때문에, 245 | 결국 인증의 강도는 선택지중 가장 약한 것과 같다고 보아야 한다. 246 | 이 문제를 피하기 위한 확실한 방법은 클라이언트가 언제나 가능한 한 가장 강력한 인증 제도를 선택하는 것이다. 247 | 248 | ### 13.5.4 사전 공격 249 | 250 | 사전 공격은 전형적인 비밀번호 추측 공격이다. 251 | 악의적인 사용자는 트랜잭션을 엿들을 수 있고 난스/응답 쌍에 대해 흔히 구할 수 있는 비밀번호 추측 프로그램을 사용할 수 있다. 252 | 해결방법은 크래킹하기 어렵도록 상대적으로 복잡한 비밀번호를 사용하는 것과 괜찮은 비미런호 만료 정책 외에는 실직적으로 없다. 253 | 254 | ### 13.5.5 악의적인 프락시와 중간자 공격 255 | 256 | 프락시 중 하나가 악의적이거나 보안이 허술하다면 클라이언트는 중간자 공격에 취약한 상태가 될 가능성이 있다. 257 | 이 문제를 해결할 좋은 방법은 없다. 가능한 해결책은 클라이언트가 사용자에게 인증의 강도를 시작적으로 보여주는것, 258 | 클라이언트가 언제나 가능한 한 가장 강력한 인증을 선택하도록 설정하는 것 등이 있다. 259 | 260 | ### 13.5.6 선택 평문 공격 261 | 262 | 다이제스트 인증을 사용하는 클라이언트는 응답을 생성하기 위해 서버가 제공한 난스를 이용한다. 263 | 만약 보안이 허술하거나 악의적인 프락시가 트래픽 중간에 끼어든다면, 그것은 어렵지 않게 클라이언트가 응답 계산을 하기 위한 난스를 제공할 수 있다. 264 | 응답을 계산하기 위해 알려진 키를 사용하는 것은 응답의 암호 해독을 쉽게한다. 이것을 선택 평문 공격이라 부른다. 265 | 266 | - 미리 계산된 사전 공격: 사전 공격과 선택 평문 공격의 조합이다. 공격 서버는 미리 결정된 난스와 자주 쓰이는 비밀번호들로 응답의 집합을 생성하고 사전을 만든다. 267 | 공격 서버/프락시는 트래픽을 차단하고 미리 결정된 난스를 클라이언트로 전송하기 시작한다. 클라이언트로부터 응답을 받을 때 공격자는 대응되는 항목을 생성한 사전에서 찾는다. 268 | 만약 대응되는 것이 있다면 공격자는 특정 사용자의 비밀번호를 손에 넣은 것이다 269 | 270 | - 자동화된 무차별 대입 공격: 미리 계산된 요약을 맞춰보려 시도하는 대신, 많은 컴퓨터를 동원해 주어진 범위에서 가능한 모든 비밀번호를 열거한다. 271 | 컴퓨터가 빨라질수록 무제한 공격의 성공 가능성은 점점 더 높아진다. 이런 공격으로 인한 위험은 쉽게 방어할 수 있다. 272 | 클라이언트가 서버에서 제공된 난스 대신 선택적인 c 난스 지시자를 사용하여 응답을 생성 할 수 있도록 설정한다. 273 | 274 | ### 13.5.7 비밀번호 저장 275 | 276 | 다이제스트 인증 메커니즘은 사용자 응답을 서버 내부에 저장된 것과 비교한다. 277 | 유닉스 장치의 전통적인 비밀번호 파일과는 달리, 다이제스트 인증 비밀번호 파일이 유출되면 영역의 모든 문서는 즉각 공격자에게 노출된다. 278 | 279 | - 비밀번호 파일이 평문으로 된 비밀번호를 포함하고 있다고 생각하고 안전하게 보호한다. 280 | - 영역 이름이 유일함을 보장하며, 비밀번호 파일이 유출되더라도 피해를 특정 영역으로 국소화한다. 281 | 282 | 283 | 284 | 285 | 286 | 287 | 288 | 289 | 290 | 291 | 292 | 293 | 294 | 295 | 296 | 297 | -------------------------------------------------------------------------------- /chapter_14/README.md: -------------------------------------------------------------------------------- 1 | # [13장] HTTP:식별, 인가 보안 / 다이제스트 인증 2 | 3 | - 마감일: 12월 02일 월요일 자정 4 | - todo: 5 | - 13장 다이제스트 인증 (chap4 - chap7) + 14장 보안HTTP (chap1 - chap6) 6 | 7 | ## 정리 글 링크 8 | 9 | 1. 고석진 10 | 2. 고의성 11 | 3. 김나영 - [HTTPS의 세부사항](https://feel5ny.github.io/2019/12/08/HTTP_014_02/) 12 | 4. 류지환 13 | 5. 이승규 - [보안 HTTP](http://localhost:8000/blog/2019-11-30--%E1%84%87%E1%85%A9%E1%84%8B%E1%85%A1%E1%86%AB-http/) 14 | 6. 한재우 15 | -------------------------------------------------------------------------------- /chapter_14/chapter_14_고석진.md: -------------------------------------------------------------------------------- 1 | # HTTP 2 | 3 | ## 보안 HTTP 4 | 5 | ## 14.1 HTTP 를 안전하게 만들기 6 | 7 | 중요한 트랜잭션을 위해서는 HTTP 와 디지털 암호화 기술을 결합해야 한다. 8 | HTTP 의 보안 버전은 효율적이고, 이식성이 좋아야 하고, 관리가 쉬워야 하며, 현실 세계의 변화에 대한 적응력이 좋아야 한다. 9 | 10 | ### 14.1.1 HTTPS 11 | 12 | HTTPS 를 사용할 때, 모든 HTTP 요청과 응답 데이터는 네트워크로 보내지기 전에 암호화된다. 13 | HTTPS 는 HTTP 의 하부에 전송 레벨 암호 보안 계층을 제공함으로써 동작하는데, 이 보안 계층은 안전 소켓 계층 혹은 그를 계승한 전송 계층 보안을 이용하여 구현된다. 14 | SSL 과 TLS 는 매우 비슷하다. 15 | 16 | ## 14.2 디지털 암호학 17 | 18 | - 암호: 텍스트를 아무나 읽지 못하도록 인코딩하는 알고리즘 19 | - 키: 암호의 동작을 변경하는 숫자로 된 매개변수 20 | - 대칭키 암호 체계: 인코딩과 디코딩에 같은 키를 사용하는 알고리즘 21 | - 비대칭키 암호 체계: 인코딩과 디코딩에 다른 키를 사용하는 알고리즘 22 | - 공개키 암호법: 비밀 메시지를 전달하는 수백만 대의 컴퓨터를 쉽게 만들 수 있는 시스템 23 | - 디지털 서명: 메시지가 위조 혹은 변조되지 않았음을 입증하는 체크섬 24 | - 디지털 인증서: 신뢰할 만한 조직에 의해 서명되고 검증된 신원 확인 정보 25 | 26 | ### 14.2.1 비밀 코드의 기술과 과학 27 | 28 | 암호법은 메시지 인코딩과 디코딩에 대한 기술이다. 암호법은 단순히 볼 수 없도록 메시지를 암호화하는 것뿐 아니라 29 | 메시지의 변조를 방지하기 위해 사용할 수도 있다. 30 | 31 | ### 14.2.2 암호 32 | 33 | 암호법은 암호라 불리는 비밀 코드에 기반한다. 암호란 메시지를 인코딩하는 어떤 특정한 방법과 나중에 그 비밀 메시지를 디코딩하는 방법이다. 34 | 인코딩되기 전의 원본 메시지는 흔히 텍스트 혹은 평문이라고 불린다. 35 | 암호가 적용되어 코딩된 메시지는 보통 암호문이라고 불린다. 36 | 37 | ### 14.2.3 암호 기계 38 | 39 | 기술이 진보하면서 복잡한 암호로 메시지를 빠르고 정확하게 인코딩하고 디코딩하는 기계를 만들기 시작하였다. 40 | 암호 기계는 암호를 깨뜨리기 어렵게 하기 위해, 단순히 회전을 하는 대신 글자들을 대체하고, 순서를 바꾸며 메시지를 자르고 토막내었다. 41 | 42 | ### 14.2.4 키가 있는 암호 43 | 44 | 대부분의 기계들에는 암호의 동작방식을 변경할 수 있는 큰 숫자로 된 다른 값을 설정할 수 있는 다이얼이 달려있다. 45 | 누군가 기계를 훔치더라도 올바른 다이얼 설정이 없이는 디코더가 동작하지 않을 것이다. 46 | 암호 키는 하나의 암호 기계를 여러 가상 암호 기계의 집합처럼 만들어준다. 47 | 가상 암호 기계들은 서로 다른 키 값을 갖고 있기 때문에 제각각 다르게 동작한다. 48 | 암호 알고리즘은 'N 번 회전' 암호다. N 의 값은 키에 의해 좌우된다. 같은 메시지가 같은 인코딩 기계를 통과하더라도 키의 값에 따라 다른 출력을 생성한다. 49 | 50 | ### 14.2.5 디지털 암호 51 | 52 | - 속도 및 기능에 대한 기계 장치의 한계에서 벗어남으로써, 복잡한 인코딩과 디코딩 알고리즘이 가능해졌다. 53 | - 큰 키를 지원하는 거이 가능해져서, 단일 암호 알고리즘으로 키의 값마다 다른 수조 개의 가상 암호 알고리즘을 만들어 낼 수 있게 되었다. 54 | 55 | 기계 장치의 물리적인 금속 키나 다이얼 설정과는 달리, 디지털 키는 그냥 숫자에 불과하다. 56 | 디지털 키 값은 인코딩과 디코딩 알고리즘에 대한 입력값이다. 57 | 코딩 알고리즘은 데이터 덩어리를 받아서 알고리즘과 키의 값에 근거하여 인코딩하거나 디코딩하는 함수이다. 58 | 59 | ## 14.3 대칭키 암호법 60 | 61 | 디지털 암호 알고리즘은 대칭키 암호라 불리는데, 그들이 인코딩 할 때 사용하는 키가 디코딩을 할 때와 같기 때문이다. 62 | 대칭키 암호에서 발송자와 수신자 모두 통신을 위해 비밀 키 k 를 똑같이 공유할 필요가 있다. 63 | 발송자는 공유된 비밀 키를 메시지를 암호화하고 결과인 암호문을 수신자에게 발송하기 위해 사용한다. 64 | 수신자는 암호문을 받은 뒤 같은 공유된 키를 사용하여 평문을 복원하기 위해 해독 함수를 적용한다. 65 | 66 | ### 14.3.1 키 길이와 열거 공격 67 | 68 | 좋은 암호 알고리즘은 공격자가 코드를 크래킹하려면 존재하는 모든 가능한 키 값을 시도해보는 것 외에 다른 방법이 없게 만든다. 69 | 가능한 키 값의 개수는 키가 몇 비트이며 얼마나 많은 키가 유효한지에 달려있다. 70 | 대칭키 암호에서는 모든 키 값이 유효하다. 71 | 평범한 대칭키 암호에서, 40비트 키는 작고 중요하지 않은 업무에는 충분하다고 할 수 있다. 72 | 128비트 키를 사용한 대칭키 암호는 매우 강력하다. 73 | 74 | ### 14.3.2 공유키 발급하기 75 | 76 | 대칭키 암호의 단점 중 하나는 발송자와 수신자가 서로 대화하려면 둘 다 공유키를 가져야 한다는 것이다. 77 | 78 | ## 14.4 공개키 암호법 79 | 80 | 한 쌍의 호스트가 하나의 인코딩/디코딩 키를 사용하는 대신, 공개키 암호 방식은 두 개의 비대칭 키를 사용한다. 81 | 하나는 호스트의 메시지를 인코딩하기 위한 것이며, 다른 하나는 호스트의 메시지를 디코딩하기 위한 것이다. 82 | 메시지를 디코딩하는 능력은 소유자에게만 부여한다. 83 | 84 | ### 14.4.1 RSA 85 | 86 | 공개키 암호 체계중 유명한 하나는 MIT 에서 발명되고 이어서 RSA 데이터 시큐리티에서 상용화된 RSA 알고리즘이다. 87 | 88 | ### 14.4.2 혼성 암호 체계와 세션 키 89 | 90 | 공개키 암호 방식의 알고리즘은 계싼이 느린 경향이 있다. 91 | 실제로는 대칭과 비대칭 방식을 섞은 것이 쓰인다. 92 | 노드들 사이의 안전한 의사소통 채널을 수립할 때는 편리하게 공개 키 암호를 사용하고, 93 | 안전한 채널을 통해 임시의 무작위 대칭 키를 생성하고 교환하여 이후의 나머지 데이터를 암호화할 때는 빠른 대칭키를 사용한다. 94 | 95 | ## 14.5 디지털 서명 96 | 97 | 암호 체계는 메시지를 암호화하고 해독하는 것뿐 아니라, 누가 메시지를 썼는지 알려주고 그 멤시지가 위조되지 않았음을 증명하기 위해 메시지에 서명을 하도록하는데에 이용될 수 있다. 98 | 99 | ### 14.5.1 서명은 암호 체크섬이다 100 | 101 | 디지털 서명은 메시지에 붙어있는 특별한 암호 체크섬이다. 102 | 103 | - 서명은 메시지를 작성한 저자가 누군지 알려준다. 저자는 저자의 극비 개인 키를 갖고 있기 때문에, 오직 저자만이 체크섬을 계싼할 수 있다. 104 | - 서명은 메시지 위조를 방지한다. 악의적인 공격자가 송신 중인 메시지를 수정했다면, 체크섬은 더 이상 그 메시지와 맞지 않게된다. 체크섬 날조가 불가하다 105 | 106 | 디지털 서명은 보통 비대칭 공개키에 의해 생성된다. 개인 키는 오직 소유자만이 알고 있기 떄문에, 저자의 개인 키는 일종의 지문처럼 사용된다. 107 | 108 | - 가변 길이 멤시지를 정제하여 고정된 길이의 요약으로 만든다. 109 | - 요약에, 사용자의 개인 키를 매개변수로 하는 서명 함수를 적용한다 110 | - 한번 서명이 계산되면 메시지의 끝에 그것을 덧붙이고 메시지와 그에 대한 서명 둘 다를 전송한다. 111 | - 개인 키로 알아보기 어렵게 변형된 서명에 공개키를 이용한 역함수를 적용한다. 만약 풀어낸 요약이 버전의 요약과 일치하지 않는다면, 메시지가 송신 중에 위조되었거나 발송자가 개인 키를 갖고 있지 않은것이다 112 | 113 | 114 | ## 14.6 디지털 인증서 115 | 116 | 디지털 인증서는 신뢰할 수 있는 기관으로부터 보증 받은 사용자나 회사에 대한 정보를 담고 있다. 117 | 118 | ### 14.6.1 인증서의 내부 119 | 120 | 디지털 인증서에는 공식적으로 '인증기관' 에 의해 디지털 서명된 정보의 집합이 담겨있다. 121 | 디지털 인증서는 대상과 사용된 서명 알고리즘에 대한 서술적인 정보뿐 아니라 보통 대상의 공개키도 담고있다. 122 | 누구나 디지털 인증서를 만들 수 있지만, 모두가 인증서의 정보를 보증하고 인증서를 개인 키로 서명할 수 있는 서명 권한을 얻을 수 있는 것은 아니다. 123 | 124 | ### 14.6.2 x.509 v3 인증서 125 | 126 | 디지털 인증서에 대한 전 세계적인 단일 표준은 없다. 127 | 오늘날 사용되는 인증서가 그들의 정보를 x.509 라 불리는 표준화된 서식에 저장하고 있다. 128 | x.509 v3 인증서는 인증 정보를 파싱 가능한 필드에 넣어 구조화하는 표준화된 방법을 제공한다. 129 | 130 | - 버전: 인증서가 따르는 버젼 번호, 요즘은 보통 3 버전이다. 131 | - 일련번호: 인증기관에 의해 생성된 고유한 정수 132 | - 서명 알고리즘 ID: 서명을 위해 사용된 알고리즘 133 | - 인증서 발급자: 인증서를 발급하고 서명한 기관의 이름 134 | - 유효 기간: 인증서가 유효한 기간 135 | - 대상의 이름: 인증서에 기술된, 사람이나 조직과 같은 엔터티 136 | - 대상의 공개 키 정보: 인증 대상의 공개 키, 공개 키에 사용된 알고리즘 137 | - 발급자의 고유 ID: 발급자 이름이 겹치는 경우를 대비한 고유한 식별자 138 | - 대상의 고유 ID: 대상의 이름이 겹치는 경우를 대비한, 인증 대상에 대한 선택적인 고유한 식별자 139 | - 확장: 선택적인 확장 필드의 집합버젼 140 | 141 | ### 14.6.3 서버 인증을 위해 인증서 사용하기 142 | 143 | 사용자가 HTTPS 를 통한 안전한 웹 트랜잭션을 시작할 때, 최신 브라우저는 자동으로 접속한 서버에서 디지털 인증서를 가져온다. 144 | 만약 서버가 인증서를 갖고 있지 않다면, 보안 커넥션은 실패한다. 145 | 146 | 서버 인증서는 웹 사이트의 이름, 호스트명, 공개키, 서명 기관의 이름, 서명 등을 가지고 있다. 147 | 148 | 브라우저가 인증서를 받으면, 서명 기관을 검사한다. 만약 그 기관이 공공이 신뢰할만한 서명 기관이라면 브라우저는 그것의 공개키를 149 | 이미 알고 있을 것이며 브라우저들은 여러 서명 기관의 인증서가 미리 설치된 채로 출하한다. 150 | 151 | ## 14.7 HTTPS 의 세부사항 152 | 153 | HTTPS 는 HTTP 의 가장 유명한 보안 버전이다. HTTPS 는 HTTP 프로토콜에 대칭, 비대칭 인증서 기반 암호 기법의 강력한 집합을 결합한 것이다. 154 | HTTPS 는 또한 분산된 웹 애플리케이션의 광역 보안 관리에 있어 중요하다. 155 | 156 | ### 14.7.1 HTTPS 개요 157 | 158 | HTTPS 는 그냥 보안 전송 계층을 통해 전송되는 HTTP 이다. 159 | 암호화되지 않은 HTTP 메시지를 TCP 를 통해 전 세계의 인터넷 곳곳으로 보내는 대신에 HTTPS 는 HTTP 메시지를 TCP 로 보내기전에 160 | 그것들을 암호화하는 보안계층으로 보낸다. 161 | 162 | ### 14.7.2 HTTPS 스킴 163 | 164 | 보안 HTTP 는 선택적이다. 웹 서버로의 요청을 만들 때 서버에게 HTTP 의 보안 프로토콜 버전을 수행한다고 말해줄 방법이 필요하다. 165 | 166 | 보안이 없는 일반적인 HTTP 는 url 스킴 접두사는 `http` 이다. 167 | 보안이 되는 HTTPS 프로토콜에서 url 스킴은 `https` 이다. 168 | 169 | - 만약 url 이 http 스킴을 갖고 있다면, 클라이언트는 서버에 80 번 포트로 연결하고 평범한 http 명령을 전송한다. 170 | - url 이 https 스킴을 갖고 있다면, 서버에 443 포트로 연결하고 서버와 바이너리 포맷으로 된 몇몇 SSL 보안 매개변수를 교환하면서 핸드셰이크를 하고 암호화된 HTTP 명령이 뒤를 잇는다. 171 | 172 | ### 14.7.3 보안 전송 셋업 173 | 174 | 암호화되지 않은 HTTP 에서 클라이언트는 웹 서버의 80번 포트로 TCP 터넥션을 열고 요청 메시지를 보내고 응답 메시지를 받고 커넥션을 닫는다. 175 | HTTPS 는 SSL 보안 계층 때문에 약간 더 복잡한다. 클라이언트는 먼저 웹 서버의 443 포트로 연결한다. 176 | 연결 후 클라이언트와 서버는 암호법 매개변수와 교환 키를 협상하면서 SSL 계층을 초기화한다. 177 | 핸드셰이크가 완료되면 SSL 초기화는 완료되며, 클라이언트는 요청 메시지를 보안 계층에 보낸 수 있다. 178 | 메시지는 TCP 로 보내지기전에 암호화된다. 179 | 180 | ### 14.7.4 SSL 핸드셰이크 181 | 182 | 암호화된 HTTP 메시지를 보낼 수 있게 되기 전에, 클라이언트와 서버는 SSL 핸드셰이크를 할 필요가 있다. 183 | 핸드셰이크에서는 다음과 같은 일이 이루어진다. 184 | 185 | - 프로토콜 버전 번호 교환 186 | - 양쪽이 알고 있는 암호 선택 187 | - 양쪽의 신원을 인증 188 | - 채널을 암호화하기 위한 임시 세션 키 생성 189 | 190 | ### 14.7.5 서버 인증서 191 | 192 | SSL 은 서버 인증서를 클라이언트로 나르고 다시 클라이언트 인증서를 서버로 날라주는 상호 인증을 지원한다. 193 | 보안 HTTPS 트랜잭션은 항사 서버 인증서를 요구한다. 194 | 서명된 서버 인증서는 서버를 얼마나 신뢰할 수 있는지 평가하는 것을 도와준다. 195 | 서버 인증서는 조직의 이름, 주소, 서버 DNS 도메인 이름, 그 외의 정보를 보여주는 x.509 v3 에서 파생된 인증서이다. 196 | 사용자와 사용자의 클라이언트 소프트웨어는 모든 것이 믿을 만한 것인지 확인하기 위해서 인증서를 검증할 수 있다. 197 | 198 | ### 14.7.6 사이트 인증서 검사 199 | 200 | SSL 자체는 사용자에게 웹 서버 인증서를 검증할 것을 요구하지 않지만, 최신 웹브라우저들 대부분은 인증서에 대해 간단하게 기본적인 검사를 하고 201 | 결과를 철한 검사를 할 수 있는 방법과 함께 사용자에게 알려준다. 202 | 203 | - 날짜 검사: 브라우저는 인증서가 유효함을 확인하기 위해 인증서의 시작 및 종료일을 검사한다. 204 | - 서명자 신뢰도 검사: 모든 인증서는 서버를 보증하는 인증 기관에 의해 서명되어 있다. 205 | - 서명 검사: 서명 기관이 믿을 만하다고 판단하면, 브라우저는 서명기관의 공개키를 서명에 적용하여 체크섬과 비교해봄으로써 인증서의 무결성을 검사한다. 206 | - 사이트 신원 검사: 누군가 다른 이의 인증서를 복사하거나 트래픽을 가로채는 것을 방지하기 위해, 대부분의 브라우저는 인증서의 도메인 이름이 대화중인 서버의 도메인 이름과 비교하여 맞는지 검사한다. 207 | 208 | ### 14.7.7 가상 호스팅과 인증서 209 | 210 | 가상 호스트로 운영되는 사이트의 보안 트래픽을 다루는 것은 까다로운 경우도 많다. 사용자가 인증서의 이름과 정확히 맞지 않는 가상 호스트 명에 도착했다면 경고 상자가 나타날 것 이다. 211 | 212 | ## 14.9 프락시를 통한 보안 트래픽 터널링 213 | 214 | 클라이언트는 종종 그들을 대신하여 웹 서버에 접근해주는 웹 프락시 서버를 이용한다. 215 | 클라이언트가 서버로 보낼 데이터를 서버의 공개키로 암호화하기 시작했다면 프락시는 더 이상 HTTP 헤더를 읽을 수 없다. 216 | 헤더를 읽을 수 없다면 프락시는 요청을 어디로 보내야 하는지 알 수 없게된다. 217 | 218 | 이 문제를 해결하는 유명한 방법중 하나는 HTTPS SSL 터널링 프로토콜이다. 219 | HTTPS 터널링 프로토콜을 사용해서 르라이언트는 먼저 프락시에게 자신이 연결하고자 하는 안전한 호스트와 포트를 말해준다. 220 | 클라이언트는 내용을 프락시가 읽을 수 있도록 암호화가 시작되기 전의 평문으로 말해준다. 221 | 222 | HTTP 는 CONNECT 라 불리는 새로운 확장 메서드를 이용해서 평문으로 된 종단 정보를 전송하기 위해 사용된다. 223 | CONNECT 메서드는 프락시에게 희망하는 호스트와 포트번호로 연결을 해달라고 말해주며, 224 | 그것이 완료되면, 클라이언트와 서버 사이에서 데이터가 직접적으로 오갈 수 있게 해주는 터널을 만든다. 225 | 226 | 227 | 228 | 229 | 230 | 231 | 232 | 233 | 234 | 235 | 236 | 237 | 238 | 239 | 240 | 241 | 242 | 243 | 244 | 245 | 246 | 247 | 248 | 249 | 250 | 251 | 252 | 253 | 254 | 255 | 256 | 257 | 258 | 259 | 260 | 261 | 262 | 263 | 264 | -------------------------------------------------------------------------------- /chapter_15/README.md: -------------------------------------------------------------------------------- 1 | # [15장] HTTP: 엔터티, 인코딩, 국제화 / 엔터티와 인코딩 2 | 3 | - 마감일: 1월 06일 월요일 자정 4 | - todo: 5 | - 15장 엔터티와 인코딩 6 | 7 | ## 정리 글 링크 8 | 9 | 1. 고석진 10 | 2. 고현주 - [15. 엔터티와 인코딩](https://dev-junior.tistory.com/17) 11 | 3. 김나영 - [엔터티와 인코딩](https://feel5ny.github.io/2020/01/05/HTTP_015_01/), [인스턴스 조작과 인코딩](https://feel5ny.github.io/2020/01/06/HTTP_015_02/) 12 | 4. 류지환 13 | 5. 이승규 - [엔터티와 인코딩](https://ideveloper2.dev/blog/2020-01-04--%EC%97%94%ED%84%B0%ED%8B%B0%EC%99%80-%EC%9D%B8%EC%BD%94%EB%94%A9/) 14 | 6. 한재우 - [HTTP 완벽가이드 15장](https://bebiangel.github.io/2020/01/05/http-guide-chap15/) 15 | 7. 홍유정 - [HTTP완벽가이드 15장](https://youjung-hong.github.io/2020-01-10/HTTP완벽가이드-15-엔터티와-인코딩/) 16 | -------------------------------------------------------------------------------- /chapter_15/고석진.md: -------------------------------------------------------------------------------- 1 | # HTTP 2 | 3 | ## 엔터티와 인코딩 4 | 5 | HTTP 는 콘텐츠를 나르기 위한 잘 라벨링된 엔터티를 사용한다. 6 | 7 | ## 15.1 메시지는 컨테이너, 엔터티는 화물 8 | 9 | HTTP 메시지를 인터넷 운송 시스템의 컨테이너라고 생각한다면, HTTP 엔터티는 메시지의 실질적인 화물이다. 10 | 엔터티 헤더는 18자에 불과한 플레인 텍스트 문서를 의미한다. 11 | 12 | |Content-Type| 엔터티에 의해 전달된 객체의 종류| 13 | |---|---| 14 | |Content-Length| 메시지의 길이나 크기| 15 | |Content-Language|전달되는 객체와 대응되는 언어| 16 | |Content-Encoding|객체 데이터에 대해 행해진 변형| 17 | |Content-Location|요청 시점을 기준으로, 객체의 또 다른 위치| 18 | |Content-Range|부분 엔터티라면, 헤더는 이 엔터티가 전체에서 어느 부분에 해당하는지 정의한다| 19 | |Content-MD5|본문의 콘텐츠에 대한 체크섬| 20 | |Last-Modified|서버에서 이 콘텐츠가 생성 혹은 수정된 날| 21 | |Expires|엔터티 데이터가 더 이상 신선하지 않은 것으로 간주되는 시작하는 날짜와 시각| 22 | |Allow|리소스에 대해 어떤 요청 메서드가 허용되는지| 23 | |ETag|인스턴스에 대한 고유 검사기| 24 | |Cache-Control|문서가 캐시될 수 있는지에 대한 지시자| 25 | 26 | ### 15.1.1 엔터티 본문 27 | 28 | 엔터티 본문은 가공되지 않은 데이터만을 담고 있다. 다른 정보들은 모두 헤어데 담겨있다. 29 | 엔터티 본문은 가공되지 않은 날 데이터에 불과하기 떄문에 엔터티 헤더는 데이터의 의미에 대해 설명할 필요가있다. 30 | 31 | ## 15.2 Content-Length: 엔터티의 길이 32 | 33 | Content-Length 헤더는 메시지의 엔터티 본문의 크기를 바이트 단위로 나타난다. 34 | 어떻게 인코딩 되었든 상관없이 크기를 표현할 수 있다. 35 | 메시지를 청크 인코딩으로 전송하지 않는 이상, 엔터티본문을 포함한 메시지에서는 필수적으로 있어야한다. 36 | 서버 충돌로 인해 메시지가 잘렸는지 감지하고자 할 때와 지속 커넥션을 공유하는 메시지들 올바르게 분할하고자 할 때 필요하다. 37 | 38 | ### 15.2.1 잘림 검출 39 | 40 | 옛날 버전의HTTP 는 커넥션이 닫힌 것을 보고 메시지가 끝났음을 인지했다. 41 | 그러나 Content-Length 가 없다면 클라이언트는 커넥션이 정상적으로 닫힌 것인지 메시지 전송 중에 서버에 충돌이 발생한 것인지 구분할 수 없다. 42 | 43 | 메시지 잘림은 캐싱 프락시 서버에 특히 취약하다. 잘린 메시지를 캐시하는 위험을 줄이기 위해, 44 | 캐싱 프락시 서버는 명시적으로 Content-Length 헤더를 갖고 있지 않은 HTTP 본문은 보통 캐시하지 않는다. 45 | 46 | ### 15.2.2 잘못된 Content-Length 47 | 48 | 초창기 클라이언트들은 Content-Length 의 계산과 관련된 버그들을 갖고 있기 때문에, 클라이언트, 서버, 프락시 들은 49 | 서버가 오동작을 했는지 탐지하고 교정을 시도한다. 50 | 공식적으로 HTTP/1.1 사용자 에이전트는 잘못된 길이를 받고 그 사실을 인지했을 때 사용자에게 알려주게되어 있다. 51 | 52 | ### 15.2.3 Content-Length 와 지속 커넥션 53 | 54 | 만약 응답이 지속 커넥션을 통해서 온 것이라면, 또 다른 HTTP 응답이 즉시 그 뒤를 이을 것이다. 55 | Content-Length 헤더는 클라이언트에게 메시지 하나가 어디서 끝나고 다음 시작은 어디인지 알려준다. 56 | 커넥션이 지속적이기 때문에, 클라이언트가 커넥션이 닫힌 위치를 근거로 메시지의 끝을 인식하는 것은 불가능하다. 57 | 58 | ### 15.2.4 콘텐츠 인코딩 59 | 60 | HTTP 는 보안을 강화하거나 압축을 통해 공간을 절약할 수 있도록, 엔터티 본문을 인코딩할 수 있게 해준다. 61 | 만약 본문의 콘텐츠가 인코딩되어 있다면, Content-Length 헤더는 인코딩 되지 않은 원본의 길이가 아닌 인코딩된 본문의 길이를 바이트 단위로 정의한다. 62 | 어떤 HTTP 애플리케이션은 이것을 잘못해서 인코딩 전의 크기를 보내는 것으로 알려져 있는데, 이는 지속 커넥션일 때 심각한 오류를 유발한다. 63 | 64 | ### 15.2.5 엔터티 본문 길이 판별을 위한 규칙 65 | 66 | 1. 본문을 갖는 것이 허용되지 않는 특정 타입의 HTTP 메시지에서는, 본문 계산을 위한 Content-Length 가 무시된다. 엔터티 본문을 금하는 메시지는 67 | 어떤 엔터티 헤더 필드가 존재하느냐와 상관없이 반드시 헤더 이후의 빈 줄에서 끝나야 한다. 68 | 69 | 2. 메시지가 transfer-encoding 헤더를 포함하고 있다면, 메시지가 커넥션이 닫혀서 먼저 끝나지 않는 이상 엔터티는 '0바이트 청크' 라 불리는 70 | 특별한 패턴으로 끝나야한다. 71 | 72 | 3. 메시지가 Content-Length 헤더를 갖는다면, Transfer-encoding 헤더가 존재하지 않는 이상 Content-Length 값은 본문의 길이를 담게된다. 73 | 만약 Content-Length 헤더 필드와 identity 가 아닌 Transfer-encoding 헤더 필드를 갖고 있는 메시지를 받았다면 반드시 Content-Length 헤더를 무시해야한다. 74 | 75 | 4. 메시지가 'multipart/byteranges' 미디어 타입을 사용하고 엔터티 길이가 별도로 정의되지 않았다면, 멀티파트 메시지의 각 부분은 각자가 76 | 스스로의 크기를 정의할 것이다. 이 미디어 타입은 수신자가 이것을 해설할 수 있다는 사실을 송신자가 알기 전까지는 절대로 보내지 말아야한다. 77 | 78 | 5. 위의 규칙에 해당하지 않는다면, 엔터티는 커넥션이 닫힐 때 끝난다. 실직적으로, 오직 서버만이 메시지가 끝났음을 알리기 위해서 커넥션을 닫을 수 있다. 79 | 80 | 6. HTTP/1.0 애플리케이션과의 호환을 위해, 엔터티 본문을 갖고 있는 HTTP/1.1 요청은 반드시 유효한 Content-Length 헤더도 갖고 있어야 한다. 81 | 82 | ## 15.3 엔터티 요약 83 | 84 | 엔터티 본문 데이터에 대한 의도하지 않은 변경을 감지하기 위해, 최초 엔터티가 생성될 때 송신자는 데이터에 대한 체크섬을 생성할 수 있으며, 85 | 수신자는 모든 의도하지 않은 엔터티의 변경을 잡아내기 위해 체크섬으로 기본적인 검사를 할 수 있다. 86 | 87 | Content-MD5 헤더는 서버가 엔터티 본문에 MD5 알고리즘을 적용한 결과를 보내기 위해 사용된다. 응답을 처음 만든 서버만이 Content-MD5 헤더를 계산해서 88 | 보낼 것이다. 89 | Content-MD5 헤더는 콘텐츠 인코딩의 적용은 끝났지만 전송 인코딩은 아직 적용하지 않은 엔터티 본문에 대한 MD5를 담고있다. 90 | 메시지의 무결성을 검증하려는 클라이언트는 먼저 전송 인코딩을 디코딩한 뒤 그 디코딩 된 엔터티 본문에 대해 MD5 를 계산해야 한다. 91 | 92 | 메시지 무결성 검사에 더해, MD5는 문서의 위치를 빠르게 알아내고 콘텐츠의 중복 저장을 방지하기 위한 해시 테이블의 키로 이용될 수 있다. 93 | 94 | ## 15.4 미디어 타입과 차셋(Charset) 95 | 96 | Content-Type 헤더 필드는 엔터티 본문의 MIME 타입을 기술한다. 97 | MIME 타입은 전달되는 데이터 매체의 기저 형식의 표준화된 이름이다. 98 | Content-Type 헤더가 원본 엔터티 본문의 미디어 타입을 명시한다는 것은 중요하다. 99 | 엔터티가 콘텐츠 인코딩을 거친 경우에도 Content-Type 헤더는 여전히 인코딩 전의 엔터티 본문 유형을 명시할 것이다. 100 | 101 | ### 15.4.1 텍스트 매체를 위한 문자 인코딩 102 | 103 | Content-Type 헤더는 내용 유형을 더 자세히 지정하기 위한 선택적인 매개변수도 지원한다. 104 | 105 | ### 15.4.2 멀티파트 미디어 타입 106 | 107 | MIME '멀티파트' 이메일 메시지는 서로 붙어잇는 여러 개의 메시지를 포함하며, 하나의 복합 메시지로 보내진다. 108 | 각 구성요소는 자족적으로 자신에 대해 서술하는 헤더를 포함한다. 109 | HTTP 는 멀티파트 본문도 지원한다. 그러나 일반적으로는 폼을 채워서 제출할 때와 문서의 일부분을 실어 나르는 범위 응답을 할 때의 두 가지 경우에만 사용한다. 110 | 111 | ### 15.4.3 멀티파트 폼 제출 112 | 113 | HTTP 폼을 채워서 제출하면, 가변 길이 텍스트 필드와 업로드 될 객체는 각각이 멀티파트 본문을 구성하는 하나의 파트가 되어 보내진다. 114 | 멀티파트 본문은 여러 다른 종류와 길이의 값으로 채워진 폼을 허용한다. 115 | 116 | ### 15.4.4 멀티파트 범위 응답 117 | 118 | 범위 요청에 대한 HTTP 응답 또한 멀티파트가 될 수도 있다. 그러한 응답은 Content-Type: multipart/byteranges 헤더 및 각각 다른 범위를 119 | 담고 있는 멀티파트 본문이 함께 온다. 120 | 121 | ## 15.5 콘텐츠 인코딩 122 | 123 | HTTP 애플리케이션은 때때로 콘텐츠를 보내기 전에 인코딩을 하려고 한다. 느린 속도로 연결된 클라이언트에게 큰 HTML 문서를 전송하기 전에 서버는 124 | 전송 시간을 줄이기 위해 압축을 할 수 있다. 서버는 허가 받지 않은 제삼자가 볼 수 없도록 콘텐츠를 암호화하거나 뒤섞어서 보낼 수도 있다. 125 | 인코딩은 발송하는 쪽에서 콘텐츠에 적용한다. 콘텐츠 인코딩이 끝난 데이터는 늘 그렇듯 엔터티 본문에 담아 수신자에게 보낸다. 126 | 127 | ### 15.5.1 콘텐츠 인코딩 과정 128 | 129 | 1. 웹 서버가 원본 Content-Type 과 Content-Length 헤더를 수반한 원본 응답 메시지를 생성한다. 130 | 2. 콘텐츠 인코딩 서버가 인코딩된 메시지를 생성한다. 인코딩된 메시지는 Content-type 은 같지만 Content-Length 는 다르다. 콘텐츠 인코딩 서버는 Content-Encoding 131 | 헤더를 인코딩된 메시지에 추가하여, 수신 측 애플리케이션이 그것을 디코딩 할 수 있도록 한다. 132 | 3. 수신 측 프로그램은 인코딩된 메시지를 받아서 디코딩하고 원본을 얻는다. 133 | 134 | ### 15.5.2 콘텐츠 인코딩 유형 135 | 136 | | gzip | 엔터티에 GNU zip 인코딩이 적용되었음을 의미한다 | 137 | | compress | 엔터티에 대해 유닉스 파일 압축 프로그램인 'compress' 가 실행되었음을 의미한다 | 138 | | defalte | 엔터티가 zlib 포맷으로 압축되었음을 의미한다 | 139 | | identity | 엔터티에 어떤 인코딩도 수행되지 않았음을 의미한다. Content-Encoding 헤더가 존재하지 않는다면 이 값인 것으로 간주된다. | 140 | 141 | ### 15.5.3 Accept-Encoding 헤더 142 | 143 | 서버에서 클라이언트가 지원하지 않는 인코딩을 사용하는 것을 막기 위해, 클라이언트는 자신이 지원하는 인코딩의 목록을 Accpet-Encoding 요청 헤더를 통해 전달한다. 144 | accept-Encoding 헤더를 포함하지 않는다면, 서버는 클라이언트가 어떤 인코딩이든 받아들일 수 있는 것으로 간주한다. 145 | identity 인코딩 토큰은 오직 Accept-Encoding 헤더에만 존재할 수 있고 클라이언트에 의해 다른 콘텐츠 인코딩 알고리즘에 대한 상대적 선호도를 정의하는데 이용할 수 있다. 146 | 147 | ## 15.6 전송 인코딩과 청크 인코딩 148 | 149 | 콘텐츠 인코딩은 콘텐츠 포맷과 긴밀하게 연관되어 있다. 150 | 전송 인코딩 또한 엔터티 본문에 적용되는 가역적 변환이지만, 그들은 구조적인 이유 때문에 적용되는 것이며 콘텐츠의 포맷과는 독립적이다. 151 | 메시지 데이터가 네트워크를 통해 전송되는 방법을 바꾸기 위해 전송 인코딩을 메시지에 적용할 수 있다. 152 | 153 | ### 15.6.1 안전한 전송 154 | 155 | 전송 인코딩은 다른 프로토콜에서도 네트워크를 통한 '안전한 전송' 을 위해 존재했다. 156 | 표준화되고 너그러운 전송 기반을 갖춘 HTTP 는 '안전한 전송'의 초점을 다른데에 맞추고 있다. 157 | HTTP 에서 전송된 메시지의 본문이 문제를 일으킬 수 있는 이유는 몇 가지 밖에 없다. 158 | 159 | - 알 수 없는 크기: 몇몇 게이트웨이 애플리케이션과 콘텐츠 인코더는 콘텐츠를 먼저 생성하지 않고서는 메시지 본문의 최종 160 | 크기를 판단할 수 없다. 161 | 162 | - 보안: SSL 과 같은 유명한 전송 계층 보안 방식이 있기 때문에 전송 인코딩 보안은 흔하지 않다. 163 | 164 | ### 15.6.2 Transfer-Encoding 헤더 165 | 166 | - Transfer-Encoding: 안전한 전송을 위해 어떤 인코딩이 메시지에 적용되었는지 수신자에게 알려준다. 167 | - TE: 어떤 확장된 전송 인코딩을 사용할 수 있는지 서버에게 알려주기 위해 요청 헤더에 사용한다. 168 | 169 | ### 15.6.3 청크 인코딩 170 | 171 | 청크 인코딩은 메시지를 일정 크기의 청크 여럿으로 쪼갠다. 서버는 각 청크를 순차적으로 보낸다. 172 | 청크 인코딩을 이용하면 메시지를 보내기 전에 전체 크기를 알 필요가 업성진다. 본문이 독적으로 생성됨에 따라, 서버는 일부를 버퍼에 담은 뒤 청크를 그것의 크기와 함꼐 보낼 수 있다. 173 | 모두를 보내기 전까지 반복한다. 174 | 175 | 176 | #### 청크와 지속 커넥션 177 | 178 | 지속 커넥션에서는, 본문을 쓰기 전에 반드시 Content-Length 헤더에 본문의 길이를 담아서 보내줘야한다. 179 | 콘텐츠가 서버에서 동적으로 생성되는 경우에는, 보내기전에 본문의 길이를 알아내는 것이 불가능 할 것이다. 180 | 청크 인코딩은 서버가 본문을 여러 청크로 쪼개 보낼 수 있게 해줌으로써 이 딜레마에 대한 해법을 제공한다. 동적으로 본문이 생성되면서, 181 | 서버는 그중 일부를 버퍼에 담은 뒤 그 한 덩어리를 그의 크기와 함께 보낼 수 있다. 182 | 본문을 모두 보낼때까지 이 단계를 반복한다. 183 | 184 | 185 | #### 청크 인코딩된 메시지의 트레일러 186 | 187 | - 클라이언트의 TE 헤더가 트레일러를 받아들일 수 있음을 나타내고 있는 경우 188 | - 트레일러가 응답을 만든 서버에 의해 추가되었으며, 트레일러의 콘텐츠는 클라이언트가 이해하고 사용할 필요가 없는 선택적인 메타 데이터이므로 189 | 클라이언트가 무시하고 버려도 되는 경우 190 | 191 | ### 15.6.4 콘텐츠와 전송 인코딩의 조합 192 | 193 | 콘텐츠 인코딩과 전송 인코딩은 동시에 사용될 수 있다. 194 | 195 | ### 15.6.5 전송 인코딩 규칙 196 | 197 | - 전송 인코딩의 집합은 반드시 'chunked'를 포함해야한다. 198 | - 청크 전송 인코딩이 사용되었다면, 메시지 본문에 적용된 마지막 전송 인코딩이 존재해야한다. 199 | - 청크 전송 인코딩은 반드시 메시지 본문에 한 번 이상 적용되어야 한다. 200 | 201 | ## 15.7 시간에 따라 바뀌는 인스턴스 202 | 203 | HTTP 프로토콜은 어떤 특정한 종류의 요청이나 응답을 다루는 방법들을 정의하는데, 이것은 인스턴스 조작이라 불리며 204 | 객체의 인스턴스에 작용한다. 대표적인 두 가지가 범위 요청과 델타 인코딩이다. 205 | 클라이언트가 자신이 갖고 있는 리소스의 사본이 서버가 갖고 있는 것과 정확히 같은지 판단하고, 상황에 따라서는 새 인스턴스를 요청할 수 잇는 능력을 206 | 가질 것을 요구한다. 207 | 208 | ## 15.8 검사기와 신선도 209 | 210 | 문서가 클라이언트에서 만료되면 클라이언트는 반드시 서버에게 최신 사본을 요구해야한다. 211 | 만약 서버에서도 문서가 변경되지 않았다면 클라이언트는 다시 받을 필요가 없다. 212 | 조건부 요청이라고 불리는 특별한 요청은 클라이언트가 서버에게 자신이 갖고 있는 버전을 말해주고 검사기를 사용해 213 | 자신의 사본 버전이 더 이상 유효하지 않을 때만 사본을 보내달라고 요청하는 것이다. 214 | 215 | ### 15.8.1 신선도 216 | 217 | 서버는 클라이언트에게 얼마나 오랫동안 콘텐츠를 캐시하고 그것이 신선하다고 가정할 수 있는지에 대한 정보를 줄 것 이다. 218 | 서버는 Expires 나 Cache-Control 헤더를 통해 이러한 정보를 제공할 수 있다. 219 | 220 | ### 15.8.2 조건부 요청과 검사기 221 | 222 | 캐시의 사본이 요청되었을 때 그것이 더 이상 신선하지 않다면 캐시는 자신이 갖고 있는 사본을 신선한 것으로 만들 필요가 있다. 223 | 캐시는 원 서버에서 현 시점의 사본을 가져올 수 있지만, 대개 서버에 있는 문서는 여전히 캐시에 들어있는 신선하지 못한 사본과 같을 것이다. 224 | 만약 서버의 문서가 캐시가 갖고 있는 것과 같음에도 불구하고 항상 그 문서를 가져온다면 캐시는 네트워크의 대역폭을 낭비하고, 캐시와 서버에 불필요한 부하를 주고, 225 | 모든것을 느려지게 만든다. 226 | 227 | 이를 고치기 위해, HTTP 는 클라이언트에게 리소스가 바뀐 경우에만 사본을 요청하는 조건부 요청이라 불리는 특별한 요청을 할 수 있는 방법을 제공한다. 228 | 229 | HTTP 검사기를 약한 검사기와 강한 검사기의 두 가지로 분류한다. 230 | 약한 검사기는 리소스의 인스턴스를 고유하게 식별하지 못하는 경우도 있다. 강한 검사기는 언제나 고유하게 식별한다. 231 | 약한 검사기의 예로 객체의 바이트 단위 크기가 있다. 리소스 콘텐츠는 크기가 같더라도 내용이 다를 수 있으므로, 바이트의 개수를 세는 방식으로 동작하는 232 | 가상의 횟수 검사기는 변경이 발생했음을 약하게만 감지할 수 있다. 그러나 리소스의 콘텐츠에 대한 암호 체크섬은 강한 검사기다. 233 | 234 | ## 15.9 범위 요청 235 | 236 | HTTP 는 클라이언트가 문서의 일부분이나 특정 범위만 요청할 수 있도록 해준다. 237 | 범위 요청을 이용하면, HTTP 클라이언트는 받다가 실패한 엔터티를 일부 혹은 범위로 요청함으로써 다운로드를 중단된 시점에서 재개할 수 있다 238 | Range 헤더는 피어 투 피어 파일 공유 클라이언트가 멀티미디어 파일의 다른 부분을 여러 다른 피어로부터 동시에 다운로드 받을 때도 널리 사용된다. 239 | 범위 요청은 객체의 특정 인스턴스를 클라이언트와 서버 사이에서 교환하는 것이기 때문에, 인스턴스 조작의 일종이라는 것에 주의해야 한다. 240 | 241 | ## 15.10 델타 인코딩 242 | 243 | 델타 인코딩은 객체 전체가 아닌 변경된 부분에 대해서만 통신하여 전송량을 최적화하는, HTTP 프로토콜의 확장이다. 244 | 델타 인코딩은 일종의 인스턴스 조작인데, 왜냐하면 어떤 객체의 특정 인스턴스들에 대한 클라이언트와 서버 사이의 정보 교환에 의존하기 때문이다. 245 | 246 | 1. 클라이언트는 페이지의 어떤 버전을 갖고 있는지 서버에게 말해주어야한다. 247 | 2. 클라이언트는 자신이 갖고 있는 현재 버전에 델타를 적용하기 위해 어떤 알고리즘을 알고 있는지 서버에게 말해주어야한다. 248 | 3. 서버는 클라이언트가 갖고 있는 버전을 갖고 있는지, 어떻게 최신 버전과 클라이언트 버전에 델타를 계산할것인지 체크해야한다. 249 | 4. 델타를 계산해서 클라이언트에게 보내주고, 서버가 델타를 보내고 있음을 클라이언트에게 알려주고 페이지의 최신 버전에 대한 새 식별자를 명시해야한다. 250 | 5. 클라이언트는 자신이 갖고 있는 버전에 대한 유일한 식별자를 If-None-Match 헤더에 담는다. 251 | (서버에게 내가 갖고있는 최신 버전의 페이지가 이것과 같은 ETag 를 갖고 있지 않다면, 최신 버전의 페이지를 보내달라고 말하는 클라언트의 방식이다) 252 | 6. If-None-Match 헤더에 의해 서버는 클라이언트에게 페이지의 최신 버전 전체를 보내게 될 것 이다. 253 | 7. 클라이언트는 서버에게 A-IM 헤더를 보내서 페이지에 대한 델타를 받아들일 수 있음을 알려줄 수도 있다. 254 | 8. 서버는 클라이언트에게 요청한 객체에 대해 객체 자체가 아닌 인스턴스 조작을 보내고 있음을 말해주는 특별한 응답 코드 델타를 계산하기 위해 사용된 알고리즘을 명시한 IM 255 | 헤더, 새 ETag 헤더, 그리고 델타를 계산할 때 기반이 된 문서의 ETag 를 지정한 Delta-Base 헤더를 되돌려준다. 256 | 257 | ### 15.10.1 인스턴스 조작, 델타 생성기 그리고 델타 적용기 258 | 259 | 클라이언트는 A-IM 헤더를 사용해서 자신이 받아들일 수 있는 인스턴스 조작의 종류를 명시할 수 있다. 260 | 서버는 IM 헤더에 사용한 인스턴스 조작의 종류를 명시할 수 있다. 261 | 262 | | vcdiff | vcdiff 알고리즘을 이용한 델타 | 263 | |---|---| 264 | | diffe | 유닉스 diff -e 명령을 이용한 델타 | 265 | | gdiff | gdiff 알고리즘을 이용한 델타 | 266 | | gzip | gzip 알고리즘을 이용한 압축 | 267 | | deflate | feflate 알고리즘을 이용한 압축 | 268 | | range | 현재 응답이 범위 선택에 대한 결과인 부분콘텐츠임을 말해주기 위해 서버 응답에서 사용된다 | 269 | | identity | 클라이언트가 identity 인스턴스 조작을 받아들일 의사가 있음을 말해주기 위해 클라이언트 요청의 A-IM 헤더에서 사용된다 | 270 | 271 | 272 | 델타 인코딩은 전송 시간을 줄일 수 있지만 구현하기가 까다로울 수 있다. 273 | 델타 인코딩을 지원하는 서버는 자신이 제공하는 페이지가 변경되는 매 순간의 사본을 모두 274 | 유지하고 있어야한다. 클라이언트가 요청 보냈을 때 클라이언트가 갖고 있는 사본과 최신 사본간의 차이점을 알아 낼 수 있기 때문이다. 275 | 문서를 제공하는데 걸리는 시간이 줄어드는 대신, 서버는 문서의 과거 사본을 모두 유지하기 위해 디스크 공간을 더 늘려야한다. 276 | 이는 전송량 감소로 얻은 이득은 금방 무의미하게 만든다. 277 | 278 | 279 | 280 | 281 | 282 | 283 | 284 | 285 | 286 | 287 | 288 | 289 | 290 | 291 | 292 | 293 | 294 | 295 | 296 | 297 | 298 | 299 | 300 | 301 | -------------------------------------------------------------------------------- /chapter_16/README.md: -------------------------------------------------------------------------------- 1 | # [16장] HTTP: 엔터티, 인코딩, 국제화 / 국제화 2 | 3 | - 마감일: 1월 13일 월요일 자정 4 | - todo: 5 | - 16장 국제화 6 | 7 | ## 정리 글 링크 8 | 9 | 1. 고석진 10 | 2. 고현주 - [16.국제화](https://dev-junior.tistory.com/18) 11 | 3. 김나영 - [국제화](https://feel5ny.github.io/2020/01/13/HTTP_016/) 12 | 4. 류지환 13 | 5. 이승규 - [HTTP에서의 국제화](https://ideveloper2.dev/blog/2020-01-12--http%EC%97%90%EC%84%9C%EC%9D%98-%EA%B5%AD%EC%A0%9C%ED%99%94/) 14 | 6. 한재우 - [HTTP 완벽가이드 13장](https://bebiangel.github.io/2020/01/13/http-guide-chap16/) 15 | 7. 홍유정 - [HTTP완벽가이드 16장](https://youjung-hong.github.io/2020-01-11/HTTP완벽가이드-16-국제화/) 16 | -------------------------------------------------------------------------------- /chapter_16/고석진.md: -------------------------------------------------------------------------------- 1 | # HTTP 2 | 3 | ## 국제화 4 | 5 | HTTP 는 여러 언어와 문자로 된 국제 문서들의 처리 및 전송을 지원해야 한다. 6 | 7 | ## 16.1 국제적인 콘텐츠를 다루기 위해 필요한 HTTP 지우너 8 | 9 | HTTP 메시지는 어떤 언어로 된 콘텐츠든 미디어처럼 실어 나를 수 있다. HTTP 에서 엔터티 본문이란 비트들로 가득 찬 상자에 불과하다. 10 | 국제 콘텐츠를 지원하기 위해, 서버는 클라이언트에게 문서의 문자와 언어를 알려줘서, 클라이언트가 올바르게 문서를 이루고 있는 비트들을 문자들로 11 | 풀어내고, 올바르게 처리해서 사용자에게 콘텐츠를 제공할 수 있도록 할 필요가 있다. 12 | 13 | 서버는 클라이언트에게 문서의 문자와 언어를 HTTP Content-Type charset 매개변수와 Content-Language 헤더를 통해 알려준다. 14 | 클라이언트는 서버에게 어떤 언어를 이해할 수 있고 알파벳의 코딩 알고리즘이 브라우저에 설치되어 있는지 Aceept-Charset, Accept-Language 를 15 | 이용하여 알려줄 필요가 있다. 16 | 17 | ```text 18 | Accept-Language: fr, en;q=0.8 19 | Accept-Charset: iso-8859-1, utf-8 20 | ``` 21 | 22 | ## 16.2 문자집합과 HTTP 23 | 24 | ### 16.2.1 Charset 은 글자를 비트로 변환하는 인코딩이다 25 | 26 | HTTP Charset 값은, 어떻게 엔터티 콘텐츠 비트들을 특정 문자 체계의 글자들로 바꾸는지 말해준다. 27 | Charset 태그는 비트들을 글자들로 변환하거나 그 반대의 일을 해주는 알고리즘을 명명한다. 28 | 29 | ```text 30 | Content-Type: text/html; charset=iso-8859-6 31 | ``` 32 | 33 | Content-type 헤더는 수신자에게 콘텐츠가 HTML 파일임을 말해주고, charset 매개변수는 수신자에게 콘텐츠 비트들을 그랒들로 34 | 디코딩하기 위해 ios-8859-6 아랍 문자집합 디코딩 기법을 사용하라고 말해준다. 35 | 36 | ios-8859-6 인코딩 구조는 8비트 값을 숫자와 구두점 그리고 다른 기호들을 포함한 라틴 문자와 아랍 문자로 매핑한다. 37 | 38 | ### 16.2.2 문자집합과 인코딩은 어떻게 동작하는가 ? 39 | 40 | - 문서를 이루는 비트들은, 특정 코딩된 문자집합의 특정 문자로 식별될 수 있는 문자 코드로 변환된다. 41 | - 문자 코드는 코딩된 문자집합의 특정 요소를 선택하기 위해 사용된다. 42 | - 단계에서 사용되는 알고리즘은 MIME charset 태그를 통해 결정된다. 43 | 44 | 국제화된 문자 시스템의 핵심 목표는 표현에서 의미를 분리하는 것이다. 45 | HTTP 는 문자 데이터 및 그와 관련된 언어와 charset 라벨의 전송에만 관심을 갖는다. 46 | 47 | ### 16.2.3 잘못된 Charset 은 잘못된 글자들을 낳는다 48 | 49 | 클라이언트가 잘못된 charset 매개변수를 사용한다면, 클라이언트는 이상한 깨진 글자를 보여주게 될 것이다. 50 | 51 | // 후에 그림 추가 52 | 53 | ### 16.2.4 표준화된 MIME Charset 값 54 | 55 | 특정 문자 인코딩과 특정 코딩된 문자집합의 결합을 MIME Charset 이라고 부른다. 56 | HTTP 는 표준화된 MIME Charset 태그를 Content-Type 과 Acccept-Charset 헤더에 사용한다. 57 | 58 | [Character Sets](https://www.iana.org/assignments/character-sets/character-sets.xhtml) 59 | 60 | ### 16.2.5 Content-Type charset 헤더와 META 태그 61 | 62 | ``` 63 | Content-Type: text/html; charset=ios-2022-jp 64 | ``` 65 | 66 | 웹 서버는 클라이언트에게 MIME Charset 태그를 charset 매개변수와 함께 Content-Type 에 담아 보낸다. 67 | 만약 문자집합이 명시적으로 나열되지 않았다면, 수신자는 문서의 콘텐츠로부터 문자집합을 추측하려 시도한다. 68 | HTML Content 에서 문자 집합은 문자 집합을 서술하는 태그에서 찾을 수 있다. 69 | 만약 클라이언트가 문자 인코딩을 추측하지 못했다면, iso-8859-1 인것으로 가정한다. 70 | 71 | ### 16.2.6 Accept-Charset 헤더 72 | 73 | 대부분의 클라이언트는 모든 종류의 문자 코딩과 매핑 시스템을 지원하지 않는다. 74 | HTTP 클라이언트는 서버에게 정확히 어떤 문자 체계를 그들이 지원하는지 Accept-Charset 요청 헤더를 통해 알려준다. 75 | Accpt-Charset 헤더의 값은 클라이언트가 지원하는 문자 인코딩의 목록을 제공한다. 76 | 문자 인코딩 구조중 어떤 것으로 콘텐츠를 반환할지는 서버의 자유다. 77 | 78 | Accept-Charset 요청 헤더에 대응하는 Content-Charset 응답 헤더는 존재하지 않는다. 79 | 응답 문자집합은 MIME 과의 호환을 위해 Content-Type 응답 헤더의 charset 매개변수를 통해 서버로부터 돌려받는다. 80 | 81 | ## 16.3 다중언어 문자 인코딩에 대한 지침 82 | 83 | 국제화 애플리케이션과 콘텐츠로 많은 작업을 하는 HTTP 프로그래머는 기술 명세를 이해하고 올바르게 소프트웨어를 구현하기 위해 84 | 다중언어 문자집합 체계에 대해 깊이 이해할 필요가 있다. 85 | 86 | ### 16.3.1 문자집합 용어 87 | 88 | - 문자: 글쓰기의 최소 단위, 약식으로 유니코드라고 불리는 국제 문자 세트 89 | - 글리프: 하나의 글자를 표현하기 위한, 획의 패턴이나 다른 것과 구분되는 유일한 시각적 형태 90 | - 코딩된 문자: 글자를 다룰 수 있도록 글자에 할당된 유일한 숫자 91 | - 코드 공간: 문자 코드 값으로 사용하려고 계획해 둔 정수의 범위 92 | - 코드 너비: 문자 코드의 비트 개수 93 | - 사용 가능 문자 집합: 글자들에 대한 특정한 작업 집합 94 | - 코딩된 문자집합: 사용 가능 문자집합을 받아서 각 글자에 코드 공간이 코드를 할당해주는 코딩된 문자들의 집합 95 | - 문자 인코딩 구조: 숫자로 된 문자 코드들을 콘텐츠 비트의 연속으로 인코딩하는 알고리즘 96 | 97 | ### 16.3.2 Charset 은 형편없는 이름이다 98 | 99 | MIME Charset 태그는 문자집합을 의미하는 것이 결코 아니다. MIME Charset 값은 데이터 비트를 고유한 문자의 코드로 매핑하는 알고리즘의 이름이다. 100 | 이것은 문자 인코딩 구조와 코딩된 문자집합의 개념을 합친 것이다. 101 | 이 용어는 엉성하고 혼란스러운데, 이미 문자 인코딩 구조와 코딩된 문자집합에 대한 출판된 표준이 존재하기 때문이다. 102 | 103 | ### 16.3.3 문자 104 | 105 | 문자 쓰기는 기분적인 구성요소다. 쓰기의 기본 단위를 표현한다. 106 | 문자는 글꼴이나 스타일에 독립적이다. 107 | 108 | ### 16.3.4 글리프, 연자 그리고 표현 형태 109 | 110 | 문자는 유일하고 추상화된 언어의 요소다. 글리프는 각 글자를 그리는 특정한 방법이다. 111 | 문자는 미적인 양식과 스크립트에 따라 여러 가지 글리프를 가진다. 112 | 문자와 그것의 표현 형태를 혼동하면 안된다. 쓰기를 보다 멋지게 보이도록 하기 위해, 많은 필기체와 활자체가 인접한 113 | 글자들이 부드럽게 이어지는 연자를 지원한다. 114 | 115 | ### 16.3.5 코딩된 문자집합 116 | 117 | RFC 2277과 2130 에서 정의된 코딩된 문자집합은 정수를 글자로 대응시킨다. 118 | 코딩된 문자집합은 보통 코드 번호로 인덱싱된 배열로 구현된다. 119 | 120 | [wikipedia](https://ko.wikipedia.org/wiki/ASCII) 121 | 122 | ### 16.3.6 문자 인코딩 구조 123 | 124 | - 고정폭: 고정폭 인코딩은 각 코딩된 문자를 고정된 길이의 비트로 표현한다. 125 | - 가변폭 (비모달): 가변폭 인코딩은 다른 문자 코드 번호에 다른 길이의 비트를 사용한다. 자주 사용하는 글자의 비트 길이를 줄일 수 있고, 국제 문자에 대해서는 126 | 여러 바이트를 사용하도록 함으로써 이전 8 비트 문자집합과의 호환성도 유지할 수 있다. 127 | - 가변폭 (모달): 모달 인코딩은 다른 모드로의 전환을 위해 특별한 'escape' 패턴을 사용한다. 모달 인코딩은 처리하기 복잡하지만, 복잡한 표기 체계를 효과적으로 지원해 줄 수 있다. 128 | - 8비트: 8비트 고정폭 아이덴티티 인코딩은 간단히 각 문자 코드를 그에 대응하는 8비트 값으로 인코딩한다. iso-8859 문자 집합군은 8 비트 아이덴티티 인코딩을 사용한다. 129 | - UTF-8: UTF-8 은 인기 있는 UCS 를 위해 설계된 문자 인코딩 구조다. UTF-8 은 문자 코드의 값을 위해 비모달 가변길이 인코딩을 사용한다. 130 | 첫 바이트의 선두 비트들은 이코딩된 문자의 길이를 바이트 단위로 나타내고, 그 이후의 바이트들은 각각 6 비트의 코드 값을 담는다. 131 | - iso-2022-jp: [참고](https://ko.wikipedia.org/wiki/ISO/IEC_2022) 132 | - euc-jp: [참고](https://ko.wikipedia.org/wiki/%ED%99%95%EC%9E%A5_%EC%9C%A0%EB%8B%89%EC%8A%A4_%EC%BD%94%EB%93%9C) 133 | - euc-kr: [참고](https://ko.wikipedia.org/wiki/EUC-KR) 134 | 135 | ## 16.4 언어 태그와 HTTP 136 | 137 | 언어 태그는 언어에 이름을 붙이기 위한 짧고 표준화된 문자열이다. 138 | 언어 태그는 지역에 따라 변형된 언어나 방언을 표현할 수 있다. 139 | 140 | ### 16.4.1 Content-Language 헤더 141 | 142 | Content-Language 엔터티 헤더 필드는 엔터티가 어떤 언어 사용자를 대상으로 하고 있는지 서술한다. 143 | Content-Language 헤더는 텍스트 문서만을 위한 것이 아니다. 오디오 클립, 동영상, 애플리케이션도 특정 언어 사용자를 대상으로 할 수 있다. 144 | 145 | ### 16.4.2 Accept-Language 헤더 146 | 147 | HTTP 는 우리에게 우리의 언어 제약과 선호도를 웹 서버에 전달할 수 있게 해준다. 웹 서버가 어떤 자원에 대해 여러 언어로 된 버전을 148 | 갖고 있다면, 웹 서버는 우리가 선호하는 언어로 된 콘텐츠를 줄 수 있다. 149 | 150 | ### 16.4.3 언어 태그의 종류 151 | 152 | 언어 태그는 PFC 3066 로 문서화된 표준화된 문법을 갖고 있다. 153 | 154 | - 일반적인 언어의 종류, 특정 국가의 언어, 방언, 지방어, 다른 언어의 변형이 아닌 표준 언어, 비표준 언어 155 | 156 | ### 16.4.4 서브태그 157 | 158 | 언어 태그는 하이픈으로 분리된 하나 이상의 서브태그로 이루어져 있다. 159 | 서브태그는 A-Z 까지의 글자만을 포함한다. 160 | 161 | - 첫 번째 서브태그는 주 서브태그라 불린다. 이 값들은 표준화되어 있다. 162 | - 두 번째 서브태그는 선택적이고 자신만의 이름 표준을 따른다. 163 | - 세 번째부터의 서브 태그는 등록되어 있지 않다. 164 | 165 | ### 16.4.5 대소문자의 구분 및 표현 166 | 167 | 모든 태그는 대소문자가 구분되지 않는다. 태그 'en' 과 'eN' 은 같다. 168 | 그러나 관용적으로 언어를 나타낼 떄는 소문자를 사용하고, 국가를 나타낼 떄는 대문자를 사용한다. 169 | 170 | ### 16.4.6 IANA 언어 태그 등록 171 | 172 | 첫 번쨰와 두 번째 언어 서브태그의 값은 여러 가지 표준 문서와 그것들을 관리하는 조직에 의해서 정의된다. 173 | IANA 는 RFC 3066 의 규칙에 따라 표준 언어 태그의 목록을 관리한다. 174 | 175 | ### 16.4.7 첫 번째 서브태그: 이름공간 176 | 177 | 첫 번째 서브태그는 보통 ISO 639 표준 언어 집합에서 선택된 표준화된 언어 토큰이다. 178 | 그러나 또한 IANA 에서 등록한 이름을 의미하는 글자 'i' 일 수도 있고, 특정 집단의 전용 확장 이름임을 의미하는 'x' 일 수도 있다. 179 | 180 | - 두 글자라면 ISO 639 와 639-1 표준의 언어 코드다 181 | - 세 글자라면 ISO 639-2 표준과 확장에 열거된 언어 코드다 182 | - 글자 'i' 라면 이 언어 태그는 틀립없이 IANA 에 등록된 것이다 183 | - 글자 'x' 라면 이 언어 태그는 특정 개인이나 집단 전용의 비표준 확장 서브태그다 184 | 185 | ### 16.4.8 두 번째 서브태그: 이름공간 186 | 187 | 두 번째 서브태그는 보통 ISO 3166 국가 코드와 지역 표준 집합에서 선택된 표준화 된 국가 토큰이다. IANA 에 등록된 다른 문자열일 수도 있다. 188 | 189 | - 두 글자라면, ISO 3166 에 정의된 국가/지역이다. 190 | - 3 ~ 8 글자라면, IANA 에 등록된 것이다. 191 | - 한 글자라면, 뭔가 잘못된 것이다. 192 | 193 | ### 16.4.9 나머지 서브태그: 이름공간 194 | 195 | 세 번째와 그 이후의 서브태그에 대해서는, 8자 이하의 알파벳과 숫자가 이루어져야 한다는 것을 제외하면 다른 규칙은 없다. 196 | 197 | ### 16.4.10 선호 언어 설정하기 198 | 199 | 웹 브라우저 프로필에서 선호 언어를 선택할 수 있다. 200 | 201 | ## 16.5 국제화된 URI 202 | 203 | 오늘날 URI 는 국제화를 그다지 지원하지 않는다. 몇 가지 예외와 함께, 오늘날의 URI 는 US-ASCII의 부분집합으로 구성되어 있다. 204 | 호스트명과 URI의 경로에 더 풍부한 문자집합을 포함할 수 있게 하려는 노력이 진행중이지만, 이러한 표준은 널리 받아들여지지도 205 | 사용되지도 않고 있다. 206 | 207 | ### 16.5.1 국제적 가독성 vs 의미 있는 문자들 208 | 209 | URI 설계자들은 전 세계의 모두가 URI 를 이메일, 전화, 광고판, 라디오 등을 통해 다른 이들과 공유할 수 있기를 원했다. 210 | 그들은 URI 가 사용하기 쉽소 기억하기 쉽길 바랐다. 211 | 공유하기 쉽게 설계자들은 제한된 공통 문자집합을 선택했다. 212 | 불행히도 문자집합에는 제한이 있기 떄문에, URI 는 비영어권 사람들도 쉽게 사용하고 기억할 수 있도록 그들의 문자로 만들 수 있게 설계되지는 못했다. 213 | URI 저자들은 리소스 식별자의 가독성과 공유 가능성의 보장이, 대부분의 의미 있는 문자들로 구성될 수 있도록 하는 것보다 더 중요하다고 여겼다. 214 | 그래서 우리들은 ASCII 문자들의 제한된 집합으로 이루어진 URI 를 갖게되었다. 215 | 216 | ### 16.5.2 URI 에서 사용될 수 있는 문자들 217 | 218 | URI 에서 사용할 수 있는 US-ASCII 문자들의 부분집합은 예약된 문자들, 예약되지 않은 문자들, 이스케이프 문자들로 나뉜다. 219 | 예약되지 않은 문자들은 그것들을 허용하는 URI 의 어떤 구성요소에서든 일반적으로 사용될 수 있다. 220 | 221 | ### 16.5.3 이스케이핑과 역 이스케이핑 222 | 223 | URI 이스케이프는 예약된 문자나 다른 지원하지 않는 글자들을 안전하게 URI 에 삽입할 수 있는 방법을 제공한다. 224 | 이스케이프는 퍼센트 글자 하나와 뒤이은 16진수 글자 둘로 이루어진 세 글자 문자열이다. 225 | 16진수 두 글자는 US-ASCII 문자의 코드를 나타낸다. 226 | 227 | 내부적으로 HTTP 애플리케이션은 URI 를 데이터가 필요할 때만 언이스케이핑해야한다. 228 | 애플리케이션은 어떤 URI 도 두 번 언이스케이핑 되지 않도록 해야한다. 229 | 230 | ### 16.5.4 국제 문자들을 이스케이핑하기 231 | 232 | 이스케이프 값들은 US-ASCII 코드의 범위에 있어야 함에 주의해야한다. 233 | 어떤 애플리케이션은 iso-8859-1 확장 문자들을 표현하기 위해 이스케이프 값을 사용하려 한다. 234 | 웹 서버는 국제 문자를 포함한 파일 이름을 부호화하기 위해 이스케이핑을 오용했을 수도 있다. 이는 부정확하며 어떤 애플리케이션에서는 문제를 유발할 수 있다. 235 | 236 | ### 16.5.5 URI 에서의 모달 전환 237 | 238 | 몇몇 URI는 다른 문자집합의 글자를 표현하기 위해 ASCII 문자열을 사용한다. 239 | 현재 URI 는 그다지 국제화에 친화적이지 않다. URI 이식성의 목표는 언어 유연성의 목표보다 중요했다. 240 | 241 | ## 16.6 기타 고려사항 242 | 243 | ### 16.6.1 헤더와 명세에 맞지 않는 데이터 244 | 245 | HTTP 헤더는 반드시 US-ASCII 문자집합의 글자들로만 이루어져야 한다. 246 | 그러나 모든 클라이언트와 서버가 이를 올바르게 구현한 것은 아니므로, 때때로 127보다 큰 코드 값을 갖는 잘못된 문자를 받게 될 수도 있다. 247 | 많은 HTTP 애플리케이션은 글자들을 처리하기 위해 운영체제와 라이브러리 루틴을 사용한다. 248 | HTTP 메시지를 처리학 위해 문자 구분 라이브러리를 사용하기 전에, 메시지에 잘못된 데이터가 포함되어 있을 경우를 대비해 문서를 주의 깊게 읽어야한다. 249 | 250 | ### 16.2.2 날짜 251 | 252 | HTTP 명세는 올바른 GMT 날짜 형식을 명확히 정의하고 있지만 모든 웹 서버와 클라이언트가 규칙을 따르고 있지 않음에 주의하라. 253 | HTTP 애플리케이션은 명세에 맞지 않는 날짜를 관대하게 받아들이고, 받아들이면서 충돌을 일으키지 말아야 한다. 254 | 255 | ### 16.6.3 도메인 이름 256 | 257 | 국제화 문자를 포함하는 도메인 이름을 국제화 도메인 이름이라고 하는데, 오늘날 대부분의 웹브라우저가 퓨니코드를 이용해 이를 지원한다. 258 | 퓨니코드란 유니코드 문자열을 호스트 명에서 사용가능한 문자만으로 이루어진 문자열로 변환하는 방법으로, RFC3492 로 정의되어있다. 259 | 260 | 261 | 262 | 263 | 264 | 265 | 266 | 267 | 268 | 269 | 270 | 271 | 272 | 273 | 274 | 275 | 276 | 277 | 278 | 279 | 280 | 281 | 282 | 283 | 284 | 285 | 286 | 287 | 288 | 289 | 290 | 291 | 292 | 293 | 294 | 295 | 296 | 297 | -------------------------------------------------------------------------------- /chapter_17/README.md: -------------------------------------------------------------------------------- 1 | # [17장] HTTP: 엔터티, 인코딩, 국제화 / 내용 협상과 트랜스코딩 2 | 3 | - 마감일: 1월 20일 월요일 자정 4 | - todo: 5 | - 17장 내용 협상과 트랜스코딩 6 | 7 | ## 정리 글 링크 8 | 9 | 1. 고석진 10 | 2. 고현주 11 | 3. 김나영 - [내용 협상과 트랜스코딩](https://feel5ny.github.io/2020/01/20/HTTP_017/) 12 | 4. 류지환 13 | 5. 이승규 - [내용 협상과 트랜스코딩](https://ideveloper2.dev/blog/2020-01-19--%EB%82%B4%EC%9A%A9-%ED%98%91%EC%83%81%EA%B3%BC-%ED%8A%B8%EB%9E%9C%EC%8A%A4%EC%BD%94%EB%94%A9/) 14 | 6. 한재우 - [HTTP 완벽가이드 17장](https://bebiangel.github.io/2020/01/19/http-guide-chap17/) 15 | 7. 홍유정 - [내용 협상과 트랜스코딩](https://youjung-hong.github.io/2020-01-19/HTTP완벽가이드-17-내용-협상과-트랜스코딩/) 16 | -------------------------------------------------------------------------------- /chapter_17/고석진.md: -------------------------------------------------------------------------------- 1 | # HTTP 2 | 3 | ## 17.1 내용 협상 기법 4 | 5 | | 기법 | 어떻게 동작하는가 | 장점 | 단점 | 6 | |---|---|---|---| 7 | | 클라이언트 주도 | 클라이언트가 요청을 보내면 서버는 클라이언트에게 선택지를 보내주고, 클라이언트에서 선택한다 | 서버 입장에서 구현하기가 쉽다 | 대기 시간이 증가한다. 최소 두번의 요청이 필요하다 | 8 | | 서버 주도 | 서버가 클라이언트의 요청 헤더를 검증해서 어떤 버젼을 제공할지 결정한다 | 클라이언트 주도 협상보다 빠르다. HTTP 는 서버가 가장 적절한 것을 선택할 수 있도록 q값 메커니즘을 제공하고, 서버가 다운 스트림 장치에게 요청이 어떻게 평가되는지 말해줄 수 있도록 하기 위해 vary 헤더를 제공한다 | 헤더에 맞는 것이 없다면, 서버가 추측을 해야한다 | 9 | | 중간 장치 (프락시 캐시) | 웹 서버가 협상을 할 필요가 없다. 클라이언트 주도보다 빠르다 | 투명 협상을 어떻게 하는지에 대한 정형화된 명세가 없다 | 10 | 11 | ## 17.2 클라이언트 주도 협상 12 | 13 | 클라이언트 주도의 협상의 단점은 각 페이지에 두 번의 요청이 필요하다는 것이다. 한번은 목록을 얻고 두 번째는 선택한 사본을 얻는다. 14 | 서버에게는 클라이언트에게 줄 선택지를 표현하는 두 가지 방버이 있다. 15 | 여러 가지 버전에 대한 링크와 각각에 대한 설명이 담긴 HTML 페이지를 돌려주거나, 300 Multiple Choices 응답 코드로 16 | HTTP/1.1 응답을 돌려주는 것이다. 17 | 결정은 브라우저 사용자에 의해 수동으로 클라이언트 쪽에서 행해진다. 18 | 19 | 증가된 대기시간과 페이지당 여러번의 요청이 필요하다는 단점 외에도 여러 개의 URL 을 요구한다는 점이다. 20 | 21 | ## 17.3 서버 주도 협상 22 | 23 | 클라이언트는 자신의 무엇을 선호하는지에 대한 충분한 정보를 서버에게 주어서 서버가 현명한 결정을 할 수 있게 해 주어야한다. 24 | 서버는 이 정보를 클라이언트의 요청 헤더에서 얻는다. 25 | 26 | HTTP 서버가 클라이언트에게 보내줄 적절한 응답을 계산하기 위해 사용하는 매커니즘은 두 가지이다. 27 | 28 | - 내용 협상 헤더들을 살펴본다. 서버는 클라이언트의 Accept 관련 헤더들을 들여다보고 그에 알맞은 응답 헤더를 준비한다. 29 | - 내용 협상 헤더 외의 다른 헤더들을 살펴본다. 서버는 클라이언트의 User-Agent 헤더에 기반하여 응답을 보내줄 수도 있다. 30 | 31 | ### 17.3.1 내용 협상 헤더 32 | 33 | | 헤더 | 설명 | 34 | |---|---| 35 | | Accept | 서버가 어떤 미디어 타입으로 보내도 되는지 알려준다 | 36 | | Accept-Language | 서버가 어떤 언어로 보내도 되는지 알려준다 | 37 | | Accept-Charset | 서버가 어떤 Charset 으로 보내도 되는지 알려준다 | 38 | | Accept-Encoding | 서버가 어떤 인코딩으로 보내도 되는지 알려준다 | 39 | 40 | 엔터티 헤더는 메시지를 서버에서 클라이언트로 전송 할 때 필요한 메시지 본문의 속성을 가리킨다. 41 | 협상 헤더들은 클라이언트와 서버가 선호 정보를 서로 교환하고 문서들의 여러 버전 중 하나를 선택하는 것을 도와, 42 | 클라이언트의 선호에 가장 잘 맞는 문서를 제공해 주기 위한 목적으로 사용된다. 43 | 44 | | Accpet 관련 헤더들 | 엔터티 헤더 | 45 | |---|---| 46 | | Accept | Content-Type | 47 | | Accept-Language | Content-Language | 48 | | Accept-Charset | Content-Type | 49 | | Accept-Encoding | Content-Encoding | 50 | 51 | HTTP 는 상태가 없는 프로토콜이기 때문에, 클라이언트는 자신의 선호 정보를 반드시 매 요청마다 보내야 한다. 52 | HTTP 는 클라이언트를 위해 그들의 선호에 대한 설명을 품질값(q값) 을 이용해 전달할 수 있는 매커니즘을 제공한다. 53 | 54 | ### 17.3.2 내용 협상 헤더의 품질값 55 | 56 | ```text 57 | Accept-Language: en; q=0.5, fr;q=0.0, nl;q=1.0, tr;q=0 58 | ``` 59 | 60 | q값은 0.0부터 1.0까지의 값을 가질 수 있다 (0.0 이 가장 낮은 선호도, 1.0이 가장 높은 선호도를 의미한다). 61 | 62 | ### 17.3.3 그 외의 헤더들에 의해 결정 63 | 64 | 서버는 또한 User-Agent 와 같은 클라이언트의 다른 요청 헤더들을 이용해 알맞은 요청을 만들어내려고 시도할 수 있다. 65 | 서버가 오래된 버전의 웹브라우저는 자바스크립트를 지원하지 않는다는 것을 알고 있다면, 그들에게는 자바스크립트를 포함하지 않은 페이지를 돌려줄 수도 있다. 66 | 67 | 캐시는 반드시 캐시된 문서의 올바른 '최선의'버전을 제공해주려 해야 하기 때문에, HTTP 프로토콜은 서버가 응답에 넣어 보낼 수 있는 Vary 헤더를 정의한다. 68 | Vary 헤더는 캐시에게 서버가 내줄 응답의 최선의 버전을 결정하기 위해 어떤 요청 헤더를 참고하고 있는지 말해준다. 69 | 70 | ### 17.3.4 아파치의 내용 협상 71 | 72 | 내용 협상은 웹 사이트 콘텐츠의 제공자에게 달려있다. 73 | 74 | - 웹 사이트 디렉터리에서, variant 를 갖는 웹 사이트의 각 URI 를 위한 type-map 파일을 만든다. 그 type-map 파일은 모든 variant와 그들 각각에 대응하는 내용 협상 헤더들을 나열한다. 75 | - 아파치가 그 디렉터리에 대해 자동으로 type-map 파일을 생성하도록 하는 MultiViews 지시어를 켠다. 76 | 77 | #### type-map 파일 사용하기 78 | 79 | 아파치 서버는 type-map 파일이 어떻게 생겼는지 알 필요가 있다. 서버 설정 파일에 type-map 파일들을 위한 파일 접미사를 80 | 명시한 핸들러를 추가한다. 81 | 82 | ```text 83 | AddHandler type-map .var 84 | ``` 85 | 86 | #### MultiViews 사용하기 87 | 88 | MultiViews 를 사용하려면, access.conf 파일의 적절한 절 , 혹은 에 Options 지시어를 이용해서 89 | 웹 사이트를 포함한 디렉터리에 MultiViews 를 반드시 켜야한다. 90 | 만약 MultiViews 가 켜져 있고 브라우저가 해당 리소스를 요청했다면, 서버는 이름에 해당 리소스가 들어 있는 모든 파일을 살펴보고 91 | 그들에 대한 type-map 파일을 생성한다. 92 | 93 | ## 17.4 투명 협상 94 | 95 | 투명 협상은 클라이언트 입장에서 협상하는 중개자 프락시를 둠으로써 클라이언트와의 메시지 교환을 최소화하는 동시에 서버 주도 협상으로 96 | 인한 부하를 서버에서 제거한다. 97 | 프락시는 클라이언트의 기대가 무엇인지 알고 있고, 클라이언트의 입장에서 협상을 수행할 수 있는 능력이 있는 것으로 가정된다. 98 | 투명한 내용 협상을 지원하기 위해, 서버는 클라이언트의 요청에 가장 잘 맞는 것이 무엇인지 판별하려면 어떤 요청 헤더를 검사해야 하는지 프락시에게 99 | 반드시 말해줄 수 있어야 한다. 100 | HTTP/1.1 명세는 투명 협상에 대한 어떤 매커니즘도 정의하지 않았지만, 대신 Vary 헤더를 정의했다. 서버는 응답에 Vary 헤더를 포함시켜 보냄으로써 101 | 중개자에게 내용 협상을 위해 어떤 헤더를 사용하고 있는지 알려줄 수 있다. 102 | 103 | ### 17.4.1 캐시와 얼터네이트 104 | 105 | 콘텐츠를 캐시하는 것은 그 콘텐츠가 나중에 재사용될 것이라고 예상하기 때문이다. 106 | 캐시는 클라이언트에게 올바로 캐시된 응답을 돌려주기 위해, 서버가 응답을 돌려줄 때 사용했던 의사결정 로직의 상당 부분을 그대로 사용해야 한다. 107 | 캐시는 캐시된 응답을 돌려보낼 때 반드시 같은 헤더를 사용해야한다. 108 | 109 | 캐시는 반드시 두 번째 응답도 서버에게 그대로 전달하고 URL에 대한 이번의 응답과 지난번의 응답을 모두 저장해야 한다. 110 | 서버와 마찬가지로, 캐시는 이제 같은 URL 에 대해 두 개의 다른 문서를 갖게 된다. 111 | 다른 버전은 배리언트나 얼터네이트로 불린다. 내용 협상은 배리언트 중에서 클라이언트의 요청에 가장 잘 맞는 것을 선택하는 과정으로 이해될 수 있다. 112 | 113 | ### 17.4.2 Vary 헤더 114 | 115 | HTTP Vary 응답 헤더는 서버가 문서를 선택하거나 커스텀 콘텐츠를 생성할 때 고려한 클라이언트 요청 헤더 모두를 나열한다. 제공된 문서가 116 | User-Agent 헤더에 의존한다면, Vary 헤더는 반드시 "User-Agent" 를 포함해야한다. 117 | 캐시가 문서를 클라이언트에게 제공해 줄 수 있게 되기 전에, 캐시는 캐시된 응답 안에 서버가 보낸 Vary 헤더가 들어있는지 확인해야한다. 118 | Vary 헤더가 존재한다면, Vary 헤더가 명시하고 있는 헤더들은 새 요청과 오래된 캐시된 요청에서 그 값이 서로 맞아야만 한다. 119 | 투명 협상을 구현하기 위해 캐시는 반드시 캐시된 variant 와 함께 클라이언트 요청 헤더에 그에 알맞은 서버 응답 헤더 양쪽 모두를 저장해야 한다. 120 | 121 | 캐시는 각 배리언트마다 알맞은 문서 버전을 저장해야 한다. 캐시가 검색을 할 때, 내용 협상 헤더로 적합한 콘텐츠를 맞춰보고, 122 | 다음에 요청의 배리언트를 캐시된 배리언트와 맞춰본다. 맞는 것이 없으면, 캐시는 문서를 서버에서 가져온다. 123 | 124 | ## 17.5 트랜스코딩 125 | 126 | 서버가 클라이언트의 요구에 맞는 문서를 아예 갖고 있지 않다면 서버는 에러로 응답해야겠지만, 이론적으로 서버는 기존의 문서를 클라이언트가 127 | 사용할 수 있는 무언가로 변활할 수 있다. 이 옵션을 트랜스코딩이라고 부른다. 128 | 129 | ### 17.5.1 포맷 변환 130 | 131 | 포맷 변환은 데이터를 클라이너트가 볼 수 있도록 한 포맷에서 다른 포맷으로 변환하는 것이다. 132 | 포맷 변환은 협상 헤더에 의해 주도된다. 내용 변환 혹은 트랜스코딩은 콘텐츠 인코딩이나 133 | 전송 인코딩과는 다르다는 것에 주의하라. 134 | 135 | ### 17.5.2 정보 합성 136 | 137 | 문서에서 정보의 요점을 추출하는 것을 정보 합성이라고하는데, 트랜스코딩 과정에서 유용할 수 있다. 138 | 본문의 키워드에 기반하여 페이지를 분류하는 복잡한 기술은 문서의 핵심을 요약할 때도 유용하다. 139 | 140 | ### 17.5.3 콘텐츠 주입 141 | 142 | 양을 늘리는 또 다른 종류의 변환인 내용 주입 트랜스코딩이라는 것도 있다. 143 | 내용 주입 트랜스코딩의 예로 자동 광고 생성과 사용자 추적 시스템이 있다. 144 | 사용자 추적 시스템 또한 어떻게 페이지가 보여지고 클라이언트가 웹을 돌아다니는지에 대한 통계를 수집하기 위해 페이지에 동적으로 145 | 콘텐츠를 추가할 수 있도록 만들어져 있다. 146 | 147 | ### 17.5.4 트랜스코딩 vs 정적으로 미리 생성해놓기 148 | 149 | 트랜스코딩의 대안은 웹 서버에서 웹페이지의 여러 가지 사본을 만드는 것이다. 150 | 루트페이지를 필요할 때마다 변환하는 것은 정적으로 미리 생성해 놓는 것보다 더 쉬운 해결책이다. 151 | 이는 콘텐츠 제공에 있어 대기시간 증가로 인한 비용을 초래할 수 있다. 그러나 계산중 몇몇은 제삼자에게 수행하게 하여 152 | 웹 서버의 부담을 덜 수 있다. 변환은 더 싼 프락시나 캐시에 있는 외부 에이전트에 의해 수행될 수 있다. 153 | 154 | 155 | 156 | 157 | 158 | 159 | 160 | 161 | 162 | 163 | 164 | 165 | 166 | 167 | 168 | 169 | 170 | 171 | 172 | -------------------------------------------------------------------------------- /chapter_18/README.md: -------------------------------------------------------------------------------- 1 | # [18장] HTTP: 콘텐츠 발행 및 배포 / 웹 호스팅 2 | 3 | - 마감일: 2월 3일 월요일 자정 4 | - todo: 5 | - 18장 웹 호스팅 + 19장 배포 시스템 (1~2.4) 6 | 7 | ## 정리 글 링크 8 | 9 | 1. 고석진 10 | 2. 김나영 - [웹 호스팅](https://feel5ny.github.io/2020/02/02/HTTP_018/), [WebDAV와 공동제작](https://feel5ny.github.io/2020/02/03/HTTP_019/) 11 | 3. 류지환 12 | 4. 이승규 - [HTTP 애플리케이션 웹 호스팅](https://ideveloper2.dev/blog/2020-02-01--http-%EC%95%A0%ED%94%8C%EB%A6%AC%EC%BC%80%EC%9D%B4%EC%85%98-%EC%9B%B9-%ED%98%B8%EC%8A%A4%ED%8C%85/) 13 | 5. 한재우 - [HTTP 완벽가이드 18장](https://bebiangel.github.io/2020/02/03/http-guide-chap18/) 14 | -------------------------------------------------------------------------------- /chapter_19/README.md: -------------------------------------------------------------------------------- 1 | # [19장] HTTP: 콘텐츠 발행 및 배포 / 배포 시스템 2 | 3 | - 마감일: 2월 10일 월요일 자정 4 | - todo: 5 | - 19장 배포 시스템 (2.5 ~) ~ 20장 리다이렉션과 부하 군형 (1~3) 6 | 7 | ## 정리 글 링크 8 | 9 | 1. 고석진 10 | 2. 김나영 11 | 3. 류지환 12 | 4. 이승규 13 | 5. 한재우 14 | -------------------------------------------------------------------------------- /chapter_20/README.md: -------------------------------------------------------------------------------- 1 | # [19장] HTTP: 콘텐츠 발행 및 배포 / 리다이렉션과 부하 군형 2 | 3 | - 마감일: 2월 17일 월요일 자정 4 | - todo: 5 | - 20장 리다이렉션과 부하 군형 (4~5) 6 | 7 | ## 정리 글 링크 8 | 9 | 1. 고석진 10 | 2. 김나영 11 | 3. 류지환 12 | 4. 이승규 13 | 5. 한재우 14 | -------------------------------------------------------------------------------- /chapter_21/README.md: -------------------------------------------------------------------------------- 1 | # [18장] HTTP: 콘텐츠 발행 및 배포 / 로깅과 사용 추적 2 | 3 | - 마감일: 2월 24일 월요일 자정 4 | - todo: 5 | - 리다이렉션과 부하 군형 (6~10) + 로깅과 사용 추적 6 | 7 | ## 정리 글 링크 8 | 9 | 1. 고석진 10 | 2. 김나영 11 | 3. 류지환 12 | 4. 이승규 13 | 5. 한재우 14 | -------------------------------------------------------------------------------- /images/1-1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bookcrush/httpPerfectGuide/f038fb52319dba3dfb2b9eb34a987b8cd8564a97/images/1-1.png -------------------------------------------------------------------------------- /images/1-10.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bookcrush/httpPerfectGuide/f038fb52319dba3dfb2b9eb34a987b8cd8564a97/images/1-10.png -------------------------------------------------------------------------------- /images/1-11.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bookcrush/httpPerfectGuide/f038fb52319dba3dfb2b9eb34a987b8cd8564a97/images/1-11.png -------------------------------------------------------------------------------- /images/1-12.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bookcrush/httpPerfectGuide/f038fb52319dba3dfb2b9eb34a987b8cd8564a97/images/1-12.png -------------------------------------------------------------------------------- /images/1-13.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bookcrush/httpPerfectGuide/f038fb52319dba3dfb2b9eb34a987b8cd8564a97/images/1-13.png -------------------------------------------------------------------------------- /images/1-14.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bookcrush/httpPerfectGuide/f038fb52319dba3dfb2b9eb34a987b8cd8564a97/images/1-14.png -------------------------------------------------------------------------------- /images/1-15.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bookcrush/httpPerfectGuide/f038fb52319dba3dfb2b9eb34a987b8cd8564a97/images/1-15.png -------------------------------------------------------------------------------- /images/1-2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bookcrush/httpPerfectGuide/f038fb52319dba3dfb2b9eb34a987b8cd8564a97/images/1-2.png -------------------------------------------------------------------------------- /images/1-3.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bookcrush/httpPerfectGuide/f038fb52319dba3dfb2b9eb34a987b8cd8564a97/images/1-3.png -------------------------------------------------------------------------------- /images/1-4.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bookcrush/httpPerfectGuide/f038fb52319dba3dfb2b9eb34a987b8cd8564a97/images/1-4.png -------------------------------------------------------------------------------- /images/1-5.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bookcrush/httpPerfectGuide/f038fb52319dba3dfb2b9eb34a987b8cd8564a97/images/1-5.png -------------------------------------------------------------------------------- /images/1-6.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bookcrush/httpPerfectGuide/f038fb52319dba3dfb2b9eb34a987b8cd8564a97/images/1-6.png -------------------------------------------------------------------------------- /images/1-7.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bookcrush/httpPerfectGuide/f038fb52319dba3dfb2b9eb34a987b8cd8564a97/images/1-7.png -------------------------------------------------------------------------------- /images/1-8.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bookcrush/httpPerfectGuide/f038fb52319dba3dfb2b9eb34a987b8cd8564a97/images/1-8.png -------------------------------------------------------------------------------- /images/1-9.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bookcrush/httpPerfectGuide/f038fb52319dba3dfb2b9eb34a987b8cd8564a97/images/1-9.png -------------------------------------------------------------------------------- /images/2-1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bookcrush/httpPerfectGuide/f038fb52319dba3dfb2b9eb34a987b8cd8564a97/images/2-1.png -------------------------------------------------------------------------------- /images/2-2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bookcrush/httpPerfectGuide/f038fb52319dba3dfb2b9eb34a987b8cd8564a97/images/2-2.png -------------------------------------------------------------------------------- /images/2-3.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bookcrush/httpPerfectGuide/f038fb52319dba3dfb2b9eb34a987b8cd8564a97/images/2-3.png -------------------------------------------------------------------------------- /images/2-4.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bookcrush/httpPerfectGuide/f038fb52319dba3dfb2b9eb34a987b8cd8564a97/images/2-4.png -------------------------------------------------------------------------------- /images/2-5.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bookcrush/httpPerfectGuide/f038fb52319dba3dfb2b9eb34a987b8cd8564a97/images/2-5.png -------------------------------------------------------------------------------- /images/2-6.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bookcrush/httpPerfectGuide/f038fb52319dba3dfb2b9eb34a987b8cd8564a97/images/2-6.png -------------------------------------------------------------------------------- /images/3-1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bookcrush/httpPerfectGuide/f038fb52319dba3dfb2b9eb34a987b8cd8564a97/images/3-1.png -------------------------------------------------------------------------------- /images/3-10.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bookcrush/httpPerfectGuide/f038fb52319dba3dfb2b9eb34a987b8cd8564a97/images/3-10.png -------------------------------------------------------------------------------- /images/3-11.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bookcrush/httpPerfectGuide/f038fb52319dba3dfb2b9eb34a987b8cd8564a97/images/3-11.png -------------------------------------------------------------------------------- /images/3-12.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bookcrush/httpPerfectGuide/f038fb52319dba3dfb2b9eb34a987b8cd8564a97/images/3-12.png -------------------------------------------------------------------------------- /images/3-13.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bookcrush/httpPerfectGuide/f038fb52319dba3dfb2b9eb34a987b8cd8564a97/images/3-13.png -------------------------------------------------------------------------------- /images/3-14.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bookcrush/httpPerfectGuide/f038fb52319dba3dfb2b9eb34a987b8cd8564a97/images/3-14.png -------------------------------------------------------------------------------- /images/3-15.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bookcrush/httpPerfectGuide/f038fb52319dba3dfb2b9eb34a987b8cd8564a97/images/3-15.png -------------------------------------------------------------------------------- /images/3-2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bookcrush/httpPerfectGuide/f038fb52319dba3dfb2b9eb34a987b8cd8564a97/images/3-2.png -------------------------------------------------------------------------------- /images/3-3.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bookcrush/httpPerfectGuide/f038fb52319dba3dfb2b9eb34a987b8cd8564a97/images/3-3.png -------------------------------------------------------------------------------- /images/3-4.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bookcrush/httpPerfectGuide/f038fb52319dba3dfb2b9eb34a987b8cd8564a97/images/3-4.png -------------------------------------------------------------------------------- /images/3-5.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bookcrush/httpPerfectGuide/f038fb52319dba3dfb2b9eb34a987b8cd8564a97/images/3-5.png -------------------------------------------------------------------------------- /images/3-6.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bookcrush/httpPerfectGuide/f038fb52319dba3dfb2b9eb34a987b8cd8564a97/images/3-6.png -------------------------------------------------------------------------------- /images/3-7.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bookcrush/httpPerfectGuide/f038fb52319dba3dfb2b9eb34a987b8cd8564a97/images/3-7.png -------------------------------------------------------------------------------- /images/3-8.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bookcrush/httpPerfectGuide/f038fb52319dba3dfb2b9eb34a987b8cd8564a97/images/3-8.png -------------------------------------------------------------------------------- /images/3-9.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bookcrush/httpPerfectGuide/f038fb52319dba3dfb2b9eb34a987b8cd8564a97/images/3-9.png -------------------------------------------------------------------------------- /images/4-1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bookcrush/httpPerfectGuide/f038fb52319dba3dfb2b9eb34a987b8cd8564a97/images/4-1.png -------------------------------------------------------------------------------- /images/4-10.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bookcrush/httpPerfectGuide/f038fb52319dba3dfb2b9eb34a987b8cd8564a97/images/4-10.png -------------------------------------------------------------------------------- /images/4-11.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bookcrush/httpPerfectGuide/f038fb52319dba3dfb2b9eb34a987b8cd8564a97/images/4-11.png -------------------------------------------------------------------------------- /images/4-12.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bookcrush/httpPerfectGuide/f038fb52319dba3dfb2b9eb34a987b8cd8564a97/images/4-12.png -------------------------------------------------------------------------------- /images/4-13.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bookcrush/httpPerfectGuide/f038fb52319dba3dfb2b9eb34a987b8cd8564a97/images/4-13.png -------------------------------------------------------------------------------- /images/4-14.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bookcrush/httpPerfectGuide/f038fb52319dba3dfb2b9eb34a987b8cd8564a97/images/4-14.png -------------------------------------------------------------------------------- /images/4-15.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bookcrush/httpPerfectGuide/f038fb52319dba3dfb2b9eb34a987b8cd8564a97/images/4-15.png -------------------------------------------------------------------------------- /images/4-16.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bookcrush/httpPerfectGuide/f038fb52319dba3dfb2b9eb34a987b8cd8564a97/images/4-16.png -------------------------------------------------------------------------------- /images/4-17.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bookcrush/httpPerfectGuide/f038fb52319dba3dfb2b9eb34a987b8cd8564a97/images/4-17.png -------------------------------------------------------------------------------- /images/4-18.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bookcrush/httpPerfectGuide/f038fb52319dba3dfb2b9eb34a987b8cd8564a97/images/4-18.png -------------------------------------------------------------------------------- /images/4-19.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bookcrush/httpPerfectGuide/f038fb52319dba3dfb2b9eb34a987b8cd8564a97/images/4-19.png -------------------------------------------------------------------------------- /images/4-2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bookcrush/httpPerfectGuide/f038fb52319dba3dfb2b9eb34a987b8cd8564a97/images/4-2.png -------------------------------------------------------------------------------- /images/4-20.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bookcrush/httpPerfectGuide/f038fb52319dba3dfb2b9eb34a987b8cd8564a97/images/4-20.png -------------------------------------------------------------------------------- /images/4-21.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bookcrush/httpPerfectGuide/f038fb52319dba3dfb2b9eb34a987b8cd8564a97/images/4-21.png -------------------------------------------------------------------------------- /images/4-3.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bookcrush/httpPerfectGuide/f038fb52319dba3dfb2b9eb34a987b8cd8564a97/images/4-3.png -------------------------------------------------------------------------------- /images/4-4.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bookcrush/httpPerfectGuide/f038fb52319dba3dfb2b9eb34a987b8cd8564a97/images/4-4.png -------------------------------------------------------------------------------- /images/4-5.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bookcrush/httpPerfectGuide/f038fb52319dba3dfb2b9eb34a987b8cd8564a97/images/4-5.png -------------------------------------------------------------------------------- /images/4-6.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bookcrush/httpPerfectGuide/f038fb52319dba3dfb2b9eb34a987b8cd8564a97/images/4-6.png -------------------------------------------------------------------------------- /images/4-7.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bookcrush/httpPerfectGuide/f038fb52319dba3dfb2b9eb34a987b8cd8564a97/images/4-7.png -------------------------------------------------------------------------------- /images/4-8.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bookcrush/httpPerfectGuide/f038fb52319dba3dfb2b9eb34a987b8cd8564a97/images/4-8.png -------------------------------------------------------------------------------- /images/4-9.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bookcrush/httpPerfectGuide/f038fb52319dba3dfb2b9eb34a987b8cd8564a97/images/4-9.png -------------------------------------------------------------------------------- /images/5-1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bookcrush/httpPerfectGuide/f038fb52319dba3dfb2b9eb34a987b8cd8564a97/images/5-1.png -------------------------------------------------------------------------------- /images/5-10.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bookcrush/httpPerfectGuide/f038fb52319dba3dfb2b9eb34a987b8cd8564a97/images/5-10.png -------------------------------------------------------------------------------- /images/5-11.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bookcrush/httpPerfectGuide/f038fb52319dba3dfb2b9eb34a987b8cd8564a97/images/5-11.png -------------------------------------------------------------------------------- /images/5-2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bookcrush/httpPerfectGuide/f038fb52319dba3dfb2b9eb34a987b8cd8564a97/images/5-2.png -------------------------------------------------------------------------------- /images/5-3.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bookcrush/httpPerfectGuide/f038fb52319dba3dfb2b9eb34a987b8cd8564a97/images/5-3.png -------------------------------------------------------------------------------- /images/5-4.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bookcrush/httpPerfectGuide/f038fb52319dba3dfb2b9eb34a987b8cd8564a97/images/5-4.png -------------------------------------------------------------------------------- /images/5-5.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bookcrush/httpPerfectGuide/f038fb52319dba3dfb2b9eb34a987b8cd8564a97/images/5-5.png -------------------------------------------------------------------------------- /images/5-6.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bookcrush/httpPerfectGuide/f038fb52319dba3dfb2b9eb34a987b8cd8564a97/images/5-6.png -------------------------------------------------------------------------------- /images/5-7.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bookcrush/httpPerfectGuide/f038fb52319dba3dfb2b9eb34a987b8cd8564a97/images/5-7.png -------------------------------------------------------------------------------- /images/5-8.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bookcrush/httpPerfectGuide/f038fb52319dba3dfb2b9eb34a987b8cd8564a97/images/5-8.png -------------------------------------------------------------------------------- /images/5-9.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bookcrush/httpPerfectGuide/f038fb52319dba3dfb2b9eb34a987b8cd8564a97/images/5-9.png -------------------------------------------------------------------------------- /images/6-1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bookcrush/httpPerfectGuide/f038fb52319dba3dfb2b9eb34a987b8cd8564a97/images/6-1.png -------------------------------------------------------------------------------- /images/6-10.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bookcrush/httpPerfectGuide/f038fb52319dba3dfb2b9eb34a987b8cd8564a97/images/6-10.png -------------------------------------------------------------------------------- /images/6-11.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bookcrush/httpPerfectGuide/f038fb52319dba3dfb2b9eb34a987b8cd8564a97/images/6-11.png -------------------------------------------------------------------------------- /images/6-12.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bookcrush/httpPerfectGuide/f038fb52319dba3dfb2b9eb34a987b8cd8564a97/images/6-12.png -------------------------------------------------------------------------------- /images/6-13.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bookcrush/httpPerfectGuide/f038fb52319dba3dfb2b9eb34a987b8cd8564a97/images/6-13.png -------------------------------------------------------------------------------- /images/6-14.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bookcrush/httpPerfectGuide/f038fb52319dba3dfb2b9eb34a987b8cd8564a97/images/6-14.png -------------------------------------------------------------------------------- /images/6-15.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bookcrush/httpPerfectGuide/f038fb52319dba3dfb2b9eb34a987b8cd8564a97/images/6-15.png -------------------------------------------------------------------------------- /images/6-16.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bookcrush/httpPerfectGuide/f038fb52319dba3dfb2b9eb34a987b8cd8564a97/images/6-16.png -------------------------------------------------------------------------------- /images/6-17.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bookcrush/httpPerfectGuide/f038fb52319dba3dfb2b9eb34a987b8cd8564a97/images/6-17.png -------------------------------------------------------------------------------- /images/6-18.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bookcrush/httpPerfectGuide/f038fb52319dba3dfb2b9eb34a987b8cd8564a97/images/6-18.png -------------------------------------------------------------------------------- /images/6-19.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bookcrush/httpPerfectGuide/f038fb52319dba3dfb2b9eb34a987b8cd8564a97/images/6-19.png -------------------------------------------------------------------------------- /images/6-2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bookcrush/httpPerfectGuide/f038fb52319dba3dfb2b9eb34a987b8cd8564a97/images/6-2.png -------------------------------------------------------------------------------- /images/6-20.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bookcrush/httpPerfectGuide/f038fb52319dba3dfb2b9eb34a987b8cd8564a97/images/6-20.png -------------------------------------------------------------------------------- /images/6-21.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bookcrush/httpPerfectGuide/f038fb52319dba3dfb2b9eb34a987b8cd8564a97/images/6-21.png -------------------------------------------------------------------------------- /images/6-22.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bookcrush/httpPerfectGuide/f038fb52319dba3dfb2b9eb34a987b8cd8564a97/images/6-22.png -------------------------------------------------------------------------------- /images/6-23.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bookcrush/httpPerfectGuide/f038fb52319dba3dfb2b9eb34a987b8cd8564a97/images/6-23.png -------------------------------------------------------------------------------- /images/6-24.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bookcrush/httpPerfectGuide/f038fb52319dba3dfb2b9eb34a987b8cd8564a97/images/6-24.png -------------------------------------------------------------------------------- /images/6-25.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bookcrush/httpPerfectGuide/f038fb52319dba3dfb2b9eb34a987b8cd8564a97/images/6-25.png -------------------------------------------------------------------------------- /images/6-26.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bookcrush/httpPerfectGuide/f038fb52319dba3dfb2b9eb34a987b8cd8564a97/images/6-26.png -------------------------------------------------------------------------------- /images/6-3.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bookcrush/httpPerfectGuide/f038fb52319dba3dfb2b9eb34a987b8cd8564a97/images/6-3.png -------------------------------------------------------------------------------- /images/6-4.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bookcrush/httpPerfectGuide/f038fb52319dba3dfb2b9eb34a987b8cd8564a97/images/6-4.png -------------------------------------------------------------------------------- /images/6-5.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bookcrush/httpPerfectGuide/f038fb52319dba3dfb2b9eb34a987b8cd8564a97/images/6-5.png -------------------------------------------------------------------------------- /images/6-6.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bookcrush/httpPerfectGuide/f038fb52319dba3dfb2b9eb34a987b8cd8564a97/images/6-6.png -------------------------------------------------------------------------------- /images/6-7.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bookcrush/httpPerfectGuide/f038fb52319dba3dfb2b9eb34a987b8cd8564a97/images/6-7.png -------------------------------------------------------------------------------- /images/6-8.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bookcrush/httpPerfectGuide/f038fb52319dba3dfb2b9eb34a987b8cd8564a97/images/6-8.png -------------------------------------------------------------------------------- /images/6-9.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bookcrush/httpPerfectGuide/f038fb52319dba3dfb2b9eb34a987b8cd8564a97/images/6-9.png --------------------------------------------------------------------------------