HTTP 기반 기술

HTTP 헤더

• 필드 이름(헤더 이름)과 필드 값(헤더 값)이 콜론(:)을 기준으로 구분
• 헤더 유형
  • 특별한 사전 지식이 필요하지 않은 헤더
  • 사전 지식이 필요한 헤더 (예) 캐시, 쿠키, 콘텐츠 협상 관련 헤더

---

HTTP 요청 시 주로 사용되는 헤더

① Host

• 요청을 보낼 호스트를 나타내는 헤더
• 호스트 도메인 네임 명시, 포트 번호가 포함되어 있을 수 있음
• 예) http://info.cern.ch/hypertext/WWW/TheProject.html에 접속할 때의 HTTP 요청 메시지 일부 GET /hypertext/WWW/TheProject.html HTTP/1.1 Host: info.cern.ch

② User-Agent

• 유저 에이전트(user agent): HTTP 요청을 시작하는 클라이언트 측의 프로그램 (예: 웹 브라우저)
• User-Agent 헤더: 요청 메시지 생성에 관여한 클라이언트 프로그램과 관련된 다양한 정보가 명시

③ Referer

• 클라이언트가 요청을 보낼 때 머무르고 있던 URL이 명시
• 클라이언트의 유입 경로를 파악

④ Authorization

• 클라이언트의 인증 정보를 담는 헤더
• 인증 타입(type)과 인증을 위한 정보(credentials) 명시 Authorization: <type> <credentials>
• 인증 타입에 따라 인증 정보에 명시될 값이 달라짐

가장 기본적인 HTTP 인증 타입은 Basic

• username:password를 Base64 인코딩한 값을 인증 정보로 삼는 방식
• 예) 사용자 아이디가 'minchul'이고 비밀번호는 '1234'일 경우, 인증 정보는 'minchul:1234'를 Base64 방식으로 인코딩한 값

 

HTTP 응답 시 주로 사용되는 헤더

① Server

• 요청을 처리하는 서버 측의 소프트웨어와 관련된 정보를 명시
• 예) Unix 운영체제에서 동작하는 아파치 HTTP 서버를 의미하는 헤더 Server: Apache/2.4.1 (Unix)

② Allow

• Allow 헤더는 클라이언트에게 허용된 HTTP 메서드 목록을 알려 주기 위해 사용
• 상태 코드 **405(Method Not Allowed)**를 응답하는 메시지에서 Allow 헤더가 함께 사용

③ Retry-After

• 상태 코드 **503(Service Unavailable)**과 함께 사용될 수 있는 헤더
• 자원을 사용할 수 있는 날짜 혹은 시각을 나타냄 Retry-After: Fri, 23 Aug 2024 09:00:00 GMT Retry-After: 120
• 예) '2024년 8월 23일 금요일 09시 이후에 사용 가능함' 또는 '120초 이후에 사용 가능함'

503 : 현재는 요청을 처리할 수 없으나 추후 가능할 수도 있음

④ Location

• 클라이언트에게 자원의 위치를 알려 주기 위해 사용되는 헤더
• 주로 리다이렉션이 발생했을 때나 새로운 자원이 생성되었을 때 사용

⑤ WWW-Authenticate

• 상태 코드 **401(Unauthorized)**과 함께 사용되는 헤더
• 자원에 접근하기 위한 인증 방식을 설명 WWW-Authenticate: Basic

 

Authorization과 WWW-Authenticate 헤더를 통한 HTTP 인증(Basic 인증) 과정

1. 인증되지 않은 클라이언트가 서버에 GET 요청 메시지를 전송
2. 서버는 **401(Unauthorized)**과 함께 WWW-Authenticate 헤더를 통해 인증 방식을 알림
3. 클라이언트는 사용자로부터 인증 정보(사용자 아이디와 비밀번호)를 전달받음
4. 클라이언트는 Base64로 인코딩한 값을 Authorization 헤더를 통해 요청 메시지를 전송
5. 서버는 인증 정보를 확인
6. 인증이 유효하면 상태 코드 200으로 응답하고, 인증되지 않았으면 상태 코드 401로 응답

Authorization 과 www-authenticate 헤더를 통한 HTTP 인증(Basic 인증) 과정

 

 

HTTP 요청과 응답 모두에서 자주 활용되는 헤더

① Date

• 메시지가 생성된 날짜와 시각에 관련된 정보를 담은 헤더

② Connection

• 클라이언트와 요청과 응답 간의 연결 방식을 설정하는 헤더
• 지속 연결(Connection)에 명시되는 대표적인 연결 방식
• 가장 대표적으로 사용되는 값은 keep-alive와 close

③ Content-Length

• 본문의 바이트 단위 크기(값) Content-Length: 100

④ Content-Type, Content-Language, Content-Encoding

• 메시지 본문의 표현 방식을 설명하는 헤더
• 표현 헤더(representation header)의 일종
• Content-Type 헤더
  • 메시지 본문에서 사용된 미디어 타입
• Content-Language 헤더
  • 메시지 본문에서 사용된 자연어를 명시
  • 언어 태그로 명시: 하이픈(-)으로 구분된 구조 -> 일반적으로 첫번째 서브 태그 = 언어 코드, 두번째 서브 태그 = 국가 코드
  • 언어 코드 - 국가 코드의 조합 = "어떤 국가에서 사용하는 어떤 언어"
    • ko-KR
    • en-GB
    • en-US
• Content-Encoding 헤더
  • 메시지 본문을 압축하거나 변환한 방식

---

HTTP 기반 기술

1. 캐시
2. 쿠키
3. 콘텐츠 협상

---

HTTP 기반 기술: 캐시(cache)

• 응답 받은 자원의 사본을 임시 저장하는 기술
• 불필요한 대역폭 낭비 방지, 응답 지연 방지
• 빠른 지원 없는 기능
• 개인 전용 캐시(private cache)
  • 웹 브라우저에 저장
• 공용 캐시(public cache)
  • 클라이언트와 서버 사이에 위치한 중간 서버에 저장

• 캐시 신선도의 검사와 유지
  • 핵심은 '사본'을 저장한다는 점!
  • 캐시된 데이터는 얼마든지 원본 데이터와 달라질 수 있다
  • 캐시 신선도(cache freshness)
    • 캐시된 사본 데이터가 얼마나 최신 원본 데이터와 유사한지를 표현
  • 어떻게 캐시 신선도를 검사할 수 있을까?

• 캐시 신선도 검사: 유효 기간 설정
  • 기간이 만료되었다면 원본 데이터를 다시 요청
  • 유효 기간 설정 방법
    • 응답 메시지의 Expires 헤더(절대)와 Cache-Control 헤더의 Max-Age 값(상대)을 사용
    • 예) 캐시의 유효 시간을 2024년 2월 6일 화요일 12:00:00로 설정, 또는 1200초로 설정하는 응답 메시지

유효기간이 끝났다고 해서 무조건 다시 새로 물어올 필요 없음

 

 

캐시 신선도의 재검사

1) If-Modified-Since 헤더: 날짜를 기반으로 서버에게 물어보는 방법

• If-Modified-Since 헤더에 명시된 시점 이후로 원본에 변경이 있었다면 그때만 새 자원으로 응답하도록 서버에게 요청하는 헤더

 

서버의 Last-Modified 헤더

• 상태 코드 304(Not Modified)를 통한 자원의 '변경 여부' 뿐만 아니라 자원이 마지막으로 수정된 시점도 알려줄 수 있음

2) If-None-Match 헤더: 엔티티 태그(Etag)를 기반으로 서버에게 물어보는 방법

• ETag는 '자원의 버전'을 식별하기 위한 정보
• 버전(version)이란 '의미적인 변경 사항'
• 즉, 자원이 변경될 때마다 자원의 버전을 식별하는 Etag 값이 변경
• 반대로 자원이 변경되지 않았다면 Etag 값도 변경되지 않음

 

• '이 Etag 값과 일치하는 자원이 있는가?'
• '혹시 Etag 값이 abc인 www.example.com/index.html이라는 자원이 있는가? 자원이 변경되었다면(Etag 값이 바뀌었다면) 그때만 새 자원으로 응답하라'

 

HTTP 기반 기술: 쿠키(cookie)

쿠키(cookie)

• 서버에서 생성되어 클라이언트 측에 저장되는 데이터
• 상태를 유지하지 않는 HTTP의 특성을 보완하기 위한 수단
• 기본적으로 <이름, 값> 쌍의 형태, 추가로 다양한 속성을 가질 수 있음

 

 

 

• 서버는 쿠키를 생성하여 클라이언트에게 전송
• 클라이언트는 전달받은 쿠키를 저장해 두었다가 추후 요청 메시지에 쿠키를 포함하여 전송

 

쿠키(cookie)를 활용하는 인증 기술, 세션 인증

• HTTP는 스테이트리스 프로토콜
  • 같은 클라이언트가 서버에 여러 번 요청을 보낸다고 해도, 기본적으로 서버는 모든 요청들을 별개의 요청으로 간주
  • 클라이언트가 서버에 요청 메시지를 보낼 때마다 (아이디, 비밀번호와 같은) 인증 정보를 보내고 번거로운 인증 과정을 거쳐야 하는 것일까?
    -> 요청을 보낼 때마다 번거로운 인증 과정을 거칠 필요가 없음
  •  
• 세션 아이디(session id)와 세션 인증(session authentication)
  1. 클라이언트는 서버에게 (아이디, 비밀번호와 같은) 인증 정보를 전송
  2. 인증 정보가 올바르다면, 서버는 세션 아이디를 생성해 클라이언트에게 전송
  3. 서버는 생성한 세션 아이디를 데이터베이스 등에 저장
  4. 클라이언트는 추후 요청을 보낼 때 쿠키 내에 세션 아이디를 포함하여 전송
  5. 서버는 쿠키 속 세션 아이디와 저장된 세션 아이디를 비교하여 클라이언트를 식별

---

• 서버의 쿠키 생성 - 클라이언트의 쿠키 활용
  • 응답 메시지의 Set-Cookie 헤더, 요청 메시지의 Cookie 헤더 활용
• 응답 메시지의 Set-Cookie 헤더
  • 쿠키의 이름, 값과 더불어 세미콜론(;)으로 구분되는 속성(들)을 전달
  • 한 응답 메시지에 전달할 쿠키가 여러 개라면 다음과 같이 여러 개의 Set-Cookie

 

 

• 요청 메시지의 Cookie 헤더
  • 서버에 전달할 쿠키의 이름과 값을 나타내는 헤더
  • 여러 개의 쿠키 값을 서버에 전달해야 할 때는 세미콜론(;)을 사용
  요청 메시지 Cookie: 이름=값; 이름=값;
• 쿠키는 브라우저에서 저장되고 관리됨
• 쿠키가 저장하고 있는 속성들
  • 도메인, path, expires/max-age, size, httponly, secure

• 쿠키의 여러 속성
  • domain
    • 쿠키는 사용 가능한 도메인이 정해져 있음
    • [의심스러운 링크 삭제됨]에게 받은 쿠키를 전혀 다른 웹 사이트인 www.google.com에게 전송하면 안 됨
    • 응답 메시지 속 Set-Cookie 헤더의 'domain' 속성으로 정함
    응답 메시지 Set-Cookie: name=minchul; domain=example.com
  • path
    • 같은 도메인이라도 경로별로 쿠키를 구분하여 사용하고 싶을 경우
    • 예) www.example.com/pictures를 포함한 하위 경로에서 공통적으로 쓰는 쿠키와 www.example.com/lectures를 포함한 하위 경로에서 사용하고자 하는 쿠키를 구분하고 싶을 경우
    • 'path' 속성으로 쿠키가 적용될 경로를 명시. 지정된 경로 + 하위 경로에서 쿠키 활용
    응답 메시지 Set-Cookie: name=minchul; path=/lectures
  • expires/max-age
    • 쿠키 유효 기간
    • Expires 속성을 통해 쿠키 만료 시점 지정
    • Max-Age 속성을 통해 초 단위 유효 기간 지정
    응답 메시지
  • Set-Cookie: sessionId=abc123; Expires=Fri, 23 Aug 2024 09:00:00 GMT
  • Set-Cookie: sessionId=abc123; Max-Age=2592000

---

• 쿠키의 한계
  • 쿠키의 대표적인 한계는 보안
  • 쿠키 정보는 쉽게 노출되거나 조작될 수 있음
• Secure와 HttpOnly
  • Secure: HTTPS* 프로토콜이 사용되는 경우에만 쿠키 전송
  • HttpOnly: HTTP 송수신을 통해서만 쿠키를 이용하도록 제한하는 속성
    • 쿠키 관련 데이터는 자바스크립트 언어를 통해서도 접근 가능
    • HttpOnly는 자바스크립트에서 쿠키에 접근하지 못하도록 하는 속성

---

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

• 쿠키와 유사한 웹 스토리지(web storage)
  • 클라이언트가 저장하고 클라이언트의 상태를 추측할 수 있는 <키-값> 쌍 형태의 정보
  • 웹 스토리지는 웹 브라우저 내에 저장, 일반적으로 쿠키보다 더 큰 데이터 저장 가능
  • 쿠키는 서버로 자동 전송되지만, 웹 스토리지의 정보는 서버로 자동 전송 X

• 웹 스토리지 종류 
  • 로컬 스토리지(local storage) - 별도로 삭제하지 않는 한 영구적으로 저장에 가능한 정보
  • 세션 스토리지(session storage) - 세션이 유지되는 동안(브라우저가 열려 있는 동안) 유지되는 정보
  • 개발자 도구 → [Application] → [Storage]에서 로컬 스토리지와 세션 스토리지 확인

---

콘텐츠 협상과 표현

• 콘텐츠 협상
  • 같은 URI에 대해 가장 적합한 '자원의 형태'를 제공하는 메커니즘
  • 같은 URI로 식별 가능한 HTML 문서라 해도 영어로 요청하면 영어로 된 형태로 제공 한국어로 요청하면 한국어로 된 형태로 제공
• 자원의 표현(representation)
  • 송수신 가능한 자원의 형태
  • 즉, 콘텐츠 협상은 클라이언트에게 가장 적합한 자원의 표현을 제공하는 메커니즘
  • GET 메서드의 정의
    • '자원의 특정 표현을 습득하기 위한 메서드'

---

• 콘텐츠 협상 관련 HTTP 헤더
  • Accept
    • 선호하는 미디어 타입
  • Accept-Language
    • 선호하는 언어
  • Accept-Charset 및 Accept-Encoding
    • 선호하는 문자 인코딩과 압축 방식
  • 예) 클라이언트가 선호하는 언어가 한국어 및 클라이언트가 HTML 문서 타입을 선호
  요청 메시지
• GET /index.html HTTP/1.1
• Host: example.com
• Accept-Language: ko
• Accept: text/html

 

• 선호도에 우선순위 반영
  • 예) '언어는 한국어를 가장 선호하지만, 영어도 받을 용의가 있다'
  • 우선순위는 콘텐츠 협상 관련 헤더의 q값으로 표현(q는 Quality Value의 약자)
  • 값이 클수록 우선순위가 높음
  • 생략되었을 경우에는 1을 의미
  • 범위는 0부터 1까지
  • 예) 한국어(ko-KR, ko), 영어(en-US, en)순으로 선호하고, HTML, XML, 일반 텍스트순으로 선호

• 요청 메시지
• GET /index.html HTTP/1.1
• Host: example.com
• Accept-Language: ko-KR,ko;q=0.9,en-US;q=0.8,en;q=0.7
• Accept: text/html,application/xml;q=0.9,text/plain;q=0.8,*/*;q=0.5