HTTP #1 HTTP 메시지

질문, 피드백 등 모든 댓글 환영합니다.

HTTP는 데이터를 전송하는 방식 중 하나입니다.
인터넷에서 일어나는 대부분의 통신은 HTTP를 사용합니다.
텍스트, 사진, 영상, API, HTML까지 byte로 표현 가능한 모든 것을 HTTP를 사용하여 전송합니다.

HTTP (HyperText Transfer Protocol) 메시지

HTTP는 클라이언트 - 서버 (Request - Response) 구조로 이루어져 있습니다.

클라이언트는 서버에 요청을 보내고 서버는 요청에 맞는 결과를 응답합니다. 이 때 전송할 데이터는 HTTP 메시지에 담아 전송합니다.

HTTP 메시지는 start-line, header, message body로 구성되어 있으며 header와 message body 사이는 공백(CRLF)이 존재해야 합니다.

start line (시작 라인)

HTTP 요청 메시지에서 시작 라인(request line)은 서버가 수행해야 할 동작을 제어할 데이터가 포함됩니다.

requset line 구조는 HTTP method (공백) request-target (공백) HTTP-version으로 이루어집니다.

request-target은 절대 경로와 ?query로 표현합니다.

ex) GET /members?hl=ko HTTP/1.1

HTTP 응답 메시지에서 시작 라인(response line) 구조는
HTTP-version (공백) status-code (공백) reason-phrase 로 이루어집니다.

status-code는 요청에 따른 서버의 수행 결과를 나타냅니다.

reason-phrase는 사람이 이해가능한 짧은 글로 나타냅니다.

ex) HTTP/1.1 200 OK

HTTP header (헤더)

헤더는 HTTP 전송에 필요한 부가 정보를 포함합니다.
메시지 바디의 내용, 크기, 압축, 인증, 브라우저 정보, 캐시 관리 정보 등 수많은 내용이 포함될 수 있습니다.

헤더의 구조는 field-name ":" OWS field-value OWS (OWS:띄어쓰기 허용)로 이루어집니다.

사용되는 헤더가 너무 많아 자세한 부분은 위키피디아 부탁드립니다.

자주 사용하는 헤더 위주로 간단히 정리해보겠습니다.

• 표현 헤더 / 요청, 응답 모두 사용

  • Content-Type : 표현 데이터의 형식 ex) text/html;charset=UTF-8, application/json, image/png 등
  • Content-Encoding : 표현 데이터의 압축 방식 ex) gzip, deflate, identity
  • Content-Language : 표현 데이터의 자연 언어
  • Content-Length : 표현 데이터의 길이

• 협상(content negotiation) 헤더 : 클라이언트가 선호하는 표현 요청(요청 시에 사용)

  • Accept : 클라이언트가 선호하는 미디어 타입 전달
  • Accept-Charset : 문자 인코딩 방식
  • Accept-Encoding : 압축 인코딩 방식
  • Accept-Language : 자연 언어
    
    
  • 이들은 우선순위 Quality Values(q) 지정 가능. 0~1, 클수록 높은 우선순위(1은 생략)
    ex) Accept-Language: ko-KR,ko;q-0.9,en-US;q=0.8,en;q=0.7
    • ko-KR;q=1 (q 생략)
    • ko;q=0.9
    • en-US;q-0.8
    • en;q=0.7
  • 또는 구체적으로 명시 된 것을 우선시 함
    ex) Accept: text/*, text/plain, text/plain;format=flowed
    1. text/plain;format=flowed
    2. text/plain
    3. text/*
    

• 일반 정보 (요청에서 사용)

  • Host : 요청한 호스트 정보(도메인), 필수 정보, 하나의 서버가 여러 도메인을 처리하거나 하나의 IP주소에 여러 도메인이 적용되어 있을 때 필요
  • Referer : 이전 웹 페이지 주소, 유입 경로 분석 (Referer는 Referrer의 오타..)
  • User-Agent : 유저 에이전트 애플리케이션 정보, 클라이언트의 애플리케이션 정보(웹 브라우저, OS 등), 어떤 브라우저에서 장애가 발생하는지 파악 가능
  • Authorization : 클라이언트 인증 정보를 서버에 전달
  • From : 유저 에이전트의 이메일 정보

• 일반 정보 (응답에서 사용)

  • Server : 요청을 처리하는 오리진 서버의 소프트웨어 정보
  • Date : 메시지가 생성된 날짜
  • Location : 리다이렉트시 사용, Location 위치로 자동 이동
  • Allow : 허용 가능한 HTTP 메서드, 405 error에서 응답에 포함
  • Retry-After : 503 error에서 다음 요청을 하기까지 기다려야 할 시간
  • WWW-Authenticate : 리소스 접근시 필요한 인증 방법 정의

• 쿠키 정보

  • Set-Cookie : 응답에서 사용, 서버에서 클라이언트로 쿠키 전달
  • max-age : 초 단위 유효 시간
  • domain : 쿠키가 적용되는 위치
    명시할 경우 도메인 + 서브도메인에서 적용
    생략할 경우 현재 문서 기준 도메인에서만 적용
  • path : 이 경로를 포함한 하위 경로 페이지에서만 적용
  • Cookie : 클라이언트가 서버에서 받은 쿠키를 저장하고 HTTP 요청시 서버로 전달

• 캐시 정보

  • Cache-Control : 캐시 지시어
  • max-age : 초 단위 유효 시간
  • no-cache : 캐시해도 되지만 항상 오리진 서버에 검증하고 사용
  • must-revaildate : 캐시 만료 후 최초 조회시 오리진 서버에 검증
  • no-store : 저장하면 안됨(메모리에서만 사용하고 바로 삭제)
  • public : 응답이 public 캐시에 저장되어도 됨
  • private : 응답이 해당 사용자만을 위한 것으로 private 캐시에 저장해야 함 (디폴트)
  • s-maxage : 프록시 캐시에 적용되는 max-age

• 검증 헤더

  • Last-Modified : 데이터가 마지막에 수정된 시간
  • If-Modified-Since, If-Unmodified-Since : Last-Modified 값 사용해 비교
  • ETage : 캐시용 데이터의 고유한 버전 (데이터는 수정 되었지만 결과는 다르지 않을 때(주석 처리 등) 유용)
  • If-Match, If-None-Match : ETag 값 사용해 비교

HTTP Message Body (메시지 바디)

HTTP 메시지 바디는 실제로 전송할 데이터를 포함합니다.
HTML, JSON, API, 문서, 이미지 등 byte로 표현 가능한 모든 데이터 전송이 가능합니다.

Stateless (무상태 프로토콜)

HTTP 요청과 응답은 무상태로 이루어집니다.

즉 클라이언트가 보낸 요청은 응답이 발생함에 따라 상태가 사라집니다

예를 들어 클라이언트가 HTTP 요청으로 @gudwn357회원의 http0 을 요청하고 다시 HTTP 요청으로 http1을 전달하게 된다면 서버는 이를 인지하지 못합니다.
첫 요청에 포함한 @gudwn357에 대한 정보를 유지하지 않기 때문에 두 번째 요청에서도 이를 포함해야합니다.

때문에 클라이언트가 보다 많은 정보를 전송해야 한다는 단점이 있습니다.

서버가 상태를 유지하는 방향으로 프로토콜이 설계되어 있다면 클라이언트는 보다 적은 정보를 전송하면 되므로 편할 수 있겠지만 한 번 연결된 서버가 그 정보를 계속 유지해야 하므로 서버의 부담이 증가하고 또한 같은 서버로 계속 요청을 받아야 하므로 효율적이지 못합니다. 즉 무상태 프로토콜을 이용하면 요청 받는 서버의 제약이 없어지므로 응답 서버를 쉽게 바꿀 수 있어 서버 확장 시 용이합니다.

하지만 모든 정보를 무상태로 유지할 수는 없습니다. 로그인 등의 정보는 유지 되어야 하므로 이럴 때는 브라우저의 쿠키와 서버 세션 등을 활용하여 상태를 유지합니다.