[TCP] 흐름제어 & 혼잡제어

 

전송계층의 연결형&신뢰성 특징을 가진 TCP 프로토콜을 사용하는 통신에서는
신뢰성 보장을 위해 여러가지 방법을 가집니다.
대표적으로 오류제어, 흐름제어, 혼잡제어 등이 있습니다.

이 글은 신뢰성을 가지는 TCP 통신의 특징, 그 신뢰성을 가지기 위한 기법과
그에 대한 예들을 정리해 보겠습니다.

[ TCP ]

TCP(Transmission Control Protocol) 는 신뢰성을 확보하고 연결지향적인 특징을 가지며 segment단위의 데이터를 전송하는 전송계층의 프로토콜입니다. 연결지향적인 특징을 가지기 위해서 3way-handshake를 통해 송수신측간 connection setup(연결수립)을 합니다. 양 측간 연결이 된 후 data transfer(데이터 전송) 를 통해서 데이터를 송/수신하게 되고, 데이터 전달이 끝나면 connection termination을 통해 양측간 맺은 connection을 안전하게 해지하게 됩니다. 즉, TCP 통신 과정은 connection setup, data transfer, connection termination 세가지 단계로 나뉘게 됩니다.

 

connection setup(좌) / TCP 통신과정(우)

 

1. connection setup  : 연결수립

< 3way-handshake >

(1) SYN (Active-> Passive) : "나 너랑 연결 좀 하자. (SYN)"

(2) ACK/SYN ( Passive -> Active ) : "어. 그래 (ACK)" , "이쪽에서도 그쪽하고 연결 좀 하자(SYN)"

(3) ACK ( Active -> Passive ) : "어. 그래 (ACK)"

양방향으로 연결 수립과정이 이루어져야 한다.

 

 

 2. data transfer  : 서버에 저장할, 서버로부터 불러와 클라이언트와 통신할 데이터들

 

 

3. connection termination  : 안전하게 통신 종료과정

< 4way-handshake >

https://young1403.tistory.com/80 참고

(1) FIN (Active-> Passive) :  "나 종료할게~"

(2) ACK ( Passive -> Active ) :  "어 알겠어. 데이터 처리하던게 있어서 이것만 좀 정리하고 있을게"

(3) FIN ( Passive -> Active )  :  "데이터 다 처리했어. 나도 종료할게"

(4) ACK (Active-> Passive) :  "응"

시스템 : '혹시 전달이 늦은 데이터가 있을 수 있으니 조금만 있다 진짜로 종료해야지' (time-wait)

 

 

[ Flow Control (흐름제어) ]

흐름제어란 송신측과 수신측간의 데이터 전송 속도의 불균형을 조절하여 수신측의 처리 능력을 초과하지 않도록 보장하기 위해 사용하는 데이터 전송 관리 기법입니다. 수신측은 자신의 버퍼 용량과 처리 속도를 송신측에 알려주어 송신측에서 데이터를 보내는 속도를 조절합니다. 이를 통해 overflow 상황에서 발생하는 데이터 손실을 방지하고 안정적인 연결을 수립합니다.

흐름제어에는 대표적으로 아래 네가지 방식이 있습니다.

 

stop-and-wait

stop-and-wait

송신자가 한개의 세그먼트를 전달하면 수신자는 그 세그먼트 받았다는 응답을 보낼때 까지 송신자는 대기합니다.

stop-and-wait protocol 로 데이터 통신에서 사용하는 간단한 형태의 흐름제어 프로토콜입니다. 송신자가 한개의 세그먼트를 전송하고, 수신자로부터 응답을 받을 때까지 기다리는 방식으로 동작합니다. 수신자는 전송받은 세그먼트에 대해 확인(ACK) 또는 부정(NAK) 신호를 송신자에게 되돌려 보냅니다.

 

구현이 간단하고 오류 검출 및 복구가 쉽다는 장점이 있지만 매번 한개의 세그먼트 만 전송가능하고 중간에 신호가 유실되거나 데이터 전송이 지연되어서 time-out이 발생하게 되면 손실된 세그먼트를 재전송 해야하기 때문에, 중복된 프레임이 발생할 수 있습니다. ACK혹은 NAK신호를 받을 때 까지 다음 프레임을 받을 수 없으므로 전송효율이 떨어집니다.

 

슬라이딩 윈도우

Sliding-window

.Sliding Window는 수신 측에서 설정한 윈도우 크기만큼 송신 측에서 확인 응답(ACK) 없이 패킷을 전송할 수 있게 하여 데이터 흐름을 동적으로 조절하는 제어 기법입니다.. 위의 사진에서는 window size(연달아 보낼 수 있는 프레임 수)가 3인 상황입니다. 1번에 대한 ACK가 수신측으로 부터 송신측에 전달되면서 2,3에 대한 ACK만 기다리면서 자리 하나가 남게 됩니다. 그래서 window-size가 3이기 때문에 자리가 하나가 남아 다음 프레임인 4를 전달할 수 있게 되는겁니다.

 

이러한 sliding-window는 대표적으로 Go Back N 과 Selective Repeat 두가지 방식이 있습니다.

 

Go Back N

 

손실에 대한 오류가 발생한 부분을 포함해 그 이후의 데이터(패킷)들을 재전송하는 방식입니다. 데이터의 순서를 보장하기 위한 오류제어, 흐름제어 등을 수행합니다. 위의 사진에서는 sliding window를 기반으로 window-size가 4인 상황입니다. 다만 데이터 전송중 2번패킷에 대한 손실이 발생하였고 Receiver 쪽에서 Sender쪽으로 응답을 주지 못한 상황입니다. 그러면 Go Back N 방법을 사용하면 손실된 패킷+그 이후의 패킷들을 재전송 하는 방식입니다.

 

2번 패킷에 대해 손실이 일어났으니 window-size = 4의 크기에 맞춰 2,3,4,5 패킷을 재전송하는 방식입니다.

 

Selective Repeat

selective repeat

Go Back N 을 보완한 방식입니다. 오류가 발생한 부분의 패킷(프레임/데이터)만 재전송하는 방식입니다. 
위의 사진에서 window-size가 4이고 selective repeat 을 사용한 예입니다. 0,1번 프레임에 대한 응답은 받았지만 2번 프레임에 대해서는 프레임 손실이 일어났습니다. 0,1번 프레임은 다음 프레임인 4,5번에 대한 ACK을 한 상황이고 3번 프레임은 NAK에 대한 2번 프레임을 재전송해주게 됩니다. 그리고 window-size에서 남는 크기만큼 마지막 전송 성공(5번) 다음인 6번 프레임부터 데이터 전송을 이어나가는 방식입니다.

 

[ Congestion Control (혼잡제어) ]

혼잡제어란 네트워크가 감당하기에는 많은 양의 데이터를 (처리속도보다) 너무 빠르게 전송하여 발생하는 네트워크 혼잡 현상입니다. 한 라우터에 데이터가 몰릴 경우. 데이터를 모두 처리할 수 없게 되고 오버플로우로 데이터 손실이 발생할 수 있어서 데이터 전송속도를 강제로 줄이게 되는데 이러한 작업을 혼잡제어라 합니다. 송수신측만 다루는 흐름제어보다 조금 더 넓은 개념이라고 볼 수 있겠습니다.

 

혼잡제어를 해결하기 위한 대표적 방법 중 하나로 fast retransmit( 빠른 재전송)이 있겠습니다. 

 

Fast Retransmission( 빠른 재전송 )

Fast Retransmission

Fast Retransmission(빠른 재전송)이란 패킷을 받는 수신자 입장에서 세그먼트로 분할된 내용들이 순서대로 도착하지 않을 수 있는데 이 경우 순서대로(정상적으로) 마지막에 도착한 패킷의 순번을 ACK에 보내게 되는데 이것이 3번 중복되면 해당 패킷(정상적으로 마지막에 도착한 패킷) 순번+1번의 패킷(오류가 난 패킷)을 재전송하게 됩니다. 이 방식의 장점은 자신이 설정한 타임 아웃 시간이 지나지 않아도 3번의 중복된 ACK패킷을 받게되면 해당 패킷을 바로 재전송 할 수 있기 때문에 상황에 따라 보다 빠른 재전송을 할 수 있습니다. 이런 방식으로 패킷의 순서를 유지해 보다 신뢰성있는 데이터 송수신을 할 수 있습니다.

 

AIMD (합 증가/곱 감소 )(Additive Increase / Multicative Decrease) 

혼잡 window size

AIMD 방식은 이름 그대로 합 증가, 곱 감소 방식으로 동작한다. 네트워크 통신이 정상적으로 이루어지면 전송 속도를 더 빠르게 하기위해 window-size를 1씩 증가시키게 됩니다. 하지만 만약 패킷 손실이 일어나게 될 경우, 혼잡 window-size를 절반으로 줄이게 됩니다. 이러한 방식으로 동작하는 혼잡제어를 하기위한 것이 AIMD 방식입니다.

 

여러 host들이 각자의 window 사이즈를 가지고 통신을 할 것이기 때문에, 혼잡상황 에서의 각 호스트들의 window-size별 통신은 엇비슷하게 수렴한다고 볼 수 있습니다. 왜냐하면 어느정도 혼잡상황에서 size가 큰 host 요청이 들어온들 그것을 처리할 수 있는 네트워크 상태가 아닐것이며 또한 window-size미만에서 활용해야 하기에 그 사이즈를 초과하면 그때마다 그 Host 요청에 대한 window-size를 *0.5를 해야하기 때문이죠.  아래 참고 블로그의 글을 보면 test한 것이 있으니 시각화 자료를 보면서 한번 더 확인해 보시면 좋을 것 같습니다.

꽤나 공평한 방법이라고 하는 것 같습니다.

 

하지만 단점도 있습니다. window-size를 +1 씩 증가시키기 때문에 어느정도 높은 대역폭에 도달할 때 까지 오랜 시간이 걸리게 됩니다. 또한 네트워크의 혼잡상태를 미리 감지할 수 없고 네트워크가 혼잡해지고 나서야 대역폭을 줄이는 방식이 '데이터를 보내고보니 컸다' 라는 식의 뒤늦은 대처이기 때문에 데이터를 전송하는데 더 오랜 시간이 걸릴 수 있으며 패킷의 유실위험도 있습니다.

 

 

 

이렇게 신뢰성있는 통신을 위해 TCP에서 동작하는 흐름제어와 혼잡제어에 대해 알아보았습니다. 

 

긴 글 읽어 주셔서 감사합니다.

 

 

참고
https://notes.shichao.io/tcpv1/ch13/
3way-handshake : https://www.techopedia.com/definition/10339/three-way-handshake
fast-retransmission : https://www.sciencedirect.com/topics/computer-science/fast-retransmit
selective-repeat : https://www.codingninjas.com/studio/library/selective-repeat-arq
go-back-N : https://data-flair.training/blogs/go-back-n-arq-protocol/
AIMD : https://evan-moon.github.io/2019/11/26/tcp-congestion-control/
stop-and-wait : https://afteracademy.com/blog/what-is-stop-and-wait-protocol/