'성공과 실패를 결정하는 1%의 네트워크 원리' 스터디를 진행하며 정리한 내용이다.

---

01 웹 서버의 설치 장소

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

   인터넷을 빠져나와 서버에 도착할 때까지의 여정은 서버의 설치 장소에 따라 다름.

   

   1. 라우터에서 직접 연결하는 경우

      • 이전에는 이런 형태로 서버를 설치하는 경우가 많았지만, 현재는 주류에서 밀려났음.

        • IP 주소의 부족
        • 보안상의 이유

   2. 방화벽으로 분리하는 경우

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

        • 보안 구멍이 있어도 위험성이 적어짐
        • 위험성이 완전히 없어지지는 않았음. 액세스를 허가한 애플리케이션에 보안 구멍이 있으면 공격받을 위험성이 남아있음.

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

   1. 통신 회사의 데이터센터에 설치하는 경우
   2. 프로바이더 등이 운영하는 데이터센터라는 시설에 서버를 가지고 들어가서 설치하거나 프로바이더가 소유하는 서버를 빌려쓰는 형태로 운영하는 경우도 있음
   3. 회사 안보다 안전성이 높으며 기기의 가동 상태 감시, 방화병 설치 운영, 부정 침입 감시라는 부가 서비스를 제공하는 경우가 있어 안전성도 높음.
   4. 패킷은 라우터에서 중계되고 최종적으로 서버에 도착한다는 점은 달라지지 않음.

02 방화벽의 원리와 동작

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

   • 방화벽의 기본이 되는 개념은 특정 서버와 해당 서버 안의 특정 애플리케이션에 액세스하는 패킷만 통과시키고, 그 외의 패킷을 차단한다.

     • 통과시킬 패킷과 차단할 패킷을 선별하는 것은 간단한 일이 아니다.
   • 성능, 가격, 사용 편의성 등의 이유로 지금은 패킷 필터링형이 가장 많이 보급되었다.

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

   • 패킷의 헤더에는 통신 동작을 제어하는 제어 정보가 들어있으므로 이것을 조사하면 여러 가지 사항을 알 수 있다.

   

   • 현재 예시로 인터넷에서 웹 서버에 대한 액세스를 허가하지 않으면 웹 서버에서 인터넷의 액세스를 금지하도록 패킷을 차단한다. (부정 소프트웨어가 있어 감염 방지)
   • 인터넷에서 보내오는 패킷은 시점을 지정할 수 없지만, 종점은 웹 서버가 된다. 시점(송신처 IP 주소)은 어디라도 상관없으므로 종점(수신처 IP 주소)이 웹 서버의 IP 주소에 일치하는 패킷은 통과시킨다는 조건을 설정하면 된다.
   • 패킷을 받으면 수신 확인 응답의 구조가 작용하므로 웹 서버에서 인터넷측으로 흐르는 패킷도 있다.

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

   • 인터넷과 웹 서버 사이를 흐르는 패킷은 전부 통과되므로 웹 이외의 애플리케이션의 패킷을 전부 차단하는 쪽이 좋다.
   • 애플리케이션을 한정할 때는 TCP 헤더나 UDP 헤더에 있는 포트 번호를 조건으로 추가한다. 이 경우에는 웹 서버 포트 번호인 80번.

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

   • TCP 헤더에 있는 컨트롤 비트를 조사해서 최초의 패킷과 두 번째 이후의 패킷을 판별할 수 있다.

   • 최초의 패킷이 웹 서버측에서 인터넷측으로 흘러갈 경우 이것을 차단하도록 설정할 수 있다.

     • 표의 2행과 같이 SYN 1, ACK 0일 때 차단한다면 웹 서버가 기점이 되어 인터넷에 액세스하려고 해도 접속 동작이 틀림 없이 실패한다.
   • 인터넷에서 웹 서버에 액세스하는 패킷은 최초의 패킷은 1행의 조건을 만족하므로 패킷 필터링을 통과한다. 두 번째 패킷은 송신처가 웹 서버를 나타내지만 TCP 컨트롤 비트 조건이 2행과 합치되지 않아 3행을 통과한다.

   

   

   • 수신처 IP 주소, 송신처 IP 주소, 수신처 포트 번호, 송신처 포트 번호, TCP 컨트롤 비트를 조건으로 사용하고, 통신의 시점, 종점, 애플리케이션의 종류, 액세스 방향을 판별하는 방법을 설명했는데, 조건으로 사용하는 항목은 위와 같이 많다. 이것을 조합하면 대상이 되는 패킷을 찾아낼 수 있다. 이렇게 해서 허가하는 액세스 동작에서 흐르는 패킷과 그 외의 패킷을 완전히 선별할 수 있을 때까지 조건을 추가하고 액세스를 허가하는 패킷만 통과시키고, 그 외는 차단하도록 조건을 설정한다.
   • DNS 서버에 조회 동작은 UDP를 사용하다보니 (접속 단계 동작이 없다) 통과시키는 것과 차단하는 것을 완전히 선별할 수 없다. 이와 같이 UDP를 사용하는 애플리케이션은 패킷을 전부 통과시키거나, 불편을 감수하고 애플리케이션을 전면적으로 차단하는 방법을 선택해야 한다.

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

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

     • 이때 조건이 서로 악영향을 끼치지 않도록 주의해야 한다.
     • 예를 들면 사내 LAN과 공개 서버용 LAN 사이를 자유로이 왕래할 수 있도록 수신처 IP 주소가 공개 서버용 LAN과 일치하는 패킷을 전부 통과시켰다고 가정하자. 이때 깜빡하고 송신처 IP 주소를 사내 LAN으로 설정해두지 않으면 인터넷에서 흐르는 패킷이 전부 공개 서버용 LAN으로 유입되므로 위험한 상태에 빠질 수 있다.

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

   • 패킷 필터링형 방화벽은 패킷을 통과시킬지, 차단시킬지를 판단할 뿐만 아니라 주소 변환의 기능도 가지고 있으므로 설정도 필요하다.

     • 즉, 인터넷과 사내 LAN을 왕래하는 패킷은 주소 변환을 해야 하므로 설정이 필요하다.
     • 주소 변환을 이용하면 당연히 인터넷측에서 사내 LAN에는 액세스할 수 없게 된다.
     • 따라서 사내 LAN에 대한 액세스를 금지하도록 패킷 필터링의 조건을 설정할 필요가 없다.

7. 방화벽을 통과한다.

   • 방화벽에는 여러 가지 조건이 설정되어 있어 여기에 패킷이 도착하면 조건에 해당하는지 판정하고, 통과시킬지와 차단할지를 결정함.

   • 판정한 후 차단하는 대상이 되면 패킷을 버리고, 버린 기록을 남김.

     • 패킷 필터링 기능을 가진 라우터를 방화벽으로 사용하는 경우 패킷을 버린 기록을 남기는 일이 드물다. 라우터는 메모리 용량이 작기 때문.
   • 통과시킨다는 판정을 내린 후 패킷을 중계하는데, 이 중계 동작은 라우터의 동작과 같다.
   • 판정 조건이 복잡해지거나 패킷을 버린 기록을 남길 때는 전용 하드웨어나 소프트웨어를 사용하고 그게 아닐 경우 패킷 필터링 기능을 가진 라우터를 방화벽으로 사용할 수 있다.

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

   • 방화벽은 시점과 종점을 보고 통과시킬지, 차단할지 판단하기에 이는 위험한 패킷을 전부 판단할 수 있는 것은 아니다.

   • 특수한 데이터를 포함한 패킷을 받으면 웹 서버가 다운된다는 상황에서 시점과 종점이 일치한 패킷을 통과시켰다가 웹 서버가 다운될 수 있다.

     이 상황에서 두 가지 대처법이 있다.

     • 버그를 고쳐서 다운되지 않도록 하는 것.

       • 보안 정보 구멍을 수집하여 항상 새로운 버전으로 갱신하는 것이 중요
     • 패킷의 내용을 조사하여 위험한 데이터가 포함되어 있는 경우에 패킷을 차단하도록 장치나 소프트웨어를 방화벽과는 별도로 준비하는 방법.

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

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

   • 복수의 서버를 사용하여 처리를 분담하는 방법으로 서버 한 대당 처리량을 줄이는 것이 효과적.

     • 이를 분산 처리라고 하는데, 처리를 분담하는 방식은 여러 가지이다.

   • 가장 간단한 방법은 단순히 여러 대의 웹 서버를 설치하고 한 대가 담당하는 사용자 수를 줄이는 방법.

     • DNS 서버에서 분배하는 방법이 가장 간단함.

       

       • DNS 서버에 같은 이름으로 여러 대의 웹 서버를 등록함.
       • DNS 서버는 조회가 있을 때마다 차례대로 IP 주소를 되돌려주는 라운드 로빈 방식을 사용해서 복수의 서버에 균등하게 액세스를 분산시킬 수 있음.
       • 웹 서버가 고장난 경우 DNS 서버는 웹 서버가 동작하지 않는지 확인하지 못해 정지해도 상관없이 IP 주소를 회답해 버린다. (최근에는 많은 브라우저가 회답한 IP 주소의 맨 앞에서 액세스에 실패한다면 다음 IP 주소를 시도한다)
       • 또한 라운드 로빈에서 차례대로 웹 서버를 분배할 때 복수의 페이지를 사용하는 애플리케이션의 경우 웹 서버가 변하면 대화가 도중에 끊길 수 있다.

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

   • 위와 같은 좋지 않은 상태를 피하기 위해 부하 분산 장치 또는 로드 밸러서 등으로 부르는 기기가 고안되었다.

   

   • DNS 서버에 웹 서버 대신 부하 분산 장치를 등록한다.

     • 클라이언트는 부하 분산 장치가 웹 서버라고 생각하여 여기에 리퀘스트 메시지를 보내야 할지 판단하고, 웹 서버에 리퀘스트 메시지를 전송한다. (부하 분산 장치는 캐시 서버와 비슷한 장치 또는 캐시 서버를 발전시킨 것이라고 생각해도 좋다)

   • 대화가 복수의 페이지에 걸쳐있는지에 따라 어느 웹 서버에 전송할지 판단 기준이 달라진다.

     • 복수 페이지에 걸쳐있지 않다면 웹 서버의 부하 상태가 판단 근거가 될 것이다.

     • 복수 페이지에 걸쳐있다면 웹 서버의 부하에 관계 없이 이전의 리퀘스트와 같은 웹 서버에 전송해야 한다.

       • HTTP 프로토콜은 의도적으로 웹 서버에 액세스할 때마다 TCP 접속 동작이 수행되도록 만들어짐.
       • 송신처 IP 주소도 프록시를 사용하다 보니 클라이언트가 누구인지 몰라 판별할 수 없음.
       • 양식에 입력한 데이터를 보낼 때 그 안에 전후의 관련을 나타내는 정보를 부가하거나 HTTP 사양을 확장하여 전후 관계를 판단하기 위한 정보를 HTTP 헤더 필드에 부가하는 방법을 사용한다.
       • 부하 분산 장치는 이 정보를 조사해서 일련의 동작이라면 이전과 같은 웹 서버에 리퀘스트를 전송하고, 그렇지 않으면 부하가 적은 웹 서버에 전송하도록 동작한다.

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

1. 캐시 서버의 이용

   • 캐시 서버는 프록시라는 구조를 사용하여 데이터를 캐시에 저장하는 서버.

     • 프록시는 웹 서버와 클라이언트 사이에 들어가서 웹 서버에 대한 액세스 동작을 중개함.
     • 웹 서버에서 받은 데이터를 디스크에 저장해 두고 웹 서버를 대신하여 데이터를 클라이언트에 반송하는 기능을 캐시라고 부름. 캐시 서버는 이 기능을 이용.
     • 웹 서버보다 빨리 데이터를 송신할 수 있음.
     • 언제든지 캐시의 데이터를 이용할 수 있는 것은 아니지만 액세스 동작의 일정 부분은 웹 서버를 번거롭게 하지 않고 캐시 서버에서 처리할 수 있음. 또한 얼마라도 캐시 서버에서 액세스 동작을 고속화할 수 있으면 전체 성능이 향상된다고 생각.

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

   

   • 캐시 서버를 웹 서버 대신 DNS 서버에 등록한다.
   • 클라이언트에서 캐시 서버로 리퀘스트 메시지를 보낸다.
   • 캐시 서버는 리퀘스트 메시지의 내용을 조사하고, 데이터가 자신의 캐시에 저장되었는지 조사한다.
   • 데이터가 캐시에 저장되어 있지 않은 경우
   • 캐시 서버를 경유한 것을 나타내는 'Via'라는 헤더 필드를 추가하여 웹 서버에 리퀘스트를 전송한다.
   • 웹 서버가 한 대밖에 없으면 웹 서버의 도메인명이나 IP 주소를 캐시 서버에 설정해 두고 무조건 거기에 전송하는 방법을 취한다. 그게 아니면 몇 가지 방법 중 리퀘스트 메시지의 URI에 쓰여 있는 디렉토리로 판단하는 방법이 있다.
     URI가 /dir1/ → www1.lab.cyber.co.kr
     URI가 /dir2/ → www2.lab.cyber.co.kr
   • 전송 대상의 웹 서버에 캐시 서버가 클라이언트가 되어 리퀘스트 메시지를 보낸다.
   • 웹 서버에서 캐시 서버에 응답 메시지가 돌아오므로 캐시 서버가 그것을 받는다.
   • 응답 메시지에 캐시 서버를 경유한 것을 나타내는 'Via' 헤더 필드를 부가하며, 클라이언트에 대해 웹 서버가 되어 응답 메시지를 전송한다.
   • 응답 메시지를 캐시에 저장한 일시를 기록한다
   • 데이터가 캐시에 저장되어 있는 경우
   • 웹 서버측에서 데이터가 변경되었는지 조사하기 위한 'If-Modified-Since'라는 헤더 필드를 추가하여 'Via'와 함께 웹 서버에 전송한다.

   • 웹 서버는 'If-Modified-Since' 헤더 필드의 값과 페이지 데이터의 최종 갱신 일시를 비교하여 변경이 없으면 '304 Not Modified'와 함께 응답 메시지를 반송한다.

     • 페이지 데이터를 반송하는 것보다 부담이 적어지고, 응답 메시지도 짧다.
   • 데이터가 변경된 경우에는 캐시에 데이터가 저장되어 있지 않은 경우와 같다.

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

   • 지금까지는 웹 서버측에 두고 캐시 기능을 사용하는 프록시를 설명한 것.
   • 클라이언트측에 캐시 서버를 두는 방법도 있다.

   • 프록시는 원래 클라이언트측에 두는 방법에서 시작되었고 이 유형이 프록시의 원형으로, 포워드 프록시라고 한다.

     • 처음 등장했을 때 캐시를 이용하는 것이 목적이었지만 방화벽을 실현한다는 중요한 목적이 하나 더 있었다.

     • 프록시에서 리퀘스트 메시지를 일단 받아서 인터넷을 향해 전송하면 필요한 것을 통과시킬 수 있다는 개념.

       • 리퀘스트의 내용을 조사한 후 전송하였다. 패킷 필터링형 방화벽이라면 IP 주소나 포트 번호만 사용하므로 이렇게까지 자세히 조건을 설정하는 것은 불가능.

     • 보통 브라우저의 설정 화면에 준비되어 있는 프록시 서버라는 항목에 포워드 프록시의 IP 주소를 설정한다.

       • 설정하면 URL의 내용에 상관없이 리퀘스트 전부 포워드 프록시에 보내고 URL 그대로 리퀘스트 URL에 기록한다.
     • 서버측에 두는 캐시 서버와 같이 전송 대상의 웹 서버를 사전에 설정해 둘 필요는 없고, 모든 웹 서버에 전송할 수 있다.

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

   • 포워드 프록시는 브라우저에 대한 설정이 꼭 필요한게 특징이다.

     • 브라우저의 설정이 번거롭고 잘못 설정할 경우 브라우저가 제대로 작동하지 않는 장애의 원인이 되기도 함.
     • 인터넷에 공개하는 웹 서버는 누가 액세스하는지 알 수 없고, 브라우저에 프록시를 설정할 수 없기 때문에 웹 서버의 바로 앞에 프록시를 두는 방법을 선택하지 않음
     • 브라우저에 프록시를 설정하지 않아도 사용할 수 있도록 개량되었음. URI에 쓰여있는 디렉토리명과 전송 대상의 웹 서버를 대응시키도록 함.
     • 서버측에 설치하는 캐시 서버에 채택하고 있는 방식으로, 리버스 프록시라고 부름.

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

   • 캐시 서버에서 전송 대상을 판단하는 방법, 즉 리퀘스트 메시지에서 패킷의 헤더를 조사하는 방법이 있음.

   • 패킷 IP 헤더를 조사하여 액세스 대상 웹 서버를 알 수 있는데 이를 사용하는 것이 트랜스페어런트 프록시라고 부른다.

     • HTTP 1.1 버전에서는 웹 서버를 나타내는 'Host'라는 헤더 필드가 추가됨.

   • 이를 이용하면 보통의 리퀘스트 메시지를 전송할 수 있으므로 포워드 프록시처럼 브라우저에 설정할 필요가 없고 전송 대상을 캐시 서버에 설정할 필요도 없으며, 어느 웹 서버에서나 전송할 수 있다.

     • 포워드 프록시와 리버스 프록시의 좋은 점만 모은 형태다.

   • DNS 서버에 등록하는 것이 아니기에 (DNS 서버에 등록하면 프록시 자체가 액세스 대상이 되어 수신처 IP 주소로 전송 대상의 웹 서버를 판단한다는 중요한 구조를 이용할 수 없다) 리퀘스트 메시지를 건네주는 방법을 주의해야 한다.

     • 브라우저에서 웹 서버로 리퀘스트 메시지가 흘러가는 길에 프록시를 설치하고 메시지가 통과할 때 가로챈다.
   • 트랜스페어런트 프록시를 사용하면 사용자가 프록시의 존재를 알아차릴 필요가 거의 없다. 따라서 HTTP 메시지를 전송한다는 구조에 대한 관심이 적어지고 캐시를 이용한다는 측면에서 비중이 높아지고 있다.

05 콘텐츠 배포 서비스

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

   

   • 서버측에 캐시 서버를 두는 방법은 웹 서버의 부하를 경감하는 효과는 있지만, 인터넷을 흐르는 트래픽을 억제하는 효과는 없다.
   • 클라이언트측에 캐시 서버를 두는 방법은 패킷의 흐름이 안정되어 트래픽이 줄어들지만 웹 서버 운영자가 제어할 수 없다. 용량을 높이고 싶어도 그럴 수 없으며 심지어 클라이언트측에 캐시 서버가 있다고 단정할 수 없다.

   • 양쪽의 좋은 점을 취한 웹 서버 운영자가 제어할 수 있는 캐시 서버를 클라이언트측의 프로바이더에 두는 방법이 있다.

     • 이를 위해 캐시 서버를 설치하고, 이것을 웹 서버 운영자에게 대출하는 서비스를 제공하는 사업자가 등장했는데, 이 종류의 서비스를 콘텐츠 배포 서비스(CDS)라고 한다.
     • CDSP가 설치한 캐시 서버를 다수의 웹 서버 운영자가 공동으로 이용할 수 있어 한 회사당 비용을 절감할 수 있다.

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

   • 콘텐츠 배포 서비스를 사용하는 경우 인터넷 전체에 설치된 다수의 캐시 서버를 이용한다.
   • 이 상황에서는 다수가 있는 캐시 서버 중에서 가장 가까운 캐시 서버를 찾아내고, 클라이언트가 여기에 액세스하도록 중재하는 구조가 필요하다.

   • 이를 위해 DNS 서버가 웹 서버의 IP 주소를 회답할 때 가장 가까운 캐시 서버의 IP 주소를 회답하도록 DNS 서버를 세밀하게 설정하는 방법이 있다.

     • DNS 서버에 복수의 IP를 등록시켜 라운드 로빈이 아닌 클라이언트와 캐시 서버의 거리를 판단하여 클라이언트에 가장 가까운 캐시 서버 IP 주소를 회답하도록 설정한다.
     • 서버측의 DNS 서버에 캐시 서버 라우터의 경로표를 입수해서 정보를 모아둔다.

     • 경로표를 사용해 클라이언트측의 DNS 서버에 이르는 경로 정보를 조사한다.

       • 라우터에서 클라이언트측의 DNS 서버까지의 경로를 알 수 있고 인터넷 내부의 경로 정보에는 어떤 프로바이더를 지나는지 경로가 기록되어 있으므로 대략적인 거리를 알 수 있음.
     • 이것을 모든 라우터에 대해 조사하고 비교하면 어느 라우터가 클라이언트측의 DNS 서버에 가장 가까운지 알 수 있다.
     • 실제로 클라이언트측의 DNS 서버와 클라이언트가 같은 장소에 있는 것은 아니지만 웬만큼 정확하게 거리를 측정할 수 있다.

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

   • 'Location' 헤더를 통해 리다이렉트를 사용해 액세스 대상을 가장 가까운 캐시 서버로 돌리는 방법도 있다.

     • 리다이렉트용 서버를 웹 서버측의 DNS 서버에 등록한다.
     • 클라이언트는 리다이렉트용 서버에 HTTP 리퀘스트 메시지를 보낸다.
     • 리다이렉트용 서버에는 DNS 서버와 같이 라우터에서 모든 경로 정보가 있어 가장 가까운 캐시 서버를 찾아낸다.
     • Location 헤더를 붙여 응답을 돌려보내면 클라이언트는 캐시 서버에 다시 액세스한다.

   • HTTP 메시지의 대화가 증가해 오버헤드가 많지만 장점도 있다.

     • 클라이언트가 보내는 HTTP 메시지의 송신처 IP 주소를 바탕으로 거리를 판단하므로 정밀도가 높다. (클라이언트측의 DNS 서버와 캐시 서버의 거리를 계산하는 것이 아니므로)

   • 패킷의 왕복 시간을 통해 캐시 서버까지의 거리를 계산하여 최적의 캐시 서버에 액세스하도록 스크립트 프로그램을 내장한 페이지를 반송하는 방법도 있다.

     • 이 페이지에는 몇 개의 캐시 서버에 시험적으로 패킷을 보내고 왕복 시간을 계측한 후 가장 왕복 시간이 짧은 캐시 서버에 리퀘스트를 다시 보낸다는 내용의 리퀘스트 프로그램을 내장해 둔다.

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

   • 웹 서버에서 원래 데이터를 갱신할 경우 이것을 즉시 캐시 서버에 반영하면 성능이 올라간다.

     • 캐시의 데이터는 항상 최신 상태를 유지할 수 있으므로 원래 데이터의 갱신을 확인할 필요가 없게 되고, 최초의 액세스 동작에도 캐시 데이터를 이용할 수 있다.
     • 콘텐츠 배포 서비스에 이용하는 캐시 서버에는 이러한 대책이 내장되어 있음.
   • 동적으로 페이지를 만드는 경우 캐시 서버에 데이터를 저장해 두면 안된다. 이 경우 페이지 전체를 캐시에 저장하지 않고 매번 페이지의 내용이 달라지는 부분과 달라지지 않는 부분을 구분하고 변하지 않는 부분만 캐시에 저장해야 한다.