Yeni web iletişim yöntemi Websocket protokolünün geleneksel yöntemlerle karşılaştırılması

Transkript

1 EEB 216 Elektrik-Elektronik ve Bilgisayar Sempozyumu, Mayıs 216, Tokat TÜRKİYE Yeni web iletişim yöntemi protokolünün geleneksel yöntemlerle karşılaştırılması Onur CÖMERT 1 Mahmut HEKİM 2 1 Gaziosmanpaşa Üniversitesi, Mekatronik Mühendisliği 2 Gaziosmanpaşa Üniversitesi, Elektrik-Elektronik Mühendisliği 1 onur.comert@gop.edu.tr 2 mahmut.hekim@gop.edu.tr Özet İnternet, hızlı büyüyen bilgi çağında insan hayatının vazgeçilmez bir parçası haline gelmiştir. Bu talebe cevap olarak web tabanlı uygulamaların sayısı da artmaktadır. Web tabanlı uygulamalar istemci ve sunucu tarafı olmak üzere iki birim halinde çalışmaktadır. İstemci tarafı genellikle bir web tarayıcısıdır. Sunucudan içerik talebinde bulunur. Sonuç olarak sunucu, istemciye gerekli bilgileri sağlar. Sunucu ile istemci arasındaki iletişimi gerçekleştirmek için genelde, Long ve Comet web iletişim yöntemleri kullanılmaktadır. Bu çalışmada yeni web iletişim yöntemi olan, Long ile karşılaştırılmıştır. Bunun için bir web sunucusu ve bir istemci bilgisayar kullanılmıştır. Sunucuda biri yöntemi ile diğeri ise Long yöntemi ile bağlantıyı kabul eden iki ayrı web sayfası hazırlanmıştır. Bu web sayfalarını görüntülemek için bir tarayıcı kullanan istemci bilgisayar sunucu üzerinde bulunan veriyi farklı büyüklükte parçalar halinde ve belli aralıklarla kendi belleğine indirmektedir. Yapılan diğer deneylerde ise istemci bilgisayar, farklı büyüklüklerdeki veriyi belli aralıklarla sunucuya göndermektedir. Karşılaştırma, kullanılan bant genişliğine göre yapılmıştır. Elde edilen deney sonuçları karşılaştırılarak yönteminin Long yöntemine göre avantaj ve dezavantajları sunulmuştur. 1. Giriş Internet, hızlı büyüyen bilgi çağında insan hayatının vazgeçilmez bir parçası haline gelmiştir. Gittikçe daha fazla insan başkalarıyla iletişim kurmak, oyun oynamak, içerik sağlamak, bilgi edinmek vb. işlemler için interneti kullanmakta ve bu etkinliklere daha fazla vakit ayırmaktadır. Oluşan bu talebe cevap olarak Web tabanlı uygulamaların sayısı da gittikçe artmaktadır. Web tabanlı uygulamalar istemci ve sunucu tarafı olmak üzere iki birim halinde çalışmaktadır. İstemci tarafı genellikle bir Web tarayıcısıdır. Sunucudan içerik talebinde bulunur. Sunucu cihaz üzerinde istemcilerin talep edeceği içerikler depolanır. Ayrıca mantıksal süreçler ve işlemlerin çoğu sunucu tarafında gerçekleşir. Sonuç olarak sunucu, istemciye gerekli bilgileri sağlar. Web tabanlı uygulama geliştirmenin avantajları şöyle sıralanabilir: Birincisi platform bağımsızdır. Bir Web tarayıcı yeterlidir. İkincisi, geliştirmek kolaydır. Web tabanlı uygulamalar geliştirmek için temelde HTML (Hyper Text Markup Language) dili kullanılır. Üçüncüsü, yeni bir sürümün dağıtımı kolaydır. Kullanıcılar bir Web uygulamasının son çıkan sürümünü bilgisayarlarında çalıştırmak istediklerinde Web sunucuya bağlanarak onu kolayca elde edebilirler. Web tabanlı uygulamaların yukarıda bahsedilen avantajlarının yanı sıra birçok dezavantajı da bulunmaktadır. İstemciler sunucu ile bağlantı kurmak için bir HTTP (Hyper Text Transfer Protocol) bağlantısı kurmak zorundadırlar. Ama HTTP tek yönlü bir iletişim protokolüdür. Yani bu protokolde iletişim yalnızca bir istemcinin isteği ile meydana gelir. istemci için veri güncellemesi olup olmadığının sürekli olarak kontrol edilmesi nedeniyle çok sayıda gereksiz istek yapılmaktadır [1]. Bu dezavantajları ortadan kaldırmak amacıyla birçok yöntem geliştirilmiştir. AJAX tabanlı HTTP Long ve Comet bunlardan en önemlileridir. HTTP Long yönteminde, istemcinin talep edeceği veride bir değişiklik olana kadar ya da belli bir zaman aşımı süresi dolana kadar bağlantı açık kalmaktadır. Böylece hem Web tarayıcısında sayfaları tekrar yüklemeden değişen 158

2 EEB 216 Elektrik-Elektronik ve Bilgisayar Sempozyumu, Mayıs 216, Tokat TÜRKİYE içerikler elde edilebilmekte hem de sunucu istemciye boş mesaj göndermemektedir. Bu tekniğin çekincesi, aynen HTTP te olduğu gibi birkaç saniyede bir veride değişiklik olup olmadığının sorgulanması gerekmektedir [1,2,3]., W3C (World Wide Web Consortium) tarafından belirlenen JS API ve IETF protokollerini kapsamaktadır. API henüz standartlaştırılmamıştır. Yine de birçok Web tarayıcısı onu son şekliyle bünyesine dâhil etmiştir. TCP (Transmission Control Protocol) üzerinde çalışan bir ağ protokolüdür. Web tarayıcılarında ve Web sunucularında çalıştırılmak için tasarlanmıştır ama başka amaçlar için de kullanılabilir. HTTP protokolünden bağımsız olmasına rağmen bir bağlantının başlatılması için gereken handshake (el sıkışma) işlemi yönünden benzerlikler arz eder. sunucular HTTP ile aynı portu (TCP 8 ya da 443) kullanırlar [4,5,6]., TCP Web uygulamaları olarak bilinir ve TCP bağlantı (three-way-handshake) ile çok fazla benzerliklere sahiptir. İlk önce istemci sunucuya bir HTTP isteğinde bulunur. Bu istek, Upgrade eklentili başlık bilgisine sahiptir. Bu, HTTP isteğinin li bir handshake istek olduğu anlamına gelir. Sonra sunucu HTTP isteğini alır, istek içindeki bilgileri analiz eder ve o istemci için bir güvenlik anahtarı oluşturur. Bu noktaya değin bağlantısının oluşumu tamamlanır ve artık bu bağlantı aracılığıyla her iki taraf (sunucu ve istemci) birbirine veri iletebilir. Bağlantı oluşturulduktan sonra, sunucuya bir oturum numarası gönderilecektir. Bu numara yalnızca belli bir Socket i belirtir. Sunucu, kendisiyle bağlantıya geçen bütün istemcileri yönetebilmek için bir oturum numara listesi muhafaza eder. İstemci tarafında tarayıcı kapatıldığında sunucu bir uyarı mesajı alır ve sonra tarayıcı ve ona bağlı kaynaklar sunucunun istemci listesinden silinmeye başlar [5,6]. in ortaya çıkışının asıl amacı Comet ve HTTP (ve HTTP Long ) in yerine geçmek ve gerçek zamanlı Web uygulamalarının vasat durumunu iyileştirmektir. HTTP üzerindeki alışılmış iletişim yöntemi ile karşılaştırıldığında in temel farkı geleneksel istek/cevap standardını takip etmemesidir. veri işlemek için daha düşük işletim kaynağına gereksinim duyar. Periyodik olarak küçük verilerin taşınması gereken durumlarda daha az ağ trafiği gerektirir., sıradan HTTP yöntemi ile karşılaştırıldığında ağ trafiğini 5:1 oranına kadar düşürebilir [5,7]. Çünkü bağlantısında her bir çerçeve boyutu 2 bayttır. Long te ise 1 KB ı geçer. te, her bir HTTP mesajı göndermek amacıyla yeni bir TCP bağlantı kurulmaz. Böylece bunun için gereken bir gecikme de olmaz [1]. protokolünün iletişim performansını ve uygulanabilirliğini sınamak ve diğer iletişim metotlarıyla karşılaştırmak amacıyla birçok çalışma yapılmıştır. Bu çalışmalarda genellikle çeşitli alanlarda tabanlı uygulamalar önerilmiş ve bunlar üzerinde deneyler yapılarak sonuçlar değerlendirilmiştir. Örneğin: Chen ve Xu, yaptıkları çalışmada, HTML5 ile Web tarayıcı tabanlı çok oyunculu oyunların real-time performansını ve uygulanabilirliğini araştırmak amacıyla WebGL (Web-based Graphics Library) ve kullanan oyun sistemleri için bir framework tasarlamışlardır. Sonuç olarak ve WebGL teknolojilerinin tarayıcı tabanlı çok oyunculu oyunların gelişimini kesinlikle destekleyeceğini vurgulamışlardır [8]. Yapılan bir diğer çalışmada Furukawa, kullanılan bir Web tabanlı kontrol yazılımı geliştirmiştir. Bu uygulamaya erişmek için hem bilgisayar hem de mobil ortamlarda farklı tarayıcılar kullanmıştır. Aldığı başarılı sonuçlar ile protokolünün Web uygulamalarında kullanılabileceği göstermiştir [4]. Swamy ve Mahadevan ise bir istemci/sunucu iletişim sistemi önermişler ve yaptıkları çalışmada protokolü kullanarak, ortalama gecikmenin 15ms den 5ms ye azaldığını ve in, bant genişliği ve ölçeklenebilirlik açısından Long den çok daha iyi performans sergilediğini belirtmişlerdir [1]. Daha sonra Jiang ve Duan, Web iletişimine dayalı çalışan bir WTC (Web Tree Component) geliştirmişlerdir. Uygulamayı, HTTP Long, Comet ve kullanılarak test etmişlerdir. Diğer iki yöntemle karşılaştırıldığında teknolojisine dayalı programın, sunucu yükünü azaltmada, ağ bağlantı kesintilerini düşürmede ve real-time bağlantıda büyük avantajlara sahip olduğunu vurgulamışlardır. Ayrıca, etkili bir WTC iletişimi sağladığını ve düğüm veri iletim miktarını düşürerek WTC nin temeli olan ağaç yapısının genişleme hızını artırabileceğini belirtmişlerdir [2]. Yine Pimentel ve Nickerson, iletişiminin HTML den daha hızlı olup olmadığını anlamak için, 4 Hz hızında gönderilen gerçek zamanlı rüzgar sensör verisinin tek yönlü iletim gecikmesini ölçmek için bir Web uygulaması gerçekleştirmiştir. gecikmesini HTTP ve Long ile karşılatırmışlardır. Sonuçta metodundaki ortalama gecikmenin, veya Long e göre 2.3 ila 4.5 kat daha fazla olduğunu saptamışlardır. Sunucuya daha uzak mesafe bulunan istemcilerde ise te, Long e göre 3.8 ila 4 kat daha az ortalama gecikeme olduğunu tespit etmişlerdir [3]. Bu sonuçlar da gösteriyor ki real-time internet bağlantılarında ortalamada daha mantıklı bir yöntemdir. Daha sonra Zhangling ve Mao, yaptıkları çalışmada tabanlı bir grup iletişim yazılımı önermişlerdir. tabanlı iletişim modülü, sistemin cevap verme yeteneğini artıran iki yönlü ve eş zamanlı olmayan bir şekilde istemci ile iletişim kurmaktadır. Yaptıkları testlerde sunucuya sürekli olarak 1 baytlık mesaj göndermişlerdir. Toplamda 319 mesaj başarılı bir şekilde sunucuda işlenmiştir. Bu sonuçlar gösterdi ki bunun gibi bir tabanlı uygulama, düşük maliyetli bir sunucu donanımı üzerinde kolay bir şekilde çalışabilmektedir [7]. Chao ve ark. ise Web uygulamalarında real-time iletişim 159

3 EEB 216 Elektrik-Elektronik ve Bilgisayar Sempozyumu, Mayıs 216, Tokat TÜRKİYE üzerine yaptıkları çalışmada, ve metotları üzerinde 8 farklı deney yapmışlardır. Sonuçta real-time gerektiren daha ileri koşullarda in performansının genellikle daha iyi olduğunu saptamışlardır. Deneylerde, in aynı veri iletimi için e göre 4.48 ila kat daha az trafik oluşturduğunu göstermişlerdir [6]. Verilen bu örnekler, protokolünün real-time uygulamalarda diğer yöntemlere olan üstünlüğünü ortaya koymaktadır. Durum-3-2: Her 6 saniyede bir 1 baytlık veri Durum-3-3: Her 6 saniyede bir 1 kilobaytlık veri Yapılan deneylerin sonuçları aşağıdaki grafiklerde görülmektedir. 2. Materyal ve Metot 2.1. Materyal Deneylerde kullanılan sunucu cihazın donanım ve yazılım özellikleri aşağıdaki gibidir. İşletim Sistemi: Ubuntu İşlemci: Intel(R) Xeon(R) CPU 2.GHz Bellek: 8 GB Sunucu cihaz üzerinde Apache 2.8 Web Sunucu Hizmeti kullanılarak Web sayfaları üzerinden sunucuya erişim sağlanmıştır. Web sayfaları PHP, HTML ve JS dilleri kullanılarak hazırlanmıştır. Deneyler sırasında oluşan bant genişliğinin ölçülmesi ve paketlerin izlenmesi amacıyla Wireshark programı kullanılmıştır. Şekil 18: Sunucudan İstemciye Veri Gönderimi Metot Çalışmada hem sunucudan istemciye hem de istemciden sunucuya doğru veri gönderilmiş ve toplam 18 farklı deney yapılmıştır. Yapılan deneyler aşağıdaki gibidir: Durum-1: Her saniyede bir 1 baytlık veri Durum-1-2: Her saniyede bir 1 baytlık veri Durum-1-3: Her saniyede bir 1 kilobaytlık veri Durum-2: Her 25 saniyede bir 1 baytlık veri Durum-2-2: Her 25 saniyede bir 1 baytlık veri Durum-2-3: Her 25 saniyede bir 1 kilobaytlık veri Durum-3: Her 6 saniyede bir 1 baytlık veri Şekil 2: Sunucudan İstemciye Veri Gönderimi Şekil 3: Sunucudan İstemciye Veri Gönderimi 16

4 EEB 216 Elektrik-Elektronik ve Bilgisayar Sempozyumu, Mayıs 216, Tokat TÜRKİYE metoduna göre ortalama %39,92 daha verimli olmuştur. Şekil 4, Şekil 5 ve Şekil 6 daki grafiklerde görüldüğü üzere, yapılan deneylerde, kullanılan bant genişliği açısından metodu Long metoduna göre ortalama %54,63 daha verimli olmuştur. 3. Sonuç Şekil 4: İstemciden Sunucuya Veri Gönderimi Şekil 5: İstemciden Sunucuya Veri Gönderimi Bu çalışmada, geleneksel Long metodu ile yeni bir yöntem olan yöntemini kullanılan bant genişliği açısından karşılaştırmak için bir dizi deney yapılmıştır. Deneylerin sonuçlarına göre, sürekli olarak sunucudan istemciye doğru veri gönderilmesi durumunda Long metodunun daha verimli olduğu gözlenmiştir. Bunun nedeni metoduna göre daha performanslı bir Keep-Alive yönetimi kullanmasıdır. Keep-Alive mesajı, Long yönteminde, 3 saniyeden daha az aralıklarla veri gönderilmesi durumunda hiç gönderilmemekte ve veri gönderilmesi durumunda da ötelemektedir. Bu sayede bağlantının hayatta kalması için daha az veri trafiği yapılmaktadır. yönteminde ise veri gönderilse de gönderilmese de sabit 25 saniye aralıklarla bu mesaj gönderilmektedir. Bu da fazladan bant genişliği demektir Sürekli olarak istemciden sunucuya veri gönderilmesi gereken durumlarda ise yöntemi, bant genişliği açısından Long yöntemine göre daha fazla performans göstermiştir. Bunun nedeni, Long metodunda istemcinin, veri göndermek için sürekli olarak sunucuya bağlantı isteği göndermek zorunda kalmasıdır. Bu da fazladan veri trafiği anlamına gelmektedir. yönteminde ise bant genişliği sabit kalmaktadır. Şekil 6: İstemciden Sunucuya Veri Gönderimi Grafiklerde Y ekseni, bayt biriminden saniyede alınan ve gönderilen toplam veriyi göstermektedir. Şekil 1, Şekil 2 ve Şekil 3 teki grafiklerde de görüldüğü gibi yapılan deneylerde, kullanılan bant genişliği açısından Long metodu Sonuç olarak, yöntemi Long metoduna göre ortalamada %14,71 ve en fazla %54,63 oranında daha yüksek performans göstermiştir. Bu da, henüz yeni bir yöntem olmasına rağmen yönteminin ileriki zamanlarda ve bazı uygulamalarda tercih edilebileceğini göstermiştir. 161

5 EEB 216 Elektrik-Elektronik ve Bilgisayar Sempozyumu, Mayıs 216, Tokat TÜRKİYE 4. Kaynaklar [1] Swamy R. ve Mahadevan G., 211. Event Driven Architecture using HTML5 Web Sockets for Wireless Sensor Networks, Planetary Scientific Research Center. [2] Jiang F. ve Duan H., 212. Application Research of Technology on Web Tree Component, 212, International Symposium on Information Technology in Medicine and Education (ITME 212) IEEE, /12, sayfa: [3] Pimentel V. ve Nickerson B., 212. Communicating and Displaying Real-Time Data with, IEEE Computer Society, /12, sayfa: [4] Furukawa Y., 211. Web-based Control Application Using, Proceedings of ICALEPCS211, Grenoble, France, WEMAU1, sayfa: [5] Erkkilä J., 212. Security Analysis, Aalto University T Seminar on Network Security. [6] Chao Y., Ming L. ve Yan L., 214. Review on Realtime Communications Technology in Web Application, Advanced Materials Research Vols , safya: [7] Zhangling Y. ve Mao D., 212. A real-time Group Communication Architecture Based on, International Journal of Computer and Communication Engineering, Vol. 1, No. 4, sayfa: [8] Chen B. ve Xu Z., 211. A Framework for Browserbased Multiplayer Online Games using WebGL and, IEEE, /11, sayfa: