Что такое метрика и почему программист должен заботиться? — сеть
Насколько я понимаю, «метрикой» или «метриками» мы описываем длину (в байтах, верно?) Пакета, путешествующего по сети, проблема в том, что, насколько мне известно, это значение связано с провайдером, и найти его практически невозможно даже 2 провайдера с одинаковой метрикой.
Если я программирую программное обеспечение P2P для синхронизации двух программ, и я хотел бы оценить, каков оптимальный размер для моих пакетов, имеет ли смысл сохранять метрики в подсчете, особенно из-за того, что это значение, связанное с провайдером а во всем мире много провайдеров? Я должен применить некоторый «эвристический алгоритм», например, предполагая, что лучший показатель — самый низкий, и я просто продолжаю добавлять пустые значения для заполнения самого длинного?
Благодарю.
PS
если вам нужна отправная точка для примера, я бы предпочел что-то на C ++, так как сейчас меня интересует этот язык.
РЕДАКТИРОВАТЬ:
Резюме комментариев, которые вы можете найти ниже: похоже, мой вопрос слишком общий, и теперь я сосредоточусь на MTU и задержке (задержке), чтобы все было более точно.
Решение
Сетевое взаимодействие (и, в частности, межсетевое взаимодействие) — относительно молодая наука, еще не полностью сформированная. Следовательно, не все «правильное поведение» «разделяется» кем-либо просто потому, что не все верят (или вынуждены) обуздать его «правильно».
Следствием этого является то, что каждый должен — на некотором уровне — «заботиться» о чем-либо, поскольку невозможно полностью доверять.
Тем не менее, чтобы приблизиться к вашей проблеме, позвольте мне начать с того, чтобы сказать вам, что вы сами «ненадежны», так как используете неверную терминологию.
Вы говорите о сетевом «метрике» (то, что в сетевой науке связано с маршрутизация), но вы говорите о чем-то другом, то есть MTU (Maximum Transfer Unit). Если вы поговорите с сетевым инженером таким образом, вы почти наверняка не найдете ответа на свой вопрос просто потому, что он, скорее всего, поймет другую совершенно не связанную вещь.
Теперь, когда все ясно (надеюсь), давайте немного разберемся с теорией:
- Каждое средство передачи, из-за своей физики, вносит некоторые ошибки.
- На уровне линии это происходит главным образом из-за «электрического шума» или групповой дисперсии, что делает «сигнал» все менее и менее понятным.
- На уровне канала (или тракта для сетевого протокола без установления соединения, такого как IP) это может быть связано с потерей пакета из-за перегрузки.
- Непосредственным следствием вышеуказанных пунктов является то, что « бесконечный концы с концами правильный коробка передач«физически невозможно».
- Чтобы позаботиться об этом, оба протокола связи, а также транспортные протоколы должны ввести некоторую «проверку избыточности» (CRC) и некоторый механизм — в случае неудачи контрольной суммы — чтобы исправить ошибку. В этом смысле MTU — это просто максимальное количество байтов, которое вы можете вставить в пакет, не нарушая базовые правила о том, как вычисляется CRC и управляется физический носитель.
- В зависимости от потребностей приложения, IP предлагает различные «транспортные протоколы»:
- UDP — это «все равно»: если пакет потерян, транспортный протокол ничего не сделает для восстановления
- TCP — это «полная забота до определенного срока»: если что-то потеряно, будет задана повторная передача. Все это управляется на уровне драйвера TCP / IP, поэтому приложению не нужно заботиться, если только «проблема» не длится больше времени ожидания сеанса.
- Независимо от поведения TCP и UDP, IP также предлагает «фрагментацию»: если транспортная единица слишком длинна, чтобы поместиться в кадр протокола канала, упакованный пакет делится на более мелкие. Этот процесс происходит (по крайней мере, в теории) на каждом прыжке (каждый раз, когда вы пересекаете маршрутизатор, чтобы перейти от одной ссылки к другой, другой и другой до конечного пункта назначения), и требует полной реконструкции структуры пакета и CRC, следовательно, он требуется больше вычислительного времени и мощности процессора или маршрутизаторов, что обычно требуется просто для перемещения пакета из порта в другой.
И именно поэтому вы должны позаботиться: производительность сети не одинакова для любой длины пакета: более длинные пакеты в TCP требуют меньше времени «ожидания для подтверждения» (поэтому передача данных может выполняться быстрее), но более длинные пакеты требуют большей задержки в случае промежуточной фрагментации и большей вычислительной мощности на маршрутизаторах. (в тот момент, когда многие провайдеры не фрагментируют: если он не может идти, они просто отбрасывают и позволяют TCP перенастроить на меньший MTU или приложению, чтобы сократить его пакеты UDP).
Другими словами, если вас не волнует производительность, просто позвольте TCP выполнять свою работу, и данные каким-то образом найдут способ передачи (путем промежуточной фрагментации или сквозного согласования MTU). Но если вы хотите максимизировать производительность, чем меньше механизмов контроля ошибок и восстановления вы «стимулируете», тем меньше задержка, которую вы получаете, и, следовательно, более широкие «сегменты», которые вы получаете, и, следовательно, более высокая скорость передачи данных, которую вы получаете.
Существует «оптимальная длина» для каждого пути, который вы можете иметь между двумя конечными точками, которые вы должны обнаружить и соблюдать, если вы хотите повысить производительность.
Если вы используете UDP, все будет немного хуже: поскольку нет согласования и восстановления MTU, если слишком длинный пакет отбрасывается по пути (потому что в определенный момент он больше не будет соответствовать физическому носителю, а провайдер не Собираясь фрагментировать, чтобы защитить себя и других клиентов) вы должны позаботиться и уменьшить его размер, иначе вы никогда не сможете его передать.
Не стесняйтесь сохранять провайдера как «несправедливо» по отношению к вам, но учтите, что чрезмерная активность фрагментации может привести к тому, что маршрутизатор окажется в том месте, где никакая другая передача невозможна из ниоткуда никому. И это урон выше, чем просто сбросить поток.
Другие решения
Я думаю, что вы, вероятно, говорите о метрике из таблиц маршрутизации. Если это так, то это просто число, которое отражает «стоимость» следующего перехода, скорее всего, с точки зрения задержки, но это не прямое измерение в миллисекундах. Это не то, что программисту нужно беспокоиться.
С оптимизацией по отношению к максимальным размерам единиц передачи (MTU) вы захотите добавить как можно больше битов в пакет, чтобы минимизировать количество пакетов, передаваемых по линии. Следует отметить, что если ваш главный компьютер (тот, который получает обновления в первую очередь) обновляется медленно, вы можете решить не ждать достаточного количества данных, чтобы полностью достичь MTU, а скорее обновить ведомый компьютер (на котором вы выполняете резервное копирование данных).
Так что в качестве примера ваша логика может выглядеть примерно так (в псевдокоде)
while(keep_updating){
if(new_data_size == (MTU - x)){ //really approximately equal to but smaller then the MTU
send_update_packet();
}else if(count_time > max_wait_time){ // this will have to deal with min latency
// discussed below
send_update_packet();
}
count_time++;
}
Теперь приведенные выше примеры очень глупы, если это то, что вы на самом деле пишете. Я предполагаю, что это будет на уровне ядра (не обязательно, но, тем не менее), это, скорее всего, будет одним потоком, в то время как остальная часть вашей службы выполняет другие задачи. в каждой теме.
Теперь с точки зрения времени задержки или задержки это более конкретно рассматривается как задержка сети, что-то в ситуации p2p, которую вы, скорее всего, не контролируете, так как это требует специального соглашения об обслуживании с ISP. Однако сумма этих частей даст приблизительную задержку в общих выражениях. то есть. время, которое требуется от send_update_packet(); пока ведомая машина не получит пакет и ваш хук в ядре / ОС, где вы фактически записываете новые обновления. В любом случае, это будет задержка, которая вас интересует
Processing delay - time routers take to process the packet header
Queuing delay - time the packet spends in routing queues
Transmission delay - time it takes to push the packet's bits onto the link
Propagation delay - time for a signal to reach its destination
… Теперь относительно того, какой протокол вы должны выбрать снова, очень зависит, если вы планируете, чтобы две машины говорили все время, tcp может быть вашим лучшим, это предотвратит вас, по крайней мере, гарантируя, что пакеты не будут потеряны (роскошный UDP обрабатывает протокол выше стек). Если вы ожидаете, что обновления будут более распространенными, вы захотите избежать TCP просто из-за процесса установления соединения TCP, который потребует 3x (сумма задержки, упомянутой выше), где udp позволит вам отправлять пакетные записи. и затем дождитесь ответа на том же сокете, гарантируя, что пакет был получен правильно, если вы не получите ответ в течение времени x повторите попытку.
В соответствии с ответом @EJP, при условии, что программистам в большинстве случаев не нужно беспокоиться об этом, но на определенном уровне есть люди, которые беспокоятся об этом, особенно в случаях аварийного управления для сервера баз данных и таких областей, как это, где важно, чтобы БД как всегда близки к insync … тем не менее, это два моих чувства после написания в прошлом году кода ядра, который решает эту конкретную проблему. Надеюсь, это поможет!