[HTTP 아키텍처] 웹 서버

 웹 서버(Web Server)란, 웹 서버 소프트웨어와 이를 제공하는 물리적 서버 양쪽 모두를 가리키며, HTTP 요청을 처리하고 응답을 제공한다. 크기나 기능, 형태 등은 다양하며, 코드 몇 줄로 구현할 수 있는 서버가 있는 반면에, 몇 십 메가바이트의 안전한 상용 엔진 등도 있다. 하지만 기능은 달라도 모든 웹 서버는 리소스에 대한 HTTP 요청을 받아서 콘텐츠를 클라이언트에게 보내준다. 아래에서의 웹서버는 소프트웨어 적인 관점 위주로 설명하겠다. 

 

웹 서버의 구현

 웹 서버는 HTTP 및 HTTP 프로토콜을 구현하고 웹 리소스를 관리하며, 웹 서버 관리 기능을 제공한다. 즉 HTTP 및 그와 관련된 TCP 처리를 구현한 것이다. 그리고 웹 서버는 TCP 커넥션 관리에 대한 책임을 운영체제와 나눠 갖는다. 

 HTTP/1.1의 기능들을 지원하려면, 접근 제어, 로깅, 설정, 모니터링 등 여러 성능을 위한 각종 기능들이 필요하다. 물론 이를 직접 구현하려면 수천줄 이상의 코드가 필요하다. 하지만 요즘은 누구나 쉽게 서버를 구축할 수 있도록 엔진을 제공해 준다. 예를 들어, Node.js의 Express server는 코드 몇 줄이면 누구나 서버를 빠르게 구현할 수 있다.

// > npm init
// > npm i express

const express = require('express');

const app = express();
const server = app.listen(3000, function(){
    console.log("Express server has started on port 3000")
})

만약 서버 구축이 어렵고 남일처럼 느껴졌다면 그 걱정은 잠시 내려두고 한번 직접 만들어 보자. 

 실제로 서비스해야 한다면 당연히 더 많은 추가 작업이 필요하지만, 이것만으로도 놀랍다. 그렇다면 이렇게 구현된 웹 서버가 하는 일에 대해 좀 더 상세하게 아래 그림을 통해 살펴보자.

 

출처: https://feel5ny.github.io/2019/09/07/HTTP_005/

1단계: 클라이언트 커넥션 수락

클라이언트가 이미 서버에 열려있는 지속적 커넥션을 가지고 있다면 그 커넥션을 사용할 수 있지만, 그게 아니라면 서버에 대한 새 커낵션을 열 필요가 있다. 

 

2단계: 요청 메시지 수신

커넥션에 데이터가 도착하면, 웹 서버는 네트워크 커넥션에서 그 데이터를 읽어 들이고 파싱하여 요청 메시지를 구성한다.

요청 메시지를 파싱할 때, 웹 서버는 다음과 같은 일을 한다.

• 요청줄을 파싱하여 요청 메서드, 지정된 리소스의 식별자(URI), 버전 번호를 찾는다. 각 값은 스페이스 한 개로 분리되어 있으며, 요청줄은 CRLF 문자열로 끝난다.
• 메시지 헤더들을 읽는다. 각 메시지 헤더는 CRLF로 끝난다.
• 헤더의 끝을 의미하는 CRLF로 끝나는 빈 줄이 있다면, 찾아낸다.
• 요청 본문이 있다면 읽어 들인다(길이는 Content-Length 헤더로 정의).

3단계: 요청 처리

웹 서버가 요청을 받으면, 서버는 요청으로부터 메서드, 리소스, 헤더, 본문(있는 경우)을 얻어내어 처리한다.

나중에 좀 더 자세히 다뤄보겠다. 

 

4단계: 리소스의 매칭과 접근

웹 서버는 여러 종류의 리소스 매핑을 지원한다. 일반적으로 문서 루트 혹은 docroot로 불리는 웹 서버 파일 시스템의 특별한 폴더를 웹 콘텐츠를 위해 예약해 둔다. 이외에도 여러가지 리소스 매핑과 접근이 지원되지만, 자세한 동작 방법은 다루지는 않는다.

 

5단계: 응답 만들기

한번 서버가 리소스를 식별하면, 서버는 요청 메서드로 서술되는 동작을 수행한 뒤 응답 메시지를 반환한다.

• 응답 엔터티 - 만약 트랜잭션이 응답 본문을 생성한다면, 그 내용을 응답 메시지와 함께 돌려보낸다.
• MIME 타입 결정 - 웹 서버에게는 MIME 타입을 결정해야 하는 책임이 있다. MIME 타입과 리소스를 연결하는 방법은 여러 가지가 있다(mime.types, 매직 타이핑(Magic typing), 유형 명시(Explicit typing), 유형 협상(Type negotiation)).
• 리다이렉션 - 웹 서버는 종종 성공 메시지 대신 리다이렉션 응답(3XX 상태코드)을 반환한다. Location 응답 헤더는 콘텐츠의 새로운 혹은 원하는 위치에 대한 URI를 포함한다. 영구히 리소스가 옮겨진 경우, 임시로 리소스가 옮겨진 경우, URL 증강, 부하 균형, 친밀한 다른 서버가 있을 때, 디렉터리 이름 정규화(URI를 요청하는데 슬래시(/)를 빠뜨렸을 때, 상대 경로가 정상적으로 동작할 수 있도록 클라이언트를 슬래시를 추가한 URI로 리다이렉트 하는 것) 등의 경우에 유용하다.

 

6단계: 응답 보내기

웹 서버는 받을 때와 마찬가지로 커넥션 너머로 데이터를 보낼 때도 비슷한 이슈에 직면한다. 서버는 커넥션 상태를 추적해야 하며, 지속적인 커넥션은 특별히 주의해서 다룰 필요가 있다. 비지속적인 커넥션이라면 서버는 모든 메시지를 전송했을 때 자신쪽의 커낵션을 닫을 것이다. 

 

7단계 로깅

마지막으로 트랜잭션이 완료되었을 때 웹 서버는 트랜잭션이 어떻게 수행되었는지에 대한 로그를 로그 파일에 기록한다.