* TCP 제어
앞서 TCP Header, Handshaking 과정을 자세히 알아봤다.
더불어, TCP 에는 세부적인 동작 방식과 특징들이 존재한다.
굉장히 역사가 깊은 Protocol 이기에 시간이 지남에 따라 발전되어오면서 더욱 복잡해보인다.
중요한 것은 'TCP 는 전체적인 네트워크 상황을 고려' 한다는 것이다.
이것은 연결된 상대방의 상황까지도 포함된다.
이에 따라 항상 제어 (=Control) 란 용어를 사용하는데,
어떤 상황을 고려해 자신의 데이터를 통제한다는 의미이다.
이전 단원에서는 '동작 과정' 을 살펴보았다면,
이번 단원에서는 '동작 방식' 에 대해서 알아볼 것이다.
TCP 제어에는 크게 총 3가지가 있는데, 흐름 제어, 오류 제어, 혼잡 제어 가 그것이다.
간단하게 정리하자면,
흐름 제어 : 상대방의 상황을 고려한 통신 방식
오류 제어 : 오류인 상황을 극복하기 위한 통신 방식
혼잡 제어 : 전체 네트워크 상황을 고려한 통신 방식
정도가 되겠다.
먼저 TCP 흐름 제어부터 살펴보자.
* TCP 흐름 제어 ( Flow Control )
한마디로,
'TCP 에서 상대방의 상황을 고려한 통신 방식' 이다.
상대방이 받을 수 있다면 데이터를 전송하고 아니라면 '지연' 된다.
TCP 에서 간단하게 생각해볼 수 데이터 송수신 방식은 Stop and Wait 방식 이다.
어느 한 쪽이 세그먼트를 받으면 ACK 세그먼트를 보내주는 형식이다.
해당 방식은 간단하지만 일방적이다.
이 방식은 ACK 를 받기 위해서 데이터를 보내야하는 과정이 추가되며 세그먼트마다 개별적으로 처리해야하고
데이터가 크다면 그만큼 주고 받는 데이터가 많아짐으로 효율적이진 못하다.
또한, 혼잡 제어 관점에서도 매우 비효율적이다.
각각의 세그먼트마다 ACK 를 주고 받아야하기에 트래픽이 증가되고 패킷 손실이 된다면 상황은 악화된다.
이러한 문제점을 해결하기 위해서 사용하는 방식이 '슬라이딩 윈도우 방식'이다.
* 슬라이딩 윈도우 방식 ( Sliding Window )
'Window' 라는 임의 크기의 버퍼를 사용하는 방식이다.
일전에 우리가 TCP Header 를 살펴볼 때 'Window Size (16bit)' 라는 항목이 그것이다.
흐름 제어를 위해 사용하는 16bit 필드이며
처음 3-way handshaking 과정에서 해당 데이터를 송신 측에서 확인해 적절한 크기를 설정하고
ACK 정보에 자신의 윈도우 크기를 넣어 보낸다.
송수신자 모두 각각의 윈도우 버퍼를 갖는다.
각각 수신 윈도우 크기 ( rwnd, Receiving Window ), 혼잡 윈도우 크기 ( cwnd, Congestion Window ) 라고 한다.
윈도우 버퍼를 앞뒤로 슬라이딩하듯이 움직이듯 동작하는 기법이라 슬라이딩 방식이라 한다.
주의할 점은
송신자에서 윈도우 크기만큼 데이터를 한번에 보내는 것이 아니라,
윈도우 크기만큼의 패킷들을 하나씩 연속적으로 보내는 것이다.
통상적으로 "윈도우 크기 = 'N' 이다" 라고 표현된다.
N = 3 이라면,
3개의 패킷을 연속적으로 보내거나 받을 수 있다는 뜻이다.
이 때, 보내는 하나의 패킷 크기는 'MSS 보다 클 수 없음' 을 예측 가능하다.
( 혼잡 제어 단락에서 자세히 알아보자. )
결과적으로, 실제 송신자의 윈도우 크기 ( cwnd ) 는 cwnd, rwnd 중 작은 값이 되겠다.
수신자의 윈도우 크기 외에도 여러 가지 상황들을 고려해 설정된다.
또, 패킷이 송수신될때마다 네트워크 혼잡을 고려해 윈도우 크기는 동적으로 바뀔 수 있다.
수신자는 자신의 수신 버퍼 여유 용량 크기를 송신자에게 지속적으로 알려준다.
송신자가 수신자에게 Window 크기를 받음으로써,
앞서 살펴본 Stop and Wait 방식으로 각각의 패킷에 대해 수신자가 ACK 를 보내주지 않아도
송신자는 수신자의 상황을 알고 있기 때문에 해당 크기만큼의 패킷을 연속적으로 보낼 수 있다.
이 후, 해당 범위 만큼의 ACK 를 보내준다.
첫번째 그림은 참고된 링크의 그림이다.
두번째 그림은 참고 자료들을 토대로 간단하게 슬라이딩 윈도우 동작 과정을 그림으로 표현해봤다.
해당 상황은 오류가 없는 정상 작동의 상황을 그렸고
송신 측에서 어떤 파일을 수신자에게 보낸다고 가정하며 그림을 기준으로 동작 과정을 설명하겠다.
1. 데이터 전송한다.
2. 데이터가 수신 측에 도착하면 Window 에 저장되고 Process 는 해당 데이터를 읽는다.
3. 이 후, 송신자에게 읽은 데이터의 마지막 패킷을 근거해 송신자에게 ACK 를 보낸다.
4. 송신자는 ACK 를 받은 위치를 아직 ACK 를 받지 못한 범위 첫번째 부분으로 이동시킨다.
5. 다시 위 과정을 반복한다.
4번 상황에서 주의해야할 점은 보내고 난 즉시 Window 를 움직이는 것이 아니라,
확실하게 데이터가 도착했는지 확인되었을 때 즉, ACK 가 도착되어졌을 때 비로소 이동된다.
결국,
송신자가 연속적으로 데이터를 보낼 때, 자신이 보낸 데이터의 ACK 를 받지 못하면
Window 의 크기만큼만 데이터를 보내게 될 것이다.
슬라이딩 윈도우 방식은 전이중 방식에서 동작하기 때문에 송신자가 패킷을 보내면서 ACK 를 받을 수 있다.
지금 보낼 패킷의 위치와 ACK ( 확인 응답 ) 을 받아야하는 위치를 송신 측은 알고 있다.
이렇게 두 위치로 나눈 것은
만약 패킷이 손실되었거나 오류 상황으로 받지 못했을 때,
다음 보낼 송신 위치을 ACK 를 받지 못한 위치로 옮겨야하기 때문이다.
수신 측의 Window Size 가 다 찼으면 송신 측의 상태는 Wait 가 걸린다.
송신 측에서는 해당 버퍼가 데이터를 보내기에 충분하다고 판단될 때까지 Wait ( 지연 ) 상태가 계속된다.
자주 언급했듯이,
수신측의 Window 에 쌓이는 데이터를 Process 에서 빠르게 읽어야지만
송신 측에서 데이터를 막힘 없이 보낼 수 있다.
즉,
수신 측 버퍼를 읽는 속도 > 송신하는 속도 ( 버퍼에 데이터가 쌓이는 속도 ) 이어야만 한다.
위에서 언급된 주제 중 다뤄보지 않은 것은
중간에 잘못된 패킷을 받았을 때와 같이 오류인 상황에서는 어떤 방식으로 TCP 가 동작하는지 이다.
다음 단락에서 그 내용에 관한 TCP 오류 제어를 살펴보자.
* TCP 오류 제어 ( Error Control )
TCP 에선 재전송 오류 제어를 사용한다.
데이터를 재전송하는 방식을 'ARQ ( Automatic Repeat Request )' 라고도 한다.
오류인 상황을 예로 들면,
패킷이 손실되었거나 지연되어서 재요청을 보냈을 때, 데이터가 중복되어지거나
Seq 번호가 맞지 않아 순서 역전이 발생한 경우 등이 이에 해당한다.
오류인 상황을 어떻게 판단할 수 있을까??
1. 체크섬 데이터 기반 오류 검출.
2. 수신자가 송신자에게 명시적으로 NACK ( 부정응답 ) 을 보냄 or ACK 가 중복되어져옴.
3. 일정시간 송신자에게서 ACK 가 오지 않음. ( Timeout )
추가적으로,
2번의 경우, NACK 를 사용하지 않기도한다. ACK 가 중복되는 것만으로도 구별 가능하기 때문이다.
3번의 경우, ( 참고 링크 )
이전에 배운 timestamp 기능으로
RTT ( Round Tirp Time ) 를 계산해 적절한 RTO ( Retransmission Timeout ) 를 설정하고
RTO 가 지나면 임의의 이유로 상대방이 패킷을 받지 못했다고 판단한다.
( RTO 설정엔 여러 계산 방식들이 존재. )
TCP 는 오류인 상황에서 다시 재전송하는 방식을 취한다.
* TCP 재전송 방식
TCP 는 재전송 타이머 ( RTO ), 전송 큐 를 가지고 있다. (그림에서 Retransmit timer, Transmit Queue)
세그먼트를 송신할때마다 타이머가 가동되며 해당 세그먼트를 '복사' 하여 전송 큐에 보관되어진다.
보낸 세그먼트의 ACK 를 받으면 큐에서 삭제한다.
이외에 타이머 만료 시에 재전송을 보내게 되는데 재전송했을 때에도 재전송 과정이 반복된다.
( 그림에서 (4) 번 라인에 해당하는 과정. )
이 후, 재전송 과정이 반복되어지면 TCP 연결이 강제 종료된다.
그렇다면 무엇을 얼마만큼 재전송해야하는가 ??
위에서 TCP 는 대체로 슬라이딩 윈도우 방식을 사용한다고 배웠다.
윈도우 개념으로 해당 범위만큼의 데이터를 하나의 데이터로 취급함으로써,
ACK 를 받는다면 일정 범위의 데이터에 대한 ACK 를 받는 방식이다.
이 상황에서 오류가 발생했음을 감지했고 재전송을 시도하려할 때, 어떤 패킷을 보내야할까 ??
결국, 데이터의 범위가 존재하기 때문에 어느 범위만큼 보낼 것인지에 대한 일련의 방식이 필요하다.
거기에는 대표적으로 2가지 GBN, SR 방식이 있다. 하나씩 살펴보자.
* GBN ( Go Back N ) 방식
간단하게 생각해볼 수 있는 방식은
오류가 생긴 패킷에서부터 다시 재전송하는 방식이다.
특징적인 개념으로는 'Cumulative ACK ( 누적 ACK )' 를 사용한다는 점이다.
송신자는 항상 마지막에 받은 ACK 를 판단하며, 이 ACK 에 대한 Timeout 을 계산한다.
중복된 ACK, NACK 수신 혹은 Timeout 발생 시, 재전송한다.
( 중복된 ACK,NACK = 송신 패킷 손실 방지, Timeout = ACK 패킷 손실 방지 )
수신자는 자신이 받아야할 패킷은 최근에 받은 패킷의 바로 다음 패킷이다.
때문에 다음 패킷이라면 해당 패킷에 대한 ACK 를 보내고
그 외의 경우, 해당 패킷은 버리고 가장 최근에 제대로 수신된 패킷에 대한 ACK 를 재전송한다.
예를 들어,
송신자에서 1,2,3,4 번 패킷을 보냈고 수신자에서 2번 패킷을 받지 못했다면, 각각 1,1,1,1 번 ACK 를 보낸다.
또, 수신자가 4번 ACK 를 보낸다면 이전의 1,2,3 번의 ACK 가 오지 않았어도
송신자는 수신자가 1,2,3,4 번까지의 패킷을 받았다고 생각한다.
이 때, 송신자는 4번 ACK 에 대한 Timer 가 다시 시작된다.
이 때문에 슬라이딩 윈도우 방식과 궁합이 아주 잘맞다.
또 하나 특징으로는 송신자의 윈도우 크기는 순서번호보다 작거나 같아야한다.
그렇지 않으면,
순서번호가 반복되어지기 때문에 윈도우 크기가 꽉 찰 정도로 패킷을 보내는 상황에서
보내는 패킷의 순서번호가 중복되어지는 현상이 발생한다.
이로 인해, 수신자는 새로운 패킷인지 재전송의 패킷인지 구별하기가 어렵다.
참고한 책을 읽어보다 NACK 에 대해서 언급되는데
NACK ( 부정확인응답 ) 은 TCP 에서 사용하지 않는다고 나와있다.
왜 그럴까 ??
NACK 를 사용한다 가정하면
상대방에게 ACK / NACK 둘 중 하나를 선택해 보내야하는 로직이 추가적으로 필요하기 때문에
따로 NACK 를 사용하지 않고 중복된 ACK 로 판별하는 것처럼 보인다.
그럼에도 TCP 에서 NACK 를 사용할 수 있는 옵션이 존재해 보인다.
아래부터는 NACK 는 언급하지않고 ACK 중복으로 통합한다.
앞서 설명한 GBN 동작 방식을 간단하게 그림으로 표현했다.
간단히 과정을 살펴보면,
송신자는 연속적으로 데이터를 보냄과 동시에 ACK 수신 및 Timeout 발생을 신경쓴다.
그림에서의 2번 상황처럼,
ACK 를 중복으로 받아서 수신자가 해당 패킷 이후를 받지 못한 것을 인지하거나
ACK 를 받을 시간이 초과되는 상황들을 오류 상황으로 판별한다.
이 후, 문제가 되는 패킷부터 다시 연속적으로 재전송한다.
수신 측에선 다음 받아야할 패킷이 아니라면 버리고 즉시 최근 받은 패킷의 ACK 를 보낸다.
여기서 흥미롭게 생각해볼 문제는
"송신자는 중복된 ACK 를 받기만 하면 무조건 해당 패킷부터 재전송해야할까??" 라는 것이다.
일부 보낸 패킷이 손실된 상황에서
송신자는 계속해서 연속적으로 세그먼트를 보내고 수신자는 세그먼트를 받을 때마다 중복된 ACK 를 보내게 될 것이다.
만약 중복된 ACK 를 처리하지 않고 Timeout 을 기다리게 되면
그동안 송신자가 보낸 패킷들은 수신자가 이미 버렸고 바보처럼 다시 송신자는 패킷들을 재전송한다.
그렇다고 중복된 ACK 를 받자마자 재전송을 수행하면 수신자가 중복된 패킷을 받을 수 있다.
1->2->3->4 순서가 아니라, 1->3->2->4 순서로 온다고 가정할 때, 수신자는 1은 정상적으로 수신 후 ACK 보낸다.
다음으로 2를 받아야하는데 3을 받았다면 1 에 대한 ACK 를 다시 보내게 된다.
이 때, 만약 송신자가 중복된 ACK 를 받자마자 재전송한다면
원래라면 수신자에선 2->4 번 패킷이 수신되어 알맞게 순서대로 패킷을 받을 수 있는데
송신자에서 다시 패킷을 재전송해버리는 것이다. 이것 또한 낭비이다.
이 2가지 상황 모두 예방하기 위해서,
TCP 송신자는 같은 데이터에 대한 '3개의 중복 ACK' 를 수신한다면 타이머가 만료되기 전에 재전송한다.
위 그림 2번 상황처럼,
1번 에 대한 ACK 패킷을 3번 중복해서 받았을 때, 송신자는 다시 재전송하게 된다.
이것을 '빠른 재전송' 이라고 한다.
빠른 재전송이 발생하는 상황을 송신자 측에선
네트워크가 혼잡한 상태임을 감지하고 윈도우 크기를 줄이게 된다. ( 혼잡 제어 때 살펴보자. )
뭔가 의이한 점이 눈에 들어온다.
분명 GBN 에서의 수신자는 중복된 패킷이 들어오면 바로 버린다고 했는데
어째서 1->3->2->4 순서로 오는 패킷을 받을 수 있을까??
결론부터 말하자면,
TCP 의 오류 복구 메커니즘은 GBN, SR 방식을 혼합해서 사용하기 때문이다.
SR 방식의수신자 측에는 순서가 바뀐 세그먼트들을 저장하는 버퍼가 존재한다.
'SR ( Selective Repeat )' 은 수신자에서 받지 못한 패킷만을 판단해서 송신자에게 알려주고
송신자는 받지 못한 패킷 하나만을 구별해서 수신자에게 알려주는 방식이다.
GBN 의 단점인 이미 받은 패킷들을 재전송으로 다시 받는 비효율을 제거하기 위해
선택적으로 받지 못한 패킷만 받아 정렬될 수 있는 버퍼가 존재한다.
아래에서 자세히 알아보자.
* SR ( Selective Repeat ) 방식
특징적인 개념으로는
GBN 과 달리,'Selective Acknowledgment ( 선택적 확인 응답 )' 을 사용한다는 점이다.
' Cumulative Acknowledgment (누적 확인 응답 )' 을 사용하는 GBN 의 경우
마지막 ACK 만 보낸다면 이전의 패킷들 모두 ACK 를 받았다고 처리되지만,
SR 방식에서는 선택적 확인 응답을 사용함으로 각각의 패킷에 대한 ACK 를 보낸다.
이로 인해,
'순서가 틀린' 세그먼트에 대해서 선택적으로 ACK 를 보낼 수 있다.
( 순서가 뒤바뀐 패킷을 수신해도 ACK 를 보내고 따로 버퍼에 저장한다. )
SR 방식에서의 송신자, 수신자가 하는 역할을 나눠본다.
* 송신자
1. 상위로부터 데이터 받음 ( ex. 프로세스, Application )
프로세스에서 Segmentation 을 거친 세그먼트를 받으면 Sequence Number 를 검사한다.
순서 번호가 윈도우 크기 내에 존재하면 패킷으로 전송하고
그렇지 않으면 계층 내 버퍼에 저장되거나 상위 계층으로 되돌려진다.
프로세스에서 Stream Data 를 분해하는 과정을 거치고 나온 세그먼트들이
순서대로 Transport 계층에 보내지지 않는 사실을 알 수 있다.
2. 타임아웃
각각의 패킷마다 타임 아웃을 위해서 Timer 를 가진다.
약간의 오버헤드가 발생한다.
3. ACK 수신
ACK 를 수신했을 때, 윈도우에서 ACK 를 받아야할 가장 처음 위치의 패킷이라면,
이 후, ACK 를 받아야할 패킷의 위치까지 윈도우를 이동시킨다.
* 수신자
1. 윈도우 범위 내의 순서 번호를 가진 패킷을 수신
해당 패킷을 받으면 ACK 를 송신자에게 보낸다.
만약, 해당 패킷이 이전에 받지 않은 새로운 패킷이라면
따로 존재하는 수신자의 버퍼에 저장된다.
이 후, 순서가 맞는 패킷이 들어왔을 때, 버퍼에 있는 데이터가 한 번에 상위로 전달된다.
( ex) 2->3->4->1 로 패킷이 올 때, 1번 패킷을 받았을 때 상위로 전달됨. )
2. '이전의' 윈도우 범위의 패킷 수신
이전에 받았던 패킷에 대해서도 수신자는 ACK 를 생성해 보내주어야한다.
굉장히 흥미로운데 생각해보면 당연하다.
만약 ACK 를 보냈는데 패킷이 손실되어 송신자에서 받지 못하면
송신자의 ACK Timer 는 Timeout 되어버리고 다시 재전송을 하게 될 것이다.
따라서, 이전의 범위 패킷도 신경써야한다.
3. 그 외의 경우, 무시.
위 내용을 상기하며 그림을 살펴보자.
위 그림은 패킷이 중간에 손실되었을 때의 그림이다.
수신자는 받은 패킷마다 ACK 를 보냄으로써 선택적 ACK 를 사용하는 특징을 알 수 있다.
주목할 점은 송신자가 해당 패킷의 ACK 를 받은 것을 표기하는 것이다.
수신자는 만약 받아야할 패킷이 오지 않고 윈도우 크기 내에 있는 패킷이 온다면 자신의 버퍼에 따로 저장한다.
이 후,
패킷을 계속 받으면서 송신자에서 ACK Timeout 되어진 패킷을 수신했을 때, 순서를 재정렬한다.
순서가 맞다면 해당하는 범위까지의 패킷을 윈도우를 거치지 않고 상위 계층으로 바로 전달한다.
이렇게 정상작동하면 좋겠지만 한 가지 문제점이 있다.
아직 살펴보지 않은 GBN 과의 큰 차이점은 '이전의 패킷 수신' 이다.
앞에서도 말했듯이,
SR 방식은 송신자가 수신자에게 각 패킷에 대한 ACK 를 받아야만 하기 때문에 ( 윈도우 이동을 위해 )
만약 ACK 가 손실되어 송신자가 받지 못하면 다시 재전송하고 ACK 를 받으려고 할 것이다.
이에 응답해 수신자는 이전의 패킷에게도 ACK 를 보내주어야만 한다.
이러한 방식으로 이전에 없던 문제점이 생겨난다.
* SR 딜레마 ( Selective Repeat Dilemma )
생길 수 있는 문제를 그림으로 표현했다.
수신자에서 ACK 를 보냈지만 패킷이 전부 손실되어 송신자에게 전달되지 못한 상황에서,
다시 송신자가 수신자에게 패킷을 재전송하게 되면 ( 그림에서 1번 패킷 )
수신자가 수신한 패킷은 이전에 받은 패킷에도 존재하고 윈도우 크기 내의 받아야할 패킷이기도 하다.
수신자는 해당 패킷이 이전의 패킷인지 새로 들어오는 패킷인지 알 수 없다.
송신자의 윈도우 크기는 중복된 패킷을 예방하기 위해 Sequence Number 와 작거나 같게 설정했지만,
수신자에서 이전의 패킷이 오는 상황, 새로운 패킷이 오는 상황 둘 다 구분지어야하기에 문제가 발생한다.
이 문제의 해결 방법은
수신자의 윈도우 크기를 순서 번호 / 2 보다 작거나 같게 설정하면 된다.
SR 에서 생기는 문제점이 GBN 에서도 생길 수 있지 않나 생각했었는데 상황이 다르다.
GBN 에서는 자신의 수신할 패킷은 최근 ACK 를 보낸 패킷 즉,
처리된 패킷의 다음 패킷만을 기다리기 때문에 이전의 수신한 패킷이 온다면 버리거나 ACK 를 재전송한다.
대신 송신자의 윈도우크기는 Sequence Number 보다 작거나 같게 설정하여 중복된 패킷을 막음으로써,
새로운 패킷이라는 변수를 제거한다.
중요한 차이점은 SR 방식은 이전에 받았던 패킷에 대해서도 처리를 해주어야한다는 점이다.
* 단원 결론
TCP 는 논리적 연결을 지향하며 상대방의 상황에 따라 자신을 제어한다.
이에 따라 상대방의 응답 ( ACK ) 를 받아야하는데
슬라이딩 윈도우 방식 기반으로 효율적인 ACK 트래픽을 관리한다.
또,
패킷과 ACK 를 주고 받으면서 생길 수 있는 오류를 처리하는 과정을 "TCP Error Control" 이라고 부른다.
슬라이딩 윈도우 방식을 기본 틀로 기본적으로 구성할 수 있는 오류 메커니즘 방식이 2가지가 존재한다.
GBN / SR 방식이 그것이다.
GBN 은 상대방이 받지 못한 패킷을 다시 순서대로 재전송하는 기법이고
SR 은 상대방이 받지 못한 패킷을 선택해서 재전송할 수 있는 기법이다.
TCP 는 기본적으로 두 가지 방식을 적절히 혼용해서 사용되어진다.
추가적 내용인 혼잡 제어는 다음 단원에서 다룬다.
* 최대한 짧게 정리하려 노력했지만 주제가 주제이다보니 필요한 설명이 너무 많고
이전 단원처럼 내용이 너무 길어지는 것 같아 이쯤에서 마무리하려한다.
( 혼잡 제어는 이 다음 단원에 정리할 것. )
* 위 모든 내용은 참고된 링크와 참고된 책을 통해 쓰여진 가설입니다.
직접 테스트해본 결과가 없기 때문에 정확하지 않을 수 있습니다.
참고 자료
COMPUTER NETWORKING A TOP-DOWN APPROACH 컴퓨터 네트워킹 하향식접근 - 제 6판
( James F. Kurose * Keith W. Ross 지음, 최종원, 강현국, 신용태, 안상현, 유영환, 황호영 옮김 )
'네트워크 > 개념' 카테고리의 다른 글
| [NW]#13. TCP 혼잡 제어 ( TCP Congestion Control ) (0) | 2022.12.12 |
|---|---|
| [NW] #11. TCP ( Transmission Control Protocol ) / IP ( Internet Protocol ) (0) | 2022.11.03 |
| [NW] #10. UDP ( User Datagram Protocol ) (0) | 2022.10.17 |
| [NW] #9. VLAN ( Virtual Local Area Network ) (0) | 2022.10.11 |
| [NW] #8. Broadcast, Multicast, Unicast (0) | 2022.10.06 |