Комментарии 12
Статья хорошая, но кажется, что хаб Developer Relations совсем не форматный для нее (
Часто на собеседованиях спрашивают о таком параметре TCP как Window Size — размер окна. Речь про количество байт, которое вы можете отправить, не дожидаясь подтверждения.
Ну совершенно неоднозначная, а потому непонятная, фраза. Если узел А в заголовке пакета отправил узлу В значение Window = 1024, то попробуйте, опираясь на эту фразу, ответить, кто будет придерживаться этого ограничения при отправке - узел А, узел В или оба узла?
Это сложно. Мне кажется в статье вцелом написано не совсем правильно. Как я это понимаю:
Есть размер окна получателя. Он передается в каждом TCP сегменте. Отправитель может передать данные до значения = полученный ack number + window. Размер окна выставляет получатель. В каждом направлении в сессии свое значение. Это алгоритм скользящего окна, но он служит не для контроля перегрузки сети, а только для контроля перегрузки получателя. Чтобы на приемнике не переполнились буферы. Размер поля 16 бит, те максимум можно разрешить передать 64кб. Для сетей с большим RTT получается очень низкая пропускная способность, поэтому у TCP есть опция window scale, параметр передается в SYN при установке соединения. На него умножается значение заголовка window.
Для контроля перегрузки сети есть алгоритмы congestion control, у которых тоже есть окно. Размером этого окна управляет отправитель. Что логично, так как сеть можно положить не дойдя до получателя, плюс информация о потере пакетов и RTT есть только у отправителя. Медленный старт реализован в congestion control, а не через размер окна в TCP сегменте как написано в статье.
Соответственно отправитель использует наименьшее значение из этих двух окон.
чего-то из истории выпало что другие страны (по)строили свои сети и норвегия вроде как была ближе по коннекту на arpa - а ешё не дали second рашифровку: Управление новейших исследований и продуктов (Advanced Research Products Agency (ARPA)), агентство, выполняющее контрактные заказы Министерства обороны USA
Модель OSI потеряла смысл лет 15 тому назад.
Как только появились протоколы типа АТМ, который лежал ниже 2-го уровня, но выше 1-го.
А потом пошли различные инкапсуляции протоколов, трансляции и прочее.
Да и за все время работы этой модели так и не договорились, что же лежит на 6-ом уровне. Точки зрения на списки протоколов этого уровня менялись совершенно кардинально.
Цеттатто:
Считается, что MAC-адрес нельзя менять, и это практически так и есть.
Можно. И на физическом, и на логическом уровнях.
Очень странная статья. Как будто автор сделал(а) Ctrl + c и Ctrl + v.
Зачем описывать модели OSI и TCP/IP не упоминая кучу других моделей.
Модель OSI это первый шаг к основам стандартизации сетевых протоколов, это фундамент, позволяющий работать разрозненным сетям под одними флагом.
Отличная развернутая статья выглядит так Протоколы семейства TCP/IP. Теория и практика / Хабр (habr.com) .
Но семь уровней модели — это действительно много.
Реальность внесла свои коррективы и эту модель упростила. Сегодня повсеместно используется сетевая модель TCP/IP, в которой вместо семи уровней всего четыре.
Так это не реальность внесла, а умные ребята в 1995 собрались на конференции и внесли изменения.
Вот база всего как я это вижу и понимаю. Увы в статье всё слегка иначе.
Сетевые протоколы и модели OSI: как всё устроено