Андрей, хочу выразить огромную благодарность за проделанную работу!!!! Я очень завидую вашим студентам, в мое время можно было только мечтать о подобном преподе, который бы кратко и без лишней воды, может излагать довольно сложный материал. Ваши лекции содержат всю необходимую информацию, для того чтобы понять основу работы сетей, а если надо углубиться, то все необходимые отрывные точки для этого. Надеюсь я не надоел вам своими комментариями в каждой лекции с различными уточнениями, так как я узнал много нового из ваших лекций, мне приходилось углубляться в чтение rfc, где я находил какие - то интересные моменты. С другой стороны своими комментариями, я надеялся хоть как - то поднять ваш курс в поиске. Удачи вам!!!
+conquistador, спасибо, это как раз результат, которого я хотел добиться. Невозможно разбираться во всех тонкостях всех сетевых технологий и протоколов. Очень приятно, что помогаете и пишите уточнения в комментариях!
Отличные лекции, все предельно ясно и сжато, понятено даже для тех, кто только начинается разбираться в сетях и протоколах, не имея предварительной технической подготовки. Спасибо!
Смотрю курс с самого начала, очень нравится ваш подход. В единицу времени вложено максимально много информации, при этом не теряется информативность. Сам учусь на программиста и очень рад, что нашел вас. Спасибо! Порой мне кажется, что вы устаете отвечать всем на благодарность, под вашими роликами очень много таких комментариев. Но вы действительно специалист в преподавании!
Еще раз повторюсь, отличный курс, лучший по этой теме на русском, что я смог найти. Пока я досмотрел до этого видео, у меня уже такое ощущение, что я автора знаю несколько лет )
Андрей, благодарю вас за потрясающие курсы! Это действительно тот момент, когда нет воды, сложный материал преобразуется в доходчивое исполнение. Очень рад, что нашел Вас! Именно по этим знаниям у меня жирующий пробел. Так что погнали :)
Хз почему, но когда я что-то ввожу в поисковой системе, чтобы найти ответ на вопрос касательно сетей, то ваши видео самые информативные и понятные для человека, который просто интересуется. Вообщем спасибо хотел сказать за вашу работу и пожелать хорошего дня 😉
+Cobra Cyborg, это не страшно, все равно будет работать. Я многие примеры делаю упрощенными, чтобы не загромождать слайд. В реальных сайтах так, конечно же, лучше не делать.
Андрей, что вы подразумеваете под режимом работы запрос-ответ? То, что запрос и ответ проходят в рамках одного соединения (по TCP)? Какие еще режимы могут быть? Например просто отправка дейтаграмм оп UDP - это не режим запрос-ответ?
Запрос-ответ подразумевает, что сервер не может по своей инициативе ничего отправить клиенту. Альтернативный вариант используется в Web Socket, где устанавливается соединение и обе стороны могут в любое время передавать друг другу данные. В HTTP2 можно отправлять сразу несколько запросов, не дожидаясь поступления ответов на каждый запрос, что более эффективно с точки зрения производительности. UPD - это протокол транспортного уровня, он может использоваться в разных режимах.
@@AndreySozykin спасибо! Писал Вам длинющий вопрос, по поводу того, что браузер накидывает целую кучу лишних GET-запросов. А сейчас разобрался, что это он favicon.ico требует))) Причём и firefox и chrome так делают.
Насколько я понял, изучая HTTP и REST, на уровне абстракции вэба существуют "ресурсы", но не "серверы", а идентифицируются эти ресурсы по URI (не URL). Запросы в http это буквально "ресурс, дай" или "ресурс, возьми" и прочие, а не "браузер, отправь письмо по такому-то адресу с таким-то письмом". Ресурс в свою очередь обрабатывает запрос и возвращает репрезентацию обновлённого состояния (отсюда и REST). Вэб-браузер, вэб-сервер и навигация в сети это детали имплементации, а не сервис. Почему-то везде рассказывают про то как работает вэб, но не про то, что он собственно делает.
Формально вы правы: HTTP работает с абстрактными ресурсами, на которыми можно выполнять перечень команд (HTTP verbs). Но на уровне абстракций это все очень плохо воспринимается, особенно новичками. Поэтому я и говорю про Web-серверы, а не ресурсы, про URL, который все используют, а не URI. Это сознательное упрощение для начального уровня. После понимания основ, можно переходить уже к более абстрактным понятиям. Часто бывает, что за один ресурс отвечает кластер из нескольких серверов, поэтому понятие абстрактного ресурса важно. А серверы, кластеры серверов или контейнеров - это действительно детали реализации, которые на практике могут сильно отличаться.
@@AndreySozykin хм, если честно, мне вэб стал понятнее именно после переваривания REST. Я практически уверен, что у вас бы вышло уложить основные идеи диссертации Роя Филдинга в 15-20 минут. Думаю для многих это открыло бы глаза. Хотя это конечно моё мнение, люди все разные, да и вы преподаватель вам наверное виднее как лучше преподавать) В любом случае отличные у вас курсы! Огромное спасибо!
странное ощущение от вашего комментария: вроде, замаячило более четкое понимание работы веба, но что-то ускользает🤔... так а что такое ресурс? это сервер или браузер? а страница это ресурс? и в чем отличие uri от url? пс. а рест и соап я так и не смог понять по статьям.
Андрей, а вот я как понял, компании "почтовики" каким-то образом используют протокол IMAP который начинает функционировать уже на серверах "почтовика", а все данные(команды, аутентификационные) передаются посредством https я правильно понял? А каким образом автоматизируется перевод команд из сообщения https в сообщения imap?
"Почтовики" используют Web-приложение для чтения почты. С вами это приложение общается по протоколу HTTPS. А с почтовым сервером через IMAP. Так что никакого преобразования не происходит. Web-приложение сначала получатет данные от почтового сервера с помощью IMAP. Затем эти данные представляются в виде Web-странички и передаются вам в браузер с помощью HTTPS. Отдельный вопрос с аутентификацией. Для Web-приложения и почтового сервера могут использоваться сторонние протоколы аутентификации, например, OpenID (вот реализация от Google - developers.google.com/identity/protocols/OpenIDConnect).
+Ганс-Ульрих Рудель, действительно, в документах RFC пишется Header (заголовок) в единственном числе и Header Fields (поля заголовка). Но в RFC 7230 используется также множественное число: "All HTTP/1.1 messages consist of a start-line followed by a sequence of octets in a format similar to the Internet Message Format [RFC5322]: zero or more header fields (collectively referred to as the "headers" or the "header section")..." Заголовки во множественном числе часто используется в разных источниках, в том числе в википедии: ru.wikipedia.org/wiki/%D0%97%D0%B0%D0%B3%D0%BE%D0%BB%D0%BE%D0%B2%D0%BA%D0%B8_HTTP В иностранных источниках тоже пишут во множественном числе. Например, книга "HTTP: The Definitive Guide" www.safaribooksonline.com/library/view/http-the-definitive/1565925092/ch11s02.html Не думаю, что это принципиальный вопрос.
Ограничения зависят от типа запроса, а также типа клиента и сервера. Для запросов GET типичное ограничение по объему в несколько килобайт, для запросов POST - до гигабайт. Ссылка на подробности - stackoverflow.com/questions/2659952/maximum-length-of-http-get-request
Спасибо! Вычислить IP-адрес отправителя? Да, можно, т.к. он есть в заголовке IP-пакета. Но этот адрес может быть изменен, если используется NAT или прокси.
Ошибка 404 трактуется так, что сервер способен ответить на запрос клиента, но такой страницы на сервере нет. То есть клиент запросил страницу, которой не существует. Ошибки на стороне сервера означают, что проблемы с ПО сервера и запрос не может быть обработан.
Здравствуйте. Помогите разобраться . Отправляю данные по udp на сайт на порт 60000. На сервере порт открыт но данные не проходят зависает функция soket_read. Клиенту приходит ответ Icmp порт не доступен.в чем может быть дело?
не могли бы вы более внятно обьяснить про методы get & post, в каких случаях они используются и почему) столько информации каждый раз сбивает с толку(все определенно понятно какой размер и как передается).
GET используется для запроса веб. страницы. POST - для отправки информации на сервер, например, из формы. Это не строго, данные можно отправить и через запрос GET, а через POST просто запрашивать страницу не передавая данные. Но обычно стараются использовать GET для запросов, а POST - для отправки данных.
Сейчас методы используются немного иначе, без привязки к изначальному смыслу. Основное отличие - в GET (обычно, но не обязательно) нет тела, только путь. А в POST тело есть. Если для обработки запроса нужно передать с клиента на сервер много данных (файлы, массивы, сложные вложенные объекты) то GET не подходит, применяют POST.
Ни одного лишнего слова, ни одной потеряной секунды. Спасибо за качественную и потому доходчивую лекцию.
Пожалуйста! Рад, что понравилось!
ты рофлишь? Перескажи мне первый слайд
@@artemlobanchikov2270 не обьязательно всё держать в оперативке
Ахахахах, одна вода
Андрей, хочу выразить огромную благодарность за проделанную работу!!!!
Я очень завидую вашим студентам, в мое время можно было только мечтать о подобном преподе, который бы кратко и без лишней воды, может излагать довольно сложный материал.
Ваши лекции содержат всю необходимую информацию, для того чтобы понять основу работы сетей, а если надо углубиться, то все необходимые отрывные точки для этого.
Надеюсь я не надоел вам своими комментариями в каждой лекции с различными уточнениями, так как я узнал много нового из ваших лекций, мне приходилось углубляться в чтение rfc, где я находил какие - то интересные моменты.
С другой стороны своими комментариями, я надеялся хоть как - то поднять ваш курс в поиске.
Удачи вам!!!
+conquistador, спасибо, это как раз результат, которого я хотел добиться.
Невозможно разбираться во всех тонкостях всех сетевых технологий и протоколов. Очень приятно, что помогаете и пишите уточнения в комментариях!
++
@@AndreySozykin сейчас 2021, но и теперь ваши лекции помогают людям. Огромное спасибо за ваш труд, Андрей!
никаких "поставьте лайк и подпишитесь" за это отдельный лайк)
Спасибо!
Ramil Askerov и подписка)
Отличные лекции, все предельно ясно и сжато, понятено даже для тех, кто только начинается разбираться в сетях и протоколах, не имея предварительной технической подготовки. Спасибо!
Пожалуйста! Рад, что нравится!
Смотрю курс с самого начала, очень нравится ваш подход. В единицу времени вложено максимально много информации, при этом не теряется информативность. Сам учусь на программиста и очень рад, что нашел вас. Спасибо!
Порой мне кажется, что вы устаете отвечать всем на благодарность, под вашими роликами очень много таких комментариев. Но вы действительно специалист в преподавании!
Андрей, Спасибо, ваши лекции стоят очень дорого!!!
Пожалуйста!
Ну да... читать с википедии это очень дорого....
Максимальное количество информации за минимальное количество времени. Топчик! Спасибо! Очень круто!
Пожалуйста! Рад, что понравилось!
Великолепный контент!!! Смотрю с удовольствием Ваши лекции! Благодарю Вас, что уделили время для записи видео и тем самым передали свои знания.
Пожалуйста! Рад, что нравится!
Спасибо вам большое за ваши курсы, для человека который только пытается стать на путь айти, вы правда все очень доходчиво объяснеете.
Пожалуйста! Рад, что формат нравится!
Еще раз повторюсь, отличный курс, лучший по этой теме на русском, что я смог найти. Пока я досмотрел до этого видео, у меня уже такое ощущение, что я автора знаю несколько лет )
+Maksym Skachkov, спасибо за приятный отзыв!
Офигеть вы всё чётко рассказали, спасибо огромное))
Пожалуйста! Рад, что понравилось :-)
@@AndreySozykin , а разве за место h1 и ul используется не head и body ?
Очень хорошая подача материала, всё понятно и ничего не сбивает с толку.
Спасибо за лекции
Вновь и вновь возвращаюсь к вашему видео, чтобы уложить тему в голове, вы потрясающе четко и понятно доносите материал!
Спасибо! Рад, что понятно и полезно!
Сразу видно профессионал своего дела. Люди хорошо и понятно могут объяснить только то, что сами хорошо понимают.
Андрей, благодарю вас за потрясающие курсы!
Это действительно тот момент, когда нет воды, сложный материал преобразуется в доходчивое исполнение.
Очень рад, что нашел Вас!
Именно по этим знаниям у меня жирующий пробел.
Так что погнали :)
Успехов!
Спасибо за приятный отзыв!
Увидела, что вы рассказываете про HTTP и очень обрадовалась, нет сомнений, что это будет качественная информация.
Хз почему, но когда я что-то ввожу в поисковой системе, чтобы найти ответ на вопрос касательно сетей, то ваши видео самые информативные и понятные для человека, который просто интересуется. Вообщем спасибо хотел сказать за вашу работу и пожелать хорошего дня 😉
Спасибо за полезный материал. Без воды и всё по делу. Да, и на сайт ваш обязательно загляну, наверняка и там полезный материал.
Пожалуйста!
Спасибо большое за такие ясные и доходчивые объяснения! Очень полезное видео
Попрежнему актуальный видос. Огромное Вам спасибо!
Спасибо Андрей Владимирович !!! Вы отличный преподаватель !!!
Пожалуйста! Рад, что понравилось!
освежить знания по сетям всегда захожу к вам, спасибо!
Очень рад, что курсы полезны постоянно, а не один раз!
Спасибо большое! Любой ваш урок - клад.
Пожалуйста! Рад, что нравится!
Пора уже начинать готовить лекцию по HTTP/3 :)
Да, что-то давно не делал роликов про компьютерные сети. Сначала про HTTP/2 хотел 😊
Мое почтение! Спасибо за Ваш труд! Отдельное спасибо за резюме под видео!
Академическое качество! Спасибо)
Пожалуйста! Рад, что понравилось!
Очень интересно и доходчиво ) спасибо за материал.
Пожалуйста!
Спасибо огромное Андрей! Очень просто и очень понятно объясняете!
Пожалуйста!
Спасибо вам, весьма толковый курс и ваши способности донести материал - очень хороши!)))
Пожалуйста! Успехов в изучении сетей!
Самое лучшее объяснение работа протокола HTTP
Спасибо!
Спасибо огромное за проделанную Вами высококачественную работу!
Спасибо вам, Андрей!
Пожалуйста!
Спасибо.
Qilgan bu yaxshi amallariyezni ajrini bersin.
Пожалуйста!
спасибо, Андрей
никак не понимал HTTP, а теперь понял
Легенда, смотрел 4г назад, смотрю сейчас)
Прекрасная подача материала, большое спасибо
очень круто! спасибо)
+YouTop, пожалуйста!
Полезное видео особенно когда нужно быстро повторить инфу.
Спасибо!
Спасибо большое! Очень информативно и доступно
Пожалуйста!
Лучшее объяснение :)
Спасибо!
Дякую за корисний контент :)))))
Спасибо, очень понятно и доступно!
Пожалуйста!
СПАСИБО ВАМ БОЛЬШОЕ АНДРЕЙ !
Большое пожалуйста!
Спасибо большое, понятно даже гуманитарию :)
Отлично, очень рад!
Спасибо! Лучшие лекции. Жаль, что нет по http2.
Пожалуйста! HTTP2 обязательно сделаю!
Спасибо, думаю уже актуально по HTTP2 выпустить лекцию.
Да, готовлю такую лекцию уже.
@@AndreySozykin Здравствуйте, подготовили по HTTP2 лекцию ? Что-то по каналу не ищется, мож там название какое-то другое.
Лектор- крутой!!! Спасибо!!!!
Пожалуйста! Рад, что нравится!
Отличное видео! простое и понятное. Спасибо!
Спасибо, просто, доходчиво и по полочкам 🤓👍
Пожалуйста!
прекрасные объяснения. спасибо!
Пожалуйста!
Хороший преподаватель. Спасибо
Spasibo Za VASH TRUD :)
+atilla atilla , пожалуйста?
Заметил, что в коде html страницы, предложение "Тим Бернерс-Ли в ЦЕРН..." не заключено в теги элемента p (paragraph).
+Cobra Cyborg, это не страшно, все равно будет работать.
Я многие примеры делаю упрощенными, чтобы не загромождать слайд.
В реальных сайтах так, конечно же, лучше не делать.
Andrey Sozykin окей)
Спасибо за лекцию!
Пожалуйста!
Большое спасибо за видео!
Пожалуйста!
Андрей, что вы подразумеваете под режимом работы запрос-ответ? То, что запрос и ответ проходят в рамках одного соединения (по TCP)? Какие еще режимы могут быть? Например просто отправка дейтаграмм оп UDP - это не режим запрос-ответ?
Запрос-ответ подразумевает, что сервер не может по своей инициативе ничего отправить клиенту. Альтернативный вариант используется в Web Socket, где устанавливается соединение и обе стороны могут в любое время передавать друг другу данные.
В HTTP2 можно отправлять сразу несколько запросов, не дожидаясь поступления ответов на каждый запрос, что более эффективно с точки зрения производительности.
UPD - это протокол транспортного уровня, он может использоваться в разных режимах.
Очень доходчиво, спасибо.
Пожалуйста!
Отлично прочитано
Спасибо!
Хочу сделать клиент+сервер одновременно на микроконтроллере, этот урок очень помог
Отлично, успехов!
@@AndreySozykin спасибо! Писал Вам длинющий вопрос, по поводу того, что браузер накидывает целую кучу лишних GET-запросов. А сейчас разобрался, что это он favicon.ico требует)))
Причём и firefox и chrome так делают.
@@Voha
что такое favikon.ico?
Огромное спасибо за видео!
ЗЫ: Заметил, что число названо неправильно 5:25 там 5 тысяч, 161 байт.
на 10:21 так же произносите, значит это была не ошибка и я чего-то не знаю.
Как же вы всё усложняете...
По-моему все крайне доходчиво
Отличное видео, благодарю:)
Круто!
Спасибо!
Спасибо за урок
Пожалуйста!
Андрей, благодарю за отличный курс и подачу. Планируется ли продолжение курса и рассказ о HTTP2 и HTTP3?
В следующем году планирую обновить курс по сетям в целом. В том числе добавлю материалы по HTTP2 и HTTP3.
На первый день Бог создал компьютер и интернет. На второй день Бог создал Андрея Созыкина. И на третий день Андрей Созыкин создал свои курсы...
Спасибо за видео!
Пожалуйста!
Спасибо огромное!
спасибо, красавчик
!!
Пожалуйста!
нормально перед сном слушать что б уснуть побыстрее ))
Хоть в чем-то курс полезен 😉
Благодарю 👍
спасибо!!)
Пожалуйста!
В одной книге прочитал, что при GET запросе, Content-Length не показывается, только при POST. (PHP 7 в подлиннике)
Спасибо. Из методов еще можно добавить PATCH
классно!
Спасибо!
Пожалуйста!
спасибо)
Пожалуйста!
Лайк
Спасибо!
Насколько я понял, изучая HTTP и REST, на уровне абстракции вэба существуют "ресурсы", но не "серверы", а идентифицируются эти ресурсы по URI (не URL). Запросы в http это буквально "ресурс, дай" или "ресурс, возьми" и прочие, а не "браузер, отправь письмо по такому-то адресу с таким-то письмом". Ресурс в свою очередь обрабатывает запрос и возвращает репрезентацию обновлённого состояния (отсюда и REST). Вэб-браузер, вэб-сервер и навигация в сети это детали имплементации, а не сервис. Почему-то везде рассказывают про то как работает вэб, но не про то, что он собственно делает.
Формально вы правы: HTTP работает с абстрактными ресурсами, на которыми можно выполнять перечень команд (HTTP verbs). Но на уровне абстракций это все очень плохо воспринимается, особенно новичками. Поэтому я и говорю про Web-серверы, а не ресурсы, про URL, который все используют, а не URI.
Это сознательное упрощение для начального уровня. После понимания основ, можно переходить уже к более абстрактным понятиям.
Часто бывает, что за один ресурс отвечает кластер из нескольких серверов, поэтому понятие абстрактного ресурса важно. А серверы, кластеры серверов или контейнеров - это действительно детали реализации, которые на практике могут сильно отличаться.
@@AndreySozykin хм, если честно, мне вэб стал понятнее именно после переваривания REST. Я практически уверен, что у вас бы вышло уложить основные идеи диссертации Роя Филдинга в 15-20 минут. Думаю для многих это открыло бы глаза. Хотя это конечно моё мнение, люди все разные, да и вы преподаватель вам наверное виднее как лучше преподавать) В любом случае отличные у вас курсы! Огромное спасибо!
странное ощущение от вашего комментария: вроде, замаячило более четкое понимание работы веба, но что-то ускользает🤔...
так а что такое ресурс? это сервер или браузер? а страница это ресурс? и в чем отличие uri от url?
пс.
а рест и соап я так и не смог понять по статьям.
Very good. Thanks
пишу комментарий, чтобы в Fiddler посмотреть как работает метод POST)
Отлично! Честно сказать, забыл про Fiddler. Но тема интересная, надо будет сделать видео.
@@AndreySozykin было бы здорово. У Вас самое качественное изложение материала этих тем в русскоязычном youtube
Андрей, а вот я как понял, компании "почтовики" каким-то образом используют протокол IMAP который начинает функционировать уже на серверах "почтовика", а все данные(команды, аутентификационные) передаются посредством https я правильно понял? А каким образом автоматизируется перевод команд из сообщения https в сообщения imap?
И наоборот из сообщения IMAP в сообщение HTTPS.
"Почтовики" используют Web-приложение для чтения почты. С вами это приложение общается по протоколу HTTPS. А с почтовым сервером через IMAP. Так что никакого преобразования не происходит.
Web-приложение сначала получатет данные от почтового сервера с помощью IMAP. Затем эти данные представляются в виде Web-странички и передаются вам в браузер с помощью HTTPS.
Отдельный вопрос с аутентификацией. Для Web-приложения и почтового сервера могут использоваться сторонние протоколы аутентификации, например, OpenID (вот реализация от Google - developers.google.com/identity/protocols/OpenIDConnect).
HTTP - протокол прикладного уровня, на слайде ошибка - 3:14. Лучше указать 80/TCP
URL - правильный перевод: Единый (Одноформенный) Указатель Ресурса, где вы там уникальный нашли, не пойму
Да, правильный перевод единый или унифицированный указатель ресурса.
спасибо
Пожалуйста!
4:45 Host, Content-Type, Cjntent-Length - не заголовки, а параметры заголовка. Заголовок же должен быть один, как и тело сообщения
+Ганс-Ульрих Рудель, действительно, в документах RFC пишется Header (заголовок) в единственном числе и Header Fields (поля заголовка). Но в RFC 7230 используется также множественное число:
"All HTTP/1.1 messages consist of a start-line followed by a sequence
of octets in a format similar to the Internet Message Format
[RFC5322]: zero or more header fields (collectively referred to as
the "headers" or the "header section")..."
Заголовки во множественном числе часто используется в разных источниках, в том числе в википедии:
ru.wikipedia.org/wiki/%D0%97%D0%B0%D0%B3%D0%BE%D0%BB%D0%BE%D0%B2%D0%BA%D0%B8_HTTP
В иностранных источниках тоже пишут во множественном числе. Например, книга "HTTP: The Definitive Guide"
www.safaribooksonline.com/library/view/http-the-definitive/1565925092/ch11s02.html
Не думаю, что это принципиальный вопрос.
спасибо
Вот это я понимаю профессиональный reply... :)))
Хорошая лекция, спасибо! Какой говорите клиент под linux для ручных запросов?
telnet
но есть что-то и более современное
Андрей, подскажите пожалуйста, а есть ли какие-то ограничения на длину запроса?
Ограничения зависят от типа запроса, а также типа клиента и сервера.
Для запросов GET типичное ограничение по объему в несколько килобайт, для запросов POST - до гигабайт. Ссылка на подробности - stackoverflow.com/questions/2659952/maximum-length-of-http-get-request
@@AndreySozykin спасибо большое!!!
Спасибо, лайк) но все же 5161, не 51061, два раза оговорочка🤭
Да, надо будет обновить лекцию.
Класс всё ясно рассказал но я не понял по HTTP могут айпи адрес вычислить?
Спасибо! Вычислить IP-адрес отправителя? Да, можно, т.к. он есть в заголовке IP-пакета. Но этот адрес может быть изменен, если используется NAT или прокси.
ну тебя найдут если что.
Круто) но я смотрю видео в 2022 и ютуб уже работает на http 3 (и на UDP + quic) :( хотелось бы новую инфу получить на этот счёт
Это видео для начинающих, основа. Не всем и не всегда нужна версия 3. HTTP применяется не только в браузере, но и между отдельными сервисами.
ошибка 404 - проблема на стороне клиента. Но сайт то не найдет на сервере. Как так?
Ошибка 404 трактуется так, что сервер способен ответить на запрос клиента, но такой страницы на сервере нет. То есть клиент запросил страницу, которой не существует.
Ошибки на стороне сервера означают, что проблемы с ПО сервера и запрос не может быть обработан.
спасибо, понял.
Спасибо из Украины.
cool
Thank you!
3:34 что такое ЦЕРН ? ЦЕРН - Европейская организация по ядерным исследованиям, крупнейшая в мире лаборатория физики высоких энергий.
Да, именно так. Тим Бернерс-Ли создал WWW когда работал там.
Здравствуйте. Помогите разобраться . Отправляю данные по udp на сайт на порт 60000. На сервере порт открыт но данные не проходят зависает функция soket_read. Клиенту приходит ответ Icmp порт не доступен.в чем может быть дело?
Если приходит сообщение ICMP порт не доступен, то порт закрыт.
За 10 хвилин прослуховування даного матеріала, 3 рази заснув!
Видимо не для слабоумных создают такие материалы...
@@ilyashevelev9256 Ну так , не для вас)
Андрей, почему называете content length 50161, на слайде 5161? На 5:48
В прошлых лекциях проверьте, тоже аналогичные ошибки.
Действительно, оговорка. Спасибо!
Учту, когда буду перезаписывать обновленный вариант лекции.
Его называют какимто неопределённым "протоколом". Но это очень похоже на язык программирования. Это язык?
http - это именно протокол. а вот html, на котором пишутся странички - это уже язык. Только не язык программирования, а разметки
не могли бы вы более внятно обьяснить про методы get & post, в каких случаях они используются и почему) столько информации каждый раз сбивает с толку(все определенно понятно какой размер и как передается).
GET используется для запроса веб. страницы.
POST - для отправки информации на сервер, например, из формы.
Это не строго, данные можно отправить и через запрос GET, а через POST просто запрашивать страницу не передавая данные.
Но обычно стараются использовать GET для запросов, а POST - для отправки данных.
Сейчас методы используются немного иначе, без привязки к изначальному смыслу. Основное отличие - в GET (обычно, но не обязательно) нет тела, только путь. А в POST тело есть. Если для обработки запроса нужно передать с клиента на сервер много данных (файлы, массивы, сложные вложенные объекты) то GET не подходит, применяют POST.
Здравствуйте! Не могу разобраться с RFC по http. Есть 2068 и 2616 (вроде бы актуальнее, но не нашёл на русском). Что Вы скажете о этих RFC? Спасибо