5. 웹서버

1. 다채로운 웹 서버

`웹 서버`라는 용어는 웹서버 소프트웨어와 웹페이지 제공에 특화된 장비 양쪽 모두를 가리킨다.

웹 서버는 기능, 크기 형태가 다양하다.

1. 10줄 짜리 조그마한 펄 스크립트 웹서버
2. 50Mb짜리 안전한 상용 엔진
3. 작은 기판 위의 서버

크기와 기능은 달라도, 모든 웹 서버는 리소스에 대한 HTTP 요청을 받아서 콘텐츠를 클라이언트에게 돌려준다.

 

 

1. 웹 서버 구현

• 웹 서버는 HTTP 및 그와 관련된 TCP 처리를 구현한 것이다.
• 리소스를 관리하고 웹 서버를 설정, 통제, 확장하기 위한 관리 기능을 제공
• TCP 커넥션 관리에 대한 책임을 운영체제와 나눠 갖는다.
  • 운영체제 : 컴퓨터 시스템의 하드웨어를 관리, TCP/IP 네트워크 지원, 파일 시스템, 연산 활동을 제어하기 위한 프로세스 관리

 

웹 서버는 여러가지 형태가 가능하다

• 다목적 소프트웨어웹 서버를 표준 컴퓨터 시스템에 설치하고 실행할 수 있다.
• 전자기기 안에 몇 개의 컴퓨터 칩만으로 구현된 웹 서버를 내장시켜 완전한 관리 콘솔로 제공

 

 

2. 다목적 소프트웨어 웹 서버

• 웹 서버 소프트웨어는 거의 모든 컴퓨터와 운영체제에서 동작한다.

2022년 기준 웹 서버 시장 점유율

1. Apache(40.18%)
2. Nginx(27.66)
3. IIS(11.06%)

출처 : https://ko.hostadvice.com/marketshare/server/

2022 글로벌 웹 서버 시장 점유율 | HostAdvice

 

 

3. 임베디드 웹 서버

임베디드 웹 서버 : 일반 소비자용 제품에 내장될 목적으로 만들어진 작은 웹 서버

• 사용자가 그들의 일반 소비자용 기기를 간편한 웹 브라우저 인터페이스로 관리할 수 있게 해 준다

 

 

 

2. 간단한 펄 웹 서버

• HTTP/1.1 기능들을 지원하려면, 풍부한 리소스 지원, 가상 호스팅, 접근 제어, 로깅, 설정, 모니터링 등등 각종 기능들이 필요하다.
• 최소한으로 기능하는 HTTP 서버라면 30중 이하의 펄(Perl) 코드로도 만들 수 있다.(ex : type-o-serve)

 

 

 

3. 진짜 웹 서버가 하는 일

1. 커넥션을 맺는다.
2. 요청을 받는다.
3. 요청을 처리한다.
4. 리소스에 접근한다.
5. 응답을 만든다.
6. 응답을 보낸다.
7. 트랜잭션을 로그로 남긴다.

 

 

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

1. 새 커넥션 다루기

• 웹 서버는 클라이언트가 TCP 커넥션을 요청하면 커넥션을 맺고 TCP 커넥션에서 IP 주소를 추출하여 어떤 클라이언트가 있는지 확인한다.
• (커넥션이 맺아지면) 서버는 새 커넥션을 커넥션 목록에 추가하고 커넥션에서 오가는 데이터를 지켜보기 위한 준비를 한다.
• 웹 서버는 어떤 커넥션이든 마음대로 거절하거나 즉시 닫을 수 있다.

 

2. 클라이언트 호스트명 식별

• 대부분의 웹 서버는 '역방향 DNS(reverse DNS)'를 사용해서 클라이언트의 IP주소를 클라이언트의 호스트 명으로 변환하도록 설정되어 있다.
• 웹 서버는 클라이언트 호스트 명을 구체적인 접근 제어와 로깅을 위해 사용할 수 있다.
  • 호스트명 룩업은 꽤 시간이 많이 걸릴 수 있어 웹 트랜잭션을 느려지게 할 수 있다!
  • 많은 대용량 웹 서버는 호스트명 분석을 꺼두거나 특정 콘텐츠에 대해서만 켜놓는다.

 

3. ident를 통해 클라이언트 사용자 알아내기

ident 프로토콜 : 서버에게 어떤 사용자 이름이 HTTP 커넥션을 초기화했는지 알아낼 수 있게 해주는 프로토콜

• 위 정보가 웹 서버 로깅에서 유용하기 때문에 일반 로그 포맷의 두 번째 필드는 각 HTTP 요청의 ident 사용자 이름을 가지고 있다.
• ident는 조직 내부에서는 잘 사용할 수 있지만 공공 인터넷에서는 잘 동작하지 않음
  • 많은 클라이언트 PC는 ident 신원확인 프로토콜 데몬 소프트웨어를 실행하지 않는다.
  • ident 프로토콜은 HTTP 트랜잭션을 유의미하게 지연시킨다.
  • 방화벽이 ident 트래픽이 들어오는 것을 막는 경우가 많다.
  • ident 프로토콜은 안전하지 않고 조작하기 쉽다.
  • ident 프로토콜은 가상 IP 주소를 잘 지원하지 않는다.
  • 클라이언트 사용자 이름의 노출로 인한 프라이버시 침해의 우려가 있다.

 

 

단계 2: 요청 메시지 수신

• 커넥션에 데이터가 도착하면, 웹 서버는 네트워크 커넥션에서 그 데이터를 읽어 들이고 파싱 하여 요청 메시지를 구성
• 요청 메시지 파싱
  1. 요청줄을 파싱하여 요청 메서드, 지정된 리소스의 식별자(URI), 버전 번호를 찾는다. 각 값은 스페이스 한 개로 분리되어 있고, 요청줄은 캐리지 리턴 줄 바꿈(CRLF) 문자열로 끝난다.
  2. 메시지 헤더들을 읽는다. 각 메시지 헤더는 CRLF로 끝난다.
  3. 헤더의 끝을 의미하는 CRLF로 끝나는 빈 줄을 찾아낸다.(존재한다면)
  4. 요청 본문이 있다면, 읽어 들인다.(길이는 Content-Length 헤더로 정의)
• 웹 서버는 입력 데이터를 네트워크로부터 불규칙적으로 받기 때문에 웹 서버는 파싱해서 이해하는 것이 가능한 수준의 분량을 확보할 때까지 메시지 일부분을 메모리에 임시로 저장해둘 필요가 있다.

 

1. 메시지의 내부 표현

몇몇 웹 서버는 요청 메시지를 쉽게 다룰 수 있도록 내부의 자료 구조에 저장

 

2. 커넥션 입력/출력 처리 아키텍처

웹 서버 아키텍처에 따라 요청을 처리하는 방식이 달라진다.

 

1. 단일 스레드 웹 서버(a)

• 한 번에 하나씩 요청을 처리
• 구현하기는 간단하지만 처리 도중에 모든 다른 커넥션은 무시
• 심각한 성능 문제를 만들어내므로 로드가 적은 서버나 type-o-serve 같은 진단도구에서만 적당

 

2. 멀티 프로세스와 멀티스레드 웹 서버(b)

• 여러 요청을 동시에 처리하기 위해 여러 개의 프로세스 혹은 고효율 스레드를 할당
• 스레드/프로세스는 필요할 대마다 만들어질 수도 있고 미리 만들어질 수도 있다.
• 매 커넥션 마다 스레드/프로세스 하나씩 할당하므로 수많은 커넥션이 있을 때 메모리나 시스템 리소스에 낭비가 생긴다.
• 많은 멀티스레드 웹 서비스가 스레드/프로세스의 최대 개수의 제한을 건다.

 

3. 다중 I/O 서버(c)

• 모든 커넥션은 동시에 그 활동을 감시당한다.
• 커넥션의 상태가 바뀌면, 그 커넥션에 대해 작은 양의 처리가 수행
• 그 처리가 완료되면, 다음번 상태 변경을 위해 열린 커넥션 목록으로 돌아간다.
• 어떤 커넥션에 대해 작업을 수행하는 것은 그 커넥션에 실제로 해야 할 일이 있을 때뿐이므로 유휴 상태의 커넥션을 기다리느라 리소스를 낭비하지 않는다.

 

4. 다중 멀티스레드 웹 서버(d)

• 여러 개의 스레드는 각각 열려있는 커넥션을 감시하고 각 커넥션에 대해 조금씩 작업을 수행

 

 

단계 3: 요청 처리

• 웹 서버가 요청을 받으면, 서버는 요청으로부터 메서드, 리소스, 헤더, 본문을 얻어내어 처리한다.
• POST를 비롯한 몇몇 메서드는 요청 메시지에 엔터티 본문이 있을 것을 요구
• 그 외 OPTIONS를 비롯한 다수의 메서드는 요청에 본문이 있는 것을 허용하되 요구하지는 않는다.
• 많지는 않지만 GET과 같이 요청 메시지에 엔터티 본문이 있는 것을 금지하는 메서드도 있다.

 

 

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

• 웹 서버는 리소스 서버이므로 HTML 페이지나 JPEG 이미지 같은 미리 만들어진 콘텐츠를 제공하며, 마찬가지로 서버 위에서 동작하는 리소스 생성 애플리케이션을 통해 만들어진 동적 콘텐츠도 제공한다.
• 클라이언트에 콘텐츠를 전달하려면, 그전에 요청 메시지의 URI에 대응하는 알맞은 콘텐츠나 콘텐츠 생성기를 웹 서버에서 찾아서 콘텐츠의 원천을 식별해야 한다.

1. Docroot

Docroot : 웹 서버 파일 시스템의  특별한 폴더를 웹 콘텐츠를 위해 예약해둔 폴더(기준 폴더)

 

 

가상 호스팅 된 docroot

• 가상 호스팅된 웹 서버들 만의 분리된 문서 루트를 주는 방법으로 한 웹 서버에서 여러 개의 웹 사이트를 호스팅
• 가상 호스팅 웹 서버는 URI나 Host 헤더에서 얻은 IP 주소나 호스트 명을 이용해 올바른 문서 루트를 식별
• 이 방법으로 하나의 웹 서버 위에서 두 개의 사이트가 완전히 분리된 콘텐츠를 갖고 호스팅 되도록 할 수 있음

 

사용자 홈 디렉터리 docroots

•  사용자들이 한 대의 웹 서버에서 각자의 개인 웹 사이트를 만들 수 있도록 해주는 것
• 보통 빗금(/)과 물결표(~) 다음에 사용자 이름이 오는 것으로 시작하는 URI는 그 사용자의 개인 문서 루트를 가리킨다.

 

2. 디렉터리 목록

웹 서버는, 경로가 파일이 아닌 디렉터리를 가리키는 디렉터리 URL에 대한 요청을 받을 수 있다. 대부분의 웹 서버는 클라이언트가 디렉터리 URL을 요청했을 때 다음과 같이 몇 가지 다른 행동을 취하도록 설정할 수 있다.

1. 에러를 반환
2. 디렉터리 대신 특별한 '색인 파일'을 반환
3. 디렉터리를 탐색해서 그 내용을 담은 HTML 페이지를 반환

 

3. 동적 콘텐츠 리소스 매핑

• 요청에 맞게 콘텐츠를 생성하는 프로그램에 URI를 매핑
• 애플리케이션 서버는 백엔드 애플리케이션과 연결하는 역할을 하는데 어떤 리소스가 동적 리소스라면, 애플리케이션 서버는 그에 대한 동적 콘텐츠 생성 프로그램이 어디에 있는지 알려줄 수 있어야 한다.

 

4. 서버사이드 인클루드(Server-Side Includes, SSI)

서버사이드 인클루드 : 웹 페이지 내에서 다른 리소스의 내용을 읽어서 삽입하는 방법

• 많은 웹 서버가 서버사이드 인클루드도 포함.
• 어떤 리소스가 서버사이드 인클루드를 포함하고 있는 것으로 설정되어 있다면 서버는 그 리소스의 콘텐츠를 클라이언트에게 보내기 전에 처리.

 

5. 접근 제어

• 웹 서버는 각각의 리소스에 접근 제어를 할당할 수 있다.

 

 

 

단계 5: 응답 만들기

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

 

1. 응답 엔터티

트랜잭션이 응답 본문을 생성한다면, 그 내용을 응답 메시지와 함께 돌려보낸다. 만약 본문이 있다면, 응답 메시지는 다음을 포함한다.

• 응답 본문의 MIME 타입을 서술하는 Content-Type 헤더
• 응답 본문의 길이를 서술하는 Content-Length 헤더
• 실제 응답 본문의 내용

 

2. MIME 타입 결정하기

• mome.types
  • MIME 타입을 나타내기 위해 파일 이름의 확장자를 사용할 수 있다.
  • 각 리소스의 MIME 타입을 계산하기 위해 확장자 별 MIME타입이 담겨있는 파일을 탐색
• 매직 타이핑(Magic typing)
  • 파일의 내용을 검사해서 알려진 패턴에 대한 테이블에 해당하는 패턴이 있는지 찾는다.
  • 느리긴 하지만 파일이 표준 확장자 없이 이름 지어진 경우에는 편리
• 유형 명시(Explicit typing)
  • 파일 확장자나 내용에 상관없이 어떤 MIME 타입을 갖도록 웹서버를 설정 가능
• 유형 협상(Type negotiation)
  • 어떤 웹 서버는 한 리소스가 여러 종류의 문서 형식에 속하도록 설정할 수 있다.
  • 웹 서버가 사용자와의 협상 과정을 통해 사용하기 가장 좋은 형식을 판별할 것인지의 여부도 설정 가능
  • 웹 서버는 특정 파일이 특정 MIME 타입을 갖게끔 설정할 수도 있다.

 

 

3. 리다이렉션

웹 서버는 요청을 수행하기 위해 브라우저가 다른 곳으로 가도록 리다이렉트 할 수 있다.

 

• 영구히 리소스가 옮겨진 경우
  • 301 Moved Permanently 상태 코드로 영구히 옮겼다고 설명
• 임시로 리소스가 옮겨진 경우
  • 303 See Other와 307 Temporary Redirect 상태 코드로 설명
• URL 증강
  • 문맥 정보를 포함시키기 위해 재 작성된 URL로 리다이렉트 
  • 303 See Other와 307 Temporary Rediret 상태 코드
• 부하 균형
  • 과부하된 서버가 요청을 받았을 때 부하가 덜 걸린 서버로 리다이렉트
  • 303 See Other와 307 Temporary Rediret 상태 코드
• 친밀한 다른 서버가 있을 때
  • 웹 서버는 사용자에 대한 정보를 가지고 있는 다른 서버로 리다이렉트 시킬 수 있다.
  • 303 See Other와 307 Temporarγ Redirect 상태 코드
• 디렉터리 이름 정규화
  • 끝에 빗금(/)을 빠트렸다면, 대부분의 웹 서버는 상대 경로가 정상적으로 동작할 수 있도록 클라이언트를 슬래시를 추가한 URI로 리다이렉트

 

 

 

단계 6: 응답 보내기

• 서버는 커넥션 상태를 추적해야 한다.
• 비지속적인 커넥션이라면, 서버는 모든 메시지를 전송했을 때 자신 쪽의 커넥션을 닫는다.
• 지속적인 커넥션이라면, 열린 상태를 유지

 

 

단계 7: 로깅

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