Блог

У меня на сервере webpack dev запущено одностраничное приложение для горячей перезагрузки на моем локальном компьютере. Однако его серверное приложение не было на моем локальном сервере, оно было размещено на удаленном сервере, скажем http://remote-server.com.

Когда я использую такой адрес в поле адреса Chrome: 0.0.0.0:3000/homepage , http-запрос (вызовы api на удаленный серверный сервер) был в 5 раз (даже больше) медленнее, чем при использовании localhost:3000/homepage

Я действительно смущен, почему это произошло?

На самом деле, точнее, вопрос будет в том, что это значит для браузера / сервера, когда я прошу Chrome выполнить пинг 0.0.0.0, учитывая тот факт, что 0.0.0.0 просто используется для указания «привязки к любому возможному адресу»

HTTP-запросы похожи

 get /remote-server.com/api/v1/users
get /remote-server.com/api/v1/products
get /remote-server.com/api/v1/prices

  

Я ожидал, что http-запросы занимают столько же времени.. когда я использую 0.0.0.0 и localhost

что это значит для браузера / сервера, когда я прошу Chrome выполнить пинг 0.0.0.0, учитывая тот факт, что 0.0.0.0 просто используется для указания «привязки к любому возможному адресу»?

По спецификации RFC5735, 0.0.0.0 представляет только «исходные адреса», что означает, что это адрес, не подлежащий маршрутизации, и его нельзя использовать для назначения.

Однако, по практическим соображениям, многие клиентские ПРОГРАММЫ рассматривают 0.0.0.0 как localhost . В список такого программного обеспечения входят: Chrome, Firefox, Safari, curl, telnet и т.д. Поскольку многие веб-серверные ПРОГРАММЫ запускаются с сообщениями типа «прослушайте 0.0.0.0 …», разрешить посещение 0.0.0.0 очень удобно для начинающих разработчиков.

На самом деле, для Chrome такое поведение обсуждалось как проблема, вначале статус проблемы был «Wontfixed», но позже изменен на «Fixed» со следующим решением:

Разрешить явную навигацию по «0.0.0.0» для поддержки систем, где это выполняет навигацию по localhost (вопреки спецификациям… но, казалось бы, обычное дело).

Это по-прежнему предотвращает переход к любому другому IP с начальным октетом 0 и разрешает 0.0.0.0 только тогда, когда он фактически введен в виде 4-компонентного квадрата с точками.