신뢰적 데이터 전송의 원리와 TCP#4

wononly.dev·2023년 11월 23일

Go-back-N Selective Repeat tcp 슬라이딩 윈도우

CS

목록 보기

4/4

신뢰적 데이터 전송의 원리

슬라이딩 윈도우 프로토콜(Sliding Window Protocol)

데이터 통신에서 사용되는 흐름 제어 기법 중 하나
송신자와 수신자가 각각 윈도우라는 버퍼를 가지고 있으며, 윈도우의 크기에 따라 한 번에 보낼 수 있는 패킷의 개수가 결정됨
슬라이딩 윈도우는 윈도우의 크기를 동적으로 조절하면서 효율적인 패킷 전송을 가능하게 함
즉, 패킷을 전송할 때 수신자로부터 승인을 받기 전에 송신자가 전송할 수 있는 데이터의 양을 규제하는 흐름 제어 메커니즘

GBN(Go-Back-N) ARQ 기법

Go-Back-N 방식은 송신 측에서 전송할 패킷의 개수를 정함
버퍼에 그 개수만큼의 패킷을 저장하여 전송
버퍼를 window, 버퍼의 사이즈를 window size라고 함
버퍼의 시작점인 send_base, 다음에 보낼 패킷 번호인 next_seq_num을 가짐
수신 측은 이번에 받을 패킷의 번호를 기억하고 있음
이때 수신측은 누적 ACK(Cumulative ACK)을 사용
각 버퍼가 전송될 때 ACK를 받지 못한 가장 오래된 패킷의 Timer를 기준으로 Timeout이 발생
Timeout 이 발생하면 window에 있는 모든 패킷을 전송

SR(Selective-Repeat) ARQ 기법

GBN의 비효율성을 해결하기 위한 방식
송신측은 각 패킷마다 timer를 설정하고 timeout 된 패킷만 재전송 (GBN처럼 버퍼 모두를 전송하지 않음)
수신 측도 버퍼(window)를 가지고 있음
수신 측은 기다리던 패킷이 오면 바로 상위 계층으로 전달하고 ACK 신호를 보냄
수신 측은 기다리고 있던 패킷이 오지 않으면 일단 버퍼에 넣어놓고 ACK 신호를 보냄
수신 측의 버퍼가 가득 차면(패킷이 모두 도착하면) 상위 계층으로 전달
이외는 GBN과 비슷함
GBN보다 효율적으로 보이지만 모든 패킷에 timer가 있기 때문에 overhead가 큼

TCP

Transmission Control Protocol의 약자로 1:1 연결을 지향하며 신뢰할 수 있는 통신을 제공함
여기서 1:1은 각각 클라이언트와 서버를 의미
양 단에 연결을 수립한 뒤 데이터를 전송하고 연결을 종료함
일반적인 HTTP 통신은 TCP 방식을 따름

TCP Handshake

HandShake 는 직역하면 '악수'라는 뜻으로 마치 우리가 다른 사람과의 첫 만남에서 만나서 악수를 요청하고 악수를 받듯이,
정상적인 통신을 하기 전에, 일련의 과정을 거쳐 연결을 성립시키는 것을 말함

TCP 방식에서 연결을 수립할 때 사용하는 방식
연결할 때는 3way-HandShake
연결을 종료할 때는 4way-HandShake를 사용함

3 way HandShake

TCP 통신을 이용하여 데이터를 전송하기 위해 네트워크 연결을 설정(Connection Establish) 하는 과정
양쪽 모두 데이터를 전송할 준비가 되었다는 것을 보장하고, 실제로 데이터 전달이 시작하기 전에 한 쪽이 다른 쪽이 준비되었다는 것을 알 수 있도록 함
즉, TCP/IP 프로토콜을 이용해서 통신을 하는 응용 프로그램이 데이터를 전송하기 전에 먼저 정확한 전송을 보장하기 위해 상대방 컴퓨터와 사전에 세션을 수립하는 과정을 의미
3 way HandShake엔 총 세 가지 과정이 존재

A 👉 B : 내 말 들리니?
B 👉 A : 그래, 잘 들려. 내 말은 들리니?
A 👉 B : 나도 잘 들려!
STEP 1
- 클라이언트는 서버에 접속을 요청하는 SYN 패킷을 전송
- 이때 클라이언트는 SYN 을 보내고 SYN/ACK 응답을 기다리는 SYN_SENT 상태가 됨
STEP 2
- 서버는 SYN 요청을 받고 클라이언트에게 요청을 수락한다는 ACK 와 SYN flag 가 설정된 패킷을 발송하고 A가 다시 ACK으로 응답하기를 기다림
- 이때 B서버는 SYN_RECEIVED 상태가 됨
STEP 3
- 클라이언트는 서버에게 ACK을 보내고 이후로부터는 연결이 이루어지고 데이터가 오가게 됨
- 이때의 서버 상태가 ESTABLISHED 임

👉 위와 같은 방식으로 통신하는 것이 신뢰성 있는 연결을 맺어 준다는 TCP의 3 Way handshake 방식

<용어 정리>

SYN(Synchronize sequence numbers)

연결 확인을 위해 보내는 무작위 숫자값(내 말 잘 들려?)

ACK(Acknowledgements)

직역하면 '인정하다'라는 뜻

Client 혹은 Server로 부터 받은 SYN에 1d을 더해 SYN을 잘 받았다는 뜻 (잘 들려!)

ISN(Initial Sequence Numbers)

Client와 Server가 각각 처음으로 생성한 SYN

CLOSED

연결 수립을 시작하기 전의 기본 상태

LISTEN

포트가 열린 상태로 연결 요청 대기 상태

SYN-SENT

SYN 요청을 한 상태

SYN-RECEIVED

SYN 요청을 받고 상대방의 응답을 기다리는 중

ESTABLISHED

연결의 수립이 완료된 상태

서로 데이터를 교환할 수 있는 상태임

4 way HandShake

연결을 끊을 땐 4 way Handshake 과정을 거침

A 👉 B : 나는 다 보냈어. 이제 끊자!
B 👉 A : 알겠어! 잠시만 기다려~
B 👉 A : 나 이제 끊을게!
A 👉 B : 알겠어!
STEP 1
- 서버와 클라이언트가 TCP 연결이 되어있는 상태에서 클라이언트가 접속을 끊기 위해 CLOSE() 함수를 호출
- 이 후 CLOSE() 함수를 호출하면서 FIN segment 를 보내게 되고 클라이언트는 FIN_WAIT1 상태로 변하게 됨
STEP 2
- 서버는 클라이언트가 CLOSE() 한다는 것을 알게 되고 CLOSE_WAIT 상태로 바꾼 후 ACK segment 를 전송
- 즉, 클라이언트가 끊을 것이라는 신호를 받았다는 의미이고 CLOSE_WAIT 를 통해 자신의 통신이 끝날 때까지 기다리는 상태가 됨
STEP 3
- ACK segment를 받은 클라이언트는 FIN_WAIT2 로 변환되고 이 때 서버는 CLOSE() 함수를 호출하고 FIN segment 를 클라이언트에게 전송
STEP 4
- 서버도 연결을 닫았다는 신호를 클라이언트가 수신하면 ACK segment 를 보낸 후 TIME_WAIT 상태로 전환
- 이 후 모든 것이 끝나면 CLOSED 상태로 변환

👉 즉, 4 way HandShake는 클라이언트와 서버가 서로 연결되어 있는 상태에서 통신을 종료하는 과정에 사용하는 방식임

<용어 정리>

CLOSE-WAIT

상대방의 FIN(종료 요청)을 받은 상태

상대방 FIN에 대한 ACK를 보내고 애플리케이션에 종료를 알림

LAST-ACK

CLOSE-WAIT 상태를 처리 후 자신의 FIN요청을 보낸 후 FIN에 대한 ACK를 기다리는 상태

FIN-WAIT-1

자신이 보낸 FIN에 대한 ACK를 기다리거나 상대방의 FIN을 기다리는 상태

FIN-WAIT-2

자신이 보낸 FIN에 대한 ACK를 받았고 상대방의 FIN을 기다리는 상태

CLOSING

상대방의 FIN에 ACK를 보냈지만 자신의 FIN에 대한 ACK를 못받은 상태

TIME-WAIT

모든 FIN에 대한 ACK를 받고 연결 종료가 완료된 상태

새 연결과 겹치지 않도록 일정 시간 동안 기다린 후 CLOSED 상태로 전이함

흐름제어(Flow control)

수신측이 송신측보다 데이터 처리 속도가 빠르면 문제없지만, 송신측의 속도가 빠를 경우 문제가 생김
수신측에서 제한된 저장 용량을 초과한 이후에 도착하는 데이터는 손실 될 수 있으며, 만약 손실 된다면 불필요하게 응답과 데이터 전송이 송/수신 측 간에 빈번이 발생
이러한 위험을 줄이기 위해 송신 측의 데이터 전송량을 수신측에 따라 제어해야 함

👉 송신측과 수신측 사이의 데이터 처리 속도 차이(흐름)를 해결하기 위한 기법

해결방법

Stop and Wait
- 매번 전송한 패킷에 대해 확인 응답을 받아야만 그 다음 패킷을 전송하는 방법
Sliding Window (Go Back N ARQ)
- 수신측에서 설정한 윈도우 크기만큼 송신측에서 확인응답없이 세그먼트를 전송할 수 있게 하여 데이터 흐름을 동적으로 조절하는 제어기법

혼잡제어(Congestion Control)

송신측의 데이터는 지역망이나 인터넷으로 연결된 대형 네트워크를 통해 전달됨
만약 한 라우터에 데이터가 몰릴 경우, 자신에게 온 데이터를 모두 처리할 수 없게 됨
이런 경우 호스트들은 또 다시 재전송을 하게되고 결국 혼잡만 가중시켜 오버플로우나 데이터 손실 발생
따라서 이러한 네트워크의 혼잡을 피하기 우해 송신측에서 보내는 데이터의 전송속도를 강제로 줄이게 되는데, 이러한 작업을 혼잡제어라고 함
또한 네트워크 내에 패킷의 수가 과도하게 증가하는 현상을 혼잡이라 하며, 혼잡 현상을 방지하거나 제거하는 기능을 혼잡제어라고 함
흐름제어가 송신측과 수신측 사이의 전송속도를 다루는데 반해, 혼잡제어는 호스트와 라우터를포함한 보다 넓은 관점에서 전송 문제를 다루게 됨

👉 송신측의 데이터 전달과 네트워크 상의 데이터 처리 속도 차이를 해결하기 위한 기법
: 송신측에서 보내는 데이터의 전송 속도를 제어

해결방법

AIMD(Additive Increase / Multiplicative Decrease):
- 합 증가/ 곱 감소 알고리즘
- 처음에 패킷을 하나씩 보내고 이것이 문제없이 도착하면 window 크기(단위 시간 내에 보내는 패킷의 수)를 1씩 증가시켜가며 전송하는 방법
- 패킷 전송에 실패하거나 일정 시간을 넘으면 패킷의 보내는 속도를 절반으로 줄임
- 공평한 방식으로, 여러 호스트가 한 네트워크를 공유하고 있으면 나중에 진입하는 쪽이 처음에는 불리하지만, 시간이 흐르면 평형상태로 수렴하게 되는 특징이 있음
- 문제점은 초기에 네트워크의 높은 대역폭을 사용하지 못하여 오랜 시간이 걸리게 되고, 네트워크가 혼잡해지는 상황을 미리 감지하지 못함
- 즉, 네트워크가 혼잡해지고 나서야 대역폭을 줄이는 방식
Slow Start (느린 시작)
- AIMD 방식이 네트워크의 수용량 주변에서는 효율적으로 작동하지만, 처음에 전송 속도를 올리는데 시간이 오래 걸리는 단점이 존재
- Slow Start 방식은 AIMD와 마찬가지로 패킷을 하나씩 보내면서 시작하고, 패킷이 문제없이 도착하면 각각의 ACK 패킷마다 window size를 1씩 늘려준다. 즉, 한 주기가 지나면 window size가 2배가 됨
- 전송속도는 AIMD에 반해 지수 함수 꼴로 증가
- 대신에 혼잡 현상이 발생하면 window size를 1로 떨어뜨리게 됨
- 처음에는 네트워크의 수용량을 예상할 수 있는 정보가 없지만, 한번 혼잡 현상이 발생하고 나면 네트워크의 수용량을 어느 정도 예상할 수 있음
- 그러므로 혼잡 현상이 발생하였던 window size의 절반까지는 이전처럼 지수 함수 꼴로 창 크기를 증가시키고 그 이후부터는 완만하게 1씩 증가시킴
Fast Retransmit (빠른 재전송)
- 빠른 재전송은 TCP의 혼잡 조절에 추가된 정책
- 패킷을 받는 쪽에서 먼저 도착해야할 패킷이 도착하지 않고 다음 패킷이 도착한 경우에도 ACK 패킷을 보내게 됨
- 단, 순서대로 잘 도착한 마지막 패킷의 다음 패킷의 순번을 ACK 패킷에 실어서 보내게 되므로, 중간에 하나가 손실되게 되면 송신 측에서는 순번이 중복된 ACK 패킷을 받게 됨
- 이것을 감지하는 순간 문제가 되는 순번의 패킷을 재전송 해줄 수 있음
- 중복된 순번의 패킷을 3개 받으면 재전송을 하게 됨
- 약간 혼잡한 상황이 일어난 것이므로 혼잡을 감지하고 window size를 줄이게 됨
Fast Recovery (빠른 회복)
- 혼잡한 상태가 되면 window size를 1로 줄이지 않고 반으로 줄이고 선형증가시키는 방법
- 이 정책까지 적용하면 혼잡 상황을 한번 겪고 나서부터는 순수한 AIMD 방식으로 동작하게 됨