Principles of reliable data transfer - 편집 역사

Ahn9807: 봇: 자동으로 텍스트 교체 (-\[\[분류:컴퓨터 네트워크(\|[^\]]+)?\]\] +분류:컴퓨터 네트워킹\1)

2026-01-15T13:01:41Z

봇: 자동으로 텍스트 교체 (-\[\[분류:컴퓨터 네트워크(\|[^\]]+)?\]\] +분류:컴퓨터 네트워킹\1)

← 이전 판		2026년 1월 15일 (목) 13:01 판
122번째 줄:		122번째 줄:

	==각주==		==각주==
	[[분류:컴퓨터 ~~네트워크~~]]		[[분류:컴퓨터 네트워킹]]

2025년 4월 18일 (금) 18:34에 Pinkgo님의 편집

2025-04-18T18:34:49Z

차이 보기

Pinkgo: /* Selective repeat */

2025-04-05T05:21:23Z

Selective repeat

← 이전 판		2025년 4월 5일 (토) 05:21 판
115번째 줄:		115번째 줄:
	SR에서 수신측은 패킷이 순서대로 도착했는지는 상관없이, 정상적으로 수신된 패킷<ref>시퀸스 번호 n</ref> 이라면 ACK(n)를 전송한다. 순서가 어긋난 패킷들은 '''버퍼'''에 저장해두었다가, 순서에서 빠진 패킷들이 도착하면 상위 layer에 일괄적으로 순서대로 전달된다. 이때, '''수신측은 현재의 rcv_base보다 작은 시퀸스 번호<ref>[rcv_base-N,rcv_base-1] 구간 내에 있는 시퀸스 번호 n</ref>를 가진 패킷<ref>즉, 이미 수신된 상태이다.</ref>에 대해서도 무시하지 않고 ACK(n)를 보낸다.''' 이는 다음과 같은 문제 상황을 막기 위해서이다.<br>		SR에서 수신측은 패킷이 순서대로 도착했는지는 상관없이, 정상적으로 수신된 패킷<ref>시퀸스 번호 n</ref> 이라면 ACK(n)를 전송한다. 순서가 어긋난 패킷들은 '''버퍼'''에 저장해두었다가, 순서에서 빠진 패킷들이 도착하면 상위 layer에 일괄적으로 순서대로 전달된다. 이때, '''수신측은 현재의 rcv_base보다 작은 시퀸스 번호<ref>[rcv_base-N,rcv_base-1] 구간 내에 있는 시퀸스 번호 n</ref>를 가진 패킷<ref>즉, 이미 수신된 상태이다.</ref>에 대해서도 무시하지 않고 ACK(n)를 보낸다.''' 이는 다음과 같은 문제 상황을 막기 위해서이다.<br>
	만약 송신측이 패킷 0, 1, 2를 보내고, 수신자이 이를 정상적으로 수신하고 ACK도 전송했지만, ACK(0)만 손실되고 ACK(1), ACK(2)만 송신측에 도착했다고 하자. 이때 송신측은 ACK(0)가 도착하지 않았으므로 <code>send_base = 0</code>인 상태를 유지하며, 패킷 0에 대한 ACK(0)를 받지 못했으므로 타이머 만료시 패킷 0를 재전송한다. 하지만 수신측은 모든 패킷을 정상적으로 수신하였으므로, <code>rcv_base = 3</code>인 상태이다. 이 경우 만약 재전송된 패킷 0를 수신측이 무시한다면, 송신자는 계속 패킷 0를 재전송하므로 송신측의 window는 절대 앞으로 슬라이딩할 수 없다. 이는 수신측과 송신측이 서로 비동기화된 window를 사용하고 있기 때문에 발생하는 문제이다. SR은 이를 해결하기 위해서, 수신측이 이미 수신한 패킷에 대해서도 ACK를 전송하도록 한다.<br>		만약 송신측이 패킷 0, 1, 2를 보내고, 수신자이 이를 정상적으로 수신하고 ACK도 전송했지만, ACK(0)만 손실되고 ACK(1), ACK(2)만 송신측에 도착했다고 하자. 이때 송신측은 ACK(0)가 도착하지 않았으므로 <code>send_base = 0</code>인 상태를 유지하며, 패킷 0에 대한 ACK(0)를 받지 못했으므로 타이머 만료시 패킷 0를 재전송한다. 하지만 수신측은 모든 패킷을 정상적으로 수신하였으므로, <code>rcv_base = 3</code>인 상태이다. 이 경우 만약 재전송된 패킷 0를 수신측이 무시한다면, 송신자는 계속 패킷 0를 재전송하므로 송신측의 window는 절대 앞으로 슬라이딩할 수 없다. 이는 수신측과 송신측이 서로 비동기화된 window를 사용하고 있기 때문에 발생하는 문제이다. SR은 이를 해결하기 위해서, 수신측이 이미 수신한 패킷에 대해서도 ACK를 전송하도록 한다.<br>
	그 이외의 경우에는 패킷 수신을 무시한다.[[파일:Selective repeat- dilemma.png\|대체글=Figure 8. Selective repeat: dilemma\|섬네일\|350x350px\|Figure 8. Selective repeat: dilemma]]송신자와 수신자의 window가 동기화되어있지 않다는 점은 특수한 경우 매우 치명적인 결과를 초래한다.		그 이외의 경우에는 패킷 수신을 무시한다.[[파일:Selective repeat- dilemma.png\|대체글=Figure 8. Selective repeat: dilemma\|섬네일\|350x350px\|Figure 8. Selective repeat: dilemma]]
	예를 들어 시퀸스 번호가 0~3까지 4개만 존재한다고 하고, window의 크기는 3이라고 하자. 이때 다음과 같은 시나리오 두가지가 존재한다:<br>		송신자와 수신자의 window가 동기화되어있지 않다는 점은 특수한 경우 매우 치명적인 결과를 초래한다. 예를 들어 시퀸스 번호가 0~3까지 4개만 존재한다고 하고, window의 크기는 3이라고 하자. 이때 다음과 같은 시나리오 두가지가 존재한다:<br>
	첫 번째 시나리오에서는 송신측이 패킷 0~2를 전송하고, 수신자가 이들을 정상적으로 수신하고 ACK가 모두 송신측에 잘 전달된다. 그리고 송신자는 윈도우를 앞으로 이동시키고, 패킷 3, 0, 1을 전송한다. 이때 패킷 3이 손실되고 나머지가 도착한다. 이 경우 나중에 도착한 패킷 0은 완전히 새로운 패킷이다.<br>		첫 번째 시나리오에서는 송신측이 패킷 0~2를 전송하고, 수신자가 이들을 정상적으로 수신하고 ACK가 모두 송신측에 잘 전달된다. 그리고 송신자는 윈도우를 앞으로 이동시키고, 패킷 3, 0, 1을 전송한다. 이때 패킷 3이 손실되고 나머지가 도착한다. 이 경우 나중에 도착한 패킷 0은 완전히 새로운 패킷이다.<br>
	두 번째 시나리오에서는 송신측이 패킷 0~2를 전송하고, 수신자가 이들을 정상적으로 수신하고 ACK도 보내지만 ACK가 모두 손실된다. 타이머가 만료되어 송신자는 0~2번 패킷을 재전송한다. 이 경우에는 수신측의 window는 첫번째 시나리오와 동일하고, 동일하게 패킷 0을 수신하지만, 이는 단지 첫번째 전송분의 복사본일 뿐이다.<br>		두 번째 시나리오에서는 송신측이 패킷 0~2를 전송하고, 수신자가 이들을 정상적으로 수신하고 ACK도 보내지만 ACK가 모두 손실된다. 타이머가 만료되어 송신자는 0~2번 패킷을 재전송한다. 이 경우에는 수신측의 window는 첫번째 시나리오와 동일하고, 동일하게 패킷 0을 수신하지만, 이는 단지 첫번째 전송분의 복사본일 뿐이다.<br>

Pinkgo: /* Selective repeat */

2025-04-05T05:19:06Z

Selective repeat

← 이전 판		2025년 4월 5일 (토) 05:19 판
112번째 줄:		112번째 줄:
	'''Selective repeat''' 프로토콜은 송신자가 수신측에서 손실되거나 손상된 패킷만 재전송하도록 하여 GBN에서 볼 수 있었던 불필요한 재전송을 피한다. 이러한 개별적이고 필요에 따른 재전송을 위해서는, 수신자가 각 패킷마다 별도로 ACK을 보내야 한다.		'''Selective repeat''' 프로토콜은 송신자가 수신측에서 손실되거나 손상된 패킷만 재전송하도록 하여 GBN에서 볼 수 있었던 불필요한 재전송을 피한다. 이러한 개별적이고 필요에 따른 재전송을 위해서는, 수신자가 각 패킷마다 별도로 ACK을 보내야 한다.

	SR에서 송신측은 GBN과 마찬가지로 최대 N개의 unack된(unacknowledged) 패킷을 보낸다. 또한 수신측으로부터 전송한 패킷에 대한 ACK을 수신하며, 이는 '''cumulative ack'''로 ~~간수되지~~ 않는다. ACK(n)이 수신되었다면, 시퀸스 번호 n이 window 안에 존재할 경우에만 해당 패킷을 수신 완료한 것으로 표시한다. 만약 ACK(send_base)가 수신되었다면, send_base를 다음으로 unack된 패킷의 번호로 갱신하며 window를 슬라이딩한다. 또한 window의 사이즈가 N이면, 타이머의 개수도 N개 필요하다. N개의 타이머는 각각의 패킷에 대한 time-out을 측정하여 time-out이 발생한 패킷을 다시 수신측에 보낸다.		SR에서 송신측은 GBN과 마찬가지로 최대 N개의 unack된(unacknowledged) 패킷을 보낸다. 또한 수신측으로부터 전송한 패킷에 대한 ACK을 수신하며, 이는 '''cumulative ack'''로 간주되지 않는다. ACK(n)이 수신되었다면, 시퀸스 번호 n이 window 안에 존재할 경우에만 해당 패킷을 수신 완료한 것으로 표시한다. 만약 ACK(send_base)가 수신되었다면, send_base를 다음으로 unack된 패킷의 번호로 갱신하며 window를 슬라이딩한다. 또한 window의 사이즈가 N이면, 타이머의 개수도 N개 필요하다. N개의 타이머는 각각의 패킷에 대한 time-out을 측정하여 time-out이 발생한 패킷을 다시 수신측에 보낸다.
	SR에서 수신측은 패킷이 순서대로 도착했는지는 상관없이, 정상적으로 수신된 패킷<ref>시퀸스 번호 n</ref> 이라면 ACK(n)를 전송한다. 순서가 어긋난 패킷들은 '''버퍼'''에 저장해두었다가, 순서에서 빠진 패킷들이 도착하면 상위 layer에 일괄적으로 순서대로 전달된다. 이때, '''수신측은 현재의 rcv_base보다 작은 시퀸스 번호<ref>[rcv_base-N,rcv_base-1] 구간 내에 있는 시퀸스 번호 n</ref>를 가진 패킷<ref>즉, 이미 수신된 상태이다.</ref>에 대해서도 무시하지 않고 ACK(n)를 보낸다.''' 이는 다음과 같은 문제 상황을 막기 위해서이다.<br>		SR에서 수신측은 패킷이 순서대로 도착했는지는 상관없이, 정상적으로 수신된 패킷<ref>시퀸스 번호 n</ref> 이라면 ACK(n)를 전송한다. 순서가 어긋난 패킷들은 '''버퍼'''에 저장해두었다가, 순서에서 빠진 패킷들이 도착하면 상위 layer에 일괄적으로 순서대로 전달된다. 이때, '''수신측은 현재의 rcv_base보다 작은 시퀸스 번호<ref>[rcv_base-N,rcv_base-1] 구간 내에 있는 시퀸스 번호 n</ref>를 가진 패킷<ref>즉, 이미 수신된 상태이다.</ref>에 대해서도 무시하지 않고 ACK(n)를 보낸다.''' 이는 다음과 같은 문제 상황을 막기 위해서이다.<br>
	만약 송신측이 패킷 0, 1, 2를 보내고, 수신자이 이를 정상적으로 수신하고 ACK도 전송했지만, ACK(0)만 손실되고 ACK(1), ACK(2)만 송신측에 도착했다고 하자. 이때 송신측은 ACK(0)가 도착하지 않았으므로 <code>send_base = 0</code>인 상태를 유지하며, 패킷 0에 대한 ACK(0)를 받지 못했으므로 타이머 만료시 패킷 0를 재전송한다. 하지만 수신측은 모든 패킷을 정상적으로 수신하였으므로, <code>rcv_base = 3</code>인 상태이다. 이 경우 만약 재전송된 패킷 0를 수신측이 무시한다면, 송신자는 계속 패킷 0를 재전송하므로 송신측의 window는 절대 앞으로 슬라이딩할 수 없다. 이는 수신측과 송신측이 서로 비동기화된 window를 사용하고 있기 때문에 발생하는 문제이다. SR은 이를 해결하기 위해서, 수신측이 이미 수신한 패킷에 대해서도 ACK를 전송하도록 한다.<br>		만약 송신측이 패킷 0, 1, 2를 보내고, 수신자이 이를 정상적으로 수신하고 ACK도 전송했지만, ACK(0)만 손실되고 ACK(1), ACK(2)만 송신측에 도착했다고 하자. 이때 송신측은 ACK(0)가 도착하지 않았으므로 <code>send_base = 0</code>인 상태를 유지하며, 패킷 0에 대한 ACK(0)를 받지 못했으므로 타이머 만료시 패킷 0를 재전송한다. 하지만 수신측은 모든 패킷을 정상적으로 수신하였으므로, <code>rcv_base = 3</code>인 상태이다. 이 경우 만약 재전송된 패킷 0를 수신측이 무시한다면, 송신자는 계속 패킷 0를 재전송하므로 송신측의 window는 절대 앞으로 슬라이딩할 수 없다. 이는 수신측과 송신측이 서로 비동기화된 window를 사용하고 있기 때문에 발생하는 문제이다. SR은 이를 해결하기 위해서, 수신측이 이미 수신한 패킷에 대해서도 ACK를 전송하도록 한다.<br>

Pinkgo: /* Selective repeat */

2025-04-03T20:53:58Z

Selective repeat

← 이전 판		2025년 4월 3일 (목) 20:53 판
112번째 줄:		112번째 줄:
	'''Selective repeat''' 프로토콜은 송신자가 수신측에서 손실되거나 손상된 패킷만 재전송하도록 하여 GBN에서 볼 수 있었던 불필요한 재전송을 피한다. 이러한 개별적이고 필요에 따른 재전송을 위해서는, 수신자가 각 패킷마다 별도로 ACK을 보내야 한다.		'''Selective repeat''' 프로토콜은 송신자가 수신측에서 손실되거나 손상된 패킷만 재전송하도록 하여 GBN에서 볼 수 있었던 불필요한 재전송을 피한다. 이러한 개별적이고 필요에 따른 재전송을 위해서는, 수신자가 각 패킷마다 별도로 ACK을 보내야 한다.

	SR에서 송신측은 GBN과 마찬가지로 최대 N개의 unack된(unacknowledged) 패킷을 보낸다. 또한 수신측으로부터 전송한 패킷에 대한 ACK을 수신하며, 이는 '''cumulative ack'''로 간수되지 않는다. ACK(n)이 수신되었다면, 패킷 번호 n이 window 안에 존재할 경우에만 해당 패킷을 수신 완료한 것으로 표시한다. 만약 ACK(send_base)가 수신되었다면, send_base를 다음으로 unack된 패킷의 번호로 갱신하며 window를 슬라이딩한다. 또한 window의 사이즈가 N이면, 타이머의 개수도 N개 필요하다. N개의 타이머는 각각의 패킷에 대한 time-out을 측정하여 time-out이 발생한 패킷을 다시 수신측에 보낸다.		SR에서 송신측은 GBN과 마찬가지로 최대 N개의 unack된(unacknowledged) 패킷을 보낸다. 또한 수신측으로부터 전송한 패킷에 대한 ACK을 수신하며, 이는 '''cumulative ack'''로 간수되지 않는다. ACK(n)이 수신되었다면, 시퀸스 번호 n이 window 안에 존재할 경우에만 해당 패킷을 수신 완료한 것으로 표시한다. 만약 ACK(send_base)가 수신되었다면, send_base를 다음으로 unack된 패킷의 번호로 갱신하며 window를 슬라이딩한다. 또한 window의 사이즈가 N이면, 타이머의 개수도 N개 필요하다. N개의 타이머는 각각의 패킷에 대한 time-out을 측정하여 time-out이 발생한 패킷을 다시 수신측에 보낸다.
	SR에서 수신측은 패킷이 순서대로 도착했는지는 상관없이, 정상적으로 수신된 패킷<ref>패킷 번호 n</ref> 이라면 ACK(n)를 전송한다. 순서가 어긋난 패킷들은 '''버퍼'''에 저장해두었다가, 순서에서 빠진 패킷들이 도착하면 상위 layer에 일괄적으로 순서대로 전달된다. 이때, '''수신측은 현재의 rcv_base보다 작은 패킷 번호<ref>[rcv_base-N,rcv_base-1] 구간 내에 있는 패킷 번호 n</ref>를 가진 패킷<ref>즉, 이미 수신된 상태이다.</ref>에 대해서도 무시하지 않고 ACK(n)를 보낸다.''' 이는 다음과 같은 문제 상황을 막기 위해서이다.<br>		SR에서 수신측은 패킷이 순서대로 도착했는지는 상관없이, 정상적으로 수신된 패킷<ref>시퀸스 번호 n</ref> 이라면 ACK(n)를 전송한다. 순서가 어긋난 패킷들은 '''버퍼'''에 저장해두었다가, 순서에서 빠진 패킷들이 도착하면 상위 layer에 일괄적으로 순서대로 전달된다. 이때, '''수신측은 현재의 rcv_base보다 작은 시퀸스 번호<ref>[rcv_base-N,rcv_base-1] 구간 내에 있는 시퀸스 번호 n</ref>를 가진 패킷<ref>즉, 이미 수신된 상태이다.</ref>에 대해서도 무시하지 않고 ACK(n)를 보낸다.''' 이는 다음과 같은 문제 상황을 막기 위해서이다.<br>
	만약 송신측이 패킷 0, 1, 2를 보내고, 수신자이 이를 정상적으로 수신하고 ACK도 전송했지만, ACK(0)만 손실되고 ACK(1), ACK(2)만 송신측에 도착했다고 하자. 이때 송신측은 ACK(0)가 도착하지 않았으므로 <code>send_base = 0</code>인 상태를 유지하며, 패킷 0에 대한 ACK(0)를 받지 못했으므로 타이머 만료시 패킷 0를 재전송한다. 하지만 수신측은 모든 패킷을 정상적으로 수신하였으므로, <code>rcv_base = 3</code>인 상태이다. 이 경우 만약 재전송된 패킷 0를 수신측이 무시한다면, 송신자는 계속 패킷 0를 재전송하므로 송신측의 window는 절대 앞으로 슬라이딩할 수 없다. 이는 수신측과 송신측이 서로 비동기화된 window를 사용하고 있기 때문에 발생하는 문제이다. SR은 이를 해결하기 위해서, 수신측이 이미 수신한 패킷에 대해서도 ACK를 전송하도록 한다.<br>		만약 송신측이 패킷 0, 1, 2를 보내고, 수신자이 이를 정상적으로 수신하고 ACK도 전송했지만, ACK(0)만 손실되고 ACK(1), ACK(2)만 송신측에 도착했다고 하자. 이때 송신측은 ACK(0)가 도착하지 않았으므로 <code>send_base = 0</code>인 상태를 유지하며, 패킷 0에 대한 ACK(0)를 받지 못했으므로 타이머 만료시 패킷 0를 재전송한다. 하지만 수신측은 모든 패킷을 정상적으로 수신하였으므로, <code>rcv_base = 3</code>인 상태이다. 이 경우 만약 재전송된 패킷 0를 수신측이 무시한다면, 송신자는 계속 패킷 0를 재전송하므로 송신측의 window는 절대 앞으로 슬라이딩할 수 없다. 이는 수신측과 송신측이 서로 비동기화된 window를 사용하고 있기 때문에 발생하는 문제이다. SR은 이를 해결하기 위해서, 수신측이 이미 수신한 패킷에 대해서도 ACK를 전송하도록 한다.<br>
	그 이외의 경우에는 패킷 수신을 무시한다.[[파일:Selective repeat- dilemma.png\|대체글=Figure 8. Selective repeat: dilemma\|섬네일\|350x350px\|Figure 8. Selective repeat: dilemma]]송신자와 수신자의 window가 동기화되어있지 않다는 점은 특수한 경우 매우 치명적인 결과를 초래한다.		그 이외의 경우에는 패킷 수신을 무시한다.[[파일:Selective repeat- dilemma.png\|대체글=Figure 8. Selective repeat: dilemma\|섬네일\|350x350px\|Figure 8. Selective repeat: dilemma]]송신자와 수신자의 window가 동기화되어있지 않다는 점은 특수한 경우 매우 치명적인 결과를 초래한다.
	예를 들어 ~~패킷번호가~~ 0~3까지 4개만 존재한다고 하고, window의 크기는 3이라고 하자. 이때 다음과 같은 시나리오 두가지가 존재한다:<br>		예를 들어 시퀸스 번호가 0~3까지 4개만 존재한다고 하고, window의 크기는 3이라고 하자. 이때 다음과 같은 시나리오 두가지가 존재한다:<br>
	첫 번째 시나리오에서는 송신측이 패킷 0~2를 전송하고, 수신자가 이들을 정상적으로 수신하고 ACK가 모두 송신측에 잘 전달된다. 그리고 송신자는 윈도우를 앞으로 이동시키고, 패킷 3, 0, 1을 전송한다. 이때 패킷 3이 손실되고 나머지가 도착한다. 이 경우 나중에 도착한 패킷 0은 완전히 새로운 패킷이다.<br>		첫 번째 시나리오에서는 송신측이 패킷 0~2를 전송하고, 수신자가 이들을 정상적으로 수신하고 ACK가 모두 송신측에 잘 전달된다. 그리고 송신자는 윈도우를 앞으로 이동시키고, 패킷 3, 0, 1을 전송한다. 이때 패킷 3이 손실되고 나머지가 도착한다. 이 경우 나중에 도착한 패킷 0은 완전히 새로운 패킷이다.<br>
	두 번째 시나리오에서는 송신측이 패킷 0~2를 전송하고, 수신자가 이들을 정상적으로 수신하고 ACK도 보내지만 ACK가 모두 손실된다. 타이머가 만료되어 송신자는 0~2번 패킷을 재전송한다. 이 경우에는 수신측의 window는 첫번째 시나리오와 동일하고, 동일하게 패킷 0을 수신하지만, 이는 단지 첫번째 전송분의 복사본일 뿐이다.<br>		두 번째 시나리오에서는 송신측이 패킷 0~2를 전송하고, 수신자가 이들을 정상적으로 수신하고 ACK도 보내지만 ACK가 모두 손실된다. 타이머가 만료되어 송신자는 0~2번 패킷을 재전송한다. 이 경우에는 수신측의 window는 첫번째 시나리오와 동일하고, 동일하게 패킷 0을 수신하지만, 이는 단지 첫번째 전송분의 복사본일 뿐이다.<br>
	수신자 입장에서는 두 상황이 구분되지 않는다. 즉 이 경우에 수신자는 패킷 0이 이미 수신한 옛날 패킷의 복사본인지, 아니면 새로운 윈도우에서 새로 전송된 패킷인지 구분이 안 되는 상황에 빠진다. 이러한 상황을 막기 위해서는 SR 프로토콜에서 window의 크기를 패킷 번호 공간 크기의 절반 이하로 설정하여야 한다.		수신자 입장에서는 두 상황이 구분되지 않는다. 즉 이 경우에 수신자는 패킷 0이 이미 수신한 옛날 패킷의 복사본인지, 아니면 새로운 윈도우에서 새로 전송된 패킷인지 구분이 안 되는 상황에 빠진다. 이러한 상황을 막기 위해서는 SR 프로토콜에서 window의 크기를 시퀸스 번호 공간 크기의 절반 이하로 설정하여야 한다.

	==각주==		==각주==
	[[분류:컴퓨터 네트워크]]		[[분류:컴퓨터 네트워크]]

Pinkgo: /* Go-Back-N */

2025-04-03T20:52:55Z

Go-Back-N

← 이전 판		2025년 4월 3일 (목) 20:52 판
101번째 줄:		101번째 줄:
	[[파일:Sender’s view of sequence numbers in Go-Back-N.png\|대체글=Figure 4. Sender’s view of sequence numbers in Go-Back-N\|가운데\|섬네일\|500x500픽셀\|'''Figure 4. Sender’s view of sequence numbers in Go-Back-N''' ]]		[[파일:Sender’s view of sequence numbers in Go-Back-N.png\|대체글=Figure 4. Sender’s view of sequence numbers in Go-Back-N\|가운데\|섬네일\|500x500픽셀\|'''Figure 4. Sender’s view of sequence numbers in Go-Back-N''' ]]
	[[파일:GBN in action.png\|대체글=Figure 5. GBN in action\|섬네일\|400x400픽셀\|Figure 5. GBN in action\|가운데]]		[[파일:GBN in action.png\|대체글=Figure 5. GBN in action\|섬네일\|400x400픽셀\|Figure 5. GBN in action\|가운데]]
	'''Go-Back-N'''(GBN) 프로토콜에서 송신측은 pipeline 내에 최대 N개의 unack된(unacknowledged) 패킷을 보낸다. 또한 수신측으로부터 전송한 패킷에 대한 ACK을 수신하는데, 만약 패킷 번호가 n인 패킷에 대한 ACK은 '''cumulative ack'''으로 간주된다. 이는 n 이하의 모든 패킷들이 모두 올바르게 수신되었음을 의미한다. 또한 송신자는 가장 오래된, unack된 패킷에 대해 하나의 타이머를 가지고 time-out을 측정한다. 이때 n에 대한 time-out이 발생하면 송신자는 패킷 번호가 n 이상인 모든 패킷들을 다시 수신측에 보낸다. 만약, 패킷이 수신측에 전송되는 도중 손상되었다면, 해당 패킷은 수신측에서 폐기되고 ACK(base)를 다시 전송한다. 이후로도 손상된 패킷 이후의 ACK이 계속 base로 유지되기 때문에 타이머가 만료되고 base부터 시작해서 그 이후 모든 패킷을 다시 전송한다.		'''Go-Back-N'''(GBN) 프로토콜에서 송신측은 pipeline 내에 최대 N개의 unack된(unacknowledged) 패킷을 보낸다. 또한 수신측으로부터 전송한 패킷에 대한 ACK을 수신하는데, 만약 시퀸스 번호가 n인 패킷에 대한 ACK은 '''cumulative ack'''으로 간주된다. 이는 n 이하의 모든 패킷들이 모두 올바르게 수신되었음을 의미한다. 또한 송신자는 가장 오래된, unack된 패킷에 대해 하나의 타이머를 가지고 time-out을 측정한다. 이때 n에 대한 time-out이 발생하면 송신자는 시퀸스 번호가 n 이상인 모든 패킷들을 다시 수신측에 보낸다. 만약, 패킷이 수신측에 전송되는 도중 손상되었다면, 해당 패킷은 수신측에서 폐기되고 ACK(base)를 다시 전송한다. 이후로도 손상된 패킷 이후의 ACK이 계속 base로 유지되기 때문에 타이머가 만료되고 base부터 시작해서 그 이후 모든 패킷을 다시 전송한다.

	수신측의 동작은 더욱 간단하다. 만약 패킷 번호 n의 패킷이 정상적으로 수신되고 순서대로 도착했다면 ACK(n)을 전송하고, 해당 패킷의 데이터를 상위 계층에 전달한다. 그 외의 모든 경우에는 패킷을 폐기하고 ACK(base)를 재전송한다. 이때 상위 layer에는 패킷이 하나씩 순차적으로 전달되기 때문에, 만약 패킷 n이 전달되었다면, n보다 작은 모든 패킷들도 이미 전달된 것이 보장된다. 즉, 순서가 어긋난 패킷은 폐기되어 수신측의 상위 layer에는 패킷이 순서대로 도착한다. 이때, 수신측의 구현은 간단한데, 오직 다음에 도착할 것이 예상되는 패킷 번호, 즉 base+1만 저장하면 된다.		수신측의 동작은 더욱 간단하다. 만약 시퀸스 번호 n의 패킷이 정상적으로 수신되고 순서대로 도착했다면 ACK(n)을 전송하고, 해당 패킷의 데이터를 상위 계층에 전달한다. 그 외의 모든 경우에는 패킷을 폐기하고 ACK(base)를 재전송한다. 이때 상위 layer에는 패킷이 하나씩 순차적으로 전달되기 때문에, 만약 패킷 n이 전달되었다면, n보다 작은 모든 패킷들도 이미 전달된 것이 보장된다. 즉, 순서가 어긋난 패킷은 폐기되어 수신측의 상위 layer에는 패킷이 순서대로 도착한다. 이때, 수신측의 구현은 간단한데, 오직 다음에 도착할 것이 예상되는 시퀸스 번호, 즉 base+1만 저장하면 된다.

	하지만 GBN은 문제를 가지고 있다. 만약 window의 크기와 대역폭-지연곱<ref>Bandwidth × RTT를 의미하며, 네트워크 파이프라인에 동시에 존재할 수 있는 데이터 양을 의미한다.</ref>(Bandwidth-Delay Product)이 모두 큰 경우, 많은 패킷들이 파이프라인 안에 존재한다. 이때 만약 단 하나의 패킷 오류만 존재하더라도, GBN은 많은 수의 패킷들을 재전송할 수 있다. 또한 패킷이 손실되거나 손상될 확률이 커질수록 이러한 비효율성은 급속도로 커진다.		하지만 GBN은 문제를 가지고 있다. 만약 window의 크기와 대역폭-지연곱<ref>Bandwidth × RTT를 의미하며, 네트워크 파이프라인에 동시에 존재할 수 있는 데이터 양을 의미한다.</ref>(Bandwidth-Delay Product)이 모두 큰 경우, 많은 패킷들이 파이프라인 안에 존재한다. 이때 만약 단 하나의 패킷 오류만 존재하더라도, GBN은 많은 수의 패킷들을 재전송할 수 있다. 또한 패킷이 손실되거나 손상될 확률이 커질수록 이러한 비효율성은 급속도로 커진다.

Pinkgo: /* Packet 번호 구간 */

2025-04-03T20:51:48Z

Packet 번호 구간

← 이전 판		2025년 4월 3일 (목) 20:51 판
88번째 줄:		88번째 줄:
	=== Packet 번호 구간 ===		=== Packet 번호 구간 ===
	다음에 전송할 패킷의 시퀸스 번호를 nextseqnum, 가장 오래된 확인되지 않은 패킷의 시퀸스 번호를 base라고 하자. 그러면 시퀸스 번호의 범위는 아래와 같이 4개의 구간으로 나눌 수 있다:		다음에 전송할 패킷의 시퀸스 번호를 nextseqnum, 가장 오래된 확인되지 않은 패킷의 시퀸스 번호를 base라고 하자. 그러면 시퀸스 번호의 범위는 아래와 같이 4개의 구간으로 나눌 수 있다:
	* [0, base-1]: 이미 전송되었고 확인 응답을 받은 ~~패킷들~~		* [0, base-1]: 이미 전송되었고 확인 응답을 받은 시퀸스 번호 범위
	* [base, nextseqnum-1]: 전송되었지만 아직 확인되지 않은 ~~패킷들~~		* [base, nextseqnum-1]: 전송되었지만 아직 확인되지 않은 시퀸스 번호 범위
	* [nextseqnum, base+N-1]: 즉시 전송 가능한 시퀸스 번호 범위 (상위 계층에서 데이터가 도착하면)		* [nextseqnum, base+N-1]: 즉시 전송 가능한 시퀸스 번호 범위 (상위 계층에서 데이터가 도착하면)
	* [base+N 이상]: base에 해당하는 패킷의 ACK이 도착하기 전까지는 전송할 수 없는 시퀸스 번호		* [base+N 이상]: base에 해당하는 패킷의 ACK이 도착하기 전까지는 전송할 수 없는 시퀸스 번호 범위

	=== Window ===		=== Window ===

Pinkgo: /* Pipelined protocols */

2025-04-03T20:50:56Z

Pipelined protocols

← 이전 판		2025년 4월 3일 (목) 20:50 판
87번째 줄:		87번째 줄:

	=== Packet 번호 구간 ===		=== Packet 번호 구간 ===
	다음에 전송할 패킷의 패킷 번호를 nextseqnum, 가장 오래된 확인되지 않은 패킷의 패킷 번호를 base라고 하자. 그러면 패킷 번호의 범위는 아래와 같이 4개의 구간으로 나눌 수 있다:		다음에 전송할 패킷의 시퀸스 번호를 nextseqnum, 가장 오래된 확인되지 않은 패킷의 시퀸스 번호를 base라고 하자. 그러면 시퀸스 번호의 범위는 아래와 같이 4개의 구간으로 나눌 수 있다:
	* [0, base-1]: 이미 전송되었고 확인 응답을 받은 패킷들		* [0, base-1]: 이미 전송되었고 확인 응답을 받은 패킷들
	* [base, nextseqnum-1]: 전송되었지만 아직 확인되지 않은 패킷들		* [base, nextseqnum-1]: 전송되었지만 아직 확인되지 않은 패킷들
	* [nextseqnum, base+N-1]: 즉시 전송 가능한 패킷 번호 범위 (상위 계층에서 데이터가 도착하면)		* [nextseqnum, base+N-1]: 즉시 전송 가능한 시퀸스 번호 범위 (상위 계층에서 데이터가 도착하면)
	* [base+N 이상]: base에 해당하는 패킷의 ACK이 도착하기 전까지는 전송할 수 없는 패킷 번호		* [base+N 이상]: base에 해당하는 패킷의 ACK이 도착하기 전까지는 전송할 수 없는 시퀸스 번호

	=== Window ===		=== Window ===
	아직 ACK을 받지 않은 전송된 패킷들에 대해 허용된 패킷 번호 범위는 크기 N의 '''window'''라고 불린다. 위 문단의 표현법을 빌리면, [base, base+N-1]에 해당한다. 즉, window 내에 속하는 패킷 번호에 해당하는 패킷만 전송될 수 있으며, nextseqnum이 base+N에 도달하면, window가 가득찬 상태이며, 패킷을 더 이상 전송할 수 없다. 이때, 전송한 패킷의 ACK 신호를 수신함에 따라 이 window는 패킷 번호 공간 위를 앞으로 슬라이딩하며 움직인다. 이 때문에 N은 window 크기라고 불린다.		아직 ACK을 받지 않은 전송된 패킷들에 대해 허용된 시퀸스 번호 범위는 크기 N의 '''window'''라고 불린다. 위 문단의 표현법을 빌리면, [base, base+N-1]에 해당한다. 즉, window 내에 속하는 시퀸스 번호에 해당하는 패킷만 전송될 수 있으며, nextseqnum이 base+N에 도달하면, window가 가득찬 상태이며, 패킷을 더 이상 전송할 수 없다. 이때, 전송한 패킷의 ACK 신호를 수신함에 따라 이 window는 시퀸스 번호 공간 위를 앞으로 슬라이딩하며 움직인다. 이 때문에 N은 window 크기라고 불린다.

	그렇다면 왜 window의 크기를 N으로 제한하는 건지에 대한 의문이 들 수 있다. 이에 대한 한 가지 이유는 flow control 때문이며, 또다른 이유는 TCP의 congestion control 때문이다.		그렇다면 왜 window의 크기를 N으로 제한하는 건지에 대한 의문이 들 수 있다. 이에 대한 한 가지 이유는 flow control 때문이며, 또다른 이유는 TCP의 congestion control 때문이다.
120번째 줄:		120번째 줄:
	두 번째 시나리오에서는 송신측이 패킷 0~2를 전송하고, 수신자가 이들을 정상적으로 수신하고 ACK도 보내지만 ACK가 모두 손실된다. 타이머가 만료되어 송신자는 0~2번 패킷을 재전송한다. 이 경우에는 수신측의 window는 첫번째 시나리오와 동일하고, 동일하게 패킷 0을 수신하지만, 이는 단지 첫번째 전송분의 복사본일 뿐이다.<br>		두 번째 시나리오에서는 송신측이 패킷 0~2를 전송하고, 수신자가 이들을 정상적으로 수신하고 ACK도 보내지만 ACK가 모두 손실된다. 타이머가 만료되어 송신자는 0~2번 패킷을 재전송한다. 이 경우에는 수신측의 window는 첫번째 시나리오와 동일하고, 동일하게 패킷 0을 수신하지만, 이는 단지 첫번째 전송분의 복사본일 뿐이다.<br>
	수신자 입장에서는 두 상황이 구분되지 않는다. 즉 이 경우에 수신자는 패킷 0이 이미 수신한 옛날 패킷의 복사본인지, 아니면 새로운 윈도우에서 새로 전송된 패킷인지 구분이 안 되는 상황에 빠진다. 이러한 상황을 막기 위해서는 SR 프로토콜에서 window의 크기를 패킷 번호 공간 크기의 절반 이하로 설정하여야 한다.		수신자 입장에서는 두 상황이 구분되지 않는다. 즉 이 경우에 수신자는 패킷 0이 이미 수신한 옛날 패킷의 복사본인지, 아니면 새로운 윈도우에서 새로 전송된 패킷인지 구분이 안 되는 상황에 빠진다. 이러한 상황을 막기 위해서는 SR 프로토콜에서 window의 크기를 패킷 번호 공간 크기의 절반 이하로 설정하여야 한다.


	==각주==		==각주==
	[[분류:컴퓨터 네트워크]]		[[분류:컴퓨터 네트워크]]

Pinkgo: /* rdt3.0: channels with errors and loss */

2025-04-03T20:49:40Z

rdt3.0: channels with errors and loss

← 이전 판		2025년 4월 3일 (목) 20:49 판
62번째 줄:		62번째 줄:
	[[파일:Rdt3.0 sender FSM.png\|테두리\|프레임없음\|500x500픽셀]]		[[파일:Rdt3.0 sender FSM.png\|테두리\|프레임없음\|500x500픽셀]]

	rdt3.0에서는 패킷이 손상되는 경우 외에도 패킷 손실(loss)이 일어나는 상황을 해결한다. rdt2.2 프로토콜은 패킷 손실에 매우 취약하다. 그 이유는 rdt2.2 프로토콜이 stop-and-wait 프로토콜이기 때문에 패킷 손실이 생길 경우 송신측과 수신측 모두 패킷을 들어오기를 영원히 기다리기 때문이다. 패킷 손실을 처리하는 가장 간단한 해결책은 countdown timer을 활용하는 것이다. 송신자는 '''패킷을 보낸 후 ACK가 돌아오기를 "합리적인" 시간 동안 기다린다.''' 송신자는 1)데이터 패킷이 손실되었는지, 2)ACK이 손실되었는지, 3)혹은 데이터 패킷이나 ACK이 단지 지연되었는지 모르지만, 모든 경우에 재전송한다. 만약 해당 시간 동안 ACK 응답을 받지 못한다면 다시 해당 패킷을 수신측에 보낸다. 만약 단순히 수신측이 패킷을 정상적으로 수신하였으나 ACK이 손실된 경우에 수신측은 중복된 패킷을 받고, 패킷 번호로 이를 판별하여 폐기한다.		rdt3.0에서는 패킷이 손상되는 경우 외에도 패킷 손실(loss)이 일어나는 상황을 해결한다. rdt2.2 프로토콜은 패킷 손실에 매우 취약하다. 그 이유는 rdt2.2 프로토콜이 stop-and-wait 프로토콜이기 때문에 패킷 손실이 생길 경우 송신측과 수신측 모두 패킷을 들어오기를 영원히 기다리기 때문이다. 패킷 손실을 처리하는 가장 간단한 해결책은 countdown timer을 활용하는 것이다. 송신자는 '''패킷을 보낸 후 ACK가 돌아오기를 "합리적인" 시간 동안 기다린다.''' 송신자는 1)데이터 패킷이 손실되었는지, 2)ACK이 손실되었는지, 3)혹은 데이터 패킷이나 ACK이 단지 지연되었는지 모르지만, 모든 경우에 재전송한다. 만약 해당 시간 동안 ACK 응답을 받지 못한다면 다시 해당 패킷을 수신측에 보낸다. 만약 단순히 수신측이 패킷을 정상적으로 수신하였으나 ACK이 손실된 경우에 수신측은 중복된 패킷을 받고, 시퀸스 번호로 이를 판별하여 폐기한다.

	[[파일:Rdt3.0 no loss case.png\|테두리\|프레임없음\|280x280픽셀]] [[파일:Rdt3.0 lost packet.png\|테두리\|프레임없음\|280x280픽셀]] [[파일:Rdt3.0 ACK loss .png\|테두리\|프레임없음\|280x280픽셀]] [[파일:Rdt3.0 premature timeout.png\|테두리\|프레임없음\|280x280픽셀]]		[[파일:Rdt3.0 no loss case.png\|테두리\|프레임없음\|280x280픽셀]] [[파일:Rdt3.0 lost packet.png\|테두리\|프레임없음\|280x280픽셀]] [[파일:Rdt3.0 ACK loss .png\|테두리\|프레임없음\|280x280픽셀]] [[파일:Rdt3.0 premature timeout.png\|테두리\|프레임없음\|280x280픽셀]]

Pinkgo: /* rdt2.2: a NAK-free protocol */

2025-04-03T20:48:28Z

rdt2.2: a NAK-free protocol

← 이전 판		2025년 4월 3일 (목) 20:48 판
57번째 줄:		57번째 줄:
	[[파일:Rdt2.2 sender FSM.png\|테두리\|프레임없음\|500x500픽셀]] [[파일:Rdt2.2 receiver FSM.png\|테두리\|프레임없음\|500x500픽셀]]		[[파일:Rdt2.2 sender FSM.png\|테두리\|프레임없음\|500x500픽셀]] [[파일:Rdt2.2 receiver FSM.png\|테두리\|프레임없음\|500x500픽셀]]

	rdt2.2는 rdt2.1과 기능 동일하지만, 효율성의 증대를 위해서 '''NAK을 사용하지 않고 ACK'''만 사용한다. NAK 대신, 수신자는 마지막으로 정상 수신한 패킷에 대한 ACK를 전송하며, 이를 위해 '''ACK에 ~~패킷 순서를~~ 명시적으로 포함'''한다.<ref>이는 수신기 FSM에서 make_pkt() 함수에 ACK, 0 또는 ACK, 1 인자를 포함하는 것으로 구현된다./</ref> 이때, 송신자가 수신측으로부터 같은 패킷 번호에 대한 ACK를 두 번 받는 경우, NAK과 동일하게 처리하여 현재 패킷을 재전송한다. 예를 들어, 패킷 번호가 0과 1만 있다고 가정하자. 송신측이 수신측에게 정상적으로 0번 패킷을 전송하고 1번 패킷을 전송한 후 수신측이 (~~ACK,~~ 1)을 답신한다면, 이는 1번 패킷이 정상적으로 전달되었음을 의미한다. 반대로 수신측이 (~~ACK,~~ 0)을 전송하였을 때에는 송신측은 1번 패킷을 재전송한다.		rdt2.2는 rdt2.1과 기능 동일하지만, 효율성의 증대를 위해서 '''NAK을 사용하지 않고 ACK'''만 사용한다. NAK 대신, 수신자는 마지막으로 정상 수신한 패킷에 대한 ACK를 전송하며, 이를 위해 '''ACK에 시퀸스 번호를 명시적으로 포함'''한다.<ref>이는 수신기 FSM에서 make_pkt() 함수에 ACK, 0 또는 ACK, 1 인자를 포함하는 것으로 구현된다./</ref> 이때, 송신자가 수신측으로부터 같은 시퀸스 번호에 대한 ACK를 두 번 받는 경우, NAK과 동일하게 처리하여 현재 패킷을 재전송한다. 예를 들어, 시퀸스 번호가 0과 1만 있다고 가정하자. 송신측이 수신측에게 정상적으로 0번 패킷을 전송하고 1번 패킷을 전송한 후 수신측이 ACK(1)을 답신한다면, 이는 1번 패킷이 정상적으로 전달되었음을 의미한다. 반대로 수신측이 ACK(0)을 전송하였을 때에는 송신측은 1번 패킷을 재전송한다.

	==rdt3.0: channels with errors and loss==		==rdt3.0: channels with errors and loss==