IntServ와 RSVP로 구현하는 엔드투엔드 QoS
IntServ의 자원 예약과 RSVP, 서비스 클래스, 라우터 구성 요소를 중심으로 엔드투엔드 QoS 보장 방식과 DiffServ의 차이를 정리한다.
2026-08-14 · 최초 발행 2025-08-10
패킷을 보내기 전에 품질을 확보하는 IntServ
IntServ(Integrated Service)는 애플리케이션별로 차별화된 서비스 품질(QoS)을 제공하기 위한 IETF 표준 프레임워크다. 기존 Best-Effort 모델만으로는 실시간 트래픽이 요구하는 지연시간, 지터, 대역폭을 만족시키기 어렵다는 문제에서 출발했다.
1994년 RFC 1633에서 처음 소개됐으며, RSVP(Resource Reservation Protocol)와 함께 사용해 엔드투엔드 QoS 보장 메커니즘을 제공한다. 핵심은 데이터가 흐르기 전에 필요한 네트워크 자원을 예약하고, 그 예약을 경로 전체에서 유지하는 데 있다.
흐름 상태를 유지하며 예약을 승인하는 방식
IntServ는 애플리케이션이 필요한 네트워크 자원을 명시적으로 요청하는 모델이다. 각 흐름(Flow)의 상태 정보를 네트워크 장비가 보관하며, 새 흐름의 요청이 기존 흐름의 서비스 품질을 떨어뜨리지 않는지 승인 제어(Admission Control)로 판단한다.
예약이 승인된 뒤에는 패킷 분류와 스케줄링이 해당 자원을 기준으로 동작한다. 따라서 단순한 우선순위 지정이 아니라, 흐름별 요구사항을 실제 전달 경로에 반영하는 QoS 구조가 된다.
서비스 수준에 따라 달라지는 전달 특성
IntServ는 Guaranteed Service, Controlled-Load Service, Best-Effort Service를 제공한다.
Guaranteed Service는 엄격한 지연 시간을 보장하고, 네트워크 혼잡과 관계없이 패킷 손실 없는 전송을 보장한다. 실시간 애플리케이션과 음성·영상 전화에 맞는 서비스다.
Controlled-Load Service는 혼잡하지 않은 네트워크와 유사한 품질을 목표로 한다. 명시적인 지연 보장은 없지만, 혼잡 상황에서도 안정적인 성능을 제공하므로 적응형 실시간 애플리케이션에 적합하다.
Best-Effort Service는 전통적인 인터넷 서비스 모델이다. 별도의 QoS 보장은 없으며 웹 브라우징과 이메일 같은 비실시간 애플리케이션에 사용된다.
RSVP가 예약 경로를 만드는 과정
IntServ의 예약은 주로 RSVP를 통해 이뤄진다. 송신자는 PATH 메시지로 경로 정보와 트래픽 특성을 전달하고, 수신자는 필요한 QoS를 지정한 RESV 메시지를 역방향으로 보낸다.
예약 상태는 Soft-State 방식으로 주기적으로 갱신된다. 이를 통해 동적인 네트워크 환경 변화에 대응한다. Flowspec에는 대역폭, 지연, 지터 등 필요한 QoS 요구사항을 담고, Filterspec에는 예약 자원을 사용할 패킷을 식별하는 정보를 담는다.
라우터가 맡는 분류·승인·전송 역할
IntServ를 지원하는 라우터는 들어온 패킷을 분류하고, 새 예약을 승인하며, 예약 상태에 맞춰 전송 순서를 결정해야 한다.
패킷 분류기(Packet Classifier)는 들어오는 패킷을 적절한 QoS 클래스로 나눈다. 이때 출발지 IP, 목적지 IP, 포트, 프로토콜로 구성된 5-tuple을 기준으로 분류할 수 있다.
승인 제어(Admission Control)는 새 흐름이 기존 서비스에 미칠 영향을 확인한다. 네트워크 자원의 가용성을 검사한 뒤 요청을 허용하거나 거부한다.
패킷 스케줄러(Packet Scheduler)는 큐잉과 패킷 전송 순서를 관리한다. WFQ(Weighted Fair Queuing), PQ(Priority Queuing) 같은 알고리즘을 활용한다.
강한 보장이 가져오는 운영상의 제약
흐름별 상태 관리는 IntServ의 강점이면서 동시에 확장성 제약이다. 라우터는 흐름마다 상태 정보를 유지해야 하므로 부하가 늘어나며, 백본 네트워크에서 수백만 개의 동시 흐름을 관리하기는 어렵다.
엔드투엔드 QoS 보장을 위해서는 경로에 있는 모든 라우터가 IntServ와 RSVP를 지원해야 한다. 일부만 구현된 환경에서는 전체 경로의 품질을 보장할 수 없다. 세밀한 흐름별 제어는 운영 복잡도도 높여 대규모 네트워크에서 관리 부담으로 이어진다.
DiffServ와 비교할 때 달라지는 선택 기준
| 특성 | IntServ | DiffServ |
|---|---|---|
| 자원 예약 | 사전 예약 방식 | 사전 프로비저닝 방식 |
| 상태 관리 | 흐름별 상태 관리 | 클래스별 상태 관리 |
| 확장성 | 제한적 | 우수 |
| QoS 보장 수준 | 강력한 보장 | 상대적 차별화 |
| 복잡성 | 높음 | 낮음 |
| 프로토콜 | RSVP 필요 | 별도 시그널링 불필요 |
| 구현 범위 | 전체 경로 | 도메인 내부 |
IntServ는 흐름 단위의 강한 보장이 필요할 때 적합하다. 반면 DiffServ는 클래스 단위로 상태를 관리해 더 높은 확장성을 제공한다.
품질 보장이 필요한 네트워크 환경
기업 네트워크에서는 화상 회의와 VoIP 같은 실시간 애플리케이션의 QoS를 보장하고, 중요 업무 애플리케이션에 우선순위를 부여하는 데 활용할 수 있다.
ISP 네트워크에서는 프리미엄 서비스의 QoS 차별화와 SLA(Service Level Agreement) 준수를 위한 기술적 기반이 된다. 연구·교육 네트워크에서는 고대역폭이 필요한 과학 애플리케이션과 실시간 원격 교육 환경을 지원할 수 있다.
의료 네트워크에서는 원격 진료와 실시간 의료 영상 전송, 생명과 직결된 중요 데이터의 우선 처리에도 적용할 수 있다.
에지의 예약과 코어의 확장성을 함께 다루기
현대 네트워크에서는 IntServ와 DiffServ를 결합하는 하이브리드 접근이 실용적이다. 에지 네트워크에는 IntServ를 적용하고, 코어 네트워크에는 DiffServ를 활용하는 방식이다.
SDN과 통합하면 소프트웨어 정의 네트워킹을 통해 자원을 더 유연하게 관리할 수 있으며, 중앙화된 컨트롤러는 IntServ의 확장성 문제 해결에 활용될 수 있다. 5G에서는 네트워크 슬라이싱과 IntServ 원리를 결합해 서비스별 네트워크 자원을 보장하는 방향도 가능하다.
마이크로서비스 아키텍처와 컨테이너 기반 애플리케이션이 사용하는 클라우드 네이티브 환경에서도 네트워크 품질 관리가 요구된다. IntServ는 이러한 환경에서 QoS를 다루는 기본 개념과 메커니즘으로 의미를 가진다.
적용 전 확인할 운영 조건
도입 전에는 트래픽 패턴과 애플리케이션 요구사항을 파악하고, 네트워크 토폴로지와 용량 계획을 수립해야 한다. 라우터와 스위치가 IntServ와 RSVP를 지원하는지 확인한 뒤 장비 구성과 파라미터를 조정한다.
중요 애플리케이션부터 적용해 테스트 환경에서 검증한 후 범위를 확대하는 방식이 적절하다. 운영 중에는 QoS 메트릭을 계속 모니터링하고, 성능 이슈가 발생하면 파라미터를 조정해야 한다.