Começando com HTTP

1. Boas-vindas a este curso!: Olá pessoal e bem-vindos a este curso no protocolo HTTP. Meu nome é Alex e sou engenheiro de software que vem escrevendo código usado neste protocolo nos últimos três anos. Quando ouvi falar da possibilidade de criar um curso para explicar como isso funciona, eu estava bastante ansioso para desenvolver um. Esta aula será estruturada em dez lições que contêm etapas práticas para você tomar para entender o que é o protocolo HTTP e como você pode aproveitar esse conhecimento com codificação. Um ritmo próprio da onda T, mostrarei como você pode ver todos os pedidos feitos de e para sua máquina, mas não antes. Vou explicar o que nossos métodos HTTP retornam códigos manipulados de outras coisas. Se você estiver interessado em como a Internet funciona, considere este curso para você. Não há outros requisitos, em seguida, uma conexão com a Internet para o projeto desta classe, será extremamente prático e envolverá você a seguir as etapas apresentadas no curso. Assim, você pode começar sua jornada de escrever código com um enorme bloco de conhecimento sob seu cinto. Esse é o protocolo HTTP. Pensamos no conjunto, acho que raramente o vemos na primeira lição. 2. Códigos de status HTTP: Olá pessoal, e bem-vindos de volta ao discurso. Nesta palestra, vamos dar uma olhada nos códigos de status HTTP, também chamados de códigos de retorno Essa é uma parte fundamental da comunicação na web. A razão pela qual esses códigos de dados são tão importantes é porque eles são emitidos por um servidor em resposta à solicitação de um cliente feita a esse servidor específico e são as informações mais relevantes e curtas sobre o andamento da solicitação. O primeiro dígito do código de status especifica uma das cinco classes padrão de respostas As frases de mensagem mostradas são típicas, mas qualquer alternativa legível por humanos pode ser fornecida Como eu estava dizendo, os códigos de retorno HTTP têm três dígitos. Se esses três dígitos começarem com um, o status que você está recebendo é informativo, o que significa que a solicitação foi Se começar com dois, significa que a solicitação foi uma operação bem-sucedida, ou seja, foi recebida, compreendida e aceita com sucesso . Com três, isso significa que um redirecionamento, como em outras ações, precisa ser realizado para concluir a solicitação Se começar com quatro, significa que sua solicitação teve um erro do cliente. Algo deu errado no lado do cliente e a solicitação contém uma sintaxe incorreta ou simplesmente não pode ser atendida Por fim, se seu código de três dígitos começar com o dígito cinco, isso significa que sua solicitação teve um Algo deu errado no lado do servidor, por exemplo, o servidor pode não atender a uma solicitação aparentemente válida. Agora, vamos examinar as diferentes categorias de respostas e listar alguns exemplos para cada uma delas. Para respostas informativas, temos o código 100 com a palavra-chave continue Isso significa que o servidor recebeu os cabeçalhos da solicitação e o cliente deve continuar enviando o corpo da solicitação Esse código é usado em situações em que o servidor precisa confirmar que está disposto a aceitar a solicitação. Por exemplo, um usuário pode enviar um arquivo grande para ser carregado em um serviço de compartilhamento de arquivos. Pense em transferir, o servidor responde com 100 contínuos para indicar que está pronto para receber esse arquivo grande e o usuário pode prosseguir com o upload real em respostas informativas Também temos 11 com as palavras-chave de protocolos de comutação. O servidor está indicando aqui uma mudança no protocolo, como a mudança de HTTP para um soquete web O cliente deve seguir esse novo protocolo para comunicação posterior. Para a próxima categoria, temos respostas bem-sucedidas, e aqui temos um código muito conhecido, que é 200, seguido pela palavra-chave ok. Esse é o código de sucesso mais comum, indicando que a solicitação foi bem-sucedida, o servidor atendeu à solicitação e a resposta contém os dados ou informações solicitados. Por exemplo, pense em um usuário acessando uma postagem de blog e o servidor responde com um código de status de 2000 K entregando o conteúdo do blog solicitado com sucesso Também temos 21, o que significa criado. Esse código de status indica que a solicitação resultou na criação de um novo recurso. Geralmente é usado com solicitações de postagem ou venda. Você pode pensar em um usuário que envia um formulário de registro em um site e o servidor responde com 21 criados, esperançosamente para indicar que uma nova conta de usuário foi Além disso, nas mensagens de sucesso, temos 24 sem conteúdo enquanto o servidor processou a solicitação com sucesso. Nesse caso, ele não tem corpo de resposta para enviar de volta ao cliente. Isso geralmente é usado para solicitações de exclusão. Se um usuário excluir um comentário em uma plataforma de mídia social e o servidor responder com 24 sem conteúdo, ele confirma a remoção sem retornar nenhum dado redundante adicional Passando para as mensagens de redirecionamento, temos 31 com as palavras-chave movidas permanentemente O recurso solicitado foi movido permanentemente para um novo URL. O cliente deve atualizar seus favoritos ou links adequadamente Você pode pensar em um site de comércio eletrônico que muda sua estrutura de URL e o usuário tenta acessar um site antigo. Página do produto. O servidor responde com 31 movidos, redirecionando permanentemente o usuário para a nova URL do Também temos aqui o código de 34 não modificado. Esse status é usado para indicar que a versão em cache do recurso do cliente ainda é válida e não há necessidade de baixá-la novamente. Se um usuário acessa um site dos EUA frequentemente visitado, o servidor, reconhecendo que o cache do navegador do usuário está atualizado, responde com esses três ou quatro não modificados, indicando que a versão em cache ainda é válida e que nenhum dado novo Para respostas de erro do cliente, temos 400, o que é uma solicitação incorreta. O servidor não conseguiu entender a solicitação aqui devido à sintaxe inválida, falta de parâmetros ou talvez a outros problemas no site do cliente Pense em um usuário que envia uma consulta de pesquisa com parâmetros inválidos em um site de reservas de viagens e o servidor responde com 400 solicitações incorretas, e o servidor responde com indicando que a solicitação Além disso, temos 41 para pessoas não autorizadas. A solicitação requer autenticação do usuário. O cliente que envia essa solicitação deve fornecer credenciais válidas, por exemplo, um nome de usuário e senha ou um token Tudo isso para acessar o recurso. Por exemplo, se um usuário tentar acessar um documento particular em um serviço de armazenamento em nuvem sem a autenticação adequada, o servidor naturalmente responderá com 41 solicitações não autorizadas, solicitando o usuário forneça credenciais de registro válidas antes receber toda a resposta Por fim, temos 43 proibidos. O servidor entendeu a solicitação , mas se recusa a atendê-la. A solicitação do cliente é válida, mas o servidor decidiu não servir o recurso. Se um usuário tentar acessar uma seção exclusiva para administradores de um aplicativo web e o servidor responder com 43 proibidos, isso indica que o usuário não tem as permissões necessárias para essa ação Você pode ver que 41 não autorizados são recebidos quando você não fornece nenhuma credencial e 43 proibidos são recebidos quando você fornece credenciais, mas eles não têm as permissões necessárias Também temos 44 não encontrados aqui. O recurso solicitado não foi encontrado no servidor. Isso indica que o URL é inválido ou que o recurso não existe mais Se um usuário clicar em um link quebrado que levou a uma página de produto excluída em um site de comércio eletrônico, o servidor responderá com 44 não encontrado, a fim de notificar o usuário de que o recurso solicitado não existe mais Para respostas de erro do servidor, temos 500, que significa Erro interno do servidor. Essa é uma mensagem de erro genérica e indica que uma condição inesperada impediu o servidor de atender à solicitação É uma pegadinha para erros do lado do servidor. Pense aqui em um usuário que tenta enviar um pedido em uma loja virtual, mas devido a um problema inesperado no servidor, essa solicitação resulta em um erro interno 500 do servidor. O usuário é aconselhado a tentar novamente mais tarde. Além disso, temos 52 para gateway inválido. Esse código de status indica que um servidor atuando como gateway ou proxy recebeu uma resposta inválida de um servidor upstream, geralmente indica problemas de rede Você pode pensar em um usuário que acessa um servidor web ou uma API que atua como gateway ou outro serviço O servidor gateway encontra um problema ao encaminhar a solicitação para o servidor upstream, resultando em uma resposta de gateway de 52 leitos Obviamente, há muito mais códigos de retorno do que os que eu enumerei, mas caso você encontre um que não esteja mencionado aqui, você pode pesquisar no Google e entenderá exatamente o que aconteceu com Quando se trata da distinção entre métodos HTTP seguros e não seguros, isso não está diretamente relacionado ao código de status HTTP Métodos seguros, como pegar e entregar, são projetados para não ter um impacto significativo nos recursos. Eles geralmente estão associados a respostas bem-sucedidas ou informativas Embora métodos inseguros, como colocar ou publicar, possam ter uma variedade de respostas dependendo da situação específica, incluindo sucesso, erros do cliente e do servidor Como conclusão desta lição, códigos de retorno HTTP são essenciais para entender os resultados das solicitações HTTP. Eles fornecem informações sobre o sucesso, o redirecionamento, erros do cliente e até mesmo os erros do servidor associados a uma determinada solicitação Esses códigos são uma parte fundamental do desenvolvimento e solução de problemas da Web, ajudando desenvolvedores como você e usuários a diagnosticar problemas e interpretar os resultados de suas interações com os serviços da suas interações com Com tudo isso dito, agradeço a vocês por permanecerem comigo até o final desta palestra e espero ver vocês na próxima 3. Métodos de solicitação HTTP: Olá pessoal, e bem-vindos de volta a este curso. Nesta palestra, examinaremos um conceito muito importante: os métodos HTTP Eles geralmente são chamados de verbos HTVP e são a base da comunicação entre clientes e servidores na web mundial Eles definem as ações que um cliente pode solicitar de um servidor, desde a recuperação de dados até a modificação Nesta lição, exploraremos os vários métodos HTTP, seus exemplos práticos e seu papel na comunicação na web, bem como sua classificação como segura ou insegura e o principal conceito fundamental da potência do item Para começar, vamos primeiro entrar na sigla C RD. Ela representa as quatro operações fundamentais para gerenciar dados em um banco de dados ou sistema de armazenamento de dados. É comumente usado no contexto de bancos de dados e desenvolvimento de software da API para descrever as ações básicas que podem ser executadas nos dados. Cada letra na sigla corresponde a uma operação específica para criar A operação de criação envolve a adição de novos dados, registros ou recursos a um banco de dados ou armazenamento de dados. É a ação de inserir uma nova informação ou uma nova entidade No contexto de uma API, isso normalmente significa enviar uma solicitação para criar um novo recurso. A letra R é para leitura. Essa operação envolve recuperar ou acessar dados de um banco de dados ou armazenamento de dados Essa operação não modifica os dados. É tudo uma questão de buscar e visualizar as informações existentes nas APIs Isso geralmente corresponde ao envio de uma solicitação para recuperar dados de um recurso U significa atualização. Isso envolve a modificação de dados existentes em um banco de dados. É a ação de fazer alterações em um registro existente, como atualizá-lo, atributos ou conteúdo. Em uma API, a atualização normalmente exige o envio de uma solicitação para modificar um recurso. D significa exclusão, e essa operação é a ação de remover dados, registros ou recursos de um banco de dados ou armazenamento de dados Isso resulta na remoção permanente das informações especificadas no contexto das APIs. Isso corresponde ao envio de uma solicitação para remover um recurso. As operações CRUD são fundamentais no gerenciamento e manipulação de dados Eles servem como base para criar e interagir com bancos de dados, serviços da web e aplicativos para realizar essas tarefas essenciais Ao projetar APIs ou trabalhar com bancos de dados, as operações CRUD são um conceito crucial para desenvolvedores como você, pois fornecem uma maneira padronizada de gerenciar dados com eficiência e precisão Falamos primeiro sobre as operações CRUD pois elas se entrelaçavam com os verbos HTTP de post, from create, get from read, put from update e delete, como veremos Vamos voltar agora aos métodos HTTP. Primeiro, temos o Get It usado para recuperar os dados de um recurso que provavelmente é identificado por um parâmetro de ID ou uma lista geral que contém todos os elementos desse recurso Algumas observações sobre as solicitações get indicam que elas podem ser armazenadas em cache e marcadas como favoritos Eles permanecem no histórico do navegador e nunca devem ser usados ao lidar com dados confidenciais. Além disso, eles têm algumas restrições em relação ao comprimento, como eu disse ao defini-los. Eles são usados apenas para recuperar dados e não modificá-los em nenhuma forma ou formato Imagine que você está usando um navegador para acessar um site de notícias on-line. Quando você clica em um artigo de notícias, seu navegador envia uma solicitação get ao servidor do site solicitando o conteúdo do artigo. O servidor responde enviando de volta o artigo solicitado, permitindo que você, o cliente, o leia Em seguida, temos uma postagem. Esse método HTTP cria um novo recurso e o envia para ser processado pelo servidor. Não é seguro e pode ter efeitos colaterais no servidor ou no recurso. Algumas observações quando se trata de métodos de postagem são que, diferentemente dos métodos get, eles não podem ser armazenados em cache, marcados como favoritos ou mesmo no histórico do navegador E também não têm restrições quanto ao comprimento. Além disso, o botão Voltar, se pressionado na solicitação de postagem, reenviará os dados Ao contrário de uma solicitação Get, em que não causará danos a um cenário da vida real. Imagine que você está usando um aplicativo de mídia social e decide criar uma nova postagem. Quando você clica no botão de publicação real, o aplicativo envia uma solicitação de postagem ao servidor, incluindo o texto e qualquer mídia anexada. O servidor processa sua solicitação, salva a postagem e fica visível para seus seguidores. Em seguida, colocamos o método HTTP. Isso atualiza um recurso especificado, o que significa que ele substitui todas as representações atuais do recurso de destino pela carga útil da solicitação A principal diferença quando se trata dos métodos de postagem e venda são os resultados obtidos ao repeti-los repetidamente. Embora o método put sempre produza o mesmo resultado ao atualizar um recurso repetidamente, o método post terá efeitos colaterais se tentar inserir duas vezes a mesma entidade em um sistema. Imagine que você tem um blog pessoal e percebe um erro de digitação em um de seus artigos publicados Você usa um sistema de gerenciamento de conteúdo e faz correções no conteúdo dos artigos Quando você salva as alterações, o CMS envia uma solicitação put para atualizar o artigo no servidor, garantindo que a versão corrigida seja exibida agora Em seguida, excluímos. Esse método solicita a remoção de um recurso na URL especificada. Ele deve excluir o recurso, se ele existir. Digamos que você tenha um aplicativo de e-mail aberto, como o e-mail, e queira bagunçar sua caixa de entrada removendo um e-mail desatualizado. Quando você seleciona esse e-mail específico e clica em excluir, o aplicativo envia uma solicitação excluída para o servidor de e mail, que remove o e-mail da sua caixa de entrada No que diz respeito ao patch do método HTTP, ele é usado para aplicar modificações parciais em um recurso. Geralmente é usado quando você deseja atualizar somente um subconjunto dos dados dos recursos Imagine que você está usando um aplicativo de gerenciamento de tarefas para acompanhar seu trabalho. Você percebe que a data de vencimento ou uma tarefa foi alterada, então você abre o aplicativo e atualiza somente a data de vencimento sem alterar nenhum outro detalhe da tarefa O aplicativo enviará uma solicitação de patch ao servidor que modifica somente a data de vencimento da tarefa Em seguida, temos a cabeça. Head é semelhante a Get, mas solicita apenas os cabeçalhos do recurso Sem os dados reais, ele é usado para verificar os recursos criados nos dados ou existência sem transferir todo o conteúdo real Isso poderia ser usado, por exemplo, se você estivesse navegando um site de compras e quisesse comprar um produto dele. Antes de ver os detalhes do produto, você clica no botão Verificar disponibilidade. O site envia uma solicitação antecipada ao servidor solicitando dados formatados, como disponibilidade do produto, preço e informações de estoque, sem carregar a página inteira do produto e todos os detalhes correspondentes Por fim, temos o método HTTP de opções. Esse método recupera informações sobre as opções de comunicação disponíveis para um recurso Ele permite que um cliente descubra quais métodos HTTP são suportados pelo servidor. Se você está criando um aplicativo da Web e precisa determinar quais ações são suportadas por um serviço da Web , esse método HTTP é crucial para você. O aplicativo envia uma solicitação de opções ao serviço perguntando quais métodos estão disponíveis para recursos específicos. Isso ajuda seu aplicativo a se adaptar aos recursos dos serviços e saber que tipo de solicitação ele pode enviar a ele. Esses eram todos os métodos HTTP, mas há mais conceitos-chave a serem entendidos aqui. A seguir, vamos ver como podemos classificar um método HTTP. Quando se trata desses verbos HTTP, eles podem ser amplamente categorizados Em primeiro lugar, métodos seguros são aqueles métodos HTTP projetados para não ter impacto significativo nos recursos que visam. Em outras palavras, quando um método seguro é usado, ele não deve causar alterações ou efeitos colaterais no servidor ou no próprio recurso. Os métodos HTTP a seguir são considerados seguros, mas não devem alterar o estado do recurso ou do servidor. É exclusivamente para recuperação de dados. Além disso, ele recupera metadados sem transferir todo o conteúdo, tornando-o novamente seguro Também temos métodos HTTP inseguros. Esses, por outro lado, são métodos HTTP que podem potencialmente levar a mudanças no estado do recurso ou do servidor. Eles não são seguros no sentido de que podem ter efeitos colaterais, como criação, modificação ou exclusão de recursos Os métodos HTTP a seguir são considerados inseguros. Publicá-lo não é considerado seguro porque geralmente leva à criação de um novo recurso ou à modificação de um existente. Coloque-o diretamente, modifica ou cria recursos e, portanto, não é um método seguro Excluir, isso leva à remoção do recurso especificado, tornando-o inerentemente inseguro Por fim, o patch, embora seja mais direcionado do que post ou put, ele ainda pode alterar os dados dos recursos, tornando-o um método inseguro Vamos agora entrar no termo muito importante de idempotência no contexto dos métodos HTTP. A idempotência se refere à propriedade de uma operação em que realizar a mesma ação várias vezes tem o mesmo efeito que executar mesma ação várias vezes tem o mesmo efeito tem o Isso significa que, se você enviar uma solicitação idempotente várias vezes, o estado do sistema e o recurso com o qual ele interage devem permanecer inalterados Vamos dar uma olhada em alguns exemplos de métodos HTTP idempotentes. O método get é idempotente quando você recupera informações com Fazer a mesma solicitação repetidamente não deve alterar o estado do servidor ou do recurso que você está buscando O método de venda também é potente. Se você usar put para atualizar um recurso com determinados dados, enviar a mesma solicitação put várias vezes resultará no recurso contendo os mesmos dados todas as vezes. Por fim, excluímos aqui. É um método idempotente porque se você solicitar a exclusão de um recurso usando delete, enviar a solicitação repetidamente não mudará o fato de que o recurso Em contraste com os métodos idempotentes, os métodos não idempotentes têm resultados diferentes quando repetidos não idempotentes têm resultados diferentes quando repetidos. Por exemplo, o método post não é idempotente e solicitações repetidas de publicação para criar um recurso podem levar à criação de vários Cada solicitação resulta na adição de um novo recurso. Normalmente, a solicitação de patch também não é potente para o item. repetição de uma solicitação de patch pode atualizar um recurso diferente a cada vez se as alterações forem incrementais ou dependerem do estado atual do Vamos ver agora por que a potência do item é importante. Em primeiro lugar, métodos potentes de itens contribuem para a resiliência do sistema Em cenários em que ocorrem problemas de rede, tempos limite ou falhas de comunicação, as operações potentes do item podem ser repetidas com segurança sem causar efeitos colaterais indesejados A potência do item também está intimamente relacionada ao armazenamento em cache. Quando uma resposta a uma solicitação potente de um item é armazenada em cache, solicitações subsequentes podem ser atendidas a partir do cache, reduzindo a carga no servidor e melhorando o Métodos potentes de itens garantem um comportamento previsível. Desenvolvedores e usuários podem confiar no fato de que a repetição de uma solicitação não resultará em resultados diferentes ou mudanças inesperadas no estado do sistema Por fim, a potência do item simplifica o tratamento de erros. Quando uma solicitação falha ou é interrompida, tentar novamente não gera inconsistência ou Em geral, ao projetar APIs, é essencial escolher os métodos HTTP apropriados para diferentes operações e documentar comportamento potente de seus itens Isso ajuda clientes e desenvolvedores como você entender como as solicitações devem ser tratadas e o que esperar quando interagem com a API Com tudo isso dito, eu realmente espero que alguns dos conceitos apresentados nesta palestra ajudem você no futuro E estou ansioso para ver você nas próximas palestras. 4. Depurando solicitações HTTP: Olá pessoal e bem-vindos de volta a este curso HTTP. Nesta palestra, discutiremos a solução de problemas e a depuração Porque, na minha opinião, pelo menos como desenvolvedor, é muito importante entender como solucionar problemas e depurar solicitações HTTP Essa habilidade é essencial para garantir que os aplicativos da Web funcionem sem problemas, diagnosticando e corrigindo problemas e oferecendo uma experiência de usuário perfeita As solicitações HTTP estão no centro de cada interação na web, seja carregando uma página da web, enviando um formulário, obtendo dados de uma API ou até mesmo transmitindo conteúdo multimídia Tudo começa com uma solicitação HTTP. No entanto, essas solicitações nem sempre estão isentas de erros. Vários fatores podem levar a problemas , como configurações incorretas do servidor, problemas de rede, bugs no site do cliente ou conflito entre componentes diferentes E é exatamente aqui que entra esta palestra para ajudá-lo a entender primeiro que os problemas comuns que podem surgir em solicitações HTTP são a primeira solução de problemas ineficaz Aqui temos coisas como erros de servidor, porque os servidores podem encontrar vários erros, como 44, que é o código para não encontrado, 500 para erro interno do servidor ou 53, que é serviço indisponível Esses erros podem resultar de servidores mal configurados ou problemas com aplicativos Também temos erros do lado do cliente. Clientes como navegadores da Web também podem gerar esses erros, como 400 por solicitação inválida ou 43 por solicitação proibida. Isso geralmente ocorre devido a problemas com a solicitação ou as permissões do cliente. Problemas de rede são outro fator que pode interromper a comunicação entre o cliente e o servidor Isso inclui problemas como DNS, falhas de resolução, conexões lentas ou até mesmo interrupções completas na rede Violações de compartilhamento de recursos de origem cruzada também podem bloquear solicitações para um domínio diferente. Se não for configurado corretamente, isso pode causar problemas de segurança e funcionalidade. Por fim, temos erros de SSL e TLS. Essas duas camadas de segurança podem causar erros. Eles podem ocorrer quando as conexões HTTP não são estabelecidas adequadamente. Esses erros podem interromper a transferência segura de dados. Agora, a parte mais importante da lição, depuração Esse pode ser um processo sistemático para identificar e resolver problemas de forma eficaz. Aqui estão as etapas a seguir. Primeiro, verifique as ferramentas do desenvolvedor do navegador. A maioria dos navegadores da Web modernos oferece ferramentas para desenvolvedores que permitem inspecionar solicitações de rede Você pode visualizar solicitações e cabeçalhos de resposta, cargas e mensagens de erro Isso acontecerá no Google Chrome, por exemplo, se você pressionar o controle F 12 ou a função F 12 se estiver em um Mac e depois acessar a rede. Em seguida, você deve revisar os códigos de status HTTP. Esses códigos na resposta fornecem informações valiosas sobre o resultado da solicitação. Familiarize-se com os códigos de status comuns para identificar o problema rapidamente Você também pode inspecionar cabeçalhos de solicitação e resposta. Preste muita atenção aos cabeçalhos de solicitação e resposta. Eles podem revelar detalhes importantes sobre o problema, como tokens de autenticação ausentes, tipos de conteúdo incorretos ou problemas no curso. Em seguida, você pode examinar os dados da carga útil se a solicitação envolver transferência de dados Inspecione as anomalias ou problemas da carga útil. Formatos de dados incompatíveis, dados corrompidos ou parâmetros ausentes podem causar problemas Você também deve verificar os registros do servidor. Os registros do servidor podem oferecer informações sobre o que está acontecendo no servidor. Eles podem revelar erros, problemas de desempenho ou, novamente, configurações incorretas Em seguida, você pode verificar a conectividade da rede Certifique-se de que sua conexão de rede na máquina da qual você está enviando solicitações esteja estável. Às vezes, problemas intermitentes de conectividade podem levar a falhas na solicitação Por fim, você pode usar ferramentas de depuração on-line. Várias ferramentas on-line estão disponíveis para testar e depurar Essas ferramentas podem ajudar a simular solicitações, verificar cabeçalhos e validar respostas Aqui, algo digno de menção é que, se você estiver desenvolvendo o aplicativo web em o erro HTTP está acontecendo, você pode pressionar novamente a função F 12 para acessar as ferramentas de desenvolvedor do navegador e, em seguida, pressionar o comando P e procurar P e procurar o script em que acha que o erro está acontecendo, colocar um ponto de interrupção lá e continuar com a depuração, e continuar com a depuração o que você pode fazer atualizando a página Quando se trata de ferramentas de depuração comuns, há várias que podem ajudar na depuração Primeiro, temos, é claro, Postman. Essa popular ferramenta de teste de API permite enviar e receber solicitações HTTP, inspecionar cabeçalhos e visualizar respostas Em seguida, temos Curl. A ferramenta de linha de comando é excelente para enviar solicitações HTTP e visualizar respostas em um terminal. Também temos o Hitler, que é um proxy de depuração da web que registra e inspeciona o tráfego HTTP e HTTPS entre o computador que está instalado Por fim, temos o Wireshark, que é um analisador de protocolo de rede e pode ajudá-lo a solucionar problemas no nível da rede que é um analisador de protocolo de rede e pode ajudá-lo a solucionar problemas no nível da rede que afetam as solicitações HTTP. Quando se trata de solução de problemas e depuração, a colaboração eficaz com sua equipe é vital para resolver problemas complexos Mantenha uma documentação completa de suas descobertas, incluindo mensagens de erro, registros e etapas de depuração Compartilhe essas informações com colegas que possam ajudar a diagnosticar e resolver o problema Concluindo, solucionar problemas e depurar solicitações HTTP é uma habilidade fundamental para desenvolvedores da Web, pois o HTTP é o protocolo fundamental das Ser capaz de identificar e resolver problemas de forma rápida e eficaz é essencial para fornecer aplicativos web confiáveis e uma experiência de usuário perfeita Usando ferramentas de desenvolvedor, examinando códigos de status, inspecionando cabeçalhos e cargas, verificando os registros do servidor e utilizando ferramentas de depuração Desenvolvedores como você podem diagnosticar e corrigir problemas de solicitação HTTP enquanto mantêm seus aplicativos funcionando sem problemas Com tudo isso dito, agradeço muito a vocês por ficarem comigo até o final desta palestra Espero que isso tenha lhe dado uma vantagem na solução de problemas e depuração de solicitações HTTP que surgirão no Eu era X e estou ansioso para ver você no próximo. 5. O que é HTTP?: Olá pessoal e bem-vindos novamente a este curso HTTP. Nesta primeira palestra, daremos uma olhada no protocolo HTTP e discutiremos o que é e também teremos uma visão geral básica de como ele funciona. Para começar, HTTP é um protocolo usado principalmente para transferir informações na forma de dados pela World Wide Web Ele faz parte do pacote Internet Protocol. Ele define comandos e serviços usados para transmitir dados de páginas da web Você pode pensar no HTTP como a base da comunicação de dados ou da Web mundial. Obviamente, aqui, os documentos de hipertexto incluem hiperlinks para outros recursos que o usuário que os vê pode acessar facilmente Por exemplo, com um clique do mouse ou tocando na tela em um navegador da web O protocolo HTTP está funcionando por um servidor. Modelo de cliente. Um cliente aqui pode ser um computador doméstico, um laptop ou até mesmo um dispositivo móvel. O servidor HTTP geralmente é um host da Web que executa um software de servidor Web, como o IIS. Por exemplo, quando você acessa um site, seu navegador envia uma solicitação ao servidor web correspondente e ele responde com um código de status HTTP Se o URL for válido e a conexão for criada, o servidor enviará ao seu navegador a página da web no formato HTML padrão e, junto com ela, outros arquivos relacionados. Outra observação, digna de observação aqui, seria que o HTTP é um sistema de resposta de solicitações sem estado A conexão é mantida entre o cliente e o servidor somente para a solicitação imediata. Depois que a solicitação for atendida, a conexão será fechada. Depois que o cliente HTTP estabelece uma conexão TCP com o servidor e envia um comando de solicitação, o servidor envia de volta sua resposta e fecha Agora, os códigos de retorno HTTP mais comuns estão entre os de 200. Isso significa que existe uma solicitação bem-sucedida, também conhecida como página da web também conhecida como página da web que você está tentando acessar. Depois, temos o código de status 31, que significa movido permanentemente, e que geralmente é encaminhado para uma nova URL ao receber esse código Então temos 41, que significa solicitação não autorizada, e você basicamente precisa autorização para superar esse ponto Se você está tentando acessar esse URL, você também pode ter um quatro ou três, o que é proibido, o que significa que o acesso não é permitido à página ou diretório que você está tentando acessar por meio do URL. E, por fim, também há 500 que significa erro interno do servidor, e isso geralmente é usado por uma configuração incorreta do servidor Http também define comandos, e isso pode ser parecido com get e post, que são usados para lidar com o envio de formulários em sites. As conexões HTTP criptografadas ocorrem por HTTPS, uma extensão do HTTP projetada para transmissão segura de dados. Essa conexão segura é disponibilizada por criptografia usando o certificado SSL. O SSL vem da camada de soquetes seguros e também tem um sucessor hoje em dia , chamado LS, também conhecido como segurança da camada de transporte Esses são protocolos para estabelecer links autenticados e criptografados entre redes e computadores Embora o protocolo SSL tenha sido descontinuado com o lançamento da primeira versão do LS, ainda é comum se referir a essa tecnologia relacionada como SSL ou SSL Atualmente, a versão mais atual é o TLS 13. Não se preocupe com SSL e HTTPS por enquanto, pois esta palestra é apenas uma visão geral e, em uma palestra posterior, abordaremos mais detalhadamente todo o As diferenças entre o HTTP e o HTTPS e assim por diante, para você entender em profundidade essas noções Por enquanto, vamos repetir as noções mais uma vez No protocolo HTTP, existem duas entidades. O cliente, que é seu navegador doméstico, e o servidor web real. Esses dois podem se comunicar, mais especificamente pelo cliente fazendo solicitações ao servidor web e pelo servidor enviando respostas. Essa comunicação é estruturada em partes, chamadas de mensagens, em oposição a um fluxo contínuo de Na próxima palestra, daremos uma olhada no HTTP, principais componentes e na estrutura dele Então, se isso parece interessante, estou ansioso para ver vocês lá. E muito obrigado por ficar comigo até o final desta palestra 6. Componentes HTTP: Olá pessoal, e bem-vindos de volta ao curso HTTP. Nesta palestra, examinaremos mais de perto quais são exatamente os principais componentes do protocolo HTTP Considero que esse é um fator chave para entendermos exatamente como todo esse protocolo está funcionando. Agora, é claro, existem mais entidades do que apenas o cliente e o servidor. Nesta palestra, vamos examiná-los se existem outros servidores de autorização, como é o caso no protocolo 00 para aquele O, ou se existem outros roteadores ou modems Como um coletivo, essas entidades estão entre o cliente e o servidor web que são, afinal, os dois principais atores desse protocolo HTTP. Todas as outras entidades são chamadas de proxies. Agora, a entidade mais importante do protocolo HTTP é o usuário, também chamado de cliente. Esse usuário acessa um site na Internet e o faz usando uma ferramenta que atua em seu nome e é chamada de navegador da web, como você já deve saber Ou um agente de usuário em termos específicos. Neste usuário, você pode pensar como se estivesse em casa operando em sua própria máquina. Quando você abre o Google Chrome e digita qualquer URL do Facebook ou de alguma plataforma de mídia social que está tentando acessar, você é o usuário, a parte mais importante desse protocolo HTTP. Agora, em todo esse processo, sempre é o navegador quem inicia a solicitação e nunca o servidor web para o qual você faz a solicitação Agora, você pode observar que foi você quem criou a conta de mídia social e você quem a está verificando. Todo o processo vem de você, do cliente, e também da ferramenta que você está usando. Ou seja, como mencionei antes, o navegador da web da sua máquina. Agora, quando lhe é dada a tarefa de mostrar a página da Internet que você solicitou com seu navegador. Seu navegador tem a tarefa de recuperar o documento HTML que representa este site que você solicitou do servidor Ele pode até mesmo fazer solicitações adicionais se essa página tiver referências de outros recursos que precisam ser recuperados Por exemplo, você pode pensar em imagens, PNGs e assim por diante, mas a resposta tem todas as informações e o navegador as reunirá em um documento HTML que será mostrado para você Olhando agora para o outro lado dessa troca de informações que ocorre nesse protocolo, temos o servidor web, uma entidade que fornece os documentos solicitados pelo cliente como resposta à sua solicitação. O que precisamos entender aqui é que, embora em nossa palestra descrevamos esse servidor web como uma entidade única, na maioria dos casos hoje em dia, dadas as grandes quantidades de dados armazenados pelas empresas em seus servidores, definitivamente não será o Não será uma única entidade por trás do servidor web. Você pode pensar nos dados das empresas de mídia social de todos os usuários que têm uma conta com elas. E se os usuários estão na casa dos milhões, você pode pensar que seria praticamente impossível manter todos os dados em uma única máquina. O servidor de que estamos falando que hospeda todas as informações dos usuários é, na verdade, composto por uma abundância de máquinas servidoras. Então, se você já viu armazéns da empresa onde eles armazenam seus servidores, podem estar em filmes ou simplesmente pesquisar servidores na web, ele mostrará aquelas salas enormes cheias de servidores web Então você saberá do que estou falando. Eles compartilham entre si as informações que armazenam. Então, eles compartilham e equilibram toda a carga que têm entre eles. essa infinidade de servidores pode Além disso, essa infinidade de servidores pode fazer solicitações a bancos remotos para fornecer o documento final que está sendo solicitado pelo cliente E nesse banco de dados, isso pode ser alguma outra informação que eles possam interrogar sobre usuários ou algum outro campo relacionado a O último ator neste protocolo são os proxies reais que são, como mencionei anteriormente, várias outras máquinas que transmitem as mensagens enviadas por esses dois atores principais, o cliente e o servidor Esses proxies podem ser não transparentes ou transparentes Não transparente significa que eles podem alterá-lo, e transparente significa que eles estão apenas encaminhando e não o alterarão em nenhuma forma ou formato se o alterarem. Portanto, eles não são Eles podem fazer muitas coisas, como filtrar cache no seu navegador. Ou até mesmo balancear a solicitação feita pelo cliente, permitindo que diferentes servidores comecem a atender diferentes partes da solicitação. Então, esses são os principais componentes e os principais atores que estão disponíveis no protocolo HTTP. Na próxima palestra, examinaremos mais de perto todos os fluxos HTTP, como esse protocolo está funcionando exatamente passo a passo Obrigado por ficarem comigo até o final desta palestra, e eu realmente espero ver vocês na próxima 7. O fluxo de trabalho HTTP: Olá pessoal, e bem-vindos de volta a este curso HTTP. Nesta palestra, examinaremos mais de perto o fluxo de trabalho HTTP para entender exatamente como esse protocolo funciona Podemos falar sobre o fluxo de trabalho que ocorre quando um cliente está fazendo uma solicitação para o servidor web para entender melhor o protocolo HTTP. Em primeiro lugar, como eu disse, o cliente abriria uma nova conexão ou talvez reusaria uma aberta para o servidor web Essa conexão pode ser do tipo TCP e será usada, como você deve ter adivinhado, para fazer a solicitação real ao servidor Como você pode ver aqui, novamente, o cliente é quem inicia todo o fluxo de trabalho, conforme discutimos em uma palestra anterior A próxima etapa é enviar a mensagem HTTP, que especifica o recurso você deseja recuperar como cliente, ou seja, a página da Web à qual você está tentando acessar Depois de receber uma resposta do servidor web, seu navegador a lerá e a analisará em um documento HTML que será legível por humanos e estético para você ver Por fim, a conexão pode ser fechada ou usada. Além disso, para outros fluxos como o que acabamos de mencionar, é claro. Agora, ao pensar sobre isso, uma observação aqui pode ser que esse fluxo pode ser um pouco diferente se estivermos familiarizados com o conceito de pipeline HTTP e o que significa pipelining HTTP E, portanto, permite que o cliente faça várias solicitações para servidores diferentes sem precisar esperar primeiro pelas respostas anteriores Porque esse processo foi ensinado como linear antes. Mas o pipelining HTTP encontra uma solução alternativa para tudo isso Essa foi uma visão geral ampla do fluxo de trabalho HTTP. Na próxima palestra, discutiremos o que é uma URL e, posteriormente, qual é sua estrutura exata Se isso parece interessante, estou ansioso para ver vocês lá. Muito obrigado por ficar comigo até o final desta palestra 8. Cache: Olá pessoal, e bem-vindos de volta ao discurso sobre o protocolo HTTP Nesta palestra, falaremos sobre uma estratégia fundamental para otimizar o desempenho de uma aplicação web, que é Isso envolve armazenar dados e recursos acessados com frequência para reduzir a necessidade de recuperação redundante de dados Resultando em tempos de carregamento mais rápidos, melhores experiências do usuário e redução da carga do servidor. Quando se trata de otimização do desempenho na web, cache desempenha um papel fundamental E é um conceito que todo desenvolvedor web deve entender. Mas antes de entender isso, vamos falar sobre a necessidade e a importância do armazenamento em cache Os aplicativos da Web dependem da transferência de dados entre clientes que geralmente são navegadores e servidores da Web. Já falamos sobre todo esse fluxo em uma lição anterior. Cada solicitação de um recurso, como uma página HTML, um arquivo Javascript ou uma imagem, exige uma viagem do cliente ao servidor e O tempo que leva. Essa viagem de ida e volta pode impactar significativamente a percepção do usuário velocidade e a capacidade de resposta de um site cache resolve esse desafio armazenando cópias de recursos em vários locais, reduzindo a necessidade de buscar os mesmos dados repetidamente Ele acelera a entrega de conteúdo ao usuário e minimiza a carga nos servidores cache pode ocorrer em diferentes níveis na arquitetura da web Do lado do cliente aos servidores intermediários e redes de entrega de conteúdo, também chamados de CDNs Vamos dar uma olhada agora nos tipos de cache que existem Em primeiro lugar, temos o cache do navegador. Os navegadores da Web mantêm seus caches locais, onde armazenam recursos como folhas de estilo, imagens e scripts Quando um usuário visita novamente um site, o navegador pode recuperar esses recursos do cache, economizando tempo e também Você pode pensar em uma imagem de uma página da web e ela é armazenada em cache pelo navegador do usuário Quando o usuário navega para outra página no mesmo site, a imagem é carregada do cache local, reduzindo a necessidade de uma solicitação do servidor O segundo tipo de cache é chamado de cache CDN ou rede de entrega de conteúdo Cdns são redes distribuídas de servidores estrategicamente colocadas em várias localizações geográficas Eles armazenam em cache e veiculam conteúdo de locais próximos ao usuário. Ao armazenar e entregar conteúdo de servidores H, CDNs podem reduzir significativamente a latência e melhorar os tempos de carregamento que o usuário experimentará Um site usa uma CDN para distribuir suas imagens. Digamos que quando um usuário na Europa acessa o site, as imagens são entregues de um servidor CDN próximo, em vez do servidor origem, reduzindo o tempo de carregamento Em terceiro lugar, temos o cache do servidor proxy em redes corporativas Os servidores proxy geralmente são empregados para armazenar em cache sites externos acessados com frequência. Isso não apenas melhora o desempenho, mas também conserva a largura de banda ao reduzir a quantidade de dados obtidos repetidamente de Como exemplo, o servidor proxy de uma empresa armazena em cache sites externos acessados com frequência, melhorando o desempenho e mais do que isso, economizando Em HTTP, existem cabeçalhos de cache, SCTP, a base do protocolo A web mundial inclui vários cabeçalhos de cache que instruem clientes e intermediários sobre como armazenar em cache e validar recursos Esses cabeçalhos são cruciais para controlar e otimizar o armazenamento em cache dos recursos da web Esses cabeçalhos são como os outros cabeçalhos sobre os quais falamos, cabeçalhos de autorização e assim por diante, mas são chamados de tag de controle de cache e, modificados pela última vez, O cabeçalho de controle de cache define as diretivas Como max H para definir o tempo máximo em que um recurso é considerado novo. Uma tag de entidade, representada pelo cabeçalho da tag, é um identificador exclusivo para um recurso. Quando um recurso é alterado, a tag muda, permitindo que os clientes verifiquem se o recurso ainda é válido. O último cabeçalho modificado indica a hora da última modificação de um recurso. Isso ajuda os clientes a validar se sua cópia em cache ainda é atual e relevante Quando se trata de armazenamento em cache, existem várias estratégias que os desenvolvedores podem aplicar O primeiro é chamado de cache busting e é empregado quando os recursos mudam com frequência Os desenvolvedores podem vincular números de versão ou parâmetros de consulta exclusivos aos URLs de recursos, forçando os navegadores a buscar o conteúdo Em seguida, você pode aproveitar os caches do navegador. Os desenvolvedores podem otimizar URLs de recursos e definir cabeçalhos de controle de cache apropriados para maximizar os benefícios do armazenamento em cache do navegador Por fim, você pode usar CDNs. As redes de distribuição de conteúdo são altamente eficazes para carregar recursos do servidor e fornecer conteúdo para servidores próximos, melhorando assim o desempenho Existem alguns benefícios do armazenamento em cache e da otimização do desempenho Eles incluem latência reduzida porque o armazenamento em cache reduz significativamente o tempo necessário para carregar recursos, resultando em uma experiência de usuário mais rápida Além disso, eles minimizam a carga do servidor fornecendo recursos de cache Os servidores ficam livres da carga de lidar com solicitações repetidas para o mesmo cliente Você também economizará largura de banda. cache conserva a largura de banda ao reduzir a quantidade de dados transferidos entre servidores e clientes Também aprimoramos a experiência do usuário porque tempos de carregamento mais rápidos e aplicativos mais responsivos aprimoram a experiência e a satisfação do usuário Embora as otimizações de cache e desempenho sejam altamente vantajosas, há desafios e considerações a serem considerados ao implementá-las Primeiro, você precisa prestar atenção à experiência do usuário. Encontrar um equilíbrio entre segurança e conveniência para o usuário é essencial aqui. Às vezes, estratégias complexas de armazenamento em cache podem dissuadir os usuários. Você também precisa ter em mente a complexidade da implementação de forma adequada. implementação do armazenamento em cache, a otimização de URLs de recursos e configuração de cabeçalhos exigem planejamento exigem Em resumo, o armazenamento em cache é uma técnica predominante para otimizar o desempenho Ele reduz a latência, conserva a largura de banda e aprimora a experiência do usuário, e aprimora a experiência do usuário aproveitando vários tipos de cache, cabeçalhos de cache e estratégias de controle de cache aproveitando vários tipos de cache, cabeçalhos de cache e estratégias de controle de cache. Os desenvolvedores da Web podem criar aplicativos da Web rápidos e responsivos que atendam às demandas dos usuários modernos da Web Em um mundo em que o desempenho na web é um fator crítico para o sucesso de aplicativos como o que vivemos atualmente, dominar a arte do cache é indispensável É uma habilidade que pode transformar um site lento em uma plataforma extremamente rápida e responsiva, plataforma extremamente rápida e responsiva, satisfazendo os usuários e reduzindo Você pode descobrir isso em seu site e estou ansioso para ouvir as experiências de seu cara à medida que a Internet continua crescendo e evoluindo O papel dessa captura nas otimizações de desempenho continua tão importante como sempre Mas com isso dito, agradeço a vocês por ficarem comigo até o final desta palestra Eu realmente espero que você tenha conseguido algo com isso, e estou ansioso para ver você na próxima. 9. Compartilhamento de Resource Cross Origin: Olá pessoal e bem-vindos de volta a este curso HTTP. Nesta palestra, falaremos sobre o compartilhamento de recursos de origem cruzada Esse é um recurso de segurança muito importante dos aplicativos web modernos, permitindo acesso controlado a recursos de diferentes domínios Em uma era em que os aplicativos da web interagem com vários serviços e APIs na Internet, o curso desempenha um papel fundamental na manutenção da segurança e, ao mesmo tempo, permite dados entre origens Nos primórdios da web, os navegadores aplicavam uma política estrita de mesma origem Isso significava que as páginas da web só podiam fazer solicitações para o mesmo domínio do qual foram carregadas. Embora essa política fosse essencial para a segurança, ela se tornou uma limitação significativa à medida que os aplicativos da web evoluíram. aplicativos web modernos, por outro lado, geralmente exigem acesso a recursos hospedados em domínios diferentes Isso inclui carregar fundos de scripts do Google Images e dados de servidores e APIs de terceiros para lidar com essa limitação e permitir solicitações controladas de origem cruzada. O curso foi introduzido como um recurso de segurança. O curso permite que os servidores web especifiquem quem pode acessar os recursos e sob quais condições. Ele faz parte do protocolo HTTP e funciona adicionando cabeçalhos HTTP às respostas enviadas pelos servidores web Esses cabeçalhos transmitem as políticas dos servidores em relação às solicitações de origem cruzada Vamos dar uma olhada agora nos principais componentes. Claro, primeiro temos a origem. Qual termo se refere à combinação de domínio de protocolo e porta da qual uma página da web foi carregada. Por exemplo, Htp, exemplo.com é uma origem, enquanto Http exemplo.com e Http sub exemplo.com são origens diferentes Em seguida, temos os cabeçalhos HTTP. O curso os usa para comunicar permissões para solicitações de origem cruzada. Os cabeçalhos mais críticos são o cabeçalho de origem que é enviado pelo cliente para indicar a origem da página solicitante O controle de acesso permite que o cabeçalho de origem definido pelo servidor especifique quais origens têm permissão para acessar seus recursos. Métodos de permissão de controle de acesso. cabeçalho especifica os métodos HTTP get post, put, delete permitidos para solicitações de origem cruzada E o controle de acesso permite cabeçalhos que listam os cabeçalhos HTTP que podem ser usados na solicitação real Agora que os cabeçalhos estão prontos, vamos examinar mais de perto processo do curso e quais etapas ele realmente envolve A primeira etapa é a solicitação de pré-voo. Quando uma página da Web faz uma solicitação de origem cruzada com determinadas condições, por exemplo, cabeçalhos ou credenciais personalizados, o navegador envia uma solicitação de preflight, ou seja, uma solicitação de opções HTTP, para o Essa solicitação de pré-voo solicita permissão para fazer a solicitação real de origem cruzada Em seguida, o servidor de destino responde à solicitação de preflight com os cabeçalhos apropriados do curso Se o servidor aprovar a solicitação, ela incluirá cabeçalhos como acesso, permitir métodos de permissão de controle de acesso de origem e cabeçalhos de permissão de controle de acesso Por fim, se a resposta do servidor à solicitação de preflight for positiva, o navegador enviará a solicitação real para o servidor de destino O servidor pode incluir cabeçalhos do curso na resposta para indicar se a solicitação de origem cruzada é permitida Eu escolhi falar sobre o curso nesta palestra porque ele é essencial em vários cenários do mundo real Você pode pensar em APIs de terceiros aqui. Os aplicativos da Web geralmente integram serviços de terceiros e APIs para várias funcionalidades como compartilhamento de mídia social, processamento de pagamentos ou serviços de mapeamento O curso permite que essas integrações ocorram com segurança. Os sites podem precisar carregar recursos como fontes ou scripts de redes de distribuição de conteúdo ou fornecer dados de servidores remotos. curso garante que o compartilhamento de dados entre origens seja seguro e controlado. Login único e autenticação. Muitos provedores de identidade implementam soluções de login único do curso quatro . Ele permite uma experiência de registro perfeita e segura mesmo se o provedor de identidade residir em um domínio diferente Por fim, o curso também é uma parte fundamental da segurança na web Ao permitir que os servidores definam quais origens acessam suas solicitações, isso ajuda a evitar solicitações não autorizadas de origem cruzada Embora o Course aprimore a segurança na web, sua implementação deve ser abordada com cuidado porque, em primeiro lugar, políticas de curso mal configuradas podem inadvertidamente Portanto, é muito importante validar e testar minuciosamente as configurações do curso Além disso, nem todos os navegadores oferecem suporte total ao curso. Alguns navegadores mais antigos podem não lidar com isso corretamente ou ter limitações. Os desenvolvedores devem estar cientes dessas limitações ao usar o curso. As solicitações Preflight adicionam uma viagem extra de ida e volta às solicitações de origem cruzada, potencialmente afetando Minimizar as solicitações de pré-voo é crucial para aplicativos eficientes Com tudo isso dito, o compartilhamento de recursos entre origens é parte integrante da segurança e funcionalidade modernas da web. Ele permite que aplicativos da web acessem recursos e serviços de diferentes domínios mantendo interações controladas e seguras Desenvolvedores e administradores de servidores precisam de um entendimento sólido, é claro, para garantir que seus aplicativos da Web possam aproveitar todo o potencial das solicitações de origem cruzada e, ao mesmo tempo proteger-se contra ameaças à segurança Muito obrigado por ficarem comigo até o final desta palestra Espero que você tenha aproveitado isso e use o compartilhamento de recursos de origem cruzada em suas futuras solicitações HTTP. Eu era Boi e estou ansioso para ver você na próxima palestra 10. O que é uma URL?: Olá pessoal, e bem-vindos de volta a este tutorial do HDDP. Nesta palestra, discutiremos os URLs e o que eles são exatamente? Um acrônimo de URL vem do localizador uniforme de recursos. Um URL nada mais é do que o endereço de um recurso na World Wide Web. Obviamente, esse recurso pode ser uma página da Web real, uma imagem ou qualquer outro tipo de dado reunido que possa ser encontrado na Internet. Uma observação aqui é que cada valor do URL aponta na rede mundial para um recurso exclusivo. Esses recursos podem ser uma página HTML, um documento CSS, uma imagem e assim por diante. Eles podem até ser um agregado Json que, quando você abre, contém apenas dados entre chaves Alguns deles podem ser movidos ou removidos. Portanto, a Internet está se movendo tão rápido hoje em dia. Se for esse o caso, isso pode indicar diretamente um código de retorno HTTP de quatro ou quatro não encontrado se preocupe com os códigos de retorno. Teremos uma seção futura que será inteiramente sobre eles e os discutiremos em detalhes. A forma como acessaríamos um URL seria digitá-lo na barra do navegador e pressionar Enter. O que aconteceria no back-end desse processo que o usuário básico não conhece e não sabe, basicamente como funciona, seria esse navegador UR, então o navegador do usuário faria uma solicitação no servidor especificado na URL para recuperar exatamente as informações especificadas no caminho dessa URL Podemos ver que esses URLs são uma ferramenta que possibilita a solicitação ao servidor a partir de nossos navegadores locais Portanto, eles são muito úteis. Agora, dependendo do contexto em que estamos, existem apenas dois tipos de URLs que são classificados como URLs absolutos e URLs relativos A diferença é bem sutil entre os dois, mas merece ser conhecida, pois é um conceito bastante básico que você pode encontrar. Se você entrar no desenvolvimento web ou simplesmente digitar um F 12 no Google Chrome e tentar ler o recurso de uma página da web, você pode se deparar com esse conceito. E é melhor abordá-lo para que você o entenda profundamente quando se deparar com ele. Um URL absoluto é melhor usado quando não há contexto. Por exemplo, na página inicial do nosso navegador. Absoluto significa que você precisa especificar o caminho completo para a solicitação que está fazendo. Agora, no outro extremo do espectro, quando se trata de URLs relativos, se um URL for usado dentro de um documento HTML, por exemplo, você pode simplesmente especificar o caminho relativo de onde você está e agora ele terá que levá-lo até lá Isso pode acontecer porque o navegador nesse ponto tem a URL do documento em que você está e pode usá-la para preencher o vazio do caminho relativo que você está inserindo Ele pode usar isso como um ponto intermediário para chegar aonde você deseja ir em relação a esse ponto. Se você ver um caminho que começa com uma barra, o navegador colocará o caminho restante após a barra em relação ao caminho está naquele ponto, ou seja, depois dele E nós o levaremos ao destino escolhido, se for válido. É por isso que a nomenclatura relativa do URL foi escolhida. Pensando nisso, os URLs são uma forma muito simples legível por humanos de navegar de forma rápida e simples na Internet sem muito conhecimento tecnológico sem Além disso, dada a falta de experiência da maioria dos usuários da Internet, a propriedade semântica dos URLs deve ser mantida como uma boa prática para talvez manter essa clareza na manipulação dos caminhos das solicitações dos usuários comuns Nas próximas palestras, examinaremos mais de perto os elementos-chave exatos na estrutura de um URL e os decomporemos para ver o que cada um deles faz Se isso parece interessante, estou ansioso para ver vocês lá. Muito obrigado por ficar comigo até o final desta palestra 11. A estrutura de uma URL: Olá pessoal, e bem-vindos de volta a este tutorville HTTP. Nesta palestra, examinaremos mais de perto a estrutura de uma URL Algo em que você talvez nunca tenha pensado, pois acabou de escrever na barra do navegador doméstico. Mas esses URLs, na verdade, têm uma estrutura e cada parte deles significa algo Quando você os reúne, eles podem nos levar exatamente para onde queremos ir, talvez uma parte específica em um documento HTML da web que o servidor hospeda. Um URL é composto, como eu disse, de partes diferentes, e algumas delas são obrigatórias, enquanto outras são opcionais. A primeira parte de uma URL é o esquema dela. Isso indica o protocolo que o navegador deve usar, solicitar o recurso, geralmente para sites, o protocolo é HTTPS ou HTTP. O endereçamento de páginas da web requer um dos dois. Isso é basicamente muito simples, e você pode ter visto o esquema em alguns URLs que você escreveu, ou talvez, se você clicou no URL da página da web em que está agora, você pode ver que começa com Eu não acho que isso seja nada estranho para você agora, você só sabe mais sobre o nome dele Depois do esquema, temos a parte de autoridade que é separada do esquema por um padrão de caracteres, que é a coluna e depois duas barras Nessa autoridade, temos o nome de domínio, por exemplo. Isso pode ser www.thenameofyoursite.com Este é o domínio, o endereço real em que Pode incluir até mesmo a porta, mesmo que isso não seja muito comum, pois veremos o porquê em breve. E esses dois são separados novamente por uma coluna. Então, ficaria assim na coluna site.com. E então o Port 88 talvez. Agora, o domínio indica qual servidor da Web está sendo solicitado, como você vê no seu dia a dia ao escrever W e, em seguida, no site que você está tentando acessar, esse servidor da Web está sendo solicitado. Agora, a porta indica a porta técnica, por assim dizer, usada para acessar o recurso no servidor web. Geralmente é omitido se o servidor web usa as portas padrão do protocolo HTTP É por isso que quase nunca o vemos. O servidor web quase sempre usa as portas padrão do protocolo HTTP. Quanto a mim, raramente via qualquer porta depois do domínio. Agora, depois da parte de autoridade na estrutura de uma URL, vem o caminho do recurso no servidor web. Agora, nos primórdios da web, um caminho como esse representava uma localização física no servidor web. Mas agora é principalmente uma abstração gerenciada por servidores web sem qualquer realidade física Esse caminho do qual estamos falando aqui pode ser algumas barras que indicam, por exemplo, o usuário, depois o ID de um usuário especificado e, novamente, algum fato sobre esse usuário pode ser sua página de informações Então, cada uma dessas palavras-chave é separada, como eu disse, por barras após a autoridade, e elas apontam para um local muito específico nesse servidor web Portanto, ele vem com informações adicionais. Embora essas sejam as partes principais, também podemos ter parâmetros. Eles são uma lista de pares de valores-chave separados pelo símbolo final. Isso também pode aparecer em URLs com bastante frequência, e o servidor da Web pode usar esses parâmetros para adicionar mais funcionários entre o retorno do recurso Por fim, talvez tenhamos uma âncora. E isso representa uma espécie de marcador dentro do recurso, dando ao navegador as instruções para mostrar o conteúdo localizado naquele ponto de marcador em um documento HDML Por exemplo, o que uma âncora faria é que o navegador rolasse para baixo automaticamente até o ponto em que a âncora está definida E em um documento de vídeo ou áudio no navegador, ele tentará ir até a hora que a âncora representa É importante notar que a parte após o H t também é conhecida como identificador de fragmento, e essa é basicamente a sintaxe de uma âncora Essa era basicamente a estrutura de um URL em detalhes. Espero que vocês tenham conseguido algo com isso. E a partir de agora, cada vez que você inserir um URL, você poderá muito bem separar cada uma de suas partes em sua cabeça e entender o nome de cada uma e, mais importante do que isso, o que cada uma delas faz Agora, na próxima seção, falaremos sobre um processo chamado codificação de URL, que é muito interessante e útil quando se trata da Internet Então, se isso parece interessante, estou ansioso para ver vocês lá. Muito obrigado por ficar comigo até o final desta palestra 12. Codificação de URL: Olá pessoal, e bem-vindos de volta a este curso HTTB. Nesta palestra, discutiremos o processo de codificação de URL O que é, por que e quando é útil quando se trata de codificação de URL, também conhecida como codificação percentual O que todo esse processo faz é converter caracteres em um formato que pode ser transmitido em URLs pela World Wide Web Como ele faz isso é basicamente processando o conjunto de caracteres G. Nesse ponto, você pode perguntar: qual é o objetivo de ter essa codificação Bem, é necessário porque, na maioria das vezes, os URLs têm caracteres que não estão dentro do conjunto G e precisam ser convertidos nesse formato para que esse URL específico funcione ao entrar em um navegador da web Toda a forma como essa codificação funciona é bem simples e direta Para cada caractere que não seja um caractere SG, ele está sendo substituído por um sinal de porcentagem seguido por dois dígitos hexadecimais Isso significa que para cada personagem que não é um personagem Asch Basicamente, ele mapeia esse caractere para uma estrutura de três caracteres , da qual o primeiro é sempre a porcentagem e os próximos dois são dígitos hexadecimais Agora, para os espaços em particular, se você pensou bem, eles também não são permitidos dentro de um URL. E eles são substituídos no URL pelo sinal de adição caso você já tenha tentado representá-los. Existem na Internet tabelas inteiras nas quais você pode ver para onde cada caractere é mapeado quando se trata da codificação de URL Ou você tem uma abordagem ainda mais simples do que essa. Se você se deparar com a situação de querer codificar um URL a partir de seu texto que não seja Asch Existem sites como o URL Encoder.org e, se você colar o texto do UR lá, ele poderá codificá-lo automaticamente como um URL codificado Portanto, esse é um processo bastante básico e direto que é muito simples de entender, mas é fundamental que você saiba que ele é usado para escrever praticamente qualquer coisa em uma nova URL que outra forma, não teria permissão para estar Obrigado por ficarem comigo até o final desta palestra. Na próxima, veremos a sessão HTTP e também os cookies para entender melhor esse protocolo. Então, se isso parece interessante para vocês, estou ansioso para ver vocês lá. 13. Sessões e cookies: Olá pessoal, e bem-vindos de volta ao tutorial HTTP. Nesta palestra, vamos discutir a sessão HTTP e também os cookies que estão disponíveis aqui para entender melhor esse protocolo e como ele funciona A forma como as sessões HTTP funcionam é usando essas coisas chamadas cookies e também técnicas criptográficas para manter a data sem armazenar tantos dados no servidor Ao apresentar uma página da web dinâmica, o servidor envia os dados do estado atual para o cliente, ou seja, o navegador da web, na forma de um cookie. Isso é o que é um cookie, o cliente salva esse cookie na memória que recebeu ou no disco. Dessa forma, o servidor web não precisa. Com cada solicitação sucessiva, o cliente devolve o cookie ao servidor O servidor usa os dados para lembrar o estado do aplicativo para aquele cliente específico e também gerar uma resposta apropriada. Esse mecanismo pode funcionar bem em quase todos os contextos, mas há algumas exceções você pode ter visto ao entrar um novo site que exigem que você aceite todos os cookies Isso é o que isso significa. Ele enviará partes das informações para que eles não precisem armazená-las em seus servidores da web. Informações sobre a sessão em que você está. E informações sobre isso, porém, se você clicar nesse site mais tarde, ele saberá de onde levá-lo. No entanto, os dados armazenados em um cliente, ou seja, em você, vulneráveis ao uso sessões do lado do cliente, onde confidencialidade e a integridade são necessárias O seguinte deve ser garantido. Precisamos ter confidencialidade. Dados, integridade e autenticidade. confidencialidade vem do fato que nada além do servidor deve ser capaz de interpretar os dados da sessão, ou seja, nenhum terceiro ou hacker A integridade significa que nada além do servidor deve manipular os dados de forma acidental ou E a autenticidade significa que nada além do servidor deve ser capaz de iniciar sessões válidas Agora, para realizar essas três propriedades e garantir que elas sejam respeitadas, o servidor precisa criptografar dados da sessão antes de enviá-los ao cliente E a modificação de tais informações por qualquer outra parte deve ser evitada por meio desse meio criptográfico Transmitir o estado de um lado para o outro a cada solicitação só é prático se o tamanho da Coca-Cola for Em essência, as sessões do lado do cliente trocam espaço em disco do servidor ou a largura de banda extra que cada solicitação da web exigirá Além disso, o navegador limita o número e o tamanho dos cookies que podem ser armazenados por um site para melhorar a eficiência e permitir mais dados de cessação O servidor pode compactar os dados antes de criar o cookie, descompactando-os posteriormente quando o cookie for retornado pelo cliente Isso pode funcionar com ferramentas de compressão, como programas Win Sip ou Seven P os quais vocês talvez estejam familiarizados Ao tornar os cookies muito grandes, a troca não valeria mais a pena, pois a largura de banda para enviá-los seria obviamente É sobre a sessão HTTP, como ela é aprimorada pelos cookies Espero que vocês tenham entendido algo dessa palestra. Na próxima, examinaremos detalhadamente todos os métodos de solicitação HTTP, veremos o que são, o que fazem e como podem ser úteis em nossa jornada para entender melhor o protocolo HTTP. Se isso parece interessante, estou ansioso para ver vocês lá. Obrigado por ficar comigo até o final desta palestra. 14. WebSockets: Olá pessoal e bem-vindos de volta a este curso sobre o protocolo HTTP. Nesta palestra, vamos dar uma olhada nos web sockets Eles são muito importantes na comunicação em tempo real quando se trata do protocolo HTTP. No cenário moderno da tecnologia web, as expectativas dos usuários em relação à comunicação em tempo real atingiram novos patamares. Como você pode ver, tudo ao seu redor está conversando com amigos no Whatsapp, monitorando dados de vida ou colaborando com colegas de trabalho A demanda por interação instantânea e perfeita na web nunca foi tão grande Para atender a essa demanda, os desenvolvedores da web em geral recorrem ao Web Sockets, uma tecnologia que facilita a comunicação em tempo real pelo protocolo HTTP Nesta lição, vamos nos aprofundar no mundo dos soquetes web E como eles permitem a comunicação em tempo real sem a necessidade de solicitações HTTP constantes. Eles realmente são uma parte essencial desse protocolo. Mas antes disso, vamos dar uma outra olhada no modelo de resposta de solicitação HTTP o qual já falamos. Basta atualizá-lo. Antes de explorarmos os soquetes da web, é essencial entender a base sobre a qual eles operam O protocolo de transferência de hipertexto ou foreshort. HTTP sempre foi a espinha dorsal da World Wide Web, servindo como mecanismo para a troca de dados entre clientes, geralmente navegadores e servidores da Web No modelo tradicional de resposta de solicitação HTTP, o cliente envia uma solicitação ao servidor que processa a solicitação e envia de volta uma resposta. Embora esse modelo funcione bem para muitas interações na web, ele tem limitações quando se trata de comunicação em tempo real. No modelo HTTP tradicional, uma nova solicitação é necessária para cada interação entre o cliente e o servidor. Isso significa que, para recuperar novos dados ou mensagens, o cliente deve enviar solicitações repetidamente, resultando em uma série de trocas de ida e volta Essa abordagem não é adequada. Aplicativos em tempo real em que os dados precisam fluir de forma contínua e instantânea e entrar nos soquetes da web Eles foram introduzidos como uma solução para a limitação do HTTP tradicional. Eles fornecem um canal de comunicação bidirecional completo canal de comunicação bidirecional uma única conexão de longa duração com soquetes da web Tanto o cliente quanto o servidor podem iniciar a comunicação de forma independente Isso significa que os dados podem ser enviados do servidor para o cliente, ou vice-versa, sem a necessidade uma nova solicitação HTTP a cada vez, como era o caso antes. Agora, vamos examinar os principais recursos dos soquetes da Web e também os principais motivos pelos quais você deve considerar implementá-los em seus próprios aplicativos Primeiro, temos uma conexão persistente. Os soquetes da Web mantêm uma conexão persistente entre o cliente e o servidor Depois que a conexão é estabelecida, ela permanece aberta, permitindo que os dados fluam continuamente sem a sobrecarga de abrir e fechar conexões para cada interação Em segundo lugar, temos demandas de comunicação em tempo real de baixa latência demandas de comunicação em tempo real Baixa latência e soquetes web funcionam nessa frente. Como a conexão está sempre aberta, os dados podem ser transmitidos com o mínimo de atraso, tornando os soquetes da Web ideais para aplicativos em que atualizações instantâneas são essenciais O terceiro recurso principal do web socket é o protocolo leve O protocolo de soquete Web foi projetado para ser leve, reduzindo a sobrecarga da transferência de dados Essa eficiência contribui para a velocidade e a capacidade de resposta dos aplicativos em tempo real Por fim, temos a comunicação de origem cruzada, que é suportada por soquetes da web, que significa que os clientes podem se conectar a servidores de soquetes da web em diferentes domínios Isso o torna adequado para vários casos de uso, incluindo aplicativos de bate-papo e feeds de dados ao vivo Agora vamos dar uma olhada em alguns casos de uso do mundo real apenas para que você entenda melhor todo o conceito de websocket As vantagens dos soquetes web são evidentes em várias aplicações do mundo real Para o primeiro cenário, vamos considerar os aplicativos de bate-papo. Eles se beneficiam dos recursos de mensagens instantâneas dos soquetes da web Os usuários podem trocar mensagens em tempo real sem a necessidade de atualizar a página continuamente Aqui você pode pensar seu aplicativo de bate-papo favorito, seja no celular ou na web. Em seguida, temos jogos online. Eles geralmente exigem atualizações em tempo real , como movimentos do jogador e mudanças no estado do jogo. soquetes Web permitem a sincronização perfeita dados do jogo Além disso, se você estiver investindo. Você pode pensar no mercado de ações e nas plataformas financeiras. Nos serviços financeiros, os dados em tempo real são essenciais. As plataformas do mercado de ações usam soquetes da web para fornecer preços de ações ao vivo, tendências de mercado e execuções comerciais aos Por fim, ferramentas de colaboração, como quadros brancos compartilhados e editores de documentos dependem de atualizações em tempo real para garantir que todos os participantes vejam as Quando se trata de implementar soquetes web, tanto o cliente quanto o servidor precisam de suporte para soquetes web Java Script por meio da API de soquete web é comumente usado no lado do cliente Estruturas e bibliotecas do lado do servidor, como nenhum JS com a biblioteca YS ou o padrão com soquete web, habilitam esse suporte a websocket no lado Esse é um ótimo ponto de partida de bibliotecas para examinar se você já tem uma situação de cliente-servidor na qual deseja implementar soquetes web Embora os soquetes web ofereçam uma solução poderosa para comunicação em tempo real, existem alguns desafios e considerações Primeiro, temos escalabilidade. Lidar com um grande número de conexões de web socket pode ser um desafio balanceamento de carga e o gerenciamento eficiente da conexão são cruciais para aplicativos escaláveis de soquete web Em seguida, temos problemas de firewall e proxy. Algumas redes e configurações de segurança podem restringir o tráfego de soquetes da web Nesses casos, as conexões de soquete da web podem precisar ser encapsuladas por meio de HTTP ou Ou você pode até mesmo implementar uma solução alternativa caso sua implementação do web socket falhe Terceiro, temos segurança habilitada A segurança das conexões de soquetes da web é vital Implementar conexões seguras de soquete da web, que são duplas de YSS, e validar dados para evitar vulnerabilidades de segurança Em resumo, os soquetes da web revolucionaram comunicação em tempo real na web ao superar as limitações do HDDP Eles fornecem uma baixa latência por conexão direcional que serve como espinha dorsal de vários aplicativos em tempo real, desde plataformas de bate-papo até jogos online e Desenvolvedores da Web equipados com conhecimento de soquetes da Web estão na posição ideal para criar a próxima geração de aplicativos da Web em tempo real que atendam às crescentes demandas dos usuários por uma interação instantânea e perfeita Obrigado por ficarem comigo até o final desta palestra Eu realmente espero que você tenha tirado proveito disso. E os websockets serão, a partir de agora um conceito que você entenderá completamente Estou ansioso para ver você na próxima lição. 15. HTTPs: Olá pessoal, e bem-vindos de volta ao curso HTTP. Nesta palestra, vamos discutir o protocolo HTTPS, o que ele faz melhor do que o HTTP, se devemos usá-lo e também entender em um básico e até mais nível básico e até mais avançado, como ele funciona começar, o Para começar, o protocolo e a sigla HTTPS o protocolo de transferência de hipertexto que vem de protegido É praticamente a mesma coisa que HTTP, mas este tem o S e a palavra-chave secure anexados a ele. E, abordando o principal problema de segurança com o protocolo HTTP sobre o qual falamos até é que as informações que fluem do servidor para o cliente não são criptografadas de forma alguma. Além disso, o problema com essa falta de criptografia é que ela pode ser vista por qualquer pessoa exatamente na forma que tem. que significa que, é claro, ele pode ser facilmente roubado, mas também substituído por um hacker ou um terceiro que esteja ajudando nessa troca, ele pode intervir O protocolo HTTPS corrige isso usando um certificado SSL. A sigla SSL vem de Security Sockets Layer, e esse certificado ajuda a criar uma conexão criptografada segura entre o servidor web e o navegador do cliente Além disso, protege informações confidenciais de serem roubadas à medida que são transferidas entre o servidor e o navegador. Criptografar essas informações significa que elas são mapeadas para alguma outra forma que um terceiro ou invasor não consegue entender e, além disso, até mesmo vê-las, acessá-las ou roubá-las A diferença mais importante entre os protocolos HTTP e HTTPS é obviamente o certificado SSL. Na verdade, o HTTPS é basicamente um protocolo HTTP simples sobre o qual falamos até agora, com apenas uma camada de segurança adicional, o que é muito importante. No entanto, essa segurança adicional pode ser extremamente importante, especialmente para sites que armazenam informações confidenciais de seus usuários, como informações de cartão de crédito. Por exemplo, se você comprou algo em um site, talvez tenha visto isso ou apenas sua senha. Portanto, se você não vê um cadeado à esquerda do URL e está tentando acessar sua conta digitando sua senha ou tentando comprar algo com os detalhes do seu cartão de crédito. Você deve parar porque não é seguro e seus dados podem ser roubados de um invasor que está vendo esse processo Agora, o certificado SSL criptografa as informações, como eu disse, que os usuários fornecem ao site, o que basicamente significa que ele traduz os dados em Mesmo que alguém consiga roubar os dados estão sendo comunicados entre o servidor e o destinatário, não conseguiria entendê-los graças a essa criptografia que o certificado de célula S aplica a ele a essa criptografia que o certificado de célula S aplica a Além disso, além de aplicar essa camada extra, HTTPS também é protegido pelo protocolo TLS Agora, o protocolo e a sigla TLS vêm da segurança da camada de transporte E o que ele faz é ajudar a fornecer integridade de dados, o que ajuda a evitar que a transferência de dados seja modificada ou até mesmo corrompida. Outra coisa que ele faz é fornecer autenticação que prova aos usuários que eles estão realmente se comunicando com os sites reais Isso significa que, no final das contas, o terceiro não pode vir e alterar o conteúdo transmitido entre o cliente e o servidor. Isso é muito importante, os usuários podem identificar se um site está usando o protocolo HTTPS pelo endereço da web, pela primeira parte do endereço da web ou pela URL, como vimos na aula anterior, que é chamada de autoridade antes do início do nome principal Essa parte ali indica se o site está usando o protocolo HTTP ou HTTPS. Você deve apenas olhar sua URL e ver isso. Ou você também pode verificar o cadeado que está presente na parte esquerda do URL. Isso também dirá se você está acessando uma página protegida com HTTPS ou não. Agora, para fazer uma rápida recapitulação, a principal diferença entre o protocolo HTTP e o HTTPS é simplesmente a presença do certificado unnecess O HTTP não tem o certificado SSL e o HTTPS o tem Esse certificado de avaliador criptografa suas informações para que sua conexão seja protegida e as informações que você está transmitindo não possam ser roubadas ou modificadas por terceiros Foi sobre isso com o protocolo HTTPS. Dps é obviamente um protocolo preferido atualmente e quase sempre implementado em páginas da web Além disso, se você gosta desenvolvimento web e está tentando criar um site, sugiro que use esse protocolo mais seguro, especialmente se estiver tentando obter dados confidenciais dos usuários. Portanto, esse protocolo o tornará menos suscetível a um texto de eventuais hackers Muito obrigado por ficarem comigo até o final desta palestra Na próxima, daremos uma olhada algumas ferramentas muito úteis com as quais podemos ver as solicitações HTTP reais feitas de nossa máquina para outros servidores da web e capturá-las para ver quais informações são outros servidores da web e capturá-las para ver quais informações enviadas ou recebidas e assim por diante. Então, essa será a parte mais concreta e acionável do nosso tutorial aqui Então, se isso parece interessante, estou ansioso para ver vocês lá. 16. Endereços IP: Olá pessoal, e bem-vindos de volta ao curso HTTP. Nesta palestra, aprenderemos mais sobre o que é um endereço AP e como podemos usá-lo em nossos esforços com o O endereço AP significa um endereço de protocolo da Internet. É daí que vem o NP, Internet Protocol. O que é, é um rótulo numérico como 1902121. Esse rótulo representa sua conexão com uma rede de computadores que usa o Protocolo da Internet para comunicação, por isso é um endereço de Protocolo da Internet. Um endereço AP tem duas funções principais. A função de identificação da interface de rede e a função de endereçamento de localização. Em breve, falaremos mais amplamente sobre essas duas funções em termos mais fáceis de entender Mas enquanto existirem as versões do Protocolo da Internet, havia duas versões principais do Protocolo da Internet. A primeira, quando foi iniciada, é chamada de versão quatro, também conhecida como IPV quatro, e define um endereço AP como um número de 32 bits No entanto, devido ao crescimento da Internet e ao esgotamento dos quatro endereços IPV disponíveis, uma nova versão do IP Porque você não pode pensar que um número de 32 bits possa armazenar apenas alguns endereços. partir dessa necessidade, criamos o IPV six, que é a versão seis do protocolo da Internet Esses endereços IP estão usando 128 bits em vez de apenas 32. Agora, outra menção notável aqui é que o espaço de endereço IP é gerenciado globalmente pela autoridade de números atribuídos à Internet. Esses endereços IP são gravados e exibidos em anotações legíveis por humanos Como exemplo que eu dei, um endereço IP válido é 1902120 Os administradores de rede da Internet atribuem números, autoridade ou, em geral, atribuem um endereço IP a cada dispositivo conectado a uma rede Essas atribuições podem ser estáticas ou dinâmicas. O que isso significa é que eles podem ser fixos ou permanentes. Tudo depende das práticas de rede em que você está e dos recursos de software da máquina na qual você está trabalhando. Agora, abordando a finalidade do endereço AP e o porquê, é importante que você saiba coisas sobre ele. Isso ocorre porque um endereço IP identifica o host. E você pode ver isso se digitar o endereço IP do Google. Alguns sites estão dispostos a mostrar seu próprio endereço IP e também mostram exatamente onde você está em um mapa global. Obviamente, se você não estiver usando uma VPN ou algo parecido, isso redirecionará seu acesso à Internet para algum outro O endereço IP identifica o host ou mais especificamente, sua interface de rede com ele Como eu disse, ele fornece a localização do host na rede. E dessa forma, ele tem a capacidade de estabelecer um caminho para esse hospedeiro. Sua linha foi caracterizada como um nome que indica o que vemos. Um endereço indica onde está e a rota indica como chegar lá. O cabeçalho de cada pacote IP contém o endereço AP do host de envio e o do host de destino, que veremos em breve, quando examinaremos algumas solicitações de HDTP feitas no algumas solicitações de HDTP Fiddler ou no Wireshark Como conclusão, em essência, os endereços IP são o identificador que permite que as informações sejam enviadas entre dispositivos em uma rede. Eles contêm informações de localização e também tornam os dispositivos acessíveis para comunicação. A Internet precisa de uma forma de diferenciar entre diferentes computadores, roteadores e sites É exatamente isso que o endereço IP fornece, uma maneira de fazer isso e uma parte essencial de como a Internet funciona hoje em dia. Eu realmente espero que vocês tenham tirado algo útil dessa palestra. Muito obrigado por ficar comigo até o final, e estou ansioso para ver você na próxima 17. Solicitações de HTTP na prática: Ajudem pessoal e bem-vindos de volta ao tutorial HTTP. Nesta primeira palestra da seção, temos mais experiência prática com ferramentas reais que nos ajudarão não apenas entender melhor todo o protocolo HTTP e suas solicitações, mas também talvez até mesmo a fazer algumas coisas sobre elas Não apenas entendê-los para ver exatamente como uma solicitação é feita, as informações sobre ela na prática e até mesmo ver se há algo de errado com ela ou algo parecido. Nesta primeira palestra, vamos dar uma olhada em um software desenvolvido por uma empresa chamada Alaric É chamado Fiddler. Você pode se perguntar agora que serve essa ferramenta Fiddler Bem, essa é uma entidade proxy, sobre a qual, se você se lembra, falamos na palestra anterior A entidade proxy era uma entidade que estava entre a entidade do servidor e a entidade do cliente. E executou a solicitação real entre essas duas entidades principais por meio dele. E era transparente ou não com base na manipulação ou não dos dados da solicitação isso que o fiddler é, é um servidor proxy que mostrará, é claro, todo o tráfego da web em sua máquina local com a qual você o instalou em vários servidores web Por exemplo, se você entrar um site de mídia social a partir do seu computador, ele mostrará a solicitação que você já fez e você poderá vê-la com muito mais detalhes. Agora, o motivo pelo qual essa ferramenta é usada é para depurar o tráfego da web para aplicativos em navegadores E o que isso significa é, por exemplo, digamos que você criou o site e queria ver exatamente como sua solicitação ao site é feita. Se algo der errado com isso, você gostaria de examinar essa solicitação específica para ver o que há de errado com ela. E os dois realmente ajudarão você a fazer isso, mostrando muitas informações sobre cada solicitação específica feita de suas máquinas locais ou da máquina cliente para o servidor web. Agora, para baixar o software Fiddler, você pode acessar o Google, exatamente Fiddler, é claro, a versão básica é uma versão ainda mais básica e você também pode Mas ao obtê-lo, você deve digitar seu e-mail e, em seguida, selecionar o país em que você está e algumas coisas assim. Faça o download direto. Além disso, se você estiver no ambiente Apple ou Linux, você deve usar um desses botões de download. Mas estamos no Windows. Nas máquinas, escolhi o download padrão, ele apenas baixará um executável para você Isso seria bem simples e, depois de abri-lo, você pode ver que ele mostra apenas um contrato de licença Depois de clicar em Concordo, ele começará a instalá-lo em sua máquina local. Depois que a instalação estiver concluída, teremos uma visão geral dessa ferramenta para ver exatamente como as solicitações são mostradas e como podemos avançar na compreensão desse protocolo usando essa ferramenta. Depois de abri-lo, você pode fazer login com sua conta. Farei isso em apenas um momento e entrarei em contato com você assim que estiver no aplicativo. Está bem? Então, estou de volta depois de criar minha conta no Fiddler Depois de abrirmos o aplicativo, você verá que isso o guiará por um rápido tutorial. Em primeiro lugar, basicamente digo que ele não rastreará seu tráfego HTTPS pois ele é criptografado e não rastreado Mas você pode clicar no ícone de deterate para mudar isso Em seguida, ele mostrará toda a parte esquerda da ferramenta em que tráfego aparecerá e cada uma dessas linhas significará algo. Obviamente, o resultado está no código de status da solicitação sobre a qual falamos. O, o método como em get post e assim por diante. O processo, o IP remoto e, em seguida, o URL a seguir Depois de clicar em uma solicitação da parte esquerda aqui, você verá a resposta real e o conteúdo real da resposta em HTML, Json e outras formas em que ela pode ser mostrada aqui, você pode capturar o tráfego ao vivo ou não Então, é claro, podemos ter algumas sessões seguras. Depois de concluir o tutorial, você pode clicar no botão Eu e, em seguida, clicar no sinal vermelho de exclamação após o símbolo da URL E quando você clicar nele, ele também começará a rastrear as solicitações e respostas reais que estão passando por HTTPS. Porque você concederá esse certificado a ele para permitir que ele veja as solicitações feitas com segurança Por exemplo, abri meu Chrome aqui e abri minha conta no Instagram. Você pode ver que, depois de fazer isso, recebi muitas fotos aqui do meu feed do Instagram e, claro, algumas outras para acessar tokens que recebi por meio da autenticação no Facebook, no Instagram e assim por diante Assim, você pode ver também na primeira parte, não apenas o número da solicitação que foi feita com base no tipo, mas também o tipo de resposta que você recebeu. Por exemplo, essas são as imagens que você viu. Essa é uma resposta de Jason. Esses são métodos de postagem usados para criar coisas e assim por diante. Obviamente, você pode agrupá-los por resultados. Em primeiro lugar, se você quiser que as solicitações de resultados sejam aceitáveis, você pode fazer isso e, em seguida, elas realmente aumentarão. Por exemplo, aqui está o último que teve uma resposta 43. Então, temos o método se você quiser primeiro obter os tipos de solicitações e assim por diante. Em seguida, os processos do IP e também os tamanhos dos corpos ou comentários. Você também pode encomendá-los com isso. Agora, ao receber essa solicitação, você pode ver algumas coisas. Aqui temos uma prévia. Podemos ver isso no formato bruto. Você pode ver o corpo da solicitação e também os cabeçalhos que vieram com ela Aqui, é claro, temos algumas informações bastante gerais sobre isso, como o último dia em que foi modificado, o tipo de conexão, a duração do conteúdo e assim por diante. Novamente, a resposta também é mostrada aqui. Você pode salvar a sessão. Portanto, uma sessão é quando você começa a ver algumas solicitações , pode iniciar a sessão e tem algumas solicitações , finalizá-la e salvá-la. No que diz respeito à sessão, você também pode remover todos eles se quiser começar do zero. Como eu disse, a sessão de segurança pode compartilhar a sessão. Na verdade, você pode fazer alguns filtros avançados, como cabeçalhos de resposta e cabeçalhos de solicitação, para ver apenas algumas das solicitações que ocorrem Aqui você tem algumas notificações, seu perfil, as configurações. Isso é basicamente algo básico, mas pode ser muito útil, como eu disse, se você quiser criar um site ou talvez apenas expor algumas APIs ao seu serviço web e quiser ver como serão as solicitações feitas para obter a API de endpoints Essa é a ferramenta que você gostaria de usar. Claro, também existe outra ferramenta chamada Wireshark, e vamos examinar essa ferramenta a seguir e dar uma olhada mais profunda nela, mas, por enquanto, isso foi tudo com a Agradeço muito a vocês por ficarem comigo até o final desta palestra 18. Wireshark: Olá pessoal e bem-vindos de volta a este tutorial HTTP. Nesta última palestra, examinaremos mais profundamente outra ferramenta que aprimorará nosso conhecimento sobre o protocolo HTTP e as solicitações feitas com mais exatidão Isso também é chamado de Wireshark, como você pode ver na tela E é outro aplicativo muito semelhante ao último aplicativo que estava nessa área, e falamos sobre isso na palestra anterior, que foi o Fiddler Esse aplicativo também permite que você capture e investigue detalhadamente o tráfego de rede que você tem, seja, as solicitações feitas e as respostas recebidas entre o cliente, ou seja, o navegador da Web que você tem na máquina local em que o instalou e o servidor da Web para o qual você faz solicitações. E isso pode variar de acordo com o site que você acessa e o que você recebeu dele. Novamente, aqui podemos simplesmente pesquisar no Google Wireshark. É uma ferramenta gratuita e, quando estiver no Wireshark.org, você pode basicamente começar baixando-a começar Estou no Windows, vou instalar esse 64 bits também. Mas, novamente, eles também têm o se você usa um produto Apple, pode escolher isso para instalar. E assim que você clicar nele, como você pode ver, ele também fará o download do executável Então, eu também explicarei a configuração para você. Como é bastante simples, você pode simplesmente instalá-lo com tudo que o Caes Também pediremos que você associe todas essas extensões de arquivos diferentes ao Wireshark Vamos instalá-lo na unidade C. Não vou usar esse MP 1102, nem o USB, só não vou clicar nele Você realmente não precisa dessas ferramentas para apenas observar essas solicitações feitas e ver exatamente quais são os detalhes sobre elas. Como você pode ver aqui, o wireshark está sendo instalado. E eu entrarei em contato com vocês assim que a ferramenta for instalada e aberta na minha máquina para que possamos ver o que está acontecendo e como podemos usá-la, pessoal. Depois de abrir o wireshark, você pode selecionar a conexão que Eu escolhi a Internet para então, como você pode ver na tela, eu simplesmente parei por enquanto. Assim, você terá uma visão melhor que exatamente está acontecendo aqui. Mas é claro que o sinal do tubarão aqui é usado para iniciar a captura real da solicitação E este é o botão de parada na primeira parte superior aqui. Ao contrário do fogo, que tinha essas partes na vertical, este as tem na horizontal. Mas aqui você pode ver a solicitação real que ocorreu, o protocolo, a origem nos IPs de destino que pode ser muito útil se você quiser, por exemplo, ver uma solicitação que saiu do seu computador na rede. Você pode classificar a partir da fonte e ela mostrará os IPs em ordem ordenada. Então, é claro, a duração da resposta, o número delas. Se você quiser entrar em mais detalhes sobre a solicitação real, clique nela. Em seguida, ele mostrará na segunda e na terceira janelas reais mais informações sobre essa solicitação específica. Na terceira janela, ele mostrará a resposta real em linguagem decimal No segundo, ele mostrará como a solicitação é o corpo e uma resposta real em XML ou em qualquer formato que ela tenha. Além disso, as respostas e todas essas coisas boas aparecerão no segundo tipo de janela. Isso também é sobre o Wireshark. Não há muita diferença entre esses dois. Normalmente trabalho com o Wireshark da forma como o descobri, mais simples e direto do que mais simples e direto Mas os dois são bons o suficiente nesse trabalho. Assim, você pode escolher com qual delas se sente mais confortável com base no que viu nessas duas palestras Foi sobre isso com o pessoal do tutorial HTTP. Espero que você tenha aprendido algo e agora entenda melhor o protocolo HTTP, quais são as solicitações, quais são as entidades em um fluxo de trabalho de cliente-servidor agora entenda melhor o protocolo HTTP, quais são as solicitações, quais são as entidades em um fluxo de trabalho de cliente-servidor e todas as outras coisas sobre as quais falamos, códigos de status e métodos de solicitação HTP Se você tiver alguma dúvida sobre o protocolo HTTP, pode entrar em contato comigo e me enviar uma mensagem E vou me certificar de responder a vocês no menor tempo possível Mas, mais uma vez, muito obrigado por ficar comigo até o final do tutorial e assisti-lo, e espero vê-lo em outros tutoriais que criarei