원서는 2002년, 번역본은 2014년에 발행되어, 현재와는 상황이 많이 다를 것이라 생각합니다.
하지만 웹이 어떻게 동작하는지 기본적인 개념은 확실히 알 수 있을거라 생각하여 읽기 시작합니다.
알고 있는 내용은 한 번 더 상기시킨다 생각하고, 몰랐던 내용들은 확실히 알아간다는 생각으로 정리하고 있습니다.

공부 중 (11/22 ~ 임시중단)
정리하며 읽기에는 모르는 내용이 너무 많아, 바로 정리를 하기 보단 필요한 부분을 골라 읽거나, 눈에 익을 때 까지 반복하여 읽고 이해가 된 후에 정리를 하는 것이 낫다 판단하여 정리는 잠시 중단합니다.

1부. HTTP: 웹의 기초

02장. URL과 리소스

• URL (Uniform Resource Locator)
  • 인터넷의 리소스를 가리키는 표준 이름이다.
  • 구조
    <스킴>://<사용자 이름>:<비밀번호>@<호스트>:<포트>/<경로>;<파라미터>?<질의>#<프래그먼트>
    1. 스킴 : 리소스를 가져올 때 사용하는 프로토콜 (예: http, ftp, ...)
    2. 사용자 이름 : 리소스 접근 시 필요한 사용자 이름
    3. 비밀번호 : 사용자의 비밀번호
    4. 호스트 : 호스트명 혹은 IP 주소
    5. 포트 : 호스팅 서버가 열어 둔 포트 번호
    6. 경로 : 가져오려는 리소스가 서버 내에 위치한 곳
    7. 파라미터 : 서버에 정확한 요청을 하기 위해 필요한 파라미터
    8. 질의 : 애플리케이션에 파라미터를 전달하는데 사용
    9. 프래그먼트 : 리소스 중 일부분을 가리킨다. 클라이언트에서만 사용
  • 단축 URL
    • 절대 URL : 리소스 접근하는데 필요한 모든 정보를 가지고 있음
      (예: https://www.naver.com/index.html)
    • 상대 URL : URL을 짧게 표기하는 방식. base URL을 기준으로 한다.
      (예: ./index.html)
  • URL 확장
    • 호스트명 확장 : 호스트명을 일부만 입력해도 전체로 확장
      (예: yahoo만 입력해도 앞뒤로 www.과 .com을 자동으로 붙여줌.)
    • 히스토리 확장 : URL의 일부만 입력해도 이전 방문 기록에 따라 전체 URL을 보여줌
  • 안전하지 않은 문자
    • URL은 어떤 IP를 통해서든 안전하게 전송되도록 설계하는 것이 중요했기에 작고 안전한 알파벳 문자만 포함하도록 하였다.
      하지만 알파벳 외의 문자를 포함할 때가 있기에, 이스케이프 라는 기능을 추가하여 안전하지 않은 문자를 안전한 문자로 인코딩 하게 하여 이동성과 완성도를 높였다.
    • 이스케이프 문자열 : US-ASCII에서 사용이 금지된 문자들로, 특정 문자나 데이터를 인코딩할 수 있게 함
      • 인코딩 체계 : % + ASCII코드 (두 개의 16진수 숫자)

03장. HTTP 메시지

• HTTP 메시지
  • HTTP 애플리케이션 간에 주고받은 데이터의 블록
  • 인바운드 : 서버로 이동/ 아웃바운드 : 클라이언트로 이동
  • 모든 메시지는 다운스트림으로 흐른다.
  • 시작줄, 헤더, 본문의 세 부분으로 이루어져있다.
    • 시작줄과 헤더는 줄 단위로 분리된 아스키 문자열이며, 각 줄은 CRLF로 끝난다.
    • 본문은 optional한 데이터이다.
• 메시지 문법
  • 요청 메시지

    <메서드> <요청URL> <버전>
     <헤더>
     
     <엔티티본문>

  • 응답 메시지

    <버전> <상태코드> <사유구절>
     <헤더>
     
     <엔티티본문>

• 시작줄
  • 메서드 : 서버에게 무엇을 해야하는지 말해준다.
    • GET, HEAD, PUT, POST, TRACE, OPTIONS, DELETE ...
  • 상태코드 : 클라이언트에게 무엇이 일어났는지 말해준다.
    • 100~ : 정보성
    • 200~ : 성공
    • 300~ : 리다이렉션
    • 400~ : 클라이언트 에러
    • 500~ : 서버 에러
  • 사유구절 : 상태코드에 대해 사람이 이해하도록 보여주는 메시지.
  • 버전 : HTTP의 버전 정보. HTTP/x.y 형식으로
• 헤더
  • 일반 헤더 : 요청/응답 모두 나타나는 일반적인 헤더
  • 요청 헤더 : 요청 정보 제공
  • 응답 헤더 : 응답 정보 제공
  • Entity 헤더 : 리소스 정보 제공
  • 확장 헤더 : 정의되지 않은 헤더
• 본문
  • 실질적인 데이터. 비어있을 수 있다.

04장. 커넥션 관리

• TCP
  • TCP는 IP패킷을 통해 데이터를 전송한다.
  • 데이터 스트림을 세그먼트라는 단위로 잘게 나누고, IP 패킷에 담아 인터넷을 통해 전달한다.
    (IP 패킷 ⊃ TCP 세그먼트 ⊃ TCP 데이터 스트림)
  • TCP 커넥션은 다음 네가지 값으로 식별하며, 유일한 커넥션을 생성한다.
    <발신지 IP 주소, 발신지 포트, 수신지 IP 주소, 수신지 포트>
• TCP 성능에 관한 고려
  • TCP 커넥션 핸드셰이크 지연 : 새로운 TCP 커넥션이 생성될 때 발생하는 지연
  • 확인응답 지연 : 확인응답 알고리즘(TCP가 같은 방향으로 송출되는 데이터 패킷에 확인응답을 편승시키는데, 그 경우를 늘리기 위해 사용되는 알고리즘)으로 인한 지연
  • TCP 느린 시작 : TCP 커넥션은 급작스러운 부하를 방지하기 위해 처음에는 커넥션 속도를 제한하고, 점점 그 제한을 높여가며 자체적으로 튜닝한다. 이로 인하여 새로운 커넥션에서 일어나는 지연
  • 네이글 알고리즘과 TCP_NODELAY : 네이글 알고리즘(세그먼트가 최대 크기가 되지 않으면 전송을 하지 않는 알고리즘)으로 인한 지연. HTTP 스택에 TCP_NODELAY 파라미터 값을 설정하여 네이글 알고리즘을 비활성화 하기도 한다.
  • TIME_WAIT의 누적과 포트 고갈 : TCP 커넥션의 종단에서 커넥션을 끊으면, IP주소와 포트번호를 메모리의 작은 제어영역(control block)에 기록하는데, 보통 세그먼트 최대 생명주기의 2배 정도(약 2분) 유지가 된다. 그 시간 동안에 새로운 커넥션이 생기면 새로운 포트를 사용하는데, 보통의 경우 문제가 되지 않지만 성능 시험을 하는 상황에서 문제가 발생하기도 한다. 커넥션을 많이 맺거나 대기 상태로 있는 제어 블록이 많아지는 상황을 주의.
• HTTP 커넥션 관리
  • Connection 헤더
    • 두 개의 인접한 HTTP 애플리케이션에만 적용될 옵션을 지정하는 것.
    • 커넥션 토큰을 쉼표로 구분하여 가지고 있음
    • 다른 커넥션들에게는 전달되지 않는다. (홉별, hop-by-hop)
    • 구조
      • HTTP 헤더 필드 명 : 해당 커넥션과 관련있는 헤더 나열
      • 임시토큰 : 커넥션에 대한 비표준 옵션
      • close : 작업이 완료되면 종료됨
• HTTP 커넥션의 성능 향상
  • 병렬 커넥션
    • 여러 개의 TCP 커넥션을 통한 동시 HTTP 요청
    • 단점
      • 네트워크 대역폭이 좁을 때 대부분 시간을 데이터 전송하는데만 사용
      • 메모리 소모가 크고, 자체적인 성능 문제를 발생 시킬 수 있음
    • 따라서 적은 수의 병렬 커넥션만 허용
  • 지속 커넥션
    • 커넥션을 끊지 않고 재활용
    • 커넥션 준비 작업 시간 절약 가능, 느린시작으로 인한 지연이 없음
    • 커넥션 수를 줄여준다.
    • 병렬 커넥션과 함께 사용할 때 가장 효과적이다.
  • 파이프라인 커넥션
    • 공유 TCP 커넥션을 통한 병렬 HTTP 요청
    • 여러 개의 요청은 응답이 도착하기 전 까지 큐에 쌓이고, 요청들이 전달되면 그 뒤의 요청도 뒤 이어 전달될 수 있다.
    • POST와 같은 비멱등 요청은 에러가 발생한 경우 어떤 것들이 서버에서 처리되었는지 알 수 없기 때문에 요청을 보내서는 안된다.
      (멱등 : 몇 번 실행되었는지와 상관없이 같은 결과를 반환하는 트랜잭션. 예) GET, HEAD, PUT, DELETE, TRACE, OPTIONS)
  • 다중 커넥션
    • 요청과 응답들에 대한 중재

05장. 웹 서버

• 웹 서버
  • HTTP 및 TCP 처리를 구현한 것
  • HTTP 프로토콜을 구현하고, 웹 리소스를 관리하고, 웹 서버 관리 기능을 제공
• 운영체제
  • 컴퓨터 시스템의 하드웨어를 관리하고, TCP/IP 네트워크 지원, 파일 시스템, 연산 활동 제어를 위한 프로세스 관리를 제공
• 웹 서버가 하는 일
  1. 커넥션을 맺는다.
  2. 요청을 받는다.
  3. 요청을 처리한다.
  4. 리소스에 접근한다.
  5. 응답을 만든다.
  6. 응답을 보낸다.
  7. 트랜잭션을 로그로 남긴다.

06장. 프락시

• 웹 프락시 서버
  • 트랜잭션을 수행하는 중개인이다.
  • 서버이면서 동시에 클라이언트이다.
  • 프락시 vs 게이트웨이
    • 프락시는 같은 프로토콜을 사용하는 둘 이상의 애플리케이션을 연결
    • 게이트웨이는 다른 프로토콜을 사용하는 둘 이상의 애플리케이션을 연결
• 프락시를 사용하는 이유
  • 여러 유용한 웹 서비스를 구현하기 위해 트래픽을 감시하고 수정할 수 있다.
  • 보안, 성능을 개선하거나 비용을 절약하게 한다.
  • 예시
    • 어린이 필터 : 어린이에게 부적절한 사이트 접근 거부
    • 문서 접근 제어자 : 접근하기 전에 비밀번호 요구
    • 보안 방화벽 : 보안을 강화
    • 웹 캐시 : 문서의 로컬 사본을 관리하고, 요청이 오면 먼 원 서버까지 가지 않고 근처 캐시 서버에서 빠르게 제공
    • 대리 프락시 : 웹 서버의 성능 개선을 위해 사용
    • 콘텐츠 라우터 : 돈을 지불한 사용자 혹은 제공자에게 요청을 가까운 복제 캐시로 전달
    • 트랜스코더 : 데이터의 표현 방식을 변환해주는 것. 이미지 용량을 줄이기 위해 확장자를 변경하거나 크기를 줄이는 등의 행위
    • 익명화 프락시 : 신원을 식별할 수 있는 특성을 제거하여 개인 정보 보호, 익명성 보장

07장. 캐시

• 웹 캐시
  • 문서의 사본을 자동으로 보관하는 HTTP 장치
  • 장점
    • 불필요한 데이터 전송을 줄인다.
    • 네트워크 병목을 줄인다.
    • 원 서버에 대한 요청을 줄여 서버의 부하를 줄인다.
    • 거리로 인한 지연을 줄인다.
  • 적중
    • 캐시 적중 : 요청이 왔을 때, 캐시에 사본이 있다면 해당 사본을 돌려준다.
    • 캐시 부적중 : 사본이 없다면 원 서버로 요청을 전달한다.
    • 캐시 재검사 : 사본이 최신인지 점검하는 것.
      • 적중(느린 적중) : 사본과 서버 객체와 동일한 경우. 적중보단 느리지만 부적중보다는 빠르다.
      • 부적중 : 다른 경우 서버 객체를 받아온다.
      • 객체 삭제 : 서버 객체가 삭제된 경우
      • 주로 If-Modified-Since 헤더를 이용한다.
    • 적중과 부적중을 구별하는 방법
      • Date 헤더를 현재 시간과 비교
      • Age 헤더를 이용하여 응답이 얼마나 오래되었는지 확인
  • 적중률
    • 문서 적중률
      • 얼마나 많은 웹 트랜젝션을 외부로 보내지 않았는가.
      • 이것을 개선하면 전체 대기시간이 줄어든다.
    • 바이트 단위 적중률
      • 얼마나 많은 바이트가 인터넷으로 나가지 않았는가.
      • 이것을 개선하면 대역폭 절약을 최적화 한다.
  • 캐시 처리 단계
    1. 요청 받기 : 들어오는 데이터를 읽어들임
    2. 파싱 : 요청 메세지를 파싱
    3. 검색 : URL을 알아내어 로컬 사본이 있는지 검사
    4. 신선도 검사 : 일정 기간 동안 사본을 보유할 수 있도록 함
    5. 응답 생성 : 캐시된 서버 응답 헤더를 토대로 응답 헤더를 생성
    6. 발송 : 응답을 클라이언트에게 돌려줌
    7. 로깅 : 로그를 저장
  • 신선도 검사
    • 캐시 문서가 만료되기 전에는 사본을 제공할 수 있지만, 만료가 되면 캐시는 반드시 서버와 문서에 변경된 것이 있는지 검사해야 한다. 변경된 것이 있다면 새 사본을 가져와야 한다.

08장. 게이트웨이, 터널, 릴레이

• 게이트웨이
  • 서로 다른 프로토콜과 애플리케이션 간의 HTTP 인터페이스
  • 리소스와 애플리케이션을 연결하는 역할
  • HTTP 트래픽을 다른 프로토콜로 자동 변환하여, HTTP 클라이언트가 다른 프로토콜을 알 필요 없이 서버에 접속할 수 있게 하기도 한다.
  • 프로토콜 게이트 웨이
    • HTTP/* : 서버 측 웹 게이트웨이
      • 클라이언트로부터 HTTP 요청이 원 서버 영역으로 들어오는 시점에 요청을 외래 프로토콜로 전환한다.
      • 객체를 받는 대로 HTTP 응답에 실어 클라이언트에 전송
    • HTTP/HTTPS : 서버 측 보안 게이트웨이
      • 모든 웹 요청을 암호화하여 개인 정보 보호와 보안을 제공한다.
    • HTTPS/HTTP : 클라이언트 측 보안 가속 게이트웨이
      • 웹 서버의 앞단에 위치.
      • 보안 HTTPS 트래픽을 받아 복호화하고, 웹 서버로 보낼 일반 HTTP 요청을 만든다.
      • 게이트웨이와 원 서버간에 있는 네트워크가 안전한지 확인하고 사용해야 한다.
  • 리소스 게이트웨이
    • 웹 서버가 애플리케이션과 통신하는 수단
    • 공용 게이트웨이 인터페이스
    • 서버 확장 API
• 애플리케이션 인터페이스
  • 웹 애플리케이션이 통신하는 데 사용
• 터널
  • HTTP 커넥션을 통하여 HTTP가 아닌 트래픽을 전송하는데 사용
  • HTTP의 CONNECT 메서드를 사용하여 커넥션을 맺는다.
  • 터널을 통한 데이터는 게이트웨이에서는 볼 수 없기 때문에 게이트웨이는 패킷의 순서나 흐름에 대한 어떤 가정도 할 수 없다.
  • 터널은 원래 방화벽을 통해서 암호화된 SSL 트래픽을 전달하려고 개발되었다.
• 릴레이
  • HTTP 명세를 준수하지 않는 간단한 HTTP 프락시. 한 번에 한 개의 홉에 데이터를 전달
  • 맹목적 릴레이가 Connection 헤더를 제대로 처리하지 못하여 keep-alive 커넥션이 행에 걸릴 수 있는 등의 문제가 발생할 수 있으므로 주의해서 사용해야 한다.