[네트워크] TCP 혼잡 제어

네트워크 관련 글 순서(참조 영상 기준)

애플리케이션 계층
- 네트워크 애플리케이션의 원리
- DNS
- TCP를 이용한 Socket 프로그래밍

전송계층
- 전송 계층 서비스의 원리
- rdt 원리
- 연결 지향 전송: TCP
- TCP 흐름 제어(3-way handshake, 4-way handshake)
- TCP 혼잡 제어

네트워크 계층
- 네트워크 계층 서비스
- Network Address Translation(NAT), DHCP
- 라우팅 알고리즘(Link State, Distance Vector)
- 계층적 경로 변경(AS)

링크 계층
- 다중 엑세스 프로토콜
- LANs(근거리 통신망)

무선 및 모바일 네트워크
- 무선 네트워크

웹 요청 시 일어나는일

네트워크 보안
- 대칭키 & 공개키,RSA 암호화
- Secure e-mail, SSL, MAC
- IPSec(ESP), Firewall(방화벽)

 

TCP 혼잡 제어(TCP Congestion control)

 

혼잡(congestion): 네트워크에서 처리할 수 있는 양보다 더 많은 데이터가 들어왓을 때 나타나는 현상

 

전에 배웠던 흐름 제어는 1개의 TCP Sender 와 Reciver간의 overflow에 대해서 다루지만,

혼잡제어는 수많은 TCP에 의해 데이터를 받는 경우로 흐름제어에 비해 직관적이지 않다.

 

---

 

시나리오

1) 2개의 송신자. 무한 버퍼를 갖는 하나의 라우터

 

첫번째 시나리오 상황에선, 라우터의 버퍼가 무한대인 상황으로 실제론 없는 경우이다.

 

두 호스트 A,B는 λ 만큼의 속도로 데이터를 라우터에 제공하고, 그에 대한 수신측의 처리량도 λ가 된다.

그래서 A,B가 보낼 수 있는 최대  속도로 전송해도, 라우터에 공간은 무한하기때문에 언젠가는 다 서버에 전송되어서 재전송할 필요도 없다.

 

첫번째 시나리오에서의 연결 성능.

R: 출력 링크의 가능한 출력량

 

두 호스트가 동시에 보내므로, R/2가 올바른 전송률. 전송속도가 R/2보다 커져봤자 처리량은 동일.

 

오른쪽 그림은 한 호스트의 속도에 따른 지연량이다. 빠른 속도로 보내면 라우터의 버퍼에 무한대로 쌓여 딜레이가 크게 증가한다.

2) 2개의 송신자. 유한 버퍼를 갖는 하나의 라우터

 

위와 다르게 라우터의 버퍼가 유한하다.

 

이 경우 버퍼가 오버플로우가 발생할 수 있으며(데이터 유실), 발생 시 재전송이 필요하다.

 

두번째 시나리오는 3가지의 상황에 따라 다르다.

 

상황1) 호스트가 라우터의 버퍼가 비어있는지 알고, 비어있을때만 패킷 송신

-> 현실적으로 불가능하지만^[각주:1]이땐 1번 시나리오와 같이 손실 발생 X

 

 상황2) 호스트는 패킷이 손상된 것을 알았을때 재전송

-> 현실적으론 한정된 공간의 라우터에 데이터를 계속 보내면 유실될테고,

유실된 것을 재전송하게 됨.점차 R/2에 가까워지는 구조.(실제로 필요한 양보다 더 많은 양이 나감)

 

상황3) 유실 여부는 모르지만, 타임아웃을 통해 재전송하게 됨.

 

 

2,3번 상황을 보면 많이 보내서 네트워크가 막혔는데, 더 많은 데이터를 보내게 된다.(재전송)

 

 

3)  4개의 송신자. 유한 버퍼 라우터. 멀티홉 경로

 

가장 현실적인 시나리오이다.

 

upstream 라우터(호스트 앞)를 건너 마지막 downStream 라우터(도착지점 앞)를 거쳐서 가게 되는데,

거쳐가는 라우터 중 한 군데에서 꽉 차 있다면 데이터가 버려진다.

(라우터의 자원을 사용하면서 가다가 버퍼가 꽉찬 라우터를 만나면 버려지는데 그럼 기존에 자원을 쓴건 낭비가 되어버림)

 

기존엔 많이 보내면 보낼수록 처리량이 많아졌다면, 이건 특정시점 이후 떨어지게 됨.

 

이 특정시점. 즉 네트워크 혼잡상황을 만들지 않는 양을 찾아야한다.

 

 

네트워크의 상황은 어떻게 파악하냐면, 세그먼트에 대한 피드백을 근거해서 확인한다.

피드백이 잘 오면 네트워크상황이 괜찮구나. 안오면 혼잡상황이구나라고 판단

 

여기서 혼잡상황을 안만들게 데이터를 보내야하는데, 그 방법이 윈도우 사이즈를 잘 정하는 것이다.

 

 

window 사이즈 정하는 법

1) reciver window: 흐름제어에서 reciver buffer에 의해 정해짐

2) congestion window : 네트워크가 받아들일 수 있는 양

 

이 두가지 윈도우 중 작은 값으로 윈도우 사이즈가 정해진다.

(윈도우를 사용하는 이유는 오버플로우가 일어나지 않게 하는것!)

 

그래서 혼잡제어에선 conditon window를 결정하는 것이 중요하다.

 

---

혼잡제어 원리

 

AIMD (Additive Increase Multiplicative Decrease)

-> 점진적 증가, 지수적 감소(절반씩 줄어듬)

 

additive increase : 매 RTT마다 1 MSS^[각주:2]씩 WS(window size) 증가한다.

multiplicative decrease : 손실 감지되면 WS를 절반으로 줄어든다.

 

cnwd^[각주:3]는 RTT마다 1MSS를 보내고, 피드백을 받으면 그만큼 컨디션 윈도우를 점진적으로 늘림 (additive increase)

 

데이터 유실이라고 생각되면, 사이즈를 절반으로 줄인다(multiplicative decrease)

 

 

기본적 혼잡제어 기법

1) Slow Start

1MSS 씩 점진적으로 늘리면 윈도우 사이즈가 커지는데 오래 걸리기 때문에 일정 지점(ssthresh)까진 지수적 증가를 한다.

 

2) Congestion Avoidance

네트워크에 혼잡상황 유발하기 쉬운 구간에선 1mss만큼 증가

 

 

근데 혼잡상황이라고 추측하는 데이터 유실은 두가지 상황에서 확인 가능하다.

1) 타이머 초과

2) 3 duplicate acks

 

둘중에 혼잡상황을 더 확인 가능한건 타이머초과이다.

dup acks는 앞에꺼 이후에 뒤에꺼가 받아졌다고 피드백이 계속 오는거니까 혼잡하지 않다고 판단할수도 있다.

 

 

 

데이터 유실 시 대응 방법

 

1) TCP Tahoe

유실이 확인 된 순간 윈도우 사이즈를 다시 원점으로 돌아가서 1MSS로 한다.

쓰레시홀드(ssthresh)는 발생지점 윈도우사이즈의 절반에 해당하는걸로 설정해둔다.

 

 

2) TCP RENO

유실 상황 중 3 dup acks상황에선 유실발생지점에서 윈도우사이즈를 절반으로 줄이고, 쓰레시홀드도 절반 설정

 

 

TCP throughput

TCP 전송속도를 뜻함.

 

결국 다시 돌아와서 TCP를 사용할때 전송속도를 정하는건 네트워크가 결정한다.

고정된 값이 아닌 네트워크의 상황에 따라 결정된다.

 

UDP는 애플리케이션이 결정한다.

 

 

TCP Fairness

 

같은 게이트웨이를 사용하는 각각의 디바이스에서 네트환경을 보면서 전송속도를 정할텐데, 각각의 디바이스가 공평한 전송속도를 가질 수 있는가

 

놀랍게도 이렇게 이루어짐

 

라우트의 공간을 R이라고 쳤을때,

 

처음엔 다르게해서 속도를 올리다가 혼잡상황을 발견하면 서로 1/2씩 줄이게될테고,

반복되면 각각의 디바이스가 비슷한 속도를 수렴되게 된다.

 

 

 

---

참조

 

KOCW 네트워크 강의 - 한양대 2018 1학기 이석복 교수님

컴퓨터네트워크

https://suhwanc.tistory.com/107

7. TCP 혼잡제어

http://blog.skby.net/tcp-%ED%98%BC%EC%9E%A1%EC%A0%9C%EC%96%B4/

TCP 혼잡제어 > 도리의 디지털라이프

 

1. 빈 공간이 있는지 없는지 알 수 없음 [본문으로]
2. 맥시멈 세그먼트 사이즈 [본문으로]
3. 혼잡 윈도우 사이즈 [본문으로]