Почему данные буфера TCP на стороне приемника

В большинстве описаний функции TCP PUSH упоминается, что функция PUSH требует от отправителя не сразу отправлять данные (не дожидаясь заполнения буфера), но также требует, чтобы данные были перенесены в приемное приложение на стороне приемника, без буферизации.

Что я не понимаю, почему данные буфера TCP на принимающей стороне вообще? В конце концов, сегменты TCP перемещаются по IP-датаграммам, которые обрабатываются целиком (т.е. уровень IP обеспечивает только весь сегмент для уровня TCP после выполнения любой необходимой повторной сборки фрагментов IP-дейтаграммы, которые переносят любой данный сегмент). Затем, почему ожидающий приемный уровень TCP будет ждать доставки этих данных в приложение? Один случай может заключаться в том, что приложение не читало данные в этот момент времени. Но тогда, если это так, то принудительное нажатие данных на приложение в любом случае невозможно. Таким образом, мой вопрос заключается в том, почему функция PUSH должна диктовать что-либо о поведении приемника? Учитывая, что приложение считывает данные во время поступления сегмента, этот сегмент должен в любой момент быть доставлен в приложение сразу.

Кто-нибудь может помочь решить мои сомнения?

Ответ 1

TCP должен буферизовать полученные данные, потому что он не знает, когда приложение будет фактически читать данные, и оно сообщило отправителю, что оно хочет получить (доступное "окно" ). Все эти данные сохраняются в "окне приема" до тех пор, пока приложение не закроется.

Как только приложение считывает данные, оно отбрасывает данные из окна приема и увеличивает размер отчета, отправленного отправителю, с последующим ACK. Если это окно не существует, отправитель должен будет отложить отправку до тех пор, пока получатель не сообщит ему, что он не сможет сделать, пока приложение не опубликует. Это добавило бы полную задержку задержек с задержкой в оба конца для каждого прочитанного вызова, если не больше.

Большинство современных реализаций также используют этот буфер для хранения полученных пакетов не по порядку, чтобы отправитель мог повторно передавать только потерянные, а не все после него.

Бит PSH обычно не используется . Да, реализация отправляет его, но обычно это не изменяет поведение принимающей стороны.

Ответ 2

Обратите внимание, что, хотя другие комментарии верны (бит PSH вообще не влияет на поведение приложения в большинстве реализаций), он все еще используется TCP для определения поведения ACK. В частности, когда бит PSH установлен, принимающий TCP будет немедленно подавать ACK вместо использования задержанных ACK. Незначительные детали;)