쿠키

• HTTP의 stateless한 특성을 보완하기 위한 수단
• 서버에서 생성되어 클라이언트 측에 저장되는 <이름, 값> 형태의 데이터
  • 이외에도 만료기간 같은 추가적인 속성값도 가질 수 있음
• 클라이언트는 서버로부터 받은 쿠키를 주로 브라우저에 저장
  • 추후 같은 서버에 요청을 보낼 때 요청 메시지에 쿠키를 포함하여 전송
• 서버가 클라이언트에게 쿠키를 전송할 때는 응답 메시지의 "Set-Cookie 헤더"가 활용
• 클라이언트가 서버에게 쿠키를 송신할 때에는 "Cookie 헤더"가 활용
• 어떤 서버로부터 쿠키를 전달받으면 해당 서버에게 보내는 요청 메시지에는 자동으로 전달받은 쿠키가 포함

쿠키의 속성

• domain과 path 속성을 통해 쿠키를 전송할 도메인과 경로를 제한할 수 있음
• Expires와 Max-age 속성으로 쿠키의 유효기간을 명시하여 유효기간이 지나면 해당 쿠키는 삭제되어 전달 x
• Secure 속성은 HTTPS를 통해서만 쿠키를 송수신하도록 하는 속성
• HttpOnly 속성은 자바스크립트를 통한 쿠키의 접근을 제한하고, 오직 HTTP 송수신을 통해서만 쿠키에 접근하도록 함

웹 스토리지: 로컬 스토리지와 세션 스토리지

• 웹 스토리지: 브라우저 내의 저장 공간, 일반적으로 쿠키보다 더 큰 데이터를 저장할 수 있음
• 쿠키는 서버로 자동 전송되지만, 웹 스토리지의 정보는 서버로 자동 전송되지 않음
• 로컬 스토리지는 별도로 삭제하지 않는 한 영구적으로 저장 가능
• 세션 스토리지는 세션이 유지되는 동안(브라우저가 열려있는 동안) 유지되는 정보

캐시

• 캐시 메모리는 "메모리에 접근하는 시간을 줄이기 위해 자주 참조되는 내용을 저장하는 장치"
  • HTTP에서도 이와 유사한 개념인 HTTP 캐시가 있음
• HTTP의 캐시는 "응답받은 자원의 사본을 임시 저장하여 불필요한 대역폭 낭비와 응답 지연을 방지하는 기술"
• 응답 메시지에 캐시의 유효기간을 설정할 수 있음
• 클라이언트가 응답받은 자원을 임시 저장하여(캐시하여) 이용하다가 유효기간이 만료되면 다시 서버에 자원을 요청해야 함
• 캐시에 유효기간이 존재하는 이유는 "클라이언트가 캐시를 참조하는 사이 서버의 원본 데이터가 변경되어 원본 데이터와 캐시된 사본 데이터 간의 일관성이 깨질 수 있기 때문"
  • 캐시된 사본 데이터와 원본 데이터가 얼마나 유사한지의 정도는 "캐시 신선도"라고 표현
• 캐시된 데이터의 유효 기간이 만료되었더라도, 서버의 원본 데이터가 변경되지 않았다면 서버로부터 같은 자원을 응답받을 필요가 없음
  • 따라서 클라이언트는 캐시의 유효 기간이 만료되었을 때, 서버에게 "원본 자원이 변경된 적이 있는지" 질의
  • 클라이언트가 서버에게 원본 데이터의 변경 여부를 물을 때에는 "날짜"를 기반으로 묻거나, "엔티티 태그"를 기반으로 물을 수 있음
• 날짜를 기반으로 물을 때에는 "If-Modified_Since 헤더"를 통해서
  • 서버의 응답으로는
  1. 서버가 요청받는 자원이 변경된 경우 : 상태 코드 200과 함께 새로운 자원을 반환
  2. 서버가 요청받는 자원이 변경되지 않은 경우 : 304(Not Modified) 상태 코드와 함께 Last-Modified 헤더로 마지막 변경 시점을 알림
  3. 서버가 요청받는 자원이 없는 경우 : 404 상태 코드 전송
• 엔티티 태그 기반
  • Etag라고 부르는 "엔티티 태그"
  • "자원의 버전"을 식별하기 위한 정보
  • 자원이 변경될 때마다 자원의 버전을 식별하는 Etag값이 변경되고, 반대로 자원이 변경되지 않으면 Etag 값도 변경되지 않음
  • 대표적인 요청 헤더 "If-None-Match 헤더"를 통해서 이루어짐
  • 서버의 응답은 위의 3가지 경우와 같음

콘텐츠 협상

• 실은 HTTP 메시지를 통해 주고받는 것이 "자원"이 아니라, "자원의 표현"
  • "표현"이란 송수신 가능한 자원의 형태를 의미
• 같은 자원에 대해 할 수 있는 여러 표현 중(ex> xml, json, jpg, txt...) 클라이언트가 가장 적합한 자원의 표현을 제공하는 기술을 "콘텐츠 협상"이라고 함
• 클라이언트가 선호하는 자원의 표현을 "콘텐츠 협상 헤더"를 통해 서버에게 전송하면, 서버는 클라이언트가 요청한 자원의 표현을 응답
  • Accept: 선호하는 미디어 타입을 나타내는 헤더
  • Accept-Language: 선호하는 언어를 나타내는 헤더
  • Accept-Encoding: 선호하는 인코딩 방식을 나타내는 헤더

보안: SSL/TLS와 HTTPS

• HTTPS는 HTTP에 SSL 혹은 TLS라는 프로토콜의 동작이 추가된 프로토콜
• SSL Secure Socket Layer과 TLS Transport Layer Security는 모두 인증과 암호화를 수행하는 프로토콜로, TLS는 SSL을 계승한 프로토콜
• TLS 1.3기반 HTTPS 메시지는 크게 아래와 같은 단계를 거쳐 전송
  1. TCP 쓰리 웨이 핸드셰이크
  2. TLS 핸드 셰이크
  3. 메시지 송수신
• 2번의 과정을 거쳐 서로에 대한 인증과 메시지 암호화가 이루어지므로, 2번을 거쳐 3번에서 주고받는 메시지는 암호화된 메시지
• TLS 핸드 셰이크의 핵심 내용은 크게 2가지
  1. TLS 핸드 셰이크를 통해 암호화 통신을 위한 키를 생성/교환이 가능
  2. 인증서 송수신과 검증이 이루어질 수 있음

암호화 통신을 위한 키 생성/교환

• TLS에서 활용되는 암호화 알고리즘을 통해 평문을 암호화하거나 복호화하려면 "키"라는 정보가 필요
• "키"는 암호화 통신을 수행하는 두 호스트만 알고 있어야 하는 정보로,
• TLS 핸드셰이크 과정에서 "ClientHello 메시지", "ServerHello 메시지"를 주고 받으며 생성/교환
• ClientHello 메시지에는 "사용 가능한 암호화 알고리즘과 해시 함수"를 서버에 알리기 위한 정보가 포함
  • 이 정보를 "암호 스위트"
• ServerHello 메시지는 제시된 암호 스위트들을 선택하는 메시지
  • 선택된 TLS의 버전, 암호 스위트 등의 정보, 등이 포함
• ClientHello와 ServerHello메시지를 주고 받으면 암호화된 통신을 위해 협의되어야 할 정보들이 결정되고, 결정된 정보를 토대로 "키"를 만들어 암호화/복호화 할 수 있도록 함

인증서 송수신과 검증

• 인증서는 "당신이 통신을 주고받는 상대방은 틀림없이 당신이 의도한 대상이 맞다"라는 사실을 입증하기 위한 정보
• 인증서를 발급하고 검증하는 제 3의 "인증기관(CA)" 공인 기관
• TLS에서 인증서 관련한 메시지로는 "Certificate"와 "CertificateVerify" 메시지
  • Certificate 메시지에는 인증서 내용들이 포함
  • CertificateVerify 메시지에는 인증서의 내용이 올바른지 검증하기 위한 내용들이 포함
• 암호화에 사용할 키, 인증서 확인한 후 TLS 핸드셰이크의 마지막을 의미하는 Finished 메시지를 주고받고, TLS 핸드셰이크를 통해 얻어낸 키를 기반으로 암호화된 데이터를 주고 받음