라우팅
목적지 표시를 보고 어디로 넘길지 고르는 일입니다. 갈 수 있는 곳이 여럿일 때 생기는 판단입니다. 무엇을 보고 고르는지는 자리마다 다릅니다.
상세
동네에 새 길이 뚫리거나 다리가 막히면 갈림길마다 서 있는 표지판을 누군가 고쳐 답니다. 운전자는 그 표지판이 가리키는 대로 바로 앞 갈림길에서 한 번 꺾을 뿐입니다. 표지판을 맞춰 세워 두는 그 손이 길을 정하는 쪽입니다.
라우팅은 목적지 표시와 갈 수 있는 곳들 사이의 대응을 세워 두고, 들어온 건마다 그 대응에 따라 다음으로 넘길 곳 하나를 정하는 일입니다. 라우팅이라는 말은 넘기는 동작이 아니라 고르는 일에 붙습니다. 재료가 셋입니다. 무엇을 보고 고르는지, 후보가 무엇인지, 고른 결과가 무엇인지입니다.
flowchart TD
A["목적지 표시"] --> B{"후보 목록과 대조"}
B -->|맞는 항목| C["다음으로 넘길 곳 하나"]
B -->|맞는 항목 없음| D["기본 후보 또는 버림"]
첫째 재료인 목적지 표시는 보낸 쪽이 붙여 놓은 값입니다. 고르는 쪽은 이 값을 읽기만 하고 바꾸지 않습니다. 둘째 재료인 후보 목록은 고르는 쪽이 들고 있는 표입니다. 셋째인 고른 결과는 최종 목적지가 아니라 바로 다음 자리 하나입니다.
RFC(Request for Comments) 1122 는 IP(Internet Protocol, 인터넷 규약) 레이어가 자신이 보내는 데이터그램마다 올바른 다음 홉을 고른다고 적습니다. 목적지가 연결된 네트워크 위에 있으면 목적지 호스트로 곧바로 보내고, 그렇지 않으면 연결된 네트워크에 있는 게이트웨이로 보내야 한다고 적습니다. 로컬인지 원격인지를 가르는 절차도 못 박아 두었습니다. 주소 마스크로 목적지 주소에서 뽑은 비트와 출발지 주소에서 뽑은 비트가 서로 맞으면 그 목적지는 연결된 네트워크 위에 있고, 맞지 않으면 게이트웨이를 거쳐야만 닿습니다.
한 번에 한 걸음만 정해진다는 것이 여기서 따라옵니다. 고르는 쪽은 전체 경로를 들고 있지 않습니다. 자기 표에 적힌 다음 자리 하나만 압니다.
층이 달라도 재료 셋은 같습니다. 인터넷에서는 목적지 주소가 표시 자리를 맡고 경로표가 후보 목록을 맡습니다. 요청을 받는 자리에서는 요청 경로와 메서드가 표시가 되고 등록해 둔 경로 패턴이 후보가 됩니다. 메시지를 나르는 자리에서는 라우팅 키가 표시가 되고 큐에 걸어 둔 바인딩이 후보가 됩니다.
배경
보내는 쪽이 모든 목적지로 가는 길을 다 알고 있을 수는 없습니다. 그 길은 계속 바뀌기까지 합니다. RFC 1812 는 라우팅이 복잡하고 어려운 문제라 호스트가 아니라 라우터가 수행해야 한다고 적습니다. 같은 대목이 중요한 목표 하나를 덧붙입니다. 인터넷 라우팅 구조가 피할 수 없이 바뀌면서 생기는 변화로부터 호스트 소프트웨어를 떼어 놓는 것입니다.
그래서 보내는 쪽에는 최소한만 남깁니다. RFC 1122 는 같은 목적지로 데이터그램을 여러 개 효율적으로 보내려면 출발지 호스트가 다음 홉 게이트웨이로 가는 대응을 담은 경로 캐시를 반드시 유지해야 한다고 적습니다. 그리고 이 캐시를 쓰는 절차가 주된 라우팅 부담을 게이트웨이 쪽에 두도록 설계됐다고 밝힙니다. 캐시에 그 목적지 정보가 없으면 호스트는 기본 게이트웨이를 골라 보냅니다. 그 게이트웨이가 최선의 다음 홉이 아니면 게이트웨이가 최선의 다음 홉 게이트웨이로 대신 넘깁니다. 그리고 출발지 호스트에 ICMP(Internet Control Message Protocol, 인터넷 제어 메시지 규약) 리다이렉트 메시지를 돌려줍니다.
이름은 표를 만드는 쪽에서 왔습니다. RFC 1812 는 라우터라는 말이 이 경로 데이터베이스를 짓는 과정에서 나왔다고 적습니다. 그리고 라우팅 프로토콜과 설정이 맞물려 도는 그 과정을 라우팅이라 부른다고 적습니다.
예시
Django URL 디스패처
path("articles/<int:year>/", views.year_archive)
Django 공식 문서는 요청이 들어오면 먼저 루트 URLconf 모듈을 정하고, 그 모듈에서 urlpatterns 변수를 찾는다고 적습니다. 그 다음 URL 패턴을 적힌 순서대로 훑다가 요청 URL(Uniform Resource Locator, 통합 자원 위치 지정자) 과 처음 맞는 것에서 멈춥니다. 맞는 패턴을 찾으면 그 패턴이 가리키는 뷰를 불러옵니다. 위 한 줄에서 표시는 요청 경로이고, 후보 목록은 urlpatterns 이고, 고른 결과는 year_archive 뷰입니다.
Express 라우트
app.get('/about', (req, res) => { res.send('about'); });
Express 공식 안내서는 애플리케이션의 끝점이 클라이언트 요청에 어떻게 응답하는지를 라우팅이라고 부릅니다. HTTP(HyperText Transfer Protocol, 하이퍼텍스트 전송 규약) 메서드에 대응하는 app 객체의 메서드로 라우팅을 정의합니다. GET 요청은 app.get() 이 받고 POST 요청은 app.post 가 받습니다. 여기서는 표시가 경로 하나가 아니라 메서드와 경로 둘입니다.
RabbitMQ direct 익스체인지
channel.exchange_declare(exchange='direct_logs', exchange_type='direct')
channel.basic_publish(exchange='direct_logs', routing_key=severity, body=message)
RabbitMQ 공식 튜토리얼은 direct 익스체인지 x 에 큐 둘이 묶인 구성을 보입니다. 첫 큐는 바인딩 키 orange 로 묶였고 둘째 큐는 black 과 green 두 개로 묶였습니다. 이 구성에서 라우팅 키 orange 로 발행한 메시지는 첫 큐로 갑니다. black 이나 green 이면 둘째 큐로 갑니다. 나머지 메시지는 전부 버려집니다. 표시가 메시지에 붙은 라우팅 키이고, 후보 목록이 큐마다 걸어 둔 바인딩 키입니다.
Kubernetes 인그레스
rules:
- http:
paths:
- path: /testpath
pathType: Prefix
backend:
service:
name: test
port:
number: 80
Kubernetes 공식 문서는 인그레스를 클러스터 안의 서비스로 들어오는 외부 접근을 관리하는 API(Application Programming Interface, 응용 프로그램 인터페이스) 오브젝트라고 적습니다. 경로 목록을 두고 경로마다 service.name 과 포트를 붙입니다. 들어오는 요청의 호스트와 경로가 둘 다 맞아야 로드 밸런서가 그 서비스로 트래픽을 넘깁니다. 표시가 호스트와 경로 두 값이고, 고른 결과가 백엔드 서비스입니다.
리눅스 경로표
ip route add default via 192.168.1.1 dev eth0
ip-route(8) 매뉴얼 페이지가 예제로 싣고 있는 한 줄입니다. 모든 주소를 받는 기본 경로를 더합니다.
다음 홉은 로컬 게이트웨이 192.168.1.1 이고, 그 게이트웨이에는 eth0 장치로 닿습니다. 경로표에
적히는 것이 목적지 조건과 다음 홉과 나가는 인터페이스라는 것이 이 한 줄에 다 들어 있습니다.
경계
경로표를 보고 이 패킷을 이 인터페이스로 내보내는 그 한 번의 동작도 라우팅인가. RFC 1812 의 어휘로는 아닙니다.
RFC 1812 는 IP 데이터그램을 넘기는 일이 일반적으로 라우터에게 다음 홉 라우터의 주소와 그에 해당하는 인터페이스를 고르게 만든다고 적습니다. 마지막 홉이면 다음 홉 라우터 대신 목적지 호스트를 고른다고 덧붙입니다. 그리고 그 고르는 일을 릴레이 또는 포워딩이라고 부른다고 적습니다. 라우팅이라는 말은 같은 문단에서 다른 자리에 붙습니다. 라우팅 프로토콜과 설정이 맞물려 그 판단이 기대는 경로 데이터베이스를 채워 나가는 과정입니다.
flowchart TD
subgraph 라우팅
P["라우팅 프로토콜과 설정"] --> T["경로 데이터베이스"]
end
subgraph 포워딩
F["다음 홉 선택"] --> O["인터페이스로 내보냄"]
end
T --> F
문서의 짜임 자체가 이 선을 따릅니다. RFC 1812 는 포워딩을 인터넷 레이어를 다루는 5장에 두고, 라우팅 프로토콜을 응용 레이어를 다루는 7장에 둡니다. 5장 도입부는 이 절이 패킷을 포워딩하는 과정을 설명한다고만 적습니다.
선이 흐려지는 자리도 같은 문서에 적혀 있습니다. RFC 1812 는 그 경로 데이터베이스를 라우팅 테이블이라고도 부르고 포워딩 테이블이라고도 부른다고 적습니다. RFC 1122 는 게이트웨이로 보내는 동작 자체에 route 를 동사로 씁니다. 이름은 이렇게 섞입니다. 가르는 기준은 하나입니다. 한 건을 처리하는 쪽인가, 그 처리가 들여다볼 표를 만드는 쪽인가입니다.
관련 항목
라우팅을 규정하는 표준과 프로토콜
RFC · IP · 라우팅 프로토콜 · BGP · OSPF · RIP · IGP · EGP
라우팅 판단을 이루는 구성 요소
경로표 · 다음 홉 · 게이트웨이 · 기본 게이트웨이 · 자율 시스템 · 최장 프리픽스 매치
라우팅의 하위 종류
직접 라우팅 · 간접 라우팅 · 정적 라우팅 · 동적 라우팅
포워딩 단계에서 함께 나오는 개념
포워딩 · ICMP · ICMP 리다이렉트 · TTL · 라우팅 루프 · traceroute
목적지 표시로 쓰이는 주소 형식
IP 주소 · IPv4 · IPv6 · 서브넷 · 서브넷 마스크 · 프리픽스 · 네트워크 · 데이터그램
요청을 목적지로 넘기는 구성 요소
URL · URL 디스패처 · 경로 패턴 · 미들웨어 · 리버스 프록시 · 인그레스 · 로드밸런싱 · 로드 밸런서 · 백엔드
URL 라우팅에 적용되는 설계 규칙
API · API 설계 · REST · HTTP · HTTP 메서드 · GET · POST
라우팅을 실제로 구현하는 프레임워크와 플랫폼
Django · Express · RabbitMQ · Kubernetes · 리눅스
메시지 브로커가 라우팅에 쓰는 개념
익스체인지 · 라우팅 키 · 바인딩 키 · 메시지 큐 · 발행-구독
다른 이름: routing · 경로 선택