33. ENQ / ACK / NAK / EOT (통신 제어 문자)

핵심 인사이트 (3줄 요약)

본질: ASCII 기반의 데이터 링크 제어(특히 BSC 프로토콜)에서 통신 장비 간에 연결을 맺고(ENQ), 수신 성공(ACK)과 실패(NAK)를 알리며, 통신 종료(EOT)를 선언하는 **가장 원초적이고 핵심적인 4대 제어 문자(Control Characters)**다.

가치: 이 4가지 문자의 핑퐁 교환은 네트워크가 단순히 0과 1을 쏟아붓는 배관이 아니라, 에러를 인지하고 재전송(ARQ)을 수행하여 신뢰성 있는 엔드투엔드(End-to-End) 무결성을 보장하는 지능형 시스템으로 도약하게 만든 근간이다.

융합: 비록 문자 동기방식(BSC)은 낡은 유물이 되었으나, "물어보고, 응답하고, 실패하면 다시 보내는" 이 완벽한 철학은 현대 TCP의 3-Way Handshake와 HTTP 상태 코드(200 OK, 4xx 에러)의 DNA에 그대로 융합되어 살아 숨 쉬고 있다.

Ⅰ. 개요 및 필요성 (Context & Necessity)

개념:
- ENQ (Enquiry, 0x05): 상대방에게 링크 설정을 요구하거나 응답을 재촉할 때 쓰는 "질문" 문자. ("들을 준비 됐어?")
- ACK (Acknowledgment, 0x06): 정상적으로 수신했거나 연결 준비가 끝났음을 알리는 "긍정 응답" 문자. ("응, 완벽해. 계속 쏴!")
- NAK (Negative Acknowledgment, 0x15): 데이터가 깨졌거나 버퍼가 차서 못 받는 상황을 알리는 "부정 응답" 문자. ("에러 났어. 방금 그거 다시 보내!")
- EOT (End of Transmission, 0x04): 더 이상 보낼 데이터가 없어 통신 링크를 해제하고 매체 주도권을 넘기는 "종료" 문자. ("나 볼일 다 봤어. 끊을게!")
필요성: 우주로 전파를 쏘거나 해저 케이블로 전기를 보낼 때, 도중에 잡음(Noise)에 맞아 데이터가 박살 나는 일은 필연적이다. 만약 수신기가 에러가 났다고 송신기에게 알려주지 않으면(NAK 부재), 송신기는 계속 헛수고를 하고 최종 파일은 엉망진창이 된다. 통신의 신뢰성을 100%로 끌어올리기 위해서는 기계들끼리 "잘 받았냐?" "아니, 다시 줘"라고 대화할 수 있는 자동 반복 요청 (ARQ, Automatic Repeat reQuest) 시스템이 절대적으로 필요했고, 이를 구현하기 위해 약속된 최소한의 단어가 바로 저 4개의 제어 문자다.
💡 비유: 군대의 무전 통신 규율과 완벽히 일치한다.
- ENQ: "본부, 본부, 여기는 알파. 들리는가? 오버."
- ACK: "여기는 본부, 아주 잘 들린다. 말하라. 오버." (본 내용 수신 후) "복명복창, 정확히 접수했다. 오버."
- NAK: "지직.. 잡음이 심하다. 방금 한 말 다시 반복하라. 오버."
- EOT: "이상, 상황 보고 끝. 통신 끝."
제어 문자를 활용한 완벽한 통신 흐름 시각화:

  ┌─────────────────────────────────────────────────────────┐
  │        ENQ / ACK / NAK / EOT 를 이용한 에러 복구(ARQ) 메커니즘     │
  ├─────────────────────────────────────────────────────────┤
  │                                                         │
  │  [송신기 (Tx)]                          [수신기 (Rx)]      │
  │                                                         │
  │  1. ENQ (통신 연결 좀 하자!) ────────────────▶             │
  │                         ◀──────────────── ACK (응 쏴봐!)  │
  │                                                         │
  │  2. Data 블록 1 ──────────────────────────▶             │
  │                         ◀──────────────── ACK (잘 받았어) │
  │                                                         │
  │  3. Data 블록 2 ──⚡(잡음에 맞아 깨짐!)──X──▶ (수신기 CRC 에러 감지)│
  │                         ◀──────────────── NAK (깨졌어! 다시!) │
  │                                                         │
  │  4. Data 블록 2 (재전송!) ─────────────────▶             │
  │                         ◀──────────────── ACK (이제 완벽해) │
  │                                                         │
  │  5. EOT (나 더 보낼 거 없어. 끊는다) ─────────▶ (링크 해제 및 종료)│
  └─────────────────────────────────────────────────────────┘

[다이어그램 해설] 이 단순한 핑퐁(Ping-Pong) 게임이 현대 네트워크 신뢰성의 전부다. 데이터가 노이즈 벼락을 맞아 깨지는 것(3번)은 하드웨어의 숙명이다. 중요한 것은 깨졌을 때 수신기가 침묵하지 않고 즉시 NAK를 날려 송신기의 멱살을 잡고 **재전송(Retransmission)**을 시키는 논리적 흐름이다. 이 ENQ-ACK-NAK 릴레이 덕분에, 아무리 노이즈가 심한 태평양 해저를 건너도 내 카카오톡 메시지가 글자 하나 틀리지 않고 100% 무결하게 도착하는 기적이 완성된다.

📢 섹션 요약 비유: 친구한테 전화로 전화번호를 불러줄 때, "준비됐어?(ENQ)", "응(ACK)", "010-1234(Data)", "어?(NAK)", "다시, 010-1234(재전송)", "응, 적었어(ACK)", "이제 끊을게(EOT)" 하는 인간의 가장 상식적인 대화 확인 절차를 기계어로 번역해 놓은 것입니다.

Ⅱ. 아키텍처 및 핵심 원리 (Deep Dive)

1. Stop-and-Wait ARQ (정지-대기 방식)

이 제어 문자 4개를 조합하여 만든 가장 원시적이고 튼튼한 에러 복구 아키텍처다.

동작 원리: 송신기는 데이터 블록을 1개 딱 쏘고 나면, 자체 타이머(Timer)를 켜고 무조건 **동작을 정지(Stop)한 채 대기(Wait)**한다.
분기점 1 (ACK 도착): 수신기가 데이터의 CRC(에러 검출)를 돌려보고 정상이면 ACK를 보낸다. 송신기는 이를 받고 다음 블록을 쏜다.
분기점 2 (NAK 도착): 데이터가 깨졌으면 NAK를 보낸다. 송신기는 버퍼에 보관해 둔 방금 전 블록을 꺼내 묻지도 따지지도 않고 재전송한다.
분기점 3 (타임아웃, ACK/NAK 유실): 가다가 데이터가 아예 증발하거나, 수신기가 보낸 ACK가 증발해버리면 송신기는 무한정 기다리게 된다. 이를 막기 위해 타이머가 만료되면 억지로 방금 데이터를 한 번 더 재전송한다.
한계: 하나 쏘고 대답을 기다려야 하므로, 태평양 횡단처럼 전파 지연(RTT)이 긴 곳에서는 대역폭 효율(Throughput)이 5% 밑으로 처참하게 박살 난다.

2. 제어 문자의 계층적 진화 (ASCII $\rightarrow$ Flag/Header)

과거 BSC 프로토콜 시절에는 정말로 아스키코드 0x06이라는 8비트 '문자'를 선로에 쏴서 ACK를 표현했다. 하지만 이런 문자 기반 제어는 투명성 문제(데이터 안에 ACK 문자와 똑같은 비트열이 있으면 오작동)를 낳았다.

현대의 HDLC(L2)나 TCP(L4)에서는 더 이상 특정 문자를 통째로 쓰지 않는다.
대신 패킷의 헤더(Header) 안에 아주 얇은 1비트짜리 플래그(Flag) 비트를 만들어 상태를 통제한다.
예: TCP 헤더 안에는 ACK 플래그 (1 bit), SYN 플래그 (ENQ 역할, 1 bit), FIN 플래그 (EOT 역할, 1 bit)가 존재한다.
즉, 과거 1바이트씩 낭비하던 통신 제어 문자 철학이, 현대에는 헤더 안의 1비트 스위치로 극도로 압축되어 본질적인 영생을 누리고 있는 것이다.

Ⅲ. 융합 비교 및 다각도 분석

비교 1: 각 계층별 제어 문자(기능)의 투영과 진화

원시 제어 문자 (BSC, L2)	목적 / 의미	현대 TCP/IP (L4 계층)의 대응 요소	현대 HTTP (L7 계층)의 대응 요소
ENQ (Enquiry)	연결 수립 요청	SYN (Synchronize) 패킷 발송	클라이언트의 `GET / HTTP/1.1` 요청
ACK (Acknowledge)	정상 수신 확인	ACK 플래그 (Acknowledgment Number)	`HTTP 200 OK` 정상 응답 코드
NAK (Negative ACK)	오류 발생 재전송 요구	(NAK 대신) 중복 ACK (Dup ACK) 연달아 3번 송신	`HTTP 400/500` 번대 에러 코드 리턴
EOT (End of Trans)	통신 완전 종료	FIN (Finish) 또는 RST (Reset) 패킷	`Connection: close` 헤더 처리

통찰: 통신 기술이 50년간 발전하면서 하드웨어와 포맷은 100번 넘게 바뀌었지만, "ENQ로 묻고, ACK로 확인하고, NAK로 고치며, EOT로 헤어지는" 이 4단 논리 구조만큼은 단 1비트도 변하지 않고 전 네트워크 스택을 관통하고 있다.

과목 융합 관점

컴퓨터구조 (CA): 컴퓨터 마더보드 내부에서 CPU와 주변 기기(PCIe, USB) 간의 통신에서도 동일한 프로토콜이 돈다. CPU가 그래픽카드에 메모리를 쓰라고 데이터를 던질 때, PCIe 컨트롤러 하드웨어 레벨에서 ACK(수신 완료)나 NAK(버퍼 풀) 패킷을 초당 수십억 번씩 주고받으며 전기적 찰나의 데이터 유실을 막아낸다.
알고리즘 (비잔틴 장군 문제): 분산 시스템에서 양쪽이 서로의 ACK를 100% 확신할 수 없다는 '두 장군 문제(Two Generals Problem)'가 있다. 내가 보낸 데이터에 대한 ACK가 왔는데, "상대방은 자기가 보낸 ACK가 나한테 잘 도착했다는 걸 어떻게 알지?"라는 무한 루프의 딜레마. 이를 현실적으로 끊어내기 위해 TCP는 3번만 악수하는(3-Way Handshake, SYN $\rightarrow$ SYN/ACK $\rightarrow$ ACK) 타협적인 알고리즘으로 지구상 통신을 통일했다.
📢 섹션 요약 비유: 이 4개의 문자는 인간 세상의 "안녕하세요(ENQ)", "네 알겠습니다(ACK)", "뭐라고요?(NAK)", "안녕히 계세요(EOT)"라는 대화의 4대 필수 요소와 같습니다. 언어가 한국어에서 영어로, 수화로 바뀌어도 저 네 가지 의미를 빼놓고는 소통 자체가 불가능합니다.

Ⅳ. 실무 적용 및 기술사적 판단

실무 시나리오

시나리오 — 데이터센터 간 대용량 데이터 복제 시 지연 폭발 (Stop-and-Wait의 한계): 과거 프레임 릴레이나 구형 X.25 망을 이용해 서울에서 부산으로 1GB 데이터를 전송하는데 속도가 1Mbps도 안 나온다. 회선 대역폭은 100Mbps로 남아돈다. [해결책] 1개의 데이터 블록을 보내고 1개의 ACK를 무조건 기다려야만 다음 블록을 쏘는 고전적 정지-대기(Stop-and-Wait ARQ) 방식의 치명적 낭비 때문이다. 부산까지 빛이 다녀오는 시간(RTT)이 10ms라면, 1초에 기껏해야 100개의 ACK밖에 못 받는다. 즉, 대역폭이 100기가라도 1초에 100블록 이상을 물리적으로 전송할 수 없다. 엔지니어는 이를 타파하기 위해 ACK를 받기 전에 프레임을 10개, 100개씩 연속으로 와르르 쏟아내는 Go-Back-N 이나 Selective Repeat 같은 슬라이딩 윈도우(Sliding Window) 알고리즘을 지원하는 현대적 스택(TCP 윈도우 스케일링)으로 장비와 프로토콜을 전면 튜닝해야 한다.
시나리오 — TCP 재전송 폭풍(Retransmission Storm) 및 서버 패닉 진단: AWS 클라우드의 웹 서버 CPU가 갑자기 100%를 치면서 서비스가 마비되었다. Wireshark로 패킷을 캡처해 보니 클라이언트 쪽으로 똑같은 순서 번호의 Dup ACK(중복 ACK)가 수만 개씩 찍히고 있다. [해결책] 현대판 NAK 현상인 Fast Retransmit (빠른 재전송) 루프에 빠진 상태다. 중간 라우터나 무선망 환경에서 특정 패킷(예: 3번 패킷)이 계속 유실되자, 클라이언트는 "3번 못 받았어! 3번 못 받았어!"라며 계속 동일한 ACK(3번 내놓으라는 뜻의 NAK 역할)를 서버로 난사한 것이다. 서버 커널은 이 빗발치는 재전송 요구에 응답하느라 패킷을 계속 다시 만들며 CPU를 탕진했다. 실무자는 방화벽의 MTU 단편화 문제나 스위치 버퍼 드롭 등 중간 물리/링크 구간에서 패킷을 찢어 먹는 근본적인 L1/L2 병목을 제거해야 서버의 L4 TCP 패닉을 잠재울 수 있다.

신뢰성 있는 통신망에서 에러율 증가 및 ACK 병목을 분석하는 의사결정 흐름은 다음과 같다.

  ┌───────────────────────────────────────────────────────────────────┐
  │         네트워크 속도 저하 시 ACK/재전송 병목 진단 및 해결 플로우           │
  ├───────────────────────────────────────────────────────────────────┤
  │                                                                   │
  │   [회선은 빵빵한데 파일 전송 속도가 극도로 느리고 애플리케이션 지연 호소]            │
  │                │                                                  │
  │                ▼                                                  │
  │      Wireshark 캡처 시, 검은색(또는 빨간색)의 TCP Retransmission 패킷이 많은가?│
  │          ├─ 예 ─────▶ [물리적 에러 발생으로 NAK(Dup ACK)가 터져 나오는 상태] │
  │          │                     │                                  │
  │          │                     └─▶ [조치: 케이블 불량 점검, 광 모듈 감쇠 해결] │
  │          │                                                        │
  │          └─ 아니오 (재전송은 전혀 없고 패킷은 정상적으로 예쁘게 넘어감)           │
  │                │                                                  │
  │                ▼                                                  │
  │      재전송은 없는데, 송신 측이 패킷 몇 개만 보내고 ACK가 올 때까지 놀고 있는가?   │
  │          ├─ 예 ─────▶ [전형적인 윈도우 사이즈 미스매치 (Stop-and-Wait 증후군)]│
  │          │                     │                                  │
  │          │                     └─▶ [조치: TCP Window Scaling 켜서 한 방에 많이 쏘게 튜닝]│
  │          │                                                        │
  │          └─ 아니오 ──▶ [네트워크 정상. 수신 측 디스크 I/O 나 애플리케이션 병목 의심]│
  └───────────────────────────────────────────────────────────────────┘

[다이어그램 해설] "느리다"는 현상을 ACK 관점에서 해부하는 마스터키다. 패킷 캡처를 떴을 때 '재전송(Retransmission)'이 뜬다는 건 데이터가 가다 깨져서 계속 NAK를 맞고 다시 쏘느라 느리다는 뜻이다(물리적 에러). 반면 에러는 한 개도 없는데 느리다면? 그건 송신기가 한 개 쏘고 ACK 기다리느라 시간을 낭비하는 멍청한 로직(윈도우 크기 작음)으로 돌고 있다는 완벽한 증거다(논리적 오버헤드). 두 가지는 처방전이 180도 다르다.

도입 체크리스트

기술적: 사물인터넷(IoT) 센서망(MQTT 등) 설계 시, 센서가 배터리를 아끼기 위해 매번 서버의 ACK를 기다리지 않고 데이터만 툭 던지고(QoS 0) 바로 깊은 수면(Deep Sleep)에 들어가도록, NAK-재전송 오버헤드를 의도적으로 제거한 무결성 타협(Fire-and-Forget) 아키텍처를 적용했는가?
운영·보안적: 방화벽(FW) 룰 세팅 시, 불법 스캐너(nmap)가 살아있는 서버를 찾기 위해 SYN(ENQ 역할) 패킷만 무작위로 난사하고 ACK를 주지 않아 서버 메모리를 고갈시키는 SYN Flooding 공격을 방어하기 위한 SYN Cookie 등의 커널 튜닝이 적용되어 있는가?

안티패턴

UDP 망에서 무지성 ACK 로직 직접 구현: 영상 스트리밍을 실시간으로 빠르게 쏘기 위해 오버헤드가 없는 UDP 프로토콜을 선택해 놓고, 정작 개발자가 애플리케이션 단(L7)에서 패킷이 갈 때마다 "잘 받았어?" 하고 커스텀 ACK를 쏘고 못 받으면 재전송하는 코드를 직접 짜넣는 미친 짓. 이는 UDP를 쓰면서 TCP의 멍청한 Stop-and-Wait를 직접 구현한 최악의 안티패턴이다. 에러가 나면 과감히 버리고 다음 프레임을 보여주는 것이 UDP 생태계의 철학이다.
📢 섹션 요약 비유: 택배(데이터)를 보낼 때마다 기사님이 고객한테 일일이 "잘 받으셨나요?(ENQ)" 묻고 사인(ACK)을 받는 건 다이아몬드(금융/파일) 배송엔 필수지만, 매일 아침 문 앞에 던지고 가는 우유 배달(스트리밍)에 사인을 받겠다고 기사님이 문 앞을 지키고 있으면 우유는 다 썩어버립니다.

Ⅴ. 기대효과 및 결론

정량/정성 기대효과

최적화 지점	단순 송신 (ACK/NAK 부재, UDP형)	4대 제어문자 기반 ARQ 도입 (TCP형)	아키텍처적 진화 효과
신뢰성(Reliability)	노이즈 발생 시 데이터 영구 손상	에러 시 NAK 쳐서 100% 원본 복원	금융, 파일 다운로드의 무결점(Error-free) 통신 완성
흐름 제어	수신기 버퍼 터지며 패킷 몽땅 드롭	ACK 응답 타이밍으로 속도 밸런스 조율	과부하로 인한 네트워크 붕괴(Congestion) 선제 차단
연결 관리	상대가 죽었는지 살았는지 모름	ENQ/EOT로 상대방 생사 및 점유권 관리	예측 가능하고 통제된 세션(Session) 유지 달성

미래 전망

SACK (Selective Acknowledgment)의 극대화: 과거엔 100개의 데이터 중 50번 하나가 깨져서 NAK가 오면 50번부터 100번까지 무식하게 다 다시 보냈다(Go-Back-N). 최신 통신망에서는 수신기가 "나머지는 다 잘 받았고 딱 50번 하나만 구멍 났어(SACK)"라고 정밀하게 짚어주어 송신기가 50번 하나만 핀포인트로 재전송하게 만드는 극한의 효율성 최적화가 모든 모바일망(LTE/5G)과 TCP 표준에 장착되었다.
AI 기반 선제적 오류 복구 (FEC의 역습): 통신 거리가 지구-화성 수준으로 엄청나게 멀어지면, 왕복 20분이 걸리는 우주에서 NAK를 치고 재전송(ARQ)을 받는 건 사실상 불가능하다. 이런 심우주 통신(Deep Space)에서는 ACK/NAK 철학을 버리고, 아예 보낼 때부터 인공지능이 "우주 노이즈 때문에 30%는 깨질 테니, 복구용 퍼즐(FEC)을 왕창 섞어 한 방에 쏘자"며 수신기가 묻지도 따지지도 않고 스스로 깨진 패킷을 살려내는 구조로 패러다임이 옮겨가고 있다.

참고 표준

TCP (Transmission Control Protocol, RFC 793): OSI 4계층 전송 계층의 황제. 데이터(Payload) 앞에 붙는 헤더 내부에 SYN, ACK, FIN, RST 비트 플래그를 두어 과거 BSC 통신 제어 문자의 철학을 인터넷 세상에 완벽히 이식한 프로토콜.
HDLC 프레임 (REJ / SREJ): 비트 동기방식 L2 규격에서 수신기가 에러를 감지했을 때 송신기에게 재전송을 요구하는 제어 프레임(Reject, Selective Reject)으로 과거 NAK의 역할을 하드웨어적으로 승계한 규격.

"ENQ, ACK, NAK, EOT." 이 네 단어는 차가운 기계 덩어리들에게 부여된 **'소통의 영혼'**이다. 맹목적으로 전기를 쏟아붓기만 하던 더미(Dummy) 장비들은 이 제어 문자들을 통해 비로소 서로의 안부를 묻고(ENQ), 수고를 칭찬하며(ACK), 실수를 질책하고 바로잡으며(NAK), 예의 바르게 이별하는(EOT) 지능적 생태계를 이루게 되었다. 가장 단순한 이 4박자 리듬은, 반세기가 지나 광케이블과 5G 전파가 하늘을 뒤덮은 지금도 전 세계 모든 소프트웨어와 하드웨어의 가장 깊숙한 커널 안에서 1초에 수십억 번씩 핑퐁을 치며 거대한 인터넷을 무너지지 않게 받치고 있는 굳건한 주춧돌이다.

  ┌──────────────────────────────────────────────────────────────────┐
  │         에러 복구와 신뢰성 통제를 위한 통신 제어 진화 로드맵          │
  ├──────────────────────────────────────────────────────────────────┤
  │                                                                  │
  │   1막 (문자 기반의 핑퐁)        2막 (헤더 플래그와 윈도우)       3막 (초정밀 복구/우회) │
  │   │                       │                      │               │
  │   ▼                       ▼                      ▼               │
  │ [BSC 제어문자 4총사]     →  [TCP 플래그 / Sliding Window] → [SACK / QUIC (UDP 기반)]│
  │   │                       │                      │               │
  │   ├─ 1개 쏘고 1개 기다림(느림) ├─ 헤더 1비트로 압축, 연속 발사  ├─ 깨진 1개만 딱 찝어서 고침 │
  │   ├─ 데이터 투명성 훼손 한계   ├─ 오류 시 Go-Back-N 무식 재전송 ├─ 지연 0초, 패킷 앞뒤 종속성 파괴│
  │   └─ "문자로 대화하며 조심조심" └─ "플래그만 띄우고 와르르 쏟아내자" └─ "ACK 기다리는 시간마저 아깝다"│
  └──────────────────────────────────────────────────────────────────┘

[다이어그램 해설] 상대방이 잘 받았는지 챙기는 기술의 발전사다. 1막 옛날에는 조심스럽게 박스 1개 보낼 때마다 전보(ACK 문자)를 쳐서 확인받느라 속도가 안 났다. 2막 인터넷 시대엔 박스를 수만 개 연속으로 쏟아부으면서, 송장 귀퉁이에 작은 체크 표시(ACK 플래그)만 쓱 보고 넘기는 고속화(슬라이딩 윈도우)를 달성했다. 지금의 3막(QUIC)에 와서는, 중간에 박스 1개가 깨져도 뒤에 오는 멀쩡한 박스들을 멈추게 하지 않고 깨진 놈만 핀셋으로 골라 다시 가져오라(SACK)는 극강의 효율성 최적화에 도달했다.

📢 섹션 요약 비유: 옛날엔 편지 1장 쓰고 답장(ACK) 올 때까지 한 달을 멍하니 기다렸다면, 지금은 매일 100장씩 미친 듯이 편지를 쏟아내면서 친구가 "50번째 편지 글씨가 번졌어(NAK)!"라고 카톡 하나 틱 보내면 50번째 편지만 쓱 다시 복사해서 보내주는(SACK) 스마트한 소통의 진화입니다.

📌 관련 개념 맵 (Knowledge Graph)

개념 명칭	관계 및 시너지 설명
ARQ (자동 반복 요청)	수신측이 에러를 발견하면 NAK를 날리고, 송신측이 알아서 다시 보내는 통신계의 자기 주도적 에러 복구 시스템 전체를 칭한다.
슬라이딩 윈도우 (Sliding Window)	매번 ACK를 기다리는 정지-대기(Stop-and-Wait)의 지옥 같은 속도 저하를 박살 내고, ACK 없이도 윈도우 룸(여유 공간)만큼 냅다 패킷을 쏟아붓는 현대 고속 통신의 심장이다.
3-Way Handshake	TCP가 연결을 맺을 때 ENQ/ACK 철학을 발전시켜, SYN $\rightarrow$ SYN+ACK $\rightarrow$ ACK 의 3단 악수를 통해 양쪽 모두 전송 준비가 100% 완료되었음을 우주적으로 보증하는 절차.
SACK (선택적 확인 응답)	중간에 구멍 난 패킷이 있을 때 무식하게 그 이후 데이터를 전부 다시 보내는 게 아니라, 딱 잃어버린 그 패킷 1개만 NAK를 쳐서 핀포인트로 재전송받는 L4 고급 기술.
FCS / CRC (오류 검출)	수신기가 방금 받은 데이터가 썩었는지 안 썩었는지 알아야 NAK를 칠 수 있다. 이때 프레임 꼬리에 달린 CRC 수학 코드를 계산해 에러 여부를 100% 확신하는 L2 탐지 장치다.

👶 어린이를 위한 3줄 비유 설명

친구한테 긴 전화번호를 불러줄 때, 그냥 다다다다 말하면 친구가 놓칠 수 있으니까 "준비됐어?(ENQ)" 하고 묻는 게 통신의 시작이에요.
친구가 "응, 말해!(ACK)" 하면 번호를 부르고, 친구가 못 들었으면 "다시 말해줘!(NAK)"라고 해서 내가 번호를 다시 불러주는 똑똑한 대화법이죠.
이 4개의 핑퐁 대화가 없었다면, 컴퓨터는 내가 카카오톡 사진을 제대로 받았는지 확인도 안 하고 혼자 허공에 데이터를 날려버리는 바보가 됐을 거예요!