05. 서버측의 LAN에는 무엇이 있는가? - chwyym/Network GitHub Wiki

1. 웹 서버의 설치 장소

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

어떤 리퀘스트가 웹 서버에 도착하는 과정은 웹서버가 설치된 장소에 따라 다르며, 아래와 같이 분류할 수 있다.

  1. 사내의 LAN에 서버를 설치하고 직접 액세스 하느냐 (라우터에서 직접 웹서버로 접근 가능한 경우)
  2. 방화벽에 의해 필터를 거치고 웹서버로 요청이 가느냐
  • 참고로, 방화벽은 특정 애플리케이션에 액세스 하는 패킷만 통과시키고 그 외의 패킷은 차단하는 역할을 하며, 보통 바이러스 검사, 부정 침입 검사, 검역 네트워크 등의 구조를 함께 사용하는 것이 보통이다.
  1. 통신 회사의 데이터 센터에 웹 서버가 있느냐
  • 데이터 센터는 프로바이더의 중심 부분에 있는 NOC에 직접 접속 되었거나 프로바이더들이 상호 접속하는 IX에 집결되어있다.

2. 방화벽의 원리와 동작

1) 패킷 필터링형

서버의 설치 장소와 관계 없이 지금은 바로 앞에 방화벽이 있는 것이 보통이며, 주로 패킷 필터링형의 방화벽이 많이 쓰인다. 참고로, 방화벽의 유형에는 패킷 필터링형, 애플리케이션 게이트웨이형, 서킷 게이트웨이형이 존재한다.

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

패킷 필터링의 조건을 설정할 때는 먼저 패킷의 흐름에 착안하며, 수신처 IP 주소와 송신처 IP 주소에 따라 시점과 종점을 판단한다.

위의 그림은 인터넷에서 보내오는 패킷은 시점을 지정할 수 없지만, 흐름의 종점은 웹 서버가 되므로 이것을 조건으로 설정하고 조건에 해당하는 패킷만 통과시킨다.

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

외부에서 들어오는 패킷을 포트 필터 없이 받게되면 보안상의 위험이 발생하므로, 애플리케이션을 한정할 때는 TCP 헤더나 UDP 헤더에 기록되어잇는 포트 번호를 조건으로 추가한다.

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

결론은 열려있는 포트로만 외부에서 접속을 받겠다는 것. 이렇게 하는 이유는 서버에서 클라이언트로 나가는 것을 먼저 차단해버리면 나가는 패킷 자체가 차단되어 버리므로 상대로부터 응답자체를 받지 못한다. (이렇게되면 서버가 외부 인터넷과 연결을 할 수가 없다.) 따라서, 밖에서 안으로 들어오는 패킷을 필터링하면 서버에 들어온 요청을 응답해줄 수 있게된다. 참고로 위의 그림에서는 TCP 컨트롤비트가 SYN=1, ACK=0인 경우, 방향이 반대이므로 차단이지만, 그렇지 않은경우는 상대에게 응답을 주는 방향이라고 판단하므로 정상적인 접근이 가능해진다.

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

웹 서버의 패킷이 인터넷과 공개 서버용 LAN을 왕래하는 경우, 사내 LAN과 인터넷 또는 사내 LAN과 공개 서버용 LAN을 왕래하는 패킷의 조건도 설정해줘야한다. 만약에 수신처 IP 주소가 공개 서버용 LAN과 일치하는 패킷을 전부 통과시키고, 송신처 IP 주소를 조건으로 설정하지 않음녀 인터넷 측에서 흘러온 패킷이 무조건 공개 서버용 LAN에 유입되고, 공개 서버용 LAN에 설치한 서버 전부가 위험한 상태에 빠질 수 있다.

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

패킷 필터링형 방화벽은 패킷을 통과시킬지, 차단시킬지를 판단할 뿐만 아니라 주소 변환의 기능도 가지고 있으므로 설정도 필요하다. 구체적으로는 패킷의 시점과 종점을 조건으로 지정한 후 주소 변환이 필요한 경우에는 주소 변환을 하고, 변환이 필요하지 않은 경우에는 변환하지 않도록 설정한다.

7) 방화벽을 통과한다.

'패킷 필터링'이라는 구조는 방화벽용의 특별한 구조라고 생각할 것이 아니라 라우터의 패킷 중계 기능 중에서 부가 기능이라고 생각하는 것이 좋다. 패킷 필터링형 방화벽은 수신처 IP 주소, 송신처 IP 주소, 수신처 포트 번호, 송신처 포트 번호, 컨트롤 비트 등으로 패킷을 통과시킬지 판단한다.

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

패킷의 내용에 위험요소가 포함되어있는 경우, 방화벽의 구조는 이것을 판단하지도 대처하지도 못한다. 이 문제의 원인은 웹 서버 SW 버그에 있으므로 버그를 고쳐서 다운되지 않도록 하는 법과 패킷을 내용을 조사해서 위험한 데이터가 포험되어있는 경우 패킷을 차단하도록 장치나 소프트웨어를 방화벽과는 별도로 준비하는 방법이 있다.

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

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

복수의 서버를 사용하여 처리를 분담하는 방법을 분산 처리라고 한다. 부하분산을 구현하기 위한 가장 간단한 방법은 단순히 여러 대의 웹 서버를 설치하고 한 대가 담당하는 사용자 수를 줄이는 방법이 있다. 이 방법을 취할 경우 클라이언트가 보내는 리퀘스트를 웹 서버에 분배하는 구조가 필요한데, DNS 서버에서 분배하는 방법이 가장 간단하다. 그리고 DNS 서버에서는 리퀘스트를 분배하기 위해서 라운드로빈 을 구조를 차용하여 서버 부하를 분산시킨다. 단, 이것은 서버가 죽더라도 감지가 안되기 때문에, 죽은 서버에 리퀘스트를 전달한다는 단점이 있다.

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

위의 문제를 방지하기 위해 부하 분산 장치 또는 로드 밸런서 등으로 부르는 기기가 고안되었고, DNS 서버에 부하 분산 장치를 등록하면 부하 분산 장치가 어느 웹 서버에 리퀘스트를 전송할지 판단해준다. 그리고 부하 분산 장치는 리퀘스트 전송 대상을 판별하기 위해 웹 서버와 정기적으로 CPU나 메모리의 사용률 등을 수집하거나 시험 패킷을 던진 후 응답 시간으로 부하를 판단한다.

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

1) 캐시 서버의 이용

  • 캐시 서버

    • 데이터베이스 서버와 웹 서버와 같은 역할 에 따라 서버를 나누는 방법 중 하나이다.
    • 프록시 라는 구조를 사용해서 데이터를 캐시에 저장하는 서버이다.
      • 웹 서버와 클라이언트 사이에서 웹 서버에 대한 액세스 동작을 중개한다.
      • 캐시
        • 중개할 때, 웹 서버에서 받은 데이터를 디스크에 저장하고 웹 서버를 대신하여 데이터를 클라이언트에 반송한다.
    • 웹 서버보다 빨리 데이터를 송신한다.
    • 캐시 서버에서 어느정도 리퀘스트를 처리하므로 그 만큼 웹서버의 부하가 준다.

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

  • 캐시 서버를 부하 분산 장치와 마찬가지로 웹 서버 대신 DNS 서버에 등록한다.

  • 캐시에 데이터가 없는 경우

    1. 클라이언트가 캐시 서버에 요청을 보냄
2. 캐시 서버가 웹서버로 받은 리퀘스트 메시지를 전송
3. 웹 서버가 캐시 서버로 콘텐츠 데이터를 포함하여 응답
4. 캐시 서버가 콘텐츠를 캐시에 축적
5. 클라이언트에 응답
    • 캐시 서버가 리퀘스트 메시지에 If-Modified-Since 가 포함되지 않는 경우 웹 서버는 콘텐츠를 전송한다.
    • ex) If-Modified-Since: Wed, 21 Sep 2008 10:25:52 GMT

  • 캐시에 데이터가 있는 경우

    1. 클라이언트가 캐시 서버에 요청을 보냄
2. 캐시 서버가 웹서버로 받은 리퀘스트 메시지를 전송
3. 웹 서버가 '콘텐츠에 변경 없음' 이라는 정보를 회신고 거기에 대한 응답
4. 캐시 서버가 캐시에 축적 되어있던 콘텐츠를 이용
5. 클라이언트에 응답
    • 캐시 서버가 리퀘스트 메시지에 If-Modified-Since 가 포함된경우 웹 서버는 콘텐츠를 전송하지 않는다.

  • 캐시 서버는 리퀘스트 메시지의 URI의 디렉토리를 보고 요청을 전달할 웹 서버를 판단할 수 있다.

  • If-Modified-Since와 데이터의 최종 갱신 일지를 비교하여 변경 됨 여부를 판단한다.

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

  • 포워드 프록시
    • 클라이언트측에 프록시라는 구조를 두는 것이다.
    • 프록시의 원형이다.
    • 처음 등장했을 당시 캐시를 이용하는 것이 목적이었다.
    • 방화벽을 실현한다는 중요한 목적이 있었다.
      • 패킷의 IP나 포트로 필터링하는 것보다 더 자세한 조건을 설정하는 것이 가능하다.
    • 포워드 프록시의 설정 여부에 따른 리퀘스트 메시지의 차이
      • 설정한 경우
        • URL의 http://....하는 문자열에서 액세스 대상의 웹 서버의 이름을 제외하고 파일이나 프로그램의 경로명 일부를 추출하여 리퀘스트의 URI 부분에 기록한다.
      • 설정하지 않은 경우
        • URL의 http://... 부분을 그대로 포함하여 리퀘스트 메시지를 작성한다.
    • 브라우저에 대한 설정이 반드시 필요하다.

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

  • 기존의 포워드 프록시는 브라우저에 대한 설정이 반드시 필요하다.
    • 만약 설정이 잘못된다면 장애를 유발하는 원인이 되기도 한다.
  • 그런데, 웹 서버같은 경우
    • 포워드 프록시를 사용하면 누가 액세스하는지 알 수 없고
    • 브라우저에 대한 프록시 설정을 할 수 없기 때문에
    • 웹 서버 바로 앞에 프록시를 두는 방법을 선택하지 않는다.
  • 웹 서버는 보통의 리퀘스트 메시지를 전송할 수 있도록 포워드 프록시를 개량한 리버스 프록시를 사용한다.
    • 이것이 캐시 서버에 채택하고 있는 방식이다.

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

  • 리퀘스트 메시지에서 패킷의 헤더(Host)를 조사하여 전송 대상을 판단하는 방법이다.
    • HTTP 1.1 부터 액세스 대상의 웹 서버를 나타내는 Host라는 헤더 필드가 추가되었다.
  • 포워드 프록시와 리버스 프록시의 조은 점만 모은 형태의 편리한 구조다.
  • 보통의 리퀘스트 메시지를 전송할 수 있다.
  • 브라우저 설정이 필요하지 않다.
  • 어느 웹 서버에나 전송할 수 있다.
  • 브라우저에서 웹 서버로 리퀘스트 메시지가 흘러가는 길에 트랜스페어런트 프록시를 설치한다.
    • 리버스 프록시처럼 DNS 서버에 등록하면, 프록시 자체가 액세스 대상이 되어버린다.
    • 따라서 수신처 IP 주소로 전송 대상의 웹 서버를 판단한다는 중요한 구조를 이용할 수 없게 된다.
  • 이 프록시를 사용하면, 사용자가 프록시의 존재를 알아차릴 필요가 거의 없다.

05. 콘텐츠 배포 서비스

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

  • 웹 서버의 직전에 캐시 서버를 두는 경우
    • 장점
      • 웹 서버의 부하를 억제할 수 있다.
    • 단점
      • 인터넷의 트래픽을 억제하지는 못한다.
  • 클라이언트측에 캐시 서버를 두는 경우
    • 장점
      • 인터넷의 트래픽을 억제하는 효과는 높다.
    • 단점
      • 웹 서버 운영자는 캐시 서버를 제어할 수 없다.
  • 인터넷의 주위에 캐시 서버를 두는 경우
    • 프로바이더와 계약하여 웹 서버 운영자가 제어할 수 있는 캐시 서버를 클라이언트측의 프로바이더에 두는 방법이다.
    • 장점
      • 위 두 가지 경우의 좋은 점을 취한 방법이다.
      • 인터넷의 트래픽을 제어할 수 있으며
      • 서버 운영자가 캐시 서버를 제어할 수 있다.
    • 단점
      • 서버는 인터넷의 어디에서 액세스하는지 알 수 없다.
      • 이 방법을 전면적으로 실행하려면 프로바이더의 POP 전부에 캐시 서버를 설치해야 하므로 비현실적이다.
        • 중요한 프로바이더에 중점을 두어서 캐시 서버의 수를 줄인다.
          • 그래도 비용면이나 노력변에서 보통일이 아니다.
        • 콘텐츠 배포 서비스(CDSP: Content Delivery Service Provider)
          • 위 문제를 해결하고자 캐시 서버를 설치하고 이것을 웹 서버 운영자에게 대출하는 서비스를 제공하는 사업자가 등장했다.
          • CDSP는 중요한 프로바이더와 계약하고 그곳에 다수의 캐시 서버를 설치한다.

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

  • 다수가 있는 캐시 서버 중에서 가장 가까운 캐시 서버를 찾아내어 클라이언트가 여기에 액세스하도록 중재하는 구조가 필요하다.
    • DNS 서버가 웹 서버의 IP 주소를 회답할 때, 가장 가까운 캐시 서버의 IP 주소를 회답하도록 DNS 서버를 설정한다.
      • 클라이언트와 캐시 서버의 거리를 판단하여 클라이언트에 가장 가까운 캐시 서버의 IP 주소를 회답한다.
        • 라우터의 경로표를 이용하여 DNS 서버에 이르는 경로 정보를 조사한다.
        • 위 방법으로 웬만큼 정확하게 거리를 측정할 수 있다.

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

  • 리다이렉트(redirect)

    • '그 데이터는 이쪽의 서버에 있으므로 그쪽으로 다시 액세스 하세요'
    • 위와 같이 다른 웹 서버에 액세스하도록 처리하는 것을 말한다.

  • 가장 가까운 캐시 서버에 액세스 하는 방법은 한 가지가 더 있다.

    • 리다이렉트를 이용해 액세스 대상을 가장 가까운 캐시 서버로 돌린다.
      • 리다이렉트용 서버를 웹 서버의 DNS 서버에 등록한다.
      • 클라이언트는 HTTP 리퀘스트 메시지를 리다이렉트용 서버에 보내게 된다.
      • 리다이렉트용 서버에는 라우터에서 모은 경로표가 존재한다.
      • 이 경로표로 가장 가까운 캐시 서버를 찾는다.
      • 캐시 서버를 나타내는 Location 헤더를 붙여 응답을 돌려보낸다.
      • 클라이언트는 돌려받은 응답 메시지의 Location으로 다시 액세스한다.
    • 장점
      • HTTP 메시지의 송신처 IP 주소를 바탕으로 거리를 판단하므로 정밀도가 높다.
    • 단점
      • HTTP 메시지의 대화가 증가하므로 오버헤드가 많다.

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

  • 기존에는 웹 서버에 갱신된 내용의 유무를 확인하고 캐시 서버의 콘텐츠를 갱신했다.
  • 위가 혼잡하게 뒤얽히면 응답 시간이 악화된다.
  • 이것을 개선려면 웹 서버에서 원래 데이터를 갱신할 경우 이것을 즉시 캐시 서버에 반영해야 한다.
    • 콘텐츠 배소 서비스의 캐시 서버에 이러한 대책이 내장되어있다.