
![http 완벽 가이드 표지](https://user-images.githubusercontent.com/67692759/211473613-0531c7c1-578d-4c68-993a-138e17e7ce3e.png)

HTTP 완벽 가이드의 `2. HTTP 아키텍처`를 읽고 정리한 내용입니다.

---

# 7장: 캐시

웹 캐시는 자주 쓰이는 문서의 사본을 자동으로 보관하는 HTTP 장치다. 웹 요청이 캐시에 도착했을 때, 캐시된 로컬 사본이 존재한다면, 그 문서는 원 서버가 아니라 그 캐시로부터 제공된다. 캐시는 다음과 같은 혜택을 준다

- 불필요한 데이터 전송을 줄여서, 네트워크 요금으로 인한 비용을 줄여준다
- 네트워크 병목을 줄여준다. 대역폭을 늘리지 않고도 페이지를 빨리 불러올 수 있게 해준다
- 원 서버에 대한 요청을 줄여준다. 서버는 부하를 줄일 수 있으며 더 빨리 응답할 수 있게 된다
- 페이지를 먼 곳에서 불러올수록 시간이 많이 걸리는데, 캐시는 거리로 인한 지연을 줄여준다

## 적중과 부적중

캐시에 요청이 도착했을 때, 만약 대응하는 사본이 있다면 이를 사용해 요청이 처리된다. 이를 `캐시 적중(cache hit)`이라고 부른다. 대응하는 사본이 없다면 원 서버로 요청이 전달된다. 이를 `캐시 부적중(cache miss)`라고 부른다.

### 재검사(revalidation)

사본이 최신인지 서버를 통해 점검해야 하는데 이러한 신선도 검사를 HTTP 재검사라고 부른다. 캐시는 원한다면 스스로 사본을 재검사 할 수 있다. 대부분의 캐시는 클라이언트가 사본을 요청하였으며 그 사본이 검사를 할 필요가 있을 정도로 충분히 오래된 경우에만 재검사를 한다.

콘텐츠가 변경되지 않았다면, 서버는 `304 Not Modified` 응답을 보낸다. 캐시는 사본이 신선하다고 임시로 다시 표시한 뒤 그 사본을 클라이언트에 제공한다. 이를 재검사 적중 혹은 느린 정중이라고 부른다. 이는 원 서버와 검사가 필요하기 때문에 순수 캐시 적중보다는 느리고, 서버로부터 객체 데이터를 받아올 필요가 없기 때문에 캐시 부적중보다는 빠르다.

HTTP는 캐시된 객체를 재확인하기 위해 If-Modified-Since 헤더를 자주 사용한다. 이는 캐시된 시간 이후에 변경된 경우에만 사본을 보내달라는 의미이다.

- 재검사 부적중: 서버 객체가 캐시된 사본과 다르다면, 서버는 컨텐츠 전체와 함께 HTTP 200 OK 응답을 클라이언트에게 보낸다.
- 객체 삭제: 만약 서버 객체가 삭제되었다면, 서버는 404 Not Found 응답을 돌려보내며, 캐시는 사본을 삭제한다.

### 적중률

캐시가 요청을 처리하는 비율을 캐시 적중률 또는 문서 적중률이라고 부른다. 적중률 40%면 웹 캐시로 괜찮은 편이다.

바이트 단위 적중률은 캐시를 통해 제공된 모든 바이트의 비율을 표현한다.

문서 적중률을 개선하면 전체 대기 시간이 줄어들고, 바이트 단위 적중률의 개선은 대역폭 절약을 최적화한다.

클라이언트가 응답이 캐시에서 왔는지 알아내는 방법은 Date 헤더를 이용하는 것이다. 응답의 생성일이 현재 시각보다 오래되었다면 클라이언트는 응답이 캐시된 것임을 알 수 있다. 다른 방법은 응답이 얼마나 오래되었는지를 말해주는 Age 헤더를 사용하는 것이다.

## 캐시 토폴로지

한 명에게만 할당된 캐시를 개인 전용 캐시(private cache), 공유된 캐시를 공용 캐시(public cache)라고 부른다. 웹 브라우저는 개인 전용 캐시를 내장하고 있다. 공용 캐시는 프락시 캐시로, 로컬 캐시에서 문서를 제공하거나, 사용자 입장에서 서버에 접근한다. 공용 캐시는 불필요한 트래픽을 줄일 수 있는 기회가 많다.

## 캐시 처리 단계

1. 요청 받기
2. 파싱: 메시지를 파싱하여 URL과 헤더를 추출한다
3. 검색: 로컬 복사본이 있는지 검사하고, 사본이 없다면 사본을 받아와 로컬에 저장한다
4. 신선도 검사: 사본이 충분히 신선한지 검사하고, 신선하지 않다면 변경사항이 있는지 서버에게 물어본다
5. 응답 생성: 새로운 헤더와 캐시된 본문으로 응답 메시지를 만든다
6. 발송: 네트워크를 통해 응답을 클라이언트에게 돌려준다
7. 로깅: 선택적으로 캐시는 트랜잭션에 대해 서술한 로그를 남긴다

## 사본을 신선하게 유지하기

HTTP는 `Cache-Control`과 `Expries`라는 특별한 헤더들을 이용해 원 서버가 각 문서에 유효기간을 붙일 수 있게 해준다.

캐시는 필요하다면 서버와의 접촉 없이 사본을 제공할 수 있다. 캐시 문서가 만료되면, 캐시는 반드시 서버와 문서에 변경된 것이 있는지 검사해야 하며, 만약 변경이 있다면 신선한 사본을 새 유효기간과 함께 얻어 와야 한다.

캐시된 문서가 만료되었다는 것은, 그 문서가 원 서버에 존재하는 것과 실제로 다르다는 것을 의미하지는 않으며, 이제 검사할 시간이 되었음을 뜻한다. 캐시는 문서의 신선도를 매 요청마다 검증할 필요 없이 문서가 만료되었을 때 한 번만 서버와 재검사하면 된다.

### 조건부 메서드와 재검사

조건부 메서드는 재검사를 효율적으로 만들어준다. `If-Modified-Since`와 `If-None-Match`가 있다.

- If-Modified-Since: <date> : 만약 문서가 주어진 날짜 이후로 수정되었다면 요청 메서드를 처리한다.만약 변경되지 않았다면 304 Not Modified 응답 메시지를 클라이언트에게 돌려준다.
- If-None-Match: <tags> : 캐시된 태그가 서버에 있는 문서의 태그와 다를 때만 요청을 처리한다.

## 캐시 제어(Cache-Control)

HTTP 문서가 만료되기 전까지 얼마나 오랫동안 캐시될 수 있게 할 것인지 서버가 설정할 수 있는 방법.

- no-store: 캐시가 그 응답의 사본을 만드는 것을 금지한다.
- no-cache: 로컬 캐시 저장소에 저장된다. 다만 먼저 서버와 재검사를 하지 않고서는 캐시에서 클라이언트로 제공될 수 없다.
- max-age: 신선하다고 간주되었던 문서가 서버로부터 온 이후로 흐른 시간을 명시한다. s-maxage는 공용 캐시에만 적용 가능하다
- expires: 실제 만료 날짜를 명시한다.
- must-revalidate: 캐시가 만료 정보를 엄격하게 따르길 원할 때. 캐시가 이 객체의 신선하지 않은 사본을 원 서버와의 최초의 검사 없이는 제공해서는 안됨을 의미한다. must-revalidate로 신선도 검사를 했을 때 원 서버를 사용할 수 없다면 504 Gateway Timeout error를 반환한다.

### 휴리스틱 만료

만약 응답이 Cache-Control: max-age헤더나 Expires 헤더 중 어느 것도 포함하지 않고 있다면, 캐시는 경험적인 방법으로(heuristic) max age를 계산한다.

---

# 8장: 통합점: 게이트웨이, 터널, 릴레이

## 게이트웨이

게이트웨이는 리소스와 애플리케이션을 연결하는 역할을 한다.게이트웨이는 요청을 받고 응답을 보내는 포털같이 동작하는데, 동적인 콘텐츠를 생성하거나 데이터베이스에 질의를 보낼 수 있다.

웹 게이트웨이는 클라이언트 측 프로토콜과 서버 측 프로토콜을 / 으로 구별하여 기술한다.

### 프로토콜 게이트웨이

![Untitled](https://github.com/prefer2/algorithm/assets/67692759/95db67cd-c2e5-4423-aa28-bd057b6db3b1)

- HTTP/\*: 서버 측 웹 게이트웨이. 게이트웨이는 응답을 HTTP 응답에 실어서 클라이언트에 전송한다
- HTTP/HTTPS: 서버 측 보안 게이트웨이. 기업 내부의 요청을 암호화하여 개인 정보와 보안을 제공. 사용자의 모든 세션을 암호화함
- HTTPS/HTTP: 클라이언트 측 보안 가속 게이트웨이. 보안 HTTPS 트래픽을 받아서 복호화하고, 웹 서버로 보낼 일반 HTTP 요청을 만든다.

### 리소스 게이트웨이

게이트웨이의 가장 일반적인 형태인 애플리케이션 서버는 목적지 서버와 게이트웨이를 한 개의 서버로 결합한다.애플리케이션 게이트웨이에서 유명했던 최초의 API는 공용 게이트웨이 인터페이스(CGI)였다. CGI가 내부에서 어떤 처리를 하는지는 사용자에게 보이지 않는다.

![Untitled 1](https://github.com/prefer2/algorithm/assets/67692759/ba3dc177-c49e-4153-8db1-28b4c31a4ed6)

## 터널

웹 터널은 HTTP 프로토콜을 지원하지 않는 애플리케이션에 HTTP 애플리케이션을 사용해 접근하는 방법을 제공한다. HTTP 커넥션 안에 HTTP가 아닌 트래픽을 얹어, 웹 트래픽만을 허락하는 방화벽이 있더라도 HTTP가 아닌 트래픽을 전송할 수 있다.

![Untitled 2](https://github.com/prefer2/algorithm/assets/67692759/2f9ca6e3-6020-4622-a282-cce9cafff3cd)

### SSL 터널링

웹 터널은 원래 방화벽을 통해서 암호화된 SSL 트래픽을 전달하려고 개발되었다. 터널을 사용하면 SSL 트래픽을 HTTP 커넥션으로 전송하여 80 포트의 HTTP만을 허용하는 방화벽을 통과시킬 수 있다.


다람쥐 책을 읽자 2. HTTP 아키텍처

HTTP 완벽 가이드(2)


![http 완벽 가이드 표지](https://user-images.githubusercontent.com/67692759/211473613-0531c7c1-578d-4c68-993a-138e17e7ce3e.png)

HTTP 완벽 가이드의 `1. HTTP: 웹의 기초`를 읽고 정리한 내용입니다.

---

# 2장: URL과 리소스

URL은 브라우저가 정보를 찾는데 필요한 리소스의 위치를 가리키며, URL을 이용해 사람과 애플리케이션이 인터넷사의 수섭억 개의 리소스를 찾고 사용하며 공유할 수 있다.

`URI`는 `URL`과 `URN`으로 이루어져있다. URN은 현재 리소스가 어디에 존재하든 상관없이 그 이름만으로 리소스를 식별하고, URL은 리소스가 어디 있는지 설명해서 리소스를 식별한다. URN은 유일무이한 이름 역할을 한다. 즉 리소스를 다른 곳으로 옮기더라도 동일한 URN으로 사용이 가능하다. 하지만 URN은 아직 채택되지 않아 접할 기회가 많지 않다.

## URL 구조

![Untitled](https://user-images.githubusercontent.com/67692759/211474642-3449b10f-1257-45f6-86c8-fcfb7ec6bb2b.png)

- 스킴(프로토콜): 리소스에 어떻게 접근하는지 알려준다.
- 도메인: 서버의 위치. 웹 클라이언트의 리소스가 어디에 호스팅 되어 있는지 알려준다.
- 포트: 리소스를 호스팅하는 서버가 열어놓은 포트번호. 많은 스킴이 기본 포트를 가지고 있다.
- 리소스 경로: 요청받은 리소스가 무엇인지 알려준다.
- 파라미터: 애플리케이션이 서버에 정확한 요청을 하기 위해 필요한 입력 파라미터들을 받는다. 이름/값 쌍의 리스트로 이루어진다.
  - 질의 문자열(Query String): 요청받을 리소스 형식의 범위를 좁히기 위해서 사용할 수 있다. 대부분 ‘&’로 나뉜 ‘이름=값’ 쌍 형식의 질의 문자열을 사용한다.
- 프래그먼트(앵커): 리소스의 특정 부분을 가리킬 수 있도록 프래그먼트 컴포넌트를 제공한다.

## 안전하지 않은 문자

이스케이프라는 기능으로 안전하지 않은 문자를 안전한 문자로 인코딩 할 수 있다. 이스케이프 문자열은 US-ASCII에서 사용이 금지된 문자들로, 특정 문자나 데이터를 인코딩할 수 있게 하여 이동성과 완성도를 높인다.

안전하지 않은 문자를 퍼센티지 기호(%)로 시작해, ASCII 코드로 표현되는 두 개의 16진수 숫자로 이루어진 이스케이프 문자로 바꾼다.

입력받은 URL에서 어떤 문자를 인코딩해야 하는지 결정하는 데는 브라우저와 같이 사용자로부터 최초로 URL을 입력받는 애플리케이션에서 하는 것이 가장 적절하다

---

# 3장: HTTP 메시지

## 메시지의 흐름

HTTP는 인바운드와 아웃바운드라는 용어를 트랜잭션 방향을 표현하기 위해 사용한다. 메시지가 서버로 향하는 것은 `인바운드`이고, 모든 처리가 끝난 뒤에 사용자에게 돌아오는 것은 `아웃바운드`이다.

모든 메시지는 다운스트림으로 흐른다. 메시지의 발송자는 수신자의 업스트림이다.

## 메시지의 구조

HTTP 메시지는 `시작줄`, `헤더`, `본문` 세 부분으로 이루어진다. 시작줄과 헤더는 줄 단위로 분리된 아스키 문자열이며, 본문은 데이터 덩어리이다.

![Untitled](https://user-images.githubusercontent.com/67692759/211474771-67cec665-fada-408b-93f0-e75bbb54605c.png)

### 시작줄

요청 메시지의 시작줄은 무엇을 해야하는지 말해주고, 응답 메시지의 시작줄은 무슨 일이 있었는지 말해준다.

요청줄에는 메서드와 그 동작에 대한 대상을 지칭하는 URL이 있다. 또한 클라이언트가 어떤 HTTP 버전으로 말하고 있는지 서버에게 알려주는 HTTP 버전도 포함한다.

응답줄에는 응답 메시지에서 쓰인 HTTP 버전, 숫자로 된 상태고드, 수행 상태에 대해 설명해주는 텍스트로 된 사유 구절이 들어있다.

### 헤더

헤더 필드는 요청과 응답 메시지에 추가 정보를 더한다. Content-length, ContentType 등이 들어간다.

### 엔티티 본문

HTTP 메시지의 화물이다. 이것을 수송하도록 HTTP가 설계된 것이다. 여러 종류의 데이터를 실어 나를 수 있다.

더 자세한 내용은 아래 링크에서 확인 가능하다

[https://developer.mozilla.org/ko/docs/Web/HTTP/Messages](https://developer.mozilla.org/ko/docs/Web/HTTP/Messages)

[https://developer.mozilla.org/ko/docs/Web/HTTP/Methods](https://developer.mozilla.org/ko/docs/Web/HTTP/Methods)

[https://developer.mozilla.org/ko/docs/Web/HTTP/Status](https://developer.mozilla.org/ko/docs/Web/HTTP/Status)

[https://developer.mozilla.org/ko/docs/Web/HTTP/Headers](https://developer.mozilla.org/ko/docs/Web/HTTP/Headers)

---

# 4장: 커넥션 관리

## TCP 커넥션

TCP 커넥션은 인터넷을 안정적으로 연결해준다. TCP는 HTTP에게 신뢰할 만한 통신 방식을 제공한다. TCP 커넥션의 한쪽에 있는 바이트들은 반대쪽으로 순서에 맞게 정확하게 전달된다.

![Untitled](https://user-images.githubusercontent.com/67692759/211474818-62f09f4f-67f4-41f4-bd78-fb09a5d7e3da.png)

TCP는 IP 패킷(IP 데이터그램)이라고 불리는 작은 조각을 통해 데이터를 전송한다. TCP는 세그먼트라는 단위로 데이터 스트림을 잘게 나누고, 세그먼트를 IP 패킷이라고 불리는 봉투에 담아서 인터넷을 통해 데이터를 전달한다.

컴퓨터는 TCP 커넥션을 여러개 가지고 있다. TCP는 포트 번호를 통해서 이런 여러 개의 커넥션을 유지한다. TCP 커넥션은 발신지 IP 주소, 발신지 포트, 수신지 IP 주소, 수신지 포트 네 가지 값으로 식별한다. 이 네 가지 커넥션 구성요소를 모두 똑같이 가리키고 있는 커넥션은 있을 수 없다.

### TCP 소켓프로그래밍

운영체제에서TCP 커넥션의 생성과 관련된 여러 기능을 제공한다. 소켓 API를 사용하면 종단 데이터 구조를 생성하고, 원격 서버의 TCP 종단에 그 종단 데이터 구조를 연결하여 데이터 스트림을 읽고 쓸 수 있다. TCP API는, 기본적인 네트워크 프로토콜의 핸드셰이킹, TCP 데이터 스트림과 IP 패킷 간의 분할 및 재조립에 대한 모든 세부사항을 숨긴다.

## TCP의 성능에 대한 고려

HTTP는 TCP 바로 위에 있는 계층이기 때문에 HTTP 트랙잭션의 성능은 그 아래 계층인 TCP 성능에 영향을 받는다. 클라이언트 서버가 너무 많은 데이터를 내려받거나 복잡하고 동적인 자원들을 실행하지 않는 한, 대부분의 HTTP 지연은 TCP 네트워크 지연 때문에 발생한다.

## 지속 커넥션

HTTP/1.1을 지원하는 기기는 처리가 완료된 후에도 TCP 커넥션을 유지하여 앞으로 있을 HTTP 요청에 재사용할 수 있다. 오늘날 많은 웹 애플리케이션은 적은 수의 병렬 커넥션만을 맺고 그것을 유지한다.

### keep-alive

keep-alive 커넥션을 구현한 클라이언트는 커넥션을 유지하기 위해서 요청에 Connection: Keep-Alive 헤더를 포함시킨다. 이 요청을 받은 서버는 그 다음 요청도 이 커넥션을 통해 받고자 한다면, 응답 메시지에 같은 헤더를 포함시켜 응답한다. 다만 이 요청을 받았다고 해서 무조건 그것을 따를 필요는 없다.

### HTTP/1.1의 지속 커넥션

HTTP/1.1의 지속 커넥션은 기본으로 활성화되어 있다. 응답에 Connection: close 헤더가 없으면 응답 후에도 커넥션을 계속 유지하는 것으로 추정한다.


다람쥐 책을 읽자 1. HTTP: 웹의 기초

Tags - http (2)

HTTP 완벽 가이드(2)

HTTP 완벽 가이드(1)