Я одновременно обновляю несколько страниц в браузере (любой браузер, Safari, Chrome и т.д.), И они неожиданно застревают, ожидая "соединения". lsof показывает количество соединений в состоянии SYN_SENT . Их число увеличивается каждую секунду, до 100-150. Это происходит за 10-20 секунд. Затем все они исчезают, и веб-страницы, наконец, загружаются.
Что это может быть? Я дома, на обычном домашнем интернет-соединении.
РЕДАКТИРОВАТЬ: Сначала я подумал, что это будет зависеть от того, сколько вкладок браузера вы открываете, и поэтому вы будете страдать от "нормального" функционирования вашего стека TCP/IP - ограничения скорости новых соединений TCP (и истощения). из доступных эфемерных портов). Но я перечитал ваш оригинальный пост и заметил, что вы сказали, что соединения SYN_SENT накапливаются. Это означает, что вашей машине удается создать много соединений одновременно. Я оставлю старый текст моего оригинального ответа без изменений (если только по той причине, что я потратил часы на его изучение, и это довольно интересный материал), но я просто хотел добавить это изменение в начале, чтобы избежать разочарования читателя. Конец моего поста посвящен ограничениям роутера, и я подозреваю, что это проблема. Вы можете попробовать тот же тест на другом интернет-соединении (например, 3G, используя личную точку доступа iPhone).
Оригинальный пост...
Я только что провел эксперимент - я использовал окно Chrome Developer Tools для контроля загрузки страницы, одновременно загружая www.ft.com. Затем я просмотрел каждую строку на вкладке «Сеть» окна «Инструменты разработчика» и вручную скопировал каждый уникальный хост / сервер, к которому обращались при загрузке главной страницы www.ft.com. Всего было получено доступ к 71 уникальному серверу:
ft.com
s1.ft-static.com
navigation.webservices.ft.com
s4.media.ft.com
s2.ft-static.com
im.ft-static.com
www.googleadservices.com
www.ft-static.com
amch.questionmarket.com
reg.ft-static.com
service.maxymiser.net
personalisation.ft.com
pong.qubitproducts.com
track.ft.com
stats.ft.com
www.googletagservices.com
js.revsci.net
cdn.krxd.net
partner.googleadservices.com
admin.brightcove.com
mostpopular.sp.ft-static.com
googleads.g.doubleclick.net
fastft.ftdata.co.uk
widget-cdn.rpxnow.com
static.chartbeat.com
pubads.g.doubleclick.net
www.google.com
4235225.fls.doubleclick.net
ads.rubiconproject.com
ping.chartbeat.net
pagead2.googlesyndication.com
c.brightcove.com
ads.revsci.net
media.ft.com
pix04.revsci.net
beacon.krxd.net
secure.fastclick.net
leadback.advertising.com
ib.adnxs.com
api.adsymptotic.com
optimized-by.rubiconproject.com
cdn.quilt.janrain.com
s1.test.ft-static.com
www.facebook.com
b.scorecardresearch.com
tap2-cdn.rubiconproject.com
b.scorecardresearch.com
im.test.ft-static.com
clamo.ftdata.co.uk
assets.rubiconproject.com
tap.rubiconproject.com
x.bidswitch.net
rp.gwallet.com
rc.d.chango.com
i.w55c.net
tags.bluekai.com
rbp.mxptint.net
ads.p161.net
magnetic.t.domdex.com
ads.mediade.sk
ad.turn.com
video.ft.com
pool.adizio.com
cdn.trn.com
p.brilig.com
s.ixiaa.com
api.bizographics.com
metrics.brightcove.com
goku.brightcove.com
www.google-analytics.com
brightcove.vo.llnwd.net
Это становится хуже, хотя! Обратите внимание, что ко многим из этих хостов обращались многократно, но давайте предположим, что веб-браузер (или ОС) достаточно интеллектуален, чтобы поддерживать соединения TCP в течение нескольких секунд и использовать их повторно. Использование lsof -n -p 8420 | grep -c "IPv4" (Chrome использует PID 8420, и у меня нет других открытых страниц в Chrome; я полностью очистил кэш и заранее отключил AdBlock и т. д.). Во время перезагрузки страницы я просто несколько раз поднимаю стрелку вверх по команде lsof , а приведенный выше конвейерный grep дает мне счет, то есть:
$ lsof -n -p 8420 | grep -c "IPv4"
42
$ lsof -n -p 8420 | grep -c "IPv4"
64
$ lsof -n -p 8420 | grep -c "IPv4"
75
$ lsof -n -p 8420 | grep -c "IPv4"
85
$ lsof -n -p 8420 | grep -c "IPv4"
111
$ lsof -n -p 8420 | grep -c "IPv4"
129
$ lsof -n -p 8420 | grep -c "IPv4"
127
$ lsof -n -p 8420 | grep -c "IPv4"
128
$ lsof -n -p 8420 | grep -c "IPv4"
129
$ lsof -n -p 8420 | grep -c "IPv4"
128
$ lsof -n -p 8420 | grep -c "IPv4"
128
$
Как вы можете видеть, загрузка одной веб-страницы привела к пику 129 соединений TCP. Независимо от того, находились они в состоянии ESTABLISHED или какое-либо закрывающее состояние, например CLOSE_WAIT, не имеет значения - эти исходные порты не могут использоваться в этой точке и по умолчанию будут возвращаться в пул в течение 60–480 секунд (изначально указан RFC793). MSL (максимальное время жизни сегмента) 4 минуты, но я думаю, что сейчас 60-120 секунд по умолчанию). В Windows XP и Vista было доступно всего несколько тысяч временных портов (по умолчанию), поэтому, как вы можете видеть, на вашей машине было бы очень просто исчерпать доступные порты. * Важно отметить, что, как вы можете видеть из первого выполнения lsof , в моей системе уже было открыто 42 соединения, поэтому на этой веб-странице было открыто 87 новых соединений. Я запускал его пару раз, чтобы другие приложения (почтовый клиент и т.д.) Не увеличивали эти цифры во время тестирования.
Есть и другие ограничения - я могу говорить только о Linux здесь, так как у меня не было времени исследовать это на Windows (я уже потратил несколько часов на изучение этой проблемы, и мне нужно есть!) ... но в В Linux (и OSX) существует ограничение на максимальное количество файловых дескрипторов на процесс, и это ограничение устанавливается в нескольких местах. Предел 256. Имейте в виду, что некоторые веб-браузеры запускают один процесс на одну вкладку, поэтому я не уверен, что вы попали бы в эту стену, но было бы достаточно легко изменить ограничения и повторно протестировать. Google для "ulimit max file descriptors" и "launchctl maxfiles", чтобы найти оба места, где он установлен. Также см. Этот пост Stackoverflow.
Из моих дней до OSX я знал, что в Windows XP было ограничение скорости создания новых соединений TCP. Это должно было уменьшить распространение червей, таких как Sasser, за счет ограничения того, насколько быстро они могут создавать новые соединения TCP, но также было предотвращено поглощение ресурсов ОС - каждое новое соединение TCP требует ресурсов, которые ОС обычно выделяет PRE. во время загрузки (для выделения / уничтожения буферов при каждом открытии / закрытии TCP-соединения потребуется больше времени, поэтому ОС заранее создает таблицу соединений). Если вы посмотрите на страницу конфигурации для клиентов Torrent (например, Transmission), их глобальное ограничение по умолчанию для новых TCP-подключений равно 120, а ограничение на торрент - 60. Их руководство пользователя рекомендует придерживаться 120, и я видел, как моя работа в Интернете действительно пикирует, если я установлю его на 200-240. Это действительно ограничивает TCP MSL - время, которое требуется для возврата порта TCP в TIME_WAIT в пул.
Моя интуиция говорит, что вы ограничены тем фактом, что каждая вкладка вашего браузера будет создавать множество новых TCP-соединений, и, загружая, скажем, 15 вкладок одновременно, вы просите ОС открыть все TCP-соединения. в то же время. При повторном запуске теста убедитесь, что вы подождите не менее 4 минут между запусками теста и используете netstat -n -p tcp (в Windows просто используйте netstat -no). Если вы используете * nix, используйте lsof -n -i | grep -c заранее, чтобы увидеть, сколько соединений уже открыто на вашем компьютере.
ПОСЛЕДНО ... проверь свой роутер / шлюз. В прошлом я видел множество ADSL-маршрутизаторов на базе BusyBox, у которых максимальный лимит составляет 1024 одновременных TCP-соединения (в любом состоянии, т.е. установлено, close_wait и т.д.). Одного клиента, выполняющего загрузку P2P, было достаточно, чтобы полностью остановить маршрутизатор - и этот симптом был в точности таким, как вы описали, но даже если вы пытались загрузить только одну веб-страницу. P2p может съесть 1024 подключения в течение нескольких минут просто потому, что все, что вам нужно сделать, это открыть и закрыть 1024 подключения в течение 4 минут, и новые подключения не будут разрешены. Обычная жалоба заключалась в том, что «когда я запускаю eMule, даже при медленном ограничении скорости загрузки, все в моем доме жалуются, что интернет становится практически непригодным для использования». Причина, по которой домашний интернет-маршрутизатор показывает *** о соединениях TCP, заключается в том, что они почти всегда запускают NAT / PAT и часто имеют брандмауэры с сохранением состояния / SPI, которые требуют отслеживания всех соединений. Тем не менее, маршрутизаторы, сделанные в последние несколько лет, должны лучше справляться с этим.
Надеюсь, это поможет.
Это означает, что ваш компьютер отправил пакет запроса соединения (SYN) на целевой компьютер, но еще не получил ответ (ACK или NAK , положительный или отрицательный соответственно). Это так называемое полуоткрытое соединение. Он исчезнет, когда истечет время ожидания подключения.
Так что либо ваше соединение ненадежно, либо удаленный сервер.
/edit: Конечно, их не должно быть сотни. Ни один браузер не сделает этого. Вы уверены, что это не какой-то торрент-клиент? ;)