[HTTP 완벽 가이드] 1. HTTP: 웹의 기초 - 3장 http메세지

yoon Y·2022년 10월 17일
0

http메세지는 무언가를 담아 보내는 소포와 같다.

메세지의 흐름

http메세지는 http애플리케이션 간에 주고받는 데이터의 블록들이다.
클라이언트 - 프락시 서버 - 서버 사이를 흐른다.
인바운드, 아웃바운드, 업스트립, 다운스트림은 메세지의 방향을 이미하는 용어다.

인바운드/아웃바운드

트랜젝션 방향을 표현하기 위해 사용한다.

인바운드: 메세지가 클라이언트 → 서버로 향하는 것.
아웃바운드: 서버 → 클라이언트로 향하는 것.

업스트림/다운스트림

http메세지는 강물과 같이 흐른다.
요청 메세지나 응답 메세지냐에 관계없이 모든 메세지는 다운스트림으로 흐른다.

업스트림: 메세지 발송자
다운스트림: 메세지 수신자


메세지의 각 부분

시작줄, 헤더 블록, 본문 이렇게 세 부분으로 이루어진다.

  1. 시작줄
    • 이것이 어떤 메세지인지 서술한다.
    • 문자열로 이루어져있다.
  2. 헤더 블록
    • 속성을 담고 있다.
    • 문자열로 이루어져있다.
  3. 본문
    • 데이터를 담고 있다.
    • 있어도 되고 없어도 된다.
    • 문자열, 이진 데이터 등등 다양한 타입의 데이터를 받을 수 있다.

메세지 문법

모든 http메세지는 요청 메세지나 응답 메세지로 분류된다.
요청 메세지 - 서버에 어떤 동작을 요구한다.
응답 메세지 - 요청의 결과를 클라이언트에게 돌려준다.
시작 라인을 제외하고 두 메세지의 기본 구조는 같다.

요청 메세지
<메서드> <요청 url> <http버전>
<헤더>

<엔티티 본문>

응답 메세지
<http버전> <상태 코드> <사유 구절>
<헤더>

<엔티티 본문>

1. 시작줄

모든 http메세지는 시작줄로 시작한다.
요청 메세지의 시작줄은 무엇을 해야하는지 말해준다.
응답 메세지의 시작줄은 무슨일이 일어났는지 말해준다.

1-1. 메서드

클라이언트 측에서 서버가 리소스에 대해 수행해주길 바라는 동작이다.

  • http명세는 공통 요청 메서드의 집합을 정의한다.
  • 메서드에 따라 본문이 있는 경우도 있고 아닌 경우도 있다.
  • 서버가 http명세의 모든 메서드들을 다 구현한 것이 아닐 수 있다.
  • 명세에 있는 것을 제외하고 직접 그들만의 메서드를 추가로 구현할 수 있다. (확장 메서드)

안전한 메서드

  • http는 안전한 메서드라 불리는 메서드의 집합을 정의한다.
    안전하다는 것은 http요청의 결과로 인해 서버에서 일어나는 일은 아무것도 없다는 의미이다.
  • GET, HEAD메서드는 안전하다고 할 수 있다.
  • 안전한 메서드의 목적은 서버에 어떤 영향을 줄 수 있는 안전하지 않은 메서드가 사용될 때 사용자들에게 그 사실을 알려주는 http애플리케이션을 만들 수 있도록 하는 것에 있다. (ex-경고 메세지 띄우기)

주요 메서드 종류

GET
주로 서버에게 리소스를 달라고 요청하기 위해 쓰인다.

HEAD
GET처럼 동작하지만 응답으로 헤더만을 돌려준다.
리소스를 가져오지 않고도 그에 대한 정보를 알아낼 수 있다.
개체가 존재하는지 확인할 수 있다.
리소스가 변경되었는지 검사할 수 있다.

PUT
요청한 Url에 이름대로 서버에 새로운 문서를 생성하거나 이미 존재한다면 교체하는 것이다.

POST
서버에 입력 데이터를 전송하기 위해 사용한다.
HTML폼을 지원하기 위해 흔히 사용된다.
입력 데이터를 게이트 웨이에 보내 처리하는 등 다양한 용도(검색, 생성, 조회 등)로 사용할 수 있다.

OPTIONS
서버에게 특정 리소스에 대해 어떤 메서드가 지원되는지 물어보기 위해 사용된다.

DELETE
서버에게 요청 url로 지정한 리소스를 삭제할 것을 요청한다.
하지만 실제로 리소스가 삭제되는 것을 클라이언트가 보장받지는 못한다.
http명세는 서버가 클라이엍느에게 알리지 않고 요청을 무시하는 것을 허용하기 때문이다.

POST과 PUT의 차이
PUT과 POST의 차이는 멱등성으로 PUT은 멱등성을 가지고 POST는 멱등성을 가지지 않는다.
POST - Resouce identifier (x)
POST는 리소스의 생성을 담당한다. POST /shoes
POST는 동일한 요청을 여러번 했을 때 모든 요청에서 새로운 id로 새로운 리소스가 생성된다.
PUT - Resouce identifier (o)
PUT은 리소스의 생성과 수정을 담당한다.
PUT은 새로운 id에 대한 요청 시에만 리소스를 새로 생성하고, PUT /shoes/{존재하지 않는_SHOE_ID}
이후 같은 요청 시 갱신한다. PUT /shoes/{존재하는_SHOE_ID}

멱등성이란?
동일한 요청을 한 번 보내는 것과 여러 번 연속으로 보내는 것이 같은 효과를 지니고,
서버의 상태도 동일하게 남을 때, 해당 HTTP 메서드가 멱등성을 가졌다고 말합니다.
https://developer.mozilla.org/ko/docs/Glossary/Idempotent

1-2. 요청 url

요청 대상 리소스의 완전한 url 혹은 url의 경로 구성요소이다.
서버는 url에서 생략된 호스트/포트가 자신을 가리키는 것으로 간주한다.

1-3. 상태 코드

요청 중에 무엇이 일어났는지 클라이언트에게 설명하는 세 자리의 숫자다.

  • 각 코드의 첫번째 자릿수는 상태의 일반적인 분류('성공', '에러' 등)을 나타낸다.
  • 프로그램이 에러를 처리하기 쉽다.
200~299: 요청 성공
300~399: 리소스가 옮겨짐
400~499: 클라이언트가 뭔가 잘못된 요청을 했음
500~599: 서버에서 뭔가 실패했음

현재 버전의 HTTP는 각 상태 분류에 대해 적은 수의 코드만을 정의했다. (앞으로 더 정의될 것)
정의된 코드들을 제외하고는 직접 의미를 정의해서 사용할 수 있다.

HTTP 상태 코드 상세

1-4. 사유 구절

숫자로 된 상태 코드의 의미를 사람이 이해할 수 있게 설명해주는 짧은 문구이다.

  • 상태 코드와 일대일로 대응한다.
  • 오로지 사람에게 읽히기 위한 목적으로 개발자들이 정의한다.
  • 같은 코드라도 사유 구절이 다를 수 있다.
    예) 'HTTP/1.0 200 NOT OK', 'HTTP/1.0 200 OK'는 사유 구절이 다르지만
    동등하게 요청 성공을 의미하는 것으로 처리되어야 한다.
  • http명세는 사유구절에 대한 어떤 엄격한 규칙도 제공하지 않는다.

1-5. 버전 번호

http애플리케이션들이 자신이 따르는 프로토콜의 버전을 상대방에게 말해주기 위한 수단이 된다.
버전 번호는 http로 대화하는 애플리케이션들에게 대화 상대의 능력메세지의 형식에 대한 단서를 주기 위한 것이다.

다른 버전 간의 통신 시 주의할 점

  1. 낮은 버전과 통신하는 높은 버전의 애플리케이션은 높은 버전의 새로운 기능을 사용할 수 없다.
    → http 1.1버전 애플리케이션과 대화하는 http 1.2버전 애플리케이션은 1.2버전의 새로운 기능을 사용할 수 없다.

  2. 버전 번호는 어떤 애플리케이션이 지원하는 가장 높은 http버전을 가리킨다.
    → http 1.1을 명시한 애플리케이션은 http 1.0 ~ http 1.1까지 모두 이해할 수 있는 것.


2. 헤더

2-1. 헤더의 분류

  1. 일반 헤더

    • 메세지에 대한 아주 기본적인 정보를 제공하며 요청과 응답 양쪽에 모두 나타날 수 있다.
    • Date, Connection, Cache-Control...
  2. 요청 헤더

    • 클라이언트에 대한 정보, 선호, 능력같은 요청에 대한 부가 정보를 제공한다.
    • 서버가 더 나은 응답을 주기 위해 활용할 수 있다.
    • Accept관련 - Accept, Accept-Charset, Accept-Encoding, Accept-Lenguage
    • 조건부 요청 관련 - Expect, If-Match, If-Range, If-Modifiled-Since
    • 요청 보안 관련 - Authorization, Cookie
  3. 응답 헤더

    • 서버에 대한 정보, 능력, 응답에 대한 특별한 설명 등 부가 정보를 클라이언트에게 제공한다.
    • 클라이언트가 응답을 잘 다루고 후에 더 나은 요청을 할 수 있도록 도와준다.
    • Age, Public, Server, Retry-After
    • 다양한 리소스에 대한 협상 헤더 - Accept-Ranges, Vary
    • 응답 보안 헤더 - set-Cookie, WWW-Authenticate
  4. 엔티티 헤더

    • 리소스의 본문 크기와 콘텐츠 같은 리소스 자체 정보 혹은 그 외에 리소스에 대한 광범위한 정보를 제공한다.
    • Allow, Location
    • 콘텐츠 관련 - Content-Type, Content-Encoding, Content-Lenguage, Content-Length
    • 캐싱 관련 - ETag, Expires, Last-Modified

2-2. 헤더 필드

요청과 응답 메세지에 추가 정보를 더한다.
헤더는 0개 이상의 헤더 필드들로 이루어져있다.

구성
헤더 필드는 이름, 콜론(:), 선택적인 공백, 값, CRLF(줄바꿈)으로 이루어져 있다.
헤더 블록은 빈줄로 끝나 헤더 목록의 끝과 엔티티 본문의 시작을 표시한다.

3. 엔티티 본문

엔티티 본문은 http메시지의 화물이라고 할 수 있다.
이미지, 비디오, html문서, 소프트웨어, 신용카드 트랜잭션, 전자우편 등 여러 종류의 디지털 데이터를 실어 나를 수 있다.

profile
#프론트엔드

0개의 댓글