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 от  партнера