
Серверу необходимо квитировать полученные Q байт данных, но у сервера НЕТ
собственных полезных данных для отправки клиенту. Следовательно, серверу придется отправлять
клиенту сегмент, в котором после заголовка TCP не будет полезных данных, а в самом заголовке
TCP будет передана квитанция на полученные Q байт. Как сервер формирует сегмент с флагом
ACK (так как поле Acknowledged Number должно быть интерпретировано, более того, ради этого
поля и отправляется этот сегмент) и указывает в поле Acknowledged Number значение равное
X+1+Q. Действительно, до получения последнего сегмента сервер ожидал от сервера байта номер
X+1, теперь, получив Q байт (с номерами от X+1 до X+1+Q-1) сервер уже станет ожидать от
клиента байта номер X+1+Q, что и отмечает в поле Acknowledged Number. По сути, это и есть
квитанция на полученные Q байт – клиент, получив данный сегмент увидит, что сервер ожидает
байт с номером X+1+Q и сделает вывод о том, что ВСЕ предыдущие байты сервером получены.
Какое значение необходимо установить серверу в поле Sequence Number? Сервер обещал клиенту,
что первый байт, который сервер пришлет, будет иметь номер Y+1, ранее сервер не передавал
клиенту данных, следовательно по прежнему первый байт, который сервер пришлет клиенту будет
иметь номер Y+1. Более того, в данном (4-ом) сегменте сервер НЕ передает клиенту данных,
поэтому по крайней мере в следующем сегменте Sequence Number сервера будет равен Y+1. Итак,
сегмент 5 – это чистая квитанция, полезных данных в ней нем нет, но не потому, что невозможно
послать сегмент, который бы был одновременно квитанцией и носителем полезных данных, просто
в данном примере у сервера НЕТ данных для отправки клиенту. Пусть затем клиент снова
нуждается в передаче порции данных длиной W серверу, рассмотрим, как должен сформировать
свой сегмент клиент. Последний байт, переданный клиентом для сервера имел номер X+1+Q-1,
следовательно сервер ожидает от клиента байт номер X+1+Q, о чем сервер и уведомил клиента в