[CS/ Network] 컴퓨터 네트워킹 하향식 접근 8판 3장 트렌스포트 계층 3.4 신뢰적인 데이터 전송의 원리

3.4 신뢰적인데이터전송의원리 183
3.4.1 신뢰적인데이터전송 프로토콜의 구축 185
3.4.2 파이프라이닝된 신뢰적인데이터전송 프로토콜 193
3.4.3 GBN 197
3.4.4 SR 201

• 신뢰적인 데이터 전송 = 트랜스포트 계층뿐만 아니라 링크 계층, 애플리케이션 계층에서도 발생 -> 네트워킹에서 매우 중요
• 상위 계층 객체에게 제공되는 서비스 추상화 = 데이터가 전송될 수 있는 신뢰적인 채널의 서비스 추상화
• 신뢰적인 채널: 전송된 데이터가 손상(0<->1), 손실X, 순서 보장
  • = TCP가 인터넷 애플리제이션에게 제공하는 서비스 모델
• ㄴ 이러한 서비스 추상화를 구현하는 것이 신뢰적인 데이터 전송 프로토콜(reliable
  transfer protocol)의 의무
• 이 작업은 아래 계층(비신뢰적인 점대점 채널 가정)이 신뢰적이지 않을 수 있어서 어려움
  • ex) TCP : 비신뢰적인 종단 간의 네트워크 계층(IP)의 바로 상위에 구현
• 하위 채널에서 비트 손상이나, 전체 패킷 손실하면 어케함?
  • 가정 : 순서는 보장 됨.
  • 그림 3.8(b): 데이터 전송 프로토콜의 인터페이스
    • 데이터 전송 프로토콜의 송신 측 : rdt_send () 호출 = 위쪽으로부터 호출됨
      • rdt = reliable data transfer 프로토콜
      • _send = rdt의 송신측이 호출
    • 수신 측 : rdt_rcv () 호출 = 패킷이 채널의 수신 측으로 도착했을 때 호출됨.
      -rdt 프로토콜이 상위 계층에 데이터를 전달할 때 deliver_data() 호출
  • 이제부터 프로토콜 데이터 단위를 ‘세그먼트’보다는 일반 용어‘패킷'을 사용
    • 대체로 컴퓨터 네트워크에 적용 (어느 특정 계층에서만 속함X)
• 이 절에선 단방향 데이터 전송의 경우인 송신->수신 측까지의 데이터 전송만을 고려
• 신뢰적인 양방향(전이중) 데이터는 어렵지 않지만，설명은 상당히 복잡
  • 단방향데이터 전송만 생각하더라도 그림 3.8처럼 프로토콜의 송신 측과 수신 측이 양방향으로 패킷을 전달할 필요가 있음을 유의
• rdt의 송신 측과 수신 측은 전송 데이터를 포함하는 패킷을 교환하는 것 외에 제어 패킷을 양쪽으로 전송해야 한다는 것을 볼 것이다.
• rdt의 송신 측과 수신 측 모두 udt_send () 를 호출함으로써 다른 쪽에 패킷을 전송
• udt: 비신뢰적인 데이터 전송(unreliable data transfer)

🚸 3.4.1 신뢰적인 데이터 전송 프로토콜의 구축

프로토콜 먼저 함 보고 시작하쟈~

완벽하게 신뢰적인 채널상에서의 신뢰적인 데이터 전송: rdt1.0

• 하위 채널이 완전히 신뢰적인 가장 간단한 경우를 고려
• 프로토콜 자체는 단순하며 rdtl.0이라 부름
• 그림 3.9 : rdtl. 0 송신자와 수신자에 대한 유한상태 머신(finite-state machine, FSM) 정리
  • 송신자에 대해 그리고 수신자에 대해 분리된 FSM이 있다는 것에 유의
  • 그림 3.9에서 송신자와 수신자 FSM은 각각 하나의 상태만 가짐
    • (ㄴ-> 전이는 필연적으로 그 상태로부터 자신으로 되돌아온다.)
• 그림 3.9 FSM 구성 요소 설명
  • FSM 설명에 있는 화살표 : 한 상태로부터 다른 상태로의 전이
  • 전이를 일으키는 이벤트(event) : 변화를 표기하는 가로선 위에 나타냄
  • 이벤트가 발생했을 때의 액션(action) : 가로선 아래에 나타냄
  • 이벤트 발생 시 어떠한 행동X or 어떠한 이벤트 발생 없이 행동이 취해질 때，
    동작이나 이벤트가 없음을 명시하기 위해 각각 가로선 아래나 위에 기호 A 사용
  • FSM의 초기 상태 : 점선 화살표로 표시 (후에 복잡해지면 중요)
• rdt의 송신 측
  • rdt_send(data) 이벤트에 의해 상위 계층으로부터 데이터 수신
    -> 데이터를 포함한 패킷 생성(make_pkt(data)) -> 패킷을 채널로 송신
  • ㄴ 상위 계층 애플리케이션의 호출에 의해 발생(ex : rdt_send())
• rdt의 수신 측
  • rdt_rcv (packet) 이벤트에 의해 하위의 채널로부터 패킷 수신
    -> 패킷으로부터 데이터를 추출(extract(packet, data))
    -> 데이터를 상위 계층으로 전달(deliver_data(data))
  • ㄴ 하위 계층 프로토콜로부터의 호출에 의해 발생(예: rdt_rcv())
• 이러한 간단한 프로토콜에서는 데이터 단위와 패킷의 차이점이 없다.
• 모든 패킷 흐름은 송신자로부터 수신자까지
  = 완전히 신뢰적인 채널에서는 오류X -> 수신 측이 어떤한 피드백 제공 필요X
• 송신자가 데이터를 송신하자마자 수신 자는데이터를 수신할 수 있다고 가정했음올 유념
  = 수신자가 송신자에게 천천히 보내라는 것을 요청할 필요 X
  

비트 오류가 있는 채널상에서의 신뢰적 데이터 전송: rdt2.0

• 하위 채널에서 패킷 안의 비트들이 손상된다는 모델 가정
  • ㄴ 패킷이 전송 또는 전파되거나 버퍼링될 때 네트워크의 물리적 구성요소에서 발생
  • 전송된 모든 패킷 순서 보장 가정
• 메시지 받아쓰기 프로토콜 : 수신자가 아래 두 응답 중 하나를 송신자로 보냄
  • 긍정 확인응답(positive acknowledgment, “OK”)
  • 부정 확인응답(negativeacknowledgment, “그것을 반복해주세요”)
• 자동 재전송 요구(Automatic Repeat reQuest, ARQ) 프로토콜 : 위 처럼 재전송 기반 신뢰적 데이터 전송 프로토콜
  • 비트 오류를 처리하기 위해 기본적으로 다음과 같은 세 가지 부가 프로토콜 기능 요구
  1. 오류 검출 : 비트 오류가 발생했을 때 수신자가 검출할 수 있는 기능이 필요
     • 지금은 그냥 송신자로부터 수신자에게 전송되는 추가 비트들이 요구된다고만 알자~
     • 추가 비트들은 rdt2.0 데이터 패킷의 패킷 체크섬 필드로 모아질 것
  2. 수신자 피드백 : 송신자가 수신자의 상태를 알기 위한 유일한 방법
     • rdt2.0 프로토콜은 수신자 -> 송신자 쪽으로 ACK와 NAK 패킷들 전송
     • 원칙적으로 이러한 패킷은 단지 한 비트 길이면 된다. ex) 0:NAK, 1:ACK
  3. 재전송 : 수신자에서 오류를 가지고 수신된 패킷은 송신자에 의해 재전송 됨.
• 그림 3.10은 오류 검출，긍정 확인응답, 부정 확인응답들을 채택하는 데이터 전송 프로토콜 rdt2.0의 FSM
  • 송신 측 FSM은 2개의 상태를 가짐
    • 왼쪽 상태에서 송신 측 프로토콜은 상위 계층으로부터 데이터가 전달되기를 기다림. - rdt_send(data) 이벤트가 발생
      -> 패킷 체크섬+전송 데이터를 포함하는 패킷(sndpkt)을 생성 ->
      -> udt_send(sndpkt) 동작을 통해 전송
    • 오른쪽 상태에서 송신자 프로토콜은 수신자로부터의 ACK 또는 NAK 패킷을 기다림
    • 만약 ACK 패킷이 수신된다면(rdt_cv(rcvpkt) && isACK (rcvpkt))
      -> 송신자는 가장 최근에 전송된 패킷이 정확하게 수신되었음을 알게 됨
      -> 프로토콜은 상위 계층으로부터 데이터를 기다리는 상태로 돌아감.
    • 만약 NAK가 수신되면
      -> 프로토콜은 마지막 패킷을 재전송
      -> 재전송된 데이터 패킷 응답으로 ACK 또는 NAK를 기다림
      • 이때는 상위 계층으로부터 더 이상의 데이터를 전달받을 수 없다는 점에 유의
        = rdt_send () 이벤트는 발생X
      • 이는 오직 송신자가 ACK를 수신하고 이 상태를 떠난 후에 발생
        = 수신자가 현재의 패킷을 정확하게 수신 확인 전까지 새 데이터 전달X
      • ㄴ=> rdt2.0과 같은 프로토콜은 전송 후 대기(stop-and-wait) 프로토콜
  • 수신자 측 FSM은 아직 단일 상태를 가짐
    • 패킷 수신 -> 수신된 패킷의 손상여부에 따라 ACK 또는 NAK로 응답
    • rdt_rcv(rcvpkt) && corrupt (rcvpkt) : 패킷이 수신되고 오류가 검출되는 이벤트에 대응

rdt2.0의 수정된 버전인 rdt2.1에 대한 FSM

• 프로토콜 rdt2.0의 치명적인 결함
  • 여기서는 ACK 또는 NAK 패킷이 손상될 수 있다는 가능성을 고려X
    • 이러한 사소한 실수는 생각보다 간단치X
      -> 최소한 그러한 오류를 검출위해 ACK와 NAK패킷에 대한 체크섬 비트 추가
  • +) 어떻게 프로토콜이 ACK 또는 NAK 패킷 오류로부터 복구됨?
    • ACK 또는NCK가 손상된다면，송신자는 수신자가 전송된 데이터의 마지막 부분을 올바르게 수신했는지를 알 방법이 없음
• ㄴ 해결책 : 데이터 패킷 순서 번호(새로운 추가 필드)를 삽입하는 방식으로 데이터 패킷에 송신자가 번호를 붙이는 것
  • 수신자는 수신된 패킷이 재전송받을 지를 결정할 때는 이 순서 번호만 확인하면 됨.
    • 가장 최근에 받은 응답 패킷 번호가 같으면 재전송, 아니면 새 패킷 전송
    • 일반적으로 패킷 손상X 채널 가정 -> ACK, NCK 패킷의 순서 번호 나타낼 필요X
      • 여기서는 가장 최근에 받은 응답 패킷은 가장 최근에 전송된 데이터 패킷에 대한 응답으로 함
• rdt2.1 송신자와 수신자 FSM은 전보다 두 배 많은 상태를 가짐
  • 프로토콜 상태가 현재 전송되고 있거나，수신자가 기다리고있는 패킷이 순서 번호 0 또는 1을 가져야 하는지를 반영해야 하기 때문
  • 0번 패킷이 송신되고 있거나 기다리고 있는 상태에서의 동작
    = 1번 패킷이 송신되고 있거나 기다리고 있는 상태의 반대 (단지 순서 번호의 차이)
  • 수신자로부터 송신자까지의 긍정 확인응답과 부정 확인응답을 모두 포함
  • 순서가 바뀐 패킷이 수신:수신자는 이미 전에 수신한 패킷에 대한 긍정 확인응답 전송
    • 직전 패킷에 대해 ACK를 송신 = NAK를 송신한 것과 같은 효과
  • 손상된 패킷이 수신 : 수신자는 부정 확인응답 전송
    

rdt2.0의 수정된 버전인 rdt2.2에 대한 FSM

• 비트 오류를 갖는 채널을 위한 NAK 없는 신뢰적인 데이터 전송 프로토콜
  • rtd2.1과 rtd2.2의 미묘한 차이
    • 수신자가 반드시 ACK 메시지에 의해 확인응답되는 패킷의 순서 번호 포함
      • = NAK 안씀요
      • 수신자 FSM의 make_pkt()에 ACK,0 또는 ACK,1 인 인수를 넣어서 수행
    • 송신자는 수반 ACK 메시지에 의해 확인응답된 패킷의 순서 번호를 반드시 검사
      • 송신자 FSM의 isACK(）에 0 또는 1 인 인수를 넣어서 수행

2.0 : 졸라간단
2.1 : ACK 중복으로 순서바뀐거 알수있음, NAK로 패킷 손상알 수있음
2.2 : ACK만으로 순서 바뀐거, 손상 둘다 알 수있음. NAK 안씀요

비트 오류와 손실 있는 채널상에서의 신뢰적인 데이터 전송: rdt3.0

• 비트가 손상되는 것 + 하위 채널이 패킷을 손실하는 경우 고려(오늘날의 컴퓨터 네트워크 ex 인터넷)
  • 패킷 손실이 발생했을 때 어떤 행동올 한 것인가
    • 체크섬，순서 번호, ACK 패킷，재전송의 사용
  • 어떻게 패킷 손실을 검출할 것인가
    • 새로운 프로토콜 메커니즘 추가 : 송신자에게 손실된 패킷의 검출과 회복 책임을 부여
    • ACK를 손실 -> 수신자로부터 어떠한 응답X
      -> 송신자가 패킷 손실을 확신할 정도로 충분한 시간을 기다리고, 데이터 패킷 재전송
    • 얼마나 기다릴꺼임? -> 예측 어려움
      • 현명하게 선택해~ -> 꼭 손실 안된 경우라도 오래 기다리면 재전송 = 중복 패킷 수신 가능
        => 채널에서 중복 데이터 패킷（duplicate data packet)의 가능성 포함
      • 이러한 중복 패킷을 순서번호로 처리 가능 good~
  • 시간 기반의 재전송 메커니즘을 구현하기 위해，주어진 시간이 지난 후에 송신자를 인터럽트（중단）할 수 있는 카운트다운 타이머（countdown timer) 필요
    • 송신자의 동작
      (1） 매 패킷（첫 번째 또는 재전송 패킷）이 송신된 시간에 타이머를 시작함
      (2） 타이머 인터럽트에 반응함（적당한 행동을 취함）
      (3） 타이머를 멈춤
• 패킷의 순서 번호가 0과 1 이 번갈아 일어나므로，프로토콜 rdt3.0은 때때로 얼터네이팅 비트 프로토콜(alternating-bit protocol)이라고 부른다
• 그림 3.15 : 패킷이 손상되거나 손실될 수 있는 채널에서 데이터를 신뢰적으로 전송하는 프로토콜인 rdt3.0에 대한 송신자 FSM
  

🏭 3.4.2 파이프라이닝된 신뢰적인 데이터 전송 프로토콜

• 그림 3.16 : 프로토콜이 패킷 손실 또는 지연 없이 어떻게 동작하는지와 손실된 데이터 패킷을 어떻게 처리하는지를 보여준다.
  • 시간은 다이어그램의 위로부터 아래로 움직임
    = 패킷에 대한 수신 시간 < 패킷 전송 시간 : 전송 지연과 전파 지연 때문에
  • (b)〜(d) : 송신 측 꺾쇠는 타이머가 설정된 후에 타임아웃된 시간을 가리킴
  • rtd3.0 = alternating-bit 프로토콜(패킷의 순서 번호가 0과 1 이 교차)이라고도 함.
• 프로토콜 rdt3.0의 문제점 : 전송 후 대기 -> 졸라 나쁜 성능
  • 링크로 패킷을 실제로 전송하는 데 필요한 시간 : d(trans) = L/R
  • 송신자 전송 시간 : t = RTT/2 + L/R
  • 머 이것저것(책 194~)하면 송신자 이용률이 0.027%로 개꾸진걸 볼 수 있음
    • 송신자 이용률 : 실제로 분주하게 비트를 전송하는 데만 걸린 시간(또는 채널)
      
  • 여기서는 송신자와 수신자 사이의 중간 라우터에서 발생하는 처리 지연, 큐잉 지연
    + 송신자와 수신자에서의 하위 계충 프로토콜 처리 시간을 무시
    => 이를 포함하면 지연이 더욱 증가하고 더 꾸지다는 거를 볼 수 있음.
    

• 성능 문제 해결책 : 파이프라이닝(pipelining)
  : 전송 후 대기 방식으로 동작X -> 송신자에게 그림 3.17(b)에서 보이는 것처럼 확인응답을 기다리지 않고 여러 패킷을 전송하도록 허용
  • 확인 응답 전 N개 패킷을 보내면 이론상 이용률 N배
  • 많은 전송 중인 송신자-수신자 패킷을 파이프라인에 채워 넣음으로써 나타냄
  • 신뢰적인 데이터 전송 프로토콜에서의 중요성
    1. 순서 번호의 범위가 커져야 한다.
    • 각각의 전송 중인 패킷(재전송은 고려X)은 유일한 순서 번호를 가져야 함.
    • 전송 중인 확인응답(ack)이 안 된 패킷이 여럿 있을지도 모르기 때문
    2. 프로토콜의 송신 측과 수신 측은 패킷 하나 이상을 버퍼링해야 한다.
    • 송신자는 최소한 전송되었으나 확인응답되지 않은 패킷을 버퍼링
    • 정확하게 수신된 패킷의 버퍼링은 수신자에게서도 필요
    3. 필요한 순서 번호의 범위와 버퍼링 조건은 데이터 전송 프로토콜이 손실 패킷, 손상 패킷, 상당히 지연된 패킷들에 대해 응답히는 방식에 달려 있다.
    • 파이프라인 오류 회복의 두 가지 기본적인 접근 방법
      • GBN（Go-Back-N，N부터 반복)
      • SR（Selective Repeat, 선택적 반복）

🔂 3.4.3 GBN

• GBN（Go-Back-N，N부터 반복) : 프로토콜에서 송신자는 확인응답을 기다리지 않고 여러 패킷을 전송（가능할 때）가능
  • 그러나 파이프라인에서 확인응답이 안 된 패킷의 최대 허용 수보다 크지 말아야 함.
• 그림 3.19 : GBN 프로토콜에서 송신자 관점의 순서 번호 범위
  • base : 확인응답이 안 된 가장 오래된 패킷의 순서 번호
  • nextseqnum（전송될 다음 패킷의 순서 번호）: 사용되지 않은 가장 작은 순서 번호
  • 순서 번호의 범위에서 4개의 간격 식별
    • 간격 [0, base-1]에서 순서 번호 : 이미 전송되고 확인응답이 된 패킷
    • 간격 [base, nextseqnum-1] : 송신은 되었지만 아직 확인응답되지 않은 패킷
    • 간격 [nextseqnum, base+N-1] : 상위 계층으로부터 데이터가 도착하면 바로 전송될 수 있는 패킷
    • 간격 [base+N,~] : 파이프라인에서 확인응답이 안 된 패킷（특별히，순서 번호 base를 가진 패킷）의 확인응답이 도착할 때까지 사용 불가
  • 전송되었지만 아직 확인응답이 안 된 패킷을 위해 허용할 수 있는 순서 번호의 범위는 순서 번호의 범위상에서 크기가 N인 ‘윈도’로 나타냄
    • 프로토콜이 동작할 때，이 윈도는 순서 번호 공간에서 오른쪽으로 이동（slide）된다.
    • N을 윈도 크기（window size）라 부름
    • GBN 프로토콜은 슬라이딩 윈도 프로토콜（sliding-window protocol）이라고도 부른다
• 실제로 패킷의 순서 번호는 패킷 헤더 안의 고정된 길이 필드에 포함
  • 만약 k가 패킷 순서 번호 필드의 비트 수라면，순서 번호의 범위는 [0, 2^k 一 1]이 됨
  • 순서 번호의 제한된 범위에서, 순서 번호를 포함하는 모든 계산은 모듈로 2^k 연산을 이용
    • 순서 번호 공간은 크기 2^k의 링처럼 생각 = 순서 번호 2^k 一 1 다음에 0
  • rdt3.0이 1비트의 순서 번호 필드를 가지므로 [0, 1]의 순서 번호 범위를 갖는다는 것을 기억
• 필드의 TCP 순서 번호는 패킷 단위라기보다는 바이트 스트림에서 바이트를 세는 수

• 그림 3.20, 그림 3.21 : ACK 기반의 NAK 없는 GBN 프로토콜의 송신 측과 수신측의 확장된 FSM
  • base와 nextseqnum 변수 추가
  • 이러한 변수에서의 동작과 이러한 변수를 포함하는 조건부 동작을 추가
    => 이 FSM을 확장된 FSM（extended FSM）
• GBN 송신자는 다음과 같은 세 가지 타입의 이벤트에 반응
  • 상위로부터의 호출 : rdt_send()가 위에서 호출 됨
    -> 송신자는 우선 윈도가 가득 찼는지 = N개의 아직 확인응답되지 않은 패킷이 있는지를 확인
    • 만약 윈도가 가득 차 있지 않다면, 패킷이 생성 -> 송신 -> 변수들 갱신
    • 만약 윈도가 가득 차 있다면，
      -> 데이터를 상위 계층으로 그대로 반환(= 윈도가 가득 차 있다는 의미)
      -> 상위 계층은 나중에 재시도
      • 실제적인 구현에서 송신자는 이 데이터를 버퍼링(즉시 송신하진 않음)
      • ㄴ OR 오직 윈도가 가득 차 있지 않을 때만 rdt_send () 를 호출하는 동기화 메커니즘(예: 세마포어(semaphore) 또는 플래그(flag))을 사용
  • ACK의 수신 : 순서 번호 n을 가진 패킷에 대한 확인응답은 누적 확인응답으로 인식
    • 누적 확인응답은 n까지의 순서 번호를 가진 모든 패킷에 대한 확인 응답(수신 측에서 올바르게 수신된 n을 포함)
  • 타임아웃 이벤트 : 타이머는 손실된 데이터 또는 손실된 확인응답 패킷으로부터 회복하는 데 사용 - 타임아웃이 발생한다면，송신자는 전송했지만 아직 확인응답되지 않은 모든 패킷 재송신
    • 만일 한 ACK가 수신되었지만, 추가로 ‘전송했지만，아직 확인응답안 된 패킷’이 아직 존재한다면，타이머는 재시작.
    • 만약 아직 확인응답 안 된 패킷이 없다면，타이머는 멈춘다
• GBN에서의 수신자의 행동(단순)
  • 만약 순서 번호 n을 가진 패킷이 오류X + 순서대로 수신 -> 패킷 n에 대한 ACK를 송신 -> 상위 계층에 패킷의 데이터 부분을 전달
  • 그 외의 경우에는 수신자는 그 패킷 폐기 -> 가장 최근에 제대로 수신된 순서의 패킷에 대한 ACK 재전송
  • 패킷이 상위 계충에 한번에 하나씩 전송됨 -> 패킷 k가 수신되고 상위 계층에 전달됨
    = k보다 낮은 순서 번호를 가진 모든 패킷 또한 전달 됨
  • => 누적 확인 응답을 사용하는 것은 GBN을 위한 자연스러운 선택
  • 왜 정확하게 왔는데 순서바뀐 거 버림? -> 수신자가 상위 계층에 데이터를 순서대로 전달해야 함
    • 안 버리면 순서 잘 못온거 버퍼링했다가 앞에거 오면 전달해야함->앞에거가 또 잘못온거면?ㅋㅋ
    • 심플 이즈 베스트 버리면 버퍼링이 간단~ => 수신자는 다음 패킷 순서 번호만 알면 됨
    • ㄴ 위 값은 그림 3.21 수신자 FSM에서 보이는 변수 expectedseqnum에서 유지
    • 물론，그 패킷의 재전송이 손실, 왜곡 가능성 때문에 많은 재전송이 필요할 지도모르는 단점有
    • <-> 송신자는 윈도 상,하위 경계와, 윈도 내 nextseqnum 위치 유지
      

• 그림 3.22 : 윈도 크기가 4 패킷인 경우에 대한 GBN 프로토콜의 동작
  • 이 윈도 크기의 제한 때문에 송신자는 패킷 0부터 3까지 송신
  • 그러나 송신을 계속 하기 전에 하나 이상의 패킷이 긍정 확인응답되는 것을 기다림
  • 각각의 성공적인 ACK(예 : ACKO, ACK1)가 수신되었을 때，윈도는 앞으로 이동하고 송신자는 하나의 새로운 패킷(pkt4와 pkt5, 각각)을 전송
  • 수신 측에서는 패킷 2가 손실되었으므로 패킷 3, 4, 5는 순서가 잘못된 패킷으로 발견되어 제거

• 어떤 프로토콜 스택에서 프로토콜 구현은 그림 3.20 확장된 FSM의 구현과 유사한 구조를 가짐.
• 이벤트 기반 프로그래밍 : 발생할 수 있는 다양한 이벤트에 대한 대응으로 취할 수 있는 동작을 구현하는 다양한 절차들과 유사
  • 다양한 프로시저들은 프로토콜 스택에서 다른 프로시저에 의해 호출, 인터럽트의 결과로 요청됨.
  • 송신자에서 이러한 이벤트는
    (1) rdt_send()를 호출하기 위한 상위 계층 개체로부터의 호출
    (2) 타이머 인터럽트
    (3) 패킷이 도착했을 때 rdt_rcv ()를 호출하기 위한 하위 계층으로부터의 호출
• GBN 프로토콜은 TCP의 신뢰적인 데이터 전송 구성요소의 거의 모든 기술이 통합
  • 순서 번호，누적 확인응답，체크섬，타임아웃/재전송 동작에 대한 사용이 포함

🤏🏻 3.4.4 SR

• GBN의 성능 문제
  • 윈도 크기와 대역폭 지연 곱의 결과가 모두 클 때，많은 패킷이 파이프라인에 존재
  • 그러나 GBN은 패킷 하나의 오류 때문에 많은 패킷을 불필요하게 재전송
  • 채널 오류의 확률이 증가할수록 파이프라인은 불필요한 재전송 데이터로 채워짐
• SR(Selective Repeat) 프로토콜 : 수신자에서 오류(손실되거나 변조된)가 발생한 패킷을 수신했다고 의심되는 패킷만 송신자가 재전송 -> 불필요한 재전송을 피함
  • 필요에 따라 각각의 개별적인 재전송은 수신자가 올바르게 수신된 패킷에 대한 개별적인 확인응답을 요구
  • 윈도 크기 N은 파이프라인에서 아직 확인응답이 안 된 패킷 수를 제한하는 데 사용
  • ㄴ but 송신자는 윈도에 있는 몇몇 패킷에 대한 ACK를 이미 수신했을 것
• 그림 3.23 : 순서 번호 공간에 대한 SR 송신자와 수신자의 관점
  
• SR 수신자
  • 패킷의 순서와는 무관하게 손상 없이 수신된 패킷에 대한 확인응답 확인
    -> 순서가 바뀐 패킷은 누락된 패킷이 수신될 때까지 버퍼에 저장
    -> 누락된 패킷이 수신된 시점에서 일련의 패킷을 순서대로 상위 계충에 전달
• 그림 3.26은 손실된 패킷이 나타날 때까지의 SR 동작의 예
  • 수신자는 처음에 패킷 3. 4, 5를 버퍼에 저장하고，마지막으로 패킷 2가 수신되었을 때 패킷 2와 함께 상위 계층에 전달
    
• SR 송신자 이벤트와 행동
  1. 상위로부터 데이터 수신 :상위에서 데이터가 수신될 때，SR 송신자는 패킷의 다음 순서 번호를 검사
     • 순서 번호가 송신자 윈도 내에 있으면 데이터는 패킷으로 송신
     • 그렇지 않으면 GBN처럼 버퍼에 나중에 전송하기 위해 되돌려짐.
  2. 타임아웃 : 타이머는 손실된 패킷을 보호하기 위해 재사용
     • 타임아웃 시 오직 한 패킷만이 전송 -> 각 패킷은 자신의 논리 타이머를 가짐
     • ㄴ-> 하나의 하드웨어 타이머가 여러 개의 논리 타이머를 흉내
  3. ACK 수신: ACK가 수신되었을 때, SR 송신자는 그 ACK가 윈도 내에 있다면 그 패킷을 수신된 것으로 표기
     • 만약 패킷 순서 번호가 send_base와 같다면, 윈도 베이스는 가장 작은 순서 번호를 가진 아직 확인응답되지 않은 패깃으로 옮겨진다.
     • 만약 윈도가 이동하고 윈도 내의 순서 번호를 가진 미전송 패킷이 있다면，이 패킷들은 전송된다.
• SR 수신자 이벤트와 행동
  1. [rcv_base, rcv_base+N-l] 내의 순서 번호를 가진 패킷이 손상 없이 수신
     • 이 경우는 수신된 패킷이 수신자의 윈도에 속하는 것이며, 선택적인 ACK 패킷이 송신자에게 회신됨.
     • 만약 이 패킷이 이전에 수신되지 않았던 것이라면 버퍼에 저장됨.
     • 만약 이 패킷이 수신 윈도의 base와 같은 순서 번호를 가졌다면，
       이 패킷과 이전에 버퍼에 저장되어 연속적으로 번호를 가진 패킷들은 상위 계층으로 전달
     • ex)그림 3.26을 고려 : rcv__base=2의 순서 번호를 가진 패킷이 수신될 때, 이 패킷과 3,4, 5 패킷이 상위 계층에 전달 가능
  2. [rcv_base-N, rcv_base-1] 내의 순서 번호를 가진 패킷이 수신
     • 이 경우에는 이 패킷이 수신자가 이전에 확인 응답한 것이라도 ACK가 생성되어야 한다.
     • 확인 응답 안해주면 송신자의 윈도는 결코 앞으로 이동하지 않음.
     • 송신자와 수신자의 윈도가 항상 같지는 않다
     • 이러한 동기화 부족 : 순서 번호의 한정된 범위에 직면했을 때 중요
       • 그림 3.27 너무 큰 윈도를 가진 SR 수신자의 고민: 새 패킷인가. 아니면 재전송된 것인가?
       • ㄴ 뭐래노 ㅡㅡp204쪽, 쨰뜬 윈도 크기 <= 순서 번호 공간 크기
  3. 그 외의 경우,패킷을 무시한다

• 순서 번호가 재사용 -> 중복된 패킷들을 막을 수 있는 조치 필요
  • 실제 방식은 송신자가 이전에 송신된 순서 번호 x를 가진 패킷들이 더는 네트워크상
    에 없음을 어느 정도 ‘확신’할 때까지 순서 번호가 재사용되지 않음을 확실히 하는 것
  • 이는 패킷이 어느 일정 시간 이상으로 네트워크에서 존재할 수 없다는 가정에 의해
    이루어진다. (대략 3분)