Вимоги: На одному сервері процеси взаємодіють між собою за допомогою анонімних конвеєрів, іменованих конвеєрів, файлів відображення пам'яті, HTTP, TCP, стандартних потоків введення/виведення тощо. Іноді серверам потрібно розгортати кілька додатків, і застосунки можуть взаємодіяти між собою за допомогою gRPC та Unix доменних сокетів.
огляд
Сокети домену Unix
Доменні сокети Unix (UDS), локальні сокети або сокети міжпроцесної комунікації (IPC) — це кінцеві точки комунікації, які обмінюються даними між процесами, що працюють у тій самій операційній системі Unix або подібній до Unix.
Назва доменного сокета Unix стосується значення параметра домену, переданого функції, що створила ресурс системи сокета. Також обирається той самий домен зв'язку. [ 1 ] AF_UNIXAF_LOCAL
Допустимі значення параметрів для typeUDS такі:
- SOCK_STREAM (порівняно з TCP) – використовується для сокетів, орієнтованих на поток
- SOCK_DGRAM (порівняно з UDP) – сокет, орієнтований на дейтаграми, для збереження меж повідомлень (як і в більшості реалізацій UNIX, сокети датаграм домену UNIX завжди надійні і не змінюють порядок дейтаграм)
- SOCK_SEQPACKET (порівняно з SCTP) – послідовні сокети пакетів для з'єднань, які зберігають межі повідомлень і доставляють повідомлення у порядку їх надсилання
Інструмент UDS є стандартним компонентом операційної системи POSIX.
Чому використовують доменні сокети Unix?
Сокети домену Unix дозволяють міжпроцесну комунікацію на одній машині. То чому б обрати їх замість TCP/IP? Наприклад, у TCP/IP можна використовувати loopback адресу (localhost) для зв'язку з одним сервером. Чому на Windows варто обрати їх замість конвеєрів іменувань Windows?
Загалом, існує кілька причин, чому ви можете обрати UDS замість TCP/IP для міжпроцесної комунікації:
- Сокети домену Unix зазвичай мають менше накладних витрат і вищу швидкість передачі, ніж використання TCP/IP
- TCP/IP-сокети є обмеженим ресурсом, тоді як доменні сокети Unix не мають жорстких обмежень
- Сокети домену Unix доступні у файловій формі, тому легко «відкрити» відомі шляхи
- Інтеграція з файловими системами також додає додатковий рівень безпеки (якщо у вас немає доступу до шляху до файлу, ви не можете отримати доступ до сокета)
Перший момент легко зрозуміти — швидкий пошук у Google покаже, що бенчмарки UDS і TCP/IP завжди кращі за UDS, бо вони не лише мають значно меншу затримку, а й значно вищу пропускну здатність. Це головним чином пов'язано з тим, що UDS оптимізований для спілкування з одним і тим самим сервером,Для IP-комунікації localhost має проходити через IP-стек як з боку відправника, так і з боку отримувача。
TCP/IP-сокети — це обмежений ресурс; Ви можете використовувати лише до 65 535 розеток одночасно. Якщо додати цю проблему, максимальна кількість розеток, які TIME_WAIT реально доступні, може бути значно меншою за це значення. З'єднання localhost також споживає сокети в цьому пулі. Розумне використання UDS дозволяє уникнути цієї проблеми; Він дозволяє спілкуватися без вичерпання TCP/IP-сокетів.
Сервер
Створіть новий проєкт консолі .NET 8, змініть SDK на Microsoft.NET.Sdk.Web і налаштуйте його наступним чином:
Greet.proto налаштований так:
Код виглядає так:
Після початку компіляції, як показано нижче:
клієнт
Створіть новий проєкт консолі .NET 8 і зверніться до наступних бібліотек:
Метод виклику інтерфейсу gRPC викликається 10 разів, і кожен дзвінок триває 200 мілісекунд, і код має вигляд наступного:
Починайте проєкт, і після завершення виконання виконання, як показано на рисунку нижче:
Посилання:
Вхід за гіперпосиланням видно.
Вхід за гіперпосиланням видно. |