TCP\IP-1

 1. Поле «номер протокола» IP-заголовка

4.18 Могут ли TCP и UDP использовать один и тот же порт? |Кодирование Кобаяши

 

 Причина 3: Избегайте траты ресурсов

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

Причины отказа от использования «двустороннего рукопожатия» и «четырехстороннего рукопожатия»:

• «Два рукопожатия»: невозможно предотвратить установление исторических соединений, что приведет к пустой трате ресурсов с обеих сторон, и невозможно надежно синхронизировать серийные номера обеих сторон;
• «Четырехстороннее рукопожатие»: трехстороннее рукопожатие теоретически устанавливает наименее надежное соединение, поэтому нет необходимости использовать большее время связи . ( Трех достаточно, почему четыре?)

Почему начальный порядковый номер должен быть разным при каждом установлении TCP-соединения?

Для этого есть две основные причины:

• Для предотвращения получения исторических пакетов при следующем соединении с той же четверкой ( основной аспект );
• В целях безопасности не позволяйте хакерам подделывать TCP-сообщения с тем же серийным номером, которые могут быть получены другой стороной;

• Клиент и сервер устанавливают TCP-соединение, и пакет данных, отправленный клиентом, блокируется сетью, а затем пакет данных повторно передается после тайм-аута.В это время серверное устройство выключается и перезагружается, а соединение, установленное с клиентом, пропадает, поэтому при получении пакета данных от клиента будет отправлено сообщение RST .
• Сразу после этого клиент устанавливает соединение с сервером тем же квадроциклом, что и предыдущее соединение ;
• После того, как новое соединение установлено, пакет данных, заблокированный сетью в предыдущем соединении, просто поступает на сервер, и порядковый номер пакета данных оказывается в пределах окна приема сервера, поэтому пакет данных будет получен. сервером в обычном режиме, это может привести к путанице данных.
• Можно видеть, что если порядковые номера инициализации клиента и сервера одинаковы каждый раз, когда устанавливается соединение, легко может возникнуть проблема, заключающаяся в том, что историческое сообщение будет получено следующим соединением с тем же четверным числом .

Если серийные номера инициализации клиента и сервера «различны» каждый раз при установлении соединения, существует высокая вероятность того, что серийные номера исторических сообщений «не находятся» в окне приема другой стороны, что в значительной степени позволяет избежать исторические сообщения, такие как следующее изображение:

Наоборот, если порядковые номера инициализации клиента и сервера «одинаковы» каждый раз, когда устанавливается соединение, существует высокая вероятность того, что порядковые номера исторических пакетов просто «только что вошли» в окно приема другая сторона, что приводит к обновлению исторических пакетов Соединение успешно получено.

Следовательно, каждый порядковый номер инициализации отличается в значительной степени, что может в значительной степени предотвратить получение исторического сообщения при следующем соединении с тем же четверным.Обратите внимание, что это в значительной степени, но не полностью исключено ( поскольку порядковый номер будет иметь проблема переноса. , поэтому необходимо использовать механизм временных меток для оценки исторических пакетов . Подробнее см. в статье: Как TCP избегает исторических пакетов? (открывается в новом окне) ) .

Как случайным образом генерируется начальный серийный номер ISN? (Только сейчас я все еще думал о том, как был сгенерирован первоначальный серийный номер, просто чтобы иметь возможность ответить...)

Это все еще немного хлопотно. .

В RFC793 упоминается алгоритм случайной генерации серийного номера ISN инициализации: ISN = M + F(localhost, localport, remotehost, remoteport).

• M это таймер, который увеличивается на 1 каждые 4 микросекунды.
• F Это алгоритм хеширования, который генерирует случайное значение на основе IP-адреса источника, IP-адреса назначения, исходного порта и порта назначения. Чтобы гарантировать, что алгоритм Hash не может быть легко рассчитан извне, лучше использовать алгоритм MD5.

Поскольку уровень IP будет фрагментирован, зачем уровню TCP по-прежнему нужен MSS?

• MTU: максимальная длина сетевого пакета , обычно в  1500 байтах в Ethernet;
• MSS: после удаления заголовков IP и TCP максимальная длина данных TCP, которые могут быть размещены в сетевом пакете;

Первое рукопожатие потеряно, что происходит?

Когда клиент хочет установить TCP-соединение с сервером, он первым делом отправляет сообщение SYN, а затем входит в состояние  SYN_SENT .

После этого, если клиенту не удается получить сообщение SYN-ACK от сервера (второе рукопожатие), он запускает механизм «повторной передачи тайм-аута» для повторной передачи сообщения SYN, а повторно переданное сообщение SYN. ​​Серийные номера совпадают .

В разных версиях операционной системы может быть разный таймаут, у кого-то 1 секунда, у кого-то 3 секунды.Этот тайм-аут жестко запрограммирован в ядре.Если вы хотите изменить его, вам нужно перекомпилировать ядро, что хлопотно.