성공과 실패를 결정하는 1%의 네트워크 원리 5장: 방화벽과 캐시 서버

Chapter 5. 서버측의 LAN에는 무엇이 있는가?

인터넷에 들어간 패킷이 통신 회선이나 프로바이더의 네트워크를 통해 서버측의 POP로 운반된 이후에는

패킷은 서버를 향해 나아가서 서버의 바로 앞에 있는 방화벽, 캐시 서버, 부하 분산 장치 등을 통과하는데 이것에 대해 공부해보자.

01. 웹 서버의 설치 장소

1. 사내에 웹 서버를 설치하는 경우

• 사내의 LAN에 서버를 설치하고, 인터넷에서 직접 액세스하는 경우에 패킷은 가장 가까운 POP에 있는 라우터, 액세스 회선, 서버측 라우터를 경유하여 서버 머신에 도착한다. 이 방식은 보안 문제, IP 부족으로 인해 현재 많이 사용하는 방식이 아니다.
• 지금은 방화벽으로 분리하는 방식을 많이 채택한다. 방화벽은 관문의 역할을 하여 특정 서버에서 동작하는 특정 애플리케이션에 액세스하는 패킷만 통과시키고, 그 외의 패킷을 차단하는 역할을 한다. 그래도 액세스를 허가한 애플리케이션에 보안 구멍이 있으면 위험성이 남아있다.

2. 데이터센터에 웹 서버를 설치하는 경우

• 프로바이더 등이 운영하는 데이터 센터라는 시설에 서버를 가지고 들어가서 설치하거나 프로바이더가 소유하는 서버를 빌려쓰는 형태로 운영하는 경우도 있다. 안전성이 높은 것이 장점이다.

02. 방화벽의 원리와 동작

1. 패킷 필터링형이 주류이다.

• 방화벽의 기본이 되는 개념은 앞에서 설명했듯이 특정 서버와 해당 서버 안의 특정 애플리케이션에 액세스하는 패킷만 통과시키고, 그 외의 패킷을 차단한다. 
• 방화벽은 현재 성능, 가격, 사용 편의성 등의 이유로 패킷 필터링형이 제일 많이 보급되어 있다.

2. 패킷 필터링의 조건 설정 개념

• 패킷의 헤더에는 통신 동작을 제어하는 제어 정보가 들어있다. MAC헤더, IP 헤더, TCP 헤더 or UDP 헤더를 통해 패킷 필터링의 조건으로 설정할 수 있다.
• 패킷 필터링을 사용해 웹 서버에서 인터넷의 액세스를 금지하도록 패킷을 차단한다.
• 수신처나 송신처의 주소에 따라 패킷이 어디서, 어디로 흘러가는지를 판단하여 통과시킬 것인지, 차단할 것인지 결정하는 것이 첫걸음이다.

3. 애플리케이션을 한정할 때 포트 번호를 사용한다.

• 웹 이외의 애플리케이션의 패킷을 전부 차단하는 쪽이 좋다.
• 애플리케이션을 한정할 때는 TCP 헤더나 UDP 헤더에 기록되어 있는 포트 번호를 조건으로 추가한다.
• 즉 수신처 IP 주소가 웹 서버의 주소와 일치하고, 수신처 포트 번호가 80번인 패킷은 통과한다.
• 또한 송신처 IP 주소가 웹 서버의 주소와 일치하고 송신처 포트 번호가 80번인 패킷도 통과하도록 설정한다.
• 그리고 웹 서버 이외의 애플리케이션에 대한 액세서를 허가할 경우에는 이 애플리케이션의 포트 번호를 설정하여 이것이 통과하도록 한다.

4. 컨트롤 비트로 접속 방향을 판단한다.

• 패킷이 흐르는 방향이 아니라 액세스 방향을 판단해 정지시켜야 하는데, 여기에서 도움이 되는 것이 TCP 헤더에 있는 컨트롤 비트다.
• TCP는 최초에 행하는 접속 단계의 동작에서 3개의 패킷이 흐르는데, 최초의 패킷만 TCP 컨트롤 비트의 SYN이라는 비트가 1로 되고,
  ACK라는 비트가 0이 된다.
• 다른 패킷에서 같은 값을 취하는 경우는 없으므로 이 값을 조사해서 최초의 패킷과 두 번째 이후의 패킷을 판별할 수 있다.

5. 사내 LAN에서 공개 서버용 LAN으로 조건을 설정한다. 

• 인터넷과 공개 서버용 LAN을 왕래하는 패킷의 조건을 설정할 뿐만 아니라 사내 LAN과 인터넷 또는 사내 LAN과 공개 서버용 LAN을 왕래하는 패킷의 조건도 설정해야 한다.

6. 밖에서 사내 LAN으로 액세스할 수 없다.

• 패킷 필터링형 방화벽은 패킷을 통과시킬지, 차단시킬지를 판단할 뿐만 아니라 주소 변환의 기능도 가지고 있으므로 설정도 필요하다.
• 즉 인터넷과 사내 LAN을 왕래하는 패킷은 주소 변환을 해야한다.
• 주소 변환을 이용하면 당연히 인터넷측에서 사내 LAN에는 액세스할 수 없게 된다.
• 따라서 사내 LAN에 대한 액세스를 금지하도록 패킷 필터링의 조건을 설정할 필요가 없다.

7. 방화벽을 통과한다.

• 패킷이 도착하면 조건에 해당하는지 판정하고, 통과시킬지와 차단할지를 결정한다.
• 이렇게 판정한 후 차단한 대상이 되면 패킷을 버리고 버린 기록을 남긴다.
• 버린 패킷 중에는 부정 침입의 흔적을 나타내는 것이 있으므로 이것을 분석하여 침입자의 수법을 밝히거나 향후 부정 침입 대책에 도움이 될 수 있기 때문이다.
• 패킷 필터링은 라우터의 부가 기능이라고 생각하면 좋다.
• 판정 조건이 많아지면 라우터에 설정하기 부담스럽다. 또한 패킷을 버린 기록을 남기는 것도 부담스러운데 이렇게 되면 
  전용 하드웨어나 소프트웨어를 사용한다.
• 정리하면 패킷 필터링형 방화벽은 수신처 IP 주소, 송신처 IP 주소, 수신처 포트 번호, 송신처 포트 번호, 컨트롤 비트 등으로 패킷을 통과시킬지 판단한다.

8. 방화벽으로는 막을 수 없는 공격

• 방화벽은 패킷 흐름의 시점과 종점을 보고 통과시킬지, 차단할지 판단하는데, 시점과 종점만 보고 위험한 패킷을 전부 판단할 수 있는 것은 아니다.
• 웹서버가 특수한 데이터를 포함한 패킷을 받으면 다운된다고 가정해보자.
  패킷의 내용을 조사하지 않으면 위험할지 판단할 수 없는데 방화벽의 구조는 이러한 상황에 대처할 수 없다.
• 이러한 상황은 두 가지 대처법이 있다.
• 먼저 웹 서버 소프트웨어의 버그에 있으므로 버그를 고쳐서 다운되지 않도록 하는 것이 첫 번째 대처법이다.
• 두 번째는 패킷의 내용을 조사해 위험한 데이터가 포함되어 있는 경우에 패킷을 차단하도록 장치나 소프트웨어를 방화벽과는 별도로 준비하는 방법이다.

03. 복수 서버에 리퀘스트를 분배한 서버의 부하 분산

1. 처리 능력이 부족하면 복수 서버로 부하 분산된다.

• 서버에 액세스가 증가할 때는 서버로 통하는 회선을 빠르게 하는 방법이 효과적이지만, 회선을 빠르게 하는 것만으로 부족한 경우가 있다.
• 이때 가장 먼저 떠오르는 방법은 서버 머신을 고성능 기종으로 교체한는 것이다. 그래도 트래픽이 늘어나면 아무리 고성능의 기종을 사용해도 한 대로는 따라잡지 못할 수 있다.
• 이럴 경우 복수의 서버를 사용해 처리를 분담하는 방법이 효과적이다. 이러한 처리 방법을 통틀어 분산 처리라고 하는데, 처리를 분담하는 방식은 여러가지다.
• 가장 간단한 방법은 단순히 여러 대의 웹 서버를 설치하고 한 대가 담당하는 사용자 수를 줄이는 방법이다.
• 이 방법은 클라이언트가 보내는 리퀘스트를 웹 서버에 분배하는 구조가 필요하다. 구체적인 방법은 몇 가지가 있는데, DNS 서버에서 분배하는 방법이 가장 간단하다.
• 서버에 액세스할 때 DNS 서버에 조회하여 IP 주소를 조사하는데, DNS 서버에 같은 이름으로 여러 대의 웹 서버를 등록해 놓으면 DNS 서버는 조회가 있을 때마다 차례대로 IP 주소를 돌려준다. 이런 방식을 라운드 로빈이라고 한다.
• 이 방법에는 결점이 있다. 웹 서버가 많으면 고장나는 것도 있는데,  고장난 웹 서버를 신경쓰지 않고 그저 순서대로 IP 주소를 회답한다.
• 또한 CGI 등의 애플리케이션에서 페이지를 만드는 경우 복수의 페이지에 걸쳐 대화할 수 있는데, 웹 서버가 변하면 대화가 도중에 끊길 수 있다.

2.부하 분산 장치를 이용해 복수의 웹 서버로 분할된다.

• 위에서 언급한 좋지 않은 상태를 피하기 위해 부하 분산 장치 또는 로드 밸런서 등으로 부르는 기기가 등장했다.
• 부하 분산 장치를 사용할 때는 먼저 부하 분산 장치를 웹 서버 대신 DNS 서버에 등록한다.
• 그러면 클라이언트는 부하 분산 장치가 웹 서버라고 생각하여 여기에 리퀘스트 메시지를 보내야 할지 판단하고, 웹 서버에 리퀘스트 메시지를 전송한다.
• 여기에서의 요점은 어느 웹 서버에 리퀘스트를 전송해야 할지 판단하는 부분이다.
• 판단 근거는 여러가지가 있지만, 대화가 복수의 페이지에 걸쳐있는지에 따라 판단 기준이 전혀 다르다.
• 복수 페이지에 걸쳐있지 않은 단순한 액세스라면 웹 서버의 부하 상태가 판단 근거가 될 것이다.
• 웹 서버와 정기적으로 정보를 교환하여 CPU나 메모리의 사용률 등을 수집하고, 이것을 바탕으로 어느 웹 서버의 부하가 낮은지 판단하거나,. 시험 패킷을 웹 서버에 보내 응답 시간으로 부하를 판단하는 방법이 일반적이다.
• 단, 웹 서버의 부하는 단시간에 증가하거나 감소하므로 꼼꼼히 상황을 조사하지 않으면 정확한 곳까지 파악할 수 없다.
  그렇다고 너무 자세한 상황을 조사하려면 부하를 조사하는 동작 자체로 웹 서버의 부하가 증가한다.
• 정리하면 특정 웹 서버에 부하가 집중되지 않도록 한다는 점은 모든 방법에 공통이다.
• 대화가 복수 페이지에 걸쳐있을 때는 웹 서버의 부하에 관계 없이 이전의 리퀘스트와 같은 웹 서버에 전송해야 한다.
• 이렇게 하려면 먼저 대화가 복수 패이지에 걸쳐있는지 판단해야 하는 것이 요점이다. 
• 전후 관계를 알지 않아도 리퀘스트의 송신처 IP 주소가 같다면 일련의 것이 라는 식으로 간단히 판단하면 되지만, 그럴 수 없다.
• 전후 관계를 판단하기 위해 여러 가지 방법이 고안되었는데, 양식에 입력한 데이터를 보낼 때 그 안에 전후의 관련을 나타내는 정보를 부가하거나 HTTP 헤더에 필드에 부가하는 방법이다.
• 부하 분산 장치는 이러한 정보를 조사해 일련의 동작이라면 이전과 같은 웹 서버에 리퀘스트를 전송하고, 그렇지 않으면 부하가 적은 웹서버에 전송하도록 동작한다.

04. 캐시 서버를 이용한 서버의 부하 분산

1. 캐시 서버의 이용

• 역할에 따라 서버를 나누는 방법으로도 부하 분산을 처리할 수 있는데 그 중 하나가 캐시 서버를 사용하는 방법이다.
• 캐시 서버는 프록시라는 구조를 사용하여 데이터를 캐시에 저장하는 서버다.
• 프록시는 웹 서버와 클라이언트 사이에 들어가서 웹 서버에 대한 액세스 동작을 중개하는 역할을 하는데, 액세스 동작을 중개할 때 웹 서버에서 받은 데이터를 디스크에 저장해 두고 웹 서버를 대신하여 데이터를 클라이언트에 반송하는 기능을 가지고 있다.
• 이것을 캐시라고 부르며, 캐시 서버는 이 기능을 이용한다.
• 캐시 서버쪽은 웹 서버에서 받아 보존 해 둔 데이터를 읽어서 클라이언트에 송신만 하므로 웹 서버보다 빨리 데이터를 송신할 수 있다.
• 캐시에 데이터를 저장한 후 웹 서버측에서 데이터가 변경되면 캐시의 데이터를 사용할 수 없다. 늘 캐시를 사용할 수 있는 것은 아니라는 뜻이다.
• 그러나 조금이라도 캐시 서버에서 액세스 동작을 고속화할 수 있으면 전체 성능이 향상된다. 캐시 서버에서 리퀘스트를 처리하면 그 만큼 웹 서버의 부하가 줄면서 웹 서버의 처리 시간을 단축할 수 있다.

2. 캐시 서버는 갱신일로 콘텐츠를 관리한다.

• 캐시 서버를 사용할 때는 부하 분산 장치와 마찬가지로 캐시 서버를 웹 서버 대신 DNS 서버에 등록한다.
• 그러면 사용자는 캐시 서버에 HTTP 리퀘스트 메시지를 보낼 것이고, 캐시 서버가 메시지를 받는다. 수신 동작은 웹 서버와 동일하다.
• 캐시 서버가 리퀘스트 메시지를 받으면 메시지의 내용을 조사하고, 데이터가 자신의 캐시에 저장되었는지 조사한다.

먼저 데이터가 캐시에 저장되지 않은 경우다.

• 데이터가 캐시에 저장되어 있지 않다면 리퀘스트 메시지에 캐시 서버를 경유한 것을 나타내는 'Via'라는 헤더 필드를 추가해 웹 서버에 리퀘스트 메시지를 전송한다.
• 웹 서버가 한 대밖에 없으면 웹 서버의 도메인 명이나 IP 주소를 캐시 서버에 설정해 두고 무조건 거기에 전송한다.
• 한 대의 캐시로 여러 대의 서버의 데이터를 캐시하는 경우에는 이런 방법이 곤란하다.
• 리퀘스트 메시지의 내용에 따라 전송 대상의 웹 서버를 판단하는 방법이 필요하다.
• 대표적인 방법은 리퀘스트 메시지의 URI의 디렉토리를 보고 판단하는 방법이다.
• 이 설정을 보고 리퀘스트 메시지를 전송한다. 이때 전송 대상의 웹 서버에 대해 캐시 서버가 클라이언트가 되어 리퀘스트 메시지를 보낸다.
• 웹 서버에서 보면 캐시 서버가 클라이언트로 보인다. 웹 서버에서 캐시 서버에 응답메시지가 돌아오므로 이것을 받는다.
• 그럼 응답 메시지에 캐시 서버를 경유한 것을 나타내는 'Via' 헤더 필드를 부가해, 클라이언트에 대해 웹 서버가 되어 응답 메시지를 전송한다.
• 그리고 응답 메시지를 캐시에 저장하고 저장한 일시를 기록한다.
• 이렇게 클라이언트와 웹 서버 사이를 중개하는 것이 프록시 구조다.
• 그리고 중개할 때 페이지의 데이터를 저장하면 캐시 서버에 데이터가 축적되고, 사용자는 액세스한 페이지가 캐시 서버에 저장되어 있는 경우가 증가한다. 

다음은 데이터가 캐시에 저장되어 있는 경우다.

• 먼저 사용자로부터 도착한 리퀘스트 메시지를 받아 캐시에 저장되었는지 조사한다.
• 그리고 웹 서버측에서 데이터가 변경되었는지 조사 하기 위한 'If-Modified-Since' 라는 헤더 필드를 추가해 웹 서버에 전송한다.
• 웹 서버는 'If-Modified-Since' 헤더 필드의 값과 페이지 데이터의 최종 갱신 일시를 비교하여 변경이 없으면 변경이 없는 것을 나타내는 응답 메시지를 반송한다.
• 이때 웹 서버는 데이터의 최종 갱신 일시를 조사하는 것으로 끝나므로 페이지 데이터를 반송하는 것보다 부담이 적어진다.
• 이후 응답 메시지는 캐시 서버에 또착하는데, 이렇게 해서 캐시에 저장한 데이터가 최신 데이터와 같은 것을 알 수 있으므로 캐시 서버는 캐시에서 데이터를 추출해 사용자에게 보낸다.
• 웹 서버측에서 데이터가 변경된 경우에는 캐시에 데이터가 저장되지 않은 경우와 동일하다.
• 웹 서버는 최신 데이터를 반송하므로 응답 메시지에 'Via'  헤더를 부가해 사용자에게 전송하고 데이터를 캐시에 저장한다.

3. 프록시의 원점은 포워드 프록시다.

• 캐시 서버에서 이용하는 프록시라는 구조는 원래 클라이언트측에 두는 방법에서 시작되었다.
• 이 유형이 프록시의 원형으로, 포워드 프록시라고 한다.
• 포워드 프록시가 처음 등장했을 때 캐시를 이용하는 것이 목적이었다. 이것은 서버측에 설치하는 캐시 서버와 같지만, 당시의 포워드 프록시는 방화벽을 실현한다는 중요한 목적이 한 가지 더 있었다.
• 프록시는 리퀘스트의 내용을 조사한 후 전송하므로 리퀘스트의 내용에 따라 액세스가 가능한지 판단할 수 있다.
  즉 위험한 사이트나 작업과 관계 없는 사이트에 대한 액세스는 금지한다는 액세스 제한을 마련할 수 있다.
• 포워드 프록시를 사용할 경우에는 보통 브라우저의 설정 화면에 준비되어 있는 프록시 서버라는 항목에 포워드 프록시의 IP 주소를 설정한다.
• 그러면 브라우저의 리퀘스트 메시지 송신 동작이 조금 달라진다. 포워드 프록시를 설정하면 URL의 내용에 상관 없이 리퀘스트를 전부 포워드 프록시에 보낸다.
• 포워드 프록시를 설정하지 않는 경우에는 URL에서 웹 서버의 이름을 제외하고 파일이나 프로그램의 경로명의 일부를 추출해 이것을 리퀘스트의 URI 부분에 기록한다. 하지만 포워드 프록시를 설정하면 http://.. 라는 URL을 리퀘스트의 URL에 기록한다.
• 포워드 프록시를 사용할 경우에는 URL의 경우에는 URL이 그대로 쓰여있으므로 URL이 전송 대상이 된다.
• 그러므로 서버측에 두는 캐시 서버와 같이 전송 대상의 웹 서버를 사전에 설정해둘 필요는 없고, 모든 웹 서버에서 전송할 수 있다.
• 서버측에 두는 캐시 서버라면 설정해 둔 웹 서버에만 전송할 수 있으므로 상당히 다르다.

4. 포워드 프록시를 개량한 리버스 프록시

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

5. 트랜스페어런트 프록시

• 캐시 서버에서 전송 대상을 판단하는 방법, 즉 리퀘스트 메시지에서 패킷의 헤더를 조사하는 방법이 있다.
• 패킷의 맨 앞에 있는 IP 헤더에는 수신처 IP 주소가 기록되어 있으므로 이것을 조사하면 액세스 대상 웹 서버가 어디에 있는지 알 수 있는데, 이 방법을 트랜스페어런트 프록시라고 부른다.
• 이 방법이라면 보통의 리퀘스트 메시지를 전송할 수 있으므로 포워드 프록시처럼 브라우저에 설정할 필요가 없다. 또한 전송 대상을 캐시 서버에 설정할 필요도 없고, 어느 웹 서버에서나 전송할 수 있다.
• 그러나 주의 할점도 있는데 리버스 프록시와 같이 DNS 서버에 등록하는 방법이라면 이 리퀘스트 메시지가 프록시에 도착하지만, 트랜스페어런트 프록시는 DNS 서버에 등록하는 것도 없다. DNS 서버에 등록하면 트랜스페어런트 프록시 자체가 액세스 대상이 되어 수신처 IP 주소로 전송 대상의 웹 서버를 판단한다는 중요한 구조를 이용할 수 없다.
• 이대로면 리퀘스트 메시지는 브라우저에서 웹 서버로 흘러갈 뿐 트랜스페어런트 프록시에는 도착하지 않는다.
• 이것을 해결하기 위해 브라우저에서 웹 서버로 리퀘스트 메시지가 흘러가는 길에 트랜스페어런트 프록시를 설치한다. 그리고 메시지가 트랜스페어런트 프록시를 통과할 때 이것을 가로챈다.
• 또한 리퀘스트 메시지가 흐르는 길이 많으면 여기에 전부 트랜스페어런트 프록시를 설치해야 하므로 길이 한 개로 수렴하는 형태로 네트워크를 만들고, 수렴되는 곳에 트랜스페어런트 프록시를 설치하는 것이 보통이다. 액세스 회선 부분에 설치해도 된다.
• HTTP의 메시지를 전송한다는 구조에 대한 관심이 적어지고 캐시를 이용한다는 측면에서 비중이 점점 높아지고 있다.

05. 콘텐츠 배포 서비스

1. 콘텐츠 배포 서비스를 이용한 부하 분산

• 캐시 서버는 서버측에 두는 경우와 클라이언트측에 두는 경우가 이용 효과에서 차이가 난다.
• 서버측에 캐시 서버를 두는 방법은 웹 서버의 부하를 경감하는 효과는 있지만, 인터넷을 흐르는 트래픽을 억제하는 효과는 없다.
  이 점에서는 클라이언트측에 캐시 서버를 두는 쪽이 낫다.
• 인터넷 안에는 혼잡한 곳이 있을 수 있어서 그곳을 통과하려면 시간이 걸린다. 클라이언트측에 캐시 서버가 있으면 혼잡에 휘말려드는 일이 없으므로 패킷의 흐름이 안정된다. 큰 화상 같은 대용량 데이터를 포함하는 콘텐츠라면 효과가 크다.
• 클라이언트측에 두는 캐시 서버는 클라이언트측의 네트워크를 운영 관리하는 사람이 소유하므로 웹 서버 운영자가 제어할 수 없다.
• 캐시 서버는 놓는 장소에 따라 장점과 단점이 있지만 양쪽의 좋은 점을 취한 방법도 있다.
• 프로바이더와 계약해 웹 서버 운영자가 제어할 수 있는 캐시 서버를 클라이언트측의 프로바이더에 두는 방법이다.
• 이 방법을 사용하면 사용자로부터 가까운 장소에 캐시 서버를 설치하면서 웹 서버를 제어할 수는 있지만, 인터넷에 공새하는 서버는 인터넷의 어디에서 액세스하는지 알 수 없다.
• 따라서 이 방법을 전면적으로 실형하려면 프로바이더의 POP 전부에 캐시 서버를 설치해야 하지만, 수가 많으므로 비현실적이다.
• 이 문제를 해결하기 위해 먼저 중요한 프로바이더에 중점을 두면 캐시 서버의 수를 줄일 수 있다.
• 이렇게 해도 문제가 존재하는데 프로바이더와 계약해서 캐시 서버를 설치하는 일이 보통일이 아니라는 것이다.
• 그러나 이것도 해결 방법이 존재하는데, 바로 캐시 서버를 설치하고 이것을 웹 서버 운영자에게 대출하는 서비스를 제공하는 사업자가 존재한다는 것이다. 이런 종류의 서비스를 콘텐츠 배포 서비스라고 한다.
• 이 서비스를 제공하는 사업자 CDSP는 중요한 프로바이더와 계약하고 그곳에 다수의 캐시 서버를 설치한다.
• 한편 CDSP는 웹 서버 운영자와도 계약해 웹 서버와 CDSP의 캐시 서버를 연대시킨다. 웹 서버와 캐시 서버를 잘 연대시키면 클라이언트가 웹 서버에 액세스할 때 CDSP의 캐시 서버에 액세스한다.

2. 가장 가까운 캐시 서버의 관점

• 콘텐츠 배포 서비스를 사용하는 경우 인터넷 전체에 설치된 다수의 캐시 서버를 이용한다.
• 이런 상황에서는 다수가 있는 캐시 서버 중에서 가장 가까운 캐시 서버를 찾아내고, 클라이언트가 여기에 액세스하도록 중재하는  구조가 필요하다.
• 몇 가지 방법이 존재한다. 먼저 DNS 서버가 웹 서버의 IP 주소를 회답할 때 가장 가까운 캐시 서버의 IP 주소를 회답하도록 DNS 서버를 세밀하게 설정하는 방법이다.
• 위 방법에서 중요한 점은 클라이언트와 캐시 서버의 거리를 판단하는 방법이다.
• 이 방법은 먼저 캐시 서버의 설치 장소에 있는 라우터에서 경로 정보를 모아둔다. 이 경로표를 사용해 DNS의 조회 메시지의 송신처, 즉 클라이언트 측의 DNS 서버에 이르는 경로 정보를 조사한다. 그러면 대략적인 거리를 알 수 있다. DNS 서버끼리 연대하기 때문에 이 같은 동작이 가능하다.
• 물론 클라이언트측의 DNS 서버는 반드시 클라이언트와 같은 장소에 있는 것이 아니므로 정확한 거리를 측정하지는 못하지만, 웬만큼 정확하게 거리를 측정할 수 있다.

3. 리피터용 서버로 액세스 대상을 분배한다.

• 다른 방법도 존재하는데 HTTP 헤더에는 Location이라는 헤더가 있다.
• 이것은 웹 서버의 데이터를 다른 서버로 옮기는 경우에 사용한다. '그 데이터는 이쪽의 서버에 있으므로 그쪽으로 다시 액세스하세요.'라는 의미다.
• 이렇게 해서 다른 웹서버에 액세스하도록 처리하는 것을 리다이렉트라고 하며, 이것을 사용해 액세스 대상을 가장 가까운 캐시 서버로 돌리는 것이 또 한 가지 방법이다.
• 리다이렉트에 의해 가장 가까운 캐시 서버를 클라이언트에 통지할 때는 리다이렉트용 서버를 웹 서버측의 DNS 서버에 등록한다.
  그러면 클라이언트는 여기에 HTTP의 리퀘스트 메시지를 보내고, 리다이렉트용 서버에는 DNS 서버와 같이 라우터에서 모은 경로 정보가 있으며, 여기에서 가장 가까운 캐시 서버를 찾는다.
• 그리고 캐시 서버를 나타내는 Location 헤더를 붙여 응답을 돌려보내면 클라이언트는 캐시 서버에 다시 액세스한다.
• 리다이렉트의 HTTP 메시지가 증가하므로 오버헤드가 많지만 장점도 있다.
• 리다이렉트는 클라이언트가 보내는 HTTP 메시지의 송신처 IP 주소를 바탕으로 거리를 판단하므로 정밀도가 높다.
• 패킷의 왕복 시간을 통해 캐시 서버까지의 거리를 계산해 최적의 캐시 서버에 액세스하도록 스크립트 프로그램을 내장한 페이지를 반송하는 방법도 있다.

4. 캐시 내용의 갱신 방법에서 성능 차이가 난다.

• 캐시 서버의 효율을 좌우하는 요소 중 캐시의 내용을 갱신하는 방법이 있다.
• 바로 웹 서버에서 원래 데이터를 갱신할 경우 이것을 즉시 캐시 서버에 반영하는 방법이다.
• 그러면 캐시의 데이터는 항상 최신 상태로 유지하고 원래 데이터의 갱신을 확인할 필요가 없게 되고, 최초의 액세스 동작에도 캐시의 데이터를 이용할 수 있다.
• 콘텐츠 배포 서비스에 이용하는 캐시 서버에는 이러한 대책이 내장되어 있다.
• CGI 애플리케이션 등에서 동적으로 페이지를 만드는 경우도 있는데, 이런 경우는 캐시 서버에 데이터를 저장해 두면 안된다.
• 이 경우는 달라지는 부분과 달라지지 않는 부분을 구분하고 변하지 않는 부분만 캐시에 저장해야 한다.

결과적으로 방화벽이나 프록시 서버, 캐시 서버 등 웹 서버의 바로 앞에는 다양한 서버가 있는데, 리퀘스트는 최종적으로 이곳을 통과해 웹 서버에 도착한다.

 

참고자료

 

컴퓨터 네트워킹 하향식 접근 제 7판

성공과 실패를 결정하는 1%의 네트워크 원리

https://product.kyobobook.co.kr/detail/S000000559964

1%의 네트워크 원리 | Tsutomu Tone - 교보문고