2020.12.13 작성글 이전

---

5장 웹 서버

5.1 다채로운 웹 서버

웹 서버는 HTTP 요청을 처리하고 응답을 제공한다. 웹 서버는 기능, 형태, 크기가 다양하다. 기능은 달라도 모든 웹 서버는 리소스에 대한 HTTP 요청을 받아서 콘텐츠를 클라이언트에게 돌려준다.

5.1.1 웹 서버 구현

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

• 웹 서버
  • HTTP 프로토콜 구현
  • 웹 리소스 관리
  • 웹 서버 관리 기능 제공
  • TCP 커넥션 관리에 대한 책임을 운영체제와 나눠 갖는다
• 운영체제
  • 하드웨어 관리
  • TCP/IP 네트워크 지원
  • 웹 리소스 유지를 위한 파일시스템, 연산 활동을 제어하기 위한 프로세스 관리

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

• 다목적 소프트웨어 웹 서버를 컴퓨터 시스템에 설치하고 실행할 수 있다.
• 전자기기 안에 몇 개의 컴퓨터 칩만으로 구현된 웹 서버를 내장시켜서 완전한 관리 콘솔로 제공

5.1.2 다목적 소프트웨어 웹 서버

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

출처 : https://news.netcraft.com/archives/2020/10/21/october-2020-web-server-survey.html

넷크래프트의 조사는 인터넷 웹 사이트들이 어떤 웹 서버를 통해 서비스 되고 있는지 보여준다.

책은 2014년도를 기준으로 1위 마이크로소프트 2위 아파치 3위가 nginx 였다. 책에서 nginx 서버가 수년간 꾸준히 증가한다고 했는데

2020년을 기준으로 보면 nginx 서버가 1위 점유율로 올라갔다.

5.1.3 임베디드 웹 서버

일반 소비자용 제품에 내장될 목적으로 만들어진 작은 웹 서버이다. (예: 프린터, 가전제품) 사용자가 그들의 일반 소비자용 기기를 간편한 웹 브라우저 인터페이스로 관리할 수 있게 해준다.

5.3 진짜 웹 서버가 하는 일

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

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

5.4.1 새 커넥션 다루기

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

5.4.2 클라이언트 호스트 명 식별

웹 서버는 역방향 DNS(reverse DNS)를 사용해서 클라이언트의 IP 주소를 클라이언트의 호스트 명으로 변환하도록 설정되어있다. 호스트 명 룩업은 시간이 많이 걸릴 수 있어 웹 트랜젝션을 느려지게 할 수 있다.

많은 대용량 웹 서버는 호스트 명 분석을 꺼두거나 특정 콘텐츠에 대해서만 켜놓는다.

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

서버에게 어떤 사용자 이름이 HTTP 커넥션을 초기화했는지 찾아낼 수 있게 해준다. ident는 조직 내부에서는 사용할 수 있지만, 일반 공공 인터넷에서는 잘 동작하지 않는다.

• 클라이언트 PC에서 identd 프로토콜 데몬 실행 X
• 방화벽이 ident 트래픽 막음
• ident 프로토콜은 안전하지 않고 조작이 쉬움
• ident 프로토콜은 가상 IP 주소를 잘 지원하지 않음
• 사용자 이름 노출로 프라이버시 침해의 우려

5.5 단계 2: 요청 메시지 수신

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

• 요청줄을 파싱하여도 요청 메서드, 지정된 리소스의 식별자, 버전 번호를 찾는다.

  요청줄은 캐리지 리턴 줄바꿈 문자열(CRLF)로 끝난다

• 메시지 헤더들을 읽는다(각 헤더는 CRLF로 끝남)

• 헤더의 끝을 의미하는 CRLF로 끝나는 빈 줄을 찾아낸다(존재한다면)

• 요청 본문이 있다면, 읽어 들인다

5.5.1 메시지의 내부 표현

요청 메시지를 쉽게 다룰 수 있도록 내부의 자료 구조에 저장한다.

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

웹 서버들은 항상 새 요청을 주시하고 있다. 웹 서버 아키텍처의 차이에 따라 요청을 처리하는 방식도 달라진다.

• 단일 스레드 웹 서버
  • 한 번에 하나씩 요청을 처리
  • 트랜젝션이 완료되면, 다음 커넥션 처리
  • 구현은 간단하지만, 처리 도중 다른 모든 커넥션이 무시됨
  • 심각한 성능 문제 야기
• 멀티프로세스와 멀티스레드 웹 서버
  • 여러 요청을 동시에 처리하기 위해 여러개의 프로세스 or 고효율 스레드를 할당
  • 스레드/프로세스의 최대 개수에 제한이 있음 -> 수많은 스레드/프로세스는 메모리나 시스템 리소스를 소비
• 다중 I/O 서버
  • 다중 아키텍처 -> 모든 커넥션은 동시에 그 활동을 감시당함
  • 어떤 커넥션에 대해 작업을 수행하는 것은 그 커넥션에 실제로 해야 할 일이 있을 때 뿐
  • 스레드와 프로세스는 유휴 상태의 커넥션을 기다리느라 리소스를 낭비하지 않음
• 다중 멀티스레드 웹 서버
  • 멀티스레딩과 다중화를 결합
  • 여러 개의 스레드는 각각 열려있는 커넥션을 감시하고 각 커넥션에 대해 조금씩 작업을 수행

5.6 단계 3: 요청처리

웹 서버가 요청을 받으면, 서버는 요청으로부터 메서드, 리소스, 헤더, 본문(없을 수도)을 얻어내어 처리한다.

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

웹 서버는 정적 리소스 및 동적 콘텐츠도 제공한다.

5.7.1 Docroot

일반적으로 웹 서버 파일 시스템의 특별한 폴더를 웹 콘텐츠를 위해 예약 해둔다. 이 폴더는 루트 혹은 docroot로 불린다. 요청 메시지에서 URI를 가져와서 문서 루트 뒤에 붙인다.

GET /specials/saw-blade.gif HTTP/1.0
Host: www.joes-hardware.com

웹 서버의 문서 루트가 /usr/local/httpd/files를 갖고 있을 때, 웹 서버는 /usr/local/httpd/files/specials/saw-blade.gif 파일을 반환한다.

DocumentRoot /usr/local/httpd/files

httpd.conf 설정 파일에 DocumentRoot 줄을 추가하여 아파치 웹 서버의 문서 루트를 설정할 수 있다.

• 가상 호스팅된 docroot

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

가상 호스팅 웹 서버는 URI나 HOST 헤더에서 얻은 IP 주소나 호스트명을 이용해 올바른 문서 루트를 식별한다. 이 방법으로, 하나의 웹 서버 위에서 두 개의 사이트가 완전히 분리된 콘텐츠를 갖고 호스팅 되도록 할 수 있다.

아파치 웹 서버에서는, 각 가상 웹 사이트의 VirtualHost 블록이 가상 서버에 대한 DocumentRoot 지시자를 포함하도록 설정해야 한다

• 사용자 홈 디렉터리 docroots

보통 빗금과(/) 물결표(~) 다음에 사용자 이름이 오는 것으로 시작하는 URI는 그 사용자의 개인 문서 루트를 가리킨다.

5.7.2 디렉터리 목록

웹 서버는 경로가 파일이 아닌 디렉터리를 가리키는, 디렉터리 URL에 대한 요청을 받을 수 있다. 대부분의 웹 서버는 디렉터리 URL을 요청했을 때 다음과 같이 다른 행동을 취하도록 설정할 수 있다.

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

5.7.3 동적 콘텐츠 리소스 매핑

웹 서버는 URI를 동적 리소스에 매핑할 수도 있다. 웹 서버들 중에서 애플리케이션 서버라고 불리는 것들은 웹 서버를 복잡한 백엔드 애플리케이션과 연결 하는 일을 한다.

5.7.4 서버사이드 인클루드(Server-side Includes, SSI)

많은 웹 서버가 서버사이드 인클루드도 지원한다. 서버는 그 리소스의 콘텐츠를 클라이언트에게 보내기 전에 처리한다. 서버는 콘텐츠에 변수 이름이나 내장된 스크립트가 될 수 있는 어떤 특별한 패턴이 있는지 검사를 받는다.

5.7.5 접근 제어

웹 서버는 클라이언트의 IP 주소에 근거하여 접근을 제어할 수 있고 혹은 리소스에 접근하기 위한 비밀번호를 물어볼 수 있다.

5.8 단계 5: 응답 만들기

5.8.1 응답 엔터티

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

5.8.2 MIME 타입 결정하기

• mime.types 파일 이름의 확장자를 사용할 수 있다.
• 매직 타이핑 파일의 내용을 검사해서 알려진 패턴에 대한 테이블에 해당하는 패턴이 있는지 찾는다.
• 유형 명시(Explicit typing) 파일 확장자나 내용에 상관없이 어떤 MIME 타입을 갖도록 웹 서버를 설정
• 유형 협상(Type negotiation) 한 리소스가 여러 종류의 문서 형식에 속하도록 설정한다. 웹 서버가 사용자와의 협상 과정을 통해 사용하기 가장 좋은 형식을 판별할 것인지의 여부도 설정

5.8.3 리다이렉션

웹 서버는 종종 성공 메시지 대신 리다이렉션 응답을 반환한다. 리다이렉션 응답은 3XX 상태 코드로 지칭된다. Location 응답 헤더는 콘텐츠의 새로운 혹은 선호하는 위치에 대한 URI를 포함한다.

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

  301 Moved Permanently 상태 코드 사용

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

  303 See Other / 307 Temporary Redirect 상태 코드 사용

• URL 증강

  트랜젝션 간 상태를 유지하는 유용한 방법이다. 303 See Other / 307 Temporary Redirect 상태 코드 사용

• 부하 균형

  과부하된 서버가 요청 받으면, 덜 부하 걸린 서버로 리다이렉트 303 / 307

• 친밀한 다른 서버가 있을 때

  303 See Other / 307 Temporary Redirect 상태 코드 사용

• 디렉터리 이름 정규화

  클라이언트가 디렉터리 이름 요청을 할 때 요청 끝에 빗금을 빠뜨렸다면, 클라이언트를 슬래시를 추가한 URI로 리다이렉트 한다

5.9 단계 6: 응답 보내기

서버는 커넥션 상태를 추적해야 하며 지속적인 커넥션은 특별의 주의해서 다뤄야 한다.

5.10 단계 7: 로깅

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