애플리케이션 계층

애플리케이션 계층은 웹 애플리케이션을 통해 이뤄지는 계층을 의미한다.

 

웹 애플리케이션이란 브라우저, 유튜브, 넷플릭스 등 인터넷을 통해 정보를 교환하는 프로그램이다. 유튜브 영상을 본다던가, 댓글을 쓴다던가 볼만한 영상을 검색을 한다던가 등, 사용자가 필요한 정보를 나르는 역할을 한다.

 

따라서 웹 애플리케이션은 종단에서만 구현되어있으며, 네트워크 코어에서는 구현되어있지 않다. 네트워크 코어에서는 링크 계층 내지는 네트워크 계층까지만 주로 구현된다.

웹 애플리케이션의 구조

애플리케이션 구조(application architecture)는 크게 두 가지가 있다.

 

클라이언트-서버 구조(client-server architecture)

항상 동작하는 호스트를 서버라고하며, 서버는 클라이언트라고 불리는 다른 호스트들에게서 요청을 받고, 응답을한다. 일반적인 애플리케이션의 구조다.

 

P2P 구조(peer-topeer, P2P)

서버(항상 켜져있는 호스트)에 최소 또는 아예 의존하지 않으며, 호스트 쌍(peer)이 직접 소통한다. 나중에 더 다룰 예정이다.

프로세스

프로세스(process)란 종단시스템에서 통신하는 주체며, 프로세스 간 통신내용을 메시지(message)라고한다.

가령, 내가 내 블로그 글에 접속한다고하면, 프로세스는 내 크롬 브라우저와 티스토리 웹 서버가 되며, 메시지는 내 블로그의 내용이 된다.

 

그래서 프로세스 관점에서 네트워크 애플리케이션은 정보를 보내는 프로세스와 정보를 받는 프로세스로 구성된다.

따라서 두 프로세스 간 통신세션을 초기화하는 프로세스를 클라이언트, 접속을 기다리는 프로세스를 서버라고 칭한다. 이는 P2P에서도 마찬가지. P2P에서 특정 호스트가 정보를 보낼 것을 요구하면 클라이언트, 정보를 보내주면 서버라고 칭한다.

소켓

애플리케이션 계층에서의 메시지는 아래계층 (전송, 네트워크, 링크 등...)에서 전송되기 때문에 애플리케이션 계층은 보낼 메시지를 바로 아래계층은 전송계층으로 넘겨야한다. 이 때 메시지는 두 계층 간에 직접적으로 전달되는게 아니라 소켓(socket)이란 일종의 창구를 이용한다.

 

소켓은 애플리케이션과 전송계층(네트워크) 간 데이터 이동의 창구 역할을 담당하며, 애플리케이션과 네트워크 간 정보 전달을 위해 여러 기능들을 지원하므로 소켓API라고도 칭한다.

 

예를들어 내가 누군가에게 메일을 보내고 싶다면, 보낼 메시지와 수신자 정보 등을 정리해야한다. 여기까지가 애플리케이션 계층의 역할이고 이 뒤로부터는 전송계층의 영역이다. 따라서 애플리케이션 계층에서는 메시지와 수신자 정보만 정리한 후, 소켓의 send() 메서드를 호출하여 정보를 네트워크로 보내고 recv() 메서드를 호출하여 전송계층에서 정보를 넘겨받는다.

 

소켓을 사용하는 이유는 전송계층부터는 정보전달에 필요한 과정들이 복잡해지기 때문이다. 따라서 애플리케이션 계층에서는 이런 복잡성을 신경쓰지 않고 send(), recv() 등 소켓API만 호출해 애플리케이션 계층에서의 복잡성을 낮추기 위함이다. 소켓의 내용은 나중에 조금 더 나온다.

프로세스와 소켓

메시지를 주고받는 주체는 프로세스다.

따라서, 전송계층에서는 메시지를 받고, 어느 소켓을 통해 어느 프로세스에게 메시지를 전달해야할지 정해야하고, 이는 포트번호(port number)를 이용해 구분한다. 같은 호스트더라도 80번 포트와 25번 포트에 동시에 메시지가 도착하면, 그 두 메시지는 서로 다른 프로세스에서 처리된다.

애플리케이션 계층 프로토콜

웹 애플리케이션이 서로 간에 메시지를 교환하기 위해서는 메시지를 교환할 방법이 필요하다. 이를 프로토콜(protocol)이라고하며, HTTP, 비트토렌트, DNS, SMTP 등이 있다.

HTTP

HTTP는 HyperText Transfer Protocol의 약어로, 직역하면 하이퍼텍스트 전송 프로토콜이다. 여기서 하이퍼텍스트란, 글, 그림, 오디오, 비디오 등 여러 형태의 미디어를 아우르는 정보 시스템이다. 그리고 이 하이퍼텍스트들은 HTML 파일에 정리되어 웹 페이지로 표현된다.

 

 

웹 페이지는 객체로 구성되어있다. 객체(object)란 URL로 지정할 수 있는 파일(HTML, 이미지, CSS 등..)이다.

만약 https://www.conx.co.kr/project/projectImg1.png 에 이미지 파일이 저장된다면, 해당 이미지 파일은 객체다.

그리고 위 URL에서 www.conx.co.kr은 호스트 이름이 되며, /project/projectImg1.png는 경로이름이 된다.

 

그래서 HTTP는 클라이언트가 서버에게 웹 페이지를 어떻게 요청하는지, 그리고 어떻게 제공받을지, 연결을 어떻게 진행할지 등을 정의한다. 해당 "URL에 속하는 객체를 주십시오"라고하는 것이 요청, 실제 객체를 반환하는 것이 응답이 된다.

HTTP 메시지 구조

요청

와이어샤크를 통해 확인한 HTTP 요청 메시지

 

기본적인 HTTP 요청의 형태는 다음과 같다.

맨 첫 줄을 요청 라인(request line), 이후의 줄을 헤더 라인(header line)이라고 부른다.

 

요청라인에는 HTTP 메서드(방식), 유청 URL, HTTP 버전이 들어간다. 위의 사진에서 GET 메서드로, / URL로, HTTP 1.1 버전을 사용해 요청을 전송했음을 알 수 있다. HTTP 메서드는 웹개발할 때 그 메서드와 동일하다.

 

헤더라인에는 여러가지 헤더들이 있다. 어느곳에서 정보를 받아왔는지 명시하는 HOST 헤더, Connection: keep-alive를 통해 전송계층에서 세워진 연결이 요청 이후에도 지속됨을 알 수 있고, User-agent는 Mozilla/5.0 (크롬 브라우저), Accept-language는 ko-KR, 한국어로 설정된다. 서버에 객체의 한국어 버전이 있다면 한국어버전을 내리고, 없다면 기본 버전을 내린다. 이 밖에도 여러 헤더들이 위치해있어, 요청에 대한 기초적인 정보들을 포함한다.

 

응답

와이어샤크로 본 응답

응답포맷은 이렇게 설정되어있다.

응답포맷은 상태 라인(status line), 헤더 라인, 개체 몸체로 이루어진다.

 

위의 예시에서 HTTP 1.0 버전을 사용해 응답했으며, 200 OK 응답이 떨어졌음을 알 수 있다. 헤더에는 서버정보(Server), HTTP 응답이 만들어진 시간(Date) 등 다양한 정보들이 들어간다. 사실 간단한 웹사이트에 날린 요청에 대한 응답이기 때문에 헤더의 정보가 적은 편이다.

 

HTTP 메시지의 특징은 ASCII 텍스트로 쓰여 사람들이 읽을 수 있다는 점이다.

쿠키

HTTP 서버는 클라이언트에 대한 정보를 필요로하지 않는다. 그래서 이를 비상태 프로토콜(stateless protocol)이라고도 칭한다.

stateless한 HTTP 서버에서 사용자를 식별해야할 때가 있는데, 이 때 쿠키(cookie)를 사용한다.

 

쿠키의 저장과정은 위와같이 이루어진다.

 

1. HTTP 요청을 통하여 특정 웹사이트에 방문한다.

2. 웹서버는 이 사용자에 대하여 특정ID를 생성, 쿠키에 저장한 후 HTTP 응답에 Set-cookie 헤더를 포함하고, 브라우저는 이 응답을 받으면 브라우저가 관리하는 쿠키 파일에 이를 저장한다.

3. 이후 같은 사이트에 또 방문하게 되면 브라우저는 쿠키에 저장한 특정ID값을 넣어서 보낸다. 따라서 서버는 이 사용자를 식별할 수 있다.

 

사실 이것은 기본적이면서도 간단한 쿠키의 사용법으로, 더 다양한 쿠키 사용법들이 존재한다.

프록시 서버를 통한 캐싱

프록시 서버는 웹 서버를 대신하여 HTTP 요청에 응답하는 서버다. 프록시 서버는 요청을 받았으면 자신에게 그 요청에 대한 응답의 사본이 있는지 검사하고, 만약 사본이 있다면 응답을 반환, 없다면 웹 서버로 요청을 보내고 응답을 받아온 후, 사본을 저장하고 클라이언트에게 응답을 반환한다.

 

웹 캐싱의 장점은

 

1. 응답시간 감소

웹 서버를 거치지 않고 가까운 프록시서버만 거치므로 지연발생이 적어 빠른 응답반환이 가능하며, 특히 병목구간의 대역폭이 클라이언트-서버보다 클라이언트-프록시 서버에서 더 높은 경우 유의미한 효과를 얻을 수 있다.

 

2. 트래픽 감소

학교, 회사 등에서의 기관LAN을 사용하고 있을 때, 기관 네트워크와 연결된 공중인터넷의 접속 회선의 처리율이 낮다고 하자.

이 문제를 해결하려면 접속 회선의 접속률을 15Mbps에서 더 증가시키는 방안을 쓰거나, 웹캐시를 사용하여 LAN 내에서 우선 HTTP 요청을 처리하는 방법이 있다. (전자는 보통 비싸다) 따라서 저렴한 가격으로 트래픽을 더 빠른 LAN 내에서만 이동할 수 있게하므로 외부로 나가는 트래픽의 조절(감소)이 가능하다.

조건부 GET

이러한 웹캐싱의 문제점 중 하나는 바로 프록시 서버의 사본의 최신화 여부다. 캐싱된 값이 웹 서버의 값과 달라서 여러 문제를 일으킬 수 있기 때문이다. 그래서 HTTP는 조건부 GET(conditional GET)을 사용하여 프록시 서버의 응답이 최신화되었는지 여부를 검사할 수 있다.

 

1. 프록시 서버는 웹 서버로부터 객체를 받아오면 이의 사본과 함께 마지막으로 수정된 날짜를 저장하고, 응답을 클라이언트에게 반환한다.

2. 이후 웹 클라이언트가 요청을 보낼 때, HTTP 헤더에 If-modified-since 헤더를 추가한다. 이는 응답으로 내려올 객체가 해당 날짜 이후에 수정된 경우에만 객체를 반환하라는 의미이며, 주로 가장 최근에 프록시 서버로부터 응답을 받은 응답의 마지막으로 수정된 날짜다.

3. 프록시 서버가 자신의 사본이 If-modified-since 헤더의 조건에 부합하지 않는 경우 웹 서버로 요청을 보낸다.

4. 웹 서버는 If-modified-since 헤더의 값 이후로 객체가 변한 경우 변한 값을 내려주고, 변하지 않은 경우 빈 개체 몸체를 반환한다. 응답코드는 304

 

웹 캐시 서버는 일반적으로는 ISP가 설치한다.

HTTP 버전처리

TCP

TCP는 전송계층에서의 두 프로세스 간 통신을 담당하는 프로토콜이다. 특징으로는 서로 데이터를 교환하기 전, 서로 간단히 전송에 대한 정보를 교환하고, 교환이 끝나면 두 프로세스는 TCP 연결되었다고 한다. 또한 모든 데이터를 올바른 순서로, 오류없이 전달한다. 그리고 TCP는 현재 네트워크 링크가 혼잡할 경우, 전송속드를 줄이는 혼잡제어의 기능들도 가지고 있다. 3장에서 제대로 다룬다.

지속연결과 비지속연결

만약 보내야하는 객체가 HTML 파일 1개, 이미지 11개로 총 12개의 객체가 있다고하자.

 

비지속연결에서는 프로세스끼리 TCP 연결된 후, 데이터를 교환하자마자 TCP 연결이 끊어진다. 즉, 객체 1개를 보내자마자 연결이 끊어진다. (정확히는 TCP는 오류가 없어야하므로 데이터를 보낸 후 제대로 받았다는 응답을 받은 후에 연결을 끊는다.) 이를 통해 12개이 객체가 총 12번 TCP 연결을 세운 후에 전부 보내질 수 있다. 시간이 오래걸릴 수 있지만, 프로세스끼리 동시에 여러 개의 TCP 연결을 만들어 병렬적인 데이터 전송도 가능하다.

 

지속연결에서는 데이터를 보낸 후에도 TCP 연결을 유지하고, 데이터가 오가지 않은 채로 일정기간이 지나면 연결을 끊는다. 비지속연결은 결국 요청을 여러 번 만들어야하므로 이 과정에서의 지연들을 예방할 수 있다.

 

HTTP는 지속적 TCP 연결을 사용한다. 즉, 전송계층에서 TCP를 통해 메시지를 송수신하며, TCP연결이 한 번 만들어지면 일정기간동안 아무 데이터가 송수신되지 않는한 연결은 유지된다.

HTTP/1.1에서의 지속적 TCP 연결의 문제

웹페이지에서 하나의 TCP 연결만을 사용한다면 모든 요청은 서로 공평하게 네트워크 대역폭을 나눠가진다.

그러나, HOL(Head Of Line) 블로킹 문제가 발생한다.

 

유튜브와 같은 사이트는 영상 제목, 설명, 댓글 등의 데이터는 작은 편이지만, 영상이라는 데이터는 상당히 큰 편이다. 그래서 웹페이지가 하나의 TCP 연결만을 사용하면 영상과 같이 큰 데이터가 TCP 연결에서 전송 중일 때, 그 뒤에 작은 데이터들은 빨리 전송될 수 있음에도 불구, 자신의 전송차례까지 기다려야한다.

HTTP/1.1에서는 TCP 연결을 여러 개 사용하여 병렬적으로 데이터를 전송했기 때문에 이 문제를 해결할 수 있었다.

 

만약 5개의 TCP 링크가 이미 병목 링크에서 작동 중이고, 사용자가 TCP 연결을 하나 더 만들었다고치면, 6개의 TCP 연결이 생기며 모든 연결은 가능한 대역폭을 나눠가지므로 1/6씩 대역폭을 나눠가진다. 그러나 TCP 연결을 1개가 아니라 3개를 만들어버린다면? 특정 사용자가 3/8의 대역폭을 가질 것이다. 따라서 TCP의 혼잡제어가 무력화될 뿐더러 특정 TCP 연결이 더 많은 대역폭을 할당받을 수 있다. (많은 HTTP/1.1 브라우저는 최대 6개의 연결을 동시에 만들 수 있었다.)

 

따라서 HTTP/1.1의 문제점의 해결은 병렬 TCP 연결의 수를 줄이는 것에 있었다.

HTTP/2 프레이밍

HTTP/2에서는 프레임 인터리빙(Interleaving)을 사용한다.

인터리빙이란 여러 작업들을 조금씩 번갈아가며 수행하는 것을 의미한다. 그리고 이를 위해 HTTP/2에서는 데이터들을 프레임이라는 작은 단위로 쪼갠다. 그리고 번갈아가며 수행하는, 프레임 인터리빙이라는 기술을 사용한다.

 

HTTP/1.1에서의 문제상황에서, 작은 데이터 10개가 2개의 프레임으로, 큰 영상이 1000개의 프레임으로 구성되어있다면, 큰 영상의 프레임을 1개 보내고, 작은 데이터들의 프레임을 1개씩 보내고, 다시 큰 영상의 프레임을 1개 보내고, 작은 데이터들의 마지막 프레임을 1개씩 보내고, 다시 큰 영상을 전송하는 방식이다.

 

따라서 유튜브를 볼 때 제목, 설명글, 댓글과 같은 작은 데이터들은 프레임이 22개가 도착한 후에 완전히 전송받는다. 반대로 HOL 블로킹 문제에서는 1020개의 데이터 프레임이 도착한 후에야 작은 데이터를 받을 수 있었다. 즉, 전송이나 지연시간이 극적으로 줄지는 않더라도 사용자가 체감하는 지연시간은 감소시킬 수 있으면서 HTTP/1.1의 문제점을 해결할 수 있다.

 

따라서 HTTP/2에서 프로세스 간 HTTP 메시지를 보낼 때, 응답 값(메시지)은 여러 개의 프레임으로 쪼개진다. (일반적으로 헤더는 쪼개지지 않고 프레임 하나로 친다.) 쪼개진 프레임들은 인터리빙된 후 TCP 연결 상에서 전송되며, 수신측에서는 이를 조합하여 사용한다.

 

또한 수신된 쪼개진 프레임들을 다시 결합하는 일을 프레이밍이라고한다.

 

이외에도 메시지의 우선순위를 지정하고, 서버가 클라이언트 측으로 응답을 여러 개 보낼 수 있다는 특징들이 있다. 

'CS > 컴퓨터 네트워크' 카테고리의 다른 글

[네트워크] DNS란?  (0) 2026.07.08
[네트워크] 전자메일 - SMTP 프로토콜  (0) 2026.07.08
[네트워크] 지연과 패킷손실, 네트워크 계층 프로토콜  (0) 2026.07.01
[네트워크] 인터넷이란 무엇인가?  (0) 2026.06.30
[네트워크] 혼공네트 독서 #9 - TCP  (0) 2026.01.26

티스토리툴바