HTTP의 메시지

HTTP 프로토콜을 통해 응답을 요청하거나 받는 경우 HTTP 메시지의 형태가 넘어온다.

이 메시지를 통해 어떤 정보들이 넘어왔는지 혹은 넘어가는지를 확인하는 것

---

HTTP의 요청메시지 형태와 응답메시지 형태의 구성은 아래 그림과 같다. (출처)

ㅇ

 

먼저 HTTP의 메시지가 어떤 구조를 가지는지 부터 살펴보자! (출처)

• 요청메시지의 시작 라인에는 GET, POST 등이 들어간다.
• 공백 라인은 무조건 존재해야한다.

HTTP메시지 구조

---

시작 라인(요청메시지)

• start-line = request-line(요청메시지일 경우) / status-line(응답메시지일 경우)
• request-line = method (GET, POST 등) SP(공백) request-target(요청하는 대상의 Path) SP HTTP-version CRLF(엔터)
  • 요청메시지(HTTP 메서드)
  • 종류 : GET, POST, PUT, DELETE 등
    • GET : 리소스의 데이터를 찾아줘!
    • POST : 리소스 데이터 줄테니까 처리해줘!
    • PUT : 리소스 대체해줘! 없으면 생성해주고!
    • DELETE : 리소스 삭제해줘!
  • 요청대상
    • absolute-path[?query] (절대경로[?쿼리])
    • 보통 절대경로 ("/") 로 시작한다.
    • http://...?x=y 처럼 다른 유형의 경로지정 방법도 있다.
  • HTTP 버전
    • 마지막에는 HTTP 버전이 들어간다.

---

시작 라인(응답메시지) 

• start-line = request-line(요청메시지일 경우) / status-line(응답메시지일 경우)
• status-line = HTTP-version SP(space) status-code(상태 코드) SP reason-phrase CRLF
  • ex) HTTP/1.1 200 OK
  • → HTTP 버전 (한칸 띄고) HTTP 상태코드 (한칸 띄고) 사람이 알아볼 수 있는 간단한 이유문구 
    • HTTP 버전
    • HTTP 상태 코드 : 요청 성공, 실패를 나타냄
      • 200 : 성공
      • 400 : 클라이언트 요청 오류
      • 500 : 서버 내부 오류
  • 이유 문구 : 사람이 이해할 수 있는 짧은 상태 코드 설명 글 ex) HTTP/1.1 200 OK

---

HTTP 헤더 구조

• header-field = field-name ":" OWS field-value OWS / OWS (띄어쓰기를 허용 한다 뜻) 
  • ex) Host: www.google.com 
    1. 여기서 주의할점은 Host or host 대소문자의 구분은 상관 없다.
    2. 대신 Host (한칸 띄고) : 이렇게 사용못함 → Host: (O) Host : (X)
• field-name은 대소문자 구분 없음

---

HTTP 헤더 용도

- HTTP 전송에 필요한 모든 부가정보를 다 포함하고 있다.

   → ex) 메시지 바디 내용(뭘로 되어있는지? html인지 xml인지의 설명 등), 메시지 바디 크기, 압축(압축이 됬는지 안됬는지), 인증, 요청 클라이언트 정보(chrome으로 요청했는지 등), 서버 애플리케이션 정보, 캐시 관리 정보 등

---

 

HTTP 메시지 바디 용도

• 실제 전송할 데이터가 들어가있다.
• HTML 문서, 이미지, 영상, JSON 등등 byte로 표현할 수 있는 모든 데이터 전송 가능

HTTP 메시지 바디(파란색 부분)

 

HTTP는 메시지로도 알수 있지만 단순한 형태를 가진다.

시작하는 줄 → 머리(header) → 몸(body) → 메시지(message) 이런 형태

아직 HTTP/2, HTTP/3 보다는 1.1 버전 기준으로 공부하는게 맞다!