네트워크 용어정리

프록시(proxy)

 

프록시서버

컴퓨터 네트워크에서 다른 서버 상의 자원을 찾는 클라이언트로부터 요청을 받는 중계하는 서버 즉, 중계해주는 서버

프록시 서버는 프록시 서버에 요청된 내용들을 캐시를 이용하여 저장한다.

 

 

구조상 위치에 따라 포워드 프록시, 리버스 프록시로 나뉘며 서로 반대의 개념

 

포워드 프록시

• 일반적인 프록시 서버
• 클라이언트-서버 구조에서 클라이언트 쪽을 대리
• 클라이언트에서 서버로 리소스를 요청할 때 직접 요청하지 않고 프록시 서버를 거쳐 요청
• 인터넷보다 프록시서버를 먼저 호출하면 포워드 프록시
• 서버가 응답받은 IP는 프록시 서버의 IP이기 때문에 클라이언트가 누군지 알 수 없음. -> 클라이언트를 감춤
• Ex) 회사 내부 인트라넷에서 인터넷상에 있는 서버에 요청을 할 때 프록시 서버를 먼저 호출함

 

리버스 프록시

• 애플리케이션 서버의 앞에 위치
• 클라이언트가 서버에 요청할 때 리버스 프록시를 호출
• 리버스 프록시가 원 서버로부터 응답을 전달받아 다시 클라이언트에게 전송
• 인 클라이언트가 프록시 서버를 호출하여 내부망에 있는 서버를 호출하면 리버스 프록시
• 클라이언트는 리버스 프록시 서버를 먼저 호출하여 실제 서버의 IP를 알 수 없음
• Ex) 회사 내부 인트라넷에 있는 서버를 호출할 때 인터넷 망에 있는 클라이언트가 리버스 프록시 서버에 요청하여 응답을 받음

 

프록시(포워드) EX

• 클라이언트의 IP를 숨겨 개인 정보 보호
• SSL과 같은 암호화 가능
• 네트워크 대역폭을 줄이고 서버의 응답을 압축하여 성능을 향상
• 방화벽으로 보호되는 서버와 인터페이스 하여 보안 강화
• 로드 밸런싱을 구현하여 서버가 다운돼도 서비스 계속 작동 가능
• (비디오, 이미지, 스크립트 및 HTML) 정적 콘텐츠를 캐시하여 최근에 엑세스한 콘텐츠를 빠르게 제공하여 과부하 방지
• 콘텐츠 전송 네트워크를 이용하여 가장 가까운 위치에서 서비스를 제공
• 프록시를 사용하여 구성 가능한 정책에 따라 사용자가 웹사이트 또는 기타 서비스 연결 불가하게 필터링 가능
• 감사 추천 또는 도청과 같은 동기를 위해 네트워크 트래픽을 기록하는 데 사용 가능
• 웹 브라우저가 웹사이트의 IP주소를 조회하는데 사용하는 DNS 쿼리와 같은 네트워크 서비스의 속도를 높이도록 설계 가능

 

리버스 프록시 EX

• 요청을 전달할 위치를 결정 가능
• TSL와 같은 암호화 구현
• 요청을 스캔하고 의심스러워 보이는 모든 것을 거부하여 정보 보안에 용이
• 요청을 캐시하여 성능 향상 가능
• 콘텐츠 전송 네트워크는 종종 리버스 프록시로 구현되기도 함

 

 

로드밸런서(Load Balancer)

서비스 규모가 커지면 서버 한 대로는 모든 서비스를 수용할 수 없게 되며, 서버 한 대로 서비스를 제공할 수 있는 용량이 충분하더라도 서비스를 단일 서버로 구성하면 해당 서버의 애플리케이션, 운영체제, 하드웨어에 장애가 발생했을 때, 정상적인 서비스를 제공할 수 없다.

 

서비스 가용성(availability)을 높이기 위해서 하나의 서비스는 보통 두 대 이상의 서버로 구성하는데 각 서버 IP주소가 다르므로 사용자가 서비스를 호출할 때는 어떤 IP로 서비스를 요청할지 결정해야 한다. 사용자에 따라 호출하는 서버의 IP가 다르면, 특정 서버에 장애가 발생했을 때, 전체 사용자에게 영향을 미치지 않아 장애 범위는 줄어들겠지만 여전히 부분적으로 서비스 장애가 발생하며 이러한 문제점을 해결하기 위해서 로드 밸런서(Load Balancer)를 사용한다.

 

 

로드 밸런싱

 

로드 밸런서는 동일한 서버를 하는 다수의 서버가 등록되고 클라이언트로부터 서비스 요청이 오면 로드 밸런서가 받아 사용자별로 다수의 서버에 요청 분산하여 부하를 분산한다.

 

로드 밸런서는 서비스를 위한 가상 IP를 하나 제공하고, 사용자는 서버의 개별 IP가 아닌 동일한 가상IP를 통해 서버로 접근한다. 또한 각 서버의 서비스의 상태를 체크해 하나의 서버에 장애가 발생하여도 장애가 발생하지 않는 서버로 요청을 분산하여 장애 없이 서비스를 제공한다.

 

 

계층별 로드 밸런서

로드 밸런서는 동작하는 계층에 따라 OSI 7 계층 모델을 기준으로 보통 4 계층과 7 계층으로 나눈다.

 

L4 로드 밸런서

 

 

L4 Load Balancing

 

일반적인 로드 밸런서가 동작하는 방식이며 TCP, UDP 정보(특히 포트 넘버)를 기반으로 로드 밸런싱을 수행한다. 이때, 부하를 분산하는 기능뿐만 아니라, TCP 계층에서의 최적화와 보안 기능을 함께 제공한다. 그러나 최근 사용되는 로드 밸런서는 4 계층과 7계층의 기능을 모두 지원하기 때문에 4계층 로드밸런싱만 제공하는 경우는 찾기 어렵다.

 

 

L7 로드 밸런서

 

 

L7 Load Balancing

 

 

HTTP, FTP, SMTP와 같은 애플리케이션 프로토콜 정보를 기반으로 로드 밸런싱을 수행하며 HTTP 헤더 정보나 URI와 같은 정보를 기반으로 프로토콜을 이해한 후 부하를 분산한다. 일반적으로 이런 장비를 ADC(Application Delivery Controller)라고 부르며 리버스 프락시 역할을 수행한다. 대부분의 L7 로드밸런서는 4 계층에서 7 계층까지 로드밸런싱 기능을 제공하며, 장애극복(Failover), 리다이렉션의 기능도 함께 수행한다.

 

 

 

 

캐시의 기본 원리 및 적용

 

 

 

클라이언트가 logo.jpg 이미지에 대한 요청을 보내고 서버가 해당 이미지에 대한 응답을 줄 때, HTTP 헤더가 0.1M, 바디가 1.0M로 총 1.1M로 가정해보겠다. 같은 이미지를 다시 요청하더라도 첫 번째처럼 똑같이 1.1M의 응답을 보냅니다. 이 경우 logo.jpg 데이터가 변경되지 않아도 계속 데이터를 새로 다운로드하여야 한다.

 

인터넷 네트워크는 매우 느리고 비싸며 브라우저 로딩 속도 또한 느려지며 느린 사용자의 경험을 제공하여 해결책을 나온 것이 캐시이다.

 

 

캐지 적용 - 첫번째 요청

 

캐시(cache)

컴퓨터 과학에서 데이터나 값을 미리 복사해 놓는 임시 장소를 말한다.

 

캐시의 접근 시간에 비해 원래 데이터를 접근하는 시간이 오래 걸리거나 값을 다시 계산하는 시간을 절약하고 싶은 경우에 사용하며 캐시에 데이터를 미리 복사해 놓으면 계산이나 접근 시간이 없어 더 빠른 속도로 데이터에 접근이 가능하다.

 

브라우저에 캐시를 저장할 땐 헤더에 cache-control 속성을 통해 캐시의 유효한 시간을 지정할 수 있다.

Ex) Cache-control : max-age = 60 이면 60초 동안 캐시가 유효하다는 의미

 

 

 

캐시 적용 - 두번째 요청

 

두번째 요청에서는 캐시를 우선 조회하며 캐시가 존재하고 아직 60초가 지나지 않아 유효한 캐시라면 해당 캐시에서 데이터를 가져온다.

이러한 경우 캐시 가능 시간 동안 네트워크를 사용하지 않아도 돼서 비싼 네트워크 사용량을 줄일 수 있으며 브라우저 로딩 속도가 매우 빠르며 사용자에게 빠른 경험을 제공한다.

 

만약, 캐시의 유효시간이 초과한다면 어떻게 될까?

 

캐시 적용 - 세번째 요청 ( 캐시시간초과상황)

 

이러한 경우 다시 서버에 요청을 하여 다시 조회하고, 캐시를 갱신하여 60초간 유효한 데이터를 응답받으며 이때, 다시 네트워크 다운로드가 발생하게 된다.

 

 

 

캐시 적용 -세번째 요청(다시 응답)

 

응답 결과를 브라우저가 랜더링 하면 브라우저 캐시는 기존 캐시를 지우고 새 캐시로 데이터를 업데이트하며 이 과정에서 캐시 유효 시간이 다시 초기화된다.

 

 

 

캐시 검증 헤더와 조건부 요청

 

앞에선 캐시의 유효시간이 초과하면 다시 요청을 보내 새로운 데이터로 캐시를 업데이트하였다. 굳이 데이터가 같은데 또 요청을 보내 업데이트하면 데이터 낭비이다. 만약 캐시 유효시간이 지나도 변경이 없어서 해당 데이터를 써도 되는 상황이라면 이를 검증하고 사용하는 방법은 없을까? 

 

 

Last-Modified 와 If-Modified-Since

 

 

 

검증 헤더 Last Modified를 이용해 캐시의 수정시간을 알 수 있으며 Last Modified는 데이터가 마지막으로 수정된 시간 정보를 헤더에 포함된다. 이로 인해 응답 결과를 캐시에 저장할 때 데이터 최종 수정일도 저장됩니다.

 

 

 

처음 Last-Modified를 확인하여 데이터의 수정을 검증하고 수정값이 없다면 바디를 제외한 HTTP 헤더(0.1M)만 전송하며 브라우저 캐시에 응답 결과를 재사용, 헤더 메타 데이터 또한 갱신(60초 유효)한다. 브라우저는 캐시에서 조회한 데이터를 랜더링 한다. 

 

즉, 캐시 유효 시간이 초과하여도, 서버의 데이터가 갱신되지 않으면 304 Not Modified 응답 코드와 바디 없이 헤더 메타데이터만 응답하며 클라이언트는 서버가 보낸 응답 헤더 정보로 캐시의 메타데이터를 갱신하여 클라이언트는 캐시에 저장되어있는 데이터를 재활용한다.

 

결과적으로, 네트워크 다운로드는 발생하지만 용량이 적은 헤더 정보만 다운로드한다.

 

Last - Modified와 If-Modified-Since 단점 

• 1초 미만(0.x초) 단위로 캐시 조정이 불가능하며 날짜 기반의 로직을 사용한다.
• 데이터를 수정하여 날짜가 다르지만 수정 결과는 똑같을 때 수정 날짜는 바뀌었기 때문에 바디값을 포함하여 응답한다.
• 서버에서 별도의 캐시 로직을 관리하고 싶은 경우 

ex) 스페이스나 주석처럼 크게 영향이 없는 변경에서 캐시를 유지하고 싶은 경우

 

 

 

 

ETag 와 If-None-Match

ETag : 캐시용 데이터에 임의의 고유한 버젼이름을 달아둔 것이며 데이터가 변경되면 이름을 바꾸어서 변경함(Hash를 다시 생성)

            단순하게 ETag를 보내서 같으면 유지, 다르면 다시 받는 방식이다.