5장 웹 서버
웹 서버는 월드 와이드 웹의 일꾼
5.1 다채로운 웹 서버
웹 서버 = 하드웨어 + 소프트웨어
모든 웹 서버는 리소스에 대한 http 요청을 받아서 콘텐츠를 클라이언트에게 돌려준다.
5.1.1 웹 서버 구현
웹 서버 = http 및 그와 관련된 TCP 처리를 구현한 것
여러가지 형태가 가능한데
sw를 hw에 설치하고 실행할 수 있다.
기기 안에 웹 서버를 내장시켜서 완전한 관리 콘솔로 제공한다.
5.3 진짜 웹 서버가 하는 일
- 커넥션을 맺는다
- 요청을 받고,
- 처리한다.
- 리소스에 접근한다.
- 응답을 만들고,
- 보낸다.
- 트랜잭션을 로그로 남긴다.
5.4 단계 1: 클라이언트 수락
만약 이미 열려있는 지속적 커넥션을 갖고 있다면, 클라이언트는 그 커넥션을 사용할 수 있다.
그렇지 않다면, 새로운 커넥션을 열 필요가 있다.
5.4.1 새 커넥션 다루기
클라이언트가 TCP 커넥션을 요청하면,
서버는 IP주소를 추출해 클라이언트를 확인한다.
만약 새 커넥션이 맺어진다면, 서버는 새 커넥션을 커넥션 목록에 추가한다.
서버는 언제든 커넥션을 거절하거나 즉시 닫을 수 있다.
5.4.2 클라이언트 호스트 명 식별
서버는 역방향 DNS를 사용해서 클라이언트의 IP주소를 호스트 명으로 변환할 수 있다. 다만 웹 트랜잭션을 느려지게 할 수 있다.
역방향 DNS = IP주소를 통해 이름을 얻어 신뢰도를 판단하는 방법. 스팸 메일 처리에 적용
5.4.3 ident를 통해 클라이언트 사용자 알아내기
ident 프로토콜 = 특정 TCP 연결 사용자 식별 프로토콜
조직 내부에서는 사용할 수 있으나, 공공인터넷에서는 잘 동작하지 않는다.
- 많은 클라이언트 PC가 ident 프로토콜을 실행하지 않음
- 트랜잭션이 느려짐
- 방화벽이 막을 수 있음
- 안전하지 않음
- 클라이언트 이름 노출 = 프라이버시 침해
결국 클라이언트를 신뢰할 수 있는가가 문제이다.
클라이언트가 고의적 혹은 실수로 ident를 잘못 보낸다면? -> 무결성이 의심
비 TCP/IP 연결 (로컬 연결)에 대해서는 ident를 지정하면
-> Peer 인증을 대신 사용한다.
Peer 인증? -> 클라이언트 운영체제 사용자 이름을 커널로부터 획득
5.5 단계 2: 요청 메세지 수신
서버는 요청을 파싱해 메세지를 구성하면서 아래와 같은 일을 수행한다.
- 요청 메서드, 리소스의 식별자, 버전정보를 찾음
- 메세지 헤더를 읽음
- 헤더의 끝(CRLF)를 찾음
- 요청 본문을 읽음(본문이 있다면)
서버는 파싱해서 이해하는 것이 가능한 수준의 분량을 확보할 때까지 메모리에임시로 저장해 둘 필요가 있다.
5.5.1 메세지의 내부 표현
몇명 웹 서버는 요청 메세지를 쉽게 다를 수 있도록 내부의 자료 구조에 저장한다.
5.5.2 커넥션 입력 / 출력 처리 아키텍처
단일 스레드 웹 서버
한 번에 하나씩 요청을 처리
구현은 간단하나 성능이 매우 안좋음
멀티 프로세스, 멀티스레드 웹 서버
여러 요청을 동시에 처리하기위해 여러 개의 프로세스, 스레드를 사용
너무 많은 자원(메모리, 시스템 리소스)를 소모하므로 최대 개수에 제한
다중 I/O 서버
대량의 커넥션을 지원하기 위해 커넥션의 활동을 감시
다중 멀티스레드 웹 서버
멀티스레딩과 다중화의 결합
5.6 단계 3: 요청처리
요청을 받은 것을 처리한다.
몇몇 메서드는 본문을 금지하거나, 요구한다.
5.7 단계 4: 리소스의 매핑과 접근
웹 서버 = 리소스 서버
미리 만들어진 콘텐츠를 제공하거나, 동적인 컨텐츠를 제공한다.
5.7.1 Docroot
특별한 폴더를 웹 콘텐츠를 위해 예약해둔 것.
서버는 파일 시스템의 docroot 이외 부분이 노출되는 일이 생기지 않도록 주의해야한다.
가상 호스팅된 docroot
한 웹 서버에서 여러개의 웹 사이트를 호스팅 하는 경우가 있다.(같은 IP -> 여러 도메인)
접근 도메인별로 DocumentRoot 설정을 달리하여 리소스 접근을 핸들링할 수 있다.
사용자 홈 디렉터리 docroots
docroot를 활용하여 사용자들이 한대의 웹 서버에서 각자의 개인 웹 사이트를 만들 수 있도록 해준다.
5.7.2 디렉터리 목록
웹 서버는 디렉터리 URL에 대한 요청을 받을 수 있고 아래와 같은 동작을 하도록 설정할 수 있다.
- 에러를 반환 (일반적)
- 색인 파일(index) 파일 반환
- 디렉터리를 탐색한 결과 html 페이지를 반환
위의 설정이 가능하며 몇몇은 보안에 문제가 있다.
5.7.3 동적 콘텐츠 리소스 매핑
URI를 동적 리소스에 매핑할 수 있다. = 요청에 맞게 콘텐츠를 생성하는 프로그램에 URI를 매핑
요청에 맞게 콘텐츠를 생성하는 프로그램 = CGI
CGI = 공용 게이트웨이 인터페이스(Common Gateway Interface)
: 웹 서버에서 사용자 프로그램을 동작시키는 인터페이스
독립적, 쉽고, 가볍고, 재사용이 쉽고, 안전하다.
다만 느리고 메모리를 많이 사용한다.
5.7.4 서버사이드 인클루드(SSI)
설정되어있다면, 서버는 그 리소스의 콘텐츠를 클라이언트에 보내기 전에 처리한다.
주로 방문자 수, 조회 수 처리에 사용.
부가적으로 서버사이드 인젝션이라는 키워드가 많이 나온다.
5.7.5 접근 제어
웹 서버는 각각의 리소스에 접근 제어를 할당할 수 있다.
5.8 단계 5: 응답 만들기
응답 메세지는 응답 상태코드, 응답 헤더, 응답 본문을 포함한다.
5.8.1 응답 엔터티
트랜잭션이 응답 본문을 생성한다면 주로 다음을 포함한다.
- Content-Type 헤더 : 응답 본문의 MIME 타입을 서술
- Content-Length 헤더 : 응답 본문의 길이 서술
- 응답 본문
5.8.2 MIME 타입 결정하기
- mime.types
: 가장 흔한 방법으로 파일 이름의 확장자를 사용한다. - 매직 타이핑
: 파일의 내용을 검사해서 결정한다. 느리지만 파일의 표준확장자가 없으면 편리하다. - 유형 명시
: 파일 확장자나 내용에 상관없이 MIME를 갖도록 설정한다. - 유형 협상
: 한 리소스가 여러 종류의 문서 형식에 속하다록 설정할 수 있다.
5.8.3 리다이렉션
서버는 요청을 수행하기 위해 브라우저가 다른 곳으로 가도록 리다이렉트 할 수 있다.
다음은 리다이렉트가 유용한 경우
- 영구히 리소스가 옯겨진 경우
: 301 - 임시로 리소스가 옮겨진 경우
: 303, 307 - URL 증강
: 문맥 정보를 포함시키기 위해, 트랜잭션간 상태를 유지하는 방법, 303, 307 - 부하 균형
: 과부화된 서버가 요청받을 시, 부하를 줄이기 위해 핸들링, 303, 307 - 친밀한 다른 서버가 있을 때
: 클라이언트의 정보를 가지고 있는 서버로, 303, 307 - 디렉터리 이름 정규화
5.9 단계 6: 응답 보내기
서버는 커넥션 상태를 추적해야 하며, 비지속적인 커넥션이라면 자신쪽의 커넥션을 다을 것이다.
지속적인 커넥션이고 응답이 언제 끝나는 지 알수 없다면 열린 상태를 유지할 것이다.
5.10 단계 7: 로깅
트랜잭션이 완료되었을 때 웹 서버는 트랜잭션이 어떻게 수행되었는지 로그에 기록한다.
