Apache·Nginx와 웹 서버 운영

01HTTP 요청을 파일 응답으로 바꾸는 처리 순서

• HTTP·요청브라우저가 URL에서 호스트 이름과 경로를 나누고 주소를 찾은 뒤 연결을 수립하면 웹 서버는 HTTP 요청의 메서드·대상 경로·헤더를 읽는다.
• HTTPS·HTTPHTTPS에서는 HTTP보다 먼저 TLS 협상과 서버 인증서 검증이 진행된다.
• URI서버는 어떤 가상 호스트인지 선택하고 URI에 맞는 정적 파일 또는 처리기를 찾은 뒤 상태 코드·헤더·본문을 응답한다.
• GET과 HEADGET은 표현을 요청하고 HEAD는 같은 종류의 메타데이터를 본문 없이 요청한다.
• 응답상태 200은 성공 응답, 301/302 등은 이동, 403은 접근 거부, 404는 찾을 수 없음, 5xx는 서버 쪽 처리 문제를 표현한다.

  • 모든 실패를 TCP 연결 문제로 설명할 수 없는 이유다.
• Content-LengthContent-Type은 수신자가 본문을 해석할 형식이고 Content-Length는 전송하는 본문의 바이트 길이에 관련된다.
• HTTPHTTP/1.1의 아래 텍스트 형식과 HTTP/2·3의 프레이밍은 다르다.

GET /guide.html HTTP/1.1
Host: study.example
Accept: text/html

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Content-Length: 32

<!doctype html><p>hello web!</p>

교육용 예시. 결과와 주소는 설명용이며 실제 시스템에서 실행한 기록이 아니다.

02DNS가 IP를 알려 줘도 Host와 SNI가 필요한 이유

• 한 주소의 여러 사이트DNS는 이름을 주소로 해석하지만 같은 IP와 포트에서 여러 사이트를 제공할 수 있다.
• HTTP·HostHTTP/1.1의 Host 헤더는 요청한 사이트 이름을 서버에 전하고 이름 기반 가상 호스트 선택에 사용된다.

  • 단순히 IP 주소로 접속하면 기본 가상 호스트로 갈 수 있다.
• HostHost가 파일 시스템 디렉터리 이름 그 자체는 아니며 설정에 정의된 선택 규칙을 거친다.
• HTTPS·HTTPHTTPS에서는 HTTP 헤더가 암호화되어 전송되기 전에 TLS 단계에서 인증서를 선택해야 한다.
• SNI·요청SNI는 클라이언트가 요청한 서버 이름을 TLS 협상에 전달한다.
• 인증서 이름 검증인증서 이름과 요청한 호스트가 맞아야 정상적인 서버 인증이 된다.
• DNS와 인증서 선택같은 IP에서 인증서가 다른 두 사이트를 제공하는 상황을 DNS만으로 설명할 수 없는 이유가 여기에 있다.

03Apache Listen·VirtualHost·Directory의 역할

• ListenListen은 서버가 어느 주소·포트의 연결을 받을지 정한다.
• VirtualHostVirtualHost는 해당 연결과 호스트 이름에 맞는 사이트 설정을 선택하고 ServerName은 이름 선택 기준, DocumentRoot는 정적 문서 기준 경로다.
• Directory<Directory>는 파일 시스템 경로에 대한 정책이며 URL 기준 처리와 구분한다.
• Include 연결설정을 conf.d에 놓는 방식은 주 설정이 그 파일들을 Include하도록 연결되어 있어야 작동한다.
• Options IndexesOptions Indexes는 적절한 인덱스 파일이 없을 때 디렉터리 목록을 생성할 수 있게 한다.
• AllowOverride NoneAllowOverride None은 해당 경로의 .htaccess 재정의를 읽지 않도록 하는 정책이다.
• RequireRequire all granted는 Apache 접근 통제를 허용하지만 실제 파일의 DAC·SELinux까지 바꾸지 않는다.
• TLS아래는 정적 실습 사이트의 예시이며 TLS를 구성한 운영 설정을 대체하지 않는다.

<VirtualHost *:80>
    ServerName study.example
    DocumentRoot /srv/study
    <Directory /srv/study>
        Options -Indexes
        AllowOverride None
        Require all granted
    </Directory>
</VirtualHost>

교육용 예시. 결과와 주소는 설명용이며 실제 시스템에서 실행한 기록이 아니다.

04Nginx의 server·location·root·try_files

• Nginx·server_nameNginx는 listen과 server_name으로 서버 블록을 선택하고 URI에 따라 location을 적용한다.
• root·파일 경로root는 정적 파일 경로의 기준을 정하며 단순 root 매핑에서는 요청 URI를 이어 파일을 찾는다.
• alias·locationalias는 지정 location 부분을 다른 경로로 대체하는 방식이라 경로 결합 의미가 다르다.
• location정규식 location과 prefix location에는 선택 순서가 있으므로 파일에 적힌 모든 블록을 위에서 아래로 단순 실행한다고 보지 않는다.
• try_filestry_files는 지정 후보가 실제 존재하는지 순서대로 보고 마지막 처리로 넘어간다. 정적 사이트에서 try_files $uri $uri/ =404는 요청 파일, 디렉터리 후보를 살펴보고 없으면 404를 돌려주는 예다.
• indexSPA에서 무조건 index.html로 넘기는 구성을 일반 문서 사이트에도 쓰면 존재하지 않는 경로가 모두 200처럼 보일 수 있으므로 서비스의 라우팅 방식에 맞춘다.

server {
    listen 80;
    server_name study.example;
    root /srv/study;
    index index.html;
    location / {
        try_files $uri $uri/ =404;
    }
}

교육용 예시. 결과와 주소는 설명용이며 실제 시스템에서 실행한 기록이 아니다.

08설정 검사·reload와 실제 요청의 연결

• nginxapachectl configtest와 nginx -t는 설정 문법과 일부 참조 조건을 검사한다.
• DNS문법이 유효하다는 사실이 DNS·인증서·파일 접근·백엔드 응답까지 정상임을 보장하지는 않는다.
• reloadreload는 지원되는 방식으로 새 설정을 읽게 하는 요청이며 보통 기존 요청을 가능한 한 처리하면서 새 worker 또는 설정으로 전환한다.

  • 프로그램별 구현과 실패 시 기존 설정 유지 여부를 구분한다.
• access log·요청access log는 어떤 요청에 어떤 응답을 반환했는지, error log는 처리 중의 구체적 오류를 설명한다.
• 요청·Host로컬 요청에서 Host를 명시하면 DNS와 분리하여 가상 호스트 선택을 관찰할 수 있다.
• HTTPss의 listen 결과와 curl의 HTTP 상태를 이어 보면 연결 수락, 사이트 선택, 파일 처리라는 정상 흐름이 증거로 연결된다.
• 로그의 민감정보로그에는 인증 정보나 민감한 쿼리 문자열이 남을 수 있으므로 필요한 기록 범위를 설계한다.

  • 변경 전후에는 대표 경로와 오류 경로를 같은 조건으로 비교한다.
• HTTP·응답HTTP 응답이 성공했더라도 애플리케이션의 업무 기능까지 정상인지는 별도 검증이 필요하다.

nginx -t
# Apache 환경은 apachectl configtest / httpd -S
curl -i -H "Host: study.example" http://127.0.0.1/guide.html
ss -lntp

교육용 예시. 결과와 주소는 설명용이며 실제 시스템에서 실행한 기록이 아니다.

09한 HTTP 요청이 처리되는 단계

• 요청·TLSnotes.example.test의 정적 문서를 요청하는 예에서는 TLS 인증서 선택, HTTP 사이트 선택, URI의 파일 경로 대응, 파일 접근을 차례로 연결한다.
• 동적 경로의 처리같은 서버의 애플리케이션 경로로 바꾸면 마지막 단계가 파일 읽기에서 upstream 연결로 달라진다.
• 응답다음 도식에서 응답 코드가 만들어진 위치를 따라가면 인증서 문제·정적 파일 접근 문제·뒤 서버 연결 문제를 서로 구분할 수 있다.

1. 연결·TLS리스닝 주소에 연결하고 HTTPS이면 TLS 및 인증서 조건을 확인한다.
2. HTTP 요청Host와 문서 경로로 사이트와 경로 규칙이 선택된다.
3. 파일 열기문서 루트 등에 매핑된 경로의 읽기와 접근 조건을 확인한다.
4. 내용 반환파일 내용을 읽거나 경로·권한 오류가 반환된다.
5. HTTP 응답선택된 처리 결과를 상태 코드와 본문으로 전달한다.

10같은 서버에서 한 사이트만 실패하는 이유

• DNS기본 사이트는 열리는데 특정 도메인만 실패한다면 DNS 결과와 접속 이름, 가상 호스트 매칭, 해당 인증서를 확인한다.
• 404와 경로 매핑특정 경로만 404면 URL과 실제 파일 매핑을 대조하고, 403이면 파일·상위 경로 권한과 목록 정책 등 접근 조건을 확인한다.
• 502와 Upstream프록시 경로에서 502가 나오면 정적 파일 권한만 조사하지 말고 upstream 연결과 응답 형식을 살핀다.

  • 504는 중계 구간의 시간 초과를 조사할 단서다.
• 상태 코드의 한계오류 코드는 원인을 좁히는 단서이며 서버나 애플리케이션이 정의한 응답 정책도 고려해야 한다.
• 설정 검사설정 검사가 성공해도 바인딩할 포트 충돌, 인증서 파일 접근, 외부 의존성 실패는 실행 중에 드러날 수 있다.
• 같은 조건의 전후 비교변경 전후 같은 도메인·프로토콜·경로·인증 조건으로 요청해야 결과를 비교할 수 있다.
• 상태 코드접근 로그의 상태 코드와 처리 시간, 오류 로그의 시각을 연결하고 프록시가 있다면 요청 식별자로 뒤 서버까지 추적한다.
• 오래된 캐시 응답브라우저 캐시나 중간 캐시 때문에 오래된 응답을 보는 경우에는 실제 응답을 만든 계층과 캐시 조건도 확인한다.