HTTP는 HyperText Transfer Protocol로 웹상에서 정보를 주고받을 수 있는 프로토콜이다.
HTTP는 HTML, TEXT, 이미지, 음성, 영상, 파일, JSON, XML 등 거의 모든 형태의 데이터 전송이 가능하사다. 또한 서버간에 데이터를 주고 받을 때도 대부분 HTTP를 사용한다.
즉, 거의 지금은 HTTP 시대라고 볼 수 있다.
HTTP 역사
- HTTP/0.9 1991년: GET 메서드만 지원, HTTP 헤더 X
- HTTP/1.0 1996년: 메서드 헤더 추가
- HTTP/1.1 1997년: 가장 많이 사용, 가장 중요한 버전
- RFC2068 (1997) -> RF2616 (1999) -> RFC7230~7235 (2014)
- HTTP/2 2015년: 성능 개선
- HTTP/3 진행중: TCP 대신 UDP 사용, 성능 개선
위에 역사에서 알수 있듯 TCP는 HTTP/1.1과 HTTP/2를 사용하고, UDP는 HTTP/3을 사용한다.
현재는 HTTP/1.1이 주로 사용되며, HTTP/2와 HTTP/3도 점점 증가하는 추세이다.
HTTP 특징
- 클라이언트 서버 구조
- 무상태 프로토콜(stateless), 비연결성
- HTTP 메세지
- 단순하고 확장 가능
클라이언트 서버 구조
HTTP의 특징 중 하나인 클라이언트 서버 구조는 Request-Response 구조이다.
클라이언트는 서버에 요청을 보내고, 응답을 기다리며 서버가 요청한 대한 결과를 만들어서 응답하는 방식이다.
무상태 프로토콜 - 스테이스리스(Stateless)
무상태 프로토콜은 서버가 클라이언트의 상태를 보존하지 않는 것이다.
이러한 무상태 프로토콜은 서버 확장성이 높다(스케일 아웃/scale out)는 장점이 있지만,
클라이언트가 추가로 데이터를 전송해야한다는 단점이 존재한다.
Stateful(상태 유지), Stateless(무상태) 차이
- 상태 유지(Stateful): 중간에 다른 서버로 바뀌면 안된다. (중간에 다른 서버로 바뀔 때 상태 정보를 다른 서버에게 미리 알려줘야 한다.)
- 무상태(Stateless): 중간에 다른 서버로 바뀌어도 된다.
- 갑자기 클라이언트 요청이 증가해도 서버를 대거 투입할 수 있다.
- 무상태를 응답 서버를 쉽게 바꿀 수 있다. -> 무한한 서버 증설 가능
Stateful(상태 유지) vs Stateless(무상태)
실제 서비스 단계에서는 모든 것을 무상태로 설계할 수 있는 경우도 있고, 없는 경우도 있다.
예를 들어 로그인이 필요 없는 단순한 서비스 소개 화면의 경우 상태를 보관할 필요가 없기 때문에 무상태로 설계하는 것이 좋지만, 로그인이 필요한 경우에는 로그인된 상태가 지속될 필요가 있기 때문에 상태 유지를 이용하는 것이 필요하다.
일반적으로 브라우저 쿠키와 서버 세션 등을 사용해서 상태를 유지하며, 상태 유지는 가급적 최소한 사용하는 것이 서버관점에서 좋다.
비연결성(connectionless)
비연결성은 클라이언트와 서버간의 연결 모델 중에 하나이다.
먼저 연결을 유지하는 모델을 살펴보자
위와 같이 서버는 요청을 보내는 클라이언트들과 지속적으로 연결되어 있기 때문에 서버 자원을 지속적으로 소모된다.
또한 다수의 클라이언트가 연결될 경우 서버 과부화가 생기는 위험이 발생한다.
그렇다면 연결을 유지하지 않는 모델은 어떨까?
연결을 유지하지 않는 모델은 연결을 유지하는 모델과는 다르게 클라이언트가 요청을하고, 그 요청에 대해 응답을 한 후 연결을 끊는다.
이런 모델을 사용하게 되면, 서버는 지속적으로 연결될 필요가 없기 때문에 최소한의 자원만 사용할 수 있다는 장점이 있으며, 과부화에 대한 위험이 줄어든다.
HTTP는 기본적으로 연결을 유지하지 않는 모델을 사용한다. 즉, 비연결성을 특징으로 가진다.
이러한 특성은 일반적으로 초 단위 이하의 빠른 속도로 응답이 가능하게 만들어준다. 따라서 서버 자원을 효율적으로 사용할 수 있다.
비연결성 - 한계와 극복
위에서 살펴본 비연결성에서도 한계점이 존재한다.
먼저 TCP/IP 연결을 새로 맺어야 한다는 것인데 TCP/IP 연결을 위한 3 way handshake를 할 때 시간이 추가된다.
또한 웹 브라우저로 사이트를 요청하면 일반적으로 HTML 뿐만 아니라 다양한 자원이 함께 다운되기 때문에 각각의 자원들이 요청될 때 시간이 추가적으로 더 들수 있다.
이런한 한계점은 HTTP 지속 연결(Persistent Connections)로 해결하였다.
이는 HTTP/2, HTTP/3에서 더 많이 최적화 되었다.
HTTP 메세지
HTTP는 HTTP 메세지를 이용해 클라이언트와 서버 간의 요청과 응답을 처리한다.
HTTP 요청/응답 메세지는 아래와 같은 구조를 가진다.
시작 라인 - 요청 메세지
시작 라인(start-line)은 request-line 또는 status-line으로 불리는데 요청 메세지에서는 request-line으로 불린다.
- request-line = method SP(공백) request-target SP HTTP-version CRLF(엔터)
- method: HTTP 메서드 (GET: 조회)
- request-target: 요청 대상 (/search?q=hello&hl=ko)
- HTTP-version: HTTP 버전
시작 라인 - 요청 메세지(HTTP 메서드)
HTTP 메서드는 서버가 수행해야할 동작을 지정하는 것이다.
대표적으로 리소스 조회의 의미를 가지는 GET과 요청 내역 처리의 의미를 가지는 POST가 있다.
그 외에도 PUT, DELETE 등 다양한 종류의 메서드가 존재한다.
시작 라인 - 요청 메세지(요청 대상)
클라이언트가 요청을 보내는 대상을 지정한다.
- absolute-path?query
- absolute-path(절대경로): "/"로 시작하는 경로
시작라인 - 요청 메세지(HTTP 버전)
클라이언트가 요청을 보내는데 사용되는 HTTP 버전을 의미한다.
시작라인 - 응답 메세지
위에 요청 메세지에도 있듯 시작 라인(start-line)은 request-line 또는 status-line으로 불리는데 요청 메세지와는 다르게 응답 메세지는 status-line으로 불린다.
- status-line = HTTP-version SP status-code SP reason-phrase CRLF
- HTTP-version: HTTP 버전
- status-code: HTTP 상태 코드이며, 요청의 성공과 실패를 나타낸다.
- reason-phrase: 이유 문구로 사람이 이해할 수 있는 짧은 상태 코드 설명 글이다.
HTTP 헤더
메세지 바디의 내용, 메세지 바디의 크기, 압축, 인증 등등 HTTP 전송에 필요한 모든 부가정보를 담고 있는 부분이다.
HTTP 표준 헤더의 경우 엄청나게 많이 존재한다.(https://en.wikipedia.org/wiki/List_of_HTTP_header_fields)
또한 필요시 임의의 헤더도 추가 가능하다.
- header-field = field-name ":" OWS(띄어쓰기 허용 - 띄어쓰기 해도 되고 안해도 됨) field-value OWS
- field-name은 대소문자 구분이 없다.
HTTP 메세지 바디
HTTP 메세지 바디는 실제 전송할 데이터가 존재하는 곳이다.
HTML, 이미지, 영상, JSON 등등 byte로 표현할 수 있는 모든 데이터를 전송할 수 있다.
참고 강의 : "김영한 강사님", 인프런 모든 개발자를 위한 HTTP 웹 기본 지식
- 문제 발생 시 삭제 조치 하도록 하겠습니다.
