📖/spring(김영한)

모든 개발자를 위한 HTTP 웹 기본 지식 3일차

모팔구 2023. 8. 17. 15:19
728x90
반응형

섹션7 HTTP 헤더1 - 일반 헤더

HTTP 헤더 개요

  • header field = field-name:OWSfield-valueOWS (OWS: 띄어쓰기 허용)
  • HTTP 헤더의 용도
    • HTTP 전송에 필요한 모든 부가정보를 가지고 있음 ex) 메시지 바디의 내용, 메시지 바디의 크기, 압축 ,인증, 요청 클라이언트, 서버 정보, 캐시 관리 정보 등등
    • 표준 헤더가 매우 많음
    • 필요시 임의의 헤더를 추가할 수 있음
  • RFC2616(과거) 버전
    • HTTP 헤더
      • General 헤더: 메시지 전체에 적용되는 정보
      • Request 헤더: 요청 정보
      • Response 헤더: 응답 정보
      • Entity 헤더: 엔티티 바디 정보
    • HTTP 바디
      • 메시지 본문(message body)은 엔티티 본문(entity body)을 전달하는데 사용함
      • 엔티티 본문은 요청이나 응답에서 전달할 실제 데이터
      • 엔티티 헤더는 메시지 본문의 데이터를 해석할 수 있는 정보를 제공함 ex) 데이터 유형(html, json 등), 데이터 길이, 압축 정보 등등
  • RFC723x 변화
    • 엔티티(Entity) → 표현(Representation)
    • Representation = representation Metadata + Representation Data 즉, 표현은 표현 메타데이터와 표현 데이터를 합친 것이다
    • HTTP 바디
      • 메시지 본문(message body)을 통해 표현 데이터를 전달한다. 메시지 본문을 페이로드라고도 한다
      • 표현은 요청이나 응답에서 전달할 실제 데이터다. 표현 헤더는 표현 데이터를 해석할 수 있는 정보를 제공한다 ex) 데이터 유형(html, json 등), 데이터 길이, 압축 정보 등등
      • 표현 헤더는 표현 메타데이터와 페이로드 메시지를 구분해야 하지만 강의에서는 생략한다

표현

  • 표현 헤더의 항목
    • Content-Type: 표현 데이터의 형식
      ➥속성 예) text/html; charset=utf-8, application/json, image/png 등
    • Content-Encoding: 표현 데이터의 압축 방식 데이터를 전달하는 곳에서 압축 후 인코딩 헤더 추가함. 데이터를 읽는 쪽에서 인코딩 헤더의 정보로 압축을 해제함
      ➥속성 예) gzip, deflate, identity
    • Content-Language: 표현 데이터의 자연 언어
      ➥속성 예) ko, en, en-US
    • Content-Length: 표현 데이터의 길이. 바이트 단위. Transfer-Encoding(전송 코딩)을 사용하면 Content-Length를 사용하면 안됨 왜냐 하면 전송 코딩 안에 정보가 다 기재돼있기 때문
    • 표현 헤더는 전송, 응답 둘 다 사용한다

콘텐츠 협상

  • 협상: 클라이언트가 선호하는 표현 요청
    • Accept: 클라이언트가 선호하는 미디어 타입 전달
    • Accept-Charset: 클라이언트가 선호하는 문자 인코딩
    • Accept-Encoding:  클라이언트가 선호하는 압축 인코딩
    • Accept-Language: 클라이언트가 선호하는 자연 언어
    • 협상 헤더는 요청시에만 사용

전송 방식

  • 단순 전송: 한번에 요청하고 한번에 응답을 받을 때 사용함 콘텐츠의 길이(Content-Length)를 알 수 있음
  • 압축 전송: 서버에서 콘텐츠를 압축해서 전송할 때 사용함 Content-Encoding을 추가해야함
  • 분할 전송: Transfer-Encoding을 사용함 콘텐츠를 분할해서 전송함 분할하면 각각의 바이트가 존재하고 Content-Length가 예상되지 않기 때문에 사용할 수 없음
  • 범위 전송: 범위를 지정해서 전송할 수 있음 Range나 Content-Range를 사용함

일반 정보

  • From: 유저 에이전트의 이메일 정보. 일반적으로 잘 사용하지는 않음 검색 엔진 등에서 주로 사용함. 요청용
  • Referer: 현재 요청된 페이지의 이전 웹 페이지 주소. Referer를 사용해서 유입 경로를 분석할 수 있음. 요청용
  • User-Agent: 유저 에이전트 애플리케이션 정보 즉, 클라이언트의 애플리케이션 정보를 알려준다. 통계를 낼 수 있는 정보들. 어떤 종류의 브라우저에서 장애가 발생하는지 파악할 수 있다. 요청용
  • Server: 요청을 처리하는 ORIGIN 서버의 소프트웨어 정보. 응답용
  • Date: 메시지가 발생한 날짜와 시간. 응답용

특별한 정보

  • Host: 요청한 호스트 정보(도메인). 필수값. 하나의 서버가 여러 도메인을 처리해야 할 때 즉, 하나의 IP 주소에 여러 도메인이 적용되어 있을 때 사용함. 요청용
  • Location: 페이지 리다이렉션
  • Allow: 허용 가능한 HTTP 메서드
  • Retry-After: 유저 에이전트가 다음 요청을 하기까지 기다려야 하는 시간. 날짜나 초단위로 표기할 수 있음

인증

  • Authorization: 클라이언트 인증 정보를 서버에 전달함
  • WWW-Authenticate: 리소스 접근 시 필요한 인증 방법을 정의함

쿠키

  • 쿠키 미사용시
    • HTTP는 무상태 프로토콜이기 때문에 클라이언트와 서버가 요청과 응답을 주고 받으면 연결이 끊어진다. 클라이언트가 다시 요청하면 서버는 이전 요청을 기억하지 못한다. 클라이언트와 서버는 서로 상태를 유지하지 않는다. 이를 보완하려면 모든 요청에 사용자 정보를 포함해야 한다 이는 보안상, 개발상의 문제 등을 발생시킨다
  • 쿠키 사용 시
    • 요청한 정보 Set-Cookie의 값으로 저장되고 이후 쿠키 저장소에 저장한다 요청 후 같은 서버의 다른 페이지로 접근하면 쿠키 저장소에서 해당 정보를 가져와 유지한다
    • 즉 모든 요청에 쿠키 정보를 자동으로 포함시켜 보안과 개발 시의 문제를 보완할 수 있다
  • 쿠키
    • 사용처: 사용자 로그인 세션 관리, 광고 정보 트래킹 등
    • 쿠키 정보는 항상 서버에 전송된다. 네트워크 트래픽을 추가로 유발하기 때문에 최소한의 정보(세션 id, 인증 토큰 등)만 사용하는 것을 권장한다
    • 서버에 전송하지 않고 웹 브라우저 내부에 데이터를 저장하고 싶다면 웹 스토리지인 localStorage, sessionStorage 등을 사용하면 된다
    • 보안에 민감한 데이터(주민번호, 신용카드 번호 등)는 저장하면 안된다 
    • 생명 주기
      • expires: GMT 기준. 만료일이 되면 쿠키가 삭제됨. Set-Cookie의 속성값
      • max-age: 초단위. 0이나 음수를 지정하면 쿠키가 삭제된다. Set-Cookie의 속성값
      • 세션 쿠키: 만료 날짜를 생략하면 브라우저 종료까지만 유지함
      • 영속 쿠키: 만료 날짜를 입력하면 해당 날짜까지만 유지함
    • 도메인
      • 명시: 명시한 문서 기준 도메인 + 서브 도메인 포함
        ➥ ex) domain=example.org를 지정해 쿠키를 생성하면 dev.example.org도 쿠키로 접근이 가능함
      • 생략: 현재 문서 기준 도메인만 적용됨
        ➥ ex) domain=example.org에서 쿠키를 생성하면 dev.example.org는 쿠키로 접근이 불가능함
    • 경로: 이 경로를 포함한 하위 경로 페이지만 쿠키로 접근할 수 있음 path=/로 지정함
      ➥ ex) path=/home으로 지정하면 /home, /home/level1, /home/level1/level2에서 접근이 가능하나 /hello는 접근 불가능함
    • 보안
      • Secure: 쿠키는 http, https를 구분하지 않고 전송하는데 secure를 적용하면 https인 경우에만 전송함
      • HttpOnly: XSS 공격을 방지할 수 있음. 자바스크립트에서 접근 불가능함. HTTP 전송에만 사용함
      • SameSite: XSRF 공격을 방지함. 요청 도메인과 쿠키에 설정된 도메인이 같은 경우에만 쿠키를 전송함
  • Set-Cookie: 서버에서 클라이언트로 쿠키를 전달함. 응답용.
  • Cookie: 클라이언트가 서버에서 받은 쿠키를 전달하고 

 

섹션8 HTTP 헤더2 - 캐시와 조건부 요청

캐시 기본 동작

  • 캐시가 없을 때 데이터가 변경되지 않아도 계속 네트워크를 통해서 데이터를 다운로드 받아야 한다. 인터넷 네트워크는 매우 느리고 비싸며 브라우저의 로딩 속도는 느리다 그렇기에 느린 사용자 경험을 제공하게 된다 
  • 캐시가 유효한 시간을 지정(cathe-control: max-age=n초)해 캐시를 적용하면 데이터를 다운로드 한 후 해당 시간 동안에는 데이터 다운로드를 하지 않고 유지된다 즉 캐시 가능 시간 동안 네트워크를 사용하지 않아도 된다. 그럼 비싼 네트워크 사용량을 줄일 수 있고 브라우저 로딩 속도가 매우 빨라진다. 그렇기 때문에 빠른 사용자 경험을 제공하게 된다 
  • 캐시가 유효한 시간을 초과하면 서버를 통해 데이터를 다시 조회하고 캐시를 갱신한다. 이때 다시 네트워크 다운로드가 발생한다. 

검증 헤더와 조건부 요청1

  • 캐시가 만료돼서 다시 요청했늗네 서버에서 데이터를 변경하지 않은 경우 데이터를 전송하는 대신 저장해 두었던 캐시를 재사용할 수 있다. 그러려면 클라이언트의 데이터와 서버의 데이터가 같다는 사실을 확인할 수 있는 방법이 필요하다 검증 헤더와 조건부 요청을 사용하면 된다
  • 검증 헤더 추가: Last-Modified를 UTC 기준으로 추가한다 이는 데이터 최종 수정일을 지정한다
  • 조건부 요청 추가: if-modifed-since로 기준 수정일을 지정할 수 있다.
  • 캐시 유효시간을 초과해도, 서버의 데이터가 갱신되지 않으면 304 Not Modified와 헤더 메타 정보만(바디X) 응답한다 클라이언트는 서버가 보낸 응답 헤더 정보로 캐시의 메타 정보를 갱신한다 클라이언트는 캐시에 저장되어 있는 데이터를 재활용하기 떄문에 네트워크 다운로드가 발생하지만 용량이 적은 헤더 정보만 다운로드한다. 매우 실용적임

검증 헤더와 조건부 요청2

  • 검증 헤더: 캐시 데이터와 서버 데이터가 같은지 검증함. Last-Modified, ETag가 사용됨
  • 조건부 요청 헤더: 검증 헤더로 조건에 따른 분기를 서버에 요청함. 조건을 만족하면 200 OK, 조건을 만족하지 않는다면 304 Not Modified가 발생한다
    • if-modified-since: 특정 날짜 이후에 데이터가 수정되었으면(Last-Modified) 200 OK, 수정되지 않았으면 304 Not Modified가 발생함
    • if-none-match: ETag가 같으면 304 Not Modified, 다르면 200 OK가 발생함
  • Last-Modified, if-modified-since 조합의 단점
    • 1초 미만 단위로 캐시 조정할 수 없다.
    • 날짜 기반의 로직을 사용한다.
      • 데이터를 수정해서 날짜가 다르지만, 같은 데이터를 수정해 데이터 결과가 같은 경우(A → B → A) 단점 발생
    • 서버에서 별도의 캐시 로직을 관리하고 싶은 경우(스페이스나 주석처럼 크게 영향이 없는 변경에서 캐시를 유지하고 싶은 경우) 단점 발생 
  • 위 단점을 보완하려면 ETag, if-none-match 조합을 사용한다
    • ETag(Entity Tag): 캐시용 데이터에 임의의 고유한 버전 이름을 해쉬값으로 지정한다. 데이터가 변경되면 이름인 해쉬값을 바꾸어서 변경한다 단순하게 ETag만 보내서 같으면 유지하고 다르면 다시 다운로드 한다
    • 캐시 제어 로직을 서버에서 완전히 관리한다. 클라이언트는 단순히 이 값을 서버에 제공한다 즉, 클라이언트는 캐시 매커니즘을 모른다. 
    • 사용 예
      • 서버는 배타 오픈 기간인 3일 동안 파일이 변경되어도 ETag를 동일하게 유지한다
      • 애플리케이션 배포 주기에 맞추어 ETag를 모두 갱신한다

캐시와 조건부 요청 헤더

  • 캐시 제어 헤더
    • Cache-Control: 캐시를 제어하는 캐시 지시어(directives)
      • 캐시 지시어
        • max-age: 캐시 유효시간. 초단위. 날짜 기준보다 훨씬 유연함
        • no-cache: 데이터는 캐시를 해도 되지만 항상 원 서버(origin server)에 검증하고 사용함
        • no-store: 데이터에 민감한 정보가 있으므로 저장하면 안됨. 메모리에서 사용하고 최대한 빨리 삭제됨
    • Pragma: 캐시를 제어함(하위 호환)
      • 캐시 지시어
        • no-cache
    • Expires: 캐시 유효 기간 지정(하위 호환)
      • 캐시 지시어
        • expires: 캐시 만료일을 정확한 날짜로 지정함(GMT 기준)
  • 검증 헤더와 조건부 요청 헤더
    • 검증 헤더
      • ETag
      • Last-Modified
    • 조건부 요청 헤더
      • if-match, if-none-match: ETag 값 사용
      • if-modified-since, if-unmodified-since: Last-Modified 값 사용

프록시 캐시

  • Cache-Control 캐시 지시어
    • public: 응답이 public 캐시에 저장되어도 됨
    • private: 응답이 해당 사용자만을 위한 것으로 private 캐시에 저장해야 함(기본값)
    • s-maxage: 프록시 캐시에만 적용되는 max-age
  • Age(HTTP 헤더)
    • 시간: 오리진 서버에서 응답 후 프록시 캐시 내에 머문 시간을 초단위로 지정

캐시 무효화

  • Cache-Contol 캐시 지시어
    • no-cache: 위 참고
    • no-store: 위 참고
    • must-revalidate: 캐시 만료 후 최초 조회 시 원 서버에 검증해야함. 원 서버 접근 실패시 반드시 504 Gateway Timeout 에러가 발생해야 함. 캐시 유효 시간이라면 캐시를 사용함
  • Pragma 캐시 지시어
    • no-cache

섹션9 다음으로

다음으로

-

 

 

반응형
728x90
반응형
저작자표시 (새창열림)