1.
Pendahuluan Squid merupakan aplikasi yang mempunyai kegunaan untuk mendukung akses internet. Salah satu kegunaan Squid adalah sebagai penyimpanan sementara dari web content atau sering disebut web cache. Dalam penerapannya, web cache dapat digunakan pada topologi yang berbeda-beda serta konfigurasai yang berbeda pula. Sebagai contoh pada topologi single gateway dengan konfigurasi default squid, proses caching belum dapat terjadi, sehingga dibutuhkan konfigurasi tambahan agar file dapat dikelola oleh squid diantaranya dengan memberikan refresh_pattern tambahan dan juga menambah delay_pools sebagai manajemen bandwidth. Permasalahan yang terjadi ketika menggunakan topologi lain seperti topologi DMZ, konfigurasi manajemen bandwidth dari single gateway tidak dapat diterapkan karena hanya mengatur trafik yang berasal dari internet, sehingga apabila diterapkan dalam topologi DMZ, trafik yang berasal dari lokal ataupun internet tidak akan diketahui karena hanya memiliki satu jalur yaitu jalur trafik internet. Berdasarkan alasan tersebut, perlu kiranya dibuat pengelolaan trafik pada topologi DMZ untuk memisahkan jalur paket data yang berasal dari lokal web cache dan internet. Salah satu cara dengan memanfaatkan qos flows dan DSCP sebagai penanda paket data sehingga dapat dilakukan manajemen bandwidth untuk jalur internet dan lokal web cache agar cache dapat didistribusikan dengan baik. 2.
Tinjauan Pustaka Penelitian terdahulu salah satunya adalah pada jurnal dengan judul “Fairness Evaluation of a DSCP Based Scheduling Algorithm for Real-Time Traffic in Differentiated Service Networks”. Jurnal ini membahas penelitian tentang pengaturan penjadwalan video streaming secara adil dengan memanfaatkan DSCP sebagai klasifikasi trafik yang disimulasikan menggunakan OPNET IT GURU [1]. Dalam penelitian lain dengan judul “Implementasi Squid Server pada Proxy Cache Video”, aplikasi squid mampu digunakan untuk cache video pada sistem operasi FreeBSD 8.2 dengan memanfaatkan aplikasi Videocache 1.9.1. Peningkatan kecepatan dapat dilakukan dengan adanya Videocache ketika mengunduh file video, sehingga mempersingkat waktu pengunduhan[2]. Pada penelitian ini pemanfaatan squid digunakan sebagai media web cache. Pada kesempatan yang diberikan, topologi yang digunakan dalam penelitian ini adalah topologi DMZ. DMZ menggambarkan suatu host atau suatu segmen jaringan yang disisipkan sebagai zona netral antara jaringan internal suatu organisasi dan internet [3]. Untuk mengatur jalannya trafik pada web cache ataupun internet dibutuhkan penanda paket yaitu DSCP. Fungsi dari DSCP untuk mengelompokkan paket data menjadi kelas-kelas tertentu dengan memberikan suatu kode[4] sehingga dapat dilakukan pengelolaan bandwidth untuk lokal web cache dan internet. Pengelolaan bandwidth adalah suatu cara yang dapat digunakan untuk management dan mengoptimalkan berbagai jenis jaringan dengan menerapkan layanan Quality Of Service (QoS) untuk menetapkan tipetipe lalu lintas jaringan [5].
1
3.
Metode Penelitian Dalam penelitian ini digunakan tahapan Network Development Life Cycle (NDLC) yang memiliki 6 tahapan, diantaranya : analysis, design, simulation prototyping, implementation, monitoring, dan management [6]. Metode ini dipilih karena mengandung unsur-unsur yang tepat untuk digunakan pada saat penelitian.
Gambar 1. Network Development Life Cycle [6]
Gambar 1 merupakan gambar metode Network Development Life Cycle yang akan dijelaskan sebagai berikut. Tahap pertama: analysis merupakan tahap analisa permasalahan yang muncul seperti analisis topologi, analisis konfigurasi yang digunakan, serta analisis kebutuhan sistem. Analisis topologi dilakukan dengan survei lapangan sehingga dapat diketahui topologi yang sedang digunakan seperti pada Gambar 2. 192.168.5.10/24
192.168.1.254 192.168.5.5
Client
192.168.1.64
Switch Proxy Server (Web Cache)
Internet
Gambar 2 Topologi Awal (Single Gateway)
Gambar 2 merupakan topologi awal sebagai single gateway. Proxy server digunakan sebagai router sekaligus berfungsi sebagai gateway untuk mengakses internet. Analisis konfigurasi dilakukan setelah mendapat topologi yang ada dengan melihat konfigurasi yang berpengaruh pada web cache seperti misalnya refresh_pattern yang digunakan. Pada topologi awal refresh_pattern yang
2
digunakan masih bersifat default dari squid yang konfigurasinya dapat dilihat pada Kode Program 1. Kode Program 1 Konfigurasi Refresh_pattern Default Squid 1.
refresh_pattern ^ftp:
1440
2.
refresh_pattern -i (/cgi-bin/|\?)
3.
refresh_pattern .
0
20%
20%
10080 0
0%
0
4320
Kode Program 1 merupakan konfigurasi refresh_pattern squid yang belum diubah dan masih bersifat default. Kode Program 1 baris pertama merupakan refresh_pattern untuk melakukan proses caching dari object yang berasal dari FTP dengan nilai waktu minimal kurang dari 1440 menit maka object tersebut masih dikatakan baru, dan saat object sudah berada di cache lebih dari 10080 menit maka akan dianggap kadaluarsa dan akan mengambil dari server asli. Kode Program 1 baris kedua digunakan untuk menghindari proses caching terhadap situs yang mengandung konteks cgi-bin untuk menghindari konflik terhadap CGI script dan konten dinamis. Kode Program 1 baris ketiga digunakan untuk melakukan proses caching konten lain maksimal 4320 menit. Setelah proses analisa konfigurasi selesai, selanjutnya dilakukan pengujian terhadap konfigurasi dari topologi awal, dengan mengunduh satu file yang sama dari sebuah web server sebanyak 30 kali untuk mengetahui proses caching sudah berjalan dengan normal atau belum. Proses pengujian dilakukan dengan menggunakan calamaris, yaitu aplikasi dari linux yang berfungsi untuk melihat statistic kinerja dari squid proxy. Calamaris akan mencatat hasil dari access.log squid yang kemudian ditampilkan dalam bentuk tabel seperti pada Gambar 2 yang merupakan gambar tabel pada calamaris yang berisi keterangan tentang MISS yang berarti file diunduh dari server asli dan belum terdapat di cache serta HIT apabila file sudah terdapat dalam cache dan diunduh dari server lokal. Hasil pengujian statistic proses caching dapat dilihat pada Gambar 3.
Gambar 3 Hasil Pengujian Statistic Proses Caching
3
Gambar 3 merupakan hasil pengujian statistic proses caching sebanyak 30 kali pengujian, tetapi tidak ada satupun yang menunjukkan file tersebut diunduh dari server lokal. Hal ini dibuktikan dengan presentase HIT 0,00 % dan MISS 99,98 % yang dicatat pada calamaris sehingga dengan konfigurasi refresh_pattern default squid, proses caching belum dapat terjadi. Analisis kedua dilakukan dengan menambah refresh_pattern pada topologi yang ada. Konfigurasi refresh_pattern dapat dilihat pada Kode Program 2. Kode Program 2 Konfigurasi Refresh_Pattern Tambahan 1.
refresh_pattern -i \.(7z|arj|bin|bz2|cab|dll|exe|gz|inc|iso|jar|lha|ms(i|p|u)|rar|rpm|tar|tgz| zip|rtp|rpz|nui|kom|stg|pak|sup|nzp|npz|iop)$ 1440 99% 14400 overrideexpire override-lastmod ignore-private reload-into-ims ignore-mustrevalidate ignore-reload
2.
refresh_pattern -i \.(class|doc|docx|pdf|pps|ppt|ppsx|pptx|ps|rtx|txt|wpl|xls|xlsx)$ 1440 99% 14400 override-expire override-lastmod ignore-private reload-into-ims ignore-must-revalidate ignore-reload
3.
refresh_pattern -i \.(3gp|ac4|agx|au|avi|axd|bmp|cbr|cbt|cbz|dat|divx|gif|hqx|ico|jp(2|e|eg|g) |mid|mk(a|v)|mov|og(a|g|v)|qt|ra|ram|rm|tif|tiff|wa(v|x)|wm(a|v|x)|x-flv)$ 1440 99% 14400 override-expire override-lastmod ignore-private reload-intoims ignore-must-revalidate ignore-reload
4.
refresh_pattern -i \.(mp(e?g|a|e|1|2|)|mk(a|v)|ms(i|u|p)|og(x|v|a|g)|rar|rm|r(a|p)m|snd|vob|wa v) 10800 80% 10800 ignore-no-cache ignore-private override-expire overridelastmod reload-into-ims
5.
refresh_pattern -i \.flv$ 10080 80% 10080 override-expire override-lastmod reload-into-ims ignore-reload ignore-no-cache ignore-private ignore-auth
6. refresh_pattern -i .(html|htm|css|js)$ 1440 75% 40320 Kode Program 2 merupakan refresh_pattern tambahan yang digunakan untuk menentukan penanganan yang dilakukan squid terhadap tipe file seperti 7. refresh_pattern -i .index.(html|htm)$ 0 75% 10080 mp3, doc, mp4, dll, sehingga dapat ditentukan usia object di dalam cache. Pada 8. refresh_pattern ^ftp: 1440 20% 10080 analisa kedua dilakukan percobaan seperti analisa pertama yaitu menguji sistem dengan mengunduh file untuk melihat proses caching sudah berjalan semestinya 9. refresh_pattern ^gopher: 1440 0% 1440 atau belum. Hasil pengujian dapat dilihat pada Gambar 4. Gambar 4 merupakan 10. refresh_pattern . 0 20% 4320 hasil pengujian terhadap system yang sudah diberikan refresh_pattern tambahan. Proses caching sudah dapat terlihat0dengan adanya presentase pada MISS sebesar refresh_pattern -i (/cgi-bin/|\?) 0% 0 49,97 % dan HIT 50,01%, sehingga ketika ada pengunduhan file yang sama untuk #refresh_pattern . 180 95% 10800 override-lastmod reload-into-ims kedua kalinya, akan langsung mengambil dari web cache. Analisa ketiga refresh_pattern . 60menambah 50% 14400 dilakukan dengan konfigurasi delay_pool sebagai manajement bandwidth pada squid untuk koneksi internet. Konfigurasi delay_pool dapat dilihat pada Kode Progam 3. #cache deny QUERY #refresh_pattern ^ftp: 1440 20% 10080
4
Gambar 4 Hasil Pengujian Refresh_pattern Tambahan Kode Program 3 Pengaturan Delay_pool Sebagai Manajemen Bandwidth 1.
delay_pools 1
2.
delay_class 1 1
3.
delay_parameters 1 128000/128000
4.
delay_access 1 allow lokal
Kode Program 3 merupakan pengaturan delay_pool sebagai manajemen bandwidth yang terdapat pada squid dengan batasan bandwidth untuk jaringan dengan nama „lokal‟ sebesar 128.000 KB * 8 yaitu 1024Kbps. Tetapi untuk jaringan lokal dari web cache, squid akan secara otomatis memberikan bandwidth lokal yaitu 100 Mbps. Pengujian dilakukan dengan mengunduh 30 file yang berbeda pada sebuah web server dan akan diunduh lagi dengan client yang berbeda untuk melihat proses manajemen bandwidth dari squid dengan mencatat lamanya waktu unduh file sebelum tersimpan di cache dan setelah tersimpan dalam cache. Kemudian selain mencatat lamanya waktu unduh, maka akan dilihat juga bandwidth yang dibutuhkan saat pengunduhan file dari internet ataupun dari lokal web cache menggunakan aplikasi wireshark. Hasil pengujian dapat dilihat pada Gambar 5 dan Gambar 6. Gambar 5 merupakan hasil pengujian pengunduhan file sebelum tersimpan di cache. Rata-rata waktu pengunduhan file sebelum tersimpan di cache 129 detik dan rata-rata bandwidth-nya adalah 1024 Kbps. Gambar 6 merupakan hasil pengujian pengunduhan file setelah tersimpan di cache. Rata-rata waktu pengunduhan file 3 detik dan rata-rata bandwidth 68400 Kbps. Analisa keempat yaitu penggunaan web cache apabila konfigurasi topologi single gateway digunakan pada topologi yang berbeda. Topologi yang digunakan yaitu topologi dengan model DMZ seperti pada Gambar 7.
5
Gambar 5 Pengujian Pengunduhan File Sebelum Tersimpan di Cache
Gambar 6 Pengujian Pengunduhan File Setelah Tersimpan di Cache
6
192.168.10.0/24
Client
Router
192.168.1.254/ 24
Switch
Internet
192.168.5.0/24
Proxy Server (Web Cache
Gambar 7 Topologi DMZ
Gambar 7 merupakan topologi DMZ dimana semua trafik data akan melewati router. Koneksi dari client menuju internet akan dibelokkan ke proxy server oleh router. Demikian juga koneksi dari internet menuju client akan melewati router menuju ke proxy server sebelum sampai ke komputer client. Kemudian akan diberikan konfigurasi yang sama pada topologi single gateway sebelum menambahkan refresh_pattern pada konfigurasi squid. Pengujian dilakukan sebanyak 30 kali dengan cara yang sama seperti pada analisis sebelumnya. Hasil pengujian dapat dilihat pada Gambar 7.
Gambar 8 Hasil Pengujian Topologi DMZ Default Refresh_pattern
Gambar 8 merupakan hasil pengujian topologi DMZ yang hanya menggunakan default konfigurasi refresh_pattern. Selama 30 kali pengujian tidak ada satupun yang menunjukkan bahwa file tersebut disimpan dalam cache. Hal ini dibuktikan dengan presentase HIT 0,00 % dan MISS 99,84 % yang dicatat pada calamaris sehingga dengan konfigurasi refresh_pattern default squid, proses caching pada topologi DMZ belum dapat terjadi. Analisis selanjutnya dilakukan dengan memberikan konfigurasi refresh_pattern tambahan dan menerapkan konfigurasi dari manajemen bandwidth squid yang menggunakan delay_pool. 7
Konfigurasi delay_pool akan diubah menjadi konfigurasi simple queue pada Mikrotik dengan alokasi bandwidth sebesar 1024 Kbps. Hasil dari pengujian dapat dilihat pada Gambar 9, Gambar 10, dan Gambar 11.
Gambar 9 Hasil Pengujian Proses Caching Simple Queue dan Refresh_pattern
Gambar 10 Waktu Download dan Bandwidth Sebelum Tersimpan di Cache
Gambar 10 merupakan hasil analisis calamaris proses caching yang sudah diterapkan manajemen bandwidth menggunakan simple queue sebagai pengganti delay_pool pada squid serta memberikan konfigurasi tambahan refresh_pattern. Hasil dari calamaris telah menunjukkan bahwa proses caching sudah berjalan normal dengan adanya keterangan HIT sebesar 51,05% dan MISS 48,85%, tetapi 8
bandwidth yang didapat saat HIT dan MISS masih sama yaitu sebesar 1024Kbps seperti yang ditunjukkan pada Gambar 10 dan Gambar 11. Sedangkan rata-rata waktu pengunduhan file juga masih sama yaitu sebesar 36 detik, sehingga dapat disimpulkan bahwa proses caching sudah berjalan dengan normal pada topologi DMZ, tetapi proses pengelolaan trafik web cache belum dapat didistribusikan dengan baik.
Gambar 11 Waktu Download dan Bandwidth Setelah Tersimpan di Cache
Setelah proses analisis arsitektur jaringan selesai maka dilakukan proses analisa kebutuhan sistem untuk mendukung proses caching dengan menambah konfigurasi pada mangle dan manajemen bandwidth; Tahapan kedua: design merupakan tahap setelah hasil analisis didapatkan yang kemudian dibangunlah sebuah arsitektur jaringan dan topologi logikanya. Mengacu pada analisis yang didapat, arsitektur topologi DMZ tetap digunakan, tetapi pengubahan konfigurasi dilakukan dari yang semula hanya menggunakan simple queue dan refresh_pattern, akan ditambahkan firewall mangle dan pengaturan bandwidth diubah menjadi queue tree untuk mengatur jalur paket data web cache dan internet. Gambar 12 merupakan flowchart jalur paket Hit dan paket Miss untuk cache web proxy server. Koneksi dari Conn-Client1 akan dibelokkan ke proxy untuk melihat adanya data dalam cache, apabila data yang dimaksud belum terdapat pada cache maka Conn-Client1 mengambil data dari server asli dan menyimpannya di cache sedangkan paket data akan diarahkan ke Paket-MissProxy pada queue tree Miss. Apabila data yang dimaksud sudah terdapat dalam cache paket data akan ditandai dengan qos_flows dari squid yaitu 0x30. Paket data dari squid yang sudah ditandai akan diarahkan menuju router untuk kemudian diproses nilainya. Nilai 0x30 dalam hexadecimal akan disamakan nilainya
9
menjadi nilai decimal pada DSCP yaitu sebesar 12. Penggunaan nilai 12 berdasarkan kebutuhan untuk transfer file atau download file [7]. Saat nilai antara qos_flows dan DSCP sama maka paket data yang diambil merupakan data dari cache yang kemudian jalur paket datanya diarahkan ke Paket-Hit-Proxy pada queue tree Hit; Tahapan ketiga: simulation prototyping dilakukan dengan menggunakan bantuan aplikasi Cisco Packet Tracer dan hasil skema simulasi dapat dilihat pada Gambar 13. Start Input: ConnClient1
Redirect to Proxy Marking Qos_Flows
Checking Availble cache
NO
Marking DSCP !12
YES Marking Qos_Flows 0x30
Taking Data From Original Server
Matching DSCP 12
Save to cache
Taking Data From Cache
Paket-MissProxy
Paket-Hit-Proxy
Output: Queue Tree Miss
Output: Queue Tree HIT
End
Gambar 12 Flowchart jalur paket Hit dan paket Miss.
Gambar 13 Skema Simulasi Lingkungan Web Proxy Server
Gambar 13 merupakan skema simulasi lingkungan Web Proxy Server yang memiliki 5 client dan posisi antara router dengan Web Proxy Server sejajar. 10
Koneksi client menuju internet akan dibelokkan ke proxy server melalui port 3128 oleh router. Router akan memanajemen trafik baik dari lokal web cache atau dari internet; Tahap keempat: implementation merupakan tahap selanjutnya setelah tahap simulasi dilakukan yaitu pembangunan secara fisik yang mencakup instalasi mesin server, pengaturan jaringan fisik dan pengaturan alamat IP. Pengaturan jaringan fisik dilakukan pada sisi client, router, dan mesin server. Pengaturan sisi client dilakukan dengan mengatur alamat IP, gateway dan DNS. Pengaturan sisi router dilakukan dengan menambahkan firewall mangle untuk memisahkan jalur paket data dari internet (Miss) atau dari lokal web cache (Hit) dengan menambahkan nilai DSCP seperti pada Kode Program 4. Kode Program 4. Pengaturan Nilai DSCP pada Mikrotik 1.
ip firewall mangle add action=mark-connection chain=prerouting comment="Koneksi Client" disabled=no in-interface="LAN Client (Eth3)" new-connection-mark= Conn-Client1 passthrough=yes
2.
ip firewall mangle add action=mark-packet chain=postrouting comment=PaketMiss-Proxy connection-mark=Conn-Client1 disabled=no dscp=!12 new-packetmark= Paket-Miss-Proxy out-interface="LAN Client (Eth3)" passthrough=no
3.
ip firewall mangle add action=mark-packet chain=postrouting comment=PaketHit-Proxy connection-mark=Conn-Client1 disabled=no dscp=12 new-packetmark= Paket-Hit-Proxy out-interface="LAN Client (Eth3)" passthrough=no
Kode Program 4 merupakan pengaturan nilai DSCP pada Mikrotik untuk mengatur jalur Hit dan Miss. Kode Program 4 nomor 1 untuk membuat jalur koneksi dengan nama Conn-Client1. Kode Program 4 nomor 2 untuk membuat jalur paket MISS dari koneksi Conn-Client 1 dengan nama Paket-Miss-Proxy dengan menambah “!” pada DSCP yang artinya selain nilai DSCP yang ditentukan maka akan dianggap sebagai paket Miss. Kode Program 1 nomor 3 untuk membuat jalur paket Hit dari koneksi Conn-Client1 dengan nama PaketHit-Proxy. Contoh nilai DSCP yang digunakan pada penelitian ini yaitu dengan memberi nilai 12. Pengaturan sisi server dilakukan dengan mengatur alamat IP, gateway, DNS, serta mengatur pada squid.conf dengan menambahkan qos_flows untuk menerjemahkan nilai DSCP dari router menjadi nilai ToS pada squid seperti Kode Program 5. Kode Program 5 Pengaturan Nilai ToS pada Squid qos_flows local-hit=0x30
Kode Program 2 merupakan pengaturan nilai ToS pada Squid. Sebagai contoh dari nilai decimal DSCP yang digunakan pada penelitian ini yaitu 12 maka nilai ToS pada squid setelah disamakan nilai hexadecimal menjadi 0x30. Refresh_pattern juga ditambahkan untuk mengetahui tipe file seperti mp3, mp4, FLV, dan lain-lain dari web server tempat file diunduh agar dapat disimpan pada cache proxy server. Pengaturan batasan bandwidth dilakukan dengan membuat
11
queue tree untuk memisahkan bandwidth Miss dan Hit. Pengaturan queue tree dapat dilihat pada Kode Program 6. Kode Program 6 Pengaturan Queue Tree Paket Miss dan Paket Hit 1.
add burst-limit=0 burst-threshold=0 burst-time=0s disabled=no limit-at=0 max-limit=1M name="Total BW" packet-mark="" parent=global-out priority=8
2.
add burst-limit=0 burst-threshold=0 burst-time=0s disabled=no limit-at=204k max-limit=1M name=Client1 packet-mark=Packet-Miss-Client1 parent= "Total BW" priority=8 queue=default
3.
add burst-limit=0 burst-threshold=0 burst-time=0s disabled=no limit-at=0 max-limit=10M name=LAN-HIT packet-mark="" parent=ether3 priority=1
4.
add burst-limit=0 burst-threshold=0 burst-time=0s disabled=no limit-at=2M max-limit=10M name=Proxy-Hit-Client1 packet-mark=Packet-Hit-Client1 parent=LAN-HIT priority=1 queue=default
Kode Program 6 merupakan pengaturan queue tree paket Miss dan paket Hit. Kode Program 6 nomor 1 merupakan parent tree untuk paket Miss yang bernama Total BW dengan bandwidth total sebesar 1Mbps. Kode Program 6 nomor 2 merupakan child tree dari parent Total BW dengan nama Client1 untuk mengatur bandwidth jalur paket Miss yaitu Packet-Miss-Client1 dengan memberi nilai minimal bandwidth yang didapat client sebesar 204kbps dan nilai maksimalnya 1Mbps. Kode Program 6 nomor 3 merupakan parent tree untuk paket Hit dengan nama LAN-HIT mempunyai nilai total bandwidth sebesar 10Mbps. Kode Program 6 nomor 4 child tree dari parent LAN-HIT untuk mengatur bandwidth jalur paket Hit dari Packet-Hit-Client1 dengan memberi nilai minimal bandwidth yang didapat client sebesar 2Mbps dan nilai maksimalnya 10Mbps; Tahap kelima: monitoring merupakan proses setelah tahap implementation telah selesai dilakukan. Dalam proses monitoring dilakukan proses pengujian untuk mengambil hasil analisis yang dibutuhkan. Dalam proses pengujian terdapat beberapa aspek yang akan diamati antara lain: bandwidth proses mengunduh file, waktu rata-rata yang dibutuhkan untuk mengunduh file sebelum dan sesudah tersimpan pada cache, serta memeriksa calamaris saat proses Hit dan Miss pada squid; Tahap keenam: management merupakan tahap terakhir dari metode penelitian NDLC. Pada tahap ini dilakukan beberapa pengaturan yang disesuaikan dengan kebutuhan lapangan yang berkembang selama tahap monitoring antara lain mengubah nilai DSCP, mengganti nilai qos_flows dan mengatur mangle atau queue tree dalam router. 4.
Hasil dan Pembahasan
Hasil dan pembahasan merupakan bagian yang menampilkan pengujian dan hasil analisis yang disertai pembahasan pada setiap masing-masing bagian. Berikut merupakan hasil pengujian dan analisis pada pembuatan manajemen bandwidth dengan memanfaatkan DSCP. Pengujian dilakukan dengan cara mengunduh file yang sama dari web server yang sama secara bergantian dengan mencatat waktu pengunduhan serta mengukur bandwidth dengan bantuan
12
wireshark. Sebagai contoh apabila client 1 sedang mengunduh maka pengujian kedua pada client 2 harus menunggu proses pengunduhan yang dilakukan client 1 selesai. Pengujian pertama dilakukan dengan mengunduh file dari sebuah web server yang besarnya 9,3MB. Alamat IP pada client 1 yaitu 192.168.10.11 akan ditandai koneksinya dengan nama Conn-Client1 oleh Mikrotik. Pada saat client 1 mengunduh file tersebut maka Conn-Client1 akan dibelokkan menuju squid proxy untuk ditandai dengan qos_flows dan melihat di dalam cache proxy server apakah data yang dimaksud ada atau tidak. Karena tidak adanya cache yang dimaksud maka proxy server akan mengambil data dari server asli sehingga paket data yang ada akan ditandai dengan DSCP !12 sebagai Paket-Miss-Proxy yang tujuannya adalah alamat IP dari client 1 yaitu 192.168.10.11. Karena itu trafik yang berjalan pada mangle Mikrotik adalah Conn-Client1 dan Paket-Miss-Proxy seperti yang terlihat pada Gambar 14. Paket-Miss-Proxy akan ditandai yang kemudian paket tersebut akan diarahkan ke antrian Miss. Pada antrian Miss telah diberikan batasan bandwidth sebesar 1024Kbps sehingga pada saat hanya ada 1 client yang mengunduh file akan mendapat bandwidth maksimal seperti pada Gambar 15. Waktu pengunduhan file dan bandwidth diukur menggunakan wireshark dengan mengaktifkan filter berdasarkan ip tujuan yang kemudian ditampilkan melalui I/O graph seperti pada Gambar 16 yang merupakan waktu unduh file dan bandwidth miss pada percobaan pertama. Sumbu X merupakan interval waktu yang merupakan waktu pengunduhan saat itu sedangkan sumbu Y merupakan besarnya bandwidth yang didapat saat pengunduhan. Waktu yang dibutuhkan untuk mengunduh file sebesar 9,3 MB adalah 70 detik dan bandwidth yang didapat sebesar 1024Kbps. Setelah proses pengunduhan selesai maka calamaris akan membuat statistic proses caching dengan mempresentasikan HIT dan MISS seperti pada Gambar 16. Proses MISS akan dicatat apabila file yang diunduh berasal dari internet. Sedangkan proses HIT akan dicatat apabila file yang diunduh berasal dari lokal web cache. Pada percobaan pertama presentase HIT masih 0,00%, sedangkan MISS 98,03%.
Gambar 14 Trafik Mangle Paket Miss
Gambar 15 Queue Tree Miss
13
Gambar 16 Waktu Unduh File dan Bandwidth Miss
‟ Gambar 17 Calamaris Statistic Proses Caching Sebelum Tersimpan di Cache
Pengujian kedua dilakukan dengan mengunduh file yang sama dari client yang berbeda. Karena client 1 telah selesai mengunduh file maka data akan disimpan di dalam cache proxy server sehingga saat terjadi permintaan ke alamat web dan pengunduhan file yang sama maka proxy server akan mengambil data dari lokal web cache kemudian paket data yang ada akan ditandai dengan DSCP 12 sebagai Paket-Hit-Proxy yang tujuannya adalah alamat IP dari client 2 yaitu 192.168.10.12. Karena itu trafik yang berjalan adalah Conn-Client2 dan PaketHit-Proxy seperti yang terlihat pada Gambar 18. Paket-Hit-Proxy diarahkan ke antrian Hit yang mempunyai batasan bandwidth lebih besar daripada antrian Miss karena paket data yang diambil berasal dari lokal web cache. Karena hanya client 2 yang mengakses maka bandwidth yang didapat juga maksimal yaitu sebesar 10.240 Kbps. Hal ini dapat dilihat pada proses antrian seperti pada Gambar 19 dan wireshark pada Gambar 20. Waktu yang dibutuhkan untuk mengunduh file sebesar 9,3 MB adalah 70 detik.
14
Gambar 18 Trafik Mangle Paket Hit
Gambar 19 Queue Tree Hit
Gambar 20 Waktu Unduh File dan Bandwidth Hit
Gambar 21 Calamaris Statistic Proses Caching Setelah Tersimpan di Cache
15
Gambar 21 merupakan statistic calamaris pada pengujian kedua yaitu pengunduhan kedua kali dari file yang sama. Status dari calamaris menunjukkan, pada pengunduhan kedua akan terjadi HIT, sehingga presentase HIT menjadi 49,27% sedangkan presentase MISS 49,49%. Perbandingan hasil 30 kali pengujian penggunaan bandwidth internet dan lokal web cache dapat dilihat pada Gambar 22 dan Gambar 23. Gambar 22 merupakan waktu pengunduhan file dan bandwidth internet yang digunakan saat pertama kali mengakses dan mengunduh file yaitu selama 70 detik dengan bandwidth 1024 Kbps. Pengaksesan dan pengunduhan file pada pengujian selanjutnya tidak menggunakan bandwidth internet karena file telah tersimpan di dalam web cache sehingga waktu download dan bandwidth yang berasal dari internet menjadi 0. Waktu download dan bandwidth lokal web cache dapat dilihat pada Gambar 23 dengan rata-rata waktu download 9 detik dan bandwidth lokal sebesar 10240 Kbps, sehingga dapat dihitung penggunaan bandwidth, efisiensi, dan nilai ekonomisnya.
Gambar 22 Waktu Pengunduhan File dan Bandwidth Internet
16
Gambar 23 Waktu Pengunduhan File dan Bandwidth Lokal Web Cache
Bandwidth internet digunakan hanya pada saat pengujian pertama yaitu sebesar 1024 Kbps, sedangkan pengujian selanjutnya sebanyak 29 kali pengaksesan dan pengunduhan file menggunakan bandwidth lokal karena telah tersimpan di dalam web cache yaitu sebesar 10240 Kbps. Nilai efisiensi yang didapat karena hanya satu kali percobaan yang menggunakan bandwidth internet, maka nilai efisiensinya yaitu 30-1=29 sehingga apabila dipresentasekan diperoleh 29/30 x 100% = 96,67%. Nilai ekonomis yang didapat apabila 1KB mempunyai harga Rp 1,00 [8], untuk ukuran file sebesar 9,3 MB (9300KB) memiliki harga Rp1,00 x 9300 = Rp 9300,00, apabila selama 30 kali pengujian menggunakan bandwidth internet akan menghabiskan biaya 30 x Rp 9.300,00 = Rp 279.000,00, sehingga apabila hanya satu kali pengujian yang menggunakan bandwidth
17
internet, penghematan biaya atau nilai ekonomis yang didapat adalah Rp 279.000,00 – Rp 9.300,00 = Rp 269.700,00. 5.
Simpulan Dari penelitian yang dilakukan dapat disimpulkan bahwa pengelolaan trafik jalur data pada cache proxy server dengan memanfaatkan DSCP pada topologi DMZ untuk jalur paket dari internet (Miss) dan paket dari lokal web cache (Hit) dapat menghemat waktu dan bandwidth. Nilai efisiensi yang didapat dari 30 kali pengujian yaitu 96,67% karena hanya 1 pengujian yang menggunakan bandwidth internet sedangkan 29 kali menggunakan bandwidth lokal karena mengambil dari lokal web cache . Nilai ekonomis atau penghematan biaya yang didapat dari besar file 9300 KB apabila 1KB memiliki harga Rp1,00 yaitu Rp 269.700,00. 6. [1]
[2]
[3]
[4] [5] [6]
[7] [8]
Daftar Pustaka Mukherjee, Sabsyasachi and O.S Khanna. Fairness Evaluation of a DSCP Based Scheduling Algorithm for Real-Time Traffic in Differentiated Service Networks. International Jurnal of Information and Electronics Engeenering, Vol. 3, No. 4, July 2013. Irsyadi, Fatah Hasin Al, 2011, Implementasi Squid Server pada Proxy Cache Video, Surakarta, Fakultas Komunikasi dan Informatika Universitas Muhammadiyah Surakarta. Jurnal Emitor Vol 12 No. 01 ISSN 1411 8890. Chendramata, Aidil; Sunarto, J. Maeran; Rahayu, Intan. Pedoman Keamanan Web Server. Direktorat Keamanan Informasi, Direktorat Jenderal Aplikasi Informatika, Kementerian Komunikasi dan Informatika. 2011. Cisco System, Inc. (2008). Implementing Quality of Service Policies with DSCP. Cisco Documents. Riadi, Imam. 2010. Optimasi Bandwidth menggunakan Traffic Shapping. Jurnal Informatika, Vo. 4, No. 1, 2010. Goldman, Jawel E.; Philip T. Rawles, 2003, Applied Data Communications: A Business-Oriented Approach / Edition 4 Chapter 10. Wiley. 2004. http://www.hjp.at/doc/rfc/rfc4594.html (Diakses pada tanggal 1 September 2014). http://www.indosat.com/Personal/Internet/Paket_Super_Internet_masa_ aktif_3_6_dan_12_bulan (Diakses pada tanggal 1 September 2014).
18
