[네트워크] OSI 4계층, transport layer

transport layer

 

전송 프로토콜은 종단 시스템(End System)에서 실행. Process 간의 논리적인(Logical) 소통이다. 

송신 측: 애플리케이션 메시지를 세그먼트로 나누어 네트워크 계층으로 전달

수신 측: 세그먼트를 다시 메시지로 재조립하여 애플리케이션 계층으로 전달

 

신뢰성 있는 통신, in-order 통신이 필요한 경우 TCP를 사용한다.

• 혼잡 제어, 흐르 제어, 연결 설정 (hand-shaking) 등을 한다. 

unreliable, unordered 통신인 경우 UDP를 사용한다.

• 이는 "최선의 노력" (best-effort) 방식으로 동작하는 IP의 단순한 확장

다음과 같은 서비스는 제공되지 않습니다:

• 지연 보장 (delay guarantees)
• 대역폭 보장 (bandwidth guarantees)

---

multi plexing and demultiplexing

송신 측에서의 멀티플렉싱 (Multiplexing):

• 여러 소켓에서 오는 데이터를 처리하고, 전송 헤더를 추가합니다 (이 헤더는 나중에 역멀티플렉싱에 사용됩니다).

수신 측에서의 역멀티플렉싱 (Demultiplexing):

• 헤더 정보를 사용하여, 받은 세그먼트를 올바른 소켓으로 전달합니다.

 

 

demultiplexing이 일어날 때, 호스트는 IP 데이터그램을 수신합니다.

• 각 데이터그램에는 출발지 IP 주소, 목적지 IP 주소가 있음.
• 세그먼트에 출발지 포트 번호, 목적지 포트 번호가 포함되어 있습니다. 이는 32비트 주소로 표현됩니다.
• 각 데이터그램은 다른 헤더 필드와 함께 전송 계층 세그먼트를 운반합니다.
• 각 세그먼트에는 출발지와 목적지 포트 번호, 응용 프로그램 데이터가 포함됩니다.
• 호스트는 IP 주소와 포트 번호를 사용하여 데이터(페이로드) 세그먼트를 적절한 소켓으로 전송합니다.

연결 없는 멀티플렉싱

소켓을 생성할 때 DatagramSocket을 사용하고, 포트 번호를 지정합니다.

• • DatagramSocket mySocket1 = new DatagramSocket(12534);
• UDP 데이터그램을 전송할 때는 목적지 IP 주소와 포트 번호를 지정해야 합니다.
• 호스트가 UDP IP 데이터그램을 수신하면, 목적지 포트 번호를 확인합니다.
• 출발지 IP 주소나 포트 번호가 다르더라도, 동일한 목적지 포트 번호로 온 패킷은 해당 포트 번호의 소켓으로 전달됩니다.

즉, UDP에서는 목적지 포트 번호로 데이터를 구분하고 전달하는 연결 없는 멀티플렉싱 방식을 사용한다.

 

연결 지향 멀티플렉싱

TCP에서는 다음 4가지 값의 조합으로 소켓을 식별합니다:

• 소스 IP 주소
• 소스 포트 번호
• 목적지 IP 주소
• 목적지 포트 번호

이 4가지 값의 조합을 4튜플(4-tuple)이라고 합니다. 
서버 호스트는 동시에 많은 TCP 소켓을 지원할 수 있습니다. 각 소켓은 고유한 4튜플로 식별됩니다.
디-멀티플렉싱은 수신자가 이 4가지 값을 모두 사용하여 세그먼트를 적절한 소켓으로 전달하는 과정입니다.
예를 들어 웹 서버는 각 연결 클라이언트마다 다른 소켓을 사용하므로, 4튜플로 소켓을 구분하여 데이터를 전달합니다.

---

connectionless transport: UDP

UDP(User Datagram Protocol)는 RFC 768에 정의된 인터넷 전송 프로토콜입니다.

UDP의 주요 특징은 다음과 같습니다:

• 간소한 "베어본(bare bones)" 전송 서비스를 제공합니다.
• 베스트 에퍼트(best effort) 서비스를 제공하며, 패킷 손실이 발생할 수 있습니다.
• 연결 설정 과정(핸드셰이킹)이 없는 비연결형 프로토콜입니다.
• 각 UDP 세그먼트는 독립적으로 처리됩니다.
• 순서가 바뀌어 전달될 수 있습니다.

UDP는 주로 다음과 같은 애플리케이션에서 사용됩니다:

• 스트리밍 멀티미디어 앱 (패킷 손실을 견딜 수 있고, 전송률에 민감함)
• DNS (도메인 네임 시스템)
• SNMP (간단한 네트워크 관리 프로토콜)

신뢰성 있는 UDP 전송을 위해서는 애플리케이션 계층에서 별도의 메커니즘(예: 오류 복구)을 구현해야 합니다.

 

UDP가 필요한 주된 이유

1. 애플리케이션 데이터(페이로드)를 전송하는 간단한 방식이 필요합니다.
2. 연결 설정 과정이 필요 없어 지연 시간이 적습니다. 

• TCP와 달리 송신자와 수신자 사이에 연결 상태를 유지할 필요가 없습니다

3. 헤더 크기가 작아 효율적입니다.
4. 혼잡 제어 메커니즘이 없어 원하는 만큼 빠르게 데이터를 전송할 수 있습니다.

• TCP는 혼잡 제어로 인해 전송 속도가 제한될 수 있습니다.

즉, UDP는 연결 설정의 오버헤드 없이 데이터를 신속하게 전송할 수 있는 간단한 전송 프로토콜이 필요한 경우에 사용됩니다. 단, 신뢰성 보장은 애플리케이션 계층에서 별도로 구현해야 합니다.

 

UDP 체크섬 (계산 과정 이해 x)

UDP 체크섬의 목표는 전송 중에 발생한 비트 오류 등의 에러를 감지하는 것입니다.

송신자 측에서는 다음과 같이 동작합니다:

• 세그먼트의 내용(헤더 필드 포함)을 16비트 정수의 순차적 열로 취급합니다.
• 이 순차열에 대한 체크섬(1의 보수 합계)을 계산합니다. (길이가 MTU인가 그럼?)
• 계산된 체크섬 값을 UDP 세그먼트의 체크섬 필드에 삽입합니다.

수신자 측에서는 다음과 같이 동작합니다:

• 수신한 세그먼트의 내용으로 체크섬을 계산합니다.
• 계산된 체크섬과 수신한 세그먼트의 체크섬 필드 값을 비교합니다.
• 두 값이 다르면 에러가 감지된 것입니다.
• 두 값이 같다면 (아직) 에러가 감지되지 않은 것입니다. 하지만 여전히 에러가 있을 수 있습니다.

요약하면, UDP 체크섬은 전송 중 데이터가 변경되었는지 감지하는 간단한 에러 검출 메커니즘입니다.

---

Principles of reliable data transfer

신뢰성 있는 데이터 전송 프로토콜(rdt)의 복잡도는 기반 통신 채널의 신뢰성 특성에 따라 결정됩니다. 

- 통신 채널이 완전히 신뢰성이 있다면 rdt 프로토콜은 단순해집니다.
- 그러나 현실 세계의 통신 채널은 비트 에러, 패킷 손실, 패킷 지연, 패킷 중복 등의 문제가 발생할 수 있습니다.
- 이러한 신뢰성 없는 채널의 특성에 따라 rdt 프로토콜의 복잡도가 증가합니다.

따라서 신뢰성 있는 데이터 전송을 위해서는 기반 통신 채널의 특성을 정확히 파악하고, 그에 맞는 적절한 rdt 프로토콜 메커니즘을 설계해야 합니다.

 

rdt_send():

• 상위 계층(예: 애플리케이션)에서 호출되어 데이터를 전송하기 위해 사용됩니다.
• 전달할 데이터를 받아 rdt 계층에서 처리합니다.

deliver_data():

• rdt 계층에서 호출되어 수신된 데이터를 상위 계층으로 전달합니다.

udt_send():

• rdt 계층에서 호출되어 패킷을 신뢰할 수 없는 통신 채널을 통해 전송합니다.

rdt_rcv():

• 통신 채널을 통해 패킷이 도착하면 호출되어 rdt 계층에서 해당 패킷을 처리합니다.

상위 계층에서 데이터를 전송하고자 할 때 rdt_send()를 호출하면, 이 데이터는 rdt 계층으로 전달됩니다. rdt 계층에서는 데이터를 패킷으로 만듭니다. 그리고 udt_send()를 호출하여 이 패킷을 신뢰할 수 없는 통신 채널로 내보냅니다. 
수신 측에서는 rdt_rcv()를 통해 채널로부터 패킷을 받아옵니다. 받아온 패킷의 데이터는 deliver_data()를 호출하여 상위 계층으로 전달됩니다.
요컨대, 상위 계층과 rdt 계층 사이에서는 데이터 단위로, rdt 계층과 통신 채널 사이에서는 패킷 단위로 송수신이 이뤄지는 구조입니다.

신뢰성 있는 데이터 전송을 구현하기 위해 다음과 같은 접근 방식을 사용합니다:

• 단계적으로 신뢰성 있는 데이터 전송 프로토콜(rdt)의 송신측과 수신측을 개발합니다.
• 처음에는 단방향 데이터 전송만 고려합니다. 하지만 제어 정보는 양방향으로 흐를 것입니다.
• 송신측과 수신측의 동작을 정의하기 위해 유한상태기계(Finite State Machine, FSM)를 사용합니다.
• 점진적으로 더 복잡한 상황을 가정하며 프로토콜을 발전시켜 나갑니다. 예를 들어 초기에는 신뢰성 있는 데이터 전송만 고려하다가 나중에 대역폭 효율성, 전송 속도 등을 추가로 고려합니다.

 

이런 식으로 단계적이고 체계적인 접근을 통해 복잡한 신뢰성 있는 데이터 전송 프로토콜을 설계하고 구현할 수 있습니다. FSM을 사용하여 명확하게 각 상태와 이벤트를 정의함으로써 프로토콜의 정확성을 높일 수 있습니다.

---

rdt 1.0 - 완전히 신뢰할 수 있는 통신 채널 

• 기반 통신 채널은 완벽히 신뢰할 수 있습니다.
• 비트 에러가 발생하지 않습니다.
• 패킷 손실이 없습니다.

 

송신자와 수신자는 각각 별도의 유한상태기계(FSM)로 동작합니다.
송신자:

• 데이터를 기반 통신 채널로 전송합니다.

수신자:

• 기반 통신 채널로부터 데이터를 읽어옵니다.

이렇게 기반 채널이 완벽히 신뢰할 수 있다면, 별도의 오류 제어 메커니즘 없이 간단히 데이터를 송수신할 수 있습니다. 하지만 실제 네트워크 환경에서는 다양한 오류가 발생할 수 있으므로, 더 복잡한 신뢰성 메커니즘이 필요합니다.

---

rdt2.0: 비트 에러가 있는 채널

• 기반 통신 채널에서 패킷의 비트가 반전될 수 있습니다.
• 체크섬을 사용하여 비트 에러를 감지합니다.
• 발생한 에러에 대해 어떻게 복구할 것인가가 관건입니다.

에러 복구 메커니즘:

• 확인 응답(ACK): 수신자가 패킷을 정상적으로 받았음을 송신자에게 명시적으로 알립니다.
• 부정 확인 응답(NAK): 수신자가 패킷에 에러가 있었음을 송신자에게 명시적으로 알립니다.
• 송신자는 NAK를 받으면 해당 패킷을 재전송합니다.

rdt2.0의 새로운 메커니즘 (rdt1.0 대비):
- 에러 감지: 체크섬 등을 사용
- 피드백: 수신자에서 송신자로 제어 메시지(ACK, NAK) 전송

요약하면 rdt2.0은 비트 에러가 있는 채널 환경에서 체크섬과 확인응답/부정확인응답을 통해 에러를 감지하고 복구하는 메커니즘을 추가했습니다.

 

 

 

 

 

송신자 입장:

• 상위 계층에서 데이터가 내려오면 rdt_send(data)를 호출합니다.
• rdt 계층에서는 데이터를 패킷으로 만듭니다. 이때 체크섬도 패킷 헤더에 포함됩니다.
• 패킷이 만들어지면 udt_send()를 호출하여 통신 채널로 패킷을 전송합니다.
• 수신자로부터 ACK 또는 NAK를 기다립니다.
• NAK가 오면 해당 패킷을 재전송합니다.
• ACK가 오면 다음 데이터를 처리합니다.

수신자 입장:

• rdt_rcv()를 통해 통신 채널로부터 패킷을 받습니다.
• 패킷의 체크섬을 검사하여 오류 유무를 판단합니다.
• 오류가 있다면 NAK를 송신자에게 보냅니다.
• 오류가 없다면 패킷에서 데이터를 추출하고, deliver_data()를 호출하여 상위 계층으로 데이터를 전달합니다. 그리고 ACK를 송신자에게 보냅니다.

rdt2.0의 치명적 결함:
- ACK/NAK 자체에 에러가 발생하면 송신자는 수신자 상태를 알 수 없습니다.
- 단순히 현재 패킷을 재전송하는 것만으로는 부족합니다.

개선 방안:
1. 패킷에 순서 번호(sequence number)를 추가합니다.
2. 중복 패킷 처리 방식:
   - 송신자: ACK/NAK 손상 시 현재 패킷을 재전송합니다.
   - 수신자: 이미 받은 패킷(중복)은 버리고 상위 계층으로 전달하지 않습니다.
3. 정지-대기(Stop-and-Wait) 방식 사용:
   - 송신자는 한 번에 하나의 패킷만 전송하고 수신자 응답을 기다립니다.
   - 수신자 응답(ACK) 도착 후 다음 패킷을 전송합니다.

요약하면, rdt2.0의 결함을 보완하기 위해 순서번호와 정지-대기 방식을 도입하여 중복 패킷 처리 및 신뢰성 있는 전송을 보장하게 되었습니다.

---

 

이 그림은 rdt2.1 프로토콜의 송신자 측 동작을 보여주고 있습니다. rdt2.1은 이전 rdt2.0 버전에서 발생할 수 있는 ACK/NAK 손상 문제를 해결하기 위해 고안되었습니다.

주요 동작 과정은 다음과 같습니다:

1-1. 송신자는 상위 계층으로부터 데이터를 받아 rdt_send(data)를 호출합니다.
1-2. 데이터를 패킷(순서번호 0)으로 만들고 체크섬을 계산한 후, udt_send로 전송합니다.

2-1. 수신자로부터 ACK 0 또는 NAK 0을 기다립니다.
2-2. ACK가 올 경우 상위 계층에서 다음 데이터(순서번호 1)를 요청할 때까지 대기합니다.
2-3. NAK가 오거나 ACK/NAK가 손상되면 동일 패킷을 재전송합니다.

 

3-1. 상위 계층에서 다음 데이터가 내려오면 순서번호 1 패킷을 생성하여 전송합니다.

 

4-1. 수신자로부터 ACK 1 또는 NAK 1을 기다립니다.
4-2. 정상 ACK 수신 시 다음 데이터를 처리하고, 그렇지 않으면 재전송합니다.

이렇게 순서 번호를 사용하고 NAK 도착 시 재전송하는 mehtod를 통해 손상된 ACK/NAK 처리가 가능해졌습니다. 정지-대기 방식으로 한 번에 하나의 패킷만 전송하므로 순서 번호 0, 1만 사용됩니다.

 

 

이 그림은 rdt2.1 프로토콜의 수신자 측 동작을 보여주고 있습니다. 수신자는 송신자로부터 오는 패킷을 처리하고 적절한 피드백(ACK 또는 NAK)을 보내는 역할을 합니다. 

주요 동작 과정은 다음과 같습니다:

1. 수신자는 rdt_rcv(rcvpkt)를 통해 패킷을 받습니다.

2. 패킷이 손상되지 않았다면(notcorrupt):
    - 순서번호가 0(seq0)일 경우 데이터를 상위 계층으로 전달(deliver_data)하고 ACK를 보냅니다.
    - 순서번호가 1(seq1)일 경우 데이터를 버퍼에 저장하고 ACK를 보냅니다.

3. 패킷이 손상되었다면(corrupt):
    - NAK를 송신자에게 보내 재전송을 요청합니다.

4. 수신자는 송신자로부터 0과 1 순서번호 패킷을 번갈아가며 받게 됩니다.
    - 순서대로 0, 1 패킷을 받으면 데이터를 상위 계층으로 전달하고 ACK를 보냅니다.
    - 중복 패킷이 오면 해당 ACK만 다시 보냅니다.

요약하면 수신자는 패킷 손상 여부와 순서번호를 확인하여 적절히 처리하고, 피드백으로 ACK나 NAK를 송신자에게 보내는 역할을 합니다. 이를 통해 신뢰성 있는 데이터 전송이 가능해집니다.

 

송신자 측면에서 정리하면 다음과 같습니다:

- 패킷에는 0과 1 두 가지 순차 번호만 있으면 됩니다.
- 수신자로부터 받은 ACK/NAK(확인응답/부정확인응답)가 손상되었는지 확인해야 합니다. 
- 상태를 두 배로 유지해야 하는 이유는, 기대하는 다음 패킷의 순차 번호가 0인지 1인지 "기억"해야 하기 때문입니다.

요약하면, 송신자는 간단한 0,1 순차번호 체계를 사용하지만, 수신측 응답 손상 여부를 확인하고 다음에 기대되는 순차번호를 기억하는 상태를 유지해야 합니다.

 

수신자는 다음 사항을 확인해야 합니다:

• 받은 패킷이 중복인지 여부
• 상태가 0번 혹은 1번 패킷 순서를 기대하고 있는지
• 수신자는 자신이 보낸 최신 ACK/NAK(확인응답/부정확인응답)가 송신자에게 제대로 전달되었는지 알 수 없음 (중요)

요약하면, 수신자는 중복 패킷 여부, 예상 패킷 순서, 그리고 자신의 최신 ACK/NAK 전송 성공 여부를 확인해야 하지만, 이 중 마지막 항목에 대해서는 알 수 없습니다.

---

 

rdt 2.2 : A NAK-free protocol 

ack 만 사용하면서 rdt2.1 과 동일하게 동작한다. NAK 대신에, 수신자가 마지막 패킷에 대해 ok라고 ack를 보낸다. 

중복된 ack이 nak과 동일하게 동작한다. -> retransmit current pkt

[송신자 입장]
1. 애플리케이션 계층에서 데이터를 전달받으면(Wait for call 0 from above) 
2. 체크섬과 함께 패킷(sndpkt)을 만들고(make_pkt(0, data, checksum))
3. udt_send(sndpkt)를 통해 전송합니다.
4. 그리고 ACK를 기다리는 상태(Wait for ACK 0)가 됩니다.
5. 수신자로부터 ACK(isACK(rcvpkt, 1))를 받으면 다음 데이터를 보낼 수 있습니다. 
6. 하지만 손상된 패킷(corrupt(rcvpkt))이나 순서가 맞지 않는 패킷(has_seq1(rcvpkt))인 경우 재전송(udt_send(sndpkt))합니다.

[수신자 입장]
1. 송신자로부터 패킷(rcvpkt)을 받습니다.  
2. 패킷 손상(notcorrupt(rcvpkt)) 여부와 순서(has_seq1(rcvpkt))를 확인합니다.
3. 문제가 없다면 extract(rcvpkt, data)를 통해 데이터를 추출하고 deliver_data(data)를 통해 상위 계층으로 전달합니다.
4. 그리고 ACK 패킷(make_pkt(ACK1, chksum))을 만들어 udt_send(sndpkt)를 통해 송신자에게 전송합니다.

핵심은 송신자가 보낸 패킷에 대해 수신자가 ACK를 보내면 다음 데이터를 보낼 수 있고, 문제가 있으면 재전송하는 과정입니다. 순서 번호와 ACK 번호를 통해 패킷 순서와 무결성을 보장합니다.

---

rdt3.0: channels with errors and loss

새로운 가정: 기저 채널에서 데이터 패킷과 ACK가 손실될 수 있습니다.
체크섬, 시퀀스 번호, ACK, 재전송은 도움이 되지만 충분하지 않습니다.

 

해결 방안:
1) 송신자는 "적절한" 시간 동안 ACK를 기다립니다. -> 타이머 동작
2) 그 시간 내에 ACK가 오지 않으면 재전송합니다.
3) 패킷이나 ACK가 지연되었다면, 재전송된 것은 중복일 뿐입니다. 이는 시퀀스 번호로 처리할 수 있습니다.
4) 수신자는 ACK하는 패킷의 시퀀스 번호를 지정해야 합니다.
5) 이를 위해 카운트다운 타이머가 필요합니다.

요약하면, 패킷 손실 가능성을 고려하여 타이머를 통해 ACK 도착을 기다리고, 시간 초과 시 재전송하며, 시퀀스 번호와 ACK 번호를 활용하여 중복 및 순서 문제를 해결합니다.

---

Performance of rdt3.0

rdt3.0 is correct, but performance stinks 

1 Gbps link, 15 ms prop. delay, 8000 bit packet

 

 

utilization– fraction of time sender busy sending 

if RTT=30 msec, 1KB pktevery 30 msec: 33kB/sec throuputover 1 Gbps link

network protocol limits use of physical resources!

---

Pipelined protocols

Pipelined protocolspppipelining:sender allows multiple, “in-flight”, yet-ppgpgyto-be-acknowledged pkts

- range of sequence numbers must be increased

- buffering at sender and/or receiverGobackN

two generic forms of pipelined protocols: go-Back-N, selective repeat repeat

---

Go-back N

송신자는 최대 N개의 확인되지 않은 패킷을 파이프라인에 가질 수 있습니다.

수신자는 누적 ACK만 보내며, 중간에 빈 공간이 있으면 해당 패킷에 대한 ACK를 보내지 않습니다.

 

송신자는 가장 오래된 확인되지 않은 패킷에 대한 타이머를 가지고 있으며, 타이머가 만료되면 모든 확인되지 않은 패킷을 재전송합니다.

k-비트 시퀀스 번호는 패킷 헤더에 있습니다. 최대 N개의 연속된 확인되지 않은 패킷을 허용하는 "윈도우"가 있습니다.

 

이 내용은 송신자와 수신자 간의 패킷 전송 및 확인 절차에 대해 설명하고 있습니다. 

1. 송신자의 패킷 파이프라인: 송신자는 최대 N개의 확인되지 않은 패킷을 동시에 보낼 수 있습니다.
2. 수신자의 누적 ACK: 수신자는 중간에 빈 공간이 있을 경우 해당 패킷에 대해 ACK를 보내지 않고, 누적된 ACK만 보냅니다.
3. 타이머 및 재전송: 송신자는 가장 오래된 확인되지 않은 패킷에 대해 타이머를 설정하고, 타이머가 만료되면 모든 확인되지 않은 패킷을 재전송합니다.
4. 시퀀스 번호: k비트 시퀀스 번호가 패킷 헤더에 포함되어 있습니다.
5. 윈도우 크기: 최대 N개의 연속된 확인되지 않은 패킷을 허용하는 윈도우가 존재합니다.

이 개념들은 네트워크 통신, 특히 신뢰성 있는 데이터 전송을 보장하는 프로토콜(예: TCP)에서 사용됩니다. 이를 통해 데이터 전송의 효율성을 높이고 패킷 손실 시 재전송 메커니즘을 구현할 수 있습니다.

 

 

ACK(n): n번 시퀀스 번호까지의 모든 패킷을 포함하여 ACK를 누적 ACK으로 보냅니다.

 

중복 ACK를 받을 수 있습니다 (수신기를 참조하세요).

비행 중인 가장 오래된 패킷에 대한 타이머가 있습니다.

 

timeout(n): n번 패킷과 윈도우 내의 모든 높은 시퀀스 번호 패킷을 재전송합니다.

 

ACK-only: 올바르게 수신된 패킷에 대해 항상 가장 높은 순서의 시퀀스 번호를 가진 패킷에 대한 ACK를 보냅니다.

• 중복 ACK를 생성할 수 있습니다.
• 예상되는 시퀀스 번호만 기억하면 됩니다.

순서가 맞지 않는 패킷 (out-of-order pkt):

• 폐기합니다 (버퍼링하지 않음): 수신기 버퍼링 없음!
• 가장 높은 순서의 시퀀스 번호를 가진 패킷에 대해 재-ACK를 보냅니다.

 

이 내용은 패킷 전송 및 ACK 처리에 대한 개념을 설명하고 있습니다. 주요 포인트는 다음과 같습니다:

1. ACK(n): 특정 시퀀스 번호까지의 모든 패킷에 대한 누적 ACK를 보냅니다.
2. 중복 ACK: 중복 ACK를 받을 수 있으며, 이는 수신기에서 발생할 수 있습니다.
3. 타이머: 가장 오래된 비행 중인 패킷에 대한 타이머가 있습니다.
4. 타임아웃: 특정 시퀀스 번호와 그보다 높은 모든 패킷을 재전송합니다.
5. ACK 전용 패킷: 올바르게 수신된 패킷에 대해 항상 ACK를 보내며, 중복 ACK를 생성할 수 있습니다. 수신기는 예상되는 시퀀스 번호만 기억하면 됩니다.
6. 순서가 맞지 않는 패킷 처리: 순서가 맞지 않는 패킷은 폐기하고 버퍼링하지 않습니다. 대신 가장 높은 순서의 시퀀스 번호에 대해 재-ACK를 보냅니다.

이 개념들은 주로 네트워크 통신 프로토콜, 특히 TCP(Transmission Control Protocol)와 관련이 있습니다. 네트워크 효율성을 유지하고 데이터의 신뢰성을 보장하기 위해 사용됩니다.

---

Selective repeat

송신자는 파이프라인에 최대 N개의 확인되지 않은 패킷을 가질 수 있습니다.

수신자는 각 패킷에 대해 개별적으로 ACK를 보냅니다.

송신자는 각 확인되지 않은 패킷에 대한 타이머를 유지합니다.

- 타이머가 만료되면 해당 확인되지 않은 패킷만 재전송합니다.

수신자는 올바르게 수신된 모든 패킷을 개별적으로 확인합니다.

송신자는 패킷을 상위 계층으로 순서대로 전달하기 위해 필요한 경우 패킷을 버퍼링합니다.

송신자는 ACK를 받지 못한 패킷만 다시 전송합니다.

송신자는 각 확인되지 않은 패킷에 대한 타이머를 유지합니다.

송신자의 윈도우:

N개의 연속된 시퀀스 번호.

전송된 확인되지 않은 패킷의 시퀀스 번호를 제한합니다.

---

이 내용은 송신자와 수신자 간의 패킷 전송 및 확인 절차에 대해 더 세부적으로 설명하고 있습니다. 주요 포인트는 다음과 같습니다:

1. **송신자의 패킷 파이프라인**: 송신자는 최대 N개의 확인되지 않은 패킷을 동시에 보낼 수 있습니다.
2. **송신자의 개별 ACK**: 수신자는 각 패킷에 대해 개별적으로 ACK를 보냅니다.
3. **송신자의 타이머**: 송신자는 각 확인되지 않은 패킷에 대한 타이머를 설정하고, 타이머가 만료되면 해당 패킷만 재전송합니다.
4. **수신자의 개별 확인**: 수신자는 올바르게 수신된 모든 패킷을 개별적으로 확인합니다.
5. **수신자의 버퍼링**: 수신자는 패킷을 상위 계층으로 순서대로 전달하기 위해 필요한 경우 패킷을 버퍼링합니다. (go-back-n에서는 수신측에서 버퍼가 필요 없었다)
6. **재전송 조건**: 송신자는 ACK를 받지 못한 패킷만 다시 전송합니다.
7. **수신자의 윈도우**: 수신자는 N개의 연속된 시퀀스 번호로 구성된 윈도우를 유지하며, 이는 전송된 확인되지 않은 패킷의 시퀀스 번호를 제한합니다.

이 개념들은 네트워크 통신, 특히 신뢰성 있는 데이터 전송을 보장하는 프로토콜(예: TCP)에서 사용됩니다. 이를 통해 데이터 전송의 효율성을 높이고 패킷 손실 시 재전송 메커니즘을 구현할 수 있습니다.

 

2번이 도착하는 순간, 3,4,5번이 위로 올라가는거임. 

ack2가 도착하는 순간, sender에서도 6, 7, 8로 버퍼가 쭉 올라간다. 

 

송신자

상위 계층에서 데이터:

• 윈도우에서 다음 사용 가능한 시퀀스 번호가 있으면 패킷을 보냅니다.

타임아웃(n):

• 패킷 n을 재전송하고 타이머를 재시작합니다.

ACK(n) in [sendbase, sendbase+N]:

• 패킷 n을 수신된 것으로 표시합니다.
• n이 가장 작은 확인되지 않은 패킷이면 윈도우 베이스를 다음 확인되지 않은 시퀀스 번호로 이동시킵니다.

수신자

패킷 n in [rcvbase, rcvbase+N-1]:

• ACK(n)을 보냅니다.

순서가 맞지 않는 패킷: 버퍼링합니다.

• 순서가 맞는 경우: 전달합니다 (또한 버퍼링된 순서가 맞는 패킷도 전달), 윈도우를 다음 아직 수신되지 않은 패킷으로 이동시킵니다.

패킷 n in [rcvbase-N, rcvbase-1]:

• ACK(n)을 보냅니다.

그 외의 경우:

• 무시합니다.

이 내용은 송신자와 수신자 간의 패킷 전송 및 확인 절차에 대해 설명합니다. 주요 포인트는 다음과 같습니다:

• 송신자의 데이터 전송: 윈도우 내에서 다음 사용 가능한 시퀀스 번호가 있으면 패킷을 전송합니다.
• 타임아웃: 특정 패킷의 타이머가 만료되면 해당 패킷을 재전송하고 타이머를 재시작합니다.
• ACK 수신: ACK가 윈도우 범위 내에 있으면 해당 패킷을 수신된 것으로 표시하고, 가장 작은 확인되지 않은 패킷이면 윈도우 베이스를 업데이트합니다.
• 수신자의 패킷 처리:
  • 윈도우 내에서 수신된 패킷에 대해 ACK를 보냅니다.
  • 순서가 맞지 않는 패킷은 버퍼링하고, 순서가 맞는 패킷은 전달하며 윈도우를 업데이트합니다.
  • 윈도우 이전에 수신된 패킷에 대해서도 ACK를 보냅니다.
  • 그 외의 경우는 패킷을 무시합니다.

이 개념들은 네트워크 통신 프로토콜, 특히 신뢰성 있는 데이터 전송을 보장하는 프로토콜(예: TCP)에서 사용됩니다. 데이터 전송의 효율성을 높이고 패킷 손실 시 재전송 메커니즘을 통해 신뢰성을 보장합니다.

 

제대로 보내고 있는 상황. ? 윈도우 사이즈가 3인 상황이고, seq number 4개를 사용하고 있는 상황이다. 

seq # 4개로 충분하냐고? 타임 아웃으로 0번 다시 보내는 상황인데,,, 받은 애는 2번째로 오는 0번을 받았다고 착각한다. 나는 재전송한 것인데 말이다. 이전의 0번인지, 새로운 0번인지 구분이 안 간다. 

때문에 충분한 2배 정도의 seq # 가 필요하다.

 

상황에 따라서 N 값이 변하기도 하는데 그 때마다 적당히 바꿔야 한다.