웹 서버의 설치장소
예전엔 사내 LAN에 바로설치했었음. 하지만 문제점이 있었다.
- 서버뿐이 아니라 클라이언트모두에게 글로벌IP를 할당함.
- 공격에 취약함.
따라서 중간에 방화벽을 세우고, 인가한 패킷만 들어오게 하는 방식으로 운영.
요즘은 데이터 센터에 서버를 세우는 방식도 있음.
NOC에 직접접속 되어있거나 IX와 매우 가깝기에 속도가 빠르다.
어떤 경우던 라우터를 거쳐 패킷을 중계하는 건 똑같다!
방화벽의 원리와 동작
서버를 어디 설치하건 간에 방화벽은 있다. 그래서 패킷이 방화벽을 통과하는 곳 부터 탐험해보자.
방화벽의 기본 개념은 인가된 패킷만 통과. 그런데 쉽지 않음.
패킷의 종류가 다양하기 때문. 통과시킬 패킷을 고르기 어렵다. 많은 방법이 연구됨.
개중 초기방식인 패킷 필터링에 대해 알아보자.
패킷 필터링
패킷 헤더에 적혀있는 제어정보를 두고 필터링함.
- 제어정보 : TCP,MAC,IP 헤더 등. 헤더에 통신동작을 제어하는 정보들이 적혀있음. 자세한 건 전 편들 참조.
예를들어 사내 랜(192.xxx~)이 인터넷 접속은 차단하고, 인터넷이 사내랜 접속은 허용하게 하려면
- 송신IP가
192.xxx~면 차단한다.
1-1. 단, SYN값이 1이고 ACK가 0일때
=> 인터넷에서 사내랜을 접속해도, 사내랜이 응답하려면 패킷송신을 해야함. 그건 통과시키고, 사내랜에서 접속하려는 행동을 막는것.(접속을 시도하는 쪽에서 TCP헤더의 SYN값을 1로보냄)
애플리케이션을 한정하려면 포트번호 별로 통과/차단.
통/차 조건으로 사용하는 값은 헤더값 종류가 많음.
단, 패킷 필터링은 UDP방식을 구체적으로 설정할 수 없음.
=> UDP는 3-handshake가 없음.
그리고 헤더말고 서버 응답의 허점을 짚은 데이터에 실려온 악의적 행동은 차단 불가.
복수 서버에 리퀘스트를 분배한 서버의 부하 분산
서버에 액세스가 많아지면 고속회선을 탑재한다. 이는 한계가있음.
서버에서 동적 페이지 생성을 자주하는 경우 액세스가 많으면 부하가 걸림(DB조회도 생각해볼법함)
따라서 웹 서버를 많이 늘리는 게 주요 핵심.
이때 클라이언트의 요청을 분산시켜줘야 한다. 여러방법들이 있음.
도메인에 여러 IP 할당
DNS 서버에 여러 웹서버의 IP를 할당 해줌.
예를들어 주소 velog에 a,b,c라는 IP가 있다고해보자. 사용자가 velog를 주소장에 입력하면
a => b => c => a
이렇게 원형 큐같은 방식으로 IP를 내어준다. 이를 RR(Round Robin)알고리즘이라 함.
어디서 많이 들어봤는데? => 운영체제의 CPU스케쥴링 기법중 하나. 시분할 시스템 이용하는거!
로드밸런서(부하 분산 장치)
로드밸런서를 DNS에 웹서버처럼 등록. 클라이언트의 요청이 들어오면 로드밸런서가 캐치해서 적절히 서버에 분배.
예를들어 여러 페이지에 걸쳐 값이 들어오는 경우(첫페이지 아이디, 두번째 신용카드 정보) 전과 같은 서버에서 처리해야함. http는 이전 리퀘스트와 관계있는 것인지 구분하지 못함.
요즘은 쿠키같은걸 사용해서 괜찮음.
캐시서버를 이용한 서버의 부하 분산
웹 서버자체를 늘리는 방법 말고도, 기능을 분산시키는 방법이 있음.
DB서버를 따로 두는것도 그 예다. 캐시서버도 마찬가지.
캐시 서버는 프록시를 기반으로 만듬.
- 프록시(proxy) : 웹서버와 클라이언트 사이의 액세스 중개역할. 웹 서버의 데이터를 디스크에 저장. 클라이언트에게 요청이 들어오면 디스크의 데이터를 넘겨줌.
데이터가 바뀌었을땐 당연히 다시 웹서버에 요청해야함.
이 캐시서버를 웹서버처럼 DNS서버에 등록해서 사용한다.
캐시서버의 동작
여러대의 웹서버를 하나의 캐시서버에서 분배하는 방법은 요청의 디렉토리로 나누는 방법이 있음.
캐시 서버의 동작은 클라이언트가 요청한 데이터의 유무로 나눌 수 있음.
요청한 데이터가 캐시서버에 없을 때
- 캐시 서버가 데이터 없음 확인후 Via헤더 추가해서 웹서버에게 요청
- 웹서버가 캐시서버에 요청한 데이터 응답
- 캐시서버에서 클라이언트에게 Via헤더 달아서 요청한 데이터 응답.
3-1. 응답 메시지를 캐시서버에 날짜와 같이 저장.
캐시서버의 설정에 따라 Via헤더를 붙이지 않을 때도 있다.
요청한 데이터가 캐시서버에 있을 때
- 캐시서버가 웹서버에 If-Modified-Since헤더 달아 요청해 캐싱 된 데이터가 수정되었는지 확인함.
- 웹서버가 데이터 변경유무를 알려줌. 변경이 없다고 가정함.
- 캐시 서버가 클라이언트에게 Via헤더 달아서 응답!
데이터 일시만 체크하면 되기에 속도가 빠르다.
프록시의 원점
캐시 서버에서 사용하는 프록시는 사실 클라이언트측에서 먼저 사용했었음.
저속 인터넷 시절 인터넷 자체에 액세스 하는것보다 빠름. 또한 보안측면에서 유리.
설정해놓은 리퀘스트가 아니면 금지 가능. 이는 패킷 필터링보다 구체적.
이를 포워드 프록시라 하고 브라우저의 설정을 요함.
=> 설정 번거롭고, 잘못 설정하면 브라우저 먹통. 그래서 리버스 프록시가 나옴
캐시 서버는 리버스프록시를 이용해 만들었다.
포워드와 리버스의 차이를 사실 잘 모르겠어서 MDN에서 가져와봤다.
포워드 프록시는 클라이언트가 중점이고 리버스 프록시는 서버가 중점이구나!
또한 포워드 프록시는 인터넷 앞에있고, 리버스 프록시는 인터넷 뒤에있다.
따라서 리버스 프록시는 실제 주소를 알아야함.
=> DNS서버에 리버스 프록시가 등록되어 있어야 한다.
예를들어 http://www.naver.com에 접속한다고 가정.
포워드 프록시는 클라이언트의 요청을 받아 http://www.naver.com에 요청을 보낸다.
리버스 프록시는 클라이언트가 http://www.naver.com의 IP주소를 DNS서버에서 알아내 요청.
이후 들어온 요청을 실제 주소에 보낸다.
transparent proxy
일명 투명 프록시. 사용자가 알 필요 없음.
네트워크나 라우터단에서 리퀘스트를 가로채 투명 프록시에서 웹서버에 요청 전송.
브라우저에 설정할 필요가 없다!
콘텐츠 배포 서비스
캐시 서버는 응답 속도를 높여주지만 트래픽은 그대로임.
해결하기위해 클라이언트측에 캐시서버를 둘 수 있지만, 웹서버측에서 관리 불가능
이를 해결한 것이 CDN(Contetn Delivery Netwrok)다. 그 유명한 CloudFlare도 CDN사업이 주류쥐!
중요 프로바이더와 CDN 사업자가 계약해서 캐시서버를 마구마구 설치한다!
이를 웹서버측에 임대해준다. 클라이언트와 가장 가까운 캐시서버에 매칭시켜준다. done!
근데, 어떻게 가장 가까운 캐시서버에 매칭시켜줄까?
DNS서버가 가까운 캐시서버를 알려준다
캐시서버들의 라우터는 저마다 라우팅 테이블을 가짐. 여기엔 거리(Metric)도 나타나있음.
결국, 클라이언트의 요청에 적혀있는 송신처 IP와 거리가 가장 가까운 캐시서버에 연결시켜줄 수 있다!
리피터용 서버로 액세스대상 분배
HTTP헤더의 Location을 이용한다. 웹 서버의 데이터를 다른서버로 옮길때 사용하는 필드.
클라이언트와 가까운 DNS가 웹서버의 DNS를 조회하면, 리다이렉트용 웹 서버의 주소를 알려줌.
이곳엔 라우팅 테이블의 경로정보가 있음. 이를 통해 Location헤더에 가장 가까운 캐시서버의 주소를 넣어서 응답한다.
그만큼 http메시지 왕복이 증가. 오버헤드(overhead)발생. But, DNS서버 방식보단 정밀함.
몇 개의 캐시서버에 테스트패킷 보내서 시간측정 후 소요시간 짧은 서버에 연결하는 것도 있음.
캐시 내용 갱신
캐시는 사실 한 번 본 페이지를 저장해둬서 효율을 높이는 의의. 하지만 최초의 액세스에선 불가능.
또한 데이터가 바뀌었을때 체크하는 것도 응답시간 악화 요인.
=> 웹 서버의 데이터를 갱신할때 캐시서버에도 적용하면 됨.
동적 페이지는 바뀌지 않는 부분(정적부분)만 캐시해두면 된다.
