웹 서버, 다양한 해석의 여지가 다분한 용어이다.
그래서 이번 단원에서는 웹 서버의 어떤 특징에 관한 공부를 할 지 간략하게 정리하자면 다음과 같다.
- 웹 서버의 물리적인 형태의 종류
- 어떻게 웹 서버가 HTTP 트랜잭션을 처리하는지 단계별로 설명
이렇게만 봐서는 뭘 말하고 싶은지 잘 모르겠다, 일단 가보자!
중요하다고 생각한 점
웹 서버 구현
웹 서버는 HTTP 프로토콜을 구현하고, 웹 리소스를 관리하고, 웹 서버 관리 기능을 제공한다. 웹 서버는 TCP 커넥션 관리에 대한 책임을 운영체제와 나눠 갖는다. 운영체제는 컴퓨터 시스템의 하드웨어를 관리하고 TCP/IP 네트워크 지원, 웹 리소스를 유지하기 위한 파일 시스템, 현재 연산 활동을 제어하기 위한 프로세스 관리를 제공한다. (126쪽)
클라이언트에서도 HTTP 프로토콜을 구현하는 것은 마찬가지이므로,
웹 서버와 클라이언트 간에 차별되는 점은 웹 리소스를 관리하는 것이라 생각한다.
이건 말 그대로 웹을 보여주는 데에 필요한 정적 리소스, 동적 리소스가 될 수도 있고, DB에 저장되어 있는 사용자 개별의 정보일 수도 있다.
⭐️웹 서버가 하는 일⭐️
- 커넥션을 맺는다 -- 클라이언트의 접속을 받아들이거나, 원치 않는 클라이언트라면 닫는다.
[새 커넥션 다루기], [클라이언트 호스트 명 식별]. [ident를 통해 클라이언트 사용자 알아내기]- 요청을 받는다 -- HTTP 요청 메시지를 네트워크로부터 읽어 들인다.
[메시지의 내부 표현], [커넥션 입력/출력 처리 아키텍처]- 요청을 처리한다 -- 요청 메시지를 해석하고 행동을 취한다.
- 리소스에 접근한다 -- 메시지에서 지정한 리소스에 접근한다.
[Docroot], [디렉터리 목록]. [동적 콘텐츠 리소스 매핑], [서버사이드 인클루드], [접근 제어]- 응답을 만든다 -- 올바른 헤더를 포함한 HTTPP 응답 메시지를 생성한다.
[응답 엔터티], [MIME 타입 결정하기], [리다이렉션]- 응답을 보낸다 -- 응답을 클라이언트에게 돌려준다.
- 트랜잭션을 로그로 남긴다 -- 로그파일에 트랜잭션 완료에 대한 기록을 남긴다.
프로세스와 스레드
프로세스란 어떤 프로그램의 자신만의 변수 집합을 갖는 하나의 독립된 제어 흐름이다. 스레드는 프로세스의 더 빠르고 더 효율적인 버전이다. 스레드와 프로세스 모두 하나의 프로그램이 여러 작업을 동시에 할 수 있게 해준다. 설명을 단순하게 하기 위해 우리는 프로세스와 스레드를 서로 바꿔 쓸 수 있는 것처럼 다루고 있지만, 사실 둘 사이에는 성능상의 차이가 존재한다. 이러한 성능상의 이류로 많은 고성능 서버는 멀티프로세스인 동시에 멀티스레드다. (137쪽)
docroot
서버는 상대적인 url이 docroot를 벗어나서 파일 시스템의 docroot 이외 부분이 노출되는 일이 생기지 않도록 주의해야 한다. (138쪽)
MIME 타입
웹 서버에게는 응답 본문의 MIME 타입을 결정해야 하는 책임이 있다. (143쪽)
- mime types-파일 이름의 확장자 사용
- 매직 타이핑(Magic typing)-알려진 패턴에 대한 테이블 검색
- 유형 명시(Explicit typing)-내용 상관없이 웹 서버가 설정
- 유형 협상(Type negotiation)-여러 종류의 문서 형식에 속하도록 설정
MIME 타입?
Multipurpose Internet Mail Extensions의 약자로, 브라우저 상에서 문서, 파일, 바이트 모음의 확장자 또는 특성을 의미하는데, 웹서버는 HTTP 요청 상의 Content-Type 헤더에 MIME 타입을 정확하게 명시해야하는 책임이 있다. 더 정확한 정보는 여기에
리다이렉션
웹 서버는 요청을 수행하기 위해 브라우저가 다른 곳으로 가도록 리다이렉트 할 수 있다. 리다이렉션 응답은 3XX 상태 코드로 지칭된다. Location 응답 헤더는 콘텐츠의 새로운 혹은 선호하는 위치에 대한 URL를 포함한다. (144쪽)
<리다이렉트가 유용한 경우>
| 상황 | 설명 | 응답코드 |
|---|---|---|
| 영구히 리소스가 옮겨진 경우 | 리소스는 새 URL이 부여되어 새로운 위치로 옮겨졌거나 이름이 바뀌었을 수 있다. | 301 Moved Permanently |
| 임시로 리소스가 옮겨진 경우 | 이름 변경이 임시적이기 때문에 서버는 클라이언트가 나중에는 원래 URL로 찾아오고 북마크도 갱신하지 않기를 원한다. | 303 See Other 307 Temporary Redirect |
| URL 증강 | 요청이 도착했을 때, 서버는 상태 정보를 내포한 새 URL을 생성하고 사용자를 이 새 URL로 리다이렉트한다.(aka. fat URL) | 303 See Other 307 Temporary Redirect |
| 부하 균형 | 만약 과부화된 서버가 요청을 받으면 서버는 클라이언트를 좀 덜 부하가 걸린 서버로 리다이렉트할 수 있다 | 303 See Other 307 Temporary Redirect |
| 친밀한 다른 서버가 있을 때 | 서버는 클라이언트를 그 클라이언트에 대한 정보를 갖고 있는 다른 서버로 리다이렉트할 수 있다. | 303 See Other 307 Temporary Redirect |
| 디렉터리 이름 정규화 | URI 끝에 '/'를 빠뜨렸다면, 대부분의 웹 서버는 상대경로가 정상적으로 동작할 수 있도록 '/'를 추가한 URI로 리다이렉트한다. |
의문이 든 점
웹 서버 시장 점유율
책에서는 2014년도가 마지막이고, 당시에는 Microsoft가 Apache를 제쳤는데, 지금은 어떤지 궁금해서 찾아보니 지금은 Nginx, Apache 투톱이다.
그래서 Microsoft의 점유율이 확 떨어진 2019년에 무슨 일이 있었나 검색을 하고 있는데...
아직까지 적절한 원인을 찾지 못해서 아쉽다.
너무 궁금한데... 혹시 아는 분이 있다면 댓글 부탁드립니다!
++ 추가
Microsoft가 망해서라기보다는 Apache, Nginx가 성장했기 때문에 상대적으로 Microsoft의 그것이 줄어든 게 아닌가 싶다.
문제
-
웹 서버가 HTTP 트랜잭션을 처리하는 과정과 관련된 키워드가 바르게 짝지어진 것은?
1) 커넥션을 맺는다-커넥션 입력/출력 처리 아키텍처
2) 요청을 받는다-클라이언트 호스트 명 식별
3) 리소스에 접근한다-Docroot
4) 응답을 만든다-서버사이드 인클루드
5) 트랜잭션을 로그로 남긴다-ident를 통해 클라이언트 사용자 알아내기 -
웹 서버는 응답 본문의 MIME 타입을 결정하는 책임이 있습니다.
각 방법에 대해 간략히 설명하시오.1) MIME Types
2) Magic Typing
3) Explicit Typing
4) Type Negotiation
<답>
- 3)
1) 커넥션을 맺는다-[새 커넥션 다루기], [클라이언트 호스트 명 식별]. [ident를 통해 클라이언트 사용자 알아내기]
2) 요청을 받는다-[메시지의 내부 표현], [커넥션 입력/출력 처리 아키텍처]
3) 리소스에 접근한다-[Docroot], [디렉터리 목록]. [동적 콘텐츠 리소스 매핑], [서버사이드 인클루드], [접근 제어]
4) 응답을 만든다-[응답 엔터티], [MIME 타입 결정하기], [리다이렉션]
5) 트랜잭션을 로그로 남긴다-[로깅과 사용 추적]
- mime types-파일 이름의 확장자 사용
매직 타이핑(Magic typing)-알려진 패턴에 대한 테이블 검색
유형 명시(Explicit typing)-내용 상관없이 웹 서버가 설정
유형 협상(Type negotiation)-여러 종류의 문서 형식에 속하도록 설정
관련 주제
- 가상 호스팅된 docroot -> 18장 웹 호스팅
- 리소스 접근 제어 -> 12장 기본 인증
- 응답 만들기 -> 3장 HTTP 메시지/상태 코드
- 응답 보내기/지속 커넥션 -> 4장 커넥션 관리
- 로깅 -> 21장 로깅과 사용 추적
느낀 점
아무래도 이전에 배웠던, 백엔드 파트의 정보들과는 결이 다르다.
단순히 서버 요청, 응답에 필요한 코드 및 DB 쿼리가 백엔드의 핵심이라 생각했는데,
생각보다 코드를 짜는 영역이 아닌 부분도 돌아가는 원리가 중요하다는 것을 느꼈다.
특히나 Apache 코드가 종종 나왔는데 실습해볼까 싶었지만...
나중에 기회가 되면 다시 한 번 건드려봐야 겠다.
그리고 Nginx가 웹 서버였다니, 단지 front build 시 필요한 도구 정도로 인지하고 있었는데, 웹 서버임을 다시금 깨닫고 간다.
아무래도 프론트엔드 개발자는 브라우저에 그려주는 역할, 요청을 보내는 역할만 담당하다보니 웹 서버가 어떻게 돌아가는지 완전하게 파악하는 게 필요없어 보일 수도 있다.
그래도 이번 웹 서버가 하는 역할 중에 클라이언트가 보낸 요청을 가지고 제어하는 걸 보니 마냥 상관없지는 않다고 생각한다.
클라이언트가 보내는 요청이 어떻게 쓰이고 처리되는지 파악하면 전반적인 과정(프로세스)를 이해하는 데에 도움이 되지 않을까.
한 줄 요약
내가 보낸 요청이 이렇게 처리되다니!
