задний план
Это начало ежегодного осеннего набора в школу.В прошлом различные компании организовывали для студентов собеседования на месте на территории компании или школы? Однако из-за эпидемии в этом году студенты не могут проводить интервью на месте, поэтому в этом году формат интервью изменился с офлайн на онлайн, формат интервью изменился, но то, как мы оцениваем студентов, не изменилось.
Существует большая разница между студентами, которых набирают в кампусе, и теми, кого набирает сообщество.У них нет богатого опыта работы, и у них нет большого опыта работы над проектами.Так как же мы измеряем студента, который принята в школу? Это основа и потенциал, как понять основу? Как говорится, не наберешь несколько шагов, не пройдешь и тысячи миль. фундамент, как вы можете стать отличным инженером. Как проверить качество студенческого фонда? Я думаю, что более важны три аспекта: компьютерная сеть, операционная система, алгоритм и структура данных.Вообще говоря, компьютерная сеть много изучена и некоторые общие проблемы:
- расслоение сетевой модели
- Разница между TCP и UDP
- Трехстороннее рукопожатие TCP и четыре волны
- Различия между разными версиями HTTP
Перечисленные выше вопросы являются лишь частью из них.Ответы на эти вопросы в основном есть в учебниках в классе.Если вы не знаете ни одного из этих вопросов, то можно только сказать, что фундамент относительно слабый. Поскольку это видеоинтервью, я обычно спрашиваю вас, как вы думаете, использует ли видеоинтервью Niuke.com протокол TCP или UDP? Прежде чем я раскрою ответ, вы также можете подумать о том, какой сетевой протокол вы используете.Во время интервью все студенты ответили, что следует использовать UDP. Я спросил, зачем использовать UDP?В основном ответ заключается в том, что UDP - это протокол без установления соединения, не гарантирующий надежность, а скорость передачи высокая. Я также просил, что если UDP не гарантирует достоверность, я буду задавать вам вопросы во время видеоинтервью, если видеопоток вашего ответа будет потерян, то я не смогу услышать ваш ответ, а опыт видеоинтервью будет быть очень низким. В это время многие студенты изменят ответ и скажут, что следует использовать TCP. Я снова спрошу TCP, потому что он должен обеспечивать надежность, но в сложной среде общедоступной сети должны быть частые буферы или карты. явление, многие студенты потеряют дар речи в это время.
На самом деле ответ на этот вопрос придумать несложно.Мы можем совместить характеристики TCP и UDP, чтобы этот протокол мог обеспечить как надежность, так и производительность в реальном времени, что мы и называем RUDP((Надежный UDP ), распространенные протоколы RUDP включают QUIC, WebRTC, Aeron и т. д. Здесь я в основном представляю QUIC, предложенный Google, и показываю вам чудеса RUDP, чтобы увидеть, как они могут быть надежными и эффективными.
QUIC
QUIC (Quick UDP Internet Connection) — это эффективный и надежный протокол, основанный на UDP, предложенный Google, который также является протоколом прикладного уровня, таким как HTTP.
Почему это эффективно? Потому что он основан на UDP без установления соединения, а не на TCP.
Почему это надежно? Поскольку он имитирует надежность протокола TCP, надежность гарантируется на прикладном уровне.
Зачем нужен QUIC?
Интернет разрабатывался десятилетиями, но когда дело доходит до сетевых протоколов, протокол TCP чаще всего используется на транспортном уровне, а протокол HTTP — на уровне приложений.Конечно, нижний уровень HTTP также использует TCP-протокол. Хотя Интернет развивался так долго, он по-прежнему работает медленно для TCP.Сказать, что самым большим улучшением следует считатьACM CoNEXT
Опубликовано на конференции для улучшения задержки ответа веб-приложений TCP Fast Open путем изменения протокола TCP для использования трехэтапного рукопожатия для обмена данными, это может поддерживаться в ядре Linux 3.7.1 и более поздних версиях. Поскольку модификация протокола TCP неизбежно изменит ядро и приведет к обновлению системы, этот толчок будет очень сложным.
Поскольку мы не можем модифицировать ядро, Google предложил способ модифицировать протокол прикладного уровня, и есть QUIC.
Кто его использует?
Первым человеком, который будет использовать его, должен быть Google.Говорят, что 50% запросов Google - это протокол QUIC.Weibo также полностью использует протокол QUIC.В то же время есть также некоторые облачные видеосервисы, такие как Qiniu.Есть также много отделов внутри Tencent. QUIC активно используется, поэтому нет необходимости беспокоиться об использовании этого протокола.
Почему QUIC такой классный?
0RTT установить связь
RTT ((Время приема-передачи), как следует из названия, означает задержку приема-передачи. 0RTT означает, что QUIC может приносить данные с собой при отправке в первый раз. Учащиеся, знакомые с нашим TCP, должны знать, что TCP будет иметь трехстороннее рукопожатие настолько практичное То есть будет 1 RTT:
Если это HTTPS, будет использоваться дополнительное рукопожатие SSL/TLS, и будет 3 RTT:
Так как же 0RTT устанавливает связь с QUIC? Здесь я должен сказать, что 0RTT QUIC не является полным 0RTT. Ему также требуется 1RTT для согласования ключа. В QUIC используется обмен ключами Диффи-Хеллмана. Этот алгоритм представляет собой метод установления ключа, а не метод шифрования, но сгенерированный ключ можно использовать для шифрования, управления ключами или любого другого метода шифрования.Цель этой технологии обмена ключами состоит в том, чтобы дать возможность двум пользователям безопасно обмениваться ключами (KEY) для будущего использования.шифрование сообщений. Алгоритм DH использует соответствующие знания о дискретных логарифмах.Я не буду здесь подробно объяснять.Если вам интересно, вы можете поискать этот алгоритм. После того, как QUIC создаст безопасное соединение с помощью алгоритма DH, клиент кэширует исходную информацию о соединении и т. д. В последующем процессе, пока устанавливается связь с тем же сервером, данные отправляются напрямую, и нет необходимости снова согласовывать секретный ключ, что реализует последующий 0RTT.
Улучшенный контроль заторов
Существует множество алгоритмов управления перегрузкой TCP, например, основанные на обратной связи о потере пакетов (Tahoe, Reno, New Reno, SACK) и основанные на обратной связи с задержкой (Vegas, Westwood). на четыре этапа: медленный старт, предотвращение перегрузки, быстрая повторная передача и быстрое восстановление.
В QUIC используется улучшенный механизм управления перегрузкой: он может использовать разные алгоритмы управления перегрузкой для разных сервисов, разных сетевых стандартов и даже разных RTT. В то же время синхронизация пакетов также используется для определения пропускной способности сети для улучшения ее использования.
Улучшенный механизм ретрансляции
В механизме повторной передачи есть более важный термин, то есть время ожидания повторной передачи RTO (Retransmission Timeout).Как правило, эти данные будут рассчитываться в соответствии с RTT, тогда, если у нас есть более точный RTT, мы определенно можем получить лучший. .
При повторной передаче в TCP порядковый номер не меняется, что приведет к тому, что наш RTT будет неточным.Например, при повторной передаче вы не знаете, соответствует ли ваш запрос исходному запросу или запросу повторной попытки, что приведет к тому, что мы РТТ не точный.
В QUIC порядковый номер увеличивается, а реальная позиция в пакете определяется по смещению, так что можно получить более точный RTT.
Способ расчета RTT в TCP состоит в том, чтобы вычесть время отправки и время ответа, но вычисленное время не является точным, в QUIC будет вычтено время задержки подтверждения сервера, что является более точным.
Точно так же в TCP есть опция SACK, когда эта опция включена, она используется для записи диапазона некоторых неподтвержденных данных во время передачи, что удобно для последующей направленной повторной передачи нескольких групп потерянных данных вместо всех повторных передач, поэтому больше диапазонов Это удобно для более избирательных повторных передач, что также означает меньшую частоту повторных передач пакетов. Но TCP поддерживает до 3 диапазонов SACK, а QUIC — 255.
Мультиплексирование без блокировки очереди
Учащиеся, знакомые с HTTP2.0, должны знать, что в версии 2.0 при обращении к одному и тому же серверу будет только одно TCP-соединение, и все запросы будут проходить через это соединение:
И каждый запрос называется "Поток в соединении". В соединении может быть несколько потоков. Здесь проблема в том, что пакеты в TCP имеют гарантированную синхронизацию. Если поток теряет пакет, это также влияет на другие. Поток, когда он более серьезно, мультиплексирование не так хорошо, как несколько ссылок HTTP1.1.
В QUIC, поскольку нижний уровень основан на UDP, UDP не нужно гарантировать синхронизацию пакетов, а только повторно собирает пакеты при получении пакетов, поэтому этой проблемы не существует. Вот почему Google предложил использовать QUIC в HTTP3.
Лучшее управление потоком
Как упоминалось выше, QUIC мультиплексирован, и управление потоком может выполняться как для Stream, так и для Connection в QUIC.
Управление потоком QUIC немного отличается от TCP.Для обеспечения надежности длина левого края окна, когда левый край окна сдвигается вправо, зависит от количества подтвержденных байтов. . В случае потери пакета в середине, даже если получен сегмент с большим порядковым номером, окно не может превышать этот порядковый номер. Но QUIC отличается тем, что даже если некоторые пакеты ранее не были получены, его скольжение зависит только от максимального количества полученных байтов смещения.
Самое главное, что мы можем выполнять динамическую настройку.При нехватке памяти или проблемах с производительностью восходящей обработки можно использовать управление потоком для ограничения скорости передачи и обеспечения доступности сервиса.
миграция соединения
Сейчас стало обычным делом переключаться между мобильным трафиком и вайфаем на мобильных телефонах.Каждый раз при переключении ip адреса ip адрес будет меняться.Если это TCP то соединение будет прервано и соединение будет восстановлено.
В QUIC четверки IP и портов больше не идентифицируются, а в качестве идентификатора используется 64-битное случайное число, что позволяет повторно использовать соединения без переустановки новых соединений.
разное
В QUIC есть еще много других функций, таких как:
- Гарантированный порядок потоков по потоку заголовков
- Основные гарантии, что соединение является постоянным
- Токен исходного адреса предотвращает подделку адреса
- Сжатие сертификатов во время рукопожатия, чтобы избежать атак с усилением, здесь не рассматривается.
Здесь нет подробного введения, вы можете поискать информацию самостоятельно.
Суммировать
На самом деле, этот пост также является постом по грамотности.Я считаю, что многие друзья не слышали о некоторых вещах, связанных с RUDP, или слышали о нем, но всегда думали, что это очень сложная и трудная для понимания вещь.На самом деле это Распространение здесь.Говоря о RUDP, он состоит из надежного протокола прикладного уровня UDP+.Я надеюсь, что вы сможете что-то получить после прочтения этой статьи.
Справочная статья:
- Как протокол QUIC обеспечивает зашифрованную передачу 0RTT:blog.CSDN.net/dog250/Аретти…
- Техническая грамотность - новое поколение протокола сетевого транспортного уровня на основе UDP с малой задержкой - подробное объяснение QUIC:52IM.net/thread-1309…
- Анализ протокола QUIC, тестирование производительности и практика в участниках QQ:блог woo woo woo.cn on.com/we test/afraid/90…
Если вы считаете, что эта статья полезна для вас, то ваше внимание и пересылка - самая большая поддержка для меня, O(∩_∩)O: