| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | ||||
| 4 | 5 | 6 | 7 | 8 | 9 | 10 |
| 11 | 12 | 13 | 14 | 15 | 16 | 17 |
| 18 | 19 | 20 | 21 | 22 | 23 | 24 |
| 25 | 26 | 27 | 28 | 29 | 30 | 31 |
Tags
- 해커톤
- 빅데이터
- Replicaset
- 도커
- 클라우드
- ResourceQuota
- 핸드셰이크
- 해시
- namespace
- 네트워크 가상화
- 온프레미스
- cronjob
- 리소스 풀링
- Web
- 클라우드 네이티브 5회차
- 혼잡제어
- 웹 스토리지
- 하둡
- dns
- OverTheWire
- configmap
- 고가용성
- docker
- goorm
- Urn
- 네트워크
- k8s
- 다중화
- daemonset
- LimitRange
Archives
- Today
- Total
NakedFlower 님의 블로그
오류 제어, 흐름 제어, 혼잡 제어 본문
TCP는 연결형 프로토콜이자 신뢰성 있는 통신을 제공하는 프로토콜!
- 재전송을 기반으로 다양한 오류를 제어
- 흐름 제어를 통해 처리할 수 있을 만큼의 데이터 송수신
- 혼잡 제어를 통해 네트워크가 혼잡한 정도에 따라 전송량 조절
1. 재전송 기반 오류 제어
- 오류 검출과 재전송
- TCP 세그먼트의 체크섬 필드, 충분할까??
- 충분하지 않음
- 데이터가 훼손되어 있는지만 나타내주기 때문
신뢰성을 제대로 보장하려면- 송신 호스트가 송신한 세그먼트에 문제가 발생했음을 인지할 수 있어야 함
- 오류를 감지하게 되면 해당 세그먼트를 재전송할 수 있어야
그렇다면 TCP는 언제 오류를 검출하고 재전송할까
- 중복된 ack 세그먼트를 수신했을 때
- 타임아웃이 발생했을 때
1) 중복된 ACK 세그먼트를 수신했을 때

2) 타임아웃이 발생했을 때
- 호스트가 세그먼트를 전송할 때마다 재전송 타이머(retransmission timer) 시작
- 타임아웃이 발생할 때까지 ACK 세그먼트를 받지 못하면 재전송

문제가 발생한 그 세그먼트를 재전송할 수 있어야겠지?
재전송 기반: ARQ(Automatic Repeat Request, 자동 재전송 요구)
- 수신 호스트의 답변(ACK)과 타임아웃을 토대로 문제점을 진단하고,
- 문제가 생긴 메시지를 재전송함으로써 신뢰성을 확보하는 방식
ARQ의 대표적인 세 가지 방식
- Stop-and-Wait ARQ
- Go-Back-N ARQ
- Selective Repeat ARQ
Stop-and-Wait ARQ
- 제대로 전달했음을 확인하기 전까지는 새로운 메시지를 보내지 않는 방식
- 송신하고 확인받고, 송신하고 확인받고...
- 장점: 단순하지만, 좋은 신뢰성을 보장
- 단점: 네트워크의 이용 효율이 낮아지고 성능이 저하됨
- 송신 호스트(A): 확인 응답을 받기 전에는 더 보내고 싶어도 못 보냄
- 수신 호스트(B): 더 많은 데이터를 처리할 수 있어도 하나씩만 확인 응답
- 문제 해결방법
- 각 세그먼트에 대한 ACK 세그먼트가 도착하기 전이라도 여러 세그먼트를 보낼 수 있어야 함
- 파이프라이닝(pipelining) -> 연속해서 메시지를 전송할 수 있는 기술

Go-Back-N ARQ
- 파이프라이닝 기반 ARQ 일종
- 여러 세그먼트 전송 중 오류가 발생하면 해당 세그먼트부터 전부 재전송
- 순서 번호 n번에 대한 ACK 세그먼트는 'n번만의' 확인 응답이 아닌 'n번까지의 누적 확인 응답'
- -> 누적 확인 응답 (CACK, Cumulative Acknowledgement)

[참고] 빠른 재전송(fast retransmit) - 오늘날의 tcp에서는 대부분 활성화되어 있음
- 재전송 타이머가 만료되기 전이라도 세 번의 동일한 ack 세그먼트를 받았다면 곧바로 재전송
- 타이머가 끝날 때까지 기다리는 시간을 줄일 수 있음
Selective Repeat ARQ
- 선택적으로 재전송: 각각의 패킷들에 대해 ACK세그먼트를 보내는 방식
- Go-Back-N ARQ의 ACK 세그먼트가 누적 확인 응답이라면, Selective Repeat ARQ의 ACK 세그먼트는 개별 확인 응답
- 오늘날 대부분의 호스트는 Selective Repeat ARQ 지원
- Selective Repeat ARQ를 사용하지 않을 경우, Go-Back-N ARQ로 동작

2. 흐름 제어
파이프라이닝 기반 Go-Back-N ARQ/Selective Repeat ARQ
- 파이프라이닝 기반 Go-Back-N ARQ/Selective Repeat ARQ가 정상 동작하려면
- 수신 호스트가 한 번에 얼마나 받아 처리할 수 있는지 반드시 고려해야 함
- 호스트가 한 번에 받아서 처리할 수 있는 세그먼트의 양에는 한계가 있기 때문
한번에 받아서 처리할 수 있는 만큼만 보내주는 것을 흐름제어라고 함
TCP의 흐름 제어
- 송신 호스트가 수신 호스트의 처리 속도를 고려하여 송수신 속도를 균일하게 유지하는 기능
- Stop-and-Wait ARQ를 사용하면 별도의 흐름 제어가 필요하지 않음
- 파이프라이닝 기반의 Go-Back-N ARQ와 Selective Repeat ARQ에서는 흐름 제어 필요
슬라이딩 윈도우(sliding window): TCP 흐름 제어 기법
- 윈도우(window) - 송신 호스트가 파이프라이닝할 수 있는 최대량. 즉, 윈도우의 크기만큼 확인 응답을 받지 않고도 한 번에 전송 가능하다는 의미

- 첫 번째 세그먼트~네 번째 세그먼트까지가 확인 응답을 받지 않고도 전송할 수 있는 양
- 윈도우 크기에서 벗어난 숫자에 해당하는 세그먼트는 전송할 수 없음
이 상태에서 첫번째 세그먼트에 대한 ACK 세그먼트를 받았다면 윈도우는 오른쪽으로 한칸 이동

두번째 세그먼트에 대한 ack 세그먼트를 받았다면 윈도우가 점차 오른쪽으로 미끄러지듯 움직임

송신 측의 윈도우도 있다
- 수신 호스트는 TCP 헤더(윈도우 필드)를 통해 송신 호스트에게 자신이 받을 데이터의 양을 알려줌
- 송신 윈도우 : 헤더로 전달받은 수신 윈도우 토대로 연산

3. 혼잡 제어
혼잡 : 많은 트래픽으로 인해 패킷의 처리 속도가 늦어지거나 유실될 우려가 있는 네트워크 상황
TCP의 혼잡 제어
- 송신 호스트가 혼잡한 정도에 맞춰 유동적으로 전송량을 조절하는 기능
- 흐름 제어의 주체가 수신 호스트라면 혼잡 제어의 주체는 송신 호스트
- 혼잡 윈도우 : 혼잡 없이 전송할 수 있을 법한 데이터양
- -> 혼잡 윈도우가 크면? 한 번에 전송할 수 있는 세그먼트 수가 많음
- -> 혼잡 윈도우가 작으면? (네트워크가 혼잡한 상황) 한번에 전송할 수 있는 세그먼트 수가 적음
- 수신 윈도우는 수신 호스트가 헤더로 알려줌
- 혼잡 윈도우는 송신 호스트가 알아서 직접 계산해서 알아내야 함
이 계산하는 알고리즘을 혼잡제어 알고리즘이라고 함
- 혼잡 제어를 수행하는 일련의 방법
- 가장 기본적인 알고리즘인 AIMD(Additive Increase/Multiplicative Decrease)
- -> 합으로 증가, 곱으로 감소
- -> 혼잡이 감지되지 않는다면 혼잡윈도우를 RTT(Round Trip Time) (메시지를 전송한 뒤 그에 대한 답변을 받는데까지 걸리는 시간)마다 1씩 선형적으로 증가
- -> 혼잡이 감지되면 혼잡 윈도우를 절반으로 떨어뜨리는 동작을 반복 (중복된 ACK 세그먼트를 수신하거나 타임아웃이 발생했을 때 아 지금 혼잡하구나)

혼잡 제어 알고리즘의 종류
- AIMD
- 느린 시작 알고리즘
- -> 혼잡 윈도우를 1부터 시작해서 문제 없이 수신된 ACK세그먼트 하나당 1씩 증가시키는 방식
- -> 혼잡 윈도우는 RTT마다 2배씩 지수적으로 증가: 초기 전송 속도 빠른 확보
TCP의 혼잡 제어 알고리즘
- 느린 시작 임계치(slow start threshold)
- 혼잡 윈도우 값이 계속 증가하다가,
- 혼잡 윈도우 크기가 느린 시작 임계치 이상이 되거나
- 타임아웃이 발생하거나
- 세 번의 중복된 ACK 세그먼트를 수신하면
- 다음 세 가지 방법 중 하나를 선택
| 상황 분류 | 방법 |
| 타임아웃 발생 | 혼잡 윈도우 값을 1로, 느린 시작 임계치를 혼잡이 감지되었을 시점의 혼잡 윈도우 값의 절반으로 초기화한 뒤 느린 시작 재개 |
| 혼잡 윈도우 >= 느린 시작 임계치 | 느린 시작 종료, 혼잡 회피 수행 |
| 세 번의 중복 ACK 발생 | (빠른 재전송 후) 빠른 회복 수행 |
이런 상황에서 종료됨
혼잡 회피 알고리즘
- 혼잡 회피 알고리즘
- RTT마다 혼잡 윈도우를 1MSS씩 증가시키는 알고리즘
- 혼잡 윈도우 크기 선형적으로 증가
- "위워": 느린 시작 임계치를 넘어서면 혼잡 여지가 있으니 조심해서 혼잡 윈도우 증가

빠른 회복(fast recovery) 알고리즘
- 세 번의 중복된 ACK 세그먼트 수신: 빠른 재전송 + 빠른 회복 알고리즘
- 빠른 전송을 위해 느린 시작은 건너뛰고 혼잡 회피를 수행하는 알고리즘
- 단, 빠른 회복 도중이라도 타임아웃이 발생하면 다시 느린 시작을 수행

명시적 혼잡 알림(ECN)
중간 노드의 도움으로 혼잡을 제어하는 ECN
- 혼잡 감지, 혼잡 윈도우 계산, 재전송 : 오로지 송신 호스트의 몫
- 혼잡을 회피하기 위해 네트워크 중간 장치(주로 라우터)의 도움을 받는 방법

ECN을 통한 혼잡 제어
- 송신 호스트만 혼잡 제어를 수행할 경우 문제가 발생한 이후에 비로소 혼잡 제어
- ECN을 이용하면 수신 호스트의 ACK 세그먼트(라우터의 경고)를 통해 더 빠르게 혼잡을 감지

'CS > 네트워크' 카테고리의 다른 글
| HTTP에 대하여 (0) | 2025.10.04 |
|---|---|
| Domain Name Server (0) | 2025.10.03 |
| TCP, UDP, 포트 포워딩 (0) | 2025.10.02 |
| 전송 계층, NAT (0) | 2025.10.02 |
| 라우팅에 대하여 (0) | 2025.10.01 |