[http 완벽 가이드] 5장 웹 서버

 

이 내용은 http 완변 가이드란 책을 읽고 정리한 내용입니다.

 

더 자세한 내용이 궁금하시면 책을 직접 읽어보시는 걸 추천합니다.

 

 

5장 웹 서버

1. 다채로운 웹 서버

• 웹 서버라는 용어는 웹 서버 소프트웨어와 웹페이지 제공에 특화된 장비 양쪽 모두를 가리킨다.
• 웹서버는 HTTP 요청을 처리하고 응답을 제공한다.

1.1 웹 서버 구현

• 웹 서버란
  • HTTP 및 그와 관련된 TCP처리를 구현
  • 웹서버는 자신이 제공하는 리소스를 관리
  • 웹서버를 설정, 통제 , 확장하기 위한 관리 기능을 제공한다.
• 웹서버는 TCP커넥션 관리에 대한 책임을 운영체제와 나눠 갖는다.
  • 운영체제는?
    • 컴퓨터 시스템의 하드웨어를 관리하고 TCP/IP 네트워크 지원
    • 웹 리소스를 유지하기위한 파일시스템
    • 현재 연산 활동을 제어하기 위한 프로세스 관리
  • 웹서버는?
    • 다목적 소프트웨어 웹 서버의 형태
    • 임베디드 웹 서버의 형태
    • 가 있다.

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

• 컴퓨터 프로그램에 설치하고 실행할 수 있는 다목적 소프트웨어인 웹서버
• 아파치나 W3C의 직소 같은 오픈 소스 소프트웨어도 있다.
• 마이크로소프트의 웹 서버 같은 상용 소프트웨어도 있다.

1.3 임베디드 웹 서버

• 임베디드 웹 서버는 일반 소비자용 제품에 내장될 목적으로 만들어진 작은 웹서버이다.

2. 간단한 펄 웹 서버

• 책에는 아주 간단한 펄로 웹서버를 구현한 예제가 있음

3. 진짜 웹 서버가 하는 일

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

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

• 클라이언트는 이미 서버에 대해 열려있는 지속적 커넥션을 갖고 있다면, 클라이언트는 요청을 보내기 위해 커넥션을 사용할 수 있다.
  • 그렇지 않으면 다시 커넥션을 연결해야함

4.1 새 커넥션 다루기

• 클라이언트가 TCP 커넥션을 맺고자 하면 서버는 맺고,
• TCP 커넥션에서 IP 주소를 추출하여 커넥션을 맺은 클라이언트가 어떤 클라이언트인지 확인한다.
• 만약 새 커넥션을 받아드리면 커넥션 목록에 추가하고 커넥션을 통해 응답을 받을 준비를 한다.
• 서버는 어떤 커넥션이든 거절하거나 즉시 닫을 수 있으며, 클라이언트의 IP나 호스트명이 인가되지 않거나 악의적이다 판달할 경유 커넥션을 직접 닫는다.
  • 다른 시원 식별 기법 또한 사용할 수 있다.

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

• 대부분의 웹서버는 클라이언트의 IP를 역방향 DNS를 통해 호스트명을 추출한다.
• 웹서버는 클라이언트의 호스트 명을 구체적인 접근 제어와 로깅을 위해 사용할 수 있다.
• 호스트명 룩업은 많은 시간이 소요될 수 있어서 대부분의 서버는 호스트명 룩업을 꺼두거나 특정 컨텐츠에서만 켜놓는다.

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

• 서버는 IETF ident 프로토콜로 클라이언트를 식별하기도 한다.
• HTTP 커넥션을 맺으면(클라이언트 포트가 4235이라 가정)
• 서버는 113포트로 ident 커넥션을 맺는다 이에 4326,80 이라는 요청을 서버는 보낸다.
• 이에 응답줄에 클라이언트는 사용자가 누구인지 보낸다.
• 하지만 ident 커넥션은 조직 내부에서는 잘 사용할 수 있지만 공공 인터넷에서는 다음을 포함한 여러 이유로 잘 작동하지 않는다.
  • 보안에 이유 트랜잭션 지연에 이유 방화벽이 ident 트래픽을 막는 등에 이유로 사용을 하지 않는다.

5. 단계 2: 요청 메시지 수신

• 커넥션에 데이터가 도착하면, 웹 서버는 네트워크 커넥션에서 그 데이터를 읽어 들이고 파싱하여 요청 메시지를 구성한다.

 

• 참고로 요청 본문이 있다면 읽지만 길이는 content-length헤더로 정의한다.
• 요청 메시지를 파싱할 때 웹서버는 입력 데이터를 네트워크로부터 불규칙적으로 받는다.
• 커넥션은 언제든지 무효화가 가능하다.
• 웹서버는 파싱해서 이해하는 것이 가능한 수준의 분량을 확보할 때까지 데이터를 네트워크로부터 읽어서 메시지 일부분을 메모리에 임시로 저장해 둘 필요가 있다.

5.1 메시지의 내부 표현

 

• 몇몇 웹 서버는 요청 메시지를 쉽게 다룰 수 있도록 내부의 자료 구조에 저장한다.
• 예) 헤더는 속도가 빠른 룩업 테이블에 저장되어 각 필드에 신속하게 접근할 수 있도록 할 수 있다.

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

• 고성능 웹서버는 수천 개의 커넥션을 동시에 열 수 있도록 지원한다.
• 웹 서버는 항상 언제라도 도착할 수 있는 새 요청을 주시해야한다.
• 웹서버는 아키텍처의 차이에 따라 요청을 처리하는 방식도 달라진다.

 

• 단일 스레드 웹서버
  • 단일 스레드 웹 서버는 한 번에 하나씩 요청을 처리
  • 트랜잭션이 완료 되면 다음 커넥션 처리
  • 성능면에서 안좋다( 이유는 커넥션 한개가 처리 될동안 다른 커넥션은 처리가 안되기 때문
• 멀티프로세스와 멀티스레드 웹서버
  • 멀티프로세스와 멀티스레드 웹서버는 여러 요청을 동시에 처리하기 위해 여러 개의 프로세스 혹은 고효율 스레드를 할당한다.
  • 몇몇 서버는 이미 만들어질 수도 있고 매 커넥션마다 스레드와 프로세스를 할당 할 수도 있다.
  • 하지만 서버가 수백 수천 심지어 수만 개의 동시 커넥션을 처리할 때 그로 인해 만들어진 수많은 프로세스나 스레드는 너무 많은 메모리나 시스템 리소스를 소비한다.
    • 그래서 많은 멀티 스레드 웹 서비스가 스레드/프로세스의 최대 개수를 제한한다.
• 다중 I/O 서버
  • 대량의 커넥션을 지원하기 위해, 많은 웹 서버는 다중 아키텍처를 채택했다.
  • 다중 아키텍처에서는, 모든 커넥션은 동시에 그 활동을 감시당한다. 커넥션의 상태가 바뀌면(예: 데이터를 사용할 수 있게 되거나 에러가 발생), 그 커넥션에 대해 작은 양의 처리가 수행된다.
  • 그 처리가 완료되면, 커넥션은 다음번 상태 변경을 위해 열린 커넥션 목록으로 돌아간다. 어떤 커넥션에 대해 작업을 수행하는 것은 그 커넥션에 실제로 해야 할 일이 있을 때 뿐이다.
  • 스레드와 프로세스는 유휴 상태의 커넥션에 매여 기다리느라 리소스를 낭비하지 않는다.
• 다중 멀티스레드 웹 서버
  • 몇몇 시스템은 자신의 컴퓨터 플랫폼에 올라와 있는 cpu 여러 개의 이점을 살리기 위해 멀티 스레딩과 다중화를 결합한다.
  • 여러 개의 스레드는 각각 열려있는 커넥션을 감시하고 각 커넥션에 대해 조금씩 작업을 수행한다.

6. 단계 3: 요청 처리

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

7. 단계 4: 리소스의 매핑과 접근

• 웹서버는 리소스 서버이다.
• 웹서버는 클라이언트 요청에 HTML, JPEG같은 이미 만들어진 파일이나 서버 위에서 동작하는 리소스 생성 애플리케이션을 통해 만들어진 동적 컨텐츠도 제공한다.
• 웹 서버가 클라이언트에 콘텐츠를 전달하기 위해 요청 메시지의 URI에 대응하는 알맞은 콘텐츠나 콘텐츠 생성기를 웹 서버에서 찾아서 그 콘텐츠의 원천을 식별해야 한다.

7.1 Docroot

• 리소스 매핑에 가장 단순한 형태로 URI 요청에 있는 리소스 위치와 동일하게 파일 이름을 사용하는 것
• 일반적으로 웹 서버는 파일 시스템의 특별한 폴더를 웹 콘텐츠를 위해 예약한다.
  • 이 폴더를 문서 루트 혹은 Docroot라고 부른다.
• 요청 메시지에 있는 URL에 리소스 위치를 Docroot와 합친 위치에 리소스를 찾는다
• 하지만 Docroot를 사용할떄는 Docroot 외의 폴더에 접근하지 못하도록 해야한다.
• 가상 호스팅된 docroot
  • 한 웹 서버는 다른 여러 개의 호스트를 가리킨다.
  • 그래서 분리된 호스트에 각각 다른 docroot를 생성해서 두개의 사이트를 완전히 다른 콘테츠를 갖고 호스팅 되도록 할 수 있다.
  •  
  • 

• 사용자 홈 디렉터리 docroots
  • docroot의 또 다른 대표적인 활용은, 사용자들이 한 대의 웹 서버에서 각자의 개인 웹 사이트를 만들게 해주는것이다.
  • 보통 빗금과 물결표 다음에 사용자 이름이 오는 것으로 시작하는 URI는 그 사용자의 개인 문서 루트를 가리킨다.

7.2 디렉터리 목록

• 웹서버는 경로가 파일이 아닌 디렉터리를 가리키는, 디렉터리 URL에 대한 요청을 받을 수 있다.
  • 디렉터리 요청을 받았을때 서버는 다음과 같은 행동을 취할 수 있다.
    1. 에러 반환
    2. 디렉터리 대신 특별한 색인 파일 반환
    3. 디렉터리를 탐색해서 그 내용을 담은 HTML페이지를 반환

 

• 대부분의 웹서버는 요청한 URL에 대응되는 디렉터리 안에서 index.html 혹은 index.htm으로 이름 붙은 파일을 찾는다. → 만약 있다면 그 파일을 반환
• 아파치 웹서버에서는 DirectoryIndex 설정 지시자를 사용해서 기본 디렉터리 파일로 사용될 파일 이름의 집합을 설정할 수 있다.
• 만약 디렉터리 URL을 요청했을 때 기본 색인 파일이 없고 디렉터리 색인 기능이 꺼져 있다면 많은 웹 서버는 자동으로 그 디렉터리의 파일들을 크기, 변경일 및 그 파일에 대한 링크와 함께 열거한 HTML 파일을 반환한다.
  • 하지만 일반적으로 발견할 수 없는 파일도 드러나게 된다는 단점이 있다.

7.3 동적 콘텐츠 리소스 매핑

• 웹 서버는 정적 콘텐츠 뿐만 아니라 동적 콘텐츠를 제공할 수 있다.
• 웹 서버는 흔히 복잡한 백앤드 애플리케이션과 연결하는 일을 한다.
• 즉 요청에 맞게 동적 콘텐츠를 생성하는 프로그램에 URI를 매핑하는것이다.
• 오늘날에 애플리케이션 서버는 자바 서블릿과 같은 한층 더 강력하고 효과적인 서버사이드 동적 콘텐츠 지원 기능을 갖고 있다.

7.4 서버사이드 인클루드(Server-Side Includes, SSI)

• 많은 웹 서버가 서버사이드 인클루드도 지원한다.
• 만약 어떤 리소스가 서버사이드 인클루드를 포함하고 있는 것으로 설정되어 있다면, 서버는 그 리소스의 콘텐츠를 클라이언트에게 보내기 전에 처리한다.

7.5 접근 제어

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

8. 단계: 5 응답 만들기

• 한번 서버가 리소스를 식별하면, 서버는 요청 메서드로 서술되는 동작을 수행한 뒤 응답 메시지를 반환한다.

8.1 응답 엔터티

• 응답 본문을 포함하는 응답 메시지라면 주로 다음을 포함한다.
  • 응답 본문의 MIME 타입을 서술하는 Content-Type 헤더
  • 응답 본문의 길이를 서술하는 Content-Length 헤더
  • 실제 응답 본문의 내용

8.2 MIME 타입 결정하기

• 웹 서버는 MIME 타입을 결정해야하는 책임이 있다.

 

• mime.types
  • 엔터티 본문의 확장자를 이용
  • 확장자별 MIME타입이 담겨 있는 파일을 탐색한다.
  • 가장 흔한 방법
• 매직 타이핑
  • 파일의 내용을 탐색함
  • 알려진 패턴에 대한 테이블(매직 파일이라 부름)에 해당하는 패턴이 있는지 찾아 볼 수 있다.
  • 표준 확장자 없이 이름 지어진 경우에 편하다. 하지만 느림
• 유형 명시
  • 특정 파일이나 디렉터리 안의 파일들이 파일 확장자나 내용에 상관없이 어떤 MIME 타입을 갖도록 웹 서버를 설정할 수 있다.
• 유형 협상
  • 어떤 웹 서버는 한 리소스가 여러 종류의 문서 형식에 속하도록 설정할 수 있다.
  • 이때 웹 서버가 사용자와의 협상 과정을 통해 사용하기 가장 좋은 형식을 판별할 것인지의 여부도 설정 가능하다.

8.3 리다이렉션

• 웹 서버는 종종 성공 메시지 대신 리다이렉션 응답을 반환한다.
• 웹 서버는 요청을 수행하기 위해 브라우저가 다른 곳으로 가도록 리다이렉트 할 수 있다.
• 응답 코드는 3XX 상태코드이고 콘텐츠의 새로운 혹은 선호하는 위치에 대한 URI를 포함한다
• 리다이렉션이 유용한 경우
  • 영구히 리소스가 옮겨진 경우
    • 리소스가 새 URL이 부여되어 새로운 위치가 부여된 경우
  • 임시로 리소스가 옮겨진 경우
  • URL 증강
    • 서버는 종종 문맥 정보를 포함시키기 위해 재 작성된 URL로 리다이렉트한다.
  • 부하 균형
    • 만약 과부하된 서버가 요청을 받으면, 서버는 클라이언트를 좀 걸 부하가 걸린 서버로 리다이렉트할 수 있다.
  • 친밀한 다른 서버가 있을 때
    • 웹 서버는 어떤 사용자에 대한 정보를 가질 수 있다.
    • 서버는 그 클라이언트에 대한 정보를 갖고 있는 다른 서버로 리다이렉트할 수 있다.
  • 디렉터리 이름 정규화
    • 클라이언트가 디렉터리 이름에 대한 URL을 요청하는데 끝에 /을 빠트렸다면,
    • 대부분의 웹 서버는 상대경로가 정상적으로 동작할 수 있도록 클라이언트를 슬래시를 추가한 URI로 리다이렉트한다.

9. 단계 6: 응답 보내기

• 웹 서버는 많은 커넥션을 가질 수 있는데 그중 일부는 아무것도 안하고 있는 상태이고, 일부는 서버로 데이터를 보내고 있으며, 또 다른 일부는 클라이언트로 돌려줄 응답 데이터를 실어 나르고 있을 것이다.
• 만약 비지속 커넥션이라면 메시지를 다보내고 끊을 것이고
• 지속 커넥션이라면 클라이언트가 응답이 언제 끝나는지 알 수 없는 경우에 커넥션은 열린상태를 유지 할 것이다.

10. 단계: 7 로깅

• 마지막으로 트랜잭션이 완료되었을 때 웹 서버는 트랜잭션이 어떻게 수행되었는지에 대한 로그를 로그파일에 기록한다. → 이는 21장에 다룬다.