다른 사람들이 지적했듯이, 전송 계층에서 체크섬을 계산하기 전에 이미 발생하는 손상, 스트림을 가로 채서 수정하는 MITM (데이터도 포함)과 같이 전송 계층의 모든 체크섬이 도울 수없는 데이터 손상 가능성이 많이 있습니다. 수신 측에서 체크섬을 검증 한 후 발생하는 손상 등

이러한 다른 모든 가능성을 무시하고 TCP 체크섬 자체의 특성과 데이터 무결성 유효성 검사 측면에서 실제로 수행하는 작업에 중점을두면 이 체크섬의 속성이 오류 감지 측면에서 포괄적 인 것은 아닙니다. 이 체크섬 알고리즘이 선택된 방식은 시간과 함께 속도에 대한 요구 사항을 반영합니다 (1970 년대 후반).

TCP 체크섬 을 계산 하는 방법 은 다음과 같습니다.

체크섬 : 16 비트

체크섬 필드는 헤더와 텍스트에있는 모든 16 비트 단어의 보수 합계의 16 비트 보수입니다. 세그먼트에 체크섬 할 홀수의 헤더 및 텍스트 옥텟이 포함 된 경우 마지막 옥텟은 오른쪽에 0으로 채워져 체크섬 목적으로 16 비트 워드를 형성합니다. 패드는 세그먼트의 일부로 전송되지 않습니다. 체크섬을 계산하는 동안 체크섬 필드 자체는 0으로 바뀝니다.

이는 데이터를 합산 할 때 균형을 유지하는 손상이 감지되지 않음을 의미합니다. 데이터가 손상 될 수있는 여러 가지 범주의 손상이 있지만 사소한 예로 16 비트 단어의 순서를 변경하면 항상 감지되지 않습니다.

실제로 많은 전형적인 오류를 포착하지만 무결성을 보장 하지는 않습니다 . 또한 로컬 링크를 통한 전송에 대해서만 L2 계층이 무결성 검사 (예 : 이더넷 프레임의 CRC32)를 수행하는 방법을 통해 도움이되며, 손상된 데이터의 경우가 TCP 스택으로 전달되지도 않습니다.

강력한 해시 또는 바람직하게는 암호화 서명을 사용하여 데이터를 검증하는 것은 데이터 무결성을 보장하는 측면에서 완전히 다른 수준에 있습니다. 이 둘은 간신히 비교 될 수 있습니다.

답변