[Chapter 06] 데이터 링크 계층의 작업

---

1️⃣ 프레임

🩶 프레임 만들기

• 데이터 링크 계층의 역할
  • 물리 계층을 이용하여 LAN에 속해있는 노드들에게 데이터 전송
• 데이터 링크 계층은 네트워크 계층이 보내온 패킷에 데이터 링크 계층의 헤더 붙임 + 전송
• → 프레임
• 데이터 전송 방식
  1. 비동기식 전송 -> 송, 수신자 소통 안 함
     1. 예고 없이 데이터 보냄
  2. 동기식 전송 -> 송, 수신자 소통함
     1. 데이터 전송한다고 알려주고 프레임 보냄
• 플래그: 동기식 전송에서 데이터 보내기 전에 통신 시작 알리는 신호
• 프레임 시작과 끝 모두 알려줘야 함
• 프레임 시작 플래그: 프리앰블
• 프레임 끝 플래스: 포스트앰블

• but, 프레임 내에 플래그와 같은 패턴의 데이터 있을 경우 문제 발생
  • 이 경우, 데이터 앞에 이스케이프 문자 (ESC) 삽입해서 전송
    • 다음 문자가 특수문자임을 알리는 \ 사용
  • 프레임 안에 “ESC + 플레그” 패턴이 이미 있으면, “ESC+ ESC+플래그” 형태로 보냄

🩶 문자 프레임과 비트 프레임

1. 문자 프레임
   • 문자 프레임은 데이터를 아스키코드 형태로 전송
   • 프리앰블: DLE STX 붙여서 사용
   • 포스트 앰블: DLE ETX 붙여서 사용
   • 데이터에 DLE ETX가 있으면, DLE 하나 더 붙여서 전송
   • → 문자 스터핑
   • 현재 거의 사용 X
2. 비트 프레임
   • 대부분 사용하는 방식
   • 프리앰블, 포스트 앰블에 비트 패턴 사용 (똑같이 0111 1110)
     • 0 이후 1 6개 0 (8비트)

• but 데이터에 플래그와 같은 패턴 나올 시 문제 발생
• 연달아 나타나는 1의 다섯 번째 다음에 0 하나 삽입
• → 비트 스터핑

---

2️⃣ 슬라이딩 윈도우 프로토콜

🩶 데이터 전송 오류

• 오류를 발견하고 수정하는 역할: 데이터 링크 계층

1. CASE 1

• 송신 A가 보낸 프레임 사라지는 문제
  • 송신 A는 모르고 두번째 프레임 전송
• 수신 B는 처음 보낸 프레임이 사라졌는지 몰라서, 두 번째 프레임을 첫 번째 프레임이라고 착각

• 프레임을 보낸 쪽은 제대로 받았는지 확인 못함
  • 수신쪽은 프레임을 제대로 받으면 액(ACK) 소리를 침
  • 이 소리를 들어야 다음 프레임 전송

2. CASE 2

• 수신 B가 프레임 받고 ACK 했는데 ACK이 사라짐
• A는 ACK 못 받아서 다음 프레임 못보냄+ B도 다음 프레임 계속 기다림
  • 하염없이 기다림
• 양쪽 모두 타임 아웃 사용해서 해결
  • 어느 시간 내에 오지 않으면 다시 보내는 것

3. CASE 3

• 송신 A가 프레임 보냄
• 수신 B가 프레임 받고 ACK 보냄, 근데 이 ACK이 지연됨
• 송신 A가 타임아웃 (ACK 못받았으니) 걸려 같은 프레임 재전송
• 이후 첫번째 ACK 도착
• 수신 B는 이를 두 번째 프레임이라고 착각

• 이 경우 일련번호(sequence number) 사용
  • 프레임에 일련번호를 붙여 몇 번째 프레임인지 표기

4. CASE 4

• 수신 B가 프레임 받고 보낸 ACK이 늦게 도착
• 송신 A 타임아웃 결려 0번 프레임 다시 보냄
• 0번 프레임 다시 전송 후 지연된 ACK 도착
• 송신 A는 0번 프레임에 대한 ACK이라 생각하고 1번 프레임 전송
• 1번 프레임이 통신 과정에서 사라짐
• 수신 B는 타임아웃 이후 다시 온 0번 프레임 폐기 후 ACK 전송
• 송신 A는 1번 프레임에 대한 ACK이라고 생각해서 2번 프레임 전송

• 이 경우 ACK 일련번호 사용으로 해결
• 송신 A는 0번 ACK이 두번 옴을 알고 폐기

• 데이터 전송의 필수 요소
  • 응답 메시지 (ACK)
  • 타임아웃
  • 프레임 일련번호
  • ACK 일련번호
• but, 데이터도 없이 ACK만 보내는것은 낭비
  • 양방향 통신은, 양쪽에서 보냄 (그리고 보통 통신은 양방향 통신)
  • 전송되는 데이터에 ACK 넣어 보내면 이득
  • 기존 데이터에 ACK 얹어서 보내는 방식: 피기백킹

🩶 슬라이딩 윈도우 프로토콜

• 데이터 보낸 후 멈춤, ACK 기다림 → Stop-and -Wait 방식
  • 원시적이고 느림
• 에러 없는 네트워크에서 ACK 매번 기다리는건 낭비
• ACK 없이 한번에 많은 데이터 보내면 전송속도 ↑= 연속전송 프로토콜

• = 슬라이딩 윈도우 프로토콜
• 수신측은 프레임 잘 받으면 ACK, 못 받으면 NACK 보냄
• 윈도우 크기: 슬라이딩 윈도우 프로토콜에서 송수신측이 ACK 없이 보낼 수 있는 프레임 개수 (가변적)
• if 윈도우 크기 4 → ACK 없이도 4개 프레임 연속으로 보낼 수 있음
• 받는 쪽은 마지막 4번째의 ACK 만 보냄
• ACK 받으면 다음번 4개 프레임 전송

🩶 ARQ

• Automatic Repeat Request의 약자, 자동 반복 요청을 의미
• 에러가 발생한 경우 재전송을 요구하는 방식

1. 무잡음 채널에서의 프로토콜
   • Simplest
     • 받았는지, 안 받았는지는 모르겠고 그냥 1 → 2 → 3 → 4 차례로 보냄
   • Stop-and-Wait
     • 하나 보내고 ACK 기다리고 하나 보내고 ACK 기다리는 방법
2. 잡음이 있는 채널에서의 프로토콜
   • Stop-and-Wait ARQ
     • 윈도우 사이즈 1
     • 첫번째꺼 보내고 ACK, 두번째꺼 보내고 ACK
     • 못 받으면 NACK
   • Go-back-N ARQ
     • 오류가 난 지점부터 전송할 지점까지 모두 재전송 (n 만큼 다시 보냄)
     • 0123 전송 → 1에서 에러 발생 → 1번 NACK 보냄 → 1234 보냄
     • → 4에서 에러 발생 → 4번 NACK 보냄 → 4567 보냄
   • Selective Repeat ARQ
     • 오류가 난 부분 (NACK 받은 프레임)만 재전송
     • 1234 전송 → 3에서 에러 발생 → 3번 NACK 보냄 → 3567 보냄 → 5에서 에러 발생 → 5번 NACK 보냄 → 58910 보냄
     • 단, 수신 B가 버퍼에 프레임 4를 버퍼에 보관했다가 3을 받은 후 프레임 재조합해야 함
       • Go-back-N에 비해 회로도 복잡
       • but, Go-back-N보다 효율적
   • Adaptive ARQ
     • 데이터 프레임 길이 네트워크 상태에 따라 동적 변경
     • 복잡, 사용 X

---

3️⃣ 오류 처리 코드

🩶 오류 처리 코드의 종류

• 에러 탐색 코드: 에러 찾을 때 사용하는 코드
  • 패리티 비트
  • CRC 코드
  • 검사합
• 에러 보정 코드: 에러 찾고, 보정해줌
  • 허밍 코드

🩶 패리티 비트

• 간단함
• 보내려는 데이터에 추가로 1비트 만듦
• 짝수 패리티 비트
  • 1의 개수를 짝수로 맞춤
• 홀수 패리티 비트
  • 1의 개수를 홀수로 맞춤

• 간단한데, 연속에러에 취약
• 에러가 짝수 개 발생시 에러 발견 못함

• 이때 패리티 비트를 수직, 수평 배열함 (2차원)
• 근데 이것도 짝수개 에러에 취약함
• 따라서 패리티 비트는, 추가되는 1비트당 1개의 에러 찾기 가능

🩶 CRC (Cyclical Redundancy Check, 순환 중복 검사) 코드

• 적은 오버헤드로 많은 에러 찾기 가능 → 가장 많이 쓰임
• 송수신측은 같은 “CRC 코드값” 을 알고 있음
• 보내는 쪽에서 데이터를 CRC 코드 값으로 나누었을 때 나머지가 0이 되게 숫자 추가해서 보냄
  • 보내려는 데이터 12, CRC가 9
  • 9로 나누어서 0이 되는 값을 붙여 보냄 (126) (120~129 사이의 값)
  • 받는 쪽은 9로 나눠보고 0이면 에러 없음, 0 아니면 에러 있음
  • 총 8개의 오류 탐지 가능
• CRC 코드가 8비트라면, 찾을 수 있는 에러 개수 2⁸ - 1 = 255개 (전체 - 정답)
• 16비트라면 2^16 - 1 = 65535개
• CRC-16, CRC-32, CRC-64 등이 있음
• CRC-32는 이더넷 헤더, 압축파일, PNG 헤더등에 사용

🩶 CRC 자세히 알기

1. 보내는 쪽
   • 보내려는 데이터 1100, CRC 1001
   • CRC가 4비트면 원본 데이터에 0 3비트 추가
   • 이후 1100 000 대상으로 나눗셈
   • 나눗셈은 모듈러2연산 (XOR 연산)
     • 같으면 0, 다르면 1
   • 연산으로 나온 값: 101
   • 최종 수신되는 데이터: 1100 101

2. 받는 쪽

• 1100 101을 CRC 코드 (1001)로 나눠봄
• 나눗셈 결과 000 나오면 에러 없음

• CRC-16은 17 비트짜리. 32는 33 비트 짜리

• 추가 crc 알아보기

🩶 검사합

• CRC 보다 간단한 에러 탐색
• 보내려는 데이터 일정 크기로 자르고 이를 더하여 에러 탐색 코드 만듦
• but, 변형되어 우연히 합이 같아질 수 있어서 CRC 보다 찾을 수 있는 에러 양 적음

송신측

1. 16비트 8비트로 자르기

-> 여기서 8비트는 사람이 정하는 값으로 가변적

2. 자른것들 더하기

3. 1의 보수 취하기

수신측

1. 8비트로 끊어서 더해보기

2. 1의 보수를 취한 최종 결과가 0

🩶 정리

• 에러 제어
  • 에러 검출: 패리티 검사, CRC, Checksum
  • 에러 복구: Stop-and-Wait ARQ, Go-back N ARQ, SR ARQ
• 흐름 제어
  • 슬라이딩 윈도우 프로토콜: 트래픽이나 딜레이에 따라 윈도우 사이즈 조절하여 전송 속도 제한
• 이 모든 것들은 데이터 링크 계층에서 하는 것들!

---

💻 Reference

데이터통신과 네트워킹 | 조성호 - 교보문고