[네트워크] TCP 혼잡제어,흐름제어

1. TCP에 대하여 

1.1. TCP란? 

네트워크 통신 방식 중 신뢰적인 연결방식
TCP는 신뢰할 수 없는 네트워크에서 신뢰할 수 있는 네트워크를 보장할 수 있도록 하는 프로토콜
TCP는 혼잡 제어 알고리즘을 사용함 

1.2. 비 신뢰적인 문제점

1. 손실 : 패킷의 손실
2. 순서 바뀜 : 전송된 패킷의 순서가 수신할 때 바뀌는 문제
3. Congestion : 네트워크가 혼잡한 문제
4. Overload : 수신측이 초과되는 문제

1.3. TCP 데이터 전송 과정 

1. TCP는 전이중 방식의 양방향 통신이 가능하여 양방향 간 데이터 전송이 가능 
2. TCP는 연결형 서비스를 제공하므로 연결 설정, 데이터 전송, 연결 해제 3단계를 순차적으로 진행하게됨 

 

데이터 전송 과정은 다음과 같음

1. Application layer : 전송측 application layer가 socket에 데이터를 넣음 
2. Transport layer : 데이터를 세그먼트로 감싸고, network layer에게 넘겨줌 
3. 아랫단에서 send buffer에 데이터를 저장하고, 전송함
4. 수신측은 데이터를 받아 버퍼에 데이터를 저장함
5. application은 때가 되면 버퍼에 있는 데이터를 읽기 시작함 
6. 여기서 흐름제어를 통해 이 수신측 버퍼가 넘치지 않도록 해야함 
7. 따라서 수신측은 RWND(Receive WiNDow)의 남은 공간을 홍보함

 

 

2. 흐름제어 (Flow Control) 

2.1. 흐름제어란?

송신측과 수신측의 데이터 처리속도 차이를 해결하기 위한 기법 
수신측이 넘치지 않도록 전송되는 패킷을 조절하는 것
수신측이 전송측에게 자신의 Buffer 상태를 계속적으로 피드백함

2.2. Stop and Wait 

매번 전송한 패킷에 대해 확인 응답을 받아야만 그 다음 패킷을 전송 

2.3. Sliding Window(Go Back N ARQ) 

1. 수신측에서 설정한 윈도우 크기만큼 송신측에서 확인응답없이 세그먼트를 전송할 수 있게 하여 데이터 흐름을 동적으로 조절하는 제어 기법 
2. 전송은 되었지만, Acked를 받지 못한 byte의 숫자를 파악하기 위해 사용되는 protocol
3. LastByteSent - LastByteAcked <= ReceivedWindowAdvertised  (마지막으로 보낸 바이트 - 마지막에 확인된 바이트 <= 남은 공간) 
4. 현재 전송되고 있는 패킷 수 <= sliding window 

 

Sliding WIndow 동작 방식

1. 먼저 윈도우에 포함되는 모든 패킷을 전송
2. 패킷들의 전달이 확인되는 대로 윈도우를 옆으로 옮겨 범위에 해당되는 패킷들을 전송  

 

Window 

1. TCP/IP를 사용하는 모든 호스트들은 송신하기 위한 것, 수신하기 위한 2개의 Window를 가지고 있음 
2. 호스트들은 데이터 전송 전에 '3 way handshaking'을 통해 수신 호스트의 window size와 자신의 window size를 맞춤

 

 

송신 버퍼

1. 200 이전의 바이트는 이미 전송되었고, 확인 응답을 받음
2. 200~ 202 바이트는 전송되었고, 확인 응답을 받지 못함
3. 203 ~ 211 바이트는 아직 전송이 안됨 

 

수신 윈도우 

 

수신 윈도우 

송신 윈도우 

송신 윈도우

1. 수신 윈도우보다 작거나 같은 크기로 송신 윈도우를 지정해야 흐름제어가 가능   

 

송신 윈도우의 이동

 

1. 200, 201, 202 응답 Acked를 아직 받지 못함 
2. 200, 201, 202 응답 Acked를 받으면 송신측은 수신 윈도우를 203 ~ 209로 이동 

 

 

3. 혼잡 제어 (Congestion Control)

3.1. 혼잡제어란? 

송신측의 데이터 전달과 네트워크의 데이터 처리 속도 차이를 해결하기 위한 기법
한 라우터에 데이터가 몰릴 경우 데이터가 전송되지 않아 호스트들은 다시 재전송하는 악순환 발생
이러한 혼잡을 피하기 위해 송신측의 데이터 전송 속도를 강제로 조절하는 작업을 혼잡제어라고 함
네트워크 내에 패킷의 수가 과도하게 많아지는 것을 혼잡이라 함
혼잡 제어는 흐름제어와 다르게 호스트와 라우터를 포함한 보다 넓은 관점에서의 전송 문제를 다룸 

3.2. AIMD(Additive Increase / Multicative Decrease)  

1. 처음에 패킷을 하나씩 전송, 문제가 없다면 window 크기를 1씩 증가
2. 패킷 전송에 실패하거나 Timeout이면 패킷 전송 속도를 반으로 줄임
3. 공평한 방식, 여러 호스트가 한 네트워크를 공유하면 나중에 진입하는 쪽이 불리하지만 결국엔 평형 상태가 됨
4. 초반에 전송되는 패킷이 적다보니 한계 대역폭을 전부 사용할 수 없으며 대역폭을 모두 사용하려면 오랜 시간이 걸림 
5. 네트워크 혼잡을 미리 감지하지 못함

3.3. Slow Start 

1. AIMD 방식이 전송 속도를 올리는데 오랜시간이 걸리는 것에 착안 
2. 처음에는 똑같이 패킷 하나로 시작하며, 문제가 없다면 도착하는 ACK 패킷마다 window size 1씩 증가. 즉 한 주기마다 window size가 2배 증가함
3. 전송 속도는 지수 함수 꼴로 증가하며, 혼잡 현상 발생시 window size를 1로 떨어뜨림
4. 한번 혼잡 현상이 발생하면 네트워크의 수용량 예상 가능 
5. 따라서 한번 혼잡 현상이 발생했던 window size의 절반까지는 지수 함수 꼴로 증가시키다가 그 이후로는 1씩 증가 시킴

3.4. Fast Retransmit (빠른 재전송) 

1. 수신측에서 앞의 패킷이 도착하지 않고 그 이후의 패킷이 와도 ACK 패킷을 보냄
2. 순서대로 잘 도착한 마지막 패킷의 다음 패킷 번호를 ACK 패킷에 실어 보내므로, 중간에 손실되면 송신 측에서는 중복된 ACK를 받게 됨 => 재전송! 
3. 중복된 순번의 패킷을 3개 받으면 재전송함, 혼잡을 예상하고 window size 감소

3.5. Fast Recovery (빠른 회복) 

1. 혼잡한 상태가 되면 window size를 1로 줄이는 것이 아닌, 반으로 줄이고 선형 증가시킴 
2. 이 정책을 적용하면 혼잡 상황을 한번 겪고 나서부터는 순수한 AIMD 방식으로 동작 

 

 

Reference 

https://www.brianstorti.com/tcp-flow-control/

TCP Flow Control

  https://github.com/gyoogle/tech-interview-for-developer

gyoogle/tech-interview-for-developer