{"subject_id":"3a3cc48d009981a2bb0cde0f223c6a71","topico":"HTTP/2 × HTTP/3 (QUIC); gRPC; WebSockets","stems":["Acerca de paradigmas de programação orientada a objetos, julgue os itens subsequentes.","A respeito da arquitetura de sistemas web, julgue os itens que se seguem.","Julgue os itens a seguir, em relação aos serviços de mensageria, webhooks e JSON.","Acerca de desenvolvimento web e mobile, julgue os itens seguintes.","No que diz respeito à arquitetura de sistemas web, julgue os itens a seguir.","Julgue os itens que se seguem, relativamente a desenvolvimento de sistemas web.","Julgue os itens seguintes, a respeito do HTTPS e das técnicas de proteção que envolvem o uso do protocolo TLS."],"questions":[{"id":"327f7814fe22","number":18,"stem":0,"statement":"WebSocket é um protocolo que estabelece um canal de comunicação bidirecional simultânea entre um cliente e um servidor.","answer":"C","source":{"slug":"TCE_RS_25","ano":2025},"explanation":{"verdict_reason":"É a definição do protocolo: após um handshake iniciado como requisição HTTP com Upgrade e respondido com o código 101, a conexão TCP passa a ser um canal full-duplex, em que cliente e servidor enviam mensagens a qualquer momento, sem que um precise esperar a vez do outro ou provocar o envio do outro por nova requisição.","distortion_type":"correto","distorted_span":null,"corrected_statement":null,"concept":"canal full-duplex após o handshake HTTP","citation":"RFC 6455","trap_note":"Separe half-duplex de full-duplex: no primeiro os lados se alternam, no segundo transmitem ao mesmo tempo. WebSocket é full-duplex; o HTTP tradicional é requisição-resposta, com o servidor mudo enquanto não é chamado."}},{"id":"f227dafa5cd5","number":87,"stem":1,"statement":"O gRPC oferece suporte a streaming bidirecional, permitindo que cliente e servidor troquem múltiplas mensagens de forma assíncrona na mesma conexão, por meio da multiplexação do HTTP/2.","answer":"C","source":{"slug":"SUSEP_25","ano":2025},"explanation":{"verdict_reason":"O gRPC define quatro modos de chamada: unário, streaming do cliente, streaming do servidor e streaming bidirecional. No bidirecional, os dois lados enviam sequências de mensagens de forma independente e assíncrona, cada fluxo com o seu próprio controle, tudo sobre a mesma conexão graças à multiplexação de fluxos do HTTP/2.","distortion_type":"correto","distorted_span":null,"corrected_statement":null,"concept":"streaming bidirecional do gRPC sobre multiplexação","citation":null,"trap_note":"É a multiplexação do HTTP/2 que sustenta o streaming do gRPC — sem ela, cada fluxo exigiria conexão própria. Guarde o encadeamento: multiplexação permite fluxos concorrentes, fluxos concorrentes permitem streaming bidirecional."}},{"id":"a418072e01d3","number":89,"stem":2,"statement":"Provedores de API reversa devem usar WebSockets para enviar notificações em tempo real, dispensando filas ou mecanismos de retentativa com sistemas externos.","answer":"E","source":{"slug":"TJ_PA_25_SERVIDOR","ano":2025},"explanation":{"verdict_reason":"WebSocket é uma das opções de notificação em tempo real, ao lado de webhook por HTTP e de server-sent events, e nenhuma delas é obrigatória. Sobretudo, nenhuma delas dispensa fila e retentativa: o canal pode cair, o consumidor pode estar indisponível e a entrega precisa ser garantida por buffer, confirmação e nova tentativa com recuo exponencial. O WebSocket resolve o transporte, não a confiabilidade da entrega.","distortion_type":"generalizacao","distorted_span":"dispensando filas ou mecanismos de retentativa com sistemas externos","corrected_statement":"Provedores de API reversa podem usar WebSockets para enviar notificações em tempo real, sem que isso dispense filas ou mecanismos de retentativa com sistemas externos.","concept":"transporte em tempo real não garante entrega","citation":null,"trap_note":"Dispensar, eliminar a necessidade de e tornar desnecessário são o formato preferido da banca para transformar um recurso real em solução total. Pergunte o que acontece quando o canal cai: se a resposta exige fila ou retentativa, a dispensa é falsa."}},{"id":"f007a165011b","number":100,"stem":3,"statement":"A utilização de WebSocket está limitada a aplicações web, pois deve ser implementado em browsers e servidores web.","answer":"E","source":{"slug":"TCE_AC_24","ano":2024},"explanation":{"verdict_reason":"O WebSocket é um protocolo de aplicação sobre TCP, e qualquer cliente capaz de abrir uma conexão TCP e completar o handshake pode usá-lo: aplicativo móvel nativo, serviço de retaguarda, dispositivo de IoT, cliente de linha de comando, jogo em desktop. O navegador oferece a API padronizada e é o caso mais visível, mas não é requisito do protocolo.","distortion_type":"generalizacao","distorted_span":"está limitada a aplicações web, pois deve ser implementado em browsers e servidores web","corrected_statement":"A utilização de WebSocket não está limitada a aplicações web, pois qualquer cliente e qualquer servidor que implementem o protocolo sobre TCP podem utilizá-lo.","concept":"WebSocket é protocolo sobre TCP, não recurso de navegador","citation":"RFC 6455","trap_note":"Não confunda o protocolo com a API do navegador que o expõe. A mesma confusão aparece com HTTP, com TLS e com o próprio JSON: existir uma implementação famosa no browser não restringe o protocolo a ele."}},{"id":"aded88f98fd8","number":72,"stem":4,"statement":"No WebSocket, utiliza-se um fluxo de bytes no lugar de um fluxo de mensagens para fornecer comunicações completas em uma conexão TCP.","answer":"E","source":{"slug":"BCB_24","ano":2023},"explanation":{"verdict_reason":"É o contrário: o WebSocket existe justamente para substituir o fluxo de bytes do TCP por um fluxo de mensagens. O TCP entrega uma corrente contínua de octetos, sem fronteira entre um envio e outro, e por isso a aplicação teria de delimitar as mensagens por conta própria; o enquadramento do WebSocket faz essa delimitação, transportando mensagens discretas, de texto ou binárias, sobre a mesma conexão TCP.","distortion_type":"inversao","distorted_span":"utiliza-se um fluxo de bytes no lugar de um fluxo de mensagens","corrected_statement":"No WebSocket, utiliza-se um fluxo de mensagens no lugar de um fluxo de bytes para fornecer comunicações completas em uma conexão TCP.","concept":"WebSocket enquadra mensagens sobre o fluxo de bytes do TCP","citation":"RFC 6455","trap_note":"Sempre que dois termos aparecerem na fórmula X no lugar de Y, escreva a troca ao contrário e veja qual das duas versões você consegue justificar. Aqui a regra de fundo é fixa: TCP entrega bytes, WebSocket entrega mensagens."}},{"id":"5cd87433d2a8","number":74,"stem":4,"statement":"No HTTP/2, são utilizadas conexões persistentes para o atendimento a diversas solicitações em sequência, ao passo que, no HTTP/1, as conexões atendem a várias solicitações simultâneas.","answer":"E","source":{"slug":"BCB_24","ano":2023},"explanation":{"verdict_reason":"As duas metades estão trocadas. É o HTTP/1.1 que, com conexões persistentes, atende várias solicitações em sequência sobre a mesma conexão, e mesmo o pipelining manteve a exigência de resposta na ordem, com bloqueio de cabeça de fila. Quem atende solicitações simultâneas é o HTTP/2, por meio da multiplexação de fluxos independentes dentro de uma única conexão.","distortion_type":"inversao","distorted_span":"são utilizadas conexões persistentes para o atendimento a diversas solicitações em sequência","corrected_statement":"No HTTP/2, é utilizada a multiplexação para o atendimento a diversas solicitações simultâneas, ao passo que, no HTTP/1, as conexões persistentes atendem a várias solicitações em sequência.","concept":"HTTP/1.1 é sequencial; HTTP/2 é multiplexado","citation":"RFC 9113","trap_note":"Guarde a linha do tempo por palavra-chave: HTTP/1.0 abre uma conexão por requisição, HTTP/1.1 traz conexão persistente e requisição em sequência, HTTP/2 traz multiplexação e cabeçalho comprimido em binário, HTTP/3 troca o TCP pelo QUIC sobre UDP. Item que arraste a característica de uma versão para a vizinha é o formato mais comum aqui."}},{"id":"62c571586638","number":75,"stem":4,"statement":"No gRPC, o protocolo de transporte utilizado é o HTTP/2.","answer":"C","source":{"slug":"BCB_24","ano":2023},"explanation":{"verdict_reason":"O gRPC foi desenhado sobre o HTTP/2, e é dele que herda a multiplexação de fluxos, a compressão de cabeçalhos e o transporte binário que permitem chamadas simultâneas e streaming em uma única conexão. Sobre esse transporte, a serialização da mensagem fica a cargo do Protocol Buffers e o contrato é declarado em um arquivo .proto.","distortion_type":"correto","distorted_span":null,"corrected_statement":null,"concept":"gRPC sobre HTTP/2 com Protocol Buffers","citation":null,"trap_note":"Separe as duas camadas do gRPC: HTTP/2 é o transporte, Protocol Buffers é o formato de serialização. A banca troca uma pela outra, atribuindo ao gRPC transporte HTTP/1.1 ou serialização JSON."}},{"id":"d5507bac2c09","number":77,"stem":5,"statement":"O WebSocket permite o desenvolvimento de diversas aplicações em tempo real como, por exemplo, aplicações de bate-papo, jogos online com múltiplos jogadores e mapas interativos.","answer":"C","source":{"slug":"TCE_PA_16","ano":2016},"explanation":{"verdict_reason":"São exatamente os casos de uso para os quais o protocolo foi criado: aplicações em que o servidor precisa empurrar dado ao cliente sem ser solicitado e com latência baixa. Bate-papo, jogo multijogador, mapa e cotação ao vivo, painel de monitoramento e edição colaborativa entram todos nessa categoria, porque no HTTP tradicional só restaria consultar o servidor repetidamente.","distortion_type":"correto","distorted_span":null,"corrected_statement":null,"concept":"casos de uso de comunicação bidirecional persistente","citation":null,"trap_note":"O critério para reconhecer caso de uso de WebSocket é a iniciativa do servidor combinada à frequência: se o servidor precisa falar primeiro e com frequência, é WebSocket; se o cliente é que pergunta de vez em quando, requisição HTTP comum basta."}},{"id":"4ca1fd058446","number":76,"stem":6,"statement":"No HTTP, a técnica geral do controle de fluxo garante que não haja interferência entre as conexões independentes. Entretanto essa técnica foi abandonada na versão 2 do HTTP, que criou o conceito de WINDOW_UPDATE frame.","answer":"E","source":{"slug":"TJDFT_15_SERVIDOR","ano":2015},"explanation":{"verdict_reason":"O WINDOW_UPDATE é o quadro que implementa o controle de fluxo do HTTP/2 — logo, longe de abandonar a técnica, a versão 2 foi a que a introduziu na camada de aplicação, com janela por fluxo e por conexão. Ela é necessária precisamente porque a multiplexação coloca vários fluxos na mesma conexão TCP e é preciso impedir que um deles consuma sozinho a capacidade do receptor.","distortion_type":"inversao","distorted_span":"essa técnica foi abandonada na versão 2 do HTTP","corrected_statement":"No HTTP, a técnica geral do controle de fluxo garante que não haja interferência entre os fluxos independentes. Essa técnica foi introduzida na versão 2 do HTTP, que criou o conceito de WINDOW_UPDATE frame.","concept":"controle de fluxo por janela é recurso do HTTP/2","citation":"RFC 9113, seção 5.2","trap_note":"Quando a própria frase cita o mecanismo que a versão criou, o verbo é a distorção. Abandonar, remover, descontinuar e depreciar aplicados a algo cujo nome técnico o item acabou de mencionar são sinal quase certo de inversão."}}]}