По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие наши статьи:
img
Redis – это высокопроизводительная БД, которая хранит данные в памяти, доступ к которым осуществляется по ключу доступа. Она может использоваться в качестве базы данных, кэша и брокера сообщений и поддерживает различные структуры данных, такие как строки, хэши, списки, наборы и т. Д. Redis обеспечивает высокую доступность через Redis Sentinel и автоматическое разбиение между несколькими узлами Redis с помощью Redis Cluster. Это руководство описывает установку и настройку Redis в CentOS 8. Подробно про Redis можно прочесть в этой статье. Установка Redis в CentOS 8 Redis версии 5.0.x включен в стандартные репозитории CentOS 8. Для его установки выполните следующие команды от имени пользователя root или пользователя с привилегиями sudo (про то как получить права sudo можно прочесть тут) sudo dnf install redis-server После завершения установки включите и запустите службу Redis: sudo systemctl enable --now redis Чтобы проверить, работает ли сервер Redis, введите: sudo systemctl status redis Получим следующий вывод: ? redis.service - Redis persistent key-value database Loaded: loaded (/usr/lib/systemd/system/redis.service; enabled; vendor preset: disabled) Drop-In: /etc/systemd/system/redis.service.d L-limit.conf Active: active (running) since Sat 2020-02-08 20:54:46 UTC; 7s ago Вот и все! Redis установлен и работает на вашем сервере CentOS 8. Настройка удаленного доступа Redis По умолчанию Redis не разрешает удаленные подключения. Вы можете подключиться к серверу Redis только с 127.0.0.1 (localhost) - компьютера, на котором работает Redis. Если вы используете установку с одним сервером, где клиент, подключающийся к базе данных, также работает на том же хосте, вам не нужен удаленный доступ. Чтобы настроить Redis для приема удаленных подключений, откройте файл конфигурации Redis в текстовом редакторе: sudo nano /etc/redis.conf Найдите строку, начинающуюся с bind 127.0.0.1, и добавьте внутренний IP-адрес вашего сервера после 127.0.0.1. bind 127.0.0.1 192.168.1.10 Убедитесь, что вы заменили 192.168.1.10 своим IP-адресом. Сохраните файл и закройте редактор. Если вы хотите, чтобы Redis прослушивал все интерфейсы, просто закомментируйте строку. Перезапустите службу Redis, чтобы изменения вступили в силу: sudo systemctl restart redis Используйте следующую команду ss, чтобы убедиться, что сервер Redis прослушивает ваш локальный интерфейс через порт 6379: ss -an | grep 6379 Вы должны увидеть что-то вроде этого: tcp LISTEN 0 128 192.168.1.10:6379 0.0.0.0:* tcp LISTEN 0 128 127.0.0.1:6379 0.0.0.0:* Затем вам нужно настроить фаервол для доступа трафика с TCP-порта 6379. Скорее всего вы захотите разрешить доступ к серверу Redis только с определенного IP-адреса или диапазона IP-адресов. Например, чтобы разрешить подключения только с подсети 192.168.2.0/24, выполните следующие команды: sudo firewall-cmd --new-zone=redis –permanent sudo firewall-cmd --zone=redis --add-port=6379/tcp –permanent sudo firewall-cmd --zone=redis --add-source=192.168.2.0/24 –permanent sudo firewall-cmd --reload Приведенные выше команды создают новую зону с именем redis, открывают порт 6379 и разрешают доступ из частной сети. На этом этапе сервер Redis будет принимать удаленные подключения через порт TCP 6379. Убедитесь, что ваш фаервол настроен на прием соединений только из доверенных диапазонов IP-адресов. Чтобы убедиться, что все настроено правильно, вы можете попробовать пропинговать сервер Redis с удаленного компьютера, используя утилиту redis-cli, которая предоставляет интерфейс командной строки для сервера Redis: redis-cli -h ping Команда должна вернуть ответ PONG: PONG Если это так, то значит, что мы все сделали правильно!
img
Теперь вы знаете, как работают глобальные префиксы и подсети, а как насчет ID интерфейса? Мы еще не говорили о назначении IPv6-адресов нашим хостам. Назначение адресов хостам почти то же самое, что и для IPv4: Адреса должны быть уникальными для каждого хост; Вы не можете использовать префиксный адрес в качестве адреса хоста. Ранее мы писали про основы работы протокола IPv6 (Internet Protocol version 6). Вы можете настроить IPv6-адрес вручную вместе со шлюзом по умолчанию, DNS-сервером и т. д. или ваши хосты могут автоматически получить IPv6-адрес либо через DHCP, либо через что-то новое, называемое SLAAC (Stateless Address Autoconfiguration). Вот пример IPv6 адресов, которые вы могли бы выбрать для топологии, которая показана выше: Для интерфейсов роутера предлагаю использовать наименьшие числа, так как они легко запоминаются. В этом примере показан уникальный global unicast IPv6-адрес для каждого устройства. Это все, что касается global unicast адресов, так же мы должны рассмотреть уникальные локальные одноадресные адреса. Уникальные локальные адреса работают так же, как и частные адреса IPv4. Вы можете использовать эти адреса в своей собственной сети, если не собираетесь подключаться к Интернету или планируете использовать IPv6 NAT. Преимущество уникальных локальных адресов заключается в том, что вам не нужно регистрироваться в специализированном органе, чтобы получить дополнительные адреса. Вы можете распознать эти адреса, потому что все они начинаются с FD в шестнадцатеричном формате. Есть еще несколько правил, которым вы должны следовать, если хотите использовать уникальные локальные адреса: Убедитесь, что FD - это первые два шестнадцатеричных символ; Вам нужно составить 40-битный глобальный ID, вы можете выбрать все, что вам нравится; Добавьте 40-битный глобальный ID после "FD", чтобы создать 48-битный префикс; Следующие 16 бит должны использоваться для подсетей Это оставляет вам последние 64 бита для использования идентификатора интерфейса. Вот как выглядит уникальный локальный адрес: Это дает нам уникальный локальный адрес, который мы можем использовать в наших собственных сетях. Подсети global unicast адресов или уникальных локальных адресов точно такие же, за исключением того, что на этот раз мы сами создаем префикс вместо того, чтобы провайдер назначил нам глобальный префикс. Глобальный ID может быть любым, что вам нравится, с 40 битами у вас будет 10 шестнадцатеричных символов для использования. Вы можете выбрать что-то вроде 00 0000 0001, поэтому, когда вы поставите перед ним "FD", у вас будет префикс FD00:0000:0001::/48. Вы можете удалить некоторые нули и сделать этот префикс короче, он будет выглядеть так: FD00:0:1:: / 48 Теперь вы можете добавить различные значения за префиксом, чтобы сделать уникальные подсети: FD00:0:1:0000::/6; FD00:0:1:0001::/6; FD00:0:1:0002::/6; FD00:0:1:0003::/6; FD00:0:1:0004::/6; FD00:0:1:0005::/6; FD00:0:1:0006::/6; FD00:0:1:0007::/6; FD00:0:1:0008::/6; FD00:0:1:0009::/6; FD00:0:1:000A::/6; FD00:0:1:000B::/6; FD00:0:1:000C::/6; FD00:0:1:000D::/6; FD00:0:1:000E::/6; FD00:0:1:000F::/6; FD00:0:1:0010::/6; FD00:0:1:0011::/6; FD00:0:1:0012::/6; FD00:0:1:0013::/6; FD00:0:1:0014::/6; И так далее. Когда вы выполняете лабораторные работы, можно использовать простой глобальный ID. В конечном итоге вы получите короткий и простой в запоминании префикс. Для производственных сетей лучше использовать глобальный ID, чтобы он был действительно уникальным. Возможно, однажды вы захотите подключить свою сеть к другой сети, или, возможно, вам придется объединить сети. Когда обе сети имеют один и тот же глобальный идентификатор, вам придется изменить IPv6-адрес для объединённой сети. В случае, если глобальные идентификаторы отличаются, Вы можете просто объединить их без каких-либо проблем. Настройка на маршрутизаторе В оставшейся части этой статьи мы рассмотрим, как можно настроить IPv6 на наших роутерах. Если вы хотите настроить IPv6 адрес на роутере у вас есть два варианта: Вручную настроить 128-битный IPv6-адрес; Использовать EUI-64; Сначала я покажу вам, как вручную настроить IPv6-адрес, а затем объясню, что такое EUI-64. Вот что необходимо выполнить: OFF1(config)#interface fastEthernet 0/0 OFF1(config-if)#ipv6 address 2001:1234:5678:abcd::1/64 Вам нужно использовать команду ipv6 address, а затем вы можете ввести адрес IPv6. Префикс, который я использую, - это 2001:1234:5678:abcd, и этот роутер будет иметь в качестве своего адреса "хоста" "1". Если хотите Вы также можете ввести полный IPv6-адрес: OFF1(config)#interface fastEthernet 0/0 OFF1(config-if)#ipv6 address 2001:1234:5678:abcd:0000:0000:0000:0001/64 Эта команда будет иметь точно такой же результат, что и команда, введенная ранее. Мы можем проверить подсеть и IPv6-адрес следующим образом: OFF1#show ipv6 interface fa0/0 FastEthernet0/0 is up, line protocol is up IPv6 is enabled, link-local address is FE80::C000:18FF:FE5C:0 No Virtual link-local address(es): Global unicast address(es): 2001:1234:5678:ABCD::1, subnet is 2001:1234:5678:ABCD::/64 Данный вывод информации отображает global unicast адрес и нашу подсеть. Есть еще одна важная вещь, когда мы настраиваем IPv6 на роутере. По умолчанию роутер не будет пересылать никакие пакеты IPv6 и не будет создавать таблицу маршрутизации. Чтобы включить "обработку" пакетов IPv6, нам нужно включить его: OFF1(config)#ipv6 unicast-routing Большинство команд "ip" будут работать, просто попробуйте "ipv6" вместо этого и посмотрите, что он делает: OFF1#show ipv6 interface brief FastEthernet0/0 [up/up] FE80::C000:18FF:FE5C:0 2001:1234:5678:ABCD::1 OFF1#show ipv6 route connected IPv6 Routing Table - 3 entries Codes: C - Connected, L - Local, S - Static, R - RIP, B - BGP U - Per-user Static route, M - MIPv6 I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary O - OSPF intra, OI - OSPF inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2 ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2 D - EIGRP, EX - EIGRP external C 2001:1234:5678:ABCD::/64 [0/0] via ::, FastEthernet0/0 Теперь вы знаете, как настроить IPv6-адрес вручную и как его проверить. После, почитайте о том, как настроить IPv6 с EUI-64 на Cisco.
img
Предыдущая статья из цикла про популярные приложения TCP/IP тут. Установление TCP-соединения происходит до того, как любая из других функций TCP сможет начать свою работу. Установление соединения относится к процессу инициализации полей "Sequence" и "Acknowledgment" и согласования используемых номеров портов. На рисунке 5 показан пример процесса установления соединения. Этот трехсторонний процесс установления соединения (также называемый трехсторонним рукопожатием) должен завершиться до начала передачи данных. Соединение существует между двумя сокетами, хотя в заголовке TCP нет единственного поля сокета. Из трех частей сокета подразумеваются IP-адреса на основе IP-адресов источника и назначения в IP-заголовке. TCP подразумевается, потому что используется заголовок TCP, как указано значением поля протокола в заголовке IP. Следовательно, единственные части сокета, которые необходимо закодировать в заголовке TCP, - это номера портов. TCP сообщает об установлении соединения, используя 2 бита в полях флагов заголовка TCP. Эти биты, называемые флагами SYN и ACK, имеют особенно интересное значение. SYN означает "синхронизировать порядковые номера", что является одним из необходимых компонентов при инициализации TCP. На рисунке 6 показано завершение TCP-соединения. Эта четырехсторонняя последовательность завершения проста и использует дополнительный флаг, называемый битом FIN. (FIN - это сокращение от "finished", как вы могли догадаться.) Одно интересное замечание: перед тем, как устройство справа отправит третий сегмент TCP в последовательности, оно уведомляет приложение о том, что соединение прерывается. Затем он ожидает подтверждения от приложения перед отправкой третьего сегмента на рисунке. На случай, если приложению потребуется некоторое время, чтобы ответить, ПК справа отправляет второй поток на рисунке, подтверждая, что другой ПК хочет разорвать соединение. В противном случае ПК слева может повторно отправить первый сегмент. TCP устанавливает и завершает соединения между конечными точками, а UDP - нет. Многие протоколы работают в рамках одних и тех же концепций, поэтому термины "ориентированный на соединение" и "без установления соединения" используются для обозначения общей идеи каждого из них. Более формально эти термины можно определить следующим образом: Протокол, ориентированный на соединение: протокол, который требует обмена сообщениями до начала передачи данных или который имеет требуемую предварительно установленную корреляцию между двумя конечными точками. Протокол без установления соединения: протокол, который не требует обмена сообщениями и не требует предварительно установленной корреляции между двумя конечными точками. Восстановление после ошибок и надежность TCP обеспечивает надежную передачу данных, что также называется reliability or error recovery. Для обеспечения надежности TCP нумерует байты данных, используя поля "Sequence" и "Acknowledgment" в заголовке TCP. TCP обеспечивает надежность в обоих направлениях, используя поле Sequence Number одного направления в сочетании с полем Acknowledgment в противоположном направлении. На рисунке 7 показан пример того, как поля TCP Sequence и Acknowledgment позволяют ПК отправлять 3000 байтов данных на сервер, при этом сервер подтверждает получение данных. Сегменты TCP на рисунке расположены по порядку, сверху вниз. Для простоты все сообщения содержат 1000 байтов данных в части данных сегмента TCP. Первый порядковый номер - красивое круглое число (1000), опять же для простоты. В верхней части рисунка показаны три сегмента, каждый из которых на 1000 больше предыдущего, что указывает на первый из 1000 байтов сообщения. (То есть в этом примере первый сегмент содержит байты 10001999; второй - байты 20002999, а третий - байты 30003999.) Четвертый сегмент TCP на рисунке - единственный, который возвращается от сервера к веб-браузеру - подтверждает получение всех трех сегментов. Как? Значение подтверждения 4000 означает: "Я получил все данные с порядковыми номерами на единицу меньше 4000, поэтому я готов принять ваш байт 4000 следующим". (Обратите внимание, что это соглашение о подтверждении путем перечисления следующего ожидаемого байта, а не номера последнего полученного байта, называется прямым подтверждением.) Однако этот пример не исправляет никаких ошибок; он просто показывает основы того, как хост-отправитель использует поле порядкового номера для идентификации данных, а хост-получатель использует прямые подтверждения для подтверждения данных. Более интересное обсуждение вращается вокруг того, как использовать эти же инструменты для восстановления ошибок. TCP использует поля "Sequence" и "Acknowledgment", чтобы принимающий хост мог заметить потерю данных, попросить отправляющий хост повторно отправить, а затем подтвердить, что повторно отправленные данные прибыли. Существует множество вариантов того, как TCP выполняет исправление ошибок. На рисунке 8 показан только один такой пример, детализация которого аналогична предыдущему. Веб-браузер снова отправляет три сегмента TCP, снова по 1000 байт каждый, снова с легко запоминающимися порядковыми номерами. Однако в этом примере второй сегмент TCP не может пройти через сеть. Рисунок указывает на три набора идей, лежащих в основе того, как думают два хозяина. Во-первых, справа сервер понимает, что он не получил все данные. Два полученных сегмента TCP содержат байты с номерами 10001999 и 30003999. Очевидно, сервер не получил байты, пронумерованные между ними. Затем сервер решает подтвердить все данные вплоть до потерянных, то есть отправить обратно сегмент с полем подтверждения, равным 2000. Получение подтверждения, которое не подтверждает все данные, отправленные на данный момент, заставляет хост-отправитель повторно отправить данные. ПК слева может подождать несколько секунд, чтобы убедиться, что другие подтверждения не поступят (используя таймер, называемый таймером повторной передачи), но вскоре решит, что сервер сообщает: "Мне действительно нужно 2000 - отправьте его повторно". ПК слева делает это, как показано на пятом из шести сегментов TCP на рисунке. Наконец, обратите внимание, что сервер может подтверждать не только повторно отправленные данные, но и любые предыдущие данные, которые были получены правильно. В этом случае сервер получил повторно отправленный второй сегмент TCP (данные с порядковыми номерами 20002999), и сервер уже получил третий сегмент TCP (данные с номерами 30003999). Следующее поле подтверждения сервера подтверждает данные в обоих этих сегментах с полем подтверждения, равным 4000. Управление потоком с использованием окон TCP реализует управление потоком, используя концепцию окна, которая применяется к количеству данных, которые могут быть ожидающими подтверждения в любой момент времени. Концепция окна позволяет принимающему хосту сообщать отправителю, сколько данных он может получить прямо сейчас, давая принимающему хосту способ замедлить или ускорить отправляющий хост. Получатель может перемещать размер окна вверх и вниз (это называется скользящим окном или динамическим окном), чтобы изменить объем данных, который может отправить хост-отправитель. Механизм раздвижного окна имеет больше смысла на примере. В примере, показанном на рисунке 9, используются те же основные правила, что и в примерах на нескольких предыдущих рисунках. В этом случае ни один из сегментов TCP не содержит ошибок, и обсуждение начинается на один сегмент TCP раньше, чем на предыдущих двух рисунках. Начнем с первого сегмента, отправленного сервером на ПК. Поле Acknowledgment должно быть вам знакомо: оно сообщает ПК, что сервер ожидает следующий сегмент с порядковым номером 1000. Новое поле, поле окна, установлено на 3000. Поскольку сегмент передается на ПК, это значение сообщает ПК, что ПК может послать не более 3000 байтов по этому соединению до получения подтверждения. Итак, как показано слева, ПК понимает, что может отправлять только 3000 байтов, и прекращает отправку, ожидая подтверждения, после отправки трех 1000-байтовых сегментов TCP. Продолжая пример, сервер не только подтверждает получение данных (без потерь), но и решает немного увеличить размер окна. Обратите внимание, что второе сообщение, идущее справа налево на рисунке, на этот раз с окном 4000. Как только ПК получает этот сегмент TCP, ПК понимает, что он может отправить еще 4000 байтов (окно немного больше, чем предыдущее значение). Обратите внимание, что хотя на последних нескольких рисунках показаны примеры с целью объяснения того, как работают механизмы, из этих примеров может сложиться впечатление, что TCP заставляет хосты сидеть и долго ждать подтверждения. TCP не хочет заставлять хост-отправитель ждать отправки данных. Например, если подтверждение получено до того, как окно будет исчерпано, начинается новое окно, и отправитель продолжает отправлять данные до тех пор, пока текущее окно не будет исчерпано. Часто в сети, где мало проблем, мало потерянных сегментов и небольшая перегрузка, окна TCP остаются относительно большими, а узлы редко ждут отправки. Закрепим самое важное про TCP и UDP в следующей статье.
ВЕСЕННИЕ СКИДКИ
40%
50%
60%
До конца акции: 30 дней 24 : 59 : 59