Diiiiiikey

Blog

HTTP 특징

  • 클라이언트 서버 구조
    • Request/Response 구조
    • 클라이언트가 서버에 요청, 응답대기
    • 서버는 요청에 대한 결과를 만들어 응답
  • 무상태 프로토콜(Stateless)
    • 서버가 클라이언트의 상태 보존 안함
      • 서버 확장성(스케일 아웃) - 클라이언트 요청이 증가해도 서버 대거 투입 가능
      • 클라이언트 추가 데이터 전송 필요(필요한 데이터를 한번에 모두 담아서 전송)
      • 응답 서버를 쉽게 바꿀 수 있음(Stateful - 상태유지를 한다면 특정 서버가 기억하고 항상 답해야 함 - 서버에 장애가 발생한다면..)
      • 로그인이 필요한 서비스 - 브라우저 쿠키, 서버 세션, 토큰 등으로 상태 유지.
  • 비연결성(Connectionless)
    • TCP/IP의 경우 기본적으로 연결 유지 - 연결을 유지하는 모델에서 클라이언트들이 요청을 보내지 않아도 연결이 유지되기 때문에 서버 자원이 소모됨
    • HTTP는 요청을 주고받을 때만 연결을 유지, 응답을 주고 나면 TCP/IP 연결을 끊음.
    • 일반적으로 초 단위 이하의 빠른 응답 속도
    • 트래픽이 많고, 큰 규모의 서비스를 운영할 때 비연결성은 한계를 보임
      • 연결을 새로 함 - 3 way handshake 시간 추가
      • HTML, CSS, JS 등 다른 자원 추가 다운로드
      • HTTP 지속 연결(Persistent Connections)로 문제 해결
  • HTTP 메세지
  • 단순함, 확장가능

표현 헤더(Representation Headers)

HTTP 메시지는 헤더와 바디로 구분

Message Body - RFC7230(최신)

HTTP 헤더와 바디


  • 메시지 본문을 통해 표현(Representation) 데이터 전달
  • 메시지 본문 = 페이로드(payload)
  • 표현은 요청이나 응답에서 전달할 실제 데이터
  • 표현 헤더는 표현 데이터를 해석할 수 있는 정보 제공
    • 데이터 유형(html, json), 데이터 길이, 압축 정보 등
HTTP 헤더


헤더 형식

  • <field-name> : <field-value>
  • 대소문자 구분 없음

헤더 용도

  • HTTP 전송에 필요한 모든 부가정보
    • e.g. 메시지 바디 내용, 바디 크기, 압축, 인증, 요청 클아이언트, 서버 정보, 캐시 관리 정보 등
  • 표준 헤더가 너무 많음 https://en.wikipedia.org/wiki/List_of_HTTP_header_fields
  • 필요시 임의의 헤더 추가 기능

Content-Type - 표현 데이터의 형식
Content-Encoding - 표현 데이터의 압축 방식
Content-Language - 표현 데이터의 자연 언어
Content-Length - 표현 데이터의 길이

표현 헤더는 요청, 응답 둘 다 사용

Content-Type

Content-Encoding

Content-Language

  • 표현 데이터 자연 언어
    • e.g.
      • Content-Language: ko
      • Content-Language: en
      • Content-Language: en-US

Content-Length

  • 표현 데이터 길이

  • 바이트 단위

    • e.g.
      • Content-Length: 5
  • Transfer-Encoding(전송 코딩)을 사용하면 사용하면 안됨
    • 전송 시 어떤 인코딩 방법을 사용할 지 명시.
    • 현재는 Transfer-Encoding보다는 Content-Encoding을 사용.
    • Transfer-Encoding을 사용하는 경우 chunked의 방식으로 사용.

요청(Request)에서 사용되는 헤더

HTTP 요청/응답 주요 헤더


  • From - 유저 에이전트의 이메일 정보
    • 일반적으로 잘 사용하지 않음
    • 검색 엔진에서 주로 사용
  • Referer: 이전 웹 페이지 주소
    • 현재 요청된 페이지의 이전 웹 페이지 주소
    • A → B로 이동하는 경우 B를 요청할 때 Referer: A를 포함해서 요청
    • Referer를 사용하면 유입경로 수집 가능
    • Referer는 단어 Referrer의 오탈자이지만 스펙으로 굳어짐
  • User-Agent - 유저 에이전트 애플리케이션 정보
    • 클라이언트의 애플리케이션 정보(웹 브라우저 정보, 등등)
    • 통계 정보
    • 어떤 종류의 브라우저에서 장애가 발생하는지 파악 가능
      • e.g.
        • user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/
        • 537.36 (KHTML, like Gecko) Chrome/86.0.4240.183 Safari/537.36
  • Host: 요청한 호스트 정보(도메인)
    • 필수 헤더
    • 하나의 서버가 여러 도메인을 처리해야 할 때 호스트 정보를 명시하기 위해 사용
    • 하나의 IP 주소에 여러 도메인이 적용되어 있을 때 호스트 정보를 명시하기 위해 사용
  • Origin: POST 요청시, 요청을 시작한 주소를 나타냄
    • 요청을 보낸 주소와 받는 주소가 다르면 CORS 에러
    • 응답 헤더의 Access-Control-Allow-Origin와 관련
  • Authorization: 인증 토큰(e.g. JWT)을 서버로 보낼 때 사용하는 헤더
    • “토큰의 종류(e.g. Basic) + 실제 토큰 문자”를 전송
      • e.g.
        • Authorization: Basic YWxhZGRpbjpvcGVuc2VzYW1l

응답(Response)에서 사용되는 헤더

  • Server: 요청을 처리하는 ORIGIN 서버의 소프트웨어 정보
    • e.g.
      • Server: Apache/2.2.22 (Debian)
      • Server: nginx
  • Date: 메시지가 발생한 날짜와 시간
    • e.g.
    • Date: Tue, 15 Nov 1994 08:12:31 GMT
  • Location: 페이지 리디렉션
    • 웹 브라우저는 3xx 응답의 결과에 Location 헤더가 있으면, Location 위치로 리다이렉트(자동 이동)
    • 201(Created): Location 값은 요청에 의해 생성된 리소스 URI
    • 3xx(Redirection): Location 값은 요청을 자동으로 리디렉션하기 위한 대상 리소스를 가리킴
  • Allow: 허용 가능한 HTTP 메서드
    • 405(Method Not Allowed)에서 응답에 포함
      • e.g.
        • Allow: GET, HEAD, PUT
  • Retry-After: 유저 에이전트가 다음 요청을 하기까지 기다려야 하는 시간
    • 503(Service Unavailable): 서비스가 언제까지 불능인지 알려줄 수 있음
      • e.g.
        • Retry-After: Fri, 31 Dec 2020 23:59:59 GMT(날짜 표기)
        • Retry-After: 120(초 단위 표기)
  • https://en.wikipedia.org/wiki/List_of_HTTP_header_fields

콘텐츠 협상 헤더

협상 헤더는 요청 시에만 사용

  • Accept - 클라이언트가 선호나는 미디어 타입 전달
  • Accept-Charset - 클라이언트가 선호하는 문자 인코딩
  • Accept-Encoding - 클라이언트가 선호하는 압축 인코딩
  • Accept-Language - 클라이언트가 선호하는 자연 언어

Get /event
Accept-Language: ko 라고 작성하면 한국어 응답을 돌려줌

내가 선호하는 것이 없을 때를 대비해 우선순위를 정하는 법

Get /event
Accept-Language: ko-KR,ko;q=0.9,en-US;q=0.8,en;q=0.7

댓글남기기

참고