네트워크: Transport layer 정리3 (TCP Flow Control, Congestion Control...)

네트워크: Transport layer 정리2 (신뢰적 데이터 전송의 원리 Reliable Data Transfer)

 

이전의 포스팅에서 한 호스트에서 다른 호스트까지 신뢰적인 데이터 전송을 하기 위해

전송계층에서 일어나는 RDT에 대해 알아보았다. 

 

특히 전송 과정에서 패킷손실을 막기 위한 방법으로 타이머가 도입되었다. 

 

이번 포스팅에서는 타이머의 간격이 어느정도가 적당한지부터 시작한다. 

 

 

 

 

< TCP의 Timeout period 설정하기 >

 

TCP의 timout 주기는 어느정도가 적당할까?

 

RTT(Round Time Trip)정도의 길이를 기준으로 삼으면 좋을 것 같지만,

RTT는 변하는 값이므로 RTT를 timeout period로 정하기에는 다음과 같은 문제가 생긴다. 

 

 

1) TCP timeout이 RTT보다 작다면? 

premature timeout이 일어나고 불필요한 재전송이 늘어난다.

 

2) TCP timeout이 RTT보다 크다면? 

segment loss에 대한 반응이 너무 느려진다.

 

 

가장 이상적인 것은 TCP timeout이 RTT보다 살짝 큰 경우이다.  

 

변하는 RTT에 대비하여 TCP timeout을 정하기 위해 다음과 같은 방식으로 추정 RTT를 구한다.

 

이전의 Estimated RTT 값과 현재 측정한 Sample RTT을 이용해 현재의 Estimated RTT값을 구한다.

 

 

 

 

TCP timeout보다 estimated RTT값이 더 커야 한다. 

 

이를 더 확실하게 하기 위해, estimated RTT 값에 추가적으로 4 x safety margin을 더한다.

 

다음과 같이 DevRTT(safety margin)를 구해서 총 Timeout interval을 구할 수 있다. 

 

 

 

 

 

 

 

< TCP fast retransmit >

 

종종 TCP time-out period가 길어져서 ACK가 중복으로 와도 timeout이 끝날때까지 기다려야 하는 경우가 있다. 

 

그래서 TCP는 더 빠른 재전송을 위해 다음과 같은 성질을 이용한다.

 

segment가 loss되었을 때 중복 ACK(duplicate ACKs)가 연속적으로 오는데 이때

sender가 동일한 ACK를 연속 3번 받았을 때 receiver에게 segment를 재전송한다.   

 

위와 같은 방식 사용한다면 timeout이 끝날때까지 기다리지 않아도 sender는 재전송이 가능해진다.

 

여기서 세번의 중복 ACK를 받는 것을  "Triple Duplicate ACKS"라 한다.

 

 

 

receiver는 seq100 데이터를 기다리는 상태 

seq100 이후 데이터가 3번연속으로 와서 sender에게 같은 ACK를 세번 보낸다.

 

동일한 ACK를 세번 받은 sender는 receiver가 패킷을 받지 못했음을 알고 패킷 재전송을 한다.   

 

 

 

 

 

< TCP flow control >

 

다음과 같은 상황을 통해 TCP flow control에 대해 알아본다. 

 

 

패킷을 주고 받는 과정에서 네트워크 계층에서 전송계층으로 패킷들이 도착하고 

이때 전송계층의 socker receiver buffer에 패킷들이 쌓인다.  

 

마찬가지로 응용계층에서는 필요한 패킷들을 전송계층의 socker receiver buffer에서 찾아간다.

 

하지만 갑자기 너무 많은 패킷들이 TCP 소켓에 들어오면

receiver 버퍼에 너무 많은 데이터가 쌓여 loss될 수 있다.

 

그래서 receiver는 자신이 받을 수 있는 바이트 수 (사용하지 않은 버퍼 크기, receive window)를

sender에게 전송하여, receiver의 buffer가 overflow되지 않도록 조절한다.

 

 

 

 

 

< TCP Connection Management >

 

sender와 receiver는 데이터를 교환하기 전 handshake를 한다. 

 

handshake를 통해 connection에 있어 필요한 parameter를 공유한다.

 

 

1. TCP 3-way handshake

 

 

 

- client는 임의의 seq num x와 synbit를 생성한 후, server에게 전송

- server는 seq num y와 synbit를 생성하고 받은 seq num에 대한 synACK도 보낸다.

- server로 부터 메시지를 받는 순간 client는 connection 설정이 완료

- 마찬가지로 server또한 client로부터 ACK를 받으면서 connection 설정 완료

 

 

 

2. Closing connection 

 

 

 

- client는 server에게 Fin bit = 1인 segment를 보냄으로써 연결을 끊겠다는 것을 알린다.

(데이터는 보낼 수 없지만 받을 수 있는 상태가 된다)

 

- server는 여전히 데이터를 보낼 수 있으며 마저 보내야할 데이터를 다 보낸다. 

- 다 보낸 후, 연결을 끊겠다는 Finbit를 보낸다. 

- 그리고 finish에 대한 ACK를 받은 후 server 또한 연결을 끊는다.

- 자신이 보낸 finbit에 대한 ACK를 각각 받으면 connection이 close된다. 

 

 

 

 

 

< TCP Congestion Control >

 

바로 위에서 다뤘던 flow control과 congestion control과 비슷해보이지만 다르다. 

 

flow control의 경우 sender와 receiver사이의 overflow를 다루지만,

congestion control은 수많은 노드들에 의해 데이터를 받는 경우로

flow control보다 훨씬 복잡한 케이스다. 

 

congestion이 발생하면 라우터에서 buffer overflow가 발생해 packet loss가 일어날 뿐만 아니라 

라우터 buffer에서 발생한 queuing delay로 인해 delay시간이 길어질 수도 있다. 

 

그렇다면 TCP는 이러한 혼잡을 어떻게 제어할까?

 

결론적으로 말하면 AIMD(Additive increase multiplicative decrease)라는 방식을 사용해 

sender는 transmission rate(window size)를 조절한다.

 

여기서 additive increase는 패킷 손실이 일어나기 전까지

transmission rate(cwnd)를 linear하게 증가시키는 것을 의미하고

 

multiple decrease는 패킷 loss가 발생한 후

transmission rate(cwnd)를 감소시켜야할 때는 절반씩 감소시키는 것을 의미한다. 

 

 

 

(톱날 같이 생겼다)

 

 

 

※ cwnd : congestion window size

 

sender는 cwnd만큼의 데이터를 보낸다.

 

네트워크가 여유 있으면 cwnd를 증가시키면 그렇지 않다면 감소시키는 효율적이다. 

 

 

 

1. TCP slow start 

 

connection이후, increase rate는 loss 발생전까지 exponent하게 증가한다.

 

매 RTT마다 두배씩 증가하며 start되는 시점에서만 느리다고 해서 slow start라고 이름 지었다. 

 

 

 

 

2.  Loss에 대한 대응 방법

 

Loss는 크게 두가지 방식으로 발생한다.

 

1) 타임아웃이 일어나서 loss가 발생한경우 

 

이는 심각한 경우로 생각하기 때문에 cwnd를 1MSS로 초기화한다. 

이후 slow start로 증가하다가 threshold를 넘기면 linear하게 증가한다. 

 

 

2) 3 duplicate ACK의 경우(TCP RENO 방식을 사용)

 

1번의 경우보다 심각하지 않기 때문에 

cwnd를 절반정도로 떨어뜨리고 그 이후는 linear하게 증가시킨다. 

 

또한 TCP Tahoe 방식을 이용하여 초기화하는 방식도 있다. 

 

 

※ TCP Tahoe

timeout이 일어나든 3 duplicate ack가 일어나든 1MSS로 초기화하는 방식 

 

 

 

 

3. TCP fairness

 

K개의 TCP session이 같은 bottleneck 링크를 공유한다면 각각은 평균적으로 R/K의 rate를 갖는다.

 

 

 

 

2개의 TCP connection이 있다고 가정했을 때 

 

R1 + R2 <= R

0 <= R1 <= R

0 <= R2 <= R

 

위 조건을 만족해야하므로 위와 같은 삼각형 영역안에서 throughput을 갖게 된다.

 

임의의 한 지점에서 loss가 발생했을 때 x축으로 절반, y축으로 절반씩 감소하면서 fairness를 보장해준다. 

 

 

 

 

 

※전공 공부용으로 작성했습니다.

출처: computer networking a top down approach