# 네트워킹과 인터넷을 제1원리부터 이해하기

> Clean Markdown view of GeekNews topic #31364. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=31364](https://news.hada.io/topic?id=31364)
- GeekNews Markdown: [https://news.hada.io/topic/31364.md](https://news.hada.io/topic/31364.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2026-07-13T06:45:23+09:00
- Updated: 2026-07-13T06:45:23+09:00
- Original source: [fazamhd.com](https://fazamhd.com/mental-models/networking/)
- Points: 4
- Comments: 1

## Topic Body

- 인터넷은 음성·영상·문자를 **전기·빛·전파의 패턴**으로 바꿔 여러 독립 사업자의 장비를 통과시키며, 중앙 통제자나 전체 경로를 아는 단일 주체 없이 각 홉의 로컬 판단만으로 데이터를 전달함
- 전신의 디지털 재생, 전화망의 회선 교환, 패킷 교환, Ethernet, IP, TCP, DNS, TLS는 완성된 청사진의 구성품이 아니라 각 시대의 **물리적·운영상 한계**를 해결하며 누적된 프로토콜임
- IP는 손실·중복·순서 변경을 허용하는 최선 노력형 전달만 맡고, **TCP**가 종단에서 재전송·순서 복원·혼잡 제어를 수행하며 DNS는 이름을 주소로 바꾸고 TLS는 인증과 암호화를 더함
- 웹페이지를 처음 열 때는 콘텐츠 전송보다 앞서 DNS 조회, TCP 연결, TLS 핸드셰이크에 여러 차례 왕복이 필요하므로, 높은 대역폭만으로는 **지연 시간에 따른 느린 시작**을 없앨 수 없음
- 단순한 IP 계층과 공개 표준 덕분에 HTTP, VPN, WebRTC, QUIC 같은 새 프로토콜을 기존 라우터의 허가나 교체 없이 배포할 수 있으며, 인터넷은 새로운 요구가 드러날 때마다 **계층별 한계**를 계속 보완함

---

### 물리 신호에서 비트로
- 인터넷 통신은 메시지를 Wi-Fi 전파, 구리선의 전기 펄스, 광섬유의 빛으로 연속 변환하고 반대편에서 역순으로 복원함
  - 장비와 케이블은 수백만 개의 대화가 공유하며, 데이터는 여러 국가의 독립 회사가 소유한 장비를 통과함
  - 중앙 컴퓨터가 트래픽을 지휘하지 않고 각 장비가 다음 경로만 선택함
- 인터넷은 한 번에 설계되지 않았으며 **패킷 교환·TCP·DNS·TLS**는 이미 작동하던 네트워크의 특정 문제를 해결하기 위해 뒤늦게 추가됨
- 모든 링크의 기본 원리는 한쪽에서 물리량을 변화시키고, 합의된 시점에 다른 쪽에서 이를 측정하는 것임
  - 팽팽한 줄은 기계적 진동을 전달하지만 거리와 함께 마찰·느슨함 때문에 신호가 약해짐
  - 구리선은 전압, 광섬유는 레이저, Wi-Fi는 전파의 형태를 변화시켜 비트를 운반함

### 전신이 확립한 디지털 통신과 프로토콜
- 네트워크라는 말은 원래 실이나 끈이 교차한 그물 형태를 뜻했으며, 19세기 초 운하·철도망을 거쳐 1840년대 전신의 전선·중계소 체계를 가리키게 됨
- 1844년 **Samuel Morse**는 Washington에서 Baltimore로 “What hath God wrought”를 전송함
  - Morse code는 음성을 그대로 보내지 않고 짧고 긴 전기 펄스라는 이산 기호를 전달한 디지털 네트워크였음
  - 중계기는 약해진 파형을 증폭하는 대신 펄스의 존재 여부를 판별하고 깨끗한 새 펄스를 생성함
  - 단순 증폭은 구간마다 잡음까지 키우지만, 이산 기호의 재생은 대륙 규모에서도 메시지 열화를 막음
- 송수신자가 문자별 펄스와 `received`, `repeat` 같은 절차를 미리 공유한 규칙이 **프로토콜**임
  - IP, TCP, DNS, TLS도 메시지 형식과 통신 순서를 공개적으로 합의한 규칙이라는 점에서 동일함
- 전신망에서는 사람이 라우팅을 수행함
  - 중계소 운영자가 메시지를 종이테이프에 찍고 목적지에 가까운 회선이 비면 재전송함
  - 혼잡한 시간에는 메시지를 보관함에 대기시켰으며, 이 구조가 이후 전자식 저장 후 전달과 라우터로 재현됨
- 최초의 대서양 횡단 전신 케이블은 **1858년 8월** 가동됐지만 절연 손상과 과전압 문제 속에 3주 만에 고장남
  - 성공한 케이블은 1866년 SS Great Eastern이 약 4,000km 길이를 한 덩어리로 부설함
- 비트는 `0`과 `1` 두 상태 중 하나를 나타내는 최소 정보 단위임
  - 8비트인 **1바이트**는 256개 상태를 표현하며 문자 하나나 작은 숫자를 담을 수 있음

### 대역폭과 지연 시간
- **대역폭**은 링크가 초당 운반하는 비트 수이고, **지연 시간**은 한 비트가 반대편까지 도달하는 데 걸리는 시간임
- 대역폭은 신호 전송 간격을 줄이거나 여러 파장을 병렬로 사용해 높일 수 있지만, 지연 시간은 거리와 빛의 속도에 제한됨
  - 빛은 유리에서 초당 약 200,000km로 이동하며 진공 속도의 약 3분의 2임
  - New York–London 구간은 편도 약 28ms가 물리적 하한이고 왕복에는 그 두 배가 필요함
- 영상 스트리밍은 몇 초를 미리 버퍼링해 지연을 견디지만 많은 대역폭이 필요함
- 영상 통화는 대역폭 요구량이 상대적으로 작아도 낮은 지연 시간이 중요함
- 웹페이지는 콘텐츠를 받기 전에 DNS, TCP, TLS 왕복을 거치므로 **기가비트 연결**에서도 시작이 느릴 수 있음
- 대역폭은 송신 일정에서, 지연 시간은 링크 길이에서 발생하므로 둘은 서로 교환되는 값이 아님

### 회선 교환과 모뎀
- 1876년 이후 전화망은 통화마다 종단 간 전용 전기 경로를 예약하는 **회선 교환**을 사용함
  - 초기에는 교환원이 패치 코드를 꽂았고 이후 전기기계식 릴레이가 자동화함
  - 음성은 통화 중 계속 흐르므로 예약된 회선을 지속적으로 사용하는 구조가 합리적이었음
- 1950~60년대 컴퓨터는 기존 전화망을 이용할 수밖에 없어 **모뎀(modulator-demodulator)** 으로 디지털 비트를 아날로그 음향으로 변환함
- Bell 103 같은 300-baud 초기 모뎀은 **FSK**를 사용함
  - `1`은 높은 주파수, `0`은 낮은 주파수의 연속 음으로 나타냄
  - 상대 모뎀은 들리는 주파수를 판별해 비트를 복원함
- 데이터 전송 전에는 통신 속도, 오류 교정, 회선 특성을 협상함
  - 1981년 Hayes Smartmodem 이후에는 사람이 연결 상태를 확인할 수 있도록 스피커가 켜져 있어 다이얼 톤, 호출, 기능 교환, 변조 협상, 등화기 훈련이 들렸음
  - 실제 핸드셰이크는 30초 이내에 여러 단계를 거침
- DSL과 케이블은 기존 전화선·TV선을 항상 연결된 디지털 링크로 재사용했고, 가정용 광섬유는 음성망의 전선을 완전히 벗어남
- 컴퓨터 트래픽은 요청 후 읽거나 계산하는 동안 쉬는 **버스트형**임
  - 회선을 예약하면 대부분의 시간에 용량이 놀고 다른 사용자는 이용하지 못함
  - 경로가 통화 시작 시 고정되므로 중간 링크 하나만 끊어져도 연결 전체가 종료됨
- 1960년대 초에는 연구용 컴퓨터 증가, 대화형 컴퓨팅의 버스트성, 일부 구간을 잃어도 살아남아야 했던 미군의 요구가 회선 교환의 한계를 드러냄

### 패킷 교환과 최선 노력형 전달
- **Paul Baran**은 생존성을 위해, **Donald Davies**는 회선 공유를 위해 패킷 교환을 독립적으로 고안했으며 Davies가 `packet`이라는 이름을 붙임
- 메시지는 작은 단위로 나뉘고 각 패킷은 출발지·목적지 같은 제어 정보를 담은 **헤더**와 실제 데이터인 페이로드로 구성됨
- 라우터는 패킷 전체를 받은 뒤 목적지를 읽고 자체 테이블에 따라 다음 링크로 보내는 **저장 후 전달(store-and-forward)** 을 수행함
  - 규모를 유지하기 위해 개별 호스트가 아니라 주소 범위인 네트워크를 테이블에 기록함
- 패킷은 여러 대화가 같은 회선을 교차 사용하며 각각 독립적으로 라우팅됨
  - 중간 라우터가 죽으면 이후 패킷은 다른 경로를 이용할 수 있음
  - 장애 정보가 퍼지기 전에는 오래된 경로로 전송돼 손실되며, 새 경로가 안정되는 과정을 **수렴(convergence)** 이라 함
- 주소를 가진 장치는 **호스트**, 대화를 시작하는 쪽은 클라이언트, 알려진 고정 주소에서 요청을 기다리는 쪽은 서버임
- 입력 속도가 출력 링크보다 빠르면 라우터는 패킷을 메모리에 대기시키고, 큐가 차면 초과분을 버림
- 네트워크는 패킷의 손실·중복·순서 변경을 허용하는 **최선 노력형 전달**만 제공함
  - 신뢰성을 네트워크 중앙이 아니라 종단 컴퓨터에 맡긴 결정이 인터넷을 단순하게 유지하고 세계 규모로 확장하는 기반이 됨

### ARPANET과 최초의 라우터
- ARPA는 1969년 대학 연구용 컴퓨터를 연결하기 위해 최초의 실제 패킷 교환망인 **ARPANET**을 지원함
- 제조사와 운영체제가 다른 메인프레임에 패킷 교환 작업을 맡기기 어려워 BBN이 **IMP(Interface Message Processor)** 를 제작함
  - IMP는 메시지를 패킷으로 분할·라우팅·재조립하는 전용 미니컴퓨터였음
  - 사이트의 메인프레임은 로컬 IMP에 연결되고 IMP끼리는 임대 전화선으로 통신함
  - 계산을 수행하는 메인프레임을 `Host`, 전송 인프라를 IMP로 구분한 용어가 오늘날까지 이어짐
  - IMP는 최초의 라우터이며, 가정용 무선 라우터도 전용 장치가 네트워크 프로토콜을 대신 처리한다는 같은 패턴을 따름
- 1969년 10월 29일 UCLA의 Charley Kline이 Stanford Research Institute에 `LOGIN`을 입력하다 `LO`까지 보낸 시점에 수신 시스템이 고장남
- ARPANET은 1969년 12월 4개 노드가 됐고, 1973년 Norway와 London까지 확장됨

### Ethernet과 로컬 네트워크
- ARPANET 같은 원거리망은 **WAN**, 사무실 안의 여러 장치를 연결하는 망은 **LAN**임
- Robert Metcalfe는 1973년 Xerox PARC에서 **Ethernet**을 설계함
  - Hawaiian islands를 연결했던 ALOHAnet의 무허가 전송과 충돌 처리에서 아이디어를 얻음
  - 초기 Ethernet은 모든 컴퓨터가 하나의 공유 동축 케이블에 연결되고 모든 프레임을 받되 자기 주소만 처리함
- 동축 케이블은 중심 구리선, 절연층, 원통형 차폐체, 외피로 구성됨
  - 차폐체는 귀환 경로이면서 외부 간섭을 차단함
- 공유선에서 두 장치가 동시에 송신하면 **충돌**이 발생함
  - CSMA/CD는 송신 전 매체를 듣고, 송신 중 충돌을 감지하면 즉시 멈추며, 무작위 시간 뒤 재시도함
  - 반복 충돌 때 지연 범위를 두 배로 늘리는 **지수 백오프**가 영구적인 충돌을 막음
- 현대 사무실은 공유 동축 케이블 대신 각 장치에서 스위치까지 전용 꼬임선과 RJ-45 커넥터를 사용함
  - 각 포트가 전용선이고 송수신 경로가 분리된 **전이중**이므로 충돌이 원칙적으로 없음
  - CSMA/CD는 현대 유선 Ethernet에서 쓸모가 없어졌지만, 공유 매체인 공기를 쓰는 Wi-Fi에는 경합 문제가 다시 나타남
- ## 스위치와 MAC 주소
  - 네트워크 `switch`라는 이름은 철도 분기기, 전류를 전환하는 전기 키, 전화 교환대와 같은 계보를 가짐
  - 현대 네트워크 스위치는 수백만 개의 트랜지스터 스위치로 만든 ASIC으로 프레임을 전달함
  - 라우터는 전역 네트워크 주소를 사용하지만, 스위치는 로컬 하드웨어 주소인 **MAC 주소**를 사용함
  - Ethernet의 데이터 단위는 프레임임
  - MAC 주소는 `00:1A:2B:3C:4D:5E`처럼 6쌍의 16진수, 총 48비트로 기록함
  - 16진수 한 자리는 정확히 4비트, 두 자리는 1바이트와 정렬되므로 원시 비트를 짧게 나타내기에 적합함
  - 전통적인 MAC 주소의 앞 3쌍은 제조사 OUI, 뒤 3쌍은 해당 인터페이스의 일련번호임
  - 스마트폰도 Wi-Fi와 Bluetooth 칩에 각각 주소를 가짐
  - 고정 주소를 이용한 공공장소 추적을 막기 위해 현대 운영체제는 검색·연결 시 임시 무작위 MAC 주소를 생성함
  - 스위치는 프레임의 **출발지 MAC**과 들어온 포트를 관찰해 전달 테이블을 자동으로 학습함
  - 목적지가 아직 없으면 다른 모든 포트로 플러딩함
  - 목적지를 알면 해당 포트 하나로만 전달함
  - 스위치의 테이블은 로컬 트래픽에서 수동으로 추론되지만, 라우터의 테이블은 수동 설정이나 라우팅 프로토콜로 채워짐
  - MAC 주소는 로컬 세그먼트에서만 의미가 있고, IP 주소는 네트워크 사이를 이동하는 데 사용됨

### IP와 네트워크의 네트워크
- 1970년대 SATNET, PRNET, Ethernet 등 서로 다른 패킷망은 형식·주소·최대 크기가 달라 직접 통신할 수 없었음
- Vint Cerf와 Bob Kahn은 1973년 각 망의 내부 구조를 통일하지 않고 연결하는 **internetwork**를 설계함
- IP는 모든 참여 네트워크가 동의해야 하는 얇은 공통 계층임
  - 범용 IP 주소와 범용 패킷 형식을 정의함
  - 각 로컬 네트워크는 IP 패킷을 자체 프레임 안에 넣어 운반함
  - 라우터는 대화 상태를 기억하지 않으며 손실을 복구하지도 않음
  - 설정 단계도 패킷 간 공유 상태도 없는 **비연결형**이므로 구리선·광섬유·무선·위성 어디서나 구현할 수 있음
- 다양한 물리 매체가 아래에 있고 다양한 애플리케이션이 위에 있으며, 가운데 IP가 좁은 공통 지점을 이루는 **모래시계 구조**가 상호운용성을 만듦
- ## IPv4 주소와 최장 접두사 일치
  - IPv4 주소는 32비트, 즉 4개의 옥텟을 `91.198.174.192`처럼 점으로 구분한 10진수로 기록함
  - `/24`는 앞 24비트가 고정된 네트워크 접두사임
  - `255.255.255.0`이라는 서브넷 마스크도 같은 고정 비트를 다른 방식으로 나타냄
  - 라우터는 목적지와 경로를 XOR하고 접두사 이후를 마스킹해 고정 부분의 불일치 여부를 검사함
  - 여러 경로가 일치하면 가장 많은 비트가 고정된 **최장 접두사 일치**를 선택함
  - 구체적 경로가 없을 때 `0.0.0.0/0` 기본 경로를 사용함
  - 각 라우터는 전체 인터넷 지도가 아니라 이웃과 기본 방향만 알아도 다음 라우터의 같은 판단을 통해 목적지에 도달함
- ## Classful addressing에서 CIDR로
  - 1981년의 classful addressing은 네트워크 크기를 세 종류로 고정함
  - Class A `/8`은 16,777,216개, Class B `/16`은 65,536개, Class C `/24`는 256개 주소를 제공함
  - 약 4,000개 주소가 필요한 조직은 Class B를 받아 약 94%를 낭비하거나 Class C 16개를 받아 모든 코어 라우터에 16개 경로를 만들 수밖에 없었음
  - 1990년대 초에는 주소 공간과 라우터 메모리가 빠르게 소진됨
  - 1993년 도입된 **CIDR**은 접두사 길이를 자유롭게 정함
  - `/20` 하나로 4,096개 주소를 제공하고 인접 블록을 하나의 경로로 집계할 수 있음
  - IANA는 전체 IPv4 공간을 관리하고 5개 지역 인터넷 레지스트리에 큰 블록을 배분함
  - 지역 레지스트리는 ISP에, ISP는 기업과 가정에 더 작은 블록을 나눠 줌
  - 각 기관이 자기 영역만 관리하는 계층적 위임은 DNS와 같은 확장 원리임
- ## TTL, ICMP, ping, traceroute
  - IP 헤더의 **TTL**은 시간 대신 남은 홉 수를 나타내며 라우터마다 1씩 감소함
  - 0이 되면 패킷을 폐기해 잘못된 경로가 패킷을 무한 순환시키는 일을 막음
  - TTL 만료 시 라우터는 출발지에 ICMP `Time Exceeded`를 보냄
  - `ping`은 ICMP `Echo Request`와 `Echo Reply`의 왕복 시간으로 특정 호스트까지의 지연을 측정함
  - `traceroute`는 TTL을 1, 2, 3으로 늘려 각 홉에서 발생한 `Time Exceeded` 응답을 수집함
  - 원래 루프 방지용으로 만든 TTL에서 경로 진단 기능이 파생됨
- ## MTU와 단편화
  - 링크마다 한 번에 운반 가능한 최대 크기인 **MTU**가 있고 Ethernet은 1,500바이트임
  - 전통적인 IPv4 라우터는 다음 링크보다 큰 패킷을 여러 조각으로 단편화하고 목적지에서 재조립함
  - 라우터 작업량이 늘고 한 조각만 잃어도 원본 전체를 다시 보내야 함
  - 현대 방식은 `don’t fragment`를 설정하고, 전달할 수 없는 라우터가 ICMP로 허용 MTU를 알려 주는 **Path MTU Discovery**를 사용함
  - 더 좁은 후속 링크가 나오면 송신자는 다시 크기를 줄여 실제 경로의 최소 MTU에 수렴함
  - IPv6는 라우터 단편화를 제거하고 송신자 측 PMTUD만 허용함
- ## 유니캐스트·브로드캐스트·ARP·멀티캐스트
  - 한 송신자에서 한 수신자로 보내는 **유니캐스트**가 대부분의 인터넷 트래픽을 차지함
  - 서브넷은 같은 선이나 무선 채널에서 라우터 없이 MAC 주소로 직접 도달할 수 있는 물리·수치적 이웃임
  - 브로드캐스트는 서브넷의 모든 호스트에 전달되며 라우터 경계를 넘지 않음
  - DHCP는 주소가 없는 장치에 설정을 배포함
  - **ARP**는 “이 IP를 가진 장치는 누구인가”를 브로드캐스트하고 소유자만 유니캐스트로 답해 로컬 IP 주소에 대응하는 MAC 주소를 찾음
  - 결과는 몇 분간 캐시됨
  - 외부 서브넷 목적지에는 원격 서버가 아니라 기본 게이트웨이의 MAC 주소를 조회함
  - 멀티캐스트는 가입한 그룹에만 한 패킷을 전달하며 IPTV와 내부 라우팅 프로토콜 등에 쓰임
  - IPv4의 약 43억 개 주소는 부족해졌고, 128비트 주소를 사용하는 **IPv6**가 약 20년 동안 병행 배포돼 현재 트래픽의 거의 절반을 운반함

### TCP가 만드는 신뢰성
- **TCP**는 IP가 제공하지 않는 신뢰성을 두 종단에서 구현하며 중간 라우터는 TCP 상태를 알지 못함
- 모든 바이트에 번호를 붙이고 수신자는 다음에 기대하는 바이트를 ACK로 알림
  - 확인되지 않은 데이터는 재전송함
  - 순서가 뒤바뀐 데이터는 번호에 따라 재정렬한 뒤 애플리케이션에 전달함
- 양쪽이 대화 상태를 기억하므로 TCP는 **연결 지향형**이며 명시적인 시작과 끝이 있음
- 계층별 데이터 단위는 Ethernet 프레임, IP 패킷, TCP 세그먼트, UDP 데이터그램임
- ## 3-way handshake와 체크섬
  - TCP의 **3-way handshake**는 양쪽의 초기 순서 번호를 동기화함
  - 1. 클라이언트가 `SYN, seq=5000`을 보냄
  - 2. 서버가 `SYN-ACK, seq=9000, ack=5001`로 응답함
  - 3. 클라이언트가 `ACK, ack=9001`을 보냄
  - 체크섬은 전송 바이트로 계산한 값을 함께 보내고 수신자가 다시 계산해 우발적인 비트 손상을 감지함
  - 불일치한 패킷은 폐기되며 ACK가 없으므로 기존 재전송 절차가 복구함
  - Ethernet은 CRC 기반 frame check sequence, IP·TCP·UDP는 1의 보수 덧셈을 사용함
  - 체크섬을 다시 계산할 수 있는 공격자의 고의적 변조는 막지 못하며 그 역할은 TLS가 담당함
- ## 흐름 제어와 혼잡 제어
  - TCP 송신자는 확인되지 않은 데이터를 제한하는 **슬라이딩 윈도우**를 유지함
  - ACK가 도착할 때마다 창이 앞으로 이동해 빠른 송신자가 느린 수신자를 압도하지 않게 함
  - 손실은 중간 라우터의 큐가 넘친 신호로 해석되며 송신자는 창을 줄임
  - 1986년 10월 Lawrence Berkeley Lab과 UC Berkeley 사이 400m 링크는 송신자들이 손실에 더 많은 재전송으로 대응하면서 32,000bps에서 40bps로 붕괴함
  - Van Jacobson의 혼잡 제어는 손실 때 전송량을 배수적으로 줄이고 성공 때 조심스럽게 늘림
  - 수십억 연결이 중앙 조정 없이 같은 로컬 규칙을 적용해 공유망의 혼잡 붕괴를 방지함
  - 중간 패킷이 빠지면 수신자는 마지막 연속 바이트에 대한 중복 ACK를 보내며, 송신자는 타임아웃 전에 손실을 감지해 재전송할 수 있음
- ## 포트·소켓·UDP
  - IP 주소가 장치를 식별한다면 **포트**는 그 장치 안의 프로그램을 식별함
  - HTTPS 서버는 관례적으로 443번 포트를 사용함
  - IP 주소, 포트, 프로토콜의 조합이 애플리케이션의 소켓 종점을 나타냄
  - 클라이언트 운영체제는 연결 동안 임시 포트를 빌려 응답이 올 대상을 구분함
  - **UDP**는 IP에 포트만 추가하고 연결 설정, 재전송, 순서 복원을 제공하지 않음
  - 웹페이지·메일·파일처럼 완전성이 중요한 데이터에는 TCP가 적합함
  - 영상 통화·멀티플레이어 게임·DNS처럼 늦은 데이터가 손실보다 나쁜 경우 UDP가 적합함
  - TCP/IP는 1983년 1월 1일 ARPANET의 공식 프로토콜이 됐으며, IP 패킷 운반에 동의하는 모든 네트워크가 인터넷을 구성함

### 라우팅 정보가 만들어지는 방식
- ## 조직 내부의 OSPF와 RIP
  - 한 조직 안에서는 **IGP**가 링크 상태와 경로 정보를 교환함
  - OSPF 같은 링크 상태 프로토콜은 각 라우터가 자기 연결 정보를 전체에 플러딩함
  - 모든 라우터가 같은 토폴로지 지도를 가지고 독립적으로 최단 경로를 계산함
  - RIP 같은 거리 벡터 프로토콜은 이웃에게 목적지까지의 홉 수만 알림
  - 교환량은 작지만 이웃의 숫자가 여전히 참인지 검증할 전체 지도가 없음
  - 장애 후 테이블이 새 상태를 반영하는 과정이 수렴임
  - OSPF는 실제 토폴로지 변경을 전달해 빠르게 수렴함
  - RIP는 두 이웃이 서로를 경로로 믿는 루프를 만들 수 있고 패킷은 TTL이 끝날 때까지 왕복함
  - RIP는 16홉을 도달 불가로 처리하며 여러 완화책에도 OSPF보다 수렴이 느려 대부분의 프로덕션망에서 대체됨
- ## 자율 시스템과 BGP
  - NSFNET은 1985년 여러 지역 학술망을 연결하는 백본으로 시작함
  - 초기에는 상업 트래픽을 금지했고 1991년 제한을 해제함
  - 1995년 폐쇄 후 백본 역할이 여러 경쟁 상업 통신사로 분산되면서 인터넷은 단일 소유자가 없는 구조가 됨
  - 인터넷은 ISP, 대학, 통신사, 클라우드 기업 등 수만 개의 **자율 시스템(AS)** 으로 구성됨
  - BGP는 각 AS가 도달 가능한 주소 블록과 거쳐 온 AS 경로를 이웃에게 알리게 함
  - 실제 경로 선택은 속도보다 사업 정책을 우선함
  - AS 경로 길이는 로컬 선호도와 weight 같은 정책 기준 뒤에 적용되는 판별 조건임
  - 작은 사업자는 상위 사업자에게 전체 인터넷 연결 비용을 내는 **transit**을 구매함
  - 비슷한 규모의 네트워크는 transit 비용을 줄이기 위해 정산 없는 피어링을 맺음
  - 인터넷 교환 지점의 공통 스위칭 시설에서 수백 개 네트워크가 연결됨
  - DE-CIX와 AMS-IX는 약 1,000개 네트워크 규모를 연결함
  - BGP 정책은 일반적으로 돈을 받는 고객 경로, 무료인 피어 경로, 돈을 내는 공급자 경로 순으로 선호함
  - Lumen, Arelion, NTT 같은 tier-1 백본은 서로 피어링하며 상위 사업자에게 비용을 내지 않음

### 해저 광케이블, Anycast, CDN
- 약 **600개 해저 광케이블**이 사실상 모든 대륙 간 트래픽을 운반함
- 1956년 TAT-1은 동축 구리선으로 36개 음성 회선을 제공하고 약 70km마다 증폭기를 배치함
  - 아날로그 증폭은 신호와 잡음을 함께 키움
- 1988년 TAT-8은 최초의 대서양 횡단 광케이블로 두 가닥의 유리섬유에서 수만 개 음성 회선 상당의 용량을 제공함
- 광섬유는 굴절률이 높은 코어와 이를 둘러싼 클래딩의 경계에서 **전반사**를 이용함
  - 일반 거울과 달리 경계 반사 손실이 없어 약 100km 동안 빛을 안내한 뒤 증폭할 수 있음
- 파장 분할 다중화는 각 레이저의 비트 스트림을 서로 다른 파장에 실어 한 가닥에 합침
  - 파장은 선형 매질에서 함께 진행한 뒤 반대편 필터로 분리됨
  - 실제 시스템은 한 가닥에 약 100개 파장을 넣으며, 새 파장 하나가 기존 해저 유리의 처리량을 한 스트림만큼 늘림
- **Anycast**는 여러 대륙의 서버가 같은 IP를 사용하고 각 위치에서 같은 경로를 BGP로 광고함
  - 클라이언트는 설정 변경 없이 토폴로지상 가까운 서버에 도달함
- CDN은 Anycast나 위치 인식 DNS를 이용해 콘텐츠를 가까운 서버에서 제공함
  - Cloudflare와 Akamai는 영상·이미지·웹사이트 복사본을 전 세계에 배치함
  - 빛의 속도가 만드는 지연 하한을 줄이는 방법은 요청 전에 데이터를 사용자 가까이 옮기는 것임
- BGP는 이웃의 광고를 대체로 신뢰함
  - 2008년 Pakistan Telecom이 국내 YouTube 차단을 위해 더 구체적인 경로를 광고했고, 이 정보가 세계로 퍼져 많은 트래픽이 Pakistan으로 흘러 사라짐
  - **RPKI**는 서명된 레지스트리를 통해 주소 블록의 경로 광고 권한을 검증함

### 가정용 사설망과 NAT
- 가정용 라우터 한 대에는 Ethernet 스위치, Wi-Fi 무선 장치, DHCP, 기본 게이트웨이, DNS 설정 배포 기능이 결합됨
- 인터넷에서 라우팅되지 않는 사설 IPv4 블록은 반복해서 재사용할 수 있음
  - `10.0.0.0/8`은 16,777,216개 주소
  - `172.16.0.0/12`는 1,048,576개 주소
  - `192.168.0.0/16`은 65,536개 주소
- **NAT**는 내부 사설 주소와 포트를 라우터의 공인 주소와 포트로 바꾸고 응답을 원래 내부 대화로 되돌리는 테이블을 유지함
  - 서로 다른 집의 `192.168.1.5`는 패킷이 각 사설망을 벗어나지 않아 충돌하지 않음
- NAT는 내부에서 시작한 대화만 기록하므로 요청하지 않은 외부 연결을 버림
  - 가정에서 서버를 운영하려면 특정 외부 포트를 내부 장치에 연결하는 포트 포워딩이 필요함
  - ISP가 공인 주소를 바꾸면 이를 별도로 추적해야 함
  - P2P 영상 통화는 양쪽이 동시에 패킷을 보내는 등 NAT 통과 기법이 필요함
  - 주소 부족의 임시 해결책이 인터넷을 외부 요청을 받는 서버와 요청만 시작하는 장치로 나누게 됨
- `127.0.0.0/8`은 루프백 주소이며 네트워크 카드까지 가지 않고 운영체제가 같은 컴퓨터로 되돌림
  - `127.0.0.1`은 관례적으로 `localhost`임
  - 개발 서버의 `127.0.0.1:3000`은 해당 컴퓨터에서만 접근 가능함
- 장치는 로컬 하드웨어를 나타내는 MAC 주소와 네트워크에서 할당된 IP 주소를 동시에 가짐

### DNS: 숫자 대신 이름 사용하기
- ARPANET 초기에는 Stanford Research Institute의 Elizabeth Feinler 그룹이 `HOSTS.TXT` 하나에 모든 이름과 주소를 수동 관리함
  - 각 컴퓨터가 파일을 정기적으로 내려받았고, 등록되지 않은 장치는 사실상 찾을 수 없었음
  - 네트워크 성장으로 한 사무실의 편집 능력과 단일 다운로드 지점이 병목이 됨
- Paul Mockapetris는 1983년 위임 기반 **DNS**를 설계함
  - `en.wikipedia.org`는 오른쪽에서 왼쪽으로 root, `org`, `wikipedia.org`, `en` 계층을 따름
  - 네임스페이스는 각 조직이 권한 서버를 관리하는 zone으로 나뉨
- 기기는 ISP나 Cloudflare `1.1.1.1` 같은 재귀 리졸버에 조회를 맡김
  1. root는 `.org` 네임서버를 알려 줌
  2. `.org`는 `wikipedia.org`의 권한 서버를 알려 줌
  3. Wikipedia 권한 서버가 `91.198.174.192`와 3,600초 TTL을 답함
- DNS의 TTL은 IP 홉 수와 달리 초 단위 캐시 수명임
  - 브라우저, 운영체제, 재귀 리졸버가 응답을 캐시해 인기 이름은 가까운 곳에서 즉시 해결됨
  - 캐시는 상위 DNS의 부하를 낮추지만 주소 변경 후 이전 값이 TTL 동안 남는 정체성을 만듦
- 도메인 구매 시 registrar가 `.com` 같은 registry의 zone에 권한 네임서버를 지정하는 **NS record**를 기록함
  - 도메인의 zone file은 IPv4용 A record와 IPv6용 AAAA record 등을 가짐
  - Cloudflare, Route 53, registrar 또는 직접 운영하는 서버가 권한 DNS를 맡을 수 있음
  - 위치 인식 DNS는 질의 위치에 따라 서로 다른 데이터센터 주소를 돌려줄 수 있음
- ## DNS 보안과 프라이버시
  - 초기 DNS는 먼저 도착해 질의와 일치하는 답을 신뢰함
  - Dan Kaminsky는 2008년 16비트 트랜잭션 ID의 65,536개 가능성을 악용한 캐시 오염 위험을 공개함
  - 공격자가 진짜 답보다 먼저 ID를 맞춘 위조 응답과 악성 네임서버 정보를 보내면 리졸버가 공격자 지정 TTL 동안 거짓 정보를 캐시할 수 있음
  - **DNSSEC**는 각 zone이 레코드에 암호학적 서명을 붙이고 리졸버가 신뢰하는 root key까지 체인을 검증하게 함
  - 위조 답의 서명은 검증되지 않아 폐기됨
  - DNSSEC는 진위와 무결성을 보장하지만 질의 자체를 암호화하지 않음
  - DoT와 DoH는 DNS 질의를 각각 TLS 또는 HTTPS 안에 넣어 경로상의 관찰자가 조회 도메인을 읽지 못하게 함

### 웹이 추가한 사용자 인터페이스
- 1980년대 말까지 IP, TCP, Ethernet, DNS가 완성됐지만 정보 접근에는 대상 시스템과 명령줄 도구를 알아야 했음
- Tim Berners-Lee는 1989년 CERN에서 문서 공유 시스템을 제안했고 1991년 **World Wide Web**을 가동함
- 웹은 세 가지 단순한 구성요소를 사용함
  1. **HTML**은 문서의 단어나 요소를 인터넷상의 다른 문서로 연결함
  2. URL은 `https`, `en.wikipedia.org`, `/wiki/Internet`처럼 프로토콜·서버·경로를 나타냄
     - HTTPS 기본 포트는 443, HTTP는 80이므로 생략할 수 있음
  3. HTTP는 TCP 위에서 `GET /page` 같은 요청과 응답을 교환함
     - `200 OK`는 성공, `404 Not Found`는 문서 부재, `500 Internal Server Error`는 서버 내부 실패임
- URL은 DNS, HTTP는 TCP, TCP는 IP 위에 구축되므로 새 웹을 위해 기존 라우터를 바꿀 필요가 없었음
- IP, TCP, DNS, HTTP는 누구나 무료로 읽고 구현할 수 있는 **RFC**에 정의됨
  - RFC는 1969년 ARPANET 개발자들이 의견을 구하던 메모에서 시작함
  - IETF는 1986년부터 인터넷 프로토콜을 표준화함
  - 80·443번 포트도 RFC가 IANA에 등록한 관례임
- NCSA Mosaic은 1993년 문서 안에 이미지를 배치했고, 같은 팀의 Netscape Navigator는 1994년 웹을 가정으로 확산시킴

### 공개된 회선에서 비밀을 교환하는 TLS
- 초기 인터넷 프로토콜은 평문 바이트를 보내므로 라우터, ISP, 중간 네트워크가 내용을 읽거나 바꿀 수 있었음
- **공개키 암호화**는 계산은 쉽지만 역산은 현실적으로 어려운 연산으로 공개키와 개인키 한 쌍을 만듦
  - 공개키로 암호화한 데이터는 개인키로만 복호화할 수 있음
  - 개인키로 만든 서명은 공개키로 검증할 수 있음
  - 실제 서명은 메시지 전체 대신 모든 바이트에서 계산한 해시를 서명해 변경 여부도 묶음
  - RSA뿐 아니라 ECDSA와 Ed25519도 개인키 서명·공개키 검증이라는 계약을 제공함
- 공격자가 은행을 사칭해 자기 공개키를 제시하는 문제는 **인증서**로 해결함
  - 브라우저에 미리 포함된 인증 기관의 공개키가 서버 신원과 공개키의 결합을 보증함
  - 서버 인증서에서 중간 인증 기관을 거쳐 신뢰된 root까지 서명 체인을 검증함
  - 체인이 root에 도달하지 못하면 브라우저가 전체 화면 보안 경고를 표시함
- Netscape는 1994년 SSL을 만들었고 이후 **TLS**로 표준화됨
  - TLS는 TCP와 HTTP 사이에 위치함
- ## Diffie–Hellman과 세션 키
  - TLS 핸드셰이크에서 브라우저는 `ClientHello`, 지원 암호군, 공개 key share를 보내고 서버는 선택한 암호군·인증서·서명된 key share를 답함
  - 작은 예에서 공개 상수 `g=5`, `p=23`을 사용할 때:
  - 브라우저는 비밀값 `a=6`으로 `A=5⁶ mod 23=8`을 계산함
  - 서버는 비밀값 `b=15`로 `B=5¹⁵ mod 23=19`를 계산함
  - 브라우저는 `19⁶ mod 23=2`, 서버는 `8¹⁵ mod 23=2`를 계산해 같은 세션 키를 얻음
  - 도청자는 `g`, `p`, `A`, `B`를 보지만 실제 크기에서는 이산 로그 문제를 풀어 비밀값을 얻기 어려움
  - 현대 브라우저는 더 작은 수로 동등한 보안을 제공하는 타원곡선 방식의 교환을 사용함
  - 공개키 연산은 모든 바이트에 적용하기에는 느리므로 키 교환에만 쓰고, 이후에는 같은 키로 암복호화하는 빠른 **대칭키**를 사용함
  - HTTPS의 자물쇠는 중간 장치가 통신 상대, 시점, 데이터량은 볼 수 있지만 내용은 읽을 수 없다는 뜻임

### 캡슐화와 VPN
- 각 계층은 위 계층의 데이터를 자기 헤더로 감쌈
  - HTTP 요청은 TLS record 안에, TCP segment 안에, IP packet 안에, Ethernet 또는 Wi-Fi frame 안에 들어감
  - 스위치와 라우터는 각자 필요한 외부 헤더만 처리함
- **VPN**은 애플리케이션 스트림이 아니라 IP 패킷 전체를 암호화하고 VPN 서버 주소를 가진 새 패킷의 페이로드로 넣음
  - ISP는 VPN 서버와 주고받는 암호화 트래픽만 봄
  - 방문 사이트는 사용자 주소 대신 VPN 서버 주소를 봄
  - VPN 운영자는 이전 ISP가 보던 위치를 이어받으므로 보안을 절대적으로 더하기보다 신뢰 지점을 옮김
- VPN의 원래 용도는 원격 노트북을 회사 사설망에 연결해 사무실에 직접 꽂힌 것처럼 동작시키는 것임

### 링크를 클릭할 때 실제로 일어나는 일
1. 브라우저가 `https://en.wikipedia.org`에서 호스트 이름을 추출하고 DNS로 주소를 찾음
2. 얻은 주소의 443번 포트에 TCP 연결을 열고 3-way handshake를 수행함
3. TLS 핸드셰이크에서 인증서 체인을 검증하고 세션 키를 합의함
4. 암호화된 `GET /wiki/Internet` 요청을 보냄
5. 수십 개 IP 패킷으로 온 HTML을 TCP가 재정렬·재전송·재조립하고, TLS가 복호화하며, 브라우저가 해석해 화면에 그림
- ## 단계별 장애 진단
  - 어떤 사이트도 열리지 않으면 Wi-Fi, 라우터, ISP 링크처럼 DNS 이전 구간을 점검함
  - `1.1.1.1` 같은 알려진 주소에 `ping`을 보내 로컬망 밖에 도달하는지 확인할 수 있음
  - 다른 사이트는 되지만 특정 이름이 해결되지 않으면 DNS 캐시나 해당 사이트 레코드 문제임
  - DNS는 성공하지만 TCP 연결이 시간 초과되면 서버나 중간 네트워크 문제이며 `traceroute`로 도달한 홉을 확인함
  - 전체 화면 인증서 경고는 TLS 인증서 체인 검증 실패임
  - 모든 통신이 성공하고 HTTP `500`을 받았다면 요청은 서버까지 온전히 도착했고 서버 내부에서 실패함
  - DNS, TCP, TLS는 콘텐츠 첫 바이트 전에 각각 왕복 지연을 요구하므로 빠른 회선에서도 초기 응답이 느릴 수 있음
- ## 패킷 헤더와 계층별 가시성
  - 예시 요청은 20바이트 IPv4 헤더와 20바이트 TCP 헤더를 가짐
  - IP 헤더에는 전체 길이, 단편화 플래그, TTL, TCP를 뜻하는 프로토콜 번호 6, 체크섬, 출발지·목적지 주소가 들어감
  - TCP 헤더에는 임시 출발지 포트 `54211`, 목적지 포트 `443`, 순서 번호, ACK 번호, 플래그, 창 크기, 체크섬이 들어감
  - 중간 라우터는 IP 헤더만 읽고 20바이트 이후 TCP 정보와 암호화된 페이로드를 열지 않음
  - TLS는 페이로드를 암호화하지만 전달에 필요한 IP·TCP 헤더는 암호화하지 않으므로 통신 대상과 데이터량은 관찰 가능함

### 인터넷의 계층 구조
- 링크·물리 계층의 Ethernet, Wi-Fi, fiber는 한 로컬 매체에서 프레임과 비트를 이동함
- 네트워크 계층의 IP는 독립 네트워크를 가로질러 패킷을 홉 단위로 라우팅함
- 전송 계층의 TCP와 UDP는 프로그램별 전달, 신뢰성 또는 낮은 오버헤드를 제공함
- 보안 계층의 TLS는 회선을 암호화하고 상대를 인증함
- 애플리케이션 계층의 HTTP와 DNS는 문서 요청과 이름 조회라는 사용자 의미를 제공함
- 아래에서 위로 각 계층은 바로 아래 계층의 한계를 감춤
  - 링크 계층은 공유 케이블과 무선 매체의 물리 문제를 감춤
  - IP는 서로 다른 소유자의 네트워크 경계를 감춤
  - TCP는 손실·중복·순서 변경을 감춤
  - TLS는 도청과 변조를 막음
  - HTTP는 전체 과정을 요청과 응답으로 단순화함
- 1984년 OSI 모델은 물리·데이터 링크를 분리하고 세션·표현·애플리케이션을 구분한 7계층을 정의함
  - 실제 인터넷은 먼저 배포된 TCP/IP 구조를 사용했지만, `layer 2` 스위칭, `layer 3` 라우팅, `layer 7` 애플리케이션 인식이라는 OSI 용어는 업계에 남음

### QUIC과 계속 진화하는 인터넷
- 계층은 아래 인터페이스에만 의존하므로 구리선을 광섬유나 Wi-Fi로 바꿔도 애플리케이션을 변경할 필요가 없음
- HTTP/3는 TCP 대신 UDP 위의 **QUIC**으로 신뢰성과 암호화를 함께 구현함
- TCP의 단일 순서화 바이트 스트림에서는 멀티플렉싱된 요청 중 패킷 하나가 손실되면 관련 없는 요청도 뒤에서 대기함
  - QUIC은 요청마다 독립적으로 ACK되는 스트림을 제공해 손실이 해당 스트림만 멈추게 함
- TCP 핸드셰이크 후 TLS 핸드셰이크를 순서대로 수행하면 HTTP 데이터 전에 두 차례 왕복이 필요함
  - QUIC은 전송 설정과 암호화를 하나의 핸드셰이크로 합치고, 기억하는 서버 재방문에서는 추가 왕복 없이 시작할 수 있음
- TCP 연결은 IP·포트 조합에 묶이지만 QUIC은 휴대전화가 Wi-Fi에서 셀룰러로 전환해 주소가 바뀌어도 연결을 유지함
- IP는 포트로 페이로드를 전달할 뿐 내부 프로토콜을 제한하지 않음
  - SSH는 원격 셸, SMTP는 메일, MQTT는 제한된 IoT 장치용 발행·구독, WebRTC는 브라우저 간 직접 음성·영상, 게임 엔진은 오래된 위치 갱신을 버리는 맞춤 UDP 프로토콜을 사용함
  - Google은 QUIC을 Chrome과 자사 서버 사이에 독점 배포한 뒤 IETF가 HTTP/3로 표준화했으며 기존 인터넷 인프라 변경은 필요하지 않았음
- IPv4 주소 고갈 뒤에도 IPv6 전환은 기반 계층 교체 비용 때문에 진행 중이며, 실시간 영상·클라우드 게임·원격 협업은 지연 한계를 계속 압박함
- 저궤도 위성은 왕복 지연에서 해저 케이블과 경쟁하고 있으며, 앞으로의 프로토콜도 현재 애플리케이션이 기존 계층의 한계와 충돌할 때 새로운 절충안을 통해 등장하게 됨

## Comments



### Comment 61675

- Author: neo
- Created: 2026-07-13T06:45:24+09:00
- Points: 1

###### [Hacker News 의견들](https://news.ycombinator.com/item?id=48871470) 
* 비교해 보면 이 글도 **구성이 매우 좋았음**: [https://explained-from-first-principles.com/internet/](<https://explained-from-first-principles.com/internet/>)

* 가이드라인상 이런 칭찬만 남기는 게 실례일 수 있지만, 정말 훌륭한 글이었다. **네트워크가 생겨난 과정과 작동 원리**를 유익하고 짜임새 있게 풀어내면서 흥미로운 이야기로 엮었다  
  LLM이 쓴 글이라는 반응도 있지만, 설령 그렇더라도 상관없다. 좋은 글은 좋은 글이다
  * 첫 번째 애니메이션에는 **메시징 플랫폼을 호스팅하는 서버**도 들어가야 한다. 아니면 해당 예시를 P2P 애플리케이션으로 바꾸는 편이 낫다
  * 아침에 일어나 문득 떠올라 인간이 직접 하이쿠 비슷한 것을 지어봤다  
    “이미 클링온어와 엘프어가 있었다. 이제는 **LLM어**가 생겼다.”

* 내용 자체는 전적으로 저자가 썼을 수 있지만, 본문과 저자의 댓글 문체를 비교하면 **AI로 상당한 수준의 교정**을 거쳤다고 확신한다  
  그게 꼭 나쁘다는 뜻은 아니지만, 이를 알아챈 이들을 편집증적이라고 몰아붙이는 것도 부당하다

* Digital PDP-1이 받은 최초의 대규모 주문은 **ITT의 천공 테이프 메시징 작업**에 투입하기 위한 것이었다: [https://www.eejournal.com/article/gordon-bell-1934-2024-gran...](<https://www.eejournal.com/article/gordon-bell-1934-2024-grandmaster-of-computer-architecture-wizard-of-vax-inventor-of-the-uart-founder-of-the-computer-history-museum/>)

* 부정적인 반응과 균형을 맞추고 싶다. 처음 몇 절만 읽었지만, 단순한 시작점에서 여러 개념이 어떻게 발전했는지 아주 잘 풀어냈다  
  소프트웨어 엔지니어로 일하며 조사와 시행착오를 통해 배운 수많은 개념을 **한 편의 글로 압축**해 놓았다. Faza가 이런 글을 계속 만들어 공유해 주면 좋겠다
  * 우리가 당연하게 여기는 것들이 어떻게 발전했는지 설명하는 것이 이 글들의 목적이었다. 쓰는 동안 나 역시 새로운 내용을 많이 배우고, 이해가 부족했던 부분도 발견했다  
    기존 자료는 기술적 세부 사항에만 집중하거나, 누구나 쉽게 따라오도록 개념을 지나치게 단순화한다고 느꼈다. 그래서 **상세하면서도 따라가기 어렵지 않은 설명**을 시도했다  
    처음에는 글과 도표만 쓸 생각이었지만, 시뮬레이션을 활용하면 훨씬 더 잘 설명할 수 있다는 걸 알게 됐다

* 글의 구성과 표현이 훌륭하며 Bartosz Ciechanowski의 작업이 떠오른다: [https://ciechanow.ski](<https://ciechanow.ski>)  
  본문 안의 **대화형 요소에 사용한 기술 스택**이 무엇인지, 다시 만든다면 다른 기술을 선택할지도 궁금하다
  * 처음에는 대화형 요소를 넣을 계획 없이 Astro 기반 정적 사이트를 만들고 Markdown 파일에 콘텐츠를 작성했다  
    이후 Astro가 사용자 정의 JavaScript 컴포넌트를 삽입할 수 있는 MDX를 지원한다는 걸 알게 됐다. 초기 애니메이션은 순수 JavaScript, SVG, CSS 전환 효과로 구현했지만, 시뮬레이션이 복잡해지면서 **상태 관리를 위해 React**를 사용하기 시작했다

* 여기 있는 비교적 무난한 댓글 두 개가 `[dead]` 처리돼 있다. **봇 댓글**이라면 무엇을 보고 판별할 수 있는지 궁금하다
  * HN의 블로그 글 대부분과 상당수 댓글이 주로 AI로 작성됐다는 느낌이 든다. 다만 익명 인터넷에는 예전부터 이런 요소가 늘 존재했다

* 페이지를 불러온 뒤 **비행기 모드**를 켜면, 이전에 화면에 들어오지 않았던 애니메이션이 재생되지 않는다. 이상한 동작이다
  * 저자다. 기존에는 스크롤해 화면에 들어온 시점에만 시뮬레이션을 내려받았다  
    이제 **페이지 로드 시 모든 시뮬레이션을 다운로드**하고, 화면에 들어올 때 재생하도록 수정해 배포했다

* 여기 반응이 지나치게 부정적이다. 여러 부분을 훑어봤는데 애니메이션은 보기 좋고 글은 읽기 쉬웠으며, 내용도 저품질 생성물이 아니었다  
  **전신의 역사적 배경**이 흥미로웠고 대역폭과 지연 시간의 차이도 세심하게 다뤘다. 다만 글이 너무 길어서 이 내용을 잘 모르는 독자가 끝까지 읽을 가능성은 낮아 보인다
  * 기존 자료가 지나치게 교과서 같거나 너무 개괄적이라고 느껴, 누구나 개념을 자세히 이해하도록 돕고 싶었다. 그래서 좀 더 흥미롭게 설명해 보려 했다
  * 다른 사람을 일축하면 자신이 더 낫다고 느끼기 쉽다. 특히 HN에서는 긴 글을 실제로 읽고 평가해 건설적인 비판을 내놓기까지 시간이 걸리므로, **성급한 반응일수록 부정적이거나 맥락에서 벗어나는** 경향이 있다