Каким будет payload tcp сегмента если ethernet mtu задан в 9001 байт

Обновлено: 07.07.2024

IP фрагментация и обратная сборка

Проблемы с IP фрагментацией

При работе с IP фрагментацией следует помнить о нескольких особенностях.

Обход IP фрагментации путем использования TCP MSS.

TCP Maximum Segment Size (MSS) определяет максимальный размер данных, который машина готова получить через один TCP сегмент. Сам TCP сегмент инкапсулируется в IP пакет. Значение MSS передается в заголовке TCP SYN при установлении соединения между двумя узлами (через механизм трехэтапного установления соединения). Обе стороны соединения передают значение своего MSS. В отличие от популярного заблуждения, принимаемое значение MSS не несет характер переговоров. Отправляющий хост обязан ограничить размер своих исходящих TCP сегментов значением равным или меньшим значению, сообщенному ему принимающим хостом.
Значение MSS выбирается таким образом, чтобы предотвратить IP фрагментацию. Механизм работы MSS следующий: при создании TCP соединения, машина определяет размер буфера исходящего интерфейса и MTU этого интерфейса. Дальше эти два числа сравниваются и выбирается наименьшее. Тут следует оговориться, что за MTU выбирается число по формуле MTU минус 40 байт, для учета TCP и IP заголовков. Затем выбранное число сравнивается с размером MSS, переданным принимающей стороной, и снова выберется наименьшее значение.
Пример работы MSS:

Таким образом MSS на обеих сторонах установлено равным 1460 байтам, это наиболее частая ситуация.
В данном примере IP фрагментация не будет происходить, поскольку в процессе установления TCP соединения, размер TCP сегментов был взят с расчетом на вмещение в MTU низлежащей сети. Однако, если IP пакет пойдет через сети с меньшим MTU, то может потребоваться фрагментация.

Что такое PMTUD?

Проблемы PMTUD

В процессе работы PMTUD могут произойти три проблемы:

На пограничном к отправителю маршрутизаторе установить политику снятия DF флага для всех исходящих пакетов. Это приведет к фрагментации больших IP пакетов.
На пограничном к отправителю маршрутизаторе установить политику указания MSS в исходящих SYN TCP сегментах. Установить MSS таким образом, чтобы один IP пакет вмещался в самый маленький MTU на всем пути следования.

С распространением различного вида туннелирования трафика проблема IP фрагментации стала более насущной. Из-за появления допольнительных заголовков размер IP пакета увеличивался и уже не влезал в MTU сети. Например, GRE добавляет 24 байта к пакету, что может привести к IP фрагментации из-за того, что MTU исходящего интерфейса не способно передать пакет целиком.

Что такое туннель?

Туннель представляет из себя виртуальный интерфейс, который позволяет инкапсулировать пассажирский пакет в транспортный протокол. Этот механизм используется в схемах инкапсуляции типа точка-точка.
Туннель состоит из следующих частей:

Пассажирский протокол (IP, IPX и пр.)
Несущий протокол (GRE, IP in IP)
Транспортный протокол (IP)

Инкапсуляция трафика при работе туннеля используется, в частности, для связи географически разнесенных сетей (VPN).

Роль маршрутизатора при работе PMTUD на концах туннеля

Маршрутизатор может играть две роли при работе PMTUD на концах туннеля

Общая последовательность действий маршрутизатора при работе с инкапсуляцией.

Чистый IPsec в туннельном режиме

Туннельный режим. В котором оригинальный IP пакет инкапсулируется целиком. В получившемся новом пакете в качестве адресов источника и назначения указываются точки IPsec туннеля. Туннельный режим используется только с юникастовым IP траффиком. Данный режим используется для организации VPN.
Транспортный режим. В этом режиме, только информация внутри оригинального пакета (payload) инкапсулируется, оставляя заголовок оригинального IP пакета. Данный режим используется в рамках одной сети, когда источник и назначение IPsec туннеля (пиры) совпадают с источником и назначением оригинального IP пакета. Также он используется, когда другой туннельный протокол сначала инкапсулирует оригинальный IP пакет, после чего IPsec используется для защиты получившегося туннельного пакета.

IPsec также поддерживает механизмы PMTUD и изменения флага DF у своих пакетов.
Пример.

Совместная работа GRE и IPsec

Домашнее задание к занятию "3.6. Компьютерные сети, лекция 1"

Необязательное задание: можно посмотреть целый фильм в консоли telnet towel.blinkenlights.nl :)

Узнайте о том, сколько действительно независимых (не пересекающихся) каналов есть в разделяемой среде WiFi при работе на 2.4 ГГц. Стандарты с полосой 5 ГГц более актуальны, но регламенты на 5 ГГц существенно различаются в разных странах, а так же не раз обновлялись. В качестве дополнительного вопроса вне зачета, попробуйте найти актуалый ответ и на этот вопрос.

Адрес канального уровня – MAC адрес – это 6 байт, первые 3 из которых называются OUI – Organizationally Unique Identifier или уникальный идентификатор организации. Какому производителю принадлежит MAC 38:f9:d3:55:55:79 ?

Каким будет payload TCP сегмента, если Ethernet MTU задан в 9001 байт, размер заголовков IPv4 – 20 байт, а TCP – 32 байта?

Может ли во флагах TCP одновременно быть установлены флаги SYN и FIN при штатном режиме работы сети? Почему да или нет?

ss -ula sport = :53 на хосте имеет следующий вывод:

Почему в State присутствует только UNCONN , и может ли там присутствовать, например, TIME-WAIT ?

Обладая знаниями о том, как штатным образом завершается соединение (FIN от инициатора, FIN-ACK от ответчика, ACK от инициатора), опишите в каких состояниях будет находиться TCP соединение в каждый момент времени на клиенте и на сервере при завершении. Схема переходов состояния соединения вам в этом поможет.

TCP порт – 16 битное число. Предположим, 2 находящихся в одной сети хоста устанавливают между собой соединения. Каким будет теоретическое максимальное число соединений, ограниченное только лишь параметрами L4, которое параллельно может установить клиент с одного IP адреса к серверу с одним IP адресом? Сколько соединений сможет обслужить сервер от одного клиента? А если клиентов больше одного?

Может ли сложиться ситуация, при которой большое число соединений TCP на хосте находятся в состоянии TIME-WAIT ? Если да, то является ли она хорошей или плохой? Подкрепите свой ответ пояснением той или иной оценки.

Чем особенно плоха фрагментация UDP относительно фрагментации TCP?

Если бы вы строили систему удаленного сбора логов, то есть систему, в которой несколько хостов отправяют на центральный узел генерируемые приложениями логи (предположим, что логи – текстовая информация), какой протокол транспортного уровня вы выбрали бы и почему? Проверьте ваше предположение самостоятельно, узнав о стандартном протоколе syslog.

Сколько портов TCP находится в состоянии прослушивания на вашей виртуальной машине с Ubuntu, и каким процессам они принадлежат?

Ответ:
прослушиваемых портов = 5 IPv4 + 8IPv6 Процессы соответсвенно: systemd,sshd,nginx

Какой ключ нужно добавить в tcpdump , чтобы он начал выводить не только заголовки, но и содержимое фреймов в текстовом виде? А в текстовом и шестнадцатиричном?

Попробуйте собрать дамп трафика с помощью tcpdump на основном интерфейсе вашей виртуальной машины и посмотреть его через tshark или Wireshark (можно ограничить число пакетов -c 100 ). Встретились ли вам какие-то установленные флаги Internet Protocol (не флаги TCP, а флаги IP)? Узнайте, какие флаги бывают. Как на самом деле называется стандарт Ethernet, фреймы которого попали в ваш дамп? Можно ли где-то в дампе увидеть OUI?

Скорость передачи данных зависит от сетевых и системных характеристик.

img1 Процесс передачи данных по сети

a) Буферы
Оригинальная конфигурация TCP ограничивает скорость передачи буфером (опция Window Size — «размер окна») и является полем размером в 2^16 байт (до 64 КБайт). Максимальная пропускная способность в данном случае:

Пример: У вас 100 мегабитное соединение к Интернету и до сервера задержка 100 мс.
Стандартным стеком TCP, максимальная скорость передачи данных не превысит 10 Мбит/сек
( 524288 бит / 0.1 сек = 5.24 Мбит/сек не смотря на то что у вас 100 мегабитный линк).

b) Bandwidth-delay product (BDP)
Производительность TCP в принципе не столько зависит от скорости канала, сколько от так называемом «bandwidth*delay product» или BDP (результат пропускная способность*задержка), который представляет собой число байт необходимых отправителю и получателю для максимального заполнения TCP соединения.
Проблемы производительности возникают в случаях так называемых «длинных и широких труб» (LFN «long fat network»), так как BDP в таком случае превышает размер окна TCP, тем самым ограничивая скорость передачи.

img2 Влияние задержки на максимальную пропускную способность TCP

Примером могут служить мобильный интернет или быстрый оптический линк.
Пример расчетов BDP:
a) широкополосный мобильный интернет: 10 Mb/s, 100 ms RTT
B×D = 10^7 b/s × 10^-1 s = 10^6 b, or 1 Mb / 125 kB
b) высокоскоростная наземной сеть: 1 Gb/s, 10 ms RTT
B×D = 10^9 b/s × 10^-2 s = 10^7 b, or 10 Mb / 1.25 MB

Рассчитать BDP можно тут.
”Размер окна” TCP должен превышать BDP для достижение максимальной нагрузки канала.

c) Protocol Overhead
По некоторым оценкам около 95% компьютеров мира подключены через технологию Ethernet.
Ethernet MTU (полезная нагрузка кадра Ethernet) = макс. 1500 bytes.
Если принять во внимание все заголовки Ethernet, IP, TCP, картина будет выглядеть так:

img3 Передача одного Ethernet кадра

Цифры указывают размер (в байтах) заголовка для определенного протокола.
IFG (Interframe gap) — обязательное межкадровое пространство.
Заголовки: preamble, frame delimiter, Ethernet header/FCS – 26 bytes, IFG – 12 bytes, IP header – 20 bytes, TCP header – 20 bytes.

Если исключить VLAN tagging, TCP timestamp и другие опциональные возможности, максимальная полезная нагрузка (Payload) TCP в сетях Ethernet будет:
Max TCP Payload= (MTU–TCP–IP) / (MTU+Ethernet+IFG) = (1500–40) / (1500+26+12) = 94.9 %

d) Задержка и потеря пакетов
Так как речь идет о надежной передачи информации, потеря пакетов в сети вынуждает TCP передавать повторно сегменты и влияет непосредственно на понижение скорости.
Зависимость скорости TCP в соотношении к потери пакетов, определяется формулой Mathis-а:

где: MSS (Maximum segment size) – максимальный размер сегмента TCP (MSS = MTU – packet headers=1460 bytes),
MTU — максимальный размер передаваемого блока нижнего уровня OSI (Ethernet MTU = 1500 bytes),
RTT — время двусторонней задержки (от одного конца к другому и назад, от англ. Round Trip Time)
Ploss — Loss probability (вероятность потерь).
Можно обратить внимание что формула не действительна с Ploss = 0. Это нормально, так как в реальном мире всегда есть потери пакетов.

img4 Влияние задержки и потеря пакетов на максимальную пропускную способность TCP

Большинство провайдеров не будет гарантировать потери менее 0.01% (1 пакет из 10`000).
Проверить статистику по протоколам можно командой “netstat –s”.

2) Оптимизация TCP

a) усовершенствования протокола
В связи с этим были разработаны расширения протокола, описанные в стандарте TCP Extensions for High Performance (RFC1323), которые призваны решить ограничения.
Среди них:
— TCP Window Scale Option: возможность увеличение Размера Окна до 2^30 (1 ГБайт),
— TCP selective acknowledgment (SACK) options: принимающая сторона указывает какие именно пакеты в потоке подтверждены (положительно или отрицательно) (RFC2018),
— TCP timestamps: улучшение замеров RTT (Round Trip Time Measurement — RTTM), предотвращение накладки порядковых чисел ACK (Prevention Against Wrapped Sequence numbers — PAWS),
— Path MTU discovery: определение максимального MTU на всем пути,
— Explicit Congestion Notification (ECN): указывает на перегрузку пути без сбрасывание пакетов (RFC3168).

Проверить текущие настройки TCP/IP компьютера можно здесь.

b) aдаптация oперационных систем
Несмотря на то что документ RFC1323 был опубликован в далеком 1992 году, в ОС-ы внедряли изменения не сразу.

OS Windows
Поддержка RFC1323 появилась начиная с Windows 2000 (XP, Server 2003) и для активации опции необходимо покрутить в реестре.
Системы Windows Server 2008, Vista, 7 включают новую реализацию стека протоколов TCP/IP, известную как стек протоколов TCP/IP нового поколения («Next Generation TCP/IP Stack»). Он спроектирован для того, чтобы обеспечивать сетевые технологии Windows на несколько лет вперед. Среди нововведений:
— aвтонастройка окна получения (Receive Window Auto-Tuning),
— compound TCP: решает проблему низкой производительности в сетях с высокой пропускной способностью с помощью нового алгоритма, вместо алгоритмов, использовавшихся на других платформах,
— усовершенствования для сред с высоким уровнем потерь и еще много чего.
Многие опции включены по умолчанию. Конфигурация через командную строку.

С подробными процедурами настройки для различных ОС (Windows XP, FreeBSD, Linux, Solaris, Mac OS X), можно ознакомится на сайте суперкомпьютерного центра Питтсбурга.

Примечание: Хотя через маршрутизаторы в основном проходит весь трафик (между разными сетями), отношение к оптимизации TCP имеют только косвенное (в некоторых случаях), так как работают на более нижнем уровне сетевой модели OSI и выполняют функцию определение оптимальных маршрутов и лишь доставку пакетов до назначения.

3) Измерения производительности стека TCP/IP

В сети существуют множество методов измерения скорости подключения к Интернету.
Здесь будет рассмотрен случай с использованием утилиты nuttcp («New TTCP»), так как она имеет несколько приятных преимуществ:
— простой и эффективный метод измерения пропускной способности канала через TCP или UDP,
— кроссплатформенная одно-файловая программа (CLI),
— возможность проверки эффективности локального стека TCP/IP (loopback),
— стабильная работа сервера (корректное завершения TCP сессий), без подвисаний и падений
(как в случае с iperf),
— работа клиента из NAT-а.

Немного истории: В 1980 году, Mike Muuss (автор ping-а) создал ttcp («Test TCP») — один из первых инструментов тестирования пропускной способности TCP. Многие изменения с тех пор были созданы в различных реализациях и с новыми возможностями. Nuttcp является одной из них. Последняя бета — апрель 2010.

Тестирования работает по схеме клиент-сервер.
Измеряется payload — полезная нагрузка (без заголовков).
Подключение по порту 5000. Передача данных — 5001 (и выше если указать многопоточный тест).

опции клиента:
-w128 — TCP receive window size = 128 KB
-r — receiving (прием, для клиента)
-F — устраняет возможные проблемы с соединением если вы в NAT-е
-i5 — показывать результат каждые 5 секунд
-T15 — длительность тестирования (15 секунд).

TX% и RX% являются загрузкой процессора на передатчике и приемнике.

Проверка производительности железа и стека TCP/IP ОС:
C:\> nuttcp.exe -w1m 127.0.0.1
205.0625 MB / 10.00 sec = 172.0189 Mbps 19 %TX 12 %RX

Примеры результатов:
— Intel Core 2 Duo (2 core) @ 1.6 GHz/ 1 GB RAM / Windows XP = 1300/1400 Mbps
— AMD Athlon X2 Dual-Core 4600 @ 2.4 GHz/ 2 GB RAM / Windows 7 = 2000/2100 Mbps
— Intel XEON X5650 (24 cores) @ 2.67GHz/ 8 GB RAM / FreeBSD = 16600/18000 Mbps

Проверяем Download (от сервера к клиенту):
C:\> nuttcp.exe -w128 -r -F –i5 -T15 server-ip
56.0166 MB / 5.00 sec = 93.9803 Mbps
56.0575 MB / 5.00 sec = 94.0489 Mbps
56.0338 MB / 5.00 sec = 94.0090 Mbps

168.2676 MB / 15.00 sec = 94.1020 Mbps 3 %TX 10 %RX

1371.1741 MB / 15.00 sec = 766.6703 Mbps 26 %TX 39 %RX 3153 host-retrans 0.29 msRTT

Проверяем Upload (от клиента к серверу):
C:\> nuttcp.exe -w128 –i5 -T15 server-ip
55.6250 MB / 5.00 sec = 93.3169 Mbps
55.8125 MB / 5.00 sec = 93.6562 Mbps
55.6875 MB / 5.00 sec = 93.4277 Mbps

167.2500 MB / 15.12 sec = 92.7664 Mbps 17 %TX 6 %RX

1305.3853 MB / 15.06 sec = 727.0077 Mbps 20 %TX 48 %RX 24478 host-retrans 0.29 msRTT

4) Вместо заключения

В процессе тестирования, нужно помнить что максимальная скорость отдельного TCP соединения определяется различными факторами:
— максимальная пропускная способность самого медленного участка пути,
— время между отправкой запроса и получением ответа (RTT),
— большинство задержек на больших расстояниях вызваны скоростью света в волокне (

200 км/мс),
— дополнительные задержки могут возникнуть в момент перегрузки сети или устройства (сервер, рутер, пк),
— автоматическое понижение скорости при обнаружении потерь пакетов (стандартный механизм TCP предотвращения перегрузок),
— отсутствие других негативных эффектов (минимальное количество ошибок битов на физическом уровне (Bit Error Rate<10^-8),
— исправность сетевой карты и корректная работа драйвера),
— один физический линк может нести множество одновременных TCP соединений,
— один хост может иметь несколько одновременных соединений, даже с тем же удаленным хостом (быстро проверить можно с TCPView или TCPEye).

Популярные speedtest-ы обычно работают в связке browser, flash + geo-локация до ближайшего доступного сервера, что создает:
— дополнительную нагрузку на локальную машину (ЦП, память) и сеть (заголовки WWW и т.п.),
— выбор сервера может быть не оптимальным,
— возможность ошибочных результатов.

И на последок, хотелось бы отметить часто встречаемые проблемы с низкой производительностью сети:
— узкое окно TCP (Window Size),
— несоответствие Ethernet Duplex,
— плохой сетевой кабель.

Я нашел пару объяснений [1][2] минимальный размер IP-пакета должен быть 64 байта. Я думаю, что объяснение в приведенных выше ссылках правильное. В этом случае, почему не минимальный размер" данных " фрейма Ethernet (64-20-20) = 24 bytes ?

может ли кто-нибудь объяснить это более ясно?

минимальный размер фрейма для Ethernet продиктован в 64 байтах (Как также описано в ваших ссылках).

в слое 4 (TCP или UDP) длина крышек ступиц 4 и это отслеживается в заголовке IP.
Это означает, что для UDP минимальное ожидаемое значение составляет 8 байт (для заголовка). И, для TCP это 20 байт (минимальный заголовок TCP).

часть вы, кажется, не хватает начинается теперь.
Пока локальные сети длина данных должна быть не менее 46 байт, длина IP не обязательно должна быть 46-20 байт. Это может быть намного меньше.

так, если бы у нас был 8 байт UDP пакетов данных, его длина IP будет 20+8 но длина полезной нагрузки Ethernet все равно будет 46 байт. Что происходит с 18 байт отверстие? Это мягкий, чтобы сделать кадр Ethernet на провод 64 байт (по причинам, которые вы уже знаете).

Итог: Что вы имеете в виду the application data size не имеет минимальных ожиданий, основанных на этом 64 требование к локальных сетей байта. The PAD компенсирует для всех разниц.

Короткий Ответ:
Минимальная длина части данных сегмента TCP равна нулю. Минимальная длина части данных UDP-дейтаграммы равна нулю.

Если стеку IP-адресов требуется передать в Ethernet дейтаграмму размером менее 46 байт, Ethernet дополняет ее 46 байтами, добавляя байты заполнения. У IP-заголовка есть свое собственное поле длины (как делают TCP и заголовки UDP), таким образом, те протоколы никогда не путаются и пытаются интерпретировать дополнение канального уровня как часть их собственную аппаратуру.

Дополнительная Информация:
Ethernet является лишь одним из многих, многих протоколов канального уровня, на которых может работать IP. Ethernet имеет 64 байт минимальная длина кадра для устаревших техническим причинам (так что "столкновения" могут быть надежно обнаружены на максимальный диаметр сети Ethernet, когда для Ethernet сетей локальные сети CSMA/CD и могли бы столкновения - современных сетях Ethernet коммутаторы используют везде и полный дуплекс на всех сегментах, так называемой CSMA/CD и столкновения в значительной степени ушли в прошлое).

потому что мы так часто используем IP через Ethernet, легко забыть, что Ethernet и IP-это две отдельные сетевые технологии, созданные двумя отдельными учреждениями. Ethernet, стандартизированный IEEE (институт инженеров по электротехнике и электронике), был разработан для обработки неизвестного количества сетевых протоколов (Уровень 3), кроме IP, и IP, созданный IETF (Internet Engineering Task Force), был предназначен для работы на неизвестном количество протоколов канала передачи данных (Уровень 2) помимо Ethernet. IP не изменяет свой минимальный или максимальный размер дейтаграммы только из-за одного популярного протокола канального уровня. Если протоколу канального уровня не нравится крошечная дейтаграмма, которую он получает, он должен дополнить ее. И в противоположном случае, если IP не нравится МТУ текущей ссылки на данные предложения, его фрагмент.

1,999 2 2 золотых знака 13 13 серебряных знаков 32 32 бронзовых знака

Затем, что по ip работает не только tcp, но и udp, и icmp. У каждого протокола свой предел.

А сети бывают не только ethernet.

Эталонная модель — это идеальная модель передачи данных. OSI помогает иллюстрировать зависимость одних протоколов от других, и кто кем погоняет, но она не может диктовать, как им функционировать.

MTU и модель OSI

В большинстве типов локальных и глобальных сетей определяется такое понятие как максимальный размер поля данных кадра или пакета, в которые должен инкапсулировать свой пакет протокол IP. Эту величину обычно называют максимальной единицей транспортировки - Maximum Transfer Unit, MTU. Сети Ethernet имеют значение MTU, равное 1500 байт, сети FDDI - 4096 байт, а сети Х.25 чаще всего работают с MTU в 128 байт.

MTU является характеристикой канального уровня модели OSI. Если IP хочет отослать датаграмму, которая больше чем MTU канального уровня, осуществляется фрагментация (fragmentation), при этом датаграмма разбивается на меньшие части (фрагменты). Каждый фрагмент должен быть меньше чем MTU.

Теоретически, максимальный размер IP-дейтаграммы составляет 65 535 байтов, что обусловлено 16-разрядным полем полной длины в IP-заголовке.

Вам пользователь @Smithson сообщил правильный ответ, ведь IP работает не только над Ethernet, в каждой сети свой размер.

Зачем нужен MTU?

Когда общаются два компьютера в одной и той же сети, важным является MTU для этой сети. Однако, когда общаются два компьютера в разных сетях, каждый промежуточный канал может иметь различные MTU. В данном случае важным является не MTU двух сетей, к которым подключены компьютеры, а наименьший MTU любого канала данных, находящегося между двумя компьютерами. Он называется транспортным MTU (path MTU).

Транспортный MTU между любыми двумя хостами может быть не постоянным. MTU зависит от загруженности канала на настоящий момент. Также он зависит от маршрута. Маршрут может быть несимметричным (маршрут от A до B может быть совсем не тем, что маршрут от B к A), поэтому MTU может быть неодинаков для этих двух направлений.

У протокола TCP есть MSS

Есть такое понятие, как максимальный Размер TCP Сегмента (MSS), который определяет максимальное количество данных, которые хост желает принимать в единственной TCP/IP датаграмме.

Мало того, эта TCP/IP датаграмма может быть фрагментирована в уровне IP.

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

Механизм работы MSS следующий: при создании TCP соединения, машина определяет размер буфера исходящего интерфейса и MTU этого интерфейса. Дальше эти два числа сравниваются и выбирается наименьшее. Тут следует оговориться, что за MTU выбирается число по формуле MTU минус 40 байт, для учета TCP и IP заголовков. Затем выбранное число сравнивается с размером MSS, переданным принимающей стороной, и снова выберется наименьшее значение. Пример работы MSS:

Машина А сравнивает размер своего буфера интерфейса (16 Кбайт) со значение MTU этого интерфейса (1500-40 = 1460 байт) и использует наименьшее число как MSS при отправке к машине B.
Машина B принимает значение MSS машины A (1460) и сравнивает его со значением MTU своего исходящего интерфейса (4462 — 40 = 4422 байт).
Машина B выбирает наименьшее из получившихся значений (1460) как значение MSS при отправке TCP сегментов к машине A.
Машина B сравнивает размер своего буфера интерфейса (8 Кбайт) со значение MTU этого интерфейса (4462-40 = 4422 байт) и использует наименьшее число как MSS при отправке к машине A.
Машина A принимает значение MSS машины B (4422) и сравнивает его со значение MTU своего исходящего интерфейса (1500 — 40 = 1460 байт).
Машина A выбирает наименьшее из получившихся значений (1460) как значение MSS при отправке TCP сегментов к машине B.

Таким образом MSS на обеих сторонах установлено равным 1460 байтам, это наиболее частая ситуация.

Например, tcp-сегмент при использовании технологии передачи ethernet2 может быть максимально 1500 байт

Проблемы начинаются где-то здесь. 1 500 — это вполне стандартный размер пакета (любого протокола сетевого уровня, не обязательно АйПи), который умещается в езернетный кадр. Длина сегмента ТиСиПи ещё меньше, вполне обычным значением является 1 460, как раз для того, чтобы конечный пакет (с заголовками ТиСиПи и АйПи), мог уложиться в 1 500 октетов. Стандартный размер, если не согласовано иное, и вовсе 536 (как указано в разделе 4.2.2.6 РФЦ 1122, жаль что нет перевода РФЦ 6691 (англ)).

В принципе, размер сегмента выбирается сетевым стеком ОС, как раз таки с учётом максимальных параметров передачи, потому как и в Езернет может пролазить 9 000 октетов, и не только Езернет бывает в этом мире.

идет разбиение на куски по 1500 байт на транспортном уровне, зачем указан размер 65535 байт, если передаваемые куски имеют размер 1500 байт?

Важно понимать, что вся матрёшка слоёв сетевого стека изначально задумана для жёсткого разделения решаемых в разных слоях вопросов и принципиально подразумевает независимость протоколов разного уровня. И при возникновении подобных вопросов, первое о чём имеет смысл задуматься, это что будет, если вместо протокола А на каком-то уровне будет использоваться неведомый протокол Б. Поэтому, теоретические ограничения на каждом из уровней свои и согласование реальных параметров идёт уже исходя из реальных условий. Например, для АйПи поверх Инфинибэнда типично ограничение по размеру пакета в 2 044 октета (размер сегмента ТиСиПи предлагаю посчитать самостоятельно).

Примером же практически естественного использования МТУ в 64К является интерфейс обратной петли, по умолчанию в Линуксах на нём именно такой МТУ (причём его до 2ГБ можно увеличивать! только это уже как раз бесполезно для рядовых протоколов верхних уровней), и именно на такие куски будет биться тисипишный поток, упаковываясь по дороге в айпишные пакетики (плюс-минус накладные расходы на заголовки).

Читайте также: