맨위로가기

웹 서버

"오늘의AI위키"는 AI 기술로 일관성 있고 체계적인 최신 지식을 제공하는 혁신 플랫폼입니다.
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.
목차

1. 개요

웹 서버는 클라이언트에게 웹 페이지를 전달하는 컴퓨터 프로그램으로, 그림, CSS, 자바스크립트, HTML 문서 등을 전송한다. 클라이언트는 HTTP를 통해 리소스를 요청하고, 서버는 해당 리소스를 반환하거나 오류 메시지를 보낸다. 웹 서버는 정적 및 동적 콘텐츠를 제공하며, 인증, 가상 호스팅, 데이터 압축, 동적 콘텐츠 제공 등 다양한 기능을 수행한다. 주요 웹 서버로는 Apache, IIS, Nginx 등이 있으며, 시장 점유율 경쟁이 치열하다. 웹 서버의 성능은 초당 요청 수, 연결 수, 응답 시간, 처리량 등에 의해 측정되며, 과부하를 방지하기 위해 다양한 기술이 사용된다.

2. 역사

최초의 웹 제안 (1989)은 ''"모호하지만 흥미로운..."'' 것으로 평가되었다.


웹 서버의 역사는 월드 와이드 웹(WWW), 웹 브라우저, 인터넷의 역사와 겹치는 부분이 많다.

  • 1989년: 유럽 입자 물리 연구소(CERN)의 팀 버너스리가 "Information Management: A Proposal(정보 관리: 제안)"을 작성하여 웹 시스템의 초안을 제안했다.
  • 1990년 11월: WWW를 구체화한 제안서가 발표되었고, 11월 13일부터 개발이 시작되었다.
  • 1990년 12월 ~ 1991년 1월: 최초의 웹 페이지 전개를 위해 HTTP 서버 『CERN httpd』와 각종 도구가 NEXTSTEP / NeXT 워크스테이션에 구현되었다.
  • 1991년 8월: 웹 서버와 라인 기반 웹 브라우저를 통한 프로젝트 성과 요약이 뉴스 그룹에 투고되어 WWW와 웹 서버가 데뷔했다.
  • 1992년 이후: 일리노이 대학교 미국 국립 슈퍼컴퓨터 응용 연구소(NCSA)의 로버트 맥쿨 등이 『NCSA HTTPd』를 개발하고, 마크 앤드리슨 등이 이미지 표시가 가능한 웹 브라우저 NCSA Mosaic를 개발하여 웹이 대중화되었다.


초기에는 『CERN httpd』와 『NCSA HTTPd』가 주류였으나, NCSA HTTPd의 패치 프로젝트인 Apache HTTP Server가 등장하면서 주도권이 넘어갔다.

2015년에는 Apache와 그 파생 HTTP Server가 시장의 40%, 마이크로소프트 IIS가 30%, nginx가 약 20%를 차지했다.[62] 2024년에는 nginx가 40%, Apache가 25%, Microsoft가 약 10%를 차지하고 있다.[63]

웹 서버는 UNIX에서 발전해 왔기 때문에, 주로 오픈 계열 서버인 UNIX 서버나 Windows 계열 서버에서 구현되었다. 그러나 HTTP, FTP, TCP/IP를 사용할 수 있는 범용 컴퓨터에서도 동작하는 경우도 있다.

2. 1. 초기 WWW 프로젝트 (1989–1991)

팀 버너스리는 1989년 3월, 그가 재직하던 유럽 입자 물리 연구소(CERN)에 과학자들 간의 정보 교환을 쉽게 하기 위해 하이퍼텍스트 시스템을 사용하는 새로운 프로젝트를 제안했다.[3][4][5] 1990년 10월, 이 제안서는 로베르 카이요와 함께 수정 및 보완되어 최종 승인되었다.

최초의 웹 서버, NeXT 컴퓨터 워크스테이션, 1990년. 케이스 라벨에는 "이 기계는 서버입니다. 전원을 끄지 마십시오!!"라고 적혀있다.


1990년 말부터 1991년 초까지, 버너스리와 그의 개발자들은 NeXT 워크스테이션에 설치된 NEXTSTEP 운영 체제에서 실행되는 세 가지 프로그램을 개발하고 테스트했다.

이 초기 브라우저들은 HTML의 초기 단순한 형태로 작성된 웹 페이지를, 새로운 기본 통신 프로토콜인 HTTP 0.9를 사용하여 웹 서버에서 가져왔다.

1991년 8월, 팀 버너스리는 "WWW 기술의 탄생"을 발표하고 과학자들이 이를 채택하고 개발하도록 장려했다.[8] CERN은 소스 코드를 비공식적으로 실험하고 추가 개발하는 것을 허용했다. 버너스리는 프로그램들의 채택과 사용, 그리고 다른 운영 체제로 포팅하는 것을 장려했다.[5]

다음은 초기 WWW 프로젝트의 주요 연혁이다.

연도사건
1989년팀 버너스리가 CERN에 "Information Management: A Proposal(정보 관리: 제안)"을 제출.
1990년 11월World Wide Web을 구체화한 제안서를 발표. 11월 13일부터 개발 시작.
1990년 12월 ~ 1991년 1월CERN httpd와 관련 도구를 NEXTSTEP / NeXT 워크스테이션에 구현.
1991년 8월웹 서버와 라인 기반 웹 브라우저를 통한 프로젝트 성과 요약을 뉴스 그룹에 투고.


2. 2. 빠른 개발 (1991–1995)

1991년 12월, 유럽 입자 물리 연구소(CERN) 외 최초의 웹 서버가 미국 SLAC에 설치되었다.[7] 이는 웹 브라우저와 웹 서버 간의 대륙간 웹 통신을 시작했다는 점에서 매우 중요한 사건이었다.

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

1993년 4월, CERN은 웹 소프트웨어의 세 가지 구성 요소(기본 라인 모드 클라이언트, 웹 서버 및 공통 코드 라이브러리)와 해당 소스 코드를 퍼블릭 도메인에 공개한다고 공식 발표했다.[11] 이 발표로 웹 서버 개발자들은 해당 소스 코드를 기반으로 한 파생 작업 개발에 관한 법적 문제로부터 자유로워졌다.

1994년 초, 주목할 만한 새로운 웹 서버는 다양한 유닉스 기반 OS에서 실행되었으며 `POST` HTTP 메서드와 외부 프로그램과의 통신을 위한 CGI를 구현하여 동적으로 생성된 콘텐츠를 제공할 수 있었던 NCSA httpd였다. 이러한 기능과 NCSA의 Mosaic 브라우저(웹 서버에 데이터를 전송하기 위해 HTML FORM을 관리할 수 있음)의 멀티미디어 기능은 웹 기술의 출판 및 분산 컴퓨팅 애플리케이션의 잠재력을 강조했다.

1994년 하반기에 NCSA httpd의 개발이 중단되어, 해당 서버에 관심 있는 외부 소프트웨어 개발자, 웹마스터 및 기타 전문가 그룹이 NCSA httpd 소스 코드가 퍼블릭 도메인으로 공개된 덕분에 패치를 작성하고 수집하기 시작했다. 1995년 초, 이러한 패치는 모두 NCSA 소스 코드의 마지막 릴리스에 적용되었고, 여러 테스트를 거친 후 Apache HTTP server 프로젝트가 시작되었다.[12][13]

1994년 말, Netsite라는 새로운 상용 웹 서버가 특정 기능을 갖추고 출시되었다. 이 서버는 Netscape에 의해, 그리고 이후 Sun Microsystems, 마지막으로 Oracle Corporation에 의해 개발된 여러 유사한 제품 중 첫 번째 제품이었다.

1995년 중반, Microsoft는 Windows NT OS용 IIS의 첫 번째 버전을 출시했다. 이는 월드 와이드 웹 기술 분야에서 웹의 양쪽(클라이언트와 서버) 모두에서 중요한 역할을 해왔고, 지금도 수행하고 있는 매우 중요한 상업 개발자이자 공급업체의 등장을 알렸다.

1995년 하반기에 CERN 및 NCSA 웹 서버는 이전 서버보다 개발 주기가 훨씬 빠르고, 더 많은 기능, 더 많은 수정 사항이 적용되었으며, 성능이 향상된 새로운 웹 서버의 광범위한 채택으로 인해 (전체 사용 비율에서) 감소하기 시작했다.

2. 3. 폭발적인 성장과 경쟁 (1996–2014)

1996년 말, 인터넷 도메인 이름을 소유하거나 웹사이트를 호스팅하려는 모든 사람이 사용할 수 있는 50개가 넘는 웹 서버 소프트웨어 프로그램이 이미 알려져 있었다.[15] 이들 중 다수는 짧은 기간만 존재하다가 다른 웹 서버로 대체되었다.

RFC HTTP/1.0 (1996) 및 HTTP/1.1 (1997, 1999) 프로토콜 버전 발표로 인해 대부분의 웹 서버는 (항상 완전히는 아니지만) 해당 표준을 준수해야 했다. TCP/IP 지속적 연결 (HTTP/1.1)의 사용으로 웹 서버는 허용되는 최대 동시 연결 수를 늘리고 확장성을 개선해야 했다.

1996년에서 1999년 사이에 넷스케이프 엔터프라이즈 서버(Netscape Enterprise Server)와 마이크로소프트(Microsoft)의 IIS가 주요 상용 옵션으로 부상했으며, 무료로 제공되는 오픈 소스 프로그램 중에서는 아파치 HTTP 서버(Apache HTTP Server)가 신뢰성과 다양한 기능으로 인해 선호되는 서버로 선두를 유지했다.

당시에는 제우스(Zeus) (''현재 단종됨'')라는 또 다른 상업적이고 혁신적인 웹 서버가 있었는데, 2000년대 초반까지는 시장에서 가장 빠르고 확장성이 뛰어난 웹 서버 중 하나로 알려져 있었지만, 사용 비율은 낮았다.

아파치는 1996년 중반부터 2015년 말까지 가장 많이 사용되는 웹 서버였으며, 몇 년간의 쇠퇴 이후 처음에는 IIS에, 그다음에는 Nginx에 의해 추월당했다. 이후 IIS는 아파치보다 훨씬 낮은 사용 비율로 떨어졌다.

2005–2006년부터 아파치는 새로운 성능 기능 (예: 이벤트 MPM 및 새로운 콘텐츠 캐시)을 도입하여 속도와 확장성 수준을 개선하기 시작했다.[16][17] 이러한 새로운 성능 개선 사항은 초기에 실험적인 것으로 표시되었기 때문에 사용자들이 오랫동안 활성화하지 않았고, 아파치는 상용 서버, 특히 개발 초창기부터 훨씬 우수한 성능을 달성하고 아파치 쇠퇴기에 잘 테스트된 고급 기능 목록을 제공할 수 있었던 다른 오픈 소스 서버와의 경쟁으로 더욱 어려움을 겪었다 (대부분 정적 콘텐츠를 제공할 때).

실제로 2000년 이후 몇 년 만에 라이트스피드(LiteSpeed)를 비롯한 다른 상업적이고 경쟁력 있는 웹 서버뿐만 아니라, Hiawatha, 체로키 HTTP 서버(Cherokee HTTP server), Lighttpd, Nginx 및 상업적 지원과 함께 제공되는 기타 파생/관련 제품과 같은 뛰어난 품질과 매우 높은 성능을 가진 많은 오픈 소스 프로그램이 등장했다.

2007–2008년경 대부분의 인기 있는 웹 브라우저는 호스트-도메인당 2개의 지속적 연결 (RFC-2616에서 권장하는 제한)[18]의 이전 기본 제한을 4, 6 또는 8개의 지속적 연결로 늘려 이미지가 많은 무거운 웹 페이지의 검색 속도를 높이고, 웹 페이지에서 양방향 이벤트 알림에 사용되는 동적 객체에 할당된 지속적 연결 부족 문제를 완화했다.[19] 1년 이내에 이러한 변경 사항으로 인해 웹 서버가 관리해야 하는 최대 지속적 연결 수가 평균적으로 거의 세 배로 증가했다. 이러한 추세 (지속적 연결 수 증가)는 느린 웹 서버 앞에 리버스 프록시를 채택하는 데 강력한 추진력을 제공했으며, 너무 많은 하드웨어 리소스 (CPU, RAM, 빠른 디스크가 많은 고가의 컴퓨터)를 요구하지 않고도 매우 많은 동시 연결을 처리할 수 있는 속도와 기능을 보여줄 수 있는 새로운 웹 서버에게 또 다른 기회를 제공했다.[20]

썬 마이크로시스템즈의 SOHO용 웹 서버 Sun Cobalt Qube 3 (2002년)

2. 4. 새로운 도전 (2015년 이후)

2015년에 새로운 프로토콜 버전인 HTTP/2를 정의하는 RFC가 발표되었다. 하지만 새로운 사양의 구현은 난이도가 높아서 사용 비율이 1%에서 2% 미만인 '''비교적 덜 대중적인 웹 서버 개발자들''' 사이에서는 이 새로운 프로토콜 버전을 지원할지 여부에 대한 고민이 발생했다.[21][22]

HTTP/2를 지원하려면 여러 요인으로 인해 내부 구현을 근본적으로 변경해야 하는 경우가 많았다. 예를 들어, 항상 암호화된 연결이 필요하고, 동일한 TCP 포트에서 HTTP/1.x 연결과 HTTP/2 연결을 구분해야 했으며, HTTP 메시지의 이진 표현, 메시지 우선순위, HTTP 헤더 압축, 스트림(TCP/IP 하위 연결) 사용 및 관련 흐름 제어 등이 필요했다. 이러한 이유로 일부 웹 서버 개발자들은 새로운 HTTP/2 버전 지원을 하지 않는 것을 선택했다.[21][22] 그들이 지원을 미룬 이유는 다음과 같다.

  • HTTP/1.x 프로토콜은 브라우저에서 매우 오랫동안 지원될 것이기 때문에 가까운 미래에 클라이언트와 서버 간의 호환성 문제는 없을 것이다.
  • HTTP/2 구현은 압도적인 복잡성을 가진 작업으로 새로운 종류의 버그 발생 가능성을 열어 개발 및 테스트에 상당한 투자가 필요했을 것이다.
  • HTTP/2 지원은 노력이 정당화될 경우 언제든지 나중에 추가할 수 있었다.


반면, '''가장 인기 있는 웹 서버 개발자들은 새로운 프로토콜을 빠르게 제공하기 위해 노력했다'''. 이는 그들이 충분한 인력과 시간을 가지고 있었고, 이전의 SPDY 프로토콜 구현을 재사용할 수 있었기 때문이다. 가장 많이 사용되는 웹 브라우저에서도 같은 이유로 매우 빠르게 구현했다. 웹마스터들이 웹 트래픽 증가에 대한 압박을 느껴 TCP/IP 연결 수를 줄이고 웹사이트 접근 속도를 높일 수 있는 기능을 빨리 설치하고 싶어했기 때문에 개발자들이 신속하게 행동하도록 했다.[23]

2020-2021년에는 HTTP/3 프로토콜에 대한 RFC 초안이 발표된 후 HTTP/2 구현에 대한 역학이 부분적으로 반복되었다.

3. 기술 개요

웹 서버의 주된 기능은 클라이언트에게 웹 페이지를 전달하는 것이다. 이때 그림, CSS, 자바스크립트 등을 포함한 HTML 문서가 주로 전달된다. 웹 브라우저나 웹 크롤러와 같은 클라이언트는 HTTP를 통해 리소스를 요청하며, 서버는 해당 리소스를 반환하거나 처리할 수 없을 경우 에러 메시지를 전송한다.[1] 리소스는 보통 서버의 보조 기억 장치에 있는 파일을 가리키지만, 항상 그런 것은 아니다.

PC 클라이언트가 인터넷을 통해 웹 서버에 연결됨


웹 서버는 콘텐츠 제공뿐만 아니라 파일 업로드 등 클라이언트로부터 콘텐츠를 전달받는 기능도 수행한다. 또한, 서버 사이드 스크립트 언어(Server-side scripting)를 지원하여 HTML 문서를 동적으로 생성할 수 있다. ASP, PHP 등의 스크립트 언어를 통해 데이터베이스의 정보를 조회하거나 수정하여 동적 컨텐트를 생성하는데, 이는 정적 컨텐트보다 속도는 느리지만 유연하게 내용을 바꿀 수 있다.[1]

웹 서버는 월드 와이드 웹 외에도 프린터, 라우터, 웹캠과 같은 임베디드 장치나 근거리 통신망(local network)에서도 시스템 모니터링 및 장치 관리를 위해 사용된다. 이 경우 클라이언트는 별도 소프트웨어 설치 없이 웹 브라우저만으로 서비스를 이용할 수 있다.

웹 서버 프로그램은 클라이언트-서버 모델에서 서버 역할을 하며, 하나 이상의 HTTP 프로토콜 버전을 구현한다. HTTPS 보안 변형과 기타 기능 및 확장을 포함하는 경우가 많다.

클라이언트 웹 브라우저의 URL에 지정된 정보를, HTTP에 따른 TCP/IP 소켓 스트림(HTTP 커넥션)에 전송한다. 보통 복수의 커넥션을 설정하고, HTML 문서와 이미지 파일 등을 병렬 전송하여 처리 시간을 단축한다.

CGI 스크립트나 Java Servlet을 통해 웹 화면과 연동된 동적 처리를 수행할 수 있다. CGI 처리에는 Perl, Ruby, PHP 등의 스크립트 언어가 주로 사용된다. Java Servlet은 부하 분산을 위해 별도 서버로 분리하기도 한다. 대규모 웹 서비스에서는 로드 밸런서를 사용하여 여러 웹 서버로 처리를 분산시킨다.

또한, 불특정 다수의 웹 브라우저(클라이언트)와의 접속을 수행하기 위해, 일반적으로 웹 서버 및 웹 애플리케이션 서버에는 DNS 서버와의 연동 설정을 통합한다.

3. 1. 공통 기능

웹 서버 프로그램은 구현 방식이 다르지만, 대부분 다음과 같은 공통 기능을 제공한다.[1]

  • HTTP: HTTP 요청과 응답을 처리한다.
  • 통신 기록: 클라이언트 요청 및 서버 응답에 대한 정보를 로그 파일에 기록한다.


대부분의 웹 서버는 다음과 같은 추가 기능도 제공한다.[1]

  • 인증: 사용자 인증 기능을 제공한다.
  • 정적 콘텐츠 관리: 정적 콘텐츠를 효율적으로 관리한다.
  • HTTPS 지원: 보안 연결을 지원한다.
  • 콘텐츠 압축: 전송 속도를 높이기 위해 콘텐츠를 압축한다.
  • 가상 호스팅: 하나의 IP 주소로 여러 웹사이트를 운영할 수 있게 한다.
  • 대용량 파일 지원: 큰 파일(2GB 이상)을 처리할 수 있다.
  • 대역폭 스로틀링: 네트워크 과부하를 방지하기 위해 대역폭을 조절한다.

3. 2. 요청 메시지 처리

웹 서버는 클라이언트로부터 HTTP를 통해 리소스를 요청받는다. 서버는 해당 리소스를 반환하거나, 처리할 수 없을 경우 오류 메시지를 전달한다. 리소스는 보통 서버의 보조 기억 장치에 있는 실제 파일을 가리키지만, 웹 서버의 구현 방식에 따라 달라질 수 있다.[1]

웹 서버는 파일을 업로드하는 등 클라이언트로부터 콘텐츠를 전달받는 기능도 수행한다. 또한, ASP, PHP 등 서버 사이드 스크립트 언어를 지원하여 HTML 문서를 동적으로 생성할 수 있다. 이렇게 생성된 동적 컨텐트는 데이터베이스의 정보를 조회하거나 수정하는 데 사용된다. 정적 컨텐트는 동적 컨텐트보다 빠르고 쉽게 캐시되지만, 내용은 항상 동일하다.[1]

웹 서버 프로그램은 HTTP 요청 메시지를 읽고 해석하며, 구문을 확인하고, 알려진 HTTP 헤더를 식별하여 해당 값들을 추출한다.[24] 이를 통해 요청을 충족시킬 수 있는지 판단하며, 여기에는 컴퓨터 보안을 포함한 여러 단계가 필요하다.[25]

클라이언트 웹 브라우저의 URL에 지정된 정보를, HTTP에 따른 TCP/IP 소켓 스트림(HTTP 커넥션)에 전송한다. 보통 복수의 커넥션을 설정하고, HTML 문서와 이미지 파일 등을 병렬 전송하여 처리 시간을 단축한다.[26]

CGI 스크립트나 Java Servlet을 통해 웹 화면과 연동된 동적 처리를 수행할 수 있다. CGI 처리에는 Perl, Ruby, PHP 등의 스크립트 언어가 주로 사용된다.[26] Java Servlet은 부하 분산을 위해 별도 서버로 분리하여 수직 분산(스케일 아웃)하기도 한다.[26] 대규모 웹 서비스에서는 로드 밸런서를 사용하여 여러 웹 서버로 처리를 분산시킨다.[26]

3. 2. 1. URL 정규화

웹 서버 프로그램은 일반적으로 다음과 같은 목적으로 URL 정규화(대부분의 HTTP 요청 메시지에서 발견되는 URL)를 수행한다.

  • 웹사이트의 루트 디렉토리에서 항상 깔끔하고 균일한 리소스 경로를 만든다.
  • 보안 위험을 낮춘다(예: 웹사이트의 루트 디렉토리 외부의 정적 리소스에 접근하거나 웹사이트 루트 디렉토리 아래의 접근이 금지되거나 권한이 필요한 경로에 접근하려는 시도를 더 쉽게 차단함으로써).
  • 웹 리소스의 경로를 인간과 웹 로그 분석 프로그램(로그 분석기/통계 응용 프로그램이라고도 함)이 더 쉽게 인식하도록 한다.


"URL 정규화"라는 용어는 URL을 일관된 방식으로 수정하고 표준화하는 프로세스를 의미한다. 스키마와 호스트를 소문자로 변환하는 것을 포함하여 여러 유형의 정규화가 수행될 수 있다. 가장 중요한 정규화 중에는 "." 및 ".." 경로 세그먼트 제거, 빈 경로 구성 요소가 아닌 경로에 후행 슬래시를 추가하는 것이 있다.

3. 2. 2. URL 매핑

URL 매핑은 URL이 참조하는 리소스를 파악하여 요청하는 클라이언트에 해당 리소스를 반환할 수 있도록 분석하는 과정이다. 이 과정은 웹 서버에 대한 모든 요청에 대해 수행되며, 일부 요청은 HTML 문서나 GIF 이미지와 같은 파일로 처리되고, 다른 요청은 CGI 프로그램 실행 결과로 처리되며, 또 다른 요청은 내장 모듈 처리기, PHP 문서 또는 Java 서블릿과 같은 다른 프로세스에 의해 처리된다.[27]

실제로, 단순한 ''정적 콘텐츠 제공''(예: URL 재작성 엔진, 동적 콘텐츠 제공) 이상의 고급 기능을 구현하는 웹 서버 프로그램은 일반적으로 해당 URL을 처리하는 방법을 파악해야 한다. 예를 들어 다음과 같다.

  • URL 리디렉션: 다른 URL로 리디렉션한다.
  • 파일 콘텐츠의 ''정적 요청''
  • ''동적 요청'' 중:
  • 해당 디렉토리에 포함된 파일 또는 다른 하위 디렉토리의 디렉토리 목록
  • 해당 URL 경로를 처리할 수 있는 프로그램/모듈 프로세서를 식별하고 다른 URL 부분(일반적으로 경로 정보 및 쿼리 문자열 변수)을 전달하기 위한 기타 유형의 동적 요청


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

웹 서버가 위에 언급된 고급 기능 중 하나 이상을 구현하는 경우, 유효한 URL의 경로 부분은 웹사이트 디렉토리 트리 아래의 기존 파일 시스템 경로(파일 시스템의 파일 또는 디렉토리)와 항상 일치하지 않을 수 있다. 이는 동적 요청을 위한 내부 또는 외부 모듈 프로세서의 가상 이름을 참조할 수 있기 때문이다.

3. 2. 3. URL 경로를 파일 시스템으로 변환

웹 서버 프로그램은 URL 경로(전체 또는 일부)를 대상 웹사이트의 루트 디렉터리 아래에 있는 절대 경로로 변환할 수 있다.[28] 웹사이트의 루트 디렉터리는 구성 파일이나 웹 서버의 내부 규칙에 의해 지정될 수 있으며, 이는 HTTP 클라이언트 요청에서 발견된 URL의 호스트 부분인 웹사이트 이름을 사용한다.[28]

파일 시스템으로의 경로 변환은 다음과 같은 유형의 웹 리소스에 대해 수행된다.

  • 로컬, 일반적으로 실행 불가능한 파일 (파일 내용에 대한 정적 요청)
  • 로컬 디렉토리 (동적 요청: 즉석에서 생성된 디렉토리 목록)
  • 프로그램 이름 (CGI 또는 SCGI 인터페이스를 사용하여 실행되고 웹 서버가 출력을 읽어 HTTP 요청을 한 클라이언트에게 다시 전송하는 동적 요청)


웹 서버는 요청된 URL(HTTP 요청 메시지)에서 발견된 경로를 (호스트) 웹사이트 루트 디렉토리의 경로에 추가한다. 아파치 서버에서는 일반적으로 `/home/www/website`이며, 유닉스 머신에서는 일반적으로 `/var/www/website`이다.
정적 파일 요청에 대한 URL 경로 변환 예시http://www.example.com/path/file.html (기존 파일에 대한 ''정적 요청'')

클라이언트의 사용자 에이전트는 `www.example.com`에 연결한 다음 다음과 같은 HTTP/1.1 요청을 보낸다.

```

GET /path/file.html HTTP/1.1

Host: www.example.com

Connection: keep-alive

```

이 요청은 로컬 파일 시스템의 다음 리소스를 가리킨다.

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

웹 서버는 파일이 존재할 경우 해당 파일을 읽고 클라이언트의 웹 브라우저로 응답을 보낸다. 응답은 파일의 내용을 설명하고 파일 자체를 포함하거나, 파일이 존재하지 않거나 액세스가 금지되었다는 오류 메시지를 반환한다.
정적 index 파일이 없는 디렉토리 요청에 대한 URL 경로 변환 예시http://www.example.com/directory1/directory2/ (기존 디렉토리에 대한 암시적 ''동적 요청'')

클라이언트의 사용자 에이전트는 `www.example.com`에 연결한 다음 다음과 같은 HTTP/1.1 요청을 보낸다.

```

GET /directory1/directory2 HTTP/1.1

Host: www.example.com

Connection: keep-alive

```

이 요청은 로컬 디렉토리 경로를 가리킨다.

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

웹 서버는 디렉토리의 존재를 확인하고 존재하며 액세스할 수 있는 경우 index 파일을 찾으려고 시도한다. index 파일이 존재하지 않는 경우 요청을 디렉토리 목록 전용 내부 모듈 또는 프로그램으로 전달하고, 마지막으로 데이터 출력을 읽고 클라이언트의 웹 브라우저로 응답을 보낸다. 응답은 디렉토리의 내용(포함된 하위 디렉토리 및 파일 목록)을 설명하거나, 디렉토리가 존재하지 않거나 액세스가 금지되었다는 오류 메시지를 반환한다.
동적 프로그램 요청에 대한 URL 경로 변환 예시''동적 요청''의 경우 클라이언트가 지정한 URL 경로는 웹 서버가 동적 콘텐츠를 생성하는 데 사용하는 기존 외부 프로그램(일반적으로 CGI가 있는 실행 파일)을 참조해야 한다.[29]

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/forum.php?action=view&ordeby=thread&date=2021-10-15 HTTP/1.1

Host: www.example.com

Connection: keep-alive

```

이 요청은 프로그램의 로컬 파일 경로(이 예시에서는 PHP 프로그램)를 가리킨다.

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

웹 서버는 해당 프로그램을 실행하여 path-info와 쿼리 문자열 `action=view&orderby=thread&date=2021-10-15`를 전달하여 프로그램이 실행하는 데 필요한 정보를 갖도록 한다. 이 경우 2021년 10월 15일부터 스레드로 정렬된 포럼 항목 보기를 포함하는 HTML 문서를 반환한다. 이 외에도 웹 서버는 외부 프로그램에서 보낸 데이터를 읽고 해당 데이터를 요청을 한 클라이언트에게 다시 보낸다.

3. 3. 요청 메시지 관리

웹 서버는 클라이언트로부터 받은 각 HTTP 요청 메시지를 읽고 확인한다.[1] 요청이 해석되고 확인되면 메서드, URL, 매개변수에 따라 처리한다.[28]

웹 서버는 다음과 같은 요청 처리 경로를 따른다.[28]

  • 요청 내용이 허용되지 않는 경우 (상태 라인 또는 메시지 헤더), 오류 응답을 보낸다.
  • 요청에 `OPTIONS`와 같이 웹 서버의 일반 코드로 충족될 수 있는 메서드가 있으면 성공적인 응답을 전송한다.
  • URL에 권한 부여가 필요한 경우, 권한 부여 오류 메시지를 전송한다.
  • URL이 리디렉션에 매핑되는 경우, 리디렉션 메시지를 전송한다.
  • URL이 동적 리소스에 매핑되는 경우, 해당 처리기를 호출하고 요청 매개변수를 전달한다.
  • URL이 정적 리소스에 매핑되는 경우, 내부 정적 처리기를 호출하여 해당 파일을 보낸다.
  • 요청 메서드가 알려지지 않거나 리소스 없음, 내부 서버 오류 등 허용할 수 없는 조건이 있는 경우, 오류 응답을 전송한다.


웹 서버는 이러한 과정을 통해 클라이언트의 요청을 처리하고, 정적 또는 동적 콘텐츠를 제공하거나 오류 메시지를 반환한다.

3. 3. 1. 정적 콘텐츠 제공

웹 서버는 주로 그림, CSS, 자바스크립트 등을 포함한 HTML 문서를 클라이언트에게 전달하는 기능을 한다.[28] 이러한 콘텐츠는 일반적으로 웹 서버가 클라이언트에 전송할 때 변경되지 않고, 어떤 프로그램에 의해 수정될 때까지 동일하게 유지되기 때문에 '정적'이라고 불린다.[28]

PC 클라이언트가 정적 콘텐츠만 제공하는 웹 서버와 네트워크를 통해 통신


웹 서버 프로그램이 '''정적 콘텐츠를 제공'''할 수 있고 그렇게 구성되어 있다면, 웹사이트의 루트 디렉토리 아래에 있는 기존 파일의 URL 경로와 일치하는 유효한 URL 경로가 요청 메시지에 있을 때, 그리고 파일이 웹 서버 프로그램의 내부 규칙에 의해 요구되는 속성을 가지고 있을 때마다 파일 콘텐츠를 보낼 수 있다.[28]

'''정적 콘텐츠만''' 제공할 때, 웹 서버 프로그램은 일반적으로 제공되는 웹사이트의 '''파일 내용을 변경하지 않으며''', 따라서 다음과 같은 HTTP 메서드만 지원하면 된다.[28]

  • `OPTIONS`
  • `HEAD`
  • `GET`


정적 파일 콘텐츠의 응답은 '''파일 캐시'''로 속도를 높일 수 있다.[28]

클라이언트인 웹 브라우저의 URL에 의해 지정된 웹 서버 내에 존재하는 HTML 문서의 각종 정보를, 클라이언트로부터 접속된 HTTP에 따른 TCP/IP 소켓 스트림(HTTP 커넥션이라고 부름)에 전송한다. 대부분의 경우, 클라이언트의 웹 브라우저와 사이에 복수의 커넥션을 설정하고, HTML 문서와 그 하위의 개별 정보 파일(이미지 파일 정보 등)을 병렬로 전송하여, 처리 시간을 단축하여 서비스를 제공한다.

3. 3. 2. 동적 콘텐츠 제공

웹 서버는 서버 사이드 스크립트 언어(Server-side scripting)를 지원하여 동적 콘텐츠를 생성할 수 있다. ASP, PHP 등 다양한 스크립트 언어를 통해 데이터베이스 정보를 조회하고, 이를 바탕으로 동적으로 HTML 문서를 만들어 사용자에게 제공한다. 이러한 동적 콘텐츠는 정적 콘텐츠에 비해 유연하지만, 처리 속도가 느리고 캐싱이 어렵다는 단점이 있다.

PC 클라이언트가 정적 및 동적 콘텐츠를 제공하는 웹 서버와 네트워크를 통해 통신


웹 서버 프로그램이 동적 콘텐츠를 제공하도록 구성된 경우, 클라이언트 요청의 매개변수를 전달하기 위해 적절한 내부 모듈 또는 외부 프로그램(요청된 URL 경로와 연결됨)과 통신할 수 있다. 그 후, 웹 서버 프로그램은 생성된 데이터 응답을 읽어 요청을 한 클라이언트 프로그램에 다시 보낸다.

내부 모듈 및/또는 외부 프로그램과 통신하기 위해 웹 서버 프로그램은 여러 가지 사용 가능한 게이트웨이 인터페이스 중 하나 이상을 구현해야 한다.

세 가지 표준이자 역사적인 게이트웨이 인터페이스는 다음과 같다.

; CGI

: 외부 CGI 프로그램은 각 동적 요청에 대해 웹 서버 프로그램에 의해 실행된 다음, 웹 서버 프로그램은 생성된 데이터 응답을 읽어 클라이언트에게 다시 보낸다.

; SCGI

: 외부 SCGI 프로그램(일반적으로 프로세스)은 웹 서버 프로그램 또는 다른 프로그램/프로세스에 의해 한 번 시작된 다음 네트워크 연결을 기다린다. 이에 대한 새 요청이 있을 때마다 웹 서버 프로그램은 요청 매개변수를 보내고 데이터 응답을 읽기 위해 새 네트워크 연결을 만듭니다. 그런 다음 네트워크 연결이 닫힙니다.

; FastCGI

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

웹 브라우저의 URL에 의해 지정된 웹 서버 내에 존재하는 HTML 문서의 각종 정보를, 클라이언트로부터 접속된 HTTP에 따른 TCP/IP 소켓 스트림(HTTP 커넥션이라고 부름)에 전송한다. 대부분의 경우, 클라이언트의 웹 브라우저와 사이에 복수의 커넥션을 설정하고, HTML 문서와 그 하위의 개별 정보 파일(이미지 파일 정보 등)을 병렬로 전송하여, 처리 시간을 단축하여 서비스를 제공한다.

또한, HTML 문서에 각종 처리를 통합하여, CGI 스크립트나 Java Servlet (서버 측에서 실행되는 자바 프로그램)이라고 불리는 웹 화면과 연동된 동적 처리를 수행하는 것이 가능하다. CGI 처리에서는 Perl, Ruby, PHP 등의 스크립트 언어로 개발되는 경우가 많다.

Java Servlet에서는 자바에 의한 동적 처리 부하를 분산시키기 위해, Java Servlet을 처리하는 기능을 별도 서버로 분리하여, 웹 애플리케이션 서버로서 수직 분산(스케일 아웃)하는 것도 일반화되어 있다.

대규모 웹 서비스를 제공하는 경우, 동일한 서비스를 제공하는 웹 서버를 병렬로 설치하고, 로드 밸런서라고 불리는 각종 로직(라운드 로빈 방식이나 처리 중인 부하를 계측하여 할당하는 서버를 결정하는 것, 서버의 성능을 고려하여 가중치를 부여하는 방식 등이 존재)에 의해 웹 서버로의 처리를 분산시키는 장치를, 웹 서버군 앞에 두는 경우가 많다.

  • Oracle HTTP Server(영어판)
  • * RDBMS 벤더인 오라클이 제공하는 웹 서버(Oracle HTTP Server)는 Java EE를 사용한 웹 애플리케이션 서버와 연동하여 HTML 문서 내에 데이터베이스를 검색하기 위한 SQL문을 직접 기술하고, 데이터베이스에서 데이터를 HTML 기반으로 불러와 가공하는 것이 가능하다.

3. 4. 응답 메시지 전송

웹 서버의 주된 기능은 웹 페이지를 클라이언트에게 전달하는 것이다. 이때 그림, CSS, 자바스크립트 등을 포함한 HTML 문서가 함께 전달된다.[24] 웹 브라우저나 웹 크롤러와 같은 클라이언트는 HTTP를 통해 리소스를 요청하고, 서버는 해당 리소스를 반환하거나 처리 불가능 시 에러 메시지를 전송한다.[25]

웹 서버는 월드 와이드 웹뿐만 아니라 프린터, 라우터, 웹캠 등의 임베디드 장치나 근거리 통신망에서도 사용된다. 이러한 장치들의 관리 및 모니터링을 위해 웹 서버를 활용하면, 클라이언트 측에 별도 소프트웨어 설치 없이 웹 브라우저만으로 서비스를 제공할 수 있다는 장점이 있다.

웹 서버는 클라이언트의 요청에 따라 URL이 지정하는 웹 서버 내 HTML 문서 정보를 TCP/IP 소켓 스트림(HTTP 커넥션)에 전송하거나, CGI 스크립트나 Java Servlet과 연동하여 동적인 처리를 수행할 수 있다. 또한, 대규모 웹 서비스의 경우 로드 밸런서를 통해 여러 웹 서버로 처리를 분산시키거나, 불특정 다수 클라이언트와의 접속을 위해 DNS 서버와 연동하기도 한다. 요청 메시지를 성공적으로 처리할 수 없는 경우에는 오류 응답 메시지가 전송된다.[25]

3. 4. 1. 오류 메시지

웹 서버 프로그램은 클라이언트 요청 메시지에 다양한 종류의 오류 메시지로 응답할 수 있으며, 이러한 오류는 크게 두 가지 범주로 나뉜다.

  • HTTP 클라이언트 오류: 요청 메시지 유형 또는 요청된 웹 리소스의 가용성 때문이다.[33]
  • HTTP 서버 오류: 내부 서버 오류 때문이다.[34]


클라이언트 브라우저가 오류 응답/메시지를 수신하면, 해당 오류가 주 사용자 요청(예: 웹 페이지와 같은 웹 리소스의 URL)과 관련이 있는 경우, 일반적으로 해당 오류 메시지가 일부 브라우저 창/메시지에 표시된다.

3. 4. 2. URL 권한 부여

웹 서버 프로그램은 요청된 URL 경로에 대해 다음을 확인할 수 있다.[35]

  • 모든 사람이 자유롭게 접근할 수 있는지 여부
  • 사용자 인증(예: 사용자 이름 및 비밀번호와 같은 사용자 자격 증명 요청)이 필요한지 여부
  • 일부 또는 모든 종류의 사용자의 접근이 금지되는지 여부


권한 부여/접근 권한 기능이 구현 및 활성화되어 있고 웹 리소스에 대한 접근이 허용되지 않은 경우, 필요한 접근 권한에 따라 웹 서버 프로그램은 다음과 같이 처리한다.

  • 특정 오류 메시지(예: 접근 금지됨)를 전송하여 접근을 거부할 수 있다.
  • 일반적으로 클라이언트 브라우저가 사람 사용자에게 필요한 사용자 자격 증명을 제공하도록 강제하는 특정 오류 메시지(예: 접근 인증되지 않음)를 전송하여 접근을 거부할 수 있다. 인증 자격 증명이 제공되면 웹 서버 프로그램은 이를 확인하고 수락하거나 거부한다.

3. 4. 3. 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/`


위의 예시는 가능한 리디렉션 유형 중 일부일 뿐이다.

3. 4. 4. 성공 메시지

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

웹 리소스 데이터가 클라이언트로 다시 전송되면, 해당 데이터는 검색 방식(파일에서 가져온 내용인지, 아니면 프로그램/모듈의 출력인지)에 따라 '''정적 콘텐츠''' 또는 '''동적 콘텐츠'''가 될 수 있다.

4. 성능

웹 서버는 응답 속도를 높이고 하드웨어 리소스 사용을 줄이기 위해 콘텐츠 캐시를 구현한다.[38][39] 정적 콘텐츠는 파일 캐시로, 동적 콘텐츠는 동적 캐시로 캐시된다.

웹 서버는 사용자 경험을 위해 클라이언트 요청에 빠르게 응답해야 하며, 특히 트래픽이 많을 때에도 응답성이 뛰어나야 한다. 총 사용자 대기 시간(브라우저 시간 + 네트워크 시간 + 웹 서버 응답 시간)을 최소화하는 것이 중요하다.

클라이언트 웹 브라우저의 URL로 지정된 웹 서버 내 HTML 문서는 클라이언트 HTTP 요청에 따라 TCP/IP 소켓 스트림(HTTP 커넥션)으로 전송된다. 보통 복수의 커넥션을 설정, HTML 문서와 이미지 파일 등을 병렬 전송하여 처리 시간을 단축한다.

CGI 스크립트나 Java Servlet(서버 측 실행 자바 프로그램)을 통해 HTML 문서에 동적 처리를 통합할 수 있다. CGI 처리에는 Perl, Ruby, PHP 등의 스크립트 언어가 사용된다.

Java Servlet의 경우, 부하 분산을 위해 처리 기능을 별도 서버로 분리하여 웹 애플리케이션 서버로서 수직 분산(스케일 아웃)하기도 한다.

대규모 웹 서비스는 동일 서비스를 제공하는 웹 서버를 병렬 설치하고, 로드 밸런서를 통해 처리를 분산시켜 서버 고장에 대한 가용성·신뢰성을 확보한다. (느슨한 결합 클러스터의 일종)

웹 서버 및 웹 애플리케이션 서버는 DNS 서버와 연동된다.

4. 1. 성능 지표

웹 서버 소프트웨어의 주요 '''성능 지표''' (다양한 운영 조건 하에서 측정됨)는 일반적으로 다음과 같다.[48]

  • '''초당 요청 수''' ('''RPS''', '''QPS'''와 유사하며, HTTP 버전 및 구성, HTTP 요청 유형 및 기타 운영 조건에 따라 다름)
  • '''초당 연결 수''' ('''CPS'''), 웹 서버에서 허용하는 초당 연결 수 (HTTP/1.0 또는 HTTP/1.1을 연결당 매우 적은 수의 요청/응답 제한, 즉 1..20과 함께 사용하는 경우 유용함)
  • 각 새로운 클라이언트 요청에 대한 '''네트워크 대기 시간''' + '''응답 시간''' ; 일반적으로 벤치마크 도구는 시간 경과 내에 충족된 요청 수를 표시 (예: 1ms, 3ms, 5ms, 10ms, 20ms, 30ms, 40ms 이내) 및/또는 최단, 평균 및 최장 응답 시간
  • 초당 바이트 단위의 '''응답 처리량'''


운영 조건 중, 테스트 중에 사용되는 '''동시 클라이언트 연결 수''' (1..''n'')는 웹 서버에서 지원하는 '''동시성 수준'''과 테스트된 성능 지표의 결과를 연관시킬 수 있으므로 중요한 매개변수이다.

4. 2. 소프트웨어 효율성

웹 서버 소프트웨어 설계 및 채택된 모델은 다음과 같다.

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


기타 프로그래밍 기술은 다음과 같다.

  • 가능한 CPU 캐시 미스 최소화
  • 속도를 위해 중요한 경로에서 가능한 CPU 분기 예측 오류 최소화
  • 특정 기능/작업을 수행하는 데 사용되는 시스템 호출 수를 최소화
  • 기타 트릭


위에 언급된 내용은 웹 서버 프로그램을 구현하는 데 사용되며, '''성능'''에 큰 영향을 미칠 수 있다. 특히 '''확장성''' 수준은 '''과부하''' 또는 고급 하드웨어(많은 CPU, 디스크 및 많은 RAM)를 사용할 때 달성할 수 있다.

실제로 일부 웹 서버 소프트웨어 모델은 대상 성능을 달성하기 위해 다른 모델보다 더 많은 OS 리소스(특히 더 많은 CPU와 더 많은 RAM)가 필요할 수 있다.

4. 3. 작동 조건

웹 서버의 성능에 영향을 줄 수 있는 여러 작동 조건이 있다. 성능은 다음 요소들에 따라 달라질 수 있다.

  • 웹 서버의 설정 (로그 파일 활성화 여부 등)
  • 클라이언트 요청에서 사용되는 HTTP 버전
  • 평균 HTTP 요청 유형 (메서드, HTTP 헤더 및 선택적 본문의 길이)
  • 요청된 콘텐츠가 정적인지 동적인지 여부
  • 콘텐츠가 캐시되었는지 여부 (서버 또는 클라이언트에서)
  • 콘텐츠의 압축 여부 (전송 시 압축, 미리 압축, 또는 압축 안 함)
  • 연결 암호화 여부
  • 웹 서버와 클라이언트 간의 평균 네트워크 속도
  • 활성 TCP 연결 수
  • 웹 서버에서 관리하는 활성 프로세스 수 (외부 CGI, SCGI, FCGI 프로그램 포함)
  • 웹 서버가 실행되는 컴퓨터의 하드웨어 및 소프트웨어 제한 또는 OS 설정
  • 기타 조건


클라이언트인 웹 브라우저의 URL로 지정된 웹 서버 내 HTML 문서의 정보를, 클라이언트로부터 접속된 HTTP에 따른 TCP/IP 소켓 스트림(HTTP 커넥션)에 전송한다. 대부분 클라이언트의 웹 브라우저와 사이에 복수의 커넥션을 설정하고, HTML 문서와 하위 정보 파일(이미지 파일 등)을 병렬 전송하여 처리 시간을 단축한다.

HTML 문서에 각종 처리를 통합하여, CGI 스크립트나 Java Servlet(서버 측 실행 자바 프로그램)과 연동된 동적 처리를 수행할 수 있다. CGI 처리에는 Perl, Ruby, PHP 등의 스크립트 언어가 사용된다.

Java Servlet에서는 부하 분산을 위해 Java Servlet 처리 기능을 별도 서버로 분리하여, 웹 애플리케이션 서버로서 수직 분산(스케일 아웃)을 하기도 한다.

대규모 웹 서비스는 동일 서비스를 제공하는 웹 서버를 병렬 설치하고, 로드 밸런서를 통해 웹 서버로의 처리를 분산시킨다.

이를 통해 서버 고장에 대한 가용성·신뢰성을 확보한다. (느슨한 결합 클러스터의 일종)

웹 서버 및 웹 애플리케이션 서버에는 DNS 서버와의 연동 설정을 통합한다.

4. 4. 벤치마킹

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

5. 부하 제한

웹 서버는 각 작동 조건 조합에 대해 미리 정의된 '''부하 제한'''을 가진다. 이는 운영 체제 리소스에 의해 제한되기도 하고, 동시에 처리할 수 있는 클라이언트 연결 수가 제한되기 때문이다(일반적으로 각 활성 웹 서버 프로세스당 2개에서 수만 개 사이, C10k 문제 및 C10M 문제 참조).

웹 서버가 부하 제한에 근접하거나 초과하면 '''과부하'''가 걸려 '''응답하지 않게''' 될 수 있다.

대규모 웹 서비스를 제공하는 경우, 동일한 서비스를 제공하는 웹 서버를 병렬로 설치하고, 로드 밸런서 (라운드 로빈 방식이나 처리 중인 부하를 계측하여 할당하는 서버를 결정하는 것, 서버의 성능을 고려하여 가중치를 부여하는 방식 등이 존재)를 통해 웹 서버로의 처리를 분산시키는 장치를 웹 서버군 앞에 두는 경우가 많다.

5. 1. 과부하 원인

웹 서버는 다음과 같은 다양한 원인으로 인해 과부하 상태가 될 수 있다.

  • '''과도한 합법적인 웹 트래픽''': 짧은 시간 안에 수천, 수백만 명의 사용자가 웹사이트에 접속하는 경우(예: Slashdot 효과) 과부하가 발생할 수 있다.
  • '''분산 서비스 거부 공격''': 서비스 거부 공격(DoS 공격) 또는 분산 서비스 거부 공격(DDoS 공격)은 의도된 사용자가 컴퓨터나 네트워크 리소스를 사용할 수 없게 만드는 공격이다.
  • '''컴퓨터 웜''': 수백만 대의 감염된 컴퓨터에서 발생하는 비정상적인 트래픽은 웹 서버를 과부하시킬 수 있다.
  • '''XSS 웜''': 수백만 개의 감염된 브라우저나 웹 서버에서 발생하는 높은 트래픽은 과부하의 원인이 된다.
  • '''인터넷 봇''': 대규모 웹사이트에서 필터링/제한되지 않은 봇 트래픽은 네트워크 리소스(대역폭) 및 하드웨어 리소스(CPU, RAM, 디스크)를 소모시켜 과부하를 유발할 수 있다.
  • '''인터넷 속도 저하''': 네트워크 속도 저하(예: 패킷 손실)로 인해 클라이언트 요청 처리가 느려지고 연결 수가 증가하여 서버 제한에 도달하면 과부하가 발생한다.
  • '''느린 백 엔드 응답''': 웹 서버가 동적 콘텐츠를 제공할 때 데이터베이스와 같은 백 엔드 컴퓨터에서 느린 응답을 기다리는 동안, 새로운 클라이언트 연결/요청이 과도하게 들어오면 과부하가 발생할 수 있다.
  • '''웹 서버의 부분적인 사용 불가''': 유지 관리, 업그레이드, 하드웨어나 소프트웨어 오류 등으로 인해 일부 웹 서버를 사용할 수 없게 되면, 나머지 서버에 트래픽이 몰려 과부하가 발생할 수 있다.

5. 2. 과부하 증상

과부하된 웹 서버의 증상은 대개 다음과 같다.

  • 요청이 긴 지연(1초에서 수백 초)으로 처리된다.
  • 웹 서버는 HTTP 오류 코드를 반환하는데, 500, 502,[49][50] 503,[51] 504,[52] 408 또는 간헐적인 404가 발생할 수 있다.
  • 웹 서버는 어떠한 콘텐츠도 반환하기 전에 TCP 연결을 거부하거나 재설정(중단)한다.
  • 매우 드문 경우, 웹 서버는 요청된 콘텐츠의 일부만 반환한다. 이러한 동작은 과부하의 증상으로 나타나더라도 버그로 간주될 수 있다.

5. 3. 과부하 방지 기술

대부분의 인기 있는 웹사이트는 과도한 부하 제한을 부분적으로 극복하고 과부하를 방지하기 위해 다음과 같은 일반적인 기술을 사용한다.

  • 하드웨어 기능 및 사용에 맞게 OS 매개변수를 튜닝한다.
  • 웹 서버 매개변수를 튜닝하여 보안 및 성능을 향상시킨다.
  • 웹 캐시 기술을 배포한다. (정적 콘텐츠뿐만 아니라 가능한 경우 동적 콘텐츠에도 적용한다.)
  • 다음과 같은 방법으로 네트워크 트래픽을 관리한다.
  • * 불량 IP 소스에서 오거나 불량 패턴을 가진 원치 않는 트래픽을 차단하기 위한 방화벽을 사용한다.
  • * 불량 HTTP 패턴을 가진 요청을 삭제, 리디렉션 또는 다시 작성하기 위한 HTTP 트래픽 관리자를 사용한다.
  • * 네트워크 사용량의 피크를 완화하기 위한 대역폭 관리 및 트래픽 셰이핑을 사용한다.
  • 서로 다른 종류의 (정적 및 동적) 콘텐츠를 제공하기 위해 서로 다른 도메인 이름, IP 주소 및 컴퓨터를 사용한다.
  • * 목적은 크거나 거대한 파일(download.*) (해당 도메인은 CDN으로 대체될 수도 있음)을 작고 중간 크기의 파일(static.*)과 주요 동적 사이트(일부 콘텐츠가 백엔드 데이터베이스에 저장될 수 있음) (www.*)에서 '''분리'''하는 것이다.
  • * 각각의 웹 서버 컴퓨터(그룹)에 대해 다른 설정을 사용하여 크거나 거대한 (10 ~ 1000MB 이상) 파일을 효율적으로 제공하고 (다운로드 속도 제한을 포함하여) 작고 중간 크기의 파일을 완벽하게 캐싱하면서, 과도한 부하가 걸린 상태에서도 동적 사이트의 성능에 영향을 미치지 않도록 한다.
  • * 예시:
  • ** https://download.example.com
  • ** https://static.example.com
  • ** https://www.example.com
  • 로드 밸런서 뒤에 함께 그룹화되어 하나의 큰 웹 서버처럼 작동하거나 표시되는 많은 웹 서버 (컴퓨터)를 사용한다.
  • 각 컴퓨터에 더 많은 하드웨어 리소스(예: RAM, 빠른 디스크)를 추가한다.
  • 웹 서버에 더 효율적인 컴퓨터 프로그램을 사용한다.
  • 동적 요청을 처리하기 위해 가장 효율적인 웹 서버 게이트웨이 인터페이스를 사용한다. (동적 페이지를 검색할 때마다 하나 이상의 외부 프로그램을 생성하면 성능이 저하된다.)
  • HTTP 응답 속도를 높이기 위해 다른 프로그래밍 기술과 우회 경로를 사용한다.
  • * 예시: 스타일 시트, 이미지 및 스크립트와 같이 변경되지 않거나 매우 드물게 변경되는 개체를 동적 호출을 통해 검색하는 것을 피한다. 해당 콘텐츠를 정적 파일에 한 번 복사한 다음 동적 콘텐츠와 동기화한다.
  • 최신 효율적인 버전의 HTTP를 사용한다.
  • * 예시: 일반 HTTP/1.1을 사용하는 것 외에도 HTTP/2를 활성화하고, 웹 서버 소프트웨어가 후자 두 프로토콜에 대한 안정적인 지원을 제공하는 경우 HTTP/3도 활성화하여 각 클라이언트가 시작하는 TCP/IP 연결 수와 교환되는 데이터 크기를 많이 줄인다(더 압축된 HTTP 헤더 표현과 데이터 압축 때문).


'''HTTP/2 및 HTTP/3 프로토콜 사용에 대한 주의사항'''

최신 HTTP (2 및 3) 프로토콜은 일반적으로 각 요청/응답 데이터에 대해 더 적은 네트워크 트래픽을 생성하지만, 웹 서버 소프트웨어에서 사용되는 더 많은 OS 리소스(예: RAM 및 CPU)가 필요할 수 있다.(암호화된 데이터, 많은 스트림 버퍼 및 기타 구현 세부 사항 때문).[53][54] HTTP/2와 HTTP/3도 웹 서버 및 클라이언트 프로그램의 설정에 따라 매우 높은 속도로 크거나 거대한 파일을 업로드하는 데 최적의 옵션이 아닐 수 있다. 데이터 스트림이 요청의 동시성에 최적화되어 있기 때문에, 많은 경우 HTTP/1.1 TCP/IP 연결을 사용하는 것이 더 나은 결과/더 높은 업로드 속도를 얻을 수 있다(사용 환경에 따라 다를 수 있음).

대규모 웹 서비스를 제공하는 경우, 동일한 서비스를 제공하는 웹 서버를 병렬로 설치하고, 로드 밸런서라고 불리는 각종 로직(라운드 로빈 방식이나 처리 중인 부하를 계측하여 할당하는 서버를 결정하는 것, 서버의 성능을 고려하여 가중치를 부여하는 방식 등이 존재)에 의해 웹 서버로의 처리를 분산시키는 장치를, 웹 서버군 앞에 두는 경우가 많다.

6. 시장 구조

넷크래프트에서 조사한 주요 웹 서버의 시장 점유율은 다음과 같다.

제품제조업체웹 사이트 수백분율
아파치아파치359,441,46853.42%
IIS마이크로소프트112,303,41216.69%
nginxNGINX, Inc.104,411,08715.52%
GWS구글23,029,2603.42%

[70]

Netcraft가 제공하는 인터넷 상위 웹 서버의 전체 사이트 시장 점유율에 대한 최신 통계는 다음 표와 같다.

웹 서버: 전체 사이트 시장 점유율
날짜nginx(Nginx, Inc.)아파치(ASF)OpenResty(OpenResty Software Foundation)Cloudflare 서버(Cloudflare, Inc.)IIS(Microsoft)GWS(Google)기타
2021년 10월[55]34.95%24.63%6.45%4.87%4.00% (*)4.00% (*)22% 미만
2021년 2월[56]34.54%26.32%6.36%5.0%6.5%3.90%18% 미만
2020년 2월[57]36.48%24.5%4.00%3.0%14.21%3.18%15% 미만
2019년 2월[58]25.34%26.16%해당 없음해당 없음28.42%1.66%19% 미만
2018년 2월[59]24.32%27.45%해당 없음해당 없음34.50%1.20%13% 미만
2017년 2월[60]19.42%20.89%해당 없음해당 없음43.16%1.03%15% 미만
2016년 2월[61]16.61%32.80%해당 없음해당 없음29.83%2.21%19% 미만



참고: (*) 소스 페이지에서 소수점 값을 공개적으로 보고하지 않으므로 백분율은 정수로 반올림되었다(그래프에서 반올림된 값만 보고됨).

주요 웹 서버의 시장 점유율


가장 인기 있는 웹 서버의 ''전체 사이트 시장 점유율'' 1995–2005 차트


2015년에는 Apache 및 그 파생판인 각 벤더의 HTTP Server가 시장의 40%, 마이크로소프트의 IIS가 시장의 30%, nginx가 20% 정도를 차지했다.[62] 2024년에는 nginx가 40%, Apache가 25%, Microsoft가 10% 정도를 차지하고 있다.[63]

7. 제품



넷크래프트(Netcraft)의 2007년 9월 웹 서버 사용 분포 조사 결과는 다음과 같다.

제작사제품사용 사이트 수
아파치 소프트웨어 재단아파치 웹 서버67,898,632
마이크로소프트IIS47,226,195
구글GWS6,616,713
썬 마이크로시스템즈Sun Java System Web Server1,997,150
OverseeOversee1,601,209
lighttpdlighttpd1,515,963
기타 등등-8,296,292
총-135,152,154



2015년에는 Apache 및 그 파생 제품이 시장의 40%, 마이크로소프트의 IIS가 30%, nginx가 약 20%를 차지했다.[62] 2024년에는 nginx가 40%, Apache가 25%, Microsoft가 약 10%를 차지하고 있다.[63]

LAMP 소프트웨어 번들 (여기에는 Squid도 포함) 고성능 및 고가용성 솔루션

  • 아파치 HTTP 서버
  • 인터넷 정보 서비스
  • [http://www.soft3304.net/04WebServer/ 04webserver]
  • lighttpd
  • 체로키
  • [http://www.hiawatha-webserver.org/ Hiawatha Webserver]
  • thttpd
  • RaidenHTTPD
  • nginx
  • Zope
  • 기타
  • CERN httpd
  • NCSA HTTPd
  • AN HTTPD
  • Tux 웹 서버(영어판)는 과거 리눅스 커널 패치 형태로 작성된 HTTP 서버 구현이다. 정적 콘텐츠만 제공하고 커널 계층에서 동작하여 일반 웹 서버보다 빠르다고 알려졌다.[64] 개발자는 Red Hat의 커널 해커 Ingo Molnár였으며, 최초 버전은 Red Hat Linux 6.2 및 7.0용으로 출시되었다.[65] 커널 내에서 작동하며, 스토리지와 네트워크 모두에 대해 제로 카피 입출력을 수행할 수 있었다.[66][67] 2009년경 역할을 마치고 유지보수되지 않았다.[68] Content Accelerator라고도 불렸다.[69]
  • Oracle HTTP Server(영어판)
  • 오라클이 제공하는 웹 서버(Oracle HTTP Server)는 Java EE를 사용한 웹 애플리케이션 서버와 연동하여 HTML 문서 내에 데이터베이스를 검색하기 위한 SQL문을 직접 기술하고, 데이터베이스에서 데이터를 HTML 기반으로 불러와 가공할 수 있다.

참조

[1] 서적 Web Server Technology https://books.google[...] Morgan Kaufmann 2021-01-22
[2] 서적 Sun Web Server: The Essential Guide https://books.google[...] Pearson Education 2021-10-14
[3] 뉴스 "'Father of the web' Sir Tim Berners-Lee on his plan to fight fake news" https://www.telegrap[...] The Telegraph 2019-02-01
[4] 웹사이트 History of Computers and Computing, Internet, Birth, The World Wide Web of Tim Berners-Lee http://history-compu[...] 2019-02-01
[5] 웹사이트 WWW Project History (original) http://info.cern.ch/[...] CERN (World Wide Web project) 2021-12-20
[6] 웹사이트 WorldWideWeb wide-area hypertext app available (announcement) https://groups.googl[...] CERN (World Wide Web project) 2021-10-16
[7] 웹사이트 Web History https://web30.web.ce[...] CERN (World Wide Web project) 2021-10-16
[8] 웹사이트 Qualifiers on hypertext links ... https://www.w3.org/P[...] CERN (World Wide Web project) 2021-10-16
[9] 서적 Analysis and Testing of Ajax-based Single-page Web Applications https://www.research[...] null 2021-12-18
[10] 웹사이트 "Hobbes' Internet Timeline v5.1 (WWW Growth) NOTE: till 1996 number of web servers = number of web sites" http://www.isoc.org/[...] ISOC 2021-12-18
[11] 웹사이트 Licensing the Web https://home.cern/sc[...] CERN (World Wide Web project) 2021-10-16
[12] 웹사이트 NCSA httpd http://illinois.edu/[...] NCSA (web archive) 2021-12-16
[13] 웹사이트 About the Apache HTTPd server: How Apache Came to be https://httpd.apache[...] Apache: HTTPd server project 2021-12-17
[14] 웹사이트 "Web Server Survey, NOTE: number of active web sites in year 2000 has been interpolated" https://news.netcraf[...] Netcraft 2021-12-27
[15] 웹사이트 Netcraft: web server software (1996) http://www.netcraft.[...] Netcraft (web archive) 2021-12-16
[16] 웹사이트 Overview of new features in Apache 2.2 https://httpd.apache[...] Apache: HTTPd server project 2021-12-16
[17] 웹사이트 Overview of new features in Apache 2.4 https://httpd.apache[...] Apache: HTTPd server project 2021-12-16
[18] 간행물 RFC 2616, Hypertext Transfer Protocol -- HTTP/1.1
[19] 웹사이트 Maximum concurrent connections to the same domain for browsers http://sgdev-blog.bl[...] null 2021-12-21
[20] 웹사이트 Linux Web Server Performance Benchmark - 2016 results https://www.rootuser[...] RootUsers 2021-12-22
[21] 웹사이트 Will HTTP/2 replace HTTP/1.x? https://http2.github[...] IETF HTTP Working Group 2021-12-22
[22] 웹사이트 Implementations of HTTP/2 in client and server software https://github.com/h[...] IETF HTTP Working Group 2021-12-22
[23] 웹사이트 Why just one TCP connection? https://http2.github[...] IETF HTTP Working Group 2021-12-22
[24] 간행물 RFC 7230, HTTP/1.1: Message Syntax and Routing
[25] 간행물 RFC 7230, HTTP/1.1: Message Syntax and Routing
[26] 간행물 RFC 7230, HTTP/1.1: Message Syntax and Routing
[27] 웹사이트 URL Mapping http://people.apache[...] Apache software foundation 2021-11-15
[28] 웹사이트 Mapping URLs to Filesystem Locations https://httpd.apache[...] Apache: HTTPd server project 2021-10-19
[29] 웹사이트 Dynamic Content with CGI https://httpd.apache[...] Apache: HTTPd server project 2021-10-19
[30] 서적 HTTP developer's handbook https://books.google[...] Sams's publishing 2021-12-09
[31] 웹사이트 Directory listings https://cwiki.apache[...] Apache foundation: HTTPd server project 2021-11-16
[32] 웹사이트 Apache: directory listing to download files https://archive.apac[...] Apache: HTTPd server 2021-12-16
[33] 간행물 RFC 7231, HTTP/1.1: Semantics and Content
[34] 간행물 RFC 7231, HTTP/1.1: Semantics and Content
[35] 간행물 RFC 7235, HTTP/1.1: Authentication
[36] IETF RFC 7231, HTTP/1.1: Semantics and Content
[37] IETF RFC 7231, HTTP/1.1: Semantics and Content
[38] 웹사이트 Caching Guide https://httpd.apache[...] Apache: HTTPd server project 2021-12-09
[39] 웹사이트 NGINX Content Caching https://docs.nginx.c[...] F5 NGINX 2021-12-09
[40] 웹사이트 Main Memory Caching of Web Documents https://www.ra.ethz.[...] Computer networks and ISDN Systems 2021-12-09
[41] 웹사이트 IPlanet Web Server 7.0.9: file-cache https://docs.oracle.[...] Oracle 2021-12-09
[42] 웹사이트 Apache Module mod_file_cache https://httpd.apache[...] Apache: HTTPd server project 2021-12-09
[43] 웹사이트 HTTP server: configuration: file cache https://www.gnu.org/[...] GNU 2021-12-09
[44] 웹사이트 Apache Module mod_cache_disk https://httpd.apache[...] Apache: HTTPd server project 2021-12-09
[45] 웹사이트 What is dynamic cache? https://www.educativ[...] Educative 2021-12-09
[46] 웹사이트 Dynamic Cache Option Tutorial https://www.sitegrou[...] Siteground 2021-12-09
[47] 웹사이트 Improving Web Server Performance by Caching Dynamic Data https://www.research[...] Usenix 2021-12-09
[48] 간행물 WebMonitor: a tool for measuring World Wide Web server performance https://firstmonday.[...] 2021-11-04
[49] 웹사이트 Getting a 502 Bad Gateway Error? Here's What to Do https://www.lifewire[...] 2019-02-01
[50] 웹사이트 What is a 502 bad gateway and how do you fix it? https://www.itpro.co[...] 2019-02-01
[51] 웹사이트 Getting a 503 Service Unavailable Error? Here's What to Do https://www.lifewire[...] 2019-02-01
[52] 웹사이트 Getting a 504 Gateway Timeout Error? Here's What to Do https://www.lifewire[...] 2019-02-01
[53] 웹사이트 Slow uploads with HTTP/2 https://github.com/n[...] github 2021-11-15
[54] 웹사이트 Delivering HTTP/2 upload speed improvements https://blog.cloudfl[...] Cloudflare 2021-11-15
[55] 웹인용 October 2021 Web Server Survey https://news.netcraf[...] Netcraft 2021-11-15
[56] 웹인용 February 2021 Web Server Survey https://news.netcraf[...] Netcraft 2021-04-08
[57] 웹인용 February 2020 Web Server Survey https://news.netcraf[...] Netcraft 2021-04-08
[58] 웹인용 February 2019 Web Server Survey https://news.netcraf[...] Netcraft 2021-04-08
[59] 웹인용 February 2018 Web Server Survey https://news.netcraf[...] Netcraft 2021-04-08
[60] 웹인용 February 2017 Web Server Survey https://news.netcraf[...] Netcraft 2017-03-13
[61] 웹인용 February 2016 Web Server Survey https://news.netcraf[...] Netcraft 2022-01-27
[62] 문서 November 2015 Web Server Survey http://news.netcraft[...] netcraft
[63] 문서 February 2024 Web Server Survey https://www.netcraft[...] netcraft
[64] 웹사이트 オープンソースの高速Webサーバー「TUX」の実力 https://xtech.nikkei[...] 2024-03-09
[65] 웹사이트 Red Hat TUX Web Server https://web.archive.[...] 2024-03-09
[66] 웹사이트 TUX 2.0 Reference Manual https://www.stllinux[...] 2024-03-09
[67] 웹사이트 ASCII.jp: Red Hat、Linuxカーネル内で動作する高速Webサーバをリリース https://ascii.jp/ele[...] 2024-03-09
[68] 웹사이트 TUX installation https://listman.redh[...] 2024-03-09
[69] 웹사이트 Red Hat Content Accelerator 2.2: Reference Manual https://cs.uwaterloo[...] 2024-03-09
[70] 문서 2013년 5월 조사 http://news.netcraft[...]


본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.

문의하기 : help@durumis.com