[HTTP 완벽가이드] 5장 웹 서버

웹 서버

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

“웹 서버” 라는 용어는 웹 서버 소프트웨어와 웹페이지 제공에 특화된 장비(컴퓨터와 같은) 양쪽 모두를 가리킨다.

웹 서버 구현

웹 서버는 HTTP 및 그 외 관련된 TCP 처리를 구현한 것이다.

웹 서버는 HTTP 프로토콜을 구현하고, 웹 리소스를 관리하고, 웹 서버 관리 기능을 제공한다.

웹 서버는 TCP 커넥션 관리에 대한 책임을 운영체제와 나눠서 한다.

다목적 소프트웨어 웹 서버

다목적 소프트웨어 웹 서버는 네트워크에 연결된 표준 컴퓨터 시스템에서 동작한다.

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

• 다목적 소프트웨어 웹 서버를 표준 컴퓨터 시스템에 설치하고 실행 할 수 있다.
• 사용자에게 판매할 전자 기기 안에 몇개의 컴퓨터 칩 만으로 구현된 웹 서버를 내장시킬 수 있음

다목적 소프트웨어 웹 서버

다목적 소프트웨어 웹 서버는 네트워크에 연결된 표준 컴퓨터 시스템에서 동작한다.

아파치 나 W3C jigsaw 같은 오픈 소스 소프트웨어를 사용할 수 도 있고 마이크로소프트나 아이플래닛의 웹 서버 같은 상용 소프트웨어에서도 사용 할 수 있다.

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

임베디드 웹 서버

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

ex) 프린터, 가전제품

웹 서버가 하는 일

웹 서버마다 하는일이 다르고 처리하는것이 훨씬 복잡하지만 아래처럼 웹 서버가 하는 일을 간단하게 나눌 수 있음.

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

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

클라이언트가 웹 서버에 TCP 커넥션을 요청하면 웹서버는 그 커넥션을 맺고 TCP 커넥션에서 IP 주소를 추출하여 커넥션 맞은편에 어떤 클라이언트가 있는지 확인한다.

서버는 새 커넥션을 커넥션 목록에 추가하고 커넥션에서 오가는 데이터를 지켜보기 위한 준비를 한다.

웹 서버는 어떤 커넥션이든 마음대로 거절하거나 즉시 닫을 수 있다.

클라이언트 호스트 명 식별

대부분의 웹 서버는 역 방향(reverse DNS) 를 사용해서 클라이언트의 IP주소를 클라이언트의 호스트 명으로 변환하도록 설정되어 있다.

웹 서버는 클라이언트 호스트 명을 구체적인 접근 제어와 로깅을 위해 사용 할 수 있다.

호스트 명 룩업(hostname lookup)은 꽤 시간이 많이 걸려 웹 트랜잭션을 느리게 할 수 있다.

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

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

이 정보는 특히 웹 서버 로깅에서 유용하다.

ident 프로토콜은 특정 TCP 연결의 사용자를 식별하는 데 도움이되는 인터넷 프로토콜입니다.

ident는 조직 내부에서는 잘 사용할 수 있지만, 공공 인터넷에서는 아래와 이유로 잘 동작하지 않음

• 많은 클라이언트 PC는 ident 신원 확인 프로토콜 데몬 소프트웨어를 실행하지 않음
• ident 프로토콜은 HTTP 트랜잭션을 유의미하게 지연 시킨다.
• 방화벽이 ident 트래픽이 들어오는 것을 막는 경우도 있음
• ident 프로토콜은 안전하지 않고 조작하기가 쉬움
• ident 프로토콜은 가상 IP 주소를 잘 지원하지 않음
• 클라이언트 사용자 이름의 노출로 인한 프라이버시 침해의 우려가 있음

단계 2: 요청 메세지 수신

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

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

• 요청줄을 파싱하여 요청 메서드, 지정된 리소스의 식별자(URI) , HTTP 버전번호 를 찾는다.
• 메세지 헤더들을 읽는다.
• 헤더의 끝을 의미하는 CRLF로 끝나는 빈줄을 찾아낸다. (존재 한다면)
• 요청 본문이 있다면, 읽어 들인다(길이는 Content-Length 헤더로 정의함)

메세지 내부 표현

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

자료 구조는 요청 메세지의 각 조각에 대한 포인터와 길이를 담을 수 있다.

헤더는 속도가 빠른 룩업 테이블에 저장되어 필드에 신속하게 접근 할 수 있을 것 이다.

(사진)

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

웹 서버들은 항상 새 요청을 주시하고 있다.

그 이유는 요청은 언제라도 도착 할 수 있기 때문이다.

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

• 단일 스레드 웹서버

단일 스레드 웹 서버는 한번에 하나씩 요청을 처리한다.

트랜잭션이 완료되면 다음 커넥션이 처리되어 이 아키텍쳐는 구현하기는 간단하지만 처리 도중에 모든 다른 커넥션은 무시된다.

(사진)

• 단일 스레드 웹 서버

단일 스레드 웹 서버는 한번에 하나씩 요청을 처리한다.

트랜잭션이 완료되면 다음 커넥션이 처리된다.

(사진)

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

멀티프로세스와 멀티스레드 웹 서버는 여러 요청을 동시에 처리하기 위해 여러 개의 프로세스 혹은 고효율 스레드를 할당한다.

스레드/프로세스 는 필요할 때 마다 만들어질 수도 있고 미리 만들어질 수도 있다.

동시 커넥션을 처리할 때 그로 인해 만들어진 수많은 프로세스나 스레드는 너무 많은 메모리나 시스템 리소스를 소모한다.

많은 멀티스레드 웹 서비스가 스레드/프로세스 최대 개수에 제한을 건다

(사진)

• 다중 I/O서버

대량의 커넥션을 지원하기 위해, 많은 웹 서버는 다중 아키텍쳐를 채택했다.

(사진)

• 다중 멀티 스레드 웹 서버

몇몇 시스템은 자신의 컴퓨터 플랫폼에 올라와 있는 CPU 여러 개의 이점을 살리기 위해 멀티스레딩과 다중화(multiplexing)를 결합한다. 여러 개의 스레드는 각각 열려있는 커넥션을 감시하고 각 커넥션에 대해 조금씩 작업을 수행한다.

단계 3: 요청 처리

웹 서버가 요청을 받으면, 서버는 요청으로부터 메소드, 리소스, 헤더, , 본문 (없는 경우도 있음)

을 얻어내어 처리한다.

POST를 비롯한 몇몇 메소드는 요청 메세지에 엔티티 본문이 있을 것을 요구한다.

GET과 같이 요청 메세지에 엔티티 본문이 있는 것을 금지하는 메소드도 있다.

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

웹 서버는 리소스 서버다.

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

Docroot

웹 서버는 여러 종류의 매핑을 지원한다.

일반적으로 웹 서버 파일 시스템의 특별한 폴더를 웹 콘텐츠를 위해 예약 해 둔다.

(사진)

가상 호스팅 docroot

가상 호스팅 웹 서버는, 각 사이트에 그들만의 분리된 문서 루트를 주는 방법으로 한 웹 서버에서 여러 개의 웹 사이트를 호스팅 한다.

가상 호스팅 웹 서버는 URI나 Host 헤더에서 얻은 IP 주소나 호스트 명을 이용해 올바른 문서 루트를 식별한다.

(사진)

사용자 홈 디렉터리 docroots

사용자들이 한 대의 웹 서버에서 각자의 개인 웹 사이트를 만들 수 있도록 해주는 것이다.

디렉터리 목록

웹 서버는, 경로가 파일이 아닌 디렉터리를 가리키는, 디렉터리의 URL에 대한 요청을 받을 수 있다.

클라이언트가 디렉터리 URL을 요청했을 때 다음과 같이 몇 가지 다른 행동을 취하도록 설정 할 수 있다.

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

사용자가 디렉터리 URL을 요청했을 때 기본 색인 파일이 없고 디렉터리 색인 기능이 꺼져 있지 않다면, 웹 서버는 자동으로 그 디렉터리의 파일들을 크기, 변경일 및 파일에 대한 링크와 함께 열거한 HTML 파일을 반한다.

이로 인해 일반적으로 발견할 수 없는 파일도 드러나게 된다는 단점이 있다.

동적 컨텐츠 리소스 매핑

웹 서버는 URI를 동적 리소스에 매핑 할 수도 있다.

요청에 맞게 콘텐츠를 생성하는 프로그램에 URI를 매핑 하는 것이다.

접근 제어

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

단계 5: 응답 만들기

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

응답 메세지는 응답 상태코드, 응답 헤더, 응답 본문(생성이 되었다면)을 포함한다.

응답 엔티티

만약 본문이 있다면 응답 메세지는 주로 다음을 포함한다.

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

MIME 타입 결정하기

mime.type

웹 서버는 MIME 타입을 나타내기 위해 파일 이름의 확장자를 사용 할 수 있다.

(사진 5-12)

매직 타이핑(Magic typing)

아파치 웹 서비스는 각 파일의 MIME 타입을 알아내기 위해 파일의 내용을 검사해서 알려진 패턴에 대한 테이블에 해당하는 패턴이 있는지 찾아 볼 수 있다.

느리긴 하지만 파일의 표준 확장자가 없이 이름 지어진 경우에는 특히 편리하다.

유형 명시(Explicit typing)

특정 파일이나 디렉터리 안의 파일들이 파일 확장자나 내용에 상관없이 어떤 MIME타입을 갖도록 설정 할 수 있다.

유형 협상(Type negotiation)

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

리다이렉션

웹 서버는 종종 성공 메세지 대신 리다이렉션 응답을 반환한다.

리다이렉션 응답의 상태 코드는 3XX 로 지칭된다.

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

웹 서버는 클라이언트에게 리소스의 이름이 바뀌었으므로, 클라이언트는 북마크를 갱신하거나 할 수 있다고 말해 줄 수 있다.

301 Moved Pernanently 상태 코드가 이런식의 리다이렉트를 위해 사용된다.

임시로 리소스가 옮겨진 경우

만약 리소스가 임시로 옮겨지거나 이름이 변경된 경우 서버는 클라이언트를 새 위치로 리다이렉트 하기를 원한다.

303 See other , 307 Temporay Redirect 상태 코드는 이런 경우에 사용된다.

URL 증강

서버는 종종 문맥 정보를 포함 시키기 위해 재 작성된 URL로 리다이렉트한다.

303 See other , 307 Temporay Redirect 상태 코드를 사용한다.

부하 균형

만약 과부화된 서버가 요청을 받으면, 서버는 클라이언트를 좀 덜 부하가 걸린 서버로 리다이렉트 할 수 있다.

303 See other , 307 Temporay Redirect 상태 코드를 사용한다.

친밀한 다른 서버가 있을 때

서버는 클라이언트를 그 클라이언트 대한 정보를 갖고 있는 다른 서버로 리 다이렉트 할 수 있다.

303 See other , 307 Temporay Redirect 상태 코드를 사용한다.

디렉터리 이름 정규화

클라이언트가 디렉터리 이름에 대한 URI를 요청하는데 끝에 빗금(/)을 빠뜨렷다면,

대 부분의 웹 서버는 상대경로가 정상적으로 동작 할 수 있도록 클라이언트를 슬래시를 추가한 URI로 리다이렉트 한다.

단계 6: 응답 보내기

웹 서버는 받을 떄와 마찬가지로 커넥션 너머로 데이터를 보낼 때도 비슷한 이슈를 직면한다.

서버는 커넥션 상태를 추적해야 하며 지속적인 커넥션은 특별히 주의해 사용할 필요가 있다.

비 지속적인 커넥션이라면, 서버는 모든 메세지를 전송했을 때 자신쪽의 커넥션을 닫을 것이다.

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

단계 7: 로깅

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

.