7. Web Server

2022 우아한스터디 "HTTP 완벽가이드"를 진행하면서

'HTTP 완벽 가이드' 책을 읽고, 글쓴이의 생각을 정리하는 글 입니다.

https://book.naver.com/bookdb/book_detail.nhn?bid=8509980 

HTTP 완벽 가이드

 

1. Web Server?

요즘은 많은 분들이 Django, Flask, Spring boot 등 Web App 프래임워크를 가지고 웹페이지를 만들 수 있습니다.

 

하지만, 우아한 수영을 하는 오리가 물밑에서 엄청난 일을 하고있듯

 

이런 프래임워크들 역시, HTTP 통신 규격에 맞게 많은 작업들은 한 결과라고 할 수 있죠.

 

Web Server가 하는 일을 살펴보면, 아래와 같습니다.

 

1_1. Connection 생성

1_2. Requests를 받는다

1_3. Requests를 처리한다

1_4. Requests를 처리하기 위한 Resource에 접근한다.

1_5. Response를 만든다

1_6. Response를 보낸다.

1_7. 트랜잭션 결과를 로그로 남긴다.

 

간단하죠?

 

실제로 하나의 Requests를 처리하는 경우만 생각하면 간단합니다.

 

하지만, Requests의 종류는 정말 다양하고, 이를 위한 Requests를 처리하는 다양한 Method를 정의하는 것이 바로 Web Server라고 할 수 있습니다.

 

그럼, 각 단계별로 특이사항을 살펴 보겠습니다.

 

1_1. Connection 생성

4. 커넥션 관리(1편) (tistory.com)

4. 커넥션 관리(1편)

5. 커넥션 관리(2편) (tistory.com)

5. 커넥션 관리(2편)

여기서 다뤘던 내용들이 Connection 생성에서 사용되는 기술들입니다.

 

이 단계에서 Client의 Host명을 확인하는 작업이 추가로 요구됩니다.

 

1_1->1 Reverse DNS 방법으로 찾을 수 있지만, 이 작업은 시간이 오래걸려서 잘 사용되지 않는다고 합니다.

 

1_1->2 ident를 통해서 Clinet 사용자 알아내기

ident 프로토콜은 서버에게 어떤 사용자 이름이 HTTP 커넥션을 초기화했는지 찾아낼 수 있게 해줍니다. 

 

ident 프로토콜은 새로운 HTTP Connection이 생성 되었을 때 Web Server에서 Client로 ident정보를 Requests하게 됩니다.

 

그러면 Client는 이 Requests에 HTTP Connection을 열고, (최초포트, 서버포트:USERID:UNIX:NAME) 과 같은 Response를 보냅니다.

 

보면 알겠지만, 이 과정에서 Connection이 두번 생겨야 하고, 조작의 위험 및 네트워크의 지연이 발생해서 내부망을 이용하는 조직인트라넷 외에는 잘 사용하지 않는다고 합니다.

(그래서 어떤게 답인지는 책에 없더라..)

 

1_2. Requests 받기

Requests는 표준 HTTP 요청 형태로 날라옵니다.

이때, HTTP 요청의 경우 Header 부분이 KEY : Value형태로 존재하는것을 알 수 있습니다.

 

그래서 아래 예시처럼 HTTP Message를 구조체 + Pointer OR Json 형태로 파싱합니다.

CRLF = Carriage Return(\r) + Line Feed(\n)
요청 메세지
/*
GET /specials/sqw-blade.gif HTTP1.0 CRLF

Accept : image/gif CRLF
Host : www.joes-hardware.com CRLF
CRLF
*/

↓
Parsing
↓

{
    method : 1
    version : 1.0
    uri : {
    	specials/saw-blade.gif
    }
    header count : 2
    headers = {
    	Host : www.joes-hardware.com
        Accept : image/gif
    }
    body : -
}

정상적은 파싱을 위해서 HTTP Message Header는 CRLF로 끝나야 하며, Header의 끝을 알리는 공백+CRLF가 포함되어야 합니다.

 

이때 이러한 HTTP Message가 오는 양아 많이지면서, 이런 Message I/O를 효율적으로 처리하기 위한 아키텍처들이 고안됩니다.

 

1_2->1. 단일스레드 웹서버

한번에 하나의 Connection만 연결하고, 한번에 하나의 요청만 처리 가능한 공무원 웹서버 입니다.

1_2->2. 멀티스레드 I/O 웹서버

한번에 하나의 Connection만 연결하고, 대신 Connection에서 오는 여러 요청을 멀티쓰레드로 처리합니다.

1_2->3. 다중 I/O 웹서버

한번에 여러개의 Connection을 허용하지만, 한번에 하나의 요청만 처리 가능합니다.

1_2->4. 다중 + 멀테스레드 I/O 웹서버

다수의 Thread가 각자 다수의 Connection을 생성할 수 있는 가장 이상적인 웹서버 입니다.

 

1_3. 나머지

사실 나머지 부분은 크게 특별한 내용이 없습니다.

proxy말고 원본서버에 접근할 경우 상대주소 형태로 요청이 옵니다(Ex. "/docs/joe/index.html")

 

이때 HTTP Header부분의 Host와 결합해서 정확한 Resource주소를 찾는다 정도입니다.

 

그 이외에는 Response에 필요한 Header를 적절히 추가하는 작업인데, 이 부분은 Response의 Case에 따라 천차만별이니....

 

이번 포스팅은 여기까지 하겠습니다