HTTP 비연결성 (feat. 지속 연결)

HTTP의 특징: 비연결성

 

HTTP는 네트워크의 응용계층(애플리케이션 계층)에서 클라이언트 프로세스와 서버 프로세스가 통신하기 위한 프로토콜로 오늘 날 웹 환경에서 광범위하게 사용되는 중요한 프로토콜이다. HTTP는 특징 중 하나로 상대측과 통신에 성공한 연결을 지속하지 않는다는 비연결성(connectionless)을 가지는데, 오늘은 비연결성이 무엇이고 어떠한 이점 그리고 한계를 갖는지 한번 살표보자.

 

 

비연결성이란?

비연결성은 연결을 지향하지 않음을 의미한다. HTTP는 서버와 클라이언트가 엄격히 분리되어 있는 프로토콜로 통신을 하는 양측 중 한쪽은 반드시 클라이언트, 다른 한쪽은 반드시 서버가 된다. HTTP 통신은 클라이언트가 서버로 리소스를 요청하거나 서버 상의 리소스를 조작하는 것을 요청하는 방식으로 시작되고, 서버에서 클라이언트의 요청을 처리해 결과값을 알려주며 끝나게 된다. 즉, 클라이언트의 요청과 함께 시작되어 서버의 응답과 함께 끝나는 것이다.

 

이렇게 요청이 서버 상에서 처리되어 응답이 완료된 것을 한 차례의 HTTP 통신이라고 정의한다면, HTTP는 이 한 차례의 통신 이후 다음 번의 통신을 위해 연결을 유지할 지, 연결을 유지하지 않고 연결을 끊어버릴 지를 선택할 수 있다. HTTP는 이 때, 통신 완료 이후 연결을 이어가는 대신 즉시 연결을 끊어버리는 방법을 택하는데, 이것을 바로 비연결성이라고 하는 것이다.

 

그렇다면 왜 HTTP는 통신 이후 연결을 바로 끊어버리는 것일까? 사실 한 차례의 HTTP 연결이 수행되기 위해서는 HTTP 연결 이전과 이후에 전송 계층에서의 TCP 연결이 필요해 생각보다 수행되는 작업이 많은데, 1회 통신 후에 이 연결을 끊어 버리는게 너무 아까운 거 아닐까?

 

사실 비연결성은 HTTP를 가볍고 유연성이 높은 프로토콜로 만들어주는데 일조했다. HTTP의 성공에 많은 기여를 한 HTTP의 중요한 특징 중의 하나이니 분명 어떠한 이점이 있을 것이다. 한번, 아래와 같은 상황을 염두해보자.

 

A 서버와 B 서버는 각각 1초에 n건의 클라이언트 요청이 들어오는 웹서버다.
A 서버는 연결을 지향하는 프로토콜을 사용하고, B 서버는 연결을 지향하지 않는 프로토콜을 사용한다.

n이 증가할수록, 부하가 더 많이 걸리는 서버는 어디일까?

 

이 문제에 답을 하기 위해서는 통신의 연결을 유지하는데 서버의 자원이 소모된다는 부분을 인식해야 한다. A 서버는 클라이언트와의 통신 이후 연결을 끊지 않는다. 따라서 서버에 접근하는 클라이언트의 수가 많아질수록 연결에 소모해야 하는 자원이 급격하게 증가할 소지가 있다. 반면 B 서버는 연결을 지향하지 않기 때문에 클라이언트와의 통신이 완료되는 즉시 연결을 끊어 버려 연결에 필요한 자원을 A 서버에 비해 소모하지 않는다. 여러가지 상황을 다각적으로 고려해봐야 하겠지만 서버에 접근하는 클라이언트의 수(n)이 증가하면 증가할수록, B 서버보다는 A 서버에 부하가 더 집중될 것 같다.

 

 

비연결성의 한계

그러나 웹 환경은 계속해서 변화한다. 웹이 처음 나왔을 때는 인터넷 환경에서 서버와 클라이언트가 주고 받는 통신이 비교적 가볍고 간단했다. 정적인 리소스인 HTML 파일을 주고 받거나 한 두개의 이미지 파일들이 HTML 파일과 함께 네트워크를 지나 다녔을 것이다.

 

그러나 현재는, 하나의 웹 페이지를 열었을 때 서버와 클라이언트가 주고 받는 리소스의 양이 과거에 비해 훨씬 많아졌다. 시험 삼아 네이버의 메인 페이지를 띄워 https://www.naver.com 이라는 페이지 하나를 요청했을 때 몇 개의 리소스가 주고 받아지는지 확인해 봤는데, 무려 313건이 조회되었다. 사용자는 한 번의 클릭으로 네이버 서버에서 메인 페이지 하나만을 요청했을 뿐인데, 내부적으로 수행된 HTTP 통신이 313건이나 된 것이다.

 

글을 쓰고 있는 중에도 통신이 계속되고 있었다. 314건으로 늘어난 것을 확인할 수 있다.

 

한번 생각해보자. 웹 페이지 하나를 요청했을 때 내부적으로 발생하는 HTTP 요청 메세지가 300건 이상이라면, 이거 뭔가 굉장히 비효율적이지 않은가? 분명 비연결성을 지향하는 HTTP는 1회의 통신이 종료되면 연결을 끊는다고 했다. 그 말은, 매번 새로운 요청이 생길 때마다, 새로운 연결이 필요하다는 것을 의미한다. 나는 naver.com이라는 네이버의 메인 페이지를 주세요, 라고 요청한 것 뿐인데, 내 컴퓨터와 네이버의 웹서버는 총 313번의 연결을 생성하고, 끊고, 생성하고, 또 끊고 해야 한다. 이건 서버의 자원의 소모를 효율적으로 막기 위한 비연결성의 애초의 목적에 부합하지 않은 결과이다.

 

 

HTTP 지속 연결

지속 연결은 이러한 비연결성의 문제를 극복하기 위해 고안된 개념으로 HTTP1.1 버전은 기본적으로 HTTP의 지속 연결을 지원한다. 지속연결을 이해하기 위해 잠시 아래의 그림을 확인해보자.

 

출처 : https://llniceqll.tistory.com/203

위의 그림은 HTTP 통신이 1회 생길 때 발생되는 통신의 프로세스를 보여준다. 그림에서 Request Message로 표시되어 있는 부분이 HTTP 요청이고 DATA(Response)로 표시되어 있는 부분이 HTTP 응답이다. 그 위와 아래의 SYN, ACK 등은 HTTP 이전에 수행되는 전송 계층에서의 TCP 통신을 의미한다. 

 

TCP는 데이터 송수신 및 네트워크 연결의 안정성을 보장하는 프로토콜로 이에 대한 메커니즘으로 3 ways handshakes라는 개념을 사용한다. 클라이언트에서부터 서버로 통신을 시도해 "잘 들려?", "어 잘 들려, 너는?", "나도 잘 들려!" 하면서 서로의 위치와 존재 여부를 확인하는 방법으로 총 세번 통신이 오고 가고 한다고 해서 3 ways handshakes라고 하는 것이다. 

 

한번의 HTTP 통신이 이루어지기 위해 앞뒤로 TCP 연결이 이루어진다는 부분을 확인했다. HTTP의 지속연결은 이 TCP 연결을 끊지 않고 HTTP 통신을 계속 주고 받는다. 첫번째 HTTP 통신이 이루어질 때만 TCP가 3 ways handshake를 수행할 뿐, 이후의 HTTP 요청과 응답에서는 이 과정을 생략하는 것이다. 이렇게 되면 계속해서 연결을 새로 맺어야 할 때는 불가피하게 수행되었어야 할 작업을 생략할 수 있다. 따라서 네트워크 부하를 효율적으로 제어할 수 있다.