Подключение к учетным записям на моем VPS зависает до 20 секунд перед установкой подключения

Чтобы проверить, является ли это проблемой DNS или TCP-соединения, я бы установил tcpdump на сервере, Wireshark на вашем клиенте и проведите некоторые измерения самостоятельно. Это требует некоторых навыков работы с консолью, но попробовать стоит.

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

Вся эта публикация основана на предположении, что это либо проблема тайм-аута обратного просмотра DNS, либо более глубокая проблема в сети.

После установки tcpdump, выясните, через какой физический сетевой интерфейс HTTP-запросы попадают на ваш сервер. Затем определите общедоступный IP-адрес машины, с которой вы работаете - это необходимо, чтобы отфильтровать нежелательный шум, если вы запустите тест соединения.

Назовем IP-адрес вашего сервера A и IP-адрес вашего клиента B.

Предполагая, что интерфейс, содержащий IP-адрес этого виртуального хоста, называется eth0ты должен бежать tcpdump как пользователь root как это:

# tcpdump -n -s 1500 -w /tmp/tcpdump.pcap -i eth0 \(host A and host B and tcp port 80\) or udp port 53

(заменить A и B с вашими IP-адресами; если вы используете https вместо того http заменить tcp port 80 с участием tcp port 443)

Программа запустится и захватит весь трафик между вашей клиентской машиной и вашим сервером, а также пакеты DNS (боюсь, почти все из них, но мы вернемся к этому позже) и сохраним содержимое в файле /tmp/tcpdump.pcap.

Затем запустите свой запрос. После того, как вы заметили проблему, вернитесь к консоли и остановитесь. tcpdump нажав CTRL+C.

Теперь предлагаю вам установить программу Wireshark на вашем клиентском компьютере для более глубокого анализа.

После установки загрузите файл со своего сервера на клиентский компьютер и загрузите файл в Wireshark через File -> Open.

Чтобы проверить правильность установления связи TCP, найдите первые три пакета. Если перехват сетевого трафика прошел успешно, найдите первый пакет с TCP SYN установлен флаг. Отметьте это с помощью мыши и выберите Analyze -> Follow TCP Stream чтобы отфильтровать это единственное TCP-соединение (мы делаем это, потому что обычно у вас будет довольно много TCP-соединений от одного запроса к веб-серверу, но пока мы хотим рассмотреть только одно).

Окно откроется, просто закрой его снова, нам это не нужно. Теперь выделите первый пакет и выберите Edit -> Set time reference (Toggle). Это сделает все временные метки во всем окне относительно первого помеченного вами пакета, чтобы мы могли проверить, в порядке ли время. Также установите View -> Time Display Format -> Seconds since previous displayed packet если это не по умолчанию.

Посмотрите на первые четыре пакета. Вы заметите, что у них будут установлены определенные TCP-флаги:

1. Первый пакет от вашего клиента к серверу имеет SYN установлен флаг.
2. Второй пакет от вашего сервера к клиенту имеет SYN и ACK установлен флаг.
3. Третий пакет от вашего клиента к серверу имеет только ACK установлен флаг.
4. В четвертом пакете теперь будет ваш первый HTTP GET запрос.
5. Пятый пакет - это сервер ACKпри условии, что HTTP GET был получен
6. Пакет sixt - это первые данные, которые приходят
7. И это даже больше данных; если вы посмотрите в нижнюю часть Wireshark, вы увидите содержимое.

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

Вы можете видеть, что все эти пакеты очень внимательно следуют друг за другом, их разделяют всего сотни миллисекунд. Если это ваш случай, TCP-соединение работает само по себе, и мы более подробно рассмотрим DNS. Но если это не Хорошо для вас, если вы видите длительные задержки или даже повторные передачи TCP или сообщения о «дублировании ACK» и т. П., Тогда вам нужно изучить более глубокую сетевую проблему. Тогда вернитесь к своему VPS-провайдеру.

Однако, если все в порядке, мы смотрим на DNS. Для этого мы хотим проверить следующий факт:

• Своевременно ли отвечает DNS-сервер на вопросы?
• Какой именно вопрос DNS вызывает проблемы?

Я буду следовать следующему гипотезу:

• Сервер видит IP-адрес вашего клиента и хочет узнать его DNS-имя.
• Для этого он отправит так называемый IN PTR вопрос к серверу имен
• Я мог представить, что этот так называемый «поиск с уважением» либо не работает, либо сервер имен медленно отвечает.

Итак, теперь вам нужно немного перетасовать числа. Предположим, что IP-адрес вашего клиента 1.2.3.4. Сейчас обеспечить регресс число (4.3.2.1) и добавьте суффикс .in-addr.arpa к нему. Теперь вы создали правильный запрос для Wireshark. в Filter-поле, скажем:

dns.qry.name == "4.3.2.1.in-addr.arpa"

В приведенном ниже примере я запрашивал полное имя моего сервера на 78.47.204.196, поэтому мой фильтр dns.qry.name == "196.204.47.78.in-addr.arpa":

В моем случае вы видите интересный эффект. Мой сервер имен в 192.168.1.1 не ответил достаточно быстро, на вкус моего клиента, поэтому он отправил другой запрос, но на этот раз с использованием IPv6. Однако на самом деле это не имеет значения, он просто отправит тот же запрос снова, если у вас нет IPv6. Вы видите, что настоящий ответ - yalla.hackers-r-us.org - приходит через 2,96 секунды после запроса. Это медленно, но ответ есть.

Вы знаете, что необходимо проверить следующее:

• Приходит ли вообще ответ на запрос?
• Как часто один и тот же вопрос задается снова и снова?

Если вы видите, что запрос снова и снова отправляется снова в течение 30 секунд, вы знаете, что это проблема DNS.

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

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

Вы можете попробовать изменить DNS-серверы VPS на 8.8.8.8 и 8.8.4.4 (Открытые DNS-преобразователи Google), чтобы увидеть, улучшит ли это положение вещей. В качестве альтернативы спросите у провайдера VPS его локальные настройки DNS и убедитесь, что они правильно установлены в /etc/resolv.conf (или там, где эти настройки находятся в WHM / cPanel).

Если бы вы подключались к хосту через SSH, я бы согласился с предложением DNS. Однако в этом случае вы просто проверяете задержку для обслуживания HTTP-запроса.

Глядя на первый сайт в браузере Chrome, я получаю такую ​​информацию о задержке, как:

2,04 с (загрузка: 2,04 с, DOMContentLoaded: 1,42 с)

Второй сайт:

4,59 с (загрузка: 4,40 с, DOMContentLoaded: 4,21 с)

Еще один инструмент, который мне нравится использовать, - это проверка хоста.

Сайт 1:

http://check-host.net/check-report/1dc3fb

Сайт 2:

http://check-host.net/check-report/1dc3fa

Некоторые другие вещи сразу же на сайте 1:

www.google-analytics.com

Сайт 2:

https://twitter.com/statuses/user_timeline/spare_brain.json?callback=twitterCallback2&count=5

Могу я также предложить зарегистрироваться в фантастических инструментах Google для веб-мастеров:

https://www.google.com/webmasters/tools/home?hl=en