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

 (fazamhd.com)
3P by GN⁺ | ★ favorite | 댓글 1개
  • 인터넷은 음성·영상·문자를 전기·빛·전파의 패턴으로 바꿔 여러 독립 사업자의 장비를 통과시키며, 중앙 통제자나 전체 경로를 아는 단일 주체 없이 각 홉의 로컬 판단만으로 데이터를 전달함
  • 전신의 디지털 재생, 전화망의 회선 교환, 패킷 교환, 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을 보냄
      1. 서버가 SYN-ACK, seq=9000, ack=5001로 응답함
      1. 클라이언트가 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 전환은 기반 계층 교체 비용 때문에 진행 중이며, 실시간 영상·클라우드 게임·원격 협업은 지연 한계를 계속 압박함
  • 저궤도 위성은 왕복 지연에서 해저 케이블과 경쟁하고 있으며, 앞으로의 프로토콜도 현재 애플리케이션이 기존 계층의 한계와 충돌할 때 새로운 절충안을 통해 등장하게 됨

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 비교해 보면 이 글도 구성이 매우 좋았음: 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...

  • 부정적인 반응과 균형을 맞추고 싶다. 처음 몇 절만 읽었지만, 단순한 시작점에서 여러 개념이 어떻게 발전했는지 아주 잘 풀어냈다
    소프트웨어 엔지니어로 일하며 조사와 시행착오를 통해 배운 수많은 개념을 한 편의 글로 압축해 놓았다. Faza가 이런 글을 계속 만들어 공유해 주면 좋겠다

    • 우리가 당연하게 여기는 것들이 어떻게 발전했는지 설명하는 것이 이 글들의 목적이었다. 쓰는 동안 나 역시 새로운 내용을 많이 배우고, 이해가 부족했던 부분도 발견했다
      기존 자료는 기술적 세부 사항에만 집중하거나, 누구나 쉽게 따라오도록 개념을 지나치게 단순화한다고 느꼈다. 그래서 상세하면서도 따라가기 어렵지 않은 설명을 시도했다
      처음에는 글과 도표만 쓸 생각이었지만, 시뮬레이션을 활용하면 훨씬 더 잘 설명할 수 있다는 걸 알게 됐다

  • 글의 구성과 표현이 훌륭하며 Bartosz Ciechanowski의 작업이 떠오른다: https://ciechanow.ski
    본문 안의 대화형 요소에 사용한 기술 스택이 무엇인지, 다시 만든다면 다른 기술을 선택할지도 궁금하다

    • 처음에는 대화형 요소를 넣을 계획 없이 Astro 기반 정적 사이트를 만들고 Markdown 파일에 콘텐츠를 작성했다
      이후 Astro가 사용자 정의 JavaScript 컴포넌트를 삽입할 수 있는 MDX를 지원한다는 걸 알게 됐다. 초기 애니메이션은 순수 JavaScript, SVG, CSS 전환 효과로 구현했지만, 시뮬레이션이 복잡해지면서 상태 관리를 위해 React를 사용하기 시작했다

  • 여기 있는 비교적 무난한 댓글 두 개가 [dead] 처리돼 있다. 봇 댓글이라면 무엇을 보고 판별할 수 있는지 궁금하다

    • HN의 블로그 글 대부분과 상당수 댓글이 주로 AI로 작성됐다는 느낌이 든다. 다만 익명 인터넷에는 예전부터 이런 요소가 늘 존재했다

  • 페이지를 불러온 뒤 비행기 모드를 켜면, 이전에 화면에 들어오지 않았던 애니메이션이 재생되지 않는다. 이상한 동작이다

    • 저자다. 기존에는 스크롤해 화면에 들어온 시점에만 시뮬레이션을 내려받았다
      이제 페이지 로드 시 모든 시뮬레이션을 다운로드하고, 화면에 들어올 때 재생하도록 수정해 배포했다

  • 여기 반응이 지나치게 부정적이다. 여러 부분을 훑어봤는데 애니메이션은 보기 좋고 글은 읽기 쉬웠으며, 내용도 저품질 생성물이 아니었다
    전신의 역사적 배경이 흥미로웠고 대역폭과 지연 시간의 차이도 세심하게 다뤘다. 다만 글이 너무 길어서 이 내용을 잘 모르는 독자가 끝까지 읽을 가능성은 낮아 보인다

    • 기존 자료가 지나치게 교과서 같거나 너무 개괄적이라고 느껴, 누구나 개념을 자세히 이해하도록 돕고 싶었다. 그래서 좀 더 흥미롭게 설명해 보려 했다
    • 다른 사람을 일축하면 자신이 더 낫다고 느끼기 쉽다. 특히 HN에서는 긴 글을 실제로 읽고 평가해 건설적인 비판을 내놓기까지 시간이 걸리므로, 성급한 반응일수록 부정적이거나 맥락에서 벗어나는 경향이 있다
답변달기