두 프로토콜 중 슬라이딩 윈도우 프로토콜은 중지 및 대기 프로토콜보다 효율적입니다.
비교 차트
| 비교 근거 | 정지 및 대기 프로토콜 | 슬라이딩 윈도우 프로토콜 |
|---|---|---|
| 행동 | 요청 및 답장 | 동시 전송 |
| 전송 가능한 프레임 수 | 오직 하나 | 배수 |
| 능률 | 적게 | 상대적으로 |
| 승인 | 도착하는 각 패킷 다음에 전송됩니다. | 확인 응답 창이 유지됩니다. |
| 전송 유형 | 반이중 | 전이중 |
| 전달 지연 | 긴 | 짧은 |
| 링크 활용 | 가난한 | 보다 나은 |
Stop-and-Wait 프로토콜의 정의
통신에서 송신 측에서 데이터를 전송하는 속도가 수신 측에서 데이터를 수신하는 속도보다 매우 높다면 네트워크가 이러한 종류의 사례를 어떻게 처리 할 것인가? 송신자와 수신자의 작업 속도가 변하지 않아야합니다. stop-and-wait 프로토콜 은이 문제에 대한 해결책으로 떠 올랐습니다. 이 프로토콜에서 보낸 사람은 프레임을 보낸 다음 승인을 기다립니다. 수신자가 송신자에게 확인 응답을 보내면 수신자는 더 나아가서 다른 프레임을 보냅니다.
stop-and-wait 프로토콜의 예는 RPC (Remote Procedure Call) 입니다. 서브 루틴 호출이 한 장치의 프로그램에서 다른 장치의 라이브러리 루틴으로 구현되는 유사한 패턴에서 작동하기 때문에 RPC (Remote Procedure Call) 입니다. 대부분의 프로그램은 단일 스레드이므로 진행하기 전에 응답을 기다리고 다른 요청을 보냅니다.
슬라이딩 윈도우 프로토콜의 정의
중지 및 대기 프로토콜과 마찬가지로 슬라이딩 창 프로토콜 은 흐름 제어 메커니즘을 구현하는 방법이기도합니다. 제한된 양의 데이터를 한 번에 한 방향으로 전송할 수있는 중지 및 대기 프로토콜의 단점을 제거했습니다. 슬라이딩 윈도우 프로토콜의 성능은 여러 프레임을 동시에 양방향으로 전송함으로써 향상되었습니다 (즉, n> 1, stop-and-wait 제한 n은 1). 이 방식에서 송신자는 프레임을 추적하기 위해 수신자에게 순차적으로 넘버링 된 프레임을 보낸다. 헤더 크기가 n 비트라면 시퀀스의 범위는 0에서 (2n-1)이다.
여기에있는 창은 버퍼가 비어있는 내용을 읽은 후 수신자가 읽지 않을 때까지 데이터를 저장하는 데 사용되는 버퍼를 나타냅니다. 그것은 두 가지 형태의 창을 사용하는데, 창과 창은 (2n-1)까지 범위를 가질 수 있습니다. 송신 창은 송신 된 프레임과 관련된 일련 번호를 유지하며 발신자 측에서 제어됩니다.
TCP 프로토콜 은 슬라이딩 윈도우 프로토콜로 작동하며 운영 체제의 커널에있는 버퍼를 사용합니다.
Stop-and-Wait 프로토콜과 슬라이딩 윈도우 프로토콜 간의 주요 차이점
- 중지 및 대기 프로토콜은 요청 및 응답 모델을 따릅니다. 반대로, 슬라이딩 윈도우 프로토콜에서, 프레임들은 특정 윈도우 크기에 대해 자발적으로 전송된다.
- 슬라이딩 윈도우가 한 번에 하나 이상의 프레임을 전송하는 동안 정지 및 대기 프로토콜에서 한 번에 하나의 프레임 만 전송됩니다.
- 슬라이딩 윈도우 프로토콜의 효율성은 짧은 전파 지연을 생성하기 때문에 중지 및 대기 프로토콜 이상의 것입니다.
- 정지 및 대기 프로토콜은 각 프레임을 수신 한 후 수신자 측에서 수신 확인을 생성하지만, 슬라이딩 창에서 수신 확인은 특정 프레임 세트를 수신 한 후에 생성됩니다.
- 중지 및 대기 프로토콜의 전송 모드는 반이중입니다. 반대로 슬라이딩 윈도우의 경우 전이중입니다.
- 슬라이딩 윈도우 프로토콜은 링크를 효과적으로 활용합니다. 대조적으로, 중지 및 대기 프로토콜의 링크 활용도는 열등합니다.
결론
프로토콜, 중지 및 대기 및 슬라이딩 창 프로토콜은 모두 흐름 제어를위한 메커니즘을 제공합니다. 그러나 지연 및 대기 프로토콜이 네트워크 리소스를 낭비하는 동안 슬라이딩 창 프로토콜의 성능은 대역폭을 효과적으로 활용하므로 중지 및 대기 프로토콜보다 성능이 우수합니다.
