홈으로

webserv study 5

April 22, 2022

2022-04-20

select

select가 readable이라고 판단하는 경우는

1. 값을 읽을 수 있는 경우
2. disconnect인 경우(poll도 마찬가지로 연결을 정상 종료한 client socket을 readable이라고 판단한다.)

• select()에서 errorfds는 error output을 의미하는 것이 아니라 error가 발생했을 때 set된다.

https://yeosong1.github.io/webserv

• 상태별 html 파일이라고 하는 것을 보니 fully static website를 구현하기 위한 것일 것 같다.
• 전에 fork를 소스 코드를 따오는 것으로 생각했었는데 이 글을 보고 다시 생각해보니 ‘CGI 이외의 용도(예 : php, perl, ruby 등..)에는 fork를 사용할 수 없습니다.’ 이 문장의 fork는 fork()인 것 같다.

2022-04-21

https://developer.ibm.com/articles/l-async/

Asynchronous blocking I/O

https://evan-moon.github.io/2019/09/19/sync-async-blocking-non-blocking/#동기-방식–논블록킹-방식

동기(Synchronous)는 정확히 무엇을 의미하는걸까?

asynchronous blocking I/O

• select() 같은 multiplexer가 비동기 블로킹 방식이다.
• 두 번째 페이지는 왜 이런 방식이 탄생했는지 잘 설명하고 있다.
• 특히 synchronous라는 단어를 자신만의 방식으로 구체적으로 정의하고 있는 부분이 마음에 들었다.
  • 작업의 순서를 보장하는 성질을 synchronous라고 한다.

https://homoefficio.github.io/2017/02/19/Blocking-NonBlocking-Synchronous-Asynchronous/

Blocking-NonBlocking-Synchronous-Asynchronous

• 여기서도 synchronous에 대해 같은 결의 설명을 하고 있다.

1. 동기 & 블록킹 I/O의 경우 직관적이나, 여러 개의 I/O를 동시에 처리할 수 없다.
2. 논블록킹 I/O는 프로세스들의 작업을 컨트롤하는 것이 까다롭다. (대부분 이런 저레벨 프로그램은 C로 짠다. JS나 Python 같은 걸 생각하면 안된다.)
3. 그렇다고 동기 & 블록킹 I/O와 멀티 프로세싱이나 쓰레딩을 결합해서 쓰자니 자원 문제도 있고 프로세스/쓰레드 간 통신이나 동기화가 빡셈

• 첫 번째 페이지는 select()의 구체적인 동작을 묘사하고 있다.
  • select()를 큰 틀에서 보면 blocking이지만 fd는 non-blocking I/O를 사용한다.
  • 이는 위와 같은 이유로 select()가 비동기 블로킹 방식이 필요했기 때문에 채택한 구현 방식이다.
  • 내부적으로 non-blocking I/O가 여러 fd들을 확인하기 때문에 asynchronous라고 하는 것이다.(fd와 matching하는 반대편에서 작업을 하는 중이든 끝난 상황이든 상관 없이 지금 상태만 확인하고 다음 fd를 확인하러 넘어감)
  • 만약 blocking I/O를 사용한다면 한 fd에서 blocking되어 여러 fd를 확인할 수 없다.
• 사실상 2x2 matrix에 속하는 특징을 갖는 상황의 함수가 존재하고 그걸 구현하는 것이 아니라,
• 어떤 기능을 구현했을 때 그것을 관점에 따라 이렇게도 해석할 수 있고 저렇게도 해석할 수 있는 문제라고 생각한다.

int main(configuration file)
	check validity of configuration file

https://nginx.org/en/docs/beginners_guide.html

Beginner’s Guide

directive =			simple-directive / block-directive
simple-directive =	name SPACES *parameter ";"
block-directive =	name SPACES *parameter "{" *instruction "}"
context =			name SPACES *parameter "{" *(instruction / directive) "}"

• example of context: events, http, server, location
• context 밖에 존재하는 directive들은 main context에 있는 것으로 간주한다.

main {
	events {}
	http {}
}

http {
	server {}
}

server {
	location {}
}

• The rest of a line after the ‘#’ sign is considered a comment

location / {
	root /data/www;
}

• 어떤 path가 여러 location block과 일치하면 가장 긴 접두사를 선택한다.
• 위의 location block의 접두사 길이는 1이기 때문에 다른 location block과 전부 불일치하는 경우 이 블럭이 사용될 것이다.

server {
	location / {
		root /data/www;
	}

	location /images/ {
		root /data;
	}
}

• 위의 configuration은 localhost의 80번 포트를 listen하는 실행 가능한 configuration이다.

server {
	listen 8080;
	root /data/upl;

	location / {
	}
}

• 선택된 location block이 root directive를 가지고 있지 않을 때 server 안의 root directive를 사용한다.

server {
	location ~ .php$ {
		root /data
	}
}

• 위 정도로 CGI program route를 설정할 수 있도록 하면 될 것 같다.
  • php 대신 cgi가 될 수도 있고 py가 될 수도 있고

configuration file 에러 상황 예시

server {
	listen 80 default_server;
	listen [::]:80 default_server;

	root /var/www/html;

	index index.html index.htm index.nginx-debian.html;

	server_name _;

	location / {
		try_files $uri $uri/ =404;
	}
}

server {
	listen 80 default_server;
	listen [::]:80 default_server;

	root /var/www/html;

	index index.html index.htm index.nginx-debian.html;

	server_name _;

	location / {
		try_files $uri $uri/ =404;
	}
}

• 같은 이름의 server가 2 개 존재하는 경우

root@2fef7e25b01f:/etc/nginx/sites-available# nginx -s reload
nginx: [emerg] a duplicate default server for 0.0.0.0:80 in /etc/nginx/sites-enabled/default:74
root@2fef7e25b01f:/etc/nginx/sites-available# 

• 이런 식으로 만약 파싱 중에 에러가 발생할 수 있다.
• 읽으면서 모든 에러를 바로 판단하도록 만들면 프로그램이 복잡해질 것 같다.
• 단계를 나눠서 구현하면 좋을 것 같다.
• configuration file을 파싱해오는 작업은 webserv 시작에 단 한 번 시행하므로,
• 성능 최적화에 무게를 두기 보다는,
• 작업이 다소 반복될 수 있더라도 각 절차가 행하는 행동이 뚜렷하도록 구현하는 것에 무게를 두는 것이 좋을 것 같다.

1. configuration file을 파싱해서 메모리에 구조화하여 저장한다.
	단순 문법적 오류에 대해 에러를 발생시킨다. ( ex: "{}"를 사용하기로 약속했다면 여는 괄호와 닫는 괄호가 짝이 맞는가? )
	일단 전부 string으로 값을 읽어온다.
2. 여러 방식으로 에러 check를 진행한다.
	1. directive가 올바른가? ( ex: 구현하지 않은 directive )
	2. directive의 인자가 올바른가? ( ex: checkListen(), checkIndex() )
		- directive에 따라 인자의 type, 인자의 범위, 인자의 갯수 등 확인
3. 파싱해온 값으로 server의 변수들을 설정한다.

for (fin >> string) {
	if (string is syntax error)
		handle error;
	else
		parser.add(string);
}

try {
	server.setWithParser(parser);
}
catch (server set error) {
	handle error;
}

• safari는 https가 아닌 http 페이지는 열지 못한다.
• 따라서 https를 구현하지 않는 우리 web server의 타겟 클라이언트는 chrome이나 firefox가 좋아보인다.
  • (https 구현 안하는거 맞죠?)