TCP의 에러 감지는 완벽하지 않을 수도 있다?

신뢰성 있는 통신을 보장하는 TCP에 사실 허점이 있다면 믿으시겠습니까? 이번 글에서는 TCP에서 에러 감지를 하는 방법에 대해 알아보도록 하겠습니다.

참고 자료는 다음과 같습니다.

• Can a TCP checksum fail to detect an error? If yes, how is this dealt with? - Stack Overflow
• TCP Checksum Errors: Issues and Workarounds - Baeldung
• Transmission control protocol - Wikipedia

TCP에서 에러를 감지하는 방법

TCP(transmission controll protocol)은 header의 checksum을 이용하여 패킷이 손상되었는지 확인할 수 있습니다.

송신 측에서는 checksum 알고리즘을 이용하여 계산한 값을 TCP checksum header에 넣어 송신합니다. 그리고 수신 측에서도 checksum 알고리즘을 이용하여 계산한 값이 header의 값과 일치하는지 확인합니다.

Checksum 계산의 흐름은 다음과 같습니다.

1. header와 data를 16비트로 분할한다.
2. 분할한 값에 대한 비트 합을 구한다.
3. 비트 합에 대한 1의 보수를 취한다.

이후 계산한 값이 header의 checksum 값과 동일하지 않다면 패킷이 손상되었다고 판단합니다.

checksum의 함정

패킷이라는 것은 header와 payload를 포함한 전체 데이터를 말합니다. 이 말은 즉슨, payload가 손상되듯 header 또한 손상될 수 있는데요. 따라서 checksum 값 또한 손상될 수 있습니다.

손상된 범위에 따라 다음과 같이 경우의 수를 나열할 수 있습니다.

• checksum은 손상되지 않았으나 payload가 손상된 경우
• checksum이 손상되었고 payload도 손상된 경우

첫 번째 경우에는 checksum 값이 다르기 때문에 에러를 감지할 수 있습니다. 그러나 두 번째 경우는 checksum이 어떻게 손상됬는지에 따라 예상 외의 결과를 낳을 수 있습니다.

손상된 checksum이 우연의 일치로 일치한다면?

checksum의 값은 16비트로 65,536가지의 값을 표현할 수 있습니다. 이러한 특징 때문에 손상된 checksum의 값이 우연의 일치로 같을 수도 있습니다.

상위 레이어에서 해결한다

이러한 문제는 충분히 발생할 수 있고 실제로도 발생하고 있습니다. 그렇다면 이를 어떻게 해결할 수 있을까요?

정답은 바로 TCP를 사용하는 상위 레이어, 즉 application layer에서 이에 대해 해결하는 것입니다. Application layer의 대표적인 프로토콜인 HTTP에서는 CRC를 이용하여 TCP의 checksum 충돌 현상을 해결합니다.

마무리하며

이번 글에서는 TCP의 error dection에 사용되는 checksum의 빈 틈에 대해 알아보았습니다. TCP가 reliable trasmission을 보장한다고 하지만 한계점은 존재했었고 이를 해결하기 위해 HTTP와 같은 상위 layer에서 이를 보완한다는 점이 인상깊었습니다. 이번 글이 익숙함으로부터 경계심을 기를 수 있길 바랍니다. 😁