No Image

Прерывается связь с сервером

СОДЕРЖАНИЕ
527 просмотров
10 марта 2020

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

1. Влияние программ

Чтобы комфортно играть, нужно всегда закрывать ненужные программы:

  1. Браузер. Браузер с массой открытых вкладок создаёт проблемы при загрузке и соединении с интернетом. Если у пользователя слабый ПК и низкая скорость интернета, то браузер будет слишком перегружать систему во время боя, что будет сказываться на многих факторах, в том числе на скорости интернета.
  2. Антивирус. Перед запуском клиента игры рекомендуется отключать антивирус, поскольку он может замедлить все процессы. Это также может стать причиной для частых потерь связи.
  3. Брандмауэр. Включённый брандмауэр, как внешний, так и внутренний, может блокировать связь при запущенной игре. Нужно отключить все брандмауэры.
  4. Торрент-клиент. Открытый торрент трекер постоянно поддерживает интернет соединение. В новых версиях появилось много рекламы, которая постоянно изображается в активном режиме. Даже без скачивания, торрент-клиент занимает большое количество оперативной памяти и мощи ЦП, что может сказываться на всех функционалах, в том числе на непрерывном соединении.

Перед запуском игры следует закрыть все ненужные программы. Самый быстрый способ это сделать при помощи диспетчера задач. Чтобы его вызвать, нужно одновременно нажать комбинацию кнопок Ctrl+Alt+Delete. В диспетчере будет находиться список запущенных приложений.

Ненужные задачи можно закрывать щелчком правой мыши «снять задачу».

Для проверки соединения необходимо закрыть все лишние программы. Если связь перестанет пропадать, тогда причина кроется среди них. Чтобы понять, какое приложение мешать играть, нужно поочерёдно запускать каждую программу и проверять. Наилучшим способом, чтобы не терять лишнее время, лучше перед запуском клиента закрывать все приложения и программы.

2. Кэш World of Tanks

Кэш игры – эта самая частая причина обрыва связи. Чтобы восстановить качество соединения, необходимо почистить кэш World of Tanks. Чтобы его почистить, нужно совершить несколько действий:

  1. Открыть окно комбинацией кнопок Win+R.
  2. В появившейся строке ввести %appdata% и нажать ОК.
  3. Откроется список папок, в котором нужно зайти в папку Wargaming.net.
  4. Удалить всё содержимое из папки.
  5. Перезапустить ПК.

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

3. Игра перестанет запускаться в случае удаления нужных файлов.

Чаще такие ситуации случаются при удалении модов. Чтобы решить эту проблему, нужно воспользоваться специальным приложением от разработчиков WGCheck.

При запуске оно просканирует все файлы и восстановит клиент.

При работе с GUI и терминальными приложениями нередко случается, что пользователь, работая в режиме удаленного доступа (как правило, через Интернет), покинув компьютер минут на 15, по возвращении обнаруживает, что программа зависла. На любое действие она отвечает ошибкой, содержащей примерно такие фразы: «Потеряна связь с сервером», "[WINSOCK] virtual circuit reset by host" и т.п. Наблюдается такое и при выполнении «долгоиграющих» методов (запросов к серверу), в которых не предусмотрен вывод прогресс-бара или какая-либо интерактивность.

Данная проблема характерна не только для GUI и терминальных решений на базе СУБД Caché и Ensemble компании InterSystems, а вообще для любого клиент-серверного взаимодействия по протоколу TCP/IP. Обычно она решается на прикладном уровне путём периодического обмена пустыми сообщениями специального вида, предназначенными лишь для того, чтобы просигнализировать о том, что приложение «живо».

Ниже о том, как можно решать эту проблему без программирования.

Источник проблемы

Источник проблемы лежит в природе протокола TCP/IP. Как правило, источник сеанса TCP/IP и его приемник находятся в различных сетях, и на пути сеанса встречается несколько маршрутизаторов. Хотя бы один из них обычно выполняет NAT-преобразование адресов. Ресурсы маршрутизатора всегда ограничены, поэтому некоторые из них выполняют очистку NAT-таблиц от «мёртвых» сеансов. Сеанс считается «мёртвым», если по нему не передавались пакеты в течение некоторого заданного интервала времени (назовем его интервал очистки). Таким образом, «молчаливый» сеанс может быть принят за «мёртвый» и вычищен из NAT-таблицы. При этом ни источник, ни приемник об этом не уведомляются («не царское дело»), и оба они остаются в уверенности, что сеанс ещё «жив» (в чем легко убедиться командой netstat, выполнив ее на клиенте или на сервере в момент возникновения ошибки, но до нажатия на ОК). Когда пользователь, получивший сообщение об ошибке, нажмет на ОК, о разрыве сеанса узнает клиент; серверный же процесс завершится, когда «умерший» сеанс распознает ОС.

Читайте также:  Microsoft xna game studio

Экспериментально установлено, что интервал очистки у многих маршутизаторов (по крайней мере, с прошитым Linux 2.4/iptables) составляет около 10 минут. Постараемся заставить наш TCP-сеанс автоматически поддерживать себя в активном состоянии, даже когда не передается никаких пакетов с данными.

Предлагаемое решение

На уровне ОС обнаружением разорванных TCP-соединений управляют следующие параметры ядра, управляющие работой механизма tcp_keepalive [1]:
tcp_keepalive_time — интервал времени с момента отправки последнего пакета с данными; по истечении этого срока соединение помечается как требующее проверки; после начала проверки параметр не используется;
tcp_keepalive_intvl — интервал между проверочными пакетами (отправка которых начинается по истечении tcp_keepalive_time);
tcp_keepalive_probes — количество неподтвержденных проверочных пакетов; по исчерпании этого счетчика соединение считается разорванным.

Надо сказать, что механизм tcp_keepalive имеет двойное назначение: он может использоваться как для искусственного поддержания активности соединения, так и для выявления разорванных (так называемых «полуоткрытых») соединений. В данной статье обсуждается в основном первое применение, о втором применении, возможно, речь пойдёт в следующей статье на эту тему.

Для того чтобы механизм tcp_keepalive был задействован для TCP-соединений, необходимы два условия:
• поддержка на уровне ОС; к счастью, и в Windows, и в Linux она имеется;
• на одном из концов соединения сокет должен быть открыт с параметром SO_KEEPALIVE. Как оказалось, сервисы Caché открывают сокеты с этим параметром, а сервис OpenSSH несложно заставить поступать аналогично.

Наибольший интерес для нас представляет первый параметр (tcp_keepalive_time), так как именно от него зависит, насколько часто будет выполняться проверка неактивных (с точки зрения отсутствия трафика) соединений. Его значение по умолчанию — и в Windows, и в Linux — равно двум часам (7200 с). Типичное же время бездействия, после которого наступает разрыв, составляет около 10 минут. Поэтому предлагается установить значение параметра в 5 минут, что позволит искусственно поддерживать активность TCP-сеансов, не перегружая сеть избыточным трафиком (5 минут — это не 5 секунд).

Установка параметров tcp_keepalive на сервере Windows

Вы должны обладать правами Администратора к серверу. В разделе реестра
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesTcpipParameters
создайте параметр DWORD с именем KeepAliveTime и значением 300000 (десятичным). Параметр задаётся в миллисекундах, поэтому предлагаемое значение — это 5 минут. После чего остановите Caché и перезагрузите сервер.

Что касается двух других параметров tcp_keepalive, то их умолчания в Windows таковы:

KeepAliveInterval
Key: TcpipParameters
Value Type: REG_DWORD—time in milliseconds
Valid Range: 0–0xFFFFFFFE
Default: 1000 (1 секунда)

KeepAliveProbes
Такого параметра (устанавливающего количество неподтвержденных проверочных пакетов), в реестре не существует. Согласно [2], в Windows 2000 / XP / 2003 в этом качестве используется значение параметра TcpMaxDataRetransmission (умолчание — 5), а в более поздних версиях [3] — фиксированное значение, равное 10. Поэтому, если менять только значение первого параметра (с 7200 на 300), сохраняя умолчание для второго, сервер Windows 2008 будет узнавать о разрыве TCP-соединения через 1*10 + 300 = 310 секунд.

Установка параметров tcp_keepalive на сервере Linux

Изменить значения параметров можно «на ходу», не перезагружая сервер. Зайдите как root и выполните:

Чтобы сделать изменение долговечным по отношению к возможным перезагрузкам сервера, проще всего отредактировать файл параметров ядра /etc/sysctl.conf, добавив в него строку (лучше две):

Обратите внимание, что в отличие от Windows, значение параметра задается в секундах.
Что касается остальных двух параметров tcp_keepalive, то их умолчания в Linux таковы:

Если менять только значение первого параметра (с 7200 на 300), сохраняя умолчания для остальных двух, сервер Linux будет узнавать о разрыве соединения только через 75*9 + 300 = 975 секунд.

Установка параметра TCPKeepAlive в конфигурации СУБД Caché

Начиная с версии 2008.2, в Caché для платформ Windows и Linux появилась возможность задавать tcp_keepalive_time на уровне сокета, что удобно, так как позволяет избежать изменения настроек операционной системы. Однако «в чистом виде» эта возможность, в основном, представляет интерес лишь для независимых разработчиков сокет-серверов. К счастью, она была дополнена параметром конфигурации TCPKeepAlive=n в секции [SQL], доступным для редактирования со страницы Портала управления системой: Конфигурация > Общие Настройки SQL. Значение по умолчанию — 300 секунд (то, что доктор прописал). Действие параметра распространяется не только на SQL, но и, как нетрудно догадаться, на любые соединения с Caché, обслуживаемые сервисом %Service_Bindings. К ним относится, в частности, и объектный доступ через CacheActiveX.Factory, поэтому если ваше приложение может использовать этот протокол в качестве транспорта, не стоит упускать такую возможность.

Читайте также:  Что такое яндекс dns

Установка параметров KeepAlive в конфигурации сервера OpenSSH

Если вы используете SSH [4] (для работы в режиме командной оболочки или как транспорт для вашего GUI-приложения), то… скорее всего, проделанной настройки ядра будет достаточно, поскольку сервис OpenSSH (по крайней мере, в версии 5.x) по-умолчанию открывает сокет с параметром SO_KEEPALIVE.

На всякий случай стоит проверить конфигурационный файл /etc/ssh/sshd_config. Найдите в нем строку

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

Протокол SSH v.2 имеет альтернативные средства контроля активности сеансов, например, с помощью настройки параметров сервиса OpenSSH ClientAliveInterval и ClientAliveCountMax.
При использовании этих параметров, в отличие от TCPKeepAlive, запросы KeepAlive отправляются через защищённый SSH канал и не могут быть подменены. Приходится признать, что альтернативные средства являются более безопасными, нежели традиционный механизм TCPKeepAlive, для которого существует опасность анализа KeepAlive-пакетов и организации DoS-атак [5].

Устанавливает время ожидания в секундах, по истечении которого, если не поступает информация со стороны клиента, sshd отправляет ему запрос отклика через защищённый канал. По умолчанию используется 0, что означает, что клиенту не будет направлен такой запрос.
Устанавливает количество запросов клиенту, которые могут быть отправлены sshd без получения на них отклика. Если предел достигнут, sshd разъединяется с клиентом и завершает сеанс. Значение по умолчанию: 3. Если вы установите значение параметра ClientAliveInterval равным 60, оставив ClientAliveCountMax без изменений, то не отвечающие ssh-клиенты будут отключены примерно через 180 секунд. При этом следует отключить механизм TCP KeepAlive, установив

Всегда ли это работает?

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

Одна из них имеет место, когда из-за низкого качества сетевого обслуживания связь может физически пропадать в течение коротких промежутков времени. Если сеанс бездействует, а связь временно пропадает и восстанавливается до того, как клиент или сервер попытаются что-то друг другу послать, то никто из них ничего «не замечает», и TCP-сеанс сохраняется. В случае периодических проверок TCPKeepAlive возрастает вероятность обращения сервера к клиенту в моменты временного исчезновения связи, что может вести к принудительным разрывам TCP-соединения. В такой ситуации можно попробовать увеличить на сервере KeepAliveInterval до 60-75 секунд (вспомнив, что в Windows умолчание — 1 секунда) при максимальном количестве повторов равным 10, в надежде, что за 10 минут любая временная сетевая проблема самоустранится. Правда, если повторные передачи будут длиться слишком долго, и окажется, что
KeepAliveTime + (KeepAliveInterval * кол-во_повторов) > 10 минут
то TCP-сеанс, несмотря на все предпринятые усилия, может быть принят за «мёртвый» и вычищен из NAT-таблицы.

Другая категория проблем связана с недостаточной пропускной способности используемых маршрутизаторов и/или каналов связи, когда при перегрузке могут теряться любые пакеты, в том числе и KeepAlive. В случае маршрутизаторов такие проблемы иногда решаются сменой прошивки (мне, например, это помогло победить Acorp ADSL XXXX), или, в худшем случае, заменой его на более производительную модель. В случае «слишком узких» каналов связи не остаётся ничего другого, кроме как их расширять.

Заключение

Предложенный подход позволяет искусственно поддерживать активность сеансов TCP/IP, по которым в текущий момент не передается никаких данных, исключительно на системном уровне, не внося каких-либо изменений в прикладной код. На сегодня он проверен и успешно используется в Caché for UNIX (Red Hat Enterprise Linux 5 for x86-64) 2010.1.4 (Build 803), Caché for Windows (x86-64) 2010.1.4 (Build 803), а также в более поздних версиях.

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

При развёртывании приложения в агрессивной среде (удалённый доступ, распределённые системы и т.д.), подумайте о реализации KeepAlive не на уровне TCP, а на уровне защищённого протокола более высокого уровня; хорошим кандидатом здесь оказывается SSH.

В этой статье мы расскажем о том, какие бывают наиболее частые проблемы с сервером, как их диагностировать, что делать в случае поломки и самое главное – как их предотвратить.

Читайте также:  Структура следование visual basic лабораторная работа

Как могут выглядеть типичные сбои сервера:

  • сервер вообще не запускается
  • проблема с загрузкой сервера – сервер запускается, но показывает “синий экран смерти” (BSOD)
  • сервер запускается, на нем загружается операционная система, но некоторые сервисы не работают (например, сайт)
  • произошел сбой связи с сервером по сети
  • сервер сильно нагревается при работе
  • постоянные перезагрузки без видимых причин
  • заметно падает скорость выполнения операций

Причины сбоя и поломок сервера, типичные неисправности:

  • Физическое отключение – вероятнее всего, причиной неисправности серверов являются проблемы с аппаратной частью или пропало электричество. В первом случае понадобится ремонт или замена отказавшей детали, быстро исправить это вряд ли получится. Во втором попробуйте сначала загрузить/перезагрузить сервер, когда электричество появится – есть шансы, что его работоспособность восстановится.
  • Сервер запускается, но находится не в сети, клиентские приложения пытаются к нему подключиться и выдают ошибку подключения к серверу – неожиданная проблема связи с сервером может возникнуть из-за неполадок в сетевой карте сервера или из-за неправильных сетевых настроек (неправильный IP-адрес, маска подсети, шлюз, проблема в сетевых протоколах). Также есть возможность, что ошибка соединения с сервером вызвана неисправностью сетевого кабеля или другого сетевого оборудования – роутера/свитча/хаба.
  • Причиной отключения сервера может быть поломка одной из комплектующих, согласно статистике, чаще всего “летят” жесткие диски HDD, материнские платы, адаптеры, процессоры.
  • Ошибки в конфигурации – многие типичные неисправности сервера являются прямым следствием ошибок в его настройке, для их устранения понадобится помощь квалифицированного системного администратора.
  • Причиной сбоя сервера может быть перегрузка системы, вызванная внутренними процессами, например, активностью пользователей или неудачно настроенным снятием резервных копий, или DOS/DDOS-атакой снаружи.
  • Запуск сервера и сбой запуска? Возможно, в этом виновен перегрев сервера.

Как устранить и предотвратить проблемы с сервером

Предотвратить поломки сервера значительно проще и дешевле, чем устранять, когда они уже проявились.

Вот несколько требований, выполняя которые вы сможете снизить вероятность отказа вашего сервера:

  • Если у вас собственная серверная, организуйте в ней качественное охлаждение и старайтесь держать ее всегда закрытой, чтобы туда не проникала лишняя пыль. Обязательно используйте источники бесперебойного питания.
  • Регулярно проводите профилактическое обслуживание серверов – чистку от пыли, замену термопасты и т.д.
  • Используйте специализированное ПО для мониторинга, чтобы отслеживать состояние сервера и вовремя заметить проблемы работы сервера.
  • У вас обязательно должно быть настроено резервное копирование и восстановление данных сервера, чтобы предотвратить потерю важной информации в случае, если сервер все же “упадет”. Регулярно делайте бекапы, а если есть возможность – используйте отказоустойчивый кластер, тогда при сбоях в работе сервера его работа будет распределена между остальными серверами в кластере.

Если несмотря на все предпринятые меры у вас все же возникли проблемы с сервером, что делать?

В некоторых случаях можно попробовать самостоятельно провести диагностику, чтобы понять, что произошло и как исправить проблемы с сервером:

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

Срочный ремонт серверов, что можно сделать

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

Например, неквалифицированная попытка восстановить данные может вместо этого окончательно их уничтожить.

Обслуживание серверов

Инженеры ГК «Интегрус» уже много лет занимаются сервисным обслуживанием и ремонтом серверов, к нам всегда можно обратиться за бесплатной консультацией, аудитом, а если понадобится – то и за срочным ремонтом серверов.

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

Комментировать
527 просмотров
Комментариев нет, будьте первым кто его оставит

Это интересно
Adblock
detector