Un navegador web es un ejemplo de un agente de usuario (UA). Otros tipos de agente de usuario incluyen el software de indexación utilizado por los proveedores de búsqueda (rastreadores web), navegadores de voz, aplicaciones móviles, y otro software que accede, consume o muestra contenido web.
HTTP está diseñado para permitir que los elementos de red intermedios mejoren o permitan las comunicaciones entre clientes y servidores. Los sitios web de alto tráfico a menudo se benefician de servidores de caché web que ofrecen contenido en nombre de los servidores normales para mejorar el tiempo de respuesta. Los navegadores Web Cache han accedido previamente los recursos web y los reutiliza cuando sea posible para reducir el tráfico de red. Los servidores proxy HTTP que se ubican en los límites de la red privada pueden facilitar la comunicación para los clientes sin una dirección globalmente enrutable, mediante mensajes con servidores externos.
HTTP es un protocolo de capa de aplicación diseñado en el marco de protocolos de Internet. Su definición presume un protocolo de capa de transporte subyacente y fiable, y el Protocolo de Control de Transmisión (TCP) se utiliza comúnmente. Sin embargo HTTP puede utilizar protocolos no fiables como el User Datagram Protocol (UDP), por ejemplo, en el Simple Service Discovery Protocol (SSDP).se identifican los recursos HTTP y situadas en la red por identificadores uniformes de recursos (URI) -OR, más específicamente, Localizadores Uniformes de Recursos (URL) -usando el HTTP o HTTPS esquemas URI. URI y los hipervínculos en Hypertext Markup Language (HTML) documentos forman redes de documentos
1,05 - Diferenciar entre versiones de HTTP Historia HTTP
La primera versión documentada de HTTP es HTTP
El HTTP WG había previsto publicar nuevos estándares en diciembre de 1995 y el soporte para HTTP pre-estándar 1.1 basado en el RFC 2068 para luego desarrollar (llamado HTTP-NG) que fue rápidamente adoptado por los principales desarrolladores de navegadores a principios de 1996. En marzo de 1996, HTTP pre-estándar 1.1 fue apoyado en Arena, Netscape 2.0, Netscape Navigator Gold 2.01, Mosaic 2.7, 2.5 Lynx, y en Internet Explorer 2.0. La adaptación del usuario final de los nuevos navegadores fue rápida. En marzo de 1996, una empresa de alojamiento web informó que más del 40% de los navegadores en uso en Internet eran compatibles con HTTP 1.1. Esa misma empresa de alojamiento web informó que en junio de 1996, el 65% de todos los navegadores que acceden a sus servidores estaban con HTTP 1.1. El HTTP 1.1 estándar como se define en el RFC 2068 fue lanzado oficialmente en enero de 1997. Se hicieron mejoras y cambios en la especificación HTTP 1.1 estándar hasta que fue dada de baja RFC 2616 en junio de 1999.
Algunos de los principales cambios de la versión 1.0 a la versión 1.1 se basaron en métodos de petición. HTTP define métodos (a veces conocido como verbos) para indicar la acción deseada para ser realizada en el recurso identificado. Lo que este recurso representa, si los datos o datos preexistentes que se generan de forma dinámica, dependen de la aplicación del servidor. A menudo, el recurso corresponde a un archivo o la salida de un archivo ejecutable que reside en el servidor. HTTP 1.0 define la GET, métodos POST y HEAD y el HTTP 1.1 añaden nuevos métodos: OPTIONS, PUT, DELETE, TRACE y CONNECT.
Estructura de las transacciones HTTP
Como la mayoría de los protocolos de red, HTTP utiliza el modelo cliente-servidor: un cliente HTTP abre una conexión y envía un mensaje de solicitud a un servidor HTTP; Después, el servidor devuelve un mensaje de respuesta y,por lo general, contiene el recurso que fue solicitado. Después de la entrega de la respuesta, el servidor cierra la conexión (haciendo de HTTP un protocolo sin estado, es decir, sin el mantenimiento de cualquier información de conexión entre las transacciones).
Los formatos de los mensajes de solicitud y respuesta son similares, y en inglés. Ambos tipos de mensajes consisten en:
Dicho de otra manera, el formato de un mensaje HTTP es:
Header1: valor1
Las líneas iniciales y encabezados deben terminar en CRLF, aunque debe manejar líneas que terminan en tan sólo LF. (Más exactamente, CR y LF aquí significa valores ASCII 13 y 10, a pesar de que algunas plataformas pueden utilizar diferentes caracteres.)
El camino es la parte de la URL después de que el nombre de host, también llamada la petición URI (URI es como una URL, pero más general).
La versión HTTP siempre toma la forma de “HTTP / xx”, en mayúsculas.
1xx indica sólo un mensaje informativo 2xx indica el éxito de algún tipo 3xx redirige al cliente a otra URL 4xx indica un error por parte del cliente 5xx indica un error por parte del servidor
200
OK
|
La solicitud tuvo éxito, y el recurso
resultante (por ejemplo, archivo o de salida del script) se devuelve en el
cuerpo del mensaje.
|
301
|
Movido permanentemente
|
302
|
Movido temporalmente
|
303
|
El recurso se ha movido a otra URL (dado
por la localización: cabecera de respuesta), y debe ser recuperado
automáticamente por el cliente. Esto es a menudo utilizado por un script CGI
para redirigir el navegador a un archivo existente
|
403
Forbidden
|
La solicitud fue una petición válida,
pero el servidor se niega a responder a ella
|
404
Not Found
|
El recurso solicitado no existe
|
500
Internal Server Error
|
error inesperado del servidor Una. La
causa más común es un script del lado del servidor que tiene mala sintaxis,
falla, o no puede funcionar
|
503
Service Unavailable
|
El servidor no está disponible (debido a
que está sobrecargado o apagado por mantenimiento). En general, este es un
estado temporal.
|
Las líneas de cabecera proporcionan información acerca de la petición o respuesta, o sobre el objeto enviado en el cuerpo del mensaje. Las líneas de cabecera están en el formato de texto de cabecera habitual, que es: una línea por cada cabecera, de la forma “HeaderName: valor”, terminando con CRLF. Es el mismo formato utilizado para correo electrónico y publicacion de noticias.
Determinar un método de solicitud HTTP para un caso de uso dado
Además GET, los dos métodos más utilizados son HEAD y POST.
El método HEAD
Una petición HEAD es igual que una petición GET, excepto que pide al servidor devolver sólo las cabeceras de respuesta, y no el recurso real (es decir, sin el cuerpo del mensaje). Esto es útil para comprobar las características de un recurso sin tener que descargarlo, lo que se ahorra ancho de banda. Use HEAD cuando en realidad no necesite contenido de un archivo.
La respuesta a una solicitud HEAD nunca debe contener un cuerpo de mensaje, sólo la línea de estado y cabeceras.
El método POST
Una solicitud POST se utiliza para enviar los datos al servidor para ser procesados de alguna manera, como por un script CGI. Una solicitud POST es diferente de una petición GET de las siguientes manera:
• Hay un bloque de datos enviados con la solicitud, en el cuerpo del mensaje. Hay por lo general cabeceras adicionales para describir este cuerpo del mensaje, como Content-Type: y Content-Lengt.
• El URI de la solicitud no es un recurso para recuperar; por lo general es un programa para manejar los datos que está enviando.
• La respuesta HTTP es normalmente la salida del programa, no un archivo estático.
El uso más común de POST, por el momento, es enviar datos de formulario HTML a scripts CGI. En este caso, la cabecera de Content-Type: es generalmente application / x-www-form-urlencoded, y la de Content-Length: cabecera da la longitud de los datos del formulario con codificación URL (aquí es una nota en URL-codificación). La secuencia de comandos CGI recibe el cuerpo del mensaje a través de STDIN, y lo decodifica. He aquí una presentación forma típica, usando POST:
POST /path/script.cgi HTTP / 1.0
From: frog@jmarshall.com
User-Agent: HTTPTool / 1.0
Content-Type: application / x-www-form-urlencoded
Content-Length: 32
home=Cosby&favorite+flavor=flies
Se puede utilizar una solicitud POST para enviar todos los datos que desea, no sólo formar presentaciones. Sólo asegúrese de que el emisor y el programa receptor están de acuerdo en el formato.
El método GET también se puede utilizar para enviar formularios. Los forma de los datos es de URL Codificada y adjunta a la solicitud URI.
Explicar el propósito y la funcionalidad de HTTP abiertas, las cabeceras HTTP, DNS, SIP, FTP
HTTP Keep-Alives
El mantenimiento de conexiones HTTP, también llamada conexión HTTP persistente o reutilización de la conexión HTTP, es la idea de utilizar una única conexión TCP para enviar y recibir múltiples peticiones/respuestas de HTTP , en lugar de abrir una nueva conexión para cada par petición / respuesta única.
El campo de encabezado Keep-Alive y la información adicional que proporciona son opcionales y no necesitan estar presentes para indicar que se ha establecido una conexión persistente.
 |
| Múltiples respuestas, un único "apretón de manos" |
Cabeceras HTTP
Los campos de cabecera HTTP son componentes de la sección de encabezado de solicitud y respuesta de mensajes en el Protocolo de transferencia de hipertexto (HTTP). Definen los parámetros de funcionamiento de una transacción HTTP.
Los campos de cabecera se transmiten después de la línea de petición o respuesta, la cual es la primera línea de un mensaje. Los campos de cabecera son pares nombre-valor separados por dos puntos en formato de cadena de texto claro, terminada por un retorno de carro (CR) y la secuencia de carácter de avance de línea (LF). El final de la sección de encabezado se indica mediante un campo vacío, lo que resulta en la transmisión de dos pares CR-LF consecutivos. Históricamente, las largas colas se podían doblar en varias líneas; líneas de continuación se indican por la presencia de un espacio (SP) o pestaña horizontal (HT) como el primer carácter en la línea siguiente. Este plegado está ahora obsoleto.
Sistema de nombres de dominio (DNS)
Si alguna vez has usado Internet, es una buena apuesta decir que usted ha utilizado el sistema de nombres de dominio o DNS, incluso sin darse cuenta. DNS es un protocolo dentro de un conjunto de protocolos para definir cómo las computadoras intercambian de datos en Internet y en muchas redes privadas, conocidos como el conjunto de protocolos TCP / IP. Su función básica es la de convertir un nombre de dominio fácil de usar como “howstuffworks.com” en un protocolo de Internet (IP) como 70.42.251.42 que utilizan los ordenadores para identificar entre sí en la red. Es como el GPS de su ordenador para Internet.
Los ordenadores y otros dispositivos de red de Internet utilizan una dirección IP para encaminar su solicitud para el sitio que está tratando de alcanzar. Esto es similar a marcar un número de teléfono para conectarse a la persona que está intentando llamar. Gracias al DNS, sin embargo, usted no tiene que mantener su propia agenda de direcciones IP. En su lugar, sólo tiene que conectar a través de un servidor de nombres de dominio, también llamado un servidor DNS o servidor de nombres, que gestiona una base de datos masiva que asigna nombres de dominio a direcciones IP.
Ya sea accediendo a un sitio web o el enviando un correo electrónico, el equipo utiliza un servidor DNS para buscar el nombre de dominio que intenta acceder. El término apropiado para este proceso es resolución de nombres DNS, y diría que el servidor DNS resuelve el nombre de dominio a la dirección IP. Por ejemplo, cuando se introduce “http://www.howstuffworks.com” en su navegador, que forma parte de la conexión de red incluye la resolución del nombre de dominio “howstuffworks.com” en una dirección IP, como 70.42.251.42.
Siempre se puede pasar por alto una búsqueda de DNS mediante la introducción de 70.42.251.42 directamente en su navegador (probarlo). Sin embargo, es probable que sea más fácil recordar “howstuffworks.com” cuando se quiere volver más tarde. Además, la dirección IP de un sitio web puede cambiar con el tiempo, y algunos sitios asociar varias direcciones IP con un nombre de dominio único.
Sin servidores DNS, Internet cerraría muy rápidamente. Pero, ¿cómo el equipo sabe qué servidor DNS a utilizar? Por lo general, cuando se conecta a la red doméstica, el proveedor de servicios de Internet (ISP) o una red Wi-Fi, el módem o router que asigna direcciones de red de su ordenador también envía información de configuración de red importante para su ordenador o dispositivo móvil.
Esa configuración incluye uno o más servidores DNS que el dispositivo debe utilizar cuando la traducción de nombres DNS a la dirección IP.
Protocolo de Iniciación de Sesión (SIP)
Protocolo de Iniciación de Sesión (SIP) es un protocolo de comunicaciones utilizado para la comunicación entre diferentes dispositivos en una red de la empresa, ya sea en la LAN, WAN, o a través de Internet. Un ejemplo de esto podría ser un simple conversación telefónica de dos vías, usando voz sobre IP (VoIP) en la LAN o WAN o una troncal SIP a través de Internet a un proveedor de servicios. Un troncal SIP proporciona una nueva manera de conectar a un proveedor de servicios para las llamadas entrantes y salientes; es una conexión a través de Internet en lugar de una conexión telefónica tradicional, como RDSI.
SIP le permite aprovechar al máximo las aplicaciones como videoconferencia, presencia y mensajería instantánea. Estas aplicaciones, y otras como ellas, cuando trabajan en conjunto se conocen como las comunicaciones unificadas. Las comunicaciones unificadas se abre un nuevo mundo de posibilidades en la forma de interactuar con sus clientes actuales y potenciales, dándoles una experiencia más rica cuando se trata de usted y su personal.
SIP proporciona a las empresas muchas ventajas sobre las soluciones anteriores de telefonía, y lo mejor de todo, se puede ahorrar dinero.
En el pasado, las conexiones con el proveedor de servicios (compañía telefónica) sólo eran posibles mediante una línea telefónica dedicada, como una conexión RDSI.
Protocolo de transferencia de archivos (FTP)
Protocolo de transferencia de archivos (FTP) es un protocolo de red estándar que se utiliza para transferir archivos desde un host a otro host a través de una red basada en TCP, tales como Internet. FTP se basa en la arquitectura cliente-servidor y utiliza por separado conexiones de control y de datos entre el cliente y el servidor. Los usuarios de FTP pueden autenticarse usando un protocolo de inicio de sesión en texto claro, normalmente en forma de un nombre de usuario y contraseña, pero pueden conectarse de forma anónima si el servidor está configurado para permitirlo. Para la transmisión segura encripta el nombre de usuario y contraseña, y cifra el contenido, FTP es a menudo asegurada con SSL / TLS ( “FTPS”). El protocolo ( “SFTP”) SSH File Transfer a veces también se utiliza en su lugar, pero es tecnológicamente diferente.
Las primeras aplicaciones de cliente FTP eran las aplicaciones de línea de comandos desarrollados antes de que los sistemas operativos tuvieran interfaces gráficas de usuario, y que todavía se envían con la mayoría de los sistemas operativos Windows, UNIX y Linux. Decenas de clientes FTP y utilidades de automatización ya se han desarrollado para equipos de sobremesa, servidores, dispositivos móviles y hardware, y FTP se ha incorporado en cientos de aplicaciones de productividad, tales como editores de páginas Web.
Diferenciar entre FTP pasivo y activo
Una de las preguntas que más se ve cuando se trata de servidores de seguridad y otros problemas de conectividad a Internet es la diferencia entre FTP activa y pasiva. Con suerte el texto siguiente le ayudará a aclarar algunas de la confusión sobre cómo es el soporte de FTP en un entorno de servidor de seguridad.
Lo básico
FTP es un servicio basado en TCP exclusivamente. No hay ningún componente UDP a FTP. FTP es un servicio inusual, ya que utiliza dos puertos, un puerto '' de datos y un puerto 'comando' (también conocido como el puerto de control). Tradicionalmente estos son el puerto 21 para el puerto de comando y el puerto 20 para el puerto de datos. La confusión comienza sin embargo, cuando nos encontramos con que en función del modo, el puerto de datos no es siempre en el puerto 20.
FTP activo
En el modo activo FTP, el cliente se conecta a un puerto aleatorio sin privilegios (N > 1023) al puerto de comandos del servidor FTP, el puerto 21. A continuación, el cliente empieza a escuchar al puerto de N + 1 y envía el comando FTP PORT N + 1 al servidor FTP. El servidor se conectará de nuevo al puerto de datos especificado por el cliente desde su puerto de datos local, que es el puerto 20.
Desde el punto de vista del cortafuegos del lado del servidor, para soportar FTP modo activo los siguientes canales de comunicación necesitan ser abiertos:
• El puerto de servidor FTP 21 desde cualquier lugar (cliente inicia la conexión)
• El puerto de servidor FTP 21 a los puertos "> 1023" (servidor responde al puerto de control de cliente)
• El puerto de servidor FTP 20 a los puertos "> 1023" (servidor inicia la conexión de datos al puerto de datos del cliente)
• El puerto de servidor FTP 20 de los puertos "> 1023" (El cliente envía ACK al puerto de datos del servidor)
Cuando se dibuja a cabo, la conexión aparece como sigue:
• El comando de puerto del cliente contacta con el puerto de comandos del servidor y envía el comando PORT 1027.
• Después, el servidor envía un ACK al puerto de comandos del cliente
• El servidor inicia una conexión en su puerto de datos locales al puerto de datos del cliente especificado anteriormente.
• Por último, el cliente envía un ACK.
El principal problema con FTP modo activo en realidad cae en el lado del cliente. El cliente FTP no hace la conexión real al puerto de datos del servidor - simplemente le dice al servidor qué puerto está escuchando en el servidor y se conecta de nuevo al puerto especificado en el cliente. Desde el cortafuegos del lado del cliente esto parece ser un sistema externo de iniciar una conexión a un cliente interno - algo que por lo general está bloqueado.
FTP pasivo
Con el fin de resolver el problema del servidor que inicia la conexión con el cliente se desarrolló un método diferente para las conexiones FTP. Esto se conoce como modo pasivo, o PASV, después del comando que utiliza el cliente para indicar al servidor que está en modo pasivo.
En el modo pasivo de FTP el cliente inicia ambas conexiones con el servidor, y es la solución del problema de cortafuegos de filtrado de la conexión del puerto de datos entrante al cliente desde el servidor. Al abrir una conexión FTP, el cliente abre dos puertos no privilegiados al azar a nivel local (> 1023 y N + 1). El primer puerto contacta con el servidor en el puerto 21, pero en vez de emitir un comando PORT y permitir que el servidor se conecte de nuevo a su puerto de datos, el cliente se ejecuta el comando PASV. El resultado de esto es que el servidor a continuación, abre un puerto aleatorio sin privilegios (P > 1,023) y envía P de vuelta al cliente en respuesta al comando PASV. El cliente entonces inicia la conexión desde el puerto N + 1 al puerto P en el servidor para transferir datos.
Desde el punto de vista de seguridad, para el soporte de FTP en modo pasivo los siguientes canales de comunicación necesitan ser abiertos:
• El puerto de servidor FTP 21 desde cualquier lugar (cliente inicia la conexión) •
• El puerto de servidor FTP 21 a los puertos > 1023 (el servidor responde al puerto de control de cliente) •
• Los puertos del servidor FTP > 1023 desde cualquier parte (cliente inicia una conexión de datos a puerto aleatorio especificado por el servidor
• Los puertos del servidor FTP > 1023 a los puertos remotos > 1023 (Server envía ACK (y datos) al puerto de datos del cliente)
Cuando se dibuja, una conexión FTP en modo pasivo sería algo así:
• El cliente contacta con el servidor en el puerto de comandos y emite el comando PASV. • • Después, el servidor responde con el puerto 2024, para decirle al cliente qué puerto está escuchando para la conexión de datos.
• Luego, el cliente inicia la conexión de datos desde su puerto de datos al puerto de datos del servidor especificado.
• Por último, el servidor envía un ACK al puerto de datos del cliente.
Mientras que el modo pasivo de FTP resuelve muchos de los problemas desde el lado del cliente, se abre toda una serie de problemas en el lado del servidor. El mayor problema es la necesidad de permitir que cualquier conexión remota a los puertos numerados en el servidor. Afortunadamente, muchos demonios FTP, incluyendo el popular WU-FTPD permiten al administrador especificar un rango de puertos, que utilizará el servidor FTP.
El segundo problema consiste en dar soporte y solucionar de problemas de los clientes. A modo de ejemplo, la utilidad de línea de comandos FTP proporcionada con Solaris no soporta el modo pasivo, lo que exige un cliente FTP de terceros, tales como ncftp.
Explicar el propósito y la funcionalidad de SMTP
El servidor SMTP
Siempre que envíe un pedazo de correo electrónico, el cliente de correo electrónico interactúa con el servidor SMTP para que administre el envío. El servidor SMTP de su servidor puede tener conversaciones con otros servidores SMTP para entregar el correo electrónico. Supongamos que quiero enviar un correo electrónico. Tengo mi cuenta en HowStuffWorks. com. Quiero enviar un correo electrónico a jsmith@mindspring.com. Estoy utilizando un cliente de correo electrónico independiente como Outlook Express.
Cuando creé mi cuenta en HowStuffWorks, le dije a Outlook Express el nombre del servidor de correo - electrónico. howstuffworks.com. Cuando compongo un mensaje y pulse el botón Enviar, esto es lo que sucede:
• •
•
•
• Outlook Express se conecta al servidor SMTP en mail.howstuffworks.com utilizando el puerto 25.
• Outlook Express tiene una conversación con el servidor SMTP, diciendo al servidor SMTP la dirección del remitente y la dirección del destinatario, así como el cuerpo del mensaje.
• El servidor SMTP toma la dirección “a” (jsmith@mindspring.com) y la divide en dos partes: el nombre del destinatario (jsmith) y el nombre de dominio (mindspring.com). Si la dirección “Para” había sido otro usuario en howstuffworks.com, el servidor SMTP simplemente entregar el mensaje al servidor POP3 para howstuffworks.com (usando un pequeño programa llamado el agente de entrega). Puesto que el receptor está en otro dominio, SMTP necesita comunicarse con ese dominio.
• El servidor SMTP tiene una conversación con un servidor de nombres de dominio o DNS. Dice: “¿Me puede dar la dirección IP del servidor SMTP para mindspring.com?” El DNS responde con la una o más direcciones IP para el servidor (s) SMTP que Mindspring opera.
• El servidor SMTP en howstuffworks.com conecta con el servidor SMTP en Mindspring usando el puerto 25. Tiene la misma conversación de texto simple que el cliente de correo electrónico tuvo con el servidor SMTP para HowStuffWorks, y da el mensaje al servidor Mindspring. El servidor Mindspring reconoce que el nombre de dominio para jpérez está en Mindspring, por lo que le pasa el mensaje al servidor POP3 de Mindspring, que pone el mensaje en el buzón de jsmith.
Si, por alguna razón, el servidor SMTP en HowStuffWorks no puede conectar con el servidor SMTP en Mindspring, entonces el mensaje entra en una cola. El servidor SMTP en la mayoría de máquinas utiliza un programa llamado sendmail para hacer el envío, por lo que esta cola se llama la cola de sendmail. Sendmail tratará periódicamente para volver a enviar los mensajes en su cola. Por ejemplo, podría volver a intentar cada 15 minutos. Después de cuatro horas, por lo general le enviará un correo que le indica que hay algún tipo de problema. Después de cinco días, la mayoría de las configuraciones de sendmail se dan por vencidas y devuleven el correo como no entregado.
El servidor SMTP entiende comandos de texto muy simples como HELO, MAIL, RCPT y DATA. Los comandos más comunes son:
• HELO - preséntese
• EHLO - presentarse y solicitar el modo extendido
• MAIL FROM: - especificar el remitente
• RCPT TO: - especificar el destinatario
• DATOS - especificar el cuerpo del mensaje (A, De y Asunto debe ser las tres primeras líneas).
• RSET - reset
• QUIT - salir de la sesión
• AYUDA - obtener ayuda sobre los comandos
• VRFY - verificar una dirección
• EXPN - expandir una dirección
• VERBO - verbose
Explicar el propósito y la funcionalidad de una cookie
¿Cómo funcionan las cookies en HTTP?
Una cookie es un fragmento de texto que un servidor web puede guardar en el disco duro de un usuario. Las cookies permiten que un sitio Web almacene información en el equipo del usuario y posteriormente recuperarla. Las piezas de información se almacenan como pares nombre-valor.
Por ejemplo, un sitio Web puede generar un número de identificación único para cada visitante y almacenar el número de identificación en la máquina de cada usuario mediante un archivo de cookies.
Si utiliza Internet Explorer de Microsoft para navegar por la web, se pueden ver todos las cookies que se almacenan en su máquina. El lugar más común para ellos residen en un directorio llamado c: / windowscookies. Cuando miro en ese directorio en mi máquina, encuentro 165 archivos. Cada archivo es un archivo de texto que contiene los pares nombre-valor, y hay un archivo para cada sitio web que ha colocado las cookies en mi máquina.
Se puede ver en el directorio que cada uno de estos archivos es un archivo de texto simple, normal. Se puede ver qué sitio Web coloca el archivo en su máquina mirando el nombre del archivo (la información también se almacena dentro del archivo). Puede abrir cada archivo haciendo clic en él.
Por ejemplo, he visitado goto.com, y el sitio ha colocado una cookie en mi máquina. El archivo de cookies para goto.com contiene la siguiente información:
www.goto.com/ ID de usuario A9A3BECE0563982D
Goto.com ha almacenado en mi máquina de un solo par nombre-valor. El nombre de la pareja es ID de usuario, y el valor es A9A3BECE0563982D. La primera vez que visité goto.com, el sitio me asignó un valor de identificación único y se almacena en mi máquina.
(Tenga en cuenta que probablemente hay otros valores almacenados en el archivo aparte de los tres que se muestran arriba. Esa es la limpieza de información para el navegador.)
La gran mayoría de los sitios almacenan sólo un poco de información de un usuario ID-en su máquina. Sin embargo, un sitio puede almacenar muchos pares de nombre y valor si se quiere.
Un par nombre-valor son simplemente datos nombrados. No es un programa, y no se puede “hacer” nada. Un sitio web puede recuperar sólo la información que se ha colocado en su máquina. No se puede recuperar la información de los archivos cookie, o cualquier otra información de su máquina.
¿Cómo utilizan los sitios web las cookies?
Las cookies evolucionaron porque resuelven un gran problema para las personas que gestionan los sitios Web. En el sentido más amplio, una cookie permite que un sitio almacene información de estado de la máquina. Esta información permite a un sitio Web recordar en qué estado se encuentra en su navegador. Un ID es una simple archivo de información de estado -. Si existe una identificación de su máquina, el sitio sabe que usted ha visitado antes. El Estado es, “Su navegador ha visitado el sitio al menos una vez”, y el sitio conoce su ID de esa visita.
Los sitios web utilizan cookies en muchas maneras diferentes. Éstos son algunos de los ejemplos más comunes:
Los sitios pueden determinar con precisión cuántas personas realmente visitan el sitio. Resulta que a causa de los servidores proxy, el almacenamiento en caché, concentradores y así sucesivamente, la única manera para que un sitio pueda contar con precisión los visitantes es establecer una cookie con un identificador único para cada visitante. El uso de las cookies, los sitios pueden determinar cuántos visitantes llegan, cuántos son nuevos en comparación con visitantes de la repetición y con qué frecuencia ha visitado a un visitante. Los sitios pueden almacenar las preferencias del usuario para que el sitio pueda ser diferente para cada visitante (a menudo referido como la personalización). Por ejemplo, si visita msn.com, le ofrece la posibilidad de “cambiar el contenido / diseño / color”. También le permite introducir su código postal y obtener información sobre el tiempo a medida. Al introducir su código postal, el siguiente par nombre-valor se agrega al archivo de cookies de MSN:
WEAT CC = NC% 5FRaleigh% 2DDurham ® ION = www.msn.com/
• Desde que vivo en Raleigh, Carolina del Norte, esto tiene sentido.
• La mayoría de los sitios parecen almacenar las preferencias de este tipo en el sitio de la base de datos y almacenar nada más que una identificación como una cookie, pero el almacenamiento de los valores reales en pares nombre-valor es otra manera de hacerlo.
Los sitios de comercio electrónico pueden implementar cosas como carritos de la compra y opciones de pago y envío “rápido”. La cookie contiene un identificador y permite que el sitio no pierda la vista a medida que agrega cosas diferentes a su carrito. Cada elemento que se agrega a su carro de la compra se almacena en la base de datos del sitio junto con su valor de ID.
A la salida, el sitio sabe lo que está en su carrito recuperando todas sus selecciones de la base de datos. Sería imposible poner en práctica un mecanismo de compra cómoda y sin cookies o algo parecido.
En todos estos ejemplos, tenga en cuenta que lo que la base de datos es capaz de almacenar son elementos que ha seleccionado desde el sitio, las páginas que ha visitado desde el sitio, la información que le han dado al lugar de formularios en línea, etc. Toda la información es almacenada en la base de datos del sitio, y en la mayoría de los casos, una cookie que contiene su identificador único es todo lo que se almacena en el ordenador.
Dada una situación en la que un cliente se conecta a un host remoto, a explicar cómo se produce el proceso de resolución de nombres
Proceso de resolución de nombres
Si un usuario quiere conectarse a una aplicación o sitio web en una red, ya sea pública o privada, debensaber a dónde ir para llegar a la aplicación. Como hemos discutido en secciones anteriores, todas las ubicaciones en una red tiene una dirección IP que se puede conectar a la aplicación o servicio que reside. El reto es recordar todas las direcciones IP de los sitios o aplicaciones que necesitan conectarse a una base del día a día. Es más fácil para un ser humano para recordar un nombre de una dirección IP. Por ejemplo, es más fácil de recordar que www.google.com 74.125.229.178. Sin embargo, para utilizar un nombre en lugar de una dirección IP significa un registro de los nombres que se correlacionan con la dirección IP que ha de ser mantenido y ser puesto a disposición de buscar por todos los nodos conectados a la red. El sistema de nombres de dominio (DNS) es un sistema de nombres distribuido jerárquico utilizado para esta función.
En el proceso de resolución de nombres DNS, para un cliente para conectarse a un host remoto, un buen número de pasos que se llevan a cabo. Vamos a pasar por esos pasos en un nivel alto.
Un usuario quiere llegar a la página web www.google.com. Así que él / ella abre un navegador y tipos www.google.com en la barra de ruta en el navegador. El sistema de los usuarios no sabe inherentemente la dirección IP de la página web. Así que hace una búsqueda de DNS del nombre y el proceso es básicamente lo siguiente:
• El sistema del usuario buscará en su archivo de host local una entrada coincidente para www.google.com. Si coincide con una entrada, utilizará esa dirección IP, y el proceso termina aquí.
• Si no se encuentra una entrada en el archivo de host local, el sistema del usuario buscará en su caché una entrada coincidente para www.google.com. Si una entrada existe entonces se intentará conectar a esa dirección, y el proceso termina aquí.
• Si no hay ningún registro en la memoria caché del sistema del usuario, entonces el sistema solicitará la dirección IP de su servidor DNS local para www.google.com.
• Si el servidor DNS local tiene una entrada para www.google.com en su caché, entonces responderá al sistema del usuario con esa dirección IP. El sistema pondrá a la entrada en su caché y se conectará a la dirección. El proceso es entonces completa.
• Si el servidor DNS local no tiene una entrada para www.google.com en su caché, entonces el servidor DNS local hará una llamada a los servidores raíz en su configuración de DNS para la dirección IP del servidor de nombres autorizada para el dominio .com . El servidor DNS local entonces consultar el nombre servidor autorizado del dominio .com para el Servidor Autorizador de nombres del dominio .google.com. Una vez que el servidor DNS local tiene esa dirección IP, se consulta al Servidor Autorizador de nombres del dominio .google.com para el registro A (dirección IP) del www.google.com.
• El servidor DNS local colocará esa respuesta en su caché y luego es capaz de responder al sistema del usuario con esa dirección IP. El sistema de usuario pondrá la entrada en su caché y se conectará a la dirección. El proceso es entonces completa.
Todos estos pasos se llevarán a cabo muy rápido y sólo tarda milisegundos.
Explicar el propósito y la funcionalidad de una URL
URL - Uniform Resource Locator
Un localizador uniforme de recursos (URL) es una referencia a un recurso que especifica la ubicación del recurso en una red informática y un mecanismo para la recuperación de la misma. Un URL es un tipo específico de identificador uniforme de recursos (URI), aunque muchas personas utilizan los dos términos indistintamente. Una URL implica los medios para acceder a un recurso indicado, lo cual no es cierto en todos los URI. URL se presentan más comúnmente en las páginas web de referencia (HTTP), pero también se utilizan para la transferencia de archivos (FTP), correo electrónico (mailto), acceso a base de datos (JDBC), y muchas otras aplicaciones.
La mayoría de los navegadores web muestran la dirección URL de una página web sobre la página en una barra de direcciones. Cada URL HTTP consta de los siguientes, en el orden dado. Varios esquemas distintos de HTTP también comparten este formato general, con alguna variación.
La sintaxis es la siguiente:
scheme://[user:password@]domain:port/path?query_string#fragment_id
Detalles de los componentes:
•
•
•
• El esquema, que en muchos casos es el nombre de un protocolo (pero no siempre), define cómo se obtuvo el recurso. Los ejemplos incluyen HTTP, HTTPS, FTP, archivos y muchos otros. Aunque los esquemas son sensibles a mayúsculas, la forma canónica es minúscula.
• El nombre de dominio o la dirección IP numérica literal da la ubicación de destino de la URL. Una dirección IPv6 literal numérica se puede dar, pero debe estar entre []. p.ej [ db8: 0cec :: 99: 123a].
• El dominio google.com, o su dirección IP numérica 173.194.34.5, es la dirección del sitio web de Google.
• No influye si se escribe con mayúsculas o minúsculas en la parte del nombre de dominio de un URL:
http://en.example.org/ y HTTP://EN.EXAMPLE.ORG/ tanto abrir la misma página.
• El número de puerto, dado en decimal, es opcional; Si se omite, se utiliza el valor por defecto para el esquema.Por ejemplo, http://vnc.example.com:5800 se conecta al puerto 5800 de vnc.example.com, que puede ser apropiado para una sesión de control remoto VNC. Si se omite el número de puerto para una http: URL, el navegador se conecta en el puerto 80, el puerto HTTP predeterminado. El puerto predeterminado para una página https: solicitud es 443.
• La ruta se utiliza para especificar y tal vez encontrar el recurso. Este camino puede que no describan las carpetas del sistema de archivos en el servidor web. Puede ser muy diferente de la disposición de las carpetas en el servidor web. Es mayúsculas y minúsculas, a pesar de que se puede tratar como sensible a las mayúsculas por algunos servidores, especialmente los basados en Microsoft Windows.
• Si el servidor es sensible a mayúsculas y http://en.example.org/wiki/URL es correcta, entonces http://en.example.org/WIKI/URL o http://en.example.org/wiki/url se mostrará una página de error HTTP 404, a menos que estas URL apunten a recursos válidos sí mismos.
• La cadena de consulta contiene datos que se pasarán al software que se ejecuta en el servidor. Puede contener pares nombre / valor separadas por símbolos de unión, por ejemplo ? FIRST_NAME = John Doe y apellidos =.
• El identificador de fragmento, si está presente, especifica una parte o una posición dentro del recurso global o documento.
Cuando se utiliza con HTML, se suele especificar una sección o ubicación dentro de la página, y se utiliza en combinación con elementos de anclaje o el atributo “id” de un elemento, el navegador se desplaza para mostrar esa parte de la página.
El nombre de esquema define el espacio de nombres, el propósito y la sintaxis de la parte restante de la URL. El software intentará procesar una URL de acuerdo a su esquema y contexto. Por ejemplo, un navegador web por lo general eliminar la referencia de la URL http://example.org:80 mediante la realización de una solicitud HTTP a la anfitrión example.org, utilizando el número de puerto 80.
Hay otros sistemas que no siguen el patrón de HTTP. Por ejemplo, el esquema mailto sólo utiliza direcciones de correo electrónico válidas. Cuando se hace clic en en una aplicación, la dirección URL mailto: bob@example.com puede iniciar un compositor e-mail con la dirección bob@example.com en el campo.
No hay comentarios:
Publicar un comentario