Существует ли такое понятие, как «типичное» или «фактическое» значение по умолчанию для размера MTU?

При написании сетевого программного обеспечения существует ли стандарт по умолчанию, типичный или иным образом де-факто стандарт размера MTU, о котором мне следует знать? Если так, то, что это?
Имеет размер MTU 1500 (как предлагается здесь: Какой максимальный MTU поддерживается стандартами DSL) хорошее практическое правило?
Кроме того, я не задумываюсь над этой проблемой? Это одна из тех вещей, которые люди считать важно при написании сетевого программного обеспечения, но в практическом, реальном мире, не имеет большого значения, поскольку TCP позаботится о деталях за вас?

Я спрашиваю здесь, а не на StackOverflow, потому что мне нужна точка зрения системного администратора, когда дело доходит до актуальных вопросов поддержки, связанных с размером MTU.

ОБНОВИТЬ: Основываясь на некоторых отзывах и начальных ответах, я немного сужаю фокус:

Приложение, которое я пишу, будет обмениваться данными между рабочими столами / серверами через WAN-соединение.
Это типичное программное обеспечение для настольных ПК / серверов (т.е. не для мобильных устройств), и хотя возможно, что привязанный ноутбук будет использовать это программное обеспечение в мобильной сети, меня это не волнует.
Он даже не будет пытаться иметь дело с каким-либо уровнем стека TCP, кроме уровня приложения, для оптимизации.
Издержки VPN могут быть исключены в рамках этого вопроса

networking mtu

Это довольно широкий вопрос.

1500 - обычное дело? Да, безусловно, для традиционного Ethernet в локальной сети.

Можно ли предполагать 1500 или ожидать его для любого соединения? Нет. Мобильные пользователи, которые подключаются из любого места, могут иметь разные MTU в разное время.

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

VPN-соединения в целом, скорее всего, будут иметь уменьшенный MTU, и они повсюду. Это может быть 1410, 1390, 1362 или другое любопытное число.

Если вас интересует максимальный размер полезной нагрузки для данного TCP-соединения, вы, вероятно, сочтете согласованный максимальный размер сегмента более значимым. Для стандартного LAN-соединения 1500 MTU это обычно будет 1460, но в итоге он должен отражать размер, приемлемый для обоих хостов.

Для соединений, которые проходят через множество переходов, может быть нереалистично ожидать, что все переходы будут иметь «стандартный» MTU или что MTU может быть надежно определен. См. Обсуждение Path MTU Discovery по теме.

Обнаружение MTU пути
http://en.wikipedia.org/wiki/Path_MTU_discovery#Problems_with_PMTUD

Обход проблем с обнаружением MTU пути с помощью ограничения MSS
http://lartc.org/howto/lartc.cookbook.mtu-mss.html

Вам не следует заботиться о MTU, поскольку сетевой стек позаботится о необходимых оптимизациях. Если вы используете TCP, стек может использовать методы для расчета максимального размера сегмента (MSS), который, в свою очередь, в идеале будет приводить к пакетам, размер которых меньше самого низкого MTU в пути. Один из них является Открытие PMTU.

В общем, вам не следует пытаться перехитрить стек - многоуровневая архитектура TCP / IP использует абстракции по уважительным причинам. Если у вас нет лучших, вам следует оставить функции сегментации и фрагментации там, где они были задуманы.

Как писали другие, не существует "безопасного MTU", который можно было бы принять, кроме минимально определенного MTU для IP-пакетов - что составляет 68 байт и поэтому имеет довольно низкую практическую ценность из-за огромных накладных расходов.

Типичные проблемы поддержки из-за ограничений MTU в основном двоякие:

ненужная фрагментация и, как следствие, более высокие накладные расходы протокола и более высокие задержки для протоколов пинг-понга
прерванные передачи из-за невежественных администраторов брандмауэра, фильтрующих ICMP и, таким образом, нарушая обнаружение PMTU на пути

Оба фактора - не то, с чем вам следует иметь дело в приложении.

В ответ на:

На этот вопрос сложно ответить, потому что всегда будет сводка того, что влияет на производительность программного обеспечения, когда оно касается сети. MTU, оптимизированный для связи порта коммутатора с портом коммутатора, не принесет вам много пользы по каналу WAN или, что еще хуже, VPN, который будет добавлять накладные расходы и потенциально фрагментацию.
Да, но вы не можете контролировать исходящие потоки во всех ситуациях!
Да, вы слишком много думаете, действительно ли вы пишете программное обеспечение, которое вернется на уровень 2 для оптимизации? Если бы вы писали, скажем ... драйвер iSCSI, тогда да, вам, вероятно, придется подумать о таких вещах.

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

MTU по умолчанию - 1500, что является максимальным значением, используемым в Интернете. При туннелировании трафика могут потребоваться меньшие значения. Большая часть трафика будет фрагментирована и повторно собрана, если он превышает максимально доступный MTU на канале. Только если установлена опция DNF (Do Not Fragment), пакеты должны быть меньше или равны MTU. Локальный MTU устанавливает верхний предел используемого MTU.
Поскольку у большинства хостов MTU составляет 1500. Это хорошее значение по умолчанию. Некоторые интернет-провайдеры предоставляют ссылки с использованием протоколов туннелирования, таких как PPPOE, которые обеспечивают меньший MTU. Точно так же многие ранние последователи IPv6 могут использовать туннель и иметь меньший MTU.
Скорее всего, вы слишком задумались над проблемой. В реальном мире вы не можете полагаться на локальный MTU для определения MTU ссылки. Вы также не можете рассчитывать на то, что это статическое значение. При необходимости пакеты будут фрагментированы и повторно собраны. Например, размер блока для NFS обычно составляет 4096, и они обычно отправляются фрагментами.