본문 바로가기

프로그래밍/HTTP

[HTTP 완벽 가이드] 웹 서버

웹서버

웹서버는 HTTP 프로토콜을 구현하고 웹 리소스를 관리하고 웹 서버 관리 기능을 제공

 

nginx, apache 등등이 있다.

웹서버가 하는 일

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

 

클라이언트 커넥션 수락

 

클라이언트가 이미 서버와 지속 커넥션을 가지고 있다면 이걸 사용하면 되지만,

아닌 경우엔 클라이언트는 서버에 대한 새 커넥션을 열 필요가 있다.

 

- 새 커넥션 다루기

 

클라이언트가 서버에 TCP 커넥션 요청을 하면 , 서버는 TCP 커넥션에서 IP 주소를 추출하여

IP주소를 검증 후 커넥션을 맺는다.

 

새 커넥션이 맺어지면 서버는 커넥션 목록에 새 커넥션을 추가하고 오가는 데이터를 지켜보기 위한 준비를 한다.

 

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

대부분 웹서버는 DNS 로 클라이언트의 IP 주소를 호스트 명으로 변환하도록 설정이 되어있다.

 

웹 서버는 클라이언트의 호스트명을 이용해 구체적인 접근 제어와 로깅을 위해 사용 할 수 있다.

 

호스트 명 룩업 은 시간이 많이 걸려서 웹 트랜잭션을 느리게 할 수 도 있다.

때문에 대용량 웹 서버는 호스트명 분석을 꺼두기도 한다.

  •  

 

요청 메시지 수신

서버에서는 요청 메시지를 파싱한다.

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

 

 

 

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

 

 - 요청 시작 줄에 요청 메소드, 리소스 주소, 버전 번호를 먼저 찾는다.

시작 줄은 CRLF 문자열로 끝나게 된다.

 - 메시지 헤더들을 읽고 이것도 마찬가지로 CRLF 로 끝난다.

 - 헤더의 끝을 알리는 빈 줄 (CRLF) 도 찾는다.

 - 요청 본문이 있다면 읽어들인다. (길이는 Content-length 헤더로 정의)

 

 

- 메시지 내부 표현

 

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

요청 메시지의 각 부분에 포인터와 길이를 담을 수 있고

헤더를 룩업 테이블에 저장을 해서 각 필드에 빠르게 접근 가능하다.

 

 

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

 

 

단일 스레드 웹서버

- 한번에 하나씩 요청을 처리, 트랜잭션이 완료되면 다음 커넥션 처리

- 구현은 간단하지만 처리 도중에 다른 커넥션은 무시된다.

 

멀티프로세스와 멀티스레드 웹 서버

- 여러 요청을 동시에 처리하기 위해 여러개의 프로세스를 할당한다.

- 서버에서 처리 할 수 있는 최대 스레드 수가 있다.

 

다중 I/O 서버

- 대량의 커넥션을 위해 다중 아키텍처를 채택한다.

- 커넥션 상태가 바뀌면 그 커넥션에 대한 작은 양의 처리가 수행

- 처리가 완료되면 다음을 위해 커넥션 목록으로 돌아간다.

- 스레드와 프로세스는 유휴 상태에 있는 커넥션을 기다리느라 리소스를 낭비하지 않는다.

 

다중 멀티스레드 웹 서버

- CPU 여러개의 이점을 살리기 위해 멀티 스레딩과 다중화를 결합

  •  

 

요청 처리

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

POST를 비롯한 몇몇 메서드는 요청 메시지에 엔티티 본문이 있을 것을 요구하고

그 외 메서드에서는 본문이 있어도 되지만 요구하지 않는다.

GET에서는 엔티티 본문이 있는것을 금지한다.

 

 

 

리소스의 매핑과 접근

웹 서버는 리소스 서버인데, 

서버 위에서 동작하는 리소스 생성 어플리케이션을 통해 만들어진 동적 컨텐츠도 제공한다.

 

웹 서버가 클라이언트에 컨텐츠를 제공하려면, 요청 URL 에 해당하는 컨텐츠나 생성기를 웹 서버에서 찾아야 한다.

 

- Docroot

 

웹 서버 파일 시스템의 특별한 폴더를 웹 콘텐츠를 위해 설정한다.

 

DocumentRoot 로 주소를 설정한다.

각 사이트에 그들만의 분리된 문서 루트를 줄 수 있다.

 

- 디렉토리 목록

웹 서버는 디렉토리에 해당하는 URL 을 요청했을때는 몇가지 행동을 취하도록 되어있다.

- 에러를 반환

- 디렉토리 대신 특별한 색인 파일을 반환

- 디렉토리를 탐색해서 그 내용을 담은 HTML 페이지 반환

    •  

- 동적 컨텐츠 리소스 매핑

 

웹서버는 URL을 동적 리소스에 매핑 할 수 있다.

요청에 맞는 어플리케이션에 URL을 매핑 하는 것이다.

웹 서버들 중에서 어플리케이션 서버라는건 웹 서버를 어플리케이션과 연결 하는 일 을 하는것

 

오늘날의 어플리케이션 서버는 자바 서블릿 같이 갈력하고 효과적인 서버사이드 동적 컨텐츠를 제공한다.

 

- 접근 제어

웹 서버는 각각의 리소스에 접근 제어를 할 수 있다.

 

 

응답 만들기

 

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

 

응답 엔티티

- 트랜잭션이 응답 본문을 생성하면 , 내용을 응답 메시지와 함꼐 돌려보낸다.

 

응답 본문이 있다면, 응답 메시지는 다음을 포함한다.

- MIME 타입을 서술하는 Content-Type 헤더

- 길이를 서술하는 Content-Length 헤더

- 실제 응답 본문의 내용

 

리다이렉션

필요에 따라서 요청 후 클라이언트에게 이동할 위치를 알려줄 수 있다. Location 응답 헤더 처럼

 

 

응답 보내기

비지속적 커넥션이라면 서버는 모든 메시지를 전송하고 커넥션을 닫고

지속적 커넥션이라면 서버가 Content-Length 헤더를 바르게 계산하게 주의를 필요로 한다.

 

 

로깅

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