확인: HTTP 와 진단 순서

문항 6개. 정답과 해설은 풀어 본 뒤에 보여 드립니다.

1. `nc` 로 요청을 쓰는데 서버가 응답하지 않고 계속 기다린다. 가장 흔한 원인은?

   1. 헤더 뒤의 빈 줄을 빼먹어 서버가 헤더가 더 올 줄 안다
   2. HTTP/1.1 대신 HTTP/1.0 을 적었다
   3. Host 헤더의 값이 서버 주소와 달라 거절되었다
   4. 요청 줄의 경로가 슬래시로 시작하지 않았다

2. HTTP/1.1 에서 `Host` 헤더가 필수인 이유는?

   1. 서버가 응답을 돌려보낼 주소를 알아야 해서
   2. DNS 캐시를 서버 쪽에서 갱신하려고
   3. 프록시가 요청을 압축할지 결정하려고
   4. 한 서버(한 IP)가 여러 사이트를 받으므로 어느 사이트인지 골라야 해서

3. `curl` 이 `404` 를 받았다. 이 사실이 확실히 말해 주는 것은?

   1. DNS 가 틀려 엉뚱한 서버에 닿았다
   2. TCP 연결과 HTTP 요청·응답까지 모두 성공했고 그 경로의 자원만 없다
   3. 방화벽이 응답을 일부 잘랐다
   4. 서버 프로세스가 죽어 커널이 대신 답했다

4. 디렉터리를 `/docs` 처럼 슬래시 없이 요청했을 때 python http.server 의 응답은?

   1. 404 — 파일이 아니므로
   2. 200 — 디렉터리 목록을 그대로 보여 준다
   3. 301 과 `Location: /docs/` — 슬래시 붙은 곳으로 가라
   4. 403 — 디렉터리 접근은 금지

5. "ping 은 되는데 웹이 안 열린다" 에서 ping 결과가 확인해 준 것은?

   1. 방화벽이 TCP 80 을 열어 두고 있다
   2. 서버의 웹 프로세스가 살아서 듣고 있다
   3. TCP 80 포트까지의 핸드셰이크가 된다
   4. 링크·주소·경로처럼 ICMP 가 지나는 층은 정상이다

6. "web.lab.internal 이 안 열린다" 를 받았을 때 올바른 진단 순서는?

   1. 응답(curl -v) → 방화벽(counter) → 이름(getent) → 경로, 끝에서부터 거꾸로
   2. 이름(getent) → 경로(ip route get) → 포트(ss) → 방화벽(counter) → 응답(curl -v)
   3. 방화벽(nft)을 먼저 전부 끄고 되는지 본 뒤 규칙을 하나씩 켠다
   4. 서버(http.server)를 재시작하고 안 되면 라우터(ip_forward)를 재시작한다