개념 사전/시스템 · 서버 / 웹 서버
개념 사전 · 프로그램

Apache HTTP Server

Apache · 아파치 · Apache HTTP Server

는 HTTP 요청을 받아 정적 파일 또는 설정한 처리기의 응답을 제공하는 웹 서버이다. 모듈과 · 같은 설정 구역으로 사이트 선택·파일 접근·프록시· 기능을 구성한다.

밑줄 용어에 마우스를 올리거나, 키보드로 선택하거나, 터치하면 설명을 볼 수 있습니다.

로고: Apache HTTP Server 공식 자료. 제품 식별을 위해 표시하며 각 상표의 권리는 권리자에게 있습니다.

01무엇이고, 어떤 일을 하나

  • 동일 서버의 여러 사이트를 로 나눈다.
  • 파일 시스템 경로와 URL 처리 정책을 구역별로 지정한다.
  • 모듈을 조합하여 인증·프록시··응답 처리를 확장한다.
  • 선택한 이 ·스레드와 연결 처리 방식을 결정한다.

02어떤 순서로 동작하나

  1. 초기화

    로드된 하나의 이 포트 바인딩과 자식 ·스레드를 준비한다. prefork와 worker·event는 같은 동시 처리 모델이 아니다.

  2. 연결 수락

    에 지정한 주소와 포트에서 연결을 받고 해당 주소 집합의 가상 호스트 후보를 정한다.

  3. 사이트 선택

    이름 기반 구성에서는 요청의 Host 등을 ServerName·ServerAlias와 비교해 를 선택한다.

  4. 정책·처리기 적용

    문서 경로와 등의 정책, 구성된 모듈과 처리기를 연결한다. URL 기준 구역과 파일 시스템 기준 구역을 구별한다.

  5. 응답과 기록

    허용된 파일 또는 애플리케이션 결과를 반환하고 access·error log에 처리 결과를 기록한다.

  6. 연결 대기·재사용

    event 에서는 처리를 마친 keep-alive 연결의 대기를 listener 쪽에 맡겨 요청 처리 스레드를 다른 요청에 쓸 수 있다. 모든 모듈의 블로킹 작업까지 없어지는 것은 아니다.

03먼저 알아둘 용어와 구성요소

Multi-Processing Module은 포트 연결 수락과 요청 실행 주체의 배정을 담당한다. 모델은 실제 로드된 을 기준으로 설명한다.
prefork는 비스레드 자식 모델, worker는 여러 와 스레드의 혼합 모델이다. event는 worker 계열에서 유휴 keep-alive 대기 등을 분리하여 스레드 점유를 줄인다.
은 서버가 어느 주소·포트의 연결을 받을지 정한다.
는 해당 연결과 호스트 이름에 맞는 사이트 설정을 선택하고 ServerName은 이름 선택 기준, DocumentRoot는 정적 문서 기준 경로다.
<>는 파일 시스템 경로에 대한 정책이며 URL 기준 처리와 구분한다.
설정을 conf.d에 놓는 방식은 주 설정이 그 파일들을 하도록 연결되어 있어야 작동한다.
는 적절한 인덱스 파일이 없을 때 디렉터리 목록을 생성할 수 있게 한다.
None은 해당 경로의 .htaccess 재정의를 읽지 않도록 하는 정책이다.
LEARN THROUGH PRACTICE

Redirect와 Alias를 URL 변화·접근 로그로 구별하기

같은 실습 앱을 제공하는 세 설정을 비교하여 브라우저 재요청, 내부 파일 매핑, 규칙의 차이를 설명한다.

실습 구성과 전제

  • 의 서로 다른 구성 사례를 비교한다. RedirectMatch·RewriteRule·Alias 세 설정을 한 에 동시에 넣는 절차가 아니다.
  • 경로는 수업의 실습 앱 예시다. 공개 서버에 취약한 앱을 설치하는 배포 예제가 아니며, 주소와 포트는 격리된 실습 환경에 맞춰 사용한다.

  1. RedirectMatch의 301을 두 요청으로 추적한다

    • ^/$는 루트 경로 하나를 선택한다. //는 클라이언트에게 다시 요청하도록 알려 주는 목적지이며 서버 파일 경로가 아니다.
    • 브라우저는 리다이렉트 응답의 Location을 읽고 새 요청을 보낸다. 주소창 변화와 접근 로그의 요청 수를 함께 보면 내부 매핑과 구분할 수 있다.
    bash
    curl -i http://127.0.0.1/
curl -i -L http://127.0.0.1/

    해당 실습 서버에서 첫 응답만 보는 요청과 리다이렉트를 따라가는 요청을 비교한다.

    7/29 · 실습·개념 참고 화면 1원본 크기로 보기 ↗
    • VirtualHost *:80 안에 RedirectMatch 301 ^/$ /dvwa/가 있다.
    • ServerName과 리다이렉트 목적지는 서로 다른 항목이며 앱의 실제 파일 위치는 이 줄에 표시되지 않는다.
    7/29 · 실습·개념 참고 화면 3원본 크기로 보기 ↗
    • 첫 로그는 GET / HTTP/1.1과 상태 301이다.
    • 다음 로그는 GET /dvwa/ HTTP/1.1과 상태 200이어서 두 요청을 구분할 수 있다.
    확인 기준

    첫 응답의 Location과 두 번째 요청 경로를 확인한다. 301은 영구 이동이므로 브라우저 캐시의 영향도 구별한다.

  2. RewriteRule이 외부 리다이렉트를 만드는 조건을 읽는다

    • 화면은 RewriteEngine On, 루트 URI 조건, R=301·L 플래그를 사용한다. Rewrite라는 이름만 보고 항상 서버 내부 처리라고 판단하면 안 된다.
    • R은 리다이렉트 응답을 만들고 L은 현재 규칙 처리의 해당 단계를 끝낸다. RewriteRule의 매칭 대상은 server와 문맥에 따라 달라지므로 규칙 위치를 먼저 확인한다.
    7/29 · 패킷 캡처 2원본 크기로 보기 ↗
    • RewriteCond는 REQUEST_URI가 루트인지 검사한다.
    • RewriteRule 끝의 [R=301,L]이 보이므로 외부 301 응답을 의도한 사례다.
    확인 기준

    응답 코드와 Location이 의도대로인지 확인한다. 규칙 모양이 다르더라도 RedirectMatch 사례처럼 클라이언트 재요청이 일어나는지 비교한다.

  3. Alias의 URL→파일 경로 매핑을 읽는다

    • 별도 Alias 사례는 URL /를 /var/www/html// 아래에 매핑한다. 클라이언트가 //로 이동할 필요 없이 루트 URL에서 해당 파일을 제공할 수 있다.
    • Alias가 가리킨 파일에도 접근 허용과 파일 시스템 권한이 적용된다. 화면의 all은 .htaccess 처리를 넓게 허용하므로 필요한 설정 범위를 검토해야 한다.
    7/29 · 실습·개념 참고 화면 4원본 크기로 보기 ↗
    • Alias / 뒤에 /var/www/html/dvwa/ 파일 시스템 경로가 있다.
    • 같은 경로의 Directory 안에 AllowOverride all과 Require all granted가 있다.
    7/29 · 실습·개념 참고 화면 5원본 크기로 보기 ↗
    • 접근 로그의 첫 요청 GET /는 200이며 이 구간에는 앞 사례의 301 행이 없다.
    • 이후 CSS·JavaScript·이미지 등 추가 리소스 요청도 각각 별도 로그 행으로 남는다.
    확인 기준

    주소가 유지된다는 관찰, 첫 응답 코드, 적용 설정을 함께 비교한다. 일부 로그에 301이 없다는 사실만으로 서버 전체에 리다이렉트가 없다고 단정하지 않는다.

실습에서 확인한 동작 원리

  • Redirect는 클라이언트에게 새 URL을 요청하게 하고 Alias는 서버 내부에서 URL의 파일 위치를 매핑한다.
  • 접근 로그의 한 행은 보통 한 요청을 나타낸다. 페이지 로드 한 번에도 리다이렉트와 여러 리소스 요청이 생길 수 있다.
관련 개념·전체 실습 화면 이어서 읽기 →
동작·명령 참고 문서
LEARN THROUGH PRACTICE

Apache의 수신 포트·문서 루트·디렉터리 허용을 따로 검증하기

의 LAMP 설정 화면에서 요청을 받는 조건과 파일을 제공하는 조건을 나누고, 기본 페이지가 뜨는 원인을 추적한다.

실습 구성과 전제

  • 2.4 계열의 httpd 서비스와 /etc/httpd 설정 경로를 기준으로 읽는다. 의 apache2 경로와 섞지 않는다.
  • 캡처는 서로 다른 설정 항목을 보여 주는 자료다. 아래 확인 명령은 실습용 예시이며, 이 조각만으로 설정 전체나 모든 URL의 성공을 단정하지 않는다.

  1. Listen과 주석을 구별해 수신 조건을 읽는다

    • #으로 시작하는 예시는 주석이다. 활성 줄의 80이 실제 수신 설정이며 방화벽 허용과는 별개다.
    • 가상 호스트는 수신 주소·포트 후보 안에서 Host 이름을 비교한다. ServerName을 추가해도 나 이 자동으로 생기지는 않는다.
    bash
    sudo httpd -t
sudo httpd -S
sudo ss -ltnp

    구문, 가상 호스트 매핑, 실제 수신 소켓을 각각 확인하는 명령이다.

    LAMP - rocky · 실습·개념 참고 화면 4원본 크기로 보기 ↗
    • 46행의 특정 주소 Listen은 #으로 주석 처리되어 있다.
    • 47행의 Listen 80은 활성 설정이며, 다른 포트를 사용한 Nginx 실습과 구분해야 한다.
    확인 기준

    구문 검사가 통과해도 서비스가 중지되어 있으면 수신하지 않는다. 80 포트의 실제 를 확인한다.

  2. DocumentRoot에 URI를 연결한다

    • 기본 파일 제공에서 /index.html은 DocumentRoot 아래의 index.html에 대응한다. Alias·Rewrite·별도 가 있으면 적용 경로를 다시 확인한다.
    • 홈 디렉터리에 index.html을 만들었다는 사실만으로 기본 웹 문서가 바뀌지는 않는다. 요청의 문서 루트와 생성한 파일 위치가 일치해야 한다.
    bash
    ls -l /var/www/html/index.html
namei -l /var/www/html/index.html

    파일 존재와 상위 디렉터리 검색 권한을 조회한다.

    LAMP - rocky · 실습·개념 참고 화면 8원본 크기로 보기 ↗
    • 활성 DocumentRoot 값은 /var/www/html이다.
    • 이 설정 조각에는 사용자 홈 디렉터리를 문서 루트로 지정한 내용이 없다.
    확인 기준

    파일을 놓은 경로와 요청이 선택한 DocumentRoot가 같아야 한다. 파일 없음과 읽기 거부를 구별한다.

  3. 웹 접근 허용과 운영체제 권한을 분리한다

    • 화면의 < />는 파일 시스템 루트에 대한 기본 제한이다. 공개 경로에 적용되는 더 구체적인 설정도 함께 읽어야 최종 허용 여부를 판단할 수 있다.
    • Require all denied는 HTTP 접근 제어이고 chmod 모드와 다른 검사다. none은 해당 범위에서 .htaccess의 설정 덮어쓰기를 사용하지 않는다는 뜻이다.
    LAMP - rocky · 실습·개념 참고 화면 7원본 크기로 보기 ↗
    • <Directory /> 안에 AllowOverride none과 Require all denied가 나란히 있다.
    • 전역 기본 제한 한 조각이므로 /var/www/html의 추가 허용 블록 존재 여부를 이 사진만으로 알 수 없다.
    확인 기준

    403이면 적용된 ·Require, 경로 권한, 정책과 오류 로그를 대조한다. 전체 루트의 제한을 해제하는 방식으로 해결하지 않는다.

  4. 기본 테스트 페이지를 사용자 문서와 구별한다

    • 의 테스트 페이지는 웹 요청에 응답한 화면이다. 문서에는 와 안내가 모두 있으므로 화면의 로고만으로 실제 응답 를 확정하지 않는다.
    • 문서 내용·접속 URL·서비스와 로그를 함께 확인한다. 설정을 수정했다면 구문 검사 후 reload하고 같은 URL을 다시 요청해 비교한다.
    bash
    sudo httpd -t && sudo systemctl reload httpd
curl -i -H 'Host: lab.example.test' http://127.0.0.1/
sudo tail -n 30 /var/log/httpd/error_log

    실습의 Host 이름으로 바꿔 응답과 오류 로그를 확인한다. reload는 설정을 수정한 경우에만 실행한다.

    LAMP - rocky · 실습·개념 참고 화면 1원본 크기로 보기 ↗
    • HTTP Server Test Page라고 표시되며 운영체제 기본 안내 문서가 보인다.
    • 본문은 /var/www/html과 welcome.conf를 안내하고 Apache·Nginx 각각의 사용 조건을 설명한다.
    확인 기준

    기본 페이지가 계속 보이면 선택된 ·문서 루트·index·welcome 설정을 확인한다. HTTP 응답 코드와 본문이 기대한 값인지 함께 판단한다.

실습에서 확인한 동작 원리

  • 수신 포트, 가상 호스트 선택, URI의 파일 경로 변환, 접근 허용은 서로 다른 단계다.
  • 서비스 active·구문 검사·기본 페이지 출력만으로 원하는 사이트의 동작을 모두 검증한 것은 아니다.
관련 개념·전체 실습 화면 이어서 읽기 →
동작·명령 참고 문서

04예제로 따라가기

  • DocumentRoot가 /srv/site인 가상 호스트와 다른 문서 루트의 가상 호스트를 같은 포트에서 이름으로 나누어 운영할 수 있다.
  • 가 허용되고 적절한 인덱스 문서가 없으면 디렉터리 목록이 응답으로 만들어질 수 있다.
  • Require all granted는 차원의 허용이지 DAC나 레이블을 바꾸는 설정은 아니므로 파일 읽기가 여전히 거부될 수 있다.
  • httpd -M 또는 해당 배포판의 apachectl -M 출력에서 mpm_event_module을 보면 event 구성을 식별할 수 있다. 는 항상 연결마다 하나를 점유한다는 비교는 정확하지 않다.

05혼동하기 쉬운 점과 확인 기준

  • -t나 apachectl configtest는 설정 파싱·일부 자원 접근을 검사한다. 모든 Host·URI·인증·백엔드 응답을 실제로 실행해 검증하는 것은 아니다.
  • 같은 IP에서 한 이름만 실패하면 Host·SNI·server_name/ServerName과 기본 사이트를 대조한다. 가 같은 IP를 돌려줘도 사이트 선택이 동일하지 않을 수 있다.
  • 설정 파일을 특정 폴더에 놓는 것만으로 적용되는 것은 아니다. 주 설정의 연결과 실제 실행 중인 구성 경로가 맞아야 한다.

06상세 노트 · 실습 자료

헤더 구조, 설정 예시, 수치 계산과 수업 캡처는 아래 노트에서 이어집니다.

Apache·Nginx와 웹 서버 운영웹 서버는 요청을 받을 주소와 사이트를 선택하고 정적 파일을 제공하거나 애플리케이션으로 요청을 전달합니다.상세 노트 읽기 →정방향·역방향 프록시와 캐시프록시가 누구를 대신해 요청을 전달하는지 구분하면 접근 제어, TLS 종료, 캐시와 실제 클라이언트 주소를 이해하기 쉽습니다.상세 노트 읽기 →Linux 권한·ACL·특수 권한파일과 디렉터리의 r·w·x는 의미가 다릅니다. 소유권, 그룹, ACL과 추가 접근 통제를 순서대로 확인합니다.상세 노트 읽기 →
READ · OBSERVE · CONNECT

함께 보는 학습 자료

아래 공식 자료를 본문의 개념·예제와 함께 읽어 보세요. 자료별로 확인할 위치와 관찰할 내용을 적었습니다.

공식 가이드

Apache event MPM의 연결 대기와 작업 스레드

Relationship with the Worker 다음 How it Works의 Keep-alive 항목을 읽는다. 연결마다 하나라는 단순 비교 대신 listener와 worker가 언제 역할을 넘기는지 살펴본다.

읽으면서 확인할 것
  • 자식 안의 listener와 worker 스레드
  • keep-alive 대기를 처리 스레드에서 분리하는 시점
  • graceful 종료 중 기존 가 남는 이유

공식 문서 · 표준

기초 개념과 동작 설명을 대조한 자료입니다. 제품 버전과 실제 설정에 따른 차이는 본문 및 원문에서 확인하세요.