[1일차] 21p.

일단 TCP 커넥션이 맺어지면, 클라이언트와 서버 컴퓨터 간에 교환되는 메시지가 없어지거나, 손상되거나, 순서가 뒤바뀌어 수신되는 일은 결코 없다. 네트워크 개념상, HTTP 프로토콜은 TCP 위의 계층이다. HTTP는 자신의 메시지 데이터를 전송하기 위해 TCP를 사용한다. 이와 유사하게 TCP는 IP 위의 계층이다.

[2일차] 23p.

애플리케이션은 정해진 방식대로 구현해야 한다. 어떤 애플리케이션에 어떤 URL을 보내든지, 그 전에 클라이언트 애플리케이션에서 안전하지 않거나 제한된 문자 를 변환하는 것이 좋다. 안전하지 않은 모든 문자를 인코딩하기만 하면, 다른 애플리케이션으로부터 특별한 의미를 가지는 문자를 받았을 때 혼동할 걱정 없이, 애플리케이션 간에 공유할 수 있는 URL의 원형을 유지할 수 있다.

[3일차] 34p.

HTTP 메시지는 단순한, 데이터의 구조화된 블록이다. 각 메시지는 클라이언트로부터의 요청이나 서버로부터의 응답 중 하나를 포함한다. 메시지는 시작줄, 헤더 블록, 본문 이렇게 세 부분으로 이루어진다. 시작줄은 이것이 어떤 메시지인지 서술하며, 헤더 블록은 속성을, 본문은 데이터를 담고 있다. 본문은 아예 없을 수도 있다. 시작과 헤더는 그냥 줄 단위로 분리된 아스키 문자열이다. 각 줄은 캐리지 리턴 (ASCII 13)과 개행 문자(ASCII 10)로 구성된 두 글자의 줄바꿈 문자열으로 끝난다. 이 줄바꿈 문자열은 'CRLF'라고 쓴다. HTTP 명세에 따른다면 줄바꿈 문자열은 CRLF이지만 견고한 애플리케이션이라면 그냥 개행 문자도 받아들일 수 있어야 한다는 점을 언급할 필요가 있을 듯하다. 오래되거나 잘못 만들어진 HTTP 애플리케이션들 중에서는 캐리지 리턴과 개행 문자 모두를 항상 전송하지는 않는 것들도 있다. 엔터티 본문이나 메시지 본문(혹은 그냥 '본문')은 단순히 선택적인 데이터 덩어리이다. 시작줄이나 헤더와는 달리, 본문은 텍스트나 이진 데이터를 포함할 수도 있고 그냥 비어있을 수도 있다.

[4일차] 23p.

전 세계 모든 HTTP 통신은, 지구상의 컴퓨터와 네트워크 장비에서 널리 쓰이고 있는 패킷 교환 네트워크 프로토콜들의 계층화된 집합인 TCP/IP를 통해 이루어진다. 세계 어디서든 클라이언트 애플리케이션은 서버 애플리케이션으로 TCP/IP 커넥션을 맺을 수 있다. 일단 커넥션이 맺어지면 클라이언트와 서버 컴퓨터 간에 주고 받는 메시지들은 손실 혹은 손상되거나 순서가 바뀌지 않고 안전하게 전달된다.

[5일차] 20p.

한 번 혹은 여러 번 실행됐는지에 상관없이 같은 결과를 반환한다면 그 트랜잭션은 멱등(idempotent)하다고 한다. GET, HEAD, PUT, DELETE, TRACE 그리고 OPTIONS 메서드들은 멱등하다고 이해하면 된다. 클라이언트는 POST와 같이 멱등인 아닌 요청은 파이프라인을 통해 요청하면 안 된다. 그렇지 않으면 전송 커넥션이 예상치 못하게 끊어져 버렸을 때, 알 수 없는 결과를 초래할 수 있다. 비멱등인 요청을 다시 보내야 한다면, 이전 요청에 대한 응답을 받을 때까지 기다려야 한다. 비멱등인 메서드나 순서에 대해 에이전트가 요청을 다시 보낼 수 있도록 기능을 제공한다 하더라도, 자동으로 재시도하면 안 된다. 예를 들어 대부분 브라우저는 캐시된 POST 요청 페이지를 다시 로드하려고 할 때, 요청을 다시 보내기를 원하는 지 묻는 대화상자를 보여준다.

[6일차] 21p.

웹 서버는 여러 종류의 리소스 매핑을 지원한다. 하지만 리소스 매핑의 가장 단순한 형태는 요청 URI를 웹 서버의 파일 시스템 안에 있는 파일 이름으로 사용하는 것이다. 일반적으로 웹 서버 파일 시스템의 특별한 폴더를 웹 콘텐츠를 위해 예약해 둔다. 이 폴더는 문서 루트 혹은 docroot로 불린다. 웹 서버는 요청 메시지에서 URI를 가져와서 문서 루트 뒤에 붙인다.

[7일차] 23p.

문서 적중률과 바이트 단위 적중률은 둘다 캐시 성능에 대한 유용한 지표다. 문서 적중률은 얼마나 많은 웹 트랜잭션을 외부로 내보내지 않았는지 보여준다. 트랜잭션은 고정된 소요 시간을 포함하게 되는데, 이것은 종종 길 수도 있기 때문에(예를 들어 서버로의 TCP 커넥션을 맺는 경우), 문서 적중률을 개선하면 전체 대기시간(지연)이 줄어든다. 바이트 단위 적중률은 얼마나 많은 바이트가 인터넷으로 나가지 않았는지 보여준다. 바이트 단위 적중률의 개선은 대역폭 절약을 최적화한다.

[8일차] 23p.

Cache-Control: must-revalidate 응답 헤더는 캐시가 이 객체의 신선하지 않은 사본을 원 서버와의 최초의 재검사 없이는 제공해서는 안 됨을 의미한다. 캐시는 자유롭게 신선한 사본을 제공할 수 있다. 만약 캐시가 must-revalidate 신선도 검사를 시도했을 때 원 서버가 사용할 수 없는 상태라면, 캐시는 반드시 504 Gateway Timeout error를 반환해야 한다.

[9일차] 21p.

웹 크롤러는, 먼저 웹페이지를 한 개 가져오고, 그 다음 그 페이지가 가리키는 모든 웹페이지를 가져오고, 다시 그 페이지들이 가리키는 모든 웹페이지들을 가져오는, 이러한 일을 재귀적으로 반복하는 방식으로 웹을 순회하는 로봇이다. 웹 링크를 재귀적으로 따라가는 로봇을 크롤러 혹은 스파이더라고 부르는데, HTML 하이퍼링크 들로 만들어진 웹을 따라 기어다니기(craw) 때문이다. 인터넷 검색엔진은 웹을 돌아다니면서 그들이 만나는 모든 문서를 끌어오기 위해 크롤러를 사용한다. 이 문서들은 나중에 처리되어 검색 가능한 데이터베이스로 만들어지는데, 이는 사용자들이 특정 단어를 포함한 문서를 찾을 수 있게 해준다.

[10일차] 22p.

로봇 커뮤니티는 로봇에 의한 웹 사이트 접근이 유발할 수 있는 문제를 알고 있었다. 1994년, 로봇이 그들에게 맞지 않는 장소에 들어오지 않도록 하고 웹 마스터에게 로봇의 동작을 더 잘 제어할 수 있는 메커니즘을 제공하는 단순하고 자발적인 기법이 제안되었다. 이 표준은 "Robots Exclusion Standard"라고 이름 지어졌지만, 로봇의 접근을 제어하는 정보를 저장하는 파일의 이름을 따서 종종 그냥 robots.txt 라고 불린다. robots.txt의 아이디어는 단순하다. 어떤 웹서버는 서버의 문서 루트에 robots.txt라고 이름 붙은 선택적인 파일을 제공할 수 있다. 이 파일은 어떤 로봇이 서버의 어떤 부분에 접근할 수 있는지에 대한 정보가 담겨있다. 만약 어떤 로봇이 이 자발적인 표준에 따른다면, 그것은 웹 사이트의 어떤 다른 리소스에 접근하기 전에 우선 그 사이트의 robots.txt를 요청할 것이다.

[11일차] 22p.

오늘날 검색엔진들은 그들이 갖고 있는 전 세계의 웹페이지들에 대해 '풀 텍스트 색인(full-text indexes)'이라고 하는 복잡한 로컬 데이터베이스를 생성한다. 이 색인은 웹의 모든 문서에 대한 일종의 카드 카탈로그처럼 동작한다. 검색엔진 크롤러들은 웹페이지들을 수집하여 집으로 가져와서, 이 풀 텍스트 색인에 추가한다. 동시에, 검색엔진 사용자들은 핫봇(http://www.hotbot.com)이나 구글(http://www.google.com)과 같은 웹 검색 게이트웨이를 통해 풀 텍스트 색인 에 대한 질의를 보낸다. 크롤링을 한 번 하는데 걸리는 시간이 상당한 데 비해 웹페이지들은 매 순간 변화하기 때문에, 풀 텍스트 색인은 기껏 해봐야 웹의 특정 순간에 대한 스냅숏에 불과하다.

[12일차] 20p.

쿠키는 크게 세션 쿠키(session Cookie)와 지속 쿠키(persistent cokite) 두 가지 타입으로 나눌 수 있다. 세션 쿠키는 사용자가 사이트를 탐색할 때, 관련한 설정과 선호사항들을 저장하는 임시 쿠키다. 세션 쿠키는 사용자가 브라우저를 닫으면 삭제된다. 지속 쿠키는 삭제되지 않고 더 길게 유지될 수 있다. 지속 쿠키는 디스크에 저장되어, 브라우저를 닫거나 컴퓨터를 재시작하더라도 남아있다. 지속 쿠키는 사용자가 주기적으로 방문하는 사이트에 대한 설정 정보나 로그인 이름을 유지하려 고 사용한다. 세션 쿠키와 지속 쿠키의 다른 점은 파기되는 시점뿐이다. 뒤에서 다룰 것이지만, 쿠키는 Discard 파라미터가 설정되어 있거나, 파기되기까지 남은 시간을 가리 키는 Expires 혹은 Max-Age 파라미터가 없으면 세션 쿠키가 된다.

[13일차] 24p.

Base-64 인코딩은 바이너리, 텍스트, 국제 문자 데이터(어떤 시스템에서는 문제를 일으킬 수 있는) 문자열 받아서 전송할 수 있게, 그 문자열을 전송 가능한 문자인 알파벳으로 변환하기 위해 발명됐다. 전송 중에 원본 문자열이 변질될 걱정 없이 원격에서 디코딩할 수 있다. base-64 인코딩은 국제 문자나 HTTP 헤더에서 사용할 수 없는 문자{큰따옴표, 콜론, 캐리지 리턴)를 포함한 사용자 이름이나 비밀번호를 보내야 할 때 유용할 수 있다. 또한, base-64는 어렵지 않게 사용자 이름과 비밀번호 문자를 섞을 수 있기 때문에, 서버나 네트워크를 관리하면서 뜻하지 않게 사용자 이름과 비밀번호가 노출되는 문제를 예방하는 데 도움이 된다.

[14일차] 21p.

한 쌍의 호스트가 하나의 인코딩/디코딩 키를 사용하는 대신, 공개키 암호 방식은 두 개의 비대칭 키를 사용한다. 하나는 호스트의 메시지를 인코딩하기 위한 것이며, 다른 하나는 그 호스트의 메시지를 디코딩하기 위한 것이다. 인코딩 키는 모두를 위해 공개되어 있다(그래서 공개키 암호 방식이라는 이름이 붙었다). 하지만 호스트만이 개인 디코딩 키를 알고 있다.

[15일차] 22p.

HTTPS는 HTTP의 가장 유명한 보안 버전이다. 널리 구현되었으며 주류 상용 브라우저와 서버에 구현되어 있다. HTTPS는 HTTP 프로토콜에 대칭, 비대칭 인증서 기반 암호 기법의 강력한 집합을 결합한 것이다. 이 기법들의 집합은 무정부 상태의 분권화된 글로벌 인터넷 환경에서도 HTTPS를 매우 안전한 동시에 매우 유연하고 관리하기 쉽게 만들어 준다. HTTPS는 인터넷 애플리케이션의 성장을 가속한 동시에 웹 기반 전자상거래의 고속 성장을 이끄는 주력이다. HTTPS는 또한 분산된 웹 애플리케이션의 광역 보안 관리에 있어 대단히 중요하다.

[16일차] 21p.

콘텐츠 인코딩 과정은 다음과 같다.

1. 웹 서버가 원본 Content-Type과 Content-Length 헤더를 수반한 원본 응답 메시지를 생성한다.
2. 콘텐츠 인코딩 서버(아마 원 서버이거나 다운스트림 프락시일 것이다)가 인코딩된 메시지를 생성한다. 인코딩된 메시지는 Content-Type은 같지만(본문이 압축되었거나 했다면) Content-Length는 다르다. 콘텐츠 인코딩 서버는 Content-Encoding 헤더를 인코딩된 메시지에 추가하여, 수신 즉 애플리케이션이 그것을 디코딩할 수 있도록 한다.
3. 수신 측 프로그램은 인코딩된 메시지를 받아서 디코딩하고 원본을 얻는다.

[17일차] 23p.

If-Modified-Since 상태 헤더는 문서 인스턴스의 마지막 수정된 날짜를 검사하므로, 우리는 마지막 수정된 날짜를 검사기라고 말할 수 있다. If-None-Match 조건부 헤더는 문서의 ETag 값을 평가한다. ETag는 특별한 키워드이거나 엔터티와 관련된 버전 식별 태그이다. Last-Modified와 ETag는 HTTP에 의해 사용되는 두 개의 주요한 검사기다.