네트워크 제대로 알아보자 - 다섯번째 이야기

 

들어가기 전에

지난 번 `네 번째 이야기` 포스팅에 이어 Chapter 5 내용을 정리해보려고 한다.

 

 

Chapter 5. 서버측의 LAN에는 무엇이 있는가_방화벽과 캐시 서버의 탐험

웹 서버와 패킷을 주고 받을 때 라우터에서 패킷을 그대로 중계할 수 있다. 하지만, 현재 이 방법은 주류에서 밀려났다. 그 이유 중 하나가 IP 주소의 부족이고 또 하나는 보안상의 이유이다.

 

사람이 하는일에는 실수가 있게 마련이므로 보안 구멍을 완전 막기는 어렵지만 방치 상태로 서버를 설치하는 것은 현명한 방법이 아니다.

 

액세스 대상이 되는 서버의 소재지(라우터)

 

그림과 같이 방화벽을 두는 방법이 일반화 되었다.

`방화벽`은 네트워크를 외부에서의 공격으로부터 지키기 위해 고안된 구조의 하나로서 이런 종류의 구조 중에는 최초로 등장한 것이다.

현재는 이 구조를 빠져나가는 공격수법이 많이 출현했기 때문에 방화벽과 더불어 바이러스 검사, 부정침입검사, 검역 네트워크 등의 구조를 함께 사용하는 것이 보통이다.

 

`방화벽`은 관문의 역할을 하여 특정서버에서 동작하는 특정 애플리케이션에 액세스하는 패킷만 통과시키고, 그 외의 패킷을 차단하는 역할을 한다.

 

서버에 액세스가 증가할 때, 서버로 통하는 회선을 빠르게 하는 방법이 효과적이지만 회선을 빠르게 하는 것만으로 부족한 경우도 있다. 이때, 서버 머신을 고성능 기종으로 교체 하는것과 서버의 한대 당 처리량을 줄이고 복수의 서버를 분담해 사용하는 분산처리가 있다.

 

분산처리의 가장 단순한 방법은 서버 한 대가 담당하는 사용자 수를 줄이는 방법이다. 예를 들어, www.lab.cyber.co.kr  이 서버명을 3개의 IP 주소를 대응시킨다 가정하자.

 

- 192.0.2.60
- 192.0.2.70
- 192.0.2.80

처음에는 x.x.x.60, x.x.x.70, x.x.x.80을 순서대로 조회하고 이후에는 차례를 바꿔서 회답한다.
그리고 1주기를 순환하고는 원래대로 돌아가는 데 이 방법을 라운드 로빈이라고 한다.

 

 

웹 서버에 대한 액세스를 분배하는 부하 분산 장치

 

웹 서버측에서 보면 HTTP의 대화는 1회씩 전혀 다른 것으로 보여서 받은 리퀘스트가 이전 리퀘스트에 계속되는 것인지, 아니면 이전 리퀘스트와는 관계가 없는 것인지를 판단할 수 없다.

 

이것은 HTTP 프로토콜이 의도적으로 이렇게 하도록 만들어졌기 때문이다. 이러한 전후관계를 판단하려면 웹 서버측의 정보를 유지해야하므로 웹 서버의 부담을 높이는 결과가 된다. 최초의 HTTP 사양에는 정적인 문제만 취급했고 따라서 전후관계를 판단하는 중간 과정이 의도적으로 생략되었다.

 

그렇다면, 그냥 전후관계를 모른채로 송신처 IP 주소가 같다면 전달하면 되지 않을까? 그럴 수 없는게 프록시라는 존재 때문이다. 부하 분산 장치를 사용하게 되면 리퀘스트를 보낸 클라이언트를 판별할 수 없다.

 

전후관계를 판단하기 위해 여러가지 방법이 고안되었다. HTTP 헤더 필드에 부가하는 방법이다. 이 정보를 흔히 `쿠키(cookie)`라고 한다. 부하 분산 장치는 이러한 정보를 조사하여 일련의 동작이면 이전과 같은 웹 서버에 리퀘스트를 전송, 그렇지 않으면 부하가 적은 웹 서버에 전송한다.

 

여러 대의 서버를 설치하는 것이 아닌 다른 방법으로도 부하 분산을 하는 방법도 있다. 역할에 따라 서버를 나누는 방법으로 `캐시 서버`를 사용하는 방법이다. 캐시 서버는 프록시라는 구조를 사용해 데이터를 캐시에 저장하는 서버이다.

 

콘텐츠를 일시 저장하고 대리로 회신하는 캐시 서버

 

캐시 서버를 경유한 것을 나타내는 `Via`라는 헤더 필드를 추가하여 전송한다.

원본 서버의 데이터가 변경된 경우, 캐시 서버의 데이터도 변경 되어야 한다. 이때 웹 서버측에서 데이터가 변경되었는지 조사하기 위한 `If-Modified-Since`라는 헤더 필드를 추가해 전송한다.

 

캐시에 데이터가 저장 되어 있는 경우

 

지금까지 설명은 프록시라는 구조를 웹 서버측에 두고 캐시 기능을 이용하는 것이지만, 사실 캐시 서버에서 이용하는 프록시라는 구조는 원래 클라이언트 측에 두는 방법에서 시작되었다. 이 유형이 프록시의 원형으로 `포워드 프록시`라고 한다.

 

포워드 프록시가 처음 등장했을 때 캐시를 이용하는 것이 목적이었고 방화벽을 실현한다는 중요한 목적이 한 가지 더 있었다. 이 목적을 달성하기 위해 가장 현실적인 방법은 패킷 왕래를 전부 정지시키는 것이다. 그러나 패킷을 전부 정지시키면 인터넷에 대한 액세스도 정지된다. 이렇게 하여 필요한 것을 통과시키는 방법을 생각하기 위해 `프록시`라는 구조를 고안한 것이다.

 

포워드 프록시는 메시지를 전송하는 동작도 서버측에 두는 캐시 서버가 웹 서버를 판단하는 부분이 약간 다르다. 포워드 프록시를 사용할 때 URI 부분에 http://~~~ 라는 URL이 그대로 쓰여있어 웹 서버를 사전에 설정해둘 필요없고 모든 웹서버에 전송할 수 있다.

 

포워드 프록시를 사용할 경우 브라우저에 대한 설정이 꼭 필요한데 설정이 번거롭고 잘못 설정한 경우에는 브라우저가 제대로 작동하지 않는다. 이에 따라 브라우저에 프록시를 설정하지 않아도 사용할 수 있도록 개량되었다. 리퀘스트 메시지의 URI에 쓰여있는 디렉토리 명과 전송 대상의 웹 서버를 대응시켜서 URI 부분에 http://~~~ 라고 쓰여있지 않은 보통의 리퀘스트 메시지를 전송할 수 있도록 했다. 서버 측 캐시 서버가 채택한 방식으로 `리버스 프록시`라고 부른다.

 

패킷의 맨 앞에 있는 IP 헤더에는 수신처 IP 주소가 기록되어 있으므로 이것을 조사하면 액세스 대상 웹서버가 어디에 있는지 알 수 있는데, 이 방법을 `트위스트 페어런트 프록시`라고 부른다.

 

캐시 서버의 배치 장소는 세 종류이다.

 

웹 서버 운영자가 스스로 프로바이더와 계약하여 캐시 서버를 설치하는 것은 비용면, 노력면에서 보통일이 아닌데, 캐시 서버를 설치하고 웹 서버 운영자에게 대출하는 서비스를 제공하는 `콘텐츠 배포 서비스(Content Delivery Service)`가 있다.

 

경로 정보와 연동한 DNS 서버의 동작

 

위 그림처럼 경로표를 이용해 가장 가까운 캐시 서버를 찾는다.

 

리다이렉트로 가장 가까운 캐시 서버에 액세스하는 원리

 

위 그림은 리다이렉트로 가장 가까운 캐시 서버에 액세스하는 원리이다.

 

여기까지가 Chapter 5 내용의 끝이고 다음은 Chapter 6 마지막 포스팅이다.