웹 서버

드디어 다시 시작한다.!!!
이 번장에서 배우는 것은 다음과 같다고 한다.
- 여러 종류의 소프트웨어 및 하드웨어 웹서버에 대해 조사한다.
- HTTP 통신을 진단해주는 간단한 웹 서버를 펄로 작성해본다.
- 어떻게 웹 서버가 HTTP 트랜잭션을 처리하는지 단계별로 설명한다.
난 자바로 개발하는데 펄이 이라니...
감사합니다

다체로운 웹 서버

웹 서버는 다양한 크기가 존재한다.
웹 서버는 웹 서버 소프트웨어와 웹페이지 제공에 특화된 장비 양쪽 모두 가리킨다.
하지만, 결국 클라이언트에게 HTTP 요청을 전달하는 것은 변함이 없다.

웹 서버 구현

웹 서버는 자신이 제공하는 리소스를 관리하고 웹 서버를 설정, 통제, 확장하기 위한 기능을 제공한다.
웹 서버는 운영체제와 TCP 커넥션 관리에 대한 책임을 나눠갖는다.
운영체제는 컴퓨터 시스템의 하드웨어를 관리하고 TCP/IP 네트워크 지원, 웹 리소스를 유지하기 위한 파일 시스템,
현재 연산 활동을 제어하기 위한 프로세스 관리를 제공한다.

다 목적 소프트웨어 웹 서버

다 목적?
목적이 많다.
다양하게 사용할 수 있다라는 건가..
종류로는
아파치, W3C의 직소 오픈 소프트웨어 또는
마이크로소프트, 아이플래닛의 웹 서버 상용 서비스
를 이용할 수 있다.
넷크래프트의 조사를 확인해보자.
책이 오래 되었나보다.

August 2014 Web Server Survey | Netcraft News

책에 나온 자료는 2014년 자료다.
그 중에서 우리가 확인할 것은

이 부분이다.
하지만 우리는 2021년에 살고 있기 때문에
2021년 자료도 같이 보자.

May 2021 Web Server Survey | Netcraft News

현재는 nginx가 일위다 오오

마소는 어쩌다 저렇게 되었을까? ㅜㅜ
2014년 1위인데...
그리고 nginx는 어떻게 1위를 할 수 있었을까?
솔직히 지금은 아파치랑 nginx빼면 별 볼일 없는 것 같다.
나중에 nginx를 공부해서 어떻게 nginx는 웹 서버 시장에서 1위를 차지했는지 알고 싶어졌다.

임베디드 웹 서버

- 일반 소비자용 제품에 내장될 목적으로 만들어진 작은 웹 서버이다.
예시) 아이픽 성냥 머리 크기 웹서버

Got a Match?

들어가기 더럽게 어렵네..
한 개더 있는데 안들어가진다.
아무튼 임베디드는 작은 웹서버다.

간단한 펄 웹 서버

HTTP/1.1을 지원하려면, 풍부한 리소스 지원, 가상 호스팅, 접근 제어, 로깅, 모니터링, 그 외 성능을 위한 각종 기능이 필요하다.
최소한의 기능하는 HTTP서버 라면, 30줄 이하의 펄 코드로도 만들 수 있다고 한다.
만들어 보자.

#!/usr/bin/perl use Socket; use Carp; use FileHandle; $port = (@ARGV ? $ARGV[0] : 8080); $proto = getprotobyname('tcp'); socket(S, PF_INET, SOCK_STREAM, $proto) || die; setsocket(S, SOL_SOCKET, SO_REUSEADDR, pack("l", 1)) || die; bind(S, sockaddr_in($port, INADDR_ANY)) || die; listen(S, SOMAXCONN) || die; printf(" <<<Type-O-Serve Accepting on Port %d>>>\n\n",$port); while(1) { $cport_caddr = accept(C,S); ($cport,$caddr) = sockaddr_in($cport_caddr); C->autoflush(1); $cname = gethostbyaddr($caddr,AF_INET); printf(" <<<Request From '%s'>>>\n", $cname); while($line = <C>) { print $line; if($line =~ /^\r/) {last;} } printf(" <<<Type Response Followed by '.'>>>\n"); while($line = <STDIN>) { $line =~ s/\r//; $line =~ s/\n//; if($line =~ /^\./) {last; } print C $line . "\r\n"; } close(C); } 

책에 나온대로 작성해봤다.
나는 web.pl로 만들었기 때문에
perl web.pl 8080으로 접속한다.

이 코드는 단순히 HTTP 메시지를 보여줄 뿐이다.
8080으로 접속하면 재미없으니까 7000으로 접속해보자.

<<<Type-O-Serve Accepting on Port 7000>>>
그러면 이렇게 미리 세팅된 메시지가 나온다.

이제 localhost:7000으로 접속해보자.

그러면 이렇게 동작하고 있다는 것을 알수 있다.
그러면 이게 동작하고 있는지 알 수 있는 방법은 간단하다.

이렇게 무한정으로 동작하고 있다는 것을 알 수 있다.
그러면 일반적인 서버와 다른점은 이것 같은 경우는 그 다음을 코딩하지 않았기 때문이다.
근데 생각보다 다른 언어로도 충분히 할 수 있을 것 같다.
예를 들면 자바로?
만들어 볼까......???
다음처럼 작성하면 된다.

public static void main(String[] args) throws IOException { int port = 7777; // tcp 지정 udp: DatagramSocket try (ServerSocket listen = new ServerSocket(port)) { Socket connection; while ((connection = listen.accept()) != null) { InputStream inputStream = connection.getInputStream(); int data; while ((data = inputStream.read()) != 0) { System.out.print((char) data); } } } }

그러면 같은 결과를 얻을 수 있다.

GET / HTTP/1.1 Host: localhost:7777 Connection: keep-alive Cache-Control: max-age=0 sec-ch-ua: " Not A;Brand";v="99", "Chromium";v="90", "Google Chrome";v="90" sec-ch-ua-mobile: ?0 Upgrade-Insecure-Requests: 1 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4430.212 Safari/537.36 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9 Sec-Fetch-Site: none Sec-Fetch-Mode: navigate Sec-Fetch-User: ?1 Sec-Fetch-Dest: document Accept-Encoding: gzip, deflate, br Accept-Language: ko-KR,ko;q=0.9 

펄이랑 같은 결과를 출력 했다.
생각보다 간단한데...
뭐 이거말고 다른것도 할 수 있는데 여기에서는 이쯤까지만 하구

진짜 웹 서버가 하는 일

진짜 웹서버는 위에서 하는 일 말고 다양한 일들을 수행한다.
그들은 7가지의 공통적인 일들을 수행한다고 한다.
그러면 하나씩 살펴보면서 공부해보자.

1단계 : 클라이언트 커넥션 수락

커넥션을 수락한다라...
서버와 클라이언트가 약속을 잡는 그런 느낌인가?

그러면 클라이언트와 서버가 어떻게 커넥션을 수락하는 과정을 자세하게 살펴보자.

새 커넥션 다루기

처음에 무조건 새 커넥션을 받겠지?

아 이런 느낌인가 커넥션이라는게...
커넥션이라는게 한번만 맺어진는게 아니구나
서버는 커넥션 목록을 추가하고 커넥션에서 오가는 데이터를 지켜보기위한 준비를 한다라...
그러니가 약속을 한번만 하는게 아니라 여러번 할 수 있구
선물을 일방적으로 한쪽에서 주는구나...ㅎ
선물 주는 쪽이 클라이언트쪽이고
서버는 그걸또 거절 할 수 있다네
그러니까 이것을 굳이 해석하면 서버가 갑이고 클라이언트가 을이고
서버가 클라이언트와의 약속에 대한 권한을 가지니까
거절 할 수 도 있고 그 약속을 없던걸로 만들 수 있는걸로 이해 된다.

클라이언트 호스트 명 식별

클라이언트 IP주소를 클라이언트의 호스트 명으로 변환하도록 설정하는 것이 역방향 DNS라고 한다.
(반대로 알고 있었네...ㅎ)
아무튼 웹 서버가 이 역할을 한다고 한다.
참고로 호스트 명 룩업은 웹 트랜잭션을 느리게 할 수 있다고 한다.
(룩업은 찾다라는 뜻이다.)
그러면 따지고 보면 역방향 DNS도 호스트명 룩업이라는 이야기인데...
아무튼 많은 대용량 웹 서버는 호스트 명 분석(hostname resolution)을 꺼두거나 특정 콘텐츠에 대해서만 켜놓는다고 한다.
* 아파치에서는 HostnameLookups 설정 지시자로 켤 수 있다고 한다.

HostnameLookups off <Files ~"\.(html|htm|cgi)$"> HostnameLookups on </Files>

이거는 HostnameLookups를 이용해서 html과 cgi를 켠 모습니다.
그러면 이것을 끈 다고 생각해보면, ip주소로만 접속해야하는건가....
잘 모르겠다.
아무튼 서버가 이런일도 하는구나 생각이 든다.
근데 cgi가 뭐냐

공용 게이트웨이 인터페이스 - 위키백과, 우리 모두의 백과사전

이런거랍니다. ㅎ

ident를 통해 클라이언트 사용자 알아보기

ident?
서버에게 어떤 사용자 이름이 HTTP 커넥션이 초기화했는지 찾아낼 수 있게 해준다.
일단 네이버 아이디 같은 건 아닐테고
아이피 주소 같은건가....
아무튼 클라이언트가 ident 프로토콜을 지원 한다면, 클라리언트는 ident 결과를 위해
TCP 포트 113번을 listen한다.
서버는 그 후 자신의 커넥션을 클라이언트의 identd 서버 포트를 향해 열고,
새 커넥션에 대응하는 사용자 이름을 묻는 간단한 요청을 보낸다.
조직 단위로는 잘 사용하지만,
공공 인터넷 환경에서는 다음과 같은 이유들로 사용하지 않는다고 한다.
- 많은 클라이언트 PC는 identd 신원확인 프로토콜 데몬 소프트웨어를 생행하지 않는다.
- ident 프로토콜은 HTTP 트랜재션을 유의미하게 지연시킨다.
- 방화벽이 ident 트래픽이 들어오는 것을 막는 경우가 많다.
- ident 프로토콜은 안전하지 않고 조작하기 쉽다.
- ident 프로토콜은 가상 IP 주소를 잘 지원하지 않는다.
- 클라이언트 사용자 이름의 노출로 인한 프라이버시 침해의 우려가 있다.

ident가 동등성을 체크하는 것 같다.

2단계 : 요청 메시지 수신

커넥션에 데이터가 도착한다는건
약속을 수락했다는 거지...
웹 서버는 네트워크 커넥션에서 그 데이터를 읽어 들이고 파싱하여 요청 메시지를 구성한다.

파싱(parsing) | 과학문화포털 사이언스올

왠지 어려지는 기분이 드는 곳이다.ㅎ
요청 메시지를 파싱할 때, 웹 서버는 다음과 같은 일을 한다.
- 요청줄을 파싱하여 요청 메서드, 지정된 리소스의 식별자, 버전 번호를 찾는다.
- 각 값은 스페이스 한 개로 분리되어 있으며, 요청줄은 캐리지 리턴 줄바꿈 문자열로 끝난다.

그렇다고 합니다.&nbsp;

- 메시지 헤더들을 읽는다. 각 메시지 헤더는 CRLF로 끝난다.
- 헤더의 끝을 의미하는 CRLF로 끝나는 빈 줄을 찾아낸다.(존재한다면)
존재한다면? 그렇다는건 없을 수도 있다는 거네...
- 요청 본문이 있다면, 읽어드린다.
웹 서버는 파싱해서 이해하는 것이 가능한 수준의 분량을 확보할 때까지 데이터를 네트워크로부터 읽어서 메시지 일부분을 메모리에 임시로 저장해 둘 필요가 있다.
확보할때까지????

이해가 가능한 수준의 분량??
얘네도 암기하나... 컴퓨터라고 만능은 아닌건가...
아무튼 이렇게 확보한 데이터를 임시로 저장해둔다? 이게 캐시인가? 뭐 지금은 틀려도 상관없지 왜냐하면 추후에 배울테니
데이터를 네트워크로 부터 읽는다.
네트워크...

메시지의 내부 표현

이건 그림을 봐야 이해가 되는데. 그리기 귀찮기는 한데 그려보자.!

책에는 이것보다 더 자세하게 작성이되어있다.
그러니 책을 보는 것을 추천한다.
이것이 뭐냐면 요청 메시지가 어떻게 표현이 되는지 조금더 이해가 되기 쉽게 정리해놓은거라 생각한다.
정리되면 사람이나 기계나 조금더 빨라지는 것 같다.
정리하면 보통 자료구조 Map으로 하는게 더 효율적일 것 같은데...
왜냐하면, Map에는 키와 값 존재해서 키를 가지고 값을 바로 찾을 수 있기 때문이다.
아 찾기 귀찮아...
List로 하나씩 비교하는게 빠를까? 아니면 key를 이용해서 바로 value찾는것이 빠를까?

커넥션 입력/출력 처리 아키텍쳐

당연한 말이지만, 고성능 웹 서버를 이용하면, 수 천개의 커넥션을 동시에 열 수 있다고 한다.
그러니까 고성능이지.
모든 웹 서버가 같은 방식으로 동작하지는 않을 것이다.
만약, 같은 방식으로 동작을 한다면, 다양한 웹 서버가 등장할 수 있었을까?
그냥 아파치만 쓰면 되는데 nginx라는 것도 등장하고 지금은 미비하지만 언젠가 성장할 가능성이 있을런지도 모를 가능성이 있는(대충 어떻게 될지 모른다는 뜻) google등 많이 등장했다.
지금부터 하나씩 보면서 어떤 특징이 있는 지 살펴보자.
웹 서버를 말하는게 아니라 웹 서버의 아키텍쳐에 대해 살펴볼것입니다.
단일 스레드 웹 서버

하나의 한번에 하나씩 요청을 처리하는 것이라고 한다.
참고로 스레드는 일꾼이다.
즉, 일꾼이 한명이니 하나의 요청(커넥션)만 처리 할 수 있다.
만약, 다른 커넥션을 처리해야되는 상황이라면? 무시한다.
왜냐하면 지금 하는 것도 바쁜데 뭘 더 하냐고
참고로 위에서 만든 웹 서버가 이거에 해당된다고 한다.
당연히 nginx, 아파치 등들은 단일 스레드 웹 서버는 아니겠지...
그림을 그려보면 다음과 같다고 한다.

마지막에 NG가 있었지만 귀찮아서 그냥 올립니다.

지금 그림을 보면 커넥션 목록에서 하나씩 나와서 커넥션이 이뤄진다음 다음 것으로 넘어가는 걸 확인 할 수 있다.
이것이 바로 단일-스레드 I/O 아키텍처이다.
멀티프로세스와 멀티스레드 웹 서버
이것은 위방법과 다르게 프로세스 또는 스레드가 하나가 아니라는 뜻이다.
결국 일꾼이 많다는 이야기인데
일꾼이 많으면 좋은데 돈이 많이 든다.
그렇다고 일 못하는 인원을 쓰면 혼자 일하는 것보다 효율이 안나오고...
그러니 좋은 일꾼을 쓸 수 밖에 없다. 그래서 일꾼을 많이 사용하면 그 만큼 비용이 많이 들기 때문에 최대 인원을 정한다고 한다.
책에서는 프로세스를 어떤 프로그램이 자신만의 변수 집합을 갖는 하나의 독립된 제어 흐름이다. 스레드는 프로세스의 더 효율적인 버전이라는 것으로 봐서 비슷한 용어로 설명하는 것 같다.
이것도 그려보자. 근데 그릴 수 있나...

동시라고 이해해주세요. 힘듭니다.

멀티 스레드 환경이라 먼저 시작했다고 먼저 끝나지 않는다는 것을 알 수 있다.
자세히 보면 두 번째가 먼저 종료 되었다.

다중 I/O 서버
많은 웹 서버가 이 아키텍쳐를 선택했다고 한다.
내가 이해한게 맞다면, 모든 커넥션은 동시에 그 활동을 감시 당한다고 했으니...

일단 그려보자. 이게 맞나...

몰라 그냥 대충 그렀어

이렇게 그린 이유는 커넥션이 끊어지지 않는 것이 중요하다고 생각했고,
마치 I/O환경이 여러개인것 처럼 활동하는 그런건가...

다중 멀티 스레드 웹 서버
이거는 멀티 커넥션을 여러개 한걸로 이해 된다.
마치 멀티 프로세스와 다중 I/O가 합쳐진 느낌이라 생각이 들어서 굳이 그리지 않았다.

3단계 : 요청 처리

요청을 받았으니 요청을 처리하는 것이 도리지. ㅇㅇ

도리

GET은 데이터를 가져오고 POST는 데이터를 보내고 PUT은 수정하고 DELETE는 지우고
OPTIONS은 어떤 메소드인지 확인하고
HEAD는 어떤 헤더를 사용하는지 확인하고 마지막으로 TRACE는 진단하는 방식을 이용한다.

4단계 : 리소스의 매핑과 접근

요청을 처리했으니 리소스에 접근해야지 ㅇㅇ
웹 서버는 리소스 서버다.
콘텐츠를 제공한다.
웹 서버가 클라이언트에 콘텐츠를 제공하려면, 그전에 요청 메시지의 URL에 대응하는 알맞은 콘텐츠나 콘텐츠 생성기를 웹 서버
에서 찾아서 그 콘텐츠를 원천을 식별해야 한다.

Docroot
리소스 매핑의 가장 단순한 형태는 요청 URL를 웹 서버의 파일 시스템 안에 있는 파일 이름으로 사용하는 것이다.
일반적으로 웹 서버 파일 시스템의 특별한 폴더를 웹 콘텐츠를 위해 예약 해 둔다.
웹 서버는 요청 메세지에서 URL를 가져와서 문서 루트에 붙인다.

그러니까 요청 메시지가 들어왔어.
예를 들어, XXXXX.gif파일이 들어왔어.
그리고 웹 서버에 저장되겠지..
근데 문제는 어디에 사용이 되냐가 문제인데...
문서 루트를 미리 정해서 그곳에 사용한다라고 이해가 된다.
아파치에서는 httpd.conf 설정 파일에 DocumentRoot줄을 추가하여 웹 서버의 문서 루트를 설정 할 수 있다고 한다.

DocumentRoot /usr/local/httpd/files

- 서버는 상대적인 url이 docroot를 벗어나서 파일 시스템의 docroot 이외 부분이 노출되는 일이 생기지 않도록 주의해야 한다.

가상 호스트된 docroot
- 웹 서버는, 각 사이트에 그들만의 분리된 문서 루트를 주는 방법으로 한 웹 서버에서 여러 개의 웹 사이트를 호스팅 한다.
하나의 웹 서버에서 두 개의 사이트가 완전히 분리가 된다라..
그러니까 일반 docroot같은 경우는 하나의 url만 허용하는데 이것 같은 경우는 2개 이상도 가능하다는 건가..
naver, daum이 같은 웹 서버를 사용한다고 한다면, 적절하게 docroot를 정해서 그곳을 사용한다는 것 같다.
아파치에서는 VirtualHost블록을 이용하면 사용할 수 있다고 한다.

<VirtualHost www.joes-hardware.com> DocumentRoot /docs/joe </virtualHost> <VirtualHost www.mary-hardware.com> DocumentRoot /docs/mary </virtualHost> ... 

다른 속성이 있지만 생략하였다.
근데 왜 가상이라는 단어를 사용하는거야?
그거는 18장에서 자세히 공부한다고 한다니 지금은 이런 용어가 있구나 정도만 알고 넘어가야 겠다.
사용자 홈 디렉터리 docroots
- 사용자들이 한 대의 웹 서버에서 각자의 개인 웹 사이트를 만들 수 있도록 해주는 것이다.
보통 / 과 ~ 다음에 사용자 이름이 오는 것으로 시작하는 URI는 그 사용자의 개인 문서 루트를 가리킨다.

이것도 비슷한 느낌인가?

디렉터리 목록

웹 서버는 경로가 아닌 디렉토리를 가리키는, 디렉터리 URL에 대한 요청을 받을 수 있다.
대부분의 웹서버는 클라이언트가 디렉터리 URL을 요청했을 때 다음과 같이 몇 가지 다른 행동을 취하도록 설정한다.
- 에러를 반환한다.
- 디렉터리 대신 특별한 '색인 파일'을 반환한다.
- 디렉터리를 탐색해서 그 내용을 담은 HTML 페이지를 반환한다.
이것으로 유추하면 에러를 반환하거나 아니면 어떤것을 반환하는 것 같다.
아파지에서는 DirectoryIndex 지시자를 이용해 기본 디렉터리 파일로 사용될 모든 파일의 이름을 우선순위로 나열한다.

DirectoryIndex index.html index.htm home.html home.htm index.cgi

아 그러니까 이중에서 찾는다는 말인가?
- 색인 기능이 꺼져있지 않다면, 많은 웹 서버는 자동으로 그 디렉터리의 파일들의 크기, 변경, 일 및 그 파일에 대한 링크와 함께 열거한 HTML 파일을 반환한다.
- 이렇게 하면, 편하지만, 문제는 불 필요한 파일도 보일 수 있다는 엄청난 단점을 가지고 있다.
디렉터리 색인 파일 자동 생성은 다음과 같은 방법으로 끌 수 있다고 한다.

Options -Indexes

동적 콘텐츠 리소스 매핑

- 요청에 맞게 콘텐츠를 생성하는 프로그램에 URI를 매핑하는 것이다.
동적이라는게 계속 변한다는 건데...
마치 위에서 내가 만든 GIF파일 처럼 계속 적으로 변하는 것을 말한다.
정적 리소스 같은 경우 그것이 URL만 알고 있으면 되는데,
동적 같은 경우는 계속 리소스가 변하기 때문에 URL도 변하지 않을까 추측해본다.
왜냐하면 URI의 I가 고유한다는 뜻이고
동적이라는 뜻은 리소스가 변한다는 건데...
만약, 리소스가 변할때마다 URI가 고정이 되면,
자연스럽게 서로 다른 리소스가 같은 URI를 갖게 되니
URI의 조건에 맞지 않는다.
그래서 변한다고 생각이 드는데
문제는 변하면 서버 입장에서는 어떻게 알까?
대부분의 웹 서버는 동적 리소스를 식별하고 매핑할 수 있는 기본적인 매커니즘을 갖고 있다.
아파치에서는 URI의 경로명이 실행 가능한 프로그램이 위치한 디렉터리로 매핑되도록 설정하는 기능을 제공한다.
그러니까 특정 경로로 들어오면, 그것을 동적 리소스로 인식을 하던가...
아니면 특정 프로그램을 찾는 URI를 만드는것 같다.
이 부분은 조금 추상적이라 설명하기가 어렵다.ㅜㅜ
그러니 그렇구나라고 그냥 넘어가주시면... 하하

웹 초창기에는 CGI를 사용했는데, 서버사이드 애플리케이션 실행을 위한 간단한 인터페이스라고 한다.
오늘날의 애플리케이션 서버는 마이크로 소프트의 액티브 서버 페이지 자바 서블릿 등이 존재한다고 한다.

서버 사이드 인클루드 (Server-Side Includes, SSI)

어떤 리소스가 서버사이드 인쿠르드를 포함하고 있는 것으로 설정되어 있다면, 서버는 그 리소스의 콘텐츠를 클라이언트에게 보내기 전에 처리한다.
서버는 콘텐츠에 변수 이름이나 내장된 스크립트가 될 수 있는 어떤 특별한 패턴이 있는지 검사를 받는다.

접근 제어

접근 제어되는 리소스에 대한 요청이 도착했을 때, 웹 서버는 클라이언트의 IP주소에 근거하여 접근을 제어할 수 있고,
혹은 리소스에 접근하기 위한 비밀 번호를 물어볼 수도 있다.

5단계 : 응답 만들기

- 서버는 요청 메서드로 서술되는 동작을 수행한 뒤, 응답 메시지를 반환한다.

응답 엔티티

트랜잭션이 응답 본문을 생성한다면, 그 내용을 응답 메시지와 함께 돌려보낸다.
만약 본문이 있다면, 응답메시지는 주로 다음을 포함한다.
- 응답 본문은 MIME 타입을 서술하는 Content-Type 헤더
- 응답 본문의 길이를 서술하는 Content-Length 헤더
- 실제 응답 본문의 내용

MIME 타입 결정하기

웹 서버에게는 응답 본문의 MIME 타입을 결정해야 하는 책임이 있다.

우 : 웹 서버

MIME타입과 리소스를 연결하는 여러 가지 방법들이다.

mime.types
- 파일 이름의 확장자를 사용할 수 있다.
- 웹 서버는 각 리소스의 MIME 타입을 계산하기 위해 확장자별 MIME타입이 담겨 있는 파일을 탐색한다.
매직 타이핑(Magic typing)

- 아파치 웹 서버는 각 파일의 MIME 타입을 알아내기 위해 파일의 내용을 검사해서 알려진 패턴에 대한 테이블에 해당하는 패턴이 있는지 찾아 볼 수 있다. (느린 MAP인가..)
- 느리지만, 파일이 표준 확장자가 없이 이름이 지어진 경우에는 유용하다.
유형 명시(Explicit typing)
특정 파일이나 디렉터리 안의 파일들이 파일 확장자나 내용에 상관없이 어떤 MIME 타입을 갖도록 웹 서버를 설정할 수 있다.
유형 협상(Type negotiation)
- 어떤 웹 서버는 한 리소스가 여러 종류의 문서 형식에 속하도록 설정 할 수 있다.
- 웹 서버가 사용자와의 협상 과정을 통해 사용하기 가장 좋은 형식을 판별할 것인지의 여부도 설정 할 수 있다.
- 특정 파일이 특정 MIME타입을 갖도록 할 수 있다.

리다이렉션

웹 서버는 종종 성공 메시지 대신 리다이렉션 응답을 반환한다.
웹 서버는 요청을 수행하기 위해 브라우저가 다른 곳으로 가도록 리다이렉트 할 수 있다.
영구히 리소스가 옮겨진 경우
- 리소스는 새 URL이 부여되어 새로운 위치로 옮겨졌거나 이름이 바뀌었을 수 있다.
- 상태 코드 : 301은 이런 종류의 리다이렉션를 위해 사용된다.
임시로 리소스가 옮겨진 경우
- 만약 리소스가 임시로 옮겨져지거나 이름이 변경된 경우, 서버는 클라이언트를 새 위치로 리다이렉트 하길 바란다.
- 클라이언트가 나중에는 원래 URL로 찾오고 북마크도 갱신하지 않는다.
왜냐하면 임시니까.
- 상태 코드 : 303, 307이 이런 종류에 사용된다.
URL 증강
- 재 작성된 URL로 리다이렉트 한다.
- 요청이 도착했을 때, 서버는 상태 정보를 내포한 새 URL을 생성하고 사용자를 새 URL로 리다이렉트 한다.
- 클라이언트는 리다이렉트를 따라가서, 이번엔 상태 정보가 추가된 완전한 URL을 포함한 요청을 다시 보낸다.
- 트랜잭션간 상태를 유지하는 방법이다.
- 상태코드 : 303,307이 이런 종류에 사용된다.
부하 균형
- 만약, 과부화된 서버가 요청을 받으면, 서버는 클라이언틀르 좀 덜 부하가 걸린 서버로 리다이렉트 할 수 있다.
- 상태 코드 : 303, 307
친밀한 다른 서버가 있을 때
- 서버는 어떤 사용자의 정보를 가질 수 있다.
- 서버는 클라이언트를 그 클라이언트에 대한 정보를 갖고 있는 다른 서버로 리다이렉트 할 수 있다.
- 상태 코드 : 303, 307
디렉터리 이름 정규화
- 클라이언트가 디렉터리 이름에 대한 URL를 요청하는데 끝에 빗금(/)을 빠뜨렸다면, 대부분의 웹 서버는 상대경로가 정상적으로
동작할 수 있도록 클라이언트를 슬래시를 추가한 URL로 리다이렉트한다.

6단계 : 응답 보내기

- 서버는 여러 클라이언트에 대한 많은 커넥션을 가질 수 있다.
- 서버는 커넥션 상태를 추적해야 하며, 지속적인 커넥션은 특별히 주의해서 다룰 필요가 있다.
- 비 지속적인 커넥션이라면, 서버는 모든 메시지를 전송했을 때 자신쪽의 커넥션을 닫을 것이다.
- 지속 커넥션이라면, 서버거 Content-Length 헤더를 바르게 계산하기 위해 특별한 주의를 필요로 하는 경우나
클라이언트가 언제 끝나는지 알 수 없는 경우에 커넥션은 열린 상태를 유지할 것이다.

7단계 : 로깅

- 트랜잭션이 완료되었을 때 웹 서버는 트랜잭션이 어떻게 수행되었는지에 대한 로그를 로그파일에 기록한다.

참고 자료

https://www.w3.org/Jigsaw/
https://datatracker.ietf.org/doc/html/rfc1413
이번에도 대충한것 같군...