Краткие выводы

Перед тем как два процесса смогут обмениваться данными с использованием TCP, они должны установить соединение между собой. Когда работа между ними закончена, соединение должно быть разорвано. В этой главе детально рассмотрено то, как устанавливается соединение с использованием "трехразового рукопожатия" и как оно разрывается с использованием четырех сегментов.

Мы использовали tcpdump, чтобы показать все поля в заголовке TCP. Мы также посмотрели, как установленное соединение может быть прервано по тайм-ауту, как сбрасывается соединение, что происходит с полуоткрытым соединением и как TCP предоставляет полузакрытый режим, одновременное открытие и одновременное закрытие.

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

TCP соединения уникально идентифицируются 4 параметрами: локальным IP адресом, локальным номером порта, удаленным IP адресом и удаленным номером порта. Если соединение разрывается, одна сторона все равно должна помнить об этом соединении, в этом случае мы говорим что работает режим TIME_WAIT. Правило гласит, что эта сторона может осуществить активное открытие, войдя в этот режим, после того как истекло удвоенное время MSL, принятое для данной реализации.

Упражнения

В разделе "Установление и разрыв соединения" мы сказали, что исходный номер последовательности (ISN) обычно устанавливается в 1 и увеличивается на 64000 каждые полсекунды и каждый раз когда осуществляется активное открытие. Это означает, что младшие три цифры в ISN всегда будут 001. Однако на рисунке 18.3 эти младшие три цифры для каждого направления равны 521. Как это произошло?
На рисунке 18.15 мы напечатали 12 символов, но видели что TCP послал 13 байт. На рисунке 18.16 мы напечатали 8 символов, однако TCP отправил 10 байт. Почему в первом случае был добавлен 1 байт, а во втором 2 байта?
В чем заключается отличие между полуоткрытым соединением и полузакрытым соединением?
Если мы стартуем программу sock в качестве сервера, а затем прервем ее работу (при этом к ней не было подключено ни одного клиента), мы можем немедленно перестартовать сервер. Это означает, что он не будет находиться в состоянии ожидания 2MSL. Объясните это в терминах диаграммы изменения состояний.
В разделе "Диаграмма состояний передачи TCP" мы показали, что клиент не может повторно использовать тот же самый локальный номер порта, пока порт является частью соединения в состоянии ожидания 2MSL. Однако, если мы запустим программу sock дважды подряд в качестве клиента, подсоединяясь к серверу времени, мы можем использовать тот же самый локальный номер порта. В дополнение, мы можем создать новое соединение, которое будет в состоянии ожидания 2MSL. Как это происходит?

sun % sock -v bsdi daytime
connected on 140.252.13.33.1163 to 140.252.13.35.13
Wed Jul 7 07:54:51 1993
connection closed by peer

sun % sock -v -b1163 bsdi daytime повторное использование того же номера локального порта
connected on 140.252.13.33.1163 to 140.252.13.35.13
Wed Jul 7 07:55:01 1993
connection closed by peer
В конце раздела "Диаграмма состояний передачи TCP", когда мы описывали состояние FIN_WAIT_2, мы указали, что большинство реализаций переводит соединение из этого состояния в состояние CLOSED, если приложение осуществило полное закрытие (не наполовину закрытый) примерно через 11 минут. Если другая сторона (в состоянии CLOSE_WAIT) ждет 12 минут перед осуществлением закрытия (отправка своего FIN), что его TCP получит в ответ на FIN?

Какая сторона в телефонном разговоре осуществляет активное открытие, а какая осуществляет пассивное открытие? Возможно ли одновременное открытие? Возможно ли одновременное закрытие?
На рисунке 18.6 мы не видели ARP запрос или ARP отклик. Однако аппаратный адрес хоста svr4 должен быть в ARP кэше bsdi. Что изменится на этом рисунке, если этот пункт в ARP кэше отсутствует?
Объясните следующий вывод команды tcpdump. Сравните его с рисунком 18.13.

1 0.0 solaris.32990 > bsdi.discard: S 40140288:40140288 (0)
win 8760 <mss 1460>
2 0.003295 (0.0033) bsdi.discard > solaris.32990: S 4208081409:4208081409 (0)
ack 40140289 win 4096
<mss 1024>
3 0.419991 (0.4167) solaris.32990 > bsdi.discard: P 1:257 (256) ack 1 win 9216
4 0.449852 (0.0299) solaris.32990 > bsdi.discard: F 257:257 (0) ack 1 win 9216
5 0.451965 (0.0021) bsdi.discard > solaris.32990: . ack 258 win 3840
6 0.464569 (0.0126) bsdi.discard > solaris.32990: F 1:1 (0) ack 258 win 4096
7 0.720031 (0.2555) solaris.32990 > bsdi.discard: . ack 2 win 9216
Почему бы серверу на рисунке 18.4 не скомбинировать ACK на FIN клиента со своим собственным FIN, уменьшив тем самым количество сегментов до трех?
На рисунке 18.16, почему номер последовательности RST равен 26368002?
Скажите, основан ли запрос TCP к канальному уровню о его MTU на принципе разбиения на уровни?
Представьте, что на рисунке 14.16 каждый DNS запрос отправляется с использованием TCP вместо UDP. Скажите, сколькими пакетами будет осуществлен обмен?
Если MSL равно 120 секунд, через какое максимальное время система может инициировать новое соединение, а затем осуществить активное закрытие?
Прочитайте RFC 793, чтобы посмотреть что произойдет, когда конечная точка, находящаяся в режиме TIME_WAIT, получает повторный FIN, который помещает ее в это состояние.
Прочитайте RFC 793, чтобы посмотреть что произойдет, когда конечная точка, которая находится в состоянии TIME_WAIT, получает RST.
Прочитайте требования к хостам Host Requirements RFC, чтобы получить определение полудуплексного TCP закрытия.
На рисунке 1.8 мы показали, что входящие TCP сегменты демультиплексируются на основе номера порта назначения TCP. Правильно ли это?

На главную

Содержание раздела