TCP 심화
1. L2·L4의 오류제어와 ARQ
ARQ(Automatic Repeat reQuest)는 ACK, 순서번호, 타이머, 재전송으로 데이터 유실·손상을 복구하는 오류제어 방식이다.
| 구분 | L2 | L4 |
|---|---|---|
| 범위 | 인접 노드 간(Hop-by-Hop) | 송신 호스트~수신 호스트 간(End-to-End) |
| 단위 | 프레임 | 세그먼트(TCP는 바이트 스트림 기준) |
| 목적 | 개별 링크 오류의 신속한 복구 | 전체 경로의 신뢰성 보장 |
L2와 L4 모두 ARQ 원리는 같지만, 적용 범위와 데이터 단위가 다르다.
2. ARQ 방식의 분류
ARQ
├─ Stop-and-Wait ARQ
│ └─ 윈도우 크기 1, 한 건 전송 후 ACK 대기
└─ Sliding Window ARQ
├─ Go-Back-N ARQ
└─ Selective Repeat ARQ| 방식 | 오류·유실 발생 시 |
|---|---|
| Stop-and-Wait | 해당 데이터 1개 재전송 |
| Go-Back-N | 유실 데이터부터 이후 전송분을 모두 재전송 |
| Selective Repeat | 유실 데이터만 선택 재전송 |
3. 슬라이딩 윈도우
슬라이딩 윈도우는 ACK를 하나씩 기다리지 않고 여러 데이터를 연속 전송하기 위한 전송 범위 관리 구조다.
송신 윈도우 크기 = 5
송신 가능: 1, 2, 3, 4, 5
ACK 3 수신
= 1, 2 수신 완료
= 다음으로 3을 기대
새 송신 윈도우: 3, 4, 5, 6, 7이미 3~5를 보냈다면 새로 전송 가능한 데이터는 6, 7이다.
4. TCP ACK의 의미
TCP는 다음 기대 번호 기반의 누적 ACK를 사용한다.
TCP ACK 7
= 1~6번 바이트까지 연속 수신 완료
= 다음으로 7번 바이트를 기대따라서 ACK는 항상 다음 두 뜻을 함께 가진다.
ACK n
= n 이전 데이터의 수신 확인
+ n번 데이터의 다음 기대 표시ACK n이 “n번 데이터를 받았다”는 뜻으로 쓰이는 경우는 교과서적 Selective Repeat의 개별 ACK 표기 관례에 가깝다. 기술사 답안의 다이어그램에는 ACK 의미를 범례로 명시하는 것이 좋다.
※ TCP ACK n: n-1까지 누적 수신 완료, n번 데이터 기대여기의 n이 Sequence Number임
5. Go-Back-N과 Selective Repeat 비교
1~5 전송 중 3이 유실되고 4, 5가 도착한 경우를 예로 들면 다음과 같다.
| 구분 | Go-Back-N | Selective Repeat |
|---|---|---|
| 수신 측의 4·5 처리 | 폐기 | 버퍼에 보관 |
| 송신 측 재전송 | 3, 4, 5 모두 | 3만 |
| 3 재수신 후 | 다음 번호 4 기대 | 4·5도 보관했으므로 연속 처리 가능 |
| 특징 | 단순하지만 비효율적 | 효율적이지만 버퍼·제어 복잡 |
6. TCP와 전통적 Selective Repeat의 차이
TCP는 Selective Repeat 성격에 가깝지만, 전통적 Selective Repeat ARQ와 완전히 같지는 않다.
| 구분 | 전통적 Selective Repeat | TCP |
|---|---|---|
| 순서번호 | 보통 프레임·패킷 단위 | 바이트 단위 |
| ACK | 개별 ACK 중심 | 누적 ACK 기본 |
| 순서 밖 데이터 | 버퍼링 | 버퍼링 |
| 선택 수신 정보 | 개별 ACK로 전달 | SACK 옵션으로 수신 구간 전달 가능 |
| 손실 복구 | 유실 프레임 재전송 | Fast Retransmit, RTO, SACK 등 활용 |
TCP는 기본적으로 누적 ACK를 쓰지만, SACK을 사용하면 순서 밖으로 수신한 구간도 송신 측에 알려 손실 데이터만 더 정확하게 재전송할 수 있다.
7. SACK과 비트맵 ACK
둘 다 수신 측이 “이미 받은 데이터”를 송신 측에 알리는 선택 확인 방식이다.
| 구분 | SACK | 비트맵 ACK |
|---|---|---|
| 표현 방식 | 수신 완료 구간의 시작·끝 | 각 데이터의 수신 여부를 비트로 표시 |
| 예 | [4~6], [8~10] 수신 | 01110111 |
| 대표 사례 | TCP SACK | Wi-Fi Block ACK 등 |
누적 ACK: “여기까지 연속 수신”
SACK: “추가로 이 구간도 수신”
비트맵 ACK: “이 범위의 각 데이터 수신 여부”L2에서도 선택 확인 기능은 사용한다. 다만 TCP SACK이라는 동일한 형식을 사용하는 것이 아니라 Wi-Fi Block ACK, NACK, 비트맵 등 기술별 방식을 사용한다.
8. TCP의 오류제어·흐름제어·혼잡제어
TCP는 슬라이딩 윈도우 기반의 전송 구조 안에서 세 기능을 통합한다.
| 기능 | 목적 | 주요 수단 |
|---|---|---|
| 오류제어 | 유실·손상 복구 | 순서번호, 체크섬, ACK, RTO, 재전송, SACK |
| 흐름제어 | 수신 버퍼 초과 방지 | 수신 윈도우 rwnd |
| 혼잡제어 | 네트워크 혼잡 방지 | 혼잡 윈도우 cwnd |
실제 송신 가능량
= min(rwnd, cwnd) - 현재 ACK 대기 중인 데이터량rwnd(수신 윈도우): 수신 측이 자신의 버퍼 여유를 광고하는 값cwnd(혼잡 윈도우): 송신 측이 네트워크 상태를 추정해 설정하는 값
rwnd: “수신자가 더 받을 수 있는 양”
cwnd: “네트워크가 감당할 수 있는 양”9. TCP의 손실 감지와 재전송
TCP의 표준 오류 복구는 FEC가 아니라 ARQ 기반 재전송이다.
손실 감지
├─ 중복 ACK 3회 수신
│ └─ Fast Retransmit: 타임아웃 전 즉시 재전송
└─ RTO 만료
└─ 재전송 Timeout에 따른 재전송RTO는 Retransmission Timeout, 즉 재전송 타임아웃이다. 세그먼트 전송 후 일정 시간 내 ACK가 오지 않으면 손실로 판단하는 기준 시간이며, TCP는 RTT와 RTT 변동폭을 바탕으로 이를 동적으로 계산한다.
(RTT: Round Trip Time, 왕복 시간)
10. TCP 혼잡제어
| 기능 | 내용 |
|---|---|
| Slow Start | cwnd를 RTT마다 대략 2배 증가시켜 초기 전송량 탐색 |
| Congestion Avoidance | cwnd를 RTT마다 대략 1 MSS씩 선형 증가 |
| Fast Retransmit | 중복 ACK 3회 수신 시 손실 세그먼트 즉시 재전송 |
| Fast Recovery | Fast Retransmit 후 cwnd를 과도하게 줄이지 않고 회복 |
연결 시작
→ Slow Start
→ Congestion Avoidance
→ 손실 발생
├─ 중복 ACK 3회: Fast Retransmit + Fast Recovery
└─ RTO 만료: cwnd를 크게 낮추고 Slow Start 재진입11. 핵심 결론
TCP는 슬라이딩 윈도우 기반 ARQ를 통해 연속 전송과 신뢰성을 제공한다.
오류제어는 ACK·순서번호·재전송으로, 흐름제어는 수신 윈도우(rwnd)로, 혼잡제어는 혼잡 윈도우(cwnd)로 수행하며, 실제 송신량은min(rwnd, cwnd)에 의해 제한된다.
OSI 7 계층
I. 통신표준 참조모델, OSI 7계층의 개요
-
개념: 통신기능 7계층 표준화 모델
-
특징: (1) 계층별 독립적 기능 분리 (2) 상하위 계층간 인터페이스 정의
-
통신 표준화 위한 계층적 참조모델
II. OSI 7계층의 구성도 및 구성요소
가. OSI 7계층의 구성도
[7.응용]-[6.표현]-[5.세션]
-[4.전송]-[3.네트워크]
-[2.데이터링크]-[1.물리]
↕ (상호 캡슐화/역캡슐화)
- 상위 응용~하위 물리 계층 순
나. OSI 7계층의 구성요소
| 구분 | 구성요소 | 설명 |
|---|---|---|
| 상위계층 | 응용계층 | 사용자 서비스 제공 |
| 상위계층 | 표현계층 | 데이터 형식 변환 |
| 상위계층 | 세션계층 | 통신세션 관리 |
| 하위계층 | 전송계층 | 종단간 신뢰성 전송 |
| 하위계층 | 네트워크계층 | 경로설정 및 주소지정 |
| 하위계층 | 데이터링크/물리 | 매체접근 및 신호전송 |
- 상위 3계층·하위 4계층 구분
III. OSI 7계층 추가정보
| 구분 | 내용 | 비고 |
|---|---|---|
| 비교 | TCP/IP 4계층과 대응관계 | 실무는 TCP/IP 주로 사용 |
| 표준 | ISO/IEC 7498 표준 | 1984년 제정 |
| 시사점 | 계층별 장애구간 식별 용이 | 네트워크 설계·운영 기준 |
- TCP/IP 대비 개념적 참조모델
- 7~5 → 응용 계층 (Application Layer)
- 4 → 전송계층 (Transport Layer)
- 3 → 인터넷 계층 (Internet Layer)
- 2,1 → 네트워크 접속 계층 (Network Access Layer)
OSI 7계층의 계층별 프로토콜 종류
I. 계층별 표준통신규약, 계층별 프로토콜의 개요
-
개념: 각 계층 기능수행 위한 통신규약
-
특징: (1) 계층별 독립적 프로토콜 정의 (2) 상위계층 하위계층 서비스 이용
-
계층마다 고유기능 수행 프로토콜 존재
II. 계층별 프로토콜의 구성도 및 구성요소
가. 계층별 프로토콜의 구성도
[응용]HTTP,FTP,SMTP,DNS
[표현]SSL/TLS,JPEG
[세션]NetBIOS,RPC
[전송]TCP,UDP
[네트워크]IP,ICMP,ARP
[링크]Ethernet,PPP
[물리]RS-232,USB
- 상위계층일수록 응용특화 프로토콜
나. 계층별 프로토콜의 구성요소
| 구분 | 구성요소 | 설명 |
|---|---|---|
| 상위3계층 | HTTP,FTP,SMTP | 응용서비스 제공 규약 |
| 상위3계층 | SSL/TLS | 암호화 표현변환 |
| 전송계층 | TCP | 연결형 신뢰전송 |
| 전송계층 | UDP | 비연결형 고속전송 |
| 하위3계층 | IP,ARP | 주소지정 및 경로설정 |
| 하위3계층 | Ethernet | 매체접근 제어 |
- 신뢰성·속도별 전송프로토콜 구분
III. 계층별 프로토콜 추가정보
| 구분 | 내용 | 비고 |
|---|---|---|
| 관련기술 | HTTP/3는 UDP기반 QUIC사용 | 성능개선 트렌드 |
| 비교 | TCP는 신뢰성, UDP는 속도우선 | 용도별 선택 |
| 시사점 | 프로토콜 계층매칭 트러블슈팅 | 장애분석 기초 |
- 신기술은 계층경계 넘나드는 추세
OSI 7계층의 계층별 데이터 종류
I. 계층별 전송단위, 계층별 데이터의 개요
-
개념: 각 계층서 처리되는 데이터 단위
-
특징: (1) 계층통과시 헤더 캡슐화 (2) 계층별 고유 PDU 명칭
-
계층별 PDU 캡슐화로 데이터 전송
II. 계층별 데이터의 구성도 및 구성요소
가. 계층별 데이터의 구성도
[응용~세션] Data
↓ +TCP Header
[전송] Segment(TCP)/Datagram(UDP)
↓ +IP Header
[네트워크] Packet
↓ +Frame Header/Trailer
[링크] Frame
↓ 신호변환
[물리] Bit
- 하위 이동시 헤더 순차 추가
나. 계층별 데이터의 구성요소
| 구분 | 구성요소 | 설명 |
|---|---|---|
| 상위PDU | Data | 응용~세션계층 데이터 |
| 상위PDU | Segment/Datagram | 전송계층 PDU |
| 중간PDU | Packet | 네트워크계층 PDU |
| 중간PDU | Frame | 데이터링크계층 PDU |
| 하위PDU | Bit | 물리계층 신호단위 |
| 하위PDU | Header/Trailer | 제어정보 캡슐화 |
- Data~Bit 순 캡슐화 진행
III. 계층별 데이터 추가정보
| 구분 | 내용 | 비고 |
|---|---|---|
| 비교 | 캡슐화(송신)·역캡슐화(수신) 대응 | 양방향 처리 |
| 시사점 | 패킷분석시 PDU단위 식별필요 | 네트워크 진단기초 |
| 관련기술 | 와이어샤크로 계층별 헤더 확인 | 실무 분석도구 |
- 송수신간 캡슐화/역캡슐화 대칭
OSI 7계층의 계층별 주요 장비
I. 계층별 네트워크장비, 계층별 장비의 개요
-
개념: 각 계층 기능수행 위한 통신장비
-
특징: (1) 계층 높을수록 지능적 처리 (2) 하위계층 장비 단순중계 위주
-
계층별 특성 반영한 전용장비 존재
II. 계층별 장비의 구성도 및 구성요소
가. 계층별 장비의 구성도
[7응용~4전송] 게이트웨이,L4스위치
[3네트워크] 라우터,L3스위치
[2데이터링크] 스위치,브리지
[1물리] 허브,리피터,케이블
- 상위계층 갈수록 처리지능 높아짐
나. 계층별 장비의 구성요소
| 구분 | 구성요소 | 설명 |
|---|---|---|
| 상위계층장비 | 게이트웨이 | 네트워크간 연결점 제공 |
| 상위계층장비 | L4스위치 | 포트기반 부하분산 |
| 네트워크계층 | 라우터 | 경로선택 및 패킷전달 |
| 네트워크계층 | L3스위치 | IP기반 고속스위칭 |
| 하위계층장비 | 스위치,브리지 | MAC주소 기반 전달 |
| 하위계층장비 | 허브,리피터 | 신호증폭 단순중계 |
- 라우터·스위치가 실무핵심 장비
III. 계층별 주요 장비 추가정보
| 구분 | 내용 | 비고 |
|---|---|---|
| 비교 | 허브는 충돌영역 공유, 스위치는 분리 | 성능차이 핵심 |
| 관련기술 | L3스위치가 라우터기능 흡수 추세 | 장비융합화 |
| 시사점 | 장애계층 파악해 장비단위 대응 | 네트워크 운영효율 |
- 장비 고도화로 계층경계 모호화
(참고용)“스위치”라는 이름의 유래
핵심은 전화교환기(Switchboard)에서 유래한 개념입니다. 네트워크 스위치는 이 “회선을 연결해주는” 개념을 데이터 통신에 적용한 장비입니다.
어원적 배경
전화교환기(Telephone Switchboard)
- 초기 전화망에서 교환원이 발신자와 수신자 회선을 물리적으로 “연결(switch)“해주던 장비/작업에서 유래
- 회선 A와 회선 B를 필요할 때만 연결하고, 통화가 끝나면 끊는 방식 → “스위칭(switching)”
네트워크 스위치로의 적용
- 허브(Hub)는 들어온 신호를 연결된 모든 포트로 무조건 전달(브로드캐스트 방식)
- 스위치는 목적지 MAC 주소를 보고 필요한 포트로만 선택적으로 연결/전달
- 즉, “여러 회선(포트) 중 필요한 경로만 골라 연결한다”는 동작이 전화교환기의 스위칭 개념과 동일
허브와의 비교로 이해하기
| 구분 | 허브(Hub) | 스위치(Switch) |
|---|---|---|
| 동작방식 | 모든 포트로 무조건 전달 | MAC주소 확인 후 해당 포트로만 전달 |
| 충돌영역 | 전체 포트가 하나의 충돌영역 공유 | 포트별로 충돌영역 분리 |
| 이름 유래 | 단순 중계허브(허브=중심점) | 회선을 선택 연결(switching) |
| 비유 | 방송(broadcast) | 전화교환(switching) |
정리하면
- “스위치”라는 이름은 **“여러 경로 중 필요한 경로로 데이터를 선택적으로 전환(switch)해서 보낸다”**는 동작 원리 자체에서 나온 이름
- 이 개념은 **회선 교환(Circuit Switching)**과 **패킷 교환(Packet Switching)**이라는 통신망의 근본적인 두 가지 교환 방식 개념과도 연결됨
- 회선교환: 전화망처럼 통신 동안 회선을 고정 점유
- 패킷교환: 데이터를 패킷 단위로 나눠 필요할 때마다 경로를 동적으로 스위칭 (오늘날 인터넷 방식)
- 네트워크 스위치(2계층 장비)는 이 중 패킷교환/프레임교환 개념에 기반해 MAC 주소 테이블을 참조하여 포트 간 프레임을 “스위칭”하는 장비이기 때문에 이런 이름이 붙었습니다
참고로 “L4/L7 스위치”라는 이름이 붙은 것도 이 연장선입니다 — 단순 MAC 기반 스위칭을 넘어 포트/콘텐츠 정보까지 참조해 “스위칭(경로선택)“한다는 의미가 확장 적용된 것입니다.
(참고용) 브리지(Bridge)란
브리지는 2계층(데이터링크 계층)에서 동작하며, 두 개 이상의 네트워크 세그먼트(충돌영역)를 MAC 주소 기반으로 연결·중계하는 장비입니다. 앞서 다룬 “계층별 주요 장비” 표에서 스위치와 함께 묶었던 장비인데, 좀 더 자세히 설명드리면 사실 브리지는 스위치의 원조 개념입니다.
핵심 목적
충돌영역(Collision Domain) 분리
- 허브로 연결된 네트워크는 모든 단말이 하나의 충돌영역을 공유 → 단말 수가 많아질수록 충돌 증가, 성능 저하
- 브리지는 네트워크를 여러 세그먼트로 나누고, MAC 주소 테이블을 학습해서 필요한 세그먼트로만 프레임을 전달
- 불필요한 트래픽은 다른 세그먼트로 넘기지 않음 → 충돌영역 축소, 전체 네트워크 효율 향상
동작 방식
[세그먼트A: PC1,PC2] --[브리지]-- [세그먼트B: PC3,PC4]
- PC1이 PC2에게 프레임 전송 (같은 세그먼트)
- 브리지는 MAC 주소 테이블 확인 → 목적지가 같은 세그먼트(A)에 있음을 인지
- 세그먼트 B로는 프레임을 넘기지 않음 (필터링)
- 반대로 PC1이 PC3에게 보내면 세그먼트 B로 전달 (포워딩)
브리지 vs 스위치, 왜 헷갈릴까
| 구분 | 브리지 | 스위치 |
|---|---|---|
| 등장시기 | 더 오래됨 (스위치의 원조) | 브리지 발전형 |
| 포트 수 | 보통 2개 (세그먼트 2개 연결) | 다수 포트(4~48포트 등) |
| 처리방식 | 소프트웨어 기반 처리 | 하드웨어(ASIC) 기반 고속처리 |
| 동작원리 | MAC주소 학습·필터링·포워딩 (동일) | MAC주소 학습·필터링·포워딩 (동일) |
즉, 브리지와 스위치는 동작 원리(MAC 기반 학습/필터링/포워딩)가 완전히 동일하며, **“포트가 많은 브리지 = 스위치”**라고 이해하셔도 무방합니다. 실무에서는 포트 수가 적고 오래된 개념이라 “브리지”라는 용어 자체는 거의 쓰이지 않고, 대부분 “스위치”로 통칭됩니다.
정리하면
- 브리지의 목적: 세그먼트 간 MAC 주소 기반 선택적 중계로 충돌영역 분리, 네트워크 성능 향상
- 역사적 위치: 허브(단순중계) → 브리지(지능형 중계, 원조) → 스위치(다중포트 브리지, 발전형)
- 정보관리기술사 시험 관점에서는 “브리지”를 별도 주제로 깊게 물어보기보다, 스위치의 원리를 설명할 때 그 기원으로 함께 언급되는 경우가 많습니다
데이터 링크 계층의 오류제어
- 두음: 스고세 Stop and wait Go-back N Selective
H-ARQ
FEC는 block, non-block 방식으로 나뉨
I. 프레임 오류 검출·정정, 오류제어의 개요
-
개념: 전송오류 검출·정정하는 링크계층 기능
-
특징: (1) 프레임 단위 오류검출 수행 (2) FEC·ARQ로 정정·재전송
-
프레임 오류 검출 후 정정·재전송으로 신뢰성 확보
II. 오류제어의 구성도 및 구성요소
가. 오류제어의 구성도
[송신측] [수신측]
Frame+FCS 생성 ──전송──▶ FCS 검사
│ │
│ 오류검출(패리티/CRC)
│ │
│ FEC 자체정정 가능?
│ ├─Yes→ 정정 후 수신
▲ └─No→ 재전송요청
ACK 수신 시 다음 프레임 전송 ◀── NAK/Timeout
- 검출 후 FEC 정정 또는 ARQ 재전송 분기
나. 오류제어의 구성요소
| 구분 | 구성요소 | 설명 |
|---|---|---|
| 오류검출 | 패리티 비트 | 홀짝성 검사 |
| 오류검출 | CRC | 다항식 기반 정밀검출 |
| 오류정정(FEC) | 해밍코드 | 비트단위 자체정정 |
| 오류정정(FEC) | 컨볼루션 코드 | 연속 비트 결합 부호화 |
| 오류정정(FEC) | Reed-Solomon | 블록단위 다중오류 정정 |
| 재전송제어(ARQ) | Stop-and-Wait | 1프레임씩 확인 후 전송 |
| 재전송제어(ARQ) | Go-Back-N/SR | 슬라이딩윈도우 기반 재전송 |
- 검출·FEC정정·ARQ재전송 3범주 구성
CRC는 Cyclic Redundancy Check(순환 중복 검사)의 약자입니다.
- Cyclic: 다항식 나눗셈(순환 코드) 기반으로 계산한다는 의미
- Redundancy: 원본 데이터 외에 검사용 잉여 비트(체크섬)를 덧붙인다는 의미
- Check: 그 값으로 오류 유무를 검사(확인)한다는 의미
동작 방식은 전송할 데이터를 미리 정해진 생성다항식으로 나눈 나머지를 프레임 끝에 붙여 보내고, 수신측이 같은 다항식으로 다시 나눠봐서 나머지가 0이 아니면 오류로 판단하는 구조입니다.
III. 오류제어 추가정보
| 구분 | 내용 | 비고 |
|---|---|---|
| 관련기술 | H-ARQ: FEC+ARQ 결합방식 | Type I/II/III로 구분 |
| 사용시점 | 이동통신 등 무선환경 활용 | 채널상태 시변하는 환경 |
| 사용시점 | FEC·ARQ 유리조건 공존시 | 정정+재전송 상호보완 |
| 산업표준 | LTE/5G는 IR 방식 채택 | 재전송마다 다른정보 추가전송 |
- IR(Incremental Redundancy): 재전송마다 새 정보 덧붙여 결합해 복호율 향상
TCP 전체 개요
1. 상위 개념: TCP 신뢰성 제어의 목표 체계
TCP가 해결해야 하는 문제는 근본적으로 세 가지이고, 각각 목적이 다릅니다.
| 구분 | 목적 | 대상 | 핵심 메커니즘 |
|---|---|---|---|
| 오류 제어 (Error Control) | 데이터의 정확한 전달 보장 | 패킷 손실/손상 | ARQ (Sequence Number, ACK, Timeout, Retransmission) |
| 흐름 제어 (Flow Control) | 수신자 처리 능력 보호 | 송신자-수신자 간 속도 불일치 | Sliding Window (Receiver Window, rwnd) |
| 혼잡 제어 (Congestion Control) | 네트워크(중간 경로) 보호 | 망 자원 과부하 | Congestion Window (cwnd), AIMD, Slow Start |
이 세 가지는 “무엇을 보호하느냐” 가 다르다는 게 핵심 구분 기준입니다. 오류제어는 데이터 자체, 흐름제어는 수신 호스트, 혼잡제어는 네트워크 인프라를 보호합니다.
2. 슬라이딩 윈도우가 “공통 플랫폼”으로 작동하는 방식
슬라이딩 윈도우는 원래 오류제어(ARQ)의 한 방식(Go-Back-N, Selective Repeat)에서 출발한 개념인데, TCP는 이 구조를 재활용해서 흐름제어와 혼잡제어까지 얹었다고 보시면 됩니다.
- 오류제어 관점: 윈도우 내에서 순서번호(Sequence Number)로 각 바이트를 추적하고, ACK가 오지 않으면 재전송(Retransmission)합니다. 이때 윈도우는 “확인응답 없이 보낼 수 있는 범위”를 정의합니다.
- 흐름제어 관점: 수신자가 자신의 버퍼 여유를 rwnd(Receiver Window) 값으로 ACK에 실어 보내고, 송신자는 실제 전송 윈도우 크기를
min(cwnd, rwnd)로 제한합니다. 즉 윈도우의 “크기 결정권”을 수신자가 갖는 구조입니다. - 혼잡제어 관점: 송신자 스스로 cwnd(Congestion Window)를 계산해서 네트워크 상태(RTT, 패킷 손실)에 따라 윈도우 크기를 조절합니다. Slow Start, Congestion Avoidance, Fast Retransmit/Recovery가 이 cwnd를 변화시키는 알고리즘입니다.
3. 관계 정리 (계층 구조)
실제 전송 가능한 윈도우 크기 = min(cwnd, rwnd)
│ │
[혼잡제어 담당] [흐름제어 담당]
│ │
둘 다 "슬라이딩 윈도우"라는 동일한 자료구조/동작원리 위에서 계산됨
│
윈도우 안의 각 세그먼트는 오류제어(ACK/재전송)로 관리됨
즉 답안을 쓰실 때는 이런 논리 흐름이 자연스럽습니다:
- TCP는 신뢰성 있는 전달을 위해 오류제어·흐름제어·혼잡제어 3가지가 필요하다
- 세 제어 모두 “확인응답 기반 + 윈도우”라는 공통 골격(슬라이딩 윈도우)을 공유한다
- 단, 윈도우 크기를 결정하는 주체와 목적이 다르다 (수신자가 결정=흐름제어용 rwnd / 송신자가 네트워크 상태보고 결정=혼잡제어용 cwnd)
- 최종 송신 윈도우는 두 값 중 작은 값으로 결정되고, 그 안에서 개별 세그먼트의 신뢰성은 ARQ(오류제어)가 보장한다
TCP
I. 신뢰성 있는 종단간 전송프로토콜, TCP의 개요
-
개념: 연결지향형 신뢰성 데이터 전송 프로토콜
-
특징: (1) 3-way handshake 연결설정 (2) 오류·흐름·혼잡 통합제어
-
신뢰성·순서보장 갖춘 전송계층 프로토콜
II. TCP의 구성도 및 구성요소
가. TCP의 구성도
[연결설정: 3-Way Handshake]
│
▼
[데이터 전송: Sliding Window 기반]
├─ 오류제어(ACK/재전송)
├─ 흐름제어(rwnd)
└─ 혼잡제어(cwnd)
│
▼
[연결종료: 4-Way Handshake]
- 설정→전송제어→종료 3단계 생명주기
나. TCP의 구성요소
| 구분 | 구성요소 | 설명 |
|---|---|---|
| 연결관리 | 3-Way Handshake | SYN·SYN-ACK·ACK |
| 연결관리 | 4-Way Handshake | FIN 기반 연결종료 |
| 헤더필드 | Sequence/ACK Number | 바이트 순서·확인응답 |
| 헤더필드 | Window Size | 수신가능 버퍼크기 |
| 전송제어 | 오류제어 | ACK·재전송 손실복구 |
| 전송제어 | 흐름·혼잡제어 | rwnd·cwnd 전송량조절 |
- 연결관리·헤더필드·전송제어 3범주 구성
III. TCP 추가정보
| 구분 | 내용 | 비고 |
|---|---|---|
| 비교 | UDP 대비 신뢰성·순서보장 우수 | 오버헤드 존재 |
| 관련기술 | QUIC으로 HOL Blocking 개선 추세 | HTTP/3 채택 |
| 시사점 | 실시간성보다 정확성 요구환경에 적합 | 스트리밍은 UDP선호 |
- 신뢰성 특화, 실시간성은 상대적 약점
TCP 오류제어
I. 데이터 신뢰전달 보장기법, TCP 오류제어의 개요
-
개념: ACK·재전송 기반 손실복구 기법
-
특징: (1) 순서번호 기반 순서보장 (2) Timeout 기반 재전송
-
ACK·순서번호로 손실·중복 검출복구
II. TCP 오류제어의 구성도 및 구성요소
가. TCP 오류제어의 구성도
[Sender]--Seg(Seq#)-->[Receiver]
↑ │
└------ACK/SACK----------┘
(Timeout 시 재전송)
(3중복ACK 시 Fast Retransmit)
- ACK 지연/누락 시 재전송 트리거
(SACK: Selective ACK, 선택적 확인 응답, 일부만 수신 완료했을 때, 어디를 받았고 어디를 못 받았는지 표기)
나. TCP 오류제어의 구성요소
| 구분 | 구성요소 | 설명 |
|---|---|---|
| 식별 | Sequence Number | 바이트 단위 순서식별 |
| 식별 | Checksum | 데이터 손상 검출 |
| 확인응답 | Cumulative ACK | 누적 수신확인 |
| 확인응답 | SACK | 비연속 수신구간 통지 |
| 복구 | RTO 재전송 | 타임아웃시 재전송 |
| 복구 | Fast Retransmit | 중복ACK3회시 즉시재전송 |
- 식별·확인응답·복구 3단계 구조
(TCP에서 ACK는 ‘수신자가 다음에 받기를 기대하는 바이트 번호’임. 중복 ACK를 받았다는건 해당 ACK의 데이터를 받지 못하고 다른 데이터들을 받았다는 뜻. Fast Retransmit은 RTO를 기다리지 않고 재전송을 하기 때문에 Fast라는 이름이 붙었다.)
III. TCP 오류제어 추가정보
| 구분 | 내용 | 비고 |
|---|---|---|
| 비교 | UDP는 오류제어 미제공 | 신뢰성 트레이드오프 |
| 기술동향 | SACK 확장으로 복구효율 개선 | RFC 2018 |
| 시사점 | 재전송타이머 과다시 성능저하 | RTO 튜닝 필요 |
- SACK 도입으로 복구정밀도 향상
TCP 흐름제어
I. 수신자 처리능력 보호기법, TCP 흐름제어의 개요
-
개념: 수신버퍼 기준 송신속도 조절기법
-
특징: (1) 슬라이딩 윈도우 기반 (2) 수신자가 윈도우 결정
-
rwnd로 송신측 전송량 제한
II. TCP 흐름제어의 구성도 및 구성요소
가. TCP 흐름제어의 구성도
[Receiver Buffer 여유량]
│ 계산
▼
rwnd 값 산출
│ ACK에 실어 전달
▼
[Sender] 전송량 ≤ rwnd
- 수신버퍼 상태가 송신윈도우 결정
나. TCP 흐름제어의 구성요소
| 구분 | 구성요소 | 설명 |
|---|---|---|
| 윈도우 | rwnd | 수신가능 버퍼크기 |
| 윈도우 | Sliding Window | 전송범위 이동관리 |
| 예외처리 | Zero Window | 버퍼포화 알림 |
| 예외처리 | Window Probe | Zero Window 해제확인 |
| 버퍼관리 | Receive Buffer | 수신데이터 임시저장 |
| 버퍼관리 | Buffer 조정 | 애플리케이션 처리속도 반영 |
- 윈도우·예외처리·버퍼 3요소 결합
III. TCP 흐름제어 추가정보
| 구분 | 내용 | 비고 |
|---|---|---|
| 비교 | 혼잡제어는 송신자, 흐름제어는 수신자 주도 | 주체 차이 |
| 관련기술 | Window Scaling으로 대역폭 확장 | RFC 1323 |
| 시사점 | Zero Window 방치시 통신정체 | Probe 필수 |
- 수신자 주도 제어라는 점이 핵심차별점
TCP 혼잡제어
I. 네트워크 자원보호 기법, TCP 혼잡제어의 개요
-
개념: 망 상태 반영 송신량 조절기법
-
특징: (1) cwnd 기반 송신자 자율제어 (2) 손실을 혼잡신호로 해석
-
cwnd로 네트워크 과부하 방지
II. TCP 혼잡제어의 구성도 및 구성요소
가. TCP 혼잡제어의 구성도
[Slow Start]--cwnd<ssthresh-->[지수증가]
│ 도달
▼
[Congestion Avoidance]--선형증가(AIMD)
│ 손실감지
▼
[Fast Retransmit/Recovery]--cwnd 절반감소
- 증가·감소 반복으로 최적전송률 수렴
나. TCP 혼잡제어의 구성요소
| 구분 | 구성요소 | 설명 |
|---|---|---|
| 윈도우 | cwnd | 혼잡기준 송신윈도우 |
| 윈도우 | ssthresh | 증가방식 전환기준 |
| 알고리즘 | Slow Start | 지수적 초기증가 |
| 알고리즘 | AIMD | 선형증가 급격감소 |
| 손실대응 | Fast Retransmit | 중복ACK시 즉시대응 |
| 손실대응 | Fast Recovery | 손실후 완만한 복구 |
- 4단계 알고리즘이 순환적으로 동작
III. TCP 혼잡제어 추가정보
| 구분 | 내용 | 비고 |
|---|---|---|
| 비교 | 흐름제어는 수신자, 혼잡제어는 망상태 기준 | 목적대상 차이 |
| 관련기술 | CUBIC·BBR 등 신규 알고리즘 대두 | 고대역폭 환경대응 |
| 시사점 | 공정성과 처리량 간 트레이드오프 존재 | 알고리즘 선택 중요 |
- BBR 등 지연기반 알고리즘으로 진화중
6G 이동통신기술
복잡허네.. 나중에 정리
QoS
I. 네트워크 자원 우선제어, QoS의 개요
-
개념: 트래픽별 자원 차등 보장 기술
-
특징: (1) 대역폭·지연 등 성능지표 보장 (2) 트래픽 우선순위 기반 제어
-
한정자원 효율분배로 서비스품질 보장
II. QoS의 구성도 및 구성요소
가. QoS의 구성도
[분류/Classification]→[표시/Marking]
↓
[큐잉/Queuing]→[정책/Policing·Shaping]
↓
[혼잡관리/Congestion Mgmt]→[전송]
- 분류→표시→큐잉→정책 순차 처리
나. QoS의 구성요소
| 구분 | 구성요소 | 설명 |
|---|---|---|
| 트래픽제어 | 분류(Classification) | 트래픽 유형별 식별 |
| 트래픽제어 | 표시(Marking) | DSCP 등 우선순위 태깅 |
| 큐잉기법 | PQ | 우선순위 큐 선처리 |
| 큐잉기법 | WFQ | 가중치 기반 공정분배 |
| 트래픽관리 | 셰이핑 | 트래픽 속도 평활화 |
| 트래픽관리 | 폴리싱 | 초과트래픽 제한·폐기 |
- 제어·큐잉·관리 3범주로 구성
WFQ: Weighted Fair Queue
III. QoS 추가정보
| 구분 | 내용 | 비고 |
|---|---|---|
| 표준 | IntServ vs DiffServ | 흐름기반 대 클래스기반 |
| 관련기술 | SDN 기반 동적 QoS 제어 | 최신 트렌드 |
| 시사점 | 5G·클라우드 환경 필수요소 | 실시간서비스 품질보장 |
- IntServ·DiffServ 대비, SDN 연계 확대
QoS의 모델
I. 자원예약·차등처리 방식, QoS 모델의 개요
-
개념: QoS 구현 위한 표준 아키텍처 방식
-
특징: (1) 흐름별 자원예약 방식 존재 (2) 클래스별 차등처리 방식 존재
-
자원보장 수준따라 모델 상이
II. QoS 모델의 구성도 및 구성요소
가. QoS 모델의 구성도
[Best Effort]
↓
[IntServ] ── RSVP 흐름별 예약
↓
[DiffServ] ── DSCP 클래스별 처리
↓
[MPLS-TE] ── 경로기반 트래픽엔지니어링
- BestEffort→IntServ→DiffServ 발전
나. QoS 모델의 구성요소
| 구분 | 구성요소 | 설명 |
|---|---|---|
| BestEffort | 순서없는 전송 | 품질보장 없는 기본방식 |
| BestEffort | 단순큐잉 | FIFO 방식 처리 |
| IntServ | RSVP | 종단간 자원예약 프로토콜 |
| IntServ | 흐름별 상태관리 | 라우터별 세션정보 유지 |
| DiffServ | DSCP 마킹 | 패킷헤더 우선순위 표시 |
| DiffServ | PHB | 홉별 처리행동 정의 |
- BestEffort·IntServ·DiffServ 3범주
PHB: Per-Hob Behavior
- 개념: 라우터(홉)가 패킷의 DSCP 값을 보고 그 홉에서 어떻게 처리할지 정의한 “행동 규칙”
- 핵심 아이디어: DSCP는 그냥 패킷에 붙이는 “표시(마킹)“일 뿐이고, 그 표시를 보고 라우터가 실제로 무엇을 할지를 정의한 게 PHB입니다. 즉 DSCP는 “이름표”, PHB는 그 이름표에 대응하는 “행동 지침서”인 셈입니다.
- 동작 방식: DiffServ는 흐름 상태를 유지하지 않으므로, 각 라우터는 패킷이 지나갈 때마다 매번 독립적으로 DSCP 값만 보고 로컬하게(hop별로) PHB를 적용 — 이전 홉이 뭘 했는지, 다음 홉이 뭘 할지는 신경 쓰지 않음
III. QoS 모델 추가정보
| 구분 | 내용 | 비고 |
|---|---|---|
| 비교 | IntServ 확장성 낮음 | 라우터 부하 증가 |
| 비교 | DiffServ 확장성 우수 | 대규모망 적합 |
| 시사점 | 대규모망은 DiffServ 채택 | 실무 표준 |
- IntServ 정밀·DiffServ 확장성 대비
(RSVP, DSCP, WFQ 관련 정보)
QoS 모델 관점에서 보면:
- RSVP는 IntServ(통합서비스) 모델의 핵심 프로토콜 — 흐름(flow)별로 자원을 예약
- DSCP는 DiffServ(차별화서비스) 모델의 핵심 마킹 방식 — 패킷 단위로 우선순위 표시
- WFQ는 두 모델 모두에서 활용 가능한 큐잉(스케줄링) 알고리즘 — 실제 전송 순서를 결정하는 실행 메커니즘
즉, RSVP·DSCP는 “어떻게 우선순위를 정할 것인가(정책 계층)“의 문제이고, WFQ는 “정해진 우선순위를 라우터가 실제로 어떻게 큐에서 처리할 것인가(실행 계층)“의 문제입니다. DSCP로 마킹된 패킷을 WFQ가 가중치 기반으로 큐잉해서 내보내는 식으로 함께 동작하는 경우가 많습니다.
1. RSVP (Resource ReSerVation Protocol)
- 개념: 송신자-수신자 간 종단간 대역폭을 사전에 예약하는 시그널링 프로토콜
- 동작: 송신자가 PATH 메시지를 보내면 수신자가 RESV 메시지로 응답하며 경로상 라우터마다 자원을 예약
- 특징: 흐름(session) 단위로 상태를 유지해야 하므로 라우터 부하가 크고, 대규모 네트워크에서는 확장성이 떨어짐
- 활용: 화상회의, VoIP 등 엄격한 대역폭 보장이 필요한 서비스 / MPLS-TE에서도 RSVP-TE 형태로 확장 사용
2. DSCP (Differentiated Services Code Point)
- 개념: IP 헤더의 ToS(Type of Service) 필드 중 6비트를 사용해 패킷의 처리 우선순위를 표시하는 마킹 값
- 동작: 네트워크 진입점(edge router)에서 트래픽을 분류해 DSCP 값을 마킹하면, 이후 각 홉의 라우터는 별도 흐름 정보 없이 이 값만 보고 PHB(Per-Hop Behavior)를 적용
- 특징: 흐름별 상태 유지가 필요 없어 확장성이 우수 → 대규모 백본망에 적합
- 대표 클래스: EF(Expedited Forwarding, 실시간 트래픽), AF(Assured Forwarding, 등급별 보장), BE(Best Effort)
3. WFQ (Weighted Fair Queuing)
- 개념: 트래픽 흐름마다 가중치를 부여해 공정하게 대역폭을 분배하는 큐잉 알고리즘
- 동작: 각 흐름을 별도 큐에 배정하고, 가중치에 비례해 라운드로빈 방식으로 패킷을 서비스 — 우선순위 높은 흐름이라도 다른 흐름을 완전히 굶기지 않음
- 특징: PQ(Priority Queuing)처럼 낮은 우선순위 트래픽이 무한정 대기하는 기아(starvation) 현상을 방지
- 변형: CBWFQ(Class-Based WFQ)는 DSCP 등으로 분류된 클래스별로 대역폭을 보장하도록 확장한 형태 — 실무에서 DiffServ와 결합해 가장 많이 쓰이는 조합
정리하면, RSVP(IntServ 예약)와 DSCP(DiffServ 마킹)는 “누구에게 우선순위를 줄지” 결정하는 상위 정책이고, WFQ는 그 정책을 큐 단에서 실제로 구현하는 스케줄링 메커니즘이라는 관계로 이해하시면 됩니다.
IntServ = Integrated Services (통합 서비스)
“통합”이라는 이름이 붙은 이유는, 기존의 Best Effort(전송 순서 구분 없이 뭉뚱그려 처리)와 달리 하나의 네트워크 안에서 서로 다른 서비스 품질 요구사항을 통합적으로 수용하겠다는 취지에서입니다. 즉 “여러 종류의 트래픽(실시간 음성, 데이터 등)을 하나의 IP망에 통합해서 각각 필요한 품질을 보장한다”는 의미로, RFC 1633(1994)에서 이 이름이 채택됐습니다. 흐름(flow) 하나하나를 개별적으로 통합관리한다는 뉘앙스가 강합니다.
DiffServ = Differentiated Services (차별화 서비스)
“차별화”는 IntServ와 대비되는 철학에서 나온 이름입니다. 흐름 하나하나를 다 예약·관리하는 대신, 트래픽을 몇 개의 클래스로 나누고(differentiate) 클래스별로 차등 대우만 해주면 충분하다는 접근입니다. RFC 2475(1998)에서 이 이름이 정해졌는데, “개별 흐름 구분(per-flow)“이 아니라 “클래스 구분(per-class differentiation)“이라는 점을 이름에서부터 명확히 하려 한 겁니다.
이름이 곧 설계 트레이드오프를 반영
정리하면 두 이름은 우연이 아니라, **“무엇을 단위로 QoS를 처리하느냐”**라는 핵심 차이를 그대로 담고 있습니다:
- IntServ → “통합(Integrated)”: 모든 흐름을 하나하나 통합 관리 → 정밀하지만 무거움
- DiffServ → “차별화(Differentiated)”: 클래스 단위로만 차별 대우 → 가볍지만 상대적으로 성긴 제어
앞서 말씀드린 RSVP(흐름별, IntServ와 짝) vs DSCP(클래스별, DiffServ와 짝)의 구조 차이도 결국 이 이름에서부터 예견된 설계라고 보시면 됩니다.
IntServ와 DiffServ의 관계
한쪽이 무조건 더 “발전된” 것은 아니고, 서로 다른 문제를 해결하기 위한 트레이드오프 관계로 보는 게 정확합니다. 다만 등장 순서와 채택 현황을 보면 왜 이런 오해가 생기는지는 이해가 됩니다.
”발전”처럼 보이는 이유
- 시기: IntServ(RFC 1633, 1994)가 먼저 나왔고, DiffServ(RFC 2475, 1998)가 그 뒤에 등장 — IntServ의 확장성 문제를 해결하려는 목적으로 설계됨
- 채택: 오늘날 인터넷 백본, 대규모 사업자망은 거의 DiffServ 기반 — IntServ는 사실상 특수 목적으로만 남음
이 때문에 “DiffServ가 IntServ를 대체한 더 나은 버전”처럼 보이지만, 정확히는 확장성을 얻는 대신 정밀한 보장을 포기한 트레이드오프입니다.
무엇이 더 나은지는 “무엇을 기준으로 보느냐”에 달림
| 기준 | IntServ 우위 | DiffServ 우위 |
|---|---|---|
| 보장 정밀도 | 흐름별 수학적 보장(대역폭·지연 확정) | 클래스 단위 상대적 보장(확정 아님) |
| 확장성 | 라우터가 흐름 수만큼 상태유지 → 대규모망 불가 | 상태 유지 불필요 → 대규모망 적합 |
| 구현 복잡도 | RSVP 시그널링 전체 경로 필요 | 진입점에서만 마킹, 이후 단순 |
| 적합 환경 | 소규모/폐쇄망, 엄격한 SLA 필요시 | 대규모 공중망, 인터넷 백본 |
즉 IntServ가 “정밀하지만 무거워서” 대규모망에 못 쓰인 반면, DiffServ는 “덜 정밀하지만 가벼워서” 널리 쓰이게 된 것 — 기술적으로 열등해서 밀린 게 아니라, 애초에 노리는 배포 규모(scale)가 다른 설계입니다.
실무에서는 결합해서 쓰기도 함
- MPLS-TE: RSVP-TE처럼 IntServ 계열 시그널링을 코어망 트래픽 엔지니어링에 활용
- 캠퍼스/엔터프라이즈 경계: 소규모 구간엔 IntServ적 정밀제어, 백본 구간엔 DiffServ로 전환하는 하이브리드 설계도 존재
정리하면, DiffServ는 IntServ의 “업그레이드판”이라기보다는 **“확장성 문제를 다른 방식으로 접근한 대안”**이라고 보는 게 기술사 시험 관점에서도 더 정확한 표현입니다.
QoS의 측정요소
I. 성능품질 정량평가 지표, QoS 측정요소의 개요
-
두음: 대처지지손가
-
개념: 네트워크 성능품질 정량평가 지표 집합
-
특징: (1) 대역폭·지연 등 계량화 가능 (2) SLA 계약기준으로 활용
-
정량지표로 서비스품질 객관평가
II. QoS 측정요소의 구성도 및 구성요소
가. QoS 측정요소의 구성도
[대역폭] [지연]
↑ ↑
[지터]←[측정요소]→[손실률]
↓ ↓
[가용성] [처리량]
- 6대 지표가 서비스품질 종합구성 (방사형으로 그리기)
나. QoS 측정요소의 구성요소
| 구분 | 구성요소 | 설명 |
|---|---|---|
| 전송속도 | 대역폭(Bandwidth) | 링크 최대전송용량 |
| 전송속도 | 처리량(Throughput) | 실제 전송성공 데이터량 |
| 시간지표 | 지연(Delay/Latency) | 송수신 종단간 소요시간 |
| 시간지표 | 지터(Jitter) | 패킷도착간격 변이량 |
| 신뢰지표 | 손실률(Packet Loss) | 전송중 유실패킷 비율 |
| 신뢰지표 | 가용성(Availability) | 서비스 정상제공 비율 |
- 속도·시간·신뢰 3범주로 구성
III. QoS 측정요소 추가정보
| 구분 | 내용 | 비고 |
|---|---|---|
| 표준 | ITU-T Y.1541 IP망 QoS등급 | 클래스별 목표치 규정 |
| 관련기술 | RFC 2544 벤치마킹 방법론 | 장비성능 측정표준 |
| 시사점 | 실시간서비스는 지연·지터 민감 | VoIP·영상 품질좌우 |
- ITU-T 표준기반 정량측정 체계
SDN(소프트웨어 정의 네트워크)
(Software-defined Network다. 하드웨어 기반 네트워크에서 소프트웨어로 정의할 수 있는 네트워크로 진화함)
I. 소프트웨어 정의 네트워크, SDN의 개요
-
개념: 제어·전달 분리한 SW기반 네트워크
-
특징: (1) Control/Data Plane 분리 (2) 중앙집중 제어·프로그래밍
-
제어평면 분리로 네트워크 유연성 확보
II. SDN의 구성도 및 구성요소
가. SDN의 구성도
[Application Plane] : 어플리케이션, 오케스트레이션
│ (Northbound API, REST)
[Control Plane] : SDN 컨트롤러
│ (Southbound API, OpenFlow)
[Data Plane] : 스위치, 라우터(전달장비)
- 3계층 구조, North/Southbound API 연동
(Forwarding은 Data Plane이, 나머지 토폴로지 관리, Routing, QoS, 보안, ACL등은 Control Plane에서 한다)
나. SDN의 구성요소
| 구분 | 구성요소 | 설명 |
|---|---|---|
| Control Plane | SDN 컨트롤러 | 네트워크 전체 제어·정책결정 |
| Control Plane | 토폴로지 관리 | 전체 망 구조 실시간 파악 |
| Data Plane | Flow Table | 패킷 처리규칙 저장 |
| Data Plane | 화이트박스 스위치 | 단순 전달기능 수행 |
| 인터페이스 | Northbound API | 응용-컨트롤러 연동 |
| 인터페이스 | Southbound API | 컨트롤러-장비 연동(OpenFlow) |
- Control/Data Plane과 API 계층 연계
III. SDN 추가정보
| 구분 | 내용 | 비고 |
|---|---|---|
| 비교 | 기존망 대비 제어·전달 통합→분리 | 유연성·확장성 향상 |
| 관련기술 | OpenFlow 표준 프로토콜 활용 | ONF 주도 표준화 |
| 시사점 | NFV·클라우드 네트워킹 기반기술 | 자동화 운영 효과 |
- 제어전달 분리로 망 자동화·가상화 촉진
AWS의 VPC같은게 다 SDN을 통해서 구현된거겠네
네, 맞습니다. AWS VPC(Virtual Private Cloud)는 SDN 기술을 기반으로 구현된 대표적 사례예요.
어떻게 연결되는가
- 물리적으로 AWS 데이터센터의 수많은 서버는 실제로는 공유된 물리 네트워크 위에 있지만, VPC는 고객마다 독립된 가상 네트워크(사설 IP 대역, 서브넷, 라우팅 테이블, 보안그룹 등)를 제공합니다.
- 이게 가능한 이유가 바로 SDN의 핵심 원리인 제어와 전달의 분리 때문입니다. AWS는 물리 스위치/라우터(Data Plane)를 하드웨어별로 개별 설정하는 대신, 소프트웨어 컨트롤러(제어 계층)가 전체 네트워크 정책을 중앙에서 관리하고, 이를 각 물리 장비의 Flow 규칙으로 내려보내는 구조를 씁니다.
VPC에 실제로 녹아있는 SDN 개념들
| SDN 개념 | VPC에서의 대응 |
|---|---|
| Control Plane (정책결정) | VPC 설정 API, 라우팅테이블/보안그룹 정책 엔진 |
| Data Plane (전달) | Nitro 카드 등 물리 네트워크 하드웨어 |
| 가상화 | 오버레이 네트워크(VXLAN 등)로 논리적 격리 |
| Flow 기반 제어 | 패킷 단위 매핑 규칙을 통해 가상 네트워크 트래픽을 물리망에 전달 |
특히 AWS는 자체 개발한 Nitro 시스템을 통해 네트워크 가상화 기능 상당 부분을 전용 하드웨어(스마트 NIC)로 오프로드하는데, 이것도 근본적으로는 “제어 로직(정책)은 소프트웨어가 정의하고, 실제 데이터 전달은 최적화된 별도 계층이 수행한다”는 SDN의 사상을 확장한 형태입니다.
참고: AWS가 VPC 구현 방식의 세부 아키텍처를 전부 공개하지는 않기 때문에, “AWS가 내부적으로 OpenFlow를 그대로 쓴다”는 식의 특정 프로토콜 단위까지 확정할 수는 없어요. 하지만 개념적으로 VPC, Azure VNet, GCP VPC 등 클라우드의 가상 네트워크 서비스들은 모두 SDN 원리(제어/전달 분리, 중앙집중 관리, 오버레이 가상화) 위에서 동작한다는 건 업계에서 일반적으로 통용되는 이해입니다.
OpenFlow
I. SDN 표준 프로토콜, OpenFlow의 개요
-
개념: 제어-전달 분리하는 SDN 표준 프로토콜
-
특징: (1) 제어평면·데이터평면 분리 (2) 플로우테이블 기반 제어
-
중앙집중 제어로 네트워크 유연성 확보
II. OpenFlow의 구성도 및 구성요소
가. OpenFlow의 구성도
[Controller(제어평면)]
|
OpenFlow 프로토콜(Secure Channel)
|
[Switch(데이터평면)]
├ FlowTable
├ GroupTable
└ MeterTable
|
[Host/Network]
- 컨트롤러-스위치 간 표준 인터페이스 구조
나. OpenFlow의 구성요소
| 구분 | 구성요소 | 설명 |
|---|---|---|
| 제어부 | Controller | 전체 플로우 정책 결정 |
| 제어부 | Secure Channel | 컨트롤러-스위치 통신로 |
| 데이터부 | Flow Table | 매치·액션 규칙 저장 |
| 데이터부 | Group Table | 다중경로 처리 지원 |
| 메시지 | Controller-to-Switch | 룰 설치·조회 명령 |
| 메시지 | Asynchronous | 이벤트·오류 통지 |
- 제어부·데이터부·메시지 3범주로 구성
III. OpenFlow 추가정보
| 구분 | 내용 | 비고 |
|---|---|---|
| 표준 | ONF에서 버전 관리·표준화 | 최신 1.5.x |
| 비교 | 기존 라우팅 대비 중앙집중 제어 | 정적 라우팅과 대비 |
| 시사점 | 망 구성 유연화, 트래픽 최적화 | SDN 도입 핵심 |
- ONF 표준화, SDN 핵심 프로토콜
IP 주소
I. 논리적 네트워크 식별자, IP 주소의 개요
-
개념: 네트워크상 호스트 논리적 식별주소
-
특징: (1) 계층적 주소체계 (2) 라우팅 경로 결정 기준
-
네트워크 계층 논리주소, 라우팅 근거
II. IP 주소의 구성도 및 구성요소
가. IP 주소의 구성도
IPv4 (32bit)
├─ Network ID : 네트워크 식별
└─ Host ID : 호스트 식별
IPv6 (128bit)
├─ Global Routing Prefix
├─ Subnet ID
└─ Interface ID
- 네트워크ID+호스트ID 계층 구조
나. IP 주소의 구성요소
| 구분 | 구성요소 | 설명 |
|---|---|---|
| 체계 | IPv4 | 32비트 4옥텟 표기 |
| 체계 | IPv6 | 128비트 콜론 표기 |
| 클래스 | Class A~E | 규모별 대역 구분 |
| 클래스 | Subnet Mask | 네트워크/호스트 구분 |
| 할당방식 | 공인IP | 인터넷 유일주소 |
| 할당방식 | 사설IP | 내부망 전용주소 |
- IPv4·IPv6 체계, 클래스·할당방식 구분
III. IP 주소 추가정보
| 구분 | 내용 | 비고 |
|---|---|---|
| 관련기술 | NAT로 사설IP 변환 | 공인IP 절약 |
| 관련기술 | DHCP 동적할당 | 관리부담 감소 |
| 시사점 | IPv4 고갈로 IPv6 전환 | 듀얼스택 병행 |
- NAT·DHCP 연계, IPv6 전환 추세
MAC 주소
I. 물리적 장치 식별자, MAC 주소의 개요
-
개념: 네트워크 장비 고유 물리주소
-
특징: (1) 48비트 고정 하드웨어주소 (2) 데이터링크계층 프레임 전달
-
NIC 제조시 부여된 고유 물리주소
II. MAC 주소의 구성도 및 구성요소
가. MAC 주소의 구성도
MAC Address (48bit, 6byte)
├─ OUI (앞 24bit) : 제조사 식별
└─ NIC ID (뒤 24bit) : 장치 고유번호
- OUI+NIC ID 24bit씩 결합구조
나. MAC 주소의 구성요소
| 구분 | 구성요소 | 설명 |
|---|---|---|
| 구조 | OUI | 제조사 코드 영역 |
| 구조 | NIC ID | 개별 장치 일련번호 |
| 유형 | Unicast | 단일장치 전송용 |
| 유형 | Multicast | 그룹장치 전송용 |
| 관리 | ARP | IP-MAC 주소 매핑 |
| 관리 | MAC 테이블 | 스위치 학습·저장 |
- OUI·NIC 구조, 유니/멀티캐스트 구분 (ARP: Address Resolution Protocol)
III. MAC 주소 추가정보
| 구분 | 내용 | 비고 |
|---|---|---|
| 비교 | IP주소 대비 논리이동 불가 | 물리계층 고정값 |
| 관련기술 | ARP 스푸핑 보안위협 | 위변조 취약 |
| 시사점 | 접근제어 필터링 활용 | MAC 화이트리스트 |
- IP와 대비되는 고정 물리식별자
Port 주소
I. 프로세스 식별자, Port 주소의 개요
-
개념: 전송계층 응용프로세스 식별번호
-
특징: (1) 16비트 0~65535 범위 (2) 다중세션 동시처리 지원
-
전송계층서 프로세스 구분하는 논리번호
II. Port 주소의 구성도 및 구성요소
가. Port 주소의 구성도
Port Number (16bit, 0~65535)
├─ Well-known Port (0~1023)
├─ Registered Port (1024~49151)
└─ Dynamic/Private Port (49152~65535)
- 범위별 3단계 계층 구조
나. Port 주소의 구성요소
| 구분 | 구성요소 | 설명 |
|---|---|---|
| 범위 | Well-known | 표준서비스 예약포트 |
| 범위 | Registered | 등록된 응용포트 |
| 범위 | Dynamic | 임시할당 포트 |
| 프로토콜 | TCP 포트 | 연결지향 세션식별 |
| 프로토콜 | UDP 포트 | 비연결 세션식별 |
| 활용 | Socket | IP+Port 논리연결점 |
- 범위·프로토콜별 포트 구분
III. Port 주소 추가정보
| 구분 | 내용 | 비고 |
|---|---|---|
| 관련기술 | 방화벽 포트필터링 | 보안정책 적용 |
| 관련기술 | NAT/PAT 포트변환 | 다중세션 지원 |
| 시사점 | 불필요포트 차단 필요 | 공격표면 축소 |
- 필터링·변환 통한 보안운영 핵심
전자메일 주소
I. 전자우편 식별자, 전자메일 주소의 개요
-
개념: 사용자와 메일서버 식별하는 주소
-
특징: (1) 로컬파트@도메인 구조 (2) SMTP 기반 전송체계
-
사용자ID+도메인 결합된 고유식별자
II. 전자메일 주소의 구성도 및 구성요소
가. 전자메일 주소의 구성도
user@example.com
├─ Local Part : 사용자 계정명
└─ Domain Part : 메일서버 도메인
└─ DNS MX 레코드로 서버 조회
- 로컬파트@도메인 2단 구성
나. 전자메일 주소의 구성요소
| 구분 | 구성요소 | 설명 |
|---|---|---|
| 구조 | Local Part | 사용자 계정 식별 |
| 구조 | Domain Part | 메일서버 도메인 |
| 프로토콜 | SMTP | 메일 발송 프로토콜 |
| 프로토콜 | POP3/IMAP | 메일 수신 프로토콜 |
| 인프라 | MX 레코드 | 메일서버 DNS 조회 |
| 인프라 | 메일서버 | 송수신 중계 처리 |
- 구조·프로토콜·인프라로 구성
III. 전자메일 주소 추가정보
| 구분 | 내용 | 비고 |
|---|---|---|
| 관련기술 | SPF/DKIM 인증 | 스푸핑 방지기술 |
| 관련기술 | DMARC 정책 | 발신도메인 검증 |
| 시사점 | 피싱메일 대응 필요 | 인증체계 강화 |
- 인증기술로 위변조 방지 강화