핵심 진단 도구

앞 글에서 문제를 단계와 구간으로 나누어 좁히는 방법을 보았습니다. 이 글에서는 각 단계를 확인하는 도구를 다룹니다. 도구마다 확인해 주는 범위가 정해져 있어서, 그 범위를 넘어서 결과를 해석하면 엉뚱한 결론에 이릅니다. ping이 된다고 웹 서버가 정상인 것이 아니고, curl이 느리다고 서버의 처리가 느린 것도 아닙니다.

단계마다 쓰는 도구

ping과 traceroute, mtr은 5장 3편에서, openssl s_client는 10장 2편에서 자세히 보았으므로 여기서는 주의할 점만 짚고, 나머지 도구를 중심으로 봅니다. 패킷 분석은 다음 글에서 다룹니다.

ping과 traceroute를 쓸 때

ping이 답하지 않는다고 서버가 죽은 것은 아닙니다. 많은 서버와 방화벽이 ICMP를 막아 두기 때문입니다. AWS라면 새로 만든 보안 그룹은 들어오는 규칙이 하나도 없어 ICMP도 막히지만, 기본 보안 그룹은 같은 그룹에 속한 자원끼리의 트래픽을 허용하므로, 같은 VPC 안에서도 그룹에 따라 결과가 달라집니다. 반대로 ping이 된다고 웹 서버가 정상인 것도 아닙니다. ping이 확인하는 것은 ICMP가 오가는 길뿐이어서, 443번 포트가 막혔는지는 알려 주지 않습니다.

traceroute의 * * *는 그 홉이 응답하지 않았다는 뜻일 뿐 패킷을 넘기지 못한다는 뜻이 아니고, 한 홉의 지연이나 mtr의 손실률은 그 뒤의 홉과 목적지까지 이어지는지를 함께 봐야 합니다. 둘 다 가는 길만 보여 주므로 돌아오는 길이 의심된다면 반대쪽에서도 확인합니다.

dig와 getent로 이름을 확인한다

dig는 DNS 서버에 직접 질문을 보내 응답을 그대로 보여 줍니다. 8장 2편에서 본 것처럼 status와 flags, TTL까지 볼 수 있어 DNS의 문제를 진단하기에 좋습니다.

dig www.example.com A                     # 기본 리졸버에 묻는다
dig @1.1.1.1 www.example.com A            # 다른 리졸버와 비교한다
dig @ns1.example.com www.example.com A    # 권한 서버의 원본을 본다
dig +trace www.example.com                # 루트부터 위임을 따라간다
getent hosts www.example.com              # 운영체제가 실제로 주는 답(Linux)
Resolve-DnsName www.example.com           # Windows PowerShell

dig와 getent의 결과가 다를 수 있다는 점이 중요합니다. dig는 DNS 서버에만 묻지만, 애플리케이션이 쓰는 getaddrinfo()는 /etc/nsswitch.conf의 순서대로 hosts 파일과 DNS를 보므로, getent가 애플리케이션이 받는 답에 더 가깝습니다. hosts 파일에 예전 주소를 적어 두고 잊었다면 dig로는 정상으로 보이는데 애플리케이션은 계속 예전 서버로 갑니다. dig +trace도 그 순간 루트부터 직접 따라간 결과일 뿐, 리졸버의 캐시에 남은 답을 보여 주지는 않습니다.

더 깊이: getent hosts와 getent ahosts는 다른 함수를 부른다

getent는 데이터베이스 이름에 따라 다른 C 라이브러리 함수를 부릅니다. getent(1)에 따르면 hosts는 오래된 gethostbyname2()로 찾고, ahosts는 애플리케이션이 쓰는 getaddrinfo()를 주소 체계 AF_UNSPEC으로 불러 돌려받은 주소를 하나씩 보여 줍니다. 둘 다 /etc/nsswitch.conf를 따르므로 hosts 파일은 반영되지만, 보여 주는 주소의 목록은 다를 수 있습니다.

glibc의 getent 소스를 보면 getent hosts는 이름을 받으면 먼저 IPv6로 찾고, IPv6 주소가 하나도 없을 때만 IPv4로 다시 찾습니다. 그래서 A와 AAAA 레코드가 모두 있는 이름이라면 IPv6 주소만 보여 줄 수 있고, IPv4 주소가 틀린 문제를 이 명령으로는 놓칠 수 있습니다. 애플리케이션이 받는 주소 목록에 더 가까운 것은 getent ahosts이며, 한쪽 주소만 보고 싶다면 ahostsv4나 ahostsv6를 씁니다. 다만 ahostsv6는 AI_V4MAPPED를 켜고 getaddrinfo()를 부르므로, IPv6 주소가 하나도 없으면 IPv4 주소를 ::ffff:로 시작하는 IPv6 형식으로 바꾸어 보여 줍니다.

ss로 누가 듣고 있는지 본다

ss는 6장 1편에서 본 것처럼 소켓의 상태를 보여 줍니다. 서버가 떠 있는데 바깥에서 접속이 안 된다면, 가장 먼저 그 프로세스가 어느 주소에서 듣고 있는지 확인합니다. 다음은 ss -tlnp의 출력을 필요한 열만 남겨 옮긴 예입니다.

State   Local Address:Port   Process
LISTEN  0.0.0.0:80           nginx
LISTEN  0.0.0.0:443          nginx
LISTEN  127.0.0.1:3000       node
LISTEN  0.0.0.0:5432         postgres

nginx는 0.0.0.0, 곧 모든 주소에서 듣고 있지만, node는 127.0.0.1에서만 듣고 있습니다. 루프백 주소는 같은 컴퓨터 안에서만 닿으므로, 바깥에서 3000번 포트로 접속하면 연결이 거부됩니다. 같은 컴퓨터의 nginx가 이 포트로 프록시하는 구조라면 오히려 바람직한 설정이지만, 바깥에서 직접 받아야 한다면 애플리케이션이 그 인터페이스의 주소나 0.0.0.0에서 듣도록 고치고 방화벽도 열어야 합니다. 반대로 postgres가 0.0.0.0에서 듣고 있다면, 바깥에 열 필요가 없는 데이터베이스가 열려 있는 것은 아닌지 확인해야 합니다.

ss -s                                                          # 상태별 연결 수의 요약
ss -tnp state established                                      # 맺어진 연결과 그 프로세스
ss -Htn state established '( sport = :80 or dport = :80 )' | wc -l   # 80번 포트의 연결 수

마지막 명령은 로컬이나 상대의 포트가 정확히 80인 연결만 셉니다. 출력을 grep :80으로 거르면 8080번 포트의 연결까지 함께 세어지므로, ss의 필터 문법을 쓰는 편이 정확합니다.

nc와 Test-NetConnection으로 포트를 확인한다

nc(netcat)는 TCP 연결을 맺어 보기만 하는 데 쓰기 좋습니다. -z는 데이터를 보내지 않고 연결만 확인하고, -v는 결과를 자세히, -w는 기다릴 시간을 정합니다.

nc -zv -w 3 db.internal.example.com 5432          # 데이터베이스 포트에 연결되는가
nc -l 9000                                        # 서버 쪽: 9000번 포트에서 잠시 듣는다
nc -zv -w 3 server.example.com 9000               # 클라이언트 쪽: 방화벽이 이 포트를 통과시키는가
Test-NetConnection -ComputerName db.internal.example.com -Port 5432   # Windows PowerShell

nc -l로 서버 쪽에 임시로 포트를 열어 두고 반대쪽에서 연결해 보면, 애플리케이션과 상관없이 경로와 방화벽이 그 포트를 통과시키는지만 따로 확인할 수 있습니다. 연결이 바로 실패하면 RST를 받은 연결 거부이고, 정해 둔 시간만큼 기다리다 실패하면 아무 답이 없는 시간 초과입니다. 앞 글에서 본 것처럼 두 결과는 원인이 다릅니다. nc의 옵션은 배포판마다 들어 있는 구현에 따라 조금씩 다르므로, 옵션이 통하지 않으면 그 시스템의 man nc를 확인합니다.

curl로 HTTP를 들여다본다

curl은 HTTP 단계를 확인하는 가장 기본적인 도구입니다. 아래 네 줄은 같은 서버를 서로 다른 쪽에서 들여다봅니다. 연결 과정 전체를 보는 -v, 응답 헤더만 보는 -I, 리다이렉트를 끝까지 따라간(-L) 뒤의 주소와 상태 코드만 찍는 -w, DNS 대신 정한 주소로 접속하는 --resolve입니다. -s는 진행 막대 같은 부가 출력을 꺼서 필요한 결과만 남기고, -o /dev/null은 본문을 버립니다.

curl -v https://www.example.com/                          # 연결, TLS, 요청과 응답의 헤더를 모두 본다
curl -sI https://www.example.com/                         # 응답 헤더만
curl -sL -o /dev/null -w '%{url_effective} %{http_code}\n' https://example.com/   # 리다이렉트를 따라간 끝
curl --resolve www.example.com:443:192.0.2.11 https://www.example.com/            # DNS를 거치지 않고 특정 서버로

-v는 *로 시작하는 줄에 연결과 TLS의 진행을, >로 시작하는 줄에 보낸 요청의 헤더를, <로 시작하는 줄에 받은 응답의 헤더를 보여 주므로 어느 단계에서 멈췄는지 바로 보입니다. --resolve는 이름을 DNS로 풀지 않고 지정한 주소로 연결하면서도, SNI와 Host 헤더는 원래 이름 그대로 보냅니다. 그래서 로드 밸런서 뒤의 서버 한 대나 아직 DNS를 바꾸지 않은 새 서버를, 인증서 검사를 통과하는 그대로 시험해 볼 수 있습니다. 주소로 https://192.0.2.11/에 접속하면 인증서의 이름이 맞지 않아 실패하므로 이와 다릅니다.

느린 요청을 조사할 때는 -w로 단계마다의 시각을 찍습니다. 이 값들은 모두 요청을 시작한 순간부터 그 단계가 끝날 때까지의 누적 시간이라는 점이 중요합니다.

curl -o /dev/null -s -w 'dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer} total=%{time_total}\n' https://www.example.com/

그래서 단계마다 걸린 시간은 이웃한 값의 차이로 구해야 합니다. 다음 코드는 그림의 누적 시간을 구간으로 나눕니다.

def phases(t):
    names = ["DNS", "TCP 연결", "TLS", "첫 바이트까지", "본문 전송"]
    marks = [0, t["namelookup"], t["connect"], t["appconnect"], t["starttransfer"], t["total"]]
    return {name: round((b - a) * 1000) for name, a, b in zip(names, marks, marks[1:])}

timing = {"namelookup": 0.02, "connect": 0.08, "appconnect": 0.20, "starttransfer": 0.35, "total": 0.50}
result = phases(timing)
for name, ms in result.items():
    print(f"{name}: {ms}ms")
print(f"합계: {sum(result.values())}ms")

DNS: 20ms
TCP 연결: 60ms
TLS: 120ms
첫 바이트까지: 150ms
본문 전송: 150ms
합계: 500ms

connect 값 0.08초를 TCP 연결에 걸린 시간으로 읽으면 DNS의 20ms까지 더해 잘못 읽게 됩니다. 실제로 TCP 연결에 걸린 시간은 0.08 − 0.02 = 60ms입니다. TCP 연결의 시간은 거의 한 번의 RTT이므로, 이 값으로 서버까지의 RTT를 짐작할 수 있습니다. TLS의 120ms는 그 RTT의 두 배쯤이므로 TLS 1.2처럼 왕복이 두 번 필요한 핸드셰이크였을 수 있습니다.

TLS가 끝난 뒤 첫 바이트가 오기까지의 150ms를 서버의 처리 시간으로 읽으면 안 됩니다. 그 안에는 요청을 보내는 시간, 서버의 처리 시간, 첫 응답이 돌아오는 한 번의 RTT가 함께 들어 있습니다. 서버의 처리 시간만 알고 싶다면 같은 요청의 서버 기록과 대조합니다. 첫 바이트 뒤의 본문 전송 시간은 응답의 크기와 대역폭, 6장 3편의 혼잡 윈도우가 정합니다. 이 해석은 새 연결 하나로 리다이렉트 없이 HTTPS를 받는 경우의 것이며, 연결을 재사용하거나 프록시, HTTP/3를 쓰면 각 값의 뜻이 달라집니다.

정리

• 도구마다 확인해 주는 범위가 정해져 있으므로, 이름 해석, 경로, 포트, TLS, HTTP, 패킷의 단계마다 맞는 도구를 고르고 그 범위 안에서 해석합니다.
• ping이 안 된다고 서버가 죽은 것이 아니고, ping이 된다고 웹 서버가 정상인 것도 아닙니다.
• dig는 DNS 서버의 답을, getent는 hosts 파일까지 반영한 운영체제의 답을 보여 주므로 둘이 다르면 내 컴퓨터의 설정을 의심합니다.
• ss -tlnp로 서버가 어느 주소에서 듣는지 확인하고, 127.0.0.1에서만 듣는 서버는 바깥에서 닿지 않습니다.
• nc나 Test-NetConnection으로 포트의 연결만 따로 확인하며, curl --resolve는 DNS를 거치지 않고 특정 서버를 이름 그대로 시험하게 해 줍니다.
• curl의 -w 시간은 모두 누적 값이므로 이웃한 값의 차이로 구간을 구하고, 첫 바이트까지의 시간에는 RTT와 요청 전송이 섞여 있습니다.

연습 문제

1. 누적 시간을 구간으로

새 HTTPS 연결 하나로 리다이렉트 없이 받은 요청의 curl 결과가 dns=0.01 connect=0.05 tls=0.12 ttfb=0.40 total=0.70입니다. TCP 연결과 TLS, 첫 바이트까지, 본문 전송에 각각 몇 ms가 걸렸나요? 가장 긴 구간만 보고 원인이 된 장비를 정할 수 있나요?

2. 바깥에서 닿지 않는 서버

ss -tlnp에 LISTEN 127.0.0.1:3000 node가 보이고, 같은 서버에서 curl localhost:3000은 되는데 다른 컴퓨터에서 curl http://서버주소:3000은 연결이 거부됩니다. 왜 그런가요? 어떻게 고칠 수 있나요?

3. 특정 서버만 시험하기

www.example.com의 DNS는 로드 밸런서를 가리키고 있고, 그 뒤에 새로 올린 서버 192.0.2.11이 정상인지 DNS를 바꾸기 전에 확인하고 싶습니다. curl https://192.0.2.11/과 curl --resolve www.example.com:443:192.0.2.11 https://www.example.com/은 무엇이 다른가요?

다음 글 패킷 분석에서는 tcpdump와 Wireshark로 실제로 오간 패킷을 잡아, 핸드셰이크와 재전송, RST를 직접 읽어 내는 방법을 살펴봅니다.