728x90
반응형
18. 웹 서버의 설치 장소
18-1. 사내에 웹 서버를 설치하는 경우
- 가장 간단한 방법은 (a)처럼 사내의 LAN에 서버를 설치하고, 인터넷에서 직접 액세스하는 경우이다.
- 이때 패킷은 가장 가까운 POP에 있는 라우터, 엑세스 회선, 서버측 라우터를 경유하여 서버 머신에 도착한다.
- 하지만 IP 주소를 저장하기에 부족해지고, 보안상의 문제로 사용되지 않는다. 사소한 설정 실수로 사내 LAN서버가 뚫리면 무방비 상태가 되어버린다.
- 지금은 (b)처럼 방화벽을 두는 방법이 일반화되어있다. 방화벽은 관문의 역할을 하여 특정 서버에서 동작하는 특정 애플리케이션에 액세스하는 패킷만 통과시키고, 그 외의 패킷을 차단하는 역할을 한다.
18-2. 데이터센터에 웹 서버를 설치하는 경우
- (c)와 같이 프로바이더 등이 운영하는 데이터센터라는 시설에 서버를 가지고 들어가서 설치하거나 프로바이더가 소유하는 서버를 빌렸는 형태로 운영하는 경우도 있다.
- 이는 안정성이 높고 웹 서버가 데이터센터에 설치된 경우에는 인터넷의 중심 부분에서 데이터센터로 패킷이 흘러가고, 여기에서 서버 머신에 도착한다.
19. 방화벽의 원리와 동작
19-1. 패킷 필터링이 주류이다.
서버의 설치 장소와 관계 없이 바로 앞에 방화벽이 있는 것이 보통이다.
- 방화벽의 기본이 되는 개념은 앞에서 설명했듯이 특정 서버와 해당 서버 안의 특정 애플리케이션에 액세스하는 패킷만 통과시키고, 그 외의 패킷을 차단한다.
- 그러나 네트워크에는 다양한 종류의 패킷이 흐르고, 이 중에서 통과시킬 패킷만 선별하는 것은 어려운 방법이다.
- 이 때문에 많은 방법이 고안되었고, 현재는 패킷 필터링형이 가장 많이 보급되었다.
19-2. 패킷 필터링의 조건 설정 개념
패킷의 헤더에는 통신 동작을 제어하는 제어 정보가 들어있으므로 이것을 조사하면 여러 가지 사항을 알 수 있다. 아래 예를 통해 알아보자.
- 공개용 서버를 설치하는 LAN과 사내 LAN이 분리되어 있고, 웹 서버는 공개 서버용 LAN에 접속되어 있다고 가정
- 인터넷에서 웹 서버에 대한 액세스를 허가하지 않으면 웹 서버에서 인터넷의 액세스를 금지하도록 패킷을 차단한다.
- 이러한 상황에서 패킷 필터링의 개념을 설명하자면 패킷 필터링의 조건을 설정할 때는 먼저 패킷의 흐름에 착안한다.
- 수신처 IP주소와 송신처 IP주소에 따라 시점과 종점을 다르게 판단한다.
- [위 그림①]의 예라면 인터넷에서 웹 서버를 향해 패킷이 흐른다. 인터넷에서 보내오는 패킷은 시점을 지정할 수 없지만, 흐름의 종점은 웹 서버가 되므로 이것을 조건으로 설정하고 조건에 해당하는 패킷만 통과시키는 것이다.
- 즉, 시점(송신처 IP주소)은 어디라도 상관없으므로 종점(수신처 IP주소)이 웹 서버의 IP 주소에 일치하는 패킷은 통과시킨다는 조건이다
- 이렇게 해서 인터넷측에서 웹 서버로 흘러가는 패킷은 방화벽을 통과하지만, 이것만으로는 액세스 동작이 제대로 작동하지 않는다.
- 패킷을 받으면 정확하게 도착했는지를 송신측에 알리는 수신 확인 응답의 구조가 작용하므로 웹 서버에서 인터넷 측으로 흐르는 패킷도 있기 때문이다.
- 웹 서버에서 클라이언트에 보내는 데이터가 있고, 이 패킷도 웹 서버에서 인터넷측으로 흘러간 후 그곳에서 시점(송신처 IP주소)이 웹 서버의 주소에 일치하는 패킷도 통과한다.
- 이와 같이 수신처나 송신처의 주소에 따라 패킷이 어디서, 어디로 흘러가는지를 판단하여 통과시키 것인지, 차단할 것인지 결정하는 것이 첫걸음이다.
19-3. 애플리케이션을 한정할 때 포트 번호를 사용한다
- 이것뿐이라면 인터넷과 웹 서버 사이를 흐르는 패킷은 전부 통과해서 위험하다.
- 따라서 포트 번호를 사용하여 수신처 IP 주소가 웹 서버의 주소와 일치하고, 수신처 포트 번호가 일치할 경우 패킷을 통과시킨다.
19-4. 컨트롤 비트로 접속 방향을 판단한다
- 이렇게 하면 애플리케이션도 지정하지만, 웹 서버에서 인터넷측에 액세스하는 동작을 정지시킬 수 없다.
- 웹의 동작은 TCP 프로토콜을 사용하여 양방향으로 패킷이 흐르므로 단순히 웹 서버에서 인터넷으로 흐르는 패킷을 정지시키면 인터넷에서 웹 서버에 액세스하는 동작도 정지된다.
- 패킷이 흐르는 방향이 아니라 액세스 방향을 판단하여 정지 시켜야하는데, 여기에서 도움이 되는 것이 TCP 헤더에 있는 컨트롤 비트이다.
- 실제로는 통과 시키는 것과 차단하는 것을 완전히 선별할 수 없는 경우도 있는데, DNS 서버가 대표적 예다
- DNS 서버에 조회하는 동작은 UDP를 사용하는데, UDP는 TCP와 달리 접속 단계의 동작이 없으므로 TCP처럼 컨트롤 비트에 의해 액세스 방향을 판별할 수 없다.
19-5. 사내 LAN에서 공개 서버용 LAN으로 조건을 설정한다
- 위 그림 구성의 경우 인터넷과 공개 서버용 LAN을 왕래하는 패킷의 조건을 설정할 뿐만 아니라 사내 LAN과 인터넷 또는 사내 LAN과 공개 서버용 LAN을 왕래하는 패킷의 조건도 설정해야 한다.
- 예를 들어 사내 LAN과 공개 서버용 LAN 사이를 자유로이 왕래할 수 있도록 수신처 IP 주소가 공개서버용 LAN과 일치하는 패킷을 전부 통과시켰다고 가정해보자.
- 그런 다음 깜빡 잊고 송신처 IP 주소를 조건으로 설정하지 않으면 인터넷 측에서 흘러온 패킷이 무조건 공개 서버용 LAN에 유입된다.
- 이렇게 되면 공개 서버용 LAN에 설치한 서버 전부가 위험하므로 조건을 잘 설정해야 한다.
→ 패킷 필터링형 방화벽은 수신처 IP 주소, 송신처 IP 주소, 수신처 포트 번호, 송신처 포트 번호, 컨트롤 비트 등으로 패킷을 통과시킬지 판단한다
20. 복수 서버에 리퀘스트를 분배한 서버의 부하 분산
20-1. 처리 능력이 부족하면 복수 서버로 부하 분산된다
- 서버에 액세스가 증가할 때는 서버로 통하는 회선을 빠르게 하는 방법이 효과적이지만, 회선을 빠르게 하는 것만으로 부족한 경우가 있다
- 이때는 복수의 서버를 사용하여 처리를 분담하는 방법으로 서버 한 대당 처리량을 줄이는 것이 효과적이다. 이러한 처리 방법을 분산 처리라고 한다.
- 가장 간단한 방법은 클라이언트가 보내는 리퀘스트를 웹 서버에 분배하는 구조가 필요하다. 구체적 방법 중, DNS 서버에서 분배하는 방법이 가장 간단한다.
- 서버에 액세스할 때 DNS 서버에 조회하여 IP 주소를 조사하는데, DNS 서버에 같은 이름으로 여러 대의 웹 서버를 등록해 놓으면 DNS 서버는 조회가 있을 때마다 차례대로 IP 주소를 되돌려준다.
- 3개의 IP 주소가 있으면 [1, 2, 3] - [2, 3, 1] - [3, 1, 2] 순으로 IP를 되돌려주는 방식이며 이를 라운드 로빈이라고 한다.
- 해당 방법의 단점은 복수의 페이지에 걸쳐 대화하는 경우, 웹 서버가 변하면 대화가 도중에 끊길 수 있다.
20-2. 부하 분산 장치를 이용해 복수의 웹 서버로 분할된다
이러한 좋지 않은 상태를 피하기 위해 부하 분산 장치 또는 로드 밸러서 등으로 부르는 기기가 고안되었다.
- 부하 분산 장치를 사용할 때는 먼저 부하 분산 장치를 웹 서버 대신 DNS 서버에 등록한다.
- 그러면 클라이언트는 부하 분산 장치가 웹 서버라고 생각하여 여기에 리퀘스트 메시지를 보내야 할지 판단하고, 웹 서버에 리퀘스트 메시지를 전송한다.
- 여기서 요점은 말할 것도 없이 어느 웹 서버에 리퀘스트를 전송해야 할지 판단하는 부분이다.
- 판단 근거는 웹 서버와 정기적으로 정보를 교환하여 CPU나 메모리의 사용률 등을 수집하고, 이것을 바탕으로 어느 웹 서버의 부하가 낮은지 판단하거나, 시험 패킷을 웹 서버에 보내 응답 시간으로 부하를 판단하는 방법이 일반적이다.
- 대화가 복수 페이지에 걸쳐있을 때는 웹 서버의 부하에 관계 없이 이전의 리퀘스트와 같은 웹 서버에 전송해야 한다.
- 이렇게 하려면 먼저 대화가 복수 페이지에 걸쳐있는지 판단해야 하는 것이 요점이다.
- HTTP의 기본 동작은 리퀘스트 메시지를 보내기 전에 TCP의 접속 동작을 하고, 응답 메시지를 반송하면 연결을 끊는다. 그리고 다음에 웹 서버에 대한 액세스할 때는 TCP의 접속 동작부터 다시 수행한다. 그러므로 웹 서버측에서 보면 HTTP의 대화는 1회씩 전혀 다른 것으로 보여서 받은 리퀘스트가 이전 리퀘스트에 계속 되는 것인지, 아니면 이전 리퀘스트와는 관계가 없는 것인지를 판단할 수 없다.
- 전후 관계를 판단하기 위해 여러 가지 방법이 고안되었지만 양식에 입력한 데이터를 보낼 때 그 안에 전후의 관련을 나타내는 정보를 부가하거나 HTTP의 사양을 확장하여 전후 관계를 판단하기 위한 정보를 HTTP 헤더 필드에 부가하는 방법이다.
- 부하 분산 장치는 이러한 정보를 조사하여 일련의 동작이라면 이전과 같은 웹 서버에 리퀘스트를 전송하고, 그렇지 않으면 부하가 적은 웹 서버에 전송하도록 동작한다.
21. 캐시 서버를 이용한 서버의 부하 분산
21-1. 캐시 서버의 이용
데이터베이스 서버와 웹 서버 같은 역할에 따라 서버를 나누는 방법으로, 이러한 역할별 분산 처리 방법 중의 하나가 캐시 서버를 사용하는 방법이다.
- 캐시 서버는 프록시라는 구조를 사용하여 데이터를 캐시에 저장하는 서버이다.
- 프록시는 웹 서버와 클라이언트 사이에 들어가서 웹 서버에 대한 액세스 동작을 중개하는 역할을 한다.
- 액세스 동작을 중개할 때 웹 서버에서 받은 데이터를 디스크에 저장해두고 웹 서버를 대신하여 데이터를 클라이언트에 반송하는 기능을 가지고 있다. 이를 캐시라고 부르며 캐시 서버는 이 기능을 이용한다.
21-2. 캐시 서버는 갱신일로 콘텐츠를 관리한다
[캐시 서버의 동작]
- 캐시 서버를 사용할 때는 캐시 서버를 웹 서버 대신 DNS 서버에 등록한다.
- 그러면 사용자는 캐시 서버에 HTTP의 리퀘스트 메시지를 보낼 것이고[위 그림 ①] 캐시 서버가 메시지를 받는다
- 이 때 수신 동작은 웹 서버 수신 동작과 같다. 접속을 기다리는 패킷을 만들고, 여기에 사용자가 접속하면 접속 동작을 실행하여 사용자가 보낸 리퀘스트 메시지를 받는 것이다.
- 사용자가 보면 캐시 서버가 웹 서버에 보일 것이다. 그래서 리퀘스트 메시지를 받으면 캐시 서버는 리퀘스트 메시지의 내용을 조사하고, 데이터가 자신의 캐시에 저장되었는지 조사한다.
- 캐시에 데이터가 저장되어 있지 않은 경우 위 그림 ②와 같이 캐시 서버를 경유한 것을 나타내는 'Via'라는 헤더 필드를 추가하여 웹 서버에 리퀘스트를 전송한다.
- 우선 어느 웹 서버에 리퀘스트를 메시지를 전송해야 할지 판단해야 한다. 웹 서버가 한 대 밖에 없으면 웹 서버의 도메인명이나 IP 주소를 캐시 서버에 설정해두고 무조건 거기에 전송하는 방법을 취한다.
- 하지만 한 대의 캐시 서버로 저장하는 건 무리가 있기에 리퀘스트 메시지의 내용에 따라 전송 대상의 웹 서버를 판단하는 것 같은 방법이 필요하다.
- 대표적인 것은 리퀘스트 메시지의 URI[위 그림 (b)의 ①]에 쓰여있는 디렉토리를 보고 판단하는 방법이다.
- 이 설정을 보고 전송 대상을 판단하여 리퀘스트 메시지를 전송한다. 이때 전송 대상의 웹 서버에 대해 캐시 서버가 클라이언트가 되어 리퀘스트 메시지를 보낸다.
- 즉 소켓을 만들고 웹 서버의 소켓에 접속하여 리퀘스트 메시지를 보내는 식이다. 웹 서버에서 보면 캐시 서버가 클라이언트에 보이는데, 웹 서버에서 캐시 서버에 응답 메시지가 돌아오므로 그것을 받는다
- 이렇게 클라이언트와 웹 서버 사이를 중개하는 것이 프록시 구조이다
21-3. 프록시의 원점은 포워드 프록시이다
지금까지 작성한 것이 프록시라는 구조를 웹 서버 측에 두고 캐시 기능을 이용하는 것이지만, 클라이언트 측에 캐시 서버를 두는 방법도 있다. 여기에서 클라이언트측에 두는 캐시 서버도 설명한다.
- 사실 캐시 서버에서 이용하는 프록시라는 구조는 원래 클라이언트측에 두는 방법에서 시작되었다. 이 유형이 프록시의 원형으로, 포워드 프록시라고 한다.
- 포워드 프록시는 캐시 이용 뿐만 아니라 방화벽을 실현한다는 목적이 존재했다.
- 프록시에서 리퀘스트 메시지를 일단 받아서 인터넷을 향해 전송하면 필요한 것을 통과시킬 수 있다는 개념이다
- 프록시는 리퀘스트의 내용을 추가한 후 전송하므로 리퀘스트의 내용에 따라 액세스가 가능한지 판단할 수 있다
- 포워드 프록시를 사용할 경우에는 보통 브라우저의 설정 화면에 준비되어 있는 프록시 서버라는 항목에 포워드 프록시의 IP 주소를 설정한다. 그러면 브라우저의 리퀘스트 메시지 송신 동작이 조금 달라진다.
- 포워드 프록시를 설정하면 URL의 내용에 상관 없이 리퀘스트를 전부 포워드 프록시로 보낸다. 그리고 리퀘스트 메시지도 URI만 기록하는 것이 아닌 URL 그대로 기록한다.
- 포워드 프록시는 메시지를 전송하는 동작도 서버측에 두는 캐시 서버와 전송 대상의 웹 서버를 판단하는 부분이 약간 다르다.
- 포워드 프록시를 사용할 경우에는 URI 부분에 http:// .... 라는 URL이 그대로 쓰여있으므로 URL이 전송 대상이 된다.
- 그렇기 때문에 서버측에 두는 캐시 서버와 같이 전송 대상의 웹 서버를 사전에 설정해 둘 필요는 없고, 모든 웹 서버에서 전송할 수 있다.
- 서버측에 두는 캐시 서버라면 설정해 둔 웹 서버에만 전송할 수 있으므로 상당히 다르다.
21-4. 포워드 프록시를 개량한 리버스 프록시
- 포워드 프록시를 사용할 경우에는 브라우저에 대한 설정이 꼭 필요한데, 이것이 포워드 프록시의 특징이다.
- 인터넷에 공개하는 웹 서버에 누가 액세스 하는지 알 수 없고, 브라우저에 프록시를 설정할 수 없기 때문에 웹 서버의 바로 앞에 프록시를 두는 방법을 선택하지 않는다.
- 이에 따라 브라우저에 프록시를 설정하지 않아도 사용할 수 있도록 개량되었다. 즉 리퀘스트 메시지의 URI에 쓰여있는 디렉토리명과 전송 대상의 웹 서버를 대응시켜서 URI 부분에 http://.... 라고 쓰여있지 않은 보통의 리퀘스트 메시지를 전송할 수 있도록 했다.
- 이것이 서버측에 설치하는 캐시 서버에 채택하고 있는 방식으로 리버스 프록시라고 한다.
21-5. 트랜스페어런트 프록시
- 패킷의 맨 앞에 있는 IP 헤더에는 수신처 IP 주소가 기록되어 있으므로 이것을 조사하면 액세스 대상 웹 서버가 어디에 있는지 알 수 있는데, 이 방법을 트랜스페어런트 프록시라고 한다.
- 트랜스페어런트 프록시는 포원드 프록시 장점 + 리버스 프록시 장점 형태의 편리한 구조이지만, 리퀘스트 메시지를 건네는 방법에 주의해야 한다.
- 브라우저에 설정하지 않으므로 웹 서버로 보내고, DNS에 등록하지도 않으므로 브라우저에서 웹 서버로 흘러갈 뿐이다.
- 이것을 해결하기 위해 브라우저에서 웹 서버로 리퀘스트 메시지가 흘러가는 길에 트랜스페어런트 프록시를 설치하면 메시지를 중간에 가로챈다.
- 이 방법을 사용하면 리퀘스트 메시지가 흐르는 길에 모두 설치해야 하므로, 네트워크 길을 한 개로 구현하고 중간에 트랜스페어런트 프록시를 설치한다.
- 트랜스페어런트 프록시를 사용하면 사용자가 프록시의 존재를 알아차릴 필요도 없다.
22. 콘텐츠 배포 서비스
22-1. 콘텐츠 배포 서비스를 이용한 부하 분산
캐시 서버는 서버 또는 클라이언트 중 어느 위치에 두느냐에 따라 효과가 다르다.
- 서버 측에 두면 웹 서버의 부하를 경감할 수 있다. 하지만 인터넷을 흐르는 트래픽을 억제할 수 없다.
- 클라이언트 측에 캐시 서버를 두면 패킷이 안정된다. 대용량 데이터를 포함하는 콘텐츠라면 효과가 크다. 하지만 웹 서버 운영자가 제어할 수 없다.
- (c)와 같이 프로바이더와 계약하여 웹 서버 운영자가 제어할 수 있는 캐시 서버를 클라이언트 츠의 프로바이더에 두는 방법이 효과적이다.
- 하지만 프로바이더의 POP 전부에 캐시 서버를 설치하는 것은 수가 너무 많으므로 비현실적이다. 그래서 캐시 서버를 설치하고, 이것을 웹 서버 운영자에게 대출하는 서비스를 제공하는 사업자가 등장했는데 콘텐츠 배포 서비스라고 한다.
22-2. 가장 가까운 캐시 서버의 관점
콘텐츠 배포 서비스를 사용하는 경우 인터넷 전체에 설치된 다수의 캐시 서버를 사용하는데 다수가 있는 캐시 서버 중에서 가장 가까운 캐시 서버를 찾아내고, 클라이언트가 여기에 액세스하도록 중재하는 구조가 필요하다.
- DNS 서버가 웹 서버의 IP 주소를 회답할 때 가장 가까운 캐시 서버의 IP 주소를 회답하도록 DNS 서버를 세밀하게 설정한다
[DNS 서버 동작 복습]
- 최초에 액세스 대상의 웹 서버를 기록한 조회 메시지를 만들고, 이것을 자신의 LAN에 있는 DNS 서버에 보내는 곳부터 시작된다
- 그러면 클라이언트 측의 DNS 서버는 웹 서버의 이름의 계층 구조를 조사하여 이름이 등록되어 있는 DNS 서버, 즉 웹 서버 측에 있는 DNS 서버를 찾아내고 거기에 조회 메시지를 보낸다.
- 웹 서버측의 DNS 서버는 조회 메시지를 받고 이름에 대응하는 IP 주소를 조사하여 회답한다. 웹 서버 측의 DNS 서버에는 관리자가 등록한 서버명과 IP 주소를 대응시킨 대응표가 있을 것이므로 대응표에서 서버명을 찾고, 이것에 대응하는 IP 주소를 회답한다.
- 그러면 회답이 클라이언트 측의 DNS 서버에 도착하고, 여기에서 클라이언트 측에 회답이 돌려진다.
하지만 이렇게 하면 멀리 있는 캐시 서버의 IP 주소를 되돌려 줄 수 있다. 그래서 가장 가까운 캐시 서버에 액세스할 경우에는 라운드 로빈이 아니라 클라이언트와 캐시 서버의 거리를 판단하여 클라이언트에 가장 가까운 캐시 서버의 IP 주소를 회답하도록 한다.
[ 첫 번째 방법 ]
- 이 방법은 먼저 준비 단계로 캐시 서버의 설치 장소에 있는 라우터에서 경로 정볼르 모아둔다.
- 이 경로표를 이용하여 DNS의 조회 메시지의 송신처, 즉 클라이언트 측의 DNS 서버에 이르는 경로 정보를 조사한다.
- 이것을 모든 라우터에 대해 조사하고 비교하면 어느 라우터가 클라이언트 측의 DNS 서버에 가장 가까운지 알 수 있다.
[ 두 번째 방법 ]
- HTTP의 사양에는 다양한 헤더 필드가 정의되어 있고, 이 중에서 'Location'이라는 헤더가 있다.
- 이것은 웹 서버의 데이터를 다른 서버로 옮기는 경우에 사용하는 것으로, '그 데이터는 이쪽의 서버에 있으므로 그쪽으로 다시 액세스하라'라는 의미이다.
- 이렇게 해서 다른 웹 서버에 액세스하도록 처리하는 것을 리다이렉트(redirect)라고 하며, 이것을 사용하여 액세스 대상을 가장 가까운 캐시 서버로 돌린다.
22-3. 캐시 내용의 갱신 방법에서 성능 차이가 발생한다
- 원래 캐시의 개념에는 한 번 액세스한 데이터를 저장해두고, 이것을 두 번째 이후의 액세스 동작에 이용하여 액세스 동작의 효율을 높이는 데 있었지만, 이 방법은 최초의 액세스 동작에 도움이 되지 않는다.
- 또한 두 번째 이후의 액세스에서도 원래 데이터를 가진 웹 서버에 갱신된 내용의 유무를 확인한다는 동작이 있기 때문에 이것이 혼잡하게 뒤얽히면 응답 시간이 악화된다.
- 이 점을 개선하려면 웹 서버에서 원래 데이터를 갱신할 경우 이것을 즉시 캐시 서버에 반영해야 한다.
- 그러면 캐시의 데이터는 항상 최신의 상태를 유지할 수 있으므로 원래 데이터의 갱신을 확인할 필요가 없게 되고, 최초의 액세스 동작에서도 캐시의 데이터를 이용할 수 있다.
728x90
반응형
'CS > 네트워크' 카테고리의 다른 글
| HTTP 프로토콜 동작 과정 시각화 다이어그램 만들기 (0) | 2023.08.02 |
|---|---|
| 웹 서버에 도착한 데이터를 수신하고 처리하는 방법 (0) | 2023.07.28 |
| 액세스 회선이란, 엑세스 회선 과정, 프로바이더와 프로바이더를 경유하여 흐르는 패킷 (0) | 2023.07.26 |
| 허브와 스위치, 라우터의 동작 과정과 기능 (0) | 2023.07.25 |
| 서버에서 연결 끊고 소켓 말소, IP와 이더넷의 패킷 송·수신 동작 (0) | 2023.07.24 |