현재 HTTP 메시지에 모든 것을 전송
- HTML, TEXT
- 이미지, 음성, 영상, 파일
- JSON, XML (API)
거의 모든 형태의 데이터 전송 가능하며, 서버 간에 데이터를 주고 받을 때도 대부분 HTTP 를 사용한다.
HTTP 역사
- HTTP/0.9 1991 년 - GET 메서드만 지원, HTTP 헤더 없음
- HTTP/1.0 1996 년 - 메서드, 헤더 추가
- HTTP/1.1 1997년 - 현재 사용하는 대부분의 기능 지원 (가장 많이 사용)
- HTTP/2 2015년 - 성능 개선
- HTTP/3 진행중 - TCP 대신에 UDP 사용 (성능 개선)
HTTP/1.1 이 현재 가장 많이 사용되며 대부분의 기능들을 모두 제공하고 있다.
HTTP/2 와 HTTP/3 는 성능 개선에 중점을 두고 있다.
HTTP 기반 프로토콜
- TCP - HTTP/1.1, HTTP/2
- UPD - HTTP/3
현재 HTTP/1.1 주로 사용하고 있지만, HTTP/2 와 HTTP/3 도 점점 증가하는 추세이다.
HTTP 특징
- 클라이언트 서버 구조
- 무상태 프로토콜(스테이스리스), 비연결성
- HTTP 메시지
- 단순함, 확장 가능
클라이언트 - 서버 구조
클라이언트 서버 구조는 클라이언트가 서버에 요청을 보내고, 응답을 받을 때까지 대기하는 구조를 말한다.
이때 서버는 클라이언트가 보낸 요청에 맞는 결과를 만들어서 응답한다.
이러한 구조는 양쪽 사이드가 독립적으로 진화 및 발전할 수 있도록 해준다.
클라이언트와 서버 쪽 목적이 서로 다르기에 이렇게 독립적으로 진화 시킬 수 있는 것이다.
클라이언트의 경우 UI 와 UX, 서버의 경우 복잡한 데이터 처리와 비즈니스 로직 에만 목적을 두고 개발되는 것이다.
Stateless 무상태
무상태란 클라이언트에 대한 상태(State)를 따로 저장하지 않는다는 것을 의미한다.
반면에, Stateful 상태 유지의 경우 클라이언트에 대한 정보를 유지하고 요청에 대해 응답하는 경우를 뜻한다.
상태 유지의 경우 고객의 요청마다 응답에 필요한 데이터를 매번 보내지 않아도 되는 장점이 있지만,
해당 고객에 대한 정보를 가지고 있는 같은 서버가 항상 유지되어야 하는 문제점이 있다.
즉, 해당 서버가 장애가 발생하면 다른 서버는 그 고객에 대한 정보가 없기에 요청에 응답해줄 수 없다.
무상태의 경우 클라이언트가 매번 응답에 필요한 데이터를 함께 요청하기 때문에,
어떤 서버라도 해당 요청에 대해서 응답할 수 있다는 장점을 가지고 있다.
이러한 장점을 기반으로 무상태인 경우 스케일 아웃을 효과적으로 가져갈 수 있다.(서버 증설, 수평 확장에 유리)
그렇지만, 무상태의 경우 매번 클라이언트의 정보를 요청 받는다는 단점이 역시 존재하며,
실무에선 모든 서비스를 무상태로 설계할 수도 있지만 상태 정보를 가져가야할 경우도 반드시 존재한다.(로그인 서비스)
따라서, 완벽한 무상태 서비스를 만들 순 없지만 쿠키나 세션 등을 사용해서 최소한의 상태만을 유지하는 것이 베스트이다.
Connectionless 비 연결성
HTTP 는 기본적으로 연결을 유지하지 않는 모델이다.
따라서, 클라이언트로부터 요청이 왔을 때 연결하고 이에 응답하고 난 후에 서버는 해당 연결을 바로 끊는다.
이를 통해 서버는 최소한의 자원만을 유지할 수 있게 된다.
만약, 모든 요청에 대해 연결을 끊지 않고 유지한다면,
서버의 자원은 유지한 연결 개수만큼 자원을 지속적으로 소모하게 된다.
일반적으로 1시간 동안 수천명이 서비스를 사용해도 실제 서버에서 동시 처리하는 요청은 수십개 이하로 매우 작다.
따라서, 비 연결성을 통해 서버 자원을 매우 효율적으로 사용할 수 있게 된다.
다만, 비 연결성인 경우엔 클라이언트의 요청마다 매번 TCP/IP 연결을 해야하는데,
이 과정에서 3 way handshake 시간이 추가된다.
웹 브라우저의 경우 요청 때마다 html 뿐만 아니라 js, css, 이미지 등 수많은 자원을 매번 다운로드하게 된다.
이러한 비 연결성의 문제점들을 현재는 HTTP 지속 연결(Persistent Connections) 로 문제 해결하고 있고,
HTTP/2, HTTP/3 에서는 이 부분이 많이 최적화 되고 있다.
HTTP 메시지
 |
 |
HTTP 메시지 구조 및 공식 스펙 - datatracker.ietf.org/doc/html/rfc7230#section-3
요청 메시지
HTTP 요청 메시지의 start-line 은 request-line 이라 불린다.
request-line 은 method + request-target + HTTP-version 으로 구성된다.
method 의 경우 HTTP 메서드로서 서버가 수행해야 할 동작을 명시한다.
대표적으로 GET, POST, PUT, DELETE 등 이 존재한다.
request-target 은 위 메서드를 실제 수행할 대상을 작성하는 곳이다.
구성은 대게 absolute-path[?query] 절대 경로 ? 쿼리로 작성된다.
(참고로 http://...?x=y 등과 같이 다른 유형의 경로지정 방법도 존재한다.)
HTTP-version 은 말 그대로 사용 중인 HTTP 버전 작성해주면 된다.
예시엔 따로 body 부분이 없었지만, 실제로 요청에도 body 가 필요한 경우가 있다.
응답 메시지
HTTP 응답 메시지의 start-line 은 status-line 이라 한다.
status-line 의 구성은 다음과 같다.
status-line = HTTP-version + status-code + reason-phrase (각 구성 요소 사이에 공백 존재)
HTTP-version 은 말 그대로 사용 중인 HTTP 버전이 기재되며,
HTTP-status 는 상태 코드를 의미하며, 요청에 대한 성공, 실패를 나타낸다.
대표적으로 200 (성공), 400(클라이언트 오류 실패), 500(서버 내부 오류) 등이 있다.
reason-phrase 의 경우 사람이 이해할 수 있는 주어진 상태 코드에 대한 짧은 설명이 기재된다.
다음으로 살펴볼 부분은 HTTP 헤더 이다.
HTTP 전송에 필요한 모든 메타 정보(부가정보)가 해당 필드 안에 기재된다.
헤더는 header-field = field-name: field-vlaue 와 같이 작성된다. (key-value 형태)
참고로, field-name 은 대소문자 구분을 따로 하지 않는다.
헤더 정보로 사용되는 예시로는 메시지 바디의 내용, 바디의 크기, 압축, 인증, 요청 클라이언트 정보, 서버 정보, 캐시 정보 등이 존재한다.
표준 헤더로 정의된 내용이 현재 너무 많다. (참고 - en.wikipedia.org/wiki/List_of_HTTP_header_fields)
이 뿐만 아니라, 필요 시 임의의 헤더 추가하여 사용할 수 있다.
응답 메시지의 마지막은 바로 메시지 바디 파트 이다.
실제 전송할 데이터들을 가지고 있으며, HTML 문서, 이미지, 영상, JSON 등 byte 로 표현할 수 있는 모든 데이터가 담길 수 있다.
참고
- 해당 게시글은 김영한 님의 모든 개발자를 위한 HTTP 웹 기본 지식을 참고하여 작성하였습니다.
- 더 자세한 내용 필요하실 경우 강의를 수강하시길 적극 권장드립니다.
댓글