[HTTP] 웹 서버

2021. 9. 25. 14:45

HTTP 아키텍처

05 웹 서버

  • 여러 종류의 소프트웨어 및 하드웨어 웹 서버에 대해 조사한다.
  • HTTP 통신을 진단해주는 간단한 웹 서버를 펄(Perl)로 작성해본다.
  • 어떻게 웹 서버가 HTTP 트랜잭션을 처리하는지 단계별로 설명한다.

 

5.1 다채로운 웹 서버

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

 

5.1.1 웹 서버 구현

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

 

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

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

 

5.1.3 임베디드 웹 서버

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

 

5.3 진짜 웹 서버가 하는 일

  • 커넥션을 맺는다
  • 요청을 받는다.
  • 요청을 처리한다.
  • 리소스에 접근한다.
  • 응답을 만든다.
  • 응답을 보낸다.
  • 트랜잭션을 로그로 남긴다.

 

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

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

5.4.1 새 커넥션 다루기

  • 클라이언트가 웹 서버에 TCP 커넥션을 요청한다.
  • 웹 서버는 그 커넥션을 맺고 TCP 커넥션에서 IP 주소를 추출한다.
  • 추출한 주소로 커넥션 맞은편에 어떤 클라이언트가 있는지 확인한다.
  • 웹 서버는 어떤 커넥션이든 마음대로 거절하거나 즉시 닫을 수 있다.

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

  • 대부분의 웹 서버는 역방향 DNS(reverse DNS)를 사용해서 클라이언트의 IP주소를 클라이언트의 호스트 명으로 변환하도록 설정되어있다.
    • 이렇게 얻은 호스트 명으로 구체적인 접근 제어와 로깅을 위해 사용할 수 있다.
  • 호스트 명 룩업(hostname lookup)은 꽤 시간이 많이 걸릴 수 있어 웹 트랜잭션을 느려지게 할 수 있다.

 

 

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

  • 커넥션에 데이터가 도착하면, 웹 서버는 네트워크 커넥션에서 그 데이터를 읽어 들이고 파싱하여 요청 메시지를 구성한다.
  • 요청 메시지를 파싱할 때, 웹 서버는 다음과 같은 일을 한다.
    • 요청줄을 파싱하여 요청 메소드, 지정된 리소스의 식별자 , 버전 번호를 찾는다.
    • 메시지 헤더들을 읽는다. 각 메시지 헤더는 CRLF로 끝난다.
    • 헤더의 끝을 의미하는 CRLF로 끝나는 빈 줄을 찾아낸다(존재 할 때만)
    • 요청 본문이 있다면, 읽어 들인다(길이는 Content-Length 헤더로 정의)

5.5.1 메시지의 내부 표현

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

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

  • 웹 서버 아키텍처에 다라 요청을 처리하는 방식도 달라진다.
  • 단일 스레드 웹 서버
    • 한 번에 하나씩 요청을 처리
    • 처리 도중에 모든 다른 커넥션은 무시됨
  • 멀티프로세스와 멀티스레드 웹 서버
    • 여러 요청을 동시에 처리하기 위해 여러개의 프로세스 혹은 고효율 스레드를 할당
    • 프로세스/스레드는 필요할 때 만들어 질수도 있고 미리 만들어질 수 도 있다.
    • 스레드, 프로세스는 머무 많은 메모리나 시스템 리소스를 소비한다.
      • 때문에 최대 개수에 제한을 건다.
      • 스레드 풀에 대해 조사하자
  • 다중 I/O 서버
    • 대량의 커넥션을 지원하기 위해, 많은 웹 서버는 다중 아키텍처를 채택했다.
    • 다중 아키텍처에서는, 모든 커넥션은 동시에 그 활동을 감시당한다.
  • 다중 멀티스레드 웹 서버
    • 여러 개의 스레드는 각각 열려있는 커넥션을 감시하고 각각 커넥션에 대해 조금씩 작업을 수행한다.

 

 

5.6 단계 3 : 요청 처리

  • 웹 서버가 요청을 받으면, 서버는 요청으로부터 메소드, 리소스, 헤더, 본문을 얻어내어 처리함
    • 본문은 없는 경우도 있음
  • 자세한 내용은 책의 후반부에서 다루게 될 예정

 

 

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

  • 웹 서버는 리소스 서버다.
  • 웹 서버가 클라이언트에 콘텐츠를 전달하려면, 그 전에 요청 메시지의 URI에 대응하는 알맞은 콘텐츠나 콘텐츠 생성기를 웹 서버에서 찾아서 그 콘텐츠의 원천을 식별해야함

5.7.1 Docroot

  • 웹 서버는 여러 종류의 리소스 매핑을 지원함
  • 하지만 리소스 매핑의 가장 단순한 형태는 요청 URI를 웹 서버의 파일 시스템 안에 있는 파일이름으로 사용하는 것이다.
  • 일반적으로 웹 서버 파일 시스템의 특별한 폴더를 웹 콘텐츠를 위해 예약 해 둔다.
    • 이 폴더는 문서 루트 혹은 docroot라고 불린다.
/specials/saw-blade.gif에 대한 요청 도착

웹서버는 /usr/local/httpd/files를 갖고있음

웹 서버는 /usr/local/httpd/files/specials/saw-blade.gif 파일 반환
  • 가상 호스팅된 docroot
    • 가상 호스팅 웹 서버는, 각 사이트에 그들만의 분리된 문서 루트를 주는 방법으로 한 웹 서버에서 여러개의 웹 사이트를 호스팅 한다.
    • URI를 구분해 docroot를 따로 잡아 리소스를 반환하는 것이다.
  • 사용자 홈 디렉토리 docroots
    • 사용자들이 한 대의 웹 서버에서 각자의 개인 웹사이트를 만듦
    • 빗금(/)과 물결표(~)에 사용자 이름을 붙여 개인 문서 루트를 가리킴

5.7.2 디렉토리 목록

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

5.7.3 동적 콘텐츠 리소스 매핑

  • 웹 서버는 요청에 맞게 콘텐츠를 생성하는 프로그램에 URI를 매핑 할 수 있다.
  • 웹 서버들 중에서 어플리케이션 서버라고 불리는 것들은 웹 서버를 복잡한 백엔드 어플리케이션과 연결하는 일을 한다.

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

  • 서버가 리소스의 콘텐츠를 클라이언트에게 보내기 전에 처리하는 것이다.
  • 서버는 콘텐츠에 변수 이름이나 내장된 스크립트가 될 수 있는 어떤 특별한 패턴이 있는지 검사를 받음
    • 특별한 패턴은 변수 값이나 실행 가능한 스크립트의 출력 값으로 치환됨
  • SSR과 CSR을 정리해보자

5.7.5 접근제어

  • 웹 서버는 각각의 리소스에 접근 제어를 할당할 수 있음
  • 12장 참고

 

 

5.8 단계 5 : 응답만들기

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

5.8.1 응답 엔티티

  • 만약 트랜잭션이 응답 본문을 생성하면 응답 메시지와 함께 돌려보낸다.
    • 응답 본문의 MIME 타입을 서술하는 Content-Type 헤더
    • 응답 본문의 길이를 서술하는 Content-Length 헤더
    • 실제 응답 본문의 내용

5.8.2 MIME 타입 결정

  • MIME 타입과 리소스를 연결하는 여러가지 방법
    • mime.types
      • 파일 이름 확장자 사용
    • 매직 타이핑(magic typing)
      • 파일을 내용을 검사해 알려진 패턴에 대한 테이블에 해당하는 패턴이 있는지 찾아봄
    • 유형 명시(Explicit typing)
      • 특정 파일이나 디렉토리 안의 파일들이 파일 확장자나 내용에 상관없이 어떤 MIME 타입을 갖도록 웹 서버 설정 가능
    • 유형 협상(Type negotiation)
      • 어떤 웹 서버는 한 리소스가 여러 종류의 문서 형식에 속하도록 설정할수 있다.

5.8.3 리다이렉션

  • 3XX 응답코드와 함께 리다이렉션 응답을 보낸다.
  • Location 응답 헤더는 콘텐츠의 새로운 혹은 선호하는 위치에 대한 URI 포함
  • 다음의 경우에 유용하다
    • 임시로 리소스가 옮겨진 경우
    • URL 증강
    • 부하 균형
      • 부하가 좀 덜 걸린 서버로 리다이렉션
    • 친밀한 다른 서버가 있을 때
    • 디렉토리 이름 정규화

 

 

5.9 단계 6 : 응답 보내기

  • 웹 서버는 받을 때와 마찬가지로 커넥션 너머로 데이터를 보낼 때도 비슷한 이슈에 직면함
  • 서버는 커넥션 상태를 추적해야 하며 지속적인 커넥션은 특별히 주의해서 다룰 필요가 있다.
    • 지속적 커넥션이라면 서버가 Content-Length 헤더를 바르게 계산하기 위해 특별한 주의를 필요한 경우나, 클라이언트가 응답이 언제 끝나는지 알 수 없는 경우에, 커넥션은 열린 상태를 유지할 것이다.

 

 

5.10 단계 7 : 로깅

  • 트랜잭션이 완료되었을 때 웹 서버는 트랜잭션이 어떻게 수행되었는지에 대한 로그를 로그파일에 기록

'CS > 네트워크' 카테고리의 다른 글

[HTTP] 캐시  (0) 2021.10.06
[HTTP] 프록시  (0) 2021.09.28
[HTTP] 커넥션 관리  (0) 2021.09.17
[HTTP] HTTP 메시지 (메소드, 상태코드, 헤더)  (0) 2021.09.12
[HTTP] URL과 리소스 정리  (0) 2021.09.05

+ Recent posts