네트워크 : 데이터 링크
이전에는 정보를 어떻게 시그널 형태로 잘 전송할 것인지 물리적인 채널에서 일어나는 일들을 어떻게 극복할 것인지 배웠다.
이번엔 링크에 대해서 배울 것이다. 처음에는 구분하기가 힘들다.
데이터 링크는 지점에서 지점으로 생각하면 된다.
데이터 링크란?
: 통신에서 일반적인 개념으로 한 지역에서 다른 지역으로 데이터를 전송 또는 수신할 목적을 위한 도구이다.
인터넷이라고 하는 것은 결국 그것이다. 네트워크 간에 연결하는 것이 결국은 인터넷이다.
정보를 어떻게 잘 보낼것인가?
이전에 배운 내용 여기에서는 하나의 링크에서 발생하는 일들을 배우는 것이다.
온갖 수많은 링크 데이터 컨트롤이 있다.
네트워크 마다 컨트롤하는 프로토콜이 다 다르다.
다음과 같은 기능들을 어떤 시스템에서는 적용이 되어있고, 어떤 것은 안되어 있다.
OSI 7레이어
효율성이 점점 강조되다 보니깐. 위와 같은 경우는 효율성이 떨어진다. 최근에는 레이어의 개념이 많이 무너졌다
데이터 링크 컨트롤 프로토콜 기능
Frame Synchronization(동기화)
1. 0과 1의 시퀀스를 모아서 하나의 패킷, 혹은 하나의 프레임 단위로 전송한다.
2. 그런데 여기에서 데이터 링크를 할 것이다. 송신단, 수신단이 있는데, 지금 받는 데이터가 데이터인지 알 수 없다.
3. 그래서 실제로 데이터가 보내지면 어디 부분이 데이터인지 알려주는 것이다.
* 신호는 항상 데이터일 수가 없다. 노이즈일 수도 있고 없을 수도 있다.
= 프레임의 경계를 찾아내는 그런 기능을 위의 개념이라고 한다. 이게 데이터인지 프레임인지 이런 것을 알려주기 위한 기능이다.
Flow control
: 데이터의 흐름을 컨트롤 한다.
1. 얼만큼 빠르게 보내느냐? 받을 수 있는 만큼 데이터를 보내야 한다.
2. 하지만 데이터를 받는 양보다 보내는 양이 많아지면 데이터가 넘처 흐른다.
3. 수신단에 받을수 있는 용량보다 송신단에서 보내는 용량이 더 크다면 데이터가 넘처 흐른다.
4. 그렇기 때문에 받을 수 있는 수신노드의 용량을 보고 흐름을 제어한다.
* 현재는 데이터 링크에서 flow control을 이야기한다. 어떤 레이어의 관점에서라든지 개념이 살짝 달라질 수 있다. 세션인지, 노드인지 링크인지 에서 flow cotrol을 한다.
* flow control이 없으면 버퍼가 가득 차거나, 오래된(기존의) 데이터를 프로세싱 하는 동안에 넘칠 것이다.
* 그림에서 Model of Frame TransMission 부분 다시 확인하기
Error contorl
: 에러가 난 것을 잘 처리하는 개념이다.
데이터를 보내면 잘받았어? 라고 말하고 그리고 그에 해당하는 응답을 하는 개념이라고 보면 된다.
Addressing
: 내가 어디로 보낼 것인가? 보내는 주소,
네트워크는 링크가 엄청 많다. 나와만 보내는 것이 아니라 수많은 링크와 연결되어 있기 때문에 주소가 필요하다.
Control and Data
: 말그대로 어떤 데이터를 보낼 것인가 생각하는 것이다. 비디오를 보낼 것이냐, 이메일을 보낼 것인가?
* 실제 정보 컨텐츠가 아닌 컨트롤 정보를 보낼 수 도 있는 것이다.
Link Management
: 링크가 끊어지거나 링크에 관한 것을 관리하는 부분이라고 보면 된다.
위와 같은 개념들이 데이터 링크 컨트롤 프로토콜에서 수행하는 기능이다.
- Stop and Wait flow control
: flow control 방법이다. 기본적으로 가장 심플한 방법이다.
하나 보내고, 멈추고, okay 사인이 오면 다시 보낸다(어!~ 다시 보내도 돼!라고 하면 보낸다).
= 한번에 한 프레임만 보낸다.
1. 송신자가 데이터를 보낸다
2. 수신단에서 ack에 대해서 응답을 한다.
3. -> 다음 프레임이 보낼때 까지 소스는 ack를 기다린다 ->
Utilization을 보자. 그림을 보고 확인해봐라. 이그림에 대해서 해석 해보자
a가 1보다 작은 경우는 문제가 안된다. propagation time = a, transmission time
하지만 훨씬 큰 경우는 신호가 날아가는데 오래걸리는 경우, 채널이 비어있는 시간이 많아지기 때문에 비효율적이다.
심플하고 편리하지만 위와 같은 경우는 효율성이 떨어질 수 있다.(그림만 보고 한번에 캐치하면 --> 시험에 나올 수도)
그래서 위와 같은 비효율성의 문제 때문에 sliding window를 사용한다.
다수의 프레임을 한번에 보낸다.
*프레임? 데이터가 담겨진 신호로 확인해보자.
여러개의 멀티플 넘버의 프레임을 ack없이 한번에 보낸다.
1,2,3을 한번에 보낸다. 3개를 다 받으면 다음것 세개로 보내고 --> 이러면 stop and wait하는 시간이 줄어든다.
이럴려면 window 프레임에 인덱스가 있어야 한다,. 프레임에 순서가 있어야 한다. 그래서 프레임에 넘버링을 해야한다.
시퀀스 넘버가 프레임 안에 포함되어야 한다. 만약에 5비트이다 그러면 0~31까지 나타낼 수 있고 여기에서는 시퀀스가 넘버가 k비트에 따라 결정이 되면 프레임 넘버가 2의 k이고 이러면 윈도우 사이즈는 2의 k승 -1이다.
왜그럴까???
https://itchipmunk.tistory.com/363 에서 발췌
수신자의 윈도우가 꽉 찰 때 까지, 데이터를 전송하는 방법이다. 만약, 윈도우가 꽉 찼다면 수신자가 더 큰 윈도우가 있다고 알릴 때 까지 전송을 중단해야 한다.
슬라이딩 윈도우 흐름 제어는 버퍼 크기가 제한되어 있을 때 효과적이다.
수신자가 n 개의 프레임을 받을 수 있는 버퍼 공간이 있을 때, 송신자는 수신자가 n 개의 프레임을 버퍼에 넣을 때까지 ACK 메시지를 받지 않더라도 보낼 수 있다.
ACK 를 받은 프레임들을 쫓을 수 있도록, 순차적으로 전송된 프레임들은 넘버링된다.
슬라이딩 윈도우가 최대 7개라면 최대 7까지 ack를 받지 않은 상태에서 보낼수 있는 용량이다 라는 뜻이다.
High Level Data Link Control(HLDC)
아주 전통적이지만 데이터 링크 프로토콜에 기본이 되는 구조이다.
이 프로토콜의 사용자는 다음과 같이 나눴다.
1. station
- primary : 링크를 직접 제어하는 노드
- secondary : 부차적인 노드
- combinded :
2. Link configuration - 링크의 구성이다.
- unbalanced - 1 primary, multiple secondary
- balanced - 2 combined station
모든 프로토콜을 이야기할 때 제일 처음으로 다루는 내용이다.
Frame Structure
: Flag+ control + address + information + FCS + flag
각 부분들이 무슨 뜻이고 어떤 기능을 하는지 확인하자.
Flag
: 먼저 기존에 배웠던 프레임 동기화에 대해서 확인해보자. 프레임 동기화란 무엇인가? 프레임의 시작과 끝을 알려줘야 한다는 개념이다. 그래야지 어디부터가 데이터의 시작이고 데이터의 끝을 알려줄 수 있기 때문이다.
시작과 끝을 알려주기 위해서는 플래그에 8비트를 앞과 뒤에 집어 넣는다.
하지만 이와 같은 경우 어떤 2가지 문제점이 발생한다.
1. 플래그가 깨져버리면 프레임을 날려버릴 수 있다.
2. 만약에 다른 필드와 플래그 값이 우연하게 동일한 값이면 필드 값들이 엉망 진창이 된다.
2번과 같은 문제를 방지하기 위해서 Bit stuffing을 사용한다.
Bit stuffing이란? 데이터의 5비트마다 0을 하나씩 넣어주는 기술을 의미한다. 이렇게 한다면 어떠한 경웨도 정보 필드에 플래그 필드와 동일한 연속적인 1이 나올 수가 없다.
하지만 Bit stuffing에도 다음과 같은 단점이 있다. 0을 집어 넣기때문에 데이터를 처리하는 속도가 느려진다. 그래서 현재는 사용하지 않는 방법이라고 한다.
Address
address 필드는 한 바이트 단위로 처리한다. 1바이트는 8비트인데, 이 부분에서 가장 왼쪽에 있는 하나의 비트 값이 1인지 0인지에 따라서 address필드를 extend할 것인지 아닌지 확인할 수 있다. extend한다는 뜻은 지금 읽고 있는 바이트 다음으로 또 다른 주소 값이 오느냐 안오느냐를 확인할 수 있는 비트이다. 말 그대로 끝을 알려주는 비트라고 보면 된다.
* 여기에서 address값이 11111111이면 현재 연결되어 있는 모든 단말기에 전송할 수 있다는 뜻이다.
Information field
1바이트 단위로 보낸다. 길이는 다양하다.
I 프레임, u프레임에서 보내진다.
FCS field
에러 감지 코드이다.
보통은 16비트의 크기를 가진다. CRC_CCITT비트 기준을 사용한다.