1. 웹 서버의 설치 장소

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

• 과거에 많이 사용하던 형태

1. IP 주소의 부족 : 서버뿐 아니라 클라이언트에도 public IP를 할당해야 하므로
2. 보안상의 이유 : 서버가 노출된 상태이므로
   ⇒ 현재는 사용하지 않음

• 현재는 방화벽을 두는 방법을 씀
  • 방화벽 : 네트워크를 외부에서의 공격으로부터 지키기 위해 고안된 구조의 하나
  • 특정 서버에서 동작하는 특정 애플리케이션에 액세스하는 패킷만 통과시키고, 그 외의 패킷을 차단하는 역할

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

• 웹 서버를 회사 안에 설치하지 않고 프로바이더 등이 운영하는 데이터 센터라는 시설에 설치하거나 프로바이더가 소유하는 서버를 빌려쓰는 형태
• 서버에 대한 액세스가 증가했을 때 효과적
• 회사 안에 설치하는 것보다 안정성이 높음

2. 방화벽의 원리와 동작

1. 방화벽

• 방화벽 : 특정 서버와 해당 서버 안의 특정 애플리케이션에 액세스하는 패킷만 통과시키고, 그 외의 패킷은 차단
• 패킷을 선별하는 다양한 방법이 있지만 현재는 패킷 필터링형이 가장 많이 보급
  • 성능, 가격, 사용 편의성 등의 이유

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

1. IP 주소
   • 수신처 IP 주소와 송신처 IP 주소에 따라 시점과 종점을 판단해 통과여부 결정
   • 인터넷에서 웹 서버를 향해 패킷이 흐르는 상황이라면 : 시점(송신처 IP주소)은 어디라도 상관없으므로 종점(수신처 IP주소)이 웹 서버의 IP 주소에 일치하는 패킷은 통과시킨다는 조건을 설정
2. 포트번호
   • IP주소만으로 통과여부를 판단한다면 인터넷과 웹 서버 사이를 흐르는 패킷은 전부 통과
   • 웹 이외의 애플리케이션을 한정할 때는 TCP헤더나 UDP헤더에 기록되어있는 포트 번호를 조건으로 추가
3. 컨트롤 비트
   • 최초의 패킷에 들어 있는 SYN(1), ACK(0)을 이용해 최초의 패킷 판별
   • 최초의 패킷이 웹서버 → 인터넷 방향일 경우 차단하도록 설정하는 방법으로 웹 서버에서 인터넷에 액세스를 막을 수 있음

⇒ 이런 방식으로 허가하는 액세스 동작에서 흐르는 패킷과 그 외의 패킷을 완전히 선별할 수 있을 때가지 조건을 추가

3. 방화벽의 동작

• 방화벽은 차단 대상이 되는 패킷은 버리고 버린 기록을 남김 ⇒ 부정 침입의 흔적을 나타내는 것이 있으므로 이것을 분석하여 향후 부정 침입 대책에 사용
• 방화벽은 통과 대상이 되는 패킷은 라우터의 동작과 마찬가지로 중계함

부가 기능이 필요없다면, 방화벽은 패킷 필터링 기능을 가진 라우터이다

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

• 방화벽은 시점과 종점만 조사하므로 패킷 중 특수한 데이터(서버가 다운될 수 있는)가 들어있어도 신경쓰지 않음

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

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

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

• 서버에 액세스가 증가할 때 해결하는 방법
  1. 서버 머신을 고성능 기종으로 교체 ⇒ 고성능 기종을 사용해도 한 대로는 힘들 수 있음
  2. 복수의 서버를 사용하여 처리를 분담 ⇒ 서버 한 대 당 처리량을 줄일 수 있음 분산 처리
• 처리를 분담하는 방식

1. 단순히 여러 대의 웹 서버를 설치하고 한 대가 담당하는 사용자 수를 줄이는 방법
   • 클라이언트가 보내는 리퀘스트를 웹 서버에 분배하는 구조 필요 ⇒ 여러 가지 방법이 있지만 DNS 서버에서 분배하는 방법이 가장 간단 (서버에 액세스할 때 DNS 서버에 조회하여 IP 주소를 조사하는데, DNS 서버에 같은 이름으로 여러 대의 웹 서버를 등록해 놓으면 DNS 서버는 조회가 있을 때마다 차례대로 IP 주소를 돌려줌)
   • ✅ 3대의 웹 서버를 설치하면 한 대가 받는 클라이언트 수는 3분의 1로 줄고 그만큼 서버 한 대 당 부하가 가벼워짐
   • ❌ DNS 서버는 웹 서버가 동작하지 않는지 확인하지 못하므로 여러 웹 서버 중 고장난 서버가 있어도 상관하지 않고 IP 주소를 회답함
2. 부하 분산 장치를 이용해 부하를 분산하는 방법
   • 부하 분산 장치를 사용할 때는 먼저 부하 분산 장치를 웹 서버 대신 DNS 서버에 등록
   • 그러면 클라이언트는 부하 분산 장치가 웹 서버라고 생각하여 여기에 리퀘스트 메시지를 보내야 할지 판단하고, 웹 서버에 리퀘스트 메시지를 전송
   • 어느 웹 서버에 리퀘스트 메시지를 전송해야 할지 판단하는 방법
     1. 대화가 복수의 페이지에 걸쳐있지 않은 단순 액세스 : 웹 서버의 부하 상태에 따라 판단 ⇒ 웹 서버와 정기적으로 정보를 교환하여 CPU나 메모리 사용률 등을 수집하고 이것을 바탕으로 어느 웹 서버의 부하가 낮은지 판단하거나, 시험 패킷을 웹 서버에 보내 응답 시간으로 부하를 판단하는 방법이 일반적
   • 단, 부하는 단시간에 변화하므로 꼼꼼히 상황을 조사해야 함, BUT 너무 자세히 조사하면 조사 자체로 웹 서버의 부하가 증가해버림
     1. 대화가 복수의 페이지에 걸쳐있을 때 : 웹 서버의 부하와 관계 없이 이전의 리퀘스트와 같은 웹 서버에 전송

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

1. 캐시 서버

• 같은 기능을 하는 여러 대의 웹 서버를 설치하는 것이 아니라 역할별 분산처리 방법 중 하나인 캐시 서버를 사용하는 방법
• 프록시를 사용하여 데이터를 캐시에 저장하는 서버
  • 프록시 : 웹 서버와 클라이언트 사이에 들어가서 웹 서버에 대한 액세스 동작을 중개하는 역할
  • 캐시 : 웹 서버에서 받은 데이터를 디스크에 저장해 두고 웹 서버를 대신해 데이터를 클라이언트에 반송하는 기능
• URL 점검, 액세스 권한 점검, 페이지 안에 데이터를 내장하는 등의 처리를 내부에서 실행하기 때문에 다소 시간이 걸리는 웹 서버와 달리 캐시 서버는 웹 서버에서 받아 보존해 둔 데이터를 읽어서 클라이언트에 송신만 하므로 웹 서버보다 빨리 데이터 송신 가능

2. 캐시 서버의 동작

• 부하 분산 장치와 마찬가지로 캐시 서버를 웹 서버 대신 DNS 서버에 등록
• 클라이언트는 캐시 서버에 HTTP 리퀘스트 메시지를 보냄
• 캐시 서버는 리퀘스트 메시지의 내용을 조사하고, 데이터가 자신의 캐시에 저장되었는지 조사

1. 저장되어 있는 경우
   • 캐시 서버는 리퀘스트 메시지에 데이터가 변경되었는지를 조사하기 위한 If-Modified-Since 헤더를 추가하여 웹 서버에 전송
   • 웹 서버는 이 헤더 값과 페이지 데이터의 최종 갱신 일시를 비교하여 변경이 없으면 변경이 없는 것을 나타내는 응답 메시지 반송 304 Not Modified
   • 캐시 서버는 이 응답메시지를 통해 캐싱된 데이터가 최신 데이터와 같다는 것을 알았으므로 클라이언트에게 캐시에서 추출한 데이터를 보냄
   • 이 경우 클라이언트에게 보내는 응답 메시지는 캐시에 데이터가 없었던 경우에 보내는 메시지와 같음 (헤더에 Via 필드 추가)
   • 만약 데이터가 변경된 경우에는 2. 와 같이 동작
2. 저장되어 있지 않은 경우
   • 캐시 서버는 리퀘스트 메시지에 캐시 서버를 경유한 것을 나타내기 위해 Via 라는 헤더 필드를 추가하여 웹 서버에 리퀘스트 전송
   • 웹 서버가 한 대라면 무조건 거기에 전송하지만 여러 대의 서버가 있는 경우 리퀘스트 메시지의 내용에 따라 전송 대상의 웹 서버를 판단하는 방법 필요
   • 일반적으로는 리퀘스트 메시지의 URI에 쓰여있는 디렉토리를 보고 판단
   • 전송 대상의 웹 서버에게는 캐시 서버가 클라이언트가 됨
   • 캐시 서버는 웹 서버로부터 받은 응답 메시지에 캐시 서버를 경유한 것을 나타내는 Via 헤더 필드 추가 후 클라이언트에 응답 메시지 전송
   • 전송 후 응답 메시지를 캐시에 저장하고 저장한 일시 기록

3. 포워드 프록시

• 포워드 프록시 : 웹 서버 측에 프록시를 두고 캐시 기능을 이용하는 것이 아니라, 클라이언트 측에 캐시 서버를 두는 방법
• 포워드 프록시의 목적 : 캐싱, 방화벽
  • 송신처와 수신처의 주소만 확인하는 방화벽과 달리 프록시는 리퀘스트 메시지의 내용을 조사하므로 위험한 사이트나 관계 없는 사이트에 액세스를 제한할 수 있음
• 브라우저의 설정 화면에서 프록시 서버라는 항목에 포워드 프록시의 IP 주소를 설정하는 방법으로 사용가능
• 동작 과정
  • 포워드 프록시가 없으면 브라우저는 URL에서 액세스 대상의 웹 서버를 계산해서 여기에 리퀘스트 메시지를 보내지만, 포워드 프록시를 설정하면 URL의 내용에 상관없이 리퀘스트를 전부 포워드 프록시에 보냄
  • 포워드 프록시를 설정한 경우, URL에서 URI부분만 리퀘스트에 기록하지 않고 전체 URL을 그대로 리퀘스트 메시지에 기록
  • 서버 측에 두는 캐시 서버와 달리 리퀘스트 메시지에 URL이 그대로 쓰여있으므로 전송대상의 웹 서버를 사전에 설정해 둘 필요 없이 모든 웹 서버에서 전송할 수 있음

4. 리버스 프록시

• 포워드 프록시는 브라우저에 대한 설정이 꼭 필요하기 때문에 번거롭고 장애의 원인이 되기 쉬움
• 리버스 프록시 : 서버측에 캐시 서버를 설치하는 방법
  • 리퀘스트 메시지의 URI에 쓰여있는 디렉토리명과 전송 대상의 웹 서버를 대응시켜 URI 부분에 전체 주소가 아닌 보통의 리퀘스트 메시지를 전송함
• 클라리언트가 인터넷에 데이터를 요청하면 리버스 프록시가 이 요청을 받아 내부 서버에서 데이터를 받은 후 클라이언트에 전달
• 클라이언트는 내부 서버에 대한 정보를 알 필요 없이 리버스 프록시에만 요청하면 됨
• 내부 서버 (WAS) 에 직접적으로 접근한다면 DB 에 접근이 가능하기 때문에 중간에 리버스 프록시를 두고 클라이언트와 내부 서버 사이의 통신을 담당
• 또한 내부 서버에 대한 설정으로 로드 밸런싱(Load Balancing) 이나 서버 확장 등에 유리

포워드 프록시 VS 리버스 프록시

1. End Point
   • Forward Proxy 는 클라이언트가 요청하는 End Point가 실제 서버 도메인이고 프록시는 둘 사이의 통신을 담당해준다.
   • Reverse Proxy 는 클라이언트가 요청하는 End Point가 프록시 서버의 도메인이고 실제 서버의 정보는 알 수 없다.
2. 감춰지는 대상
   • Forward Proxy는 클라이언트가 감춰진다.
   • 요청 받는 서버는 포워드 프록시 서버를 통해서 요청을 받기 때문에 클라이언트의 정보를 알 수 없다.
   • Reverse Proxy 는 반대로 서버가 감춰진다.
   • 클라이언트는 리버스 프록시 서버에게 요청하기 때문에 실제 서버의 정보를 알 수가 없다.

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

• 트랜스페어런트 프록시 : 패킷의 맨 앞에 있는 IP 헤더에 있는 수신처 IP 주소를 통해 액세스 대상 웹 서버가 어디에 있는지 캐시 서버에서 전송 대상을 판단하는 방법
• 보통의 리퀘스트 메시지를 전송할 수 있으므로 포워드 프록시처럼 브라우저 별도 설정이 필요 없음
• 브라우저에서 웹 서버로 리퀘스트 메시지가 흘러가는 길에 트랜스페어런트 프록시를 설치해서 메시지가 트랜스페어런트 프록시를 통과할 때 가로챔

5. 콘텐츠 배포 서비스

1. 콘텐츠 배포 서비스

• 콘텐츠 배포 서비스 : 캐시 서버를 설치하고 웹 서버 운영자에게 대출해주는 서비스
• CDSP : 콘텐츠 배포 서비스를 제공하는 사업자
  • 프로바이더와 계약 후 다수의 캐시 서버를 설치
  • 웹 서버 운영자와도 계약하여 웹 서버와 CDSP의 캐시 서버를 연대시킴
  • 캐시 서버는 다수의 웹 서버의 데이터를 캐싱할 수 있으므로 다수의 웹 서버 운영자가 공동으로 이용할 수도 있음

2. 가장 가까운 캐시 서버를 찾아내는 방법

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

1. DNS 서버가 웹 서버의 IP 주소를 회답할 때 가장 가까운 캐시 서버의 IP 주소를 회답하도록 DNS 서버를 세밀하게 설정
2. HTTP의 리다이렉트를 이용해 액세스 대상의 가장 가까운 캐시 서버로 돌리는 것
   • 리다이렉트용 서버를 웹 서버측의 DNS 서버에 등록
   • DNS 서버와 마찬가지로 라우터에서 모은 경로 정보를 가지고 가장 가까운 캐시 서버를 찾아 Location 헤더에 붙여 응답을 돌려보냄
   • ❌ 리다이렉트의 HTTP 메시지가 증가해 오버헤드가 많음
   • ✅ 클라이언트가 보내는 HTTP 메시지의 송신처 IP 주소를 바탕으로 거리를 판단하므로 정밀도가 높음

3. 캐싱의 성능

• 콘텐츠 배포 서비스에서 캐시의 내용을 갱신하는 방법 : 웹 서버에서 기존 데이터를 갱신할 경우 즉시 캐시 서버에 반영
• 매번 페이지의 내용이 달라지는 부분과 달라지지 않는 부분을 구분해 변하지 않는 부분만 캐시에 저장