TCP-IP крупным планом
Поток данных с использованием
Рисунок 19.4 Поток данных с использованием rlogin между slip и vangogh.cs.berkeley.edu.
Первое, на что необходимо обратить внимание, на рисунках 19.3 и 19.4, то, что нет задержанных ACK от slip к vangogh. Это происходит потому, что в данном случае данные всегда готовы к отправке, перед тем как истечет таймер задержанного ACK.
Необходимо обратить внимание на различные размеры данных, которые отправляются слева направо: 1, 1, 2, 1, 2, 2, 3, 1 и 3 байта. Это объясняется тем что, что клиент собирает данные, которые необходимо послать, однако не посылает их, пока на ранее отправленные данные не приходит подтверждение. С использованием алгоритма Нагла с помощью девяти сегментов (а не 16) было отправлено 16 байт. Обработка сегментов 14 и 15 противоречит алгоритму Нагла, необходимо посмотреть на номера последовательности, чтобы определить, что произошло в действительности. Сегмент 14 это отклик на ACK, полученный в сегменте 12, так как подтвержденный номер последовательности равен 54. Однако перед тем как этот сегмент данных отправлен клиентом, от сервера прибывает сегмент 13. Сегмент 15 содержит подтверждение (ACK) на сегмент 13, номер последовательности 56. Таким образом, клиент игнорировал алгоритм Нагла, так как мы видим два последовательных сегмента данных, посланных от клиента к серверу.
Также на рисунке 19.4 необходимо обратить внимание на то, что существует один задержанный ACK, передаваемый однако от сервера к клиенту (сегмент 12). Мы предположили, что это задержанный ACK, потому что он не содержит данных. Сервер скорее всего был занят в этот момент времени, поэтому сервер Rlogin не мог отправить эхо символ, перед тем как истек таймер задержанного ACK.
И в заключение, обратимся к размеру данных и номерам последовательности в последних двух сегментах. Клиент посылает 3 байта данных (с номерами 18, 19 и 20), затем сервер подтверждает эти 3 байта (ACK 21 в последнем сегменте), однако посылает назад только один байт (с номером 59). Здесь происходит следующее: TCP сервер подтверждает 3 байта данных за один раз, однако эхо этих 3-х байт не будет готово к отправке назад, пока их не сгенерирует сервер Rlogin. Это показывает на то, что TCP может подтвердить принятые данные, до того как приложение считало и обработало эти данные. TCP подтверждение просто означает, что TCP корректно получил данные. Определить, что процесс сервера не считал эти 3 байта данных можно благодаря тому, что объявленный размер окна в последнем сегменте равен 8189, а не 8192.
