웹 서버 #

작성자 jaewon0913

5.1 다채로운 웹 서버 #

• 웹 서버는 HTTP 요청하고 처리하고 응답을 제공한다.
• 웹 서버 소프트웨어와 웹페이지 제공에 특화된 장비 양쪽 모두를 가리킨다.

5.1.1 웹 서버 구현 #

• 웹 서버는 HTTP 및 그 와 관련된 TCP 처리를 구현한 것이다.
• 웹 서버는 HTTP 프로토콜을 구현하고, 웹 리소스를 관리하고, 웹 서버 관리 기능을 제공한다.
• 웹 서버는 여러가지 형태가 가능하다.
  • 다목적 소프트웨어 웹 서버를 표준 컴퓨터 시스템에 설치하고 실행할 수 있다.
  • 종종 어떤 회사들은 사용자에게 판매할 전자기기 안에 몇 개의 컴퓨터 칩만으로 구현된 웹 서버를 내장시켜서 완전한 관리 콘솔로 제공하기도 한다.

5.1.2 다목적 소프트웨어 웹 서버 #

• 다목적 소프트웨어 웹 서버는 네트워크에 연결된 표준 컴퓨터 시스템에서 동작한다.
• 웹 서버 소프트웨어는 거의 모든 컴퓨터와 운영체제에서 동작한다.

5.1.3 임베디드 웹 서버 #

• 임베디드 웹 서버는 일반 소비자용 제품에 내장될 목적으로 만들어진 작은 웹 서버이다.
• 사용자가 가들의 일반 소비자용 기기를 간편한 웹 브라우저 인터페이스로 관리할 수 있게 한다.

5.2 간단한 펄 웹 서버 #

• 완전한 기능을 갖춘 HTTP 서버를 만들고자 한다면 50,000줄이 넘는 코드로 되어있고, 부가적인 처리 모듈들을 더 하면 훨씬 커진다.
• HTTP/1.1의 기능들을 지원하려면, 풍부한 리소스 지원, 가상 호스팅, 접근 제어, 로깅, 설정, 모니터링, 그 외 성능을 위한 기능 필요하다.

5.3 진짜 웹 서버가 하는 일 #

1. 커넥션을 맺는다.
   • 클라이언틔 접속을 받아들이거나, 원치 않은 클라이언트라면 닫는다.
2. 요청을 받는다.
   • HTTP 요청 메시지를 네트워크로부터 읽어 들인다.
3. 요청을 처리한다.
   • 요청 메시지를 해석하고 행동을 취한다.
4. 리소스에 접근한다.
   • 메시지에서 지정한 리소스에 접근한다.
5. 응답을 만든다.
   • 올바른 헤더를 포함한 HTTP 응답 메시지를 생성한다.
6. 응답을 보낸다.
   • 응답을 클라이언트에게 돌려준다.
7. 트랜잭션을 로그로 남긴다.
   • 로그파일에 트랜잭션 오나료에 대한 기록을 남긴다.
     

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

• 클라이언트가 이미 서버에 대해 열려있는 지속적 커네겻을 갖고 있다면, 클라이언트는 요청을 보내기 위해 그 커넥션을 사용할 수 있다.
• 만약 가지고 있지 않다면, 클라이언트는 서버에 대한 새 커낵션을 열어야만 한다.

5.4.1 새 커넥션 다루기 #

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

5.4.2 클라이언트 호스트 명 식별 #

• 대부분의 웹 서버는 역방향 DNS 를 사용해서 클라이언트의 IP 주소를 클라이언트의 호스트 명으로 변환화도록 설정되어 있다.
• 웹 서버는 클라이언트 호스트 명을 구체적인 접근 제어와 로깅을 위해 사용할 수 있다.
• 많은 대용량 웹 서버는 호스트 명 분석을 꺼두거나 특정 콘텐츠에 대해서만 켜놓는다.

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

• ident 프로토콜은 서버에게 어떤 사용자 이름이 HTTP 커넥션을 초기화했는지 찾아낼 수 있게 해준다.

5.5 단계 2: 요청 메시지 수신 #

• 커넥션에 데이터가 도착하면, 웹 서버는 네트워크 커넥션에서 그 데이터를 읽어 들이고 파싱하여 요청 메시지를 구성한다.
• 요청 메시지를 파싱할 때, 웹서버는 아래와 같은 일을 한다.
  1. 요청줄을 파싱하여 요청 메소드, 지정된 리소스의 식별자, 버전 번호를 찾는다.
  2. 메시지 헤더들을 읽는다.
  3. (존재시)헤더의 끝을 의미하는 CRLF로 끝나는 빈 줄을 찾아낸다.
  4. 요청 본문이 있다면, 읽어 들인다.
• 요청 메시지를 파싱할 때, 웹 서버는 입력 데이터를 네트워크로부터 불규칙적으로 받는다.
• 네트워크 커넥션은 언제라도 끊길 수 있다.

5.5.1 메시지의 내부 표현 #

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

5.5.2 커넥션 입력/출력 처리 아키텍쳐 #

• 공성능 웹 서버는 수천 개의 커넥션을 동시에 열 수 있도록 지원한다.
• 수천 개의 커넥션들은 웹 서버가 전 세계의 클라이언트들과 각각 한 개 이상의 커넥션을 통해 통신할 수 있게 한다.
• 웹 서버 아키텍처의 차이에 따라 요청을 처리하는 방식도 달라진다.

단일 스레드

• 한 번 요청에 하나씩 처리한다.
• 구현은 간단하지만 처리 도중에는 다른 모든 커넥션이 기다려야만 한다.

멀티 프로세스와 멀티 스레드

• 여러 요청을 동시 처리하기 위해 여러 개의 프로세스 혹은 고효율 스레드를 할당한다.
• 스레드/프로세스는 필요할 때마다 만들어질수도 있고, 미리 만들어 사용할 수도 있다.
• 스레드/프로세스가 너무 많아지면, 메모라니 시스 리소스를 소비하기 때문에 보통 최대 개수를 제한한다.

다중 I/O

• 다중 아키텍처에서는 모든 커넥션은 동시에 그 활동을 감시당한다.
• 어떤 커넥션의 상태가 바뀌면 그 커넥션에 대해 작은 양의 처리가 수행된다.

다중 멀티스레드

• CPU 여러 개의 이점을 살리기 위해 멀티쓰레(b)와 다중화(c)를 결합한 것이다.
• 여러 개의 쓰레드(보통 하나의 물리적 프로세스)는 각각 열려있는 커넥션을 감시하고 각 커넥션에 대해 조금씩 작업을 수행한다.

5.6 단계3: 요청 처리 #

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

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

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

5.7.1 Docroot #

• 리소스 매핑의 가장 단순한 형태는 요청 URI를 웹 서버의 파일 시스템 안에 있는 파일 이름으로 사용하는 것이다.
• 웹 서버의 특별한 폴더를 웹 콘텐츠를 통해 예약해두는데, 이 폴더를 docroot이라고 부른다.
• 웹 서버 내부 설정에서 문서 루트를 설정 가능하다.
• 대부분의 웹 서버는 루트 위의 파일을 보려고 하는 URI를 허용하지 않는다.

가상 호스팅된 docroot

• 가상 호스팅 웹 서버는 각 사이트에 그들만의 분리된 문서 루트를 주는 방법으로 하나의 웹 서버에서 여러 개의 웹 사이트를 호스팅한다.
• 웹 서버는 URI나 Host 헤더에서 얻은 IP 주소나 호스트 명을 이용해서 올바른 문서 루트를 식별한다.

사용자 홈 디렉터리 docroots

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

5.7.2 디렉터리 목록 #

• 웹 서버는 경로가 파일이 아닌 디렉토리를 가리키는 URL에 대한 요청을 받을 수 있다.
• 대부분의 웹 서버는 클라이언트가 디렉터리 URL을 요청했을 때 다음과 같은 해동을 할 수 있다.
  • 에러를 반환한다.
  • 디렉터리 대신 특별한 파일을 반환한다.
  • 디렉터리를 탐색해서 그 내용을 담은 HTML 페이지를 반환한다.

5.7.3 동적 콘텐츠 리소스 매핑 #

• 웹 서버는 URI를 동적 리소스에 매핑할 수 있다.
• 어떤 리소스가 동적 리소스라면, 어플리케이션 서버는 그에 대한 동적 콘텐츠 생성 프로그램이 어디에 있는지, 그리고 어떻게 그 프로그램을 실행하는지 알려줄 수 있어야 한다.

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

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

5.7.5 접근 제어 #

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

5.8 단계5: 응답 만들기 #

• 서버가 리소스를 식별하면, 서버는 요청 메서드로 서술되는 동작을 수행한 뒤 응답 메시지를 반환한다.
• 응답 메시지는 응답 상태 코드, 응답 헤더, 응답 본문을 포함한다.

5.8.1 응답 엔티티 #

• 만약 응답 본문이 있다면, 응답 메시지는 주로 다음을 포함한다.
  • 응답 본문의 MIME 타입을 서술하는 Content-Type 헤더
  • 응답 본문의 길이를 서술하는 Content-Length 헤더
  • 실제 응답 본문의 내용

5.8.2 MIME 타입 결정하기 #

mime.types

• 웹 서버는 MIME 타입을 나타내기 위해 파일 이름의 확장자를 사용할 수 있다.
• 웹 서버는 각 리소스의 MIME 타입을 계산하기 위해 확장자별 MIME 타입이 담겨 있는 파일을 탐색한다.

매직 타이핑(Magic Typing)

• 파일 내용을 검사해서 알려진 패턴에 대한 테이블(매직 파일)에 해당하는 패턴이 있는지 찾아보는 방식이다.
• 속도가 느리긴 하지만 파일이 표준 확장자 없이 이름 지어진 경우에 사용하면 좋다.

유형 명시(Explicit Typing)

• 파일 확장자나 내용에 관계없이 어떤 MIME 타입을 갖도록 웹 서버가 지정하는 방식이다.

유형 협상(Type Negotiation)

• 어떤 웹 서버는 한 리소스가 여러 종류의 문서 형식에 속하도록 설정할 수 있다.

5.8.3 리다이렉션 #

• 웹 서버는 종종 성공 메시지 대신 리다이렉션 응답을 반환한다.
• 웹 서버는 요청을 수행하기 위해 브라우저가 다른 곳으로 가도록 리다이렉트 할 수 있다.

5.9 단계6: 응답 보내기 #

• 웹 서버는 받을 때와 마찬가지로 커넥션 너머로 데이터를 보낼 때도 비슷한 이슈에 직면한다.
• 서버는 커넥션 상태를 추적해야 하며 지속적인 커넥션은 특별히 주의해야 한다.
• 비지속 커넥션
  • 모든 메시지를 전송 후 서버 쪽에서 커넥션을 닫는다.
• 지속 커넥션
  • 서버가 Content-Length 헤더를 바르게 계산하기 위해 특별한 주의를 필요로 하는 경우 또는 클라이언트가 응답이 언제 끝나는지 알 수 없는 경우에 커넥션을 유지한다.

5.10 단계7: 로깅 #

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