Windows maximum tcp connections

Содержание
  1. Configure the max limit for concurrent TCP connections
  2. Windows 10 Maximum TCP-IP Connection Limit
  3. Windows 10 Maximum TCP-IP Connection Limit
  4. Maximum packet size for a TCP connection
  5. 10 Answers 10
  6. Настройка производительности TCP/IP для виртуальных машин Azure TCP/IP performance tuning for Azure VMs
  7. Распространенные методы настройки TCP/IP Common TCP/IP tuning techniques
  8. MTU, фрагментация и разгрузка большой отправки MTU, fragmentation, and large send offload
  9. Максимальный передаваемый блок данных MTU
  10. Фрагментации Fragmentation
  11. Бит «не фрагментировать» в пакете IP The Don’t Fragment bit in an IP packet
  12. Влияние фрагментации на производительность Performance implications of fragmentation
  13. Преимущества и последствия изменения MTU Benefits and consequences of modifying the MTU
  14. Azure и MTU ВМ Azure and VM MTU
  15. Azure и фрагментация Azure and fragmentation
  16. Настройка MTU Tune the MTU
  17. Разгрузка большой отправки Large send offload
  18. Масштабирование и ПМТУД окна MSS TCP TCP MSS window scaling and PMTUD
  19. Максимальный размер сегмента TCP TCP maximum segment size
  20. Обнаружение MTU пути Path MTU Discovery
  21. VPN и MTU VPN and MTU
  22. Задержка, время приема-передачи и масштабирование окна TCP Latency, round-trip time, and TCP window scaling
  23. Задержка и время приема-передачи Latency and round-trip time
  24. Влияние задержки и времени кругового пути на TCP Latency and round-trip time effects on TCP
  25. Масштабирование окна TCP TCP window scaling
  26. Поддержка масштабирования окна TCP Support for TCP window scaling
  27. Увеличить размер MTU Increase MTU size
  28. Ускоренная работа в сети и масштабирование на стороне приема Accelerated networking and receive side scaling
  29. Ускорение работы в сети Accelerated networking
  30. Масштабирование на стороне приема Receive side scaling
  31. TCP-TIME_WAIT и TIME_WAIT ассассинатион TCP TIME_WAIT and TIME_WAIT assassination
  32. Факторы виртуальной сети, которые могут повлиять на производительность Virtual network factors that can affect performance
  33. Максимальная исходящая пропускная способность виртуальной машины VM maximum outbound throughput
  34. Вопросы производительности в Интернете Internet performance considerations
  35. Вопросы проектирования сети Network design considerations
  36. Регионы Azure, виртуальные сети и задержка Azure regions, virtual networks, and latency
  37. Нехватка исходного порта NAT Source NAT port exhaustion
  38. Измерение производительности сети в Azure Measure network performance on Azure
  39. Измерение времени кругового пути и потери пакетов Measure round-trip time and packet loss
  40. Измерение фактической пропускной способности TCP-соединения Measure actual throughput of a TCP connection
  41. Измерение фактической пропускной способности виртуальной машины Measure actual bandwidth of a virtual machine
  42. Обнаружение неэффективных поведений TCP Detect inefficient TCP behaviors
  43. Следующие шаги Next steps

Configure the max limit for concurrent TCP connections

To keep the TCP/IP stack from taking all resources on the computer, there are different parameters that control how many connections it can handle. If running applications that are constantly opening and closing connections (P2P), or are providing a service which many tries to connect to at the same time (Web-server like IIS), then one can improve the performance of these applications by changing the restriction limits.

There is a parameter that limits the maximum number of connections that TCP may have open simultaneously.

[HKEY_LOCAL_MACHINE \System \CurrentControlSet \Services \Tcpip \Parameters]
TcpNumConnections = 0x00fffffe (Default = 16,777,214)

Note a 16 Million connection limit sounds very promising, but there are other parameters (See below), which keeps us from ever reaching this limit.

[HKEY_LOCAL_MACHINE \System \CurrentControlSet \Services \Tcpip \Parameters]
MaxUserPort = 5000 (Default = 5000, Max = 65534)

Note it is possible to reserve port numbers so they aren’t used as dynamic ports in case one have a certain application that needs them. This is done by using the ReservedPorts (MS KB812873) setting.

Note Vista changes the default range from 1024-5000 to 49152-65535, which can be controlled with the dynamicport setting using netsh. More Info MS KB929851.

[HKEY_LOCAL_MACHINE \System \CurrentControlSet \Services \Tcpip \Parameters]
MaxFreeTcbs = 2000 (Default = RAM dependent, but usual Pro = 1000, Srv=2000)

[HKEY_LOCAL_MACHINE \System \CurrentControlSet \services \Tcpip \Parameters]
MaxHashTableSize = 512 (Default = 512, Range = 64-65536)

Note Microsoft recommends for a multiprocessor environment, that the value should not be higher than the maximum amount of concurrent connections (MaxFreeTcbs), also if multiprocessor then it might be interesting to look at the registry-key NumTcbTablePartitions (Recommended value CPU-count multiplied by 4).

[HKEY_LOCAL_MACHINE \System \CurrentControlSet \services \Tcpip \Parameters]
TcpTimedWaitDelay = 120 (Default = 240 secs, Range = 30-300)

Note with Win2k the reuse of sockets have been changed, so when reaching the limit of more than 1000 connections in TIME-WAIT state, then it starts to mark sockets that have been in TIME_WAIT state for more than 60 secs as free. It is possible to configure this limit:

[HKEY_LOCAL_MACHINE \System \CurrentControlSet \services \Tcpip \Parameters]
MaxFreeTWTcbs = 1000 (Default = 1000 sockets)

Note with Win2k3 SP1 the reuse of sockets have been changed, so when it has to re-use sockets in TIME_WAIT state, then it checks whether the other party is different from the old socket. Eliminating the need to fiddle with (TcpTimedWaitDelay) and (MaxFreeTWTcbs) any more.

[HKEY_LOCAL_MACHINE \System \CurrentControlSet \services \Tcpip \Parameters]
KeepAliveTime = 1800000 (Default = 7,200,000 milisecs)

When data is sent/received the data is copied back and forth to non-paged pool memory for buffering. If there are many connections receiving/sending data, then it is possible to exhaust the non-paged pool memory. The max size of the non-paged pool buffer allocated for each connection is controlled by MaxBufferredReceiveBytes or TCPIP Receive Window depending on which is smallest. More Info MS KB296265

Note if using the Professional/Home edition of Windows then it is very likely that it is crippled (By Microsoft) not to handle many concurrent TCP connections. Ex. Microsoft have officially stated that the backlog limit is 5 (200 when Server), so the Professional edition is not able to accept() more than 5 new connections concurrently. More Info MS KB127144

Note even if having optimized Windows to handle many concurrent connections, then connections might still be refused when reaching a certain limit, in case a NAT-Router/Firewall is placed infront of it, which is unable to handle so many concurrent connections.

Note if having activated SYN-Attack-Protection (Enabled by default in Win2k3 SP1) or installed WinXP SP2, a limit is introduced on how many connection attempts (half-open) one can make simultaneously (XP SP2 & Vista = 10; Vista SP2 = no limit). This will keep worms like blaster and sasser from spreading too fast, but it will also limit other applications that creates many new connections simultaneously (Like P2P).

EventID 4226: TCP/IP has reached the security limit imposed on the number of concurrent TCP connect attempts

Windows Vista SP2 removes the limit again, but it can be enabled with the following DWORD registry setting:

[HKEY_LOCAL_MACHINE \SYSTEM \CurrentControlSet \Services \Tcpip \Parameters]
EnableConnectionRateLimiting = 1

Источник

Windows 10 Maximum TCP-IP Connection Limit

> как же тогда работает тот же торрент клиент в обычной винде
Эта винда не обычная, очень мало у кого home версия. И торент в ней вот так и работает, хреново. TCP он не использует, кстати, иначе бы не смог перекидывать данные p2p, когда оба клиента за натами.

Хакнуть наверное можно, но не разу не слышал, чтобы так делали. Если уж нарушать лицензию, гораздо проще другую версию винды поставить.

0iStalker
> Возьми Linux/Freebsd
Да это я чисто любопытства спрашивал, сервак то всё равно не Linux-е, где этих ограничений нет вообще вроде как. Странная политика винды.

Zab
> TCP он не использует, кстати, иначе бы не смог перекидывать данные p2p, когда
> оба клиента за натами.
Так а как он работает, через UDP что ли?

-=MASTER=-
Zab
Вы там бухаете что ли?
В винде лимит на 10 или 20 полуоткрытых tcp соединений. Иными словами 10 или 20 попыток одновременных соединений.
Есть еще какой-то мелкий лимит на количество smb и ms-rdp сессий.
К количеству одновременных установленных tcp соединений это не имеет никакого отношения.
Какой-то лимит есть конечно, но чтобы его достигнуть, надо очень постараться.

youtube
Вы не видели home-версии, видимо.
На самом деле, я не знаю какой лимит у домашней десятки, но у всех остальных количество доступных сокетов в системе было очень маленьким, а соответственно и число соединений. Могу предположить, что в десятке принципиально ничего не изменилось. 20 сокетов вместо 10, которые были в XP home. Должны же они в винде что-то урезать, если эту версию распространяют едва ли не бесплатно. иначе нормальную покупать не будут.

-=MASTER=-
> Так а как он работает, через UDP что ли?
Да, собственно данные передаются по udp.
По tcp (вернее, по http) ты получаешь торент-файл с сервера обычно. Но данные то качаются минуя все сервера, их может быть ни одного не доступно, а торент-клиент будет благополучно качать.

Zab
> XP home
Это был вообще огрызок, каких еще поискать нужно благо, после SP2 он перестал существовать вообще. Нет смысла сравнивать его с любой другой версией винды.

Zab
> Вы не видели home-версии, видимо.
Видел. Там как раз ограничение на smb и ms-rdp. На количество tcp сессий вообще такого ограничения нет.

youtube
> Какой-то лимит есть конечно
65535

MrShoor
> 65535
это кол-во портов, а на один порты ты можешь приконнектить много TCP соединений

-=MASTER=-
> это кол-во портов, а на один порты ты можешь приконнектить много TCP соединений
Помимо тех портов, которые ты задаешь явно есть еще и внутренние порты, которые определяют в какое приложение на какое соединение направить данный пакет. Ты эти порты нигде не задаешь и в принципе их не видишь, но они есть.

MrShoor
> Ты эти порты нигде не задаешь и в принципе их не видишь, но они есть.
хмм, не слышал, думал, что при коннекте к серверу на определённый порт, просто инициализируется сокет и передаётся серверу его дескриптор, который типа int, то есть сокетов в теории может быть очень много. А что, реально на один порт может только 65535 TCP приконнектится? Что-то на гон похоже )

-=MASTER=-
Представь, что ты, разработчик ОС. Вот пользователь открывает 10 соединений на один и тот же порт на один и тот же сервер. Как ты определишь какие пакеты в какое соединение рассылать? Для этого и существует локальный порт. Открываешь Resource Monitor в винде, и на вкладке Network смотришь раздел TCP Connections. Там есть колонка с локальными портами, которые назначаются случайным образом на каждое открытое соединение.
Можно получить самому список этих локальных портов через GetTcpTable. А если сходишь и посмотришь параметры, которые возвращает тебе эта функция, то увидишь там в MIB_TCPROW параметр dwLocalPort для которого черным по белому написано:

Источник

Windows 10 Maximum TCP-IP Connection Limit

> как же тогда работает тот же торрент клиент в обычной винде
Эта винда не обычная, очень мало у кого home версия. И торент в ней вот так и работает, хреново. TCP он не использует, кстати, иначе бы не смог перекидывать данные p2p, когда оба клиента за натами.

Хакнуть наверное можно, но не разу не слышал, чтобы так делали. Если уж нарушать лицензию, гораздо проще другую версию винды поставить.

0iStalker
> Возьми Linux/Freebsd
Да это я чисто любопытства спрашивал, сервак то всё равно не Linux-е, где этих ограничений нет вообще вроде как. Странная политика винды.

Zab
> TCP он не использует, кстати, иначе бы не смог перекидывать данные p2p, когда
> оба клиента за натами.
Так а как он работает, через UDP что ли?

-=MASTER=-
Zab
Вы там бухаете что ли?
В винде лимит на 10 или 20 полуоткрытых tcp соединений. Иными словами 10 или 20 попыток одновременных соединений.
Есть еще какой-то мелкий лимит на количество smb и ms-rdp сессий.
К количеству одновременных установленных tcp соединений это не имеет никакого отношения.
Какой-то лимит есть конечно, но чтобы его достигнуть, надо очень постараться.

youtube
Вы не видели home-версии, видимо.
На самом деле, я не знаю какой лимит у домашней десятки, но у всех остальных количество доступных сокетов в системе было очень маленьким, а соответственно и число соединений. Могу предположить, что в десятке принципиально ничего не изменилось. 20 сокетов вместо 10, которые были в XP home. Должны же они в винде что-то урезать, если эту версию распространяют едва ли не бесплатно. иначе нормальную покупать не будут.

-=MASTER=-
> Так а как он работает, через UDP что ли?
Да, собственно данные передаются по udp.
По tcp (вернее, по http) ты получаешь торент-файл с сервера обычно. Но данные то качаются минуя все сервера, их может быть ни одного не доступно, а торент-клиент будет благополучно качать.

Zab
> XP home
Это был вообще огрызок, каких еще поискать нужно благо, после SP2 он перестал существовать вообще. Нет смысла сравнивать его с любой другой версией винды.

Zab
> Вы не видели home-версии, видимо.
Видел. Там как раз ограничение на smb и ms-rdp. На количество tcp сессий вообще такого ограничения нет.

youtube
> Какой-то лимит есть конечно
65535

MrShoor
> 65535
это кол-во портов, а на один порты ты можешь приконнектить много TCP соединений

-=MASTER=-
> это кол-во портов, а на один порты ты можешь приконнектить много TCP соединений
Помимо тех портов, которые ты задаешь явно есть еще и внутренние порты, которые определяют в какое приложение на какое соединение направить данный пакет. Ты эти порты нигде не задаешь и в принципе их не видишь, но они есть.

MrShoor
> Ты эти порты нигде не задаешь и в принципе их не видишь, но они есть.
хмм, не слышал, думал, что при коннекте к серверу на определённый порт, просто инициализируется сокет и передаётся серверу его дескриптор, который типа int, то есть сокетов в теории может быть очень много. А что, реально на один порт может только 65535 TCP приконнектится? Что-то на гон похоже )

-=MASTER=-
Представь, что ты, разработчик ОС. Вот пользователь открывает 10 соединений на один и тот же порт на один и тот же сервер. Как ты определишь какие пакеты в какое соединение рассылать? Для этого и существует локальный порт. Открываешь Resource Monitor в винде, и на вкладке Network смотришь раздел TCP Connections. Там есть колонка с локальными портами, которые назначаются случайным образом на каждое открытое соединение.
Можно получить самому список этих локальных портов через GetTcpTable. А если сходишь и посмотришь параметры, которые возвращает тебе эта функция, то увидишь там в MIB_TCPROW параметр dwLocalPort для которого черным по белому написано:

Источник

Maximum packet size for a TCP connection

What is the maximum packet size for a TCP connection or how can I get the maximum packet size?

10 Answers 10

The absolute limitation on TCP packet size is 64K (65535 bytes), but in practicality this is far larger than the size of any packet you will see, because the lower layers (e.g. ethernet) have lower packet sizes.

The MTU (Maximum Transmission Unit) for Ethernet, for instance, is 1500 bytes. Some types of networks (like Token Ring) have larger MTUs, and some types have smaller MTUs, but the values are fixed for each physical technology.

This is an excellent question and I run in to this a lot at work actually. There are a lot of «technically correct» answers such as 65k and 1500. I’ve done a lot of work writing network interfaces and using 65k is silly, and 1500 can also get you in to big trouble. My work goes on a lot of different hardware / platforms / routers, and to be honest the place I start is 1400 bytes. If you NEED more than 1400 you can start to inch your way up, you can probably go to 1450 and sometimes to 1480’ish? If you need more than that then of course you need to split in to 2 packets, of which there are several obvious ways of doing..

The problem is that you’re talking about creating a data packet and writing it out via TCP, but of course there’s header data tacked on and so forth, so you have «baggage» that puts you to 1500 or beyond.. and also a lot of hardware has lower limits.

If you «push it» you can get some really weird things going on. Truncated data, obviously, or dropped data I’ve seen rarely. Corrupted data also rarely but certainly does happen.

At the application level, the application uses TCP as a stream oriented protocol. TCP in turn has segments and abstracts away the details of working with unreliable IP packets.

TCP deals with segments instead of packets. Each TCP segment has a sequence number which is contained inside a TCP header. The actual data sent in a TCP segment is variable.

There is a value for getsockopt that is supported on some OS that you can use called TCP_MAXSEG which retrieves the maximum TCP segment size (MSS). It is not supported on all OS though.

I’m not sure exactly what you’re trying to do but if you want to reduce the buffer size that’s used you could also look into: SO_SNDBUF and SO_RCVBUF.

Источник

Настройка производительности TCP/IP для виртуальных машин Azure TCP/IP performance tuning for Azure VMs

В этой статье рассматриваются распространенные методы настройки производительности TCP/IP и некоторые моменты, которые следует учитывать при их использовании для виртуальных машин, работающих в Azure. This article discusses common TCP/IP performance tuning techniques and some things to consider when you use them for virtual machines running on Azure. В нем приводятся основные сведения о методах и их настройке. It will provide a basic overview of the techniques and explore how they can be tuned.

Распространенные методы настройки TCP/IP Common TCP/IP tuning techniques

MTU, фрагментация и разгрузка большой отправки MTU, fragmentation, and large send offload

Максимальный передаваемый блок данных MTU

Максимальный размер блока передаваемых данных (MTU) — это самый крупный кадр (пакет), заданный в байтах, который может быть отправлен через сетевой интерфейс. The maximum transmission unit (MTU) is the largest size frame (packet), specified in bytes, that can be sent over a network interface. Параметр MTU является настраиваемым. The MTU is a configurable setting. Значение MTU по умолчанию, используемое на виртуальных машинах Azure, и параметр по умолчанию для большинства сетевых устройств, составляет 1 500 байт. The default MTU used on Azure VMs, and the default setting on most network devices globally, is 1,500 bytes.

Фрагментации Fragmentation

Фрагментация происходит при отправке пакета, превышающего MTU сетевого интерфейса. Fragmentation occurs when a packet is sent that exceeds the MTU of a network interface. Стек TCP/IP прервет пакет на более мелкие части (фрагменты), соответствующие MTU интерфейса. The TCP/IP stack will break the packet into smaller pieces (fragments) that conform to the interface’s MTU. Фрагментация происходит на уровне IP-адреса и не зависит от базового протокола (например, TCP). Fragmentation occurs at the IP layer and is independent of the underlying protocol (such as TCP). Если 2 000-байтовый пакет передается через сетевой интерфейс с MTU 1 500, пакет будет разбит на пакеты 1 1 500-Byte и 1 500-Byte. When a 2,000-byte packet is sent over a network interface with an MTU of 1,500, the packet will be broken down into one 1,500-byte packet and one 500-byte packet.

Читайте также:  Windows exe fix windows 7

Сетевые устройства в пути между источником и назначением могут либо сбрасывать пакеты, превышающие MTU, либо фрагментировать пакет на меньшие части. Network devices in the path between a source and destination can either drop packets that exceed the MTU or fragment the packet into smaller pieces.

Бит «не фрагментировать» в пакете IP The Don’t Fragment bit in an IP packet

Бит «не фрагментировать» (DF) является флагом в заголовке IP-протокола. The Don’t Fragment (DF) bit is a flag in the IP protocol header. Бит DF указывает, что сетевые устройства в пути между отправителем и получателем не должны фрагментировать пакет. The DF bit indicates that network devices on the path between the sender and receiver must not fragment the packet. Этот бит можно задать по многим причинам. This bit could be set for many reasons. (Один из примеров см. в подразделе «обнаружение MTU пути» этой статьи.) Когда сетевое устройство получает пакет с установленным битом «не фрагментировать», а этот пакет превышает MTU интерфейса, стандартное поведение устройства — удаление пакета. (See the «Path MTU Discovery» section of this article for one example.) When a network device receives a packet with the Don’t Fragment bit set, and that packet exceeds the device’s interface MTU, the standard behavior is for the device to drop the packet. Устройство отправляет сообщение о фрагментации ICMP обратно в исходный источник пакета. The device sends an ICMP Fragmentation Needed message back to the original source of the packet.

Влияние фрагментации на производительность Performance implications of fragmentation

Фрагментация может негативно сказаться на производительности. Fragmentation can have negative performance implications. Одной из основных причин влияния на производительность является влияние фрагментации ЦП на память и пересборкой пакетов. One of the main reasons for the effect on performance is the CPU/memory impact of the fragmentation and reassembly of packets. Когда сетевому устройству необходимо выполнить фрагментацию пакета, ему потребуется выделить ресурсы ЦП и памяти для выполнения фрагментации. When a network device needs to fragment a packet, it will have to allocate CPU/memory resources to perform fragmentation.

То же самое происходит при сборке пакета. The same thing happens when the packet is reassembled. Сетевое устройство должно хранить все фрагменты, пока они не будут получены, чтобы их можно было собрать в исходный пакет. The network device has to store all the fragments until they’re received so it can reassemble them into the original packet. Этот процесс фрагментации и повторной сборки может также вызвать задержку. This process of fragmentation and reassembly can also cause latency.

Другая возможная отрицательная производительность фрагментации заключается в том, что фрагментированные пакеты могут поступать не по порядку. The other possible negative performance implication of fragmentation is that fragmented packets might arrive out of order. Если пакеты получены не по порядку, некоторые типы сетевых устройств могут быть удалены. When packets are received out of order, some types of network devices can drop them. В этом случае необходимо повторно передать весь пакет. When that happens, the whole packet has to be retransmitted.

Фрагменты обычно удаляются с помощью таких устройств безопасности, как сетевые брандмауэры или когда буферы приема для сетевого устройства исчерпаны. Fragments are typically dropped by security devices like network firewalls or when a network device’s receive buffers are exhausted. Когда буферы приема для сетевого устройства исчерпаны, сетевое устройство пытается повторно собрать фрагментированный пакет, но не имеет ресурсов для хранения и повторного предположения пакета. When a network device’s receive buffers are exhausted, a network device is attempting to reassemble a fragmented packet but doesn’t have the resources to store and reassume the packet.

Фрагментация может рассматриваться как отрицательная операция, но поддержка фрагментации необходима при подключении различных сетей через Интернет. Fragmentation can be seen as a negative operation, but support for fragmentation is necessary when you’re connecting diverse networks over the internet.

Преимущества и последствия изменения MTU Benefits and consequences of modifying the MTU

В целом, можно создать более эффективную сеть, увеличив значение MTU. Generally speaking, you can create a more efficient network by increasing the MTU. Каждый передаваемый пакет содержит сведения о заголовке, которые добавляются к исходному пакету. Every packet that’s transmitted has header information that’s added to the original packet. Когда фрагментация создает больше пакетов, накладные расходы на заголовки становятся более эффективными, что делает сеть менее эффективной. When fragmentation creates more packets, there’s more header overhead, and that makes the network less efficient.

Пример приведен ниже. Here’s an example. Размер заголовка Ethernet составляет 14 байт плюс последовательность с 4 байтами для проверки согласованности кадров. The Ethernet header size is 14 bytes plus a 4-byte frame check sequence to ensure frame consistency. Если отправляется 1 2 000-байтовый пакет, в сеть добавляется 18 байт ресурсов Ethernet. If one 2,000-byte packet is sent, 18 bytes of Ethernet overhead is added on the network. Если пакет фрагментирован в 1 500-байтовый пакет и 500-байтовый пакет, каждый пакет будет содержать 18 байт заголовка Ethernet, а всего 36 байт. If the packet is fragmented into a 1,500-byte packet and a 500-byte packet, each packet will have 18 bytes of Ethernet header, a total of 36 bytes.

Помните, что увеличение MTU не обязательно приводит к повышению эффективности сети. Keep in mind that increasing the MTU won’t necessarily create a more efficient network. Если приложение отправляет только 500-байтовые пакеты, накладные расходы заголовков будут существовать, если значение MTU равно 1 500 байт или 9 000 байт. If an application sends only 500-byte packets, the same header overhead will exist whether the MTU is 1,500 bytes or 9,000 bytes. Сеть станет более эффективной, только если она использует большие размеры пакетов, которые зависят от MTU. The network will become more efficient only if it uses larger packet sizes that are affected by the MTU.

Azure и MTU ВМ Azure and VM MTU

Значение MTU по умолчанию для виртуальных машин Azure составляет 1 500 байт. The default MTU for Azure VMs is 1,500 bytes. Стек виртуальной сети Azure попытается фрагментировать пакет на 1 400 байт. The Azure Virtual Network stack will attempt to fragment a packet at 1,400 bytes.

Обратите внимание, что стек виртуальной сети не является неэффективным, так как он фрагменты передаются в 1 400 байт, хотя виртуальные машины имеют MTU 1 500. Note that the Virtual Network stack isn’t inherently inefficient because it fragments packets at 1,400 bytes even though VMs have an MTU of 1,500. Большой процент сетевых пакетов намного меньше 1 400 или 1 500 байт. A large percentage of network packets are much smaller than 1,400 or 1,500 bytes.

Azure и фрагментация Azure and fragmentation

Виртуальный сетевой стек настроен на удаление фрагментов неупорядоченного кода, то есть фрагментированных пакетов, которые не поступают в исходный фрагментированный порядок. Virtual Network stack is set up to drop «out of order fragments,» that is, fragmented packets that don’t arrive in their original fragmented order. Эти пакеты удаляются в основном из-за уязвимости сетевой безопасности, объявленной в ноябре 2018 с именем Фрагментсмакк. These packets are dropped mainly because of a network security vulnerability announced in November 2018 called FragmentSmack.

Фрагментсмакк — это ошибка в том, как ядро Linux обрабатывает пересборку фрагментированных пакетов IPv4 и IPv6. FragmentSmack is a defect in the way the Linux kernel handled reassembly of fragmented IPv4 and IPv6 packets. Удаленный злоумышленник может использовать этот изъян для активации ресурсоемких операций пересборки фрагментов, что может привести к увеличению времени ЦП и отказу в обслуживании в целевой системе. A remote attacker could use this flaw to trigger expensive fragment reassembly operations, which could lead to increased CPU and a denial of service on the target system.

Настройка MTU Tune the MTU

Вы можете настроить значение MTU виртуальной машины Azure, как и в любой другой операционной системе. You can configure an Azure VM MTU, as you can in any other operating system. Но при настройке MTU следует учитывать фрагментацию, которая происходит в Azure, описанную выше. But you should consider the fragmentation that occurs in Azure, described above, when you’re configuring an MTU.

Мы не рекомендуем клиентам увеличивать MTU виртуальных машин. We don’t encourage customers to increase VM MTUs. В этом обсуждении рассказывается о том, как Azure реализует MTU и выполняет фрагментацию. This discussion is meant to explain the details of how Azure implements MTU and performs fragmentation.

Увеличение MTU не известно для повышения производительности и может негативно сказаться на производительности приложения. Increasing MTU isn’t known to improve performance and could have a negative effect on application performance.

Разгрузка большой отправки Large send offload

Разгрузка большой отправки (LSO) может повысить производительность сети за счет разгрузки сегментации пакетов на адаптер Ethernet. Large send offload (LSO) can improve network performance by offloading the segmentation of packets to the Ethernet adapter. Если параметр LSO включен, стек TCP/IP создает большой TCP-пакет и отправляет его на адаптер Ethernet для сегментации перед его пересылкой. When LSO is enabled, the TCP/IP stack creates a large TCP packet and sends it to the Ethernet adapter for segmentation before forwarding it. Преимущество «LSO» заключается в том, что он может освободить ЦП от сегментирования пакетов до размеров, соответствующих MTU и разгрузку, которая обрабатывает интерфейс Ethernet, где он выполняется на оборудовании. The benefit of LSO is that it can free the CPU from segmenting packets into sizes that conform to the MTU and offload that processing to the Ethernet interface where it’s performed in hardware. Дополнительные сведения о преимуществах LSO см. в разделе поддержка разгрузки больших отправок. To learn more about the benefits of LSO, see Supporting large send offload.

Если включено LSO, клиенты Azure могут видеть крупные размеры кадров при выполнении записи пакетов. When LSO is enabled, Azure customers might see large frame sizes when they perform packet captures. Эти крупные размеры кадров могут привести к тому, что некоторые клиенты могли подумать о фрагментации или что в противном случае используется большой MTU. These large frame sizes might lead some customers to think fragmentation is occurring or that a large MTU is being used when it’s not. В случае с параметром LSO адаптер Ethernet может объявить в стеке TCP/IP больший максимальный размер сегмента (MSS) для создания большего пакета TCP. With LSO, the Ethernet adapter can advertise a larger maximum segment size (MSS) to the TCP/IP stack to create a larger TCP packet. Затем весь несегментированный кадр перенаправляется на адаптер Ethernet и отображается в записи пакетов, выполняемой на виртуальной машине. This entire non-segmented frame is then forwarded to the Ethernet adapter and would be visible in a packet capture performed on the VM. Но этот пакет будет разбит на несколько меньших кадров через адаптер Ethernet в соответствии с MTU адаптера Ethernet. But the packet will be broken down into many smaller frames by the Ethernet adapter, according to the Ethernet adapter’s MTU.

Масштабирование и ПМТУД окна MSS TCP TCP MSS window scaling and PMTUD

Максимальный размер сегмента TCP TCP maximum segment size

Максимальный размер сегмента TCP (MSS) — это параметр, ограничивающий размер TCP-сегментов, что позволяет избежать фрагментации пакетов TCP. TCP maximum segment size (MSS) is a setting that limits the size of TCP segments, which avoids fragmentation of TCP packets. В операционных системах эта формула обычно используется для установки MSS: Operating systems will typically use this formula to set MSS:

Заголовок IP и заголовок TCP имеют размер 20 байт или 40 байт. The IP header and the TCP header are 20 bytes each, or 40 bytes total. Поэтому интерфейс с MTU 1 500 будет иметь размер MSS 1 460. So an interface with an MTU of 1,500 will have an MSS of 1,460. Однако размер MSS можно настроить. But the MSS is configurable.

Этот параметр придается в третьем случае по протоколу TCP, если сеанс TCP настроен между источником и назначением. This setting is agreed to in the TCP three-way handshake when a TCP session is set up between a source and a destination. Обе стороны отправляют значение MSS, а нижняя из двух используется для TCP-соединения. Both sides send an MSS value, and the lower of the two is used for the TCP connection.

Помните, что значения MTU источника и назначения не являются единственными факторами, определяющими значение MSS. Keep in mind that the MTUs of the source and destination aren’t the only factors that determine the MSS value. На промежуточных сетевых устройствах, таких как VPN-шлюзы Azure, можно настроить MTU независимо от источника и назначения, чтобы обеспечить оптимальную производительность сети. Intermediary network devices, like VPN gateways, including Azure VPN Gateway, can adjust the MTU independently of the source and destination to ensure optimal network performance.

Обнаружение MTU пути Path MTU Discovery

Параметр MSS согласовывается, но он может не указывать на реальный размер MSS, который можно использовать. MSS is negotiated, but it might not indicate the actual MSS that can be used. Это связано с тем, что другие сетевые устройства в пути между источником и назначением могут иметь более низкую величину MTU, чем у источника и назначения. This is because other network devices in the path between the source and the destination might have a lower MTU value than the source and destination. В этом случае устройство, значение MTU которого меньше, чем пакет, удалит пакет. In this case, the device whose MTU is smaller than the packet will drop the packet. Устройство будет передавать сообщение о необходимости фрагментации ICMP (тип 3, код 4), который содержит MTU. The device will send back an ICMP Fragmentation Needed (Type 3, Code 4) message that contains its MTU. Это сообщение ICMP позволяет исходному узлу уменьшить MTU соответствующего пути. This ICMP message allows the source host to reduce its Path MTU appropriately. Процесс называется «обнаружение MTU пути» (ПМТУД). The process is called Path MTU Discovery (PMTUD).

Процесс ПМТУД неэффективен и влияет на производительность сети. The PMTUD process is inefficient and affects network performance. При отправке пакетов, превышающих MTU сетевого пути, пакеты необходимо передавать с более низким значением MSS. When packets are sent that exceed a network path’s MTU, the packets need to be retransmitted with a lower MSS. Если отправитель не получит сообщение о необходимости фрагментации ICMP, возможно, из-за сетевого брандмауэра в пути (который обычно называется пмтуд блаккхоле), отправителю не известно, что необходимо уменьшить MSS и будет постоянно передаваться пакет. If the sender doesn’t receive the ICMP Fragmentation Needed message, maybe because of a network firewall in the path (commonly referred to as a PMTUD blackhole), the sender doesn’t know it needs to lower the MSS and will continuously retransmit the packet. Поэтому мы не рекомендуем увеличивать значение MTU виртуальной машины Azure. This is why we don’t recommend increasing the Azure VM MTU.

VPN и MTU VPN and MTU

Если вы используете виртуальные машины, которые выполняют инкапсуляцию (например, VPN-виртуальные сети), существуют некоторые дополнительные соображения, касающиеся размера пакета и MTU. If you use VMs that perform encapsulation (like IPsec VPNs), there are some additional considerations regarding packet size and MTU. Виртуальные частные сети добавляют дополнительные заголовки к пакетам, что увеличивает размер пакета и требует меньшего размера MSS. VPNs add more headers to packets, which increases the packet size and requires a smaller MSS.

Для Azure рекомендуется установить для фиксации TCP-порта MSS значение 1 350 байт и интерфейс туннеля MTU в 1 400. For Azure, we recommend that you set TCP MSS clamping to 1,350 bytes and tunnel interface MTU to 1,400. Дополнительные сведения см. на странице VPN-устройства и параметры IPsec/IKE. For more information, see the VPN devices and IPSec/IKE parameters page.

Задержка, время приема-передачи и масштабирование окна TCP Latency, round-trip time, and TCP window scaling

Задержка и время приема-передачи Latency and round-trip time

Задержка в сети регулируется скоростью света в оптоволоконной сети. Network latency is governed by the speed of light over a fiber optic network. Пропускная способность сети TCP также эффективно регулируется по времени приема-передачи (RTT) между двумя сетевыми устройствами. Network throughput of TCP is also effectively governed by the round-trip time (RTT) between two network devices.

Маршрут Route расстояние; Distance Одностороннее время One-way time RTT RTT
Нью Йорк — Сан, Санкт New York to San Francisco 4 148 км 4,148 km 21 мс 21 ms 42 мс 42 ms
Нью Йорк — Лондон New York to London 5 585 км 5,585 km 28 МС 28 ms 56 МС 56 ms
Нью Йорк — Сидней New York to Sydney 15 993 км 15,993 km 80 мс 80 ms 160 мс 160 ms

В этой таблице показано расстояние между двумя расположениями в прямой строке. This table shows the straight-line distance between two locations. В сетях расстояние обычно превышает значение прямой линии. In networks, the distance is typically longer than the straight-line distance. Ниже приведена простая формула для вычисления минимального RTT, которое регулируется скоростью освещения: Here’s a simple formula to calculate minimum RTT as governed by the speed of light:

minimum RTT = 2 * (Distance in kilometers / Speed of propagation)

Для скорости распространения можно использовать 200. You can use 200 for the speed of propagation. Это расстояние в километрах, которое перемещается в 1 миллисекунду. This is the distance, in kilometers, that light travels in 1 millisecond.

Возьмем в качестве примера новый Москва в Сан Франциско. Let’s take New York to San Francisco as an example. Расстояние прямой линии составляет 4 148 км. The straight-line distance is 4,148 km. Поключив это значение в уравнение, мы получаем следующее: Plugging that value into the equation, we get the following:

Minimum RTT = 2 * (4,148 / 200)

Результат уравнения задается в миллисекундах. The output of the equation is in milliseconds.

Если вы хотите получить лучшую производительность сети, логично выбрать назначения с кратчайшим расстоянием между ними. If you want to get the best network performance, the logical option is to select destinations with the shortest distance between them. Кроме того, необходимо спроектировать виртуальную сеть, чтобы оптимизировать путь к трафику и сократить задержку. You should also design your virtual network to optimize the path of traffic and reduce latency. Дополнительные сведения см. в подразделе «вопросы проектирования сети» этой статьи. For more information, see the «Network design considerations» section of this article.

Влияние задержки и времени кругового пути на TCP Latency and round-trip time effects on TCP

Время приема-передачи напрямую влияет на максимальную пропускную способность TCP. Round-trip time has a direct effect on maximum TCP throughput. В протоколе TCP Размер окна — это максимальный объем трафика, который может быть отправлен через TCP-соединение, прежде чем отправителю нужно получить подтверждение от получателя. In TCP protocol, window size is the maximum amount of traffic that can be sent over a TCP connection before the sender needs to receive acknowledgement from the receiver. Если для TCP MSS задано значение 1 460, а для параметра размер окна TCP задано значение 65 535, отправитель может 45 отправлять пакеты, прежде чем получать подтверждение от получателя. If the TCP MSS is set to 1,460 and the TCP window size is set to 65,535, the sender can send 45 packets before it has to receive acknowledgement from the receiver. Если отправитель не получает подтверждение, данные будут передаваться повторно. If the sender doesn’t get acknowledgement, it will retransmit the data. Формула выглядит так: Here’s the formula:

TCP window size / TCP MSS = packets sent

В этом примере 65 535/1 460 округляется до 45. In this example, 65,535 / 1,460 is rounded up to 45.

Это состояние «ожидание подтверждения» — механизм обеспечения надежной доставки данных, который заставляет RTT влиять на пропускную способность TCP. This «waiting for acknowledgement» state, a mechanism to ensure reliable delivery of data, is what causes RTT to affect TCP throughput. Чем дольше отправитель ждет подтверждения, тем дольше будет необходимо подождать перед отправкой дополнительных данных. The longer the sender waits for acknowledgement, the longer it needs to wait before sending more data.

Ниже приведена формула для вычисления максимальной пропускной способности отдельного TCP-подключения: Here’s the formula for calculating the maximum throughput of a single TCP connection:

Window size / (RTT latency in milliseconds / 1,000) = maximum bytes/second

В этой таблице показана максимальная пропускная способность (в МБ/с) для одного TCP-подключения. This table shows the maximum megabytes/per second throughput of a single TCP connection. (Для удобства чтения используется единица измерения в мегабайтах.) (For readability, megabytes is used for the unit of measure.)

Если пакеты теряются, максимальная пропускная способность подключения TCP будет снижена, пока отправитель повторно передает уже отправленные данные. If packets are lost, the maximum throughput of a TCP connection will be reduced while the sender retransmits data it has already sent.

Масштабирование окна TCP TCP window scaling

Масштабирование окна TCP — это метод, который динамически увеличивает размер окна TCP, позволяя отправлять больше данных, прежде чем требуется подтверждение. TCP window scaling is a technique that dynamically increases the TCP window size to allow more data to be sent before an acknowledgement is required. В предыдущем примере пакеты 45 были бы отправлены раньше, чем требовалось подтверждение. In the previous example, 45 packets would be sent before an acknowledgement was required. При увеличении числа пакетов, которые могут быть отправлены до появления подтверждения, уменьшается количество случаев, когда отправитель ожидает подтверждения, что увеличивает максимальную пропускную способность TCP. If you increase the number of packets that can be sent before an acknowledgement is needed, you’re reducing the number of times a sender is waiting for acknowledgement, which increases the TCP maximum throughput.

В следующей таблице показаны эти связи: This table illustrates those relationships:

Размер окна TCP (байт) TCP window size (bytes) Задержка приема-передачи (МС) RTT latency (ms) Максимальная пропускная способность в мегабайтах и секундах Maximum megabyte/second throughput Максимальная пропускная способность мегабит/сек Maximum megabit/second throughput
65 535 65,535 30 30 2.18 2.18 17,48 17.48
131 070 131,070 30 30 4.37 4.37 34,95 34.95
262 140 262,140 30 30 8,74 8.74 69,91 69.91
524 280 524,280 30 30 17,48 17.48 139,81 139.81

Но значение заголовка TCP для окна TCP имеет длину всего 2 байта, что означает, что максимальное значение для окна приема — 65 535. But the TCP header value for TCP window size is only 2 bytes long, which means the maximum value for a receive window is 65,535. Для увеличения максимального размера окна был введен коэффициент масштабирования окна TCP. To increase the maximum window size, a TCP window scale factor was introduced.

Коэффициент масштабирования является также параметром, который можно настроить в операционной системе. The scale factor is also a setting that you can configure in an operating system. Ниже приведена формула для вычисления размера окна TCP с использованием коэффициентов масштабирования: Here’s the formula for calculating the TCP window size by using scale factors:

TCP window size = TCP window size in bytes \* (2^scale factor)

Ниже приведено Вычисление коэффициента масштабирования окна 3 и размера окна 65 535: Here’s the calculation for a window scale factor of 3 and a window size of 65,535:

65,535 \* (2^3) = 262,140 bytes

Коэффициент масштабирования, равный 14, приводит к увеличению размера окна TCP, равному 14 (максимально допустимое смещение). A scale factor of 14 results in a TCP window size of 14 (the maximum offset allowed). Размер окна TCP будет 1 073 725 440 байт (8,5 гигабит). The TCP window size will be 1,073,725,440 bytes (8.5 gigabits).

Поддержка масштабирования окна TCP Support for TCP window scaling

Windows может задавать различные коэффициенты масштабирования для разных типов подключений. Windows can set different scaling factors for different connection types. (Классы подключений включают в себя центр обработки данных, Интернет и т. д.) Get-NetTCPConnection Чтобы просмотреть тип подключения масштабирования окна, используйте команду PowerShell: (Classes of connections include datacenter, internet, and so on.) You use the Get-NetTCPConnection PowerShell command to view the window scaling connection type:

Get-NetTCPSetting Для просмотра значений каждого класса можно использовать команду PowerShell: You can use the Get-NetTCPSetting PowerShell command to view the values of each class:

Вы можете задать начальный размер окна TCP и коэффициент масштабирования TCP в Windows с помощью Set-NetTCPSetting команды PowerShell. You can set the initial TCP window size and TCP scaling factor in Windows by using the Set-NetTCPSetting PowerShell command. Дополнительные сведения см. в разделе Set-нетткпсеттинг. For more information, see Set-NetTCPSetting.

Это действующие параметры TCP для AutoTuningLevel : These are the effective TCP settings for AutoTuningLevel :

аутотунинглевел AutoTuningLevel Коэффициент масштабирования Scaling factor Коэффициент масштабирования Scaling multiplier Формула для Formula to
вычислить максимальный размер окна calculate maximum window size
Выключено Disabled Нет None Нет None Размер окна Window size
С ограниченным доступом Restricted 4 4 2 ^ 4 2^4 Размер окна * (2 ^ 4) Window size * (2^4)
С высоким уровнем ограничений Highly restricted 2 2 2 ^ 2 2^2 Размер окна * (2 ^ 2) Window size * (2^2)
Норм. Normal 8 8 2 ^ 8 2^8 Размер окна * (2 ^ 8) Window size * (2^8)
Экспериментальный Experimental 14 14 2 ^ 14 2^14 Размер окна * (2 ^ 14) Window size * (2^14)

Эти параметры, скорее всего, влияют на производительность TCP, но следует помнить, что многие другие факторы в Интернете, за пределами управления Azure, также могут влиять на производительность TCP. These settings are the most likely to affect TCP performance, but keep in mind that many other factors across the internet, outside the control of Azure, can also affect TCP performance.

Увеличить размер MTU Increase MTU size

Так как больший размер MTU означает больший размер MSS, может возникнуть вопрос, может ли увеличение значения MTU увеличить производительность TCP. Because a larger MTU means a larger MSS, you might wonder whether increasing the MTU can increase TCP performance. Скорее всего, нет. Probably not. Размер пакета по сравнению с TCP-трафиком имеет свои достоинства и недостатки. There are pros and cons to packet size beyond just TCP traffic. Как обсуждалось ранее, наиболее важными факторами, влияющими на производительность пропускной способности TCP, являются размер окна TCP, потеря пакетов и RTT. As discussed earlier, the most important factors affecting TCP throughput performance are TCP window size, packet loss, and RTT.

Мы не рекомендуем, чтобы клиенты Azure изменили значение MTU по умолчанию на виртуальных машинах. We don’t recommend that Azure customers change the default MTU value on virtual machines.

Ускоренная работа в сети и масштабирование на стороне приема Accelerated networking and receive side scaling

Ускорение работы в сети Accelerated networking

Сетевые функции виртуальных машин исторически использовали ЦП как на гостевой виртуальной машине, так и на гипервизоре или узле. Virtual machine network functions have historically been CPU intensive on both the guest VM and the hypervisor/host. Каждый пакет, транзитный через узел, обрабатывается программным обеспечением ЦП узла, включая все инкапсуляцию и декапсуляция виртуальной сети. Every packet that transits through the host is processed in software by the host CPU, including all virtual network encapsulation and decapsulation. Так что чем больше трафик проходит через узел, тем выше нагрузка на ЦП. So the more traffic that goes through the host, the higher the CPU load. И если ЦП узла занят другими операциями, это также повлияет на пропускную способность и задержку сети. And if the host CPU is busy with other operations, that will also affect network throughput and latency. Azure решает эту задачу с помощью ускорения работы в сети. Azure addresses this issue with accelerated networking.

Ускоренная сеть обеспечивает постоянную ултраловную задержку сети с помощью встроенного программируемого оборудования Azure и технологий, таких как SR-IOV. Accelerated networking provides consistent ultralow network latency via the in-house programmable hardware of Azure and technologies like SR-IOV. Ускоренная сеть перемещает значительную часть программно-определяемой сети Azure из стека на процессоры и в Смартникс на основе FPGA. Accelerated networking moves much of the Azure software-defined networking stack off the CPUs and into FPGA-based SmartNICs. Это изменение позволяет приложениям конечных пользователей освобождать циклы вычислений, что снижает нагрузку на виртуальную машину, уменьшая устойчивость и несогласованность в задержках. This change enables end-user applications to reclaim compute cycles, which puts less load on the VM, decreasing jitter and inconsistency in latency. Иными словами, производительность может быть более детерминированной. In other words, performance can be more deterministic.

Ускоренная сеть повышает производительность, позволяя гостевой виртуальной машине обходить узел и устанавливать путь к данным непосредственно с Смартник узла. Accelerated networking improves performance by allowing the guest VM to bypass the host and establish a datapath directly with a host’s SmartNIC. Ниже приведены некоторые преимущества ускорения работы в сети. Here are some benefits of accelerated networking:

Меньше задержек и более высоких пакетов в секунду (PPS). Удаление виртуального коммутатора из пути к данных позволяет устранить время обработки политики на узле и увеличить количество пакетов, которые могут быть обработаны на виртуальной машине. Lower latency / higher packets per second (pps): Removing the virtual switch from the datapath eliminates the time packets spend in the host for policy processing and increases the number of packets that can be processed in the VM.

Снижение колебаний. обработка виртуального коммутатора зависит от объема политики, которую необходимо применить, и рабочей нагрузки процессора, выполняющего обработку. Reduced jitter: Virtual switch processing depends on the amount of policy that needs to be applied and the workload of the CPU that’s doing the processing. Разгрузка применения политики к оборудованию устраняет эту вариативность за счет доставки пакетов непосредственно на виртуальную машину, устраняя связь между узлами и виртуальными машинами и все программные прерывания и переключения контекста. Offloading the policy enforcement to the hardware removes that variability by delivering packets directly to the VM, eliminating the host-to-VM communication and all software interrupts and context switches.

Уменьшение загрузки ЦП. обход виртуального коммутатора на узле приводит к снижению загрузки ЦП для обработки сетевого трафика. Decreased CPU utilization: Bypassing the virtual switch in the host leads to less CPU utilization for processing network traffic.

Чтобы использовать функцию ускорения сети, необходимо явно включить ее на каждой применимой виртуальной машине. To use accelerated networking, you need to explicitly enable it on each applicable VM. Инструкции см. в статье Создание виртуальной машины Linux с ускорением работы в сети. See Create a Linux virtual machine with Accelerated Networking for instructions.

Масштабирование на стороне приема Receive side scaling

Масштабирование на стороне приема (RSS) — это технология сетевого драйвера, которая более эффективно распределяет получение сетевого трафика за счет распределения обработки приема между несколькими процессорами в многопроцессорной системе. Receive side scaling (RSS) is a network driver technology that distributes the receiving of network traffic more efficiently by distributing receive processing across multiple CPUs in a multiprocessor system. В простых терминах RSS позволяет системе обрабатывать более принятый трафик, так как использует все доступные процессоры, а не только один. In simple terms, RSS allows a system to process more received traffic because it uses all available CPUs instead of just one. Более техническое обсуждение RSS см. в статье Общие сведения о масштабировании на стороне приема. For a more technical discussion of RSS, see Introduction to receive side scaling.

Чтобы добиться максимальной производительности при включении ускорения работы в сети на виртуальной машине, необходимо включить RSS. To get the best performance when accelerated networking is enabled on a VM, you need to enable RSS. Кроме того, RSS может предоставить преимущества виртуальным машинам, которые не используют ускоренную сеть. RSS can also provide benefits on VMs that don’t use accelerated networking. Общие сведения о том, как определить, включена ли поддержка RSS и как ее включить, см. в статье Оптимизация пропускной способности сети для виртуальных машин Azure. For an overview of how to determine if RSS is enabled and how to enable it, see Optimize network throughput for Azure virtual machines.

TCP-TIME_WAIT и TIME_WAIT ассассинатион TCP TIME_WAIT and TIME_WAIT assassination

TCP-TIME_WAIT — это еще одна Общая Настройка, влияющая на производительность сети и приложения. TCP TIME_WAIT is another common setting that affects network and application performance. На занятых виртуальных машинах, открывающих и закрываемых многими сокетами, как клиентами, так и серверами (исходный IP-адрес: исходный порт + конечный IP-адрес: порт назначения) во время нормальной работы протокола TCP, данный сокет может находиться в TIME_WAIT состоянии в течение длительного времени. On busy VMs that are opening and closing many sockets, either as clients or as servers (Source IP:Source Port + Destination IP:Destination Port), during the normal operation of TCP, a given socket can end up in a TIME_WAIT state for a long time. Состояние TIME_WAIT предназначено для того, чтобы разрешить доставку дополнительных данных на сокет перед его закрытием. The TIME_WAIT state is meant to allow any additional data to be delivered on a socket before closing it. Таким образом, стеки TCP/IP обычно запрещают повторное использование сокета путем автоматического удаления пакета TCP SYN клиента. So TCP/IP stacks generally prevent the reuse of a socket by silently dropping the client’s TCP SYN packet.

Количество времени, в течение которого сокет находится в TIME_WAIT настраивается. The amount of time a socket is in TIME_WAIT is configurable. Может варьироваться от 30 секунд до 240 секунд. It could range from 30 seconds to 240 seconds. Сокеты являются ограниченным ресурсом, а количество сокетов, которые могут использоваться в любое заданное время, можно настроить. Sockets are a finite resource, and the number of sockets that can be used at any given time is configurable. (Как правило, число доступных сокетов равно 30 000.) Если доступные сокеты используются или если клиенты и серверы имеют несовпадающие параметры TIME_WAIT, а виртуальная машина пытается повторно использовать сокет в TIME_WAIT состоянии, новые соединения не будут выполняться, так как пакеты TCP SYN будут удалены без вмешательства пользователя. (The number of available sockets is typically about 30,000.) If the available sockets are consumed, or if clients and servers have mismatched TIME_WAIT settings, and a VM tries to reuse a socket in a TIME_WAIT state, new connections will fail as TCP SYN packets are silently dropped.

Значение диапазона портов для исходящих сокетов обычно настраивается в стеке TCP/IP операционной системы. The value for port range for outbound sockets is usually configurable within the TCP/IP stack of an operating system. То же самое справедливо и для параметров TCP TIME_WAIT и повторного использования сокета. The same thing is true for TCP TIME_WAIT settings and socket reuse. Изменение этих чисел может привести к повышению масштабируемости. Changing these numbers can potentially improve scalability. Но в зависимости от ситуации эти изменения могут вызвать проблемы взаимодействия. But, depending on the situation, these changes could cause interoperability issues. При изменении этих значений следует соблюдать осторожность. You should be careful if you change these values.

Для устранения этого ограничения масштабирования можно использовать TIME_WAIT ассассинатион. You can use TIME_WAIT assassination to address this scaling limitation. TIME_WAIT ассассинатион позволяет повторно использовать сокет в определенных ситуациях, например, если порядковый номер в IP-пакете нового соединения превышает порядковый номер последнего пакета из предыдущего соединения. TIME_WAIT assassination allows a socket to be reused in certain situations, like when the sequence number in the IP packet of the new connection exceeds the sequence number of the last packet from the previous connection. В этом случае операционная система разрешит установить новое подключение (будет принимать новое значение SYN/ACK) и принудительно закрыть предыдущее подключение, которое было в TIME_WAITном состоянии. In this case, the operating system will allow the new connection to be established (it will accept the new SYN/ACK) and force close the previous connection that was in a TIME_WAIT state. Эта возможность поддерживается на виртуальных машинах Windows в Azure. This capability is supported on Windows VMs in Azure. Чтобы узнать о поддержке других виртуальных машин, обратитесь к поставщику ОС. To learn about support in other VMs, check with the OS vendor.

Дополнительные сведения о настройке параметров TCP-TIME_WAIT и диапазона портов источника см. в разделе Параметры, которые можно изменить для повышения производительности сети. To learn about configuring TCP TIME_WAIT settings and source port range, see Settings that can be modified to improve network performance.

Факторы виртуальной сети, которые могут повлиять на производительность Virtual network factors that can affect performance

Максимальная исходящая пропускная способность виртуальной машины VM maximum outbound throughput

Azure предоставляет различные размеры и типы виртуальных машин, каждый из которых имеет разную комбинацию возможностей производительности. Azure provides a variety of VM sizes and types, each with a different mix of performance capabilities. Одной из этих возможностей является пропускная способность сети (или пропускная способность), измеряемая в мегабит в секунду (Мбит/с). One of these capabilities is network throughput (or bandwidth), which is measured in megabits per second (Mbps). Так как виртуальные машины размещаются на общем оборудовании, сетевая емкость должна быть достаточно общей для виртуальных машин, использующих одно и то же оборудование. Because virtual machines are hosted on shared hardware, the network capacity needs to be shared fairly among the virtual machines using the same hardware. Более крупные виртуальные машины выделяют больше пропускной способности, чем небольшие виртуальные машины. Larger virtual machines are allocated more bandwidth than smaller virtual machines.

Пропускная способность сети, выделяемая каждой виртуальной машине, определяет скорость передачи данных от виртуальной машины (исходящий трафик). The network bandwidth allocated to each virtual machine is metered on egress (outbound) traffic from the virtual machine. Ограничение распространяется на весь сетевой трафик, покидающий виртуальную машину, независимо от его назначения. All network traffic leaving the virtual machine is counted toward the allocated limit, regardless of destination. Например, если виртуальная машина имеет ограничение в 1 000 Мбит/с, это ограничение применяется, если исходящий трафик предназначен для другой виртуальной машины в той же виртуальной сети или один за пределами Azure. For example, if a virtual machine has a 1,000-Mbps limit, that limit applies whether the outbound traffic is destined for another virtual machine in the same virtual network or one outside of Azure.

Входящий трафик не измеряется и не ограничивается напрямую. Ingress is not metered or limited directly. Но существуют и другие факторы, такие как ограничения ресурсов ЦП и хранилища, которые могут повлиять на способность виртуальной машины обрабатывать входящие данные. But there are other factors, like CPU and storage limits, that can affect a virtual machine’s ability to process incoming data.

Ускоренная сеть разработана для повышения производительности сети, включая задержку, пропускную способность и загрузку ЦП. Accelerated networking is designed to improve network performance, including latency, throughput, and CPU utilization. Ускоренная сеть может повысить пропускную способность виртуальной машины, но она может сделать это только до выделенной пропускной способности виртуальной машины. Accelerated networking can improve a virtual machine’s throughput, but it can do that only up to the virtual machine’s allocated bandwidth.

К виртуальным машинам Azure подключен по крайней мере один сетевой интерфейс. Azure virtual machines have at least one network interface attached to them. У них может быть несколько. They might have several. Пропускная способность, выделенная виртуальной машине, представляет собой сумму всего исходящего трафика по всем сетевым интерфейсам, подключенным к компьютеру. The bandwidth allocated to a virtual machine is the sum of all outbound traffic across all network interfaces attached to the machine. Иными словами, пропускная способность выделяется отдельно для каждой виртуальной машины независимо от того, сколько сетевых интерфейсов подключено к компьютеру. In other words, the bandwidth is allocated on a per-virtual machine basis, regardless of how many network interfaces are attached to the machine.

Ожидаемая исходящая пропускная способность и число сетевых интерфейсов, поддерживаемых каждым размером виртуальной машины, подробно описаны в подразделении размеров виртуальных машин Windows в Azure. Expected outbound throughput and the number of network interfaces supported by each VM size are detailed in Sizes for Windows virtual machines in Azure. Чтобы увидеть максимальную пропускную способность, выберите тип, например Общее назначение, а затем найдите раздел, посвященный размерам на полученной странице (например, «Dv2-Series»). To see maximum throughput, select a type, like General purpose, and then find the section about the size series on the resulting page (for example, «Dv2-series»). Для каждого ряда существует таблица, которая предоставляет сетевые спецификации в последнем столбце, озаглавленном «максимальное число сетевых адаптеров/ожидаемая пропускная способность сети (Мбит/с)». For each series, there’s a table that provides networking specifications in the last column, which is titled «Max NICs / Expected network bandwidth (Mbps).»

Ограничение пропускной способности применяется ко всей виртуальной машине. The throughput limit applies to the virtual machine. На пропускную способность не влияют следующие факторы. Throughput is not affected by these factors:

Число сетевых интерфейсов. Ограничение пропускной способности применяется к сумме всего исходящего трафика от виртуальной машины. Number of network interfaces: The bandwidth limit applies to the sum of all outbound traffic from the virtual machine.

Ускоренная сеть. Хотя эта функция может быть полезна при достижении опубликованного ограничения, она не меняет этого ограничения. Accelerated networking: Though this feature can be helpful in achieving the published limit, it doesn’t change the limit.

Назначение трафика. При оценке ограничения на исходящий трафик полностью учитываются все назначения. Traffic destination: All destinations count toward the outbound limit.

Протокол. При оценке ограничения на исходящий трафик полностью учитываются все протоколы. Protocol: All outbound traffic over all protocols counts towards the limit.

Вопросы производительности в Интернете Internet performance considerations

Как обсуждалось в этой статье, факторы в Интернете и вне контроля Azure могут повлиять на производительность сети. As discussed throughout this article, factors on the internet and outside the control of Azure can affect network performance. Ниже приведены некоторые из этих факторов. Here are some of those factors:

Задержка. время приема-передачи между двумя местами назначения может зависеть от проблем в промежуточных сетях, по трафику, который не принимает «кратчайший» путь расстояния и по неоптимальным путям пиринга. Latency: The round-trip time between two destinations can be affected by issues on intermediate networks, by traffic that doesn’t take the «shortest» distance path, and by suboptimal peering paths.

Потеря пакетов: потеря пакетов может быть вызвана перегрузкой сети, проблемами физического пути и недостаточной производительностью сетевых устройств. Packet loss: Packet loss can be caused by network congestion, physical path issues, and underperforming network devices.

Размер MTU/фрагментация. Фрагментация по пути может привести к задержкам при получении данных или в пакетах, которые поступают в неопределенном порядке, что может повлиять на доставку пакетов. MTU size/Fragmentation: Fragmentation along the path can lead to delays in data arrival or in packets arriving out of order, which can affect the delivery of packets.

Traceroute — это хороший инструмент для измерения характеристик производительности сети (таких как потеря пакетов и задержка) по каждому сетевому пути между исходным устройством и конечным устройством. Traceroute is a good tool for measuring network performance characteristics (like packet loss and latency) along every network path between a source device and a destination device.

Вопросы проектирования сети Network design considerations

Наряду с рассмотренными выше соображениями топология виртуальной сети может повлиять на производительность сети. Along with the considerations discussed earlier in this article, the topology of a virtual network can affect the network’s performance. Например, конструкция типа «звезда», обеспечивающая передачу трафика глобально в виртуальную сеть с одним концентратором, приведет к задержке в сети, что повлияет на общую производительность сети. For example, a hub-and-spoke design that backhauls traffic globally to a single-hub virtual network will introduce network latency, which will affect overall network performance.

Количество сетевых устройств, через которые проходит сетевой трафик, также может повлиять на общую задержку. The number of network devices that network traffic passes through can also affect overall latency. Например, в структуре «звезда», если трафик проходит через виртуальный сетевой модуль периферийного сервера и виртуальный модуль концентратора перед передачей в Интернет, сетевые виртуальные устройства могут ввести задержку. For example, in a hub-and-spoke design, if traffic passes through a spoke network virtual appliance and a hub virtual appliance before transiting to the internet, the network virtual appliances can introduce latency.

Регионы Azure, виртуальные сети и задержка Azure regions, virtual networks, and latency

Регионы Azure состоят из нескольких центров обработки данных, которые существуют в общей географической области. Azure regions are made up of multiple datacenters that exist within a general geographic area. Эти центры обработки данных могут быть физически не рядом друг с другом. These datacenters might not be physically next to each other. В некоторых случаях они разделяются примерно на 10 километров. In some cases they’re separated by as much as 10 kilometers. Виртуальная сеть является логическим наложением поверх сети физического центра обработки данных Azure. The virtual network is a logical overlay on top of the Azure physical datacenter network. Виртуальная сеть не подразумевает какую-либо конкретную топологию сети в центре обработки данных. A virtual network doesn’t imply any specific network topology within the datacenter.

Например, две виртуальные машины в одной виртуальной сети и подсети могут находиться в разных стойках, строках или даже в центрах обработки данных. For example, two VMs that are in the same virtual network and subnet might be in different racks, rows, or even datacenters. Они могут быть разделены с помощью волоконно оптических кабелей или километрами волоконно оптического кабеля. They could be separated by feet of fiber optic cable or by kilometers of fiber optic cable. Этот вариант может привести к задержке переменных (разница в нескольких миллисекундах) между разными виртуальными машинами. This variation could introduce variable latency (a few milliseconds difference) between different VMs.

Географическое размещение виртуальных машин и потенциальная задержка между двумя виртуальными машинами могут зависеть от конфигурации групп доступности и Зоны доступности. The geographic placement of VMs, and the potential resulting latency between two VMs, can be influenced by the configuration of availability sets and Availability Zones. Но расстояние между центрами обработки данных в регионе зависит от региона и в основном зависит от топологии центров обработки данных в регионе. But the distance between datacenters in a region is region-specific and primarily influenced by datacenter topology in the region.

Нехватка исходного порта NAT Source NAT port exhaustion

Развертывание в Azure может взаимодействовать с конечными точками за пределами Azure в общедоступном Интернете и/или в пространстве общедоступных IP-адресов. A deployment in Azure can communicate with endpoints outside of Azure on the public internet and/or in the public IP space. Когда экземпляр инициирует исходящее подключение, Azure динамически сопоставляет частный IP-адрес с общедоступным IP-адресом. When an instance initiates an outbound connection, Azure dynamically maps the private IP address to a public IP address. После того как Azure создаст это сопоставление, возвращаемый трафик исходящего потока может также получить доступ к частному IP-адресу, в котором исходит поток. After Azure creates this mapping, return traffic for the outbound originated flow can also reach the private IP address where the flow originated.

Для каждого исходящего подключения Azure Load Balancer необходимо поддерживать это сопоставление в течение некоторого периода времени. For every outbound connection, the Azure Load Balancer needs to maintain this mapping for some period of time. С учетом многоклиентской природы Azure поддержание этого сопоставления для каждого исходящего потока для каждой виртуальной машины может быть ресурсоемким. With the multitenant nature of Azure, maintaining this mapping for every outbound flow for every VM can be resource intensive. Поэтому существуют ограничения, которые задаются и основываются на конфигурации виртуальной сети Azure. So there are limits that are set and based on the configuration of the Azure Virtual Network. Или, чтобы точнее сказать, виртуальная машина Azure может одновременно устанавливать определенное количество исходящих подключений. Or, to say that more precisely, an Azure VM can only make a certain number of outbound connections at a given time. При достижении этих ограничений виртуальная машина не сможет создавать больше исходящих подключений. When these limits are reached, the VM won’t be able to make more outbound connections.

Но это поведение можно настроить. But this behavior is configurable. Дополнительные сведения о нехватке портов SNAT и SNAT см. в этой статье. For more information about SNAT and SNAT port exhaustion, see this article.

Измерение производительности сети в Azure Measure network performance on Azure

В этой статье приводится ряд максимальных показателей производительности, связанных с задержкой сети и временем приема-передачи (RTT) между двумя виртуальными машинами. A number of the performance maximums in this article are related to the network latency / round-trip time (RTT) between two VMs. В этом разделе приводятся некоторые рекомендации по тестированию задержки и RTT, а также проверке производительности TCP и производительности сети виртуальных машин. This section provides some suggestions for how to test latency/RTT and how to test TCP performance and VM network performance. Вы можете настроить и протестировать производительность по TCP/IP и сетевым значениям, описанным выше, с помощью методик, описанных в этом разделе. You can tune and performance test the TCP/IP and network values discussed earlier by using the techniques described in this section. Вы можете подключать значения задержки, MTU, MSS и размера окна к представленным выше вычислениям и сравнить теоретическое максимальное значение с фактическими значениями, наблюдаемыми во время тестирования. You can plug latency, MTU, MSS, and window size values into the calculations provided earlier and compare theoretical maximums to actual values that you observe during testing.

Измерение времени кругового пути и потери пакетов Measure round-trip time and packet loss

Производительность TCP в значительной степени зависит от RTT и потери пакетов. TCP performance relies heavily on RTT and packet Loss. Служебная программа PING, доступная в Windows и Linux, предоставляет самый простой способ измерения времени приема на работу и потери пакетов. The PING utility available in Windows and Linux provides the easiest way to measure RTT and packet loss. В выходных данных проверки связи будет показана минимальная/максимальная/средняя задержка между источником и назначением. The output of PING will show the minimum/maximum/average latency between a source and destination. Она также будет показывать потери пакетов. It will also show packet loss. Проверка связи по умолчанию использует протокол ICMP. PING uses the ICMP protocol by default. Для проверки RTT TCP можно использовать PsPing. You can use PsPing to test TCP RTT. Дополнительные сведения см. в разделе PsPing. For more information, see PsPing.

Измерение фактической пропускной способности TCP-соединения Measure actual throughput of a TCP connection

NTttcp — это средство для тестирования производительности TCP виртуальной машины Linux или Windows. NTttcp is a tool for testing the TCP performance of a Linux or Windows VM. Можно изменить различные параметры TCP, а затем проверить преимущества с помощью NTttcp. You can change various TCP settings and then test the benefits by using NTttcp. Для получения дополнительных сведений см. следующие ресурсы. For more information, see these resources:

Измерение фактической пропускной способности виртуальной машины Measure actual bandwidth of a virtual machine

Можно проверить производительность различных типов виртуальных машин, ускоренной сети и т. д. с помощью средства под названием iPerf. You can test the performance of different VM types, accelerated networking, and so on, by using a tool called iPerf. iPerf также доступен в Linux и Windows. iPerf is also available on Linux and Windows. iPerf может использовать TCP или UDP для проверки общей пропускной способности сети. iPerf can use TCP or UDP to test overall network throughput. на тесты пропускной способности TCP iPerf влияют факторы, описанные в этой статье (например, задержка и RTT). iPerf TCP throughput tests are influenced by the factors discussed in this article (like latency and RTT). Поэтому UDP может дать лучшие результаты, если нужно просто протестировать максимальную пропускную способность. So UDP might yield better results if you just want to test maximum throughput.

Дополнительные сведения вы найдете в следующих статьях: For more information, see these articles:

Обнаружение неэффективных поведений TCP Detect inefficient TCP behaviors

При записи пакетов клиенты Azure могут видеть TCP-пакеты с флагами TCP (SACK, DUP ACK, повторной ПЕРЕДАЧЕй и быстрой повторной ПЕРЕДАЧЕй), которые могут указывать на проблемы с производительностью сети. In packet captures, Azure customers might see TCP packets with TCP flags (SACK, DUP ACK, RETRANSMIT, and FAST RETRANSMIT) that could indicate network performance problems. Эти пакеты специально указывают на неэффективность работы сети в результате потери пакетов. These packets specifically indicate network inefficiencies that result from packet loss. Но потеря пакетов не обязательно связана с проблемами производительности Azure. But packet loss isn’t necessarily caused by Azure performance problems. Проблемы с производительностью могут быть результатом проблем с приложениями, проблем с операционной системой или других проблем, которые могут быть не связаны напрямую с платформой Azure. Performance problems could be the result of application problems, operating system problems, or other problems that might not be directly related to the Azure platform.

Кроме того, помните, что некоторые пересылки и дублирование подтверждений в сети являются нормальными. Also, keep in mind that some retransmission and duplicate ACKs are normal on a network. Были созданы надежные протоколы TCP. TCP protocols were built to be reliable. Свидетельство этих пакетов TCP в записи пакетов не обязательно указывает на системную сетевую проблему, если они не являются избыточными. Evidence of these TCP packets in a packet capture doesn’t necessarily indicate a systemic network problem, unless they’re excessive.

Тем не менее, эти типы пакетов указывают на то, что пропускная способность TCP не достигает максимальной производительности по причинам, изложенным в других разделах этой статьи. Still, these packet types are indications that TCP throughput isn’t achieving its maximum performance, for reasons discussed in other sections of this article.

Следующие шаги Next steps

Теперь, когда вы узнали о настройке производительности TCP/IP для виртуальных машин Azure, вам может потребоваться ознакомиться с другими соображениями по планированию виртуальных сетей или дополнительными сведениями о подключении и настройке виртуальных сетей. Now that you’ve learned about TCP/IP performance tuning for Azure VMs, you might want to read about other considerations for planning virtual networks or learn more about connecting and configuring virtual networks.

Источник

Поделиться с друзьями
Советы экспертов и специалистов
Adblock
detector