Домашний интернет по кабелю от провайдера. Кабель подключен к сетевому адаптеру на мат плате компа.
Я уже отключил "Клиент для сетей Microsoft", "Общий доступ к файлам и принтерам для сетей Microsoft", так как мне не нужны сетевые папки и других компов у меня нет. И хочу отключить лишнее чтобы повысить безопасность в сети.
Нужны ли мне эти компоненты обведенные красным? Что не будет работать если я их отключу?

Здравствуйте, CRT, Вы писали:

CRT>Домашний интернет по кабелю от провайдера. Кабель подключен к сетевому адаптеру на мат плате компа.
CRT>Я уже отключил "Клиент для сетей Microsoft", "Общий доступ к файлам и принтерам для сетей Microsoft", так как мне не нужны сетевые папки и других компов у меня нет. И хочу отключить лишнее чтобы повысить безопасность в сети.
CRT>Нужны ли мне эти компоненты обведенные красным? Что не будет работать если я их отключу?

CRT>Image: 4Qs8IiW.png

Чисто для интернета достаточно оставить IPv4 и QoS.

IPv6 пригодится только если провайдер предоставляет такой "белый" адрес (т.е. он должен начинаться на любое кроме fdeX fe80 fec0).

Для безопасности, запретить все входящие соединения, простому пользователю они не нужны никакие ни при каких обстоятельствах.

Все проблемы от жадности и глупости

Здравствуйте, Stanislaw K, Вы писали:

SK>Для безопасности, запретить все входящие соединения, простому пользователю они не нужны никакие ни при каких обстоятельствах.

Хм, а разве мессенджер не на них работает ?

Здравствуйте, CRT, Вы писали:

CRT>Домашний интернет по кабелю от провайдера. Кабель подключен к сетевому адаптеру на мат плате компа.
CRT>Я уже отключил "Клиент для сетей Microsoft", "Общий доступ к файлам и принтерам для сетей Microsoft", так как мне не нужны сетевые папки и других компов у меня нет. И хочу отключить лишнее чтобы повысить безопасность в сети.
CRT>Нужны ли мне эти компоненты обведенные красным? Что не будет работать если я их отключу?

Не нужны. Ничего важного. В Висте LLDP-протокол позволял красивую диаграму сети рисовать, а сейчас вообще непонятно зачем нужен. ("Драйвер протокола LLDP" соответственно тоже можно вырубить)

Здравствуйте, Pavel Dvorkin, Вы писали:


PD>Хм, а разве мессенджер не на них работает ?

Он работает на исходящих ко внешнему серверу

Т.е. на сетевом адаптере нет listening socket

Входящие сообщение разрешены т.к. Firewall рассматривает это как установленное соединениеб начатое мессенжером ко внешнему серверу

Windows Firewall — stateful

Здравствуйте, Vetal_ca, Вы писали:

PD>>Хм, а разве мессенджер не на них работает ?

V_>Он работает на исходящих ко внешнему серверу

V_>Т.е. на сетевом адаптере нет listening socket

V_>Входящие сообщение разрешены т.к. Firewall рассматривает это как установленное соединениеб начатое мессенжером ко внешнему серверу

Хм, так что, клиент непрерывно делает запросы на сервер, нет ли там чего-то ? Или там постоянно открытое соединение ? Но тогда, выходит, сервер их поддерживает для миллионов клиентов...

Если да, то почему ? Не проще было бы с сервера сделать запрос на клиента ?

PD>Хм, так что, клиент непрерывно делает запросы на сервер, нет ли там чего-то ? Или там постоянно открытое соединение ?

Там зачастую HTTP long polling
https://datatracker.ietf.org/doc/html/rfc6202#section-2
TCP соединение скорее всего будет открыто, но не обязательно.

PD> Но тогда, выходит, сервер их поддерживает для миллионов клиентов...

для IM, где постоянно что-то происходит (смена статусов и пр), их так и так придется держать (что иницированные с одной стороны, что с другой).

PD>Если да, то почему ? Не проще было бы с сервера сделать запрос на клиента ?

Ну во-первых клиенты в массе своей за NAT или firewall.
Во-вторых у клиента и IP может неожиланно поменяться.
В третьих для клиента больше вероятность уйти в оффлайн, чем для сервера. А пытаться достучаться до оффлайн клиента, это тоже нагрузка.

Но когда дело доходит до передачи данных (файлов, аудио, видео), то конечно становится выгоднее не гонять этот трафик через сервер.
И здесь начинаются попытки "пробить" NAT/firewall, что описано в https://datatracker.ietf.org/doc/html/rfc8445
И тут как раз входящие соединения были бы полезны, но если NAT на стороне ISP, то шансы на успех невелики.

Здравствуйте, Pavel Dvorkin, Вы писали:


V_>>Входящие сообщение разрешены т.к. Firewall рассматривает это как установленное соединениеб начатое мессенжером ко внешнему серверу

PD>Хм, так что, клиент непрерывно делает запросы на сервер, нет ли там чего-то ? Или там постоянно открытое соединение ? Но тогда, выходит, сервер их поддерживает для миллионов клиентов...

PD>Если да, то почему ? Не проще было бы с сервера сделать запрос на клиента ?

Отчасти можно с push уведомлениями (Android, IOS), так что клиент просыпается и делает запрос к серверу. Это не только соединение но и батарейка.

В остальных, reusable connections, connections pooling и многое другое.

Со всходящими не проще, особенно с IPv4/NAT

Да, постоянные соединения это еще удержание состояний во всех NAT на пути к серверу, чтобы запрос мог вернуться к клиенту