07:57 - не совсем понял: несколько HTTP соединений или TCP соединений? Если это не опечатка, то эти http соединения находятся в пределах одного tcp соединения, или каждое http соединение находится внутри своего tcp соединения?
Андрей, подскажите пожалуйста, не удается установить соединение через PuTTY. Нужно выбирать RAW, Telnet? У меня ошибка "Connection closed by remote host", либо "400 Bad Request". А может быть просто в 2016 году вы не использовали HTTPS, а теперь используете и больше такой вариант общения с сервером не работает?
Если кому интересно, вот статья в блоге nginx, рассказывающая о том, что нового в HTTP 2.0 и почему он далеко не всегда выгоднее HTTP 1.1: www.nginx.com/blog/http2-module-nginx/#features Warning: статья на английском.
Интересно как работает keep-alive в современном мире Single Page Applications. По сути сервер отдает практически пустую html-страницу пользователю при первоначальном заходе на сайт. Потом подгружается js-бандл, который тянет с сервера json-ы с данными и рендерит их в симпатичном лэйауте. И в процессе взаимодействия пользователя с сайтом просто гуляют туда-сюда json-ы, без перезагрузки страницы. Имеет ли смысл серверу SPA держать соединение 5-15 секунд, или выгоднее при каждом XmlHttpRequest открывать новое TCP-соединение?
Загрузка данных через XmlHTTPRequest все равно выполняется через HTTP. Выгодно или нет держать соединение открытым, определяется конкретным приложением, насколько часто данные в нем должны обновляться.
+Sergey Ufimtsev, да, может. Поддержка постоянного соединения не является обязательной. У сервера может не хватить ресурсов. Или администратор может напрямую запретить постоянное соединение. В этом случае сервер просто закрывает соединение сразу после передачи ответа.
Вы говорите, что сначала идет запрос на сервер для получения HTML документа, а после его загрузки происходит его анализ с целью поиска других связанных ресурсов для загрузки. То есть сначала загружаем документ, потом файлы стилей, картинки и скрипты. С файлами стилей и картинками все понятно, они действительно подгружаются после загрузки документа, чем создают некоторые проблемы для разработчиков среди которых перемещение контента из за поздно загрузившейся картинки, мигание шрифтов и прочее. Но файлы скриптов (JS) они ведь выполняются по мере загрузки страницы, то есть синхронно и основной поток будет ждать их загрузки. То есть они в отличии от остальных файлов по умолчанию синхронны и только используя специальные атрибуты можно задать иное поведение. Первый вопрос: интересно, а почему так? Второй вопрос: а как вообще так то?)) Браузер что, тормозит весь поток и даже текущую загрузку целевого документа, но отдает запрос на загрузку скрипта и его выполнения и только потом он все возобновляет? Что за важность такая у скриптов? Спасибо))
Не совсем понятна одна деталь. Когда браузер открывает несколько HTTP соединений, он в каждом соединении должен установить TCP соединение, или что-то не так я понимаю? Если не сложно ответьте подробнее.
А вы в лекции говорили, что каждое такое соединение может быть постоянным и использоваться для загрузки нескольких ресурсов, что противоречит данному ответу.
+Андрей Прощенко, это разные режимы работы. Первоначально для загрузки каждого элемента страницы нужно было отправлять отдельный запрос HTTP и в нем устанавливать соединение. Когда страницы стали сложными, такой подход перестал быть эффективным. Поэтому разработали новый подход с постоянным соединением TCP, через которое можно загружать несколько элементов страницы.
Это я понял, я просто запутался, а вы говорите за еще один вариант, как можно ускорить загрузку страницы - несколько HTTP соединений, и каждое из них исп. для загрузки разных ресурсов. Они могут исп. постоянное TCP соединение?ua-cam.com/video/7DitlqcesKI/v-deo.html
+Андрей Прощенко, да, каждое соединение HTTP может использовать постоянное соединение TCP. Но у каждого HTTP соединения будет свое TCP соединение. В HTTP версии 2 можно асинхронно запрашивать через одно соединение TCP несколько ресурсов. Это называется мультиплексирование.
5:50 А за зачем close писать если есть флаг fin? Просто в дальнейшем этот флаг нельзя отправить и закрыть соединение? Или после close соединение со стороны клиента считается закрытым? Как вообще происходит дело после connection: close ?
Флаг fin используется в TCP. А close - в протокол HTTP. После того, как в HTTP написать close, реализация HTTP создаст сегмент TCP для разрыва соединения (с установленным флагом FIN) и проследит, чтобы соединение разорвалось.
на примере python import socket sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM) sock.bind(('127.0.0.1', 8888)) sock.listen(5) while True: try: client, addr = sock.accept() except KeyboardInterrupt: sock.close() break else: result = client.recv(1024) client.close() # если бы мы тут не закрыли соединение с клиентом, то получилось бы, # якобы тут от http приходит, connection: keep alive заголовок и соединение постоянно слушается ? print("MSG:", result.decode('utf-8')) т.е когда клиент устанавливает TCP соединение с сервером, сервер не закрывает соединение с клиентом после получения сегмента и постоянно ждет новых?
08:09 Имелось ввиду несколько TCP соединений через которые пойдут запросы HTTP? Или же все-таки в старой версии HTTP не использовалось TCP и все отправлялось в запросах, что делает метод нескольких HTTP соединений немного улучшеной старой технологией?
Да, несколько соединений TCP. Что значит "все отправлялось в запросах"? HTTP - это протокол прикладного уровня для работы с Web. TCP - протокол транспортного уровня для передачи данных. HTTP никогда не был протоколом транспортного уровня и никогда не выполнял работу TCP, это два совершенно разных уровня.
Обалдеть. Такой курс бесплатный. Огромное вам спасибо.
Пожалуйста!
Спасибо большое за ваш труд!
+Ivan _, пожалуйста!
Может быть у Вас найдется время создать аналогичную лекцию с объяснением VPN соединений ?
Это лучший образовательный канал! Спасибо вам за труд!
Спасибо за приятный отзыв!
Спасибо.
Qilgan bu yaxshi amallariyezni ajrini bersin.
Пожалуйста!
Андрей, огромное спасибо за Вашу работу! Изучал по Вашим урокам компьютерные сети, прошёл собеседование!!!
Найкращий контент про мережі !!!
Спасибо!
07:57 - не совсем понял: несколько HTTP соединений или TCP соединений?
Если это не опечатка, то эти http соединения находятся в пределах одного tcp соединения, или каждое http соединение находится внутри своего tcp соединения?
Лучший и системный курс
Спасибо!
Андрей, спасибо вам большое!
Спасибо вам, Андрей!
Пожалуйста!
Spasibo Balshoe
vso ochen krasivo i poyatlivo
+atilla atilla, пожалуйста!
Андрей, подскажите пожалуйста, не удается установить соединение через PuTTY. Нужно выбирать RAW, Telnet? У меня ошибка "Connection closed by remote host", либо "400 Bad Request". А может быть просто в 2016 году вы не использовали HTTPS, а теперь используете и больше такой вариант общения с сервером не работает?
Спасибо, все лаконично и понятно!
Пожалуйста!
Андрей огромное спасибо !
Пожалуйста!
Сенькю за лекции
Ю ар велком!
Дякую за корисний контент :))))
Спасибо Вам большое!
Пожалуйста!
Подскажите пожалуйста, как разобраться с протоком WebSocket? Как-то мало информации системной об этом, показалось. Спасибо
Если кому интересно, вот статья в блоге nginx, рассказывающая о том, что нового в HTTP 2.0 и почему он далеко не всегда выгоднее HTTP 1.1: www.nginx.com/blog/http2-module-nginx/#features
Warning: статья на английском.
Интересно как работает keep-alive в современном мире Single Page Applications.
По сути сервер отдает практически пустую html-страницу пользователю при первоначальном заходе на сайт. Потом подгружается js-бандл, который тянет с сервера json-ы с данными и рендерит их в симпатичном лэйауте.
И в процессе взаимодействия пользователя с сайтом просто гуляют туда-сюда json-ы, без перезагрузки страницы.
Имеет ли смысл серверу SPA держать соединение 5-15 секунд, или выгоднее при каждом XmlHttpRequest открывать новое TCP-соединение?
Загрузка данных через XmlHTTPRequest все равно выполняется через HTTP. Выгодно или нет держать соединение открытым, определяется конкретным приложением, насколько часто данные в нем должны обновляться.
Здравствуйте, спасибо за урок! А сервер HTTP 1.1 может сам отказаться от поддержки постоянного соединения?
+Sergey Ufimtsev, да, может. Поддержка постоянного соединения не является обязательной. У сервера может не хватить ресурсов. Или администратор может напрямую запретить постоянное соединение.
В этом случае сервер просто закрывает соединение сразу после передачи ответа.
Вы говорите, что сначала идет запрос на сервер для получения HTML документа, а после его загрузки происходит его анализ с целью поиска других связанных ресурсов для загрузки. То есть сначала загружаем документ, потом файлы стилей, картинки и скрипты. С файлами стилей и картинками все понятно, они действительно подгружаются после загрузки документа, чем создают некоторые проблемы для разработчиков среди которых перемещение контента из за поздно загрузившейся картинки, мигание шрифтов и прочее. Но файлы скриптов (JS) они ведь выполняются по мере загрузки страницы, то есть синхронно и основной поток будет ждать их загрузки. То есть они в отличии от остальных файлов по умолчанию синхронны и только используя специальные атрибуты можно задать иное поведение.
Первый вопрос: интересно, а почему так?
Второй вопрос: а как вообще так то?)) Браузер что, тормозит весь поток и даже текущую загрузку целевого документа, но отдает запрос на загрузку скрипта и его выполнения и только потом он все возобновляет? Что за важность такая у скриптов?
Спасибо))
Строго говоря, в 1.0 есть возможность юзать keep-alive через расширение протокола :).
+dzen1234, да, это правильно.
Друг, спасибо
Пожалуйста!
спасибо!!!
Пожалуйста!
7:59 разве в HTTP/1 максимальное число одновременных соединений с одним источником не ограничено двумя?
Я не знаю такого ограничения в самом протоколе.
2:52 - оговорка, TCP-соединения
Не совсем понятна одна деталь. Когда браузер открывает несколько HTTP соединений, он в каждом соединении должен установить TCP соединение, или что-то не так я понимаю? Если не сложно ответьте подробнее.
Да, если не используется постоянное TCP-соединение.
А вы в лекции говорили, что каждое такое соединение может быть постоянным и использоваться для загрузки нескольких ресурсов, что противоречит данному ответу.
+Андрей Прощенко, это разные режимы работы. Первоначально для загрузки каждого элемента страницы нужно было отправлять отдельный запрос HTTP и в нем устанавливать соединение. Когда страницы стали сложными, такой подход перестал быть эффективным. Поэтому разработали новый подход с постоянным соединением TCP, через которое можно загружать несколько элементов страницы.
Это я понял, я просто запутался, а вы говорите за еще один вариант, как можно ускорить загрузку страницы - несколько HTTP соединений, и каждое из них исп. для загрузки разных ресурсов. Они могут исп. постоянное TCP соединение?ua-cam.com/video/7DitlqcesKI/v-deo.html
+Андрей Прощенко, да, каждое соединение HTTP может использовать постоянное соединение TCP. Но у каждого HTTP соединения будет свое TCP соединение.
В HTTP версии 2 можно асинхронно запрашивать через одно соединение TCP несколько ресурсов. Это называется мультиплексирование.
Спасибо, всё по делу
Пожалуйста!
Это и есть web socket?
Нет, web сокеты это отдельная технология. Вот видео про Web-сокеты - ua-cam.com/video/TxVriqBkqbM/v-deo.html
Спасибо!
5:50 А за зачем close писать если есть флаг fin? Просто в дальнейшем этот флаг нельзя отправить и закрыть соединение? Или после close соединение со стороны клиента считается закрытым? Как вообще происходит дело после connection: close ?
Флаг fin используется в TCP. А close - в протокол HTTP. После того, как в HTTP написать close, реализация HTTP создаст сегмент TCP для разрыва соединения (с установленным флагом FIN) и проследит, чтобы соединение разорвалось.
@@AndreySozykin спасибо, как-то всё запутанно, но логично ска)
на примере python
import socket
sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
sock.bind(('127.0.0.1', 8888))
sock.listen(5)
while True:
try:
client, addr = sock.accept()
except KeyboardInterrupt:
sock.close()
break
else:
result = client.recv(1024)
client.close() # если бы мы тут не закрыли соединение с клиентом, то получилось бы,
# якобы тут от http приходит, connection: keep alive заголовок и соединение постоянно слушается ?
print("MSG:", result.decode('utf-8'))
т.е когда клиент устанавливает TCP соединение с сервером, сервер не закрывает соединение с клиентом после получения сегмента и постоянно ждет новых?
Да, именно так.
08:09 Имелось ввиду несколько TCP соединений через которые пойдут запросы HTTP? Или же все-таки в старой версии HTTP не использовалось TCP и все отправлялось в запросах, что делает метод нескольких HTTP соединений немного улучшеной старой технологией?
Да, несколько соединений TCP.
Что значит "все отправлялось в запросах"? HTTP - это протокол прикладного уровня для работы с Web. TCP - протокол транспортного уровня для передачи данных. HTTP никогда не был протоколом транспортного уровня и никогда не выполнял работу TCP, это два совершенно разных уровня.
спасибо)
Лайк
Спасибо!
Спасибо
Пожалуйста!
Plus
Спасибо Вам Андрей!
Пожалуйста!
благодарю
Спасибо!
Спасибо
Пожалуйста!