슬라이딩 윈도우 프로토콜 (흐름제어)

 

 

지난 포스팅에서 효율적인 오류제어를 위헤 데이터 프레임에는 순서번호가 있다고 말했다. 하지만 데이터 순서 번호가 있다고 송신 측에서는 프레임을 마구잡이로 보낼 수 없다. 수신 호스트는 데이터 프레임을 버퍼에 보관하여 처리하는데, 버퍼가 가득찬다면 버퍼로 들어오는 데이터 프레임이 유실될 수 있다. 그러므로 흐름제어를 해주어야 한다. 일반적으로 가장 많이 사용되는 흐름제어를 위한 프로토콜이 슬라이딩 윈도우 프로토콜이다.

 

슬라이딩 윈도우 프로토콜

 

지난 포스팅에서 프레임 릴레이 방식으로 송신호스트는 수신호스트로 다수의 프레임을 연달아 보낸다고 말하였다. 그렇다면 몇 개의 프레임을 보내야 적절한 흐름을 유지할 수 있을까? 여기서 연달아 보낼 수 있는 프레임의 개수를 두고, 윈도우 크기(Window Size)라 부른다. 송신측은 수신 측에게 윈도우 크기만큼의 프레임을 전송한 후, ACK 응답을 기다린다. 수신측으로부터 ACK응답이 들어오면 프레인 전송이 가능해진다.

 

 

 

그림과 같이 송신측이 수신측으로 보내야 할 프레임이 9개가 있다.윈도우 크기가 3이라며 송식측 1번부터 3번까지의 프레임을 연달아 수신호스트에 전송한다. 그리고 ACK 응답을 기다린다.

 

수신측으로부터 프레임의 순서번호가 담긴 ACK응답이 들어오면 송신측은 응답이 들어온 개수만큼 다시 데이터를 전송한다. 만약 수신 측에서 NAK응답을 보낸다면 해당 순서번호의 프레임을 재전송하면 된다.

 

그러나 연속형 전송(Pipelining) 에서는 좀 더 특별한 오류제어 방식이 있어야한다. 연속형 전송이란 윈도우 크기를 늘려 최대한 ACK를 받지 않고 많은 양의 프레임을 보내는 것이다. ACK를 주고 받으면 전송속도가 느려지는 단점을 보완한 방식이다. 많은 양의 프레임을 다루는 만큼 특별한 오류 제어 방식이 필요하다.

 

GO-BACK-N 방식

 

윈도우의 크기가 9라면 1번부터 9번까지의 프레임을 수신 호스트로 보낼 수 있다. 그런데 만약 5번 프레임의 NAK응답이 들어온다면, 5번 프레임부터 9번 프레임까지 전부 재전송 하는 방식이 GO-BACK-N 방식이다.

 

 

수신호스트는 5번부터 9번까지의 프레임을 모두 버린다. 5번부터 9번 안에는 정상적인 프레임도 존재하지만 그냥 버린다. 어떻게 보면 비효율적이지만 복잡한 계산없이 단순하게 오류제어를 함으로써 전송효율을 높이는 것이다.

선택적 재전송 방식 (Selective Retransmission)

 

GO-BACK-N 방식처럼 전부 버리는 것이 아닌, 오류가 발생한 프레임만 선택적으로 재전송하는 방식이 Selective Retransmission이다.

 

.

수신 호스트는 5번 프레임에서 오류를 검출하면 NAK응답을 송신호스트로 전송한다. 그리고 나머지 6번-9번은 잠시 보관한다. 5번 프레임이 재전송되어 들어오면 다시 순서대로 프레임 오류검사를 시작한다. 9번까지 ACK응답이 잘 들어오면 송신호스트는 다시 윈도우 크기만큼의 프레임을 전송한다.

 

피기배킹(Piggybacking)

 

지금까지는 데이터 프레임과 응답 프레임이 서로 다른 객체였다. 피기배킹에서는 데이터 프레임과 응답 프레임이 하나의 패키지로 전송된다. 피기배킹 방식은 송신호스트와 수신호스트가 구분되어 있지 않은 양방향 통신인 경우 유용하게 사용된다.

 

 

위 그림과 같이, 데이터 프레임을 전송할 때 ACK응답도 같이 패키지로 전송하는 것이다. 만약 ACK응답 전송 시점에 데이터 프레임을 전송하지 않는다면 혼자 전송되기도 한다. 그러나 웬만하면 데이터 프레임과 같이 전송되기에 데이터 프레임을 얼마나 기다리느냐에 따라서 시스템 성능이 달라진다.

 

 

---

참고자료

쉽게 배우는 데이터 통신과 컴퓨터 네트워크

저자 : 박기현

출판 : 한빛아카데미발매2016.12.26.