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. 로깅
        트랜잭션 완료 후 수행 결과에 대해 로그파일 기록.

DNS

네트워크 상의 도메인 네임을 IP 주소에 매핑해 주는 시스템으로, 초기에 호스트 네임 별로 IP 주소 정보를 시스템 안의 hosts.txt 파일로 관리하던 것이 관리 대상이 증가하고, 기술의 발달에 따라 분산 구조로 관리가 가능하도록 개발된 시스템이다.
DNS 도메인 네임은 a-z, A-Z, 0-9, 하이픈(-) 문자만 허용한다.

DNS Components

-       TLD: Top Level Domain. 루트 도메인 하위의 상위 도메인

-       SLD: Second Level Domain. 도메인 등록 조직, 국가 등 소속 기관의 성격으로 분류. gTLD의 하위 도메인일 경우, 최종 사용자가 정의한 도메인을 등록하여 사용한다.

-       Third Level Domain: SLD 하위 도메인으로, gTLD를 제외하고 최종 사용자에 의해 정의된 도메인

Sub Domain: 사용 목적에 따라 최종 사용자에 의해 정의된 도메인. a.b.com의 경우 a 가 서브 도메인에 해당한다.

Name Server

  도메인 네임 스페이스에 대한 정보를 저장하는 호스트. 일반적으로 네임 스페이스에 대한 정보를 파일 형태로 가지고 있고, 해당 존에 대한 권한을 가지고 있다. 마스터/슬레이브 구성의 네임 서버의 경우, 보조 네임 서버에서 마스터 네임 서버의 존 파일을 읽어 서비스 한다. 또한 캐싱 기능으로 TTL 값을 이용한다. 한번 들어온 질의에 대하여 응답을 저장해 두고, 같은 질의 시 해당 응답을 돌려준다.

Zone

네임 스페이스 내부의 일부분으로, 해당 존의 네임 서버는 도메인 파일이 아닌 존 파일을 읽는다.

Resolver 
   OS에 포함된 네트워크 소켓 라이브러리에 포함된 프로그램으로, 브라우저 등 DNS 클라이언트의 요청을 네임 서버로 전달하고, 메인 네임과 IP 주소를 받아 클라이언트에 제공하는 기능을 수행.

-       Recursive DNS
일반적인 재귀적 네임 서버. 클라이언트로 최종 결과값을 반환하며, 리졸버로부터 질의 요청이 들어온 경우, 네임 서버가 직접 탐색하여 결과를 반환한다.

-       Iterative DNS
루트 네임서버, 일부 TLD 네임 서버의 형태. 자신이 직접 관리 하지 않는 질의는 응답이 가능한 네임 서버 목록으로 응답하는 방식.

-       PQDN (Partially Qualified Domain Name): 호스트 네임으로 시작하지만 루트 도메인까지 명시되지 않은 도메인.

-       FQDN (Fully Qualified Domain Name): 호스트 네임부터 네임 스페이스의 루트까지 표시된 도메인 네임. DNS 존 파일에서는 PQDN과 구분하기 위해 도메인 끝에 마침표를 붙여 FQDN임을 식별한다.

DNS zone, 도메인 네임과 관련된 정보를 갖는 레코드로, 각 값들이 이름과 값으로 바인딩 된다. 이 정보들이 DNS 네임 서버 내에 레코드 집합으로 구성된다. DNS 쿼리에 대해 1개 이상의 레코드 값을 포함한 DNS 메시지를 응답한다.

-       AXFR (Authoritative Zone Transfer)
마스터 네임 서버에서 보조 네임 서버로 전체 존 파일을 전송하는 것

-       IXFR (Incremental Zone Transfer)
존 파일의 이전 값과 비교하여 변경된 부분만 전송하는 것. 권한 서버가 요청 받은 내용이 부족할 경우 무시되고 AXFR 응답을 보낸다.

리소스 레코드는 도메인 네임에 설정할 수 있는 데이터 타입이다. 도메인 네임을 키 값으로 하여 이를 도메인 네임에 필요한 데이터를 설정하는데, 사전에 정의된 데이터 타입과 포맷으로 해야 한다. 도메인 네임과 IP 주소 매치를 위해 사용된다. 

  -A 리소스 레코드: Host Address란 의미로 도메인 네임에 매치되는 IPv4를 정의한다. 

Ø  Class: IN(InterNet) 외에도 있지만 현재 대부분 IN사용
  TTL: 요청된 리소스 리코드는 TTL에 명시된 시간 소요 후 삭제되어 재요청이 필요. 생략 시 SOA 리소스 레코드에 정의된 default TTL 적용 

Ø  NS (Name Server) 리소스 레코드: 도메인 존의 네임서버를 정의. 

Ø  CNAME 리소스 레코드: Canonical Name. 도메인 네임에 별칭을 매치. 해당 도메인 네임에 대한 리소스 레코드를 동일하게 접근하여 사용하므로, 정보를 CNAME이 상속받는다. 
   ex) www.naver.com IN CNAME naver.com 참조 시 naver.com 리소스 레코드를 참조하여 정보를 반환한다. 

-SOA 리소스 레코드: Start of a zone Of Authority. 존에 대한 권한 시작을 의미. 하나의 도메인 존에 반드시 하나의 SOA가 존재하는 특수 레코드로, 도메인 존의 default 설정과 마스터 네임 서버 지정 등에 사용된다. 

Name: 상위 도메인 존에게 위임 받은 도메인 존의 도메인 네임 
  마스터 네임 서버: NS 리소스 레코드와 A 리소스 레코드를 통해 도메인 존에 대한 리소스 레코드 생성, 변경, 삭제 등의 권한을 위임 받음
  Responsible person: 도메인 존 관리 담당자 메일 주소 
  Serial: 도메인 존 파일에 대한 버전 정보. 정보 변경 시 증가. 이 값을 기반으로 슬레이브 네임 서버가 마스터 네임서버의 최신 리소스 레코드 정보를 획득한다. 
  Refresh: 슬레이브 네임 서버가 마스터 네임서버에 도메인 존 파일 버전을 질의하는 초단위 시간으로, 해당 시간만큼 대기 후 마스터에 질의 
  Retry: 슬레이브 네임 서버가 마스터 네임 서버에 질의 실패 시 재시도 하는 초 단위 시간으로 Refresh 보다 작은 값 작성 
  Expire: 슬레이브 네임 서버가 질의 실패 시 마스터로부터 얻은 정보의 유효 시간 초 단위 작성. 해당 도메인 존에 대한 질의 무시 
  Minimum: 도메인 존 파일에 있는 리소스 레코드들의 default TTL 값 작성(초 단위) 

SOA 끝 필드의 각 설정 값들은 기본 초 단위이며, D, H, W로 각각 일, 시간, 주로 작성 가능하다.

-MX 리소스 레코드: 수신 메일  서버를 정의. 호스트명이나 도메인 네임으로만 정의가 가능하다. IP 주소 입력 시 도메인으로 인식하여 존재하지 않는 도메인이 되어버린다. 레코드 입력 시 마지막에 .을 붙인 FQDN을 사용한다.

GET, POST, PUT

GET

           - URL?id=user&page=1 형식
           - 서버에서 데이터를 가져와 보여주는 용도

기본적으로 서버로 부터 리소스를 가져올 때 사용하며, 데이터를 서버로 전달하는 경우, URL이 길어져 브라우저에서 제한하는 URL 길이에 걸려 데이터가 잘리는 상황이 발생한다.

기본적으로 URI 표준은 길이 제한이 없으나, 브라우저 마다 URL을 제한하거나, 서버 측에서 처리 가능 길이가 제한되는 등의 상황이 있다.

ex) 게시판 글 중에서 특정 ID 값을 전달하여 해당하는 글을 가져오는 경우

POST

메시지 Body 안에 포함 되어 숨겨져서(인코딩 되어) 전달
           - HTML FORM submit 형태
           - 서버의 값, 상태를 변경

서버 측에서 데이터를 전달받아 수행하는 형태로 사용된다.

또한 리소스의 위치를 지정하지 않고 생성할 때 사용된다.  PUT과 달리 멱등성이 존재하지 않는다.

ex) 게시판에 글을 작성하고 SUBMIT을 하는 경우

PUT

URI, URL

URI

URL

-URL의 문자집합은 표현 문자가 적은(안전한) US-ASCII에 이스케이프 문자열을 추가하여 이동성과 완성도를 높였다. 

-이스케이프 문자열은 ‘%’로 시작하여 ASCII 코드로 표현되는 두개의 16진수 숫자로 이루어져 있다. 

(Ex. 공백: 32 (0x20) -> http://.../a%20space) 

-특수 목적(인터넷 게이트웨이, 프로토콜에서의 혼동 등)의 예약 문자들이 있고 이 문자들을 해당 목적 외로 사용하려면 반드시 인코딩 후 사용해야 한다. 

Scheme

주어진 리소스에 접근하는 방식을 알려주는 정보이다. URL을 해석하는 애플리케이션이 어떤 프로토콜을 사용하여 리소스를 요청해야 하는지를 알려준다. 알파벳으로 시작하고, ':' 으로 나머지 URL과 구분한다.  

Port  

웹 상의 리소스를 찾을 때, 해당 리소스를 가진 서버를 찾는 필요한 두가지 정보는 호스트와 포트이고, HTTP 기본 포트는 80을 사용한다.  

Username & Password

사용자 이름과 비밀번호 컴포넌트는 해당 서버에 접근하기 위해 필요한 정보로, 사용자 이름의 기본값은 'anonymous'이다. 입력 위치는 "SCHEME://username:password@HOST" 형식으로 사용한다.  

Parameter

URL을 사용하는 애플리케이션이 리소스에 접근할 때, 프로토콜 파라미터가 필요하다. 서버가 요청을 처리하기 위해 필요한 것으로, 애플리케이션이 정확한 요청을 하기 위해 필요한 입력 파라미터를 받는데 사용한다. 이름, 값 쌍의 리스트로 ';'로 구분하여 사용한다. 
(ex. ftp://HOST/pub/gnu;type=d) 

Query string

데이터베이스 등의 서비스들은 요청 받을 리소스 형식의 범위를 좁히기 위해 질문이나 질의를 받을 수 있다. 게이트웨이를 가리키는 URL 경로에 '?'를 붙인 뒤, 질의 컴포넌트를 붙여 전달한다. 질의 컴포넌트 포맷에 제약사항은 없으며 '&'로 나뉜 '이름=값' 형식의 문자열을 사용한다.  

(ex. .../check.cgi?iteem=1&color=blue)  

Fragment

리소스 내의 특정 부분을 가리킬 수 있도록 하는 컴포넌트로, HTML 내의 특정 이미지 등을 지시할 수 있다. 클라이언트는 서버에 프래그먼트를 전달하지 않는다. 브라우저가 서버로부터 전체 리소스를 받은 후, 프래그먼트를 사용하여 원하는 리소스의 일부를 보여준다.  

Relative URL

Base URL을 기준으로 './doc.html'과 같이 URL 내의 리소스를 간결히 기술하는데 사용한다. 프래그먼트 이거나 URL의 일부이며, 브라우저는 절대 URL 간 상호 변환이 가능해야 한다. 

Convert to absolute URL

스킴이 비어 있을 경우 base url 스킴을 상속받으며, 각 컴포넌트를 검사한다. 컴포넌트가 모두 비어 있을 경우 마찬가지로 base url의 컴포넌트를 상속받는다. 상속 후 경로에서 ‘./’, ‘…/./’을 제거하고 상대 컴포넌트와 새로운 절대 URL로 합친다. 

Base URL

상대 URL을 절대 URL로 변환하기 위해 찾는 기준. <BASE> HTML 태그로 리소스에서 명시적으로 base url을 기술하기도 한다 .
-base URL이 없는 경우 절대 URL으로만으로 이루어질 수 있으나 불완전하거나 깨진 URL일 수도 있다.
-리소스에 base url이 명시되어 있지 않은 경우 리소스의 URL이 base url로 사용된다.

URL Expansion

브라우저에서 사용자 입력 중에 자동으로 URL을 확장해 주는 기능으로, 사용자에게 빠른 URL 입력을 도와준다.  

Host expansion

호스트 명 확장: 휴리스틱만을 사용해서 입력 호스트 명을 전체 호스트 명으로 확장. naver를 입력하면 앞 뒤로 ‘www’, ‘com을 붙여준다. 해당 단어를 포함한 사이트를 찾지 못할 경우 몇 가지 제안하는 URL을 보여주기도 한다. 

History expansion

히스토리 확장: 과거에 사용자가 방문했던 URL 기록을 저장해 놓고, 입력된 URL의 앞 글자를 포함하는 완결된 형태의 URL을 선택할 수 있도록 해 준다.

TCP/IP

IP

IPv6

TCP/IP

Network Access Layer

-Sequence number: 0 ~ 2^32 -1 범위의 번호로, 초과 시 0으로 되돌아온다. 수신지 TCP에 세그먼트의 첫 번째 바이트가 시퀀스 넘버라는 것을 알린다. 

-Acknowledgement number: 수신 노드가 송신 노드에서 수신하려는 바이트 번호로, 마지막 성공 시퀀스 넘버 + 1이다. 
-플래그: 프로토콜 동작 제어용 비트 단위 플래그 
-윈도우 크기: 데이터 버퍼인 윈도우의 사이즈. 

3-way Handshaking - 연결 설정 시퀀스

4-way Handshaking - 연결 종료 시퀀스

TCP Flow control

TCP Connection control

    일반적으로 TCP 커넥션은 클라이언트와 서버 간 연결 수립 후 데이터를 주고받은 뒤 커넥션을 끊고 통신이 필요하면 다시 커넥션을 설정한다. 하지만 이는 연결 수립에 따르는 시간이 추가적으로 소요되기 때문에 이에 대한 해결책으로 Persistent connection이 등장했다. 연결은 한번만 설정하고, 지속적으로 데이터를 주고받을 수 있다. 하지만 이 또한 데이터를 주고받을 때 하나의 데이터를 받았다는 응답도 처리해야 하는 TCP 특성상 지연이 발생할 수 있다.
 HTTP Pipelining으로 이를 해소할 수 있는데, 연결 수립 후 데이터를 여러 번 받은 뒤, 순차적으로 여러 번 응답하는 방식이다.

HTTP - 2

HTTP 동작 방식

HTTP Message

HTTP Status Code

ref: http://designtaxi.com

100-199: 정보성 상태 코드

200-299: 성공 상태 코드

300-399: 리디렉션 상태 코드 

400-499: 클라이언트 에러 상태 코드

500-599: 서버 에러 상태 코드 

HTTP Headers

ref: http://www.google.com (all images)

ref: http://www.google.com (all images)

VDI (Virtual Desktop Infrastructure)

How to provide a service, the method.

Container Orchestration

5. Redhat - Openshift == Docker + Kubernetes + Redhat

Evolution

In Business

데이터센터는 초기 구축 비용을 제외 하고는 시간이 지남에 따라 유지 보수를 해야하는 자원이다.

데이터센터 인프라 자체에서 비즈니스적인 수익이 창출되지 않는다. 따라서 유지되는 비용을 줄이는 것이 최선이고, 그 우선순위가 가장 높은것이 전기 소모다.  비용적인 측면에서 PM은 그다지 효율적이지 않다는 결론이 나왔고, VM이 도입 된 것이다.

대기업은 비즈니스를 원하지만, 대부분의 중소기업은 그들이 만드는 흐름에 맞출 뿐 이다.

Microsoft supports Docker native now.

Maintenance

>HW: Parallel process, duplex

>SW: TCP/IP to Restful to NW distribution. Application distribution(MSA)

- Server virtualization

- Container: Application platform virtualization. Orchestration, automation, easy to manage (compare with VM).

IaaS and PaaS must have SDN

PM vs Container

-Interact VM kernel and Host Kernel brings resource issue that indicates performance.

-Distributed deployment issue brings network problem

-Host kernel updated or application code edit could be a problem

-VM OS resource also needed

>> Monolithic Architecture

>> Need to scale-up not a scale-out.

+Native structure brings performance enhancement

+App isolation via namespace(linux kernel function)

+Without guest OS > OS system configuration without kernel

+Host subordinate kernel

-If kernel is down, affect on all of applications

=Uusing cgroups(control groups) to limit the host's resources

Docker container: LXC + Distributed Deployment and Management Concepts

LXC is OS container as a light weight VM. One application in one container.

리눅스 컨테이너는 경량화된 VM이라고 보면 된다. 도커 컨테이너에서 1개의 어플리케이션은 1개의 컨테이너에서 사용한다.

Orchestration