웹 서버와 HTTP가 통신하는 방법

1

Web & Network

목록 보기
8/9
post-thumbnail

서버 '단 1대'로 멀티 도메인을 가능하게 하는 가상 호스트

HTTP/1.1에서는 하나의 HTTP 서버에 여러 개의 웹 사이트를 실행할 수 있습니다. 예를 들면, 웹 호스팅을 제공하고 있는 사업자는 1대의 서버에 여러 고객의 웹 사이트를 넣을 수 있습니다.

고객마다 다른 도메인을 가지고, 다른 웹 사이트를 실행할 수 있는 것이죠. 이것은 가상 호스팅(Virtual Host)라는 기능을 사용하고 있기 때문입니다.

가상 호스팅을 사용하면 실제론 서버가 한 대이지만, 가상으로 서버가 여러대 있는 것 처럼 설정이 가능한것이죠.

인터넷에서 도메인명은 DNS에 의해서 IP 주소로 변환되고 나서 액세스하게 됩니다. 이 과정은 아래와 같습니다.

Ex)

  • 클라이언트 : DNS에 https://www.google.com/ 도메인 전달
  • DNS : 전달받은 도메인을 10.52.xx.xx IP 주소로 변환

DNS가 도메인을 IP 주소로 변환하였기 떄문에, 결국은 리퀘스트가 IP 주소를 기준으로 액세스하게 됩니다.

근데 위에서 말한 가상 호스팅을 사용하는 상황이라면, 한 대의 서버 안에서 여러개의 호스트가 있기에 IP 주소는 같을텐데, 이런 경우 어느 쪽에 대한 액세스인지 알 수 없습니다.

따라서 HTTP 리퀘스트를 보내는 경우에는 호스트명과 도메인명을 완전하게 포함한 URI를 지정하거나, 반드시 Host 헤더 필드에서 지정해야 합니다.


통신을 중계하는 프록시, 게이트웨이, 터널

HTTP는 클라이언트와 서버 이외에 프록시, 게이트웨이, 터널과 같은 통신을 중계하는 프로그램과 서버를 연계하는 것도 가능합니다.

이러한 프로그램과 서버는 그 다음에 있는 다른 서버에 리퀘스트를 중계하고, 그 서버로부터 받은 리스폰스를 클라이언트에 반환하는 역할을 담당합니다.


프록시

프록시는 클라이언트와 서버의 양쪽 역할을 하는 중간 다리의 역할입니다. 클라이언트가 서버에 리퀘스트를 보내면 프록시 서버를 걸쳐서 오리진 서버에 도착하죠.

오리진 서버 : 리소스 본체를 가진 서버

오리진 서버에 도착한 리퀘스트는 다시 프록시 서버를 걸쳐서 클라이언트에 돌아옵니다.

당연하게도 여러대의 프록시 서버를 경유하는 것도 가능합니다.

프록시 서버를 사용하면 좋은점이 있는데, 바로 캐싱입니다. 캐싱은 CS에서도 자주 등장하고, JPA 같은 기술들에서도 비슷하게 적용되는 사례들이 많습니다.

캐싱에 대해서는 아래서 더 자세히 설명하겠습니다.

프록시의 사용 방법은 여러 가지가 있는데, 크게 2가지로 나뉩니다.

프록시의 사용 방법

  1. 캐시를 하는지 안하는지 여부 판단
  2. 메시지를 변경 하는지 안하는지 여부 판단

프록시 - 캐싱 프록시

프록시로 리스폰스를 중계하는 때에는 프록시 서버 상에 리소스 캐시를 보존해 두는 타입의 프록시입니다.

캐시를 간단하게 설명하자면 오리진 서버에 도달해서 한번 사용한 리소스를 프록시 서버에 보존해 두고 다음에 사용할 때 오리진 서버가 아닌 프록시 서버에서 캐시를 리스폰스로 돌려주는 방식입니다.

당연히 먼 곳까지 안가고 바로 앞에있는 곳에서 리스폰스를 받아오니 속도가 더 빨라집니다.

Ex) 처음 웹 페이지를 요청했을 때와 한번 더 같은 페이지를 요청했을 때 시간차이가 나는 것

하지만 캐시 서버에 캐시가 있는 경우라도 같은 리소스의 리퀘스트에 대해서 항상 캐시를 돌려 준다고는 말할 수 없는데요.

그 이유는 캐시에 유효기간이 있기때문입니다. 이것은 캐시되어 있는 리소스의 유효성과 관계가 있습니다.

etc) 클라이언트도 인터넷 임시 파일이라고 불리는 캐시가 있습니다.


프록시 - 투명 프록시

프록시로 리퀘스트와 리스폰스를 중계할 때 메시지 변경을 하지 않는 타입의 프록시를 투명 프록시라고 합니다.

반대로 메시지에 변경을 하는 타입을 비투과 프록시라고 합니다.


게이트웨이

게이트웨이의 동작은 프록시와 거의 같은데요, 게이트웨이는 다른 서버를 중계하는 서버로 클라이언트로부터 받은 리퀘스트를 리소스를 보유한 오리진 서버인 것 마냥 받습니다.

이게 무슨 말이냐면 게이트웨이는 "서버인 척 하는 중간다리"라고 생각하시면 될 것 같습니다.

또한 게이트웨이는 클라이언트 사이를 암호화하는 방식으로 통신의 안전성을 높입니다.

예를 들면 게이트웨이는 데이터베이스에 접속해서 데이터를 얻는데 사용하거나, 보안이 중요한 결제 시스템등에 사용됩니다.


터널

터널은 눈에 보이지 않는 투명한 개념입니다. 터널은 여규에 따라서 다른 서버와의 통신 경로를 확립합니다.

이 떄 클라이언트는 암호화 통신을 통해 서버와 안전하게 통신하기 위해 사용합니다.

터널 자체는 리퀘스트를 해석하려고 하지 않으며 리퀘스트를 받은 그대로 다음 서버에 넘겨줍니다. 터널은 통신중인 양쪽 끝의 접속이 끊어질 때에 종료됩니다.

한마디로 터널은 -> 안전한 통신로를 확립해주는 개념 (터널을 통해서 리퀘스트가 이동하면 안전하다고 생각하면 됩니다.)

0개의 댓글