{"id":15167,"date":"2026-11-06T11:22:25","date_gmt":"2026-11-06T08:22:25","guid":{"rendered":"https:\/\/vasexperts.com\/?p=15167"},"modified":"2026-11-06T12:47:52","modified_gmt":"2026-11-06T09:47:52","slug":"inside-gtpcproxy","status":"publish","type":"post","link":"https:\/\/vasexperts.com\/br\/blog\/mobile-networks\/inside-gtpcproxy\/","title":{"rendered":"GTPCProxy por dentro: 348 mil Modify Bearer por segundo e sess\u00f5es que se mant\u00eam em caso de falha"},"content":{"rendered":"<a href=\"\/br\/blog\/mobile-networks\/any-vendors-pgw-no-core-network-replacement\/\">No artigo anterior, mostramos<\/a> o que o GTPCProxy \u00e9 capaz de fazer; agora vamos olhar por dentro, explicar como ele funciona e mostrar os resultados das medi\u00e7\u00f5es.\r\n \r\n<h2>N\u00facleo multithread sem estruturas compartilhadas<\/h2>\r\n \r\nA ideia principal \u00e9 que as threads de trabalho do proxy n\u00e3o atrapalham umas \u00e0s outras. Todas as sess\u00f5es do GTPCProxy s\u00e3o divididas em 1.024 parti\u00e7\u00f5es. Cada parti\u00e7\u00e3o fica vinculada a uma \u00fanica thread de trabalho, e uma thread atende muitas parti\u00e7\u00f5es.\r\n \r\nN\u00e3o h\u00e1 estruturas mut\u00e1veis compartilhadas entre v\u00e1rias threads. Por isso, as threads de trabalho n\u00e3o precisam coordenar o acesso aos dados, e cada nova thread acrescenta desempenho quase sem perdas. As medi\u00e7\u00f5es confirmam isso: com 50% da carga m\u00e1xima, n\u00e3o foi registrado nenhum bloqueio das threads de trabalho em um minuto.\r\n \r\nAs respostas dos gateways <a href=\"\/br\/products\/pgw\/\">PGW<\/a> e as mensagens de verifica\u00e7\u00e3o Echo, pelas quais o proxy sabe que o gateway est\u00e1 ativo, passam por uma fila separada, e n\u00e3o junto com as novas requisi\u00e7\u00f5es. Assim, mesmo no pico de carga, as respostas s\u00e3o processadas sem atraso e as verifica\u00e7\u00f5es cumprem o tempo previsto. O proxy n\u00e3o vai confundir um gateway saud\u00e1vel com um que falhou s\u00f3 porque ele pr\u00f3prio estava ocupado.\r\n \r\nSe ainda assim o proxy ficar sobrecarregado, ele atende as mensagens por prioridade. Primeiro v\u00eam as mensagens das sess\u00f5es j\u00e1 ativas e, depois, as requisi\u00e7\u00f5es de novas conex\u00f5es. Dessa forma, os assinantes que j\u00e1 est\u00e3o na rede n\u00e3o s\u00e3o prejudicados por um pico de novos acessos.\r\n \r\n<h2>Escalabilidade vertical: resultados das medi\u00e7\u00f5es<\/h2>\r\n \r\nO proxy grava o estado de cada sess\u00e3o no Redis, um banco de dados r\u00e1pido que mant\u00e9m tudo na mem\u00f3ria RAM. Pode ser um \u00fanico servidor Redis ou um cluster em que cada n\u00f3 tem uma c\u00f3pia de reserva (r\u00e9plica).\r\n \r\n[important]\r\nRecomendamos este esquema\r\n \r\nCada thread de trabalho tem seu pr\u00f3prio canal de grava\u00e7\u00e3o no armazenamento e seu pr\u00f3prio n\u00f3 principal do Redis com r\u00e9plica.[\/important]\r\n \r\nNesse esquema, medimos quantas requisi\u00e7\u00f5es Modify Bearer o proxy processa de forma cont\u00ednua e sem erros. (Modify Bearer \u00e9 uma requisi\u00e7\u00e3o para alterar os par\u00e2metros de uma sess\u00e3o j\u00e1 existente do assinante):\r\n \r\n<table>\r\n<tbody>\r\n<tr><td><strong>Threads de trabalho<\/strong><\/td><td><strong>Modify Bearer por segundo<\/strong><\/td><td><strong>Crescimento em rela\u00e7\u00e3o \u00e0 linha anterior<\/strong><\/td><\/tr>\r\n<tr><td>1<\/td><td>87.812<\/td><td>\u2014<\/td><\/tr>\r\n<tr><td>2<\/td><td>180.625<\/td><td>2,06 vezes<\/td><\/tr>\r\n<tr><td>4<\/td><td>348.203<\/td><td>1,93 vez<\/td><\/tr>\r\n<\/tbody>\r\n<\/table>\r\n \r\nAo passar de uma para duas threads, a capacidade cresceu 2,06 vezes e, de duas para quatro, 1,93 vez. Quatro threads processam 348.203 requisi\u00e7\u00f5es por segundo. Isso \u00e9 0,9% menos do que quatro vezes a capacidade de uma \u00fanica thread (351.248).\r\n \r\nA lat\u00eancia foi medida com quatro threads e 90% da carga m\u00e1xima durante 30 minutos. Resultados:\r\n \r\n<ul>\r\n<li>p50: 0,10 ms,<\/li>\r\n<li>p99: 0,33 ms,<\/li>\r\n<li>p99,9: 0,56 ms.<\/li>\r\n<\/ul>\r\n \r\nEm 30 minutos, o proxy processou 563.776.014 transa\u00e7\u00f5es sem erros nem perdas. A mem\u00f3ria do processo cresceu 7,9 MB nesse per\u00edodo.\r\n \r\nPara redes pequenas, um Redis \u00fanico \u00e9 suficiente. Mas um Redis \u00fanico limita a capacidade. O proxy processa cerca de 105.000 requisi\u00e7\u00f5es Modify Bearer por segundo, e adicionar threads de trabalho n\u00e3o aumenta esse n\u00famero.\r\n \r\nSe o cluster Redis receber o mesmo n\u00famero de n\u00facleos de processador que um servidor \u00fanico, a capacidade do proxy cai cerca de 21\u201322%. J\u00e1 se cada n\u00f3 principal do cluster receber um n\u00facleo pr\u00f3prio, o desempenho cresce junto com o n\u00famero de threads de trabalho do proxy.\r\n \r\n<h2>Escalabilidade horizontal e redund\u00e2ncia via BGP<\/h2>\r\n \r\nPara que o proxy n\u00e3o se torne um ponto \u00fanico de falha, suas inst\u00e2ncias s\u00e3o reunidas em grupos. Cada grupo tem seu pr\u00f3prio endere\u00e7o IP (\/32), que as inst\u00e2ncias anunciam via <a href=\"\/br\/resources\/glossary\/bgp\/\">BGP<\/a> como acess\u00edvel por meio delas. A inst\u00e2ncia ativa anuncia o endere\u00e7o com a melhor rota, e a de reserva, com uma rota pior; por isso, o tr\u00e1fego vai para a ativa.\r\n \r\n<noscript><img decoding=\"async\" src=\"\/wp-content\/uploads\/2026\/11\/proxy_failover_redis_en.svg\" alt=\"proxy failover redis\" width=\"100%\" height=\"auto\" class=\"alignnone size-full wp-image-15179\"><\/noscript><img decoding=\"async\" src=\"\/wp-content\/uploads\/2026\/11\/proxy_failover_redis_en.svg\" alt=\"proxy failover redis\" width=\"100%\" height=\"auto\" class=\"alignnone size-full wp-image-15179 lazyload\" data-src=\"\/wp-content\/uploads\/2026\/11\/proxy_failover_redis_en.svg\">\r\nFigura: Os n\u00f3s vizinhos sempre se comunicam com um \u00fanico endere\u00e7o do grupo. O BGP decide qual inst\u00e2ncia responde no momento, e ambas leem as sess\u00f5es do mesmo Redis.\r\n \r\n<h3>Falha do proxy ou do servidor<\/h3>\r\n \r\nUm programa separado, o watchdog do BGP, monitora o processo do proxy. Ele verifica o processo uma vez por segundo. Se uma inst\u00e2ncia ficar com falha por mais de 10 segundos, o watchdog deixa de anunciar seu endere\u00e7o, e o tr\u00e1fego passa para a inst\u00e2ncia de reserva. A inst\u00e2ncia s\u00f3 pode voltar a operar depois de 30 segundos de funcionamento est\u00e1vel. Assim, uma inst\u00e2ncia inst\u00e1vel n\u00e3o fica sumindo e reaparecendo.\r\n \r\nSe o servidor inteiro ou a conex\u00e3o de rede dele falhar, entra em a\u00e7\u00e3o o mecanismo BFD. Ele detecta a queda em 900 ms, ap\u00f3s tr\u00eas verifica\u00e7\u00f5es perdidas com intervalo de 300 ms. Em seguida, o endere\u00e7o passa para a inst\u00e2ncia de reserva.\r\n \r\n<h3>Por que as sess\u00f5es n\u00e3o se perdem<\/h3>\r\n \r\nAo receber uma mensagem de uma sess\u00e3o, a inst\u00e2ncia de reserva l\u00ea o estado dessa sess\u00e3o no Redis pelo identificador do t\u00fanel (TEID).\r\n \r\nOs n\u00f3s vizinhos tamb\u00e9m n\u00e3o percebem a troca. Cada n\u00f3 informa aos vizinhos o seu contador de reinicializa\u00e7\u00f5es (Recovery). Se o contador mudar, o vizinho entende que o n\u00f3 foi reiniciado e apaga as sess\u00f5es associadas a ele. Todas as inst\u00e2ncias do grupo t\u00eam o mesmo valor de Recovery, por isso o SGW e o PGW n\u00e3o confundem a troca com uma reinicializa\u00e7\u00e3o, e as sess\u00f5es s\u00e3o mantidas.\r\n \r\n<h3>Falha do Redis<\/h3>\r\n \r\nQuando o n\u00f3 principal do Redis falha, suas fun\u00e7\u00f5es passam para a r\u00e9plica. Em uma s\u00e9rie de testes com carga de 6.020 requisi\u00e7\u00f5es de cria\u00e7\u00e3o de conex\u00e3o por segundo, a troca levou no m\u00e1ximo 2,03 s.\r\n \r\n<h3>Reinicializa\u00e7\u00e3o do proxy<\/h3>\r\n \r\nA reinicializa\u00e7\u00e3o do proxy n\u00e3o derruba as conex\u00f5es. O processo em si inicia em cerca de 0,135 s (mediana) e depois l\u00ea o estado das sess\u00f5es no Redis. Uma thread de trabalho travada \u00e9 reiniciada pelo timer watchdog da thread, um mecanismo separado, sem rela\u00e7\u00e3o com o watchdog do BGP. Em uma parada planejada, o proxy primeiro responde \u00e0s transa\u00e7\u00f5es em aberto.\r\n \r\n<h3>Como aumentar a capacidade<\/h3>\r\n \r\nPara atender mais assinantes, s\u00e3o adicionados novos grupos de proxy. Os endere\u00e7os deles s\u00e3o registrados no <a href=\"\/br\/resources\/glossary\/dns\/\">DNS<\/a> para os pontos de acesso (APNs) desejados. Todos os grupos trabalham com um \u00fanico cluster Redis.\r\n \r\n<table>\r\n<tbody>\r\n<tr><td><strong>Evento<\/strong><\/td><td><strong>Como \u00e9 detectado<\/strong><\/td><td><strong>Tempo<\/strong><\/td><\/tr>\r\n<tr><td>Falha do processo do proxy<\/td><td>Watchdog do BGP, verifica\u00e7\u00e3o uma vez por segundo<\/td><td>Endere\u00e7o retirado ap\u00f3s 10 s<\/td><\/tr>\r\n<tr><td>Falha do servidor ou da rede<\/td><td>BFD, intervalo de 300 ms, 3 perdas<\/td><td>900 ms<\/td><\/tr>\r\n<tr><td>Retorno da inst\u00e2ncia \u00e0 opera\u00e7\u00e3o<\/td><td>Watchdog do BGP<\/td><td>Ap\u00f3s 30 s de funcionamento est\u00e1vel<\/td><\/tr>\r\n<tr><td>Falha do n\u00f3 principal do Redis<\/td><td>Troca para a r\u00e9plica<\/td><td>At\u00e9 2,03 s<\/td><\/tr>\r\n<tr><td>Inicializa\u00e7\u00e3o do processo do proxy<\/td><td>\u2014<\/td><td>0,135 s (mediana)<\/td><\/tr>\r\n<\/tbody>\r\n<\/table>\r\n \r\n<h2>VNF ou CNF<\/h2>\r\n \r\nO proxy \u00e9 fornecido em duas vers\u00f5es. A redund\u00e2ncia funciona da mesma forma em ambas; a diferen\u00e7a est\u00e1 apenas em onde e como o proxy \u00e9 executado. A primeira vers\u00e3o \u00e9 uma m\u00e1quina virtual (VNF), e a segunda, cont\u00eaineres no Kubernetes (CNF).\r\n \r\n<table>\r\n<tbody>\r\n<tr><td><\/td><td><strong>M\u00e1quina virtual (VNF)<\/strong><\/td><td><strong>Kubernetes (CNF)<\/strong><\/td><\/tr>\r\n<tr><td>Plataforma<\/td><td>VEOS 8<\/td><td>Kubernetes<\/td><\/tr>\r\n<tr><td>A partir de que \u00e9 instalado<\/td><td>Dois pacotes RPM<\/td><td>Imagem criada a partir dos mesmos pacotes RPM e Helm chart<\/td><\/tr>\r\n<tr><td>Como \u00e9 executado<\/td><td>Servi\u00e7o do sistema (systemd)<\/td><td>StatefulSet, dois pods por grupo<\/td><\/tr>\r\n<tr><td>Quem anuncia o endere\u00e7o do grupo<\/td><td>FRR e o watchdog do BGP<\/td><td>FRR dentro do pod do proxy<\/td><\/tr>\r\n<tr><td>Recursos e configura\u00e7\u00f5es<\/td><td>\u2014<\/td><td>Fixa\u00e7\u00e3o est\u00e1tica de n\u00facleos de processador, configura\u00e7\u00e3o em ConfigMap e Secret<\/td><\/tr>\r\n<\/tbody>\r\n<\/table>\r\n \r\nA m\u00e1quina virtual \u00e9 atualizada com o comando dnf upgrade. Primeiro atualiza-se a inst\u00e2ncia de reserva e, depois, a ativa.\r\n \r\n<h2>Monitoramento e gerenciamento<\/h2>\r\n \r\nAs m\u00e9tricas do Prometheus abrangem mensagens, transa\u00e7\u00f5es, falhas e o estado dos PGWs e do armazenamento. Pain\u00e9is prontos do Grafana est\u00e3o integrados \u00e0 interface web do proxy. Nela tamb\u00e9m est\u00e3o dispon\u00edveis indicadores consolidados, tabelas de PGWs e pools, busca de sess\u00f5es e a ficha de cada sess\u00e3o, inclusive com par\u00e2metros de redes 2G\/3G (GTPv1).\r\n \r\nA interface \u00e9 r\u00e1pida mesmo com um grande n\u00famero de sess\u00f5es. Com 100.000 sess\u00f5es, a primeira p\u00e1gina da lista abre em 6,9 ms, e a busca pelo n\u00famero do chip SIM (IMSI) leva 0,4 ms.\r\n \r\nAs configura\u00e7\u00f5es s\u00e3o divididas em dois n\u00edveis.\r\n \r\n<ul>\r\n<li><strong>O arquivo gtpcp.yaml<\/strong> controla o pr\u00f3prio proxy. Nele s\u00e3o definidos os endere\u00e7os, o n\u00famero de threads, a vincula\u00e7\u00e3o aos n\u00facleos de processador e os par\u00e2metros do armazenamento.<\/li>\r\n<li><strong>O documento de roteamento<\/strong> controla o tratamento dos assinantes. Nele s\u00e3o definidos os pools de gateways, as regras de sele\u00e7\u00e3o, os pesos, as verifica\u00e7\u00f5es de estado dos PGWs e a substitui\u00e7\u00e3o de par\u00e2metros.<\/li>\r\n<\/ul>\r\n \r\nO documento de roteamento pode ser alterado sem reiniciar o proxy, por meio de formul\u00e1rios ou em formato de texto na interface web. Antes de aplic\u00e1-la, o proxy valida a nova vers\u00e3o. Se houver um erro, o proxy continua funcionando com a vers\u00e3o atual. Sempre \u00e9 poss\u00edvel voltar \u00e0 vers\u00e3o anterior. As permiss\u00f5es s\u00e3o divididas entre dois perfis: administrador e observador.\r\n \r\n<h2>Conclus\u00e3o<\/h2>\r\n \r\nO GTPCProxy aumenta o desempenho com novos n\u00facleos de processador e novos grupos de proxy, e armazena o estado das sess\u00f5es separadamente, no Redis. Por isso, a troca para a inst\u00e2ncia de reserva passa despercebida pelo SGW e pelo PGW, que n\u00e3o precisam fazer nada para isso.\r\n \r\nVoc\u00ea pode comprovar isso nos seus pr\u00f3prios SGWs, SGSNs e PGWs em laborat\u00f3rio. A VAS Experts fornece um pacote de testes com configura\u00e7\u00e3o, cen\u00e1rios e um conjunto de ferramentas para coleta de traces. Fale com a gente para planejar a valida\u00e7\u00e3o.\r\n\r\n[product id=\u201d11736\u2033 type=\u201ddark\u201d]","protected":false},"excerpt":{"rendered":"<p>Al\u00e9m da lista de fun\u00e7\u00f5es do GTPCProxy, o engenheiro de core e a equipe de opera\u00e7\u00e3o precisam entender como ele se comporta sob carga, na falha de um n\u00f3 e no turno da noite, quando n\u00e3o h\u00e1 um engenheiro de plant\u00e3o por perto.<\/p>\n","protected":false},"author":7,"featured_media":15192,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[102],"tags":[],"class_list":["post-15167","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-mobile-networks"],"yoast_head":"<!-- This site is optimized with the Yoast SEO plugin v24.2 - https:\/\/yoast.com\/wordpress\/plugins\/seo\/ -->\n<title>GTPCProxy por dentro: 348 mil Modify Bearer por segundo e sess\u00f5es que se mant\u00eam em caso de falha - VAS Experts<\/title>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\/\/schema.org\",\"@graph\":[{\"@type\":\"WebPage\",\"@id\":\"https:\/\/vasexperts.com\/blog\/mobile-networks\/inside-gtpcproxy\/\",\"url\":\"https:\/\/vasexperts.com\/blog\/mobile-networks\/inside-gtpcproxy\/\",\"name\":\"GTPCProxy: arquitetura, medi\u00e7\u00f5es e redund\u00e2ncia via BGP \u2014 VAS Experts\",\"isPartOf\":{\"@id\":\"https:\/\/vasexperts.com\/#website\"},\"primaryImageOfPage\":{\"@id\":\"https:\/\/vasexperts.com\/blog\/mobile-networks\/inside-gtpcproxy\/#primaryimage\"},\"image\":{\"@id\":\"https:\/\/vasexperts.com\/blog\/mobile-networks\/inside-gtpcproxy\/#primaryimage\"},\"thumbnailUrl\":\"\/wp-content\/uploads\/2026\/11\/banner-dlya-inzhenernogo-yadra.webp\",\"datePublished\":\"2026-11-06T08:22:25+00:00\",\"dateModified\":\"2026-11-06T09:47:52+00:00\",\"author\":{\"@id\":\"https:\/\/vasexperts.com\/#\/schema\/person\/e437e05016391b857d85b493b3173d59\"},\"description\":\"Mostramos como o GTPCProxy escala por n\u00facleos e grupos, armazena as sess\u00f5es no Redis e faz failover em 900 ms sem que o SGW e o PGW percebam\",\"breadcrumb\":{\"@id\":\"https:\/\/vasexperts.com\/blog\/mobile-networks\/inside-gtpcproxy\/#breadcrumb\"},\"inLanguage\":\"br-PT\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\/\/vasexperts.com\/blog\/mobile-networks\/inside-gtpcproxy\/\"]}]},{\"@type\":\"ImageObject\",\"inLanguage\":\"br-PT\",\"@id\":\"https:\/\/vasexperts.com\/blog\/mobile-networks\/inside-gtpcproxy\/#primaryimage\",\"url\":\"\/wp-content\/uploads\/2026\/11\/banner-dlya-inzhenernogo-yadra.webp\",\"contentUrl\":\"\/wp-content\/uploads\/2026\/11\/banner-dlya-inzhenernogo-yadra.webp\",\"width\":850,\"height\":354,\"caption\":\"Inside GTPCProxy\"},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\/\/vasexperts.com\/blog\/mobile-networks\/inside-gtpcproxy\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"\u0413\u043b\u0430\u0432\u043d\u0430\u044f \u0441\u0442\u0440\u0430\u043d\u0438\u0446\u0430\",\"item\":\"https:\/\/vasexperts.com\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"Inside GTPCProxy: 348,000 Modify Bearer Requests per Second and Sessions That Survive Failures\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\/\/vasexperts.com\/#website\",\"url\":\"https:\/\/vasexperts.com\/\",\"name\":\"VAS Experts\",\"description\":\"VAS Experts\",\"inLanguage\":\"br-PT\",\"publisher\":{\"@id\":\"https:\/\/vasexperts.com\/#organization\"}},{\"@type\":\"Person\",\"@id\":\"https:\/\/vasexperts.com\/#\/schema\/person\/e437e05016391b857d85b493b3173d59\",\"name\":\"Elena Rudich\",\"url\":\"https:\/\/vasexperts.com\/br\/blog\/author\/elena-rudich\/\"},{\"@type\":\"Organization\",\"@id\":\"https:\/\/vasexperts.com\/#organization\",\"name\":\"VAS Experts\",\"url\":\"https:\/\/vasexperts.com\/\",\"logo\":\"https:\/\/vasexperts.com\/assets\/img\/svg\/logo.svg\",\"sameAs\":[\"https:\/\/www.linkedin.com\/company\/vas-experts\",\"https:\/\/www.youtube.com\/channel\/UCGYfhhZvmE2XbrCyerzRbGA\"]}]}<\/script>\n<!-- \/ Yoast SEO plugin. -->","yoast_head_json":{"title":"GTPCProxy por dentro: 348 mil Modify Bearer por segundo e sess\u00f5es que se mant\u00eam em caso de falha - VAS Experts","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"WebPage","@id":"https:\/\/vasexperts.com\/blog\/mobile-networks\/inside-gtpcproxy\/","url":"https:\/\/vasexperts.com\/blog\/mobile-networks\/inside-gtpcproxy\/","name":"GTPCProxy: arquitetura, medi\u00e7\u00f5es e redund\u00e2ncia via BGP \u2014 VAS Experts","isPartOf":{"@id":"https:\/\/vasexperts.com\/#website"},"primaryImageOfPage":{"@id":"https:\/\/vasexperts.com\/blog\/mobile-networks\/inside-gtpcproxy\/#primaryimage"},"image":{"@id":"https:\/\/vasexperts.com\/blog\/mobile-networks\/inside-gtpcproxy\/#primaryimage"},"thumbnailUrl":"\/wp-content\/uploads\/2026\/11\/banner-dlya-inzhenernogo-yadra.webp","datePublished":"2026-11-06T08:22:25+00:00","dateModified":"2026-11-06T09:47:52+00:00","author":{"@id":"https:\/\/vasexperts.com\/#\/schema\/person\/e437e05016391b857d85b493b3173d59"},"description":"Mostramos como o GTPCProxy escala por n\u00facleos e grupos, armazena as sess\u00f5es no Redis e faz failover em 900 ms sem que o SGW e o PGW percebam","breadcrumb":{"@id":"https:\/\/vasexperts.com\/blog\/mobile-networks\/inside-gtpcproxy\/#breadcrumb"},"inLanguage":"br-PT","potentialAction":[{"@type":"ReadAction","target":["https:\/\/vasexperts.com\/blog\/mobile-networks\/inside-gtpcproxy\/"]}]},{"@type":"ImageObject","inLanguage":"br-PT","@id":"https:\/\/vasexperts.com\/blog\/mobile-networks\/inside-gtpcproxy\/#primaryimage","url":"\/wp-content\/uploads\/2026\/11\/banner-dlya-inzhenernogo-yadra.webp","contentUrl":"\/wp-content\/uploads\/2026\/11\/banner-dlya-inzhenernogo-yadra.webp","width":850,"height":354,"caption":"Inside GTPCProxy"},{"@type":"BreadcrumbList","@id":"https:\/\/vasexperts.com\/blog\/mobile-networks\/inside-gtpcproxy\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"\u0413\u043b\u0430\u0432\u043d\u0430\u044f \u0441\u0442\u0440\u0430\u043d\u0438\u0446\u0430","item":"https:\/\/vasexperts.com\/"},{"@type":"ListItem","position":2,"name":"Inside GTPCProxy: 348,000 Modify Bearer Requests per Second and Sessions That Survive Failures"}]},{"@type":"WebSite","@id":"https:\/\/vasexperts.com\/#website","url":"https:\/\/vasexperts.com\/","name":"VAS Experts","description":"VAS Experts","inLanguage":"br-PT","publisher":{"@id":"https:\/\/vasexperts.com\/#organization"}},{"@type":"Person","@id":"https:\/\/vasexperts.com\/#\/schema\/person\/e437e05016391b857d85b493b3173d59","name":"Elena Rudich","url":"https:\/\/vasexperts.com\/br\/blog\/author\/elena-rudich\/"},{"@type":"Organization","@id":"https:\/\/vasexperts.com\/#organization","name":"VAS Experts","url":"https:\/\/vasexperts.com\/","logo":"https:\/\/vasexperts.com\/assets\/img\/svg\/logo.svg","sameAs":["https:\/\/www.linkedin.com\/company\/vas-experts","https:\/\/www.youtube.com\/channel\/UCGYfhhZvmE2XbrCyerzRbGA"]}]}},"_links":{"self":[{"href":"https:\/\/vasexperts.com\/br\/wp-json\/wp\/v2\/posts\/15167"}],"collection":[{"href":"https:\/\/vasexperts.com\/br\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/vasexperts.com\/br\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/vasexperts.com\/br\/wp-json\/wp\/v2\/users\/7"}],"replies":[{"embeddable":true,"href":"https:\/\/vasexperts.com\/br\/wp-json\/wp\/v2\/comments?post=15167"}],"version-history":[{"count":7,"href":"https:\/\/vasexperts.com\/br\/wp-json\/wp\/v2\/posts\/15167\/revisions"}],"predecessor-version":[{"id":15180,"href":"https:\/\/vasexperts.com\/br\/wp-json\/wp\/v2\/posts\/15167\/revisions\/15180"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/vasexperts.com\/br\/wp-json\/wp\/v2\/media\/15192"}],"wp:attachment":[{"href":"https:\/\/vasexperts.com\/br\/wp-json\/wp\/v2\/media?parent=15167"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/vasexperts.com\/br\/wp-json\/wp\/v2\/categories?post=15167"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/vasexperts.com\/br\/wp-json\/wp\/v2\/tags?post=15167"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}