Web Server


Connection Sequence


1.     클라이언트 커넥션 수락
클라이언트에서 웹 서버로 TCP 커넥션을 요청하면, 서버는 커넥션을 맺고 여기에서 IP 주소를 추출하여 클라이언트를 확인한다. 커넥션은 커넥션 리스트에 추가되고 모니터링 된다. 서버는 언제든지 거절하거나 닫을 수 있다.

A.     클라이언트 식별
Reverse DNS
를 사용하여 클라이언트 IP를 클라이언트 호스트명으로 변환하도록 설정한다. 클라이언트 호스트 명을 구체적인 접근 제어와 로깅을 위해 사용하며, hostname lookup은 시간이 걸릴 수 있어 웹 트랜잭션이 느려질 수 있기 때문에, hostname resolution을 꺼 두거나 특정 컨텐츠에 대해서만 켜 놓는다.
아파치에서는 HostnameLookups 설정 지시자를 사용한다.

B.      ident
IETF ident
프로토콜을 지원하는 서버는 identd를 실행하는 클라이언트의 신원을 확인 가능하다. 하지만 조작이 쉽고, 이를 사용하는 클라이언트가 많지 않아 잘 동작하지 않는다. 또한 방화벽에서도 ident 트래픽을 막아 놓는다.
아파치에서는 IdentityCheck 지시어로 사용 가능하며 가용 정보가 없으면 ‘-‘으로 채운다.

2.     요청 메시지 수신
커넥션에 데이터가 도착하면, 데이터를 읽어 요청 메시지를 파싱한다. 요청 메시지 컴포넌트는 CRLF를 기준으로 구분하며, 파싱된 데이터가 어느정도 이해가 가능한 분량이 될 때까지 메모리에 임시 저장한다.

A.     단일 스레드 웹 서버
한 번에 하나의 요청을 처리하며, 완료되어야 다음 커넥션이 처리된다. 처리 도중 다른 커넥션은 무시되므로 로드가 적은 서버나 진단도구에서만 적당하다.

B.      멀티프로세스와 멀티스레드 웹 서버
여러 개의 요청을 처리하기 위해 복수의 프로세스 / 스레드를 할당한다. Worker pool 시스템으로 스레드를 미리 생성 가능하다. 프로세스나 스레드 최대 개수에는 제한을 걸어 부하를 줄여야 한다.

C.      다중 I/O 서버
대량의 커넥션 지원을 위해 사용하며, 커넥션을 다중화 한다. 많이 사용되는 아키텍처이며, 커넥션에 대해 조금씩 작업을 수행하여 리소스 낭비가 적다.

D.     다중 멀티스레드 웹 서버
멀티 스레드, 커넥션 다중화를 결합한 아키텍처이다.

3.     리소스 매핑, 접근

A.     Docroot
여러 종류의 리소스 매핑을 지원하는 웹 서버의 가장 단순한 형태는, 서버의 파일 시스템 및 파일 이름을 URI로 사용하는 것이다.
/item/sample.jpg
를 요청 받으면, 서버에 설정된 docroot를 기준으로 /usr/local/httpd/html/item/sample.jpg를 반환하는 형식이다.
httpd.conf
설정 파일에 DocumentRoot를 설정할 수 있다.

                         i.         가상 호스팅 docroot
분리된 docroot를 설정하여 한 웹 서버에서 여러 개의 사이트를 호스팅 한다. URI, Host 헤더에서 얻은 IP 주소, 호스트명 등을 이용해 식별한다.

                        ii.         사용자 홈 dir docroot
/~
사용자명/index.html (실제위치=/home/사용자/public_html) 과 같은 URI 형식으로 해당 사용자의 개인 docroot를 가리킬 수도 있다.

B.      디렉터리
디렉터리를 가리키는 URI 요청 시 다음과 같은 액션을 취할 수 있다.

                         i.         에러 반환

                        ii.         Index 파일 반환

                       iii.         디렉터리 탐색 내용을 담은 HTML 페이지 반환

대부분의 서버는 요청 URL에 대응하는 디렉터리 안에서 index.html(index.html) 파일을 찾는다.
아파치에서는 DirectoryIndex 지시자를 사용 가능하다.

C.      동적 컨텐츠 리소스 매핑
실행 가능한 경로명을 포함한 URI로 요청을 받으면 대응하는 디렉터리에서 프로그램을 찾아 실행을 시도한다. cgi, java-servlet, ASP 등이 있다.

D.     Server-Side Includes (SSI)
웹 페이지 내에서 다른 파일 내용을 읽어 삽입하는 방법. 모든 페이지에 공통적인 내용이나 코드 최적화를 위해 사용하며, 클라이언트로 응답하기 전에 처리한다.

E.      접근 제어
IP
기반으로 제어하거나, 비밀번호를 요구

4.     응답

A.     응답 엔터티
본문의 MIME 타입과 관련된 Content-Type, Content-Length 헤더와 본문을 응답 메시지에 포함 시킨다.

B.      MIME 타입 결정

                         i.         mime.types
파일 이름의 확장자 사용하여 타입 구분. 확장자 별 MIME 타입이 명시된 파일 탐색

                        ii.         magic typing
파일의 내용을 검사해서 알려진 패턴에 대한 테이블(매직 파일)에서 찾는 방법. 표준 확장자 없이 이름 지어진 경우에 사용된다.

                       iii.         Explicit typing
확장자나 내용에 상관없이 MIME 타입을 갖도록 설정

                       iv.         Type negotiation
한 리소스가 여러 종류의 형식에 속하도록 설정하는 방식. 특정 파일이 특정 타입을 가지게 하도록 설정 가능.

C.      리디렉션

                         i.         영구 이전: 301 Moved Permanently

                        ii.         임시 이전: 303 See Other, 307 Temporary Redirect

                       iii.         URL 증강: 상태 정보를 내포한 새 URL로 리디렉트하고, 트랜잭션 간 상태를 유지하는 방법.

                       iv.         부하 균형: 부하가 덜 심한 서버로 리디렉트. 303, 307

                        v.         클라이언트 정보를 가진 타 서버로 리디렉선

                       vi.         디렉터리 이름 정규화: 클라이언트 요청에서 빠진 / 문자를 서버에서 동작 가능하게 추가한 URI로 리디렉트

     5. 로깅
        트랜잭션 완료 후 수행 결과에 대해 로그파일 기록.



Virtual Host


여러 도메인을 하나의 서버에서 호스팅 하는 방법으로, 서버의 리소스(메모리, CPU )을 공유한다. 웹 서버는 기본적으로 메인 호스트가 있고 이 외의 호스트는 모두 가상 호스트이다.

l  Name based
같은 IP에서 도메인 네임이 다른 가상 호스트 운용하는 방식으로, DNS의 다수의 도메인 네임이 하나의 서버를 가리킨다.

l  IP based
가상 호스트 별로 각 IP 주소 1개씩 부여하는 방식

l  Port-based
동일한 호스트에 가상 호스트마다 포트만 다르게 지정하는 방식,

l  Default
특정 호스트에 해당 사항이 없을 때 기본적으로 응답할 호스트

l  Host Header
헤더에 가상 호스트명과 포트번호를 명시하여 사용하는 방식

 

Stabilized Web Server


서버 다운, 트래픽 폭증, 네트워크 장애/손실 등에 예방이 필요함


-       미러링 서버 팜
스위치의 IP를 이용해 서비스를 하고, 마스터 및 복제 서버에 부하를 분산하는 방식. 지역적으로 분산 복제하는 것도 가능하다.


-       HTTP 리디렉션
마스터 서버에서 요청을 받아 복제 서버로 리디렉트. 마스터 서버로 트래픽이 집중되고, 사용자 입장에서 대기 시간이 발생하며, 리디렉션 서버 이상 시, 사이트 문제로 직결된다. 따라서 다른 리디렉션과 조합하여 사용한다.


-       DNS 리디렉션
컨텐츠의 URL4개의 IP 주소를 가리킬 수 있고, DNS 서버가 클라이언트에게 전송할 주소를 선택


n  DNS 라운드 로빈
서버 팜 전체에 대한 부하 균형 유지를 위해 DNS 호스트 명 분석 기능을 사용. 서버에 대한 클라이언트의 상대적인 위치나 서버의 현재 상태를 고려하지 않음. 다중 주소를 사용하여 lookup 한 번 종료마다 주소를 순환 한다.

u  로드 밸런싱 알고리즘: 부하가 적은 서버를 우선순위에 둠

u  근접 라우팅 알고리즘: 지리적으로 분산된 서버들 중 가까운 서버로 보냄

u  결함 마스킹 알고리즘: DNS 서버에서 네트워크 헬스 체크하여 장애 우회 라우팅



HTTP 데이터 전달

1.     게이트웨이: 서로 다른 프로토콜과 애플리케이션 간 HTTP 인터페이스.
요청을 받고 응답을 보내는 포털 역할이며, 동적인 컨텐츠를 생성하거나 데이터베이스에 질의할 수 있다. 또는 CGIAPI를 통해 애플리케이션 프로그램에 연결된다.

n  프로토콜 게이트웨이: <클라이언트 프로토콜>/<서버 프로토콜>로 구분하며, 서버 측 게이트웨이는 클라이언트와 HTTP로 통신하고 반대는 서버와 HTTP로 통신한다.
브라우저에 게이트웨이를 명시하여 대리 서버(리버스 프록시)로 설정 가능하다. HTTP/FTP 게이트웨이의 경우, 브라우저는 게이트웨이로 HTTP 프로토콜로 통신한다.

ü  HTTP/*: 서버 측 웹 게이트웨이

ü  HTTP/HTTPS: 서버 측 보안 게이트웨이

ü  HTTPS/HTTP: 클라이언트 측 보안 가속 게이트웨이. SSL 가속기로, 보안 트래픽을 복호화 하여 일반 HTTP로 트래픽을 생성한다. 효율적으로 복호화 하는 암호화 하드웨어를 내장하여 내부 서버 부하를 줄여준다.

n  리소스 게이트웨이: 특정 URL에 대한 HTTP 요청에 따라 프로그램을 실행하고, 프로그램의 출력을 수집하고, HTTP 응답으로 회신한다.

ü  CGI (Common Gateway Interface): 최초의 API, 웹서버가 사용하는 표준화된 인터페이스 집합. Perl, C, shell 등 다양한 언어로 구현이 가능하며, 단순하다. 하지만 모든 요청마다 새 프로세스를 만들어야 하므로 부하가 심해졌고, 데몬으로 동작하는 Fast CGI 개발로 해결되었다.

ü  확장 API: 웹 개발자가 직접 만든 모듈을 HTTP와 연결할 수 있는 장치로, 서버 동작을 변경하거나, 처리능력을 끌어올리기 위해 사용된다. MSFrontPage Server Extension이 있다.

2.      애플리케이션 인터페이스: 서로 다른 형식의 웹 애플리케이션이 통신하는 데 사용

n  SOAP (Simple Object Access Protocol): 웹 어플리케이션이 HTTP 헤더만으로는 더 복잡한 데이터를 교환하기 힘들기 때문에 개발된 프로토콜 집합으로 HTTP 메시지에 XML 데이터를 담는 방식에 관한 표준이다.

3.     터널: HTTP 커넥션을 통해 HTTP가 아닌 트래픽 전송. 방화벽이 HTTP 만을 허락하는 경우에 사용될 수 있다.

n  터널 커넥션
웹 터널은 HTTPCONNECT 메소드를 사용한다. HTTP/1.1에서 지원하며, 터널 게이트웨이가 임의의 목적 서버와 포트에 TCP 커넥션을 맺고 클라이언트와 서버 간 데이터를 무조건 전달 요청을 한다.

n  커넥션이 이루어지면 응답을 받지 않고도 데이터를 보낼 수 있지만 게이트웨이에서 처리가 가능해야 한다. 한 쪽의 커넥션이 끊길 경우, 끊기기 전의 데이터는 그대로 전송되고 반대편 커넥션도 끊기며, 남아있는 데이터는 버려진다.

n  SSL 터널링: 암호화된 SSL 트래픽 전송을 위해 HTTP 커넥션으로 전송

n  터널 인증: 프록시 인증 기능은 클라이언트가 터널을 사용할 권한이 있는지 검사하는 용도로 사용된다. 터널 오용 최소화를 위해 게이트웨이는 HTTPS 전용 포트인 443 등과 같이 특정 포트만 터널링을 허용해야 한다.

 


Relay


단순 HTTP 프록시 일종으로, 한번에 한 개의 홉에 데이터 전달하는 방법. 트래픽만 전달하는 간단한 프록시 구현으로, 단순 필터링이나 진단, 컨텐츠 변환 시 사용된다. 때문에, 헤더의 Keep-Alive 커넥션에 행이 걸리는 문제가 있기 때문에 사용 시 주의 해야 한다


'System Engineering > Network' 카테고리의 다른 글

HTTP - 7. Authentication  (0) 2018.07.24
HTTP - 6. Proxy  (0) 2018.07.24
HTTP 4. DNS  (0) 2018.07.24
HTTP - GET, PUT, POST  (0) 2018.07.24
HTTP - 3. URI, URL  (0) 2018.07.12

+ Recent posts