Hola, tenemos la respuesta a lo que andabas buscando, deslízate y la verás a continuación.
Solución:
El navegador no busca un archivo. Es solo pedir un recurso. Luego, el servidor decide qué devuelve ese recurso.
En su nivel más básico, ese “archivo” es literalmente solo un archivo. En el caso de la página de índice predeterminada de un directorio, la forma en que se configura el servidor determinará qué archivos se devuelven. Algunos servidores están configurados por defecto para regresar index.html si el archivo existe, vuelva a index.htm, etc. Otros predeterminados default.html, etc. Seguirán intentándolo hasta que se agote la lista de archivos predeterminados y luego devolverán un error 404.
En el caso de que la reescritura del servidor esté activada o se estén construyendo páginas dinámicas, el contenido que se devuelve normalmente no es un archivo. Se parece a un archivo, ya que la salida es (normalmente) HTML como un .html el archivo contendría. Pero detrás de escena, decenas o cientos de archivos crean ese contenido.
Tus navegadores no se cargan alguna archivo peticiones a recurso que luego proporciona el servidor a su discreción (elaboración extensa a continuación).
Si escribe google.com en la barra de herramientas de su navegador, el navegador primero agregará un protocolo, ya sea http:// o https. Luego, el navegador buscará la dirección IP que pertenece a google.com, cual es 172.217.19.206. A continuación, su navegador establecerá un socket con ese servidor en el puerto adecuado (80 para http, 443 para https).
Su navegador enviará la siguiente solicitud al servidor:
GET / HTTP/1.1
Host: google.com
El servidor web decidirá qué hacer. Esto puede implicar muchos pasos.
Un servidor web generalmente tiene algo llamado Raiz del documento para cualquier dominio que sirva. Archivos que el servidor web puede servir al usuario generalmente residir dentro de esto Raiz del documento. Por ejemplo, la raíz del documento para google.com podría residir en /var/www/domains/google.com/htdocs/.
Ahora, cuando solicita un recurso, el servidor web primero inspecciona el recurso y luego toma las medidas adecuadas. Por ejemplo, si el recurso termina con .php, el servidor web puede decidir no servir nada por sí mismo, sino que invoca al intérprete de PHP y deja que el intérprete de PHP ejecute el archivo PHP adecuado para el recurso solicitado, y luego entrega al usuario la salida.
Tomemos, por ejemplo, esta solicitud:
GET /article.php?id=123456 HTTP/1.1
Host: news.example.org
En este caso, el servidor web en news.example.org tiene la tarea de servir el recurso /article.php?id=123456. Lo que probablemente suceda es que este servidor web iniciará el intérprete de PHP. buscar el article.php archivo de la raíz del documento, introdúzcalo en el intérprete de PHP y espere la salida. Luego enviará la salida bck al navegador que la solicitó. En este caso, es probable que se trate de un sitio de un blog con cierto contenido cargado desde una base de datos (el contenido del artículo almacenado con la identificación 12345).
Pero también pueden pasar otras cosas.
Volvamos al ejemplo original:
GET / HTTP/1.1
Host: google.com
Lo que sucede con cualquier servidor web estándar (Apache, Lighttpd, etc.) es más o menos lo siguiente:
- Busque un archivo llamado
index.html(en la raíz del documento) y sírvelo - Si eso no existe, busque un archivo
index.htmy sírvelo - Si eso no existe, busque un archivo
index.phpe inicie el intérprete de PHP, sirva la salida - Si eso no existe, sirva un
404 NOT FOUNDerror
La prioridad de la extensión generalmente se puede configurar en el lado del servidor web. Es posible que el servidor no sirva index.xxx archivo en absoluto. Por ejemplo, si tiene un node.js servidor en ejecución, entonces el servidor web node.js servidor para proporcionar el recurso /, que podría ser cualquier cosa que la aplicación JS que se está ejecutando en el nodo decida que sea.
tl: dr; El navegador no busca un archivo. El navegador peticiones a recurso, el servidor web luego maneja la solicitud y entrega el contenido apropiado para el recurso solicitado, que podría ser un archivo, pero también puede ser el resultado de un programa de terceros.
En cuanto a la velocidad, depende del servidor web. Pero si desea que su servidor web siempre sirva al asjkdjhfz9874jykdfndsk.html archivar cuando / se solicita, normalmente configuraría el servidor web para buscar dicho archivo primero, haciéndolo tan rápido como cualquier otra configuración.
Descargo de responsabilidad Esta no es una descripción completa de cómo funciona un servidor web, ni está diseñado específicamente para uno. La mayoría de los servidores web funcionan de manera similar, pero especialmente los sitios como google.com probablemente ejecutará algunas cosas personalizadas que se adapten específicamente a sus necesidades.
Su navegador generalmente ofrecerá herramientas para inspeccionar la actividad de la red. Con Chrome, puede abrir las “Herramientas de desarrollo” e inspeccionar los encabezados. esto es lo que mi navegador envía a SE para permitirme editar esta respuesta:
GET /posts/93567/edit HTTP/1.1
Host: webmasters.stackexchange.com
Hay algunos más que le dicen al servidor sobre el almacenamiento en caché, qué idioma estoy esperando, qué navegador estoy usando y de dónde vengo, pero esos no son interesantes aquí. El caso es que mi navegador solicita el recurso/posts/93567/edit. Mi navegador nunca tendrá alguna idea sobre qué archivo sirve el servidor web. SE se ejecuta en ASP.NET MVC 5, lo que significa que el servidor web (en el caso de SE, un IIS) probablemente cargará algunos .asp archivo (que se puede ubicar en cualquier lugar), y permite que el tiempo de ejecución lo evalúe para el parámetro postId=93567. El archivo real o el funcionamiento interno son Nunca expuestos al navegador, porque el navegador no necesita saberlo (y porque es más seguro ocultar esa información para el que ejecuta el servidor).
La vista también le mostrará cualquier otro recurso (archivos CSS, archivos JS, imágenes, etc.) que su navegador solicite para representar correctamente el sitio. Pero con ellos, solo aprenderás sobre recurso, no si esos son o no Realmente archivos en el sistema de archivos.
Me pregunto cómo sé qué archivo se está procesando. Eventualmente puedo adivinarlo con precisión en una línea de tiempo lo suficientemente larga simplemente llamando explícitamente a ese nombre de archivo en la URL. www.xyz.com/index.html ¿no carga nada? Luego intente www.xyz.com/index.htm y así sucesivamente hasta que consiga que el sitio se renderice. Solo estoy buscando un atajo para saber qué archivo ha cargado mi navegador.
Estoy de acuerdo con John aquí en que lo que está solicitando al especificar una URL es un recurso (o para una mejor palabra, un objeto) del servidor.
Nunca sabrá al 100% con certeza qué archivo de disco real se lee cuando se solicita una URL. Esto es especialmente true si el servidor requiere que un programa de terceros se asocie con él para producir una salida.
Un programa típico de terceros es el intérprete de PHP, que es algo que utiliza Wordpress para entregar contenido. El intérprete puede procesar código que puede implicar la carga de cualquier número de archivos desde el disco del servidor para construir los datos HTML que luego se envían al navegador del usuario.
Además de eso, se puede aplicar una configuración especial al servidor para asignar URL especiales a los recursos. Esto (en un entorno apache) se conoce como reescritura de URL, y esto es muy bueno ya que es el comienzo de la creación de URL amigables.
Los usuarios no sabrán los nombres exactos de los archivos cargados ni les importará (a menos que sean piratas informáticos) porque lo único que les importa es el contenido real de la página.
También es posible que algunos administradores de servidor decidan no usar nombres de archivo reales en las URL por razones de seguridad.
Al final de todo puedes encontrar las observaciones de otros desarrolladores, tú igualmente tienes el poder mostrar el tuyo si dominas el tema.