Selamlar, X kuşağına son dönemlerinden, Y kuşağına da ilk yıllarından dahil olduğum için kendimi oldukça şanslı sayıyorum. Rutin hayat devam ederken bir taraftan da bu iki dönem arası yaşanan teknik anlamdaki devrimsel gelişmelere şahit olan, kıt imkanlar ile bu teknolojilere ulaşabilen, sindire sindire, keyfini çıkara çıkara bu teknolojileri kullanan kuşaktan bahsediyorum. Bahsettiğim nesil, zamanla BBS, Netscape Communicator, Dial-up, kullanırken yıllar sonra fiber bağlantıya geçip 4K Stream yayınları takılmadan izleyebilmiş, önceleri müziğini karışık 45’lik, 90’lık kasetten Walkman‘inde daha sonra da Discman‘inde  dinlemeye çalışırken zamanla kendini Spotify’da sevdiği listeyi kurcalarken bulmuş, Nokia 5110 da kullanmış,  iPhone 7’sine kırılmaz cam da takmış efsane nesil. 🙂 Bu neslin şahit olduğu birçok gelişim içinde IM (Instant Messaging) teknolojilerindeki gelişmeler de önemli. mIRC client ile IRC ortamlarında  “ASL PLS” şeklinde sohbet etmeye çalışırken yine zamanla ICQ, Microsoft Messenger, Skype, WhatsApp şeklinde çıtayı yükseltmiş bir nesil bu.

Böylesine geçmişe hızlıca bir bakış atan girizgah sonrası asıl konumuza gelelim; WhatsApp! Bu hafta WhatsApp Infrastructure’a yakından bakıyoruz.

Daha önceki incelemelerimde olduğu gibi bu araştırmada da sistem hakkında Online ortamlarda paylaşılmış makale, sunum ve videolardan alıntı ve çeviriler yaparak yapının bileşenlerini, bir sistem ve network yaklaşımı şeklinde incelemeye çalışacağım. İnceleme elbette tam bir Network Mapping veya net sunucu topolojisi şeklinde değil de bulgulardan yola çıkarak yorumlama şeklinde.

Makaleyi yazarken mimaride kullanılan, hakkında bilgi sahibi olmadığım teknolojiler hakkında hızlıca bir araştırma yapıp kısa kısa bu konuları da notlara dökmek istiyorum. Olur da eksik veya yanlış bir bilgi fark ederseniz lütfen geri bildirimde bulunmaktan çekinmeyin. Mimarinin sürekli geliştiğini ve kullandığım kaynakların güncelliğini yitirmiş olabileceğini göz önünde bulundurunuz lütfen.

Motivasyon

Birkaç gün önce  WhatsApp kullanıcı sayısının günlük 1 milyar olduğu resmi olarak duyuruldu. 1 milyar aktif kullanıcı! Bu kullanıcılar günlük 55 milyar mesaj gönderiyor. Günlük 4.5 milyar tane fotoğraf aktarımı yapılıyor.  Bu kullanıcılar yaklaşık 60 farklı resmi dili kullanarak bu işlemleri rahatça gerçekleştirebiliyor. Günde aktarılan video sayısı ise 1 milyar!

seoul_nighttime_timelapse__gif__by_clarissaask-d5esusr.gif

Böylesine sayılara sahip bir yapıda kullanıcıların oluşturduğu trafik nasıl yönetiliyor? Yük nasıl Scale ediliyor? Backend mimarisinde kullanılan teknolojiler, teknikler neler? Bu gibi sorulara cevaplar aramak oldukça ilgi çekici geliyor.

Hadi Başlayalım!

WhatsApp, anlık mesajlaşma uygulaması olarak geliştirilen ve günümüzde insanların Multimedya içeriklerini rahatça paylaşabildiği modern bir OSN (Online Social Network). Mimariyi incelemeden önce WhatsApp’ın nasıl ortaya çıktığına biraz değinelim istiyorum.

WhatsApp Inc. Jan Koum ve Brian Acton tarafından, 2009 yılında Santa Clara, California’da kuruldu. Her iki kurucunun da eski Yahoo! çalışanı olduğunu belirtelim.

İlk olarak bir iPhone uygulaması olarak geliştirilen uygulama,  popüler olduğunda Android, Windows Phone, BlackBerry ve Nokia ortamları için de kullanıma sunuldu. Şubat 2014’te, Facebook Inc. 19 milyar dolara satın aldı. Uygulama yaklaşık 1 milyar günlük kullanıcıya ulaşmış durumda. Bu kullanıcıların büyük çoğunluğu genç kullanıcılar.

whatsapp_users

Source: http://www.experian.com/blogs/marketing-forward/2014/02/21/the-19-billion-question-who-uses-whatsapp-and-why-are-they-so-important-to-facebook/

Yazılımı kullanmak gayet basit, karmaşık kayıt işlemleri gerektirmiyor ve arabirim oldukça şık. Uygulama otomatik bir şekilde kullanıcının kimliğini telefon numarasından tanımlayabiliyor. Cihazın kişiler rehberindeki kayıtlar otomatik bir şekilde uygulamanın erişim listesine ekleniyor. WhatsApp ile One-to-One, One-to-Many ve Group Chat iletişimi kurulabiliyor. Bütün bağlantılar Encrypted bir şekilde yapılıyor.

whsts1

Source: https://www.slideshare.net/Maheshbitla/whatsapp-architecture

Mimariye bakış

WhatsApp mimarisi ile ilgili Rick Reed (Software Architect/Engineer @WhatsApp)’in şurada ve şurada harika bir sunumu mevcut.  Kendisi bana göre bir Cluster sihirbazı. Daha önce SGI’da çalıştığını görüyoruz. SGI dağıtık compute işlemlerin vatanı. Reed’in sunumunun ana konusu WhatsApp yapısında Erlang ve FreeBSD tabanlı sunucuların kullanımı ile yükü ölçeklemek. WhatsApp, Eylül 2011’de tek bir makine üzerinde 1 milyon TCP oturumu kurmayı başardıklarını duyurmuştu. Bunun ardındaki teknolojinin ise FreeBSD + Erlang ikilisi idi.  Şu günlerde günlük 55 milyar mesajın gönderildiği dikkate alınırsa, aşağıdaki tweet’e bakılarak 4 yılda gelinen durum oldukça dikkat çekici.

whatsapp_002

Onun anlatımı ile hızlıca kuş bakışı olarak sisteme göz atalım. Çizimin berbat olduğunu kendisi de itiraf ediyor. 🙂 Dünyanın herhangi bir yerinde konumlu yüz milyonlarca kullanıcıyı karşılayan iki ana Front-end yapı mevcut. Chat ve MMS. ‘Chat’ adındaki sistemler kullanıcıları karşılayan asıl sistemlerdir. Bu sistemler, Text mesaj trafiğinin, meta-dataların, profil resimlerinin de yönetildiği sistemlerdir. Bu sistemler MMS ile senkron çalışır. Bunlarını arakasında bulunan, cluster şeklinde ayrılmış Back-end sistemlerde ise Accound datalarını, Profile ile ilgili bilgileri, Push Token’larını, Group üyeliklerinin yönetimini yapar.

what_archi01

Bunlara bağlı Offline Storage sistemler ise kullanıcılar arasında mesajlar/resimler/medya dataları aktarılırken bir süreliğine bu dataları saklar. Alıcı taraf connected olduğunda veya datayı aldığında bu data Offline sunuculardan silinir. Chat bağlantıları encrypt bağlantılardır.

Sunumlarda gözlemlediğim klasik bir server donanım durumuna bakalım;

  • Sunucular SoftLayer’da BareMetal olarak barındırılıyor.
  • 1U/2U/4U Super Micro E5-2690v2 (40 Threads)
  • Yaklaşık 550 Sunucu ve artı olarak StandBy durumdaki sunucular.
  • Yaklaşık 150 Chat sunucusu.  (Her biri için 1 milyon telefon erişimi  ve 150 milyon bağlantı.)
  • 250 MMS (multimedya) sunucu
  • Her node üzerinde 64GB-768 RAM
  • 1-12 800GB SSD (12x4TB HDD video saklama için.)
  • Her sunucuda dual link GigE x2 NIC. Bir tanesi kullanıcı tarafı için diğeri backend sistemlere bağlantı için gerekli.
  • Erlang sistemin çalışması için toplamda 11000 Core.

Erlang

WhatsApp Infrastructure’da kullanılan geliştirme dili Erlang. Erlang, ağırlıklı olarak ölçeklenebilir (scalable) ve yüksek erişilebilir (H/A)  “soft real time” sistemler geliştirmek için kullanılan bir programlama dili. Çoğunlukla telekom, bankacılık, e-ticaret ve anlık mesajlaşma ortamlarında kullanılmakta. Bu yapılarda öne çıkan tutarlılık, dağıtıklık ve hata tolere edebilmek önemlidir. Erlang, İsviçreli telekom devi Ericsson tarafından yaklaşık 30 yıl önce geliştirilmeye başlanmış.

erlang

Erlang sayesinde non-stop yani hiç durmayan uygulamalar yapabilmek mümkün. Kod değişiminde sistem durmadan (On-the-Fly) devam edilebilmekte.  Erlang ile yapılmış birkaç ürün;

Bu noktada “Soft real-time system” ve “Hard realtime-system” konularını biraz açalım.  Özete bir tabirle, bir Hard realtime sistemde, bir iş tam zamanında yapılır. Tam zamanında yapılamayan bir iş sistemin  başarısız olmasına neden olur. Bu tür sistemler daha çok kritik işlerin yapıldığı ortamlarda kullanılır; uçaklar, otomobil çekiş, sürüş kontrol sistemleri, nükleer santraller, network cihazları, telemetri ve ölçüm cihazları gibi.

Bir Hard real-time systemlerde yaşanabilecek gerçek bir soruna örnek vermek istiyorum. “Air France 447 sefer sayılı uçuş, 1 Haziran 2009 tarihinde radardan kayboldu. Daha sonra teknik bir arıza nedeni ile okyanusa düştüğü açıklandı. Kurtulan olmadı. Yapılan araştırmada yaşanan sorunlardan birinin uçağın hız göstergelerinin yanlış veri aktardığıydı.

Bir Soft real-rime sistemde ise, bir işlemin belli bir zamanda tamamlanmaması bir felakete yol açmaz.  Örneğin, bir hava durumu istasyonu sıcaklık, nem, rüzgar hızı ölçümü için birçok sensöre sahiptir. Sensörlerden ölçümler belirli sürelerde okunur. Bununla birlikte sensörler kendi aralarında senkron durumda değildir. Bir sensörden alınan veri diğerlerine kıyasla önce veya sonra olabilir. Veriler tutarlı olduğu sürece sorun olmaz. Sadece biraz geç okumaya neden olur. Lag oluşturur.

FreeBSD is the new BLACK!

Sunucular üzerinde koşan işletim sistemi FreeBSD. FreeBSD, açık kaynaklı Unix benzeri işletim sistemi. Linux’a benzer olsa da hem kapsam hem de lisans anlamında farklılıkları bulunmakta.

abstract_0109

Cluster yapısı için SMP mimarisi, video sunucuları için FreeBSD gmirror tool kullanılmakta. Dosya sistemi olarak UFS kullanılmış. Bu arada şurada neden UFS dosya sisteminin FreeBSD’lerde harika çalıştığı hakkında bir makale mevcut.

  • 2007-2010 yılları arasında FreeBSD 7 sürümü kullanılmış. Performans olarak iyi, bug olarak ara ara sıkıntı çıkarmaktaymış.
  • 2011-2012 yılları arasında FreeBSD 8 sürümü kullanılmış. Performans olarak daha iyi ama birçok bug (zero-copy sockets, igb) görülmüş. İnce bir tuning ile server başına yaklaşık 2.8 milyon bağlantıya ulaşılmış.
  • 2013 yılından günümüze ise FreeBSD 9’a geçilmiş. Bug’lar çok nadir görülmüş.

Cluster üyesi FreeBSD sunucuları üzerinde hata ayıklama, monitoring gibi işlemler için kullanılan araçlar şu sunumda belirtilmiş. .

Ölçümler için sık sık ‘Synthetic Workload diye tabir edilen test scriptler ile oluşturulan yapay yüklerle sistemin dayanabileceği yükler ölçülmüş. Özellikle de “tuning” işlemleri için oluşturulan bu  yükler önemli durumda. Bir diğer ölçüm testi ise Tee’d Workload. Bu ölçüm mekanizmasında ise mevcut production trafiğin bir hat ile ayrılmış sistemler üzerine aktarılması.  Erlang’in on-the-fly desteği ile bu testlerin yapılabilmesi mümkün durumda. ‘True Production Load Test” ise direkt production trafiğinin DNS yardımı ile sunucu üzerine aktarılması.

Neden FreeBSD? Bu noktada genel görüş şu, WhatsApp kurucuları eski Yahoo çalışanlarıydı ve orada FreeBSD ile uzunca zaman çalışma fırsatı yakaladılar. FreeBSD’ye tamamen hakim bu iki uzmanın OS tercihi bu yöndeydi.

FreeBSD kullanımı ile ilgili Wired’ın WhatsApp kurucularından Brian Acton ile yaptığı şu röportajda, neden FreeBSD kullandıklarına dair çok güzel notlar mevcut.

Brian Acton: FreeBSD tercih edildi. Çünkü Ben ve Jan daha önceden Yahoo!’dan FreeBSD yönetiminde tecrübeliydik. FreeBSD’nin sahip olduğu network stack oldukça güzel tune edilmiş durumda ve extreme bir şekilde güvenli. FreeBSD kurulum ve yönetimine oldukça net bir şekilde karar verdik. Sunucularımız Erlang ile geliştirildi. Bu dilin bütün özelliklerini kullanabildik. Servisleri iyi bir uptime seviyesinde durdurmadan geliştirebildik. Yolun her adımında Erlang kaya gibi sağlam ve performanslıydı. Zaten yol boyunca Erlang ile ciddi bir sıkıntı yaşasaydık muhtemelen farklı bir dil ile devam etmiş olurduk. Şanslıydık, bu hiç olmadı.

Linux tam bir karmaşa canavarı. FreeBSD, tekil bir dağıtım olmanın avantajına ve olağanüstü bir port koleksiyonuna sahip. OS seviyesinde yaşanan çok az hatalar bizim için avantajlı oldu.

Web server ihtiyacı için Yaws ve lighttpd. Yaws, yüksek performanslı bir web sunucu. Daha çok dinamik içeriklerin sunumu için uygun. Tamamen Erlang ile yazılmış. İki farklı çalışma modu mevcut.  Standalone mode ile standart bir web sunucu daemon olarak çalıştırabilir, ki bu default moddur. Diğer mode ise gömülü mod. Bu modda Yaws, diğer bir Erlang uygulaması içinde gömülü olarak çalışabilir.  lighttpd, hızlı, güvenli, esnek ve light bir web sunucu. Yüksek performanslı ortamlar için tasarlanmış ve optimize edilmiştir. Diğer web sunuculara kıyasla daha küçük bir memory footprint’e sahiptir. Verimli CPU kullanımı, zengin feature set’i ile load sorunu yaşayan sunucularda kullanımı idealdir.

Mnesia ile tanışın

Yapıda kullanılan veri tabanı ise Mnesia, dağıtık bir gerçek zamanlı, telekomünikasyon odaklı Database Management sistem. İlk olarak Ericsson firmasında telekom odaklı high-availability bir veri tabanı olarak geliştirilmiş. Telekomünikasyon uygulamaları için hem ilişkisel hem de ojbe tabanlı bir ortam sağlıyor. Persistence bir yapıya sahip ve  tablolar bellekte ve diskte tutarlı bir şekilde tutulur. Tablolar farklı sunucular arasında replike edilebilirler. Çok hızlı bir şekilde gerçek zamanlı data aramaları yapılabilir.

mnesia.gif

Mnesia, datayı RAM üzerinde, uygulamanızın bulunduğu alanda saklayabilir. Bu şu anlama gelir, uygulamanız Mnesia’dan veriyi birkaç mikro saniye içinde çekebilir.

Aşağıdaki çizelgede mnesia’nın diğer NoSQL DBMS’ler ile karşılaştırması görülmekte.

scalable-persistent-storage-for-erlang-theory-and-practice-8-638

Source: https://www.slideshare.net/AmirGhaffari/scalable-persistent-storage-for-erlang-theory-and-practice

2014 verileri ile WhatsApp ortamında In memory Mnesia Database yaklaşık 2TB RAM kullanmakta. 16 farklı parça şeklinde 18 milyar kayıt tutulmakta. Bu kayıtlar Account data’lar, grup üyelikleri gibi bilgilerdir. Mesajlar aktarılırken de Mnesia kullanılır.  Daha detaylı anlatmaya çalışırsak, WhatsApp, “Store and Forward” (Depola ve ilet) mekanizması ile mesajları iletir.

Bir kullanıcı bir mesaj gönderdiğinde mesaj WhatsApp sunucularında kaydedilir. Server bu mesajı karşı cihaz kabul edene kadar tekrarlı bir şekilde gönderir. Mesaj kabul edildiğinde sunucu bu mesajı karşıya aktarır ve artık mesaj sunucu veri tabanında değildir. Oradan silinir.

Eğer bir gönderilen bir mesaj bir şekilde karşı tarafa ulaşmaz ise (kullanıcı offline durumda olabilir), bu mesaj sunucuda ulaştırılmak üzere 30 gün bekletilir. Daha sonra silinir.

Dünyada genelinde yaşanan toplumsal hadiseler WhatsApp altyapısını test etmek için birebir. Dünya kupası, önemli günler, toplumsal olaylar, depremler, Futbol WhatsApp sisteminde dikey yük artışlarına neden olur.  Bu duruma örnek olarak, özellikle de tatil günleri WhatsApp Network’ünde aşırı throughput artışları oluşturmaktaymış.

  • ‘Christmas Eve’ kutlamalarında 146Gb/s upload trafiği yaşanmış.
  • Aynı gün, 360 milyon video download edilmiş.
  • Yeni yıl kutlamalarında 2 milyar resim download edilmiş.
  • Sadece 1 resim 32 milyon defa download edilmiş.

WhatsApp’ta mesaj aktarımı – ACTOR MODEL

Daha önce de bahsettiğimiz gibi, WhatsApp, kolay ölçeklenebilmek ve hatalara karşı her durumda ayakta durabilmek için Erlang dili ile yazılmıştır. WhatsApp, mesaj aktarımındaki eş zamanlılık  için ‘Actor Model‘ adında bir soyutlama kullanır. Geleneksel bellek paylaşım yaklaşımı  yerine, aktörler birbirleri ile mesaj göndererek haberleşirler. “Aktör Model” gerçekte bir matematiksel model türüdür. Bir matematiksel model, bir sistemin matematiksel kavramlar ve dil kullanarak tanımıdır. Aktör modeller karmaşık Thread‘lerin aksine lightweight, yani hafif olmak için tasarlanmıştır. Bir aktör aynı makine ya da farklı bir makine olabilir.  Şu linkte “Aktör Model” basitçe bir örnekle anlatılmış. Ben hızlıca durumu özetleyen notları aktarıyorum.
Aktörleri insanlara benzetebiliriz. Birbirleri ile konuşamayan insanlar demek daha doğru olur. Bu insanlar sadece posta yardım ile iletişim kurabiliyorlar.

İki insan düşünelim(İki aktör), Bilge bir Öğretmen ve onun öğrencisi. Öğrenci her sabah öğretmenine bir posta gönderiyor. Öğretmen de bu postaya bir geri bildirim postası gönderir. Bu işlemler şu şekilde aşama aşama ilerler:

Mesajlaşma Süreci (Messaging):

  • Öğrenci bir posta gönderir. Posta bir kez gittiğinde, posta bir daha düzenlenmez. Bu değişmezliktir (Immutability).
  • Öğretmen posta kutusunu kontrol eder ve bu işlemi herhangi bir zamanda, canı istediğinde yapabilir.
  • Öğretmen aynı zamanda bu postaya karşılık vererek öğrencisine bir posta gönderir. Bu noktada yine değişmezlik devrededir (Immutability).
  • Öğrenci posta kutusunu kontrol eder. Bu işlemi herhangi bir zamanda yapabilir.
  • Öğrenci bu postaya yanıt vermeyebiliyor.  (no blocking)

Akka Messaging

Source: http://rerun.me/2014/09/11/introducing-actors-akka-notes-part-1/

Eşzamanlılık/Aynı anda çalışabilme süreci:

Eşzamanlılığı ise şöyle soyutlayabiliriz. Yine öğretmen ve öğrenci mantığını kullanalım. 3 tane öğretmen ve 3 tane de öğrencimiz olsun. Bunlar dünyanın farklı noktalarında konuşlu WhatsApp kullanıcıları olarak düşünülebilir. Her öğrenci her öğretmene posta gönderebilmekte. Bu durumda ne olurdu? Aslında değişen bir şey olmazdı. Herkes kendine ait bir posta kutusuna sahip olacağından pek durum değişmezdi.

Burada dikkat edilmesi gereken ince bir nokta var. Varsayılan olarak, posta kutusundaki postalar sıra ile okunur ve işlenir.  Burada “sıra ile” önemli.

Akka concurrency.PNG

Source: http://rerun.me/2014/09/11/introducing-actors-akka-notes-part-1/

 Yük devralma (FailOver) Süreci:

Bu senaryoda yine 3 farklı departmandan 3 faklı öğretmenimiz mevcut. Tarih, Coğrafya ve Felsefe bölümlerimiz olsun.

  • Tarih öğretmenlerinin öğrencilere geçmiş bir olayla ilgili postayı cevapladığını düşünün.
  • Coğrafya öğretmenlerinin de ilginç bir yer ile ilgili postalar gönderdiğini düşünün.
  • Felsefe öğretmenlerinin de özlü sözler gönderdiğini hayal edin.
  • Her öğrenci de her öğretmene ayrı ayrı posta gönderip aldığını düşünün.
  • Posta gönderen öğrenci, hangi bölümden öğretmenin posta alıp/verdiği ile ilgilenmiyor. Çünkü gruba gönderiyor.

Akka Failover

Bu durumda, herhangi bir departmandaki öğretmenin hasta olduğunu ve maili göremediğini düşünelim. Bu durumda departmanda en az bir öğretmenin mailler ile ilgileniyor olması gerekmektedir. Bu durumda diğer bir öğretmen (aktör) işi devralıp mailler ile ilgilenir. Bu noktada aktörler ile ilgili gözden kaçırılmaması gereken bir durum vardır.

  • Farklı işler yapan aktörlerin dahil olduğu bir havuz olmalı.
  • Bir aktör sorun yaşadığında eskisinin görev yaptığı yerde yeni bir aktör oluşturulabilir. Bu tür durumlar için mutlaka bir aktör bulunmalı. Ya da alternatif olarak aktör mesajı reddedebilir ve diğer mesajları almaya devam edebilir.

WhatsApp’ın  mesajları yönetirken kullandığı “Actor Model”i aktardıktan sonra mesaj akış sürecine devam edelim. Aşağıdaki bilgileri konu ile ilgili bir Quora gönderisinden çevirmeye çalıştım.  Gerçek anlamda resmi bir süreç paylaşımı değil ama işin uzmanlarından süreç hakkındaki en net paylaşım bu diye düşünüyorum.

Yapıda her kullanıcı veya telefonun bir aktör olduğunu düşünün. Bu aktörler kendi gelen posta kutularından sorumludurlar. Bu posta kutuları kullanıcıların gönderip aldığı mesajları sıralanmış bir şekilde lokal disk ortamında saklanır.

Alice ve Bob’un WhatsApp’ta arkadaş olduğunu varsayalım.

Mesaj gönderme süreci:

  • Alice, Bob’a mesaj göndermeye karar verir. Alice’in telefonu WhatsApp sunucuları ile bağlantı kurar.
  • WhatsApp sunucuları bu bağlantının kesin olarak Alice’in telefonundan geldiğini doğrular.
  • Alice, TCP protokolü vasıtasıyla şu mesajı gönderir: “BOB İÇİN: Bob selam, dev bir canavar Golden Gate Köprüsü’ne saldırıyor!”
  • WhatsApp’ın bir Front-end sunucusu gelen mesajı deserialize eder ve bu mesajı Alice adındaki aktör bileşen‘e iletir. (Mesaj aktör bileşenine aktarıldı.)
  • Alice adındaki aktör bileşen, bu mesajı serialize eder ve onu “Alice’in Gönderilmiş Mesajları” başlığı ile bir dosyaya kaydeder. Bu dosya tam replike halde yani çoğaltılmış bir dosya sisteminde saklanır.  Replikasyonun amacı öngörülemeyen data kayıplarını önlemektir.
  • Alice adındaki aktör bileşen, bu mesajı Bob adındak aktör bileşene aktarmaya karar verir.
  • Aktarılan mesaj: “Msg1 form Alice: Bob selam, dev bir canavar Golden Gate Köprüsü’ne saldırıyor!” şeklinde iletilir.
  • Alice adındaki aktör bileşen bu mesajı Bob adındaki aktör bileşen kabul edene kadar tekrarlı bir şekilde aktarmaya devam eder. (Exponential Backoff süreci ile bu işlem yapılır.)

Mesaj alma süreci:

  • Aktör Bob bileşen, nihayetinde mesajı alır.
  • Mesaj ‘Bob’un Gelen Kutusu” adında bir dosyaya kaydedilir.
  • Mesaj sağlam bir şekilde kaydedildiğinde Aktör Bob bileşen be mesajın alındığına dair Aktör Alice bileşenine bir mesaj gönderir. Mesajın içeriği: “Msg1’i aldım.”  şeklindedir.
  • Aktör Alice bileşeni, bu mesajı aldığında artık tekrarlı mesaj göndermeyi durdurur.
  • Aktör Bob bileşen, Bob’un telefonun WhatsApp sunucularına bir bağlantı yapıp yapmadığını kontrol eder.
  • Sunucu bağlantısı mevcut ise Aktör Bob bileşeni bu durumu TCP yardımı ile aktarır.

Mesaj yanıtlama süreci:

  • Bob gelen mesajı görür ve onu şu şekilde cevaplar.  “ALICE İÇİN: O halde dev robotlar oluşturalım ve onlarla savaşalım!”
  • Bu mesaj yine Aktör Bob bileşeni tarafından kabul edilir ve tekrar ilk aşamadaki mesaj gönderme sürecine geri dönülerek işlemler tekrarlanır.

Bütün bu işlemlerin Jabber / XMPP  protokolü üzerinde döndüğünü belirtmem gerekli. 🙂 Kuruculardan Jan Koum, 2009 yılında, yani WhatsApp’ın daha yayınlanmadığı yıllarda ejabber’ı kurcaladığının kanıtı olan şu mesaj meşhurdur. “Nereden nereye?” sorusunun cevabını çok net anlatan bir görüntü bu. Ekip harika iş çıkarmış. Ki bu ekip, 2004 yılında 450 Milyon kullanıcı trafiğini yöneten sadece 38 kişilik bir mühendis ekibi. Ekibin yeteneklerini ortaya döken net bir sayı bence. 🙂

ejabber.JPG

Peki  kimlik doğrulama (Authentication) işlemi?

WhatsApp ilk kurulduğunda telefon numarası ile WhatsApp hesabını ilişkilendirir. Her numara bir kullanıcıdır. Telefon numarası tekil olduğundan tanımlayıcıdır. O nedenle şifre gerektirmez. Hesap fiziksel olarak bağlanmıştır. Doğrulama işlemi SMS ile yapılır.

WhatsApp iletişimi end-to-end şeklinde şifreli oluşturulur. Bu şu anlama gelir, telefonunuz ilk olarak göndereceği mesajı şifreler ve sonra WhatsApp sunucularına aktarır. Sonra sunucu bu mesaja gelen yanıtları tekrar şifreler ve telefonunuza aktarır.  Bu iki taraflı şifreleme işlemi için bir token gerekir. Bu token ilk defa telefonunuz WhatsApp sunucuları ile iletişim kurduğunda yapılan 4 haneli sayı doğrulaması ile elde edilir. Yani, telefonunuzdaki token yardımı ile mesajlar  encrypt/decrypt edilir. Bu kadarı telefon için yeterlidir. Peki ya Web doğrulama?

Nasıl oluyor da “WhatsApp Web App” hangi kullanıcıya hizmet vereceğini bilebiliyor?  Sonuçta bir kullanıcı adı veya şifre girişi olmuyor. Cevabı QR Code doğrulamada.  Çünkü telefonunuz bir toke’a zaten sahip. Bu durum şurada çok güzel anlatılmış.

Adım adım WhatsApp Web App login süreci:

  • Siteye girdiğinizde Web client, QR kodu oluşturur.
    • Bu kod aslında sizi tanımlamak için benzersiz bir kod içeriyor.  Karışıklığı önlemek adına bunu WebID olarak isimlendirelim. Web Client sürekli olarak sunucudan yeni WebID alarak belirli aralıklarla yeniler ve QR kod sürekli belirli aralıklarla yenilenir. Web Client bu WebID’sini kullanarak sunucudan giriş yetkisi ister. Ama bu yetkiyi sunucu vermez. Çünkü bir telefon henüz sisteme iliştirilmemiştir.
  • WhatsApp uygulamasını çalıştıran bir telefon QR kodu okur.
    • Telefonun okuduğu QR kod içerisindeki uniq WebID vardır ve bu WebID ile telefondaki token eşleştirilir.
    • Telefon bu belirli WebID ile bir erişim denemesi yapar.  Telefona sahip olduğu token yardımı ile kullanıcının WhatsApp hesabına girişine sunucular tarafından izin verilir.

Hücresel ağlarda WhatsApp trafiğinin etkisi

Pierdomenico Fiadino, WhatsApp trafiğini inceleyerek elde ettiği bulguları paylaşmak istiyorum. Çalışm geniş ölçekte WhatsApp trafiği incelenerek yapılmış. Pasif ölçümler ulusal bir mobile Network üzerinde, aktif ölçümler ise RIPE Atlas (RIPE Network Koordinasyon Merkezi) dahilinde yapılmış.  Trafik capture işlemleri ise standart Tool’lar (Wireshark) kullanılmış.

DNS isteklerini filtreleyerek yapılan gözlemde ortaya çıkan durum:

  • WhatsApp özelleştirilmiş bir XMPP protokolü kullanmakta
  • Media alışverişi HTTP sunucular yardımı ile yapılmakta
  • Uygulama çalışırken sadece 1 SSL connection kurulmakta
  • Her medya transferi işleminde HTTP sunucular ile dedike TLS bağlantısı yapılmakta.
  • Kullanılan isimlendirme şeması şu şekilde:

whatsapp_traffic

Source: https://tma-2015.cba.upc.edu/images/TMA/Presentations/Vivisecting_WhatsApp_in_Cellular_Networks-Servers_Flows_and_Quality_of_Experience.pdf

Yine uzunca bir yazı oldu.  🙂

452620c767366798d3

Teşekkürler.

Hakan Orcan

 

Kullanılan Kaynaklar:
[1] U.Gupta “An Overview on the Architecture of WhatsApp”
[2] https://en.wikipedia.org/wiki/XMPP
[3] http://ieeexplore.ieee.org/document/7497256/
[4] https://tma-2015.cba.upc.edu/images/TMA/Presentations/Vivisecting_WhatsApp_in_Cellular_Networks-Servers_Flows_and_Quality_of_Experience.pdf
[5] http://highscalability.com/blog/2014/3/31/how-whatsapp-grew-to-nearly-500-million-users-11000-cores-an.html
[6] https://vimeo.com/44312354
[7] http://highscalability.com/blog/2014/2/26/the-whatsapp-architecture-facebook-bought-for-19-billion.html
[8] http://www.erlang-factory.com/upload/presentations/708/HitchhikersTouroftheBEAM.pdf
[9] https://www.slideshare.net/udayslideshare/whatsapps-architecture?qid=f33ffe48-76e9-462b-b590-b1cfd40b1c6c&v=&b=&from_search=2
[10] https://www.wired.com/2015/10/whatsapps-co-founder-on-how-the-iconoclastic-app-got-huge/
[11] http://rerun.me/2014/09/11/introducing-actors-akka-notes-part-1/
[12] http://censore.blogspot.com.tr/2015/01/breaking-open-httpswebwhatsappcom.html
Advertisements

9 thoughts on “WhatsApp altyapısına teknik bir bakış

  1. Nereden buraya denk geldim bilmiyorum 😀 ama iyi ki denk gelmişim, muazzam bir yazı olmuş. Aynı kalitede telegram ı da bu tatlış makalenize katmanızı canı gönülden istiyorum ^_^
    İyi günler

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s