(해석 또는 이해가 잘못된 부분이 있다면 댓글로 편하게 알려주세요.)
You can direct HTTP traffic to gateways the same way you direct traffic to proxies. Most commonly, you explicitly configure browsers to use gateways, intercept traffic transparently, or configure gateways as surrogates (reverse proxies).
HTTP 트래픽이 프록시로 향하게 하는 것과 마찬가지로 트래픽을 게이트로 향하게 할 수 있습니다.
브라우저가 게이트웨이를 사용하도록 설정하거나, 트래픽을 투명하게 가로채거나, 게이트웨이를 Surrogate(리버스 프록시)로 구성하는 것이 가장 일반적입니다.
Figure 8-3 shows the dialog boxes used to configure a browser to use server-side FTP gateways. In the configuration shown, the browser is configured to use gw1.joes-hardware.com as an HTTP/FTP gateway for all FTP URLs. Instead of sending FTP commands to an FTP server, the browser will send HTTP commands to the HTTP/FTP gateway gw1.joes-hardware.com on port 8080.
Firue 8-3은 Server-side FTP 게이트웨이를 사용하도록 하기 위한 다이얼로그 박스를 나타냅니다.
아래 구성과 같이 브라우저는 모든 FTP URL에 대한 HTTP/FTP 게이트웨이로 gw1.joes-hardware.com을 사용합니다.
브라우저는 FTP 명령을 FTP 서버로 전송하는 대신 HTTP/FTP 게이트웨이인 gw1.joes-hardware.com의 8080번 포트에 HTTP 명령을 전송합니다.
The result of this gateway configuration is shown in Figure 8-4. Normal HTTP traffic is unaffected; it continues to flow directly to origin servers. But requests for FTP URLs are sent to the gateway gw1.joes-hardware.com within HTTP requests. The gateway performs the FTP transactions on the client’s behalf and carries results back to the client by HTTP.
게이트웨이 구성의 결과는 Figure 8-4와 같습니다.
일반적인 HTTP 트래픽은 영향을 받지 않고 원본 서버를 향해 그대로 전송됩니다.
그러나 FTP URL에 대한 요청은 HTTP 요청의 형태로 gw1.joes-hardware.com 게이트웨이에 전송됩니다.
게이트웨이는 클라이언트를 대신하여 FTP 트랜잭션을 수행하고 결과를 HTTP로 반환합니다.
The following sections describe common kinds of gateways: server protocol converters, server-side security gateways, client-side security gateways, and application servers.
다음 섹션에서는 게이트웨이의 일반적인 유형에 대해 설명합니다.
게이트웨이는 주로 Server Protocol Converters(서버 프로토콜 변환기), Server-Side Security Gateways(서버 사이드 보안 게이트웨이), Client-Side Security Gateways(클라이언트 사이드 보안 게이트웨이), Application Servers(애플리케이션 서버)로 활용됩니다.
Server-side web gateways convert client-side HTTP requests into a foreign protocol, as the requests travel inbound to the origin server (see Figure 8-5).
In Figure8-5, the gateway receives an HTTP request for an FTP resource:
ftp://ftp.irs.gov/pub/00-index.txt
Figure 8-5에서 게이트웨이는 FTP 리소스에 대한 HTTP 요청을 받습니다.
ftp://ftp.irs.gov/pub/00-index.txt
The gateway proceeds to open an FTP connection to the FTP port on the origin server (port 21) and speak the FTP protocol to fetch the object. The gateway does the following:
• Sends the USER and PASS commands to log in to the server
• Issues the CWD command to change to the proper directory on the server
• Sets the download type to ASCII
• Fetches the document’s last modification time with MDTM
• Tells the server to expect a passive data retrieval request using PASV
• Requests the object retrieval using RETR
• Opens a data connection to the FTP server on a port returned on the control channel; as soon as the data channel is opened, the object content flows back to the gateway
When the retrieval is complete, the object will be sent to the client in an HTTP response.
게이트웨이는 원본 서버의 FTP 포트(21번)에 FTP 연결을 열고 FTP 프로토콜을 통해 오브젝트를 불러옵니다.
이때 게이트웨이의 역할은 다음과 같습니다.
FTP를 통하여 오브젝트가 성공적으로 반환되면 HTTP 응답으로 클라이언트에게 해당 오브젝트를 전달합니다.
Gateways can be used to provide extra privacy and security for an organization, by encrypting all inbound web requests. Clients can browse the Web using normal HTTP, but the gateway will automatically encrypt the user’s sessions (Figure 8-6).
게이트웨이는 인바운드 되는 모든 웹 요청을 암호화하여 조직의 추가적인 개인정보 보호 및 보안 기능을 제공하기 위해 사용될 수 있습니다.
클라이언트는 일반적인 HTTP를 사용하여 브라우징을 수행하지만 게이트웨이는 자동으로 사용자의 세션을 암호화할 것입니다. (Figure 8-6)
Recently, HTTPS/HTTP gateways have become popular as security accelerators. These HTTPS/HTTP gateways sit in front of the web server, usually as an invisible intercepting gateway or a reverse proxy. They receive secure HTTPS traffic, decrypt the secure traffic, and make normal HTTP requests to the web server (Figure 8-7).
최근에는 보안 가속기로 HTTPS/HTTP 게이트웨이를 자주 사용하고 있습니다.
HTTPS/HTTP 게이트웨이는 대개 보이지 않는 Intercepting Gateway나 리버스 프록시의 형태로 웹 서버 앞에 위치하고 있습니다.
이들은 HTTPS 트래픽을 받은 후 트래픽을 복호화하여 일반적인 HTTP 요청을 웹서버에 전달합니다. (Figure 8-7)
These gateways often include special decryption hardware to decrypt secure traffic much more efficiently than the origin server, removing load from the origin server. Because these gateways send unencrypted traffic between the gateway and origin server, you need to use caution to make sure the network between the gateway and origin server is secure.
이러한 게이트웨이는 원본 서버보다 효율적으로 보안 트래픽을 복호화하여 서버의 부하를 제거하기 위해 종종 특수한 복호화 하드웨어를 포함하기도 합니다.
게이트웨이는 원본 서버까지 암호화되지 않은 트래픽을 전송하기 때문에 그 사이의 네트워크 보안을 유지하는 데 주의를 기울여야 합니다.
오늘 공부한 내용에 따르면 암호화된 트래픽을 전송하고자 할 때 두 가지 방식 중 하나를 선택할 수 있다. 하나는 HTTP/HTTPS 게이트웨이를 사용하여 서버 사이드에서 요청을 암호화하는 방식, 다른 하나는 HTTPS/HTTP 게이트웨이를 사용하여 클라이언트 사이드에서 요청을 암호화하는 방식이다. 그럼 이 두 방식 중에 더 선호하는 방식은 무엇일까?
먼저 HTTP/HTTPS 방식은 원본 서버에 암호화된 요청이 인바운드 되기 때문에 이를 복호화하기 위한 오버헤드가 발생한다. 반면 HTTPS/HTTP 방식은 원본 서버에서 추가적인 복호화를 수행하지 않기 때문에 상대적으로 부하가 덜하다. 서버의 부하가 줄어드는 것만으로도 시간과 비용을 아낄 수 있으므로 권장되는 방식은 HTTPS/HTTP이다.
두 방식 모두 클라이언트와 게이트웨이 사이, 혹은 게이트웨이와 서버 사이에서 패킷이 탈취당할 위험이 있다는 것은 동일하다. 때문에 HTTP로 트래픽이 전달되는 네트워크 구간을 안전하게 유지하는 것이 상당히 중요하다. HTTP/HTTPS 방식은 외부 네트워크에 무방비하게 HTTP 트래픽이 노출되는 구간이 분명히 존재할 수 밖에 없다. 하지만 HTTPS/HTTP 게이트웨이를 사용하는 경우 외부 네트워크에서는 안전하게 HTTPS를 유지하고 내부 네트워크에서 HTTP로 성능을 최적화 할 수 있다. 그런 점에서 보안상 더 유리한 것도 HTTPS/HTTP 게이트웨이라고 볼 수 있다.