About HTTP #3

HTTP 에 대하여 3편

---

HTTP 상태 코드

• 1xx ( Informatilnal ) : 요청이 수신되어 처리중
• 2xx ( Successful ) : 요청 정상 처리
• 3xx ( Redirection ) : 요청을 완료하려면 추가 행동이 필요
• 4xx ( Client Error ) : 클라이언트 오류, 잘못된 문법 등으로 서버가 요청을 수행할 수 없음
• 5xx ( Server Error ) : 서버 오류, 서버가 정상 요청을 처리하지 못함

만약 모르는 상태 코드가 나타난다면?

• 클라이언트가 인식할 수 없는 상태코드를 서버가 반환한다면?
• 클라이언트는 상위 코드로 해석해서 처릭한다. ( ex) 299 -> 2xx ( successful ), 451 -> (Client Error) etc .. )
• 따라서 미래에 새로운 상태 코드가 추가되어도 클라이언트를 변경하지 않아도 된다.

2xx ( Successful ) - 클라이언트의 요청을 성공적으로 처리

• 200 OK : 클라이언트의 요청에 대해 서버가 성공적으로 응답한 경우
• 201 Created : 요청에 성공하여 새로운 리소스가 생성된 경우 ( ex) POST 요청 시 새로운 리소스가 생성되고, 생성된 리소스는 응답의 Location 헤더 필드로 식별한다. )
• 202 Accepted : 요청이 접수되었으나 처리가 완료되지 않았은 경우, 배치 처리 같은 곳에서 사용 ( ex) 요청 접수 후 1시간 뒤에 배치 프로세스가 요청을 처리한다. )
• 204 No content : 서버가 요청을 성공적으로 수행했지만, 응답 페이로드 본문에 보낼 데이터가 없는 경우 ( ex) 웹 문서 편집기의 save 버튼, save 버튼의 결과로 아무 내용이 없어도 되고, 같은 화면을 유지해야하는 한다. )

3xx ( Redirection ) : 요청을 완료하기 위해 유저 에이전트의 추가 조치 필요

Redirection 의 종류

• 영구 리다이렉션 : 특정 리소스의 URI 가 영구적으로 이동

  • 301 Moved Permanently : 리다이렉트 시 요청 메소드가 GET 으로 변하고 본문이 제거될 수 있음 ( MAY )

  

  • 308 Permanently Redirect : 301과 기능은 같지만 리다이렉트 시 요청 메소드와 본문을 유지함

  

  • 실무에서는 308 대신 301을 사용한다! ( 사실 영구 리다이렉션보다는 일시 리다이렉션을 더 많이 사용한다. )

• 일시 리다이렉션 : 일시적인 변경 ( ex) 주문 완료 후 주문 내역 화면으로 이동하는 경우 )

  • 302 Found : 리다이렉트시 요청 메소드가 GET 으로 변하고, 본문이 제거될 수 있음 ( MAY )

  • 307 Temporary Redirect : 302와 기능은 같지만 리다이렉트 시 요청 메소드와 본문을 유지함 ( 요청 메소드를 변경하면 안된다. MUST NOT )

  • 303 See Other : 302와 기능은 같지만 리다이렉트 시 요청 메소드가 GET 으로 변경

  • 실무에서는 302, 303 을 거의 대부분 사용한다!

  • PRG: Post/Redirect/Get

    

    • POST 로 주문 후에 웹 브라우저를 새로 고침하면, 새로 고침은 다시 요청되기 때문에 중복 주문이 될 수 있다.

    

    • POST 로 주문 후에 새로 고침으로 인한 중복 주문을 방지한다.
    • POST 로 주문 후에 주문 결과 화면은 GET 메소드로 리다이렉트한다. 따라서 새로 고침을 하더라도 결과 화면을 GET 으로 조회하게 된다.

• 특수 리다이렉션 : 클라이언트가 서버에 캐시 기간이 만료된 여부를 물어보고, 서버는 캐시를 그대로 사용해도 된다는 ( 캐시에서 그대로 조회하라는 ) 응답을 내려줌

  • 304 Not Modified
    • 캐시를 목적으로 사용한다.
    • 클라이언트에게 리소스가 수정되지 않았음을 알려준다. 따라서 클라이언트는 로컬 PC 에 저장된 캐시를 재사용한다. ( 캐시로 리다이렉트 한다. )
    • 304 응답은 응답에 메세지 바디를 포함하면 안된다. ( 로컬 캐시를 사용해야 하므로 )
    • 조건부 GET, HEAD 요청시 사용한다.

4xx ( Client Error ) : 클라이언트의 요청에 잘못된 문법 등 서버가 요청을 수행할 수 없음

• 400 Bad Request : 요청 구문, 메세지 등이 잘못된 경우, 클라이언트는 요청 내용을 다시 검토하고 보내야 한다.
• 401 Unauthorized : 클라이언트가 해당 리소스에 대한 인증이 필요한 경우. 401 오류 발생 시 응답에 WWW-authenticate 헤더와 함꼐 인증 방법을 설명해줘야 한다.
• 403 Forbiddedn : 서버가 요청을 이해했지만 승인을 겨부한 경우, 인증 자격 증명 ( authenticaiton ) 은 있지만, 접근 권한 ( authorization ) 이 불충분한 경우
• 404 Not Found : 요청 리소스를 찾을 수 없는 겨우

5xx ( Server Error ) : 서버 문제로 오류 발생

• 500 Internal Server Error : 서버 문제로 오류 발생, 애매하면 500 오류
• 503 Service Unavailable : 서버가 일시적인 과부하 또는 예정된 작업으로 잠시 요청을 처리할 수 없는 경우, Retry-After 헤더 필드로 얼마 뒤에 복구되는 지 보낼 수도 있다. ( 거의 안나옴 )

HTTP 헤더 - 일반 헤더

1. 표현 - 젼송과 응답에 모두 사용

   • Content-Type: 표현 데이터의 형식
   • 미디어 타입, 문자 인코딩을 표현한다. ( ex) text/html; charset=utf-8, application/json, image/png etc .. )
   • Content-Encoding: 표현 데이터의 압축 방식
   • 표현 데이터를 압축하기 위해 사용한다.
   • 데이터를 전달하는 곳에서 인코딩 헤더를 추가하고 데이터를 읽는 쪽에서 인코딩 헤더의 정보로 압축을 해제한다. ( ex) gzip, deflate, identify )
   • Content-Language: 표현 데이터의 자연 언어 (ex) ko, en, en-US )
   • Content-Length: 표현 데이터의 길이

2. 협상( 콘텐츠 네고시에이션 ) - 요청시에만 사용

   • Accept: 클라이언트가 선호하는 미디어 타입 전달
   • Accept-Charset: 클라이언트가 선호하는 문자 인코딩
   • Accept-Encoding: 클라이언트가 선호하는 압축 인코딩
   • Accept-Language: 클라이언트가 선호하는 자연 언어
   • 협상에 대한 우선 순위
   • 우선 순위 표현 방법의 예 : Accept-Language: ko-KR,ko;q=0.9,en-US;q=0.8,en;q=0.7
   • 구체적인 것이 우선이다. 예를 들어, Accept:text/, text/plain, text/plain;format=flowed, */ 인 경우, 1. text/plain;format=flowed, 2. text/plain, 3. text/, 4. */

3. 일반 정보

   • From: 유저 에이전트의 이메일 정보 ( 잘 사용하지 않음 )
   • Referer: 이전 웹 페이지 주소
   • 유입 경로를 분석하는 데에 자주 사용한다.
   • User-Agent: 유저 에이전트 애플리케이션 정보 ( 웹 브라우저 정보 etc .. )
   • Server: 요청을 처리하는 오리진 서버의 소프트웨어 정보
   • Date: 메세지가 생성된 날짜

4. 특별한 정보

   • Host: 요청한 호스트 정보( 도메인 )
   • 요청에서 사용하며 필수 헤더이다.
   • 하나의 서버가 여러 도메인을 처리해야할 때 사용된다.
   • Location: 페이지 리다이렉션
   • Allow: 허용 가능한 HTTP 메소드
   • Retry-Afer: 유저 에이전트가 다음 요청을 하기까지 기다려야 하는 시간

5. 인증

   • Authorization: 클라이언트 인증 정보를 서버에 전달한다.
   • WWW-Authenticate: 리소스 접근시 필요한 인증 방법을 정의한다.
   • 401 Unauthorize 응답과 함께 사용한다.

6. 쿠키 ( 중요 )

   • Set-Cookie: 서버에서 클라이언트로 쿠키를 전달한다. ( 응답 )
   • Cookie: 클라이언트가 서버에서 받은 쿠키를 저장하고, HTTP 요청 시 서버로 전달한다.
   • HTTP 는 기본적으로 무상태 프로토콜이기 때문에, 클라이언트와 서버가 요청과 응답을 주고 받은 후 연결이 끊어진다. 따라서 클라이언트가 다시 요청한다면 서버는 이전 요청을 기억하지 못한다. 즉 클라이언트와 서버는 서로 상태를 유지하지 않는 것이다. 따라서 상태를 기억하기 위해 쿠키의 개념이 생겨나게 되었다.

   
   

   • 사용자가 로그인을 하면 서버에서 세션 키를 만들어 서버의 DB 에 저장을 해두고 세션 ID 를 클라이언트에 반환해준다.
   • 세션 쿠키: 만료 날짜를 생략하면 브라우저 종료시 까지만 유지
   • 영속 쿠키 : 만료 날짜를 입력하면 해당 날짜까지 유지

HTTP 헤더 - 캐시 검증 헤더와 조건부 요청

• 캐시 유효 시간이 초과해서 서버에 다시 요청하면 다음 두 가지 상황이 나타난다.

  1. 서버에서 기존 데이터를 변경함
  2. 서버에서 기존 데이터를 변경하지 않음
  • 따라서 검증 헤더의 개념이 생겨난다.
  1. 브라우저에서 데이터를 요청하면 서버는 Last-Modified 시간을 응답에 담아 보내준다.
  2. 브라우저는 cache-control 의 유효 시간을 확인하고, 시간이 초과된 경우 캐시가 가지고 있는 데이터의 최종 수정일 요청에 담아 서버에 보낸다.
  3. 요청의 최종 수정일과 서버의 데이터 최종 수정일이 같으면 데이터가 수정되지 않은 것이다.
  4. 따라서 서버는 바디 없이 헤더에 304 Not Modified 를 응답에 담아 보낸다.
  5. 브라우저는 응답을 받고, 서버가 보낸 응답 헤더 정보로 캐시의 메타 정보를 갱신한다.
  6. 브라우저 캐시에 존재하는 데이터를 재사용한다.
  7. 결과적으로 네트워크 다운로드가 발생하지만 용량이 적은 헤더 정보만 다운로드하므로 매우 실용적인 해결책이라고 할 수 있다.

  • 검증 헤더

    • 캐시 데이터와 서버 데이터가 같은지 검증하는 데이터이다.
    • Last-Modified, ETag

  • 조건부 요청 헤더

    • 검증 헤더로 조건에 따른 분기 처리
    • If-Modified-Since: Last-Modified 사용
      • 데이터가 변경되지 않았다면?
        • 304 Not Modified, 헤더 데이터만 전송, 전송 용량 0.1M ( 헤더 )
      • 데이터가 변경되었다면?
        • 200 OK, 모든 데이터 전송 ( 바디 포함 ), 전송 용량 1.1M ( 헤더 + 바디 )
      • 만약 데이터를 수정해서 날짜가 다르지만, 같은 데이터를 수정해서 데이터의 결과가 똑같은 경우엔 어떻게하지? ETag 사용!
      • 서버에서 별도의 캐시 로직을 관리하고 싶은 경우 ( 스페이스나 주석처럼 크게 영향이 없는 변경에서 캐시를 유지하고 싶은 경우 ) 에는 어떻게하지? ETag 사용!
    • If-None-Match: ETag 사용
      • 캐시용 데이터에 임의의 고유한 버전 이름을 달아둔다.
      • 데이터가 변경되면 이 이름을 바꾸어서 Hash 를 다시 생성한다.
      • 따라서 클라이언트 입장에서 단순하게 ETag 만 보내서 같으면 유지, 다르면 다시 받기!
      • 따라서 캐시 제어 로직을 서버에서 완전히 관리한다.

REFERENCES

김영한님 모든 개발자를 위한 HTTP 웹 기본 지식