HTTP는 텍스트 기반의 통신규약 즉, Hyper Text Transfer Protocol의 두문자어로, "인터넷에서 데이터를 주고받을 수 있는 프로토콜"입니다. 이렇게 규약을 정해두었기 떄문에 모든 프로그램이 이 규약에 맞춰 개발해서 서로 정보를 교환할 수 있게 되었습니다.
HTTP를 가장 많이 사용하는 개발자는 단언컨데 웹 개발자일 것입니다. 따라서 웹 개발자라면 HTTP에 대해서 잘 알고 있어야 하지만, 많이들 HTTP를 간과하고 있습니다. 백엔드 개발자는 좀 덜하지만, 프론트엔드 개발자는 HTTP를 모르는 경우가 부지기수입니다. 하지만 프론트엔드 개발자의 역할 중 하나가 서버로 데이터를 전송하는 것이기 때문에, HTTP를 모른다면 역할을 다하고 있다고 말할 수 없습니다.
에러를 해결하는데도 HTTP 지식이 중요합니다. 데이터를 주고 받을 때 흔히 발생하는 CORS, CORB 같은 에러들은 HTTP만 잘 알아도 쉽게 해결할 수 있습니다.
HTTP 동작
클라이언트 즉, 사용자가 브라우저를 통해서 어떠한 서비스를 URL을 통하거나 다른 것을 통해서 요청(Request)를 하면 서버에서는 해당 요청사항에 맞는 결과를 찾아서 사용자에게 응답(Response)하는 형태로 동작합니다.
- 요청 : client -> server
- 응답 : server -> client
HTML 문서만이 HTTP 통신을 위한 유일한 정보 문서는 아닙니다. Plain Text로 부터 JSON 데이터 및 XML과 같은 형태의 정보도 주고 받을 수 있으며, 보통은 클라이언트가 어떤 정보를 HTML형태로 받고 싶은지, JSON 형태로 받고 싶은지 명시해주는 경우가 많습니다.
HTTP 특징
- HTTP 메시지는 HTTP 서버와 HTTP 클라이언트에 의해 해석이 된다.
- TCP/IP를 이용하는 응용 프로토콜이다.
- HTTP는 연결 상태를 유지하지 않는 비연결성 프로토콜이다. (이러한 단점을 해결하기 위해 Cookie와 Session이 등장하였다.)
- HTTP는 연결을 유지하지 않는 프로토콜이기 떄문에 요청/응답 방식으로 동작한다.
- 서버(Server) : 어떠한 자료에 대한 접근을 관리하는 네트워크 상의 시스템 (요청에 대한 응답을 보내준다.)
- 클라이언트 : 그 자료에 접근할 수 있는 프로그램 / Ex) 웹 브라우저, 핸드폰 어플리케이션 등.....
클라이언트 프로그램에서 사용자가 회원가입을 시도하게 되면, 서버로 회원정보를 보내게 되고 서버는 회원 정보를 저장해주기도 한다. 이 과정에서 클라이언트와 서버 간의 교류가 HTTP라는 규약을 이용하여 발생하게 된다.
Request (요청)
클라이언트가 서버에게 연락하는 것을 요청이라고 하며 요청을 보낼때는 요청에 대한 정보를 담아 서버로 보냅니다.
HTTP Request Method(요청 메소드)
- GET : 특정 리소스의 표시를 요청합니다. GET을 사용하는 요청은 오직 데이터를 받기만 합니다.
- HEAD : GET 메소드의 요청과 동일한 응답을 요구하지만, 응답 본문을 포함하지 않습니다.
- POST : 특정 리소스에 엔티티(개체)를 제출할 때 쓰입니다. 이는 종종 서버의 상태의 변화나 부작용을 일으킵니다.
- PUT : 목적 리소스 모든 현재 표시를 요청 payload(전송되는 데이터)로 바꿉니다.
- DELETE : 특정 리소스를 삭제합니다.
- CONNECT : 목적 리소스로 식별되는 서버로의 터널을 맺습니다.
- OPTIONS : 목적 리소스의 통신을 설정하는 데 쓰입니다.
- TRACE : 목적 리소스의 경로를 따라 메시지 Loop-Back 테스트를 합니다.
- PATCH : 리소스의 부분만을 수정하는 데 쓰입니다.
Request (응답)
서버가 요청에 대한 답변을 클라이언트에게 보내는 것을 응답이라고 합니다.
HTTP Response Code (응답 코드)
- 1xx (조건부 응답) : 요청을 받았으며 작업을 계속합니다.
- 2xx (성공) : 클라이언트가 요청한 동작을 수신하여 이해했고 승낙했으며 성공적으로 처리했음을 가리킵니다.
- 3xx (리다이렉션 완료) : 클라이언트는 요청을 마치기 위해 추가 동작을 취해야 합니다.
- 4xx (요청 오류) : 클라이언트에 오류가 있음을 나타냅니다.
- 5xx (서버 오류) : 서버가 유효한 요청을 명백하게 수행하지 못했음을 나타냅니다.
HTTP Message
- 서버(Server)와 클라이언트(Client)가 HTTP 통신을 할때 주고 받는 메세지입니다.
- 클라이언트가 서버에게 자료를 요청하는 메세지는 "Request Message"라고 합니다.
- 서버가 클라이언트에게 요청에 대한 응답 메세지는 "Response Message"라고 합니다.
HTTP 요청과 응답의 구조는 서로 닮았으며, 그 구조는 다음과 같습니다.
- 시작 줄(Start-line)에는 실행되어야 할 요청, 또는 요청 수행에 대한 성공 또는 실패가 기록 되어 있습니다. 이 줄은 항상 한줄로 끝납니다.
- 옵션으로 HTTP 헤더 세트가 들어갑니다. 여기에는 요청에 대한 설명, 혹은 메세지 본문에 대한 설명이 들어갑니다.
- 요청에 대한 모든 메타 정보가 전송되었음을 알리는 빈 줄(Blank Line)이 삽입됩니다.
- 요청과 관련된 내용(HTML 폼 콘텐츠 등)이 옵션으로 들어가거나, 응답과 관련된 문서(document)가 들어갑니다. 본문의 존재 유무 및 크기는 첫 줄과 HTTP 헤더에 명시됩니다.
HTTP메세지의 시작 줄과 HTTP 헤더를 묶어서 요청 헤드(Head)라고 부르며, 이와 반대로 HTTP 메세지의 페이로드는 본문(Body)이라고 부릅니다.
HTTP 요청
시작줄 (첫 줄)
HTTP 요청은 서버가 특정 동작을 취하게끔 만들기 위해 클라이언트에서 전송하는 메세지입니다. 시작 줄은 다음과 같이 이 세 가지 요소로 이루어져 있습니다.
- 첫번쨰는 HTTP 메소드로, GET, PUT, POST, HEAD, OPTIONS 등을 사용하여 서버가 수행해야 할 동작을 나타냅니다. 예를 들어 GET은 리소스를 클라이언트로 가져다 달라는 것을 뜻하며, POST는 데이터가 서버로 들어가야 함을 의미(리소스를 새로 만들거나 수정하기 위해, 또는 클라이언트로 돌려 보낼 임시 문서를 생성하기 위해)합니다.
- 두 번째로 오는 요청 타겟은 주로 URL, 또는 프로토콜, 포트, 도메인의 절대 경로로 나타낼 수 있으며 이들은 요청 컨텍스트에 의해 특정지어 집니다. 요청 타겟 포맷은 HTTP 메소드에 따라 달라집니다. 포맷에는 다음과 같은 것들이 있습니다.
-Origin 형식 : 끝에 '?'와 쿼리 문자열이 붙는 절대 경로입니다. 이는 가장 일반적인 형식이며, GET, POST, HEAD, OPTIONS 메소드와 함께 사용합니다.
POST / HTTP 1.1
GET /background.png HTTP/ 1.0
HEAD /test.html?query=alibaba HTTP/1.1
OPTIONS / anypage.html HTTP/1.0
-absolute 형식 : 완전한 URL 형식입니다. 프록시에 연결하는 경우 대부분 GET과 함께 사용됩니다.
GET http://usefultoknow.tistory.com/en-ko/docs/web/HTTP/Messages HTTP/1.1
-authority 형식 : 도메인 이름 및 옵션 포트(':'가 앞에 붙습니다)로 이루어진 URL의 authority component 입니다. HTTP 터널을 구축하는 경우에만 CONNECT와 함께 사용할 수 있습니다.
CONNECT developer.mozilla.org:80 HTTP/1.1
-asterisk 형식 : OPTIONS와 함께 별표('*') 하나로 간단하게 서버 전체를 나타냅니다.
OPTIONS * HTTP/1.1 - 마지막으로 HTTP 버전이 들어갑니다. 메시지의 남은 구조를 결정하기 때문에 응답 메세지에서 써야 할 HTTP 버전을 알려주는 역할을 합니다. / Ex) HTTP/1.0, HTTP/1.1.....
헤더
요청에 들어가는 HTTP 헤더는 HTTP 헤더의 기본 구조를 따릅니다. 대소문자 구분없는 문자열 다음에 콜론(':')이 붙으며, 그 뒤에 오는 값은 헤더에 따라 달라집니다. 헤더는 값까지 포함해 한 줄로 구성되지만 꽤 길어질 수 있습니다.
다양한 종류의 요청 헤더가 있는데, 이들은 다음과 같이 몇몇 그룹으로 나눌 수 있습니다.
| General 헤더 | 메세지 전체에 적용됩니다. |
| Request 헤더 | User-Agent, Accept-Type와 같은 헤더는 요청의 내용을 좀 더 구체화 시키고(Accept-Language), 컨텍스를 제공하기도 하며(Referer), 조건에 따른 제약 사항을 가하기도 하면서(If-None) 요청 내용을 수정합니다. |
| Entity 헤더 | Content-Length와 같은 헤더는 요청 본문에 적용됩니다. 당연히 요청 내에 본문이 없는 경우 Entity헤더는 전송되지 않습니다. |
본문
본문은 요청의 마지막 부분에 들어갑니다. 모든 요청에 본문이 들어가지는 않습니다. GET, HEAD, DELETE, OPTIONS 처럼 리소스를 가져오는 요청은 보통 본문이 필요 없습니다. 일부 요청은 업데이트를 하기 위해 서버에 데이터를 전송합니다. 보통(HTML 폼 데이터를 포함하는)POST 요청일 경우에 그렇습니다.
넓게 보면 본문은 두가지 종류로 나뉩니다.
- 단일-리소스 본문(Single-Resource bodies) : 헤더 두 개(Content-Type와 Content-Length)로 정의된 단일 파일로 구성됩니다.
- 다중-리소스 본문(Multiple-Resource bodies) : 멀티파트 본문으로 구성되는 다중 리소스 본문에서는 파트마다 다른 정보를 지니게 됩니다. 보통 HTML 폼과 관련이 있습니다.
HTTP 응답
상태 줄
HTTP 응답의 시작 줄은 상태 줄(Status Line)이라고 불리며, 다음과 같은 정보를 가지고 있습니다.
- 프로토콜 버전 : 보통 HTTP/1.1 입니다.
- 상태 코드 : 요청의 성공 여부를 나타냅니다. 보통 200, 404 혹은 302입니다.
- 상태 텍스트 : 짧고 간결하게 상태 코드에 대한 설명을 글로 나타내어 사람들이 HTTP 메세지를 이해할 때 도움이 됩니다.
상태 줄은 일반적으로 HTTP/1.1 404 Not Found. 같이 생겼습니다.
헤더
응답에 들어가는 HTTP 헤더는 다른 헤더와 동일한 구조를 따릅니다. 대소문자를 구분하지 않는 문자열 다음에 콜론(':')이 오며, 그 뒤에 오는 값은 구조가 헤더에 따라 달라집니다. 헤더는 값을 포함해 전체를 한 줄로 표시합니다.
다양한 종류의 응답 헤더가 있는데, 이들은 다음과 같이 몇몇 그룹으로 나눌 수 있습니다.
| General 헤더 | 메세지 전체에 적용됩니다. |
| Response 헤더 | Accept-Ranges와 같은 헤더는 상태 줄(Status Line)에 미처 들어가지 못했던 서버에 대한 추가 정보를 제공합니다. |
| Entity 헤더 | Content-Length와 같은 헤더는 요청 분문에 적용됩니다. 당연히 요청 내에 본문이 없는 경우 Entity 헤더는 전송되지 않습니다. |
본문
본문은 응답의 마지막 부분에 들어갑니다. 모든 응답에 본문이 들어가지는 않습니다. 201, 204와 같은 상태 코드를 가진 응답에는 보통 본문이 없습니다.
넓게 보면 본문은 세가지 종류로 나뉩니다.
- 이미 길이가 알려진 단일 파일로 구성된 단일-리소스 본문 : 헤더 두개(Content-Type 와 Content-Length)로 정의 합니다.
- 길이를 모르는 단일 파일로 구성된 단일-리소스 본문 : Transfer-Encoding이 Chunked로 설정되어 있으며, 파일은 청크로 나뉘어 인코딩 되어 있습니다.
- 서로 다른 정보를 담고 있는 멀티파트로 이루어진 다중 리소스 본문 : 이 경우는 상대적으로 위의 두 경우에 비해 보기 힘듭니다.
출처
developer.mozilla.org/ko/docs/Web/HTTP/Messages
developer.mozilla.org/ko/docs/Web/HTTP/Methods
velog.io/@surim014/HTTP%EB%9E%80-%EB%AC%B4%EC%97%87%EC%9D%B8%EA%B0%80
ko.wikipedia.org/wiki/HTTP_%EC%83%81%ED%83%9C_%EC%BD%94%EB%93%9C
댓글