본문 바로가기

개발 노트/네트워크

[프로토콜] TCP 프로토콜 동작 방식

반응형

❏ TCP 프로토콜 동작방식


❍ TCP는 흐름제어(Flow control)와 혼잡제어(Congestion control) 두 개의 제어 메커니즘을 이용하여 End-to-End 간의 신뢰성 있는 전송을 보장합니다. 흐름 제어는 송신 측이 수신 측으로부터 Advertised Window 크기를 받은 후 그것보다는 적게 보냄으로써 네트워크 상의 흐름을 조절하는 방법이고, 혼잡 제어는 Sender가 네트워크 상황을 보고 스스로 흐름을 조절하는 방법입니다.


 흐름제어(Flow Control)


- 정의

송신 측과 수신 측의 데이터 처리 속도 차이를 해결하기 위한 기법입니다. 수신 측이 송신 측보다 속도가 빠른 것은 아무 문제가 없지만 송신 측이 수신 측보다 속도가 빠르면 문제가 발생합니다. 수신 측에서 수신된 데이터를 처리해서 상위 계층으로 서비스 하는 속도보다 송신 측에서 보내는 데이터의 속도가 더 빠르다면 수신 측에서는 제한된 저장용량을 초과하여 이후에 도착하는 데이터는 손실될 수 있습니다. 만약 데이터가 손실된다면 불필요하게 응답과 데이터의 재전송이 송신 측과 수신 측간에 빈번히 이동해야 합니다. 이러한 위험을 줄이기 위해 송신 측의 데이터 전송량을 수신 측의 속도에 따라 조절하며 이것을 흐름제어라고 합니다.


- Stop and Wait방식

(1) 처음 연결 설정 시 윈도우 크기 = 4K

(2) 송신 TCP4K 데이터 전송

(3) 수신 TCPACK 전송 (윈도우 크기를 “0”으로 감소)

(4) 송신 TCP는 전송 불가

(5) 수신 TCPACK 전송 (윈도우 크기를 “1K”로 증가)

(6) 송신 TCP는 다시 1K 전송 가능


- Sliding Windows 방식

• 전송되는 패킷들에게 일련번호(Sequence Number)가 매겨지게 됩니다. 송신자(Sender)는 다음의 세 가지 변수를 관리합니다.
(1) SWS(Send Window Size) :
윈도우 크기
(2) LAR(Last Acknowledgement Received) :
마지막으로 확인받은 패킷의 번호
(3) LFS(Last Frame Sent) :
마지막으로 보낸 패킷의 번호 (SWS + LAR)
송신자의 윈도는 [(LAR+1), (LAR+2), … , (LAR+SWS)]가 된다. 송신자는 이 윈도에 포함되는 모든 패킷을 전송하고 수신자로부터 ACK가 올 때 까지 기다립니다. 아무 문제가 없었다면 수신자로부터 LAR+1ACK를 가장 먼저 받게 됩니다. 그렇다면 송신자는 LAR을 갱신하고, 그렇게 되면 LAR+SWS도 그만큼 증가하기 때문에 그 다음 패킷을 보낼 수 있게 됩니다. 또 만약 어느 패킷에 대해 ACK를 받지 못한 경우, 송신자는 일정시간을 기다린 후, 확인받지 못한 패킷을 재전송합니다. 이미 현재의 윈도에 해당되는 패킷을 모두 보냈는데 ACK를 받지 못해 윈도를 이동시키지 못하고 있다면 필요한 ACK가 오기까지 기다려야 합니다.

• 수신자(Receiver)도 윈도를 따로 운용합니다. 수신자는 다음의 세 가지 변수를 관리합니다.
(1) RWS(Receive Window Size) :
윈도우 크기
(2) LAF(Last Acceptable Frame) :
수신할 수 있는 마지막의 패킷의 번호
(3) LFR(Last Frame Received) :
마지막으로 수신한 패킷의 번호
송신자와 비슷하게 수신자도 LAFLFR을 갱신하여 윈도를 이동시키며 패킷들을 접수합니다. 받는 패킷들에 대한 AKC를 보내주는 것이 수신자의 역할입니다. 수신자가 보내는 ACK는 마지막으로 도착한 패킷에 대한 ACK가 아니고, 연속적으로 도착한 패킷 중의 가장 마지막 패킷에 대한 ACK 입니다. 만약 윈도에 포함되지 않는 패킷이 도착하면, 수신자는 단순히 이 패킷을 버립니다.


- GBn(Go-Back-N) / SR(Selective-Reject) ARQ 방식

Go-back-N ARQ 방법은 수신자 쪽에서의 과정을 단순화하고 있습니다. 수신자는 오직 하나의 변수만 관리하며 순서가 뒤바뀌어 도달한 프레임들을 보관하는 버퍼가 없어 단순히 버려질 뿐입니다. 그러나 이 방법은 잡음이 많은 채널에서는 매우 비효율적입니다. 잡음이 있는 채널에서는 프레임이 손상될 확률이 높아지며 이는 다수의 프레임을 다시 전송하게 되는 것을 의미합니다. 이 재전송으로 인해 대역폭을 소모하게 되어 전송속도도 저하됩니다.

Selective-Reject ARQ 방법은 손상되거나 분실된 프레임만을 재전송합니다. 그렇기 때문에 별도의 데이터 재 정렬을 수행해야 하기 때문에 별도의 버퍼를 필요로 합니다.

Go-back-N ARQ

Selective-Reject ARQ

손상/분실된 프레임 이후의 프레임을
모두 재전송

손상 / 분실된 프레임만을 전송

구조가 비교적 간단하고 구현이 단순

구조가 복잡(프레임 재배열 등의 추가 로직)

추가 버퍼 필요 없음

순차적이지 않은 프레임을 재배열하기 위한
 
버퍼 필요

비용이 비교적 저렴

비용 및 유지 관리 비용 증가



 혼잡제어(Congestion Control)


- 정의

송신 측의 데이터 전달과 네트워크의 데이터 처리 속도 차이를 해결하기 위한 기법입니다. 송신 측의 데이터는 지역 망이나 인터넷으로 연결된 대형 네트워크를 통해 전달됩니다. 만약 한 라우터에 데이터가 몰릴 경우(혼잡할 경우) 라우터는 모든 데이터를 처리할 수 없습니다. 그렇게 되면 호스트들은 또 다시 재전송을 하게 되고 결국 혼잡을 가중시켜 오버플로우나 데이터 손실을 발생시킵니다. 이러한 네트워크 혼잡을 피하기 위해 송신측에서 보내는 데이터의 전송속도를 강제로 줄이는 거을 혼잡제어라고 합니다.


- 혼잡제어 알고리즘

AIMD (Additive Increase / Multiplicative Decrease)

처음에 패킷을 하나씩 보내고 이것이 문제없이 도착하면 윈도 크기를 1씩 증가시켜가면서 전송하는 방법입니다. 만일 패킷 전송을 실패하거나 일정한 시간을 넘으면 패킷을 보내는 속도를 절반으로 줄이게 됩니다. 이 방식은 공평한 방식으로 여러 호스트가 한 네트워크를 공유하고 있으면 나중에 진입하는 쪽이 처음에는 불리하지만 시간이 흐르면 평형상태로 수렴하게 되는 특징이 있습니다. 문제점은 초기에 네트워크의 높은 대역폭을 사용하지 못하여 오랜 시간이 걸리게 되고, 네트워크가 혼잡해지는 상황을 미리 감지하지는 못합니다.

Slow Start

AIMD와 비슷하지만 이 방식은 패킷이 문제 없이 도착하면 각각의 ACK 패킷마다 창 크기를 1씩 늘립니다. 한 주기가 지나면 창 크기가 2배로 되어 AIMD와 다르게 지수 함수 꼴르 증가 합니다. 대신 혼잡현상이 발생하면 창 크기를 1로 떨어뜨립니다. 처음에는 네트워크의 수용량을 예상할 수 있는 정보가 없지만 한번 혼잡 현상이 발생하고 나면 네트워크의 수용량을 어느 정도 예상할 수 있으므로 혼잡현상이 발생하였던 창 크기의 절반까지는 이전처럼 지수 함수 꼴로 창 크기를 증가시키고 그 이후부터는 완만하게 1씩 증가시킵니다.

Fast Retransmit

ㆍ패킷을 받는 쪽에서 먼저 도착해야 할 패킷이 도착하지 않고 다음 패킷이 도착한 경우에도 ACK 패킷을 보냅니다. 단 순서대로 잘 도착한 마지막 패킷의 다음 패킷의 순번을 ACK 패킷에 실어서 보냅니다. 따라서 중간에 패킷 하나가 손실되게 되면 보내는 측에서는 순번이 중복된 ACK 패킷을 받게 되고, 이것을 감지하는 순간 문제가 되는 순번의 패킷을 재전송해 줄 수 있습니다. 빠른 재전송은 중복된 순번의 패킷을 3개 받으면 재전송을 합니다. 그리고 이런 현상이 일어나는 것은 약간의 혼잡현상이 일어난 것이므로 창 크기를 줄이게 됩니다.

Fast Recovery

ㆍ혼잡한 상태가 되면 창 크기를 1로 줄이지 않고 반으로 줄이고 선형 증가시키는 방법입니다. 이 정책을 적용하면 혼잡 상황을 한번 겪고 나서부터는 순수한 AIMD방식으로 동작합니다.






반응형

'개발 노트 > 네트워크' 카테고리의 다른 글

[프로토콜] IP Header  (0) 2018.11.05
[프로토콜] UDP Header / UDP 동작  (0) 2018.10.30
[프로토콜] TCP 통신  (0) 2018.10.28
[프로토콜] TCP Checksum (TCP 체크섬)  (0) 2018.10.25
[프로토콜] TCP Header  (0) 2018.10.24