Почему получение запроса и ответа Http слишком поздно

Ответ 1

Что касается вашего редактирования, чтобы помочь вам разобраться. Сеть следует модели под названием Open Source Intercommunication (OSI). Эта модель разбита на семь различных слоев, все с функцией.

Эти слои находятся здесь:

Wireshark обнаруживает пакеты, расположенные на уровне 3, которые обрабатываются маршрутизатором. Карта сетевого интерфейса (NIC) берет выделенные данные и превращает их в пакет для передачи по проводу.

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

Вы видите, как только он преобразуется в пакет, он содержит следующую информацию:

• 4 Биты, содержащие версию (IPV4 или IPV6)
• 4 Биты, содержащие заголовок Интернета.
• 8 битов, которые содержат тип обслуживания или качество обслуживания и приоритет.
• 16 Биты, которые содержат длину пакета в байтах.
• 16 Биты, содержащие идентификационный тег, чтобы помочь Восстановить пакет из фрагментов.
• 3 бит, первый - это нуль, за которым следует флаг, который говорит, чтобы разрешить фрагмент или нет. И количество.
• 13 Биты, содержащие смещение фрагмента, поле для определения позиции для оригинала.
• 8 битов, содержащих Time To Live (TTL) и переходы между маршрутизаторами.
• 8 битов, содержащих протокол (TCP, UDP, ICMP и т.д.).
• 16 битов, содержащих контрольную сумму заголовка
• 32 бита, содержащие исходный IP-адрес
• 32 бита, содержащие целевой IP-адрес

Это ключевые 160 битов, которые создаются при создании такого пакета.

Что это значит?

Хорошо, вы знаете, что Wireshark занимает двадцать секунд, чтобы обнаружить ваш пакет. Так что с самого начала мы знали, что потребовалось двадцать секунд, чтобы создать этот пакет.

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

Мы также знаем, что Маршрутизатор действует как полицейский, отправляя ваши данные через Интернет или локальную сеть.

Ну, это добавляет довольно немного вывода? Но куда мне пойти?

У вас есть утилита: tracert

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

6 * 20

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

Как насчет этого между клиентом и сервером?

• Локальные сети (LAN): внутренняя эффективность сети обусловлена ​​оптимизацией каждого сетевого протокола, оборудования и физической медианы. Сетевой администратор должен измерять надежность со скоростью; а также весь трафик, создаваемый сетью. Таким образом, пропускная способность оборудования и физическая медиана важны. Вам не хотелось бы, чтобы десять автомобилей, слившихся в туннель с одной полосой, могли создать горлышко бутылки, которое относится к сети.

• Глобальная сеть (WAN): Это, по сути, подключение к Интернету - Cloud. Подумайте об этом так: ваш компьютер находится в локальной сети, маршрутизатор отправляется в WAN. Тогда ваш интернет-провайдер, скорее всего, имеет локальную сеть, которая затем имеет WAN, открытую для более крупного распределительного устройства. Он продолжает работать, пока не достигнет интернета.

Что я могу сделать?

Вы знаете, что сейчас происходит, но что я могу сделать?

Хорошо, когда вы создаете свою Службу, вы, очевидно, хотите, чтобы ваш код был скудным и высокоэффективным. Поскольку эффективность может иметь решающее значение в скорости. Таким образом, изменение размеров буфера, скорости передачи и т.д. Может значительно улучшить ваше приложение.

Очевидно, что хорошая практика использования кода поможет.

Мой код твердый, хотя?

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

• Локальная машина может генерировать чрезмерную болтовню, поэтому она занимает довольно много времени.
• Локальная сеть генерирует чрезмерную болтовню или неэффективность/низкую пропускную способность.
• Ваш запрос отправляется на большие расстояния, поэтому время задерживается.
• У вашего интернет-провайдера могут быть аппаратные брандмауэры, прокси и т.д., которые сканируют эти пакеты.
• У вашего сервера может быть чрезмерный запрос или метод Host неэффективен.

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

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

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

Инструменты:

Командная строка:

• Ping
• Tracert

Сетевые и протокольные анализаторы:

• Fiddler (HTTP/HTTPS): см., если Fiddler отображает коды HTTP-статуса для устранения неполадок.
• Wireshark: проанализирует ваш сетевой трафик, который может помочь продлить время.

Существуют и другие утилиты, позволяющие фактически смягчить и протестировать сетевые скорости даже в других местах, просто в Google "Сетевые инструменты". У Fluke есть несколько.

Надеюсь, это объяснит, почему Wireshark может потребовать двадцать секунд, чтобы даже отобразить пакет в сети.

Надеюсь, что это поможет.

Ответ 2

Используйте Wireshark для захвата вашего запроса и ответа на расстоянии 60 секунд на проводе и отправьте его команде сервера. Они могут ответить захватом, показывающим запрос и ответ ближе к 7 секундам на их стороне. Это здорово! Отправьте их в сетевую команду.

С другой стороны, возможно, что трассировка показывает, что задержка находится в вашем коде. На вашем конце может быть какое-то дросселирование или задержка, которая заставляет запрос покидать ваш процесс на значительное количество времени. Об этом также может узнать трасса Wireshark.

Ответ 3

Поток TCP/IP будет управлять большинством вещей, о которых вы беспокоитесь.

"Отправка запроса быстрее, чем сервер не может обрабатывать"

Нет, вы никогда не будете отправлять что-либо на сервер быстрее, чем он может получить при использовании сеанса TCP. Поток передачи управляется и невозможно отправить быстрее, чем сервер может обрабатывать.

"Что такое сетевой буфер"

Существует два буфера очереди, включенных в связь TCP/IP, буфер отправки и буфер приема.

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

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

recv() также имеет свой собственный буфер. Эта команда фактически ничего не получает, данные уже получены, recv() будет читать ее только из буфера приема. При использовании блокирующего сокета (по умолчанию) recv() будет зависать, если буфер пуст, ожидая появления новых данных. recv() будет возвращать только 0, если соединение было прекращено, или если вы попытаетесь использовать его с неблокирующим сокетом.

Если вы забудете recv(), и буфер приема будет заполнен, это тоже нормально. Одноранговый узел не сможет продолжить отправку, поскольку send() начнет возвращать 0 к ним, но пока вы обратите внимание на возвращаемое значение send(), никакие данные не будут потеряны в любое время.

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

"Каков альтернативный способ повысить производительность, если мы находимся на стороне клиента и не контролируем сервер"

Это не совсем правильный вопрос, вы не можете этого сделать. Я думаю, что вы можете ошибиться в HTTP-запросах, особенно учитывая, что вы выполняете POST-запросы.

При выполнении запроса POST ваш HTTP-заголовок будет содержать два заголовка, которые обычно видны только в заголовках HTTP-заголовков сервера: Content-Type и Content-Length. Они очень важны при выполнении POST, и если один из них отсутствует или ошибочен, сеанс HTTP может зависеть на пару секунд или вообще не удастся.

Другим важным аспектом HTTP является наиболее существенное различие между HTTP 1.0 и HTTP 1.1: HTTP 1.0 не поддерживает Keep-Alive. Для новичков легче общаться с HTTP 1.0, потому что с HTTP 1.0 вы подключаетесь, отправляете свой запрос, сервер отвечает и соединение прекращается, а это означает, что вы закончили загрузку ответа сервера. С HTTP 1.1 это не произойдет по умолчанию. Соединение остается открытым до истечения времени ожидания. Вы должны обратить внимание на заголовок ответа HTTP Content-Length и количество байтов, чтобы узнать, завершил ли сервер отправку запрашиваемого материала.

Также важно заметить, что не все серверы поддерживают HTTP 1.0. Вы можете сделать запрос HTTP 1.0, но он все равно ответит 1.1, с Keep-Alives и всем, чего вы не ожидали. В идеальном мире это не должно происходить, но это происходит.

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

Ответ 4

В строке 1:

В вашей точке номер 1, я полагаю, вы хотели сказать "1. Это связано с отправкой CLIENT..." и "В этом случае клиент много раз получает RESPONSE с интервалом...".

В пункте 3:

• Серверная машина, как правило, является более мощным компьютером, чем клиентская машина, поэтому "Если сервер не может обрабатывать запрос с той же скоростью, какой клиент отправляет", это очень редко. Если я правильно помню, HTTP-сервер проходит "первым пришел первым", а то, что вы называете буфером запросов, будет очередью на стороне сервера, а не клиентом. Я никогда не слышал о том, что "все запросы буферизуются в клиентском буфере".

• Сервер времени принимает ответ, как правило, быстро, но результат времени возвращается к вам, клиент имеет больше общего с тем, что делает первоначальный запрос, независимо от того, извлекает ли он только статический html файл, или получить большое изображение или документ или выполнить тяжелый запрос на сервере БД и т.д.

• Вы единственный клиент, отправляющий HTTP-запросы на сервер? Возможно нет. Является ли этот серверный сервер только сервером HTTP? Помните, что сервер обрабатывает или обрабатывает запросы от нескольких клиентов, и это может быть еще одним фактором задержки ответа иногда, даже когда сервер может обрабатывать несколько запросов одновременно и в зависимости от того, что делают эти другие запросы. Крайним примером HTTP-сервера, который не может ответить из-за нескольких запросов, является тот факт, что сервер находится под атакой [распределенного] отказа в обслуживании.

• Есть ли у вас брандмауэры, защищающие HTTP-сервер или защищающие сеть, в которой находится HTTP-сервер? Наличие правил брандмауэра или систем обнаружения вторжений сети может задержать время запроса/ответа.

• Следующим может быть еще один фактор: "Какая возможная причина, по которой запрос появляется в 20-секундной задержке сети, на самом деле он был отправлен". Он называется "перегрузкой сети" и обычно происходит на уровне маршрутизатора.

В пункте 4:

• Как только вы отмените или устраните факторы, связанные с пунктом 3, вы можете повысить производительность за счет:

• Во-первых, все остальное не является [основным] фактором задержки, выясните, каково ваше ожидаемое время отклика.

• Во-вторых, убедитесь, что у вас есть разумная точная мера времени, в течение которого поездка туда и обратно осуществляется при каких условиях/обстоятельствах. Я бы предположил, что HTTP-сервер не виноват.

• В-третьих, если вы все еще испытываете задержку, вам (или кому-то еще) потребуется посмотреть конфигурацию маршрутизатора, конфигурацию брандмауэров и ваш код страницы html, если таковые имеются, или ваше веб-приложение, если оно есть.

Edit:

Попробуйте выполнить команду pinging HTTP-сервера, чтобы узнать время округления в сети.

Вот пример; Я отправил эту команду:

ping www.yahoo.com

из окна MS-DOS на клиентском ПК.

1) Обратите внимание, что круговое движение занимает около 0,5 секунды или менее (0,5 секунды = 500 мс). Я нахожусь на восточном побережье США, Yahoo.com, скорее всего, будет стоить США на Западе (я не уверен).

2) Обратите внимание, что каждый круглый путь не всегда такой же длины, но вариация мала.

3) От моего локального ПК до открытого на мировом уровне сервера, такого как Yahoo.com, есть несколько запросов, маршрутизаторов и межсетевых экранов между ними, и время отклика не было даже 1 секунду. Это означает, что сеть и сервер редко являются причиной задержки, если они правильно настроены, что означает, что ваша страница или приложение должны быть тщательно изучены/пересмотрены, прежде чем обвинять его на HTTP-сервере.

4) Когда я отправляю запрос http://www.yahoo.com из моего браузера, загрузка страницы наверняка занимает чуть больше 0,5 секунды, я думаю из-за всех элементов html и рекламы на странице, но ответ HTTP-сервера, скорее всего, на 0,5 секунды.

Ответ 5

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

Ответ 6

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

Вы можете легко проверить это, добавив дополнительную информацию в ваш файл хоста, который находится в окнах:

C:\Windows\System32\Drivers\Etc\хостов

или в системе linux:

\ и т.д.\хозяева

Чтобы проверить информацию о домене и ip-адресе, попробуйте использовать nslookup (та же самая команда в ОС Windows и Linux)