Какие ресурсы (книги, веб-страницы и т. Д.) Вы бы порекомендовали:
netstat -s);Самое близкое, что я знаю, это этот документ, но довольно кратко.
Вы также можете напрямую ответить на вышеуказанные вопросы.
редактировать Для ясности, вопрос не только в «аномальной» задержке, но и в задержке в целом. Кроме того, речь идет именно о TCP / IP-over-Ethernet, а не о других протоколах (даже если они имеют лучшие характеристики задержки).
Что касается настроек ядра для задержки, следует иметь в виду:
echo 1 > /proc/sys/net/ipv4/tcp_low_latency
Из документация:
Если установлено, стек TCP принимает решения, которые предпочитают меньшую задержку, а не более высокую пропускную способность. По умолчанию этот параметр не установлен, что означает, что предпочтительна более высокая пропускная способность. Примером приложения, в котором следует изменить это значение по умолчанию, может быть вычислительный кластер Beowulf. По умолчанию: 0
Вы также можете отключить алгоритм Нэгла в своем приложении (который будет буферизовать вывод TCP до максимального размера сегмента) примерно так:
#include <sys/types.h>
#include <stdio.h>
#include <sys/socket.h>
#include <arpa/inet.h>
#include <stdlib.h>
#include <linux/tcp.h>
int optval = 1;
int mysock;
void main() {
void errmsg(char *msg) {perror(msg);exit(1);}
if((mysock = socket(PF_INET, SOCK_STREAM, IPPROTO_TCP)) < 0) {
errmsg("setsock failed");
}
if((setsockopt(mysock, SOL_SOCKET, TCP_NODELAY, &optval, sizeof(optval))) < 0) {
errmsg("setsock failed");
}
/* Some more code here ... */
close(mysock);
}
«Противоположностью» этого варианта является TCP_CORK, который будет "повторно загружать" пакеты. Остерегайтесь, однако, так как TCP_NODELAY может не всегда делать то, что вы ожидаете, а в некоторых случаях может снизить производительность. Например, если вы отправляете массовые данные, вам нужно максимизировать пропускную способность для каждого пакета, поэтому установите TCP_CORK. Если у вас есть приложение, которое требует немедленного взаимодействия (или где ответ намного больше, чем запрос, что сводит на нет накладные расходы), используйте TCP _NODELAY. С другой стороны, это поведение специфично для Linux, и BSD, вероятно, отличается, поэтому предостережение администратора.
Убедитесь, что вы провели тщательное тестирование своего приложения и инфраструктуры.
По моему опыту, самая большая причина аномальный задержка в других высокоскоростных сетях исправна - TCP Windowing (RFC1323, раздел 2), с тесно связанной секундой в сбоях, связанных с TCP Delayed Acks (RFC1122 раздел 4.2.3.2). Оба эти метода являются усовершенствованиями TCP для лучшей обработки высокоскоростных сетей. Когда они ломаются, скорость падает до очень медленного уровня. Сбои в этих случаях влияют на большие передачи (подумайте о потоках резервного копирования), где они будут меньше влиять на чрезвычайно малый трафик транзакций (средний размер передачи данных меньше размера MTU и существует МНОГО обратных и обратных потоков).
Опять же, я видел самые большие проблемы с этими двумя проблемами, когда разговаривают два разных стека TCP / IP. Такие как Windows / Linux, 2.4-Linux / 2.6-Linux, Windows / NetWare, Linux / BSD. Нравится очень и очень хорошо работает. Microsoft переписала стек Windows TCP / IP в Server 2008, что привело к проблемам взаимодействия Linux, которых не было в Server 2003 (я считаю, что они исправлены, но я не уверен в этом на 100%).
Разногласия по поводу точного метода отложенных или выборочных подтверждений могут привести к следующим случаям:
192.168.128.5 -> 192.168.128.20: 1500b payload, SEQ 1562 192.168.128.5 -> 192.168.128.20: 1500b payload, SEQ 9524 [200ms pass] 192.168.128.20 -> 192.168.128.5: ACK 1562 192.168.128.5 -> 192.168.128.20: 1500b payload, SEQ 12025 192.168.128.5 -> 192.168.128.20: 1500b payload, SEQ 13824 [200ms pass] 192.168.128.20 -> 192.168.128.5: ACK 12025
Пропускная способность идет через нижний предел из-за всех таймаутов в 200 мс (по умолчанию Windows устанавливает таймер отложенного подтверждения на 200 мс). В этом случае обе стороны диалога не смогли обработать TCP Delayed Ack.
Ошибки TCP Windowing труднее заметить, потому что их влияние может быть менее очевидным. В крайних случаях оконное управление полностью выходит из строя, и вы получаете пакет-> ack-> packet-> ack-> packet-> ack, который очень медленный при передаче чего-либо значительно большего, чем примерно 10 КБ, и увеличивает любой основная задержка по ссылке. Труднее обнаружить режим, когда обе стороны постоянно повторно согласовывают размер своего окна, а одна сторона (отправитель) не соблюдает согласование, которое требует обработки нескольких пакетов, прежде чем данные могут продолжить передачу. Этот вид сбоя проявляется в мигающих красных индикаторах в трассировках Wireshark, но проявляется как более низкая, чем ожидалось, пропускная способность.
Как я уже упоминал, вышесказанное часто мешает крупным переводам. С их помощью можно реально справиться с трафиком, таким как потоковое видео или потоки резервного копирования, а также с простой загрузкой очень больших файлов (например, ISO-файлов дистрибутива Linux). Так получилось, что TCP Windowing был разработан как способ решения основных проблем с задержкой, поскольку он позволяет конвейерную обработку данных; вам не нужно ждать времени приема-передачи для каждого отправленного пакета, вы можете просто отправить большой блок и дождаться одного ACK, прежде чем отправлять другие.
Тем не менее, определенные сетевые шаблоны не получают выгоды от этих обходных путей. Высокотранзакционные, небольшие переводы, например, созданные базами данных, больше всего страдают нормальный задержка на линии. Если RTT высокий, эти рабочие нагрузки сильно пострадают, тогда как большие потоковые рабочие нагрузки пострадают намного меньше.
В случае глобальной сети основным фактором задержки является скорость света. Это требует теоретический минимум ~ 36,2 мс для передачи данных через Северную Америку.
Поездка в один конец по оптоволоконному кабелю за секунды:
Умножьте 1000, чтобы преобразовать секунды в миллисекунды. Удвойте это для поездки туда и обратно:
Вот задержка от Вашингтон к Лос Анджелес, Калифорния:
На этот вопрос есть много ответов.
Вспомните, как работает TCP. Клиент отправляет SYN, сервер отвечает SYN / ACK, а клиент отвечает ACK. После того, как сервер получил ACK, он теперь может отправлять данные. Это означает, что вам нужно подождать, в два раза превышающее время приема-передачи (RTT), чтобы отправить первый бит значимых данных. Если у вас есть RTT 500 мс, вы сразу же получите задержку в 1 секунду. Если сеансы непродолжительны, но многочисленны, это приведет к большой задержке.
Как только сеанс установлен, сервер отправляет блоки данных, которые должны быть подтверждены клиентом. Сервер может отправлять столько данных в дикой природе, прежде чем он потребует подтверждения первого блока данных. Это также может создать задержку. Если блок данных упал, вы должны забрать передачу оттуда и, следовательно, создать дополнительную задержку.
На уровне IP у вас есть фрагментация (хотя сегодня она встречается довольно редко). Если вы отправляете кадры размером 1501 байт, а другая сторона поддерживает только MTU, равное 1500, вы отправляете дополнительный IP-пакет только для этого последнего бита данных. Это можно решить, используя Jumbo-кадры.
Лучший способ увеличить пропускную способность TCP / IP - максимально уменьшить задержку и максимально избежать ошибок передачи. Я не знаю каких-либо настроек ядра, но уверен, что кто-нибудь это сделает.
Вероятно, это не тот ответ, который вы ищете: основная причина задержки в WAN - это скорость света (она слишком медленная!). Кроме того, насыщенные ссылки с большим буфером по пути обычно имеют впечатляющую задержку.
См. Следующий веб-сайт: http://www.29west.com/docs/THPM/index.html
TCP - это сквозной протокол (или протокол от клиента к клиенту), который предполагает, что сеть в середине имеет очень небольшие потери. Для более надежного протокола см. X.25. Таким образом, вы будете иметь наибольший контроль над параметрами протокола только на клиентах (а не в сети).
Ethernet - это локальная сеть (LAN) (хотя это определение было широко расширено за последнее десятилетие и включило также и глобальные сети), и можно ожидать небольших потерь при передаче, если только вы не столкнетесь с 70% или более трафиком в общем сегменте. . Однако повторная передача будет нечастым явлением в современной сети Ethernet, учитывая, что в настоящее время коммутируются почти все сегменты Ethernet.
Так что перегрузка - ваш главный враг, когда дело касается задержки в локальной сети. Но тогда у вас есть более серьезные проблемы, чем просто задержка.
Если вы серьезно относитесь к проблемам с задержкой в вашем протоколе связи, вам действительно стоит подумать о коммутации пакетов, а не о протоколе виртуальных каналов, таком как UDP или RTMP.