티스토리 뷰

통신을 중계하는 프로그램

프록시

서버와 클라이언트 사이에서 중계하는 프로그램이다. 원 서버보다 물리적인 거리가 가까운 서버를 두고 캐시하여 사용하는 방법인 CDN과 연관이 깊은 듯 하다. 여러대의 프록시 서버를 경유하는 것도 가능하며 리소스 본체를 가진 서버를 Origin Server라고 한다. 프록시 서버에 리소스 캐시를 보존해 두는 프록시 서버를 캐싱 프록시라고 한다. 중계시에 메시지 변경을 하지 않는 타입은 투명 프록시라고 한다.

게이트웨이

게이트웨이 다음에 있는 서버는 HTTP 이외의 프로토콜 통신을 하는 서버가 된다. 암호화 등으로 안전성을 높이는 역할을 한다.

터널

요구에 따라 다른 서버와 통신 경로를 확보한다. SSL 등의 통신이 안전한 통신을 위해 사용된다. 터널은 해석을 하지 않으며 그대로 다음 서버에 중계하고 양 끝의 접속이 끊어질 때 종료된다.

 

 

캐시

캐시가 없다면 데이터가 변경되지 않아도 계속 네트워크를 통해 다운받아야 한다. 캐시는 유효기간을 가진다. 클라이언트(브라우저) 측에도 캐시가 있고, 캐시 서버에도 캐시를 가질 수 있다.

캐시의 유효기간

cache-control: max-age=60 이면 60초 동안의 캐시 유효시간을 가진다. 캐시 유효시간이 초과하면 서버를 통해 데이터를 다시 조회하여 갱신한다. 유효기간 이후에는 캐시가 있더라도(유효기간이 끝난다고 캐시가 삭제되는 것은 아니며 이것은 브라우저에 따라 제거 조건은 다르다) 네트워크 통신을 통해 서버에서 다시 리소스를 받아오기 때문에 비효율적이다. 따라서 이를 개선하고자 캐시된 데이터가 변경되었는지 확인하고 변경된 경우만 데이터를 다시 받아올 수 있게 검증헤더와 조건부요청을 사용한다. 

 

검증 헤더와 조건부 요청

캐시가 만료된 후, 리소스는 캐시와 같을 수도 다를 수도 있다. 따라서 이것을 검증하고 조건부로 요청한다.

 

방법1 - 최종 수정일 기준으로 확인

Last-Modified 헤더를 사용하여 데이터 최종 수정일을 캐시에 같이 저장한다. 이후 캐시가 만료되고 재요청을 할 때,

if-modified-since 헤더를 사용하여 최종 수정일과 같은지 확인하고 다를 경우만 리소스를 받아온다.

 

최종 수정일이 같은 경우 서버에서는 304 Not Modified를 전송하여 body 없이 메타데이터가 포함된 메세지로 응답한다. 브라우저에 저장된 캐시를 재사용한다.

 

단점은 1초 미만 단위의 캐시조정이 불가능하다. 수정해서 최종 수정일이 달라졌지만 결국 데이터가 동일한 경우도 있기 때문에 이 경우를 걸러내지 못한다. 서버에서 별도의 캐시 로직 관리가 불가하다.

 

방법2 - 캐시 데이터와 서버 데이터의 일치여부 확인

ETag(Entity Tag)를 사용한다. ETag에 캐시용 데이터의 고유한 버전의 이름(Hash)을 지정한다. 이 경우 Hash의 방법을 사용하는데 데이터가 같으면 Hash 값이 같고, 조금이라도 변경되면 Hash 값이 달라지는 것을 이용한다. 

 

캐시의 ETag와 서버의 ETag가 동일하면 같은 데이터이고 다르면 다른 데이터이다. 캐시의 유효기간이 만료되면

If-None-Match 헤더로 ETag 값을 전송한다. 서버가 가진 ETag 값이 같다면 304 Not Modified로 body 없는 HTTP 메시지를 응답한다. 캐시에 저장된 데이터를 그대로 다시 사용한다. 

 

캐시 제어로직을 완전히 서버에서 관리하게 된다. 클라이언트는 ETag 값을 서버에 전송함하기만 한다.

 

Cache-Control

Cache-Contrl 헤더로 캐싱 동작을 지정한다. Pragme(: no-cache 하위 호환), Expires(날짜로 지정하는데 지금은 max-age를 권장) 헤더는 하위 호환을 위해서 사용된다. Cache-Control 헤더의 디렉티브는 request, response 할 때 사용가능하다.

리퀘스트 디렉티브

디렉티브 내용
max-age=[초] 캐시 유지 기간을 초단위로 지정
no-cache 데이터는 캐시해도 되지만 origin server에 검증하고 사용해야 한다.
no-store 저장하여 보존하면 안된다. (캐시하면 안된다)

리스폰스 디렉티브

디렉티브 내용
public 응답이 public 캐시에 저장가능
private 해당 사용자만 위한 것으로 private 캐시에 저장해야 한다.
s-maxage=[초] 프록시 캐시에만 적용되는 max-age

HTTP 헤더로 Age: [초] 헤더는 오리진 서버에서 응답 후 프록시 캐시 내에 머문 시간을 의미한다.

 

확실한 캐시 무효화

Cache-Control: no-cache, no-store, must-revalidate
Pragma: no-cache

하위호환까지 생각하여 위와 같이 작성하면 거의 확실한 캐시 무효화가 가능하다. must-revalidate는 캐시 만료후 최초 조회시 원 서버에 검증해야 한다. no-cache는 프록시서버~원서버 사이의 통신이 끊기더라도 설정에 따라 200번대 응답을 할 수도 있는데 must-revalidate는 원서버에 검증하지 못하면 반드시 오류를 발생시켜야 한다.(504 Gateway Timeout)

 

정리

더보기

TCP/IP 쉽게, 더 쉽게 + 모두의 네트워크 + 그림으로 배우는 htttp & network basic 책을 읽고, 김영한님 모든 개발자를 위한 HTTP 웹 기본 지식 강의를 듣고 정리한 내용입니다.

공지사항
최근에 올라온 글
최근에 달린 댓글
Total
Today
Yesterday
링크
«   2025/04   »
1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30
글 보관함