медленное время загрузки страниц посещают в первый раз

У меня есть человечность 18.04 на ноутбуке HP Omen.

Я заметил, что каждый раз, когда я посещаю веб-сайт, который я не посетил прежде или я не посетил в течение прошлых часов, которые требуется слишком много секунд для загрузки (2-5sec). После того, как первый раз, если я посещаю позже его, занимает 'нормальное' (0.1-0.5sec) время.

Что я попробовал/к быть упомянутым:

  • Я протестировал его и на Chrome и на Firefox с той же проблемой об обоих.
  • беспроводная связь и соединенный проводом тест: та же проблема происходит.
  • Я отключил аппаратный акселератор от хрома и не сделал помог.
  • другой компьютер, работающий на той же сети с окнами OS, не имеет этой проблемы.

И некоторые тесты (слушающий совет heynnema):

time host www.booking.com

Когда рабочее вышеупомянутое в первый выполненный раз (2,4 секунды)

real    0m2,410s
user    0m0,010s
 sys    0m0,000s

Выполнение его снова (0,01 секунды):

real    0m0,011s
user    0m0,000s
 sys    0m0,010s

Протестированный также на других веб-сайтах, где я видел некоторое достижение даже 6seconcs при выполнении в первый раз.

Edit1

Также:

ls -al /etc/resolv.conf
lrwxrwxrwx 1 root root 39 Σεπ   3 21:00 /etc/resolv.conf -> ../run/systemd/resolve/stub-resolv.conf

и:

cat /etc/resolv.conf
# This file is managed by man:systemd-resolved(8). Do not edit.
#
# This is a dynamic resolv.conf file for connecting local clients to 
the
# internal DNS stub resolver of systemd-resolved. This file lists all
# configured search domains.
#
# Run "systemd-resolve --status" to see details about the uplink DNS 
servers
# currently in use.
#
# Third party programs must not access this file directly, but only 
through the
# symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a 
different way,
# replace this symlink by a static file or a different symlink.
#
# See man:systemd-resolved.service(8) for details about the supported 
modes of
# operation for /etc/resolv.conf.

nameserver 127.0.0.53
options edns0

и:

ip addr | grep mtu
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
3: wlo1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
4: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default 
5: br-44cc05437844: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default 
6: br-a928e5f9d267: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default

и /etc/systemd/resolved.conf:

# /etc/nsswitch.conf
#
# Example configuration of GNU Name Service Switch functionality.
# If you have the `glibc-doc-reference' and `info' packages installed, 
try:
# `info libc "Name Service Switch"' for information about this file.

passwd:         compat systemd
group:          compat systemd
shadow:         compat
gshadow:        files

hosts:          files mdns4_minimal [NOTFOUND=return] dns myhostname
networks:       files

protocols:      db files
services:       db files
ethers:         db files
rpc:            db files

netgroup:       nis

и /etc/systemd/resolved.conf:

#  This file is part of systemd.
#
#  systemd is free software; you can redistribute it and/or modify it
#  under the terms of the GNU Lesser General Public License as published by
#  the Free Software Foundation; either version 2.1 of the License, or
#  (at your option) any later version.
#
# Entries in this file show the compile time defaults.
# You can change settings by editing this file.
# Defaults can be restored by simply deleting this file.
#
# See resolved.conf(5) for details

[Resolve]
#DNS=
#FallbackDNS=
#Domains=
#LLMNR=no
#MulticastDNS=no
#DNSSEC=no
#Cache=yes
#DNSStubListener=yes

Edit2

Также использование ответа от Использования завихряется для обнаружения, какая часть процесса загрузки веб-сайта дает Вам проблему (использовал www.booking.com для примера ниже), у меня есть следующий результат:

  DNS lookup                          :  6,516376
  Connect to server (TCP)             :  6,718620
  Connect to server (HTTP/S)          :  0,000000
  Time from start until transfer began:  6,718712
  Time for redirection (if any)       :  0,000000
  Total time before transfer started  :  6,950434

         Total time                   :  6,950476
         Size of download (bytes)     :  0
         Average d/l speed (bytes/s)  :  0,000

Кажется, что поиск DNS берет самое длинное.

Какая-либо идея, почему это происходит?Спасибо

Edit3

Я создал новый resolv conf файл resolv8.conf в /run/systemd/resolve со следующей внутренней частью (Google DNS):

nameserver 8.8.8.8
nameserver 8.8.4.4

и новая символьная ссылка:

sudo ln -s /run/systemd/resolve/resolv8.conf /etc/resolv.conf

и теперь host -v .. и синхронизации поиска DNS разумны. Однако существует 'сопутствующий ущерб'. В каждом перезапуске я освобождаю resolv8.conf файл, таким образом, я должен переписать его и создать новую символьную ссылку снова. Также с этими изменениями хромовый просмотр обычно работает, но не Firefox, где я не могу получить доступ ни к какому веб-сайту (?? возможно, я должен сделать что-то с networkManager?).

Я, которого не получают tottaly, почему более быстро теперь все же.

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

Edit4

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

enter image description here

0
задан 4 December 2019 в 14:36

1 ответ

Ваша проблема с установкой MTU для Вашего соединения DSL.

Существует установка MTU в конфигурации сети Ubuntu и установка WAN MTU в Вашем маршрутизаторе.

Для DSL общая установка MTU является 1492. Просто разрешение и попытка, которую видит это значение сначала и доступны ли Ваши веб-сайты теперь.

Для определения корректной установки запустите со всех настроек MTU = 1500 и VPN = прочь. (VPN требует другого тестирования).

В терминале:

  ping [-c количество] [-M делает] [-s packet_size] [хост]

Используемые опции:

  • c count: количество раз для проверки с помощью ping-запросов
  • M hint: Избранный Путь стратегия Исследования MTU. может быть также do (запретите фрагментацию, даже локальную), want (сделайте исследование PMTU, фрагмент локально, когда размер пакета будет большим), или dont (не устанавливайте флаг DF).
  • s packet_size: Указывает число байтов данных, которые будут отправлены.

Необходимо всегда запускать в 1472 и прокладывать себе путь вниз к 10 каждым разам. После того как Вы получаете ответ, поднимаетесь на 1, пока Вы не получаете фрагментированный пакет. Примите, который значение (длятся хорошее значение) и добавляет 28 к значению для составления различных заголовков TCP/IP. Например, скажем, тот 1452 был надлежащим размером пакета (где Вы сначала получили ответ ICMP на свой ping). Фактический размер MTU был бы 1480, который является оптимумом для сети, с которой мы работаем.

  -c 4-M ping делает-s 1472 8.8.8.8 #, которые это, вероятно, покажет фрагментации

  -c 4-M ping делает-s 1462, который 8.8.8.8 # могут показать фрагментации

  -c 4-M ping делает-s 1452 8.8.8.8 # никакая фрагментация?

  -c 4-M ping делает-s 1453 8.8.8.8 # все еще никакая фрагментация?

ссылка: [Как определить надлежащий размер MTU с ping ICMP] [1]

 [1]: http://muzso.hu/2009/05/17/how-to-determine-the-proper-mtu-size-with-icmp-pings

Обновление № 1:

Мы должны проверить, имеют ли Ваши серверы DNS проблему с options edns0 в/etc/resolv.conf.

/etc/resolv.conf символьная ссылка, которая переходит к одному из трех мест. Сделайте a:

ls -al /etc/resolv.conf # отметьте исходную установку символьной ссылки

sudo cat /etc/resolv.conf # отметьте текущее содержание файла

sudo rm -i /etc/resolv.conf # удалите символьную ссылку


sudo ln -s /run/resolvconf/resolv.conf /etc/resolv.conf # новая символьная ссылка

sudo cat /etc/resolv.conf # отметьте текущее содержание файла

перетест использование DNS:

host -v www.booking.com | grep -i received # используйте другой веб-сайт каждый раз

sudo rm -i /etc/resolv.conf # удалите символьную ссылку


В зависимости от результатов можно также попробовать эту символьную ссылку:

sudo ln -s /run/systemd/resolve/resolv.conf /etc/resolv.conf # другая символьная ссылка

sudo cat /etc/resolv.conf # отметьте текущее содержание файла

перетест использование DNS:

host -v www.booking.com | grep -i received # используйте другой веб-сайт каждый раз

sudo rm -i /etc/resolv.conf # удалите символьную ссылку


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

sudo ln -s /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf # сброс к исходной символьной ссылке

1
ответ дан 21 December 2019 в 23:45

Другие вопросы по тегам:

Похожие вопросы: