6장

관찰 — curl 과 개발자 도구로 HTTP 의 실물을 읽는다

curl -v 의 > 는 보낸 리퀘스트, < 는 받은 리스폰스. -I 로 헤더만, -L 로 리다이렉트 추적. 개발자 도구의 Network 탭과 함께, 3 점 세트 읽기를 실물에 적용한다.

교재의 HTTP 에서, 실물의 HTTP 로

여기까지의 5 장으로, 왕복 서신의 서식·동사·답장의 숫자·곁들임 메모·캐시까지, 읽는 법의 도구는 갖춰졌습니다. 이 장에서는 그것을 실물에 적용합니다. 도구는 2 가지 — 커맨드 라인의 curl 과 브라우저의 개발자 도구입니다.

이 2 가지는 역할이 조금 다릅니다. curl 은 1 개의 리퀘스트를 날것 그대로 보내어 생 텍스트를 보여 주는 현미경, 개발자 도구는 페이지 전체의 수십 개의 리퀘스트를 한눈에 보는 레이더입니다. 1 개를 깊게 보려면 curl, 전체에서 이상을 찾으려면 Network 탭 — 이렇게 구분해 씁니다.

curl -v — 왕복 서신이 그대로 흐른다

curl -v https://example.com/ 을 실행하면(-v 는 verbose, 상세 표시), 접속의 경과와 함께 제 1 장에서 읽은 뼈대가 그대로 화면에 흐릅니다. 읽는 법의 열쇠는 행 머리의 기호입니다.

> 로 시작하는 행 — 보낸 것

이쪽에서 서버로. 리퀘스트 행(GET / HTTP/1.1)과 리퀘스트 헤더

< 로 시작하는 행 — 받은 것

서버에서 이쪽으로. 상태 행(HTTP/1.1 200 OK)과 리스폰스 헤더

* 로 시작하는 행 — curl 의 혼잣말

DNS 해석·TCP 접속·TLS 핸드셰이크의 경과 보고. 제 1 장의 Step 1〜3 이 여기에 보인다

기호 없는 행 — 바디

빈 줄 뒤에 도착한 본문(HTML 등)이 그대로 표시된다

즉 > 의 덩어리로 「무엇을 부탁했는가」, < 의 1 행째로 「결과는 어땠는가」, 이어지는 < 의 행으로 「조건과 보충」— 3 점 세트가 그대로 늘어서 있습니다.

curl -v 의 출력 예에, * 는 접속의 경과, > 는 보낸 리퀘스트, < 는 받은 리스폰스라는 주석을 붙인 그림

curl -v 출력의 주석 그림입니다. 기호 3 종(* / > / <)의 구별이 되면, 아무리 긴 출력이라도 「준비」「부탁한 것」「돌아온 것」의 3 블록으로 나눌 수 있습니다.

-I 와 -L — 헤더만·이동의 끝까지

조사에서 자주 나오는 2 가지 옵션을 짚어 둡니다.

curl -I(대문자 아이)는 「헤더만 주세요」입니다. HEAD 메서드(제 2 장)로 리퀘스트하므로, 돌아오는 것은 상태 행과 헤더뿐. Content-Type·Content-Length·Cache-Control 같은 곁들임 메모를, 본문을 다운로드하지 않고 확인할 수 있습니다.

$ curl -I https://example.com/
HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Content-Length: 1256
Cache-Control: max-age=86400

curl -L 은 「이동의 끝까지 따라가 주세요」입니다. curl 은 기본값으로는 리다이렉트를 따라가지 않고, 301/302 의 답장을 그대로 보여 줍니다. 이 정직함은 조사에 편리하고, 「어디로 이동시키려 하는가」는 Location 헤더로 확인할 수 있습니다. 최종적인 내용까지 원할 때 -L 을 붙입니다. 브라우저는 항상 -L 상당의 동작을 자동으로 하고 있으므로, curl 로 처음으로 「이동 그 자체」를 관찰할 수 있다고도 말할 수 있습니다.

개발자 도구의 Network 탭 — 열의 의미를 알면 무섭지 않다

브라우저에서 개발자 도구(많은 환경에서 F12)를 열고, Network 탭을 선택해 페이지를 새로 고침하면, 그 페이지가 보낸 모든 리퀘스트가 1 행에 1 개씩 늘어섭니다. 먼저 읽어야 할 열은 4 가지입니다.

Status

상태 코드. 빨간 행은 여기가 4xx/5xx. 조사는 이 열부터

Type

document / stylesheet / script / img 등, 리소스의 종류. Content-Type 에 대응

Size

전송량. 여기에 (disk cache) / (memory cache) 가 나오면, 서버에 리퀘스트는 나가지 않았다(제 5 장의 fresh 의 출구). 304 의 행은 전송이 수백 바이트가 되어 있을 것

Time

소요 시간. 성능 조사 때의 주역

행을 클릭하면 Headers 패널이 열리고, 리퀘스트 행·상태 행·모든 헤더 — 즉 이 강좌에서 읽어 온 텍스트 그 자체 — 를 확인할 수 있습니다.

하나 더, 체크박스인 Disable cache 를 기억해 주세요. 개발자 도구를 열고 있는 동안만 캐시를 무효로 하고, 항상 서버에서 가져오게 하는 설정입니다. 「수정이 반영되지 않는다」일 때, 캐시 탓인지 정말로 반영되지 않은 것인지를 나누는 최단 도구입니다.

전형적인 관찰 절차 — 3 점 세트를 실물에 적용한다

「표시가 이상하다」「API 가 실패한다」는 말을 들었을 때의, 이 강좌의 틀에 따른 절차를 정리합니다.

Step 1 — 실패 행을 찾아 Status 를 읽는다

Network 탭에서 빨간 행(또는 의심스러운 URL 의 행)을 찾아, 상태 코드의 백의 자리로 누구의 문제인지 분류한다(제 3 장)

Step 2 — 무엇을 부탁했는지 확인한다

그 행의 메서드와 URL. 「애초에 의도한 받는 곳·의도한 동사인가」를 의심한다(제 1〜2 장)

Step 3 — 조건과 보충을 읽는다

Headers 패널에서 Content-Type·Cache-Control·Cookie 등, 증상에 관계된 곁들임 메모를 확인한다(제 4〜5 장)

Step 4 — 재현을 최소화한다

의심스러운 1 개를 curl 로 단독 재현한다(-v 로 전문, -I 로 헤더만, -L 로 이동의 끝까지). 브라우저 고유의 요인(캐시·Cookie·확장 기능)과 떼어 놓을 수 있다

Step 4 가 듣는 것은, curl 이 깨끗한 1 개를 보내 주기 때문입니다. 브라우저에서 재현되는 문제가 curl 로 재현되지 않으면, 의심할 것은 캐시나 Cookie 등 브라우저 쪽의 상태 — 반대로 curl 로도 재현되면 서버 쪽으로 좁힐 수 있습니다.

이 장에서 가져갈 것

curl -v 는 > = 보낸 것, < = 받은 것, * = 접속의 경과. 3 점 세트가 그대로 늘어선다
-I 는 헤더만(HEAD), -L 은 리다이렉트의 끝까지. 기본값으로 이동을 따라가지 않는 정직함이 조사에 듣는다
Network 탭은 Status → 메서드와 URL → Headers 순으로 읽는다. Size 열의 (disk cache) 는 「리퀘스트가 나가지 않았다」의 표식
브라우저에서 재현되고 curl 로 재현되지 않으면 브라우저 쪽의 상태, curl 로도 재현되면 서버 쪽 — 구분의 정석

도구는 모두 갖춰졌습니다. 마지막 장은 종합 연습 — 실무풍의 8 가지 케이스에, 이 강좌의 틀을 적용해 읽어냅니다.