Chapter 10. HTTP-NG
(해석 또는 이해가 잘못된 부분이 있다면 댓글로 편하게 알려주세요.)
✏️ 원문 번역
Layer 1. Messaging
Let’s take a closer look at the three layers of HTTP-NG, starting with the lowest layer. The message transport layer is concerned with the efficient delivery of messages, independent of the meaning and purpose of the messages. The message transport layer provides an API for messaging, regardless of the actual underlying network stack.
-
HTTP-NG의 3계층에 대해 더 자세히 알아봅시다.
-
메시지 전송 레이어는 메시지의 내용과 목적에 관계없이 메시지를 효율적으로 전송하기 위해 사용됩니다.
-
내부의 실제 네트워크 스택과 무관하게 메시지를 전송하기 위한 API를 제공합니다.
This layer focuses on improving the performance of messaging, including:
• Pipelining and batching messages to reduce round-trip latency
• Reusing connections to reduce latency and improve delivered bandwidth
• Multiplexing multiple message streams in parallel, over the same connection, to optimize shared connections while preventing starvation of message streams
• Efficient message segmentation to make it easier to determine message boundaries
- 메시지 전송 레이어는 메시징의 성능을 향상시키기 위해 다음과 같은 요소들에 집중하고 있습니다.
- 요청/응답 지연을 최소화하기 위한 메시지 파이프라이닝 및 배치 처리
- 지연을 줄이고 대역폭을 효율적으로 사용하기 위한 연결 재사용
- 여러 개의 메시지 스트림을 같은 연결에 병렬로 멀티플렉싱하여 공유 연결 최적화 및 메시지 스트림의 Starvation 방지
- 메시지의 경계를 더 쉽게 결정하기 위한 효율적인 메시지 분할 방식
The HTTP-NG team invested much of its energy into the development of the Web-MUX protocol for layer 1 message transport. Web-MUX is a high-performance message protocol that fragments and interleaves messages across a multiplexed TCP connection. We discuss WebMUX in a bit more detail later in this chapter.
-
HTTP-NG 팀은 첫 번째 레이어인 메시지 전송 레이어에서 사용할 Web-MUX 프로토콜을 개발하는 데 많은 노력을 투자하였습니다.
-
Web-MUX는 다중화된 TCP 연결을 통해 흘러가는 메시지를 조직화하고 인터리빙하기 위한 고성능 메시지 프로토콜입니다.
(* 인터리빙 : 데이터 스트림을 뒤섞어 효율성을 높이고 데이터 손실을 줄이는 방식) -
Web-MUX에 대해서는 이번 챕터에서 추후에 자세히 다룹니다.
(* 내일 읽을 부분입니다.)
Layer 2. Remote Invocation
The middle layer of the HTTP-NG architecture supports remote method invocation. This layer provides a generic request/response framework where clients invoke operations on server resources. This layer does not concern itself with the implementation and semantics of the particular operations (caching, security, method logic, etc.); it is concerned only with the interface to allow clients to remotely invoke server operations.
-
HTTP-NG 아키텍처의 중간 레이어는 원격 메서드 호출을 지원합니다.
-
클라이언트가 서버 리소스에 대한 연산을 호출할 수 있도록 요청/응답 프레임워크를 제공합니다.
-
특정 연산(캐싱, 보안, 메서드 로직 등)의 구현 방식과 의미와는 전혀 관련이 없습니다.
-
오직 클라이언트가 원격으로 서버의 연산을 수행할 수 있게 하는 인터페이스에 대해서만 고려합니다.
Many remote method invocation standards already are available (CORBA, DCOM, and Java RMI, to name a few), and this layer is not intended to support every nifty feature of these systems. However, there is an explicit goal to extend the richness of HTTP RMI support from that provided by HTTP/1.1. In particular, there is a goal to provide more general remote procedure call support, in an extensible, object-oriented manner.
-
지금도 이미 사용 가능한 원격 메서드 호출 표준은 많이 존재합니다(COBRA, DCOM, Rava RMI 등).
-
다만 이 레이어가 위와 같은 시스템들의 멋진 기능들을 지원하기 위한 것은 아닙니다.
-
HTTP/1.1에서 제공되는 HTTP RMI를 더 풍부하게 지원하고자 하는 것이 명확한 목표입니다.
-
특히 확장 가능한 객체 지향 방식으로 더 일반적인 원격 프로시저 호출 방식을 지원하고자 하는 목표가 있습니다.
The HTTP-NG team proposed the Binary Wire Protocol for this layer. This protocol supports a high-performance, extensible technology for invoking well-described operations on a server and carrying back the results. We discuss the Binary Wire Protocol in a bit more detail later in this chapter.
-
HTTP-NG 팀은 해당 레이어에서 Binary Wire Protocol을 사용하는 것을 제안하였습니다.
-
이 프로토콜은 고성능의 확장 가능한 기술을 지원하여 서버에서 잘 설명된 연산을 호출하고 결과를 돌려받을 수 있습니다.
-
Binary Wire Protocol에 대해서는 챕터 후반부에서 자세히 다룹니다.
(* 내일 읽을 부분입니다.)
Layer 3. Web Application
The web application layer is where the semantics and application-specific logic are performed. The HTTP-NG working group shied away from the temptation to extend the HTTP application features, focusing instead on formal infrastructure.
-
웹 응용 프로그램 레이어는 의미와 프로그램 로직을 수행하는 것과 연관되어 있습니다.
-
HTTP-NG 워킹 그룹은 HTTP 응용 프로그램의 기능을 확장하려는 유혹을 뿌리치고 공식적인 인프라에 집중하기로 했습니다.
The web application layer describes a system for providing application-specific services. These services are not monolithic; different APIs may be available for different applications. For example, the web application for HTTP/1.1 would constitute a different application from WebDAV, though they may share some common parts. The HTTP-NG architecture allows multiple applications to coexist at this level, sharing underlying facilities, and provides a mechanism for adding new applications.
-
응용 프로그램 레이어는 응용 프로그램에 특화된 서비스를 제공하기 위한 시스템을 나타냅니다.
-
서비스는 monolithic 하지 않을 수 있습니다. 다양한 응용 프로그램에 대해 다양한 API를 이용할 수도 있습니다.
-
예를 들어 HTTP/1.1에 대한 웹 응용 프로그램은 WebDAV와 일정 부분을 공유할 수는 있지만 다른 응용 프로그램으로 구성됩니다.
-
HTTP-NG 아키텍처는 해당 레이어에서 여러 응용 프로그램이 내부의 기능을 공유하며 혼재하는 것을 허용하고 새로운 응용 프로그램을 추가하기 위한 매커니즘을 제공하고자 합니다.
The philosophy of the web application layer is to provide equivalent functionality for HTTP/1.1 and extension interfaces, while recasting them into a framework of extensible distributed objects. You can read more about the web application layer interfaces at http://www.w3.org/Protocols/HTTP-NG/1998/08/draft-larner-nginterfaces-00.txt.
-
웹 응용 프로그램 레이어의 철학은 다른 프레임워크나 확장성 있는 분산 객체를 사용하더라도 동일하게 HTTP/1.1과 확장 인터페이스 기능을 제공하는 것입니다.
-
웹 응용 프로그램 레이어의 인터페이스에 관한 자세한 내용은 http://www.w3.org/Protocols/HTTP-NG/1998/08/draft-larner-nginterfaces-00.txt 에서 확인하실 수 있습니다.
✏️ 요약
Message Transport Layer
: 메시지의 내용과 목적, 내부의 네트워크 스택과 무관하게 메시지를 효율적으로 전송하기 위한 레이어
- 파이프라이닝 및 배치 처리 : 요청/응답 지연 최소화
- 연결 재사용 : 지연 감소, 효율적인 대역폭 사용
- 멀티플렉싱 : 공유 연결 최적화 및 Starvation 방지
- 메시지 조각화 : 효율적인 메시지 분할을 통한 성능 향상
- Web-MUX 프로토콜 사용 : 다중화된 TCP 연결을 통해 흘러가는 메시지를 조직화하고 인터리빙하기 위한 프로토콜
Remote Invocation Layer
: 클라이언트가 원격으로 서버 리소스에 대한 연산을 호출할 수 있도록 하기 위한 요청/응답 프레임워크를 제공하는 레이어
- 어떤 연산인지(구현 방식과 의미)와는 연관 X
- HTTP/1.1에서 제공되는 RMI를 더 풍부하게 지원하기 위한 목적
- 확장성이 있는 객체 지향 방식으로 원격 호출을 지원하는 것이 목표
Web Application Layer
: 응용 프로그램에 특화된 서비스를 제공하기 위한 레이어
- 여러 응용 프로그램이 내부의 기능을 공유하며 혼재
- 새로운 응용 프로그램을 추가하기 위한 매커니즘 제공
- 다른 프레임워크나 분산 객체를 사용하더라도 동일하게 적용 가능하게 함
✏️ 감상
Interleaving을 쓰면 왜 효율적일까
네트워크에서 인터리빙(Interleaving)란 전송하고자 하는 데이터들을 여러 개의 패킷이나 프레임에 분산하여 전송하는 방식이다. 여기서 데이터를 분산한다는 것은 하나의 큰 데이터를 여러 개의 패킷으로 쪼갠다는 것이 아니라, 여러 개의 데이터를 순서를 섞어 전송한다는 뜻이다. 그런데 도대체 데이터를 분산하는 것이 왜 성능 향상에 도움이 되는 것일까?
손실이 없는 환경에서는 인터리빙을 사용하는 것이 오히려 비효율적이겠지만 우리의 네트워크 환경은 손실이 0이 아니다. 대체로 네트워크가 혼잡하거나 특히 무선 통신의 경우 간섭이 심할 때 발생하므로 패킷은 연속적으로 손실되는 경향이 있다. 이러한 손실을 Burst Loss라고 한다.
인터리빙을 사용하지 않는다면 Burst Loss에 대처하기가 상당히 어렵다. 하나의 덩어리 데이터가 연속적인 패킷에 실려 전송되기 때문에 복구 가능성이 현저히 낮아진다.
자기 전에 누워서 유튜브를 보려고 하는데 동영상 데이터가 인터리빙 없이 온다고 생각해보자. 무선 통신은 자그마한 벽이나 전자레인지에도 영향을 받는 연약한 녀석이다. 그런데 1초에 n프레임을 전송해야 하는 동영상 데이터가 연속적인 패킷에 실려 날아오고 있다. 잠깐 자세를 고치는 순간 동영상이 몇 초 동안 멈추거나 음성이 끊기게 될지도 모른다. 모처럼 일을 마치고 쉬려고 누웠는데 동영상이 끊기면 화가 나지 않겠는가.
그러니 인터리빙은 아쥬 중요하다!
