이석복 네트워크 (5)go-Back-N, selective repeat, window, cumulative ack, seq&window&buffer

===

http://ocw.hanyang.ac.kr/?course=8461 

컴퓨터네트워크_5회차

 

===

실제론 rdt가 아닌 패킷을 쏟아붓는다 파이프라인 방식의 전송이 필요하다(=피드백을 받기전에 많은 양의 데이터를 쏟아부어야 효율적)

쏟아붓고 한꺼번에 피드백 받고. 그래야 네트워크를 잘 활용하는 것

 

이러면 피드백, 시퀀스 넘버 관리가 복잡해진다->그래서 TCP가 복잡하다

 

===

3배만큼 늘어났어 -> 한꺼번에 많이 보내면 보낼수록 좋다. TCP도 당연히 이쪽

 

===

이런 파이프라인 방식의 신뢰성 있는 프로토콜을 동작하게 만드는 기본 어프로치

(1)go-Back-N

(2)selective repeat

(2016 : 파이프라인에서 reliability를 구현하는 굉장히 generic한 프로토콜들, 실제 존재하는 프로토콜이라기보단 교육적인 목적)

 

실제로 TCP가 둘 섞어쓴다

 

===

go-Back-N이든 selective repeat이든 많은 패킷을 한꺼번에 쏟아부을것이다

그러려면 한꺼번에 얼만큼 많이 보낼거냐는 기술이 있어야, 그게 window

window사이즈 만큼은 피드백 받지 않고 한꺼번에 보낼 수 있다

 

===

win=4면

시퀀스 넘버 0 1 2 3 4 5 6 7 8 9 10 11 12 13...

0~3은 윈도우 안에 들어있으니 한꺼번에 보낼 수 있는 것

 

 

===

Go-Back-N

"cumulative ACK", 쌓는 의미

ACK11 = 나 11번까지 잘 받았다, 12번 줘라

 

각각 패킷에 대해 timeout이 있다, ACK받기전에 예를 들어 패킷 0의 타이머가 터지면 윈도우 안에 있는 모든 애(0~3)를 다 재전송한다

▽하나 안갔으니 나머지도 안갔을거다 라고 생각해서 다 재전송? -> 밑에 보면 리시버가 좀 떨어져서 인듯

 

===

센더의 동작을 FSM으로, 상태, 이벤트가 발생하면 ~~한 행동을 취해라

timeout이벤트가 발생하면 안에 있는거 다 전송해라

복습할 때 슬라이드 읽어보세요~

 

===

리시버의 동작, gobackN의 특징이 리시버가 정말 멍청하다는 것, 버퍼도 없고 아무것도 없다

자기가 받아야될 시퀀스 넘버만 주구장창 기다려

1번 기다리고 있는데 어쩌다 1번이 멀리 돌아서 와서 2번이 먼저 오면 버리고 ACK0보낸다

버퍼가없어서 저장할 공간이 없어

2번 받고 ACK1, 이때 3, 4, 5, 6 와도 ACK1.

 

gobackN에서는 험한일은 다 센더가 한다. 리시버가 무식해서

 

===

설명은 들었는데 뭐가뭔지 모르겠지 예를 봅시다

딱보니 win=4, 0123 한꺼번에 보내고, 타이머 0123 켜주고

잘가다가

2번기다리는데 없어서 3번 온거 버리고 ACK1, 1번까진 잘 받았다

 

이 상황을 보면

0번을 보내고 ACK0을 받으면 OK, 0의 타임아웃 제거하고, 0은 이제 윈도우 안에 있을 필요없어서 윈도우가 전진한다(윈도우가 전진도 하네)

전진하면 4번 보내면서 타임아웃 설치한다

 

ACK1 받아서 윈도우전진

이렇게 돼서 저 그림(위에위에 GBN in action그림)에서 중간쯤에 4번 5번을 send하는 것

하지만 4번 5번 다 버리고 ACK1보낸다

 

그러다 시간이 지나서 2의 타임아웃이 폭파 -> 2, 3, 4, 5 재전송

 

ACK2번 오면 윈도우 전진(6번 send), 3번오면 .. 반복

 

===

go back N 뜻

좀 더 큰그림을 보면

아무 문제도 없다면 윈도우가 쭉 진행해서 추가되는 하나씩의 패킷 4, 5, 6 이렇게 순서대로 보내는 것

 

근데 만약 6번이 없어졌다 치면 ACK3, ACK4, ACK5받고 윈도우가 6, 7, 8, 9가 돼 7, 8, 9 받아도 ACK5에서 진행 안하다가 6의 timeout때 6, 7, 8, 9를 보낸다

보내는 순서로 보면 0 1 2 3 4 5 6 7 8 9 6 7 8 9가 되는 것 -> 돌아오되 n개 만큼 돌아온다 = go back N

▽ACK5를 sender가 받아서 6을 보내는 것보다 timeout이 빠른가?

 

윈도우는 한꺼번에 보낼 수 있는 양을 의미하기도 하지만 결국 윈도우 안에 들어있는 패킷들은 버퍼에 저장하고 있어야 한다

윈도우 안에 들어있는 애들은 아직 리시버가 받았는지 확인 못한 애들이야. 윈도우를 벗어난 애들은 더이상 저장하고 있을 필요가 없어  ▽보내놓고도 잘 갔는지 아직 모르니까 버퍼에 저장하고 있어야 한다는 말이겠지

 

===

유실된건 6번 하난데 789까지 다 재전송하고 있다. 실제 윈도우 사이즈는 한꺼번에 몇백개씩 보낼건데 하나 유실됐다고 다 보내? 동작은 하지만 뭔가 별로인 점이 있다. <- 리시버가 아무런 기능을 안해주니까

 

리시버 니가 일좀 해줘라(버퍼에 저장좀 해) 하는 버전이 Selective Repeat

 

===

Selective Repeat

이제 ACK의 의미가 cumulative면 안된다, ACK11은 단지 11번만 잘 받았다는 의미

timeout터지기 전에 ACK를 받으면 해제, 걔만 해제, 이전 전부 해결됐다는 의미가 아니라

 

===

설명 안한 그림

 

===

순서에 맞지 않는 패킷이라도 에러가 없으면 버퍼에 저장하고 해당 ACK를 보내준다

win=4

0번 잘 받으면 애플리케이션 레이어에 올려주고 ACK0

1번 " " "

-> 이때 센더는 윈도우 전진해서 5번까지 보낼 수 있고

2번 기다리는데

3번와도 버리지 않고 버퍼에 저장하고 ACK3 (▽2번 들어갈 맨 앞 비워두고 3번 들어가는 거 보니까 위치 지정할 수 있나보네 그리고 순서대로 쭉 빨아들이겠지?)

 

그러다 2번 타이머가 터지면 2번만 재전송

리시버는 맨 앞 비워뒀던 버퍼에다 2번 집어넣으면 2, 3, 4, 5 순서 맞게 애플리케이션 레이어에 올려준다

ACK2

윈도우 전진, 아까 ACK3받았으니 계속 전진

 

유실된 패킷만 재전송한다

 

보내는 순서는 0 1 2 3 4 5 2 6 7 8 이렇게 된다

 

리시버가 일을 하는 대신 네트워크에 부하를 덜어준다

 

===

여러가지 상황 발생하니 머릿속으로 시나리오 짜면서 그려보세요

 

===

마지막으로 생각해봐야 할 문제

시퀀스 넘버에 대해 생각해봐야 한다. 최소화 해야해

 

win=3일 때 몇개 써야 될까? 한 4개 정도 쓰면 되는거 아냐?해서 해본게 저 그림

 

===

0 1 2 한꺼번에 보내

ACK0,1,2 보내고 3번 기다려 -> 근데 이때 ACK가 전부 유실됐어

0이 재전송돼서 오면?

기다리는 3의 다음것이 0이니까 저장을 해, 근데 이때 0은 듀플리케이트잖아

3 다음인 새로운 패킷이라고 생각하고 저장했는데 실제론 재전송한애야

 

win=n 일때 시퀀스 넘버 n+1사용하면 안된다

시퀀스 넘버를 늘리면 해결돼

근데 무작정 늘릴 수 없고 새로운 패킷과 듀플리케이트를 구분할 수 있는 범위를 가진 최소를 알고 싶어

2배정도면 되겠네 느낌이 와

 

===

시퀀스 넘버는 윈도우 사이즈와 밀접한 연관이 있다

시퀀스 넘버가 듀플리케이트패킷과 새로운 패킷을 구별하려는 것이기 때문

 

===

selective repeat은 모든 윈도우 안의 패킷에 타이머를 달아야 해(TCP connection 열여서 한꺼번에 몇천개씩 보낼텐데 타이머가 몇천개다)

->

컴퓨터가 동시에 실행되는 프로세스의 개수가 몇천갠데 다 TCP connection을 갖고 있다면 그게 다 윈도우고 걔네들이 다 타이머를 갖고 있어

 

===

(다음시간)TCP는 gobackN or selective repeat 두 가지 중 장점들만 버무려서 사용한다

- 윈도우를 대표하는 타이머 하나

- ACK도 cumulative