Loading
Nota de Estudos
Study Reminders
Support
Text Version

Flow Flow, URL & Protocolo HTTP

Set your study reminders

We will email you at these times to remind you to study.
  • Monday

    -

    7am

    +

    Tuesday

    -

    7am

    +

    Wednesday

    -

    7am

    +

    Thursday

    -

    7am

    +

    Friday

    -

    7am

    +

    Saturday

    -

    7am

    +

    Sunday

    -

    7am

    +

Olá, bem-vindo ao desenvolvimento moderno de aplicativos. Nas sessões anteriores, discutimos CLI, e apps GUI. E vimos como evoluir esses apps em um aplicativo da web usando um programa CGI. Para começar, analisaremos como fizemos a evolução e obteremos uma ideia clara das mudanças no fluxo de controle e na arquitetura interna dos aplicativos. Depois disso, vamos seguir em frente para começarpensando em URLs como programadores em vez de como usuários. Embora, todos nós estamos familiarizadas com URLs como objetos que são usados diariamente para várias aplicações web.
Geralmente pensamos nele como usuários em vez de como programadores e como você verá, bastam umpoucos detalhes técnicos quando você pensa neles como objetos relevantes para a programação. Nossopróximo passo será olhar para o protocolo HTTP e estudar as ferramentas que nos permitem inspecionar o que éocorrerá quando HTTP for usado. Por último, estudaremos web browser Devtools que sãoferramentas fundamentais para qualquer programador web.Durante esta sessão, estaremos fazendo várias demos e você deverá ter os seguintes programasprontos: você pode usar uma distribuição como XAMPP que tem coisas como Apache e MySQL e assimforth, que você já pode ter instalado para a sessão anterior. Se não, você pode tentar fazerque agora. Os outros programas que precisamos serão aqueles como SOCAT, NSLOOKUP e cURL.Estes estão disponíveis na maioria do Linux ou no Windows, certamente via Cygwin e em alguns casosversões nativas podem estar disponíveis.
Nesta sessão, vamos passar por cima de ideias fundamentais que subjazem programa web. Essasideias constituem uma massa de detalhes e levará algum tempo para você obter essas ideiasorganizadas juntas, mas se ater a ela, porque essas ideias subjazem muito do que está por vir. Comodesenvolvemos nosso app, você vai começar a ver como essas ideias desempenham a sua parte em diferentes partes do aplicativo. Para ajudá-lo a organizar isso, quero enfatizar a grande visão de imagem que vocêdeve manter em mente, e depois caçá-las essas ideias em diferentes partes da grande imagem à medida que vamos adiante.
O tema principal é que existem três componentes-chave cujas interações definem a infraestrutura da web, e como resultado, definem o comportamento do aplicativo também. Estes três componentes são:o navegador, o protocolo HTTP e o servidor. Vejamos como essas três coisas funcionam com cadaoutras.
Então, à direita estão todos os elementos e as interações que vamos estudar nesta sessão.Todos nós sabemos qual é a ideia geral:
• Temos uma URL, tal como nptel.ac.in e é dada ao navegador como URL• O navegador de alguma forma figura onde o servidor está localizado. É aqui que o navegadorinterage com o sistema de nomes de domínio que converte o nome do host em um endereço IP.• Uma vez que ele tem o endereço IP, ele estabelece uma conexão TCP e ele executa uma solicitação HTTP.Então, algo incomum está acontecendo aqui, a conexão está em um protocolo e umprotocolo diferente roda em cima. O que exatamente acontece aqui é o que vamos figurarfora nesta sessão. De modo que, até o final desta sessão, este diagrama será significativo paravocê.• Depois disso temos solicitação e resposta HTTP e há bastante poucos detalhes intrincadosque você tem que dar certo em ordem para que esses comportamentos de solicitação e resposta ajudem a colocar
juntos a web de uma maneira escalável. Como acontece com toda a programação, embora o grande quadro sejarazoavelmente claro de corte, é nos detalhes que as coisas ficam interessantes.(Consulte o Tempo de Slide: 04:35)
Na primeira parte desta sessão, revisaremos como alteramos o app CLI para o app GUI parao app web CGI, observando os detalhes do que mudanças fizemos para a arquitetura interna comobem como o fluxo de controle entre partes diferentes do sistema.(Consulte o Tempo do slide: 04:59)
Então, vamos começar com o app CLI padrão. Aqui, temos três partes da CLI:• Usuário• Programa• Banco de dados
E como todos nós sabemos, é uma coisa bem direta o usuário colocar no comando, argumentos ouentrada padrão, o programa faz seu cálculo, surge com a resposta e imprime-a. Elesente-se exatamente como uma chamada de função para nós e realmente a arquitetura interna do código também é muitosemelhante.
É simplesmente uma série de chamadas de função que executam cálculos e salvam dados. No máximo se houvercomandos múltiplos, então nós vamos loop sobre eles. Também, notamos que, no que diz respeito à linguagem shell, a CLI aparece exatamente como uma chamada de função. Nós programadores podemos pensardele como uma chamada de função, mas os usuários normais pensarão nele como um comando.
 
O próximo passo em nossa discussão é o programa GUI. No programa GUI, fizemos bastante poucas mudanças. Em particular, o programa teve que ser dividido em uma parte de visualização, que mostra qual parteo usuário vê, e o modelo onde a computação está acontecendo. Essas duas partes estão ligadas por
manipuladores que, na maioria dos casos como já vimos, são simples referências que contam partes da visualizaçãoquais partes do modelo a alterar.O fluxo de controle aqui, como vimos, é agora deve ser familiar para nós. Ao executar o app,o app mostra a visualização; há um loop de eventos, que olha as prensas de botão então você coleta os dados do campoe executa qualquer que comando o botão lhe tenha pedido para então você atualizar o modelo eentão finalmente, atualizar a visualização e mostrar quaisquer que os resultados possam ser.(Consulte o Tempo de Slide: 06:58)
Internamente, a arquitetura muda conforme discutimos abaixo. O que acontece é que o programase divide em partes bem distintas. Uma parte é responsável inteiramente pelos looks e a outra parao cálculo e as duas partes estão vinculadas usando manipuladores mais o loop de eventos que leva ojob de manter o programa indo, atendendo aos pedidos dos usuários e respondendo até que o usuáriodecida finalizar o programa. A partir desses dois programas construímos o programa web.
Então, vamos comparar o que ele parece em relação a um programa GUI, assim como há uma visão e um modeloem um programa web. Há os dois componentes; o navegador e o servidor para um programa web. Desta vez, em vez de manipuladores que ligam a visualização e o modelo, o protocolo HTTPconecta o navegador e o servidor. A analogia entre visualização e modelo em um único aplicativoversus a distinção de servidor do navegador é razoavelmente precisa para aplicações simples.Mas como já falamos anteriormente, na sessão GUI, a analogia pode ficar bastante complicada já quea complexidade dos programas de browser e servidor aumenta, mas isso é para um tempo posterior. Paracomeçar com, esta analogia é muito útil na compreensão do que está acontecendo aqui.
 
O próximo passo que, nós vamos é olhar para a arquitetura interna de como é que nós construímos o programa do servidor, e no nosso caso, conseguimos o que é essencialmente um híbrido. Pegamos o programa de linha de comandos, repuramos e deixamos o servidor executado. Então, deixe o ’ s passar pela sequência do queacontece aqui. O navegador apresenta a UI inicial que é escrita em HTML e atende a ações do usuárioe registra dados do usuário.
O navegador então converte os dados do usuário de uma forma que se ajusta aos requisitos do protocolo HTTP, o servidorentão converte dados de protocolo em informações de ambiente para o programa CGI bin. Se vocêcomparar o CGI bin versus o programa da linha de comando, o que notamos é que, eles são por egrandes os mesmos, exceto que a maneira como eles se conectam ao ambiente em que elesexecutam, difere.Então, em vez de obter entrada de apenas a linha de comando, o programa CGI obtém sua entrada a partir das variáveis de ambiente, bem como padrão no e depois dele é feito imprime seu resultado para a saída padrãoque é, por sua vez, lida pelo servidor. O servidor então o formata em um formulário que funciona parao protocolo HTTP e envia para o navegador. O conteúdo deve ser tal que o navegador podeinterpretá-lo e exibir a resposta ficando pronta para o próximo ciclo.
O que é novela além da divisão na parte de modelo e de visualização é que o navegador e o servidore o programa de banco de dados podem existir em máquinas separadas. Então, é como se houvesse um tipo de eficienteacontecendo a partir da arquitetura da GUI para a arquitetura do programa web e alguns aspectosdo programa de linha de comandos podem ser preservados nesta visão.
Então, o que temos é um programa que é basicamente uma espécie de um híbrido como CLI, no que diz respeito à parte de cálculo do, é essencialmente o mesmo ciclo dado colocar a produção de produção como a GUI; a experiência do usuário como um serviço continuamente disponível. Mas, por termos introduzido um modeloe uma visualização, você consegue alguns aspectos de uma experiência contínua do usuário mesmo que o programa subjacenteseja muito parecido com um programa de linha de comando.
 
Nosso próximo programa, no entanto, será muito mais GUI como. Nossa embalagem inicial CLI nos deuapenas a separação de visualização do modelo mas ao contrário de um programa GUI, não há interações baseadas em botão.Mas antes de seguirmos para aquele programa, primeiro-iremos estudar o protocolo HTTP que conecta o navegadore o servidor e veremos o que ele faz para os programas que escrevemos até agora.
Deixe-nos resumir o que vimos do fluxo de interação até agora:• CLI têm uma função como flow sem acesso de memória através de chamadas exceto comoarmazenadas no banco de dados.• Em uma GUI, você mantém algum histórico na memória e obtemos a importante nova habilidade paraa interação do usuário a depender de ‘ como o usuário interagiu até agora ’.• Nosso programa híbrido proporciona interação contínua sem qualquer retenção de memória.Porque toda a retenção acontece ou deve acontecer no lado do servidor mas a forma como o programa CGIé escrito, ele é essencialmente apenas uma reembalagem do programa de linha de comandos. Na outra mão, algo importante já foi alcançado, pois movemos nosso programa paraa infraestrutura web. Vamos achar muito fácil depois, mesmo que a gente fosse manter o programa apenascomo o CGI bin para adicionar mais facilidades como vários usuários e a capacidade de usuários distribuídos compartilharãoeste programa, como todos sabemos, de apps web.Então, além da GUI como o comportamento, esta é a outra coisa importante que a infraestrutura webnos dá. E em programas posteriores, veremos que é possível recuperar a capacidade da GUI de reter o históricousando cookies e outros indicadores de sessão com maneiras de lembrar dados de sessão no lado do servidorque é distinto dos dados computacionais.Mas essas são coisas que vamos chegar mais tarde. Por enquanto, seguiremos em frente para estudar URLs eprotocolo HTTP. Então, essa é a próxima parte da nossa sessão.
 
Nesta parte, vamos dar uma olhada nos componentes da URL, especialmente as strings de consulta e outros aspectoscomo portas e host local. São detalhes que iniciarão o acasalamento quando começarmos a pensarde URLs como uma espécie de interface para um aplicativo web.
Então, embora estamos familiarizados com eles a partir do uso diário, precisamos entendê-los juntos comocomponentizentes de interfaces mais os participantes do protocolo HTTP. Um protocolo é um conjunto de regras que
está implícita em quaisquer duas entidades que comuniquem se são pessoas ou computadores e os detalhesde como isso a comunicação acontece importa em toda a programação web, também.
Uma URL é o acrônimo para localizador de recursos universal. É, como se diz, um localizador um endereço para um recurso. A estrutura de uma URL é do tipo protocolo colon slash host name colon porta slashcaminho. Esta estrutura possui duas partes importantes; uma é o hostname e a porta que identifica o servidor, o caminho que identifica o recurso dentro do servidor e o protocolo, que para a maioria dosusos comuns acaba por ser HTTP ou HTTPS.Por exemplo: em http://nptel.ac.in/noc, o protocolo é HTTP. O hostname énptel.ac.in e o path is noc. Podemos pensar nisso como um localizador de recursos mas para o navegador, ele funciona como um conjunto de instruções. Quando o navegador é solicitado a buscar uma URL, ele levaas seguintes etapas: primeiro consulta o servidor e o nome ‘ nptel.ac.in ’ que é entãolocalizado em forma de (o que é chamado de) endereço IP. Algumas delas você pode já estar familiarizadascom.
Mas, eu vou repetir essas coisas em detalhes para aqueles que não são. O mapeamento a partir deste nomepara o endereço IP é feito por algo chamado DNS (Domain Name Server), que nósiremos brevemente dar uma olhada mais tarde. Em seguida, a próxima parte da instrução para o navegador é que ter
localizado o servidor, o navegador deverá utilizar o protocolo HTTP para falar com ele. Como parte de conversar como servidor, ele envia o caminho Não para o servidor e, em seguida, o servidor assume.
O navegador agora ele apenas aguarda que o servidor retorne o conteúdo da URL e aqui está o queo servidor faz em seguida, ele recebe a URL e a interpreta como a seguinte sequência de instruções: primeiro, verifique se o servidor deve agir como o servidor chamado nptel.ac.in. Isto éfeito por meio de configuração que é conhecida pelo servidor. O próximo passo é levar o recursono path noc, que ele sabe como localizar novamente por meio de várias configurações.Então leia o conteúdo e envie-o de volta para o navegador. O recurso aqui é justamente o que podemospensar como um saco de bytes. Geralmente ele é um documento HTML, mas também como sabemos, PDF e vídeoe vários outros formatos de dados também estão disponíveis como recursos. O componente de caminho da URL étambém chamado de URL de solicitação. Vamos resumir essas terminologias técnicas como recursolocalizador, hostname e protocolo, etc., mais tarde, mas aquelas são mais familiares para nós.Como programadores, é a nova terminologia incomum como solicitar URL que se torna importante emdiscutindo exatamente exatamente como programamos a web. URLs como nptel.ac.in/noc são o tipo de URL mais simples do. Há muitas URLs mais complicadas que teremos que dar uma olhadaem um minuto. Então, vamos começar.
O próximo tipo de URL mais comum é o que é chamado de URL com uma string de consulta. Tente oa seguir: vá a qualquer página no Wikipedia, diga “ en.wikipedia.org/MadhavaofSangamagrama ” e depois na parte superior direita, você verá uma caixa de pesquisa. Agora digiteURL na caixa de busca e bata enter. E, em seguida, veja a URL no navegador, você verá uma URL complicada do formulário mostrado abaixo. E agora vamos tentar identificar as partes da URL.Nesse caso, veremos que o caminho ou o que é chamado de URL de solicitação, é esta parte que eu souindo para destacar é //w/index.php. A parte após o ponto de interrogação é chamada de string de consultae no exemplo atual ele tem coisas como busca e título e assim por diante. E nós vamos atéo fim desses personagens especiais. Assim, você pode esta parte depois que o ponto de interrogação é chamado de string de consulta. Você pode pensar nisso como uma sintaxe diferente para peças de função.Os nomes de parâmetros da função são coisas como título de pesquisa, e a parte após cada ‘ igual ’é o valor do parâmetro. Você pode digitar diretamente URLs, como en wikipedia.org, etc. e colocar um termo de buscadiretamente no navegador. E terá o mesmo efeito que fazer as buscas a partir da caixa,mesmo sem alguns dos parâmetros estranhos que vêm da caixa. Então, vamos tentar isso para fora.
Ok, deixe-nos experimentar o caso que acabamos de ver. Aqui estamos na página da Wikipédia paraMadhava de Sangamagrama. E aqui temos a caixa de busca com URL escrita nele. (VideoStarts: 20:07) Se atingirmos enter aqui agora, podemos ver a URL com uma string de consulta que contém
coisas como busca e título e busca de texto completo, que nos diz que perguntamos à Wikipédia, parabasicamente analisamos tudo com a palavra URL nele, principalmente aquelas que contêm o título dea URL dada.E como eu disse, podemos agora ir para a string de consulta e remover a parte URL e colocar HTTP. Eagora você verá que aqui estamos recebendo tudo sobre HTTP, por exemplo, hipertextoprotocolo de transferência, HTTPS, etcetera, etc. são um comportamento um pouco diferente acontece se vocêremover os parâmetros estranhos e tentar apenas HTTP. Agora, porque há uma página exclusivadesejada. Vamos direto para a página HTTP e notamos que a URL, apesar de digitamos como no formulário de string de consulta, foi alterada em uma URL de aparência normal. (Vídeo Ends: 21:15) Vemos maiscomportamentos interessantes uma vez que você começa a se tornar consciente de como o mecanismo de busca de URL.
Por exemplo, se você procurar a string de espaço de consulta de frase na caixa de pesquisa, você verá quea URL do navegador se transforma em uma string mais string. Por exemplo, no caso Wikipédia, temossearch equivale a consulta mais sequência seguida pelos outros parâmetros de pesquisa. Por várias razões,caracteres como espaços em branco são transformados em sequências codificadas especiais. Uma razão para isso é que as sequênciasde caracteres não espaciais são muitas vezes mais fáceis de trabalhar com em programas.Mas há outras razões históricas por que certas codificações existem. Há muitos detalhes incomunscomo esse que importa na programação web. Como um programador web você costuma aprender estes como você vai
em mas você tem que estar ciente de que eles existem. Uma razão pela qual existem regras tão estranhas é quea web cresceu um pouco como um organismo biológico por 25 anos ou mais. E como resultado, tem uma aglomeraçãode todo tipo de regras peculiadas que foram criadas quando pessoas diferentes fizeram mudançaspara a web por diferentes motivos. E a web que vemos hoje é na verdade um resultado de todas essasmudanças que aconteceram através de muitos anos.
Então, como lidar com essas raízes peculiadas? A maioria de tais raízes foram criadas, como eu disse, porrazões que eram boas quando foram inventadas, mas agora elas simplesmente foram absorvidas emo ecossistema. De vez em quando, eu vou apontar esses tipos de coisas para você e você devetambém manter a sua própria lista de coisas que você vai notar. Para mim depois de tantos anos, muitas dessasas coisas se tornaram a segunda natureza.Mas para você que está encontrando-as pela primeira vez fazendo uma lista é talvez a melhor coisaque você pode fazer. No final, eles se tornarão familiares para você. E você será capaz de consultar sitescomo Stackoverflow e Wikipédia conforme necessário para idiossincrasias que as pessoas costumavam saber em umponto no tempo falou sobre isso. E por sorte para nós, eles estão disponíveis para nós aprenderem com. Em tudo issoexperimentação é essencial.
Você deve construir pequenos websites de teste em sua própria máquina, onde você tenta as regras eas entenda em detalhes. Por sorte, ao contrário dos cientistas ou de outras pessoas que precisam trabalhar comcoisas físicas, nossos experimentos não precisam de muitos recursos. Eles só precisam de tempo e paciência.
O próximo componente a pensar sobre é uma porta URL. Além do nome do servidor para URL podeter uma porta explícita no formulário, digamos 8080. Esta URL não existe de fato, mas o siteexample.org existe. O Example.org foi um site criado nos primeiros dias da web, para o único objetivode ser, como diz, um exemplo. E em um nome curto como example.org, a porta 80 érealmente assumida.Você pode pausar este vídeo agora e ir visitar example.org para ver o que ele diz. O número da portaporque é comum para a maioria das URLs quando é 80 nunca é, não é mencionado pelo navegador.Você pode ter notado que os navegadores hoje em dia até mesmo escondem protocolos como HTTP, embora em umavez eles nunca tenham usado para fazer coisas como esta. Então, o que é um número de porta? O número da porta para um servidorestá associado a um determinado serviço.Por exemplo:• o protocolo HTTP usa a porta 80.
• HTTPS usa 443.• FTP usa 20 e 2.
Se o endereço IP de um servidor for como um número de telefone da instituição, o número da porta é como a extensãonúmero para o escritório de alguém naquela instituição e o endereço completo para uma pessoa no casodo escritório são ambas partes. Da mesma forma, o endereço completo para um serviço é o nome do servidorseguido pelo nome da porta.Quando você executa seu próprio servidor web para exemplos de prática, muitas vezes é útil ter mais deum servidor web rodando em diferentes portas como 8080, 8000, 8001 ... etc. Os números de porta abaixo de1024 são resultado para muitas finalidades. Por isso, as portas do site de prática muitas vezes são relacionadas por razões históricasvocê pode usar qualquer nome que desejar, qualquer número que desejar e não faz diferença. Por isso, vejamoscomo ele se parece a executar vários serviços de host local em sua máquina.
Como vimos a partir da sessão anterior, servidores web e máquinas de desenvolvimento podem serabordados usando o hostname especial localhost. Para o servidor web local, podemos usarhttp://localhost, ou https://localhost. Geralmente, hoje em dia um servidor web comoapache será configurado para apresentar ambos terminais HTTP e HTTPS. E o endereço IP também irátrabalhar em vez do hostname.
Por exemplo, para o host local você pode usar o “ 127.0.0.1 ”. E no servidor web em sua máquina, você pode tentar iniciar o apache em portas diferentes. Para fazer isso você tem que ser capaz de alterara configuração para apache ou qualquer outro servidor web que você utilizar. Para qualquer que seja o servidor web que vocêuse, procure na web com uma consulta, como como executar apache na porta 8080. E geralmente a primeira respostavai dizer exatamente o que mudar na configuração.
Alright, agora que vimos bem alguns detalhes sobre URLs, vamos resumi-los. URLs sãoendereços de recursos, onde um recurso é um conjunto de dados de algum tempo. Geralmente os dados em um recursoestão em formato HTML, mas outros como PDF, JavaScript, JPG, ... etc. são comuns. A URL consiste emde um protocolo, o nome do host, um número de porta, um caminho, que também é chamado de URL de solicitação epossivelmente uma string de consultaUma URL pode incluir caracteres especiais como guia de espaço, ponto de interrogação de barra, etc. emmaneiras diferentes. Uma string de consulta é como uma chamada de função. Ele possui nomes de parâmetros e valores que sãoseparados por caracteres iguais. Mas a porta ajuda uma única máquina a oferecer vários serviços. Esta terminologiaé tão comum que nós estaremos tendo exames e designações que garantem que vocêaprenda bem esta terminologia.
Certo, então agora nós somos feitos com URLs. E o nosso próximo passo será olhar para detalhes dos protocolos.