네트워크 기초 학습 메모: 처리량·지연시간·LAN/WAN·ping 구분하기

『면접을 위한 CS 전공지식 노트』의 네트워크 기초 부분을 읽으며 처리량, 지연시간, topology, LAN·MAN·WAN과 진단 명령을 정리했었다. 다시 확인해 보니 WAN을 World Area Network라고 쓴 부분과 ping을 Packet InterNet Groper의 약자로 설명한 부분이 잘못되어 있었다.

기초 용어는 짧게 외우기보다 무엇을 측정했고 무엇까지 확인했는가를 함께 적어야 장애 진단에도 쓸 수 있다.

bandwidth, throughput, latency는 같은 속도가 아니다

bandwidth는 링크나 경로가 이론적으로 제공할 수 있는 전송 용량을 가리킬 때 주로 쓴다. throughput은 일정 시간 동안 애플리케이션이나 전송 계층에서 실제로 전달한 데이터 양이다.

실제 throughput은 링크 용량뿐 아니라 packet loss, RTT, congestion control, protocol overhead, 서버와 클라이언트 성능, 경쟁 traffic의 영향을 받는다. 1Gbps link라고 해서 애플리케이션이 언제나 1Gbps를 얻는 것은 아니다.

latency도 측정 정의를 붙여야 한다.

• one-way delay: 출발지에서 목적지까지 한 방향에 걸린 시간
• RTT: 요청이 갔다가 응답이 돌아오기까지 걸린 왕복 시간

ping 출력은 ICMP Echo의 RTT다. 한 방향 latency와 같다고 볼 수 없고, 경로의 각 방향도 서로 다를 수 있다.

LAN과 WAN은 범위이지 성능 등급이 아니다

WAN은 Wide Area Network의 약자다. World Area Network가 아니다.

• LAN: 집, 사무실, 캠퍼스 일부처럼 비교적 제한된 영역의 local network
• MAN: 도시 규모를 설명할 때 쓰는 분류
• WAN: 여러 지역의 network를 장거리로 연결한 구조

이 구분은 주로 관리 범위와 지리적 규모를 설명한다. “LAN은 언제나 가장 빠르고 WAN은 언제나 가장 느리다”는 보장은 아니다. 혼잡한 무선 LAN보다 잘 설계된 전용 WAN 구간이 더 안정적일 수 있고, end-to-end 성능은 중간 경로 전체에 달려 있다.

star, tree, mesh 같은 topology의 장단점도 절대적이지 않다. 물리 배선, 논리적인 forwarding 구조, 장애 도메인, 제어 plane을 어느 관점에서 그렸는지 먼저 밝혀야 한다. 같은 network도 물리 topology와 논리 topology가 다를 수 있다.

ping은 무엇을 확인하고 무엇을 확인하지 못할까

ping은 IP와 ICMP Echo Request·Echo Reply를 이용해 대상까지의 왕복 응답과 손실을 관찰한다.

ping -c 4 1.1.1.1

ping을 만든 Mike Muuss는 이름을 sonar가 내는 소리에서 가져왔다고 설명했다. Packet InterNet Groper는 원래 이름을 만든 약자가 아니라 나중에 붙은 backronym으로 보는 것이 맞다.

ping 성공으로 알 수 있는 것은 제한적이다.

• 그 시점에 ICMP Echo 응답이 돌아왔다.
• 표본으로 보낸 packet의 RTT와 손실을 관찰했다.

다음까지 보장하지는 않는다.

• TCP port가 열려 있다.
• TLS와 HTTP가 정상이다.
• 애플리케이션이 건강하다.
• 실제 사용자 traffic과 같은 경로·우선순위를 쓴다.

반대로 ping 실패가 서비스 장애를 뜻하지도 않는다. 방화벽이나 장비가 ICMP Echo만 차단하거나 rate limit할 수 있기 때문이다.

traceroute의 각 줄을 링크 지연시간으로 단정하지 않는다

전통적인 traceroute는 IP TTL을 1부터 늘려 보내고, 중간 router의 ICMP Time Exceeded 응답을 이용해 hop을 추정한다.

traceroute example.com

표시된 시간은 probe가 해당 장비까지 갔다가 ICMP 응답이 돌아온 RTT다. 앞 hop과 다음 hop의 시간 차이가 곧 두 장비 사이 link delay라는 뜻은 아니다.

• router가 제어 plane ICMP 응답을 낮은 우선순위로 처리할 수 있다.
• ICMP를 rate limit하거나 응답하지 않을 수 있다.
• forward path와 return path가 다를 수 있다.
• load balancing 때문에 probe마다 다른 hop을 지날 수 있다.

중간 한 줄이 느려도 이후 hop이 정상이라면 그 router의 응답 정책일 수 있다. 목적지까지의 반복 측정과 실제 애플리케이션 요청을 함께 봐야 한다.

Linux에서는 질문별로 도구를 고른다

netstat과 nslookup이 완전히 사라진 것은 아니지만, 현대 Linux에서는 더 구체적인 도구를 자주 쓴다.

확인할 질문	예시 명령
interface와 주소가 있는가	ip address
어떤 gateway와 route를 쓰는가	ip route
neighbor 해석 상태는 어떤가	ip neighbor
이름이 어떤 record로 해석되는가	dig example.com A
local port가 listen 중인가	ss -lntp
TCP·TLS·HTTP 요청이 되는가	curl -v https://example.com/
hop별 응답 경향은 어떤가	traceroute 또는 tracepath

진단 순서는 증상에 맞춰 달라지지만, 다음 흐름이면 계층을 섞지 않고 범위를 좁히기 쉽다.

주소·link → route·gateway → DNS → TCP port → TLS → HTTP → 애플리케이션

예를 들어 도메인 접속이 안 될 때 IP 주소로 ping만 하고 끝내지 않는다. dig로 DNS를 분리하고, curl -v로 TCP·TLS·HTTP 중 어디서 실패하는지 확인한다. 서버 안에서는 ss로 process가 실제 주소와 port에 listen 중인지 확인한다.

프로토콜별 역할은 IP·ICMP·ARP·DHCP의 패킷 흐름에서, 명령을 이용한 더 긴 점검 순서는 Linux 네트워크 트러블슈팅에서 이어서 볼 수 있다.

참고 자료

• RFC 1122: Requirements for Internet Hosts
• RFC 792: Internet Control Message Protocol
• Mike Muuss: The Story of the PING Program
• iputils 공식 저장소: ping
• traceroute for Linux 공식 사이트