[허언증/네트워크] chapter05-② (성공과 실패를 결정하는 1%의 네트워크 원리)

안녕하세요 허언증입니다.

 

 

 

책에 있는 내용을 이해하고 서술 하듯 글을 적어 내려 갑니다. 저도 공부하는 차원에서 정리하는 글 이고 네트워크 과정에서 생략되는 부분도 발생할 수 있기 때문에 부족한 점도 있다는거 인지 하시고 편안하게 읽어주세요!! 역사처럼 물 흐르는식으로 스타일로 글을 작성합니다

 

 

 

---

 

 

 

chapter05

 

1. 웹 서버의 설치 장소

2. 방화벽의 원리와 동작

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

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

5. 콘텐츠 배포 서비스

 

 

 

 

 

 

---

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

 

 

웹서버의 방화벽과 설치 장소를 알게 되었다면 효율적인 성능에 포커스에 대해 이야기 하도록 하겠습니다. 데이탸 크기가 점점 갈수록 커지고 있는데 한 대의 서버로 모든걸 감당하기엔 무리가 있습니다. 이 문제점을 해결하기 위해 1대 보단 3대로 운영해서 분산 처리를 하도록 만들었습니다. 

 

 

 

 

 

DNS서버를 예시로 설명을 드리자면 

서버 액세스 -> DNS서버 조회 IP주소를 조사 -> DNS서버에 같은 이름으로 여러대의 웹서버 등록 입니다!

 

위 그림 처럼 등록을 할 경우 "라운드로빈" 형식으로 분배를 할 수 있습니다.

 

첫 번째 요청이 오면 192.0.2.10에 처리

192.0.2.10 > 192.0.2.20 > 192.0.2.30 

 

두 번째 요청이 오면 192.0.2.20에 처리

192.0.2.20 > 192.0.2.30 > 192.0.2.10 

 

세 번째 요청이 오면 192.0.2.30에 처리

192.0.2.30 > 192.0.2.10 > 192.0.2.20 

 

이렇게 분산하는 방법도 있습니다. 하지만 단점은 한 곳이 고장이 나버리면 통신을 못 하게 됩니다. DNS자체에서 고장 유/무를 체크를 못 하기 때문입니다. 또한 복수페이지 대화형을 인식을 못 합니다.

 

복수페이지 대화형이란 무엇인가?

회원가입을 한다고 가정을 한다면 서명,주소를 입력을 하고 다음을 누르면 신용카드 정보를 입력하라는 화면으로 바뀌게 되는데 이때 처음에 작성했던 서명,주소는 이미 데이터가 넘어간 상태입니다. 그럼 그 다음 순번인 서버에 신용카드 데이터가 넘어가가게 됩니다. 요기서 문제가 발생을 하게 되는것이죠. 

 

 

 

 

이를 해결하기 위해 "부하 분산 장치"를 이용합니다! 부하 분산 장치가 알아서  대화의 복수의 페이지가 있으면 제어 해주고 아닐시 CPU나 메모리의 상황을 보고 최단 시간 처리 되는 곳을 찾아서 보내게 됩니다. 부하 분산 장치를 웹 서버 대신 DNS 서버  등록

 

 

 

 

 

 

---

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

 

 

순순히 서버만으로 분산하는 방법을 설명을 드렸고, 이젠 다른 물리적 장치를 이용해서 서버의 부하를 분산 시켜 봅시다.  분산 시키는 방법에는 캐시서버가 있다.  ( 프록시 = 캐시서버 ) 

 

캐시서버란?

프록시라는 구조로 데이터를 캐시에 저장하는 서버이다. 캐시는 앞장에서 설명을 했었다. 간단히 이미 열어본 페이지를 다음에 요청이 올 때 바로 서버에 직접 접근하지 않고 미리 저장해준 데이터를 곧 바로 전송을 해주는 것을 말한다.

 

그리고 캐시서버에 처음 들어온 데이터라면 [Via : ~~~] 정보가 캐시서버에서 웹서버로 갈 때 추가 된다. 

데이터가 있다면 [If-Modified-Since] 헤더필드를 추가 한다. 그리고 웹서버로 보내게 된다.

 

 

 

데이터가 왜 있는데 웹서버로 보내는 걸까??? 

이유는 웹서버에서 해당 캐시 데이터가 업데이트 되었는지  확인 해야 하기 때문이다.

 

 

 

캐시서버의 동작은?

부하 분산 장치와 마찬가지로 캐시서버를 웹서버 대신 DNS 서버에 등록한다. 이 경우 웹서버가 한 대를 운영할 때 사용하지만 웹서버가 여러대 일 땐 어떻게 전송될까? GET방식의 URL 인

 

/dir1/sample1.html

/dir2/sample1.html

 

처럼 주소로 구분을 하게 된다. 

 

지금 까지의 설명은 웹서버에 프록시를 두는 예이다. 

 

 

 

이번에는 클라이언트에 프록시 서버를 뒀을 때를 생각해보자. 이를 "포워드 프록시"라고 한다.

포워드 프록시는 URL을 통해 전송하기 때문에 웹서버를 사전에 설정 해 둘 필요가 없다. URL을 이용하면 모든 웹서버에 전송이 가능하기 때문이다.

 

"리버스 프록시"는 http:// 형식이 아닌 리퀘스트 메시지에 보통의 메시지도 사용 할 수 있게 만들고 DNS서버에 등록이 가능하다. 

 

 트랜스페어런트 프록시는 리퀘스트 메시지에 패킷의 헤더를 바로 조사를 하는 방법이다. 패킷의 헤더에 IP를 통해 바로 전송 가능

 

(각각 의 프록시 좀 더 공부 할 것)

 

 

 

 

 

 

 

---

5. 콘텐츠 배포 서비스

 

 

콘텐츠 배포 서비스에 대해 말하기 전 잠시 정리를 하면 1) 웹서버에 캐시서버를 두는 겨우 2)클라이언트측에 캐시서버를 두는 경우 2가지가 있었다. 콘텐츠 배포 서비스는 마지막 세 번째의 환경을 통해 이뤄지게 되는데 바로 프로바이더 측에 캐시서버를 두는 것이다. 

 

콘텐츠 배포 서비스란?

프로바이더 측에 어느 부분 돈을 주고 장소를 빌리고 그 장소에 캐시서버를 만든다. 그리고 웹서버 업체의 조건에 계약을  하고 중간에서 서로 연결을 해주는 서비스이다. 이들을 CDSP라고 부른다

 

이렇게 분업을 통해 CDSP업체가 전문성을 갖고 서비스를 운영한다. CDSP는 캐시서버를 한 곳 만 두는게 아니라 다수를 두고 있다. 클라이언트는 CDSP의 캐시서버 중 자신이 송신하고자 하는 웹서버에 최단 경로로 보낼수 있게 된다. 최단경로로 보내는 방법은 P.373 페이지 참조 클라이언트와 캐시서버거리 P.375 이미지들 참조 또 다른 방법으로는 

 

HTTP의 Location 헤더를 사용하는 것인다. 웹서버의 데이터를 다른 서버로 옮기는 경우 "리다이렉트"를 하게 되고 HTTP오버헤드가 증가하는 단점이 있다. 하지만 DNS설정을 잘 못 해 최단 거리가 아닐수도 있지만 HTTP는 IP주소를 기반으로 전송하기 때문에 더 정확하다.

 

또한 직접 패킷을 보내 패킷 왕복시간을 클라이언트가 스스로 입력도 가능하다.