> Но я не вижу причины ограничиваться стандартным 1500.
Давай рассмотрим варианты. 1. У меня большое MTU, а с той стороны 1500 или меньше. Самый простой случай - устанавливается сессия с MTU 1500. 2. И у меня, и на том конце большое MTU. 2a. Хотя бы на одном из маршрутизаторов по пути MTU=1500 и включен tcp mss -> устанавливается сессия с MTU 1500. Случай редкий - при стандартном MTU обычно tcp mss не включают. 2b. Хотя бы на одном из маршрутизаторов по пути MTU=1500 и icmp needfrag проходит (через все наты). MTU уменьшается и сессия продолжается, имеем лишь небольшую задержку в начале сессии по сравнению со случаем стандартного MTU. 2с. На маршрутизаторе по пути MTU=1500, icmp needfrag от него где-то потерялось -> сессия не живёт. 2d. На маршрутизаторе по пути MTU=1500, icmp needfrag к источнику проходят, но роутинг асиметричный, оттуда к тебе большие пакеты проходят, а от тебя туда нет, и к тебе за нат icmp needfrag не доходят -> сессия виснет при первом объёмном post с твоей стороны. 2e. На всех маршрутизаторах по пути MTU не меньше, чем у тебя и на том конце (например, маршрутизаторов по пути нет), один из свичей пропускает только пакеты 1536 -> сессия висит. 2f. Все маршрутизаторы по пути и все свичи по пути пропускают пакеты с MTU не ниже, чем у тебя и на том конце -> получаешь выигрыш в скорости примерно 3% (при MTU 9000) - ура!
Ты считаешь, что пункт 2f перевешивает сумму 2b+2c+2d+2e? А если ещё и допустить, что теряется хотя бы 0.01% пакетов размером 1500, и процент потерь пропорционален размеру пакетов - выигрыша даже в варианте 2f уже, скорее всего, не получится.
К этому ещё можно добавить, что большинство сетевух по-прежнему не поддерживают MTU больше 1500, и рассогласование MTU приводит к проблемам в OSPF и некоторых других протоколах. То есть, вот живёшь ты себе в своей локалке с MTU 9000, и понадобилось добавить ещё один свич или роутер, который поддерживает только стандартное MTU - и нужно перестраивать всю сеть.
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
timeasmymeasure
no subject
Date: 2012-05-20 12:50 pm (UTC)Давай рассмотрим варианты.
1. У меня большое MTU, а с той стороны 1500 или меньше. Самый простой случай - устанавливается сессия с MTU 1500.
2. И у меня, и на том конце большое MTU.
2a. Хотя бы на одном из маршрутизаторов по пути MTU=1500 и включен tcp mss -> устанавливается сессия с MTU 1500. Случай редкий - при стандартном MTU обычно tcp mss не включают.
2b. Хотя бы на одном из маршрутизаторов по пути MTU=1500 и icmp needfrag проходит (через все наты). MTU уменьшается и сессия продолжается, имеем лишь небольшую задержку в начале сессии по сравнению со случаем стандартного MTU.
2с. На маршрутизаторе по пути MTU=1500, icmp needfrag от него где-то потерялось -> сессия не живёт.
2d. На маршрутизаторе по пути MTU=1500, icmp needfrag к источнику проходят, но роутинг асиметричный, оттуда к тебе большие пакеты проходят, а от тебя туда нет, и к тебе за нат icmp needfrag не доходят -> сессия виснет при первом объёмном post с твоей стороны.
2e. На всех маршрутизаторах по пути MTU не меньше, чем у тебя и на том конце (например, маршрутизаторов по пути нет), один из свичей пропускает только пакеты 1536 -> сессия висит.
2f. Все маршрутизаторы по пути и все свичи по пути пропускают пакеты с MTU не ниже, чем у тебя и на том конце -> получаешь выигрыш в скорости примерно 3% (при MTU 9000) - ура!
Ты считаешь, что пункт 2f перевешивает сумму 2b+2c+2d+2e?
А если ещё и допустить, что теряется хотя бы 0.01% пакетов размером 1500, и процент потерь пропорционален размеру пакетов - выигрыша даже в варианте 2f уже, скорее всего, не получится.
К этому ещё можно добавить, что большинство сетевух по-прежнему не поддерживают MTU больше 1500, и рассогласование MTU приводит к проблемам в OSPF и некоторых других протоколах. То есть, вот живёшь ты себе в своей локалке с MTU 9000, и понадобилось добавить ещё один свич или роутер, который поддерживает только стандартное MTU - и нужно перестраивать всю сеть.