У нас есть Mac (нет разницы, какая версия ОС, она дает те же результаты) конечные пользователи, которые испытывают медленную загрузку Mac в локальной сети. Когда загрузка начинается, время загрузки файла продолжает расти и занимает очень много времени, прежде чем загрузка будет завершена. Иногда время загрузки просто истекает. Наши пользователи, использующие Windows, не сталкиваются с этой проблемой. Mac подключены к сети Ethernet. Даже когда Mac подключен к Wi-Fi, загрузка по-прежнему ведет себя так же, как когда он подключен к Ethernet. Когда загрузка выполняется вне сети с помощью Mac, она загружается без проблем. Похоже, что проблема в нашей сети, вызывая проблемы с загрузкой Mac, но мы не можем понять, что это такое или где искать способы устранения неполадок, чтобы выяснить, что может быть причиной. Любая помощь в устранении неполадок будет принята с благодарностью. Какие возможные причины могут вызвать медленную загрузку Mac в локальной сети? Я не понимаю, почему это влияет только на машины Mac, а не на машины Windows.
Первоначально я подумал, что проблема может быть вызвана конфигурацией хоста на Mac (Mountain Lion OS X 10.8.5), поэтому я отформатировал диск и установил El Capitan, но время загрузки было таким же. Затем я сделал захват пакетов на Mac и в Windows, чтобы попытаться сравнить, что может быть причиной этого, но я не совсем знаком с тем, как анализировать захват пакетов. Глядя на снимки с небольшими знаниями, которые я знаю, я могу увидеть некоторые сбросы соединения между ними. Я даже сделал захват пакетов на Mac вне сети, чтобы попытаться увидеть, что он может делать по-другому во время загрузки. сеть. Есть ли способ опубликовать фрагмент снимков, чтобы кто-нибудь помог мне проанализировать его, чтобы увидеть, что может вызвать его в сети?
Наиболее близким к сервису сниппетов для захвата пакетов является CloudShark.
Сбросы интересны и могут быть причиной вашей воспринимаемой медлительности на машинах OS X. Чтобы объяснить, почему, мы должны немного подробнее рассказать о том, как выбираются скорости. Это основано на Скользящие окна TCP, с дополнительным порядком продукт задержки полосы пропускания.
Абсолютная пропускная способность данного сетевого подключения определяется несколькими факторами:
Соединение 1GbE, охватывающее США, имеет одностороннюю задержку около 80 мс. Поскольку здесь важны подтверждения, мы должны подсчитать время их возврата. Итак, сделайте это 160 мсек. Соединение 1GbE может иметь 20 МБ данных в «ожидающих» за эти 160 мс (1024 ГБ x 0,16 секунды), если оно передает на полной скорости.
При согласовании TCP-соединения одним из параметров, по которому устанавливается соединение с обеих сторон, является размер окна TCP. Это третий пункт: сколько данных отправляющая сторона готова оставить без упаковки по сравнению с размерами буфера принимающей стороны для приема данных. По мере передачи данных обе стороны выпускают обновления о том, насколько большое окно они готовы терпеть. Для быстрых и чистых сетей это может быть довольно много.
Но, если соединение по какой-то причине сбрасывается, процесс запускается заново с исходными размерами окна. Если окно заполнено, отправляющая сторона прекратит отправку, пока эти ACK не вернутся к ней. Вы начинаете понимать, почему сброс соединения может вызвать проблемы с производительностью.
Есть еще одна сторона этого, о которой я хочу упомянуть, поскольку я уже видел, что это вызывает такого рода проблемы раньше. Вы не упомянули, что видели это, но если вы посмотрите, вы можете их увидеть. Ретрансмиты.
Одним из дополнений к TCP из первоначальной спецификации является Избирательные благодарности. Это вступает в игру при отбрасывании пакетов, а не при сбросе соединения. Без SACK, если это соединение RTT 1 ГБ, 160 мс, о котором я упоминал ранее, имеет отбрасывание пакета, принимающая сторона будет сидеть там и сбросить 20 МБ данных на пол, прежде чем отправляющая сторона повторно отправит все из потерянного пакета. Такое поведение подходило для сетей, которые были у нас в 1989 году, но наши нынешние намного быстрее и толще. Пакеты SACK позволяют принимающей стороне сказать: «Я видел до метки времени 123 и 125–137», что позволяет отправляющей стороне только повторно передать недостающий сегмент 124 и продолжить работу с остальной частью.
у меня есть определенно известны случаи, когда отсутствие поддержки SACK в соединении приводит к просто ужасной пропускной способности. Как только мы включили их с обеих сторон, производительность поднялась до теоретического максимума.
Ключ к разгадке этой проблемы находится в начальном трехстороннем рукопожатии TCP. Вы должны увидеть SACK в заголовке Options с обеих сторон. Если машины OSX не выдают его, а Windows делает это, у вас есть большой ключ к разгадке вашей проблемы.