II. HTTP 아키텍처 | 5. 웹 서버

 

 

 

II. HTTP 아키텍처

05 웹 서버

 

  웹 서버는 웹 서버 소프트웨어(NGinX, apache...)와 웹 페이지를 제공하는 하드웨어 장비 양쪽을 가리킨다. 리소스에 대한 HTTP req을 받아서 클라이언트에게 res를 주는 것은 모두 웹 서버이다. 더 정확히는, HTTP와 그와 관련된 TCP 처리를 구현한 것이다.

  웹 서버는 어디에서든 이식할 수 있고 짧은 줄로도 구현할 수 있어서 임베디드에 웹 서버를 탑재해서 일반 소비자용의 제품을 웹을 통해 제어할 수 있도록 사용하기도 한다.

 

 

웹 서버가 하는 일

 

• 클라이언트 커넥션 수락

  클라이언트는 서버와 소통하기 위해 TCP 커넥션을 요청하면 웹 서버는 그 커넥션을 맺고 TCP 커넥션에서 클라이언트의 IP 주소를 확인하고 새 커넥션을 커넥션 목록에 추가한다. 웹 서버는 어떤 커넥션이든 마음대로 거절할수도 있고 닫을 수도 있다. 특정 IP를 밴을 하는 것은 이 과정에서 이뤄진다.

  대부분의 웹 서버는 리버스 DNS를 이용해서 클라이언트의 IP 주소를 호스트 명으로 변환하도록 설정되어 있다. 이 호스트 명을 이용해서 구체적인 접근 제어, 로깅을 위해 사용할 수는 있다. 다만, 호스트 명을 찾는 것은 꽤 많은 시간이 걸리기에 웹 트랜잭션을 느리게할 수 있다.

  

• req 받기

커넥션을 통해 req 요청이 오면 웹 서버는 해당 요청을 파싱하여 읽고 요청 메세지를 구성한다. 웹 서버는 대개 여러 커넥션을 가지는데 각 커넥션에서 들어오는 req 메세지를 어떻게 처리하는 지는 웹 서버의 아키텍처의 차이에 따라 달라진다. 

 

 - 단일 스레드 I/O 아키텍처 : 한 번에 하나씩 req를 처리한다. node.js로 구성한 웹서버는 단일 스레드에 해당한다. 참고로 node.js는 싱글 스레드라는 한계점 때문에 논 블로킹 I/O를 사용한다.

 

 - 멀티 스레드 I/O 아키텍처 : 여러개의 스레드가 req를 처리하는 방식. 대부분의 멀티 스레드/프로세스를 지원하는 웹 서비스는 스레드의 최대 갯수에 제한을 두곤 한다. (프로세스와 스레드는 같은 말처럼 쓰이지만 실은 다른 용어이다. 지금 단계에서는 스레드가 프로세스보다 더 빠르고 효율적인 버전이라고 생각하자)

 

 - 다중 스레드 I/O 아키텍처

 

 - 다중, 멀티스레드 I/O 아키텍처

 

• req 처리

웹 서버는 req 메세지로부터 메서드, 리소스, 헤더, 엔터티 본문을 얻어내서 처리한다. 이 과정에 대해서는 책의 나머지에서 계속해서 다룰 것이다.

 

• 리소스에 접근

  웹 서버가 req를 받으면 해당 메세지가 요구하는 리소스를 웹 서버에서 찾아야 한다. 이를 리소스 '매핑'(mapping)이라고 한다. 지도 상의 가상과 실재를 대응하는 것에 은유한 용어이다. 어쨌든간 웹 서버는 req에서 원하는 리소스와 실제 리소스를 매핑한다.

  

• res를 만든다

  웹 서버가 리소스를 식별하면 req 메세지의 동작을 수행한 뒤 res를 반환한다. res 메세지는 앞서 살펴보았듯이 상태코드, 응답헤더, 본문으로 구성되어 있다. MIME 타입을 서술하는 Content-Type헤더와 응답 본문의 길이가 적힌 Content-Length 헤더가 눈여겨봄직하다.

  웹서버는 응답 본문의 MIME 타입을 결정해야 하는 책임이 있다. gif면 gif, avi면 avi.

  종종 웹서버는 3xx 상태 코드와 함께 리다이렉션 res 메세지를 보내기도 한다. 리다이렉션을 하는 이유는 다양한데 대표적으로 리소스가 영구히 옮겨졌거나(301), 임시로 리소스가 옮겨졌거나(303, 307), URL을 적게 쳤을 때 자동으로 보강된 URL로 리다이렉션하기도 한다. 

 

• res를 보낸다
• 트랜잭션을 로그로 남긴다

트랜잭션이 완료되었을 때 웹 서버는 트랙잭션이 어떻게 수행되었는지 기록한다. 즉, 로그를 남긴다.