
Number значения, на единицу большего, нежели было установлено в поле Sequence Number в
предыдущем сегменте, полученном от партнера, несмотря на то, что того «байта» который таким
образом «квитируется» не передавалось. Итак, если узел послал сегмент с флагами FIN, ACK, то в
ответ он получает сегмент с флагом ACK и увеличенным на единицу (относительно переданного в
прошлом сегменте значения поля Sequence Number) значением в поле Acknowledged Number. После
этого TCP соединение переходит в полузакрытое состояние – станция А не имеет права передавать
данные станции В, в то же время станция В имеет право передавать данные для станции А, и
станция А должна квитировать полученные данные. После того, как и приложение на станции В
решает, что ему больше не нужно передавать данные приложению на станции А, станция В
отправляет свой сегмент с флагами FIN, ACK, на что ожидает от станции А сегмента с флагом ACK
и значением поля Acknowledged Number увеличенным на единицу относительно переданного в
сегменте с флагами FIN, ACK значения поля Sequence Number. Только после того, как КАЖДАЯ
сторона TCP соединения независимо уведомила другую сторону о закрытии своего
полусоединения, подтвердила указанным выше способом закрытие полусоединения другой
стороны, TCP соединение может считаться закрытым. Ясно, что в общем случае TCP соединение
закрывается с помощью четырех сегментов. Важно понять, почему НЕ объединяются сегмент,
квитирующий закрытие соединения партнера и собственные сегмент с флагом FIN – дело в том, что
закрытие одного полусоединения не предполагает автоматически закрытия второго
полусоединения, решение о квитировании сегмента с флагом FIN партнера принимает стек TCP/IP,
а решение о закрытии собственного полусоединения принимает прикладной процесс. Рассмотрим
пример, в котором продемонстрируем последовательное закрытие обоих полусоединений.
Пусть в некоторый момент времени станция А, участник TCP соединения, приняла решение
о необходимости разрыва соединения, еще раз подчеркнем, что такое решение может принять
любая сторона соединения, не зависимо от того, кто являлся сервером или клиентом в процессе
открытия соединения. При этом положим, что в ходе соединения возникла ситуация, когда станция
А ожидает от станции В очередного байта номер Y, а станция В ожидает от станции А байта номер
X. Станция А отправляет станции В сегмент с флагами FIN, ACK, уведомляя ее тем самым о
желании закрыть свою половинку соединения, при это, разумеется, в соответствии с
вышесказанным, поле Sequence Number этого сегмента равно X, а поле Acknowledged Number этого
сегмента равно Y. Станция В должна подтвердить получение сегмента с флагом FIN для станции А,
для этого станция В формирует сегмент номер 2, в котором устанавливает в поле Acknowledged
Number значение X+1, подтверждая тем самым получение сегмента с флагом FIN, но этот сегмент
еще не означает, что станция В так же собирается закрыть свое полусоединение. После обмена
двумя первыми сегментами TCP соединение может существовать еще сколь угодно длительное
время, станция А при этом не имеет права передавать данные, станция В, напротив, может
передавать данные для станции, которые станция А должна квитировать. Однако, часто
приложения не стремятся удерживать полузакрытое соединение, и получив FIN от партнера