Secara iseng saya menemukan artikel Kompasiana HTTP, Sebuah Tantangan Terselubung oleh bung Deru Sudibyo, yang pada intinya mempertanyakan kenapa format teks dipakai untuk HTTP (Hypertext Transfer Protocol), dan kemudian mengusulkan format pengganti dalam bentuk biner (binary).
Kebetulan pekerjaan saya berhubungan dengan ini (namun tidak bisa saya bilang di sini karena top secret :p), oleh karena itu saya jawab "tantangan" bung Deru, namun bukan untuk mengimplementasikan protokol tandingan HTTP, namun justru sebaliknya, untuk mendiskusikan mengapa format teks tersebut dipilih untuk dipakai oleh HTTP dan SIP (Session Initiation Protocol) (walaupun terus terang saya tidak tahu apakah memang ada proses pemilihan ini ketika protokol HTTP pertama kali dibuat. Tapi saya tahu iya ada pemilihan secara sadar untuk menggunakan format teks untuk protokol SIP).
Argumen utama untuk memakai format biner daripada teks adalah alasan kecepatan pemrosesan (argumen lain adalah space, termasuk bandwidth, yang dibutuhkan lebih kecil, namun saya kira hal ini kurang relevan di sini, karena perbedaan ukuran biner dan teks hanya beberapa bytes saja). Seperti ditulis oleh bung Deru di artikelnya, untuk memroses sebuah protokol teks memang membutuhkan proses tambahan yang disebut parsing.
Menurut saya, faktor kecepatan parsing "plain text" itu memang berpengaruh, tapi pengaruhnya sangatlah kecil. Saya dulu pernah membikin parser untuk protokol teks, dan kecepatannya bisa sekitar 8 clock cycle per karakter. Kalau misalnya HTTP requestnya sebesar 200 bytes, maka waktu yang dibutuhkan untuk mem-parse adalah 8x200=1600 clock cycles. Kalau misalkan kecepatan CPU 3 GHz, maka ini setara dengan 1600/3GHz = 0.5 microsecond saja. Berarti sekali mata berkedip, CPU bisa memproses 600-800 ribu request (berkedip membutuhkan waktu 300-400 msec). Dan parser ini dibuat dalam bahasa C saja, bukan assembler.
Tentu ini hitungan bodo-bodoan, ada banyak faktor yang mempengaruhi kecepatannya (misalnya kecepatan akses RAM, L1/L2 cache, paralelisme eksekusi instruksi, jumlah CPU atau CPU cores, dsb), tapi kira-kira begitulah orde angkanya. Jadi kalo ada website yang lelet, saya 100% yakin pasti bukan gara-gara parsing. Masih banyak komponen pemrosesan lain yang membutuhkan waktu yang jauh berlipat-lipat lebih lama, misalnya akses file, dan/apalagi akses basis data. Hampir semua situs web modern membutuhkan semacam basis data, jadi ada kemungkinan si server basis data ini bisa menjadi bottleneck-nya, karena operasi basis data memang lebih berat daripada pemrosesan HTTP. Paling tidak, akses basis data akan membutuhkan waktu dalam hitungan milisecond, sementara untuk parsing HTTP hanya membutuhkan waktu dalam hitungan microsecond, seperti ilustrasi di atas.
Di lain pihak, penggunaan format teks untuk protokol mempunyai beberapa kelebihan yang tidak bisa ditandingi oleh format binary.
Kelebihan utama adalah kemudahan untuk dibaca (readability) sehingga gampang untuk dipelajari, dimengerti, didiskusikan, dan diimplementasikan. Dan jangan lupa, kita mesti berhati-hati dengan format biner karena representasi ini bisa berbeda dari satu sistem ke sistem lain (misalnya endianness-nya, yaitu little-endian atau big-endian, atau byte ordering-nya, host atau network byte order). Tentu tidak susah untuk membuat program yang portable di semua sistem ini, dan saya pernah melakukannya juga, namun tentunya ini menambah kesulitan, dan lebih parah, kemungkinan terciptanya bugs, pada pembuatan programnya.
Faktor kemudahan ini tidak bisa dianggap remeh, buktinya adalah "perang" antara protokol H.323 dan SIP di dunia telekomunikasi di Internet (atau lebih dikenal dengan VoIP). Kedua protokol ini kurang lebih menawarkan fitur yang sama, bedanya H.323 berformat biner (dan dikembangkan oleh ITU-T), sedangkan SIP berbasis teks (dan dikembangkan oleh IETF). H.323 lebih dulu ada, dan bahkan sempat menjadi protokol de-facto untuk VoIP (sekitar tahun '90-an). Namun dengan berjalannya waku, SIP semakin menggantikan H.323, dan akhirnya sekarang SIP-lah protokol de-facto untuk VoIP.