728x90

 

그림으로 배우는 Http&Network Basic

1. 1대로 멀티 도메인을 가능하게 하는 가상호스트
HTTP/1.1 에서는 하나의 서버에 여러개의 웹 사이트를 실행할수 있다.이를 위해 "가상호스트"라는 기능을 사용하고 있다.
"가상호스트"를 사용하면 물리적으로는 서버가 1대지만 가상으로 여러대가 있는 것처럼 설정하는 것이 가능하다.

인터넷에서 도메인명은 DNS에 의해 IP 주소로 변환되고 나서 엑세스를 하게된다.
결국 요청(req)이 서버에 도착하는 시점에는 "IP주소를 기준으로 접근"하게 된다.

이때 "가상호스트"를 사용하고 있다면, 1대의 물리적 서버에서 2개의 도메인이 있을 경우, 서버는 어느 쪽에 대한 접근인지 서버는 알수가 없다.이 때문에 HTTP 요청시에 다른 호스트명과 도메인명을 완전하게 포함한 URI를 지정하거나, 반드시 Host 헤더필드(Header)에서 지정해야한다.



2. 통신을 "중계"하는 프로그램: 프록시, 게이트웨이, 터널 (여러가지 종류가 있는거야 아니면 이름만 다를걸까?)
HTTP는 클라이언트와 서버 이외에 프록시, 게이트웨이, 터널 과 같은 통신을 중계하는 프로그램과 서버를 연계하는 것도 가능합니다.

2.1 프록시(Proxy)
서버와 클라이언트의 "양쪽 역할"을 하는 중계 프로그램(둘다? 와우 양방향이네 그렇다면 순기능도 있을 것도 아닌 경우도 있겠지?)
클라이언트 요청을 서버에 전송하고, 서버의 응답을 클라이언트에 전송한다.

프록시 서버의 기본동작은 요청(req)을 서버에 전송하는 것이다.(default는 req to server)
리소스(resource) 본체(body)를 가진 서버를 오리진 서버(origin) 라고 부른다.

HTTP 통신을 할 때, 프록시 서버를 여러대 경우하는 것도 가능하다.(양방향 중계할 수 있는 놈을 여러 대 사용도 가능하다니!)
중계할 때에는 Via 헤더필드*에 "경유한 호스트 정보를 추가한다."(경유지를 기록한다..)

프록시 서버를 사용하는 이유는, 캐시(cache)를 사용한 네트워크 대역(ex. IPv6?)을 효율적으로 사용하는 것, 조직 내에서 특정 웹사이트에 대한 접근제한(조직을 국가나 기업으로 한다면?), 액세스 로그를 획득하는 정책을 철저하게 관리하는 목적 등이 있다.

프록시 사용법은 여러 가지가 있지만 크게 2개의 기준으로 분류된다.
캐시(cache)를 하는지 안하는지 그리고 메세지를 변경하는지 안하는지

2.1.1 캐싱 프록시 (Cashing Proxy)
프록시로 응답을 중계할때는 프록시 서버상에 리소스 캐시를 보존해두는 타입의 프록시(캐싱하는 프록시)
프록시에 같은 리소스에 요청이 온 경우, 오리진 서버로 부터 리소스를 획득하는 것이 아닌 프록시 서버의 "캐시"를 응답으로 되돌려준다.

2.1.2 투명 프록시 (Transparent Proxy)
프록시로 요청과 응답을 중계할때 "메세지 변경을 하지 않는 타입".
반대로 메세지에 변경을 주는 타입을 비투과(non-transparent) 프록시라고 한다.



2.2 게이트웨이(Gateway)
다른 서버를 중계하는 서버
클라이언트의 요청을 오리진서버 인것처럼 수신한다.
경우에 따라 클라이언트는 상대가 게이트웨이인지 오리진서버인지 구분하지 못한다.
게이트웨이의 동작은 프록시와 매우 유사하다.
게이트웨이가 있는 경우에는 그 다음에 있는 서버가 HTTP 서버 이외의 서비스를 제공하는 서버가 된다.
클라이언트와 게이트웨이 사이를 암호화하는 등으로 안전하게 접속함으로써 통신의 안전성을 높이는 역할은 한다.
게이트웨이는 데이터베이스에 접속해 SQL 쿼리를 사용하여 데이터를 얻는 곳에 이용할수있다.
그밖에도 쇼핑사이트 등에서 신용카드 결제시스템과 연계할 때 사용된다.

2.3 터널(Tunnel) : 양끝단 암호화 통신
터널은 요구에 따라서 다른 서버와의 통신 경로(path)를 확립한다.
클라이언트는 SSL 같은 '암호화' 통신을 통해 서버와 안전하게 통신을 할때 사용된다. 
터널은 통신하고 있는 '양쪽 끝의 접속'이 끊어질때 종료된다. (클라-서버 양끝단 상태)




3. 리소스를 보관하는 캐시
캐시(Cache)는 프록시 서버와 클라이언트의 로컬 디스크에 보관된 리소스의 사본을 말한다.
캐시를 사용하면 리소스를 가진 서버에의 접근을 줄이는것이 가능하기 때문에 통신량과 통신 시간을 절약할수 있다.
캐시서버는 프록시 서버중 하나로 캐싱프록시로 분류된다.
프록시가 서버로부터의 응답을 중계할때 프록시서버에 리소스의 사본을 보존한다.
장점으로는 같은 데이터를 몇번이고 오리진 서버에 전송할 필요가 없다.
클라이언트는 네트워크에서 가까운 서버로 부터 리소스를 얻을수 있게되어, 서버는 같은 요청을 매번 처리 하지 않아도 된다.

3.1 캐시(cache)는 유효기간이 있다
캐시서버에 있는 리소스가 항상 오리진 서버의 리소스와 같다고 보장할수는 없다.
서버에있는 리소스가 갱신되는 경우 캐시서버는 낡은 리소스를 가지게된다.
그래서 캐시를 가지고 있더라도 클라이언트의 요구나 캐시의 유효기간 등에 의해서 오리진 서버에 리소스의 유효성을 확인하거나 새로운 리소스를 다시 가지러 가는 경우도 있다.

3.2 클라이언트 측에도 캐시가 있다
클라이언트에서 사용하는 브라우저에서도 캐시를 가질수 있다. (브라우저프로그램의 캐시)
익스플로러에서는 이를 "인터넷임시파일" 이라고 부른다. (역사적인 공부가 도움이 되는 경우. 시간을 넘나들면서 학습하기)
브라우저가 "유효한 캐시(valid cache)"를 가지고 있는 경우, 서버에 접근하지 않고 로컬디스크(Local Disk)에서 불러온다.
캐시서버와 마찬가지로 유효시간이 지났다고 판단되면, 오리진 서버(origin)에 유효성을 '검증'하러(시간비교?) 가거나 새로운 리소스를 다시 획득하는 경우도 있다.


*Via:
The Via general header is added by proxies, both forward and reverse, and can appear in the request or response headers. It is used for tracking message forwards, avoiding request loops, and identifying the protocol capabilities of senders along the request/response chain.

출처: https://velog.io/@nudge411/HttpNetwork-Basic-2(그림으로 배우는 Http&Network Basic)

 

 

==

프록시:
클라이언트와 서버 사이에서 중계 역할을 하는 기능을 말하며, 그 기능을 수행하는 컴퓨터나 응용프로그램을 프록시 서버(Proxy)라고 합니다.

 

프록시 서버는 그 특징에 따라 다양한 목적으로 사용됩니다.
프록시 서버는 '캐시(Cache)'를 이용하여 임시로 데이터를 저장해두기 때문에,

사용자들이 프록시 서버 내의 데이터를 요청할 경우 전송시간이 절약됩니다.(성능)

다수 사용자들이 접속하는 사이트 정보가 저장되어 있어,
해당 사이트에 직접 접속하지 않아도 데이터 이용이 가능하므로 네트워크 '병목 현상'을 줄일 수 있습니다.(성능)
(데이터에 접근하는 계층을 두어 접근 시간의 차이를 둠. 자주 쓰는 건 가까이.Locality)

또한 프록시 서버는 방화벽 역할을 담당하기도 합니다. (웹방화벽?)

외부통신이 이루어 질 때, 모든 데이터 흐름이 프록시 서버를 거치게 되어,

유해사이트 차단이나 외부침입 방지에 사용할 수 있습니다.

이러한 특징으로 회사 등 기관에서는 보안유지를 위해 데이터 '접근 통제'하는 데 프록시 서버를 이용하기도 한다.  
다만 프록시 서버에 많은 사용자들이 몰려 클라이언트 요청(req) 과부하가 걸렸을 경우,

프록시 서버에 저장된 데이터가 없을 경우에는 반복된 검색으로 오히려 속도가 저하될 수 있다는 점을 숙지해야 한다.

컴퓨터 네트워크에서 다른 서버로의 자원 요청을 중계하는 서버로,

분산 시스템의 구조를 단순화하고 캡슐화하여 서비스의 복잡도를 줄이는 역할을 한다.

일반적으로 프록시는 대부분 '웹 프록시'를 일컫는다.

클라이언트가 필요한 서버로부터 파일, 연결, 웹 페이지 등과 같은 자원(resource)을 프록시 서버에 요청하면,

프록시 서버는 클라이언트와의 사이에서 '대신(대리)' 통신을 수행한다.

프록시서버에는 클라이언트로부터 원격에 요청(req)된 자원들이 캐시(cache)되어 임시로 저장되어 있다.
클라이언트는 자원 재요청 시 원격 서버에 접속할 필요 없이, 프록시 서버 내의 정보를 제공 받을 수 있다.

따라서 데이터 전송시간과 외부트래픽이 줄어들고 서버 측의 네트워크 병목 현상을 방지할 수 있다.

그리고 프록시 서버 측에서 위험 웹 콘텐츠 및 악성코드를 '필터'링 함으로써 클라이언트 측의 보안을 향상시킬 수 있다.

또한 익명의 사용자가 서버에 접근하는 것을 막고 외부 침입을 방지함으로써 방화벽 역할을 담당하기도 한다.

그리고 보안 유지를 위해 내부와 외부 '접근 통제'와, 인터넷 '이용률 통계' 수집을 위해 프록시 서버를 사용하기도 한다.
반대로 사용자의 입장에서 자신의 "웹 서핑 기록을 익명화"하기 위해 "익명 웹프록시(Anonymzier)"를 사용하기도 한다.

프록시 서버의 사용 목적:
* 익명으로 컴퓨터를 유지하기 위한 목적
* 캐시(cache)를 사용하여 리소스로의 접근을 빠르게 하기 위한 목적(성능)
* 네트워크 서비스나 콘텐츠로의 접근 정책을 적용하기 위한 목적(보안)
* 사용률을 기록하고 검사하기 위한 목적(성능 모니터링)
* 보안 및 통제를 뚫고 나가기 위한 목적(?)
* 바이러스 전파 및 악성 루머 전파 그리고 다른 정보들을 빼낼 목적(?)
* 역 ‘IP추적’을 방지하기 위한 목적
* 전달에 앞서 악성코드를 목적으로 전달된 콘텐츠를 검사하기 위한 목적
* 지역 제한을 우회하기 위한 목적



프록시 서버는 실제 사용자의 로컬 컴퓨터에 상주할 수도 있고 독립적인 서버로 존재할 수도 있으며 인터넷 상에서 클라이언트와 목적지 서버 사이 어느 곳이든 놓여질 수 있다.

프록시 서버 종류
포워드 프록시(Forward Proxy) : 프록시 서버가 클라이언트와 원격 서버 사이의 네트워크 상 어디에든 위치할 수 있다.
클라이언트는 원격 목적지 서버의 주소를 기반으로 자원을 요청하고 프록시서버는 그 주소를 받아 목적지 서버에 연결 하고 자원을 가져온다. 즉, 프록시 서버는 클라이언트가 알려주기 전에는 목적지 서버의 주소를 알수 없다.


리버스 프록시(Reverse Proxy)

프록시 서버가 사설 네트워크(Private Network) 상의 서버를 바로 앞단의 프론트엔드(Front-End)에 위치하고 서버들을 제어하고 보호한다.
클라이언트는 리버스 프록시 서버 주소를 목적지 서버로 하여 데이터를 요청한다.

즉, 클라이언트에게 리버스 프록시 서버는 일반적인 보통 서버로 보이게 된다.
리버스 프록시 서버는 클라이언트의 요청에 따라 자신의 뒷쪽(Reverse)에 있는 적합한 서버에 데이터 요청을 전달하고 응답된 데이터를 클라이언트로 전달한다.
따라서, 리버스 프록시 서버는 자신의 뒷쪽에 있는 실제 자원을 가지는 서버들에 대한 주소를 유지하고 있어야 한다. 리버스 프록시는 보안이나 암호화를 위해서 사용되기도 하고, 뒷단의 서버들에 대한 요청을 '부하 분산'하기 위해서 사용되기도 한다.


오픈 프록시(Open Proxy)

모든 인터넷 사용자가 액세스 할 수 있는 프록시 서버로 익명 공개 프록시는 사용자가 웹 브라우징을 하거나 다른 인터넷 서비스를 사용하는 동안 자신의 IP 주소를 숨길 수 있도록 해준다.

'네트워크' 카테고리의 다른 글

[네트워크] OSI Model  (0) 2020.06.22
[네트워크] MAC Address 메모  (0) 2020.06.16
[NET] TCP/IP PROTOCOL(forouzan) 목차  (0) 2020.06.14
[NET] HTTP와 Cookie  (0) 2020.06.14
[네트워크] HTTP 01  (0) 2020.05.31

+ Recent posts