HTTP 완벽가이드 5장 - 웹 서버가 하는 일

웹 서버는 목적에 따라 다양하지만, 기본적으로 리소스에 대한 HTTP 요청을 받아 콘텐츠를 클라이언트에게 돌려주는 일을한다.
- 간단한 일을 처리하는 작은 임베디드 서버(프린터, 가전기기, IoT 등)을 생각해보자
커넥션을 맺고, 요청을 받고, 처리(해석)하고, 리소스에 접근하고, 응답을 만들고 보낸다.

1. 커넥션 수락

: 커넥션을 지속하고 있지 않는 이상 새로운 커넥션을 만든다.

: 요청메시지를 CRLF로 구분해 요청줄, 헤더, 메시지로 파싱한다. - 몇몇 웹 서버는 그것을 key-value 자료구조에 저장

request_processes.md

request 처리방식 설명에 이만한 그림은 없는 것 같다.

단일 스레드 I/O 아키텍처: 한번에 하나씩 요청 처리. 트랜젝션 완료 시 다음 커넥션 처리(간단한 서버에서만 사용)
멀티 스레드 I/O 아키텍처: 커넥션을 받는 스레드를 늘릴 수 있다. 동적으로도 가능하고, 미리 할당해놓을 수 있다. 수만 건을 처리하는데 스레드를 다 만들어놓으면 오히려 시스템 리소스를 과소비하게 된다. 따라서 제한을 건다.
- Apache에서 사용하는 방식이 이 방식인 것 같다.
다중 I/O 아키텍처: 한 커넥션에 대해서 처리하다보면 Blocked 되는 테스크에 대해 유휴시간이 발생할텐데, 이 유휴시간동안 다른 Task를 처리한다.
- 한 커넥션에 대한 처리가 완료되면, 커넥션은 다음번의 state 변경을 기다리기 위해 커넥션 목록으로 들어가고, 스레드는 수행할 수 있는 커넥션을 빼와서 수행한다.
- NginX에서 사용하는 방식. 비동기적 처리
다중, 멀티스레드 I/O 아키텍처: 동작만 잘 되도록 구성한다면 가장 이상적인 방법 일 것으로 보인다.

: 웹서버에서 처리할 수 있는 적절한 처리를 수행한다. 단, WAS 개입이나 다른 동적 컨텐츠에 대해서는 당연히 리소스 접근이 필요.

: 정적 리소스(HTML, CSS, JPEG)에 대한 것은 웹 서버 에서 처리, 리소스는 주로 동적 컨텐츠가 필요할 떄

:요청 URI를 파일 시스템 내의 파일 이름으로 사용하는 방식

e.g) /aaa/bbb.gif 요청이 들어오고 문서 루트가 /usr/local 라면 /usr/local/aaa/bbb.gif 파일을 반환
가상 호스팅 docroot: 한 웹 서버가 여러 웹 사이트를 호스팅하고 URI나 Host 헤더로부터 얻은 IP주소나 호스트 명을 통해 문서 루트를 식별하고 적절한 콘텐츠를 전달해 주는 것
사용자 홈 디렉터리 docroots : 사용자가 자신의 로컬에서 자신의 웹 사이트를 만들도록 하는 것

: 동적 리소스에 맵핑.

애플리케이션 서버는 백엔드 애플리케이션과 연결되는 것
e.g) 아파치는 URI의 경로명이 바이너리의 위치로 맵핑되도록 기능을 제공한다.
ScriptAlias /cgi-bin/ /usr/local/etc/httpd/cgi-programs/

웹 서버는 응답 메시지를 만든다. (상태 코드, 헤더, 본문)
응답 본문(엔티티): Content-Type(MIME), Content-Length, 본문내용
MIME type 결정
- 매치 타이핑: 웹 서버가 직접 파일 내용을 검사 (표준 확장자 없는 경우)
- 유형 명시: 항상 어떤 type을 갖도록 웹 서버에 명시
- 유형 협상: 여러 종류에 속하도록 설정. 사용자와 협상을 통해 가장 좋은 형식으로 정함
리다이렉션 : Location 응답 헤더에 새로운 위치 URI를 포함시킴
- 영구히 리소스가 옮겨진 경우(301 Moved Permanently)
- 임시로 리소스 옮겨진 경우
- URL 증강: 뚱뚱한 URL 세션 유지 용도로 URL 뒤에 유저의 상태 정보를 붙여서 리다이렉션 -> 사용자는 해당 상태(세션)를 포함해 재요청

: 커넥션 너머로 데이터를 보낼 때에 받을때와 비슷한 이슈에 직면. 커넥션 상태를 추적해야 하며, 지속 커넥션이라면 Content-Length를 고려하는 등

HTTP 완벽 가이드