1 O processo de uma solicitação de rede
Normalmente, exibimos uma página correspondente após uma solicitação da Web de menos de um segundo após inserir um URL no navegador e pressionar Enter. Na verdade, esse processo completo de solicitação da Web precisa passar por várias etapas:
O primeiro passo: o DNS resolve o endereço IP;
A segunda etapa: handshake de três vias TCP para estabelecer uma conexão;
Etapa 3: se for HTTPS, também é necessário um certificado de assinatura de verificação de handshake TLS;
Etapa 4: O cliente inicia uma solicitação HTTP
Etapa 5: o servidor responde às solicitações HTTP
Etapa 6: o navegador do cliente recebe o conteúdo e analisa html, css, js
Etapa 7: o navegador renderiza a página
2 processo IP de resolução de DNS
O DNS (Sistema de Nomes de Domínio) é chamado "Sistema de Nomes de Domínio". É um sistema de nomeação de computadores e serviços de rede organizado em uma hierarquia de domínio. É usado em redes TCP / IP. O serviço que fornece é usado para converter nomes de host e nomes de domínio. Trabalhe para o endereço IP. O processo é provavelmente assim:
A primeira etapa: chame o método correspondente através da classe java.net.InetAddress para verificar se o seu próprio cache existe, porque existe um processamento de DNS de cache de segundo nível no sistema Android.
Etapa 2: Se java.net.InetAddress não estiver armazenado em cache, verifique o cache DNS da máquina virtual para determinar se ela existe.Este é o cache de segundo nível.
Etapa 3: Se o endereço IP não puder ser resolvido após o armazenamento em cache, ele lerá a resolução no arquivo Hosts local.
Etapa 4: Se a resolução do nome de domínio não puder ser concluída na máquina local através do descrito acima, o sistema poderá solicitar apenas o sistema de serviço de resolução de nome de domínio na área local para análise, como a rede do campus.Se a rede do operador estiver conectada, o servidor de resolução de nome de domínio local será o local Operadores regionais para prestar serviços.
Etapa 5: se o servidor de resolução de nome de domínio local não tiver concluído a resolução, o servidor de resolução de nome de domínio local iniciará uma solicitação de resolução para o servidor de nome de domínio raiz. O servidor de nomes de domínio raiz retorna os endereços de domínio de nível superior genérico (gTLD) do domínio pesquisado, como: .com, .cn, .org, .edu etc.
Etapa 6: o servidor de resolução de nome de domínio local inicia uma solicitação ao servidor de gTLD.
Etapa 7: o servidor gTLD recebe a solicitação iniciada pelo servidor de nome de domínio local e localiza o servidor de nomes correspondente ao nome de domínio, de acordo com o nome de domínio que precisa ser resolvido.Normalmente, esse servidor de servidor de nomes é o servidor de nome que você registrou. O servidor do provedor de serviços de nome de domínio assumirá a tarefa de resolução de nomes de domínio.
Etapa 8: o servidor de nomes procura o endereço IP correspondente ao nome do domínio e retorna o endereço IP juntamente com o tempo de vida útil (Time To Live, TTL) para o servidor de nome de domínio local.
Etapa 9: o servidor de nome de domínio local armazena em cache os resultados resolvidos e o tempo de cache é controlado pelo tempo TTL.
Etapa 10: Retornar o resultado da resolução para o usuário.O sistema do usuário armazenará em cache o endereço IP e o tempo de cache será controlado pelo TTL. Neste ponto, o processo de análise termina.
Handshake de três vias TCP 3
O chamado handshake de três vias (Handshake de três vias) refere-se a como rastrear a quantidade de dados enviados cada vez para negociar para sincronizar a transmissão e a recepção do segmento de dados, o número de confirmações de dados e a transmissão e recepção de dados determinadas de acordo com a quantidade de dados recebidos Quando o contato será cancelado e uma conexão virtual será estabelecida após a conclusão.
O primeiro handshake: o cliente envia o segmento de solicitação de conexão, define SYN (Sincronizar números de sequência, número de sequência de sincronização) como 1 e define um seq = x, (Número de sequência, número de sequência) (x é determinado pelo sistema operacional Gerado por uma determinada regra, pode ser considerado como um número aleatório) para enviar esta mensagem ( SYN = 1 seq = x ) para o servidor. Nesse momento, o cliente entra no estado enviado sincronizado SYN_SEND , aguardando a confirmação do servidor.
Segundo handshake: depois que o servidor receber o segmento de solicitação SYN do cliente, se concordar em estabelecer uma conexão, precisará confirmar (Confirmação Numbe, caractere de confirmação) para esse segmento SYN, definir ack = x + 1 e, ao mesmo tempo, Envie também informações de solicitação de SYN, defina SYN como 1, seq = y. O servidor coloca todas as informações acima em um segmento de mensagem ( ACK = 1 confirmação = x + 1, SYN = 1 seq = y ) e as envia ao cliente ao mesmo tempo.Neste momento, o servidor entra no estado recebido síncrono SYN_RECV ;
O terceiro handshake: o cliente recebe o segmento SYN + ACK do servidor e envia uma confirmação de confirmação ao servidor, ou seja, uma confirmação ACK, define ack como y + 1 e envia um segmento ACK ao servidor ( ACK = 1 ack = y + 1 ), o cliente e o servidor entram no estado conectado ESTABELECIDO e completam três handshake.
Exemplo de milheto:
O primeiro aperto de mão: o cliente disse: Olá, olá, você pode me ouvir?
O segundo aperto de mão: O servidor disse: Olá, eu posso ouvir, você pode me ouvir?
O terceiro aperto de mão: o cliente disse: eu também posso ouvi-lo falando
Depois de confirmar que eles se ouviram através do diálogo, eles podem começar a conversar um com o outro ...
Por que usar três apertos de mão em vez de dois?
Agora, suponha que ocorra uma situação anormal durante o estabelecimento da conexão: o primeiro segmento de solicitação de conexão enviado pelo cliente não é perdido, mas permanece em alguns nós da rede por um longo tempo, de modo que é adiado para um determinado ponto após o lançamento da conexão. Levou apenas um tempo para chegar ao servidor. Originalmente, este era um segmento que deveria ter sido invalidado, mas o servidor recebeu essa solicitação de conexão inválida, não sabia que era uma solicitação inválida e, por engano, considerou que o cliente havia emitido uma nova solicitação de conexão. Um segmento de confirmação é enviado ao cliente e uma conexão é estabelecida entre eles. Assumimos que o handshake de três vias não seja usado; o relacionamento de conexão será estabelecido no momento.
Como o cliente não enviou uma solicitação para estabelecer uma conexão, ele não ignorará a confirmação do servidor e não enviará dados para o servidor, mas o servidor acha que a conexão foi estabelecida e aguarda o cliente enviar dados. O servidor desperdiçará recursos.
Portanto, o aperto de mão de três vias pode efetivamente impedir o fenômeno acima. Quando o terceiro handshake, o cliente não enviará uma confirmação para a confirmação do servidor, porque o servidor não recebe a confirmação, entenderá que o cliente realmente não solicitou o estabelecimento de uma conexão.
4 quatro ondas
O oposto do handshake de três vias é a onda de quatro vias (Four-Way Wavehand), o que significa que, quando uma conexão TCP é desconectada, a waver pode ser o cliente ou o servidor.Um total de 4 pacotes são enviados entre eles para confirmar a desconexão da conexão Aberto, o processo é o seguinte:
A primeira onda de mãos: O host A envia um segmento de mensagem desconectado, define FIN (Número de conclusão) como 1 e define um seq = u (u é o último número de bytes transmitido no último +1 ) para esta mensagem ( FIN = 1 seq = u ) Após o envio, o host A entra no estado de espera de término 1 FIN_WAIT_1 .
Segunda onda: o host B recebe o segmento FIN do host A e precisa aceitar esse segmento, defina ack = u + 1 e traga o número de sequência seq = v, o host B enviará o item acima Todas as informações são enviadas de volta ao host A em um segmento de mensagem ( ACK = 1 ack = u + 1 seq = v ). Nesse momento, o host B entra no estado de espera de desligamento CLOSE_WAIT . Quando o host A recebe a solicitação de confirmação do host B , o host A entra no estado de espera de término 2 FIN_WAIT_2 , aguardando o host B enviar uma mensagem de liberação da conexão , nesse momento o host B também pode enviar dados normais para o host A.
A terceira onda: se o Host B enviou todos os últimos dados e não há mais dados a enviar, ele enviará uma mensagem de liberação da conexão ao Host A, defina FIN como 1 e selecione seq = we ACK para confirmar. Defina ack = u + 1 para enviar a mensagem de liberação ( FIN = 1 seq = w, ACK = 1 ack = u + 1 ). Nesse momento, o host B entra no estado de confirmação final LAST_ACK .
Quarta onda: Após receber a mensagem de liberação, o host A precisa enviar uma confirmação final, defina ack como w + 1 e traga o número de sequência seq = u + 1 e envie o segmento de mensagem para o host B ( ACK = 1 ack = w + 1 seq = u + 1 ), neste momento, o host A entra no estado de espera de tempo TIME_WAIT ; nesse momento, a conexão TCP não é desconectada imediatamente, mas após 2 * MSL (a vida útil mais longa do segmento, geralmente 2) Minutos, para garantir que novas conexões com o mesmo endereço e porta não sejam recriadas durante esse período), o bloco de controle de transmissão é revogado e o estado FECHADO é inserido . Durante esse período, quando o host B receber a confirmação final do host A , ele entrará imediatamente no estado fechado CLOSED e revogará o bloco de controle de transmissão . Neste ponto, as quatro mãos acenadas do TCP estão completas.
Exemplo de milheto:
A primeira onda: A disse: eu terminei, vou calar a boca e não quero dizer nada.
A segunda onda: B disse: eu recebi e sabia que você tinha terminado, mas ainda tenho algo a dizer.
Depois de B também incomodou as palavras ...
Acenou pela terceira vez: B disse: terminei de falar e tenho que calar a boca.
A quarta onda: A disse: eu recebi e sabia que você tinha terminado, mas A. não estava à vontade.Depois de esperar um período de tempo (2 ciclos máximos de vida da mensagem), eu realmente não ouvi nenhuma palavra e sabia que deveria sair; B recebeu A e sabia que havia terminado de falar e foi embora imediatamente.
Por que há um aperto de mão de três vias quando conectado, mas quatro ondas quando fechado?
TCP é um modo full-duplex, o que significa que, quando o host A envia um segmento FIN , ele informa ao host B que meus dados foram enviados e que nenhum outro dado é enviado. Neste caso, o hospedeiro B retorna ACK período de tempo pacote, disse que já sabe o host A nenhum dado é enviado, mas o código não é primariamente B não tem dados para enviar ah, então quando o host B ou anfitriões podem enviar dados para A , e quando o anfitrião Quando B também enviou o segmento de mensagem FIN , desta vez significa que o host B não tem dados para enviar e informará ao host A que não tenho dados para enviar. Então, um ao outro interromperá essa conexão TCP .
5 TLS handshake
Ideia básica do protocolo SSL / TLS
A primeira etapa: o cliente solicita a chave pública do servidor;
Etapa 2: O servidor retorna um certificado confiável contendo a chave pública;
A terceira etapa: o cliente verifica o certificado para determinar a chave pública e usa a chave pública para usar criptografia assimétrica para negociar em particular.Como gerar uma chave de conversa (a criptografia assimétrica tem baixa eficiência, mas alta segurança, portanto a chave pública do servidor é usada apenas para criptografia " chave de sessão " em si) ;
A quarta etapa: o servidor recebe o resultado descriptografado após a negociação e a comunicação entre as duas partes usa um método de criptografia simétrica para gerar uma chave de conversa (a criptografia simétrica tem alta eficiência e reduz o tempo de comunicação) .
O processo detalhado do handshake de quatro direções
O primeiro handshake: o cliente envia uma solicitação de comunicação criptografada ( ClientHello ) ao servidor , fornecendo as seguintes informações:
Ofereça suporte à versão mais alta do protocolo, como: TLS1.2
Lista de conjuntos de criptografia suportados: algoritmo de autenticação de identidade, algoritmo de troca de chaves, algoritmo de criptografia simétrica e resumo da mensagem
Lista de algoritmos de compactação suportados métodos de compactação para transmissão subsequente de compactação de informações
Número aleatório random_C, usado para gerar a chave de conversa posteriormente
Extensões de campo de extensão, parâmetros de protocolo e algoritmo de suporte e outras informações auxiliares, etc.
O segundo handshake: o servidor responde à solicitação após receber a solicitação do cliente ( server_hello + server_certificate + sever_hello_done ) (se o servidor também exigir que o cliente forneça um certificado, como o escudo U no banco on-line, ele conterá mais um Itens):
server_hello : O servidor retorna o resultado das informações negociadas, incluindo as seguintes informações:
Versão do protocolo
Confirme para usar o conjunto de criptografia
Método de compressão de escolha
Número aleatório random_S, usado para gerar chaves de conversa posteriormente
Extensões de campo de extensão, parâmetros de protocolo e algoritmo de suporte e outras informações auxiliares, etc.
server_certificates : Certificados configurados no lado do servidor com chaves públicas
server_hello_done : notifica o cliente que as informações foram enviadas
O terceiro handshake: Após receber a resposta do servidor, o cliente verificará o certificado retornado. Se o certificado não for emitido por uma autoridade confiável, ou o nome de domínio no certificado for inconsistente com o nome de domínio real, ou o certificado tiver sido revogado ou o certificado expirar, um aviso será exibido ao visitante para escolher se deseja continuar a comunicação. Se não houver nenhum problema com o certificado, o cliente continuará enviando informações ao servidor ( client_key_exchange + change_cipher_spec + encrypted_handshake_message (Finished) ) (se o servidor exigir que o cliente também retire o certificado, como o escudo U em serviços bancários na Internet, envie o certificado e seu Informações relacionadas):
client_key_exchange : calcule um número aleatório pre_master e use a chave pública extraída do certificado para criptografar a transmissão usando criptografia assimétrica
(O cliente dominou o método de cálculo da chave de conversa no momento: enc_key = Fuc (random_C, random_S, pre_master))
change_cipher_spec : indica que as comunicações subsequentes usarão o algoritmo de chave e criptografia negociado por ambas as partes para comunicação criptografada
encrypted_handshake_message : notifique o final do handshake, combine com o valor de hash de todo o conteúdo da comunicação anterior e outras informações relevantes para gerar um dado para o servidor verificar
O quarto handshake: o servidor recebe o pre_master criptografado passado pelo cliente e descriptografa-o com a chave privada, além de calcular a chave de conversa por enc_key = Fuc (random_C, random_S, pre_master) e, em seguida, retorna a mensagem ao cliente ( change_cipher_spec + encrypted_handshake_message (Concluído) ):
change_cipher_spec : indica que as comunicações subsequentes usarão o algoritmo de chave e criptografia negociado por ambas as partes para comunicação criptografada
encrypted_handshake_message : notifique o final do handshake, combine com o valor de hash de todo o conteúdo da comunicação anterior e outras informações relevantes para gerar um dado, usado para verificação
Nesse ponto, toda a fase do handshake do TLS terminou. Em seguida, a comunicação entre o cliente e o servidor é o protocolo HTTP comum, mas o conteúdo é criptografado usando a chave da sessão.
