Как сбросить стек TCP/IP в Windows 10

Интернет работает по протоколу TCP/IP. Если стек протокола TCP/IP не работает правильно в Windows 10 или любой другой операционной системе, такой как Linux или MacOS, у вас возникнут проблемы с подключением к Интернету. Лучший способ решить проблемы с Интернетом — сбросить настройки стека TCP/IP.

Это повреждение в стеке служб TCP/IP может быть вызвано различными факторами, такими как установка программного обеспечения, изменяющего сетевые настройки в Windows, вирусы и вредоносное ПО, повреждение реестра Windows и т. д.

Нет прямого способа сбросить интернет-протоколы в Windows 10. Интернет-протокол TCP/IP хранит некоторые сетевые данные локально, которые могут быть повреждены.

Если ваше Интернет-соединение не работает должным образом и вы получаете сообщение «Этот сайт недоступен», хотя Windows показывает, что вы подключены к Интернету.

Сброс стека TCP/IP возможен с помощью командной строки в Windows. Давайте пройдемся по процессу и избавим наше интернет-соединение от ошибок.

Что такое протокол TCP/IP?

Протокол управления передачей/Интернет-протокол отвечает за перенос пакетов от одного источника к месту назначения. Этот протокол включает трехстороннее рукопожатие, что означает, что перед обменом фактической информацией происходит обмен тремя пакетами между источником и целью. Это рукопожатие предназначено для установления доверия между двумя устройствами.

Многократное повторение этих рукопожатий значительно увеличит трафик в сети. Следовательно, данные кэшируются и хранятся локально, чтобы избежать ненужной транспортировки пакетов.

Более того, протокол TCP/IP работает аналогично эталонной модели OSI. Это означает, что у него есть собственный набор правил и положений, которые он устанавливает для связи между устройствами. Это называется стеком. Кэш TCP/IP относится к хранимым в устройстве данным, которые он использует для маршрутизации пакетов.

Когда и почему следует сбрасывать стек TCP/IP

Со временем Windows сохраняет кэш сетевых данных, включая IP-адреса. В системном реестре также есть параметры, которые напрямую связаны с интернет-протоколом. В любой момент они могут быть повреждены, что приведет к невозможности подключения к Интернету, даже если все остальные настройки выполнены правильно.

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

Иногда недостаточно изменить IP-адрес вашего компьютера или просто перезапустить его. Именно тогда пользователь должен прибегнуть к этому решению и сбросить свои настройки TCP / IP.

Как сбросить стек TCP/IP в Windows 10

Как мы упоминали ранее, Microsoft не предоставила простой способ сбросить интернет-протокол. Однако мы все еще можем сделать это с помощью команды netsh в командной строке.

Команду netsh можно использовать для просмотра или настройки сетевых параметров в среде Windows, указав правильные параметры.

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

1. Откройте командную строку с правами администратора.
2. Введите ipconfig /release , чтобы удалить текущие настройки IP.
   
3. Введите ipconfig /flushdns , чтобы удалить кеш DNS.
   
4. Введите netsh winsock reset для сброса кеша Windows Sockets API.
   
5. Введите netsh int ip reset , чтобы сбросить кеш стека TCP/IP. Пока не перезагружайте компьютер.
   
6. Введите ipconfig /renew , чтобы запросить новые параметры IP с сервера.
   
7. Перезагрузите компьютер.

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

Например, скрипт может выглядеть так:

Если вы по-прежнему не можете получить доступ к Интернету, вы можете полностью сбросить настройки сети Windows.

TCP/IP — это душа компьютерных сетей; без него доступ в Интернет был бы невозможен. Рекомендуется поддерживать сетевой кэш вашей системы и оптимизировать его для повышения производительности.

Инструкция по сбросу протокола актуальна для всех версий Windows. На видео заснят процесс сброса на Windows 7.

Сетевой стек windows 10

Среди распространенных проблем в Windows 10 наиболее распространены проблемы с сетевым подключением. Часто пользователи не могут подключиться к Интернету на своем ПК, даже если время установлено правильно и браузер обновлен до ​​последней версии. В таких случаях вам нужно глубоко погрузиться в Windows 10, чтобы решить основные проблемы с сетью.

В этом руководстве мы представляем вам список удобных инструментов, которые помогут исправить проблемы с сетевым подключением в Windows 10. Мы рассмотрели все, от инструментов командной строки и сброса сетевых настроек до различных средств устранения неполадок. Итак, давайте перейдем к руководству.

IPConfig

Вы можете использовать команду IPConfig, чтобы исправить большинство распространенных сетевых проблем в Windows 10. Но перед этим вам нужно открыть командную строку. Для этого нажмите поиск Windows и введите «cmd». После этого выберите «Запуск от имени администратора».

Когда откроется окно командной строки, начните вводить команды IPconfig. Первая команда ipconfig /release освобождает текущую конфигурацию IP.

После этого запустите ipconfig /renew, команду для получения новых IP-конфигураций с DHCP-сервера.

Затем вы можете очистить DNS с помощью ipconfig /flushdns. Команда удалит устаревший локальный кэш DNS с вашего ПК. С этого момента ваш компьютер будет хранить новую информацию DNS, а это значит, что вы не столкнетесь с ошибками типа «DNS_PROBE_FINISHED_NXDOMAIN» в Chrome. Если вы столкнулись с этой ошибкой, выполните эту команду, чтобы исправить ее немедленно.

Netsh

Netsh — это еще одна утилита командной строки, которая может помочь вам восстановить сетевое подключение в Windows 10. Если вы столкнулись с какой-либо проблемой в сети, эта команда поможет решить эту проблему. Запустите команду netsh winsock reset, и она сбросит весь сетевой стек на вашем ПК.

Затем перезагрузите компьютер, и на этот раз у вас не будет проблем с подключением к Интернету в Windows 10. Если вы видели ошибку «ERR_CONNECTION_RESET» в Chrome или Microsoft Edge, то, скорее всего, это должно решить проблему.

Ping не является средством устранения неполадок, но это удобная команда для проверки надежности вашей сети в Windows 10. По времени отклика вы можете определить, нужна ли вашему компьютеру диагностика сети или нет.

Просто запустите команду ping 127.0.0.1, чтобы проверить, правильно ли установлен и настроен TCP / IP на вашем ПК. Если вы получили ответ «Ошибка подключения», это означает, что вам придется сбросить всю сетевую архитектуру с помощью команды «netsh».

Устранение неполадок в сети

Если описанные выше методы не помогли, вы можете попробовать встроенное средство устранения неполадок, чтобы исправить проблемы с сетевым подключением в Windows 10.

Прежде всего, через поиск Windows найдите и выберите «Параметры устранения неполадок».

Затем нажмите «Дополнительные средства устранения неполадок».

Наконец, выберите «Подключения к Интернету», а затем нажмите «Запустить средство устранения неполадок». Инструмент обнаружит проблему и попытается исправить ее автоматически.

Также прокрутите вниз и нажмите «Сетевой адаптер». После этого запустите средство устранения неполадок, чтобы исправить большинство проблем, связанных с адаптером.

Сбросить настройки сети

Наконец, если ни один из вышеперечисленных методов у вас не работает, вам необходимо выполнить сброс всей сети в настройках Windows. Нажмите поиск Windows, затем найдите и откройте страницу настроек «Сброс сети».

Здесь нажмите «Сбросить сейчас», и Windows 10 удалит все конфигурации для DNS, DHCP, VPN, виртуальных коммутаторов, сетевых адаптеров и т. д. После этого система автоматически переустановит все конфигурации и протоколы до значений по умолчанию. Скорее всего, это исправит проблемы с сетевым подключением в Windows 10, включая ошибку сертификата SSL в Chrome.

Заключение

Таким образом, вы можете исправить ошибки связанные с сетью на вашем компьютере. Мы предложили большинство полезных инструментов командной строки, которые могут мгновенно исправить проблемы с Интернетом. Помимо этого, вы также можете попробовать некоторые встроенные средства устранения неполадок для устранения ошибок.

Тонкая настройка сетевого стека на Windows-хостах

Тонкая настройка сетевого стека на Windows-хостах

Сетевая подсистема в Windows NT прошла достаточно длительный путь – изначально являясь сетевой операционной системой, NT сразу ставила задачу предоставлять надежные, сбалансированные и эффективные сетевые решения.

Беда в том, что с точки зрения большинства админов под “настройкой сетевых параметров” понимаются видные глазом базовые минимальные пункты – как задание IP-адреса, маски и шлюза, а даже тот факт, что IP-адресов на интерфейсе может быть несколько, уже вызывает удивление.

Фактически же количество сетевых настроек в Windows NT достаточно велико, и, хорошо зная работу сетевой подсистемы, можно ощутимо улучшить работу ОС. И наоборот тоже. Поэтому данная статья обязательна к ознакомлению тем, кто хочет “покрутить параметры”.

Диспозиция

Я предполагаю, что Вы, товарищ читатель, знаете на приемлемом уровне протокол TCP, да и вообще протоколы сетевого и транспортного уровней. Чем лучше знаете – тем больше КПД будет от прочтения данной статьи.

Речь будет идти про настройку для ядра NT 6.1 (Windows 7 и Windows Server 2008 R2). Всякие исторические ссылки будут, но сами настройки и команды будут применимы к указанным ОС, если явно не указано иное.

В тексте будут упоминаться ключи реестра. Некоторые из упоминаемых ключей будут отсутствовать в официальной документации. Это не страшно, но перед любой серьёзной модификацией рабочей системы лучше фиксировать то, что Вы с ней делаете, и всегда иметь возможность удалённого доступа, не зависящую от состояния сетевого интерфейса (например KVM).

Это – первая часть статьи. Потому что настроек достаточно много. В следующей части я расскажу про другие.

Содержание

• Работаем с RSS
• Работаем с CTCP
• Работаем с NetDMA
• Работаем с DCA
• Работаем с ECN
• Работаем с TCP Timestamps
• Работаем с WSH
• Работаем с MPP

Настраиваем RSS в Windows

Аббревиатура RSS обычно ассоциируется совсем с другим, нежели с настройкой TCP. Хотя, в общем, это у всех по-разному – кто-то PHP с ходу расшифровывает как Penultimate Hop Popping, а кто-то думает, что КВД – это НКВД без первой буквы. Все люди разные. Мы будем говорить про тот RSS, который Receive Side Scaling.

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

Суть-то простая, да вот в реализации столько тонкостей, что можно написать отдельную статью. Пока это не является целью, поэтому постараюсь описать оные тонкости сжато и компактно 🙂

Для начала необходимо, чтобы сетевая карта умела формировать вышеупомянутые очереди, и умела делать это хорошо. По сути, эта задача требует от сетевой карты функционала, отдалённо напоминающего CEF (который Cisco Express Forwarding) – коммутации 3го уровня с определением и разделением отдельных потоков пакетов. Давайте попробуем разобраться на примере, как и зачем это может работать.

Допустим, у Вас есть быстрый сетевой адаптер (например, 10Гбит), и по нему к Вам приходит много данных. И эти данные хорошо разделяются на много потоков (например, когда мы ведём вебинары, на каждого слушателя идёт почти по десятку TCP-сессий, а слушателей бывает и 40). По сути, все эти потоки данных выглядят потоками только на транспортном уровне, а на сетевом сливаются в общий поток. Это, в общем, и есть работа протоколов транспортного уровня – мультиплексировать потоки данных от различных приложений на различных хостах. Но от этого нашей принимающей стороне не легче – ведь ей надо из входящего потока сформировать:

• Отдельные сессии TCP – т.е. для каждой поддерживать session state, буферы данных, состояние cwnd/rwnd, состояние sack’ов и ack’ов вообще
• Отдельные буферы для каждого фрагментированного IP-пакета
• Отдельные очереди (ведь трафик может обладать приоритетами)

И практически каждое событие во всей этой пачке сессий – это вызов прерывания и его обработка. Крайне затратно, особенно учитывая, допустим, негативный сценарий (10 гигабит поток, ip-пакеты по 1КБ). Можно даже сказать проще – ощутимое количество процентов мощности процессора (весьма дорогого, заметим) уйдёт на решение этих задач тех.обслуживания. Как с этим бороться? Да просто – пусть адаптер формирует отдельные очереди пакетов – тогда на каждую из них можно “привязать” свой процессор/ядро, и нагрузка в плане прерываний и прочего распределится. Но тут нас поджидает неочевидная проблема.

Дело в том, что просто так распределить не получится. Т.е. если мы придумаем очень простой критерий распределения (например, две очереди, четные пакеты – налево, нечетные – направо), то у нас может получиться следующая ситуация – у потоков данных часть пакетов попадёт в “четную” очередь, а часть – в “нечетную”. А в этом случае мы потеряем все возможные бонусы, возникающие при обработке непрерывного потока пакетов (обычно эти бонусы выглядят как “первый пакет обрабатываем по-полной, кэшируем все возможные результаты обработки, и все последующие пакеты обрабатываем по аналогии”). Т.е. нам надо всячески избегать ситуации, когда одному процессору придётся, обрабатывая, например, поток очень однотипных мультимедийных пакетов (какой-нибудь RTP например), пытаться “сбегать почитать” в соседнюю очередь. Скажем проще – никуда он вообще бегать тогда не будет, а придётся тогда нам выключать всяческие ускорения обработки TCP/UDP/IP-потоков, потому что работать они будут только в случае ситуации, когда весь поток однотипных пакетов обрабатывается одним ядром/процессором. А это приведёт к тому, что на процессоры придётся переводить вообще всю нагрузку по обработке сетевых данных, что с гарантией “убьёт” даже достаточно мощный CPU.

То есть, наша задача-максимум – это распределить входящие данные по нескольким отдельным очередям приёма, да так, чтобы потоки пакетов легли в очереди “целиком”, да и ещё желательно, чтобы заполнились эти очереди равномерно. Тогда мы и распределим нагрузку по процессорным ядрам, и не потеряем другие возможности по ускорению обработки потоков пакетов. Для решения этой задачи нам надо будет действовать сообща – и ОС, и оборудованию.

Хороший RSS начинается с сетевой карты. В сетевых картах, которые умеют RSS (а уже понятно, что это не карты минимального уровня), такой функционал есть – например в очень даже недорогой Intel 82576 (в моём случае – встроена в сервер) есть функционал и включения RSS сразу, и выбора количества очередей – 1, 2, 4 или 8.

Почему же количество очередей RSS будет выбираться из целочисленных степеней двойки? Тут начинается интересное, что будет роднить логику работы RSS и, допустим, логику балансировки у etherchannel.

Примечание: Разные реализации RSS используют разную логику, поэтому тут рассматривается достаточно распространённый вариант

Дело в том, что для того, чтобы определить “принадлежность” пакета к потоку, RSS использует следующую логику – берутся несколько ключевых полей пакета – SRC IP, DST IP, код протокола L4, SRC PORT, DST PORT – и от них вычисляется хэш, по последним битам которого (соответственно, для 2х очередей достаточно и одного бита, для 4х – двух, для 8 – трёх) и определяется принадлежность пакета к буферу. Соответственно, пакеты одного протокола, идущие с одного фиксированного порта и IP-адреса на другой адрес и порт, будут формировать поток и попадать в одну очередь. Такой подход достаточно быстр и прост с точки зрения балансировщика, но, как понятно, никак не решает ситуацию “Есть два стула две TCP-сессии – одна 1% канала занимает, другая 99%”. И даже не гарантирует, что обе эти сессии не попадут (с вероятностью 1/2) в одну и ту же очередь, что вообще превратит всю задачу в бессмыслицу.

Поэтому, в общем-то, остановимся на следующем факте – если у сетевой карты есть поддержка RSS, то её надо как минимум включить, чтобы первичное разделение входящего трафика на несколько очередей, притом с сохранением потоков, происходило без участия CPU.

Ну а вот дальше – уже задача операционной системы – что есть не один, а несколько потоков, и на каждый надо выделить свой процессор или ядро. Это как раз и будет тот самый RSS, который мы будем включать. Он уже будет создавать в драйвере NDIS отдельные очереди и выделять на каждую из них по процессору/ядру.

Нововведением в Windows Server 2008 R2 является то, что этим можно управлять – правда, только через реестр. В частности, управлению будут поддаваться 2 параметра – стартовое количество процессорных ядер, выделяемое для всех RSS-очередей на адаптере, и максимальное количество ядер для данной задачи. Параметры эти будут находиться по адресу HKLM\SYSTEM\CurrentControlSet\Control\Class\гуид сетевого адаптера\номер сетевого адаптера\ и называться, соответственно, *RssBaseProcNumber и *MaxRSSProcessors.

Примечание: Звёздочка в начале – не опечатка, так и надо вводить. Параметры, как понятно, 32bit DWORD.

Примечание: У RSS в Windows Server 2008 R2 есть негативный момент – распределение потоков идёт только между ядрами без HT/SMT. То есть на процессорах с Hyper Threading делите количество доступных ядер пополам.

Пример использования данных параметров – допустим, у Вас есть сервер с 16 ядрами (2 процессора по 8 ядер или 4 по 4 – не суть). Есть три сетевых адаптера – один используется для управления системой, два других – для привязки к ним виртуальных машин. Вы можете выставить указанные параметры только у двух интерфейсов, на которых будет подразумеваться высокая нагрузка, притом следующим образом – поставить RssBaseProcNumber равным 2, а MaxRSSProcessors – например, 12. Тогда тот интерфейс, который будет активнее принимать трафик, сможет “отъесть” до 12 ядер системы на обработку очередей, при этом не надо будет жестко задавать этот параметр вручную (это удобно, если нагрузка переместится на другой интерфейс). Безусловно, в этом примере надо, чтобы сетевые адаптеры тоже поддерживали RSS, и, желательно, хотя бы очередей 8.

Подводя итоги – RSS – это достаточно практичная и нужная технология, требующая поддержку и со стороны оборудования, и со стороны операционной системы. И становящаяся всё более актуальной, так как на данный момент скорости сетевых интерфейсов растут, равно как и количество процессорных ядер, а, следовательно, старый подход, когда одно ядро “разгребает” единую входящую очередь, становится всё менее эффективным.

Как включить RSS в Windows

Настраиваем логику алгоритма контроля перегрузки (CTCP) в Windows

Compound TCP – это Microsoft’овский протокол управления “окном перегрузки” (congestion window). Адресно предназначен для форсированного изменения окна при работе в сетевых средах с относительно большой задержкой (например, по WiMax или спутниковым каналам). Соответственно, не сильно полезен в сценарии широкополосного доступа в Интернет или работе по локальной сети.

По сути, всё, что он делает, это форсирует быстрое увеличение окна со стороны отправителя в случае, если обнаруживается, что сеть имеет малое время отклика, и быстро уменьшает окно в случае задержек на канале.

Примечание: Не путайте Congestion Windows (CWND) и Receive Windows (RWND). Это разные параметры TCP-сессии с разной логикой обработки

Как включить CTCP в Windows

Настраиваем использование NetDMA в Windows

NetDMA – достаточно интересная функция. Смысл её применения есть тогда, когда у Вас не поддерживается Chimney Offload и Вы хотите ускорить обработку сетевых подключений. NetDMA позволяет копировать без участия CPU данные (в общем, как и любой DMA-доступ) из приемных буферов сетевого стека сразу в буферы приложений, чем снимает с CPU данную задачу по тупому выполнению чего-то типа rep movsd .

Говоря проще, если Ваша сетевая плата не может “вытащить” на себя полную обработку TCP-соединений, то NetDMA хотя бы разгрузит процессор от самой унылой части задачи по обслуживанию сетевых соединений – копированию данных между сетевой подсистемой и использующими её приложениями.

Что нужно для включения NetDMA в Windows

Нужно оборудование, которое поддерживает NetDMA – в случае Windows это процессор с поддержкой технологий семейства Intel® I/O Acceleration Technology (I/OAT), которые, в свою очередь, входят в Intel Virtual Technology for Connectivity (VT-c). Включение NetDMA на оборудовании AMD эффекта, увы, не принесёт – не поверив, проверил на домашнем феноме 1055T – действительно, NetDMA не включается.

Как включить NetDMA в Windows

Локально:

Через Group Policy:

Откройте ключ HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\ , создайте в нём параметр EnableTCPA вида 32bit DWORD и поставьте его в единицу

Секретный уровень

Если Вы дочитали до этого места, то дальше не читайте – опасно. Но вообще, в том же ключе – HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\ – есть параметр MinPacketSizeToDma , тоже типа 32bit DWORD , который, что и логично, исходя из его названия, указывает минимальный размер пакета, для которого имеет смысл инициировать DMA-передачу. Параметр данный выставляется автоматически и его тюнинг имеет слабый практический смысл – т.е. в принципе можно представить ситуацию, когда система поставит слишком малый параметр, и будет слишком часто переключаться на DMA, а Вы это поправите вручную, но очень слабо могу представить себе КПД этой операции – выяснять сие путём достаточно кропотливых синтетических тестов, чтобы выиграть призрачные доли процента на единственной операции в единственной подсистеме, притом доли эти будут укладываться в погрешность измерений, весьма уныло.

Настраиваем использование DCA (прямого доступа к кэшу NetDMA) в Windows

По сути, Direct Cache Access – это дополнение к NetDMA, которое появляется только в NetDMA 2.0 и является опциональным (т.е. факт наличия NetDMA не говорит о том, что DCA будет работать). Задачи, которые решает DCA, просты – он “привязывает” конкретную сетевую сессию к определённому ядру процессора, и позволяет копировать данные не по трассе “сетевой интерфейс”->”оперативная память”->”кэш процессора”, а напрямую с сетевого интерфейса в кэш процессора. В ряде сценариев (быстрая сеть и много сессий и ядер CPU) выигрыш может быть ощутимым – судя по исследованиям IEEE за 2009й год, в случае загруженной на

80% 10Gbit сети плюс 12ти ядер нагрузка CPU падает примерно на треть.

Технология работоспособна для гигабитных и более быстрых сетевых адаптеров. И, как понятно, имеет смысл только в случае, когда сетевой адаптер не умеет Chimney Offload (что, в общем-то, уже достаточно сложно – в случае наличия нагрузки, при которой DCA эффективен, обычно используются сетевые адаптеры, которые на аппаратном уровне умеют обрабатывать TCP).

Кстати, интересный момент – DCA есть в Windows Server 2008, но не работает в Vista. В NT 6.1 работает везде, включая Windows 7.

Как включить DCA в Windows

Локально:

Через Group Policy:

Откройте ключ HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\ , создайте в нём параметр EnableDCA вида 32bit DWORD и поставьте его в единицу

Настраиваем уведомления о перегрузке (ECN’ы) в Windows

Технология ECN в явном виде относится и к IP, а не только к TCP, но все равно про неё стоит тут написать.

Протокол IP изначально не особо любил технологии класса Quality of Service – QOS, поэтому в заголовке IPv4 выделен байт с целью “использовать для целей управления качеством”. Притом этот байт может содержать данные в разных форматах, и то, как его интерпретировать, решает конкретный хост. Используется два возможных формата данного байта – DSCP (он же DiffServ) и IP Precedence. По умолчанию этот байт (называющийся ToS – Type of Service) обрабатывается как IP Precedence и представляет собой копию данных канального уровня (в него копируются три бита от CoS – Class of Service, которые передаются в 802.3 кадре в составе 802.1p компонента заголовка 802.1Q).

Кратко, чтобы не запутаться раньше времени:
QoS – общее название семейства технологий, занимающихся классификацией сетевых данных.
ToS – поле размером в 1 байт в заголовке IPv4, которое предназначено для записи туда вспомогательных данных QoS.
802.3 – “код” протоколов семейства Ethernet.
CoS – поле размером 3 бита в заголовке 802.1Q (это поле имеет собственное название – 802.1p), которое содержит числовой код приоритета пакета (от 0 до 7, что логично).
802.1Q – дополнительный заголовок канального уровня, добавляемый в 802.3 (да и не только туда, а и, допустим, в 802.11 (WiFi)), чтобы передавать данные о принадлежности кадра к VLAN и данные о классе обслуживания.
IP Precedence – логика прочтения поля ToS в заголовке IP-пакета, когда первые 3 бита определяют относительный приоритет данного пакета перед другими (т.е. пакет со значением 2 в этом поле является всегда более приоритетным для обработки, чем пакет со значением 1).

Но нас будет интересовать ситуация, когда в заголовке IP-пакета – в поле ToS, разумеется – данные интерпретируются в формате DSCP. В этом случае на номер класса трафика отдаётся 6 бит (что даёт возможность сделать в организации 2^6 = 64 класса трафика и удобно управлять приоритетами), а оставшиеся 2 бита отдаются как раз на сигнализацию о “заторах”.

Говоря проще, если у промежуточного устройства буфер пакетов близок к перегрузке, то оно сигнализирует Вам, отправляя служебный пакет на IP отправителя, что “пакеты скоро будет некуда девать и придётся их выбрасывать, притормози”. Отправляет их, выставляя как раз специфические биты в поле ToS. Соответственно, включая поддержку данной технологии, Вы будете включать и возможность генерации подобных пакетов, и возможность анализа оных.

Простейший пример ситуации, в которой это поможет – на пути Вашего трафика стоит маршрутизатор, который в Вашу сторону смотрит интерфейсом со скоростью 1 Gbit, а дальше – интерфейсом со скоростью 100 Mbit. Если Вы будете отдавать ему трафик с максимально возможной скоростью, то его очередь пакетов, пытающихся “выйти” через интерфейс со скорость 100 Mbit, очень быстро переполнится, и если он не сможет Вам об этом сказать (ну или если Вы не включите со своей стороны возможность услышать эти сообщения от него), то ему придётся просто в определённый момент перестать принимать пакеты, сбрасывая их. А это приведёт к тому, что начнётся потеря данных, которые надо будет восстанавливать – а служебный трафик при восстановлении данных достаточно значителен. Т.е. гораздо проще передать чуть медленнее, чем потерять много пакетов и выяснить это на уровне TCP-подключения, после чего запрашивать их повторно, теряя время и тратя трафик.

Кстати, проверить поддержку ECN ближайшим маршрутизатором можно бесплатной утилитой Internet Connectivity Evaluation Tool.

Как включить ECN в Windows

Примечание: Включится и описаный выше механизм ECN, и его специфичная часть, использующая TCP

Настраиваем TCP Timestamps (по RFC 1323) в Windows

TCP Timestamps – базовая низкоуровневая технология, которая позволяет стеку TCP измерять два важных параметра для соединения: RTTM (задержку канала) и PAWS (защита от дублирующихся TCP-сегментов). В случае, если TCP Timestamps не включены хотя бы с одной стороны подключения, оба механизма вычисления этих параметров отключены и система не может высчитать данные значения. Это приводит к тому, что становится невозможным быстро и эффективно менять размер окна TCP (без знания времени задержки на канале-то). Поэтому включать TCP Timestamps в случае работы с большими объёмами данных (например, обращение к быстрому серверу в локальной сети – типовой сценарий корпоративной LAN) необходимо – ведь иначе протокол TCP не сможет быстро “раскачать” окно передачи.

Как включить TCP Timestamps в Windows

Побочные эффекты включения TCP Timestamps в Windows

Практически не наблюдаются. Рост локальной загрузки CPU отсутствует, т.к. алгоритм достаточно прост, рост объёмов служебного трафика – так же (RTTM высчитывается, исходя из “времени оборота” обычных сегментов TCP, а не каких-то специальных дополнительных).

Настраиваем автоматический подбор размера окна TCP (WSH) в Windows

Данный параметр достаточно прост. Эта настройка – Window Scale Heuristic – говорит о том, будете ли Вы сами выбирать логику поведения протокола TCP для выбора размеров окна, либо отдадите это на усмотрение операционной системе.

Примечание: WSH – это именно Window Scale Heuristic (т.е. эвристика масштабирования ОКНА, которое окно TCP), а не Windows Scale Heuristic (эвристика масштабирования продукта фирмы Microsoft под названием Windows).

То есть при включенном алгоритме WSH вышеупомянутый тюнинг окна TCP – выбор между disabled/highlyrestricted/restricted/normal/experiemental – будет делаться автоматически и Ваша настройка параметра autotuninglevel будет просто игнорироваться. При просмотре будет появляться служебное окно с текстом «The above autotuninglevel setting is the result of Windows Scaling heuristics overriding any local/policy configuration on at least one profile» .

Как включить Window Scaling Heuristic в Windows

Настраиваем базовую безопасность TCP (параметр Memory Pressure Protection) в Windows

Данная функция предназначена для защиты от достаточно известной атаки – локального отказа в обслуживании, вызванного тем, что удалённый атакующий инициирует множество TCP-сессий к нашей системе, система выделяет под каждую сессию буферы и оперативная память, возможно, заканчивается (ну или просто забивается до степени, когда начинается свопинг и производительность ощутимо падает.

Параметр включен по умолчанию в Windows Server 2008 R2, поэтому обычно нет смысла его настраивать, но если что – Вы можете его включить вручную. Более того, Вы можете выбрать, на каких портах эту защиту включать, а на каких – нет. Это имеет смысл, если доступны снаружи лишь некоторые порты, а не все.

Как включить Memory Pressure Protection в Windows

Включение MPP для отдельного порта (например, у нас наружу опубликован веб-сервер)

Выключение MPP для всех портов, кроме указанного (например, кроме LDAP)

Дополнительно

На самом деле, можно включать или выключать MPP для протоколов IP разных версий отдельно, а не глобально для всех. Для этого будут два ключа реестра с предсказуемыми названиями:

Параметр EnableMPP в каждом из случаев имеет тип 32bit DWORD и ставится либо в единицу, либо в нуль.

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

Данный краткий обзор части возможностей настроек сетевой подсистемы Windows имеет собой цель не побудить к немедленной правке всего вышеупомянутого, а показать то, что в данной ОС присутствует достаточно много инструментов тюнинга, хорошее знание которых может очень позитивно повлиять на работу системы. Только надо учитывать, что хорошее знание – это не “какая утилитка какие ключики правит”, а в первую очередь – отличное знание базовых сетевых технологий, которое, увы, сейчас в сообществе специалистов по Windows встречается крайне редко. Но я верю, что у Вас, при надлежащем системном подходе, всё будет хорошо.

UPDATE

Зайдите на сайт под своей учётной записью, чтобы видеть комментарии под техническими статьями. Если учётной записи ещё нет — зарегистрируйтесь, это бесплатно.

Обновления личного кабинета — доступны также по RSS.

• 4 апреля: Образ Kali Linux 21.01 с обновлениями за апрель 2021
• 4 апреля: Минималистичный образ Debian Linux 10.9 с обновлениями за апрель 2021
• 4 апреля: Рабочий образ нового Windows Server 2022
• 4 апреля: Специальный образ старого Windows Server 2003 R2
• 4 апреля: Обновлённые образы Windows Server 2019
• 8 января: Образ Ubuntu Server 21.04 (hirsute hippo) с предустановленными инструментами разработчика и Kali Linux 2021 с браузерами Chrome/Firefox — соответственно серверная и клиентская часть для грядущих вебинаров по HTTP/TLS/Security
• 4 января: Январское обновление домашней лабы — с QEMU 5.2.0 и всякими другими интересностями (подробнее см. новость на сайте)
• 2 января: Новый год — новый дизайн личного кабинета. Если найдёте ошибки — пишите, поправим.
• 26 декабря: Обновлённый образ CentOS (8.2 -> 8.3) и Kali с апдейтами за декабрь 2020
• 25 декабря: Образы Ubuntu Server 20.10 и VMware ESXi 7.0 U1c

Новое в архиве Knowledge Assurance. Часть из этих записей доступна бесплатно, на нашем канале YouTube.

• HCIA 2.5 — Первый модуль курса Huawei HCIA Routing and Switching
• AT-NETLAB — Обновлённый вебинар по созданию и настройке домашней лабы
• Cisco SPNGN1 1.0 — CCNA Service Provider (последнее прочтение) занятие 7
• Cisco SPNGN1 1.0 — CCNA Service Provider (последнее прочтение) занятие 6
• Cisco SPNGN1 1.0 — CCNA Service Provider (последнее прочтение) занятие 5
• Cisco IINS 3.0 — Шестое занятие CCNA:Security 2020
• Cisco SPNGN1 1.0 — CCNA Service Provider (последнее прочтение) занятие 4
• Cisco SPNGN1 1.0 — CCNA Service Provider (последнее прочтение) занятие 3
• AT-NETLAB — Вебинар по созданию и настройке домашней лабы
• Cisco IINS 3.0 — Пятое занятие CCNA:Security 2020