웹 서버

웹 서버란?

웹 서버는 웹 서버 소프트웨어와 웹페이지 제공에 특화된 장비 모두를 가리키는 말이며, 공통적으로 리소스에 대한 HTTP 요청을 받아서 콘텐츠를 클라이언트에게 돌려주는 기능을 한다. 웹 서버는 HTTP를 비롯하여 관련된 TCP 처리를 구현한 것이기도 하다. 이렇게

• HTTP 프로토콜의 구현
• 웹 리소스 관리
• 웹 서버 관리 기능 등을 제공하는 웹 서버는 TCP 커넥션 관리에 대한 책임을 운영체제와 나누어 갖는다.

이러한 웹 서버의 형태에는 여러가지가 있는데, 크게 나누어

• 다목적 소프트웨어 웹 서버
• 임베디드 웹 서버 의 형태로 나뉘다. 

다목적 소프트웨어 웹 서버

네트워크에 연결된 표준 컴퓨터 시스템에서 동작하는 웹 서버이다. 흔히 Apache, Nginx, Caddy, IIS, LiteSpeed 등 우리가 아는 웹 서버를 의미한다. 단순히 정적인 웹 페이지를 제공하는 것 이상으로, 동적 콘텐츠 처리, API 서버 역할, 리버스 프록시, 로드 밸런싱, 보안 기능 등 다양한 역할을 수행할 수 있는 웹 서버를 의미한다.

참고로 현재 웹 서버 1등을 달리고 있는 것은 nginx이다

임베디드 웹 서버

일반 소비자용 제품에 내장될 목적으로 만들어진 작은 웹 서버이다. 임베디드 웹 서버의 작동 방식은 하드웨어에 내장된 소프트웨어로 동작하는 웹 서버이기 때문에 경량화가 중요하며, 최소한의 기능을 제공한다. 작동 방식은 위 사진을 보면 쉽게 이해가 가능하다. 웹 브라우저(클라이언트)가 HTTP 요청을 보내면, 임베디드 장치의 웹 서버는 클라이언트의 HTTP 요청을 수신받고, 요청을 분석하고 적절한 응답을 생성 한 뒤, 클라이언트에게 HTTP 응답을 반환한다. 이 과정에서 내장된 하드웨어의 상태 조회나 설정 변경, 특정 명령을 API를 통해 보내고 조작할 수 있다.

대표적인 임베디드 웹 서버로 GoAhead, CivetWeb, Mongoose, NanoHTTPD, Lighttpd 등이 있다.

웹 서버가 하는 일에 대한 고찰

웹 서버는 위와 같이 HTTP 프로토콜의 구현, 웹 리소스 관리, 웹 서버 관리 등등을 할 수 있다고는 하지만 정작 어떻게 동작하는지 이해하지 못한다면 그대로 암기과목이 될 확률이 높으므로 웹 서버가 어느 과정에서 어떻게 동작하는지를 알아야 한다.

위 사진을 보면 흐름을 이해하기 쉽다 웹 서버는 HTTP 요청을 보내고 받기까지

1. 커넥션 맺기 : 클라이언트 접속을 받거나 닫기
2. 요청 받기 : HTTP 요청 메세지를 네트워크로부터 읽어들이기
3. 요청을 처리 : 요청 메시지를 해석하고 행동 취하기
4. 리소스에 접근하기 : 메시지에서 지정한 리소스에 접근
   • 여기서 동적으로 처리해야 하는 경우, 서버와 연동하여 값을 동기화 시키지만, 정적인 파일은 그대로 가져다 준다.
5. 응답 만들기 : 올바른 헤더를 포함한 HTTP 응답 메시지 생성
6. 응답 보내기 : 응답을 클라이언트에 돌려주기
7. 트랜잭션 로깅 : 로그 파일에 트랜잭션 로깅하기 의 과정을 거친다.

여기서 크게 나눈 각 과정을 깊게 알아보자.

커넥션 맺기

클라이언트는 서버에 대해 지속적인 커넥션을 가지고 있다면 요청을 보낼 때 해당 커넥션을 사용할 수 있지만 없으면 새 커넥션을 열어야 한다. 클라이언트가 웹 서버에 TCP 커넥션을 요청하면, 웹 서버는 커넥션을 맺고 TCP 커넥션에서 IP 주소를 추출하여 커넥션 맞은편에 어떤 클라이언트가 있는지 확인한다. 커넥션 이후에는 서버가 커넥션 목록에 추가하고 계속해서 지켜볼 수 있도록 한다. 역방향 DNS를 사용하는 경우에는 클라이언트의 IP 주소를 호스트 명으로 변환할 수 있지만, 트랜잭션을 느려지게 할 가능성이 있으므로 꺼두거나 특정 콘텐츠에 대해서만 켜놓는다.

추가적으로 어떤 웹 서버는 ident, 즉 클라이언트 사용자를 식별하는 IETF ident 프로토콜을 지원한다.

IETF(Internet Engineering Task Force) : 인터넷 기술의 표준(protocols, architecture, etc.)을 개발하고 유지·보수하는 국제적인 조직

어떤 사용자 이름이 HTTP 커넥션을 초기화했는지와 같은 부가정보도 찾아낼 수 있도록 한다. 이 때, 단순히 HTTP 커넥션을 그대로 이용하는 것이 아니다. 서버는 클라이언트의 ident 서버 포트인 113번을 향해 요청을 보내고,클라이언트가 요청에 대한 응답을 반환하면 서버가 받은 정보를 기반으로 사용자 ID를 확인 후 인증하는 방식이다.

하지만 이 또한 오버헤드가 존재하고, 프라이버시 침해의 문제 등 프로토콜 자체가 안전하지 않고 조작되기 쉬운 만큼 사용을 많이 하지 않는다. 또 요즘은 네트워크에서 방화벽이 113 포트를 차단하고 있기 때문에 범용적으로 사용하기도 쉽지 않다.

요청 메시지 수신하기

커넥션에 데이터가 도착하면 웹 서버는 네트워크 커넥션에서 그 데이터를 읽어들이고 파싱하여 요청 메시지를 구성한다. 이러한 데이터를 네트워크로부터 읽어들이고, 파싱하면서 URI, 버전 번호 등을 찾는다. 각 값은 스페이스로 분리되어 있고 요청 줄은 캐리지 리턴(CRLF) 문자열로 끝난다. 이렇게 메시지의 헤더와 본문이 있으면 읽어들이는 과정을 거친다.

이 과정에서 웹 서버는 입력 데이터를 네트워크로부터 불규칙적으로 받고 네트워크 커넥션은 언제라도 무효화될 수 있기 때문에 웹 서버는 이를 파싱하고 이해할 수 있는 정도까지 네트워크로부터 읽어야 하는 만큼 메모리를 사용하여 현재까지 받아들인 메시지를 저장할 수 있어야 한다.

이런 식으로 헤더 부분에서 룩업 테이블을 두고 해당하는 필드에 넣음으로써 요청 메시지를 쉽게 다루는 경우도 있다.

아무튼 웹 서버는 이렇게 요청이 오면 메시지를 계속 받고 이를 처리할 수 있는 커넥션을 매무 많이 만들 수 있도록 지원해야 다른 사람들이 동시에 요청하더라도 이를 처리할 수 있다. 그렇기 때문에 웹 서버들은 항상 새 요청이 언제라도 올 가능성이 있어 계속 주시하고 있는 상태이다. 이렇게 새 요청을 주시하고 처리하는 방식은 웹 서버 아키텍처에 따라 조금씩 다르다.

• 단일 스레드 웹 서버
  • 한 번에 하나씩 요청을 처리
  • 하나의 요청 처리동안 다른 커넥션이 무시되어 성능 안좋음
• 멀티프로세스와 멀티스레드 웹 서버
  • 여러 요청을 동시에 처리하기 위해 여러 개의 프로세스 혹은 고효율 스레드를 할당
• 다중 I/O 서버
  • 모든 커넥션은 동시에 그 활동을 감시
  • 커넥션의 상태가 바뀌면, 그 커넥션에 대해 작은 양의 처리가 수행
  • 처리가 완료되면, 커넥션은 다음번 상태 변경을 위해 열린 커넥션 목록으로 돌아감
• 다중 멀티스레드 웹 서버
  • 컴퓨터 플랫폼에 올라와 있는 CPU 여러 개의 이점을 살리기 위해 멀티스레딩과 다중화(Multiplexing)를 결합
  • 열려 있는 커넥션을 감시하고 각 커넥션에 대해 조금씩 작업

요청 처리

웹 서버가 요청을 받으면 메서드, 리소스, 헤더, 본문 등의 정보를 얻어내어 처리한다. 본문은 있을 수도 있고 없을 수도 있다. 되도록 본문이 없어야 하는 경우도 있다.

HTTP/1.1의 명세에 따르면 GET 메서드는 Request Body를 포함해서는 호출하면 안 된다. 이는 GET 메서드가 설계 의도에 따라 단순한 데이터 조회를 목적으로 하고 있으며, 이에 따라 Request Body를 사용하지 않도록 규정되어 있다.

리소스 매핑과 접근

웹 서버가 클라이언트에 콘텐츠를 전달하려면 요청 메시지의 URI에 대응하는 알맞은 콘텐츠나 콘텐츠 생성기를 웹 서버에서 찾아서 그 콘텐츠의 원천을 식별해야 한다.

이 식별 과정에서 여러 방식의 리소스 매핑이 있지만 가장 단순한 형태는 URI를 파일 시스템의 파일 이름처럼 다루는 방식이다. 일반적으로 웹 서버 파일 시스템의 특별한 디렉토리를 예약해두는데, document root(docroot)라고 한다.

위는 아파치의 설정인데, 위와 같이 documentRoot가 설정되어 있음을 볼 수 있다. 해당 경로부터 뒤에 URI를 붙여 경로를 지정하고 해당 경로에 있는 리소스를 가져와서 보내준다.

만약 가상 호스팅 웹 서버라면 각 호스트마다 분리된 문서 루트를 줌으로써 한 웹서버에서 여러 개의 웹 사이트를 호스팅하는 방법도 있다.

이러한 docRoot는 사용자들이 한 대의 웹 서버에서 각자의 개인 웹 사이트를 만들 수 있도록 해준다. URI에 사용자의 개인 문서 루트를 가리키게 되면 각 사용자별로 다른 root를 사용할 수 있다.

server {
    listen 80;
    server_name user1.example.com;
    root /home/user1/public_html;
}
 
server {
    listen 80;
    server_name user2.example.com;
    root /home/user2/public_html;
}
 

위는 nginx의 설정인데, 이처럼 사용자 별로 별도의 docRoot를 사용할 수 있다는 의미이다.

아무튼 이렇게 이런 경로의 형식으로 접근할 수 있는데, 만약 해당 경로가 파일이 아니라 디렉토리라면 어떻게 될까? 이에 대해서는 웹 서버가 낼 행동에 대해 설정할 수 있다.

• 에러 반환
• 색인 파일 반환
• 디렉터리의 내용을 담은 HTML 페이지 반환

대부분의 웹 서버는 URL에 대응되는 디렉터리 안에서 Index.html 의 파일을 찾기 때문에 해당 파일을 가지고 있다면 해당 파일의 콘텐츠를 반환한다. 이렇게 해당 경로에 접근했을 때 기본적으로 찾는 파일을 DirectoryIndex라고 하며, 이를 따로 우선순위 별로 설정해놓아 나열된 파일 중 하나를 반환할 수 있도록 할 수도 있다. 만약 이런 색인 파일이(index.html)이 없거나 디렉터리 색인 기능도 없다면 파일들을 보여주는 HTML 파일을 반환하는 경우도 있는데, 이 경우 프라이빗해야 될 파일조차 다 보이게 되므로 주의해야 한다.

위와 같은 경우는 정적인 콘텐츠에 대한 리소스 매핑 방식이다. 하지만 웹 서버는 URI를 동적 리소스에 매핑할 수도 있다. 요청에 맞게 콘텐츠를 생성하는 프로그램에 URI를 매핑하는 것이다.

그냥 애플리케이션 서버와 웹 서버를 연결한다고 생각하면 편하다.

이런 구조처럼 웹 서버 자체에서는 정적인 콘텐츠만 제공하는데 동적인 콘텐츠는 앱 서버와 연결되어 앱 서버에서 처리한 뒤 다시 유저에게 돌아가는 구조이다. 여기서 동적인 콘텐츠란 DB 조회나 다양한 로직 처리를 요구하는 콘텐츠를 의미한다

애플리케이션 서버는 동적 콘텐츠 생성 프로그램의 위치, 실행 방법을 알려줄 수 있어야 한다. 웹 서버는 대부분 URI의 경로명이 실행 가능한 프로그램이 위치한 디렉터리로 매핑되는 기능을 가지고 있으므로 서버가 경로명을 포함한 URI로 요청을 받으면 해당 경로에 대응하는 디렉터리에서 프로그램을 찾아 실행하려 한다. 해당 프로그램은 cgi의 확장자를 가지고 있으며 찾고 있는 경로에 있는 cgi 확장자의 모든 웹 리소스에 대해서 실행시킴으로써 서버사이드에서 동적 콘텐츠를 다룬다. 하지만 이건 옛날 방식이고, 요즘에는 다른 서버 하나를 더 두는 방식을 택한다.

그 과정이 바로 위 사진과 같다. 이 과정에서는 서블릿과 같은 서버사이드 동적 콘텐츠지원 기능의 프로그램을 실행하는 Web Container를 사용하여 실행하는 것이다. 여기에서도 Web server는 Web server와 Web Container를 합친 서버의 구조는 Web Server라고만 하기 보다는 WAS(Web Application Server)라고 한다.

그렇다면 웹 서버 자체만이 http 요청을 통해 동적인 콘텐츠를 생성하기 위해서는 client <-> Web server <-> WAS(Web Server + Web Continaer) <-> Data의 구조를 가지는 것인데, WAS에도 Web server가 붙어있기 때문에 굳이 두 개를 따로 놓지 않아도 되는 거 아닌가? 라고 생각할 수 있다. 하지만 Web server와 WAS를 구분하는 이유가 따로 있다.

1. 기능을 분리하여 서버 부하 방지
   • WAS는 DB 조회나 다양한 로직을 처리하느라 바쁘기 때문에 단순한 정적 컨텐츠는 Web Server에서 단에서 WAS까지 넘어가지 않고 빠르게 클라이언트에 제공하는 것이 좋다.
   • WAS는 기본적으로 동적 컨텐츠를 제공하기 위해 존재하는 서버이다.
   • 만약 정적 컨텐츠 요청까지 WAS가 처리한다면 정적 데이터 처리로 인해 부하가 커지게 되고, 동적 컨텐츠의 처리가 지연됨에 따라 수행 속도가 느려진다.
2. 물리적으로 분리하여 보안 강화
   • SSL에 대한 암복호화 처리에 Web Server를 사용할 수 있다.
   • 추가적으로 웹 서버는 각각의 리소스에 접근 제어를 할당할 수 있으므로 서버에 악의적인 사용자가 들어가기 전 앞단 웹 서버에서 특정 리소스에 대한 접근을 제어할 수도 있다.
3. 여러 대의 WAS를 연결 가능
   • Load Balancing을 위해서 Web Server를 사용하게 되면 보다 부하를 효율적으로 분산할 수 있는 환경을 만들 수 있다.
   • fail over(장애 극복), fail back 처리에 유리
   • 특히 대용량 웹 어플리케이션의 경우(여러 개의 서버 사용) Web Server와 WAS를 분리하여 무중단 운영을 위한 장애 극복에 쉽게 대응할 수 있다.
   • 예를 들어, 앞 단의 Web Server에서 오류가 발생한 WAS를 이용하지 못하도록 한 후 WAS를 재시작함으로써 사용자는 오류를 느끼지 못하고 이용할 수 있다.

그러므로 이렇게 Web server와 WAS를 구분한 아키텍처는 위와 같은 아키텍처를 지니게 되고, 여기서 WAS는 여러개를 더 늘릴 수 있으므로 로드 밸런싱을 할 수 있게 된다. 그렇게 되면 구조는 이와 같이 여러 대의 WAS가 하나의 Web Server에 연결되어 있는 형태로 놓이게 될 것이다. 이런 식으로 웹 서버를 구성할 수도 있다는 점을 알아두면 좋다. 서비스의 규모에 따라 로드 밸런싱을 통한 부하 분산을 나누는 방식은 계속해서 쓰는 방식이기 때문이다.

하지만 동적인 콘텐츠를 무조건 애플리케이션 서버를 통해 이용해야 하는가?라고 한다면 사실 답은 다른 방법도 있다이다.
SSI(Server-side includes)는 웹 서버에서 지원하는 기능으로, 어떤 리소스가 서버사이드 인클루드를 포함하고 있는 것으로 설정되어 있다면, 서버는 그 리소스의 콘텐츠를 클라이언트에게 보내기 전에 처리한다. 즉 웹페이지 내에서 다른 파일 내용을 읽은 다음에 삽입하는 방식이다.

이런 식으로 페이지 내에서 INCLUDE 를 통해 스크립트 파일을 넣을 수도 있는 방식도 있다.

응답 만들기

어떤 방식으로든 서버가 리소스를 식별한 뒤에는 요청 메서드로 서술되는 동작을 수행하고 응답 메시지를 반환한다. 응답 메시지에는 과 같은 요소들을 포함한다.

본문

만약 트랜잭션이 응답 본문을 생성하게 되면 해당 내용도 응답메시지와 함께 돌려보내는데, 본문이 있다면

• Content-Type 헤더
• Content-Length 헤더
• 본문 은 웬만하면 있어야 한다.

MIME 타입 결정

웹 서버는 응답 본문의 MIME 타입을 결정해야 하는 책임이 있기 때문에 여러가지 방법을 통해 MIME 타입과 리소스를 연결한다.

• mime.types
  • 파일 이름의 확장자를 사용하여 포기하는 방법
  • 각 리소스의 MIME 타입을 계산하기 위해 확장자별 MIME 타입이 담겨 있는 파일을 담한다.
  • 요런 식으로 정의된 파일을 참조하여 결정할 수 있도록 한다
• 매직 타이핑(Magic Typing)
  • 파일의 내용을 검사한 뒤 알려진 패턴에 대한 테이블에 해당하는 패턴이 있는지 찾아본다
• 유형 명시(Explicit typing)
  • 웹 서버 설정에서 미리 확장자나 내용에 상관 없이 디폴트로 넣는 MIME 타입을 넣을 수 있다.
• 유형 협상(Type Negotiation)
  • 한 리소스가 여러 종류의 문서 형식에 속하도록 설정한다
  • 사용자와의 협상 과정을 통해 사용하기 가장 좋은 형식을 설정한다.

리다이렉트

가끔 리다이렌트 시키는 응답을 반환하는 경우도 있다. 리다이렉션 응답은 주로 3XX 상태 코드로 지칭되며, Location 응답 헤더는 콘텐츠의 새로운 위치나 선호하는 위치에 대한 URI를 제공한다.

이러한 리다이렉트가 유용하게 쓰이는 경우는 몇 가지 경우가 있다

• 영구히 리소스가 옮겨진 경우
  • 301 Moved Permanently 상태 코드가 주로 사용됨
• 임시로 리소스가 옮겨진 경우
  • 303 See Other과 307 Temporary Redirect 상태 코드가 주로 사용된다
• URL 증강
  • 재작성된 URL로 리다이렉트 되는 경우
  • 새 URL을 생성하고 사용자를 이 새 URL로 리다이렉트한다.
• 부하 균형
  • 과부화된 경우 서버는 클라이언트를 좀 한산한 서버로 리다이렉트시킨다
• 친밀한 다른 서버
  • 사용자에 대한 정보를 웹 서버가 미리 가지고 있다가 해당 클라이언트의 정보를 가지고 있는 서버로 리다이렉트 시키는 경우
  • 303 See Other과 307 Temporary Redirect 상태 코드가 주로 사용된다.
• 디렉터리 이름 정규화
  • 빗금(/)이 없는 URL 등을 입력했을 때 슬래시를 추가한 URL로 리다이렉트

응답 보내기

웹 서버는 받을 때와 마찬가지로 다시 응답을 보낼 때도 여러 클라이언트에 대한 많은 커넥션을 가진 채로 특정 클라이언트에 응답을 보내는데, 이 과정에서 Content-Length 헤더가 잘못 계산됐다거나 클라이언트가 응답이 언제 끝나는지 앐후 없는 경우 커넥션이 계속 열린 상태로 있기 때문에 주의해서 계속 모니터링 해야한다.