네트워크 (3) HTTP의 개요와 특징

wikipedia

 

1. HTTP (HyperText Transfer Protocol) ?

 

HTTP는 그 스펠링에서 알 수 있듯이 하이퍼텍스트를 빠르게 교환하기 위한 프로토콜이다.

또한 웹에서 이루어지는 모든 데이터 교환의 기초이며, 클라이언트-서버 구조를 가지고 있다.

1991년 처음 만들어진 HTTP는 계속해서 진화해왔으며 이제는 하이퍼텍스트가 아닌 이미지 비디오 HTML 폼 결과 등 바이트로 표현할 수 있는 거의 모든 데이터를 전송할 수 있다.

 

 

 

 

 

2. HTTP의 역사

1991년 HTTP/0.9 : GET 메서드만 지원했으며 헤더가 존재하지 않았다.

1996년 HTTP/1.0 : 메서드와 헤더가 추가되었다.

1991년 HTTP/1.1 : 오래 되었지만 아직까지도 범용적으로 사용되고 있는 버전이다.

2015년 HTTP/2 : 성능이 개선된 버전.

2019년 HTTP/3.0 : 성능이 개선되었으며 TCP 대신 UDP를 채택하게 되었다.

 

 

 

 

3. HTTP의 특징

 

3-1 ) 클라이언트 서버 구조

: 클라이언트 서버 구조란 데이터를 저장하고 관리하는 서버 부분과 해당 서버에 접속하여 데이터를 열람하는 클라이언트 부분으로 구성된 네트워크 구조를 말한다.

따라서 비즈니스 로직은 모두 서버에 밀어넣고 클라이언트는 UI를 그리는 등 각자의 일만 하도록 처리할 수 있다.

클라이언트가 서버에 요청을 보내고 대기하기 때문에 Request Response 구조라고도 이야기 한다.

 

3-2) 무상태 프로토콜 (statless)

:

컴퓨팅에서 무상태 프로토콜(stateless protocol)은 어떠한 이전 요청과도 무관한 각각의 요청을 독립적인 트랜잭션으로 취급하는 통신 프로토콜로, 통신이 독립적인 쌍의 요청과 응답을 이룰 수 있게 하는 방식이다. 무상태 프로토콜은 서버가 복수의 요청 시간대에 각각의 통신 파트너에 대한 세션 정보나 상태 보관을 요구하지 않는다. 반면, 서버의 내부 상태 유지를 요구하는 프로토콜은 상태 프로토콜(stateful protocol)로 부른다.
<wikipedia>

무상태 프로토콜은 서버에서 클라이언트와의 통신에 대한 세션을 따로 저장하지 않는다는 것을 의미한다.

서버는 request가 오면 response를 보낼 뿐 그것을 저장하지 않고 클라이언트에게 고정된 서버와의 통신을 보장해주지 않는다.

즉, 클라이언트가 지속적으로 통신을 해야하는 상황에서 서버가 data를 response를 통해 보내줬다면 클라이언트가 다시 그 response 받은 데이터를 request로 보내며 통신하게 되는 것이다.

모든 정보는 클라이언트가 가지고 있기 때문에 연결된 서버가 달라지거나 장애가 생겨도 아무런 문제가 생기지 않는다.

갑작스런 트래픽 급증 등의 문제가 있을 때 대처하기 쉽기 때문에 대다수의 웹서비스에서 Stateless 구조 기반을 따르고 있다.

 

단, 이런 무상태 프로토콜에도 단점이 있다.

일단 매번 데이터를 누적시켜 전송하기 때문에 데이터를 더욱 많이 사용하게 되고, 로그인 상태 등 지속적으로 유지해줘야 하는 것들이 존재하기 때문이다. 이런 경우는 쿠키와 세션 등을 활용해서 별도의 상태 유지 처리를 해주어야 한다. 하지만 이런 상태 유지 처리는 항상 최소한으로 유지되어야 한다.

 

 

 

3-3) 비연결성 (Connectionless)

 

좌측이 일반적인 비연결성을 나타내는 형태

 

만약 클라이언트와 서버가 통신하는 동안 연결을 계속해서 유지한다면 서버 자원을 점유하게 되는데, 이 서버 자원은 굉장히 비싼 자원이기 때문에 HTTP는 클라이언트와 Request Response 과저이 끝나면 바로 연결을 끊어버림으로써 효율적으로 서버를 관리한다.

웹 서버에서 동시 접속자가 수천명이 되더라도 동시에 처리하는 요청은 수십개 정도 밖에 되지 않고, 만약 요청이 들어오더라도 빠른 속도로 응답할 수 있기 때문에 계속해서 연결해놓을 이유가 없다.

 

문제는 이런 비연결성 때문에 3 way handshake과정을 계속해서 거치고 기타 불필요한 데이터들 또한 계속해서 전송 받아야하는 문제가 있기 때문에 Persistent Connection으로 이런 단점을 완화했다. 

Connection:keep-alive라는 값을 사용하면 요청/응답을 재사용할 수 있으며 Connection:close를 사용하면 연결을 끊는다.

그런데 사실 HTTP 1.1부터는 keep-alive가 기본값으로 설정되어 있어서 Connection:close를 사용하지 않으면 연결을 유지한다..

그리고 HTTP2부터는 Multiplexing 개념이 도입되어 이러한 HTTP1.1의 단점은 완전히 해결되었다.

멀티 플렉싱은 하나의 TCP 커넥션만으로 해당 웹페이지의 모든 요청과 응답 데이터를 전송하며 비동기적으로 데이터를 처리하는 것인데, 아래의 그림을 보면 이해하기 쉬울 것이다.

제일 우측이 HTTP 2.0부터 지원되는 Multiplexing이다.

 

 

 

4. HTTP 메세지의 구조

 

 

 

용어는 조금 다르지만 위와 같은 구조로 되어 있다.

1. start-line ( 메세지의 가장 첫번째 줄 )

2. header

3. empty line

4. message body (전송할 데이터가 없는 경우에는 생략된다)

 

참고로 empty line은 응답 분할(HTTP Response Splitting, CRLF)라고 불리는데 바디와 헤더를 구별하기 위해 반드시 필요한 부분이다. 근데 저 공백에 취약점이 있다.

해킹에 관심이 있다면 구글에 검색해보도록 하자.