큰 네트워크
네트워크의 속도와 성질이 사용자 경험에 주는 영향 — 무엇이 느림을 만들고(대역폭·지연), 무엇이 접속을 막는지(미들박스). traceroute의 동작 원리와 대역폭-지연 곱을 다룹니다.
같은 웹 앱인데도 어떤 사용자에게는 빠르고 어떤 사용자에게는 느립니다. 이 레슨에서는 네트워크의 속도와 성질이 사용자 경험에 어떤 영향을 주는지 — 무엇이 느림을 만들고(대역폭·지연), 무엇이 접속을 막는지(미들박스) — 정리합니다. 프론트엔드 성능 최적화와 “특정 사용자만 안 된다”는 문제를 진단하는 데 바탕이 됩니다.
hop과 traceroute
패킷이 라우터를 하나 거칠 때마다 이를 hop이라고 합니다. traceroute는 목적지까지 거치는 모든 hop(라우터 IP)을 순서대로 보여줘, 어디까지 트래픽이 도달하는지 확인할 수 있습니다.
traceroute는 별도의 기능이 아니라, 무한 루프를 막기 위한 안전장치를 활용한 것입니다. 모든 IP 패킷에는 TTL(Time To Live) 필드가 있어 라우터를 지날 때마다 1씩 줄어들고, 0이 되면 패킷이 폐기되며 그 라우터가 출발지로 “시간 초과” 에러 메시지를 돌려보냅니다. traceroute는 이 동작을 이용합니다.
- TTL=1 → 첫 번째 라우터에서 0이 되어 폐기 → 첫 라우터의 주소가 에러로 회신됨
- TTL=2 → 두 번째 라우터에서 폐기 → 두 번째 라우터 주소가 회신됨
- TTL을 1씩 늘려가며 보내면, 경로 전체를 순서대로 알아낼 수 있음
TTL=1 ▶ [R1] ✕ → R1 주소 회신
TTL=2 ▶ [R1] → [R2] ✕ → R2 주소 회신
TTL=3 ▶ [R1] → [R2] → [R3] ✕ → R3 주소 회신
…
TTL=n ▶ … → [목적지] 도착 → 경로 완성특정 사용자만 사이트가 느리거나 안 될 때, traceroute로 경로 어디쯤에서 멈추는지 보면 문제 지점(사용자 쪽 회선인지, 중간 경로인지)을 좁힐 수 있습니다.
대역폭과 지연 — 둘 다 “느림”으로 느껴진다
사용자가 “느리다”고 할 때 원인은 보통 둘 중 하나이며, 해결 방법이 다릅니다.
- 지연(latency) — 요청과 응답이 오가는 데 걸리는 시간입니다. 한국 사용자가 미국 서버에 접속하면 패킷이 먼 거리와 여러 hop을 왕복하느라 응답이 늦습니다. 거리와 hop 수가 주된 원인이고, 빛의 속도라는 물리적 한계가 있습니다. 작은 요청을 여러 번 주고받을수록 지연의 영향이 커집니다.
- 대역폭(bandwidth) — 단위 시간에 보낼 수 있는 데이터의 양입니다. 회선이 느리면 큰 이미지나 동영상, JS 번들이 다 내려오는 데 오래 걸립니다.
이 둘을 구분하면 최적화 방향이 보입니다. 지연이 문제면 요청 횟수를 줄이고(번들 합치기, HTTP/2 멀티플렉싱, 사용자와 가까운 CDN 사용) 왕복을 줄여야 합니다. 대역폭이 문제면 전송량을 줄여야 합니다(이미지 압축, 코드 분할, 캐싱).
여러 링크를 거치는 경로의 실제 대역폭은 가장 느린 링크(병목)에 의해 결정됩니다. 서버 쪽 회선을 아무리 빠르게 해도 사용자의 회선이 느리면 그 사용자의 체감 속도는 그대로입니다. 다만 느린 사용자가 동시에 아주 많으면 그 합이 서버 쪽 대역폭을 넘어설 수 있어, 서버 용량도 별개로 고려해야 합니다.
대역폭-지연 곱(BDP) 은
대역폭 × 왕복 지연(RTT)으로, 회선에 동시에 “떠 있을 수 있는” 데이터의 양을 뜻합니다. 빠르지만 먼 회선처럼 이 값이 크면, 한 번에 충분히 많은 데이터를 보내지 않는 한 대역폭을 다 쓰지 못합니다. 멀리 있는 서버에서 대용량을 받을 때 회선 속도만큼 안 나오는 이유가 여기에 있으며, 이것도 CDN으로 사용자와의 거리를 줄이면 완화됩니다.
패킷 손실이 (주로 혼잡 때문에) 발생할 때 TCP는 무엇을 해야 할까?
미들박스 — 방화벽·프록시·NAT
미들박스(middlebox) 는 클라이언트와 서버 사이에서 트래픽을 검사·수정·차단하는 중간 장치입니다(방화벽, 침입 탐지 시스템, 로드 밸런서 등). 출발지와 목적지 외에 경로 중간에서 통신에 개입하는 존재가 있다는 점이 핵심입니다.
- 방화벽 — 흔한 설정은 “허용된 (호스트, 포트) 조합 외에는 모두 차단”입니다. 백엔드 DB나 관리 시스템을 외부 공격에서 보호하지만, 개발·배포 과정에서 필요한 포트를 막아 방해가 되기도 합니다. 대부분의 방화벽이 HTTP(80·443)는 열어두기 때문에, 웹이 아닌 많은 통신도 HTTP를 운반 수단으로 사용합니다.
- 필터링/검열 — 일부 미들박스는 특정 웹페이지를 차단하거나 에러로 바꿉니다. 회사·학교의 콘텐츠 필터, 국가 차원의 검열 등이 여기에 해당합니다. “특정 지역 사용자만 우리 서비스에 접속이 안 된다”는 제보의 원인이 되기도 합니다.
- 프록시와 NAT — 한 공인 IP 뒤에 여러 사용자가 있을 수 있습니다(특히 통신사 단위의 carrier-grade NAT). 앞 레슨에서 본 대로, IP 주소 개수로 사용자 수를 세거나 IP로 사용자를 식별해서는 안 됩니다.
같은 공인 IP 뒤 사용자들을 웹앱이 구분하려면?
사용자가 "접속이 안 된다"고 할 때 방화벽/필터 차단 여부를 좁히는 점검으로 적절치 않은 것은?
이 레슨을 다 읽으셨나요?
완료 표시는 이 브라우저에 저장됩니다.