rdt 3.0의 가장큰 문제점 -> stop-and-wait 프로토콜이라는 점
즉, 하나의 패킷보내고 오류 처리 다하고 나서 다음 패킷보내는 방식이다.
듣기만해도 어마어마하게 늦을거 같지않은가...
얼마나 비효율적인지 계산해보자
1 Gbps전송률(R)을 가진 채널로 두 호스트가 연결되어있고 RTT는 30ms라 하자
헤더필드와 데이터를 모두 포함해서 패킷당 1000bytes의 패킷크기(L)을 가지고
1Gbps 링크를 통과하는데 걸리는 시간은 8마이크로초이다.
송신때 0.5 RTT + 8마이크로초
수신때 0.5 RTT면 총 시간은 30.008 ms 인데 데이터 전송시간은 0.008ms이다.
즉, 이용률은 0.00027이라는 끔직한 이용률이 나온다.
잘 이해가 안된다면 1Gbps 짜리 네트워크를 쓰는데 267 kbps만 이용가능하다.
참고로 유튜브 240p 짜리 영상이 300kbps~700kbps 정도 된다.
이런 문제 때문에 대두된것이 파이프라이닝!
사진처럼 3개의 패킷을 연달아 전송시키면 RTT(첫 패킷전송 응답 까지 걸리는시간) 동일하나
그 사이에 3개의 패킷을 전송했다.
즉, 송신자의 이용률(같은 시간내에 얼마나 보내냐)는 3배 증가함을 알수있다.
위 같은 방법을 이용하기 위해서는 다음과 같은 조건들이 필요하다.
1. 순서는 유일하게 가진다. (rdt 처럼 0,1을 쓰다가는 순서를 파악할수없음)
2. 송신과 수신측은 패킷을 버퍼링 해야한다.
3. 오류회복 기능을 버퍼링과 순서 번호의 범위등을 고려하여 만들어야한다. (GBN,SR 등이 존재)
GBN은 파이프라이닝의 방법중 하나이다.
ACK를 기다리지않고 여러 패킷을 보내는 방식이다.
특정한 윈도우를 가지고 있으며 윈도우 안의 패킷만을 관리, 사용한다.
이전에 전송했던 패킷의 올바른 ACK응답이 온다면 한칸 옆으로 윈도우가 이동하며
이때문에 슬라이딩 윈도우 프로토콜(sliding-window protocol) 이라고도 불린다.
특징은 다음과 같다.
올바른 순서대로 패킷이 오지않으면 (순서대로)
순서에 맞지 않는 패킷은 다버린다.
FSM를 보며 살펴보자
sender
상위 프로토콜에서 접근한다
rdt_send(data) 실행
if(nextseqnum<base + N) -> 윈도우안에 사용가능한 패킷이 존재한다면
패킷만들어서 전송
if(base==nextseqnum) -> 전송후 보니 방금 보낸 패킷이 윈도우의 첫 패킷이면
start_timer
nestseqnum++
else (윈도우에 사용가능 패킷없으면)
전송불가
timeout
-> 타이머 다시 시작
지금까지 보냈던 패킷 전부 다시전송
rdt_rcv(rcvpkt)&¬corrupt(rcvpkt) -> 리시버한테 응답 받았고 오류없으면
base 하나증가
if(base == nextseqnum) -> 만약 베이스가 새로보내야할 패킷이라면
타이머 중지
else
타이머 초기화
red_rcv(rcvpkt)
&& corrupt(rcvpkt) -> 만약 잘못된 값 즉, 이미 보낸 패킷의 ACK가 안오면 계속 대기
receiver
defalut
이전에 만들었던 ACK 계속전송
rdt_rcv(rcvpkt)&¬currupt(rcvpkt)&&hasseqnum(rcvpkt,expectedseqnum)
-> 패킷 이상없고 내가 원하던 패킷순서면
새로 ACK 해당 순서에 맞게 만들어서 전송
** 만약 패킷문제있다면
default가 실행됨
둘을 합친다면 위그림과 같다.
sender는 윈도우 내에서 계속 패킷을 보내고
receiver는 원하는 순서인지 확인후 아니라면 순서맞게 보내라고 ACK 반복
타임아웃되면 이전에 보냈던 패킷 다시 전부전송
<장점>
단순하다
<단점>
비효율적이다.
만약 많은 패킷이 윈도우 안에 꽉차있고 오류가 발생한다면 상당히 많은수의 패킷을 재전송해야함
*** 주의 : GBN에서 시퀀스 넘버는 바이트가 아닌 단순 패킷의 번호임
선택 반복 프로토콜이다.
앞선 GBN의 방식은 올바른 순서로 올때만 ACK를 보내고 그렇지 않다면 패킷을 버리는 방식이였다면
SR방식은 순서에 맞지 않더라도 올바른 패킷이 온다면 ACK를 보내고 버퍼에 저장해둔다.
이때 sender 또한 순서에 맞지 않더라도 ACK를 받으면 ACK를 받았다고 표시한다.
만약 한 패킷이 타임아웃 된다면 (이때 각패킷별로 타이머가 관리되어야함)
재전송하고 이 패킷이 receiver측의 윈도우 밖에 있을수도 있다.
그럼에도 receiver는 다시한번 ACK를 전송해줘야한다.
버퍼에 쌓아뒀던 패킷들중 비는 부분이 없이 맞춰진다면 해당 부분을 상위 프로토콜로 올린뒤
ACK를 전송한다.
ex) 2 4 5 가 버퍼에 있다가 3을 받으면 2 3 4 5 전부 Demultiplexing 후 ACK 3