HTTP’nin Gelişimi: HTTP Sürümlerindeki İletişim Yöntemlerinin İncelenmesi ve Karşılaştırılması

Ağustos 03, 2025


Evolving the HTTP: Review and Comparison the Communication Methods on HTTP Versions



Abstract 
The Hypertext Transfer Protocol (HTTP) is the foundation of most internet services, enabling access to websites, social networks, and collaborative platforms. HTTP first emerged in the early 1990s with version 0.9, and its first widely adopted version, HTTP/1.1, was standardized in 1997. The second major revision, HTTP/2, was standardized in 2014 and introduced significant changes to the protocol’s framing mechanisms. HTTP/3, the third version of the protocol, is currently in the final stages of standardization by the IETF.

This study provides a comprehensive examination of the historical development of the Hypertext Transfer Protocol (HTTP) and the communication methods employed across its various versions. It analyzes the evolution from HTTP/0.9 to HTTP/3 and subsequently investigates and compares the primary communication protocols and mechanisms utilized in modern web applications.

Keywords: http, http2, http3, soap, rest, graphql, websocket, server-sent vents, rpc, grpc

Abstract 
The Hypertext Transfer Protocol (HTTP), internet üzerindeki çoğu hizmete, web sitelerinden sosyal ağlara ve işbirlikçi platformlara erişim sağlamak için kullanılır. HTTP, 90’ların başında ortaya çıkmıştır (HTTP 0.9) ve ilk sürümü (HTTP 1.1) 1997’de standartlaştırılmıştır. İkinci sürüm (HTTP/2) 2014 yılında standartlaştırılmıştır ve protokolün çerçeveleme mekanizmalarında önemli değişiklikler içermektedir. HTTP/3, HTTP’nin üçüncü sürümüdür ve şu anda IETF’de son standardizasyon aşamasındadır.

Bu çalışma, HyperText Transfer Protocol’ün (HTTP) tarihsel gelişimini ve farklı sürümlerinde kullanılan iletişim yöntemlerini kapsamlı bir şekilde incelemektedir. HTTP/0.9’dan HTTP/3’e kadar olan gelişim süreci analiz edilmekte, ardından modern web uygulamalarında kullanılan başlıca iletişim protokolleri yada mekanizmalarını inceleyip karşılaştırmalar yapmaktadır.

Anahtar Kelimeler: http, http2, http3, soap, rest, graphql, websocket, server-sent vents, rpc, grpc

Giriş

HyperText Transfer Protocol (HTTP), internet üzerinden hipermedya (yazı, resim, video, müzik vb.) içeriklerinin aktarılmasını sağlayan, istemci-sunucu mimarisine dayalı bir uygulama katmanı protokolüdür. Bu protokol uygulama katmanı üzerinden Transmission Control Protocol/Internet Protocol (TCP/IP) yığını üzerine inşa edilen HTTP World Wide Web’in temilini oluşturarak, yıllar içinde değişen gelişen ve değişen teknolojiler doğrultusunda çeşitli sürümlerle evrilmiştir.

HyperText Transfer Protocol (HTTP), günümüzde İnternetteki hizmetlerin büyük çoğunluğuna erişmek için kullanılır. HTTP 90’ların başında ortaya çıktı (HTTP 0.9) ve ilk sürümü (HTTP 1.1) 1997’de standartlaştırıldı (R. Fielding et al. 1999). Protokolün çerçeveleme mekanizmalarında önemli değişiklikler içeren ikinci sürüm (HTTP/2) 2014’e kadar standartlaştırılmadı(Belshe, Peon, and Thomson 2015a). HTTP/3, HTTP’nin üçüncü sürümüdür ve şu anda IETF’de son standartlaştırma aşamasındadır. HTTP/3, HTTP/2’ye göre performans avantajları ve güvenlik iyileştirmeleri vaat ediyor(Bishop 2021). Önemli değişikliklerden biri, HTTP/3’ün, başlangıçta Google tarafından önerilen ve şu anda bir IETF standardı olan UDP tabanlı bir taşıma protokolü olan QUIC taşıma katmanı olarak TCP’nin yerini almasıdır(Perna et al. 2022).

Tarihçe

Hypertext Transfer Protocol (HTTP), World Wide Web’in temel iletişim protokolü olarak 1989’da Tim Berners-Lee tarafından geliştirilmiş ve web teknolojilerinin evriminde kritik rol oynamıştır(Gasser 2023).

HTTP’nin Doğuşu (1989-1991)

HTTP protokolü, World Wide Web projesinin bir parçası olarak 1989 yılında Tim Berners-Lee tarafından geliştirilmiştir. İlk amacı, hipertext belgelerinin internet üzerinden paylaşılmasını sağlamaktı. Bu dönemde web, sadece statik HTML sayfalarından oluşuyordu ve etkileşimli içerik kavramı henüz doğmamıştı.

Erken Dönem Gelişmeler (1991-1996)

1991 yılında ilk web sunucusu CERN’de çalışmaya başladı. Bu dönemde HTTP/0.9 sürümü kullanılıyordu ve protokol oldukça basitti. Sadece GET metodu destekleniyordu ve her istek için yeni bir TCP bağlantısı kurulması gerekiyordu.

Standartlaşma Süreci (1996-1999)

Internet Engineering Task Force (IETF) tarafından HTTP/1.0 standardı RFC 1945 ile resmi olarak tanımlandı. Bu dönemde POST ve HEAD metodları eklendi, durum kodları standartlaştırıldı ve başlık (header) sistemi geliştirildi(Nielsen, Fielding, and Berners-Lee 1996).

Modern HTTP Dönemi (1999-günümüz)

HTTP/1.1’in yayımlanması ile birlikte persistent connections, chunked transfer encoding ve host header gibi önemli özellikler eklendi. 2015 yılında HTTP/2, 2020 yılında ise HTTP/3 sürümleri yayınlanarak protokol günümüzün gereksinimlerini karşılayacak şekilde evrimleşti.

Sürümler

World Wide Web’in omurgasını oluşturan HTTP, yıllar içinde değişen ağ koşulları, kullanıcı beklentileri ve güvenlik ihtiyaçları doğrultusunda çeşitli sürümlerle evrilmiştir.

Modern web uygulamalarının artan karmaşıklığı ve performans gereksinimleri, HTTP üzerinde çalışan farklı iletişim protokollerinin doğmasına neden olmuştur. Bu protokoller, geleneksel istek-yanıt (request-response) modelinden real-time (anlık) iletişime, servis odaklı mimarilerden mikroservis yapılarına kadar geniş bir yelpazede çözümler sunmaktadır.

HTTP 0.9

HTTP/0.9, protokolün ilk versiyonu olarak son derece basit bir yapı ile 1989 ortaya çıkıp 1991’de uygulama katmanı protokolü olarak, TCP/IP üzerine inşa edilen HTTP/0.9, istemci-sunucu modeline dayalı basit bir iletişim mekanizması sunar. Bu sürüm, yalnızca hipermetin belgelerinin aktarımı için tasarlanmış olup, istemcinin sunucuya yalnızca GET yöntemiyle istek göndermesine izin verir ve sunucunun yalnızca HTML formatında yanıt dönmesini destekler. HTTP/0.9, stateless (durumsuz) bir protokol olarak, her isteğin bağımsız şekilde işlenmesini sağlar, bu da sistemlerin basitliğini ve ölçeklenebilirliğini korur. Ancak, bu sürüm oldukça sınırlıdır; başlık (header) bilgileri, durum kodları, hata mesajları veya çoklu medya türü desteği gibi modern HTTP sürümlerinde bulunan özelliklerden yoksundur. İstemci, bir URL aracılığıyla sunucudan bir kaynak talep eder ve sunucu, talep edilen HTML dosyasını doğrudan gönderir ya da bağlantıyı keser.

HTTP/0.9, webin ilk versiyonlarında statik içerik sunumu için yeterliydi ancak başlık bilgisi, MIME türleri, durum kodları gibi ileri düzey işlevleri barındırmadığından kısa sürede yetersiz hale gelmiştir.

Özet olarak;

  • Tim Berners-Lee / 1991
  • Sadece GET metodunu destekler.
  • Başlık (header) yoktur.
  • Yalnızca HTML içerik tipi destekleniyordu
  • Her istek için yeni TCP bağlantısı kurulur.
  • Durum kodu bilgilendirmesi yok.
  • URL ile aracılık kurulur.
  • Her isten-cevap sonra bağlantı kapatılır.

HTTP 1.0

HTTP/1.0, 1996 yılında RFC 1945 ile standartlaştırılan ikinci sürümüdür ve World Wide Web’in gelişiminde önemli bir dönüm noktası teşkil eder(Nielsen, Fielding, and Berners-Lee 1996).HTTP/0.9’un basitliğine karşın, HTTP/1.0 önemli yenilikler getirerek web teknolojilerinin daha geniş bir kullanım alanına ulaşmasını sağlamıştır. Bu sürüm, GET, POST ve HEAD gibi birden fazla istek yöntemini destekler ve HTTP başlık (header) bilgilerinin tanıtılmasıyla istemci ile sunucu arasında daha zengin meta veri alışverişine olanak tanır. Başlıklar, içerik türü (Content-Type), içerik uzunluğu (Content-Length) ve istemci/sunucu kimlik bilgileri gibi verileri içererek iletişimde esneklik ve kontrol sağlar. Ayrıca, HTTP/1.0 durum kodlarının kullanıma sunulmasıyla iletişimin durumum bilgilendirmesinin anlamlandırılması kolaylaşmıştır. Ancak, HTTP/1.0 stateless (durumsuz) bir protokoldür ve her istek-yanıt bağımsız olarak işlenir, bu da bağlantıların her istekten sonra kapanmasına neden olur (non-persistent connections). HTTP/1.0’un akademik ve tarihsel önemi, web’in yalnızca hipermetin odaklı bir sistemden, çoklu medya içeriklerini destekleyen bir platforma evrilmesinde yatmaktadır. Multipurpose Internet Mail Extensions (MIME) türlerinin entegrasyonu sayesinde HTML dışındaki dosya formatlarının aktarımı mümkün olmuş, böylece modern web uygulamalarının temeli atılmıştır. HTTP/1.0, internetin ticari ve toplumsal kullanımını hızlandırarak dijital bilgi paylaşımının standartlaşmasında kritik bir rol oynamış ve sonraki HTTP sürümlerinin geliştirilmesi için temel bir çerçeve sunmuştur(Corbel, Stephan, and Omnes 2016).

Özet olarak;

  • 1996 / RFC 1945
  • GET yanına POST, HEAD metotları eklendi.
  • Başlık (header) eklendi.
  • HTML harici MIME türleri eklendi.
  • Durum kodları eklendi (200, 404, 500 vb.).
  • Her istek için yeni TCP bağlantısı kurulur.
  • Kalıcı bağlantı özelliği eklendi.

HTTP 1.1

HTTP/1.1, 1997 yılında RFC 2068(Roy T. Fielding et al. 1997) ile tanıtılan ve 1999’da RFC 2616(Nielsen et al. 1999) ile güncellenen üçüncü sürümüdür. HTTP/1.1, kalıcı bağlantılar (persistent connections) özelliğini tanıtarak birden fazla istek-yanıt döngüsünün tek bir TCP bağlantısı üzerinden gerçekleştirilmesini mümkün kılmış ve pipelining özelliği ekleyerek aynı TCP bağlantısı üzerinden birden fazla istek ile bağlantı kurma gecikmelerini azaltarak performansını artırmıştır. HTTP/1.1, GET, POST, HEAD, PUT, DELETE, TRACE ve OPTIONS gibi genişletilmiş istek yöntemleriyle kaynak yönetimi ve sunucu-istemci etkileşiminde daha fazla esneklik sağlar. Başlık (header) yapılarında yapılan geliştirmeler, önbellekleme (caching), içerik sıkıştırma (content encoding) ve koşullu istekler gibi mekanizmalarla veri aktarımını optimize eder. HTTP/1.1, aynı zamanda ana bilgisayar (Host) başlığının zorunlu hale getirilmesiyle sanal barındırma (virtual hosting) desteği sunarak birden fazla web sitesinin tek bir sunucuda çalışmasını mümkün kılmıştır. HTTP/1.1, dijital bilgi paylaşımının ve internet tabanlı teknolojilerin evriminde kritik bir dönüm noktası oluşturmuştur(Krishnamurthy, Mogul, and Kristol 1999).

Özet olarak;

  • 1997 / RFC 2068, 1999 / RFC 2616
  • PUT, DELETE, HEAD, OPTIONS, TRACE metotları eklendi.
  • Kalıcı bağlantılar (persistent connections) eklendi.
  • Host ve subHost başlıkları eklendi.
  • Cache-Control, Content-Encoding, gibi performans özellikleri eklendi.
  • Chunked Transfer Encoding ile stream (sürekli veri aktarımı) özelliği eklendi.
  • Pipelining ile aynı TCP bağlantısı üzerinden birden fazla istek.
  • Head-of-line blocking (HoLB): Bir isteğin gecikmesi tüm bağlantıyı etkiler.

HTTP 2

Google’ın SPDY protokolünden esinlenen HTTP/2, 2015 yılında RFC 7540 ile standartlaştırılan dördüncü sürümüdür(Belshe, Peon, and Thomson 2015b). HTTP/1.1’in temel sınırlamalarını ele almak ve modern web uygulamalarının artan taleplerini karşılamak üzere tasarlanmıştır. Bu protokol, tek bir TCP bağlantısı üzerinden multiplexing (çoklamayı) mümkün kılarak, aynı anda birden fazla istek ve yanıtın bağımsız akışlar halinde paralel olarak aktarılmasını sağlar ve böylece HTTP/1.1’deki satır başı tıkanıklığının (Head-of-Line Blocking) önüne geçer(Corbel, Stephan, and Omnes 2016). Ayrıca, HPACK algoritmasıyla zorunlu hale getirilen HTTP başlık sıkıştırması, tekrarlanan ve gereksiz başlık verilerini büyük ölçüde azaltarak bant genişliği tüketimini optimize eder ve gecikmeyi düşürür. Protokolün bir diğer kritik yeniliği olan sunucu veri göndermesi (Server Push), sunucunun istemcinin açık talebi olmadan öngörülebilir kaynakları önceden istemci önbelleğine göndermesine olanak tanıyarak ek gidiş-dönüş sürelerini (RTT) ortadan kaldırır ve algılanan sayfa yükleme sürelerini iyileştirir. HTTP/2.0, geriye dönük uyumluluğu korurken (HTTP semantiği değişmez), alt katmandaki veri aktarım mekanizmasını yeniden şekillendirerek daha düşük gecikme süreleri, daha yüksek verimlilik ve gelişmiş kaynak kullanımı sağlamıştır(Kumar et al. 2023).

Özet olarak;

  • 2015 / RFC 7540
  • Binary olarak veri aktarım desteği geldi.
  • Multiplexing ile tek TCP’den paralel aktarım
  • Server Sent Event (SSE) eklendi.
  • Header sıkıştırma (HPACK) eklendi.
  • HTTPS zorunlu hale getirildi.
  • Frame-based yapı kuruldu.

HTTP 3

HTTP 3, 2022 yılında RFC 9114 ile standartlaştırılan en yeni sürümüdür ve modern web’in performans, güvenilirlik ve düşük gecikme gereksinimlerini karşılamak üzere tasarlanmış sürümüdür(Bishop 2022). Önceki HTTP sürümlerinin TCP/IP protokolü üzerine inşa edilen yapısının aksine, HTTP/3.0, QUIC (Quick UDP Internet Connections) protokolünü kullanarak User Datagram Protocol (UDP) tabanlı bir taşıma katmanı sunar. QUIC’in entegre TLS 1.3 şifrelemesi(Rescorla 2018), bağlantı kurulumunu hızlandırarak önceki sürümlere göre TCP ve TLS el sıkışmalarının neden olduğu gecikmeleri azaltır. QUIC’in sağladığı bireysel akış kontrolü ile head-of-line blocking sorununu tamamen ortadan kaldırır. Bu, bir akışın tıkanmasının diğer akışları etkilemesini önleyerek veri aktarımını daha verimli hale getirir. HTTP/2’de kullanılan HPACK algoritması, HoLB sorunlarına neden olduğu için HTTP/3’te yerini QPACK adlı yeni bir başlık sıkıştırma algoritması ile stream’ler arası bağımlılığı en aza getirerek ve sıkıştırılmış başlıkların kod çözme sürecini daha iyi hale getirmiştir(Perna et al. 2022).

Özet olarak;

  • 2022 / RFC 9114
  • TCP yerine QUIC (UDP tabanlı) kullanıldı.
  • Head of Line Blocking sorunu kaldırıldı.
  • TLS 1.3 eklendi.
  • 0-RTT ile bağlantı kurulması eklendi.
  • HTTPS zorunlu hale getirildi.
  • Frame-based yapı kuruldu.

Özellik HTTP/1.0 HTTP/1.1 HTTP/2 HTTP/3
Yıl 1996 1997 2015 2022
Metin/İkili Format Metin Metin İkili (binary) İkili
Kalıcı Bağlantı Yok Var Var Var
Çoklama (multiplexing) Yok Kısıtlı (pipelining) Var Var
Header Sıkıştırma Yok Yok HPACK QPACK
Şifreleme Zorunlu Hayır Hayır Hayır Evet (TLS 1.3)
Transport Protokolü TCP TCP TCP QUIC (UDP)
Server Push Yok Yok Var Var
Head-of-Line Blocking Var Var Var Yok
Standardizasyon RFC 1945 RFC 2068 RFC 7540 RFC 9114

Tablo 1: HTTP Sürümlerinin Karşılaştırmalı Tablosu

Perna ve arkadaşlarının 2022’de yaptığı çalışmada aynı dönemim başlarında internet trafiğinin büyük çoğunluğuna sahip kurumsallar ile beraber HTTP/3 kullanım oranı %17.01’e ulaşmışır.

Şekil 1: HTTP geçikme karşılaştırması

Yazarlar Şekil 1 gösterildiği gibi düşük bant genişliği ile sayfa yüklenme süresinde sınırlı iyileşmeler olduğunu ve yüksek gecikme durumunda her iki metrik için de önemli faydalar olduğu anlaşılmaktadır. HTTP/3’ün yüksek paket kaybı senaryolarında ve video akışı iletim yöntemleri performans iyileştirmeleri sağladığını doğrulamadıklarını belirtmişlerdir.

Sonuç olarak yazarlar HTTP/3 kullanma ve performansına ilişkin araştırma yaparak, HTTP/3’ün çeşitli ağ senaryolarındaki performans avantajlarını odaklanmışladır. Bazı önde gelen İnternet şirketlerinin 2020’de HTTP/3’ü benimsemeye başladığını ancak, erken benimseyenlerin çoğu hala web içeklerinin çoğunu üçüncü taraf HTTP/2 sunucularında barındırıyor.Yazalar tamamen tüm veri iletim yöntemlerini HTTP/3 ile kullanırsa yüksek gecikme senaryolarında performans avantajları sağladığını söylemektedirler. Paket kaybı yüksek veya bant genişliği düşük olduğunda, HTTP/3 ve HTTP/2’nin performansı hemen hemen aynıdır.

Veri İletim Teknolojileri

Bu bölümde HTTP sürümleri üzerinde gelişen geçmişten günümüze veri iletişim teknolojileri incelenmektedir.

SOAP

SOAP (Simple Object Access Protocol), internet üzerinden yapılandırılmış veri alışverişini sağlamak amacıyla geliştirilmiş, XML tabanlı bir mesajlaşma protokolüdür. Genellikle HTTP, SMTP veya TCP gibi taşıma protokolleri üzerinden çalışan SOAP, istemci-sunucu modeline dayalı dağıtık sistemlerde, özellikle web servislerinin iletişiminde kullanılır. 1998 yılında Microsoft tarafından geliştirilen SOAP, HTTP/1.1 ile yaşam döngüsüne başlamıştır.

SOAP, Universal Description, Discovery, and Integration (UDDI) ve Web Services Description Language (WSDL) ile birlikte çalışarak, servislerin arayüzlerini tanımlayarak istemcilerin sunucu işlemlerini anlamasını ve çağırmasını kolaylaştırır. Ayrıca, WS-Security gibi uzantılarla gelişmiş güvenlik mekanizmaları sunarak veri bütünlüğünü ve gizliliğini korur(Ploscar 2012).

REST

REST (Representational State Transfer), Roy Fielding tarafından 2000 yılında doktora tezinde tanımlanan(Roy Thomas Fielding 2000), web tabanlı uygulamalar için hafif, ölçeklenebilir ve esnek bir mimari yaklaşımdır. HTTP protokolü üzerine inşa edilen REST, istemci-sunucu modeline dayalı bir tasarım mekanizması sunar. REST, durum bilgisi tutmayan (stateless) bir iletişim modelidir; her istemci isteği, sunucunun yanıtı için gerekli tüm bilgileri içerir, böylece her istek bağımsız olarak işlenir. REST’in temel ilkeleri arasında istemci-sunucu ayrımı, katmanlı sistem, önbelleklenebilirlik, tekdüze arayüz ve durumsuzluk yer alır.

REST, SOAP’tan daha kolaydır ve ayrıca kısa bir içeriğe sahip olduğundan daha az bant genişliği tüketir. Bir REST web servisi, SOAP tabanlı bir web servisinin tüm avantajlarına sahiptir. Platformdan bağımsızdır, dilden bağımsızdır, güvenlik duvarlarıyla kullanılabilir ve standartlara dayanır. HTTP/1.1 ile ortaya çıkmış REST, dört CRUD (Oluştur/Oku/Güncelle/Sil) işleminin hepsi için HTTP PUT/GET/POST/DELETE kullanır.

Tablo 2 karşılaştırma özeti Bajrami ve arkadaşlarının 2024 yılında yayınladıkları çalışmaya göre elde edilmiştir. Bu çalışma REST ve SOAP mimarilerinin karşılaştırmalı analizine odaklanmıştır. Bu literatür incelemesine dahil edilen on iki makalenin sentezine dayanarak, araştırma sorularını bir araya getirmiş ve her iki yaklaşımın avantajlarını ve dezavantajlarını vurgulamıştır. REST, kullanım kolaylığı, esneklik ve mevcut web teknolojileriyle uyumlu olması nedeniyle günümüzde en yaygın tercih gibi görünse de, SOAP hala yüksek güvenlik ve işlem yönlendirmesinin önemli olduğu belirli alanlarda kritik bir rol oynamaktadır(Bajrami et al. 2024) (Halili, Ramadani, et al. 2018).


Şekil 2: SOAP ve REST performans karşılaştırması

Kumarı ve Rath tarafından yapılan "Performance comparison of SOAP and REST based Web Services for Enterprise Application Integration" isimli çalışma Şekil 2 gösterilen SOAP ve REST mimarilerinin Java tabanlı LoanBroker isimli kurumsal bir uygulaması GlassFish altyapısı üzerinden farklı metriklerde performans karşılaştırmalarını incelemektedir. Şekil 2 göre SOAP, XML’in ağır yapısı nedeniyle düşük verim sunar buna karşın REST, hafif yapısı sayesinde daha yüksek verim sağladığı anlaşılmaktadır. SOAP, XML işleme ve ağ yükü nedeniyle daha REST’in, JSON kullanımı ve basit yapısıyla REST’e göre daha yavaş çalışmaktadır. Ancak bu dezavantajlarının yanında SOAP standart hale gelmiş yapısı ve güvenlik ilkeleri ile REST göre kurumsallar arası veri iletimi olarak günümüzde halen yaygın olarak kullanılmaktadır(Kumari and Rath 2015).

GraphQL

GraphQL, web servis mimarilerini uygulamak için bir sorgu dilidir. Dil, Facebook’ta, REST gibi standart mimari stilleri kullanırken karşılaştıkları çeşitli sorunlara bir çözüm olarak dahili olarak geliştirilmiştir. 2015 yılında Facebook, GraphQL’in tanımını ve uygulamasını açık kaynaklı hale getirdi.

GraphQL, 2015 yılında Facebook tarafından tanıtılan ve 2018’de GraphQL Foundation tarafından standartlaştırılan, web tabanlı uygulamalar için bir veri sorgulama ve manipülasyon dilidir. HTTP üzerinden genellikle JSON formatında çalışan bir uygulama katmanı protokolü olarak, GraphQL, istemcilerin sunucudan yalnızca ihtiyaç duydukları verileri almalarını sağlayan esnek bir sorgu tabanlı mimari sunar. REST’in aksine, GraphQL tek bir endpoint üzerinden çalışır ve istemcilerin veri yapısını sorgularla (queries) veya mutasyonlarla (mutations) tanımlamasına olanak tanır. Bu, istemcilerin veri gereksinimlerini dinamik olarak belirtmesini sağlar ve fazla veri (over-fetching) veya eksik veri (under-fetching) sorunlarını azaltır(Brito and Valente 2020).

GraphQL’de, servis verileri bir şema tarafından temsil edilen bir grafik olarak gösterilir. Buna karşılık, REST’te, sunucu uygulamaları bir endpoint listesi uygular. GraphQL ayrıca istemcilerin sunuculardan talep ettikleri alanları tam olarak belirtmelerine olanak tanıyan bir sorgu dili tanımlar. Ek olarak REST servislerinde, sorgular endpointlerin araçlarıyla tanımlanır. Her endpoint, bir kaynak hakkında veriyi temsil eden önceden tanımlanmış bir alan kümesi döndürür, GraphQL ise yanıt sorgu yapısına benzer(Seabra, Nazário, and Pinto 2019). Çok parametreli sorguların REST’te GraphQL’den özellikle daha zor uygulandığını ve GraphQL’in bu teknolojiyle ilgili daha önce deneyimi olmayan geliştiriciler için bile daha az çaba gerektirdiğini açıkça Brito ve arkadaşlarının 2020 yılında yaptıkları çalışmada ortaya atmıştır(Brito and Valente 2020).


Şekil 3: REST ve GraphQL performans karşılaştırması

Mikuła ve Dzieńkowski tarafından 2020 yılında yayınlanan "Comparison of REST and GraphQL web technology performance" isimli çalışma REST ve GraphQL’ün performanslarını karşılaştırmalı olarak incelemektedir. Araştırma kapsamında aynı işlevselliğe sahip iki ayrı test uygulaması geliştirilmiş, biri REST API, diğeri ise GraphQL API kullanılarak yapılandırılmıştır. Performans testleri, Apache JMeter aracı ile gerçekleştirilmiş; özellikle veri görüntüleme, ekleme, güncelleme ve silme işlemlerine odaklanılmıştır.

Yapılan çalışmada, GraphQL ve REST mimarilerinin performans metrikleri, farklı veri seti boyutları ve eşzamanlı kullanıcı yükleri altında karşılaştırmalı olarak incelenmiştir. Araştırma Şekil 3 gösterildiği bulgulara göre, düşük hacimli veri setlerinin (örneğin, 5 kayıt) yüksek eşzamanlılık senaryolarında sorgulanması durumunda GraphQL’in daha üstün bir yanıt süresi performansı sergilediği tespit edilmiştir. Buna karşın, büyük hacimli veri setlerinin (örneğin, 100 kayıt) işlendiği durumlarda ise REST tabanlı servislerin daha yüksek verimlilikle çalıştığı gözlemlenmiştir.

REST mimarisinin, doğası gereği daha düşük bir gönderim yüküne sahip olmasına rağmen, "aşırı veri getirme" (over-fetching) eğilimi, özellikle mobil platformlarda performans optimizasyonu açısından bir zorluk teşkil etmektedir. Diğer yandan GraphQL, tek bir uç nokta (endpoint) üzerinden esnek sorgulama kabiliyeti sunarak yalnızca talep edilen veriyi döndürmesi sayesinde istemci merkezli uygulamalarda önemli bir avantaj sağlamaktadır. Veri manipülasyon operasyonları (ekleme, silme, güncelleme) açısından iki teknoloji arasında istatistiksel olarak anlamlı bir performans farkı saptanmamış, ancak veri boyutu verimliliği açısından REST’in daha avantajlı olduğu belirlenmiştir. Bununla birlikte, GraphQL’in karmaşık ve istemci kontrollü sorgulara olanak tanıması, gönderilen veri paketlerinin boyutunu artırabilen bir faktör olarak öne çıkmaktadır(Mikuła and Dzieńkowski 2020).

RPC & gRPC

RPC (Remote Procedure Call), uzak yordam çağrısı, dağıtık sistemlerde bir bilgisayarın başka bir bilgisayarda çalışan bir yordamı (fonksiyonu) yerel bir çağrı gibi çalıştırmasını sağlayan bir iletişim mekanizmasıdır. 1970’lerde ortaya çıkan ve 1980’lerde Sun Microsystems tarafından popülerleştirilen RPC, istemci-sunucu modeline dayanır ve genellikle TCP veya UDP gibi veri iletim protokolleri üzerinden çalışır(Bloomer 1992) (Wang, Zhao, and Zhu 1993).

gRPC, HTTP/2 protokolü üzerinde çalışan bir Uzak Prosedür Çağrısı çerçevesidir.gRPC, Google tarafından 2015 yılında açık kaynak olarak tanıtılan, RPC’nin modern ve yüksek performanslı bir uyarlamasıdır; bu, yazılım dil, işletim sistemi ve platform bağımsızlığı açısından nötr bir arayüz tanım dilidir. HTTP/2.0 protokolü üzerine inşa edilen gRPC, binary veri aktarımı için Protocol Buffers (Protobuf) kullanır ve çoklama (multiplexing), başlık sıkıştırma, çift yönlü akış, çoklama ve verimli serileştirme gibi HTTP/2.0 özelliklerinden faydalanır(Bolanowski et al. 2022).

RPC, bir prosedürün uzaktan çağrılmasına yönelik temel ve soyut bir mekanizmayken, gRPC, bu mekanizmayı Protocol Buffers ve HTTP/2 gibi modern teknolojilerle birleştirerek yüksek performanslı, dayanıklı ve platformlar arası uyumlu bir çerçeve (framework) olarak geliştirmiştir. Özellikle mikroservis tabanlı mimarilerin yaygınlaşmasıyla birlikte, servisler arası düşük gecikmeli ve yüksek verimli iletişim ihtiyacı, gRPC’nin özellikleri, modern internet ekosistemlerinin taleplerine yanıt vererek dağıtık sistemlerin ve mikro servis mimarilerinde önemli bir rol oynamaktadır.

Tablo 3 karşılaştırmalı olarak, REST, GraphQL ve gRPC teknolojilerinin kıyaslıyarak, teorik çerçeve, avantajlar, dezavantajlar ve uygulama alanları özet şeklinde göstermektedir.

REST, yüksek kullanım ve standartlaşmış yapısı sayesinde geniş çapta benimsenmiş olsa da, veri verimliliği ve gerçek zamanlı aktarım açısından modern ihtiyaçlara tam cevap veremeyebilir.

GraphQL, istemci odaklı veri sorgulama yetenekleriyle öne çıkar ve web geliştiriciler için uygun bir seçenek sunar; ancak karmaşık yetkilendirme, önbellekleme ve işleme performansı dikkate alınmalıdır.

gRPC, mikroservis mimarilerinde, düşük gecikmeli sistemlerde ve gerçek zamanlı veri akışı gereken durumlarda performans avantajı sunar, ancak entegre etmesi ve güvenlik gereksinimleri diğerlerine göre daha karmaşık düzeydedir.

Özellik REST GraphQL gRPC
Mimari Tarz Resource-based (Kaynak tabanlı) Query-based (Sorgu tabanlı) RPC-based (Uzaktan prosedür çağrısı)
Veri Formatı JSON, XML, YAML JSON Protobuf (binary, hızlı & küçük)
Performans Orta Orta Yüksek (Binary + HTTP/2)
İstemci-Tarafı Kontrolü Az Yüksek (İstemci ne isterse belirler) Düşük (Sunucuya bağlı metodlar)
Şema Tanımı Yok Zorunlu (GraphQL Schema) Zorunlu (Protobuf .proto dosyaları)
Sürümleme (Versioning) URL veya header tabanlı Şema üzerinde çözülür Protobuf üzerinden yönetilir
Veri Aşırı/ Eksikliği Evet (Over-fetching / Under-fetching) Hayır (Tam ihtiyaca uygun veri) Yönetime bağlı
Hata Yönetimi HTTP status kodları Genelde 200 + error object Status codes (gRPC status)
Gerçek Zamanlı İletişim WebSocket gerekir Subscription ile desteklenir Native streaming (bi-directional)
Dil Desteği Evrensel Evrensel Çoğu dil destekli
Tarayıcı Desteği Yüksek Yüksek Düşük (gRPC-Web eklentisi gerekir)
Geliştirme Kolaylığı Kolay Orta Orta-Zor (Protobuf tanımı gerekir)
Tip Güvenliği Düşük Orta (GraphQL Schema ile) Yüksek (Protobuf ile sıkı tip)
Önbellekleme Kolay (HTTP Cache) Zor (Özel çözümler gerekir) Zor (Genelde özel çözümler gerekir)
Ağ Trafiği / Bant Genişliği Orta Genellikle daha az Çok düşük (binary format)
Kullanım Alanı Web API’leri, mobil uygulamalar Karmaşık veri ilişkileri, tek endpoint isteyen istemciler Mikroservis içi iletişim, yüksek performanslı sistemler
İletişim Protokolü HTTP/1.1, HTTP/2 HTTP/1.1, HTTP/2 HTTP/2

Tablo 3: REST, GraphQL ve gRPC özellikleri



Şekil 4: REST, GraphQL ve gRPC performans karşılaştırması

2024 yılında Niswar ve arkadaşları tarafından yayınlanan "Performance evaluation of microservices communication with REST, GraphQL, and gRPC" isimli çalışma mikroservis mimarisi üzerinde kullanılan REST, GraphQL, ve gRPC methodlarının performans analizini ve testlerini değerlendirmektedir.

Endonezya Eğitim ve Kültür Bakanlığı’na ait entegre bilgi sistemi olan SISTER üzerinde elde edilen 2.221 adet öğretim görevlisi profili(flat) ve 6.197 adet öğretim görevlisi + eğitim bilgi(nested) verisi ile gerçekleştirilmiştir. Her protokol hem tek düzey veri (flat data) hemde karmaşık (nested) veriler üzerinde test edilmiştir. Çalışma sonucunda elde edilen performans karşılaştırmaları hem istek cevap süresi hem veri işleme için kullan CPU yüzdesi olarak Şekil 4 gösterilmektedir.

Çalışmanın sonucuna göre REST, GraphQL ve gRPC protokolleri arasında yapılan değerlendirmede, gRPC hem yanıt süresi hem de CPU kullanımı açısından en yüksek performansı sergilemiştir. Bu üstünlüğün ana nedeni, gRPC’nin HTTP/2 protokolünü kullanmasıdır. HTTP/2, daha verimli veri alışverişi sağladığı için gRPC’nin avantajını artırmıştır.

WebSocket

WebSocket protokolü, web uygulamaları için tasarlanmış, bir istemci ile sunucu arasında iki yönlü iletişim sağlamak amacıyla bir standarttır. Protokol, 2011 yılında HTTP/1.1 üzerine inşa edilerek Internet Engineering Task Force (IETF) tarafından RFC6455 olarak standartlaştırılmıştır(Melnikov and Fette 2011). Protokol, bir el sıkışma (handshake) ile başlayan ve ardından gelen mesajlardan oluşur. Amaç, bir web tarayıcısı ile bir sunucu arasında birden çok paralel HTTP bağlantısı açmadan iki yönlü iletişim sağlamakdır(Nadeem et al. 2024).

WebSocket, TCP’nin üzerine oturduğundan, bir WebSocket bağlantısı kurulmadan önce bir TCP bağlantısı gerekir. Bir TCP bağlantısı klasik üçlü el sıkışma ile üç mesajla gerçekleştirilir: SYN, SYN-ACK ve ACK. Daha sonra istemci, bir HTTP GET isteği üzerinden başlık (header) ile bir UpgradeRequest gönderir. Sunucu UpgradeResponse aynı şekilde başlık (header) ile yanıt verirse, istemci sunucu ile başarılı bir şekilde bir WebSocket bağlantısı kurulmuş olur. Ancak HTTP/2 bu mekanizmanın ve başlığın kullanımına açıkça izin vermez; bu durum HTTP/1.1’e özgüdür. HTTP/2 üzerinde WebSocket kullanmak için HTTP/2 ile eklenen CONNECT methodunu kullanılması gerekmektedir bu durum RFC 8441 ile standartlaşmıştır(McManus 2018). Ancak HTTP/2 üzerinde ek performans katkısı gözlenemeyecektir bunu sebebi veri iletim doğrudan TCP üzerinden yapılmasıdır.

WebSocket bağlantıları WSS (WebSocket Secure) protokolü ile şifrelenebilir. Ayrıca CORS (Cross-Origin Resource Sharing) politikaları ve origin doğrulaması gibi güvenlik mekanizmaları uygulanmalıdır. WebSocket kullanımı, güvenlik endişelerini geride bırakarak XSS ve veri interception gibi zayıf yönlere yol açtı. Ancak, teknoloji ilerledikçe, geliştiriciler ve akademisyenler bu hataları çözmeye odaklandılar. Bu ilerleme, özellikle WS iletişimi için tasarlanmış güçlü güvenlik mekanizmaları ve standartlarının ortaya çıkmasına neden oldu. Ayrıca, şifreleme algoritmalarındaki ve kimlik doğrulama süreçlerindeki gelişmeler, WS’nin bütünlüğünü ve gizliliğini artırdı. Siber güvenlik endüstrisindeki iş birliği girişimleri ve düzenleyici çerçeveler, WS güvenlik standartlarını iyileştirmeye yardımcı oldu(Murley et al. 2021).

HTTP request-response modeli ile çalışırken, WebSocket event-driven bir model sunar. HTTP’de sunucu yalnızca istemci talebi üzerine yanıt verirken, WebSocket’te sunucu proaktif olarak veri gönderebilir. Bu özellik, polling gibi inefficient yöntemlerin yerine geçer. WebSocket’in asenkron ve event-driven yapısı, modern web uygulamalarında gerçek zamanlı deneyimler oluşturmak için temel bir teknoloji haline gelmiştir.

2022 yılında yayınlanan Kaminski ve arkadaşlarının yaptığı çalışma REST, WebSocket, gRPC ve GraphQL internet iletişim protokollerinin karşılaştırmalı bir incelemesini sunmaktadır. Araştırmanın temel amacı, yazılım mimarilerinde servisler için en uygun iletişim protokolünü seçmelerine yardımcı olmaktır(Zaniewski and Roszczyk 2023).

Her protokol için, Python yazılım ortamındaki açık kaynaklı kütüphaneleri kullanarak bir veritabanında CRUD işlemleri için bir arayüz sağlayan bir web servisi geliştirilmiştir. Protokollerin performansını değerlendirmek için, bir istek ile cevap arasında geçen toplam zamanı ve gereken veri iletim boyut ölçülmüştür. Tüm karşılaştırmalar, Windows 10 işletim sistemine sahip bir platformda gerçekleştirilmiştir. Gerçek zamanlı bir sistemin metriklerinin değerlendirme sonuçları üzerindeki etkisini en aza indirmek için test makinesinde arka planda çalışan hiçbir görev olmadığını sağlanarak sanallaştırılmış bir ortamın performansını test etmek için sanallaştırma platformu olarak Docker Desktop 4.6.1 kullanılmıştır. Sonuçların daha iyi karşılaştırılabilir olması için tüm uygulamalarda 3.9.12 sürümündeki aynı Python yorumlayıcısı kullanılmıştır.


Şekil 5: REST, GraphQL, gRPC ve WebSoket bir ve yüz öğge alma performans karşılaştırması

Şekil 5 gösterilen performans testleri sonuçlarına göre, farklı protokollerinin platform bazında değişen davranışlar sergilediği gözlemlenmiştir. Tek öğe ekleme işlemlerinde, Docker konteyner ortamında REST protokolü en yüksek performansı gösterirken, yerel işletim sistemi üzerinde gRPC protokolü en iyi sonuçları vermiştir. GraphQL protokolü ise yerel ortamda Docker platformına kıyasla düşük performans sergilemiştir. Tek öğe getirme operasyonlarında, her iki platform ortamında da gRPC protokolü en yüksek hıza ulaşırken, GraphQL protokolü en düşük performansı göstermiştir. Yüz öğe getirme işlemlerinde gRPC protokolü yine en hızlı sonuçları verirken, WebSockets protokolü hem en yavaş hem de en az kararlı protokol olarak tespit edilmiştir. Bu bulgular, protokol seçiminin hem işlem türüne hem de platform özelliklerine bağlı olarak optimize edilmesi gerektiğini ortaya koymaktadır(Zaniewski and Roszczyk 2023).

Çalışmada yapılan testlere göre, gRPC protokolünün istemci ve sunucu arasında veri iletiminde en hızlı olduğunu göstermektedir. WebSockets protokolü, iletilen veri küçük olduğunda (bir öğe ekleme ve alma) REST’e benzer sonuçlar elde etmektedir. Veri daha büyük olduğunda (yüz öğe ile gerçekleştirilen test) en yavaş olduğu ortaya çıkmaktadır. REST ise orta hızda bir performans göstermiştir. GraphQL küçük verilerle bazı sorunlar yaşamaktadır. Yüz öğeyi alma işlemlerinde WebSockets’ten biraz daha hızlı olduğu anlaşılmaktadır. Ortaya çıkan diğer sonuç ise, Docker platformunun yerel işletim sistemine göre daha az stabil olduğudur.


Şekil 6: REST, GraphQL, gRPC ve WebSoket mesaj boyutu (byte)

Şekil 6 her protokol ve işlemde kaç byte aktarıldığını göstermektedir. Sunulan görsel, tartışmasız olarak, WebSocket diğer iletişim protokolleri arasında en iyi bellek kullanımını olduğunu gösteriyor. Hem veri alma hem de veri ekleme işlemlerinde en iyi sonuca ulaşmaktadır. Diğer protokoller, özellikle bu karşılaştırmada en fazla bellek tüketen iletişim mekanizması olan gRPC, göze çarpan şekilde daha fazla kaynak kullanmaktadır. Ayrıca, bellek kullanımının protokollerin performansıyla bir şekilde ilişkili olduğu ilişkilendirilmiştir. WebSocket, performan olarak düşük kalmasına rağmen veri transferi için en az bellek kullandığı ortaya çıkmaktadır. Tam tersi olarak gRPC için en iyi performansı göstermesine karşın aynı zamanda en fazla bellek tüketen protokoldür.

Elde edilen sonuçlar ve yazarların genel yorumlarına göre, yazılım mimarilerinde servisler ihtiyaçlarına göre seçilecek ve kullanılacak protokolleri performans, veri iletim boyutu, kullanım kolaylığı ve yaygılığı açısında değişkenlik gösterebilmektedir.

Server-Sent Events (SSE)

Server-Sent Events (SSE), web uygulamalarında sunucudan istemciye gerçek zamanlı veri akışı sağlamak için kullanılan bir HTML5 standardıdır. HTTP 1.1 protokolü üzerine inşa edilen bu teknoloji, istek-yanıt mimarisinin aksine, sunucunun istemciye sürekli olarak veri göndermesine olanak tanır. SSE, özellikle tek yönlü iletişimin yeterli olduğu senaryolarda WebSocket’lere göre daha basit ve hafif bir alternatif sunar.

SSE’nin teknik mimarisi, HTTP/1.1’in "chunked transfer encoding" özelliğini temel alır ve "text/event-stream" MIME türünü kullanır. İstemci, EventSource API’si aracılığıyla sunucuya bir HTTP GET isteği gönderir ve sunucu bu bağlantıyı açık tutarak periyodik olarak veri paketleri iletir. Her veri paketi, "data:", "event:", "id:" ve "retry:" gibi özel alanlarla formatlanır ve istemci bu olayları dinamik olarak işler. SSE’nin temel avantajları arasında basitlik, düşük kaynak tüketimi ve mevcut HTTP altyapısıyla uyumluluk yer alır. HTTP/1.1 ve HTTP/2.0 (kısmen destek) ile çalışabilen SSE, otomatik yeniden bağlanma (reconnection) mekanizmasıyla bağlantı kesintilerinde dayanıklılık sağlar(Torre et al. 2019).


Şekil 7: Server-Sent Events ve WebSocket karşılaştırması

Şekil 7 gösterilen parformans karşılaştırması Słodziak ve arkadaşları tarafından "Performance Analysis of Web Systems Based on XMLHttpRequest, Server-Sent Events and WebSocket" isimli çalışmada gösterilmektedir. Tek yönlü iletişim ve HTTP tabanlı yapısı sayesinde düşük maliyetle yeterli performans sunar. Ancak sürekli açık tutulan bir HTTP bağlantısıyla çalıştığı için, bağlantı başına kaynak tüketimi daha yüksektir ve yüksek frekanslı, çift yönlü veri gereksinimleri için uygun değildir. WebSocket ise tam çift yönlü, sürekli açık bir TCP bağlantısı üzerinden çalışan düşük gecikmeli bir protokoldür. Ayrıca WebSocket bağlantıları HTTP/2 ve HTTP/3 ortamlarında daha etkili çalışabilirken, SSE HTTP/2 ile çeşitli uyumsuzluk problemleri yaşayabilir. Özetle, düşük veri hacmi ve tek yönlü iletim için SSE yeterli olabilirken, performans gerektiren senaryolarda WebSocket tercih edilmelidir(Słodziak and Nowak 2016).

Sonuç ve Tartışma

Çalışma HTTP protokolünün tarihsel gelişimi, sürüm evrimleri ve modern web iletişim yöntemlerinin detaylı analizi gerçekleştirilmiştir. HTTP’nin 1991 yılında Tim Berners-Lee tarafından geliştirilmesinden günümüzün HTTP/3 standardına kadar olan yolculuk, web teknolojilerinin sürekli gelişen doğasını ve performans optimizasyonu arayışlarını açıkça ortaya koymaktadır. HTTP/0.9’dan başlayarak her sürümün kendine özgü yenilikleri ve iyileştirmeleri bulunmakta olup, HTTP/1.1 ile kalıcı bağlantılar, HTTP/2 ile multiplexing ve HTTP/3 ile QUIC protokolü entegrasyonu gibi kritik gelişmeler web performansında devrim niteliğinde değişiklikler sağlamıştır.

Yapılan performans analizleri, HTTP/3’ün özellikle yüksek gecikme süreli ağlarda ve paket kaybının yaşandığı durumlarda HTTP/2’ye kıyasla daha iyi performans sergilediğini göstermektedir. HTTP/2’nin head-of-line blocking problemini çözmesi ve stream multiplexing özelliği sayesinde HTTP/1.1’e göre performans artışı sağladığı ortaya çıkmaktadır.

Modern web iletişim yöntemlerinin karşılaştırmalı analizi, her metodun belirli kullanım senaryolarında öne çıktığını göstermektedir. REST mimarisinin basitliği ve yaygın desteği sayesinde günümüzde yaygın olarak tercih edildiği görülmekte olup, özellikle CRUD operasyonları için ideal çözüm sunmaktadır. SOAP’ın kurumsal ortamlarda güvenlik ve işlem bütünlüğü gereksinimleri nedeniyle hala tercih edilmesi, protokol çeşitliliğinin önemini vurgulamaktadır. gRPC’nin mikroservis mimarilerinde daha yüksek performans sağlaması, modern dağıtık sistemlerde avantajlarını ortaya koymaktadır. GraphQL’in sorgu esnekliği ve over-fetching problemini çözmesi, özellikle mobil uygulamalarda veri tasarrufu sağlayarak modern web geliştirme mimarilerinde önemli bir yer edinmesini sağlamıştır.

Gerçek zamanlı iletişim protokollerinden WebSocket’in full-duplex iletişim kabiliyeti, geleneksel HTTP istek-cevap mekanizmasının sınırlarını aştığını ve gerçek zamanlı uygulamaları için vazgeçilmez hale geldiğini göstermektedir. Server-Sent Events’in tek yönlü veri akışı senaryolarında daha düşük kaynak tüketimi sağlaması, doğru protokol seçiminin sistem verimliliği açısından kritik önemde olduğunu kanıtlamaktadır.

Gelecek çalışmalarda, HTTP/4’ün potansiyel geliştirme alanları arasında yapay zeka destekli adaptif protokol optimizasyonu, edge computing entegrasyonu ve IoT cihazları için özelleştirilmiş hafif sürümler üzerine çalışmalar yapılmaktadır. Özellikle 5G ağlarının yaygınlaşması ile birlikte ultra-düşük gecikme süreli uygulamaların artması, HTTP protokol ailesinin bu yeni gereksinimlere adapte olması için sürekli evrim geçirmesi gerekliliğini ortaya koymaktadır.

Sonuç olarak, HTTP protokolünün ve modern web iletişim yöntemlerinin gelişimi, teknoloji evriminin kullanıcı ihtiyaçları ve performans gereksinimleri tarafından gelişiminin gerçekleştiği göstermektedir. Bu çalışmanın bulguları, protokol seçimi ve optimizasyonu konularında sistem mimarları ve geliştiriciler için rehber sağlamaktadır.

Osman Şakir Kapar
İstanbul Üniversitesi-Cerrahpaşa
Lisansüstü Eğitim Enstitüsü
Bilgisayar Mühendisliği Ana Bilim Dalı
omansak.com
Haziran 2025

  1. Bajrami, Enes, Agon Memeti, Florim Idrizi, and Ermira Memeti. 2024. “COMPARATIVE ANALYSIS OF SOAP AND REST APIs: SYSTEMATIC REVIEW AND PERFORMANCE EVALUATION WITH PYTHON.” JNSM Journal of Natural Sciences and Mathematics of UT 9 (17-18): 228–43.
  2. Belshe, Mike, Roberto Peon, and Martin Thomson. 2015a. “Hypertext Transfer Protocol Version 2 (HTTP/2).”
  3. ———. 2015b. “Hypertext Transfer Protocol Version 2 (HTTP/2).” Request for Comments. RFC 7540; RFC Editor. https://doi.org/10.17487/RFC7540.
  4. Bishop, Mike. 2021. “HTTP/3.” Internet-Draft draft-ietf-quic-http-34. Internet Engineering Task Force; Internet Engineering Task Force. https://datatracker.ietf.org/doc/draft-ietf-quic-http/34/.
  5. ———. 2022. “HTTP/3.” Request for Comments. RFC 9114; RFC Editor. https://doi.org/10.17487/RFC9114.
  6. Bloomer, John. 1992. Power Programming with RPC. " O’Reilly Media, Inc.".
  7. Bolanowski, Marek, Kamil Żak, Andrzej Paszkiewicz, Maria Ganzha, Marcin Paprzycki, Piotr Sowiński, Ignacio Lacalle, and Carlos E Palau. 2022. “Eficiency of REST and gRPC Realizing Communication Tasks in Microservice-Based Ecosystems.” In New Trends in Intelligent Software Methodologies, Tools and Techniques, 97–108. IOS Press.
  8. Brito, Gleison, and Marco Tulio Valente. 2020. “REST Vs GraphQL: A Controlled Experiment.” In 2020 IEEE International Conference on Software Architecture (ICSA), 81–91. IEEE.
  9. Corbel, Romuald, Emile Stephan, and Nathalie Omnes. 2016. “HTTP/1.1 Pipelining Vs HTTP2 in-the-Clear: Performance Comparison.” In 2016 13th International Conference on New Technologies for Distributed Systems (NOTERE), 1–6. IEEE.
  10. Fielding, Roy Thomas. 2000. “Architectural Styles and Thedesign of Network-Based Software Architectures.” PhD Thesis, University of California.
  11. Fielding, Roy T., Henrik Nielsen, Jeffrey Mogul, Jim Gettys, and Tim Berners-Lee. 1997. “Hypertext Transfer Protocol – HTTP/1.1.” Request for Comments. RFC 2068; RFC Editor. https://doi.org/10.17487/RFC2068.
  12. Fielding, Roy, Jim Gettys, Jeffrey Mogul, Henrik Frystyk, Larry Masinter, Paul Leach, and Tim Berners-Lee. 1999. “Hypertext Transfer Protocol–HTTP/1.1.”
  13. Gasser, Linus. 2023. “WEB3.” Trends in Data Protection and Encryption Technologies, 209–13.
  14. Halili, Festim, Erenis Ramadani, et al. 2018. “Web Services: A Comparison of Soap and Rest Services.” Modern Applied Science 12 (3): 175.
  15. Krishnamurthy, Balachander, Jeffrey C Mogul, and David M Kristol. 1999. “Key Differences Between HTTP/1.0 and HTTP/1.1.” Computer Networks 31 (11-16): 1737–51.
  16. Kumar, Anuj, Raja Kumar Murugesan, Harshita Chaudhary, Neha Singh, Kapil Joshi, and Umang. 2023. “Speed Analysis on Client Server Architecture Using HTTP/2 over HTTP/1: A Generic Review.” In International Conference on Emerging Trends in Expert Applications & Security, 397–403. Springer.
  17. Kumari, Smita, and Santanu Kumar Rath. 2015. “Performance Comparison of Soap and Rest Based Web Services for Enterprise Application Integration.” In 2015 International Conference on Advances in Computing, Communications and Informatics (ICACCI), 1656–60. IEEE.
  18. McManus, Patrick. 2018. “Bootstrapping WebSockets with HTTP/2.” Request for Comments. RFC 8441; RFC Editor. https://doi.org/10.17487/RFC8441.
  19. Melnikov, Alexey, and Ian Fette. 2011. “The WebSocket Protocol.” Request for Comments. RFC 6455; RFC Editor. https://doi.org/10.17487/RFC6455.
  20. Mikuła, Mateusz, and Mariusz Dzieńkowski. 2020. “Comparison of REST and GraphQL Web Technology Performance.” Journal of Computer Sciences Institute 16: 309–16.
  21. Murley, Paul, Zane Ma, Joshua Mason, Michael Bailey, and Amin Kharraz. 2021. “Websocket Adoption and the Landscape of the Real-Time Web.” In Proceedings of the Web Conference 2021, 1192–1203.
  22. Nadeem, Malik Muhammad, Yousaf Raza, Ahthasham Sajid, Hamza Razzaq, Rida Malik, and Sugandima Vidanagamachchi. 2024. “Review Analysis of Web Socket Security: Case Study.” IETI Transactions on Data Analysis and Forecasting 2 (2): 56–75.
  23. Nielsen, Henrik, Roy T. Fielding, and Tim Berners-Lee. 1996. “Hypertext Transfer Protocol – HTTP/1.0.” Request for Comments. RFC 1945; RFC Editor. https://doi.org/10.17487/RFC1945.
  24. Nielsen, Henrik, Jeffrey Mogul, Larry M Masinter, Roy T. Fielding, Jim Gettys, Paul J. Leach, and Tim Berners-Lee. 1999. “Hypertext Transfer Protocol – HTTP/1.1.” Request for Comments. RFC 2616; RFC Editor. https://doi.org/10.17487/RFC2616.
  25. Perna, Gianluca, Martino Trevisan, Danilo Giordano, and Idilio Drago. 2022. “A First Look at HTTP/3 Adoption and Performance.” Computer Communications 187: 115–24.
  26. Ploscar, Adina. 2012. “XML-RPC Vs. SOAP Vs. REST Web Services in Java–Uniform Using WSWrapper.” International Journal of Computers, no. 4.
  27. Rescorla, Eric. 2018. “The Transport Layer Security (TLS) Protocol Version 1.3.” Request for Comments. RFC 8446; RFC Editor. https://doi.org/10.17487/RFC8446.
  28. Seabra, Matheus, Marcos Felipe Nazário, and Gustavo Pinto. 2019. “Rest or Graphql? A Performance Comparative Study.” In Proceedings of the XIII Brazilian Symposium on Software Components, Architectures, and Reuse, 123–32.
  29. Słodziak, Wojciech, and Ziemowit Nowak. 2016. “Performance Analysis of Web Systems Based on Xmlhttprequest, Server-Sent Events and Websocket.” In Information Systems Architecture and Technology: Proceedings of 36th International Conference on Information Systems Architecture and Technology–ISAT 2015–Part II, 71–83. Springer.
  30. Torre, Luis de la, Jesus Chacon, Dictino Chaos, Sebastián Dormido, and José Sánchez. 2019. “Using Server-Sent Events for Event-Based Control in Networked Control Systems.” IFAC-PapersOnLine 52 (9): 260–65.
  31. Wang, Xingwei, Hong Zhao, and Jiakeng Zhu. 1993. “GRPC: A Communication Cooperation Mechanism in Distributed Systems.” ACM SIGOPS Operating Systems Review 27 (3): 75–86.
  32. Zaniewski, Patryk, and Rados law Roszczyk. 2023. “Comparative Review of Selected Internet Communication Protocols.”
Tags
OMANSAK

Gönderen OMANSAK