본 내용은 "HTTP 완벽 가이드" 내용을 참고하여 기록한 정리본입니다.
웹 서버
일반적으로 웹 서버는 HTML, CSS, JS, 이미지 등 정적 파일을 제공하는 역할로 많이 알려져 있지만, 동적 콘텐츠와 애플리케이션 로직을 제공하기 위해 다른 프로세스나 내부 모듈과 연동하기도 한다.
또한 SSL/TLS 암호화 같은 보안 계층을 고려하거나, 가상 호스팅을 통해 여러 사이트를 한 서버에서 운영하는 등 부가적인 기능을 수행한다.
주요 키워드
- 커넥션 아키텍처
- docroot
- 응답 메시지 생성 방식
- 리다이렉션 방식
웹 서버의 종류
- 다목적 소프트웨어 웹 서버
- 아파치
- Nginx
- 임베디드 웹 서버
- Mongoose
- GoAhead WebServer
진짜 웹 서버가 하는 일
웹 서버는 기본적으로, 다음과 같은 7단계의 뼈대를 기반으로 동작한다.
- 클라이언트 커넥션 수락
- 요청 받기
- 요청 처리하기
- 리소스에 접근하기
- 응답 생성하기
- 응답 보내기
- 트랜잭션을 로그로 남기기
웹 서버가 단순히 정적 파일만 반환하는 것이 아니라, 실제로는 어떻게 동작하는지를 7단계로 나누어 살펴보자.
1단계: 클라이언트 커넥션 수락
하는 일
새 커넥션 다루기
- TCP 커넥션에서 IP 주소를 추출
- 클라이언트가 누군지 확인
- 새 커넥션을 커넥션 목록에 추가
- 커넥션에서 오가는 데이터를 지켜보기 위한 준비
- 커넥션을 언제든 닫을 수 있도록 준비
클라이언트 정보 식별
- 클라이언트의 호스트 명 식별
- Reverse DNS 를 통해, 클라이언트의 IP주소를 클라이언트의 호스트 명으로 변환
- 클라이언트 호스트 명을 사용
- 접근 제어
- 로깅
- hostname lookup은 매우 느린 작업
- 꺼두는게 좋음
- 혹시 다른 기능에 의해, hostname lookup이 동작하지 않도록 주의
- https://d2.naver.com/helloworld/4744401
- ident를 통해 클라이언트 사용자 알아내기
- 조직 내부에서만 잘 쓰인다.
- 공공 인터넷에서는 잘 안쓰인다.
- 이유
- identd 신원확인 프로토콜 데몬 소프트웨어가 실행되어야 한다.
- HTTP 트랜잭션이 지연된다.
- 방화벽이 ident 트래픽을 차단함
- ident 프로토콜은 안전하지 않음
- ident 프로토콜은 가상 ip주소를 잘 지원하지 않음
- 프라이버시 침해 우려
2단계: 요청 메시지 수신
하는 일
- 메시지의 내부 표현
- 메시지는 웹 서버가 다루기 쉽도록 내부 자료구조에 저장한다.
커넥션 입력/출력 처리 아키텍처의 종류
블로킹 스레드 모델
- 단일 스레드 웹 서버
- 한번에 하나의 요청을 처리
- 처리 도중에 다른 모든 커넥션은 무시
- 테스트용
- 멀티 프로세스/멀티 스레드 웹 서버
- 커넥션마다 프로세스/스레드 할당
- 여러개의 프로세스 혹은 스레드 할당
- 메모리 낭비 심함
- 스레드가 블로킹되면, 그냥 낭비되고 대기됨
논-블로킹 스레드 모델
- Multiplexed I/O 웹 서버
- 한개의 스레드가 여러개의 커넥션 할당
- 다중 멀티스레드 I/O 웹 서버
- 멀티 스레드 + 멀티플렉스 웹 서버
참고) Tomcat/Netty 와 같은 HTTP 요청 레벨 스레드 모델이 아님
- "TCP 커넥션"을 어떻게 다룰 것인가에 관한 모델
- 요즘은 Tomcat 도 커넥션 관리는 Non-Blocking 스레드 모델을 이용함
- (구) BIO Connector
- NIO Connector
3단계: 요청 처리
- 책의 다른 부분에서 다룰 예정
4단계: 리소스의 매핑과 접근
리소스 매핑
Docroot을 이용한 리소스 매핑
- 웹 서버 파일 시스템의 특별한 폴더를 웹 콘텐츠를 위해 예약해두는 것
- Document Root
- 탐색 방법
- 요청 메시지에서 URI를 가져옴
- docroot 뒤에 붙임
- 예시
- docroot: /usr/local/httpd/files 로 지정되어있다 가정
- URI: /specials/saw-blade.gif
- 웹서버의 탐색 디렉토리: /usr/local/httpd/files/specials/saw-blade.gif
- docroot를 벗어나서, 외부 파일 시스템이 노출되지 않도록 주의
- http://www.joes-hardware.com/../
- 가상 호스팅된 docroot
- 다음과 같이 가상 호스팅으로 docroot를 다르게 하고 싶을 경우
- 사용자 별로 다른 docroot 갖게 하는 방법
- 보통 /~ 로 시작하는 경로가 개인 문서 루트를 가리킴
디렉터리 목록을 이용한 리소스 매핑
- 요청한 경로가 파일이 아닌, 디렉토리를 가리키는 경우
- 처리 방식 3가지
- 에러 반환
- 디렉토리 대신, 해당 디렉토리 내 /index.html 반환
- 디렉토리를 탐색해서, 그 내용을 담은 HTML 페이지를 반환
- DirectoryIndex 설정 지시자 사용
- DirectoryIndex index.html index.htm home.html home.htm index.cgi
- 디렉토리 index 파일 자동 생성을 끌 수도 있음
- Options -Indexes
동적 콘텐츠 리소스 매핑
- CGI
- 간단한 서버사이드 애플리케이션을 실행하기 위한 인터페이스
- WAS 프레임워크를 쓰자
- MS 액티브 서버 페이지
- 자바 서블릿
서버 사이드 인클루드(SSI)
- 동적으로 HTML 페이지에 "특정 정보를 포함" 시키는 간단한 기술
- 단순한 텍스트 치환 정도만 지원
- 동적으로 복잡한 로직을 처리하긴 힘듬
접근 제어
- 12장 참고
5단계: 응답 만들기
응답 엔티티의 구성
- Content-Type 헤더
- Content-Length 헤더
- 응답 바디
MIME 타입 결정 방법
mime.types
- mime.types 테이블을 탐색해서 찾는다.
- 가장 흔한 방법이다.
매직 타이핑
- 파일의 내용을 검사
- 알려진 패턴에 대한 테이블(매직 파일)에 해당하는 패턴이 있는지 찾아봄
- 파일이 표준 확장자 없이 이름 지어진 경우에 유용
유형 명시
- 특정 파일이나 디렉터리 안의 파일들에 대하여
- 파일 확장자나 내용에 상관없이, 어떤 MIME 타입을 갖게 강제함
유형 협상
- 사용하기 가장 좋은 형식을 협상을 통해 결정
- Content Negotiation 참조
리다이렉션의 사용처
영구히 리소스가 옮겨진 경우
- 리소스가 새 URL이 부여되거나
- 새로운 위치로 옮겨졌거나
- 이름이 바뀌었을 때
- 사용 응답
- 301 Moved PErmanently
임시로 리소스가 옮겨진 경우
- 나중에 URL로 돌아올 수 있도록
- 사용 응답
- 302
- 303
- 307
URL Augmentation
- 문맥 정보를 포함시키기 위해
- 트랜잭션 간 상태를 유지시키기 위해
- URL에 추가적인 상태를 추가시켜 리다이렉션시킴
- 예시: URL 뒤에 새로운 임시 토큰을 추가한 형태로 리다이렉션
- 사용 응답
- 302
- 303
- 307
로드 밸런싱
- 부하가 덜 걸린 서버로 리다이렉션
- 사용 응답
- 302
- 303
- 307
친밀한 다른 서버가 있을 때
- 적절한 응답을 해줄 수 있는 다른 서버가 있을 때
- 사용 응답
- 302
- 303
- 307
디렉터리 이름 정규화
- 맨 뒤 "/" 빠뜨렸을 경우
- 맨 뒤에 "/" 추가해서 리다이렉션
- 상대경로가 정상적으로 동작할 수 있도록
6단계: 응답 보내기
- 커넥션 관리
- 4장 참고
7단계: 로깅
- 21장 참고
- 일반적으로 이벤트를 이용해 비동기로 기록
'CS Repo > HTTP 완벽 가이드' 카테고리의 다른 글
| 웹 캐시 (0) | 2025.04.09 |
|---|---|
| 프록시 (0) | 2025.04.08 |
| HTTP 커넥션 관리 최적화 기법 (0) | 2025.04.03 |
| HTTP에서 바라본 TCP 커넥션 관리 방식 (0) | 2025.03.27 |
| HTTP 메시지 (0) | 2025.03.25 |