Yetenek

Üç Servis Tipi

HTTP, TCP ve Layer4 servislerini tek konfigürasyon modeliyle yönetin; her tipe yalnızca doğru özellikleri gösterin.

TR7 Üç Servis Tipi modeli, uygulama tesliminde servis tipini yalnızca teknik bir ayar değil, tüm özellik matrisini belirleyen mimari karar olarak ele alır. Operatör yeni pool oluştururken HTTP, TCP veya Layer4 tiplerinden birini seçer; TR7 bu seçime göre yalnızca anlamlı aksiyonları, kuralları ve ayarları gösterir. HTTP tipi tam katman 7 görünürlük sağlar: WAAP, içerik farkındalıklı kurallar, header ve cookie işlemleri, redirect, captcha, response cache, compression ve AAM entegrasyonu bu alanda çalışır. TCP tipi SSL sonlandırma veya passthrough, SNI tabanlı yönlendirme ve bağlantı yönetimi için kullanılır. Layer4 tipi ise paket seviyesinde TCP, UDP veya protokol bağımsız yüksek performanslı dağıtım için konumlanır. Aynı model içinde kurum servisi grupları da yönetilir. Bir pool altında varsayılan grup ve ek gruplar tanımlanabilir; örneğin okuma/yazma ayrımı, mobil/masaüstü ayrımı veya bölgesel trafik dağıtımı aynı servis altında kural bazlı yönetilebilir. Sonuç: TR7, farklı trafik tiplerini ayrı ürün mantığına bölmeden; servis tipi, uygun özellik filtresi ve kurum servisi gruplamasını tek operasyon modelinde birleştirir.

Servis tipi: HTTP, TCP ve Layer4

30+

Tip bazlı aksiyon matrisi — her tip için yalnızca anlamlı seçenekler

Pool başına kurum servisi grubu — sınır yok

Servis tipi net değilse, yanlış özellikler yanlış yerde görünür ve operasyon hatası kaçınılmaz olur.

Kurumsal trafik yönetiminde HTTP, TCP ve Layer4 servisleri aynı şey değildir. HTTP trafiğinde header, cookie, path, WAAP skoru ve içerik kuralları anlamlıdır; TCP trafiğinde bağlantı, SSL sonlandırma ve SNI ön plana çıkar; Layer4 tarafında ise paket seviyesinde protokol, algoritma ve persistence davranışı belirleyicidir. Bu fark açık modellenmezse operatör, teknik olarak çalışması mümkün olmayan ayarlarla karşılaşır.

Geleneksel yaklaşımlarda servis tipi çoğu zaman farklı objeler, profiller, ayrı ekranlar veya manuel konfigürasyon blokları içine dağılır. Operatör hangi özelliğin hangi trafik tipinde geçerli olduğunu ezberlemek zorunda kalır. Yanlış yerde header kuralı, yanlış serviste WAAP ayarı veya Layer4 trafiğinde katman 7 beklentisi runtime hatasına ve zaman kaybına dönüşür.

Bir başka sorun, aynı servis altında birden fazla kurum servisi grubunun yönetilmesidir. Okuma ve yazma isteklerinin farklı hedeflere gitmesi, mobil ve masaüstü trafiğinin ayrılması veya bölgesel servis gruplarının aynı giriş noktası altında yönetilmesi çoğu yapıda ayrı bir özellik gibi ele alınır. Bu da basit bir yönlendirme ihtiyacını kavramsal olarak ağırlaştırır.

Doğru yaklaşım, tek pool objesi içinde servis tipini açıkça tanımlamak ve bu tipe göre özellik matrisini otomatik filtrelemektir. Aynı pool altında birden fazla kurum servisi grubu desteklenmeli; ancak operatör gereksiz teknik detayla boğulmadan yalnızca ilgili seçenekleri görmelidir.

TR7 Üç Servis Tipi modeli bu karmaşayı azaltır: servis tipi baştan seçilir, uygun özellikler otomatik görünür, kurum servisi grupları aynı konfigürasyon modeli içinde yönetilir.

Yaklaşımımız

TR7, servis tipini konfigürasyonun merkezi anahtarı yapar ve tüm aksiyon görünürlüğünü bu mimari seçime göre düzenler.

Pool oluşturulurken servis tipi baştan seçilir

Operatör HTTP, TCP veya Layer4 tiplerinden birini seçerek pool oluşturur. Bu seçim, daha sonra hangi aksiyonların, sağlık kontrollerinin ve trafik özelliklerinin kullanılabileceğini belirler.

Aksiyonlar servis tipine göre otomatik filtrelenir

Her aksiyonun hangi servis tipinde geçerli olduğu merkezi özellik matrisinde tanımlıdır. GUI yalnızca seçilen pool tipinde anlamlı olan ayarları gösterir; teknik olarak geçersiz seçenekler operatörün önüne gelmez.

Bir servis altında birden fazla kurum servisi grubu tanımlanır

Her pool varsayılan bir kurum servisi grubuyla başlar ve ihtiyaç halinde ek gruplar eklenebilir. Trafik, ACL ve kural mantığıyla ilgili gruba yönlendirilir.

Servis tipi sonradan değiştirilmez, yeni pool ile geçilir

Servis tipi, pool'un tüm özellik matrisini etkileyen mimari karardır. Bu yüzden mevcut pool'u farklı tipe çevirmek yerine yeni pool oluşturma ve kontrollü geçiş yaklaşımı kullanılır.

Yetenekler

Üç Servis Tipi modeli, HTTP, TCP ve Layer4 trafiği için doğru yetenekleri doğru yerde sunar.

HTTP tipi tam katman 7 görünürlük ve uygulama güvenliği sağlar

HTTP tipi, tam katman 7 proxy davranışı için kullanılır. WAAP, içerik farkındalıklı kurallar, header ve cookie manipülasyonu, redirect, captcha, response cache, compression ve AAM entegrasyonu bu tipte anlamlıdır. ALPN ile h2 ve http/1.1 seçenekleri HTTP servis davranışına dahil edilebilir. Uygulama ve API trafiği üzerinde detaylı karar, dönüşüm ve güvenlik politikası gerektiğinde doğru seçim HTTP tipidir.

TCP tipi bağlantı yönetimi ve SSL senaryolarına odaklanır

TCP tipi, katman 4 bağlantı akışı üzerinde SSL sonlandırma veya passthrough ihtiyacı olan servisler için kullanılır. SNI tabanlı yönlendirme, TLS hello inspection ve TCP bağlantı yönetimi bu alanda öne çıkar. RDP cookie persistence gibi TCP'ye özel persistence ihtiyaçları bu tipte değerlendirilebilir. MQTT ve FIX gibi protokol fonksiyonları da TCP seviyesindeki karar mantığını güçlendirebilir.

Her servis kendi çekirdeğini alır — HTTP dalgası bir UDP servisini aç bırakamaz

HTTP, TCP ve UDP servisleri yalnızca aynı platformu paylaşmaz; yayımlanan her servise kendi çekirdekleri, kendi CPU önceliği ve kendi bellek tavanı verilir. Web servisindeki bir kampanya, API'deki ağır bir WAF politikası ve UDP dinleyicisindeki bir DNS patlaması bu yüzden kendi şeridinde kalır. Yoğun konsolidasyonu güvenli kılan da budur: tek cihazdaki yirmi servis, yirmi cihaz gibi davranır — yirmi cihaz olmadan.

Layer4 tipi paket seviyesinde TCP ve UDP dağıtımı yapar

Layer4 tipi, paket seviyesinde çalışan yüksek performanslı dağıtım modeli için kullanılır. TCP, UDP veya protokol bağımsız akışlarda IPVS algoritmaları, NAT, DR ve TUN seçenekleri uygulanabilir. Bu tipte katman 7 inceleme yapılmaz; karar IP, port, protokol ve persistence mantığına dayanır. DNS, telekom veya düşük gecikme isteyen saf katman 4 servisleri için doğru mimari budur.

Güvenlik duvarı yük dengeleme — sandviç simetrik kalır

İki TR7 katmanı arasındaki güvenlik duvarı çifti, ancak bir akış ile dönüşü aynı duvardan geçerse işe yarar; aksi hâlde duvar konuşmanın yarısını görür ve düşürür. Protokolden bağımsız servis tipinde kaynak-hash seçimi bu simetriyi verir, sağlık kontrolü arızalanan duvarı saniyeler içinde döngüden çıkarır ve kapasite eklemek topolojiyi yeniden kurmak değil, listeye üye eklemektir. TR7'nin yapmadığı şey, güvenlik duvarlarının kendi oturum tablolarını senkronlamaktır — o duvarın işidir; durum tutan bir çift, üreticisinin öngördüğü şekilde kümelenmeye devam etmelidir.

Varsayılan kurum servisi grubu her pool için temel hedef kümesini oluşturur

Her pool en az bir varsayılan kurum servisi grubuna sahiptir. Bu grup, servisin temel hedef kümesini ve dengeleme algoritmasını taşır. Ek yönlendirme kuralı yazılmadığında trafik bu varsayılan gruba aktarılır. Bu model, basit servisleri sade tutarken gelişmiş senaryolar için genişlemeye izin verir.

Ek kurum servisi grupları aynı servis altında farklı trafik dilimleri yaratır

Bir pool altında `be-mobile`, `be-desktop`, `be-eu`, `be-us`, `be-readonly` veya `be-writes` gibi ek gruplar oluşturulabilir. Her grup farklı hedef kümesine, sağlık kontrolüne ve trafik davranışına sahip olabilir. ACL ve kural koşulları, isteği ilgili gruba yönlendirir. Böylece tek giriş noktası altında çoklu hedef mimarisi yönetilebilir hale gelir.

Grup seviyesinde kurallar hedefin nerede uygulanacağını belirler

Kurallar yalnızca kurum servisi grubunda, hem giriş hem grup tarafında veya belirli bir özel grup üzerinde uygulanabilir. Bu hedefleme modeli, her kuralın etki alanını açık hale getirir. Örneğin yalnızca belirli bir grup için header dönüşümü, sağlık davranışı veya yönlendirme koşulu tanımlanabilir. Operatör aynı servis içinde farklı trafik dilimlerini kontrollü biçimde ayırır.

HTTP, TCP ve ortak aksiyonlar tip matrisine göre ayrılır

CORS, çerez şifreleme, header ekleme, header silme, path değiştirme, URI normalizasyonu ve yetkilendirme gibi aksiyonlar HTTP tipine özgüdür. TCP bağlantı yönetimi ve TCP'ye özel persistence seçenekleri TCP tipinde görünür. Silent log, manuel kural, karantina tablosu, deny ve IP maskeleme gibi bazı aksiyonlar birden fazla tipte kullanılabilir. GUI bu ayrımı otomatik yaptığı için operatör yanlış servis tipinde yanlış aksiyonla uğraşmaz.

Pool kapasitesi ve bağlantı limitleri servis genelinde yönetilir

Pool seviyesinde maksimum bağlantı ve bağlantı oranı gibi sınırlar tanımlanabilir. Kurum servisi hedefleri için ayrıca bağlantı üst limitleri uygulanabilir. Bu model, yoğun trafik altında hem servis genelini hem de tekil hedefleri korumaya yardımcı olur. Kapasite ayarları servis tipine, trafik davranışına ve donanım kaynaklarına göre planlanır.

Operasyonel derinlik

Üç Servis Tipi modeli; tip değişikliği, konfigürasyon üretimi, sağlık kontrolü, istatistik yolu ve audit davranışlarıyla birlikte ele alınır.

Tip değişikliği kısıtı

Servis tipi sonradan basit bir ayar gibi değiştirilmez. Çünkü HTTP, TCP ve Layer4 tipleri farklı özellik matrisi, farklı çalışma yolu ve farklı konfigürasyon üretimi gerektirir. Tip değişimi gerekiyorsa yeni pool oluşturularak kontrollü geçiş yapılmalıdır.

Grup ACL yerleşimi

Kurum servisi grubu kurallarında ACL'in giriş tarafında mı yoksa grup tarafında mı tanımlanacağı hedefe göre belirlenir. Bu ayrım, kuralın hangi trafik aşamasında çalışacağını netleştirir. Yanlış yerde tanımlanan koşulların servis davranışını bozması engellenir.

Konfigürasyon blok üretimi

Her kurum servisi grubu ayrı çalışma bloğu olarak üretilir. Varsayılan grup ayrı, ek gruplar ayrı tanımlanır ve kurallar ilgili hedefe bağlanır. Bu yapı hem okunabilir konfigürasyon hem de geri dönüş senaryoları için avantaj sağlar.

HTTP/2 ALPN davranışı

HTTP tipinde uygun ayar etkinleştirildiğinde servis tarafı bağlantılarda h2 ve http/1.1 ALPN seçenekleri kullanılabilir. Bu ayar yalnızca HTTP servis bağlamında anlamlıdır. TCP veya Layer4 tiplerinde katman 7 HTTP davranışı beklenmemelidir.

TCP SNI yönlendirme

TCP tipinde TLS hello içindeki SNI bilgisi incelenerek yönlendirme kararı alınabilir. Bu, tam HTTP çözümleme yapmadan TLS servislerini farklı hedeflere ayırmak için kullanılır. SNI temelli kararlar, passthrough ve sonlandırma senaryolarına göre dikkatli planlanmalıdır.

Layer4 istatistik yolu

Layer4 tipinde istatistikler katman 7 proxy yolundan değil, paket seviyesindeki dağıtım mekanizmalarından alınır. Bu nedenle HTTP veya TCP proxy istatistikleriyle birebir aynı davranış beklenmez. Operatör Layer4 servisleri izlerken doğru istatistik kaynağını dikkate almalıdır.

Hangi senaryolarda kullanılır

HTTP API ağ geçidi ve WAAP koruması

SaaS ekipleri HTTP tipiyle API trafiğini tam katman 7 görünürlük altında yönetebilir. WAAP, JWT doğrulama, içerik farkındalıklı kurallar ve path tabanlı yönlendirme aynı servis modeli içinde uygulanır.

TCP tabanlı kurumsal mesajlaşma geçidi

Kurumsal ekipler TCP tipiyle SSL sonlandırma, passthrough veya kaynak IP'ye dayalı persistence kullanan servisleri yönetebilir. Katman 7 HTTP özelliği gerekmeyen bağlantı odaklı servisler sade bir modelle sunulur.

UDP tabanlı DNS servis kümesi

Telekom ve altyapı ekipleri Layer4 tipiyle UDP trafiğini paket seviyesinde dağıtabilir. IPVS algoritmaları ve persistence seçenekleriyle düşük gecikmeli, protokol odaklı servis sunumu sağlanır.

HTTP kurum servisi gruplarıyla A/B yönlendirme

E-ticaret ekipleri aynı HTTP servisi altında `be-variant-a` ve `be-variant-b` gibi gruplar oluşturabilir. ACL veya hash tabanlı koşullarla trafik kontrollü biçimde farklı deneyimlere aktarılır.

Sık sorulanlar

HTTP, TCP ve Layer4 tipleri arasındaki temel fark nedir?

HTTP tipi tam katman 7 proxy davranışı sunar: WAAP, header ve cookie manipülasyonu, redirect, captcha, response cache ve AAM entegrasyonu bu tipte çalışır. TCP tipi bağlantı yönetimi, SSL sonlandırma veya passthrough ve SNI tabanlı yönlendirme için kullanılır. Layer4 tipi ise paket seviyesinde TCP, UDP veya protokol bağımsız dağıtım yapar; katman 7 inceleme yapılmaz.

Servis tipi sonradan değiştirilebilir mi?

Hayır. Servis tipi, pool'un tüm özellik matrisini belirleyen mimari karardır ve sonradan değiştirilemez. Farklı bir tipe geçiş gerekiyorsa yeni pool oluşturulur ve trafik kontrollü biçimde taşınır. Bu kısıt, tip uyumsuzluğundan kaynaklanacak konfigürasyon hatalarını önler.

Aynı servis altında birden fazla kurum servisi grubu nasıl tanımlanır?

Her pool varsayılan bir kurum servisi grubuyla başlar. Bu gruba ek olarak `be-mobile`, `be-desktop`, `be-eu`, `be-readonly` gibi ek gruplar oluşturulabilir. ACL ve kural koşulları, gelen isteği ilgili gruba yönlendirir. Her grup kendi hedef kümesine, sağlık kontrolüne ve trafik davranışına sahip olabilir.

Layer4 tipinde istatistikler nasıl izlenir?

Layer4 tipinde istatistikler katman 7 proxy yolundan değil, paket seviyesindeki dağıtım mekanizmalarından alınır. HTTP veya TCP proxy istatistikleriyle aynı davranış beklenmemelidir. Operatör Layer4 servislerini izlerken doğru istatistik kaynağını kullanmalıdır.

TCP tipinde SNI tabanlı yönlendirme nasıl çalışır?

TCP tipinde TLS hello içindeki SNI bilgisi incelenerek yönlendirme kararı alınabilir. Bu yaklaşım, tam HTTP çözümleme yapmadan TLS servislerini farklı kurum servisi gruplarına ayırmak için kullanılır. SNI tabanlı kararlar passthrough ve SSL sonlandırma senaryolarına göre dikkatli planlanmalıdır.

Hangi aksiyonlar birden fazla servis tipinde kullanılabilir?

Silent log, manuel kural, karantina tablosu, deny ve IP maskeleme gibi aksiyonlar birden fazla tipte kullanılabilir. CORS, header ekleme/silme, URI normalizasyonu ve yetkilendirme gibi aksiyonlar yalnızca HTTP tipine özgüdür. TCP bağlantı yönetimi ve TCP'ye özel persistence seçenekleri ise yalnızca TCP tipinde görünür. GUI bu ayrımı otomatik olarak uygular.

Servis tipinize göre doğru özellik modelini keşfedin

HTTP, TCP ve Layer4 trafiğini tek konfig modelinde yönetin; kurum servisi gruplarıyla esnek hedef mimarisi kurun. Kendi ortamınızda canlı bir kurulumda gezdirelim.