Application Layer (in TCP/IP 4 Layers)

현대 사회에서 특정 사용자의 컴퓨터를 통해 지구 반대편의 사용자와 메시지를 주고 받는 일이 전혀 어렵지 않은 일이다.

이를 가능케 해주는 것이 네트워크인데, 네트워크는 편의에 따라 크게 4개의 계층으로 나뉜다. (TCP/IP 4계층 방법론 기준)

네트워크를 크게 4개의 계층으로 나눈 까닭은,

기능을 계층별로 나누어 구성하고 관리함으로써 네트워크 프로토콜의 복잡성을 줄이고 각 계층의 역할에 집중할 수 있기 때문이다.

TCP/IP 4계층은 다음의 계층으로 나뉜다.

1. 네트워크 액세스 계층(1계층)
2. 인터넷 계층(2계층)
3. 전송 계층(3계층)
4. 애플리케이션 계층(4계층)

계층이 높아질수록 사용자에게 가까워지며 

사용자간 통신에서 메시지를 보내는 측 사용자의 4계층부터 시작해서 3, 2, 1계층으로 내려간 뒤,

메시지를 수신하는 측의 사용자의 1, 2, 3, 4계층 순으로 이동하며 통신이 이루어진다.

아래는 이를 그림으로 설명한 자료이다.

출처: https://hongchangsub.com/networkprotocol/

 

 

소켓

위 그림을 보면 애플리케이션 계층과 전송 계층은 서로 인접해있다. 

이 두 계층 간 데이터의 이동을 수행해주는 것이 바로 소켓이다.

소켓은 일종의 파일 시스템으로 작동하며 이에 대한 I/O를 통해 두 계층을 잇는다.

애플리케이션 계층에서 HTTP 통신을 시도할 때, 소켓을 하나 선택해야 하며 이 과정은 포트 번호를 선택하는 것으로 추상화되어 있다. 

포트를 선택한 뒤 전송할 데이터에 대한 입력을 수행하기만 하면 그 이후 과정은 이하의 계층들이 알아서 수행해준다. 

이처럼 추상화가 잘 이루어져 있기 때문에 소켓은 일종의 전화기로 비유되기도 한다.

 

 

HTTP

애플리케이션 계층에서 지원하는 프로토콜은 HTTP, SMTP, DNS 등이 존재한다.

이 중 가장 많이 사용되는 것은 HTTP 프로토콜이다. 이에 대해 간단히 설명하고자 한다.

HTTP는 기본적으로 클라이언트-서버 모델을 따른다.

서버 측이 고정된 IP와 항상 켜져있는 서버를 갖고 있기 때문에, 클라이언트 측은 언제든지 서버 측에 요청이 가능하다. 

HTTP 프로토콜은 기본적으로 TCP 프로토콜을 기반으로 한다.

따라서 연결에 대한 신뢰가 가능한 프로토콜이며,

클라이언트와 서버는 각자의 소켓 인터페이스에 의존하기 때문에 구현에 어려움도 없다. 

 

HTTP/1.1 vs HTTP/2

현재 인터넷에서 가장 많이 사용되는 HTTP 버전은 1.1 버전과 2 버전이다.

1.1 버전은 1999년에 등장했고, 2 버전은 2015년에 등장했다.

제일 처음 등장한 HTTP/1.0 버전에는 한번의 TCP 연결에서 단 하나의 자원만 받아올 수 있다는 문제가 있었다.

만약 특정 웹사이트를 렌더링하는데 필요한 자원이 HTML 하나, 이미지 파일 열개라고 하면 총 열한번의 TCP 연결 생성 및 삭제 과정이 있는 것이다.

TCP 연결 생성 시에는 3-way Handshake라고 불리는 과정이 필요하기 때문에 매번 연결을 생성하고 삭제하는 것은 굉장히 비효율적이었다. 

이에 HTTP/1.1 버전에서는 위와 같은 상황에서 하나의 TCP 연결을 재사용하도록 변경되었다.

(이 연결은 일정 시간 유지되다가, 일정 시간 이상 통신이 이루어지지 않으면 끊어진다.)

HTTP/1.1 버전은 오랫동안 안정적으로 사용되었지만 스마트폰의 발달, 멀티 미디어에 대한 요청 증가 등의 트렌드로 문제를 직면한다.

HOL Blocking

HTTP/1.1 버전의 가장 큰 문제점은 Head of Line(HOL) Blocking이다.

HTTP/1.1 버전은 여러 요청을 순차적으로 처리하지 않고, 일단 서버에 모든 요청을 전달할 수 있는 파이프라인 방식이 도입되었다.

출처: https://bbo-blog.tistory.com/87?category=1004651

하지만 HTTP/1.1 버전의 파이프라인 방식은 그저 서버 측에서 먼저 들어온 요청에 대한 처리를 하는 동안 늦게 들어온 요청에 대한 처리를 인위적으로 미루는 식으로 구현되어 있기 때문에, 먼저 들어온 요청의 규모가 크다면 이후 요청에 대한 처리는 Blocking이 되게 된다.

이를 HTTP/2 버전에서는 멀티 플렉싱을 도입하여 해결한다.

Multi Flexing

멀티 플렉싱 방식은 HTTP 통신의 요청과 응답을 더 쪼갤 수 없는 프레임이라는 단위로 쪼개서 처리한다. (프레임은 헤더 프레임과 데이터 프레임의 두 종류로 나뉜다.)

또한 각 프레임들에 대한 재조립은 엔드포인트에서 수행하는 방식을 도입하여 특정 요청, 응답이 끝날 때까지 다른 작업이 Blocking 되는 일을 없앴다. 

그외에도 헤더 압축, 서버 푸싱 등의 방식을 도입하여 성능을 많이 개선시켰다.

현재는 HTTP/3 버전까지 나온 상황이지만 이는 아직 표준으로 채택되지는 못했다. 다만, Google이나 Youtube 등의 웹사이트에는 이를 선제적으로 적용하고 있다.