이전 시간에는 물리 계층에 대해 알아봤습니다.
오늘은 물리 계층과 데이터를 주고 받는 데이터 링크 계층에 대해 알아보겠습니다.
데이터 링크 계층
데이터 링크 계층은 Mac 주소가 사용되며, 데이터가 안전하게 전달되도록 도와주는 계층입니다.
이렇게만 설명하면 확 와닿지 않으실 테니 지금부터 자세히 설명해보겠습니다!
- 데이터 전송 과정
위의 그림은 데이터가 전송되는 과정을 보여주는 그림입니다.
송신 측에서 바라보면 네트워크 계층에서 받은 데이터에 트레일러와 헤더를 붙여 물리 계층으로 넘겨줍니다. 헤더에는 Mac주소가 들어있고, 트레일러에는 에러 검출을 위한 정보가 들어있습니다. 데이터에 헤더와 트레일러가 붙은 것을 프레임이라고 하며 데이터 링크 계층에서 사용됩니다.
수신 측은 송신 측과는 반대로 물리 계층에서 데이터가 들어오면 트레일러와 헤더를 제거하여 네트워크 계층으로 보내줍니다.
- Mac 주소
Mac 주소는 컴퓨터마다 가지고 있는 고유의 주소입니다. 같은 Mac 주소는 존재하지 않고 바뀌지 않는 물리 주소이며 2계층인 데이터 링크 계층에서 사용됩니다.
근데 이쯤에서 "통신은 IP주소로 한다고 알고 있는데 IP주소와의 차이점은 뭐지?"라는 궁금증이 생길 수 있습니다.
IP주소의 정의는 컴퓨터간 통신하기 위해 사용되는 네트워크 상 주소로, 논리 주소이며 3계층인 네트워크 계층에서 사용됩니다. 정의만 봤을 때는 두 개의 차이점을 잘 모르겠죠?
이해를 돕기 위해 예시를 들어보겠습니다. Mac 주소는 "나의 주민등록번호", IP주소는 "내가 살고 있는 집의 주소"라고 생각하면 이해하기 쉽습니다. Mac 주소는 내가 맞는지 확인하는데 사용되는 주소이고, IP주소는 데이터가 전송될 때 어디로 가야 하는지를 알 수 있는 주소입니다.
택배를 보내는 것으로 예를 들면, IP주소인 "서울시 서초구 A동 B아파트"를 통해 택배가 도착하고 Mac 주소인 "010101-0000000"을 통해 내게 온 택배가 맞는지 확인하는 것입니다.
그럼 Mac주소나 IP주소 둘 중 하나만 있어도 통신이 가능할까요? 정답은 "아니오"입니다.
Mac 주소는 위의 예시처럼 주민등록번호와 비슷하기 때문에 데이터를 보낼 때 수신 측 컴퓨터를 찾는 게 불가능에 가깝습니다. 주민등록번호가 주소체계를 포함하지 않기 때문에 해당 주민등록번호를 가진 사람이 어디 있는지 모르는 것처럼 말입니다.
IP주소는 "서울시 강남구 A동 B아파트"처럼 수신 측 컴퓨터가 어디 있는지 알 수 있는 주소지만 지번 주소가 도로명 주소로 바뀐 것처럼 사실 변할 수 있는 주소입니다.(바뀔 수 있는 주소, 즉 규칙에 맞게 정한 주소이기 때문에 논리 주소라고 하는 것입니다.) 따라서 IP주소를 따라 수신 측 컴퓨터에 도착하더라도 Mac 주소를 통해 통신하고자 하는 컴퓨터가 맞는지 확인할 필요가 있습니다.
따라서 Mac 주소와 IP주소가 모두 필요합니다!
- 흐름 제어 기법 (흐름 제어 기법은 2계층 프로토콜 중 HDLC프로토콜에 관한 내용입니다.)
송신 측에서 수신 측으로 데이터를 전송할 때 무작정 데이터를 전송한다고 해서 모든 데이터가 잘 전송되는 것은 아닙니다. 라우터나 컴퓨터같은 장치마다 받은 데이터를 처리하는 시간이 필요하기 때문입니다. 따라서 흐름 제어 기법이 필요합니다.
흐름 제어 기법은 송신 측 컴퓨터와 수신 측 컴퓨터의 데이터 처리 속도 차이를 해결하기 위한 제어 기법입니다.
컴퓨터마다 데이터를 처리할 수 있는 속도가 다른데 데이터 처리 속도가 느린 컴퓨터에 연속적으로 계속 데이터를 보내게 되면 수신 측 컴퓨터는 받은 데이터를 모두 처리할 수가 없게 됩니다.
예를 들어 1초당 10개의 프레임을 처리할 수 있는 컴퓨터에 1초당 100개의 프레임을 보내면 해당 컴퓨터가 100개의 프레임을 모두 처리할 수 없고 결국 통신이 원활하게 이루어지지 않게 됩니다.
이를 해결하기 위해 2개의 흐름 제어 기법이 사용됩니다.
(1) Stop & Wait
PC1에서 PC2로 데이터를 보낼 때 프레임을 전송한 뒤 ACK이 올 때까지 기다리는 기법입니다.
ACK(Acknowledgement)이란 데이터가 성공적으로 잘 전송되었다고 수신 측이 송신 측에 알려주는 신호입니다. 송신 측에서는 ACK을 받아야지만 문제없이 전송되었구나를 알 수 있으므로 ACK을 받을 때까지 기다려야 해서 시간이 많이 소요된다는 단점이 있습니다.
문자 보내는 것으로 예를 들어보겠습니다.
핸드폰 화면이 작고 스크롤 기능이 없어서 화면에는 하나의 문자만 보인다고 가정하겠습니다.
이러한 상황 속에서는 내가 친구에게 문자를 보낼 때 무조건 한 개만 보내야 친구가 내가 보낸 문자를 확인할 수 있습니다. 만약 여러 개 보내면 친구는 내가 이전에 보낸 문자를 확인하지 못하게 됩니다. 또한 친구에게 문자를 잘 받았는다는 답장(=ACK)을 받아야 문자가 문제없이 도착했구나를 알 수 있고, 친구가 잘 받았다는 문자를 보내면 그제야 내가 또 다른 문자를 보낼 수 있게 됩니다.
(2) Sliding Window
Sliding window에서는 버퍼가 등장합니다. 여기서 버퍼는 전송받은 데이터들의 "대기장소"로 이해하면 됩니다. 송신 측 컴퓨터와 수신 측 컴퓨터에 동일 크기의 버퍼가 준비되어 있고 버퍼의 크기만큼 window의 크기가 결정됩니다. 버퍼(=대기장소)가 존재하기 때문에 송신 측에서는 ACK과 상관없이 window(=버퍼)의 크기만큼 프레임을 보낼 수 있습니다. 프레임을 보내다가 ACK을 받게 되면 해당 ACK까지의 프레임은 수신 측에 문제없이 도착한 것이므로 송신 측 window를 ACK 된 프레임 크기만큼 이동합니다.
이해를 돕기 위해 위의 그림을 통해 설명하겠습니다. 버퍼가 5인 상황에서 송신 측의 윈도우를 표현한 것으로, 송신 측에서는 프레임 1~5를 순차적으로 수신 측에 보냅니다. 프레임 1,2를 보낸 상태에서 ACK2를 받게 되면 프레임 1,2가 제대로 전송되었다는 것을 의미하므로 윈도우를 2만큼 이동합니다. 윈도우가 이동하였으므로 프레임은 3~7까지 순차적으로 전송되며 위의 과정이 반복됩니다.
Sliding Window의 핵심은 양쪽 컴퓨터 모두에 버퍼가 존재하기 때문에(=데이터들의 대기장소가 존재하기 때문에) 받은 데이터를 바로 처리해야 하는 부담이 적어지고 ACK도 여러 프레임에 대해 한번만 보내면 된다는 것입니다. 따라서 Stop & Wait 보다 처리 속도가 빠릅니다.
위에서 들었던 예시를 다시 들어보겠습니다.
스크롤 기능이 추가되어 화면에는 5개의 문자까지 보인다고 가정하겠습니다.
문자가 화면에 보이는 개수가 윈도우의 크기라고 이해하면 됩니다. 이러한 상황 속에서 내가 친구에게 문자를 보낼 때 5개까지는 걱정 없이 보낼 수 있습니다. 2개만 보냈는데 친구에게 답장을 받는다면, 3(답장 없이도 보낼 수 있는 문자 개수)+2(잘 받았다는 확인을 받은 문자 개수) = 총 5개 만큼을 또 걱정없이 보낼 수 있습니다.
- 오류 제어 기법과 트레일러 (오류 제어 기법은 2계층 프로토콜 중 HDLC프로토콜에 관한 내용입니다.)
트레일러는 FCS(Frame Check Sequence)라 부르기도 하며, 데이터가 안전하게 전달될 수 있도록 데이터 전송 도중 오류가 발생하는지 확인하는 데 사용됩니다. 전송하고자 하는 데이터 값(트레일러를 제외한 부분)을 가지고 정해진 연산을 통해 FCS값을 결정합니다. 수신 측에서는 도착한 프레임 중 트레일러 부분을 제외하고 나머지 데이터를 통해 똑같은 연산과정을 거쳐 FCS값을 도출합니다. 받은 프레임의 FCS값과 수신 측에서 계산한 FCS값이 같으면 프레임이 오류 없이 전송되었다는 것을 보장할 수 있습니다. (어떤 연산을 하는지는 프로토콜마다 정해져 있어서 같은 연산을 수행합니다!)
만약 계산한 FCS값이 받은 프레임의 FCS값과 다르면 전송 중에 오류가 발생했다는 것을 의미하는데 이럴 땐 어떻게 해야 할까요?
송신 측에 다시 데이터를 보내달라 요청해야 하며 재전송되는 과정을 ARQ(Automatic Repeat Request)라고 합니다. 이러한 것을 오류 제어 기법이라 하며 3가지 기법이 있습니다.
(1) Stop & Wait ARQ
흐름 제어 기법의 Stop & Wait 기법에 대한 오류 제어 기법으로 수신 측에서 데이터 전송 중 오류가 발생했다는 걸 의미하는 NACK(Negative Acknowledgement)을 전송하거나 주어진 시간 안에 수신 측에서 ACK을 보내지 않으면 송신 측에서 프레임을 재전송합니다.
아래의 그림 중 첫 번째 그림이 stop & wait방식에 해당되며 왼쪽선이 송신 측, 오른쪽선이 수신 측을 의미합니다. 프레임과 ACK이 교차되는 부분 없이 순차적으로 전송되고 NACK을 받으면 해당 프레임을 다시 전송합니다.
(2) Go Back N ARQ
흐름 제어 기법의 Sliding Window 기법에 대한 오류 제어 기법으로 송신 측에서 프레임들을 순차적으로 보내면 수신 측에서 지금까지 받은 프레임에 대한 응답을 한 번만 보냅니다. 이때 하나라도 오류가 발생한 프레임이 있으면 NACK을 보내며, 수신 측이 NACK을 보내면 송신 측은 NACK이후의 모든 프레임을 다시 보냅니다.
가운데 그림을 보면 ACK이 도착하기도 전에 여러 프레임을 연속적으로 수신 측에 전송합니다. 송신 측은 NACK2를 받는 순간 프레임 2부터 다시 차례로 프레임을 전송합니다.
(3) Selective Repeat ARQ
흐름 제어 기법의 Sliding Window 기법에 대한 오류 제어 기법으로 Go Back N ARQ과 비슷하지만 문제가 생긴 프레임에 대해서만 NACK응답을 보내서 손상된 프레임만 다시 재전송받습니다. 효율은 좋을 수 있으나 문제가 생긴 프레임만 재전송해야 하므로 구조가 복잡합니다.
세 번째 그림을 보면 Go Back N과 비슷해 보이지만 NACK2가 도착했으므로 프레임 2만 다시 보내는 것을 볼 수 있습니다.
- 스위치
스위치는 데이터 링크 계층에서 사용하는 장치로 아래 그림에서 SW라고 적혀있는 것이 스위치입니다.
하나의 스위치에 여러 컴퓨터가 연결되어 있어서 언뜻 보기에는 1 계층에서 사용하는 허브와 비슷해 보입니다. 하지만 단순히 전송매체를 연결해주는 역할만 하는 허브와 달리 스위치는 Mac 주소를 저장하고 있습니다.
스위치는 Mac 주소 테이블에 자신과 연결되어 있는 컴퓨터들의 Mac 주소를 저장합니다. 그래서 허브만 연결되어 있을 때는 브로드 캐스트를 해야 했는데 스위치는 각 컴퓨터의 Mac주소를 알고 있기 때문에 데이터를 보내면 데이터 속 Mac 주소와 일치하는 컴퓨터에 데이터를 전송해줍니다.
여기까지 이해하고 나면 "분명 위에서 Mac 주소로는 통신이 안된다고 했는데 스위치를 통해 특정 컴퓨터에 데이터를 전송해주는 것을 보니 Mac주소로 통신할 수 있는 거 아닌가"하는 의문이 생길 수 있습니다. 사실 같은 스위치에 연결된 컴퓨터들끼리는 Mac 주소만으로도 데이터가 전송될 수 있습니다. 이때 같은 스위치에 연결된 컴퓨터가 무엇인지 알아야 의문이 풀립니다.
위의 그림에서 빨간 선으로 묶인 것들이 같은 스위치에 연결된 컴퓨터들이고 이를 LAN이라고 부릅니다. LAN은 한정된 공간(=집, 사무실 등)에서 스위치나 공유기에 연결된 네트워크를 의미합니다. LAN 안에 있는 각 컴퓨터들은 "스위치만 거치면" 바로 같은 LAN 안의 다른 컴퓨터로 갈 수 있고 스위치에는 컴퓨터의 Mac 주소가 있기 때문에 Mac 주소만으로 데이터가 전송될 수 있는 것입니다.
IP주소까지 모두 필요한 경우는 초록 선으로 묶인 상황입니다. 스위치로 연결된 LAN들을 라우터(R1으로 표시되어 있는 것)가 연결하고 있고 이러한 네트워크를 WAN이라고 합니다. IP주소는 WAN안에서 통신하고자 할 때(=LAN1에 연결된 컴퓨터가 LAN2에 연결된 컴퓨터와 통신하고자 할 때) 필요합니다.(라우터는 3계층에서 사용되는 장비로 라우터에 대해서는 다음 시간에 자세히 다룰 예정입니다.)
다시 말해서 스위치1에 연결되어 있는 PC1에서 스위치2에 연결되어 있는 PC2로 데이터를 보내고자 할 때는 Mac 주소만으로는 데이터 전송이 불가능합니다. 당연한 이유지만 스위치1에는 PC2의 Mac 주소가 저장되어 있지 않기 때문입니다.
스위치에 대해 정리하자면 스위치는 Mac 주소 테이블을 가지고 있어서 같은 스위치에 연결된 컴퓨터끼리는 Mac주소만으로 데이터 전송이 가능합니다. 라우터를 거쳐 다른 스위치에 연결된 컴퓨터와 통신하고자 할 때는 IP주소가 필요합니다.
지금까지 데이터 링크 계층에 대해 자세히 알아봤습니다.
다음 시간에는 네트워크 계층에 대해 알아보겠습니다.
'CS 전공지식 > 네트워크' 카테고리의 다른 글
| [네트워크] OSI 7계층(TCP) (3) | 2022.04.10 |
|---|---|
| [네트워크] OSI 7계층(전송 계층, UDP) (3) | 2022.04.02 |
| [네트워크] OSI 7계층(네트워크 계층) (2) | 2022.03.27 |
| [네트워크] OSI 7계층(물리 계층) (3) | 2022.03.15 |
| [네트워크] OSI 7계층 (3) | 2022.03.08 |
