HTTP - (3) 웹서버, 프락시에 대해

오늘 글은 웹서버와 프락시에 대해 다룰 것이다.

​

웹 서버는 기본적으로 HTTP와 TCP 처리를 하는 일을 한다.

자신이 보유하고 있는 리소스를 관리하고, HTTP 프로토콜을 구현하며 서버 관리 기능을 제공한다.

웹 서버를 만들고자 한다면, 여러 웹 서버 프로그램들 중 널리 사용되는 것들을 이용해볼 수 있다. (ex. microsoft, apache, nginx..)

샘플로 웹서버를 만들려면, 아파치 서버는 가상 호스팅, 접근 제어, 모니터링 등의 풍부한 기능을 제공하기 때문에 채택하기 어렵고,

간단하게 펄 코드 30줄 이하로 작성해볼 수 있다.

이 코드는 TCP 소켓을 생성하고, 커넥션을 기다린 뒤 요청 메시지를 받아 응답을 만들어내는 간단한 서버이다.

​

실제로 웹서버는 이와 유사하게 동작한다.

1) 커넥션을 맺고, 네트워크에서 HTTP요청 메시지를 읽는다.

2) 요청 메시지를 해석하고, 처리한다.

3) 메시지에서 지정한 리소스에 접근하고, 헤더를 포함하여 HTTP 응답 메시지를 생성한다.

4) 응답을 클라이언트로 돌려준다. 이 전체 과정을 로그로 남긴다.

​

이 과정에 대해 좀 더 깊게 살펴보자.

우선 가장 처음으로 커넥션을 맺는 과정이다. 클라이언트가 TCP커넥션을 요청오면, 서버는 커넥션을 맺은 뒤 IP주소를 추출한다.

이 IP주소로 서버는 어떤 클라이언트가 있는지 확인한다. 새롭게 맺어진 커넥션일 경우, 커넥션 목록에 추가한다.

​

커넥션이 맺어진 후, 서버는 요청 메시지를 파싱한다.

요청줄을 처음으로 파싱하는데, 메서드와 URI, 버전 번호를 분리하고 (빈 스페이스로 분리됨) 헤더를 읽은 뒤, 본문을 읽는다.

요청줄과 헤더는 각각 CRLF(캐리지 리턴 줄바꿈)으로 끝을 구분할 수 있고, 본문은 content-length헤더로 길이로 읽어들인다.

이 때 서버의 네트워크 커넥션은 언제든지 끊길 수 있기 때문에 서버는 가능한 한 이해할 수 있는 정도 단위로 임시로 메시지를 저장한다.

서버는 메시지를 읽어 내부적으로 자료구조에 담아 빠르게 요청 메시지 내용을 볼 수 있도록 한다.

​

서버는 여러 개의 커넥션을 동시에 지원할 수 있도록 설계되는데, 이 때 타입에 따라 분류를 나눌 수 있다.

* 단일 스레드 웹서버 : 한 번에 하나의 요청만 처리한다

* 멀티 프로세스와 멀티스레드 웹서버 : 여러 요청을 동시에 처리한다. 리소스 낭비를 막기 위해 최대 지원 프로세스/스레드 수에 제한을 둔다

* 다중 I/O 서버 : 커넥션을 다중적으로 처리하는 방식으로, 모든 커넥션은 활동을 감시당하며, 상태가 바뀜에 따라 서버가 매번 처리를 한다

* 다중 멀티스레드 웹 서버 : 멀티스레딩과 다중화를 결합하여, 여러 스레드가 커넥션을 각각 담당하고 처리를 진행한다.

​

서버는 요청을 처리한 이후 리소스에 접근하여 요청에서 요구하는 URI에 대응하는 콘텐츠를 찾아낸다.

이때 Docroot라는 개념이 등장하는데, Document Root라는 개념이며, 클라이언트가 요청하는 URI의 path에 붙일 디렉토리 경로이다.

이 때 클라이언트에서 URI를 docroot 상위로 요청하는 것을 허용해서는 안된다.

웹서버는 파일이 아닌 directory를 가르키는 URL을 요청받을 수도 있는데, 이 때는 index.html 파일을 찾아 반환해준다.

​

이처럼 리소스를 접근하여 요청하는 데이터를 찾아내었다면, 응답 메시지를 만들어야한다.

응답 상태 코드와 헤더, 본문을 포함하게 되는데, 본문에는 MIME타입과 길이, 내용을 포함한다.

주로 확장자명을 통해 MIME타입을 구분하고, 파일 내용을 검사하여 구분할 수도 있다.

URI가 일시적으로/혹은 영구적으로 이동되었을 경우 3XX 타입의 리디렉션 상태 코드를 반환하기도 한다.

​

서버는 응답 요청 메시지를 보내기 전에 커넥션 상태를 추적하고 있어야 한다.

비지속적인 커넥션일 경우 서버가 메시지를 모두 전송 완료하였을 때, 닫힐 것이고,

지속적인 커넥션일 경우 열린 상태를 유지할 것이다.

​

이러한 트랜잭션이 모두 완료되었을 때, 서버는 로그파일에 과정을 기록한다.

---

프락시 서버에 대해

프락시 서버는 중개자이다. 서버와 클라이언트 사이에 위치하여 HTTP 메시지를 정리한다.

프락시는 웹 서버이기도 하고 클라이언트이기도 하다. 양쪽 역할을 다 할 수 있도록 만들어야한다.

​

프락시 서버는 하나의 클라이언트가 독점적으로 사용할 수도 있고, 공유할 수도 있다. 이에 따라 각각 개인 프락시, 공용 프락시라고 부른다.

​

프락시와 게이트웨이는 유사하기도 한데, 전자는 동일한 프로토콜을 사용하는 둘 이상의 어플리케이션을 연결해주는 것이고,

후자는 서로 다른 프로토콜을 이용중인 어플리케이션을 연결한다는 점에서 닫르다.

예를 들어 프락시는 웹 프락시일 경우 양쪽 다 HTTP 통신을 이용하고, 웹/이메일 게이트웨이의 경우 한쪽은 브라우저이고 한쪽은 이메일 서버다.

​

프락시 서버를 왜 이용할까? 간단히 말하면 보안, 성능, 비용 측면에서 이득을 취할 수 있다.

예를 들어 유아용 웹사이트의 경우 성인 콘텐츠를 차단하고 필터링할 수 있다.

문서 접근의 경우에도 감사 추적을 통해 권한을 달리 부여하며 접근을 제어할 수 있다.

그 외에도 방화벽이라던지, 웹 캐시, 대리 프락시(=진짜 웹서버인 것처럼 행동함), 콘텐츠 라우터 등의 기능을 하기도 한다.

​

프락시를 네트워크 상에서 어디에 배치할 것인가도 고민해볼 수 있다. 위치에 따라 프락시 종류가 나뉘기도 한다.

- 출구 프락시 : 로컬 네트워크의 출구에 위치, 방화벽 혹은 성능 개선을 위해 제공된다.

- 접근 프락시 : ISP 접근 지점, 다운로드 속도 개선 및 대역폭 비용을 감축하기 위해 캐시 프락시 등으로 사용한다

- 대리 프락시 : 웹 서버 바로 앞에 위치하여 웹 서버의 성능을 개선하는 역할을 하기도 한다

- 네트워크 교환 프락시 : 네트워크 사이에 위치하여 트래픽 흐름을 감시하고 혼잡도를 완화시킨다

​

프락시가 트래픽을 처리하는 방법은 아래와 같이 있다.

1) 클라이언트를 수정할 수 있다, 자체적으로 클라이언트에서 프락시 서버로 HTTP요청을 보낸다

2) 네트워크에서 HTTP트래픽을 지켜보고 프락시가 서버로 향하는 트래픽을 채갈 수 있다

3) 대리 프락시는 DNS 이름 테이블에서 원 서버의 이름과 IP주소를 직접 사용한다

​

오늘날에는 웹 요청이 여러 프락시 서버를 거치게 된다. ISP 및 여러 회사들은 캐시 프락시 서버를 제공하기도 한다.

이 때문에 메시지를 잘 추적하는 것이 중요하게 되었다.

Via 헤더가 이 역할을 하는데, 중간 노드의 정보를 나열한다.

ex) Via : 1.1 proxy-62.irenes-isp.net, 1.0 cache.joes-hardware.com

위 예시에서는 두개의 프락시 서버를 지나갔다는 점을 확인할 수 있는데, 각각은 HTTP/1.1, 1.0 프로토콜을 구현하였다.

쉼표로 여러 waypoint를 구분하는데, waypoint란 프로토콜 이름 / 프로토콜 버전 / 노드 이름(호스트와 포트 번호) 을 담고 있다.

​

일전에 HTTP메시지 글에서 TRACE메서드에 대해 살펴보았는데, 이 메서드가 프락시 흐름을 디버깅할 떄 유용하게 사용된다.

메시지를 전달받는 과정에서 지나친 프락시들의 목록을 받을 수 있다.

​

프락시는 인증에 대한 기능을 제공하는데, 이 때 접근제어 장치로서 활용된다.

제한된 콘텐츠에 대한 요청을 받았을 때, 프락시 서버는 자격을 요구하는 상태코드 (407 Proxy Authorization Required)와

자격을 제출할 수 있는 Proxy-Authenticate 헤더와 함께 메시지를 보낸다.

클라이언트는 이 메시지에 따라 자격을 수집하여 제출하고, 적합하다면 콘텐츠에 접근하도록 허용한다.

​

클라이언트, 프락시, 웹 서버는 각기 다른 벤더사에 의해 개발될 수 있다. 이에 따라 제각기 지원하는 기능도 다르고, 동작도 다르다.

이 때 프락시는 어떻게 여러 타입의 클라이언트와 서버 사이에서 일관적으로 소통할 수 있을까?

클라이언트는 HTTP OPTIONS 메서드를 보내 어떤 기능을 지원하는지 파악할 수 있다.

혹은 Allow 헤더를 통해 지원 가능한 메서드들에 대해 열거하여 클라이언트로 보낼 수도 있다.

이러한 방법들로 프락시는 각기 다른 버전의 클라이언트와 서버간 상호작용을 할 수 있다.

​

---

참고서적

https://book.naver.com/bookdb/book_detail.nhn?bid=8509980

 

HTTP 완벽 가이드

성공적인 웹 트랜잭션 뒤의 숨은 핵심, HTTP의 모든 것『HTTP 완벽 가이드』는 HTTP 규약이 어떻게 작동하고 웹 기반 애플리케이션을 개발하는 데 어떻게 사용하는지 설명하고, HTTP가 효율적으로 동작하도록 함께 사용하는 다른 핵심 인터넷 기술에 대해서 소개한 책이다. 책에서는 HTTP 메서드, 헤더, 상태 코드, 프락시와 캐시의 최적화, 웹 로봇과 크롤러 설계 전략, 쿠키, 인증, 보안 HTTP, 국제화와 내용 협상, 리다이렉션과 부하 균형 전략, 더 좋은 성능의 HTTP, HTTP/2.0에 대해서 다루고 있다. 또한, 10...

book.naver.com

​