컴퓨터 네트워크 [Computer Network ] #.03 DLC

‍정진철·2023년 3월 23일
0

<역할>

1. 메시지 생성 (프레이밍)

2. 에러 검출 및 복구 ( DLC ) 를 수행. - 에러 컨트롤
데이터링크 계층이 동작하는 방식은 크게 2가지
1) dedicated 2) broadcast
에러 컨트롤 -> 보낸 정보가 없어지거나 왜곡 된 것.

3) 플로우 컨트롤 -> 2계층,4계층에 동시에 존재, 보내는 자가 받는 자의 상황을 보고 전송 시, 받는 자가 송신 속도를 조절 하는 것.


Framing

보내고자 하는 쪽에서 보내는 정보를 특정한 형태에 담아서 보내는 것.
소스 어드레스, 목적지 어드레스가 담김.
L3 (네트워크 계층) 이 보낸 데이터에 대해 에러 검출 및 복구를 수행하기 위해 추가적으로 L2(DLC)가 추가적으로 데이터 추가.

프레임 -> A에서 B로 데이터 링크가 정보를 보낼때의 형태.
character - orientd : 데이터 링크 컨트롤 단에서 전송단이 수신단에게 데이터 전송 시 처리를 "character" 단위로 함.

Physical Layer 는 자기들끼리는 0과1의 정보를 주고 받더라도 데이터 링크 계층에서 정보를 주기 위해서 사전에 "Flag"를 던지면 송수신 하던 데이터 상호작용을 멈춘다.


Byte stuffing and unstuffing

![](https://velog.velcdn.com/images/bik1111/post/dcc04ff4-6023-46ea-86 a-527ca593d519/image.png)

Textbook: Behrouz A. Forouzan, “Data Communications and Networking, 5th Edition”, McGraw-Hill Companies, Inc.

데이터 링크 계층에서 사용하는 flag와 사용자가 보내려는 데이터의 내용역시 flag라 겹치는 상황.
따라서, 해당 데이터를 수신하는 데이터 컨트롤 Layer에게 내가 보내는 정보는 flag가 아니라는 걸 알려줘야함. => Stuffing

따라서, ESC (Escape Sequence) 을 flag(보내려는 데이터 내용) 앞에 붙여줌.

흐름을 정리해 보자면, Flag 확인 ( 데이터 컨트롤 레이어의 메시지라는 것을 확인 ) -> Header (소스 어드레스, 목적지 어드레스, 기타 흐름 제어 및 오류 검출을 위한 정보 확인) -> ESC ( 뒤쪽에 있는 flag와 똑같은 데이터니 뒤쪽에 있는 정보는 flag가 아니라 사용자의 데이터니 잘 인식해서 데이터로 처리하렴) -> 수신 하는 쪽은 ESC 지우고 flag 만 3계층에게 전송

하지만, 이 ESC 의 정보마저도 사용자가 보내려는 데이터와 중복된다면 ?
-> ESC 앞에 ESC를 한 번 더 추가.

ESC + ESC => 뒤에 있는건 특수코드가 아니라 사용자의 데이터라는 의미.

역시나, 수신단은 앞쪽의 ESC는 제거해서 3계층에 올림.


Textbook: Behrouz A. Forouzan, “Data Communications and Networking, 5th Edition”, McGraw-Hill Companies, Inc.

bit 단위에서의 데이터 전송 역시 byte단위로 데이터를 전송했던 것과 원리는 동일.
다만, flag는 01111110 을 뜻함.

보내는 데이터에 flag가 안나타나는게 목표.
0으로 시작한 후 1이 5개 나타나면 0 을 집어넣음.

비트 동작으로 시킨 이유는 과거에는 느린속도도 비쌌음
따라서 비싼 통신 링크에서 0과 1 의 비트 조합까지 건드리면서 최대한 효율적으로 사용하고자함.


Concpet

큰 사각형 -> 장치,노드

Flow Control : 받는 이가 보내는 이에게 피드백을 줌
데이터 전송 속도 즉 데이터 흐름에 관한 관리를 위함.


Simple Protocol

Textbook: Behrouz A. Forouzan, “Data Communications and Networking, 5th Edition”, McGraw-Hill Companies, Inc.

현실적으로 불가능한 통신 규약.
흐름 제어 및 에러 컨트롤 X
송신단이 보내고 싶을 때 보내고 수신단은 받음.
어떠한 에러도 없고 속도 차이도 없음.


Textbook: Behrouz A. Forouzan, “Data Communications and Networking, 5th Edition”, McGraw-Hill Companies, Inc.

Packet caome from network layer => 이벤트라 칭함.
Make a frame and send it => 액션.
그리고 다음 상태는 ready.

ready 상태에서 네트워크 레이어로부터 패킷을 받는 이벤트를 겪고 그 패킷을 다시 프레임으로 만들어 피지컬 레이어를 통해 Receiving Data Link에 전송하고 다시 network layer 로부터 무언가 오길 기다림.

Start : 통신 프로그램이 최초로 시작할 때 가장 기저가 되는 상태 (ready)

sending node는 소프트웨어가 살아난 시점(start)에 ready 상태로 들어감.
그리고 ready 상태에서 네트워크 레이어로부터 패킷이 오는 이벤트가 발생하면 프레임을 만들고 네트워크 레이어를 통해 전송.

상태, 이벤트 , 액션 ...

이런식으로 통신 프로토콜을 그림으로 그리는 것을 finite state machine 이라고 함. (상태 천이도)


“Data Communications and Networking, 5th Edition”, McGraw-Hill Companies, Inc.

Ladder Diagram 혹은 메시지 시퀀스 차트라고 함.

센딩 노드에서 리시빙 노드로 데이터 프레임이 약간의 하강 기울기를 갖는것은 그만큼 시간이 소요된다는 걸 뜻함.

리시빙 노드는 받은 데이터를 벗겨서 패킷을 3계층(네트워크 레이어)에게 전송.


Stop - and - Wait Protocol

Textbook: Behrouz A. Forouzan, “Data Communications and Networking, 5th Edition”, McGraw-Hill Companies, Inc.

1) sending node 네트워크 레이어가 데이터 레이어에게 전달.
2) 데이터 링크 레이어는 받은 정보에 header,tail or stuffed flag, stuffing 을 해야 하니 까만색 부분이 추가돼 있음 -> 까만색 부분은 CRC 코드를 집어넣는 부분.
3) 리시빙 노드에 도착하면 헤더,트레일,플래그 읽고 unstuffing 수행.
4) 동시에 지금 받은 데이터 링크의 프레임을 가지고 CRC 값 계산.
5) 따라서, sender 측에서 CRC 코드를 보내고 수신쪽도 CRC값을 만들어 비교해본 후 동일 하면, 보낸 데이터는 잘 보존돼서 왔다는 증거.
6) Receiving node의 데이터 링크 레이어가 네트워크 레이어로 메시지 올림.
7) Receiving node는 CRC가 포함된 ACK (Acknowledgement) 프레임을 sending node 에게 전달.
8) ACK를 받은 sending node는 CRC값을 계산해 값을 비교 후 동일하면 프레임이 잘 갔다라는 걸 인식할 수 있게됨.


Textbook: Behrouz A. Forouzan, “Data Communications and Networking, 5th Edition”, McGraw-Hill Companies, Inc.

위에가 송신 노드 아래가 수신 노드

송신 노드

송신 노드에서 처음 통신장치가 시작되면 start -> ready
ready 상태에서 네트워크 레이어에서 패킷 받음(event) -> 해당 패킷으로부터 데이터 프레임 생성 후 copy 저장 (이유? 재전송 해야 하므로)
프레임 전송 후 타이머 시작 동시에 상태를 Blocking 으로 바꿈. (블라킹이 되는 이유는 네트워크 레이어에서 추가적으로 오는 데이터는 처리 안하겠다는 의지)

Corrupted ACK arrived : 이상한 ACK 메시지는 버림
Time - out : ACK가 오지 않음 -> 따라서, 저장됬던 프레임 재전송 후 타이머 다시 재생

Blocking -> reday : 성공적으로 ACK가 잘 전송되었다는 의미 (이벤트) -> 타이머 정지 후 재전송 위해 기존 프레임 삭제.

수신 노드

시작시 ready 상태로 들어감
프레임이 도착했는데 정보가 잘못 돼있음 -> 프레임 버림
에러가 없는 프레임 도착 -> 헤더,트레일러 처리, CRC 체크, unstuffing 수행
네트워크 레이어로 올리고 ACK 전송


첫번째 packet

1) sending node의 네트워크 레이어에서 만들어진 패킷이 데이터 링크 레이어에 도착하면 타이머 실행
2) receiving node에게 전송
3) 처리후 네트워크 레이어에게 전달
4) ACK 메시지 sending node에게 전송
5) sending node는 ACK 메시지를 잘 받았으니 타이머 정지

두번째 packet

1) 패킷이 sending node에게 전달되고 데이터 링크 레이어에서 전달
2) 전달되면서 소실됨 (LOST) -> sending node의 데이터 링크 측에서 알 수 있음
how? 타이머가 터졌고 copy했던 프레임을 재전송 하기 때문에 (resent)
3) 재전송된 프레임 잘 받았고 네트워크 레이어로 올림
4) receiving node 데이터 링크가 sending node의 데이터 링크에게 ACK 메시지 전송 후 타이머 STOP

세번째 packet

위와 같은 과정에서 receiving node가 데이터를 잘 받았고 네트워크 레이어에게 잘 올림
그리고 ACK 메시지를 쐈으나 이것이 "소실"
이렇게 되면 sending node는 잘 갔는지 모름 -> 타이머 터짐 -> Frame 재전송

receiving node 입장에서는 자기가 원하는 데이터 이므로 불만 없이 다시 받고 네트워크 레이어로 올림

하지만, 문제는 이것은 중복된 데이터임 (Duplicate)
이건 네트워크 레이어에 올라가면 안됨

이것을 개선하기 위한 방법이 ..

sending node 와 receving node 사이에 주고받는 프레임에 번호를 붙임 !!
(Frame0, Frame 1 ...)

더불어 기존에는 Frame 0번을 보내면 ACK 0 을 보내는게 아니라 그 다음의 자기가 받아야할 ACK 번호를 보냄 (ACK1)

그리고 보내는 메시지는 단일 메시지로 1개밖에 존재하지 않음
따라서, 번호는 0 아니면 1, 1 아니면 0 임

헤더에 번호가 추가된 형국 (stop-and-wait 방식은 0 아니면 1의 방식)

오류 발생 상황에서는 위에서는 중복된 데이터를 거르지 않고 네트워크 레이어로 보내버렸다면 여기서는 사전에 받은 Frame을 인식해 ACK 메시지를 받지 못한 sending node가 Frame을 재전송 했다 한들, Receiving node측에서 중복된 Frame이라 여기면 네트워크 레이어로 올리지 않는다


Piggybacking

서로 양방향 통신에 있어서 ACK라는 메시지를 따른 메시지로 빼서 추가적으로 보내는게 아니라
어차피 쌍방이 보낼 메시지가 있으니 해당 메시지에 ACK 메시지를 "합쳐서" 메시지 전송 횟수를 줄이는 것.

내가 보낼 데이터 ( 돼지의 몸통 ) + ACK 와 같은 제어정보 ( 돼지 꼬리 )


Go-Back-N Protocol

stop-and-wait은 단일 메시지만 주고 받기 때문에 통신 속도도 오래걸릴 뿐만 아니라 메시지 하나를 보내면 받는 동안에 통신 링크가 놀고 있을테니 효율성도 떨어짐

Send Winodw 도입

0 ~ 14 의 프레임 번호가 존재하고 회색 박스안에 있음
따라서 해당 프레임 번호는 상대방으로부터 ACK 메시지가 없더라도 한꺼번에 보낼 수 있음

한 번에 보낼 수 있는 메시지의 양 : Window

0 ~ 6 : 프레임 전송은 했으나 아직 ACK 메시지는 못 받은 상태 ( outstanding )

윈도우 사이즈는 2^m - 1 (개)

만약 0,1,2의 버퍼가 ACK메시지를 받았다면 3번 버퍼를 가르킴
그리고 0,1,2 3개의 응답을 받은 만큼 뒤쪽 꼬리를 3개만큼 채워 버퍼의 수를 유지함 ( Circular Ring )


<오른쪽 그림 기준>

Sender 가 Frame 0 을 전송하고 Receiver (버퍼 1개 가지고 있음) 가 수신
ACK가 전송되지 않았지만 Go-Back-N 방식에서는 Window 크기 만큼 전송이 가능키에 1번을 보낼 수 있음
Frame 1을 Receiver가 받고 2를 기다림
2를 받고 3을 기다림
Sender가 3을 보내면 3을 받고 다음 차례인 Frame 0 을 받기 위해 ACK 메시지를 보내지만 ACK 가 다 깨진 상황
그리고 window 버퍼가 다 찼기 때문에 ( 0,1,2,3) 타이머가 중지됨.

그리고 다시 재전송은 Frame 0 부터 시작됨
Go-Back-N 에서 알 수 있듯이 ACK 메시지를 Frame 0 에서부터 못받았기 때문에 처음으로 돌아감.

따라서 2^m 으로 버퍼 사이즈를 설정 하면 0 을 재전송 하게되는데 receiver는 이미 0,1,2,3을 다 받은 상황 임에도 불구하고 자기가 0을 기다렸기에 똑같은 0을 받아버림. (중복)

따라서 2^m - 1로 버퍼사이즈를 선정 한 것이 왼쪽 그림

버퍼는 0,1,2,3 까지 존재하지만 3개 (0,1,2) 까지만 윈도우를 할당하면 오른쪽에서와 같이 2까지 전송 후 receiver가 해당 Frame을 받고, Frame 0 의 ACK 메시지가 깨졌으니 송신단 입장에서는 Frame 0을 다시 보내지만 수신단 입장에서는 3을 받아야 하는 입장이기에 Correctly discarded 한다.


Textbook: Behrouz A. Forouzan, “Data Communications and Networking, 5th Edition”, McGraw-Hill Companies, Inc.

현재 송시단의 윈도우 버퍼 사이즈는 2^3 - 1 = 7개다.
수신단은 Initial State 상태에서 0 번 기다리고 있음.

송신단은 Frame 0 보내고 수신단은 성공적으로 0 을 받고 ACK1 즉 다음 순번의 Frame을 달라고 요청
송신단의 윈도우 버퍼에서 Frame 0 보냈으니 지우고 꼬리부분에서 한 칸 늘려줌

그 다음 순번이 Frame 1 을 보내고 수신단에서 성공적으로 받고 ACK2 보냄

BUT, ACK2 LOST !!

하지만 sender는 ACK2 소실 상태 모르기에 Frame2,3 연속적으로 보냄
하지만 ACK 2,3에 대한 부분을 받지 못했으니 빨간색으로 처리됨

Frame 2 받고 ACK3 전송함 -> 이 말은 즉슨 앞에 Frame1,2 를 잘받았다고 알리는 겪 그러기에 윈도우 버퍼에서 1,2 빨간색 부분을 제거해주고 꼬리부분에 슬라이딩 시켜줌

같은 논리로 Frame 3 받고 ACK4 수신단에서 송신단 측에서 보내줬기에 빨간색 부분에서 3 없애고 슬라이딩


위의 그림은 방금 앞서서 본 그림과 반대의 상황으로 위의 그림이 ACK의 소실에 관해서 다루었다면 해당 그림은 Frame 소실에 관한 얘기다.

Frmae1 이 전달되는 과정에 소실되었고 송신단은 Frame1 이 소실 된 지 모른채 Frame2,3를 지속적으로 송신하지만 수신단은 받아야 하는 프레임이 1번이기에 받지 않고 거절한다. (ACK 보내지 않음 )


Go - Back - N
: Frame2,3을 보냈지만 응답받지 못하고 다시 Frame 1을 재전송

1번을 잘받은 receiver는 2번을, 2번을 잘받은 receiver는 3번을, 3번을 잘받은 receiver는 4번의 ACK를 보내고 sender는 해당 ACK를 받고 버퍼를 지우고 슬라이딩 !

따라서 , Go - Back - N 은 보냈지만 응답받지 못한 첫번째 부분부터 재전송 하도록 한다


Selectvie Repeat Protocol

Go - Back - N 의 문제점은 송신단이 보낸 메시지 중 받지 못한 메시지의 첫번째 부분부터 재전송을 한다는 것이다 이렇게 되면 1,2,3을 보낼 시 1번이 문제가 된다면야 어쩔 수 없지만 2,3번은 성공적으로 수신단에 도 달 했음에도 불구하고 재전송 해야함 ㅠㅠ

따라서 통신 효율을 올리기 위해 Selective Repeat 의 방식을 채택.

다만, Go - Back - N과의 차이점은 송싱단의 윈도우 버퍼 사이즈가 2^m - 1 이었다면 Selective Repeat Protocol의 윈도우 버퍼 사이즈는 2^m^-1 이다.

위의 그림에서 아직 받지못한 프레임은 3번 프레임 첫번째로 받아야 할 첫번째 프레임은 3번이다
그리고 4,7,9번은 받은 Frame이다.
즉, 에러가 나면 비우면 되고 잘 받았으면 채우면 된다.

3,5,6,8은 에러 부분, 4,7,9는 잘 받은 부분

따라서 핵심 포인트는 수신단 입장에서 잘 받은 부분은 재전송 하지않고 ! 선택적으로 에러가 난 부분만 재전송을 실행하는 것이다.

Go - Back - N과의 차이점은 송신단의 버퍼 사이즈가 하나 커졌고 ACK메시지 뿐만아니라 NAK 메시지 존재
ACK 가 잘 받았다는 표시라면 NAK는 못 받았다는 의미.

못 받았다라는건 크게 2가진데 첫번째는 정해진 메시지가 안오고 그 다음 순번의 메시지가 오는 경우고 두번째는 에러가 발생한 형태로 수신된 경우 이다.

따라서 "잘"받았다 외에 "못"받았다라는 메시지가 추가된다.

오른쪽에서는 2^m-1의 윈도우 퍼버 사이즈를 갖게되는 경운데 Frame 0,1,2 ACK 메시지를 받지 못해서 다시 Frame 0 을 재전송 한다면 수신단 입장에서는 0번은 중복해서 받게 된다.

하지만 왼쪽 그림은 0,1번의 ACK메시지를 받지 못해 0번을 다시 보내도 receiver의 윈도우는 2,3번을 가르키기에 0번은 자기가 받을게 아니라는 것을 인지해 무시한다.


현재 위의 경우 같은 경우엔 m = 3 이므로 윈도우 퍼버 사이즈가 4개임.

송신단이 0번을 보내고 수신단이 받은 경우 수신단의 윈도우 버퍼를 한 칸 이동시키고 수신단은 그 다음 받아야할 Frame을 받기 위해 ACK1을 보냄.

ACK1을 받은 수신단은 Frame0의 타이머를 멈추고 0에 대한 버퍼를 해제하고 한 칸 이동 (1~4)

Frame1 을 보내려는데 LOST !

위에서 go-back-N 과의 가장 큰 차이점은 결론부터 얘기하자면 go-back-n에서는 Frame2,3을 보내도 자기가 받아야 할게 Frame1이기에 무시했지만 이경우에는 지금 당장 받아야할 프레임이 아니더라도 우선 버퍼에 저장시키고 NAK 메시지를 보냄으로써 송신단에게 수신단 측에서 받아야 할 Frame 번호를 인지시킨다.

해당 NAK 메시지를 받은 송신단은 수신단의 입장을 듣고 Frame1을 재전송 한다.

Frame1을 받은 수신단은 1을 포함해 1,2,3을 네트워크 레이어에 올리고 4,5,6,7 로 윈도우 퍼버를 슬라이딩 하고 4번 프레임을 받아야 하니 ACK4를 보냄.

ACK4를 받은 송신단은 1,2,3번의 버퍼를 지우고 4,5,6,7을 슬라이딩 시킨다.


실제 데이터 링크 레이어 위에서 동작하는 소프트웨어 중 하나 - HDLC

![](https://velog.velcdn.com/images/bik1111/post/0bd16fed-3a24-4001-8f80- 3b41dbe6b253/image.png)


프레임 포맷은 I , S , U - Frame 세가지 포맷 존재.
데이터를 주고 받는 포맷이 I 이므로 Flag가 앞쪽에 있고 중간에 유저 데이터 있고 FCS ( Frame Check Sequence - 에러 검출 필드 ) 가 존재
또한 헤더(Source Address, Destination Address) 가 존재하며 패킷 프레임의 시퀀스 넘버를 담은 Control 이 있다.

데이터를 주고 받지는 않지만 내가 ACK 메시지를 주고 받아햘 할 때 에는 S 메시지 사용
(유저 인포만 없음)

사람이 만든 소프트웨어다 보니 해당 소프트웨어를 Control 목적이 아닌 관리 차원에서 필요한 용도로 사용하기 위해 존재하는 U-frame이 있고 유저 인포가 아닌 통신 링크를 유지/관리 하기 위해서 필요한 정보를 실어 날음

단, 트레일러는 존재하지 않음


PPP

휴대폰에서 사용하는 가장 기본적인 메커니즘
PPP는 3계층 이상의 어플리케이션을 설정하고 유지 관리함
따라서 인터넷을 사용하는 이동통신 인 경우엔 PPP를 사용해 네트워크 프로토콜이 잘 돌아가게 해줌
PPP는 사용자가 합법적인지 혹은 얼마만큼의 지원을 받아야 하는지 등의 관리 기능 수행
상위 계층의 네트워크 레이어가 잘 돌아가게 해주는 역할

Protocol 이라는 필드 존재

피지컬 레이어가 정상적으로 연결되면 Establish (연결상태)로 들어감
피지컬 레이어에 문제 발생 시 다시 Dead로 돌아감
상대방 통신장치와 PPP 레벨에서 옵션을 주고 받음
서로 주고받아야 하는 옵션이 맞으면 인증의 단계에 접어듬 (Authenticate)
-> 이동통신의 경우 적절한 유심칩을 탑재한 정상적 유저인지 판단
따라서 0 아니면 1의 값을 가짐

합법적인 사용자라면 네트워크 단계로 들어감
합법적으로 Layer1,2를 쓸 수 있도록 판단이 됐으므로 Network Layer의 환경설정 실행

Open 상태로 들어서고 3계층 이상의 소프트웨어가 Data Transfer를 할 수 있는 상태로 진입


PPP안의 Frame Foramt 에는 다양한 소프트웨어가 존재
예를들어 인증이 필요한 경우 AP 사용 (CHAP, PAP)
IP Protocol 의 Configuration이 필요한 경우 IPCP 사용

PPP는 직접 데이터를 주고받는 다기 보단 상위 계층의 데이터를 실어 나름
실어나르는 대상이 어떤 프로토콜 인지 명기하는 프로토콜 필드가 존재


PPP도 연결 설정 및 해제를 하는데 이것을 해야 상대방 하고 옵션도 맞추고 인증 같은 것을 할 수 있음
다만 직접하지 않고 Link Control Protocol이라고 불리는 것을 사용

프로토콜 필드가 0xC021 이고 LCP 프로토콜의 패킷이 Payload에 담겨서 주고받음.


PPP의 가장 중요한 기능은 이동통신인 경우엔 합법적인 사용자의 유무를 거르는 것.
PAP을 사용

Payload 부분에 들어가는게 사진에 나왓듯이 3개의 부분이 주요 메시지
Authenticate를 request하거나 해당 요청에 대한 응답 (ACK, NAK)


CHAP은 유저가 바로 물어보지 않고 기다림
서버가 인증을 요청해보라고 기회를 줄 때 요청을 보냄
그러면 유저가 요청을 하고 서버가 해당 결과를 알려줌
-> 이런 방식의 이유: 부화관리

전국의 휴대폰이 동시에 무수히 많이 요청하면 서버가 버거움


IPCP : 인터넷 네트워크 계층을 쓰도록 환경을 셋업할 때 사용
IP : IP 프로토콜의 데이터를 실어나를 때 사용


profile
WILL is ALL

0개의 댓글