Время от времени ошибки с вычислением контрольной суммы происходят. Они могут быть вызваны проблемами передачи и необходимы для выявления подобного рода проблем. В каждом семействе протоколов существует механизм для восстановления после ошибок в контрольной сумме. Как они могут обрабатываться в TCP/IP?

Чтобы определить действие протокола, корректное в данной ситуации, мы обратились к авторитетным источникам - документам RFC. RFC 791, Internet Protocol, снабдил нас информацией о вычислении контрольной суммы, но лучшим источником для данной конкретной проблемы стал документ RFC 1122 , Requirements for Internet Hosts - Communication Layers (Требования к узлам сети Интернет - уровни передачи данных), за авторством Р. Брейдена (R. Braden). Этот документ содержит две отсылки к действиям, которые должны быть предприняты. Следующие выдержки взяты со стра- ницы 29 документа RFC 1122:

В нижеследующем тексте в определенных случаях в отношении полученной дейтаграммы используется выражение «молча удалить». Это означает, что дейтаграмма удаляется без дополнительной обработки, а узел не посылает какие-либо ICMP-сообщения об ошибках (см. раздел 3.2.2) в результате... ...Узел ОБЯЗАН проверять правильность контрольной суммы заголовка IP для каждой полученной дейтаграммы и молча удалять все дейтаграммы с невер- ными контрольными суммами.

Следовательно, получив пакет с неверной контрольной суммой, система не должна ничего с ним делать. Пакет следует удалить, а затем ожидать поступления следующего пакета. Система не должна отвечать сообщением об ошибке. Система не может ответить на неверную контрольную сумму 1Р-заголовка, поскольку не может определить, откуда в действительности поступил пакет. Если под сомнением контрольная сумма заголовка, как определить, что верны адреса в заголовке? А если нет уверенности относительно источника пакета, как можно на него ответить?

IP полагается на протоколы верхних уровней в восстановлении после таких ошибок. Если используется TCP (как было в данном случае), источник TCP в конечном итоге замечает, что получатель не подтвердил доставку сегмента, и посылает сегмент заново. Если используется UDP, приложение-источник отвечает за восстановление после ошибки. Ни в том ни в другом случае восстановление не зависит от сообщения об ошибке, генерируемого получателем. Итак, получив неверную контрольную сумму, центральная система должна была просто удалить испорченный пакет. Мы уведомили о проблеме разработчиков, и, следует отметить, они прислали нам поправку к программному обеспечению в пределах двух недель. Более того, поправка замечательно работала!

Не все проблемы разрешаются так же прямолинейно. Однако методика анализа не зависит от того, какова проблема.