[데이터 통신] 데이터 링크 제어(Data Link Control)
데이터 링크 제어
컴퓨터 네트워크에서 데이터가 한 노드에서 다른 노드로 전송되기 위해서는 다양한 계층의 협업이 필요하다. 이 중 데이터링크 계층(Data Link Layer)은 바로 두 인접 노드 간의 신뢰성 있는 데이터 전송을 담당하는 중요한 역할을 한다. 이 계층의 하위에 존재하는 Data Link Control(DLC) 서브레이어는 실제 전송 과정을 세밀하게 제어하며, 프레이밍(framing), 흐름 제어(flow control), 오류 제어(error control) 같은 핵심 기능을 수행한다.
Data Link Control(DLC) Services
프레이밍(Framing)
네트워크에서 데이터는 결국 비트의 나열로 전송되지만, 이러한 비트들을 단순히 연속해서 보낸다면 수신 측에서는 어디서부터 어디까지나 하나의 데이터 단위인지 알기 어렵다. 이를 해결하기 위해 사용하는 기법이 바로 프레이밍(framing)이다.
프레이밍은 데이터를 일정한 단위로 나누어 프레임(Frame)이라는 구조로 전송하며, 각 프레임은 시작과 끝을 명확히 구분할 수 있어야 한다. 또한, 송신자 주소와 수신자 주소를 포함하여 정확한 목적지로 데이터를 전달하고, 수신 측이 송신자를 식별해 응답할 수 있도록 한다.
프레이밍 방식에는 크게 두 가지가 있다.
- 문자 기반 프레이밍(Character-Oriented) : 제어 문자를 이용해 프레임의 시작과 끝을 표시한다. 단점으로는 데이터에 제어 문자가 포함될 경우 혼란이 발생할 수 있어 Byte Stuffing(바이트 삽입) 기법을 사용한다.
- 비트 기반 프레이밍(Bit-Oriented) : 비트 패턴을 기준으로 프레임을 정의한다. 제어 비트와 같은 패턴이 데이터에 포함될 수 있어 Bit Stuffing(비트 삽입) 기법을 사용하여 구분한다.
이처럼 프레이밍은 단순히 데이터를 “포장”하는 것이 아니라, 정확하고 혼동 없는 전송을 위한 구조화 작업이라 할 수 있다.
흐름 제어(Flow Control) & 오류 제어(Error Control)
데이터 전송 시 발생할 수 있는 문제 중 하나는 송신자와 수신자의 속도 차이이다. 송신자가 너무 빠르게 데이터를 보내면, 수신자의 버퍼가 가득 차 손실이 발생할 수 있다. 이를 방지하기 위한 방법이 바로 흐름 제어(Flow Control)이다.
예를 들어, 수신자가 한 번에 한 프레임만 받을 수 있다면, 해당 프레임을 처리하고 비어 있다고 신호를 보낸 후에야 송신자는 다음 프레임을 전송할 수 있다. 이러한 간단한 제어 방식은 Stop-and-Wait 프로토콜에서 볼 수 있다.
또한, 전송 과정에서 신호 간섭 등으로 인해 비트가 손상되거나 바뀔 수 있기 때문에, DLC는 오류 제어(Error Control)도 담당한다.
오류 제어는 주로 다음과 같은 기법을 사용한다.
- 패리티 검사
- 체크섬(CheckSum)
- 순방향 오류 수정(FEC)
- ARQ(Automatic Repeat reQuest, 자동 재전송 요청)
오류 제어는 수신자가 잘못된 데이터를 감지했을 때 정정하거나 재전송 요청을 보낼 수 있게 함으로써, 데이터의 정확성을 보장한다.
연결 설정 방식(Connection)
DLC 프로토콜은 데이터를 어떤 방식으로 전송하느냐에 따라 비연결형(connectionless) 또는 연결 지향형(connection-oriented)으로 나뉜다.
- 비연결형(Connectionless) 프로토콜
- 각 프레임은 독립적으로 전송되며, 다른 프레임들과의 관계가 없다.
- 프레임 간에 순서 번호가 없으며, 전송 순서를 보장하지 않는다.
- 주로 LAN에서 사용되는 프로토콜들이 여기에 속한다.(예: Ethernet, Wi-Fi etc)
- 연결 지향형(connection-oriented) 프로토콜
- 송수신 간 연결을 설정한 뒤, 순서 있게 프레임을 전송한다.
- 오류 제어나 재전송, 순서 보장이 필수적이다.
- 예: HDLC, PPP
Data-Link Layer Protocols
데이터 링크 계층의 흐름 제어와 오류 제어를 위한 핵심 프로토콜들
데이터링크 계층에서는 안정적인 데이터 전송을 위해 여러 제어 프로토콜이 사용된다. 전통적으로 이 계층에서는 네 가지 주요 프로토콜이 정의되어 있다.( Simple Protocol, Stop-and-Wait, Go-Back-N, Selective Repeat )
하지만 현재는 주로 Simple과 Stop-and-Wait 프로토콜이 사용되며, 나머지 두 개는 고급 전송 프로토콜(슬라이딩 윈도우 기반)에 통합되어 사용되기 때문에 본 장에서는 간단한 두 프로토콜만을 중심으로 설명한다.
Simple Protocol - 기본 구조만 존재하는 가장 단순한 프로토콜
Simple Protocol은 흐름 제어와 오류 제어 기능이 전혀 없는 가장 기초적인 형태의 데이터 전송 프로토콜이다. 이 프로토콜은 수신자가 무한히 빠르며, 어떤 프레임도 손실되지 않는다는 전제를 기반으로 한다.
즉, 송신자는 생각 없이 프레임을 계속 전송하고, 수신자는 그 모든 프레임을 즉시 처리할 수 있다고 가정한다. 이론적으로는 문제없이 작동하지만, 현실에서는 매우 제한적인 상황에서만 사용될 수 있다.
- 특징 요약
- 흐름 제어 없음 -> 수신자가 느려도 송신자는 계속 전송
- 오류 제어 없음 -> 손실이나 오류 발생 시 복구 불가
- 실시간 데이터 스트림(오디오 등)에서의 실험적 전송 방식에 가까움
Stop-and-Wait Protocol - 흐름 제어 + 오류 제어가 포함된 단방향 신뢰성 전송 프로토콜
Simple Protoco의 단점을 보완한 것이 바로 Stop-and-Wait Protocol이다. 이 프로토콜은 프레임을 하나씩 전송한 후, 그에 대한 수신자의 확인 응답(ACK)을 기다린다. 응답을 받은 후에야 다음 프레임을 전송하는 구조이므로 흐름 제어가 자연스럽게 적용된다.
또한, 오류 제어를 위해 각 프레임에는 CRC(Cyclic Redundancy Check) 코드가 포함되며, 오류가 감지되면 해당 프레임을 재전송하는 방식으로 복구를 수행한다.
- 동작 예시
- 첫 번째 프레임 전송 -> ACK 수신 -> 다음 프레임 전송
- 두 번째 프레임 전송 -> 손실됨 -> 타임아웃 발생 -> 재전송
- 세 번째 프레임 전송 -> ACK 손실됨 -> 송신자는 중복 재전송 -> 수신자는 같은 프레임을 두 번 수신하게 되어 중복 문제 발생
이처러 ACK의 손실이 반복 전송을 야기하고, 이는 중복 데이터 전송 문제를 초래할 수 있다. 이를 해결하기 위해 시퀀스 번호(sequence number)와 확인 응답 번호(acknoledgment)를 도입한다.
오류 제어 방식 보완: FEC vs BEC
- Forward Error Control(FEC, 순방향 오류 제어)
- 수신자가 자체적으로 오류를 감지하고 수정함
- 재전송 없이 바로 처리 가능(ex. 해밍 코드, 다항식 코드)
- Backward Error Control(BEC, 역방향 오류 제어)
- 오류 발생 시 수신자가 송신자에게 재전송 요청
- 대표적인 방식 : ARQ(Automatic Repeat reQuest)
- ARQ의 세 가지 주요 방식
- Stop-and-Wait ARQ -> 간단하지만 효율이 낮다.
- Go-Back-N ARQ -> 연속된 여러 프레임을 전송, 오류 발생 시 해당 이후 모든 프레임 재전송
- Selective Repeat ARQ -> 오류 발생 프레임만 골라서 재전송, 성능은 높지만 구현이 복잡
Piggybacking - 양방향 통신의 효율성을 높이는 전략
앞서 설명한 프로토콜들은 기본적으로 단방향 데이터 흐름(unidirectional communication)을 가정한다. 즉, 한 방향으로는 데이터, 반대 방향으로는 ACK만 흐른다. 하지만 실제 통신에서는 데이터가 양뱡향으로 오갈 수 있기 때문에, 효율성을 높이기 위한 기법이 필요하다. 그 중 대표적인 것이 Piggybacking(핑기백킹)이다.
- Piggybacking?
- 한 방향으로 가는 데이터 프레임에 반대 방향의 ACK 정보를 덧붙여 전송
- ACK를 별도로 보내지 않아도 되므로 통신 효율 상승
- 패킷 수 감소 -> 네트워크 혼잡도 완화
HDLC(High-level Data Link Control) - 비트 지향 고급 데이터링크 제어 프로토콜
HDLC는 비트 지향(Bit-oriented) 데이터 링크 제어 프로토콜로, Point-to-Point 또는 Multipoint 링크에서 신뢰성 있는 데이터 전송을 보장하기 위해 설계되었다. 이 프로토콜은 앞에서 배운 Stop-and-Wait 구조를 기반으로 하지만, 그보다 더 유연하고 강력한 기능을 제공한다.
비록 실무에서는 HDLC 자체보다 이를 기반으로 한 PPP(Point-to-Point Protocol), Ethernet, Wi-Fi와 같은 실질적인 프로토콜이 더 자주 사용되지만, HDLC의 개념과 구조는 이들 모든 프로토콜의 기초가 된다.
(보완) 문자 지향 BSC vs 비트 지향 HDLC
BSC는 전송 제어 문자를 이용하여 동기화를 수행하지만, HDLC는 고정된 비트 패턴을 사용하여 보다 세밀하고 유연한 동기화 및 제어를 지원하다.
Transfer Modes - 전송 모드
HDLC는 다양한 통신 환경에 적응할 수 있도록 여러 가지 전송 모드(Transfer Mode)를 정의하고 있다. 그중 대표적인 두 가지는 다음과 같다.
- Normal Response Mode(NRM)
- 주종 구조(Master-Slave) 기반으로 작동
- 주국(primary station)은 명령만 내리고, 종국(secondary station)은 응답만 수행
- 주로 Multipoint 환경에서 사용
- Asynchronous Balanced Mode(ABM)
- 양방향 통신(peer-to-peer)을 위한 전송 모드
- 두 노드가 모두 동등하게 데이터를 송ㅅ신할 수 있다.
- 현대의 대부분 HDLC 기반 프로토콜에서 사용하는 방식
이러한 모드들은 HDLC가 다양한 구성(topology)에서 유연하게 동작할 수 있게 해준다.
Framing - 프레임 구조
HDLC는 전송 상황에 맞추어 세가지 유형의 프레임을 사용한다. 각 프레임은 특정한 목적과 기능을 가지며, 제어 필드를 통해 이를 구분한다.
FCS(Frame Check Sequence)는 수신 측에서 오류가 발생했는지 판단하는 데 사용되며, CRC(Cyclic Redundancy Check) 알고리즘을 기반으로 계산된다.
- HDLC 프레임의 3가지 종류
- I-frame(Information Frame)
- 사용자 데이터 전송에 사용
- 프레임 번호와 ACK 정보 포함
- 오류 제어나 흐름 제어 정보도 담김
- S-frame(Supervisiory Frame)
- 데이터 없음, 제어 메시지 전송용
- 오류 탐지, 흐름 제어용 ACK/NAK 전송
- U-frame(Unnumbered Frame)
- 연결 설정/해제, 명령 제어 등에 사용
- 비연속적인 제어 정보 전달
- I-frame(Information Frame)
예제: 연결 설정과 종료
두 노드 간 연결을 설정할 때는 U-frame을 사용한다.
- Node A -> Node B : SABM (Set Asynchronous Balanced Mode) 전송
- Node B -> Node A : UA (Unnumbered Acknowledgemet) 응답
- 연결 종료 시 : Node A가 DISC(Disconnect) 프레임 전송 -> Node B는 UA로 응답
이러한 방식은 HDLC가 논리적인 연결 설정 및 해제를 지원함을 보여준다.
예제: Piggybacking 활용
Piggybacking은 앞서 설명한 것처럼 데이터 프레임에 ACK 정보를 함께 실어 보내는 방식이다. HDLC 프레임은 이 구조를 효율적으로 지원한다.
- 정상 상황 : 송신자는 다음 프레임과 함께 지난 프레임의 ACK를 실어 보냄
- 오류 상황 : 수신자가 오류가 발생한 프레임을 탐지하고 일부 프레임을 무시, ACK도 누락됨
Piggybacking은 양방향 데이터 통신의 효율을 높이는 전략으로, HDLC 구조에서 자연스럽게 지원된다.
PPP (Point-to-Point Protocol) - 가장 널리 사용되는 포인트 투 포인트 통신용 데이터 링크 프로토콜
PPP는 오늘날 인터넷 사용자들이 가정용 컴퓨터와 ISP(인터넷 서비스 제공자) 서버 간의 접속을 위해 가장 흔히 사용하는 포인트 투 포인트(Point-to-Point) 통신용 데이터링크 계층 프로토콜이다. 전화선, 케이블 모뎀, 광대역, DSL 등 다양한 물리 매체를 통해 두 노드 간 직접 연결이 필요할 때 사용되며, 매우 단순하면서도 유연한 구조를 가지고 있어 널리 활용되고 있다.
PPP는 전송을 관리하고 제어할 수 있도록 다양한 기능을 제공하면서도, 설계 목적상 일부 전통적인 데이터 링크 계층의 기능은 제외하여 단순성과 범용성을 동시에 확보했다.
PPP의 주요 서비스
PPP는 다음과 같은 기능을 제공하여 간단하면서도 실용적인 연결 환경을 제공한다:
-
프레이밍 기능 : 데이터의 시작과 끝을 식별할 수 있는 구조 제공
- 다양한 네트워크 계층 데이터 지원 : IP, IPv6, AppleTalk 등 여러 네트워크 프로토콜을 전송 가능
- 다양한 인증 프로토콜 지원 : 사용자의 정당성 확인 가능
- 오류 탐지 기능 포함 : 간단한 오류 확인을 위해 FCS 사용
- 압축 및 멀티링크 기능 : 성능 최적화 가능
그러나 PPP는 흐름 제어나 오류 정정(복구) 기능은 포함하지 않으며, 이는 상위 계층에서 처리하도록 설계되어 있다.
PPP의 프레임 구조
PPP는 문자 지향(또는 바이트 지향) 방식의 프레임을 사용한다. 이는 HDLC와 구조가 비슷하지만 보다 단순하게 설계되어 직렬 연결이나 모뎀 환경에서도 쉽게 사용할 수 있다.
HDLC와 유사하지만, PPP는 기본 주소/제어 필드를 고정 값으로 사용함으로써 간결한 구현을 가능하게 한다.
Transition Phases - 전이 단계
PPP 연결은 단순히 “연결되었다”로 끝나지 않고, 다음과 같은 단게적 절차(Transision Phases)를 통해 이루어진다.
- 링크 설정(Link Establishment) : LCP(Link Control Protocol)을 사용하여 물리적 연결과 기본 옵션 설정
- 인증(Authentication) : 선택적으로 PAP나 CHAP를 통해 사용자 인증 수행
- 네트워크 계층 설정(Network Layer Protocol Configuration) : NCP(Network Control Protocol)를 사용하여 IP나 다른 프로토콜 설정
- 데이터 전송(Data Trasger) : 정상적으로 상위 계층의 데이터 (IP 등)를 PPP 프레임으로 전송
- 연결 해제(Link Terminaion) : 연결 종료 시 LCP 패킷을 통해 세션 종료
이러한 단계들을 PPP의 전이 다이어그램으로 시각화되어 있으며, 안정적인 연결 유지 및 해제를 가능하게 한다.
Multiplexing - 다중화
PPP는 단순한 프레임 전송 외에도 다양한 프로토콜을 동시에 관리할 수 있도록 설계되어 있으며, 이를 위해 다음과 같은 프로토콜 세트를 사용한다.
- PPP 다중화를 위한 구성 프로토콜
- LCP(Link Control Protocol)
- 물리적 링크의 설정, 유지, 종료
- 오류 감지, 옵션 협상 등 포함
- APs(Authenticaion Protocols)
- 사용자 인증 수행
- PAP(Password Authenticaion Protocol) : 단순한 사용자/비밀번호 전송
- CHAP(Challenge-Handshake Authenticaion Protocol) : 도전/응답 방식으로 보안성 강화
- NCPs(Network Control Protocols)
- 각 네트워크 계층 프로토콜(IP, IPX, AppleTalk 등)을 PPP 위에서 운용 가능하게 해주는 제어 프로토콜(예: IPCP(IP Control Protocol))
- LCP(Link Control Protocol)
- PPP 내부 프레임 예시
-
각각의 프로토콜은 별도 프로토콜 번호로 구분된다.
-
PPP는 단순히 데이터를 주고받는 것만이 아니라, 연결을 설정하고, 사용자를 인증하며, 네트워크 계층 정보를 설정하는 다양한 제어 절차까지 수행한다. 이러한 절차를 수행하기 위해 PPP는 제어 프로토콜들을 따로 가지고 있고, 이들은 모두 PPP 프레임 내부에 실려 전송된다.(이를 캡슐화라고 한다.) PPP는 어떤 프로토콜의 정보가 실렸는지를 식별하기 위해 프레임의 ‘Protocol’ 필드를 사용한다. 예를 들어, IP데이터이닞, 인증 정보인지, 링크 설정 정보인지 이 필드를 통해 구분하는 것이다.
-
LCP(Link Control Protocil) : LCP는 PPP 연결의 시작과 끝을 관리하는 핵심 프로토콜이다. 우리가 전화를 걸 때 통화 버튼을 누르고 상대방과 연결이 되듯, PPP도 LCP를 통해 물리적 연결을 설정한다. 또한 연결을 유지하거나 종료할 때도 LCP가 사용된다. LCP는 연결 시 협상할 여러 가지 설정값(예: 최대 전송 크기, 압축 여부 등)을 담은 메시지를 전송한다. 이 메시지는 PPP 프레임 안에 담기며, 프레임의 Protocol 필드는 0xC021로 지정되어 LCP라는 것을 나타낸다.
- PAP(Password Authenticaion Protocol) : PAP는 사용자 인증을 위한 가장 단순한 방식이다. 사용자의 ID와 비밀번호를 평문 그대로 전송해서 인증하는 구조라, 보안성이 낮지만 구현이 간단하여 예전 시스템이나 제한된 환경에서는 여전히 사용된다. 예를 들어, 사용자가 ISP에 연결할 때 자신의 ID와 패스워드를 입력하면, 이 정보가 PAP 메시지 형태로 PPP 프레임에 담겨 서버로 전송된다. 이때 PPP 프레임의 Protocol 필드는 0xC023이다.
- CHAP(Challenge Handshake Authenticaion Protocol) : CHAP는 PAP보다 훨씬 보안성이 강화된 인증 방식이다. 사용자 정보를 암호화하여 전송하고, 서버는 이를 검증하는 구조로 되어있다. CHAP의 인증 방식은 마치 수수께끼를 푸는 것처럼 작동한다. 서버가 먼저 무작위 “질문(Challenge)”을 던지고, 클라이어느는 미리 약속한 방식(보통 해시 함수)으로 “정답(reponse)”을 계산하여 보낸다. 서버는 이 정답이 맞는지 확인하여 인증을 진행한다. CHAP 메시지도 PPP 프레임에 담겨 전송되며, 이때 Protocol 필드는 0xC223이다.
- IPCP(IP Control Protocol) : PPP는 여러 종류의 네트워크 계층 프로토콜(IP, IPv6 등)을 지원한다. 이 중에서도 가장 대표적인 것이 IP인데, 이를 위한 설정을 담당하는 프로토콜이 바로 IPCP이다. IPCP는 PPP 연결이 성립된 후, 양측이 사용할 IP주소나 DNS 서버 주소같은 설정 정보를 교환할 때 사용된다. 예를 들어, 클라이언트가 “나에게 사용할 IP 주소를 알려줘”라고 요청하고, 서버가 “너는 192.168.0.2를 사용해”라고 응답하는 과정이 IPCP를 통해 이뤄진다. 이러한 설정 메시지는 역시 PPP 프레임에 담겨 전송되며 Protocol 필드는 0x8021이다.
-
예제: PPP 연결을 통한 IP 데이터 전송
사용자가 ISP에 이메일을 보낸다고 가정했을 때, 다음의 단계로 데이터가 전송된다.
- LCP를 통해 물리 연결 설정
- CHAP 또는 PAP를 통해 사용자 인증
- IPCP를 통해 IP 연결 설정
- IP 패킷을 PPP 프레임에 담아 전송
- 세션 종료 시 LCP 종료 패킷 전송
이 과정을 통해 PPP는 다양한 계층의 기능을 통합적으로 수행하며, 안정적이고 신뢰성 있는 통신을 제공한다.
(보완) 동기식 전송 vs 비동기식 전송
PPP는 실제로 동기식과 비동기식 전송 환경 모두에서 사용될 수 있다. 이 두 방식은 전송 방식에 따라 명확히 구분된다.