[Internet] What is HTTP? (1) _ HTTP, HTTP 캐시

HTTP 정의

Hyper Text Transfer Protocol, WWW 상에서 정보를 주고받을 수 있는 프로토콜로, 클라이언트와 서버 사이에 이루어지는 요청과 응답 프로토콜입니다.

HTTP Request and HTTP Response

HTTP 동작 과정

클라이언트인 웹 브라우저가 HTTP를 통하여 서버로부터 HTML이나 Image 정보를 요청하면(Request), 서버는 요청에 응답하여 필요한 정보를 요청한 사용자에게 전달하게 됩니다.(Response)

HTTP는 파일 전송을 위한 FTP나 원격지의 호스트 컴퓨터에 접속하기 위해 사용되는 텔넷과 다르게 비연결식입니다. 그래서 클라이언트가 서버에 정보를 요청하면 서버는 응답 코드와 내용을 클라이언트에게 전송하고 클라이언트와 연결을 종료합니다. 이는 각 요청을 독립적인 트랜잭션으로 취급한다는 뜻입니다. 즉 HTTP는 무상태 프로토콜입니다.

HTTP 장점

클라이언트와 서버가 연결을 유지하지 않기 때문에 클라이언트와 서버 간의 최대 연결 수보다 훨씬 많은 요청을 처리할 수 있습니다.

HTTP 단점

서버가 응답 후 클라이언트와 연결을 끊어버려, 요청이 들어오는 클라이언트의 이전 상황을 알 수 없습니다.
위의 단점을 해결하기 위해 쿠키(Cookie)가 등장하였습니다.

HTTP 환경의 특성

connectionless
클라이언트가 요청을 한 후 응답을 받으면 그 연결을 끝어버리는 특징입니다.
HTTP는 서버와 클라이언트 간에 요청을 보내고 응답을 보냈다면 접속을 끊는 특성이 있습니다.

*** HTTP는 TCP위에서 구현되었기 때문에 네트워크 관점에서 keep-alive 옵션을 통해 연결 비용을 줄일 수 있습니다. ***

stateless
통신이 끝나면 상태를 유지하지 않는 특징입니다.
연결을 끊는 순간 클라이언트와 서버의 통신이 끝나며 상태 정보는 유지하지 않는 특성이 있습니다.

---

HTTP 캐시

HTTP 요청을 매번 서버에게 보내지 않고 한번 받았던 HTTP 응답을 재활용함으로써 성능도 향상하고 서버의 부담도 줄이는 것이 캐싱입니다.

HTTP 캐시 작동 방식

브라우저가 제공하는 모든 HTTP 요청은 먼저 브라우저 캐시로 라우팅 되어 요청을 수행하는 데 사용할 수 있는 유효한 캐시 응답이 있는지 확인합니다.
만약 일치하는 항목이 있으면 캐시에서 응답을 읽어 네트워크 대기 시간과 전송으로 인해 발생하는 데이터의 비용을 줄여줄 수 있습니다.

HTTP 캐시 종류

1.     Private Cache
Local Cache라고도 부릅니다. 이는 한 사용자에 의해서만 재활용될 수 있는 데이터만 저장되는 저장소입니다. 최초의 HTTP 요청은 서버에게 전송되어 HTTP 응답을 받아오게 되고, 이를 사설 캐시에 저장해 두고 다음번에 동일한 HTTP 요청이 시도될 때는 서버에 해당 HTTP 요청을 다시 보내지 않고 저장되어 있는 HTTP 응답을 재활용하게 됩니다.

2.     Shared Cache
여러 사용자들에 의해 재활용될 수 있는 데이터들이 저장되는 저장소입니다. 최초의 HTTP 요청은 공유 캐시를 거쳐 서버에게 전송되어 HTTP 응답을 받아오게 되고, 이를 공유 캐시에 저장해 두면 다음번에 동일한 HTTP 요청이 공유 캐시에게 전달될 때 서버에 해당 HTTP 요청을 다시 보내지 않고 저장되어 있는 HTTP 응답을 클라이언트에게 반환하게 됩니다.

HTTP 캐시 제어

1.     Cache-control 헤더

캐싱 메커니즘을 결정하는 디렉티브를 지정하는 데 사용됩니다.

Cache-control 헤더에 나열할 수 있는 디렉티브

max-age=<seconds>
seconds 만큼 캐시를 유지시킵니다. 이후엔 서버에 요청한 뒤 304 응답(동일한 페이지를 요청)을 받을 때에만 캐시를 이용합니다.

no-chache
캐시가 유효한지 확인하기 위해 매번 서버에 요청한다.

no-store
어떤 요청도 캐시로 저장하지 않는다.

public
어떤 요청에 대해서든 캐시를 저장한다.

private
타인과 공유되는 프록시 서버에는 캐시를 저장하지 않는다. 최종 사용자의 클라이언트에만 캐시를 저장한다.

2.     ETag 헤더

특정 버전의 리소스를 식별하는 식별자입니다. 만약 특정 URL의 리소스가 변경된다면, 새로운 ETag가 생성됩니다.
그렇기 때문에 기존의 ETag와 동일한 ETag를 갖고 있다면 리소스 변화가 없음을 뜻하기 때문에 캐싱된 데이터를 보내면 자원을 아낄 수 있습니다.

전체적인 HTTP 캐시 메커니즘

 

1.     클라이언트는 /doc을 요청을 하면 캐시를 지나면서 캐시에 데이터가 있는지 확인합니다.

2.     비어 있으므로 Server에 요청을 보내고 받은 문서의 내용에 대해서 max-age=100 으로 캐시에 저장합니다.
        (100초 동안 유지)

3.     10초 후 클라이언트는 /doc 요청을 동일하게 보냅니다. 캐시를 거치면서 캐시에 데이터가 있는지 확인하고
        캐시 내에 /doc 요청 데이터를 찾습니다.

4.     서버에게 요청하지 않고 캐시 내에 있는 /doc 데이터를 보내 줍니다.

5.     100초 이후 만료된 자원에 대해서는 검증을 진행해야 합니다. 서버에 /doc요청을 보냅니다.         
        이 때 ETag 헤더가 존재한다면 ETag 헤더의 값을 If-None-Match 헤더를 포함시켜 서버에게 검증 요청을 보냅니다.
        만약 ETag가 존재하지 않는다면 Last-Modified 헤더를 활용합니다.

6.     서버는 전달받은 ETag값 혹은 Last-Modified 값을 이용하여 자원의 유효성을 검사합니다.
        여전히 해당 자원이 변경이 없고 유효하다면 304 응답을 보내주면서 age(유효 시간)을 0으로 초기화해주면서
        캐시 내에 있는 데이터를 다시 반환하고 더 이상 유효하지 않다면 새로운 자원을 Body에 담아서 200 응답을
        보내줍니다. 이 때 다시 캐시 내에 데이터를 갱신해줍니다.

결론

HTTP는 클라이언트가 정보를 요청하면
서버가 정보에 대한 응답을 해주는 정보 교환과 관련된 프로토콜입니다.

이번에 글을 쓰면서 새롭게 느낀 것은 HTTP는 양방향 통신으로 생각하고 있었는데
각 요청이 독립적인 단방향 통신이었다는 것을 알게되었습니다.

다시 생각해보면 단방향 통신인데 글을 쓰면서 개념을 정확하게 알게되었습니다.

HTTP 캐시에 대해서 조사하면서 캐시가 어떻게 동작하는지 이해가 되었습니다.
ETag 헤더로 식별을 하고 max-age를 보고 캐시가 만료 되었는지,
만료가 되었을 때는 IF-None-Match 헤더를 포함시켜 서버에 요청하여
갱신하는 법까지 개념을 확실히 이해할 수 있었습니다.

[참고]

1. https://developer.mozilla.org/ko/docs/Web/HTTP

2. https://ko.wikipedia.org/wiki/HTTP

3. https://namu.wiki/w/HTTP

4. https://joshua1988.github.io/web-development/http-part1/

5. https://pjh3749.tistory.com/264

6. https://web.dev/http-cache/

7. https://enai.tistory.com/26

8. https://it-eldorado.tistory.com/142

9. https://www.huskyhoochu.com/cache-control/

10. https://developer.mozilla.org/ko/docs/Web/HTTP/Headers/ETag

11. https://interconnection.tistory.com/74