웹 서버

이 글은 검증을 위해 추가 인용문이 필요합니다. 신뢰할 수 있는 출처에 인용문을 추가하여 이 기사를 개선하는 데 도움을 주십시오. 조달되지 않은 자재는 제거될 수 있습니다.출처 : '웹 서버'– 뉴스 · 신문 · 서적 · 학자 · JSTOR (2009년 3월) (이 템플릿메시지 삭제 방법 및 삭제 시기 확인)

웹 서버는 HTTP(웹 콘텐츠를 배포하기 위해 만들어진 네트워크 프로토콜) 또는 보안 변형 HTTPS를 통해 요청을 받아들이는 컴퓨터 소프트웨어 및 기본 하드웨어입니다. 일반적으로 웹 브라우저 또는 웹 크롤러인 사용자 에이전트는 HTTP를 사용하여 웹 페이지 또는 다른 리소스에 대한 요청을 함으로써 통신을 시작하고 서버는 다음과 같이 응답합니다.에러 메세지가 표시됩니다.웹 서버는 사용자 에이전트에서 전송된 리소스를 수락하고 ^[1]저장하도록 구성할 수도 있습니다.^[2]

웹 서버를 실행하는 데 사용되는 하드웨어는 웹 서버가 처리해야 하는 요청 양에 따라 달라질 수 있습니다.범위의 하한에는 소형 웹 서버를 설정 인터페이스로 실행하는 라우터 등의 임베디드 시스템이 있습니다.트래픽이 많은 인터넷 웹 사이트는 고속 컴퓨터 랙에서 실행되는 수백 대의 서버에 대한 요청을 처리할 수 있습니다.

웹 서버로부터 송신되는 자원은 웹 서버가 이용할 수 있는 기존의 파일(스태틱콘텐츠)이 될 수도 있고 서버 소프트웨어와 통신하는 다른 프로그램에 의해 요구 시에 생성될 수도 있습니다(동적콘텐츠).전자는 일반적으로 더 빨리 처리되고 반복된 요청에 대해 더 쉽게 캐싱할 수 있는 반면 후자는 더 광범위한 애플리케이션을 지원합니다.

REST나 SOAP등의 테크놀로지는, WebDAV 확장의 서포트 뿐만이 아니라, 일반적인 컴퓨터간 통신의 베이스로서 HTTP 를 사용하고 있기 때문에, 사람이 읽을 수 있는 페이지를 제공한다는 본래의 목적을 훨씬 웃돌고 있습니다.

역사

이것은 웹 서버 프로그램의 매우 짧은 역사이기 때문에 일부 정보는 웹 브라우저, 월드 와이드 웹 및 인터넷의 역사와 중복될 수 밖에 없습니다.따라서 명확성과 이해를 위해 아래 보고되는 주요 이력 정보는 위의 설명 중 하나 또는 여러 개에서 발견되는 것과 유사할 수 있습니다.네드 역사 기사

최초의 WWW 프로젝트(1989-1991)

1989년 3월, Tim Berners-Lee 경은 하이퍼텍스트 시스템을 사용하여 과학자 간의 정보 교환을 용이하게 하는 것을 목표로 그의 고용주 CERN에 새로운 프로젝트를 제안했습니다."HyperText and CERN"이라는 제목의 제안서는 코멘트를 요청했으며 여러 사람이 이를 읽어 보았습니다.1990년 10월, 제안서는 (공저자인 Robert Cailliau로서) 재구성되어 풍부해졌고, 마침내 ^[3]승인되었다.^{[4] [5]}

1990년 후반에서 1991년 초 사이에 Berners-Lee와 그의 개발자들은 NeXT 워크스테이션에 설치된 NeXTSTEP OS에서 실행되는 세 가지 프로그램과 함께 여러 소프트웨어 라이브러리를 작성하고 테스트하게 되었습니다.

• WorldWideWeb이라고 불리는 그래픽 웹 브라우저
• 휴대용 회선 모드 웹 브라우저
• 나중에 CERN httpd로 알려진 웹 서버입니다.

이러한 초기 브라우저는 HTTP 0.9라는 새로운 기본 통신 프로토콜을 사용하여 웹 서버에서 웹 페이지를 검색했습니다.

1991년 8월 Tim Berner-Lee는 WWW 기술의 탄생을 발표하고 ^[8]과학자들이 그것을 채택하고 개발하도록 격려했다.얼마 지나지 않아 이 프로그램들은 소스코드와 함께 ^[6]사용법에 관심이 있는 사람들에게 이용 가능하게 되었다.실제로 CERN은 개발자 등을 포함한 다른 사람들이 비공식적으로 작업을 수행할 수 있도록 허용했으며, 어쩌면 그 순간까지 만들어진 작업을 더욱 발전시킬 수도 있었습니다.이것이 CERN httpd의 공식 탄생입니다.이후 Berner-Lee는 다른 OS로의 ^[5]이식뿐만 아니라 이러한 프로그램의 채택과 사용을 촉진하기 시작했습니다.

빠르고 야생적인 개발(1991-1995)

1991년 12월, 유럽 이외의 최초의 Web 서버가 SLAC(^[7]미국)에 인스톨 되었습니다.이는 웹 브라우저와 웹 서버 간의 대륙 횡단 웹 통신을 시작했기 때문에 매우 중요한 행사였다.

1991-1993년 CERN 웹 서버 프로그램은 www 그룹에 의해 지속적으로 활발하게 개발되었으며, 한편 소스 코드의 가용성과 HTTP 프로토콜의 공개 사양 덕분에 다른 많은 웹 서버 구현이 개발되기 시작했습니다.

1993년 4월 CERN은 웹 소프트웨어의 세 가지 구성 요소(기본 라인 모드 클라이언트, 웹 서버 및 공통 코드 라이브러리)와 소스 코드가 공용 ^[11]도메인에 포함되었다는 공식 성명을 발표했습니다.이것에 의해, Web 서버 개발자는, 그 소스 코드에 근거하는 파생 작업의 개발에 관한 법적 문제(실제로 존재하지 않는 위협)로부터 해방되었습니다.

1994년 초에 새로운 웹 서버 중 가장 주목할 만한 것은 NCSA httpd로, 다양한 Unix 기반 OS에서 실행되었으며, NCSA httpd를 구현함으로써 동적으로 생성된 콘텐츠를 제공할 수 있었습니다.POST 외부 프로그램과 통신하기 위한 HTTP 메서드와 CGI.이러한 기능은 NCSA의 Mosaic 브라우저의 멀티미디어 기능(웹 서버에 데이터를 보내기 위해 HTMLFORM을 관리할 수도 있음)과 함께 퍼블리싱 및 분산 컴퓨팅 애플리케이션에 대한 웹 테크놀로지의 가능성을 강조했습니다.

1994년 하반기, NCSA httpd의 개발은 NCSA httpd 소스 코드가 퍼블릭 도메인에 제공됨에 따라 외부 소프트웨어 개발자, 웹 마스터 및 기타 전문가 그룹이 패치를 작성하고 수집하기 시작할 정도로 중단되었습니다.1995년 초에 이러한 패치는 모두 NCSA 소스 코드의 마지막 릴리스에 적용되었으며, 몇 가지 테스트를 거친 ^[12][13]후 Apache HTTP 서버 프로젝트가 시작되었습니다.

1994년 말 Netsite라는 이름의 새로운 상용 웹 서버가 특정 기능을 갖춘 상태로 출시되었습니다.이것은 넷스케이프에 의해 처음 개발된 유사한 제품들 중 하나이며, 그 후 Sun Microsystems에 의해 그리고 마지막으로 Oracle Corporation에 의해 개발되었다.

1995년 중반, Windows NT OS용의 IIS 의 최초의 버전이 Microsoft 에 의해서 공개되었습니다.이는 월드 와이드 웹 테크놀로지 분야에서 웹의 양면(클라이언트 및 서버)에서 중요한 역할을 수행해 온 매우 중요한 상업적 개발자 및 벤더의 진입을 의미하기 때문에 주목할 만한 사건이었습니다.

1995년 하반기부터 CERN 및 NCSA 웹 서버는 글로벌 사용률에서 감소하기 시작했습니다. 이는 개발 주기가 훨씬 빠르며 이전 웹 서버보다 더 많은 기능, 더 많은 수정 프로그램, 더 많은 성능이 적용되었기 때문입니다.

폭발적인 성장과 경쟁 (1996-2014)

1996년 말에는 이미 50개가 넘는 알려진 (다른) 웹 서버 소프트웨어 프로그램이 인터넷 도메인 이름을 소유하거나 웹사이트를 ^[15]호스팅하고자 하는 모든 사람들이 이용할 수 있었습니다.이들 중 상당수는 수명이 짧았고 다른 웹 서버로 대체되었다.

프로토콜 버전 HTTP/1.0(1996년) 및 HTTP/1.1(1997년, 1999년)에 대한 RFC의 발행으로 대부분의 웹 서버가 이러한 표준을 완전히 준수하지 않을 수 없게 되었습니다.TCP/IP 영속 접속(HTTP/1.1)을 사용하려면 웹 서버가 허용되는 최대 동시 접속 수를 크게 늘리고 확장성 수준을 향상시켜야 합니다.

1996년에서 1999년 사이에 Netscape Enterprise Server와 Microsoft의 IIS가 주요 상용 옵션 중 하나로 부상한 반면, 무료로 이용할 수 있는 오픈 소스 프로그램인 Apache HTTP Server는 (신뢰성과 많은 기능 때문에) 우선 서버로서 선두를 지켰다.

그 몇 년 동안 제우스라고 불리는 상업적이고 혁신적이며 주목할 만한 웹 서버도 있었습니다.이 서버는 사용률이 낮음에도 불구하고 적어도 2000년대 초까지 시장에서 가장 빠르고 확장성이 뛰어난 웹 서버 중 하나로 알려져 있었습니다.

Apache는 1996년 중반부터 2015년 말까지 가장 많이 사용된 웹 서버를 만들어 냈으며, 그 후 몇 년간의 감소 끝에 IIS와 Nginx에 추월당했다.그 후 IIS는 Apache보다 훨씬 낮은 사용률로 떨어졌습니다(시장 점유율 참조).

Apache는 2005-2006년 이후 새로운 성능 기능(예: 이벤트 MPM 및 새로운 ^[16][17]콘텐츠 캐시)을 도입하여 속도와 확장성 수준을 개선하기 시작했습니다.이러한 새로운 성능 향상이 처음에는 실험적인 것으로 표시되었기 때문에 Apache는 오랫동안 사용자들에 의해 활성화되지 않았기 때문에 상용 서버 및 다른 오픈 소스 서버들의 경쟁에 더욱 시달렸습니다. 반면 Apache는 이미 훨씬 더 뛰어난 성능을 달성한 반면(대부분 정적 콘텐츠를 제공할 때) 그 이후부터)개발의 시작과 Apache가 쇠퇴할 무렵에는 충분히 많은 테스트를 거친 고급 기능 목록을 제공할 수 있었습니다.

실제로 2000년 이후 몇 년 동안 Lite Speed와 같은 상업적이고 경쟁이 치열한 다른 웹 서버뿐만 아니라 종종 뛰어난 품질과 매우 높은 성능을 가진 다른 많은 오픈 소스 프로그램도 등장했습니다.이들 프로그램들 중 Hiawatha, Cherokee HTTP 서버, Lighttpd, Nginx 및 기타 파생/관련 제품도 com과 함께 사용할 수 있습니다.금전적 지원, 부상.

위해 이미지의 많고 지속적으로 부족의 문제를 완화하기 위하여 무거운 웹 페이지의 검색 속도를 높이기 위해 약 2007-2008년 사이 가장 인기 있는 웹 브라우저 host-domain(제한 RFC-2616에 의해 추천되는)[18]당 42지속적인 연결, host-domain마다 6이나 8영구 연결, 이전의 기본 한계 증가했다.사기웹 ^[19]페이지에서 이벤트의 양방향 알림에 사용되는 동적 개체 전용 노드입니다.이러한 변경은 1년 이내에 웹 서버가 관리해야 하는 지속적 접속의 최대 수를 평균 3배 가까이 증가시켰습니다.이러한 (영속적인 접속의 수가 증가하는) 경향에 따라 속도가 느린 웹 서버 앞에 리버스 프록시를 도입하는 것이 확실히 촉진되었습니다.또한 새로운 웹 서버에도 새로운 웹 서버에서는 모든 속도와 매우 많은 동시 접속을 재요청 없이 처리할 수 있는 능력을 발휘할 수 있게 되었습니다.하드웨어 리소스가 너무 많습니다(CPU, RAM 및 고속 ^[20]디스크가 많은 고가의 컴퓨터).

새로운 과제(2015년 이후)

2015년에 RFC는 새로운 프로토콜 버전 [HTTP/2]를 발표하였고, 새로운 규격의 구현이 전혀 간단하지 않자, 그 새로운 프로토콜 ^[21][22]버전에 대한 지원을 추가하거나 추가하지 않는 딜레마가 발생하였습니다.

실제로 HTTP/2를 지원하려면 많은 요인(실제로는 항상 암호화된 접속, 같은 TCP 포트 상의 HTTP/1.x와 HTTP/2 접속을 구별하는 기능, HTTP 메시지의 바이너리 표현, 메시지 우선도, HTTP 헤더의 압축, 스트림 사용)으로 인해 내부 구현에 근본적인 변경이 필요했습니다.는 TCP/IP 서브접속 및 관련 흐름 제어 등으로도 알려져 있습니다.따라서 이들 웹 서버의 일부 개발자는 새로운 HTTP/2 버전(적어도 가까운 장래에는)을 지원하지 않는 것도 다음과 같은 주요 이유입니다.^[21][22]

• HTTP/1.x 프로토콜은 브라우저에 의해 매우 오랫동안(아마도 영원히) 지원되기 때문에 향후 클라이언트와 서버 간에 호환성이 없어집니다.
• HTTP/2의 구현은 2015년까지는 존재하지 않았던 완전히 새로운 종류의 버그에 대한 문을 열 수 있는 엄청난 복잡성의 태스크로 간주되었으며, 따라서 새로운 프로토콜의 구현 개발과 테스트에 상당한 투자가 필요했을 것이다.
• HTTP/2의 서포트를 추가하는 것은, 향후의 대처가 정당화될 경우에 대비해 항상 실시할 수 있습니다.

대신, 가장 인기 있는 웹 서버의 개발자들은 앞다퉈 새로운 프로토콜의 가용성을 제공했다. 왜냐하면 그들은 노동력과 그렇게 할 시간이 있었을 뿐만 아니라 보통 SPDY 프로토콜의 이전 구현이 출발점으로 재사용될 수 있었고 대부분의 사용된 웹 브라우저가 동일한 프로토콜에 대해 매우 빠르게 그것을 구현했기 때문이다.개발자들이 빠르게 행동하게 된 또 다른 이유는 웹마스터가 계속 증가하는 웹트래픽의 압박을 느껴 TCP/IP 접속 수를 대폭 줄이고 호스팅되는 ^[23]웹 사이트에 대한 액세스를 가속화할 수 있는 무언가를 최대한 빨리 설치하고 시도하고 싶었기 때문입니다.

2020-2021년에 구현에 관한 HTTP/2 역학은 HTTP/3 프로토콜에 관한 향후 RFC의 고급 초안이 발표된 후 부분적으로 복제되었다.

기술 개요

다음 기술 개요는 웹 서버에 구현될 수 있는 일부 기능 및 토픽에 관한 시나리오를 충분히 폭넓게 하기 위해 수행할 수 있는 태스크에 대한 극히 제한된 예를 몇 가지 제시하기 위한 시도일 뿐입니다.

웹 서버 프로그램은 HTTP 프로토콜의 하나 이상의 버전을 구현함으로써 클라이언트-서버 모델에서 서버의 역할을 수행합니다.대부분은 HTTPS 시큐어 배리언트 및 계획된 사용에 도움이 된다고 생각되는 기타 기능 및 확장을 포함합니다.

웹 서버 프로그램의 복잡성과 효율은 다음과 같이 크게 다를 수 있습니다.^[1]

• 공통 기능 구현
• 수행된 일반적인 작업
• 목표로 하는 퍼포먼스와 확장성 수준
• 바람직한 성능 및 확장성 수준을 달성하기 위해 채택된 소프트웨어 모델 및 기술
• 대상 하드웨어 및 사용 범주(예: 임베디드 시스템, 중규모 트래픽 웹 서버, 고트래픽 인터넷 웹 서버)

공통 기능

웹 서버 프로그램의 실장 방법은 다르지만, 대부분은 다음과 같은 공통 기능을 제공합니다.

이것들은 대부분의 웹 서버가 보통 가지고 있는 기본적인 기능입니다.

• 정적 콘텐츠 서비스: HTTP 프로토콜을 통해 정적 콘텐츠(웹 파일)를 클라이언트에 제공할 수 있습니다.
• HTTP: 클라이언트 HTTP 요청 버전과 호환되는 HTTP 응답 버전(예: HTTP/1.0, HTTP/1.1(종국에는 암호화된 연결 HTTPS도 있음) 및 사용 가능한 경우 HTTP/2, HTTP/3)을 전송하기 위한 HTTP 프로토콜 버전 지원.
• 로깅: 보통 웹 서버에는 보안 및 통계 목적으로 로그 파일에 대한 클라이언트 요청 및 서버 응답에 대한 일부 정보를 로깅하는 기능도 있습니다.

그 밖에 몇 가지 고급 기능 및 일반적인 기능(매우 짧은 기능만)은 다음과 같습니다.

• 동적 콘텐츠 서비스: HTTP 프로토콜을 통해 클라이언트에 동적 콘텐츠(즉석에서 생성)를 제공할 수 있습니다.
• 가상 호스팅: 하나의 IP 주소만 사용하여 많은 웹 사이트(도메인 이름)를 제공할 수 있습니다.
• 허가: 웹 사이트 경로(웹 리소스)의 일부에 대한 액세스를 허용, 금지 또는 허용할 수 있습니다.
• 콘텐츠 캐시: 서버 응답 속도를 높이기 위해 정적 콘텐츠 및 동적 콘텐츠를 캐시할 수 있습니다.
• 대용량 파일 지원: 32비트 OS에서 크기가 2GB 이상인 파일을 처리할 수 있습니다.
• 대역폭 조절: 네트워크를 포화시키지 않고 더 많은 클라이언트에 서비스를 제공할 수 있도록 콘텐츠 응답 속도를 제한합니다.
• [Rewrite engine]: 클린 URL(클라이언트 요구에 있는 것)의 일부를 실명에 매핑합니다.
• 커스텀 에러 페이지: 커스텀HTTP 에러 메시지 지원.

일반적인 태스크

웹 서버 프로그램은 실행 중일 때 일반적으로 다음과 같은 몇 가지 일반적인 작업을 수행합니다(예:^[1]

• 를 기동해, 필요에 따라서 설정 파일등의 설정을 읽어, 적용합니다.옵션으로 로그 파일을 열고, 클라이언트 접속/요구를 리슨하기 시작합니다.
• 선택적으로 설정 및 현재 작동 조건에 따라 일반적인 동작을 조정한다.
• 클라이언트 접속을 관리한다(필요에 따라 신규 접속을 삭제하거나 기존 접속을 닫는다).
• 는 클라이언트 요구를 수신합니다(HTTP 메시지를 읽음으로써).
  • 각 HTTP 요청 메시지를 읽고 확인합니다.
  • 는 보통 URL 정규화를 수행합니다.
  • 는 통상 URL 매핑을 실행합니다(디폴트로 URL 패스 변환이 될 수 있습니다).
  • 는 보통 다양한 보안 체크와 함께 URL 경로 변환을 수행합니다.
• 는 요청된 HTTP 메서드를 실행 또는 거부합니다.
  • 임의로 URL 인가를 관리합니다.
  • 임의로 URL 리다이렉션을 관리합니다.
  • 는 필요에 따라 스태틱리소스(파일 내용) 요구를 관리합니다.
    • 선택적으로 디렉토리 인덱스 파일을 관리합니다.
    • 옵션에서 일반 파일을 관리합니다.
  • 는 필요에 따라 다이내믹리소스에 대한 요구를 관리합니다.
    • 임의로 디렉토리 목록을 관리합니다.
    • 프로그램 또는 모듈 처리를 선택적으로 관리하여 동적 콘텐츠를 생성하기 위해 사용되는 외부 프로그램 실행의 가용성, 시작 및 종국적 중단을 확인합니다.
    • 옵션으로 동적 콘텐츠 생성에 사용되는 외부 프로그램/내부 모듈과의 통신을 관리합니다.
• 적절한 HTTP 응답을 송신하는 클라이언트 요구에 대한 응답(요청된 자원이나 오류 메시지 등) 최종적으로 HTTP 헤더를 검증하거나 동적 프로그램/모듈에 의해 송신된 헤더에 추가한다.
• 옵션으로 클라이언트 요구 및/또는 그 응답을 syslog에 의해 외부 사용자 로그 파일 또는 시스템로그 파일에 기록합니다(통상 일반적인 로그 형식을 사용합니다).
• 옵션으로 syslog 또는 기타 시스템 설비를 사용하여 검출된 이상 징후 또는 기타 주목할 만한 이벤트(클라이언트 요구 또는 내부 기능 등)에 관한 프로세스 메시지를 기록합니다.이러한 로그 메시지에는 보통 디버깅, 경고, 오류, 경보 레벨이 있으며, 설정에 따라 필터링(로그되지 않음)할 수 있습니다.중요도 수준도 참조하십시오.
• 선택적으로 관리되는 웹 트래픽 및/또는 그 성능에 대한 통계를 생성합니다.
• 기타 커스텀 태스크

요청 메시지 읽기

웹 서버 프로그램에는 다음과 같은 기능이 있습니다.^[24]

• HTTP 요청 메시지를 읽습니다.
• 해석할 수 있습니다.
• 그 구문을 검증한다.
• 기존 HTTP 헤더를 식별하고 그 값을 추출합니다.

HTTP 요청 메시지가 디코딩 및 확인되면 해당 값을 사용하여 해당 요청을 충족할 수 있는지 여부를 판단할 수 있습니다.이를 위해서는 보안 검사를 포함한 다른 많은 단계가 필요합니다.

URL 정규화

웹 서버 프로그램은 보통 다음과 같은 순서로 URL 정규화(대부분의 HTTP 요청 메시지에서 볼 수 있는 URL)를 수행합니다.

• 웹 사이트의 루트 디렉토리에서 자원 경로를 항상 깨끗하고 균일한 경로로 만듭니다.
• 보안 위험을 낮추기 위해(예를 들어 웹 사이트의 루트 디렉토리 외부에 있는 정적 자원에 보다 쉽게 액세스하려는 시도 또는 웹 사이트 루트 디렉토리 아래에 있는 경로 중 금지된 부분 또는 허가가 필요한 부분에 대한 액세스를 차단함)
• 인간 및 웹 로그 분석 프로그램(로그 분석기/통계 애플리케이션이라고도 함)에 의해 웹 리소스의 경로를 보다 쉽게 인식할 수 있도록 하기 위한 것입니다.

URL 정규화란 URL을 일관성 있게 수정 및 표준화하는 프로세스를 말합니다.스킴과 호스트를 소문자로 변환하는 등 몇 가지 유형의 정규화를 수행할 수 있습니다.가장 중요한 정규화는 "." 및 ".." 경로 세그먼트를 제거하고 비어 있지 않은 경로 구성요소에 후행 슬래시를 추가하는 것입니다.

URL 매핑

URL 매핑은 URL을 분석하여 참조하고 있는 리소스를 파악하여 해당 리소스를 요청 클라이언트에 반환하는 프로세스입니다.이 프로세스는 웹 서버에 대한 모든 요구에 대해 수행되며, HTML 문서나 gif 이미지와 같은 파일과 함께 제공되는 요구와 CGI 프로그램을 실행한 결과 및 내장 모듈 핸들러, PHP 문서 또는 Java Servlet과 ^[27]같은 다른 프로세스에 의해 제공되는 요구도 있습니다."

실제로 단순한 정적 콘텐츠 서비스(URL 리라이트 엔진, 동적 콘텐츠 서비스 등)를 넘어 고급 기능을 구현하는 웹 서버 프로그램은 일반적으로 해당 URL을 어떻게 처리해야 하는지 파악해야 합니다.예를 들어 다음과 같습니다.

• URL 리다이렉트, 다른 URL 리다이렉트
• 파일 콘텐츠의 정적 요청으로 간주됩니다.
• 다음 동적 요구로 지정됩니다.
  • 해당 디렉토리에 포함된 파일 또는 기타 하위 디렉토리의 디렉토리 목록
  • 이러한 종류의 URL 경로를 처리할 수 있는 프로그램/모듈 프로세서를 식별하고 다른 URL 부분(일반적으로 경로 정보 및 쿼리 문자열 변수)으로 전달하기 위한 다른 유형의 동적 요청입니다.

웹 서버의 하나 이상의 구성 파일은 URL 경로의 일부(예를 들어 파일 경로의 초기 부분, 파일 이름 확장자 및 기타 경로 구성 요소)를 특정 URL 핸들러(파일, 디렉토리, 외부 프로그램 또는 내부 모듈)^[28]에 매핑하는 것을 지정할 수 있습니다.

웹 서버가 상기의 1개 또는 복수의 고도의 기능을 실장하고 있는 경우, 유효한 URL 의 패스 부분이 Web 사이트 디렉토리 트리(파일 시스템내의 파일 또는 디렉토리)아래에 있는 기존의 파일 시스템 패스와 항상 일치하는 것은 아닙니다.이것은, 동적인 요구에 대해서 내부 또는 외부 모듈 프로세서의 가상명을 참조할 수 있기 때문입니다.

파일 시스템으로의 URL 경로 변환

웹 서버 프로그램은 물리적 파일 시스템 경로를 참조하는 URL 경로(전체 또는 일부)를 대상 웹 사이트의 루트 ^[28]디렉터리 아래에 있는 절대 경로로 변환할 수 있습니다.

웹 사이트의 루트 디렉토리는 HTTP 클라이언트 ^[28]요청에서 발견된 URL의 호스트 부분인 웹 사이트 이름을 사용하여 구성 파일 또는 웹 서버의 내부 규칙으로 지정할 수 있습니다.

파일 시스템에 대한 경로 변환은 다음 유형의 웹 리소스에 대해 수행됩니다.

• 로컬 파일(보통 복원이 불가능한 파일) (파일 내용에 대한 정적 요청)
• 로컬 디렉토리(동적 요구: 즉석에서 생성된 디렉토리 목록);
• 프로그램 이름(CGI 또는 SCGI 인터페이스를 사용하여 실행되며 출력이 웹 서버에 의해 읽혀져 HTTP 요구를 한 클라이언트에 재발송신되는 동적 요구).

웹 서버는 요청된 URL에서 발견된 경로(HTTP 요청 메시지)를 추가하여 (Host) 웹 사이트 루트 디렉토리의 경로에 추가합니다.Apache 서버에서는 일반적으로 다음과 같습니다./home/www/website(Unix 머신에서는, 통상은 다음과 같습니다./var/www/website)의 결과를 나타내는 다음의 예를 참조해 주세요.

정적 파일 요청 URL 경로 변환

다음 URL에서 지정한 기존 파일의 정적 요청의 예:

http://www.example.com/path/file.html

클라이언트의 사용자 에이전트가 다음 위치에 연결합니다.www.example.com다음에, 다음의 HTTP/1.1 요구를 송신합니다.

GET /path/file.http/1.1 호스트: www.example.com 연결: keep-displays

그 결과 로컬파일 시스템리소스가 생성됩니다.

/home/www/www.example.com/path/file.html

그런 다음 웹 서버는 파일이 있는 경우 해당 파일을 읽고 클라이언트의 웹 브라우저에 응답을 보냅니다.응답은 파일의 내용을 기술하고 파일 자체를 포함합니다.그렇지 않으면 파일이 존재하지 않거나 파일에 액세스할 수 없다는 오류 메시지가 나타납니다.

디렉토리 요청 URL 경로 변환(스태틱인덱스 파일 없음)

다음 URL에 의해 지정된 기존 디렉토리의 암묵적인 다이내믹 요구의 예:

http://www.example.com/directory1/directory2/

클라이언트의 사용자 에이전트가 다음 위치에 연결합니다.www.example.com다음에, 다음의 HTTP/1.1 요구를 송신합니다.

GET / directory1 / directory2 HTTP / 1.1 호스트: www.example.com 접속: 킵 리셋

결과는 로컬 디렉토리 경로입니다.

/home/www/www.example.com/directory1/directory2/

그런 다음 웹 서버는 디렉토리의 존재를 확인하고 디렉토리가 존재하며 액세스할 수 있는 경우 인덱스 파일(이 경우 존재하지 않음)을 검색하여 내부 모듈 또는 디렉토리 목록 전용 프로그램에 요청을 전달하고 마지막으로 데이터 출력을 읽고 클라이언트의 웹 브라우저에 응답을 보냅니다.이 응답은 디렉토리의 내용(포함된 하위 디렉토리 및 파일 목록)을 설명하거나 디렉토리가 존재하지 않거나 디렉토리의 액세스가 금지되었다는 오류 메시지를 반환합니다.

동적 프로그램 요청 URL 경로 변환

동적 요구의 경우 클라이언트에 의해 지정된 URL 경로는 웹 서버가 ^[29]동적 콘텐츠를 생성하기 위해 사용하는 기존 외부 프로그램(통상은 CGI가 있는 실행 파일)을 참조해야 합니다.

프로그램 파일을 사용하여 출력을 생성하는 동적 요청의 예:

http://www.example.com/cgi-bin/forum.php?action=view&orderby=thread&date=2021-10-15

클라이언트의 사용자 에이전트가 다음 위치에 연결합니다.www.example.com다음에, 다음의 HTTP/1.1 요구를 송신합니다.

GET /cgi-bin /http . http ?action = view & ordeby = http & date = http - 10-15 HTTP / 1.1 호스트: www.example.com Connection : keep - http - http : - get get get get get

그 결과 프로그램의 로컬 파일 경로(이 예에서는 PHP 프로그램)가 됩니다.

/home/www/www.example.com/cgi-bin/forum.php

웹 서버는 path-info와 쿼리 문자열을 전달하여 해당 프로그램을 실행합니다. action=view&orderby=thread&date=2021-10-15이 경우 2021년 10월 15일부터 스레드로 정렬된 포럼 엔트리의 뷰를 포함한 HTML 문서를 반환한다.또, Web 서버는 외부 프로그램으로부터 송신된 데이터를 읽어, 그 데이터를 요구를 한 클라이언트에 재발송합니다.

요청 메시지 관리

요구가 읽기, 해석 및 확인되면 메서드, URL 및 HTTP 헤더 값을 포함하는 파라미터에 따라 관리해야 합니다.

실제로 웹 서버는 다음 응답 ^[28]경로 중 하나를 사용하여 요청을 처리해야 합니다.

• (상태 행 또는 메시지 헤더에 있는) 요청 내용이 허용되지 않는 경우 웹 서버는 이미 오류 응답을 전송했습니다.
• 요청의 메서드가 있는 경우(예:OPTIONS웹 서버의 일반 코드로 만족할 수 있는 경우 성공적인 응답이 전송됩니다.
• URL에 허가가 필요한 경우 허가 오류 메시지가 발송됩니다.
• URL이 리다이렉션에 매핑되면 리다이렉트메시지가 발송됩니다.
• URL이 동적 자원(가상 경로 또는 디렉토리 목록)에 매핑되면 해당 핸들러(내부 모듈 또는 외부 프로그램)가 호출되고 요청 파라미터(쿼리 문자열 및 경로 정보)가 해당 요구에 응답할 수 있도록 해당 핸들러에 전달됩니다.
• URL이 정적 자원(일반적으로 파일시스템상의 파일)에 매핑되면 내부 정적 핸들러가 호출되어 해당 파일이 전송됩니다.
• 요청 방법을 알 수 없거나 다른 허용되지 않는 조건(리소스를 찾을 수 없음, 내부 서버 오류 등)이 있는 경우 오류 응답이 전송됩니다.

정적 콘텐츠 제공

웹 서버 프로그램이 스태틱콘텐츠를 처리할 수 있고 그렇게 설정되어 있는 경우 웹 사이트의 루트디렉토리 아래에 있는 기존 파일의 유효한 URL 경로(URL 매핑, URL 변환 및 URL 리다이렉션 후)와 일치하는 속성을 가진 요청 메시지가 있을 때마다 파일콘텐츠를 송신할 수 있습니다.ose는 웹 서버 프로그램의 ^[28]내부 규칙에 의해 요구됩니다.

이러한 종류의 내용은 일반적으로 클라이언트에 전송될 때 웹 서버에 의해 변경되지 않고 일부 프로그램에 의해 수정(파일 수정)될 때까지 그대로 유지되기 때문에 정적이라고 불립니다.

메모: 정적 콘텐츠만 제공하는 경우 웹 서버 프로그램은 일반적으로 서비스된 웹 사이트의 파일 내용을 변경하지 않으므로(읽기만 하고 쓰기는 하지 않으므로) 다음 HTTP 메서드만 지원하면 됩니다.

• OPTIONS
• HEAD
• GET

정적 파일 내용의 응답은 파일 캐시에 의해 고속화할 수 있습니다.

디렉토리 인덱스 파일

웹 서버 프로그램이 기존 디렉토리 중 하나와 경로가 일치하는 URL을 포함한 클라이언트 요구 메시지를 수신하고 해당 디렉토리에 액세스할 수 있으며 서비스 디렉토리 인덱스 파일이 활성화되어 있는 경우 웹 서버 프로그램은 해당 디렉토리에서 발견된 알려진(또는 설정된) 정적 인덱스 파일 이름 중 첫 번째 파일(일반 파일)의 서비스를 시도합니다.덱스 파일이 발견되거나 다른 조건이 충족되지 않으면 오류 메시지가 반환됩니다.

정적 인덱스 파일에 가장 많이 사용되는 이름은 다음과 같습니다.index.html,index.htm그리고.Default.htm.

일반 파일

웹 서버 프로그램이 기존 파일의 파일명과 일치하는 경로를 가진 URL이 포함된 클라이언트 요청 메시지를 수신하고 웹 서버 프로그램에서 파일에 액세스할 수 있으며 웹 서버 프로그램의 속성이 웹 서버 프로그램의 내부 규칙과 일치하는 경우 웹 서버 프로그램은 해당 파일을 클라이언트에 보낼 수 있습니다.

통상, 대부분의 Web 서버 프로그램은, 시큐러티상의 이유로, 통상의 파일만을 처리하거나, 디바이스 파일등의 특수한 파일 형식과 심볼릭 링크나 하드 링크를 사용하지 않게 사전에 설정되어 있습니다.목적은 정적 웹 리소스를 ^[30]제공할 때 바람직하지 않은 부작용을 방지하는 것입니다.

동적 콘텐츠 제공

웹 서버 프로그램이 다이내믹콘텐츠를 처리할 수 있고 그렇게 설정되어 있는 경우 웹 서버 프로그램은 클라이언트 요구 파라미터를 전달하기 위해 적절한 내부 모듈 또는 외부 프로그램(요구된 URL 경로와 관련됨)과 통신할 수 있습니다.그 후 웹 서버 프로그램은 해당 프로그램에서 데이터 응답을 읽습니다.생성(대부분 온 더 플라이)된 후 요청을 ^{[citation needed]}한 클라이언트 프로그램으로 재발송합니다.

주의: 정적 및 동적 콘텐츠를 제공할 때 웹 서버 프로그램은 클라이언트로부터 데이터를 안전하게 수신할 수 있도록 하기 위해 일반적으로 다음 HTTP 방법을 지원해야 합니다.따라서 대량의 데이터 세트(예를 들어 대량의 데이터 입력 또는 파일 업로드)를 웹 서버/외부 프로그램에 전송할 수 있는 인터랙티브 형식의 웹 사이트도 호스팅할 수 있습니다./ 모듈:

• POST

내부 모듈 및/또는 외부 프로그램과 통신할 수 있으려면 웹 서버 프로그램이 사용 가능한 여러 게이트웨이 인터페이스 중 하나 이상을 구현해야 합니다(동적인 콘텐츠에 사용되는 웹 서버 게이트웨이 인터페이스 참조).

3개의 표준 게이트웨이 인터페이스와 이력 게이트웨이 인터페이스는 다음과 같습니다.

CGI

외부 CGI 프로그램은 각 동적 요구에 대해 웹 서버 프로그램에 의해 실행되며 웹 서버 프로그램은 생성된 데이터 응답을 읽어내 클라이언트에 재발송합니다.

SCGI

외부 SCGI 프로그램(통상 프로세스)은 웹 서버 프로그램 또는 다른 프로그램/프로세스에 의해 한 번 시작되고 네트워크 접속을 기다립니다.새로운 요구가 있을 때마다 웹 서버 프로그램은 요구 파라미터를 송신하고 데이터 응답을 읽기 위해 새로운 네트워크 접속을 확립하고 네트워크 접속을 수행합니다.ction이 닫힙니다.

패스트 CGI

외부 Fast CGI 프로그램(일반적으로 프로세스)은 웹 서버 프로그램 또는 다른 프로그램/프로세스에 의해 한 번 시작된 후 웹 서버에 의해 영구적으로 설정된 네트워크 연결을 기다립니다. 이 연결을 통해 요청 매개 변수가 전송되고 데이터 응답을 읽습니다.

디렉토리 리스트

웹 서버 프로그램은 파일 및 하위 ^[31]디렉토리의 디렉토리 인덱스 목록의 동적 생성을 관리할 수 있습니다.

웹 서버 프로그램이 그렇게 구성되고 요청된 URL 경로가 기존 디렉토리와 일치하며 해당 디렉토리 아래에 정적 인덱스 파일이 발견되지 않으면 상기 디렉토리의 파일 및/또는 하위 디렉토리 목록을 포함하는 웹 페이지(통상은 HTML 형식)가 동적으로 생성됩니다(즉석에서).생성할 수 없는 경우 오류가 반환됩니다.

일부 웹 서버 프로그램에서는 웹 페이지 템플릿(플레이스 홀더를 포함하는 HTML 문서)을 사용할 수 있도록 하여 디렉토리 목록을 사용자 정의할 수 있습니다.$(FILE_NAME), $(FILE_SIZE)웹 서버에 의해 디렉토리에서 발견된 각 파일 엔트리의 필드 값으로 대체됩니다(예:index.tpl또는 HTML 및 임베디드 소스 코드의 사용, 즉석에서 해석 및 실행되는 예를 들어 다음과 같습니다.index.aspCGI, SCGI, FGCI 등의 동적 인덱스 프로그램 사용을 지원하거나 지원하거나 둘 다.index.cgi,index.php,index.fcgi.

동적 생성 디렉토리 목록은 정적 인덱스 페이지를 보내는 것보다 훨씬 더 많은 OS 리소스를 사용하기 때문에 일반적으로 웹 사이트의 선택된 디렉토리 몇 개만 사용하거나 사용을 피합니다.

디렉토리 리스트의 주된 용도는 파일을 그대로 다운로드(^[32]보통 이름, 크기, 변경 날짜 시간 또는 파일 속성이 랜덤으로 자주 변경될 수 있는 경우)하는 것입니다.이 경우 사용자에게 추가 정보를 제공할 필요가 없습니다.

프로그램 또는 모듈 처리

외부 프로그램 또는 내부 모듈(처리 장치)은 하나 이상의 데이터 저장소에서 데이터를 가져오거나 저장하기 위해 사용할 수 있는 일종의 애플리케이션 기능을 실행할 수 있습니다. 예를 들어 다음과 같습니다.^{[citation needed]}

• 파일(파일 시스템);
• 데이터베이스(DB);
• 로컬 컴퓨터 또는 다른 컴퓨터에 있는 다른 소스.

처리 유닛은 데이터 저장소에서 검색된 데이터를 사용하여 다음과 같은 웹 콘텐츠를 반환할 수 있습니다.^{[citation needed]}

• 문서(HTML, XML 등)
• 이미지
• 비디오
• 예를 들어 웹 인터페이스의 동적 페이지(DHTML)에 의해 표시되는 하나 이상의 값을 업데이트하기 위해 사용할 수 있고 XMLHtpRequest API에 의해 요청되었을 수 있는 구조화된 데이터(동적 페이지 참조).

실제로는 클라이언트 요구 또는 구성 설정에 포함된 하나 이상의 파라미터에 따라 내용이 달라질 수 있는 경우 일반적으로 동적으로 생성됩니다.

응답 메시지 보내기

웹 서버 프로그램은 클라이언트 요청 ^[24]메시지에 대한 응답으로 응답 메시지를 보낼 수 있습니다.

요청 메시지를 성공적으로 읽거나 디코딩하거나 분석 또는 ^[25]실행할 수 없었기 때문에 오류 응답 메시지가 전송될 수 있습니다.

메모: 다음 섹션은 웹 서버의 기능을 이해하기 위한 예로서만 보고됩니다.이 섹션은 어디까지나 완전하지도 완전하지도 않습니다.

에러 메시지

웹 서버 프로그램은 클라이언트 요구 메시지에 다양한 종류의 오류 메시지로 응답할 수 있습니다.어쨌든 이러한 오류는 주로 다음 두 가지 범주로 나뉩니다.

• 요청 메시지 유형 또는 요청된 웹 ^[33]리소스 가용성으로 인한 HTTP 클라이언트 오류
• 내부 서버 ^[34]오류로 인한 HTTP 서버 오류입니다.

클라이언트 브라우저가 에러 응답/메시지를 수신하면 메인 사용자 요구(웹 페이지 등의 웹 리소스 URL 등)와 관련된 경우 보통 해당 에러 메시지가 브라우저 창/메시지에 표시됩니다.

URL 허가

웹 서버 프로그램은 요청된 URL ^[35]경로가 다음과 같은지 여부를 확인할 수 있습니다.

• 누구나 자유롭게 접근할 수 있다.
• 사용자 인증(사용자 이름 및 비밀번호 등 사용자 자격 정보의 요구)이 필요합니다.
• 일부 또는 모든 종류의 사용자에게는 접근이 금지됩니다.

인가/액세스 권한 기능이 실장되어 유효하게 되어 있어 Web 리소스에의 액세스가 허가되지 않은 경우, 필요한 액세스 권한에 따라서는, Web 서버 프로그램이 다음과 같이 됩니다.

• 특정 오류 메시지를 전송함으로써 접근을 거부할 수 있습니다(예: 접근 금지).
• 는, 특정의 에러 메세지(예를 들면, 액세스 허가 없음)를 송신하는 것에 의해서 액세스를 거부할 가능성이 있습니다.일반적으로 클라이언트브라우저는 필요한 사용자 credential을 제공하도록 요구받습니다.인증 credential이 제공되면 웹 서버 프로그램은 이를 검증 및 승인 또는 거부합니다.

URL 리다이렉션

웹 서버 프로그램은 새로운 URL(새로운 위치)에 URL 리다이렉션을 수행하는 기능을 가질 수 있습니다.이 기능은 유효한 웹 리소스 또는 기존 웹 리소스에 액세스하기 적합한 새로운 URL을 포함하는 응답 메시지로 클라이언트 요구 메시지에 응답하는 것으로 구성됩니다(클라이언트는 새로운 ^[36]URL을 사용하여 요청을 다시 실행해야 합니다).

로케이션의 URL 리다이렉션이 사용됩니다.^[36]

• 마지막 슬래시 '/'^[31]를 추가하여 디렉토리 이름을 수정한다.
• 이러한 종류의 웹 리소스를 찾을 수 있는 새 경로에 대한 기존 URL 경로의 새 URL을 제공합니다.
• 현재 도메인에 부하가 너무 많은 경우 새 URL을 다른 도메인에 제공합니다.

예 1: URL 경로는 디렉토리 이름을 가리키지만 마지막 슬래시 '/'가 없으므로 웹 서버는 클라이언트에 리다이렉트를 전송하여 고정 경로 ^[31]이름으로 요청을 다시 수행하도록 지시합니다.

송신원:
/directory1/directory2
수신인:
/directory1/directory2/

예 2: 파일 시스템 경로를 재구성하기 위해 문서 세트가 모두 웹 사이트 안으로 이동되었습니다.

송신원:
/directory1/directory2/2021-10-08/
수신인:
/directory1/directory2/2021/10/08/

예 3: 문서 세트가 모두 새 웹 사이트로 이동되었습니다. 이제 문서에 액세스하려면 보안 HTTPS 연결을 사용해야 합니다.

송신원:
http://www.example.com/directory1/directory2/2021-10-08/
수신인:
https://docs.example.com/directory1/2021-10-08/

위의 예는 가능한 리다이렉트 종류 중 일부에 불과합니다.

성공 메시지

웹 서버 프로그램은 요청된 웹 리소스 ^[37]데이터를 선택적으로 포함하는 유효한 클라이언트 요청 메시지에 성공 메시지로 응답할 수 있습니다.

웹 리소스 데이터가 클라이언트에 다시 전송되는 경우, 검색 방법에 따라 정적 컨텐츠 또는 동적 컨텐츠일 수 있습니다(파일 또는 일부 프로그램/모듈의 출력에서).

콘텐츠 캐시

평균 HTTP 응답 시간과 사용되는 하드웨어 리소스를 줄임으로써 웹 서버의 응답을 고속화하기 위해 많은 일반적인 웹 서버가 콘텐츠카테고리에 ^[38]특화된1개 이상의 콘텐츠캐시를 구현하고 있습니다^[39]

컨텐츠는, 통상은 그 발신기지 마다 캐쉬 됩니다.예를 들어 다음과 같습니다.

• 정적 콘텐츠:
  • 파일 캐시
• 동적 콘텐츠:
  • 동적 캐시(예:/프로그램 출력).

파일 캐시

지금까지 파일에 자주 랜덤으로 빠르게 액세스해야 했던 정적 콘텐츠는 1960년대 중반부터 1970년대 중반까지 주로 전자기계식 디스크에 저장되었습니다.유감스럽게도 이러한 종류의 디바이스와의 읽기 및 쓰기는 RAM의 속도나 OS의 초기 단계부터 매우 느린 동작으로 간주되어 왔습니다.st Disk 캐시와 OS 파일 캐시 서브시스템은 자주 액세스하는 데이터/파일의 I/O 작업을 가속화하기 위해 개발되었습니다.

OS 파일 캐시를 사용하더라도 디스크에 저장되는 디렉토리 및 파일의 I/O 처리 속도가 상대적으로 느리거나 때때로 느려지는 것은 곧 최상위 웹 서버에서 예상되는 성능 향상에 걸림돌이 되었습니다.특히 1990년대 중반 이후 웹 트래픽이 지속적으로 증가함에 따라 급증하기 시작했습니다.인터넷/네트워크 회선 속도의 용이성.

스태틱 파일의 처리속도를 향상시켜 최대 초당 요청/응답수(RPS)를 늘리는 방법에 관한 문제는 웹 서버 프로그램에 구현 가능한 유용한 ^[40]캐시 모델을 제안하기 위해 1990년대 중반부터 연구/연구되기 시작했습니다.^[41]

실제로 오늘날 많은 인기 있는 고성능 웹 서버 프로그램에는 자체 사용자 랜드 파일 캐시가 포함되어 있으며, 웹 서버 사용에 맞게 맞춤형으로 구현 및 ^[42]매개 변수를 사용합니다.^{[43] [44]}

RAID 및/또는 고속 솔리드 스테이트 드라이브(I/O 속도가 매우 빠른 스토리지 하드웨어)의 광범위한 채택으로 인해 약간 감소했지만, 물론 웹 서버에 파일 캐시가 포함되어 있다는 장점이 사라지지는 않았습니다.

동적 캐시

내부 모듈 또는 외부 프로그램에 의해 출력되는 동적 콘텐츠는 항상 자주 변경되지는 않을 수 있습니다(키/파라미터가 포함된 고유 URL이 지정됨). 따라서 한동안(1초에서 몇 시간 이상) 결과 출력을 RAM 또는 고속 ^[45]디스크에 캐시할 수 있습니다.

동적 캐시의 일반적인 용도는 웹 사이트에 뉴스, 날씨, 이미지, 지도 등에 관한 동적 웹 페이지가 자주 변경되지 않고(예를 들어 n분마다), 분당 엄청난 수의 클라이언트에 의해 액세스되는 경우입니다.이 경우 캐시된 콘텐츠도 (내부 모듈이나 외부 모듈로부터 호출하지 않고) 반환하는 것이 편리합니다.클라이언트의 브라우저 ^[46]캐시에 요청된 콘텐츠의 업데이트된 복사본이 없는 경우가 많기 때문입니다.

어쨌든 대부분의 경우 이러한 종류의 캐시는 하드웨어 자원(CPU, RAM, 디스크)^[47]을 웹 서버와 경쟁하지 않기 위해 외부 서버(리버스 프록시 등)에 의해 구현되거나 특정 애플리케이션(메모캐시 등)에 의해 관리되는 별도의 컴퓨터에 동적 데이터 출력을 저장함으로써 구현됩니다.^[48]

커널 모드 및 사용자 모드 웹 서버

웹 서버 소프트웨어는 OS에 통합되어 커널 공간에서 실행되거나 사용자 공간(다른 일반 응용 프로그램처럼)에서 실행될 수 있습니다.

커널 모드로 동작하는 웹 서버(통상 커널 공간 웹 서버라고 불린다)는 커널 리소스에 직접 액세스 할 수 있기 때문에 이론적으로는 사용자 모드로 동작하는 서버보다 고속입니다.어쨌든 웹 서버를 커널 모드로 동작시키는 것에는 단점이 있습니다.예를 들어 소프트웨어 개발(디버깅)의 어려움과 런타임 크리티컬 에러 등입니다.OS 커널에 심각한 문제가 발생할 수 있습니다.

사용자 모드로 동작하는 웹 서버는 시스템에 더 많은 메모리 또는 더 많은 CPU 리소스를 사용할 수 있는 권한을 요청해야 합니다.커널에 대한 이러한 요청은 시간이 걸릴 뿐만 아니라 시스템이 자체 사용을 위해 리소스를 예약하고 실행 중인 다른 모든 애플리케이션과 하드웨어 리소스를 공유할 책임이 있기 때문에 항상 충족되는 것은 아닙니다.또한 사용자 모드에서 실행하면 (사용자 공간과 커널 공간 간에) 더 많은 버퍼/데이터 복사본을 사용하여 사용자 모드 웹 서버의 성능이 저하될 수 있습니다.

오늘날에는 거의 모든 웹 서버 소프트웨어가 사용자 모드로 실행됩니다(앞서 언급한 작은 단점 중 많은 부분이 고속 하드웨어, 새로운 OS 버전, 훨씬 빠른 OS 시스템 호출 및 최적화된 새로운 웹 서버 소프트웨어에 의해 극복되었기 때문입니다).커널 모드 또는 사용자 모드(커널 공간 또는 사용자 공간이라고도 함)에서 실행되는 웹 서버 소프트웨어의 비교도 참조하십시오.

퍼포먼스

(클라이언트/브라우저측에서) 사용자 경험을 향상시키려면 웹 서버가 클라이언트의 요구에 대해 가능한 한 신속하게 응답해야 합니다.대용량 파일이나 대용량 파일 등 일부 유형의 파일에 대해 콘텐츠 응답이 제한되지 않는 한 반환되는 데이터 콘텐츠도 가능한 한 빨리 전송해야 합니다(고속 전송 속도).

즉, 웹 서버의 응답에 대한 사용자의 합계 대기시간(브라우저 시간 + 네트워크 시간 + 웹 서버 응답시간)을 가능한 한 낮게 유지하기 위해 웹 서버의 응답성은 항상 매우 높아야 합니다.

퍼포먼스 지표

웹 서버 소프트웨어의 주요 퍼포먼스 지표(다양한 동작 조건 하에서 측정)는 일반적으로 다음 지표(즉,^[49]

• 초당 요청 수(RPS, HTTP 버전 및 구성, HTTP 요청 유형 및 기타 동작 조건에 따라 QPS와 유사)
• 초당 연결 수(CPS)는 웹 서버가 허용하는 초당 연결 수(접속당 요청/응답 제한이 매우 낮은 HTTP/1.0 또는 HTTP/1.1을 사용할 때 유용합니다(예: 1 ..20).
• 네트워크 레이텐시 + 새로운 클라이언트 요구에 대한 응답 시간.보통 벤치마크 툴은 시간 경과 범위(1밀리초, 3밀리초, 5밀리초, 10밀리초, 20밀리초, 30밀리초, 40밀리초) 및/또는 최단, 평균 및 최장 응답 시간을 나타냅니다.
• 응답 스루풋(바이트/초)입니다(바이트/초).

동작 조건 중 테스트 중에 사용되는 동시 클라이언트 접속 수(1..n)는 웹 서버에서 지원되는 동시성 수준과 테스트된 성능 메트릭의 결과를 상관시킬 수 있기 때문에 중요한 파라미터입니다.

소프트웨어 효율

채택된 특정 웹 서버 소프트웨어 설계 및 모델(예:

• 단일 프로세스 또는 다중 프로세스
• 각 프로세스에 대해 단일 나사산(나사 없음) 또는 다중 나사산
• 코루틴 사용 여부

... 및 기타 프로그래밍 기법(예:

• 제로 카피
• 발생할 수 있는 CPU 캐시 누락 최소화
• 속도를 높이기 위해 중요한 경로에서 발생할 수 있는 CPU 브런치 오예측 최소화
• 특정 기능/작업 수행에 사용되는 시스템 호출 수 최소화
• 기타 요령

...웹 서버 프로그램을 구현하기 위해 사용되며, 특히 부하가 높은 경우 또는 하이엔드 하드웨어(많은 CPU, 디스크 및 대용량 RAM)를 사용할 때 달성할 수 있는 성능, 특히 확장성 수준을 크게 왜곡할 수 있습니다.

실제로 일부 웹 서버 소프트웨어 모델은 다른 모델보다 더 많은 OS 리소스(특히 더 많은 CPU와 더 많은 RAM)를 필요로 하는 경우가 있습니다.

동작 조건

웹 서버의 퍼포먼스에 영향을 주는 동작 조건은 여러 가지가 있습니다.퍼포먼스 값은 (예를 들어)에 따라 다를 수 있습니다.

• 웹 서버 설정(로그 파일이 활성화되거나 활성화되지 않은 점 등)
• 클라이언트 요구에 의해 사용되는HTTP 버전
• 평균 HTTP 요청 유형(방식, HTTP 헤더 길이 및 옵션 본문)
• 요청된 내용이 정적인지 동적인지 여부
• 콘텐츠 캐시 여부(서버별 또는 클라이언트별)
• 컨텐츠가 즉시 압축되는지(전송되는 경우), 사전 압축되었는지(즉, 웹 서버가 컨텐츠가 압축되었음을 나타내는 유일한 표시로 해당 파일을 네트워크에 직접 전송할 수 있도록 파일 리소스가 이미 압축된 경우) 또는 전혀 압축되지 않았는지 여부.
• 접속이 암호화되어 있는지 여부
• 웹 서버와 클라이언트 간의 평균 네트워크 속도
• 액티브 TCP 접속의 수
• 웹 서버에 의해 관리되는 활성 프로세스의 수(외부 CGI, SCGI, FCGI 프로그램 포함)
• 웹 서버가 실행되는 컴퓨터 OS의 하드웨어 및 소프트웨어 제한 또는 설정
• 기타 경미한 조건

벤치마킹

웹 서버의 성능은 일반적으로 사용 가능한 자동 부하 테스트 도구 중 하나 이상을 사용하여 벤치마킹됩니다.

부하 제한

웹 서버(프로그램 설치)는 통상, 동작 조건의 각 조합에 대해서 사전에 정의된 부하 제한이 있습니다.또, OS 리소스에 의해서 제한되고, 동시 클라이언트 접속의 수가 한정되어 있기 때문에(통상은 액티브한 Web 서버 프로세스 마다 2 ~ 수만 개), 「C10k Probl」도 참조해 주세요.C10M의 문제).

웹 서버가 부하 제한에 근접하거나 초과하면 과부하가 걸리기 때문에 응답하지 않을 수 있습니다.

과부하의 원인

다음 원인 중 하나(예: 웹 서버)로 인해 언제든지 과부하가 발생할 수 있습니다.

• 정규 웹 트래픽이 초과되었습니다.단시간에 웹 사이트에 접속하는 클라이언트(예: Slashdot 효과).
• 분산 서비스 거부 공격입니다.서비스 거부 공격(DoS 공격) 또는 분산 서비스 거부 공격(DDoS 공격)은 컴퓨터 또는 네트워크 리소스를 원하는 사용자가 사용할 수 없도록 하려는 시도입니다.
• 감염된 수백만 대의 컴퓨터(그들 간에 조정되지 않음)로 인해 비정상적인 트래픽을 일으킬 수 있는 컴퓨터 웜입니다.
• XSS 웜은 수백만 개의 브라우저 또는 웹 서버에 감염되어 높은 트래픽을 일으킬 수 있습니다.
• 인터넷 봇 네트워크 리소스(대역폭 등) 및/또는 하드웨어 리소스(CPU, RAM, 디스크)가 매우 적은 대규모 웹 사이트에서는 트래픽이 필터링/제한되지 않습니다.
• 인터넷(네트워크)의 처리 속도가 저하되어(패킷 손실로 인해) 클라이언트 요구의 처리 속도가 느려지고 접속 수가 증가하여 서버 제한에 도달합니다.
• 동적 콘텐츠를 제공하는 웹 서버, 백엔드 컴퓨터(데이터베이스 등)로부터의 응답이 느립니다.이 경우 웹 서버는 HTTP 클라이언트에 응답하기 전에 백엔드 데이터 응답을 기다려야 하지만 새로운 클라이언트 연결을 너무 많이 대기합니다.tions/요구가 도착하여 과부하가 됩니다.
• 웹 서버(컴퓨터)가 부분적으로 사용할 수 없습니다.이 문제는 백엔드(데이터베이스 등) 장애와 같은 필수 또는 긴급한 유지보수 또는 업그레이드, 하드웨어 또는 소프트웨어 장애로 인해 발생할 수 있습니다.이 경우 나머지 웹 서버가 너무 많은 트래픽을 수신하여 과부하가 될 수 있습니다.

과부하 증상

과부하 웹 서버의 증상은 보통 다음과 같습니다(예:

• 요구는 (아마도 긴) 지연(1초에서 수백 초)으로 처리됩니다.
• 웹 서버가 500, 502,^[51][52] 503,^[53] 504,^[54] 408 등의 HTTP 오류 코드를 반환하거나 간헐적인 404를 반환한다.
• 웹 서버는 콘텐츠를 반환하기 전에 TCP 연결을 거부하거나 리셋(중단)합니다.
• 매우 드문 경우지만 웹 서버는 요청된 내용의 일부만 반환합니다.이 동작은 보통 과부하의 증상으로 발생하는 경우에도 버그로 간주할 수 있습니다.

과부하 방지 기술

평균 부하 제한을 부분적으로 극복하고 과부하를 방지하기 위해 대부분의 인기 웹사이트는 다음과 같은 일반적인 기술(예:

• 하드웨어 기능 및 사용 상황에 맞게 OS 파라미터를 조정합니다.
• 웹 서버 파라미터를 조정하여 보안과 성능을 향상시킵니다.
• 웹 캐시 기술(정적 콘텐츠뿐만 아니라 가능하면 동적 콘텐츠에도)의 전개
• 다음을 사용하여 네트워크 트래픽 관리:
  • 불량 IP 소스 또는 불량 패턴을 가진 원치 않는 트래픽을 차단하는 방화벽
  • HTTP 트래픽 매니저가 부정한 HTTP 패턴을 가진 요구를 폐기, 리다이렉트 또는 개서한다.
  • 네트워크 사용률의 피크를 완화하기 위한 대역폭 관리 및 트래픽쉐이핑
• 다른 도메인 이름, IP 주소 및 컴퓨터를 사용하여 다양한 종류의 콘텐츠(정적 및 동적)를 제공합니다.이 목적은 큰 파일 또는 큰 파일을 분리하는 것입니다.download.*(이 도메인은 CDN으로도 대체될 수 있습니다)소형 및 중형 파일(static.*메인 다이내믹사이트(일부 콘텐츠가 백엔드 데이터베이스에 저장되어 있을 가능성이 있음)에서 송신됩니다.www.*웹 서버 컴퓨터의 (그룹)마다 다른 설정을 사용하여 큰 파일 또는 큰 파일(10~1000MB 이상)을 효율적으로 처리할 수 있고(다운로드 제한), 부하가 높은 동적 사이트의 성능에 영향을 주지 않고 중소규모 파일을 완전히 캐시할 수 있습니다.예를 들어 다음과 같습니다.
  • https://download.example.com
  • https://static.example.com
  • https://www.example.com
• 로드 밸런서의 배후에 그룹화된 다수의 Web 서버(컴퓨터)를 사용하고, 이러한 서버(컴퓨터)가 동작하거나 하나의 큰 Web 서버로서 인식되도록 합니다.
• 각 컴퓨터에 하드웨어 리소스(RAM, 고속 디스크 등) 추가
• 보다 효율적인 웹 서버용 컴퓨터 프로그램 사용(「소프트웨어 효율」도 참조).
• 가장 효율적인 웹 서버 게이트웨이 인터페이스를 사용하여 동적 요청을 처리합니다(동적 페이지를 가져올 때마다 하나 이상의 외부 프로그램을 생성하면 성능이 저하됩니다).
• 다른 프로그래밍 기술 및 회피책을 사용하여(특히 동적 콘텐츠가 관련되어 있는 경우) HTTP 응답을 고속화합니다(스타일 시트, 이미지, 스크립트 등 거의 변경되지 않는 오브젝트를 취득하는 동적 호출을 회피함).이 오브젝트를 정적 파일에 한 번 복사한 후 dy와 동기화된 상태로 유지합니다.namic content)를 참조해 주세요.
• HTTP의 효율적인 최신 버전 사용(예를 들어 이용 가능한 웹 서버 소프트웨어에서 후자의 2개의 프로토콜을 확실하게 지원할 수 있는 경우 HTTP/2를 활성화하고 HTTP/3를 활성화함으로써 공통 HTTP/1.1을 사용할 수 없음)을 통해 각 클라이언트에 의해 시작되는 TCP/IP 접속 수와 교환되는 데이터 크기를 크게 줄입니다(HT가 소형화되어 있음).TP 헤더 표현 및 데이터 압축).

HTTP/2 및 HTTP/3 프로토콜 사용에 대한 경고

새로운 HTTP(2 및 3) 프로토콜은 보통 요구/응답 데이터별로 네트워크 트래픽을 적게 생성하지만 웹 서버 소프트웨어에서 사용하는 OS 리소스(RAM 및 CPU 등)가 더 많이 필요할 수 있습니다(암호화된 데이터, 스트림 버퍼 및 기타 구현 세부 정보 때문에). 이 외에도 HTTP/2 및 HTTP/3도 설정에 따라 다를 수 있습니다.f 웹 서버 및 클라이언트 프로그램은 데이터 스트림이 요청 동시화에 최적화되어 있기 때문에 매우 빠른 속도로 대용량 또는 대용량 파일을 업로드하는 데 최적의 옵션이 아닐 수 있습니다.따라서 대부분의 경우 HTTP/1.1 TCP/IP 연결을 사용하면 결과나 업로드 속도가 향상될 수 있습니다(마일리지가 ^[55][56]다를 수 있습니다).

시장 점유율

다음은 넷크래프트의 인터넷 상위 웹 서버 전체 사이트 시장 점유율 최신 통계다.

웹 서버: 모든 사이트의 시장 점유율

날짜.	nginx (Nginx, Inc.)	Apache(ASF)	OpenResty (OpenResty 소프트웨어 재단)	Cloudflare 서버(Cloudflare, Inc.)	IIS(Microsoft)	GWS(구글)	다른이들
2021년 10월[57]	34.95%	24.63%	6.45%	4.87%	4.00% (*)	4.00% (*)	22 % 미만
2021년 2월[58]	34.54%	26.32%	6.36%	5.0%	6.5%	3.90%	18 % 미만
2020년 2월[59]	36.48%	24.5%	4.00%	3.0%	14.21%	3.18%	15% 미만
2019년 2월[60]	25.34%	26.16%	없음	없음	28.42%	1.66%	19 % 미만
2018년 2월[61]	24.32%	27.45%	없음	없음	34.50%	1.20%	13 % 미만
2017년 2월[62]	19.42%	20.89%	없음	없음	43.16%	1.03%	15% 미만
2016년 2월[63]	16.61%	32.80%	없음	없음	29.83%	2.21%	19 % 미만

메모: (*) 퍼센티지는 정수로 반올림합니다.이것은, 그 10 진수가 소스 페이지에 의해서 공개 보고되지 않기 때문입니다(반올림한 값만이 그래프에 표시됩니다).

「 」를 참조해 주세요.

• 서버(컴퓨팅)
• 응용 프로그램 서버
• 웹 서버 소프트웨어 비교
• HTTP 서버(HTTP 요구를 처리하는 웹 서버 프로그램의 핵심 부분)
• HTTP 압축
• 웹 어플리케이션
• 오픈 소스 웹 응용 프로그램
• AMP 패키지 목록
• 바리안트 오브젝트
• 가상 호스팅
• 웹 호스팅 서비스
• 웹 컨테이너
• 웹 프록시
• 웹 서비스

동적 콘텐츠에 사용되는 표준 웹 서버 게이트웨이 인터페이스:

• CGI 공통 게이트웨이 인터페이스
• SCGI Simple Common Gateway 인터페이스
• Fast CGI Fast Common Gateway 인터페이스

동적 콘텐츠에 사용되는 기타 웹 서버 인터페이스(서버 또는 프로그래밍 언어 고유):

• SSI 서버측 SSI 지령을 포함한 정적 HTML 문서를 포함하지만 거의 사용되지 않습니다.서버 소프트웨어는 페이지 서비스 시 작은 동적 데이터(예: 날짜 및 시간, 기타 정적 파일 컨텐츠 등)를 즉시 포함하도록 해석합니다.
• SAPI 서버 애플리케이션 프로그래밍 인터페이스:
  • ISAPI 인터넷 서버 애플리케이션 프로그래밍 인터페이스
  • NSAPI Netscape 서버 애플리케이션프로그래밍 인터페이스
• PSGI Perl 웹 서버 게이트웨이 인터페이스
• WSGI Python 웹 서버 게이트웨이 인터페이스
• 랙랙 웹 서버 게이트웨이 인터페이스
• JSGI JavaScript 웹 서버 게이트웨이 인터페이스
• Java Servlet, JavaServer 페이지
• 액티브 서버 페이지, ASP.네트워크

레퍼런스

외부 링크

• Mozilla: 웹 서버란?
• Netcraft: 웹 서버 조사에 대한 뉴스