[Network] 컴퓨터 네트워크 스터디 4회차 - TCP 3-way handshake, 4-way handshake, Congestion control, Flow control

🎯 TCP에 대해 설명해주세요.

(TCP 특징에 대해서 설명하기(신뢰적 데이터 전송 중심으로))

TCP란 UDP와 함께 전송계층에서 이용되는 프로토콜로 인터넷 상에서 데이터를 전송하기 위한 규약입니다. 연결형 서비스로 연결에 성공해야 통신이 가능하며 데이터의 순서 유지를 위해 각 바이트마다 번호를 부여해 데이터의 전송순서를 보장합니다. 이렇게 데이터를 송수신 하기 전 별도의 연결 절차가 필요하기 때문에 전송속도가 느리지만 (데이터 흐름제어 및 혼잡제어도 지원하여) 신뢰성 있는 데이터를 전송한다는 특징이 있습니다. tcp는 데이터 전송 전 3-way handshaking으로 연결을 설정하고 4-way handshaking으로 연결을 해제합니다.

🎯 3 way handshake에 대해 설명해주세요.

(3 way handshake을 왜 하는지 설명, 3 way handshake의 과정을 순차적으로 설명)

3-way handshaking은 통신을 위해 port를 확인하고 연결하기 위해 3번의 요청과 응답을 반복하는 것을 의미합니다. Handshake를 통해 송신자와 수신자는 서로의 Synchronize Sequence Number를 얻을 수 있기 때문에 송신자 수신자 모두 데이터를 전송할 준비가 되었다는 것을 미리 알 수 있습니다. 송신자와 수신자 간 연결이 수립됨으로써 둘만의 전용회선을 사용하기 때문에 연결의 신뢰성과 데이터의 신뢰성을 보장할 수 있습니다.

연결 과정은 다음과 같습니다.

연결과정

Client에서 Server에 연결 요청을 하기위해 SYN 데이터를 보냅니다.
Server에서 해당 포트는 LISTEN 상태에서 SYN 데이터를 받고 SYN_RCV로 상태가 변경됩니다.
그리고 요청을 정상적으로 받았다는 대답(ACK)와 Client도 포트를 열어달라는 SYN 을 같이 보냅니다.
Client에서는 SYN+ACK 를 받고 ESTABLISHED로 상태를 변경하고 서버에 ACK 를 전송합니다.
ACK를 받은 서버는 상태가 ESTABLSHED로 변경됩니다.

TCP state (Command Line : netstat)

//LISTEN : 서버의 데몬이 떠서 접속 요청을 기다리는 상태
//SYN-SENT : 로컬의 클라이언트 어플리케이션이 원격 호스트에 연결을 요청한 상태
//SYN_RECEIVED : 서버가 원격 클라이언트로부터 접속 요구를 받아 클라이언트에게 응답을 하였지만 아직 클라이언트에게 확인 메시지는 받지 않은 상태
//ESTABLISHED : 3 way-handshaking 이 완료된 후 서로 연결된 상태
//FIN-WAIT1, CLOSE-WAIT, FIN-WAIT2 : 서버에서 연결을 종료하기 위해 클라이언트에게 종결을 요청하고 회신을 받아 종료하는 과정의 상태
//TIME-WAIT : 연결은 종료되었지만 분실되었을지 모를 느린 세그먼트를 위해 당분간 소켓을 열어두고 있는 상태
//CLOSING : 흔하지 않지만 주로 확인 메시지가 전송도중 분실된 상태
//CLOSED : 완전히 종료

🎯 4 way handshake에 대해 설명해주세요.

(4 way handshake을 왜 하는지 설명, 4 way handshake의 과정을 순차적으로 설명)

3-way handshaking은 tcp 연결을 초기화 할 때 사용한다면 4-way handshaking 은 tcp 연결을 해제하기 위한 절차입니다.

4번의 절차를 거쳐 연결을 해제하는 이유는 데이터 유실을 방지하기 위함입니다.

클라이언트가 전송한 패킷이 Routing 지연이나 패킷 유실로 인한 재전송으로 서버 측에 늦게 도착하는 상황에서 패킷이 유실되는 것을 방지하기 위해 4-Way-Handshake와 함께 TIME_WAIT라는 상태를 제공합니다.

연결해제 과정

1. 클라이언트가 연결을 종료하겠다는 FIN플래그를 전송한다. 이때 클라이언트는 FIN-WAIT 상태가 됩니다.

2. 서버는 FIN플래그를 받고, 일단 확인메시지 ACK 보내고 자신의 통신이 끝날때까지 기다리는데 이 상태가 서버의 CLOSE_WAIT상태입니다.

3. 연결을 종료할 준비가 되면, 연결해지를 위한 준비가 되었음을 알리기 위해 클라이언트에게 FIN플래그를 전송합니다. 이때 B서버의 상태는 LAST-ACK 입니다.

4. 클라이언트는 해지준비가 되었다는 ACK를 확인했다는 메시지를 보냅니다. 클라이언트의 상태가 FIN-WAIT ->TIME-WAIT 으로 변경됩니다.

<예외 상황>

그런데 만약 "Server에서 FIN을 전송하기 전에 전송한 패킷이 Routing 지연이나 패킷 유실로 인한 재전송 등으로 인해 FIN패킷보다 늦게 도착하는 상황" 이 발생한다면 어떻게 될까요?

Client에서 세션을 종료시킨 후 뒤늦게 도착하는 패킷이 있다면 이 패킷은 Drop되고 데이터는 유실될 것입니다.

클라이언트는 이러한 현상에 대비하여 Client는 Server로부터 FIN을 수신하더라도 일정시간(디폴트 240초) 동안 세션을 남겨놓고 잉여 패킷을 기다리는 과정을 거치게 되는데 이 과정을 "TIME_WAIT" 라고 합니다. 일정시간이 지나면, 세션을 만료하고 연결을 종료시키며, "CLOSE" 상태로 변화합니다.

TCP는 UDP와 달리 신뢰성 있는 데이터 전송을 위해 여러 가지 제어 기능을 제공합니다. 그중 대표적인 것이 flow control (흐름 제어)와 congestion control (혼잡 제어)인데 차이점을 구별할 필요가 있습니다.

🎯 Congestion control에 대해 설명해주세요.

(Congestion control이 왜 필요한지 설명, Congestion control 종류 2가지 설명)

Congestion control, 혼잡제어는 송신 측의 데이터 전달과 네트워크의 데이터 처리 속도 차이를 해결하기 위한 기법입니다. 데이터의 양이 라우터가 처리할 수 있는 양을 초과하면 초과된 데이터는 라우터가 처리하지 못하는데 이때 송신 측에서는 라우터가 처리하지 못한 데이터를 손실 데이터로 간주하고 계속 재전송하여 네트워크를 혼잡하게 합니다. 이런 상황은 송신 측의 전송 속도를 적절히 조절하여 예방할 수 있는데, 이것을 혼잡 제어라고 합니다.

이 혼잡제어를 실현하기 위한 방법으로 AIMD, Slow Start 가 있습니다.

AIMD : Additive Increase & Multicative Decrease의 약자로, 합 증가 & 곱 감소라는 의미입니다. 처음에 패킷을 하나씩만 보내고 문제없이 해당 패킷이 도착하면 윈도의 크기를 증가시켜 전송합니다. 만약 전송 실패가 발생할 경우 윈도우의 크기를 반으로 줄입니다. 윈도우의 크기를 너무 조금씩 늘리기 때문에 네트워크의 대역을 제대로 활용하여 속도를 내기엔 시간이 걸린다는 단점이 있습니다.
Slow Start : 윈도우의 크기를 지수적으로 증가(1,2,4,8...)하다가 혼잡이 감지되면 1로 줄이는 방법입니다. 윈도우의 크기가 처음에는 조금 느리게 증가하지만, 시간이 지날수록 윈도우의 크기가 빠르게 증가한다는 장점이 있습니다.

Slow Start의 임계점 (Threshold)

임계점은 여기까지만 Slow Start를 사용하겠다 라는 의미를 가진다.
slow start threshold (ssthresh) 라고도 한다.

이 값을 사용하는 이유는 윈도우 크기를 지수적으로 증가시키다보면 크기가 기하급수적으로 늘어나 제어가 힘들어지기 때문이다.

따라서 전송 데이터의 크기가 임계점 (Threshold)에 도달하면 선형적으로 1씩 윈도우를 증가시킨다.

AIMD, Slow Start를 사용하면서 네트워크의 혼잡이 자주 발생하면 윈도우의 크기가 크게 감소하고 네트워크의 전송률이 매우 떨어집니다. 따라서 TCP에는 패킷을 재전송하는 기법들이 존재합니다. 이들 역시 혼잡제어 기법의 일종입니다.

Fast Retransmit : 수신 측은 먼저 도착해야하는 패킷이 도착하지 않고 다음 패킷이 도착한 경우에도 응답(ACK)를 보냅니다. 단, 순서대로 도착한 마지막 패킷의 다음 패킷 순번을 응답 패킷에 실어서 보내기 때문에 송신 측은 순번이 중복된 응답 패킷을 받게되고, 이러한 중복 패킷을 3번 감지하면 문제가 되는 순번의 패킷을 재전송해줄 수 있습니다.
Fast Recovery : 혼잡한 상태가 되면 윈도우의 크기를 1로 줄이지않고 반으로 줄인 다음 선형적으로 증가시키는 기법입니다. 이 기법을 적용하면 혼잡상황을 겪고난 후에는 AIMD와 같은 방식으로 동작합니다.

실질적인 혼잡제어는 이 중 하나만으로 작동한다기보단, 상황에 따라 정책을 바꿔가며 제어합니다. 예를 들면 처음에는 Slow Start를 사용하다가 혼잡 상태가 감지되면 AMID를 사용하는 방식입니다. 이런 정책에는 Tahoe, Reno, New Reno, Cubic, Ealstic-TCP 등 여러가지가 존재합니다.

🎯Flow control에 대해 설명해주세요.

(Flow control이 필요한 이유 설명 )

Flow control, 흐름제어는 송신 측과 수신 측의 데이터 처리 속도 차이를 해결하기 위한 기법으로 수신자가 패킷을 지나치게 많이 받지 않도록 조절합니다. 수신 측이 송신 측보다 데이터 처리 속도가 빠르면 문제 되지 않지만 송신 측의 속도가 더 빠를 경우 문제가 생깁니다. 수신 측에서 제한된 저장 용량을 초과한 이후에 도착하는 데이터는 손실될 수 있으며 만약에 손실된다면 불필요한 응답과 데이터 전송이 송수신 간에 빈번하게 발생합니다. 이러한 위험을 줄이기 위해 송신 측의 데이터 전송량을 수신 측에 따라 조절해야 합니다.

-Flow control 의 종류

1) Stop and wait : 매번 전송한 패킷에 대해 확인 응답을 받아야만 그 다음 패킷을 전송하는 방법

2) 슬라이딩 윈도우 : Sliding window 방식에서는 여러 데이터 패킷을 동시에 전송해 전송 효율을 높이기 위해 윈도우라는 개념을 사용합니다. 윈도우는 송신측과 수신측에 각각 송신 윈도우(awnd), 수신 윈도우(rwnd)가 존재합니다. 이때 서버의 송신 윈도우(awnd)의 크기를 클라이언트의 수신 윈도우(rwnd)보다 크지 않게 하면 만들면 전송량이 수신량보다 적으니 수신 버퍼 overflow를 막을 수 있습니다. 그러면서도 연속적으로 데이터를 전송할 수 있기 때문에 stop and wait 방식보다 전송 효율을 높일 수 있습니다.

정리하자면, 흐름 제어는 송 수신 측 사이의 패킷 수를 제어하는 기능이라 할 수 있으며, 혼잡 제어는 네트워크 내의 패킷 수를 조절하여 네트워크의 오버플로우를 방지하는 기능입니다.

📌 어려웠던 점

이번 주차는 "주제 - 주제에 따른 개념" 이렇게 간단한 형태가 아니라 절차를 이해하고 암기해야하는 것이 많지만 그래도 많이 들어보고 접했던 개념이었고 개념 자체는 이해하기에 어렵지 않았던 것 같다.

cs 탄탄한 신입이 되고 싶다!