애플리케이션 계층, HTTP와 애플리케이션 계층 서비스

dobby·2024년 5월 27일

CS 네트워크

HTTP 특성

HTTP는 응용 계층에서 정보를 주고받는데 사용되는 프로토콜이다.
HTTP는 요청과 응답을 기반으로 동작하고, 미디어 독립적이며 상태를 유지하지 않고, 지속 연결을 지원한다.

요청-응답 기반 프로토콜

HTTP는 클라이언트-서버 구조 기반의 요청-응답 프로토콜이다.
즉, 클라이언트와 서버가 서로 HTTP 요청 메시지와 HTTP 응답 메시지를 주고받는 구조로 동작하며 각 메시지는 형태가 다르다.

미디어 독립적 프로토콜

HTTP가 요청하는 대상을 자원이라고 한다.
HTTP는 주고받을 자원의 특성과 무관하게 그저 자원을 주고받을 수단(인터페이스)의 역할만을 수행한다.

HTTP에서 메시지로 주고받는 자원의 종류를 미디어 타입이라 하며, MIME 타입이라고도 부른다.
즉, HTTP는 주고받을 미디어 타입에 특별히 제한을 두지 않고 독립적으로 동작이 가능한 미디어 독립적인 프로토콜이라 할 수 있다.

미디어 타입은 일종의 웹 세상의 확장자와 같은 개념이며, 일반적으로 파일의 종류를 .html, .png, .json, .mp4와 같은 확장자로 나타낼 수 있듯이, HTTP를 통해 송수신하는 정보의 종류는 미디어 타입으로 나타낼 수 있다.

ex) text/html, text/plain, image/png ...

무상태 프로토콜

HTTP는 상태를 유지하지 않는 stateless 프로토콜이다.
서버에서 클라이언트의 상태를 저장하지 않는 것을 의미한다.
따라서 클라이언트는 요청에 필요한 데이터를 모두 가지고 있거나 서버가 클라이언트로부터 받은 요청 사항을 모두 저장해야 한다.
이 방법들을 각각 쿠키(cookie)와 세션(session)이라고 한다.

HTTP가 상태를 유지하는 프로토콜이었다면 클라이언트는 자신의 상태를 기억하는 특정 서버하고만 상호작용할 수 있게 되어 특정 클라이언트가 특정 서버에 종속될 수 있다.

즉, 무상태의 장점은 서버 확장성이 높다는 점이다.
클라이언트의 요청에 응답하는 서버가 바뀌어도 되기 때문에 서버를 계속 확장해도 된다. 따라서 특정 서버에 문제가 생겨 응답하지 못하는 문제점을 보완할 수 있다.
HTTP가 처음 만들어졌을 때부터 오늘날까지 이어지는 중요한 설계 목표는 확장성과 견고성이다.

비연결성 프로토콜

TCP/IP와는 달리 클라이언트에서 요청을 보낸 후 서버로부터 응답을 받으면 연결을 끊는 것을 의미한다.

기본적으로 HTTP는 TCP상에서 동작하는데, HTTP는 비연결형 프로토콜이지만 TCP는 연결형 프로토콜이다.
따라서 초기의 HTTP 버전은 3-way-handshake를 통해 TCP 연결을 수립한 후, 요청에 대한 응답을 받으면 연결을 종료하는 방식으로 동작했다.
이러한 방식을 비지속 연결이라고 한다.

최근 HTTP 버전인 HTTP 3.0은 UDP 상에서 동작한다.

비연결성은 불특정 다수를 대상으로 하는 서비스에 유리하다.
연결을 유지하지 않음으로써 자원을 아낄 수 있기 때문이다.
하지만, 연결을 유지하지 않기 때문에 서버가 클라이언트를 기억할 수 없다는 단점이 있다.
동일한 클라이언트에서 연속적으로 요청이 오면, 연결과 연결 해제 과정을 반복하게 되어 자원을 낭비하게 된다.

하지만 최근 대중적으로 사용되는 HTTP 버전(HTTP 1.1 이상)은 지속 연결이라는 기술을 제공한다.

지속 연결은 일정 시간 동안 연결을 유지할 수 있도록 HTTP Keep Alive를 사용하는 것을 의미한다.
이는 하나의 TCP 연결상에서 여러 개의 요청-응답을 주고받을 수 있는 기술이다.
따라서 마지막 응답 이후 일정 시간 동안 연결을 유지해, 동일한 클라이언트로부터 요청이 오면 연결 과정을 생략할 수 있다.

클라이언트에서 HTTP 요청을 보낼 때 연결 헤더에 Keep Alive를 추가해서 보내면 서버에서 연결을 유지할 시간을 Keep Alive 헤더에 추가해 응답한다.

HTTP 프로토콜에 대해 설명해주세요
HTTP는 응용 계층에서 정보를 주고받는데 사용되는 프로토콜입니다.
HTTP는 클라이언트와 서버의 요청-응답 기반의 프로토콜이자 미디어 독립적이고 stateless하며 지속 연결 기능을 제공하는 프로토콜입니다.
클라이언트가 HTTP 메서드로 서버에게 요청을 보내면, 서버는 HTTP 상태코드로 응답하는 방식으로 동작합니다.

HTTP의 무상태성에 대해 설명해주세요.
Stateless는 서버가 클라이언트의 정보를 유지하지 않는 특성입니다.
서버는 기본적으로 클라이언트에 대한 정보가 없기 때문에 클라이언트가 누군지 식별할 수 없습니다.
클라이언트를 식별하기 위해 쿠키, 세션과 같은 상태유지 기술을 사용할 수 있습니다.
statelss는 서버 확장성이 높다는 장점이 있습니다.
클라이언트의 요청에 응답하는 서버가 바뀌어도 되기 때문에 서버를 계속 확장할 수 있으며, 특정 서버에 문제가 생겨 응답하지 못하는 문제점을 보완할 수 있습니다.

HTTP Keep-Alive에 대해 설명해주세요.
HTTP Keep-Alive는 HTTP 요청/응답시 TCP 연결을 유지하는 기능입니다.
이를 통해 매번 연결을 하지 않아도 여러 개의 요청과 응답을 처리할 수 있기 때문에 웹 응답 속도를 빠르게 할 수 있습니다.

HTTP 메시지 구조

HTTP에서는 클라이언트와 서버가 통신하기 위해 정형화된 데이터인 HTTP 메시지를 주고받는다.
위의 사진은 HTTP 메시지의 구조이다.

시작 라인

HTTP 메시지는 HTTP 요청 메시지일 수도 있고, HTTP 응답 메시지일 수도 있다.
이때 HTTP 메시지가 HTTP 요청 메시지일 경우 시작 라인은 '요청 라인'이 되고, HTTP 메시지가 HTTP 응답 메시지일 경우 시작 라인은 '상태 라인'이 된다.

요청 라인의 형식은 다음과 같다.
메서드 (공백) 요청 대상 (공백) HTTP 버전 (줄바꿈)

GET /example-page HTTP/1.1

요청 방법, 요청 URI, HTTP 버전을 의미한다.

상태 라인의 형식은 다음과 같다.
HTTP 버전 (공백) 상태 코드 (공백) 이유 구문 (줄바꿈)
예시는 아래와 같다.

HTTP/1.1 200 OK
HTTP/1.1 404 Not Found

헤더

각 HTTP 헤더는 콜론(:)을 기준으로 헤더 이름과 하나 이상의 헤더 값으로 구성된다.

GET /example-page HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; ...
Firefox/118.0
Accept: text/html

빈 줄

헤더의 끝을 나타내는 빈 줄로, 헤더와 바디를 구분한다.

바디

요청할 때 요청 방법 메서드가 POST인 경우 바디가 있고, 그 외 메서드일 때는 비어있는 상태로 전달한다.

HTTP의 요청/응답 모델에 대해 설명해주세요.
클라이언트가 서버에게 요청하고 응답받는 모델입니다.
클라이언트는 HTTP 메서드, 헤더, 바디와 함께 서버에게 HTTP 요청을 보냅니다.
서버는 클라이언트가 보낸 HTTP 메서드, 헤더, 바디에 따른 처리를 수행한 다음 상태코드를 통해 HTTP 응답을 클라이언트에게 보냅니다.
클라이언트는 서버로부터 받는 응답을 처리합니다.
예를 들어 HTML을 응답 받았을 경우 화면에 렌더링합니다.

HTTP 헤더가 뭘까요?
HTTP 헤더는 클라이언트와 서버가 어떤 행위를 할건지에 대한 부가 정보입니다.
예를들어 서버가 응답 헤더에 Cache-Control을 추가하여 응답한 데이터가 캐싱되도록 클라이언트에게 알려줄 수 있습니다.

HTTP 메서드 중 GET과 POST의 차이점에 대해 설명해주세요
GET 메서드는 클라이언트가 서버에게 데이터를 요청할 때 사용합니다.
GET에 대한 응답으로 서버는 데이터를 클라이언트에게 응답해줍니다.
POST 메서드는 클라이언트가 서버에게 데이터를 보낼 때 사용합니다.
서버는 POST를 통해 데이터를 받아 저장합니다.

HTTP 메서드 중 PUT과 PATCH의 차이점에 대해 설명해주세요
PUT은 서버 리소스를 전체 수정하고 PATCH는 서버 리소스를 일부 수정합니다.
PUT은 전체 데이터를 수정하는 메서드이므로 멱등이고,
PATCH는 구현에 따라 멱등이 아닐 수 있습니다.
예를들어 호출할 때마다 사용자의 나이를 더하는 PATCH 메서드가 있다면 이는 멱등이 아닙니다.

HTTP 상태 코드가 뭔가요?
HTTP 상태코드는 클라이언트의 요청에 대해 서버가 어떤 결과로 응답했는지 알려줍니다.
HTTP의 상태 코드는 성공을 나타내는 200번대, 리다이렉션을 나타내는 300번대, 클라이언트 에러를 나타내는 400번대, 서버 에러를 나타내는 500번대로 나눌 수 있습니다.

HTTP 파이프라이닝에 대해 설명해주세요
요청에 대한 응답을 기다리지 않고 여러개의 요청을 보내는 것입니다.
응답을 기다리지 않기 때문에 서버와 클라이언트간의 대기 시간을 줄일 수 있습니다.

HTTP/1.1, HTTP/2, HTTP/3 각각의 특징에 대해 설명해주세요.
HTTP/1.1은 오늘날까지 널리 사용되는 버전으로 이전 버전과 달리 지속 연결이 공식적으로 지원되었으며, 파이프라이닝 기능도 추가되었습니다.
HTTP/2는 HTTP/1.1의 효율과 성능을 높이기 위한 버전입니다.
송수신 효율을 높이기 위해 헤더를 압축하여 전송하고, 바이너리 데이터 기반의 메시지를 송수신합니다.
또한 서버 푸시 기능을 제공하기도 합니다.
HTTP/3은 이전 버전들이 TCP 기반으로 동작했다면 3버전은 UDP 기반으로 동작합니다.
연결형 프로토콜인 TCP에 비해 비연결형 프로토콜인 UDP는 상대적으로 더 빠르기 때문에, HTTP/3은 속도 측면에서 큰 개선이 이루어졌습니다.

HTTP 멱등성

HTTP 멱등성이란 동일한 요청을 한 번 보내는 것과 여러 번 연속으로 보내는 것이 같은 효과를 지니고, 서버의 상태도 동일하게 남을 때 해당 HTTP 메서드가 멱등성을 가졌다고 설명한다.

멱등성을 가진 메서드

GET: 처음 요청에 대한 서버 상태가 여러번 요청해도 바뀌지 않고 동일한 상태를 유지한다.
PUT: PUT 요청은 데이터를 통째로 덮어쓰기 하는 것으로, 만약 요청 시에 수정할 데이터를 일부분만 보낼 시 일부분에 해당하지 않는 데이터들은 NULL 값을 가지게 된다. 하지만 이 요청 역시 처음 요청에 대한 서버 상태와 여러 번 요청에 대한 서버 상태가 같으므로 멱등성을 가진다.
DELETE: 존재하는 데이터를 삭제한 결과와 이미 존재하지 않은 결과를 삭제하려는 시도에 대한 응답 코드는 서로 다르겠지만, (200, 404) 서버의 상태 자체는 변하지 않으므로 올바르게 구현되었다면 여러 번 수행되어도 멱등성이 보장될 것이다.

멱등성을 가지지 않는 메서드

POST: 메소드가 호출될 때마다 데이터베이스 등에 요청된 데이터가 추가될 것이고, 이는 곧 멱등성을 위배함을 알 수 있다. 호출 시마다 서버의 상태가 달라지기 때문이다.
PATCH: PUT은 리소스를 통쨰로 바꿔버리기 떄문에 멱등성이 보장되지만, PATCH는 리소스의 일부에 대하여 변화를 명령할 수 있기 때문에 항상 멱등성을 보장한다고 이야기할 수 없다.

안전한 메소드

안전한 메소드란, 서버의 상태를 변경시키지 않는 HTTP 메소드를 의미한다. GET, OPTIONS , HEAD 와 같은 조회에 사용되는 메소드를 안전하다고 이야기할 수 있다.

PUT과 DELETE 메소드는 멱등성을 갖지만, 리소스를 수정하고 제거하므로 안전한 메소드라고는 이야기할 수 없다.

즉, 멱등성을 갖는 메소드가 서버의 상태를 변경하지 않는다고 오해하면 안된다. 멱등성을 갖는 메소드도 서버의 상태를 변경시킬 수 있다. 멱등성의 핵심은 “요청에 대한 서버의 상태가 항상 같은가?”이다.

애플리케이션 계층 서비스

P2P 파일 분배

웹, 전자메일, DNS는 모두 켜져 있는 서버에 상당히 의존하는 클라이언트-서버 구조를 채택하고 있다.
하지만 P2P 구조는 서버에 최소한으로 의존하며 대신 간헐적으로 연결되는 호스트(피어) 쌍들이 서로 직접 통신한다.
피어는 서비스 제공자가 소유하는 것이 아니라 사용자가 제어하는 데스크톱과 랩톱, 스마트폰이 소유한다.

클라이언트-서버 파일 분배에서 서버는 파일 복사본을 각 피어들에게 보내야 한다.
이는 서버에게 커다란 부하를 주고 많은 양의 서버 대역폭을 소비한다.
P2P 파일 분배에서 각 피어는 수신한 파일의 임의의 부분을 다른 피어들에게 재분배할 수 있어서 서버의 분배 프로세스를 도울 수 있다.

자가 확장성

P2P 구조는 클라이언트-서버 구조의 분배 시간보다 적은 시간이 소요되며 P2P 구조를 가진 애플리케이션은 자가 확장성을 갖는다.
따라서 피어는 소비자이자 재분배자가 될 수 있다.

스트리밍 및 DASH

녹화된 비디오는 서버에 저장되어 사용자가 비디오 시청을 서버에게 온디맨드로 요청한다.
비디오의 중요한 특징은 압축될 수 있다는 것인데, 비디오 품질과 비트 전송률은 서로 반비례한다. (trade-off)
스트리밍 비디오에서 가장 중요한 성능 척도는 종단 간 평균 처리량이며, 연속재생을 제공하기 위해 네트워크는 압축된 비디오의 전송률 이상의 스트리밍 애플리케이션에 대한 평균 처리량을 제공해야 한다.
또한 압축을 사용하여 동일한 비디오를 여러 버전의 품질로 만들 수 있다.

DASH

서버가 HTTP 응답 메시지 내에서 비디오 파일을 전송하면, 클라이언트 쪽에선 애플리케이션 버퍼에 전송된 바이트가 저장된다.

이 버퍼의 바이트 수가 미리 정해진 임계값을 초과하면 클라이언트 애플리케이션이 재생을 시작한다.

클라이언트로 데이터를 보내는 과정에서 가용 대역폭의 차이는 각기 다른 클라이언트들 간에 존재할 뿐만 아니라 동일한 클라이언트에서도 시간에 따른 차이가 발생한다.

이를 개선하기 위해 HTTP 기반 스트리밍인 DASH가 개발되었다.

DASH 동작 방법

DASH에서 비디오는 여러 가지 버전으로 인코딩되며, 각 버전은 비트율과 품질 수준이 서로 다르다.
클라이언트는 동적으로 서로 다른 버전의 비디오를 몇 초 분량의 길이를 갖는 비디오 조각 단위로 요청한다.
가용 대역폭이 충분할 때는 높은 비트율의 비디오 버전을 요청하며, 가용 대역폭이 적을 때는 낮은 비트율의 비디오 버전을 요청한다.

DASH를 사용할 때, 각 비디오 버전은 HTTP 서버에 서로 다른 URL을 가지고 저장된다.
HTTP 서버는 비트율에 따른 각 버전의 URL을 제공하는 매니페스트 파일(manifest file)을 갖고 있다.

클라이언트는 먼저 매니페스트 파일을 요청하여 서버에서 제공되는 다양한 버전에 대해 알게 된다.
이후 클라이언트는 매번 원하는 버전의 비디오 조각 단위 데이터를 선택하여 HTTP GET 요청 메시지에 URL과 byte-range를 지정하여 요청한다.

즉, DASH는 클라이언트가 서로 다른 품질 수준을 자유롭게 변화시킬 수 있도록 허용한다.

CDN

Content Delivery Network
엄청난 데이터를 전 세계에 걸친 지점에 안정적으로 제공하는 것은 매우 어려운 문제이다.
서비스를 제공하는 가장 단순한 방법은 단일 데이터 센터를 구축하여 전 세계의 사용자에게 데이터 센터로부터 직접 전송하는 것이다.
하지만 이는 문제가 있다.

클라리언트가 데이터 센터로부터 지역적으로 먼 지점에 있는 경우, 종단 간 처리율이 낮아 좋지 않은 사용자 경험을 제공하게 된다.
인기 있는 데이터는 같은 통신 링크를 통해 여러 번 반복적으로 전송된다.
단일 데이터 센터는 한 번의 장애로 인해 전체 서비스가 중단될 수 있는 위험이 있다.

이렇듯 엄청난 양의 데이터를 분배하는 문제를 해결하기 위해 거의 대부분의 네트워크 기업은 CDN(콘텐츠 분배 네트워크)를 이용한다.

CDN은 지리적으로 분산된 서버들을 연결한 네트워크로서 웹 컨텐츠의 복사본을 사용자의 가까운 곳에 두거나 동적 컨텐츠의 전달을 활성화하여 웹 성능 및 속도를 향상할 수 있게 한다.

각 CDN 서버는 이른바 ‘네트워크 엣지’에 위치한다. 웹사이트의 출처라 할 수 있는 호스트 서버와 비교하면 사용자와의 거리가 더 가깝다.
이러한 이유로 CDN 서버는 흔히 엣지 서버로 불리곤 한다.

각 서버는 호스트 서버에 있던 웹 컨텐츠(HTML 파일, 이미지, 오디오, 비디오, 애플리케이션 등) 일부의 복사본을 저장하거나 캐싱한다.

CDN 사용의 장점

웹 퍼블리셔를 위한 연결 기능 및 확장성 강화
CDN은 이 컨텐츠와 사용자 간의 거리를 줄여 웹사이트 퍼블리셔가 성능을 향상하고 확장성을 강화할 수 있도록 한다.
CDN은 사이트 사용자의 컨텐츠 로딩 시간을 단축한다.
사용자가 경험하는 로딩 시간을 단축하고, 대역폭 소비 및 비용을 관리할 수 있게 한다.
대역폭 사용량 감축
웹 호스트는 원래 서버로부터 전송되는 데이터를 기준으로 요금을 부과한다. CDN은 사용자와 더 가까운 곳에 컨텐츠의 복사본을 저장함으로써 원래 서버로부터의 데이터 전송량을 줄인다. 그러면 기업의 대역폭 사용량 및 비용이 절약된다.
레이턴시 단축(latency)
시스템에 데이터를 요청하는 시점과 시스템에서 그에 응답하여 데이터를 보내기 시작하는 시점 사이의 지연 시간을 의미한다. 웹 컨텐츠를 요청하는 사용자와 이를 제공하는 서버 간의 거리가 길 수록 레이턴시가 늘어날 수 있다.
CDN 서버는 사용자와 더 가까운 곳에 웹 컨텐츠를 저장하므로, 레이턴시를 단축하고 성능을 향상할 수 있다.
트래픽 급증에 더 효과적 대응
CDN에서는 로드 밸런싱을 사용하여 급증하는 수요를 여러 서버에 분산시킴으로써 하나의 서버에 과부하가 일어나는 것을 방지한다. 로드 밸런싱은 수요 급증이 웹사이트 성능에 영향을 미치는 것을 방지하는 효과도 있다.

CDN 작동 방식

CDN은 웹사이트의 원래 서버와 달리 사용자에게 더 가까이에 있는 서버로부터 컨텐츠를 배포하는 방식으로, 웹 퍼블리셔가 더 빠르고 우수한 품질의 성능을 사용자에게 제공하도록 지원한다.

이를테면 웹사이트가 영국에 있다고 가정하자.
미국에 거주하는 누군가가 이 사이트에 엑세스할 경우, CDN은 영국에 있는 원래 서버가 아니라 미국에 있는 엣지 서버, 즉 사용자에게 더 가까운 서버에서 해당 웹 페이지를 서비스한다.
그러면 컨텐츠 로딩이 빨라지고 웹 애플리케이션 성능이 향상되며 결국 사용자 경험도 좋아진다.

전체 웹 트래픽의 절반 이상이 CDN을 통해 서비스되는 중이다.

기업에서 글로벌 거점을 확대하고 더 다양한 컨텐츠 유형을 제공함에 따라 이 비율은 계속 증가하고 있다.
게다가 CDN은 트래픽 로드를 분산시켜 어느 한 서버에 트래픽 요청이 집중되지 않게 한다.
게임 회사, 클라우드, 애플리케이션 개발자, 글로벌 시장을 대상으로 하는 전자 상거래 사이트 등으로 인해 디지털 소비 요구 사항이 증가함에 따라 컨텐츠 소유자는 사용자에게 더 좋은 서비스를 제공하고자 CDN을 활용한다.

NEXT. 네트워크 안정성을 위한 기술1

도서
혼자 공부하는 네트워크