Necesito una respuesta más técnica para una pregunta de entrevista sobre cómo funciona Internet de principio a fin [cerrado]


13

He tenido entrevistas con 5 personas separadas durante las últimas dos semanas y tres de esas cinco me han hecho esta pregunta: explique qué sucede entre presionar "Google.com" y la página que aparece en la pantalla. Básicamente, cómo funciona Internet. Después de tres veces me imagino que mejor estar preparado si alguna vez vuelvo a tener esta pregunta.

algunas cosas, pero no estoy completamente convencido de que mi respuesta sea lo suficientemente buena. Básicamente, menciono que el servidor DNS traduce "google.com" en una dirección IP. Paso un poco por encima de TCP / IP, luego hablo sobre el servidor web que literalmente sirve las páginas solicitadas que se envían de vuelta al navegador que el navegador interpreta y muestra.

Como dije antes, no estoy convencido de que mi respuesta sea lo suficientemente técnica. ¿Cuáles son los pasos que estoy dejando de lado?

Por lo que vale, dos de esas tres veces han estado con la misma compañía y me llaman para una tercera entrevista con ellos, por lo que no puedo haberlo bombardeado demasiado .


1
¿Cuál es la naturaleza de los puestos para los que estaba entrevistando?
smp7d

3
Si tres de cada cinco entrevistadores hicieron esta pregunta, es hora de que haga un estudio / investigación y obtenga una buena respuesta que demuestre que la comprende completamente. Si lo llaman para una tercera entrevista en la misma compañía y le vuelven a hacer la pregunta, demostrará que le importó lo suficiente como para reforzar su conocimiento, o no lo hizo.
Robert Harvey

1
Además, trataría de reducir el alcance de la pregunta preguntando en qué parte del proceso están más interesados. Puede que no les importe que usted sepa profundamente sobre cosas como las siete capas del modelo OSI , por ejemplo, pero usted aún debe tener un conocimiento práctico.
Robert Harvey

1
Por otro lado, tal vez la respuesta sea demasiado técnica. ¿Quizás están buscando ver cómo se puede relacionar la información con las personas de una manera no técnica?
Matt

1
Si se le pide a la pregunta que vea qué tan bien se comunica, entonces quizás sea bueno hacer preguntas sobre la pregunta en lugar de simplemente responder a una pregunta muy amplia. Puede dar una respuesta técnica muy detallada y tomarse todo el día para explicarla. No creo que ese sea el propósito de la pregunta.
Matt

Respuestas:


29
  1. Su navegador primero hace que el sistema operativo busque en su archivo "hosts" una entrada que traduzca el nombre de dominio a una dirección IP. Esta es una característica heredada heredada de ARPANET, cuando era posible que un solo archivo de texto contuviera nombres inteligibles para cada computadora accesible a través de ARPANET, y para que cada computadora conectada a él tuviera una copia relativamente reciente. Solía ​​tener algún valor restante en pequeñas redes de computadoras que no tenían NetBIOS o protocolos similares de nombres de nodos, pero hoy en día es probable que sea un objetivo para los piratas informáticos (que pueden usarlo para evitar DNS y apuntar su computadora a sitios ellos controlan) como tener un uso legítimo para una computadora cliente o su usuario / propietario.
  2. Suponiendo que su computadora no tiene una entrada HOSTS para este dominio, su navegador envía una solicitud UDP al servidor DNS configurado en la configuración de Internet del sistema operativo para la conexión que se está utilizando, pasando el "nombre de host", también conocido como nombre de dominio de la solicitud (todo entre "http: //" y la primera barra inclinada o de dos puntos después de lo que viene después, es decir, "www.google.com"). Este servidor DNS generalmente pertenece a su empresa o a su proveedor local de servicios de Internet.
    • UDP significa "Protocolo universal de datagramas" y es un protocolo de "capa de transporte" en la misma clase que TCP (arriba del protocolo IP de "capa de red", debajo de los protocolos de "capa de aplicación" como HTTP, FTP, SMTP, etc. ) Si bien TCP proporciona muchas capacidades de verificación de errores y tolerancia a fallas (agregando datos adicionales y aumentando así la sobrecarga), UDP adopta un enfoque mucho más liviano, aumentando el ancho de banda de datos netos; La desventaja es que el protocolo no admite funciones disponibles en TCP, como dividir datos grandes en múltiples paquetes (por lo que los mensajes deben ser pequeños) o reenviar paquetes perdidos en tránsito. Es bueno para mensajes pequeños y simples (como DNS) y transmisión de datos de tipo telemetría donde no importa si se pierde un paquete.
  3. Este servidor DNS sabrá una de tres cosas: cómo traducir ese nombre de dominio directamente a una dirección IP (lo que significa que es el "servidor de nombres autorizado" o ANS para ese dominio); la dirección IP del ANS o uno de sus padres; o su propio servidor de nombres principal que es más probable que sepa cómo llegar al ANS. Si el servidor no traduce la solicitud en sí, la reenviará "hacia abajo" hacia un ANS conocido o "hacia arriba" a su NS padre, y este proceso se repite de forma recursiva.
    • La "raíz" de esta estructura de árbol es un servidor único que no hace más que reenviar cualquier solicitud que reciba a uno de varios servidores de "dominio de nivel superior" o TLD. Hay, por ejemplo, un servidor de nombres ".com", que sabe cómo encontrar la dirección IP de cualquier dominio ".com" en el planeta (reenviando estas solicitudes a servidores de nombres de nivel ISP). Estos TLD reenvían solicitudes de servidores de nombres de dominio que ningún DNS conoce en una "sucursal" específica de Internet perteneciente a un ISP.
  4. Una vez que se encuentra el servidor de nombres autorizado y ha traducido el nombre de dominio a una dirección IP, esta dirección se devuelve al cliente y a su navegador. Si no se puede encontrar un ANS dentro del "tiempo de vida" de la solicitud (TTL; la cantidad máxima de veces que la solicitud debe reenviarse entre servidores, para evitar ciclos infinitos entre servidores mal configurados), el nodo devuelve un error al cliente en que la solicitud "agota" (o el nodo que es el servidor autorizado para el dominio pero que no puede traducir el prefijo de dominio particular).
  5. El navegador, para una conexión HTTP, envía una solicitud "TCP SYN" a la dirección IP y al puerto especificado (o al puerto HTTP predeterminado de 80) para establecer una conexión. Esta es una solicitud de nivel de protocolo, en capas sobre el encabezado IP de "nivel de red", que contiene información como el puerto de respuesta preferido del cliente (el "puerto de origen"), las preferencias para la comunicación TCP, como el tamaño del segmento, la escala de la ventana y el uso de funciones de protocolo opcionales.
  6. La solicitud se enruta al "nivel de enlace" (que rige cómo se manipulan los circuitos eléctricos reales para transmitir los datos contenidos en las capas de red, transporte y aplicación) a través de la estructura de Internet; típicamente los datos viajarán a través de un cable o fibra hasta la "Oficina Central" de su hogar o negocio (esto se llama la "última milla" y es típicamente el circuito que representa el mayor cuello de botella al ancho de banda) que es más o menos la "rampa de acceso" a la autopista de la información. Luego, el CO tiene acceso a tuberías de alto ancho de banda (T-carriers, SONET, etc.) que transmiten su solicitud, junto con miles de millones de otros, en todo el mundo al CO del destino, que lo reenvía al servidor o red de destino.
    • Este "enrutamiento IP" funciona de una manera conceptualmente similar a la resolución DNS; A los ISP de "nivel superior" se les asignan redes IP completas de "clase A" (todas las direcciones posibles reciben un primer byte conocido) por ICANN, y otros ISP saben quién posee esa red de Clase A y cómo llevar los datos al "frente" más cercano de esa red puerta ", utilizando información en una" tabla de enrutamiento ". Este ISP de nivel superior luego arrienda bloques de direcciones, algunos a ISP locales, otros directamente a usuarios corporativos, y estos ISP y corporaciones tienen enrutadores que usan la dirección IP (y sus propias tablas de enrutamiento) para determinar si deben enviar paquetes a otros circuitos cercanos, de lado a otros enrutadores ISP locales, o hasta troncales y enrutadores de nivel superior.
  7. El servidor recibe esta solicitud (siempre que no sea rechazada en una capa de abstracción inferior como el socket o un firewall), y si decide aceptar la conexión, enviará un paso de solicitud-respuesta "SYN-ACK", ambos reconocen el solicitar y especificar sus propias preferencias (incluidas las preferencias de los clientes que puede acomodar, pero cambiando las que no puede o que no se especificaron).
  8. Si el cliente admite la comunicación utilizando la opción establecida por el servidor, enviará una respuesta ACK y ahora la conexión está "establecida".
  9. El navegador luego envía una solicitud "HTTP GET". La solicitud incluye el URI completo del recurso solicitado por el navegador (aunque sabemos que estamos hablando con www.google.com, enviamos esa cadena como parte de la solicitud para que el servidor pueda, si lo desea, interpretar más el nombre de dominio para dirigir la solicitud). Esta solicitud puede incluir "cookies"; datos almacenados en el cliente que pueden entregarse al servidor para ayudar a procesar la solicitud de manera eficiente y conveniente (como identificar las preferencias del usuario).
  10. El servidor recibe la solicitud GET y primero decide si desea cumplirla (el servidor puede haber estado escuchando solicitudes al puerto TCP 80, pero esperando mensajes de un protocolo de aplicación diferente como FTP o VoIP; esto es raro para el puerto 80 pero más común para otros tipos de puertos). Asumiremos que sí lo acepta; el servidor luego devuelve una respuesta HTTP que contiene el recurso solicitado (en este caso, el HTML para la página predeterminada, que es la página de búsqueda omnipresente de Google). La respuesta también puede incluir "cookies", que el servidor le pide al cliente que almacene (el cliente puede o no hacerlo).
  11. El navegador digiere el HTML y lo representa para dibujar la página en la ventana del navegador. Mientras esto sucede, el cliente envía más solicitudes HTTP GET para Javascript, hojas de estilo, imágenes y otros datos que se necesitan para mostrar todo el contenido de la página de la manera prescrita por el HTML, y el cliente proporciona los datos resultantes. servidor.
  12. En una época pasada, Google se basaba en formas estáticas; escribiste lo que querías buscar en el cuadro de texto y presionaste "Buscar" (o "Me siento afortunado"). Cuando hace esto, el cliente envía una solicitud HTTP POST al servidor; la solicitud contiene la ubicación, especificada por el cliente, a la que se debe enviar la información y, por supuesto, la información misma. Esta información es digerida por el servidor, que la utiliza para buscar resultados de búsqueda, y el servidor construye una página de estos resultados que le envía. O bien, puede transformar los términos de búsqueda en una "cadena de consulta" y responder con una "redirección"; una solicitud para que el navegador envíe otra solicitud a un URI diferente especificado en el mensaje. El navegador lo hará, y luego el servidor construirá y transmitirá esa página.
  13. En los tiempos modernos, la página principal de Google es mucho más dinámica. A medida que escribe, JavaScript que se ejecuta en el lado del cliente dentro del navegador envía lo que está escribiendo a Google a lo largo de un "canal lateral" (utiliza los mismos protocolos para la comunicación, pero debido a que no es el navegador el que envía las solicitudes de páginas completas , la pantalla del navegador no se borra por completo y se vuelve a dibujar). Para la página principal, esto se utiliza para proporcionar sugerencias de consulta (sugerencias de autocompletar para cosas que podría estar buscando porque otras personas lo han hecho recientemente); en la página de resultados, hace lo mismo, pero también se puede usar para proporcionar resultados de búsqueda en tiempo real y volver a dibujar la página por completo, sin necesidad de que el navegador vuelva a cargar la página completa. Este tipo de trucos se incluyen en el encabezado general de AJAX (JavaScript asíncrono y XML,

Esta película , que es la que le mostraron a mi estudiante de primer año "Introducción a TI" en la universidad, tiene lo básico ilustrado en un formato amistoso y análogo. No es técnico de ninguna manera, pero proporciona una buena descripción conceptual de las piezas de este rompecabezas.


1
Esta es una buena respuesta, pero pasa por alto muchos detalles que la mayoría de la gente consideraría innecesarios. (No estoy diciendo que es necesario agregar estos detalles;. Sólo estoy señalando que hay mucho más en juego que no sea su posterior sugiere)
greyfade

1
Sí, debe ingresar a TCP vs UDP para buscar DNS. Si es TCP, debe entrar en el protocolo de enlace TCP de 3 vías. Probablemente sea seguro asumir que el sistema de alguna manera tiene servidores de nombres de dominio definidos (por DHCP o configuración de red de antemano) ...
Alan Shutko

1
@AlanShutko - Yo no mencionar el 3-way handshake; el SYN / SYN-ACK / ACK de ida y vuelta. No mencioné UDP, aunque es el protocolo principal para DNS.
KeithS

@KeithS, vaya, tienes razón, lo estaba buscando cuando comprobé el DNS, no más tarde. DNS podría recurrir a TCP si hay una respuesta mayor de 512 bytes y se trunca.
Alan Shutko

1
ANS - "Servidor de nombres autorizado", el servidor DNS que tiene conocimiento directo y la responsabilidad de los puntos finales de un nombre de dominio particular. ALD fue un error tipográfico. La publicación ha sido editada para ser más clara en ambos aspectos.
KeithS

1

Dejar de lado las menciones de cookies y firewalls sería un par de cosas que faltan aquí. Hay algo que decir sobre el envío de cookies para que "Google.com" pueda reconocer a un usuario y mostrar una página que puede ser diferente para alguien que no ha iniciado sesión en Google. También está la cuestión de dónde está buscando esto la persona: ¿teléfono inteligente, tableta o computadora normal (computadora portátil o de escritorio)?

Me pregunto si puede haber algunas preguntas secundarias que debías hacer pero no fue un factor aquí. Esta es más una cuestión de cómo funciona la Web, ya que Internet sería un poco más amplio e incluiría el correo electrónico y otras cosas que creo.


Supongo que fue más una prueba de sus capacidades de comunicación. ¿Puede tomar una pregunta bastante técnica y desglosarla para que lo entiendan técnicos y no técnicos? ¿Qué tipo de preguntas respondería si le pidieran que explicara a alguien que muestra la página de inicio "Google.com" en su navegador? ¿Haces un montón de suposiciones o haces las preguntas? De alguna manera, veo esto como un paralelo a una pregunta de pizarra en la que las cosas se dejan lo suficientemente vagas como para hacer preguntas para que pueda dar una respuesta correcta precisa o hacer suposiciones al dar una respuesta.


55
En mi opinión, una pregunta sobre Internet sería más sobre redes en general; ¿Cómo se encuentran las rutas? ¿Cuál es el propósito y el significado de un paquete y cómo transmiten información? ¿Cómo funciona la abstracción TCP sobre paquetes y por qué? Pero la pregunta es realmente vaga, tal vez se trate de HTTP, HTML o conmutadores de red, o ISP y backbones o cualquier otra cosa, tal vez quiera saber cómo se raspa el búfer de trama de su NIC y si el SO, la CPU o la NIC lo hacen ...
Jimmy Hoffa

@JimmyHoffa: De hecho, es una pregunta amplia. Los entrevistadores que lo preguntaron lo redactaron de tal manera que creo que el enfoque está en el lado de las cosas de la red, desde la solicitud de la página hasta la obtención de la página. Suceden muchas cosas y sospecho que serían felices sin importar la ruta que tomara, siempre que fuera lo suficientemente técnico y supiera de lo que estaba hablando.
Megacannon

1
También creo que buscan una respuesta no técnica para ver qué tan bien puedes comunicar ideas. A menudo perdemos el bosque por los árboles, no podemos ver el panorama general.
Matt

@ Jimmy Jimmy, buen punto. Probablemente debería comenzar con la dirección IP de sus servidores DNS y determinar si están en la misma subred a través de la máscara de red, y si es así, usar ARP para encontrarlos. De lo contrario, se envía un paquete a la puerta de enlace.
Alan Shutko
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.