HTTP 완벽가이드Ch5. Web Servers

웹 서버란

웹 서버란?

- HTTP요청을 처리하고 응답을 제공하는 장비, 소프트웨어

웹 서버 구현

- HTTP프로토콜 구현, TCP기반의 HTTP처리- 리소스를 관리, 웹 서버 설정 통제 확장하기 위한 기능 제공

간단한 펄 웹 서버

진짜 웹 서버가 하는 일

1. Set up connection- 클라이언트의 접속을 받아들이거나, 닫는다.

2. Receive request- HTTP요청 메시지를 네트워크로 부터 읽어들인다.

3. Process request- 요청 메시지를 해석하고 그에 따른 작업을 한다.

4. Access resource- 메시지에서 지정한 리소스에 접근한다.

진짜 웹 서버가 하는 일

5. Construct response- 헤더를 포함한 HTTP 응답 메시지를 생성

6. Send response- 응답을 클라이언트에게 돌려준다.

7. Log transaction- 로그파일에 트렌잭션 완료에 대한 기록을 남긴다.

Step1 : 클라이언트 커넥션 수락

- 새 커넥션 다루기클라이언트가 웹 서버에 TCP커넥션 요청웹 서버는 TCP커넥션에서 IP를 체크 후, 인가 기능 제공

- 클라이언트 호스트 명 식별웹 서버는 reverse DNS를 사용, 접근 제어와 로깅 기능 제공하지만 성능상의 문제로 1.3에서 기본으로 off

참조 : https://httpd.apache.org/docs/2.2/ko/misc/perf-tuning.html

- ident를 통해 클라이언트 알아보기서버가 identd서버 포트(113)으로 정보 요청, 클라이언트는 클라이언트 정보를 돌려줌.하지만 공공인터넷에서는 보안과, 트랜잭션 문제로 제한적인 사용.

Step1 : 클라이언트 커넥션 수락

요청 메세지 파싱 방법- 요청 메서드, 리소스 식별자(URI), 버전번호를 찾는다.각 값은 한 개의 스페이스로 분리, 끝은 CRLF

- 메시지 헤더들을 읽는다. 끝은 CRLF- 요청 본문이 있다면, Content-Length만큼 읽어 들인다.

Step2 : 요청 메시지 수신

커넥션 입력/출력 처리 아케텍처 고성능 웹 서버는 수천 개의 커넥션을 동시지원 웹 서버의 아키텍처에 따라 요청을 처리하는 방식도 달라짐

Step2 : 요청 메시지 수신

- 한 번에 하나씩 요청을 처리합니다.- 트랜잭션이 완료되면, 다음 트랜잭션 처리- 처리 도중에 모든 다른 커넥션이 무시 되기 때문에, 로드가 적은 서버에서 사용

단일 스레드 웹 서버

- 요청을 처리하기 위해, 여러개의 프로세스 혹은 고효율 스레드 할당.- 단일 스레드 보다 많은 커넥션을 동시에 처리 가능- 스레드/프로세스는 요청시 생성하거나, worker pool에서 사용- 많은 요청으로 인한 메모리,시스템 리소스 소비가 이어진다.그래서 스레드/프로세스 최대 생성 개수 제한을 둠

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

- 대량의 커넥션을 지원하기 위해 사용됨- 모든 커넥션을 모니터링, 커넥션에 상태가 바뀌면 해당 커넥션 처리- 스레드와, 프로세스는 유휴(idle) 상태의 커넥션에매어있지 않아도 됨.

다중 I/O서버

- 여러개의 CPU의 이점을 살리기 위해, 멀티스레딩과 다중화를 결합한 모델- 여러개의 스레드가 각각 열려있는 커넥션을 감시하고변화가 있을때 커넥션에 대한 작업을 수행

다중 멀티스레드 웹 서버

Step3 : 요청처리

- 웹 서버가 요청을 받으면, 서버는 요청으로 부터 메서드, 리소스, 헤더, 본문을

얻어서 요청을 처리한다.- 메서드에 따라, 본문필요 여부 다름- 이후 책의 나머지 챕터에서 다룸

Step4 : 리소스의 매핑과 접근

- 웹 서버는 리소스 서버- 정적 파일(HTML, JPEG, JS), 동적 컨텐츠 제공- URI에 매핑되는 리소스 식별 방법 제공

- Docroot(DocumentRoot)- VirtualHost- Directory Index

- 접근제어

DocumentRoot

URI를 웹 서버의 파일 시스템 안에 있는 파일 이름으로 사용

VirtualHost

각 사이트에 분리된 문서 루트를 주는 방법한 웹 서버에서 여러개의 웹 사이트를 호스팅 할 때

DirectoryIndex

- 웹 서버는, 파일이름이 아닌 디렉토리 URL에 대한 요청을 받을 수 있다.- 대부분의 웹 서버는 아래와 같이 처리

- 에러를 반환- 디렉터리 대신 ‘색인 파일' 반환- 디렉터리를 탐색, 내용을 담음 HTML반환

- 불필요한 파일 노출을 야기

Step5 : 응답 만들기

- 응답 메시지는 응답상태코드, 응답 헤더, 응답 본문(선택)으로 구성- 응답 본문이 있다면, 응답 메시지는 다음을 포함한다.

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

- 리다이렉션

MIME 타입 결정하기

웹 서버에게는 응답 본문의 MIME타입을 결정해야하는 책임이 있다.- Mime.types- 매직 타이핑(Magic typing)- 유형 명시(Explicit typing)- 유형 협상(Type negotiation)

Step6 : 응답 보내기

- 전송과 응답도 커넥션 관리가 핵심- nonpersistent(비지속) 커넥션

- 메세지 전송 후 커덱션을 닫기

- persistent(지속) 커넥션이라면- 서버가 Content-Length헤더를 바르게 계산하기 위해 커넥션을 유지- 클라이언트가 응답이 언제 끝나는지 알 수 없을경우 커넥션을 유지

Step7 : 로깅

- HTTP메서드- 클라이언트와 서버의 HTTP버전- 요청받은 리소스의 URL- 응답의 HTTP상태코드- 요청과 응답 메세지의 크기(모든 엔터티 본문을 포함)- 트렌젝션이 일어난 시간- Referer와 User-Agent헤더 값

일반적인 로그 포맷

209.1.32.44 - - [03/Oct/1999:14:16:00 -0400] "GET / HTTP/1.0" 200 1024http-guide.com - dg [03/Oct/1999:14:16:32 -0400] "GET / HTTP/1.0" 200 477http-guide.com - dg [03/Oct/1999:14:16:32 -0400] "GET /foo HTTP/1.0" 404 0