Comments 30
Созыкин, ты красавчик.
Человек, который явно мне показал, как dns, icmp и tcp работает.
Спасибо тебе дружище ??
Самый лучший и понятный курс по сетям, спасибо!
Что, реально хорош курс по сетям? Тогда у прослушавших не составит труда ответить на несколько простых вопросов:
является ли 1.2.3.4/24 адресом сети?
являются ли 1.2.3.0 и 1.2.3.255 адресами хостов сети 1.2.3.0/24, или это какие-то другие, особые, адреса?
а что за адрес 0.0.0.0 присваивается роутеру?
Курс по сетям не слушал. Но отвечу:
Нет, не является. Это адрес хоста.
Это особые адреса (адрес подсети и адрес для широковещательных сообщений), они исключаются из использования в качестве адресов хостов сети (частные случаи не рассматриваем).
Ответ не мальчика, но целого CCNP.
RFC4632:
In CIDR notation, a prefix is shown as a 4-octet quantity, just like a traditional IPv4 address or network number, followed by the "/" (slash) character, followed by a decimal value between 0 and 32 that describes the number of significant bits.
Здесь ни слова о том, что первые четыре октета обязаны указывать на начало префикса (подсети). Собственно, смысл в нотации «адрес-маска» или «адрес/длина маски» и заключается в том, чтобы любая реализация протокола IP без труда смогла по произвольно взятому адресу из диапазона подсети охарактеризовать эту подсеть при помощи маски. Другое дело, что есть куча кривых реализаций, которые требуют для префиксов указывать на самый первый адрес, но это не меняет стандарта, к счастью.
Заявить частный случай общим и на этом основании отказаться рассматривать общий случай — сильно (нет). Для интернета общим случаем является то, что произвольно выбранный сегмент (подсеть) не подключен к широковещательному сегменту на уровне 2 модели OSI. Таким образом, теряется всякий смысл в «широковещательном» адресе. Более того, такой адрес — всегда есть результат соглашения локальный регистратуры. В любом DHCP сервере под выделеный сегмент есть опция, указывающая, какой адрес сообщать хостам в качестве широковещательного, он может быть произвольным в пределах диапазона сегмента, а хоть бы даже и самый первый. Отдельно смешит всякое утверждение про первый и последний адреса, как особые, в контексте префиксов /31 — эдакий сегмент, где хостам делать вообще нечего, и /32 — который вообще должен сколлапсировать вселенную, потому что на два «особых» обязательных адреса там нет пространства. Что же касается «адреса сети» на уровне хоста — то это вообще не имеет никакого смысла, цискари всех «обманули». Хост в подсети имеет право занимать первый адрес без всякого нарушения протокола IP (не TCP/IP, равно как не колесо/автомобиль и не дека/самокат).
Интересный вопрос: с точки зрения rfc, разрешено ли body(тело) в get запросе?
Чтение RFC очень затягивает. Можно задать вопрос, а потом целый день провести над чтением ответа. Например RFC 9110
https://www.rfc-editor.org/rfc/rfc9110.html#name-changes-from-rfc-7231
B.3. Changes from RFC 7231
The terms "payload" and "payload body" have been replaced with "content", to better align with its usage elsewhere (e.g., in field names) and to avoid confusion with frame payloads in HTTP/2 and HTTP/3. (Section 6.4)
https://www.rfc-editor.org/rfc/rfc9110.html#name-get
9.3.1. GET
Although request message framing is independent of the method used, content received in a GET request has no generally defined semantics, cannot alter the meaning or target of the request, and might lead some implementations to reject the request and close the connection because of its potential as a request smuggling attack (Section 11.2 of [HTTP/1.1]). A client SHOULD NOT generate content in a GET request unless it is made directly to an origin server that has previously indicated, in or out of band, that such a request has a purpose and will be adequately supported. An origin server SHOULD NOT rely on private agreements to receive content, since participants in HTTP communication are often unaware of intermediaries along the request chain.
https://www.rfc-editor.org/rfc/rfc9112#name-request-smuggling
11.2. Request Smuggling
Request smuggling ([Linhart]) is a technique that exploits differences in protocol parsing among various recipients to hide additional requests (which might otherwise be blocked or disabled by policy) within an apparently harmless request. Like response splitting, request smuggling can lead to a variety of attacks on HTTP usage.
[Linhart]
Linhart, C., Klein, A., Heled, R., and S. Orrin, "HTTP Request Smuggling", June 2005, https://www.cgisecurity.com/lib/HTTP-Request-Smuggling.pdf.
В дополнение рекомендую почитать документ "How to Read an RFC" - https://www.ietf.org/blog/how-read-rfc/, особенно секцию, которая объясняет, как понимать в RFC ключевые слова MUST, SHOULD и т.п.
Проблема только в том, что доля HTTP трафика исчезающе мала и стремится к нулю.
Hidden text
так под шифром TLS то лежит всё тот же http в том же виде, и вся работа с кешами, типами запроса и всем прочим такая же.
Да, именно так. RFC с описанием HTTPS даже называется "HTTP Over TLS" - https://datatracker.ietf.org/doc/html/rfc2818
Кто бы сделал нейросеть для настройки сетей по описанию, чтобы в разных средах и в виде диалога, да с проверкой нескольких вариантов и выявления оптимального.
А gpt разве не на все руки мастер? (ну, кроме 1С))
К сожалению не профессионалу объяснить то чего нет в гугле (значит нет в интернете) он не может, его рассуждения ограничиваются общими фразами. А вот чтобы для конкретеого устройства, что и куда вписать, какую галочку нажать, такого ещё gpt не умеет. Т.е. всё ещё оператором gpt, для получения специализированной справки должен быть профессионал, а не обычный пользователь.
Так же и с докером, если не понимаешь скольк и каких строчек кода должно быть, то копипастом не отделаешься. Ещё же каждому приложению нужно разные условия маршрутизации указать и расмещения в этой иерархии линукса и т.д. ...
Сравнение с фильмом "ОНА" ещё очень несвоевременно.
А вот чтобы для конкретеого устройства, что и куда вписать, какую галочку нажать, такого ещё gpt не умеет.
Вполне умеет, если данные актуальны на дату его обучения.
GPT-4o, вроде как все адекватно написал, правда названия портов у него чуть другие, но это не существенно: https://pastebin.com/8sDMJGkf
До сих пор мне NAS qnap не может настроить виртуальный коммутатор так как я прошу, и так чтобы это стало понятно , то что он отвечает, есть в интернете на десятки часов чтения, но решение предоставить сегодня конкретно он не может, потому что в интернете нет мануалов, строго под мой случай, а он ссылается на конкретные данные, он выдает общие фразы и ссылки на те форуму, котрые и так можно найти гуглом. Т.е. он не создаёт, а больше цитирует.
Большое спасибо за такой материал! Пожалуйста, продолжайте!
Спасибо большое за статью, как всегда все сложное простым языком)
Я что-то упустил? Если убрать воду про версии http, и виды запросов (не думаю что кто-то на Хабре не знает про них, если что wiki в помощь) то остаётся только рекомендация запустить Putty под Windows.
Возможно, это совсем для "чайников"? Когда-то я только благодаря видео Андрея начал понимать сети, маски и вот это всё. Преподаватели в технаре никак нам не могли (не хотели либо не умели) донести базовых вещей, очень сложно это объясняли из-за чего больше путаницы было в голове.
А потом я нашёл плейлист Андрея Созыкина по сетям и всё встало на места :)
причем вредная рекомендация, поскольку к серверу можно подключаться и без него. Ничего лишнего ставить не надо.
Протокол HTTP