webserv

서버(Server)란??

컴퓨터 네트워크에서 다른 컴퓨터에 대해 자신이 갖고 있는 기능이나 서비스, 데이터 등을 제공하는 컴퓨터 또는 그와 같은 기능을 가진 소프트웨어 라고 한다. ex) Apache Server && Nginx, IIS(Windows 전용 Web 서버) 등

webserver 란??

하드웨어 측면

웹사이트의 컴포넌트 파일들을 저장하는 컴퓨터

컴포넌트 파일 → HTML, Images, CSS, JavaScript…

컴포넌트 파일을 인터넷을 통해 클라이언트에 전달

소프트웨어 측면

사용자가 어떻게 호스트 파일들에 접근하는지 관리

웹 서버는 주소 HTTP 프로토콜을 사용하여 클라이언트의 요청을 처리 및 응답

💡

브라우저가 웹 서버에서 불려진 파일을 필요로 할때, HTTP를 통해 파일을 요청하고, 요청이 올바른 웹 서버(하드웨어)에 도달했을때, HTTP서버(software)는 요청 문서를 HTTP를 이용해 보내준다.

정적 웹 서버

HTTP 서버(소프트웨어)가 있는 컴퓨터(하드웨어)로 구성되어 있다. 서버가 불려진 파일을 클라이언트(브라우저)에게 전송한다.

동적 웹 서버

정적 웹 서버와 추가적인 소프트웨어(일반적으로 애플리케이션 서버와 데이터베이스)로 구성된다. 애플리케이션 서버가 HTTP 서버를 통해 클라이언트(브라우저)에게 불려진 파일들을 전송하기 전에 애플리케이션 서버가 업데이트한다.

WAS(Web Application Server) 를 통해 결과가 이루어진다. 추후 WAS에 대해 따로 자세히 공부해보자.

컴포넌트 파일

기술적으로, 컴퓨터에 있는 파일들을 불러올 수 있지만, 그것들을 전담하는 웹 서버에 저장하는 것이 더 편리하다.

전담하는 웹서버

항상 실행 중

항상 인터넷에 연결 되어있다.

항상 같은 IP를 가지고 있다.

제 3자에 의해 유지보수 된다.

과제 진행

🙊 에코 서버 구현

Nginx Configuration

예시 파일


user       www www;  ## Default: nobody
worker_processes  5;  ## Default: 1
error_log  logs/error.log;
pid        logs/nginx.pid;
worker_rlimit_nofile 8192;

events {
  worker_connections  4096;  ## Default: 1024
}

http {
  include    conf/mime.types;
  include    /etc/nginx/proxy.conf;
  include    /etc/nginx/fastcgi.conf;
  index    index.html index.htm index.php;

  default_type application/octet-stream;
  log_format   main '$remote_addr - $remote_user [$time_local]  $status '
    '"$request" $body_bytes_sent "$http_referer" '
    '"$http_user_agent" "$http_x_forwarded_for"';
  access_log   logs/access.log  main;
  sendfile     on;
  tcp_nopush   on;
  server_names_hash_bucket_size 128; # this seems to be required for some vhosts

  server { # php/fastcgi
    listen       80;
    server_name  domain1.com www.domain1.com;
    access_log   logs/domain1.access.log  main;
    root         html;

    location ~ \.php$ {
      fastcgi_pass   127.0.0.1:1025;
    }
  }
}

기반 모듈

엔진엑스의 기본적인 기능을 가진 매개변수를 정의할 수 있는 지시어를 제공한다.

핵심 모듈 (core module): 프로세스 관리나 보안 같은 필수 기능 및 지시어로 이루어진다.

이벤트 모듈(event module): 네트워킹 기능의 내부 동작 방식을 구성한다.

구성 모듈(configuration module): 구성을 외부 파일에서 가져와 포함시킨다.(include)

핵심 모듈 지시어

지시어	설명
user	`user username groupname; user username;`기본값: 컴파일 할 때 결정 작업자 프로세스 (worker process)를 시작시키는 사용자 계정과 그룹을 지정할 수 있다. groupname 생략 시 user가 사용된다. user root root; 는 보안상 위험하다.
worker_process	기본값: 1 작업자 프로세스(worker_process)의 수를 정의한다. 보통 CPU의 코어 수만큼 할당하는 것이 좋으며, 확실하지 않은 경우 auto를 입력하여 자동 감지를 시도할 수 있다. Nginx는 하나의 mater process와 n개의 worker process로 구성되어 실행된다. master process는 설정 파일을 읽고, 프로세스를 유지 및 관리한다.모든 요청은 worker process에서 처리한다. master에서는 클라이언트의 요청도 처리하지 않는다.
error_log (main, http, mail, stream, server, location 에서 사용 가능)	`error_log /file/path level;` 기본값: logs/err.log error level : debug, info, notice, warn, error, crit, alert, emerg 오류 로그를 끄려면 구성파일 최상단에 error_log /dev/null crit; 로 지정한다. 파일 경로 대신 syslog, memory, stderr 등으로 지정할 수도 있다.

이벤트 모듈 지시어

지시어	설명
use	use kqueue; 기본값: 없음 어떤 이벤트 모델을 사용할지 결정한다. (nginx는 자동으로 가장 적합한 모델을 선택한다)

HTTP 핵심 모듈

💡

http 서버의 모든 기반 블록, 지시어, 변수를 포함하는 구성 요소, 주 블록은 http, server, location이다.

Flow

예상 로직 플로우이다.

Request 파싱

💡

key: [value] // value 는 LWS 로 구분되어질 수 있다.

일반적으로 다음과 같은 경우에 Base64 인코딩을 사용합니다.

데이터 크기가 작은 경우

전송 효율성보다 호환성이 중요한 경우

다음과 같은 경우에 Chunked encoding을 사용합니다.

데이터 크기가 큰 경우

전송 효율성이 중요한 경우

GET

💡

일반적으로 content-type 은 따로 넣지 않는다.

POST

image/png

일반적이지는 않음

application/octet-stream

바이너리 파일 전송

multipart/form-data

텍스트 데이터: 텍스트 데이터를 전송할 때는 주로 다음과 같은 Content-Type이 사용

text/plain: 텍스트 데이터를 평문으로 전송할 때 사용

text/html: HTML 형식의 텍스트 데이터를 전송할 때 사용

파일 데이터: 파일 데이터를 전송할 때는 주로 다음과 같은 Content-Type이 사용

application/octet-stream: 이진 데이터를 전송할 때 사용

image/png: 이미지 파일을 전송할 때 사용

DELETE

일반적으로 body 내용 무시

헤더 예시

1. `text/plain`

텍스트 데이터를 전송할 때 사용되며, 별도의 태그 없이 순수한 텍스트로만 구성됩니다.


Content-Type: text/plain;charset=utf-8

2. `text/html`

HTML 문서를 전송할 때 사용됩니다. 웹 페이지의 내용을 전송하는 데 주로 사용됩니다.


Content-Type: text/html;charset=utf-8

3. `multipart/form-data`

파일 업로드나 폼 데이터가 파일과 텍스트 필드를 모두 포함할 때 사용됩니다. 각 부분은 고유한 경계 문자열(boundary)로 구분됩니다.


Content-Type: multipart/form-data; boundary=----WebKitFormBoundary7MA4YWxkTrZu0gW

이 경계 문자열은 메시지 본문에서 각 부분을 구분하는 데 사용되며, 실제 사용할 때는 고유한 값이 생성되어 사용됩니다.

4. `application/octet-stream`

이진 데이터를 전송할 때 사용됩니다. 파일 다운로드 등에 사용되며, 특정 파일 형식을 지정하지 않는 일반적인 이진 데이터를 의미합니다.


Content-Type: application/octet-stream

5. `image/png`

PNG 형식의 이미지 파일을 전송할 때 사용됩니다.


Content-Type: image/png

Content-Type 헤더는 클라이언트와 서버 간의 데이터 교환에서 매우 중요한 역할을 하며, 올바른 Content-Type을 지정하는 것은 데이터가 올바르게 해석되고 처리되도록 하는 데 필수적입니다.

각 method 별 처리

GET

url 확인

디렉토리인가 ?

YES: 에러

NO: 해당 리소스 있는지 확인

반환

POST

DELETE

url 확인

이상 없다면 삭제 후 200 OK

Response

예시


HTTP/1.1 200 OK\r\n//status line
Date: Mon, 27 Jul 2009 12:28:53 GMT\r\n// header line
Server: Apache/2.2.14 (Win32)\r\n
Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT\r\n
Content-Length: 88\r\n
Content-Type: text/html\r\n
Connection: Closed\r\n
\r\n// crlf
<html>// body
<body>
<h1>Hello, World!</h1>
</body>
</html>

HTTP Chunked Message를 알아보자

# if 0 두달간의 노예 일상을 이제야 끝나고,, 너무 오랜만에 들여다본 블로그,, 개발자로 지내고 있지만,, 일하고 싶지는 않은 그런 삶,, 갑작스럽게 HTTP 프로토콜을 구현해야할 일이 생겨서, 규격 참고하고 구글링 하며 공부한 주제로 오늘은,, 해볼까 합니다,, #endif HTTP 라는 단어는 많이 들어보셨을거라고 생각합니다 그 중에서, Chunked 라는 단어는 조금 생소할 수도 있는데 규격대로만 생각한다면 그리 어렵지 않은 (구현은 까다로울 겁니다..) HTTP Chunked Message를 알아보도록 할겁니다,, - 아주아주 간단한 HTTP Protocol 설명 - HTTP Header와 Body를 읽는 방법 - HTTP Chunked Message란 무엇인가 1. HTTP(HyperTex..

https://mutpp.tistory.com/10

RFC

10.2.7 206 Partial Content(부분적 내용).

💡

서버가 자원에 대한 부분적 GET 요구를 완료하였다. 이 요구는 반드시 원하는 영역을 표시하는 Range 헤더 필드(14.36 절)를 포함해야 한다. 응답은 이 응답에 포함된 영역을 표시하는 Content-Range 헤더 필드(14.17 절)나 각 파트의 Content-Range 필드를 포함하는 multipart/byteranges Content-Type을 포함해야 한다. multipart/byteranges 를 사용하지 않았으면 응답의 Content-Length 헤더 필드는 Message-Body 로 전송된 OCTET 의 실제 숫자와 정확하게 일치해야 한다. Range 및Content-Range 헤더를 지원하지 않는 캐시는 206(Partial Content) 응답을 캐시해서는 안 된다.

궁금증

💡

웹 서버에서 자원을 제공한다하는데 그럼 웹 서버(하드웨어)에 데이터가 저장되어있는건가?? db에 저장하는것처럼???

웹 서버에서 정적인 데이터들을 하드웨어에 저장해 가지고 있다가 요청하면 보내주는 형식이 맞는것 같다. 일반적으로 정적인 웹 페이지를 만든다면 해당 웹 서버에 HTML 파일과 같은 컴포넌트 파일을 업로드하여 클라이언트가 요청하면 그때 웹 서버에서 제공한다고 생각하면 된다.

💡

웹서버를 직접 구현한다면 config 파일을 파싱해서 검증해야하나??

그렇다. 어디까지 config 를 유효 인자로 받을지는 본인 판단으로 구현하면 된다.

💡

멀티플렉싱의 단일 스레드 방식으로 코드가 돌아가는데 왜 fcntl로 non-blocking을 해주었는지??

시스템 콜로 해당 소켓을 사용하는 것이기 때문에 이부분을 non-blocking으로 하기 위해서 이다. 시스템 콜에 대해서 공부를 해보면 이해가 간다.

💡

웹 브라우저로 요청을 보낼 정적 페이지나 에러페이지를 따로 html로 만들어야하는가?

그렇다.

💡

클라이언트가 http 메서드를 보낼 때 브라우저가 알아서 해주나?

웹브라우저가 알아서 메서드를 생성해서 보내주거나, html form 형식에 따라 맞춰서 해준다.

💡

kqueue가 이벤트를 어떻게 감지하는지? 파일이 변화하는 거에 따라 read, write flag가 동작하는지?

파일의 변화로 이벤트가 트리거 될 수 있다. 하지만 EV_SET의 인자로 들어가는 flags 의 종류에 따라 해당 소켓이 비활성화 되어있을 수 도 있다는 점을 생각하자.

💡

CRLF 를 알아서 잘 읽나??

알아서 개행으로 잘읽으니 테스트 할때는 해당 파일을 CRLF 로만 바꿔주면 된다.(맥은 기본이 LF)

💡

multpart-form 이나 chunked 와 같은 encode-64 방식으로 바이너리 파일을 http 바디로 입력받을때 널이 들어올 수 있나??

그렇다고 한다.

💡

HTTP 바디 메세지의 끝은 어떻게 알 수 있을까?

HTTP 메시지에서 바디의 끝을 나타내는 방식은 '\0' 문자를 사용하는 것이 아니다. HTTP 프로토콜은 텍스트 기반 프로토콜이며, HTTP 메시지의 구조는 시작 줄(start line), 헤더(headers), 그리고 메시지 바디(body)로 구성된다. 각 부분은 특정 방식으로 구분되며, 바디의 끝은 '\0' 문자로 명시적으로 표시되지 않는다.

HTTP 메시지 바디의 끝은 다음 방식으로 결정된다:

Content-Length 헤더: 이 헤더는 메시지 바디의 길이를 바이트 단위로 명시한다. 클라이언트나 서버는 이 값을 사용하여 메시지 바디의 끝을 판단한다. 예를 들어, Content-Length: 1234라면, 헤더 이후에 오는 1234바이트가 메시지 바디로 해석된다.

Chunked Transfer Encoding: Transfer-Encoding: chunked 헤더가 사용될 때, 메시지 바디는 여러 개의 청크로 나누어 전송된다. 각 청크는 길이 값으로 시작하며, 마지막 청크는 0\r\n\r\n으로 표시된다. 따라서, 청크 인코딩을 사용할 때는 마지막 청크의 길이가 0이라는 점을 통해 바디의 끝을 알 수 있다.

멀티파트 바디: Content-Type: multipart/form-data와 같이 멀티파트 메시지를 사용할 경우, 각 부분은 경계 문자열(boundary string)에 의해 구분되며, 마지막 경계 문자열 뒤에 -가 추가되어 메시지의 끝을 나타낸다.

💡

EV_SET(&tmp_event, ident, filter, flags, fflags, data, udata) 에서 data 랑 udata 용도?

EV_SET 매크로는 BSD 계열 운영 체제에서 제공하는 kqueue 이벤트 알림 시스템을 설정하기 위해 사용됩니다. kqueue는 다양한 종류의 이벤트를 효율적으로 모니터링할 수 있게 해주는 메커니즘입니다. 이 시스템을 사용하면 파일 디스크립터, 타이머, 프로세스, 신호 등 다양한 이벤트 소스에 대한 변화를 비동기적으로 감지할 수 있습니다. EV_SET 매크로를 통해 개별 이벤트를 kevent 구조체에 설정할 수 있으며, 이때 여러 파라미터를 지정해야 합니다.

EV_SET의 파라미터 중 data와 udata에 대해 설명하겠습니다:

data: 이 파라미터의 용도는 이벤트 필터(filter)에 따라 다르며, 이벤트에 대한 추가 정보를 제공합니다. 예를 들어, EVFILT_READ 필터를 사용하는 경우 data는 읽을 수 있는 데이터의 바이트 수를 나타낼 수 있습니다. 다른 필터를 사용하는 경우에는 다른 종류의 정보를 나타낼 수 있습니다. 즉, data 필드는 이벤트에 따라 다른 의미를 가질 수 있으며, 이벤트의 특정 세부 사항을 나타내는 데 사용됩니다.

udata: 사용자 정의 데이터를 위한 포인터입니다. 이 파라미터는 kevent 구조체와 함께 제공되는 이벤트에 대한 사용자 정의 컨텍스트 또는 데이터를 가리키는 데 사용됩니다. udata는 이벤트 핸들러나 콜백 함수에서 해당 이벤트를 더 잘 처리하기 위해 필요한 추가 정보를 저장하는 데 유용합니다. 예를 들어, 특정 이벤트와 관련된 객체의 포인터를 udata에 저장하여 이벤트가 발생했을 때 쉽게 해당 객체에 접근할 수 있습니다.

EV_SET을 사용하여 kevent 구조체를 설정할 때, ident, filter, flags, fflags, data, udata 등의 필드를 적절히 설정함으로써, 원하는 이벤트 모니터링 동작을 정밀하게 구성할 수 있습니다. data와 udata는 이러한 설정 중에서도 특히 이벤트 처리의 유연성과 컨텍스트 관리 측면에서 중요한 역할을 합니다.