TCP 혼잡제어

TCP는 데이터를 안정적으로 보내기 위해 사용되는 전송 계층 프로토콜입니다.

우리가 웹사이트에 접속하거나 파일을 다운로드하거나 영상을 볼 때, 

많은 경우 TCP가 뒤에서 데이터를 안전하게 전달해 줍니다.

TCP는 단순히 데이터를 보내기만 하는 것이 아니라,

 중간에 데이터가 사라지면 다시 보내고, 

순서가 바뀌면 다시 정리하며, 

상대방이 받을 수 있는 속도에 맞춰 전송합니다.

그런데 TCP에서 중요한 기능이 하나 더 있습니다.

바로 혼잡제어입니다.

혼잡제어는 네트워크가 너무 복잡해지거나 막히지 않도록 TCP가 스스로 전송량을 조절하는 기능입니다.

쉽게 말하면 TCP가 "지금 네트워크가 너무 바쁜 것 같은데, 조금 천천히 보내야겠다"라고 판단하는 과정입니다.

이번 글에서는 TCP 혼잡제어가 무엇인지, 왜 필요한지, 

그리고 Linux 환경에서 직접 지연과 손실을 만들어 TCP가 어떻게 반응하는지 확인해 보겠습니다.

 

TCP 혼잡제어란?

TCP 혼잡제어는 네트워크가 감당할 수 있는 만큼만 데이터를 보내도록 전송량을 조절하는 기능입니다.

여기서 중요한 기준은 수신자 한 명의 성능이 아니라, 중간 네트워크의 상태입니다.

예를 들어 내 컴퓨터와 상대 서버가 아무리 빠르더라도, 중간에 있는 라우터나 회선이 느리면 데이터가 몰릴 수 있습니다.

데이터가 너무 많이 몰리면 라우터의 버퍼가 가득 차고, 더 이상 보관하지 못한 패킷은 버려질 수 있습니다.

TCP는 이런 패킷 손실을 보고 네트워크가 혼잡하다고 판단합니다.

TCP는 네트워크 내부를 직접 들여다보는 것이 아닙니다.

대신 패킷 손실, RTT 증가, 중복 ACK, Timeout 같은 현상을 보고 혼잡을 추정합니다.

쉽게 말하면 TCP는 도로 상황을 직접 보는 것이 아니라,

 차가 막혀서 도착 시간이 늦어지는 것을 보고 "길이 막히는구나"라고 판단하는 것과 비슷합니다.

 

혼잡제어가 필요한 이유

네트워크는 도로와 비슷합니다.

차가 적을 때는 빠르게 이동할 수 있지만, 차가 너무 많아지면 정체가 발생합니다.

이때 모든 차가 더 빠르게 달리려고 하면 도로는 더 막히게 됩니다.

오히려 각 차량이 속도를 줄이고 간격을 조절해야 전체 흐름이 안정됩니다.

TCP도 마찬가지입니다.

네트워크가 이미 혼잡한 상태인데 송신자가 계속 많은 데이터를 보내면 패킷 손실이 더 많이 발생합니다.

패킷이 손실되면 TCP는 다시 재전송을 해야 합니다.

그런데 재전송이 많아지면 네트워크에는 또다시 데이터가 증가합니다.

결국 혼잡이 더 심해질 수 있습니다.

(악순환의 반복)

그래서 TCP는 네트워크가 혼잡하다고 판단되면 전송량을 줄입니다.

그리고 네트워크가 다시 안정되었다고 판단되면 전송량을 조금씩 늘립니다.

이 과정이 바로 TCP 혼잡제어입니다.

 

 흐름제어(Flow Control)와 혼잡제어(Congestion Control)의 차이

TCP를 공부할 때 흐름제어와 혼잡제어를 헷갈리는 경우가 많습니다.

두 개념 모두 전송량을 조절한다는 점에서는 비슷합니다.

하지만 기준이 다릅니다.

흐름제어는 수신자가 받을 수 있는 만큼만 보내는 기능입니다.

혼잡제어는 네트워크가 감당할 수 있는 만큼만 보내는 기능입니다.

쉽게 말하면 흐름제어는 수신자를 보호하는 기능이고, 혼잡제어는 중간 도로(네트워크)를 보호하는 기능입니다.

흐름제어에서는 receiver window(rwnd)가 중요합니다.

혼잡제어에서는 congestion window(cwnd)가 중요합니다.

실제로 TCP가 한 번에 보낼 수 있는 데이터 양은 rwnd와 cwnd 중 더 작은 값의 영향을 받습니다.

 

cwnd란?

TCP 혼잡제어에서 가장 중요한 값은 cwnd입니다.

cwnd는 Congestion Window의 줄임말입니다.

cwnd는 TCP가 현재 네트워크에 동시에 보내도 된다고 판단하는 데이터 양입니다.

cwnd가 크면 한 번에 많은 데이터를 보낼 수 있습니다.

cwnd가 작으면 한 번에 적은 데이터만 보낼 수 있습니다.

결국 TCP 혼잡제어는 cwnd를 조절하는 과정이라고 볼 수 있습니다.

네트워크가 안정적이면 TCP는 cwnd를 증가시킵니다.

반대로 네트워크가 혼잡하다고 판단되면 TCP는 cwnd를 감소시킵니다.

쉽게 말하면 cwnd는 TCP의 가속 페달과 비슷합니다.

네트워크(도로상태)가 괜찮으면 페달을 조금 더 밟고, 네트워크(도로상태)가 막히면 페달에서 발을 떼는 것입니다.

 

Slow Start

TCP 연결이 처음 시작되면 TCP는 네트워크가 얼마나 많은 데이터를 감당할 수 있는지 알 수 없습니다.

처음부터 너무 많은 데이터를 보내면 네트워크에 부담을 줄 수 있습니다.

그래서 TCP는 작은 전송량으로 시작합니다.

이 과정을 Slow Start라고 합니다.

Slow Start는 이름만 보면 느리게 증가하는 것처럼 보입니다.

하지만 실제로는 cwnd가 빠르게 증가합니다.

ACK가 정상적으로 돌아오면 cwnd가 지수적으로 증가합니다.

예를 들면 다음과 같은 흐름입니다.


1 → 2 → 4 → 8 → 16


처음에는 조심스럽게 시작하지만, 네트워크가 잘 버틴다고 판단되면 전송량을 빠르게 늘립니다.

여기서 중요한 기준값이 ssthresh입니다.

ssthresh는 Slow Start Threshold의 줄임말입니다.

한국어로는 느린 시작 임계값 정도로 이해할 수 있습니다.

cwnd가 ssthresh보다 작을 때는 Slow Start 방식으로 빠르게 증가합니다.

cwnd가 ssthresh에 도달하면 이후에는 더 조심스럽게 증가합니다.

Congestion Avoidance

cwnd가 어느 정도 커지면 TCP는 더 이상 전송량을 급격하게 늘리지 않습니다.

계속 빠르게 늘리면 네트워크가 갑자기 혼잡해질 수 있기 때문입니다.

이때부터 TCP는 Congestion Avoidance 단계로 들어갑니다.

이 단계에서는 cwnd가 선형적으로 증가합니다.

예를 들면 다음과 같은 흐름입니다.

 

16 → 17 → 18 → 19 → 20


Slow Start처럼 두 배씩 증가하는 것이 아니라, 조금씩 천천히 증가합니다.

Slow Start는 네트워크가 어느 정도까지 버틸 수 있는지 빠르게 탐색하는 단계입니다.

Congestion Avoidance는 혼잡이 발생하지 않도록 조심스럽게 증가하는 단계입니다.

 

TCP가 혼잡을 판단하는 방법

TCP는 네트워크 내부의 라우터 상태를 직접 확인할 수 없습니다.

대신 통신 중에 나타나는 현상을 보고 혼잡을 추정합니다.

대표적인 혼잡 신호는 패킷 손실, 중복 ACK, Timeout, RTT 증가입니다.

첫 번째는 패킷 손실입니다.

중간 네트워크가 혼잡해지면 라우터의 큐가 가득 차고, 일부 패킷이 버려질 수 있습니다.

TCP는 패킷 손실을 혼잡 신호로 판단합니다.

두 번째는 중복 ACK입니다.

수신자가 특정 패킷을 받지 못하면, 이후 패킷을 받아도 같은 ACK를 반복해서 보낼 수 있습니다.

송신자는 같은 ACK가 여러 번 반복해서 오면 중간에 패킷이 손실되었다고 판단합니다.

세 번째는 Timeout입니다.

보낸 패킷에 대한 ACK가 일정 시간 안에 도착하지 않으면 TCP는 Timeout이 발생했다고 판단합니다.

Timeout은 비교적 강한 혼잡 신호입니다.

네 번째는 RTT 증가입니다.

RTT는 Round Trip Time의 줄임말입니다.

한국어로는 왕복 시간입니다.

패킷이 송신자에서 수신자까지 갔다가 ACK가 다시 돌아오는 데 걸리는 시간입니다.

네트워크가 혼잡하면 큐에서 대기하는 시간이 늘어나기 때문에 RTT가 증가할 수 있습니다.

 

Fast Retransmit과 Fast Recovery

TCP는 패킷 손실이 발생했을 때 무조건 Timeout까지 기다리지 않습니다.

같은 ACK가 여러 번 반복해서 도착하면 특정 패킷이 손실되었다고 판단하고 빠르게 재전송합니다.

이 기능을 Fast Retransmit이라고 합니다.

Fast Retransmit은 말 그대로 빠른 재전송입니다.

Timeout까지 기다리지 않고 손실된 패킷을 다시 보내기 때문에 성능 저하를 줄일 수 있습니다.

Fast Recovery는 손실 이후에 전송량을 완전히 처음부터 다시 시작하지 않고, 

어느 정도 회복 상태를 유지하면서 다시 증가시키는 방식입니다.

Fast Retransmit은 손실된 패킷을 빨리 다시 보내는 기능입니다.

Fast Recovery는 손실 이후 cwnd를 적절히 조절하면서 회복하는 기능입니다.

 

실험 환경

이번 실험은 Linux VM 2대를 사용해 진행했습니다.

하나는 Client 역할을 하고, 다른 하나는 Server 역할을 합니다.

Client에서 Server로 TCP 트래픽을 보내고, Client 쪽에서 인위적으로 지연과 패킷 손실을 발생시킵니다.

이를 통해 정상 상태와 혼잡 상태에서 TCP 동작이 어떻게 달라지는지 확인합니다.

실험에 사용한 도구는 다음과 같습니다.

iperf3 : TCP 트래픽을 발생시키고 처리량을 측정
ss : TCP 소켓 상태를 확인
tc : 지연, 손실, 대역폭 제한을 설정
tcpdump : 패킷을 캡처
Wireshark : 캡처한 패킷을 분석

 

실험 준비

Client와 Server에 필요한 패키지를 설치합니다.

sudo apt update
sudo apt install -y iperf3 iproute2 tcpdump

apt update는 설치 가능한 패키지 목록을 최신 상태로 갱신합니다.

-y 옵션은 설치 여부를 물어볼 때 자동으로 yes를 입력한다는 의미입니다.

iperf3는 네트워크 성능 측정 도구입니다.

iproute2는 ip, ss, tc 같은 네트워크 관련 명령어를 포함하는 패키지입니다.

tcpdump는 패킷을 캡처하는 도구입니다.

 

정상 네트워크 상태 측정

먼저 Server에서 iperf3를 서버 모드로 실행합니다.

iperf3 -s

-s 옵션은 server mode를 의미합니다.

Server가 TCP 트래픽을 받을 준비를 하는 것입니다.

이제 Client에서 Server로 TCP 트래픽을 보냅니다.

iperf3 -c 서버IP주소 -t 30 -i 1

-c 옵션은 client mode를 의미합니다.

-t 30은 30초 동안 테스트한다는 의미입니다.

-i 1은 1초마다 측정 결과를 출력한다는 의미입니다.

정상 상태에서는 처리량이 비교적 높고 안정적으로 나타납니다.

패킷 손실이 거의 없기 때문에 재전송도 적게 발생합니다.

 

 

TCP 내부 상태 확인

iperf3 실행 중에 다른 터미널을 열고 ss 명령어로 TCP 내부 상태를 확인합니다.

watch -n 1 "ss -ti dst 서버IP주소"

예시는 다음과 같습니다.

watch는 특정 명령어를 반복 실행하는 명령어입니다.

-n 1은 1초마다 반복한다는 의미입니다.

-t 옵션은 TCP 소켓만 확인한다는 의미입니다.

-i 옵션은 TCP 내부 정보를 자세히 보여준다는 의미입니다.

목적지 IP를 기준으로 필터링할 때 사용합니다.

이 명령어를 실행하면 rtt, cwnd, retrans 같은 정보를 확인할 수 있습니다.

rtt는 왕복 시간입니다.

cwnd는 혼잡 윈도우입니다.

retrans는 재전송 정보를 의미합니다.

정상 상태에서는 rtt가 비교적 낮고, retrans가 거의 발생하지 않습니다.

cwnd는 네트워크 상태에 따라 증가하면서 TCP가 보낼 수 있는 데이터 양을 조절합니다.

 

RTT는 약 0.915ms로 매우 낮게 측정되었고, cwnd는 638 MSS까지 증가한 상태입니다.

MSS가 1448바이트이므로 cwnd 638은 약 924KB 정도의 데이터를

ACK를 기다리는 동안 동시에 네트워크에 보낼 수 있다는 의미입니다.

이를 바탕으로 cwnd × MSS ÷ RTT를 계산하면

TCP가 현재 상태에서 보낼 수 있다고 추정하는 송신 가능 속도는 약 8.06Gbps입니다.

하지만 delivery_rate는 약 4.83Gbps로 표시됩니다.

delivery_rate는 ACK를 기준으로 실제 전달이 확인된 최근 전송 속도에 가까운 값입니다.

send 값은 현재 cwnd와 RTT를 기준으로 계산한 송신 가능 속도이고,

delivery_rate는 실제 ACK 흐름을 기준으로 확인된 최근 전달 속도입니다.

따라서 이 화면은 계산상 송신 가능 속도는 약 8.06Gbps이지만,

실제 ACK 기준 최근 전달 속도는 약 4.83Gbps 수준임을 보여줍니다.

또한 bytes_retrans 값은 1,093,240바이트이고, 전체 bytes_sent 값은 6,599,187,749바이트입니다.

이를 기준으로 계산하면 재전송 바이트 비율은 약 0.016% 정도입니다.

retrans 값은 0/755로 표시됩니다.

이는 현재 재전송 대기 중인 세그먼트는 0개이고, 누적 재전송 세그먼트는 755개 발생했다는 의미입니다.

전송 과정에서 일부 재전송은 있었지만 전체 전송량에 비해 비율이 매우 낮고,

캡처 시점에는 재전송이 계속 증가하는 상태는 아닙니다.

따라서 이 화면은 정상적인 TCP 대량 전송 중

cwnd, RTT, 송신 가능 속도, 실제 전달 속도, 재전송 상태를 함께 확인한 예시로 볼 수 있습니다.

 

 

인위적인 혼잡 환경 만들기

이제 Client에서 tc 명령어를 사용해 인위적인 혼잡 환경을 만듭니다.

먼저 네트워크 인터페이스 이름을 확인합니다.

ip -br addr

 

ip는 네트워크 인터페이스와 주소 정보를 확인하는 명령어입니다.

-br 옵션은 brief의 줄임말입니다.

결과를 간단하게 보여줍니다.

출력 결과에서 실제 통신에 사용하는 인터페이스 이름을 확인합니다.

예를 들어 eth0, ens33, enp0s3 같은 이름이 나올 수 있습니다.

이후 해당 인터페이스에 지연, 손실, 속도 제한을 적용합니다.

sudo tc qdisc add dev eth0 root netem delay 100ms loss 2% rate 5mbit

여기서 eth0는 본인 환경의 인터페이스 이름으로 바꿔야 합니다.

tc는 traffic control의 줄임말입니다.

Linux에서 트래픽 제어를 할 때 사용합니다.

qdisc는 queueing discipline의 줄임말입니다.

패킷이 나가기 전에 줄을 서는 방식을 의미합니다.

add는 새로운 규칙을 추가한다는 의미입니다.

dev eth0는 eth0 인터페이스에 적용한다는 의미입니다.

root는 최상위 qdisc에 적용한다는 의미입니다.

netem은 network emulator의 줄임말입니다.

네트워크 지연, 손실, 중복, 순서 변경 등을 인위적으로 만들 수 있습니다.

delay 100ms는 패킷에 100ms 지연을 추가한다는 의미입니다.

loss 2%는 패킷의 2%를 손실시킨다는 의미입니다.

rate 5mbit는 대역폭을 5Mbps로 제한한다는 의미입니다.

이 명령어는 eth0로 나가는 패킷에 100ms 지연을 추가하고,

2% 패킷 손실을 발생시키며, 속도를 5Mbps로 제한하는 명령어입니다.

혼잡 상태에서 TCP 측정

혼잡 조건을 적용한 후 다시 iperf3를 실행합니다.

정상 상태와 비교하면 처리량이 감소하는 것을 확인할 수 있습니다.

대역폭을 5Mbps로 제한했기 때문에 iperf3 결과도 제한된 속도 근처로 나타납니다.

또한 패킷 손실이 발생하기 때문에 TCP 재전송이 증가할 수 있습니다.

TCP는 손실을 혼잡 신호로 판단하고 cwnd를 조절합니다.

따라서 정상 상태와 비교했을 때 cwnd가 불안정하게 변하거나 감소하는 모습을 확인할 수 있습니다.

 

 

 

 

혼잡 상태에서 TCP 내부 상태 확인

혼잡 상태에서도 ss 명령어를 다시 실행합니다.

정상 상태와 비교해서 봐야 할 부분은 rtt, retrans, cwnd입니다.

먼저 rtt를 확인합니다.

delay 100ms를 추가했기 때문에 rtt가 정상 상태보다 증가합니다.

다음으로 retrans를 확인합니다.

loss 2%를 적용했기 때문에 재전송이 발생할 수 있습니다.

마지막으로 cwnd를 확인합니다.

패킷 손실이 발생하면 TCP는 네트워크가 혼잡하다고 판단하고 cwnd를 줄입니다.

혼잡 상태에서는 TCP가 전송량을 계속 무리하게 늘리지 않고,

네트워크 상태에 맞춰 조절하는 것을 확인할 수 있습니다.

 

 

tcpdump와 Wireshark를 이용한 패킷 확인

 

TCP 재전송과 중복 ACK를 더 자세히 보기 위해 tcpdump로 패킷을 캡처합니다.

 

먼저 tcpdump와 Wireshark를 다운받습니다.

 

sudo apt install -y tcpdump wireshark tshark

Client에서 다음 명령어를 실행합니다.

sudo tcpdump -i (해당인터페이스) -nn -w tcp_congestion.pcap "host 서버IP and tcp port (iperf포트)"

 

-i eth0는 eth0 인터페이스에서 패킷을 캡처한다는 의미입니다.

-w tcp_congestion.pcap은 캡처 결과를 tcp_congestion.pcap 파일로 저장한다는 의미입니다.

host IP는 해당 IP와 오가는 패킷만 캡처한다는 의미입니다.

(IP에 해당 IP입력하시면 됩니다)

캡처한 pcap 파일은 Wireshark에서 열 수 있습니다.

Wireshark에서 재전송 패킷을 확인하려면 다음 필터를 사용합니다.

tshark -r tcp_congestion.pcap -Y "tcp.analysis.retransmission"

-r tcp_congestion.pcap
→ tcp_congestion.pcap 파일을 읽습니다.

-Y "tcp.analysis.retransmission"
→ TCP 재전송 패킷만 필터링해서 보여줍니다.

중복 ACK를 확인하려면 다음 필터를 사용합니다.

tshark -r tcp_congestion.pcap -Y "tcp.analysis.duplicate_ack"

재전송 패킷이 보인다면, TCP가 손실된 데이터를 다시 보내고 있다는 의미입니다.

중복 ACK가 보인다면, 수신자가 특정 구간의 패킷을 받지 못해 같은 ACK를 반복해서 보내고 있다는 의미입니다.

손실율을 2%로 설정해놔서 상당히 많은 로그가 남아 일부만 캡쳐했습니다.

 

실험 결과 비교

정상 상태와 혼잡 상태를 비교하면 TCP의 동작 차이를 확인할 수 있습니다.

먼저 정상 상태에서는 대역폭이 비교적 높고 안정적으로 유지됩니다.

패킷 손실이 거의 발생하지 않기 때문에 재전송(손실율이 낮음)도 거의 나타나지 않습니다.

또한 RTT도 낮게 유지되며, TCP는 네트워크가 안정적이라고 판단하고 cwnd를 점진적으로 증가시킵니다.

반면 혼잡 상태에서는 대역폭이 감소합니다.

이번 실험에서는 tc 명령어를 이용해 100ms 지연, 2% 패킷 손실, 5Mbps 속도 제한을 적용했습니다.

그 결과 정상 상태보다 RTT가 증가했고, 패킷 손실로 인해 재전송도 발생했습니다.

TCP는 이러한 손실과 지연을 혼잡 신호로 판단합니다.

그래서 cwnd를 계속 무리하게 늘리지 않고, 상황에 따라 줄이거나 다시 천천히 증가시키면서 전송량을 조절합니다.

정상 상태에서는 TCP가 전송량을 늘리는 방향으로 동작하고,

혼잡 상태에서는 네트워크가 더 악화되지 않도록 전송량을 조절하는 방향으로 동작합니다.

이 결과를 통해 TCP가 혼잡한 네트워크 환경에서 무작정 데이터를 계속 보내지 않는다는 것을 확인할 수 있습니다.

TCP는 패킷 손실, RTT 증가, 중복 ACK, Timeout 같은 신호를 보고 네트워크 혼잡을 추정합니다.

그리고 cwnd를 조절하여 전송량을 줄이거나 다시 천천히 늘립니다.

결국 TCP 혼잡제어는 네트워크 전체가 무너지지 않도록 송신자가 스스로 속도를 조절하는 기능입니다.

 

실험 후 설정 제거

tc로 적용한 네트워크 제한은 실험 후 반드시 제거해야 합니다.

sudo tc qdisc del dev (해당인터페이스) root

tc qdisc del은 적용된 트래픽 제어 규칙을 삭제한다는 의미입니다.

dev 해당 인퍼테이스는 해당 인터페이스에서 삭제한다는 의미입니다.

root는 최상위 qdisc를 삭제한다는 의미입니다.

삭제 후에는 다음 명령어로 확인할 수 있습니다.

tc qdisc show dev 해당인터페이스

설정이 제거되면 지연, 손실, 대역폭 제한이 더 이상 적용되지 않습니다.

 

실험할 때 주의할 점

실제 Linux 환경에서는 사용 중인 TCP 혼잡제어 알고리즘에 따라 cwnd 변화가 조금 다르게 보일 수 있습니다.

현재 사용 중인 혼잡제어 알고리즘은 다음 명령어로 확인할 수 있습니다.

sysctl net.ipv4.tcp_congestion_control

사용 가능한 혼잡제어 알고리즘은 다음 명령어로 확인할 수 있습니다.

sysctl net.ipv4.tcp_available_congestion_control

따라서 실험 결과가 알고리즘마다 완전히 똑같이 나오지 않더라도 이상한 것은 아닙니다.

중요한 것은 패킷 손실이나 지연이 발생했을 때 TCP가 전송량을 조절한다는 흐름을 확인하는 것입니다.

 

 

 

 

정리

 

TCP 혼잡제어는 네트워크가 혼잡해지지 않도록 송신자가 스스로 전송량을 조절하는 기능입니다.

TCP는 네트워크 내부 상태를 직접 볼 수 없습니다.

대신 패킷 손실, 중복 ACK, RTT 증가, Timeout 같은 현상을 보고 혼잡을 추정합니다.

정상 상태에서는 cwnd를 증가시켜 더 많은 데이터를 보냅니다.

반대로 혼잡이 감지되면 cwnd를 줄여 네트워크에 보내는 데이터 양을 감소시킵니다.

이번 실험에서는 iperf3로 TCP 트래픽을 발생시키고, tc netem으로 지연과 손실을 인위적으로 만들었습니다.

그 결과 혼잡 상태에서 처리량이 감소하고, RTT와 재전송이 증가하는 것을 확인할 수 있었습니다.

또한 ss 명령어를 통해 cwnd, rtt, retrans 같은 TCP 내부 정보를 확인할 수 있었습니다.

이를 통해 TCP가 혼잡한 네트워크 환경에서 무작정 데이터를 계속 보내는 것이 아니라, 

네트워크 상태에 맞춰 전송량을 조절한다는 것을 확인할 수 있었습니다.

결국 TCP 혼잡제어의 핵심은 간단합니다.

네트워크가 괜찮아 보이면 전송량을 늘립니다.

네트워크가 혼잡해 보이면 전송량을 줄입니다.

그리고 다시 안정되면 천천히 전송량을 회복합니다.

TCP 혼잡제어는 인터넷 전체가 안정적으로 동작하기 위해 필요한 핵심 기능입니다.