체크섬

데이터가 전송 중 손상되지 않았는지 확인하기 위한 검증 값.

원리 — 인터넷 체크섬

TCP/UDP/IP가 쓰는 방식은 1의 보수 합이다.

• ① 데이터를 16비트 단위로 자른다

• ② 전부 더한다 (자리올림이 생기면 하위에 되더한다)

• ③ 결과를 뒤집는다(1의 보수) → 이것이 체크섬

• ④ 헤더에 넣어 보낸다

• 수신 측

• ⑤ 체크섬을 포함해 전부 더한다

• ⑥ 결과가 전부 1(0xFFFF)이면 정상

왜 뒤집어서 넣나 — 그러면 수신 측은 "합이 0xFFFF인가"만 보면 되어 계산이 단순해진다. 하드웨어로 구현하기 쉽다.

무엇을 잡고 무엇을 못 잡나

✅ 1비트 오류 — 확실히 잡는다 ✅ 대부분의 무작위 오류

❌ 두 비트가 서로 상쇄되는 오류

• 0x0001 → 0x0002 로 바뀌고
• 0x0002 → 0x0001 로 바뀌면 합이 같다 → 통과한다 ❌ 16비트 워드의 순서가 바뀐 경우 (덧셈은 교환법칙이 성립)

약 65,536분의 1 확률로 손상을 놓친다. 가볍고 빠른 대신 검출력이 낮은 것이다.

계층마다 다른 검증

• 링크 계층 (이더넷) — : CRC-32 ← 훨씬 강력
• IP 계층 — : 헤더만 체크섬 (데이터는 검사 안 함)
• 전송 계층 (TCP/UDP) : 헤더 + 데이터 체크섬
• 애플리케이션 — : 필요하면 SHA-256 등

IP는 헤더만 검사한다. 라우터가 매 홉마다 TTL을 줄이며 체크섬을 다시 계산해야 하는데, 데이터까지 검사하면 너무 느리기 때문이다. 데이터 검증은 종단(TCP)에 맡긴다 — 종단 간 원칙의 예다.

CRC와의 차이

연속된 여러 비트가 한꺼번에 깨지는 것(버스트 오류) 이 실제 전송에서 흔한데, CRC는 이것을 훨씬 잘 잡는다.

해시와 혼동하지 말 것

• 체크섬·CRC — : 우연한 손상 검출용. 의도적 위조는 못 막는다
  • 공격자가 데이터를 바꾸고 체크섬도 다시 계산하면 끝

암호학적 해시(SHA-256) : 같은 해시를 만드는 다른 데이터를 찾기 어렵다

• MAC / 서명 — : 키를 모르면 유효한 값을 만들 수 없다 → 위조 방지

"무결성"이라는 같은 단어를 쓰지만 위협 모델이 다르다. 체크섬은 노이즈를 막고, MAC은 공격자를 막는다.

UDP 체크섬은 선택 사항이었다

IPv4에서 UDP 체크섬은 0으로 두면 "검사 안 함" 을 의미했다. 성능을 위해 생략할 수 있었던 것이다.

IPv6에서는 필수가 됐다. IPv6 헤더에는 체크섬이 아예 없어서 (라우터 부담을 줄이려고 제거했다) 상위 계층이 반드시 검사해야 하기 때문이다.

실무에서 만나는 곳

# 파일 무결성 확인 (다운로드 검증)
sha256sum file.tar.gz

# 네트워크 패킷 분석에서
tcpdump -v   # "bad cksum" 이 보이면 손상 또는 체크섬 오프로드

체크섬 오프로드 — 최신 NIC은 체크섬 계산을 하드웨어가 한다. 그래서 tcpdump로 송신 패킷을 보면 체크섬이 아직 계산 전이라 "bad cksum"으로 보이는 경우가 있다. 실제 오류가 아니다.