ACK-сообщения необходимы для установления связи TCP. Тем не менее, я прочитал несколько статей, объясняющих еще один вид сообщений ACK при фактической передаче данных; отправителю необходимо дождаться сообщения ACK от получателя, которое указывает следующий байт для отправки. Это верно? Может кто-нибудь объяснить, почему мы называем это также сообщениями ACK?Понимание роли сообщений ACK после TCP Handshaking
TCP - это протокол, ориентированный на соединение по IP-сети без подключения. Следовательно, чтобы иметь представление о соединении, каждый конец должен подтвердить данные, полученные с другого конца. Это достигается посредством сообщений ACK (или сообщений подтверждения). Чтобы TCP работал правильно, каждый переданный байт должен быть подтвержден (только тогда он будет протоколом, ориентированным на соединение). Однако обратите внимание, что это не означает, что на каждый отправленный пакет должно быть отправлено сообщение с подтверждением. Необходимо «в конечном итоге» все подтвержденные данные. Ответ на каждый отправленный пакет сильно повлияет на пропускную способность, поэтому обычно отправитель может продолжать отправлять сообщения, сохраняя определенное количество данных, не подтвержденных. Это называется TCP Window. Это больше, чем простое объяснение, и большинство сложностей TCP - это попытка сохранить такое окно, чтобы пропускная способность (в байтах/сек была максимизирована). В Интернете может быть много ресурсов. Я настоятельно рекомендую прочитать «TCP/IP Illustrated - том 1» для лучшего понимания IP-сетей и TCP.
Спасибо для вашего ответа –
Слишком много ошибок здесь. Протокол, ориентированный на соединение, определяется путем запуска и завершения рукопожатия, а не наличием ACK в протоколе. Существуют протоколы NACK. Не каждый байт явно подтвержден в TCP. – EJP
Запуск и завершение - это «явное установление соединения». Вы хотите сказать - достаточно ли запускать/завершать рукопожатие и нет необходимости в промежуточном ACK для протокола, ориентированного на соединение? Кроме того, я не говорю, что протокол NACK не может существовать, это очень частный случай TCP, поэтому достаточно основанного на ACK механизма. Пожалуйста, прочитайте внимательно - я сказал - «в конце концов» каждый отправленный байт должен быть подтвержден, так где же ошибка? – gabhijit
Да, это правильно. ACK для подтверждения. – EJP
TCP гарантирует, что сообщения передаются, следовательно, ACK, который является противоположным UDP. – Marco
@Marco TCP имеет байты, а не сообщения, и гарантирует, что байты будут доставлены неповрежденными, и в порядке, и один раз или вообще не будут. Никакая сила на небе или земле не может гарантировать доставку. – EJP