Chapter 8. Integration Points: Gateways, Tunnels, and Relays
(해석 또는 이해가 잘못된 부분이 있다면 댓글로 편하게 알려주세요.)
✏️ 원문 번역
Resource Gateways
So far, we’ve been talking about gateways that connect clients and servers across a network. However, the most common form of gateway, the application server, combines the destination server and gateway into a single server. Application servers are server-side gateways that speak HTTP with the client and connect to an application program on the server side (see Figure8-8).
-
앞서 우리는 게이트웨이에 대해 이야기했습니다. 게이트웨이는 네트워크를 통해 클라이언트와 서버를 연결하는 매개체입니다.
-
하지만 게이트웨이의 일반적인 형태인 애플리케이션 서버는 목적 서버와 게이트웨이를 하나의 단일한 서버로 결합한 것입니다.
-
애플리케이션 서버는 클라이언트와 HTTP로 통신하는 서버 사이드 게이트웨이이자, 서버 측의 다른 응용 프로그램을 연결하는 장치입니다. (Figure 8-8)
In Figure 8-8, two clients are connecting to an application server using HTTP. But, instead of sending back files from the server, the application server passes the requests through a gateway application programming interface (API) to applications running on the server:
• Client A’s request is received and, based on the URI, is sent through an API to a digital camera application. The resulting camera image is bundled up into an HTTP response message and sent back to the client, for display in the client’s browser.
• Client B’s URI is for an e-commerce application. Client B’s requests are sent through the server gateway API to the e-commerce software, and the results are sent back to the browser. The e-commerce software interacts with the client, walking the user through a sequence of HTML pages to complete a purchase.
-
Figure 8-8 상에서 두 클라이언트가 HTTP를 통해 애플리케이션 서버에 연결되어 있습니다.
-
하지만 애플리케이션 서버는 서버로부터 파일을 수신받는 대신 게이트웨이 API를 통해 서버에서 구동중인 응용 프로그램으로 요청을 전달합니다.
-
수신된 클라이언트 A의 요청은 URI에 따라 API를 통해 카메라 응용 프로그램으로 전달됩니다. 카메라 이미지는 HTTP 응답 메시지에 실려 클라이언트로 반환되며 사용자의 브라우저에 표시됩니다.
-
클라이언트 B의 URI는 이커머스 응용 프로그램을 나타냅니다. B의 요청은 서버 게이트웨이 API를 통해 이커머스 소프트웨어로 전달되며 결과를 브라우저로 반환합니다. 이커머스 소프트웨어는 클라이언트와 상호작용하여 사용자가 일련의 HTML 페이지를 따라 구매를 완료할 수 있도록 안내합니다.
The first popular API for application gateways was the Common Gateway Interface(CGI). CGI is a standardized set of interfaces that web servers use to launch programs in response to HTTP requests for special URLs, collect the program output, and send it back in HTTP responses. Over the past several years, commercial web servers have provided more sophisticated interfaces for connecting web servers to applications.
-
애플리케이션 게이트웨이에 대한 API 중 가장 널리 사용되는 것은 Common Gateway Interface, 일명 CGI입니다.
-
CGI는 웹 서버가 특정 URL에 대한 HTTP 요청을 받았을 때 프로그램을 실행하여 결과를 수집하고, 다시 HTTP 응답으로 반환하도록 하는 표준화된 인터페이스 집합입니다.
-
지난 몇 년간 상업용 웹 서버는 응용 프로그램에 웹 서버를 연결하기 위해 보다 정교한 인터페이스를 제공하기 시작했습니다.
Early web servers were fairly simple creations, and the simple approach that was taken for implementing an interface for gateways has stuck to this day.
-
초기의 웹 서버는 상당히 간단한 구조였습니다.
-
그리고 지금까지도 게이트웨이용 인터페이스를 구현하기 위해 이런 단순한 접근 방식이 고수되고 있습니다.
When a request comes in for a resource that needs a gateway, the server spawns the helper application to handle the request. The helper application is passed the data it needs. Often this is just the entire request or something like the query the user wants to run on the database (from the query string of the URL; see Chapter2).
-
게이트웨이를 필요로 하는 리소스에 대한 요청이 들어왔을 때, 서버는 요청을 처리하기 위한 헬퍼 애플리케이션을 도입합니다.
-
헬퍼 애플리케이션에는 요청된 데이터가 전달됩니다.
-
이 데이터는 종종 전체 요청일 수도 있고 사용자가 데이터베이스에 실행하고자 하는 쿼리 같은 요소일 수도 있습니다. (URL의 쿼리 문자열은 Chapter 2 참고)
It then returns a response or response data to the server, which vectors it off to the client. The server and gateway are separate applications, so the lines of responsibility are kept clear. Figure 8-9 shows the basic mechanics behind server and gateway application interactions.
-
헬퍼 애플리케이션은 응답이나 응답용 데이터를 서버에 반환하고, 서버가 이를 클라이언트에 반환합니다.
-
서버와 게이트웨이는 분리된 응용 프로그램이므로 서로 책임의 영역이 명확합니다.
-
Figure 8-9는 서버와 게이트웨이 응용 프로그램 상호작용의 이면에서 동작하는 기본적인 매커니즘을 보여줍니다.
This simple protocol (request in, hand off, and respond) is the essence behind the oldest and one of the most common server extension interfaces, CGI.
- 요청이 들어오면 작업을 전달하고 응답하는 이 단순한 프로토콜이 가장 역사가 깊고 일반적인 서버 확장 인터페이스인 CGI의 핵심 요소입니다.
Common Gateway Interface (CGI)
The Common Gateway Interface was the first and probably still is the most widely used server extension. It is used throughout the Web for things like dynamic HTML, credit card processing, and querying databases.
-
CGI는 최초로 만들어진 서버 확장 API이자, 현재까지도 가장 널리 사용되고 있는 인터페이스입니다.
-
동적 HTML, 신용카드 처리, 데이터베이스 쿼리 등 웹 전반에 걸쳐 사용되고 있습니다.
Since CGI applications are separate from the server, they can be implemented in almost any language, including Perl, Tcl, C, and various shell languages. And because CGI is simple, almost all HTTP servers support it. The basic mechanics of the CGI model are shown in Figure 8-9.
-
CGI 응용 프로그램은 서버와 분리되어 있어 어떤 언어로든 구현할 수 있습니다. Perl, Tcl, C, 그 밖의 다른 Shell 언어도 포함입니다.
-
CGI는 단순하기 때문에 대부분의 HTTP 서버가 이것을 지원하고 있습니다.
-
CGI 모델의 기본적인 매커니즘은 Figure 8-9와 같습니다.
CGI processing is invisible to users. From the perspective of the client, it’s just making a normal request. It is completely unaware of the hand-off procedure going on between the server and the CGI application. The client’s only hint that a CGI application might be involved would be the presence of the letters “cgi” and maybe “?” in the URL.
-
CGI 프로세싱은 사용자에게 보이지 않습니다.
-
클라이언트의 관점에서는 일반 요청을 처리하는 것과 다를 것이 없습니다.
-
클라이언트는 서버와 CGI 응용 프로그램 사이에서 일어나는 핸드오프(전달) 과정에 대해 전혀 알지 못합니다.
-
물론 URL에 있는 "cgi" 혹은 "?" 문자를 통해 CGI 응용 프로그램이 개입할 것이라는 점을 추측할 수는 있습니다.
So CGI is wonderful, right? Well, yes and no. It provides a simple, functional form of glue between servers and pretty much any type of resource, handling any translation that needs to occur. The interface also is elegant in protecting the server from buggy extensions (if the extension were glommed onto the server itself, it could cause an error that might end up crashing the server).
-
그래서 CGI는
개쩌는 것인가요? -
맞을 수도 있고 아닐 수도 있습니다.
-
CGI가 필요한 모든 번역 작업을 처리함으로써 서버와 다양한 타입의 리소스를 연결할 수 있는 단순한 기능적 형태를 제공하는 것은 사실입니다.
-
인터페이스는 버그가 있는 확장 프로그램으로부터 서버를 보호할 수 있는 우아한 수단이기도 합니다. (만약 잘못된 확장 프로그램이 서버 자체에 침입한다면 오류를 발생시키거나 서버 자체가 손상될 수도 있습니다.)
However, this separation incurs a cost in performance. The overhead to spawn a new process for every CGI request is quite high, limiting the performance of servers that use CGI and taxing the server machine’s resources. To try to get around this problem, a new form of CGI—aptly dubbed Fast CGI—has been developed. This interface mimics CGI, but it runs as a persistent daemon, eliminating the performance penalty of setting up and tearing down a new process for each request.
-
그러나 이러한 분리는 성능상의 문제를 야기합니다.
-
CGI 요청이 들어올 때마다 새로운 프로세스를 생성하는 것은 상당히 큰 오버헤드가 발생합니다.
-
이로 인해 CGI를 사용하는 서버의 성능은 제한되며 리소스에 큰 부담이 가해질 수 있습니다.
-
문제를 해결하기 위해 새로운 형태의 CGI인 Fast CGI가 개발되었습니다.
-
Fast CGI는 CGI를 표방하고 있지만 영구적인 데몬 프로세스를 동작시켜 각 요청마다 새로운 프로세스를 생성하는 오버헤드를 제거하였습니다.
Server Extension APIs
The CGI protocol provides a clean way to interface external interpreters with stock HTTP servers, but what if you want to alter the behavior of the server itself, or you just want to eke every last drop of performance you can get out of your server? For these two needs, server developers have provided server extension APIs, which provide a powerful interface for web developers to interface their own modules with an HTTP server directly. Extension APIs allow programmers to graft their own code onto the server or completely swap out a component of the server and replace it with their own.
-
CGI 프로토콜은 HTTP 서버와 결합된 외부 인터프리터를 연결하는 명확한 수단을 제공합니다.
-
하지만 사용자가 서버의 동작 자체를 변경하고 싶거나 서버로부터 얻을 수 있는 모든 성능을 최대한으로 끌어내고 싶다면 어떨까요?
-
위의 두 가지 요구사항에 맞춰 서버 개발자들은 서버 확장 API를 제공하게 되었습니다.
-
서버 확장 API는 웹 개발자가 자신의 모듈을 HTTP 서버를 직접적으로 연결할 수 있는 강력한 인터페이스를 제공합니다.
-
확장 API는 개발자가 자신의 코드를 서버에 접목시키거나 서버의 구성 요소를 자신의 코드로 대체하는 것을 가능하게 합니다.
Most popular servers provide one or more extension APIs for developers. Since these extensions often are tied to the architecture of the server itself, most of them are specific to one server type. Microsoft, Netscape, Apache, and other server flavors all have API interfaces that allow developers to alter the behavior of the server or provide custom interfaces to different resources. These custom interfaces provide a powerful interface for developers.
-
상용 서버들은 개발자를 위해 하나 이상의 확장 API를 제공하고 있습니다.
-
이러한 확장 API는 서버 아키텍처 자체에 결합되어 있는 경우가 많기 때문에 대부분 하나의 서버 유형에 한정되어 있습니다.
-
Microsoft, Netscape, Apache를 비롯한 서버들은 개발자가 서버의 동작을 변경하거나 다른 리소스에 대한 커스텀 인터페이스를 제공할 수 있도록 서로 다른 API 인터페이스를 가지고 있습니다.
-
이러한 커스텀 인터페이스는 개발자를 위한 강력한 인터페이스입니다.
One example of a server extension is Microsoft’s FrontPage Server Extension (FPSE), which supports web publishing services for FrontPage authors. FPSE is able to interpret remote procedure call (RPC) commands sent by FrontPage clients. These commands are piggybacked on HTTP (specifically, overlaid on the HTTP POST method). For details, see “FrontPage Server Extensions for Publishing Support” in Chapter 19.
-
서버 확장 API의 한 가지 예시는 Microsoftdml FrontPage Server Extension(FPSE)입니다.
-
FPSE는 FrontPage 저자를 위한 웹 게시 서비스를 지원하며, FrontPage 클라이언트에 의해 전송된 Remote Procedure Call (RPC) 명령을 번역할 수 있습니다.
-
이러한 명령들은 HTTP에 Piggybacking 됩니다(메시지 끝에 첨부됩니다). 특히 HTTP POST 메서드에 되는 경우가 많습니다.
-
자세한 내용은 Chapter 19의 "FrontPage Server Extensions for Publishing Support" 부분을 참고합니다.
✏️ 요약
Application Server
- Gateway의 일반적인 형태로, 목적 서버와 게이트웨이를 하나로 결합한 형태
** Gateway : HTTP를 다른 프로토콜이나 응용 프로그램과 연결하는 인터페이스 - HTTP/* 서버 사이드 게이트웨이이자 서버 측의 다른 응용 프로그램을 연결하는 장치
- 게이트웨이에 대한 API로 CGI를 주로 사용
Common gateway Interface (CGI)
: 특정 URL에 대한 HTTP 요청이 들어오면 헬퍼 애플리케이션을 실행하여 처리한 후 HTTP 응답의 형태로 다시 반환하는 인터페이스
- 장점 : CGI 응용 프로그램을 다양한 언어로 개발할 수 있다, 다양한 타입의 리소스를 연결할 수 있다, 버그가 있는 확장 프로그램으로부터 서버를 보호할 수 있다
- 단점 : 요청이 들어올 때마다 새로운 프로세스를 생성하기 위한 오버헤드가 발생한다
** Fast CGI : 데몬 프로세스 내에서 요청을 처리하여 오버헤드 감소
Server Extension APIs
: 개발자가 자신의 모듈을 서버에 접목시키거나 서버의 구성 요소를 직접 수정할 수 있게 하는 인터페이스
- 서버의 동작 자체를 변경하거나 성능을 최대한으로 끌어낼 수 있음
- 서버 아키텍처 자체에 결합되어 있는 경우가 많음
- FPSE : FrontPage 클라이언트가 전송한 RPC 명령을 번역하는 Server Extension API
✏️ 감상
오늘도 스포당함 근데 일주일 쉬어서 다시 읽음
ㅋㅋㅋㅋㅋ 한 번 쉬니까 진짜 끝도 없이 쉬게 되는 것 같다... 일주일이나 쉬고 왔더니 앞 내용을 다 잊어버려서 다시 읽고 왔다. 근데 앞에서 공부한 내용 복습했더니 오늘은 별로 새로운 내용이 없는 느낌이다. 오늘 내용이 CGI인지 모르고 지난번에 CGI랑 Fast CGI까지 궁금해서 다 찾아본 덕에 정말 편하게 읽었다 👍🏻 짧게라도 그 날 그 날 <감상> 부분에 궁금한 내용들을 조사하고 정리해 놓는 게 되게 도움이 많이 되는 것 같다...!
그래서 오늘도 몇 가지 준비해 봤다. ㅎㅁㅎ
API가 너무 많아요
여기저기서 API라는 말을 참 많이 쓴다. 가장 대표적인 것이 REST API이고, 이게 무엇인지는 대부분의 개발자가 이미 알 거라고 생각한다. 말로는 설명 못하더라도 이미 느낌적인 느낌으로 말이다. REST는 Representational State Trasnfer의 약자로, 어떤 리소스에 대한 상태의 천이를 의미한다. 즉, 어떤 자원에 대한 CRUD를 수행하는 API라는 뜻이다.
그럼 도대체 API란 무엇인가? 이 용어를 이해하기 위해서는 일단 "인터페이스"라고 하는 단어의 뉘앙스를 알아야 한다. 나는 영어에 대한 감이 대단히 없는 편이라 항상 한국말로 번역이 되지 않는 이런 용어들이 참 어렵게 느껴졌다. 그래도 학부 다니면서 이 단어를 백만 번 듣고 깨달은 점이 있다면...ㅋㅋ 대충 인터페이스라는 건 어떤 두 개의 요소를 중간에서 연결하고 통신시키기 위한 가상의 관문이다. 그 중에서도 API는 Application Programming Interface니까 응용 프로그램 개발에 사용되는 모든 인터페이스를 통칭하는 표현이다.
즉 REST API는 HTTP를 통해 클라이언트와 서버(리소스를 제공하는 시스템)를 연결하는 인터페이스인 셈이다. 오늘 글에 등장한 Server Extension API도 마찬가지로 프로그래머가 개발한 어떤 모듈 혹은 프로그램과 서버 응용 프로그램을 연결하는 인터페이스라고 이해하면 된다.
API라고 하면 항상 ABI도 같이 얘기하더라
사실 왜 괜히 헷갈리게 ABI라는 단어를 만들었을까 싶긴 한데... low-level에서는 API와 ABI를 구별해서 표현한다. ABI는 Application Binary Interface의 약자다. 아마 조금 딥한 프로그래밍을 해본 사람들이라면 컴퓨터 자원을 사용하기 위해 운영체제를 활용해야 할 일이 있었을 것이다. 보통 이렇게 운영체제를 사용해야 할 일이 있으면 내장 라이브러리에 있는 함수를 호출해서 내부적으로 System Call을 호출한다. 우리가 라이브러리를 사용한다는 것은 어쨌든 메모리 상에 올라간 응용 프로그램을 가지고 소통하는 것이기 때문에 우리가 호출하는 라이브러리 함수를 API라고 이야기할 수 있다.
하지만 라이브러리 함수가 System Call을 호출하는 것은 API라고 할 수 없다. API는 응용 프로그램 레벨에서의 인터페이스고, 이건 응용 프로그램과 커널 사이의 인터페이스기 때문이다. API와 ABI를 굳이굳이 구별해서 이야기하는 이유는 아마도 두 인터페이스의 성격이 조금 다르기 때문일 것이다. API는 응용 프로그램 레벨의 인터페이스기 때문에 하드웨어에 대해 고려할 필요가 없다. 하지만 ABI는 System Call을 비롯하여 ISA와 같은 CPU 명령 집합의 호출 규약을 정의하고 있으므로 하드웨어에 의존적일 수밖에 없다.
말이 조금 어려워서 호출 규약 예시를 GPT한테 물어보니까 대충 이런 거라고 한다.
x86-64 시스템에서 open() API는 내부적으로 시스템 콜 번호 2를 사용하며, 호출 규약에 따라 rdi 레지스터에 파일 경로 포인터를 전달한다.
