.png)
Я запускаю несколько виртуальных машин в Azure. Виртуальные машины работают в подсети с NSG. Сетевые карты не используют NSG, мы не используем ускоренную сеть.
Я заметил, что когда виртуальная машина общается с другой виртуальной машиной той же подсети по протоколу TCP, значение MSS в пакетах SYN уменьшается на 42. Это означает, что если я отправлю TCP SYN с MSS=876 на другую виртуальную машину той же сети, другая виртуальная машина перехватит TCP SYN с MSS=834:
Клиент:
18:49:27.526527 IP 10.56.142.25.49614 > 10.56.142.108.ssh: Flags [S], seq 3092614737, win 17520, options [mss 876,sackOK,TS val 2936204423 ecr 0,nop,wscale 7], length 0
18:49:27.528398 IP 10.56.142.108.ssh > 10.56.142.25.49614: Flags [S.], seq 1710658781, ack 3092614738, win 28960, options [mss 1418,sackOK,TS val 390195731 ecr 2936204423,nop,wscale 7], length 0
18:49:27.528430 IP 10.56.142.25.49614 > 10.56.142.108.ssh: Flags [.], ack 1, win 137, options [nop,nop,TS val 2936204425 ecr 390195731], length 0
Сервер:
18:49:27.527362 IP 10.56.142.25.49614 > 10.56.142.108.ssh: Flags [S], seq 3092614737, win 17520, options [mss 834,sackOK,TS val 2936204423 ecr 0,nop,wscale 7], length 0
18:49:27.527682 IP 10.56.142.108.ssh > 10.56.142.25.49614: Flags [S.], seq 1710658781, ack 3092614738, win 28960, options [mss 1460,sackOK,TS val 390195731 ecr 2936204423,nop,wscale 7], length 0
18:49:27.529167 IP 10.56.142.25.49614 > 10.56.142.108.ssh: Flags [.], ack 1, win 137, options [nop,nop,TS val 2936204425 ecr 390195731], length 0
Мы используем несколько сетевых сетевых адаптеров, и наши пакеты SYN проходят через несколько переходов, и мы фактически видим, что MSS уменьшается в несколько раз. Первоначально мы замерили уменьшение на 84, а в некоторых случаях мы также замерили уменьшение на 138 (на самом деле, не кратное 42). Это означает, что мы снижаем эффективность нашей сети более чем на 10%.
Я потратил некоторое время на изучение того, как различные сетевые устройства взаимодействуют с MSS. В большинстве случаев MSS устанавливается на фиксированное значение, либо будучи ограниченным статическим значением, либо MTU пути. PaloAlto будет использовать «корректировку», которая относится к MTU сетевого интерфейса, который является фиксированным значением. Arista позволит вам установить предельное значение для входящего или исходящего трафика, опять же абсолютные значения. Некоторые поставщики брандмауэров, такие как PaloAlto, уменьшат MSS в случае DoS-атаки и активации SYN-cookie, но в этом случае MSS будет одним из 8 возможных значений.
Я считаю, что этот механизм MSS -= 42 нарушает TCP: если клиент поддерживает крупные кадры и отправляет MSS 8860, сервер в Azure получает 8876, сам отвечая 1330, но клиент получает 1246, клиент соглашается, что пакеты должны иметь 1246 байт полезной нагрузки, в то время как сервер отправит 1330 байт полезной нагрузки.
Самая большая проблема в том, что у нас есть случаи, когда трафик работает "случайно". Зажатие не выполняется должным образом на стороне экспресс-маршрута, однако из-за этого -42 здесь и там MSS фактически уменьшается до значения, которое "подходит", пока не произойдет небольшое изменение в способе маршрутизации пакетов, и вы внезапно обнаружите, что где-то была неправильная конфигурация.
Есть идеи, как объяснить это снижение? Я думаю, что такое поведение нигде не задокументировано.
РЕДАКТИРОВАТЬ
Просто читаюRFC879
MSS может использоваться совершенно независимо в каждом направлении потока данных. Результатом могут быть совершенно разные максимальные размеры в двух направлениях.
Так что это выглядит законно согласно RFC. Тем не менее, странное поведение.
решение1
В отличие от физической сети, сеть SDN потребляет дополнительные "байты" для заголовков инкапсуляции (GRE). Видимые IP-адреса — это CA (адрес клиента), но есть также PA (адрес поставщика), который требует маршрутизации в облачном провайдере. Следовательно, вы увидите меньше доступных MSS, поскольку облачный провайдер применяет дополнительное TCP-зажатие в инфраструктуре для маршрутизации бэкенда.