5장 웹 서버

5.1 다채로운 웹 서버

• 웹 서버는 HTTP 요청을 처리하고 응답을 제공한다.

5.1.1 웹 서버 구현

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

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

• 다목적 소프퉤어 웹 서버는 네트워크에 연결된 표준 컴퓨터 시스템에서 동작한다.
• 아파치나 W3C의 직소 같은 오픈 소스 소프트웨어를 사용할 수도 있고, 마이크로소프트 같은 상용 소프트웨어를 사용할 수도 있다.
• 웹 서버 소프트웨어는 거의 모든 컴퓨터와 운영체제에서 종작한다.

5.1.3 임베디드 웹 서버

• 일반 소비자용 제품에 내장될 목적으로 만들어진 작은 웹 서버이다.

5.3 진짜 웹 서버가 하는일

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

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

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

5.4.1 새 커넥션 다루기

• 클라이언트가 웹 서버에 TCP 커넥션을 요청하면, 웹 서버는 그 커넥션을 맺고 TCP 커넥션에서 IP 주소를 추출하여 커넥션 맞은편에 어떤 클라이언트가 있는지 확인한다.
• 서버는 새 커넥션을 커넥션 목록에 추가한다.
• 악의적이라고 판단할 경우 커넥션을 닫는다.

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

• 대부분 역방향 DNS 를 사용해서 클라이언트 IP 주소를 클라이언트의 호스트 명으로 변환하도록 설정되어있다.
• 호스트 명 룩업은 트랜잭션을 느리게 할 수 있다.
• 많은 대용량 웹 서버는 호스트 명 분석을 꺼두거나 특정 콘텐츠에서만 켜 놓는다.

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

• 몇몇 웹서버는 IETF ident 프로토콜을 지원한다.
• ident 프로토콜은 서버에게 어떤 사용자 이름이 HTTP 커넥션을 초기화했는지 찾아낼 수 있게 해준다.
• 많은 클라이언트 PC 는 identd 프로토콜 데몬 소프트웨어를 실행하지 않는다.
• ident 프로토콜은 HTTP 트랜잭션을 지연시킨다.
• ident 프로토콜은 안전하지 않고, 조작하기 쉽다.
• ident 프로토콜은 가상 ip 주소를 잘 지원하지 않는다.

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

• 요청 줄을 파싱하여 요청 메서드, 지정된 리소스의 식별자 (URI), 버전 번호를 찾는다.
• 메시지 헤더를 읽는다.
• 네트워크 커넥션은 언제라도 무효화 될 수 있다.

5.5.1 메시지의 내부 표현

• 몇몇 웹 서버는 요청 메시지를 쉽게 다룰 수 있도록 내부의 자료 구조에 저장한다.
• 헤더는 속도가 빠른 룩ㄱ업 테이블에 저장되어 각 필드에 신속하게 접근할 수 있다.

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

• 고성능 웹 서버는 수천 개의 커넥션을 동시에 열 수 있도록 지원한다.
• 웹 서버들은 항상 새 요청을 주시하고 있다.

단일 스레드 웹 서버

• 한 번에 하나씩 요청을 처리한다.
• 처리 도중 다른 커넥션은 무시된다.

멀티프로세스와 멀티스레드 웹 서버

• 여러 요청을 동시에 처리하기 위해 여러개의 프로세스 혹은 고효율 스레드를 할당한다.
• 몇몇 서버는 커넥션마다 스레드/프로세스를 하나 할당한다. 그러나 리소스 소비가 심할 수 있기에 최대 갯수 제한을 거는 것이 좋다.

다중 I/O 서버

• 모든 커넥션 활동은 감시 당한다.
• 커넥션의 상태가 바뀌면 그 커넥션에 대한 작은 양의 처리가 수행된다.
• 처리가 완료되면, 열린 커넥션 목록으로 돌아간다.

다중 멀티스레드 웹 서버

• 멀티스레딩과 다중화를 결합한다.
• 여러 개의 스레드는 각각 열려있는 커넥션을 감시하고 각 커넥션에 대해 조금씩 작업을 수행한다.

5.6 단계 3: 요청 처리

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

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

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

5.7.1 Docroot

• 웹 서버는 여러 종류의 리소스 맵핑을 지원한다.
• 가장 단순한 형태는 요청 URI를 웹 서버의 파일 시스템 안에 있는 파일 이름으로 사용하는 것이다.

가상 호스팅된 docroot

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

사용자 홈 디렉터리 docroots

• 사용자들이 한 대의 웹 서버에서 각자의 개인 웹사이트를 만들 수 있도록 해주는 것이다.
• URI는 그 사용자의 개인 문서 루트를 가리킨다.

5.7.2 디렉터리 목록

• 웹 서버는 디렉터리를 가리키는, 디렉터리 URL에 대한 요청을 받을 수 있다.
• 대부분 웹 서버는 디렉터리 안 Index.html 을 찾는다.

5.7.3 동적 콘텐츠 리소스 맵핑

• 웹 서버는 URI를 동적 리소스에 맵핑할 수 있다.
• 즉 요청에 맞게 콘텐츠를 생성하는 프로그램에 URI를 맵핑하는 것이다.
• 웹 서버들 중 애플리케이션 서버라고 불리는 것들은 웹 서버를 복잡한 백엔드 애플리케이션과 연결하는 일을 한다.
  • 어떤 리소스가 동적 리소스라면, 애플케이션 서버는 그에 대한 동적 콘텐츠 생성 프로그램이 어디에 있는지, 어떻게 그 프로그램을 실행하는지 알려줄 수 있어야 한다.

5.7.4 서버사이드 인클루드

• 서버는 그 리소스의 컨텐츠를 클라이언트에게 보내기 전에 처리한다.
• 서버는 컨텐츠에 변수 이름이나 내장된 스크립트가 될 수 있는 어떤 특별한 패턴이 있는지 검사를 받는다.

5.7.5 접근 제어

• 웹 서버는 또한 각각의 리소스에 접근 제어를 할당할 수 있다.
• 접근 제어되는 리소스에 대한 요청이 도착했을 때 웹 서버는 클라이언트의 IP 주소에 근거하여 접근을 제어할 수 있고, 혹은 리소스에 접근하기 위한 비밀번호를 물어볼 수 있다.

5.8 단계 5: 응답 만들기

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

5.8.1 응답 엔터티

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

5.8.2 MIME 타입 결정하기

mime.types

• 파일 이름의 확장자를 사용할 수 있다.
• 확장자별 MIME 타입이 담겨 있는 파일을 탐색한다.
• 확장자 기반 타입 연계가 가장 흔한 방법이다.

매직 타이핑

• 파일의 MIME 타입을 알아내기 위해 파일의 내용을 검사해서 알려진 패턴에 대한 테이블에 해당하는 패턴이 있는지 찾아볼 수 있다.
• 파일이 표준 확장자 없이 이름 지어진 경우에는 특히 편리하다.

유형 명시

• 파일 확장자나 내용에 상관없이 어떤 MIME타입을 갖도록 웹 서버를 설정할 수 있다.

유형 협상

• 어떤 웹 서버는 한 리소스가 여러 종류의 문서 형식에 속하도록 설정할 수 있다.
• 웹 서버가 사용자와의 협상 과정을 통해 사용하기 가장 좋은 형식을 판별할 것인지의 여부도 설정할 수 있다.

5.8.3 리다이렉션

• 응답은 3XX 상태코드이다.
• Location 응답 헤더는 콘텐츠의 새로운 혹은 선호하는 위치에 대한 URI를 포함한다.

영구히 리소스가 옮겨진 경우

• 새 URL 이 부여되어 새로운 위치로 옮겨졌거나 이름이 바뀌었을 수 있다.
• 웹 서버는 클라이언트에게 리소스의 이름이 바뀌었으므로, 클라이언트는 북마크를 갱신하거나 할 수 있다고 말해줄 수 있다.
• 301 Moved Permanently

임시로 리소스 옮겨진 경우

• 303 See other / 307 Temporary Redirect

URL 증강

• 종종 문맥 정보를 포함시키기 위해 재작성된 URL로 리다이렉트 한다.
• 303 See other / 307 Temporary Redirect

부하 균형

• 과부하되었다면 303 See other / 307 Temporary Redirect

친밀한 다른 서버

• 클라이언트에 대한 정보를 갖고 있는 다른 서버로 리다이렉트
• 303 See other / 307 Temporary Redirect

디렉터리 이름 정규화

• 빗금을 빠뜨리면 슬래시를 추가한 URI 로 리다이렉트 한다.

5.9 단계 6: 응답 보내기

• 서버는 커넥션 상태를 추적해야 하며 지속적인 커넥션은 특별히 주의해야 한다.
• 지속적인 커넥션이라면 서버가 Content-Length 헤더를 바르게 계산하기 위해 특별한 주의를 필요로 하는 경우나, 클라이언트가 응답이 언제 끝나지 알 수 없는 경우에 커넥션은 열린 상태를 유지한다.

5.10 단계 7: 로깅

• 트랜잭션이 완료되면 로그파일에 기록한다.