핵심 인사이트 (3줄 요약)

  1. 본질: DQDB(Distributed Queue Dual Bus, 분산 큐 이중 버스)는 1990년대 도시 전체를 묶는 도시권 통신망(MAN, Metropolitan Area Network)을 구축하기 위해 IEEE 802.6 위원회가 제정한 이중 버스 기반의 초고속 광통신망 표준이다.
  2. 기술적 특징: 이더넷의 충돌(CSMA/CD)이나 토큰 링의 대기 지연(Token Passing) 문제를 모두 해결하기 위해, 서로 반대 방향으로 흐르는 두 개의 뻥 뚫린 광케이블 버스(Dual Bus)에 미리 예약표(Queue)를 뽑고 데이터를 싣는 독특한 '분산 큐잉' 알고리즘을 사용한다.
  3. 역사적 한계: B-ISDN과 ATM의 등장으로, 통신망의 트렌드가 고정된 53바이트 셀 기반의 완벽한 융합망으로 넘어가면서, 이도 저도 아닌 과도기적 기술이었던 DQDB는 거의 상용화되지 못하고 역사 속으로 빠르게 퇴장했다.

Ⅰ. 개요 및 필요성 (Context & Necessity)

  • 개념: 최대 50km 반경(도시 크기)의 노드들을 150Mbps 이상의 고속으로 연결하는 MAN 규격 프로토콜. 슬롯(Slot) 단위로 데이터를 잘라서 전송한다.

  • 필요성:

    • LAN(근거리 망)은 거리가 너무 짧았고, WAN(광역 망)인 X.25 전용선은 너무 느리고 비쌌다. "서울시 전체, 부산시 전체에 있는 대학과 관공서를 하나로 묶어주는 적당한 거리(50km)의 고속 광통신망을 만들자!"라는 도시권 망(MAN)의 수요가 생겼다.
    • FDDI(이중 링)를 쓰자니 수십 km짜리 링을 완벽히 둥글게 공사하는 게 너무 빡셌다. "그냥 곧게 쭉 뻗은 선 2개(Dual Bus)를 쫙 깔고 양방향 통신을 시키자!"라는 버스 토폴로지 기반의 DQDB가 탄생했다.

  • 💡 비유: 이더넷이 "건물 내 복도", X.25가 **"도시 간 고속도로"**라면, DQDB는 서울시 내부의 주요 구청과 대학교들만을 뺑뺑 돌며 짐을 실어 나르는 **"수도권 광역 순환 급행 버스(MAN)"**를 만들기 위한 도로 설계도였습니다.

📢 섹션 요약 비유: DQDB는 양방향 통행이 불가능해 툭하면 사고가 나던 1차선 좁은 버스(Bus) 망에, 서로 반대 방향으로 질주하는 **"상행선/하행선 두 개의 거대한 컨베이어 벨트(Dual Bus)"**를 깔아 도시 전체의 택배를 해결하려 했던 물류 시스템입니다.

Ⅱ. 듀얼 버스와 분산 큐(Distributed Queue)의 원리 (Deep Dive)

1. 토폴로지: 끊어진 링 (Dual Bus)

DQDB는 물리적으로 버스 A와 버스 B, 두 개의 단방향 광케이블로 이루어진다.

  • Bus A (상행선): 왼쪽 끝(헤드)에서 오른쪽으로 끊임없이 빈 상자(슬롯)를 만들어 뿜어낸다.
  • Bus B (하행선): 오른쪽 끝에서 왼쪽으로 빈 상자를 만들어 뿜어낸다.
  • 모든 스위치(노드)는 이 두 선에 동시에 걸쳐 있다. 만약 노드 2가 자기보다 오른쪽에 있는 노드 4에게 데이터를 보내려면 Bus A를 타고, 왼쪽에 있는 노드 1에게 보내려면 Bus B를 타면 된다. 방향이 명확하여 충돌(Collision)이 0%다.

2. 기가 막힌 예약 시스템: 분산 큐(Distributed Queue) 알고리즘

토큰 링처럼 토큰이 올 때까지 멍하니 기다릴 필요가 없다. 만약 노드 3이 오른쪽 노드 5에게 데이터를 보내려 한다고 치자 (Bus A 사용).

  1. 노드 3은 무작정 Bus A의 빈 상자에 물건을 싣지 않는다. 내 오른쪽(노드 4, 5) 애들이 먼저 싣겠다고 예약해 둔 물건이 있을 수 있기 때문이다.
  2. 그래서 노드 3은 반대쪽으로 흘러가는 Bus B에다가 "나 상행선(Bus A)에 짐 하나 실을 거다!"라고 예약증(Request Bit=1)을 써서 던진다.
  3. 내 왼쪽에 있는 노드 1, 2는 Bus B를 타고 오는 예약증을 읽고, "아, 오른쪽에 있는 3번 녀석이 짐 실을 게 있구나! 그럼 내가 뿜어내는 상행선(Bus A) 빈 상자 중 하나는 3번을 위해 쓰지 말고 통과시켜 줘야겠다!"라고 속으로 카운트(Queue 카운터)를 올린다.
  4. 노드 1, 2가 양보해서 흘려보내 준 빈 상자가 노드 3에 도착하면, 그때 노드 3이 짐을 싣는다.
 ┌─────────────────────────────────────────────────────────────┐
 │               DQDB 분산 큐 (상행선 짐 싣기 예약 과정)           │
 ├─────────────────────────────────────────────────────────────┤
 │                                                             │
 │   [노드 1]        [노드 2]        [노드 3]        [노드 4]       │
 │                                    │ 나 짐 실을래! (오른쪽으로)  │
 │                                    ▼                        │
 │  ======================= Bus A (상행선 빈 상자 뿜뿜) =====▶    │
 │                                    │                        │
 │  ◀======== Bus B (하행선, 여기에 "예약증" 던짐) ===========    │
 │     ▲               ▲             │                        │
 │     │ (예약증 확인)   │ (예약증 확인) ┘                        │
 │   "아! 밑에 애가 짐 싣는다네. 빈 상자 하나 안 건드리고 패스해줄게!"     │
 │                                                             │
 │   * 핵심: 통제하는 중앙 서버 없이, 양방향으로 예약증을 날려 서로       │
 │     양보하는 '분산(Distributed)' 대기열(Queue) 시스템.          │
 └─────────────────────────────────────────────────────────────┘

3. DQDB의 몰락

이 천재적인 예약 시스템은, 데이터를 53바이트(헤더 5+페이로드 48) 단위의 슬롯으로 잘라 보낸다. (어디서 많이 보지 않았는가? 바로 ATM 셀 규격과 100% 동일하다). DQDB 위원회는 B-ISDN(ATM)과의 호환성을 위해 이 규격을 맞췄지만, 정작 통신사들은 "어차피 ATM 셀 규격 쓸 거면, 뭐하러 복잡하게 버스망 예약 시스템을 까냐? 그냥 처음부터 끝까지 ATM 스위치로 다 깔아버리자!"라며 망을 넘어가 버렸고, DQDB는 상용화 직전에 사장되었다.

📢 섹션 요약 비유: DQDB의 분산 큐는 회전초밥집에서 **"나 연어초밥 먹을 거니까 주방장(상류)님! 내 앞사람들이 다 먹어 치우지 못하게 연어초밥 하나만 따로 빼서 흘려보내 주세요!"**라고 반대편 레일로 쪽지를 날리는 극강의 민주적 컨베이어 벨트 시스템이었습니다.