[DISCURSSION] 프로젝트 시작을 위한 요구사항 정리 논의 및 정보 공유

[fing9]

주제

프로젝트를 시작하기 위해 필요한 요구사항을 함께 이야기하고, 정리하는 논의 입니다.

설명

요구 사항

• 프로그램은 구성 파일을 인수로 받거나 기본 경로를 사용해야 합니다.
• 다른 웹 서버를 execve 할 수 없습니다.
• 서버는 절대 블록되지 않아야 하며 클라이언트가 필요한 경우 적절하게 다시 시작될 수 있어야 합니다.
• 블록되지 않아야 하며 클라이언트와 서버 간의 모든 I/O 작업에 대해 poll() (또는 동등한 함수)를 1 회만 사용해야 합니다 (listen 포함).
• poll() (또는 동등한 함수)는 동시에 읽기와 쓰기를 확인해야 합니다.
• 읽기 또는 쓰기 작업을 poll() (또는 동등한 함수)를 통하지 않고 수행해서는 안됩니다.
• 읽기 또는 쓰기 작업 후 errno 값을 확인하는 것은 엄격히 금지됩니다.
• 구성 파일을 읽기 전에 poll() (또는 동등한 함수)를 사용할 필요가 없습니다.

비차단 파일 디스크립터를 사용해야 하므로, poll() (또는 동등한 함수)를 사용하지 않고도 read/recv 또는 write/send 함수를 사용하는 것이 가능하지만, 이는 시스템 리소스를 더 많이 소비할 수 있습니다.
따라서, 만약 poll() (또는 동등한 함수)를 사용하지 않고 어떤 파일 디스크립터에서도 read/recv 또는 write/send를 시도한다면, 학점이 0점이 될 것입니다.

• FD_SET, FD_CLR, FD_ISSET, FD_ZERO와 같은 모든 매크로와 정의를 사용할 수 있습니다. 이러한 것들이 무엇이며 어떻게 작동하는지를 이해하는 것이 매우 유용합니다.
• 서버에 대한 요청은 영원히 멈춰서는 안 됩니다.
• 서버는 선택한 웹 브라우저와 호환되어야 합니다.
• NGINX가 HTTP 1.1을 준수한다고 가정하고, 헤더 및 응답 동작을 비교할 수 있습니다.
• HTTP 응답 상태 코드는 정확해야 합니다.
• 제공된 오류 페이지가 없는 경우 기본 오류 페이지를 갖고 있어야 합니다.
• CGI를 제외한 다른 용도로 fork를 사용할 수 없습니다 (예: PHP, Python 등).
• 완전히 정적인 웹사이트를 제공할 수 있어야 합니다.
• 클라이언트가 파일을 업로드할 수 있어야 합니다.
• 적어도 GET, POST 및 DELETE 메서드를 지원해야 합니다.
• 서버를 스트레스 테스트해야 합니다. 모든 비용에도 불구하고 서버가 가용해야 합니다.
• 서버는 여러 포트를 수신 대기할 수 있어야 합니다 (구성 파일 참조).

MacOS에서는 다른 Unix 운영 체제와 마찬가지로 write()를 구현하지 않기 때문에 fcntl()을 사용할 수 있습니다.
다른 Unix 운영 체제와 유사한 동작을 얻기 위해 파일 디스크립터를 비차단 모드로 사용해야 합니다.

하지만 다음과 같은 플래그만을 사용하여 fcntl()을 사용할 수 있습니다: F_SETFL, O_NONBLOCK 및 FD_CLOEXEC. 다른 어떤 플래그도 사용할 수 없습니다.

III.3 설정 파일
NGINX 구성 파일의 '서버' 부분에서 영감을 받을 수 있습니다.
구성 파일에서 다음을 수행할 수 있어야 합니다:
• 각 '서버'의 포트와 호스트를 선택합니다.
• 서버 이름을 설정하거나 설정하지 않을 수 있습니다.
• 호스트:포트의 첫 번째 서버가 이 호스트:포트의 기본 서버가 됩니다 (다른 서버에 속하지 않는 모든 요청에 응답).
• 기본 오류 페이지를 설정합니다.
• 클라이언트 본문 크기를 제한합니다.
• 다음 규칙/구성 중 하나 이상을 사용하여 라우트를 설정합니다(라우트는 정규식을 사용하지 않을 것입니다):
◦ 라우트에 허용된 HTTP 메서드 목록을 정의합니다.
◦ HTTP 리다이렉션을 정의합니다.
◦ 파일이나 디렉토리를 정의하여 파일이 검색될 위치를 지정합니다(예를 들어, url /kapouet이 /tmp/www로 루트화되면 url /kapouet/pouic/toto/pouet이 /tmp/www/pouic/toto/pouet이 됩니다).
◦ 디렉토리 목록 표시를 켜거나 끌 수 있습니다.
◦ 디렉토리인 경우 응답할 기본 파일을 설정합니다.
◦ 특정 파일 확장자에 따라 CGI를 실행합니다(예: .php).
◦ POST 및 GET 메서드와 함께 작동하도록 합니다.
◦ 업로드된 파일을 허용하고 어디에 저장할지 구성할 수 있도록 합니다.
• CGI가 무엇인지 궁금하십니까?
• CGI를 직접 호출하지 않기 때문에 PATH_INFO로 전체 경로를 사용하십시오.
• 청크 요청의 경우 서버는 청크를 해제해야 하며, CGI는 본문의 끝으로 EOF를 기대할 것입니다.
• CGI의 출력에 대해서도 동일합니다. CGI에서 content_length가 반환되지 않으면 EOF가 반환된 데이터의 끝을 표시합니다.
• 프로그램은 요청된 파일을 첫 번째 인수로 CGI를 호출해야 합니다.
• 상대 경로 파일 액세스를 위해 CGI는 올바른 디렉토리에서 실행되어야 합니다.
• 서버는 하나의 CGI(php-CGI, Python 등)와 함께 작동해야 합니다.
평가 중에 모든 기능이 작동하는지 테스트하고 보여줄 수 있는 몇 가지 구성 파일과 기본 기능 파일을 제공해야 합니다.

만약 특정 동작에 대한 질문이 있다면, 프로그램의 동작을 NGINX와 비교해야 합니다.
예를 들어, server_name이 어떻게 작동하는지 확인해보세요.
작동하는 것이 모두 웹 브라우저와 테스트에서 잘 동작한다면 이를 통과시키는 것은 필수가 아니지만, 일부 버그를 찾는 데 도움이 되므로 작은 테스터를 공유해 드렸습니다.

중요한 것은 내구성입니다. 여러분의 서버는 절대로 다운되지 않아야 합니다.

하나의 프로그램으로만 테스트하지 마십시오. Python, Golang 또는 C나 C++과 같은 더 편리한 언어로 테스트를 작성하십시오.

추가 요구사항

추가 기능으로 다음을 추가할 수 있습니다:
• 쿠키 및 세션 관리 지원 (간단한 예제 준비).
• 여러 CGI 처리.
보너스 부분은 필수 부분이 완벽하게 완료되고 정상적으로 작동할 때만 평가됩니다.
완벽하다는 것은 필수 부분이 완벽하게 수행되고 잘못이 없이 작동한다는 것을 의미합니다.
필수 요구 사항을 모두 통과하지 않은 경우 보너스 부분은 전혀 평가되지 않습니다.

사용 가능 함수

Everything in C++ 98.
execve, dup, dup2, pipe, strerror, gai_strerror,
errno, dup, dup2, fork, socketpair, htons, htonl,
ntohs, ntohl, select, poll, epoll (epoll_create,
epoll_ctl, epoll_wait), kqueue (kqueue, kevent),
socket, accept, listen, send, recv, chdir bind,
connect, getaddrinfo, freeaddrinfo, setsockopt,
getsockname, getprotobyname, fcntl, close, read,
write, waitpid, kill, signal, access, stat, open,
opendir, readdir and closedir.

의견 (선택 사항)

자유롭게 서로에게 도움이 될 문서나 의견을 나눌 것에 대해 말씀해주세요.

[seungwonme]

허용 함수 정리

파일 및 프로세스 관리

• execve: 프로세스가 새 프로그램을 실행하게 합니다.

  execve("/bin/ls", args, env);

• dup/dup2: 파일 디스크립터를 복제합니다.

  int newfd = dup(fd);
  dup2(oldfd, newfd);

• fork: 현재 프로세스의 복사본을 생성합니다.

  pid_t pid = fork();

• waitpid: 자식 프로세스가 종료되길 기다립니다.

  waitpid(pid, &status, 0);

• kill: 프로세스에 시그널을 보냅니다.

  kill(pid, SIGKILL);

• signal: 시그널 핸들러를 설정합니다.

  signal(SIGINT, handler);

• chdir: 현재 작업 디렉토리를 변경합니다.

  chdir("/path/to/directory");

• access: 파일의 접근 가능성을 확인합니다.

  access("filename", R_OK);

• stat, open, read, write, close: 파일을 관리합니다.

  stat("filename", &statbuf);
  int fd = open("filename", O_RDONLY);
  read(fd, buffer, size);
  write(fd, buffer, size);
  close(fd);

• opendir, readdir, closedir: 디렉토리를 읽습니다.

  DIR *dir = opendir("path/to/dir");
  struct dirent *entry;
  while ((entry = readdir(dir)) != NULL) { /*...*/ }
  closedir(dir);

네트워킹

• socket, bind, listen, accept, connect: 네트워크 소켓을 관리합니다.

  int sockfd = socket(AF_INET, SOCK_STREAM, 0);
  bind(sockfd, (struct sockaddr *)&my_addr, sizeof(my_addr));
  listen(sockfd, backlog);
  int new_fd = accept(sockfd, (struct sockaddr *)&their_addr, &addr_size);
  connect(sockfd, (struct sockaddr *)&server_addr, sizeof(server_addr));

• send, recv: 네트워크를 통해 데이터를 보내고 받습니다.

  send(sockfd, "Hello, world!", 13, 0);
  recv(sockfd, buffer, bufsize, 0);

• getaddrinfo, freeaddrinfo: 주소 정보를 해석하고 해제합니다.

  getaddrinfo("www.example.com", "http", &hints, &res);
  freeaddrinfo(res);

• setsockopt, getsockname: 소켓 옵션을 설정하고, 소켓의 주소를 얻습니다.

  setsockopt(sockfd, SOL_SOCKET, SO_REUSEADDR, &yes, sizeof(int));
  getsockname(sockfd, (struct sockaddr *)&my_addr, &len);

• htons, htonl, ntohs, ntohl: 호스트와 네트워크 바이트 순서 간의 변환을 수행합니다.

  uint16_t network_order = htons(host_order_short);
  uint32_t host_order = ntohl(network_order_long);

이벤트 및 IO 관리

• pipe: 프로세스 간 통신을 위한 파이프를 생성합니다.

  int fds[2];
  pipe(fds);

• select, poll, epoll (epoll_create, epoll_ctl, epoll_wait), kqueue (kqueue, kevent): 비동기 IO를 관리합니다.

  // epoll 예시
  int epfd = epoll_create1(0);
  struct epoll_event ev, events[MAX_EVENTS];
  ev.events = EPOLLIN;
  epoll_ctl(epfd, EPOLL_CTL_ADD, fd, &ev);
  int nfds = epoll_wait(epfd, events, MAX_EVENTS, -1);

• fcntl: 파일 디스크립터의 플래그를 설정합니다.

  fcntl(fd, F_SETFL, O_NONBLOCK);

오류 관리

• errno: 최근 발생한 오류를 나타내는 전역 변수입니다.
• strerror, gai_strerror: 오류 코드를 문자열로 변환합니다.

  fprintf(stderr, "Error: %s\n", strerror(errno));
  fprintf(stderr, "getaddrinfo error: %s\n", gai_strerror(status));

[fing9]

RFC란 무엇인가?

RFC(Request for Comments)는 "비평을 기다리는 문서"라는 의미로, 특별한 제한은 없지만 보통 프로토콜에 대한 설명, 정형화된 형식등에 대해 설명해둔 문서입니다.

프로토콜이란?

프로토콜은 서로 다른 시스템 및 기기 간 데이터 교환을 원활히 하기 위한 표준화된 통신 규약입니다.

우리는 어떤 RFC를 읽어야 하는가?

저희는 '웹서버'를 만들기 위해서 텍스트 기반의 통신 프로토콜인, HTTP (HyperText Transfer Protocol) 1.1 프로토콜을 지켜야합니다.

최초의 HTTP 1.1의 RFC문서는 RFC-2068입니다.

하지만, 이를 개선한 HTTP 1.1의 최신 RFC는 RFC 7230 ~ 7235로 6개로 나뉘어서 개정됐습니다.

따라서 저희는 RFC 7230 ~ 7235를 레퍼런스로 읽도록 하겠습니다.

RFC 번역본 링크

RFC 7230 - HTTP/1.1 : Message Syntax and Routing 번역
RFC 7231 - HTTP/1.1 : Semantics and Content 번역
RFC 7232 - HTTP/1.1 : Conditional Requests 번역
RFC 7233 - HTTP/1.1 : Range Requests 번역
RFC 7234 - HTTP/1.1 : Caching 번역
RFC 7235 - HTTP/1.1 : Authentication 번역

[fing9]

Block이 되지 않는 Webserver를 만들어야 하는데, Thread 함수를 사용하지 않고 어떻게 비동기 작업을 처리할 수 있을까?

여러 입력자에 대해서 이벤트를 기다리는 방식으로 입출력이 처리되는 방식은 일반적으로 Event-Driven 아키텍처를 따라서 구현한다고 합니다.

I/O Multiplexing

I/O Multiplexing은 한국어로 입출력 다중화입니다.
이 멀티플렉싱의 의미는 "다수의 프로세스를 생성하지 않고도 여러 개의 클라이언트에게 서비스를 제공할 수 있는 기술"입니다.
Read 시스템콜과 같은 기본적인 입력은 Blocking I/O로 구현되어 있습니다.
이에 특정 옵션을 주어 Non-Blocking I/O를 설정할 수 있습니다.
똑같이 소켓에도 non-blocking I/O로 지정해서 열 수 있는데, 이를 지정하면 원래 block이 되어야할 상황이 온다면 block이 되는 대신 에러를 반환하고 그대로 지나가는 식으로 작동합니다.
이 non-blocking I/O를 지정해서 연 소켓에 read/write를 계속 한다면 읽을 데이터가 있거나 쓸 데이터가 있을 때까지 시스템콜이 발생합니다.
이런 요청을 계속 보내면서 응답을 조사하는 것을 폴링(Polling)이라고 합니다.
이런 폴링을 여러개의 fd에 대해서 수행해서 하나의 프로세스에서 여러 소켓의 요청을 대기하고 처리할 수 있는 것이 입출력 다중화입니다.

물론 이 폴링은 I/O Multiplexing이 아닌 멀티 쓰레드로 처리할 수 있습니다.
하지만 프로세스와 쓰레드 생성시 비용, 프로세스와 쓰레드간의 통신, 프로세스와 쓰레드 동기화를 고려해서 멀티 쓰레드가 아닌 I/O Multiplexing을 사용한다고 합니다.
I/O 멀티플렉싱을 대체 왜 쓰는지에 대한 더 자세한 설명

K-Queue

K-Queue는 이벤트 관리 시스템 콜 중 하나입니다.
등록된 여러 fd를 지켜보다가 Read/Write 가 준비됐는지를 감지하는 역할을 합니다.
이를 통해서 I/O Multiplexing을 이용하는 서버를 만들 수 있습니다.
K-Queue 사용법

직접 소켓을 순회하면 되지 K-Queue를 왜 사용하는 것인가?

왜 polling을 프로세스가 직접 순회하면서 소켓을 감지하게 구현하지 않는거지? 라는 의문이 들어서 찾아보았습니다.

모든 디스크립터는 커널 내에서 파일 엔트리라는 데이터 구조를 가리킵니다. 파일 엔트리는 파일 엔트리 개체의 시작부터 바이트 단위로 디스크립터당 파일 오프셋을 유지합니다. open 시스템 호출은 새로운 파일 엔트리를 생성합니다.

디스크립터는 새 입력의 도착이나 소켓 연결의 완료 또는 이전에 완전한 소켓 전송 버퍼에 공간이 생긴 경우(TCP가 소켓 피어로 데이터를 전송한 후)와 같이 I/O 이벤트가 발생할 때 준비 상태로 변경됩니다.
그렇기 때문에 커널이 입출력 가능여부를 탐지하는 것이 더 효율적입니다.

폴링을 직접 하지 않고 커널에 맡기는 이유

의견 및 공부 정리

처음에 조사할 때는 왜 쓰레딩이 아니라 I/O Multiplexing을 굳이 이용시키는지 의문이 있었는데 조사하면서 쓰레드의 생성 제한과, 컨텍스트 스위칭에 드는 오버헤드가 많이 크다는 것을 알 수 있었습니다.

또한 커널에서 fd를 관리하므로 폴링에 대한 오버헤드도 커널에서 해주는게 프로세스가 직접 하는 것보다 적다는 것을 알 수 있었습니다.
I/O 멀티플렉싱과 epoll

[seungwonme]

CGI란 무엇인가?

• CGI(Common Gateway Interface)는 웹 서버와 외부 프로그램 간의 인터페이스
• CGI 프로그램은 보통 웹 form에서 입력된 데이터를 처리하거나 데이터베이스 쿼리 결과를 웹 페이지로 반환하는 등의 작업을 수행
  • 회원 가입, 검색 등을 예로 들 수 있음
• cgi-bin/ 폴더에 스크립트 혹은 실행 파일로 구현하는 것이 관례

장점

1. 구현이 간단하다.
2. 언어, 플랫폼 독립적이다.
3. 2번의 장점 덕분에 재사용성이 좋다.

단점

1. 클라이언트의 요청마다 프로세스 생성(fork), CGI 프로그램 실행(execve), DB connection이 필요하므로 속도가 느리고 메모리를 많이 잡아먹는다.
2. 페이지 로드 사이에 데이터가 메모리에 캐시될 수 없다. (서버 실행파일과 CGI 프로그램은 다르므로)
3. 스크립트 혹은 인터프리터 CGI 프로그램일 경우 실행할 때마다 코드 해석의 과정이 필요하다.

CGI를 대체하는 기술들

위에 서술한 단점들을 극복하기 위한 여러 기술과 접근 방식이 시간이 흐르며 등장

FastCGI

• 탄생 배경: CGI의 단점을 극복하기 위해 1990년대 중반에 개발
• 특징: FastCGI는 프로세스를 재사용하여, 각 요청마다 새로운 프로세스를 생성하는 대신 이미 실행 중인 프로세스를 사용해 요청을 처리한다. 이는 메모리 사용량을 줄이고, 실행 시간을 단축시키는 효과가 있다.

서버 사이드 스크립트 언어와 통합 모듈

• 예시: PHP, Python (mod_python), Ruby (mod_ruby), Perl (mod_perl)
• 탄생 배경: FastCGI보다 더 통합된 방식을 제공하기 위해, 1990년대 후반부터 각각의 스크립트 언어는 웹 서버와 직접 통합될 수 있는 모듈을 개발
• 특징: 이 방식은 웹 서버와 언어 인터프리터를 밀접하게 통합하여, 인터프리터가 웹 서버의 일부로 실행된다. 이는 성능을 크게 향상시키고, CGI보다 훨씬 효율적인 실행을 가능하게 한다.

웹 어플리케이션 서버

• 예시: Tomcat (Java), Django (Python), Ruby on Rails (Ruby), Node.js (JavaScript)
• 탄생 배경: 2000년대 초반부터 복잡한 웹 어플리케이션의 개발과 배포를 용이하게 하기 위해 등장
• 특징: 웹 어플리케이션 서버는 웹 서버와 어플리케이션 로직 사이의 중간 계층으로서 작동하며, 요청 처리를 위한 전체 생명주기 관리, 데이터베이스 연결 관리, 세션 관리 등을 제공한다. 이는 어플리케이션의 개발과 유지보수를 훨씬 용이하게 한다.

AJAX와 Single Page Application (SPA)

• 탄생 배경: 2000년대 중반, 웹 어플리케이션의 사용자 경험을 향상시키기 위해 등장
• 특징: AJAX는 비동기적 웹 어플리케이션의 제작을 가능하게 하여, 페이지 전체를 새로고침하지 않고도 일부분만 업데이트할 수 있게 했다. SPA는 웹 어플리케이션을 하나의 페이지로 구성하되, 사용자와의 상호작용에 따라 동적으로 콘텐츠를 업데이트한다. 이는 서버 부하를 줄이고 사용자 경험을 크게 개선시킨다.

정리

• CGI(Common Gateway Interface)는 초기 웹 개발에서 동적 콘텐츠를 생성하기 위한 주요 방법이며 실행 파일 혹은 스크립트로 구현한다.
• 레거시 시스템이며 현재는 웹 어플리케이션 서버, SPA를 통해서 웹 서버의 동적 콘텐츠 생성을 가능하게 함

참고

• CGI와 웹서버
• CGI - 해시넷
• CGI 프로그래밍 맛보기 | 전두엽을 깨우는 블로그
• Common Gateway Interface