Bab 2. Protocol Lapisan Transport

Bab 2. Protocol Lapisan Transport

Protokol-protokol dalam lapisan Transport seperti dijelaskan dalam Bab sebelumnya, merupakan bagian yang sangat penting dalam jaringan komunikasi. Protokol-protokol ini membentuk logical communication antara proses aplikasi yang berjalan pada sebuah host menuju ke host yang lain. Yang dimaksud dengan logical communication adalah: proses aplikasi yang berjalan pada sebuah terminal yang terhubung pada terminal yang lain (misalnya: sebuah terminal melakukan akses web menuju ke web server atau ftp server) membentuk sebuah koneksi logika sedemikian sehingga seakan-akan kedua terminal tersebut langsung terhubung, padahal pada kenyataannya kedua terminal tersebut secara fisik terpisah oleh banyak sekali router dan proxy, serta perangkat-perangkat jaringan komputer yang lain, seperti terlihat dalam Gambar 2.1.

Gambar 2.1. Ilustrasi logical communication yang dibentuk oleh lapisan transport

Contoh lain lagi adalah pada saat seseorang melakukan sambungan telepon dengan menggunakan sambungan langsung jarak jauh kepada orang lain yang berada di kota yang berbeda. Dalam proses komunikasi semacam ini, kedua orang tersebut secara fisik terpisah oleh

jarak dan berbagai perangkat switch telekomunikasi, tetapi seakan-akan terjadi koneksi langsung antara kedua orang, yaitu pembicaraan dapat dilakukan secara langsung. Koneksi semacam ini kita sebut sebagai logical communication yang dibentuk oleh protokol-protokol dalam lapisan transport.

Di dalam lapisan transport pada Internet atau dalam hal ini TCP/IP, terdapat dua protokol utama yang telah digunakan secara luas yaitu Transmission Control Protocol (TCP) dan User Datagram Protocol (UDP). Dalam tugasnya sebagai protokol transport, tugas paling utama dari TCP dan UDP adalah membawa setiap paket data yang berasal dari lapisan network menuju ke lapisan aplikasi melalui multiplexing dan demultiplexing.

Gambar 2.2. Ilustrasi socket. Untuk memahami konsep multiplexing dan demultiplexing, mari kita melihat kembali konsep socket dalam TCP/IP. Seperti ditunjukkan dalam Gambar 2.2, socket berfungsi sebagai semacam pintu gerbang bagi data yang meghubungkan antara data pada lapis network dan data pada lapis aplikasi. Pada waktu tertentu, socket yang terbentuk dapat lebih dari satu. Misalkan sebuah terminal diidentifikasi dengan menggunakan sebuah nomor IP, akan tetapi pada kenyataannya terminal tersebut dapat membentuk socket lebih dari satu. Dengan kata lain, walaupun sebuah terminal hanya memiliki sebuah nomor IP saja, terminal tersebut dapat menggunakan proses dalam lapisan aplikasi yang bermacam-macam. Coba perhatikan masing-masing terminal yang anda gunakan untuk akses Internet, terminal tersebut kemungkinan besar hanya memiliki 1 buah nomor IP, tetapi proses akses sebuah atau lebih situs melalui protokol HTTP dapat dilakukan bersama-bersama dengan proses lain seperti transfer file melalui protokol FTP,

mengakses mailbox melalui protokol POP3, melakukan query melalui DNS server dan sebagainya. Hal ini dimungkinkan terjadi karena lapisan transport melakukan multiplexing dan demultiplexing seperti ditunjukkan dalam Gambar 2.3.

Masing-masing socket memiliki identifikasi yang berbeda satu dengan yang lain. Nomor identifikasi untuk socket seringkali dikenal sebagai nomor port. Sesuai dengan panjang field (16 bit) nomor port pada sebuah segment TCP atau UDP (silahkan cek kembali struktur segment dari TCP dan UDP), maka nomor dapat memiliki nomor antara 0 sampai 65535. Secara khusus nomor port antara 0 sampai 1023 disebut dengan well-known port numbers. Sebagai contoh protokol HTTP memiliki nomor port 80, FTP memiliki nomor port 21, DNS memiliki nomor port 53 dan seterusnya.

Perlu diperhatikan bahwa nomor port yang digunakan untuk identifikasi socket pada sisi terminal pengguna (client) tidak sama dengan nomor port untuk identifikasi socket pada sisi server. Semua well-known port numbers yang disebutkan di atas adalah nomor identifikasi untuk sisi server, sedangkan nomor port pada sisi client terbentuk secara acak (pada umumnya memiliki nomor di atas 1023) disebut dengan ephemeral port.

Gambar 2.3. Proses multiplexing dan demultiplexing pada lapisan transport

2.1.

Transmission Control Protocol (TCP)

2.1.1. Proses pembentukan koneksi pada TCP TCP adalah protokol yang connection-oriented. Disebut demikian karena sebelum sebuah komunikasi yang memanfaatkan protokol TCP antara dua buah terminal dapat terjadi, proses pembentukan/penetapan (establishment) koneksi harus dilakukan terlebih dahulu. Dalam proses ini kedua sisi akan melakukan inisialisasi seperti ditunjukkan dalam Gambar 2.4. Proses inisialisasi ini seringkali disebut dengan istilah three-way handshake.

Client

Server

Connection Request Send SYN=1, Seq=x Receive SYN=1

Receive SYN=1, Seq=y, ACK=x+1

Send SYN=1, Seq=y, ACK=x+1

Send SYN=0 Seq=x, ACK=y+1 Receive SYN=0, Seq=x, ACK=y+1

Gambar 2.4. Proses inisialisasi pada TCP: three-way handshake.

Langkah 1. Terminal pada sisi client meminta koneksi kepada server dengan cara mengirimkan segment TCP tanpa payload data (hanya header dari TCP, karena itu ukuran segment cukup kecil). Tetapi salah satu flag pada header dari TCP segment tersebut, yaitu flag SYN di set menjadi 1. Segment TCP ini disebut dengan segment SYN. Pada saat yang sama sisi client memilih sembarang sequence number, misalkan X, dan diletakkan pada slot sequence number dari TCP header. Segment SYN dikirimkan dari client menuju ke server sebagai tanda permintaan koneksi dari sisi client.

Langkah 2. Pada saat server menerima segment SYN yang berasal dari client, server selanjutnya membaca segment ini kemudian melakukan alokasi memory (buffer) dan mengirimkan segment balasan sebagai jaminan ketersediaan koneksi (apabila ada) kepada client. Segment ini juga tidak mengandung payload data. Sebagai penanda bahwa segment ini merupakan segment jaminan ketersediaan koneksi yang berasal dari server untuk client, server melakukan setting sebagai berikut: flag SYN dari segment

tersebut di set menjadi 1, server memilih sembarang sequence number, misalkan Y, kemudian diletakkan pada slot sequence number dari header TCP, dan terakhir server melakukan setting slot acknowledgment pada header TCP dengan nilai X+1. Segment balasan dari server ini seringkali disebut sebagai Segment SYNACK, yang kira-kira berarti “Saya telah menerima permintaan koneksi anda melalui segment dengan nomor inisialisasi X. Saya setuju untuk melakukan komunikasi dengan anda, dan nomor inisialisasi segment saya adalah Y.”

Langkah 3. Setelah menerima segment balasan sebagai jaminan koneksi dari server, selanjutnya client juga melakukan alokasi memory, dan mengirimkan segment pengakuan. Segment pengakuan ini memiliki flag SYN yang di set menjadi 0 (karena koneksi telah dibangun), slot dari sequence number diisi dengan nilai X, dan slot dari acknowledgment diisi dengan nilai Y+1.

Setelah proses three-way handshake selesai dilakukan, maka berikutnya kedua terminal dapat melakukan pertukaran data. Seperti terlihat dalam Gambar 2.5, proses (aplikasi) pada sisi client mengirimkan deretan data kepada lapis di bawahnya, yaitu TCP, melalui socket. Deretan data ini masuk ke dalam memory (buffer) yang telah di set pada saat inisialisasi three-way handshake terjadi, dan dikirimkan ke lapis dibawahnya. Perhatikan bahwa Gambar 2.5 tidak menggambarkan seluruh lapisan di bawah lapisan transport karena konsep logical link dalam bagian terdahulu.

Deretan data yang diambil dari lapis aplikasi dikelompokkan menjadi segment oleh lapis transport, yaitu header dari lapis transport ditambah dengan deretan data dari lapis aplikasi. Sekarang muncul pertanyaan berapa panjang deretan data yang dapat diletakkan ke dalam sebuah segment? Spesifikasi TCP tidak menetapkan berapa jumlah deretan data yang dapat ditampung dalam sebuah segment, karena itu jumlah deratan data tidak tentu (RFC 793). Tetapi perangkat jaringan biasanya menentukan panjang maksimum deretan data yang dapat ditampung dalam sebuah segment, disebut dengan istilah Maximum Segement Size (MSS). MSS sangat tergantung pada sistem operasi perangkat dan biasanya dapat dikonfigurasi, lazimnya 1500 byte, 536 byte dan 512 byte. MSS ini adalah jumlah deretan data maksimum yang dapat ditampung oleh segment, bukan panjang maksimum segment keseluruhan (ingat bahwa sebuah segment terdiri atas header dan payload/data). Sebagai contoh, data berupa file video melintasi jaringan

Internet, karena jumlah data file video cukup besar maka TCP akan membagi deretan data tersebut menjadi beberapa segment sedemikian rupa sehingga sebuah segment hanya dapat memuat maksimum data sebesar MSS.

Gambar 2.5. Proses pengiriman segment pada TCP

2.1.2. Struktur Segment pada TCP Segment terdiri atas dua bagian besar, yaitu header dan data atau payload. Payload adalah data yang berasal dari lapisan aplikasi. Struktur dari sebuah segment TCP secara detail ditunjukkan dalam Gambar 2.6. Penjelasan dari masing-masing slot adalah sebagai berikut: •

Bagian pertama dari header TCP adalah source port sepanjang 16 bit dan destination port sepanjang 16 bit, keduanya digunakan oleh TCP untuk menunjukkan nomor port sumber dan nomor port tujuan sebagai identifikasi dari jenis aplikasi yang sedang disetujui oleh client dan server, dalam hal ini keduanya berkaitan erat dengan proses multiplexing dan demultiplexing.

ECE URG ACK PSH RST SYN FIN

NS

CWR

Gambar 2.6. Struktur segment pada TCP •

Sequence number dengan panjang 32 bit merupakan nomor urut bagi segment TCP. Apabila flag SYN bernilai 1 maka sequence number berisi nomor inisialisasi bagi segment, tetapi apabila flag SYN bernilai 0 sequence number berisi nomor segment yang merupakan akumulasi panjang data dari byte yang paling awal sampai byte terakhir yang ada di dalam segment ini.

•

Acknowledgment number dengan panjang 32 bit merupakan nomor bagi segment acknowledgment. Apabila flag ACK di set ke 1 maka acknowledgment number berisi nomor urut dari segment berikutnya yang diharapkan oleh penerima.

•

Header length dengan panjang 4 bit menspesifikasikan panjang header dari segment TCP. Panjang header dapat berubah-ubah karena adanya slot options pada Gambar 2.6. Apabila options bernilai 0, maka panjang header hanya 20 byte.

•

Flag sebanyak 9 buah dengan panjang masing-masing 1 bit. (i) FIN: tidak ada data lagi dari pengirim. (ii) SYN: sinkronisasi sequence number. (iii) RST: reset koneksi. (iv) PSH digunakan untuk meminta mendorong data dari buffer ke lapisan aplikasi. (v) ACK: untuk menunjukkan bahwa segment ini adalah segment acknowledgement. (vi) URG: mengindikasikan data yang bersifat urgent. (vii) ECE (ECN-Echo): untuk indikasi Explicit Congestion Notification. (viii) CWR: untuk indikasi Congestion Window Reduced. (ix) NS: untuk indikasi ECN-nonce dengan tujuan untuk proteksi terhadap percobaan serangan dari pengirim.

•

Receive window dengan panjang 16 bit berisi jumlah dalam bentuk byte yang mengindikasikan jumlah data yang dapat ditampung oleh penerima pada saat ini.

•

Checksum sepanjang 16 bit digunakan untuk pengecekan kesalahan bit pada header dan data.

•

Urgent data pointer sepanjang 16 bit menunjuk pada sequence number dari data (yang bersifat urgent) terakhir apabila flag URG di set menjadi 1.

•

Options digunakan oleh pengirim dan penerima untuk melakukan negosiasi MSS.

Seperti terlihat dalam struktur segment TCP, TCP memotong-motong aliran data dalam bentuk byte ke dalam segment yang berurutan. Mari kita lihat sebuah contoh. Dua buah terminal A dan B akan bertukar data sebesar 90.000 byte dengan menggunakan TCP. MSS adalah 1500 byte. Misalkan inisialisasi sequence number awal adalah 0. Maka aliran data akan dipotong-potong menjadi 60 buah segment dengan masing-masing berisi data sebesar 1500 byte. Karena itu segment pertama mendapat nilai sequence number 0, segment kedua mendapat nilai sequence number 1500, segment ketiga mendapat nilai sequence number 3000 dan seterusnya. Bagaimana sekarang halnya dengan acknowledgment number? Dalam contoh di atas kita menyederhanakan proses pengiriman aliran data pada TCP menjadi half-duplex, yaitu pengiriman data satu arah (dari A ke B). Tetapi pada kenyataannya, TCP menggunakan model komunikasi full-duplex, artinya pada satu saat A dapat mengirim dan menerima aliran data, demikian juga B. Dengan demikian, pada saat terminal A mengirimkan segment data ke terminal B, pada saat yang sama terminal A dapat menerima aliran data lain yang berasal dari terminal B. Dalam hal ini, acknowledgment number yang diletakkan di dalam header segment data yang dikirimkan oleh terminal A berisi informasi tentang sequence number dari byte berikutnya yang diharapkan oleh A (dari terminal B). Misalkan, terminal A telah menerima semua data byte ke 0 sampai 1499 dari terminal B, dan sekarang terminal A akan mengirimkan segment ke terminal B. Bytes berikutnya yang diharapkan oleh terminal A adalah data mulai dari nomor 1500, maka terminal A meletakkan angka 1500 ini ke dalam acknowledgment number pada segment yang dikirim ke terminal B. Demikian seterusnya. Contoh lain lagi misalkan sekarang terminal A telah menerima segment dari terminal B berisi data byte ke 0 sampai 1499, dan terminal A juga telah menerima segment berisi

data byte ke 3000 sampai 4499. Karena suatu alasan tertentu terminal A belum menerima data byte ke 1500 sampai 2999, maka terminal A masih menunggu segment kedua dengan byte ke 1500 sampai 2999 ini. Segment ini dibutuhkan untuk proses pengurutan data di dalam terminal A. Karena segment berikutnya yang berasal dari A ke B akan memiliki acknowledgment number dengan nilai 1500. 2.1.3. Protokol sederhana untuk transaksi pesan Bagian ini memberikan gambaran yang disederhanakan tentang konsep pengiriman data yang reliable pada TCP, kita akan melihat bahwa protokol yang reliable sangat bergantung pada konsep pewaktu (timer). Gambaran transaksi pesan pada bagian ini hanya merupakan komunikasi satu arah, dari client menuju ke server.

Transaksi tanpa kehilangan data. Pada transaksi ini diasumsikan tidak ada kehilangan data sama sekali pada proses pengiriman atau penerimaan data. Perhatikan Gambar 2.7.

Client

Server

Send 1 Receive 1 Send ACK 2 Receive ACK 2 Send 2 Receive 2 Send ACK 3 Receive ACK 3 Send 3 Receive 3 Send ACK 4 Receive ACK 4 Window size=1

Gambar 2.7. Transaksi pesan tanpa kehilangan segment data

Koneksi dianggap telah terbentuk sebelumnya, client mengirimkan segment data dengan nomor 1. Setelah segment 1 terkirim, maka client harus menunggu konfirmasi dari server terlebih dahulu sebelum dalat mengirimkan segment ke 2. Apabila server telah menerima segment 1 dengan baik, tanpa kesalahan, maka server mengirimkan konfirmasi dalam bentuk segment acknowledgment ACK 2. Hal ini bagi client berarti: segment nomor 1 telah diterima oleh server, selantjutnya server meminta segment dengan nomor 2. Demikian seterusnya sampai semua segment terkirim. Dalam metoda

ini, terminal pengirim hanya dapat mengirimkan sebuah segment berikutnya setelah menerima konfirmasi dari terminal penerima, karena itu metoda ini disebut dengan Stop-and-Wait. Kelemahan metoda Stop-and-Wait adalah adanya waktu tunda yang cukup besar sampai seluruh segment data dikirimkan, di samping itu pengiriman data hanya dikirimkan per satu segment dalam sekali pengiriman (window=1). Karena itu metoda ini tidak diimplementasikan secara nyata pada protokol TCP.

Transaksi dengan kehilangan segment data. Sekarang mari kita perhatikan apa yang terjadi apabila sebuah segment data hilang dalam proses pengiriman. Perhatikan skenario dalam Gambar 2.8. Segment data dengan nomor urut 2 hilang dalam perjalanan (mungkin disebabkan oleh putusnya koneksi antar router dalam rimba Internet atau router sedang mengalami kongesi sehingga paket data di buang) sehingga server tidak menerima data tersebut, pada saat yang sama client sedang menunggu ACK 3 untuk dapat mengirimkan segment data berikutnya. Sebenarnya setiap kali segment data dikirimkan, baik client atau server selalu melakukan proses pewaktuan. Sehingga apabila kondisi semacam ini terjadi, maka setelah waktu time out tertentu yang ditetapkan oleh protokol terlampaui, Client akan mengirimkan kembali segment dengan nomor urut 2. Sekarang komunikasi dapat berjalan kembali.

Gambar 2.8. Transaksi pesan dengan kehilangan segment data

Transaksi dengan kehilangan segment ACK. Dalam proses transaksi pesan, mungkin sekali terjadi kehilangan segment ACK dalam perjalanan. Apabila hal ini terjadi maka,

sama seperti skenario sebelumnya protokol akan menunggu sampai waktu time out tertentu terlampaui, apabila segment ACK masih belum diterima selanjutnya client akan mengirimkan segmen data yang belum mendapatkan acknowledgment tersebut. Lihat skenario dalam Gambar 2.9 Setelah Server menerima segment dengan nomor urut 2, ACK 3 yang dikirimkan oleh Server tidak diterima oleh Client karena hilang dalam perjalanan. Maka setelah waktu tome out, Client mengirimkan ulang segment 2. Tentu saja Server akan menerima dua segment dengan nomor urut sama, tetapi Server cukup cerdas untuk mengambil hanya salah satu dari segment data yang sama tersebut.

Gambar 2.9. Transaksi pesan dengan kehilangan segment ACK

Transaksi dengan premature time out. Contoh kasus berikutnya adalah baik segment data maupun ACK mengalami kongesi di dalam salah satu router, tetapi segment tidak hilang, sedemikian sehingga segment baru tiba setelah waktu time out terlampaui. Perhatikan Gambar 2.10. Maka Client akan mengirimkan kembali segment data dengan nomor urut 2. Karena Server menerima dua buah segment dengan nomor urut sama, Server akan mengambil salah satu segment saja. Sementara itu di sisi Client, apabila ACK 3 diterima sebanyak dua kali, maka kali kedua Client tidak akan mengirimkan ulang segment yang sama. Client hanya akan menunggu sampai Segment dengan nomor urut 3 mendapatkan acknowledgment dari Server.

Gambar 2.10. Transaksi pesan dengan premature time out.

Transaksi dengan protokol Go-Back-N. Pada contoh-contoh transaksi data sebelumnya, hanya satu buah segment dapat dikirimkan pada satu saat. Sehingga apabila protokol ini diimplementasikan secara nyata, waktu tunda antara Client dan Server akan menjadi sangat besar sekali. Tetapi pada Go-Back-N, protokol mengijinkan pengiriman sebanyak N segment pada satu saat. Nilai N seringkali disebut sebagai ukuran window size (bandingkan dengan Gambar 2.7), dan protokol Go-Back-N sendiri seringkali disebut dengan istilah sliding-window protocol. Seperti terlihat dalam Gambar 2.11, Client dapat mengirimkan 4 segment sekaligus, sebaliknya sisi Server harus memberikan acknowledge satu-persatu terhadap segment yang telah diterima dengan benar. Akan tetapi, apabila terdapat kehilangan salah satu segment data (segment nomor urut 2 pada Gambar), maka segment 3 dan 4 yang telah dikirimkan dalam satu window (window size=4) dengan segment 2 akan dibuang oleh Server karena Server mendeteksi segment yang datang tidak berurutan, selanjutnya server mengirimkan ACK nomor 2. Karena acknowledgment yang dikirimkan oleh Server merupakan acknowledgment terakhir sejak segment hilang, model ini seringkali disebut sebagai cumulative acknowledgments.

Berikutnya Server akan menunggu sampai segment 2 datang

terlebih dahulu, baru kemudian segment dengan nomor urut 3,4 dan seterusnya dapat diterima.

Gambar 2.11. Transaksi pesan dengan protokol Go-Back-N

Transaksi dengan protokol Selective Repeat. Pada transaksi data dengan menggunakan protokol Go-Back-N di atas, apabila terjadi kesalahan pada salah satu segment, maka seluruh segment yang dikirimkan setelah segment yang salah tersebut akan dibuang karena Server mendeteksi adanya segment yang tidak berurutan. Metoda ini mengakibatkan efisiensi sistem secara keseluruhan akan menurun, karena segment yang telah diterima oleh Server dengan benar tetap akan dibuang dan diminta untuk dikirimkan ulang apabila segment tidak berurutan. Metoda yang lebih efisien untuk mengatasi kekurangan metoda Go-Back-N adalah protokol Selective Repeat. Pada protokol ini hanya segment yang mengalami kesalahan saja yang akan dikirimkan ulang, sedangkan segment-segment lain yang sudah diterima dengan benar tetap akan disimpan (tidak dibuang) sampai seluruh segment secara berurutan telah diterima oleh Server. Protokol ini memiliki kemampuan untuk melakukan seleksi terhadap segment tertentu saja yang perlu dikirimkan ulang. Karena itu, berbeda dengan protokol Go-BackN, protokol ini tidak menggunakan cumulative acknowledgment. Protokol ini membutuhkan acknowledgment dari setiap segment yang dikirimkan oleh Client. Karena ini pada protokol Selective Repeat, secara semantik nomor dari ACK tidak merepresentasikan nomor dari dari segment berikutnya yang diharapkan. Lihat ilustrasi dalam Gambar 2.12.

Gambar 2.12. Transaksi pesan dengan protokol Selective Repeat

2.1.4. Transaksi pesan pada TCP TCP merupakan protokol pada lapisan transport yang bersifat dapat diandalkan (reliable). Dalam hal ini TCP akan menjamin bahwa aliran data dari pengirim menuju ke penerima tidak mengandung kesalahan bit, tidak ada duplikasi segment dan diterima sesuai dengan urutan. Dengan kata lain setiap aliran data yang diterima oleh terminal penerima persis sama dengan aliran data yang dikirimkan oleh terminal pengirim. Namun untuk menjamin aliran data yang reliable dibutuhkan proses yang cukup rumit, apalagi pada kenyataannya protokol TCP berjalan di atas protokol IP yang bersifat unreliable (ingat bahwa protokol IP menggunakan konsep best effort service).

Menurut rekomendasi dalam RFC 2581, TCP menggunakan metoda Selective Acknowledge (SACK). Metoda SACK mirip dengan metoda Selective Repeat, yang mana dalam implementasi sebenarnya TCP tidak membuang segment datang yang tidak berurutan melainkan menyimpan sampai semua segment berurutan. Tetapi pada saat yang sama TCP juga menggunakan cummulative acknowledgments, seperti halnya pada metoda Go-Back-N. Karena itu pada dasarnya SACK memiliki kemiripan dengan Selective Repeat dan Go-Back-N.

Tugas 1: Bagaimana transaksi pesan pada TCP dengan menggunakan metoda SACK ini terjadi? Berikan contoh dengan menggunakan diagram transaksi pesan!

2.1.5. Estimasi waktu time out Setelah mempelajari beberapa skenario transmisi data seperti di atas, pertanyaan logis yang muncul adalah bagaimana protokol melakukan estimasi terhadap waktu time out. Pertama-tama baik Client ataupun Server harus mengetahui terlebih dahulu berapa waktu yang dibutuhkan oleh segment data melintas dari Client menuju ke Server kemudian dari Server kembali ke Client. Waktu lintasan ini di sebut dengan nama Round Trip Time (RTT). Dalam setiap koneksi kemungkinan besar nilai RTT akan berbeda-beda karena posisi Client dan Server berbeda-beda. Apabila koneksi dilakukan oleh Client dan Server yang sama, kemungkinan besar lintasan yang dilewati berbeda dari waktu ke waktu. Apabila koneksi dilakukan oleh Client dan Server yang sama dan melalui lintasan yang sama, kemungkinan besar kondisi jaringan berbeda dari waktu ke waktu. Karena itu RTT pasti berbeda dari waktu ke waktu.

Protokol TCP dalam implementasinya selalu menghitung waktu yang dibutuhkan mulai dari saat sebuah segment dikirimkan sampai acknowledgment dari segment tersebut diterima. Mari kita notasikan sampel RTT ini sebagai RTTsampel (t). TCP hanya menghitung segment yang dikirimkan sekali saja, TCP tidak menghitung segment yang dikirimkan ulang. Karena nilai RTTsampel (t) ini berbeda-beda dari waktu ke waktu, maka TCP tidak dapat menggunakan RTTsampel (t) sebagai acuan. Dalam hal ini TCP lebih tertarik pada estimasi dari RTT dalam bentuk rata-rata dari sampel RTT. Estimasi RTT ini dinotasikan sebagai RTTestimasi (t). Estimasi terhadap RTT dilakukan secara online dengan menggunakan rumusan (Jacobson’s Algorithm):

ܴܶܶ௘௦௧௜௠௔௦௜ ሺ‫ݐ‬ሻ = ሺ1 − ߙሻ ∗ ܴܶܶ௘௦௧௜௠௔௦௜ ሺ‫ ݐ‬− 1ሻ + ߙ ∗ ܴܶܶ௦௔௠௣௘௟ ሺ‫ݐ‬ሻ Berdasarkan rekomendasi dalam RFC 2988, nilai ߙ = 0.125. Kalau kita perhatikan dengan seksama, persamaan di atas memberikan bobot lebih besar pada sampel yang paling baru daripada pada sampel yang lama. Persamaan matematika di atas dalam bidang statistik seringkali dikenal dengan nama exponential weighted moving average (EWMA).

Karena nilai dari RTTestimasi (t) merupakan nilai rata-rata, secara statistik kita juga dapat menghitung variasi dari sampel RTT. Sesuai dengan RFC 2988, variasi dari RTT yang dinotasikan dengan simbol RTTvar(t) dirumuskan sebagai:

ܴܶܶ௩௔௥ ሺ‫ݐ‬ሻ = ሺ1 − ߚሻ ∗ ܴܶܶ௩௔௥ ሺ‫ ݐ‬− 1ሻ + ߚ ∗ หܴܶܶ௦௔௠௣௘௟ ሺ‫ݐ‬ሻ − ܴܶܶ௘௦௧௜௠௔௦௜ ሺ‫ݐ‬ሻห Nilai rekomendasi dari parameter ߚ = 0.25. Gambar 2.13 menunjukkan grafik dari nilai RTTsampel (t) dan RTTestimasi (t), nilai sampel RTT pada gambar diambil dengan menggunakan aplikasi PING yang berasal dari domain stikom.edu menuju ke sebuah perguruan tinggi di Australia dengan alamat situs http://www.rmit.edu.au.

Setelah mengetahui nilai estimasi dari RTT, sekarang protokol TCP harus dapat menentukan waktu time out dengan baik. Apabila waktu time out terlalu cepat, maka akan sering terjadi pengiriman ulang segment, sebaliknya apabila waktu time out terlalu lama maka pengiriman ulang segment yang hilang akan membutuhkan delay yang sangat besar. Karena itu protokol TCP menggunakan rumusan berikut untuk menentukan waktu time out:

ܶ݅݉݁‫ݐݑ݋‬ሺ‫ݐ‬ሻ = ܴܶܶ௘௦௧௜௠௔௦௜ ሺ‫ݐ‬ሻ + 4 ∗ ܴܶܶ௩௔௥ ሺ‫ݐ‬ሻ

440 430 420 410 400

RTT sampel

390

RTT estimasi

380 370 360 350 1 6 11 16 21 26 31 36 41 46 51 56 61 66 71 76 81 86 91 96

Gambar 2.13. Estimasi RTT

Tugas 2: Lakukan pengambilan 100 sampel RTT dengan menggunakan aplikasi PING pada Windows ke sembarang situs yang ada di luar Indonesia, selanjutnya dengan menggunakan data tersebut lakukan perhitungan RTTestimasi (t) dan RTTvar(t) dan gambarkan dalam bentuk grafik!

2.1.6. Flow Control Pada bagian sebelumnya dijelaskan bahwa protokol TCP mensyaratkan adanya memori sementara yang harus disediakan baik oleh sisi Server ataupun Client. Memori sementara ini digunakan untuk menampung data yang tidak mengandung kesalahan (telah melalui proses error check dan error correction yang ada pada TCP). Selanjutnya aplikasi akan mengambil data dari memori sementara ini untuk dipresentasikan kepada pengguna. Akan tetapi sangat mungkin sekali terjadi keadaan yang mana aplikasi terlalu sibuk dengan pekerjaan lain, sehingga proses pengambilan data dari memori sementara ini tertunda. Pada keadaan semacam ini, apabila pengirim terus menerus mengirimkan data maka akan terjadi proses yang dinamakan sebagai memory overflow. Untuk mengatasi hal ini TCP menggunakan flow control yang berfungsi untuk menjaga agar kecepatan pengiriman data oleh pengirim sama dengan kecepatan pembacaan data oleh aplikasi pada sisi penerima.

Untuk dapat memberikan layanan flow control, TCP menggunakan sebuah variabel yang ada pada header TCP bernama receive window. Receive window ini digunakan untuk memberitahu pengirim berapa jumlah memori yang masih bisa digunakan untuk menampung data. Sekarang mari kita definisikan beberapa variabel untuk memahami cari kerja dari flow control. •

RcvBuffer: ukuran dari memori (buffer) yang telah dialokasikan pada sisi penerima.

•

LastByteRead: jumlah byte terakhir dari aliran data yang telah dibaca dari memori oleh aplikasi.

•

LastByteRcvd: jumlah byte terakhir dari aliran data yang telah diterima dari jaringan dan ditempatkan pada memori (buffer).

Untuk mencegah agar tidak terjadi limpahan data pada memori, maka persyaratan yang harus dipatuhi dapat dirumuskan sebagai berikut:

LastByteRcvd – LastByteRead ≤ RcvBuffer

Karena itu variabel receive window disimbolkan dengan RcvWindow berisi jumlah ruang yang masih dapat diisi oleh data pada memori, dituliskan sebagai:

RcvWindow = RcvBuffer – (LastByteRcvd – LastByteRead).

Variabel RcvWindow ini bersifat dinamis, karena nilai variabel tersebut selalu berubahubah terhadap waktu. Gambar 2.14 menggambarkan variabel RcvWindow.

Gambar 2.14. Ilustrasi variabel RcvWindow pada flow control

Seperti terlihat dalam ilustrasi Gambar 2.14, pada saat sebelum memori terisi data maka nilai variabel RcvWindow akan bernilai sama dengan variabel RcvBuffer. Pada saat data mulai mengisi memori variabel RcvWindow akan semakin mengecil menuju ke 0 sampai seluruh ruang pada memori terisi data. Penerima mengirimkan informasi RcvWindow ini kepada pengirim dengan meletakkan nilai variable RcvWindow pada header dari TCP.

Sebaliknya, sisi pengirim mengendalikan flow control dengan menggunakan dua buah variabel yaitu: •

LastByteSent: jumlah byte dari aliran data yang telah dikirimkan,

•

LastByteAcked: jumlah byte dari aliran data yang telah menerima ACK dari penerima.

Jumlah data pada sisi pengirim yang telah dikirimkan tetapi belum menerima ACK adalah:

LastByteSent – LastByteAcked.

Flow control pada sisi pengirim dilakukan dengan cara menjaga agar julah data yang telah terkirim tapi belum menerima ACK tersebut bernilai sama atau lebih kecil dari RcvWindow, atau secara matematis dapat dituliskan dengan rumusan:

LastByteSent – LastByteAcked ≤ RcvWindow.

2.1.7. Congestion Control TCP menggunakan congestion control untuk membatasi kecepatan pengiriman data pada saat terjadi kongesi di dalam jaringan. Secara umum, pada saat pengirim mendeteksi bahwa jaringan sedang mengalami kongesi, maka pengirim akan menurunkan kecepatan pengiriman data. Akan tetapi apabila pengirim mendeteksi bahwa kongesi dalam jaringan telah berkurang, maka pengirim akan meningkatkan kecepatan pengiriman data.

Kongesi di dalam jaringan dapat terjadi terutama karena adanya keterbatasan memori pada router, padahal pada saat yang sama setiap pengguna di dalam jaringan ingin menggunakan kapasitas jalur komunikasi di dalam jaringan sebanyak-banyaknya. Di sisi yang lain, meningkatkan jumlah memori pada router mendekati jumlah yang tak terbatas mungkin dapat mengatasi masalah kongesi dalam jaringan tetapi membawa efek negatif yang lain yaitu semakin tingginya waktu tunda (delay) antara pengirim dan penerima.

Mari sekarang kita perhatikan bagaimana congestion control dilakukan oleh TCP. Mekanisme congestion control pada TCP dilakukan dengan menggunakan variabel congestion window yang beroperasi baik pada sisi pengirim maupun penerima, disimbolkan sebagai CongWin. Variabel ini berisi informasi tentang kecepatan pengiriman data yang dapat dilakukan oleh sisi pengirim, dan dirumuskan sebagai: jumlah data yang akan dikirimkan yang belum mendapatkan acknowledgment tidak

boleh melebihi jumlah CongWin atau RcvWindow. Secara matematis dapat dirumuskan sebagai:

LastByteSent - LastByteAcked ≤ min{CongWin, RcvWindow}

Apabila kita asumsikan bahwa memori pada sisi penerima sangat besar, maka kita akan dapati bahwa jumlah data yang akan dikirimkan yang belum mendapatkan acknowledgment dibatasi oleh variabel CongWin saja. Marilah kita asumsikan demikian. Dengan demikian rumusan di atas berarti bahwa jumlah data yang akan dikirimkan yang belum mendapatkan acknowledgment dibatasi oleh variabel CongWin, dengan cara demikian kecepatan pengiriman data menjadi terbatas. Pada setiap awal koneksi CongWin di set sebesar MSS byte dan dikirimkan melintasi jaringan, selanjutnya setelah pengirim menerima acknowledgment dan melakukan pengukuran terhadap RTT, maka pengirim dapat menghitung perkiraan kecepatan pengiriman data yang harus dilakukan sebesar CongWin/RTT bytes/sec. Dengan cara demikian kecepatan pengiriman data dapat diatur dengan cara mengubah-ubah jumlah CongWin.

a. Additive-Increase, Multiplicative-Decrease Apabila terjadi kondisi di mana perangkat router di dalam jaringan Internet tidak lagi dapat menerima/memproses data, congestion control pada dasarnya akan meminta pengirim untuk menurunkan kecepatan pengiriman data dengan cara menurunkan ukuran CongWin, dengan cara demikian diharapkan router akan memiliki cukup waktu untuk memproses data. TCP mengetahui bahwa jaringan sedang mengalami kongesi apabila 1) waktu time-out pada sisi pengirim terlampaui atau 2) pengirim menerima tiga duplikasi ACK dari sisi penerima.

Untuk menurunkan kecepatan pengiriman data, TCP menggunakan konsep multiplicative decrease, yaitu dengan cara menurunkan sebanyak setengah dari ukuran CongWin. Misalkan ukuran kongesi window pada saat ini adalah 20 KB, maka pada saat terjadi kongesi TCP akan menurunkan ukuran kongesi window menjadi 10 KB, demikian pula apabila terjadi kongesi window lagi, maka ukuran kongesi window akan diturunkan menjadi 5 KB. Akan tetapi penurunan kongesi window tidak diperbolehkan kurang dari ukuran 1 MSS.

Gambar 2.15. Ilustrasi Additive-Increase, Multiplicative-Decrease

Selanjutnya, apabila pengirim telah mengidentifikasi bahwa kongesi di dalam jaringan telah berkurang, maka TCP akan menaikkan kembali kecepatan pengiriman data secara perlahan-lahan. Dalam hal ini TCP akan meningkatkan nilai CongWin sebanyak kira-kira 1 MSS setiap kali pengirim menerima ACK atau setiap RTT. Sehingga kecepatan pengiriman data akan meningkat secara aditif. Karena itu algoritma congestion control semacam ini disebut sebagai Additive-Increase, Multiplicative-Decrease (AIMD). Pada saat TCP melakukan kenaikan kecepatan secara linier semacam ini, kondisi ini disebut sebagai Congestion Avoidance. Ilustrasi metoda AIMD ditunjukkan dalam Gambar 2.15. Terlihat bahwa ukuran kongesi window bergerak dalam sebuah siklus “meningkat secara linier kemudian turun setengahnya” dan seterusnya menyerupai pola gigi gergaji.

b. Slow Start Pada saat TCP memulai koneksi pertama kali, nilai dari CongWin diinisialisasi sebesar 1 MSS. Dengan demikian kecepatan TCP mengirimkan data pada saat ini adalah MSS/RTT. Misalkan nilai MSS adalah 1000 byte, sedangkan estimasi terhadap nilai RTT adalah 200 mili detik, maka kecepatan TCP pada saat awal koneksi adalah 400 Kbps. Dengan inisialisasi semacam ini, apabila bandwidth di dalam jaringan yang tersedia sangat besar, maka menaikkan kecepatan pengiriman data secara linier hanya akan memperlambat proses pengiriman data secara keseluruhan. Untuk mengatasi hal ini, metoda slow start TCP menaikkan kecepatan pengiriman data secara eksponensial dengan cara menaikkan nilai CongWin sebanyak dua kali setiap RTT. Selanjutnya pengirim akan menaikkan kecepatan pengiriman data secara

eksponensial sampai terjadi kongesi pada jaringan. Apabila terjadi kongesi (melalui adanya waktu time-out atau menerima ACK sebanyak 3 kali), maka kecepatan akan diturunkan setengahnya dan kemudian meningkat perlahan-lahan secara linier.

Dengan cara seperti dijelaskan di atas, TCP mengawali koneksi dengan slow start kemudian meningkatkan kecepatan pengiriman data secara eksponensial sehingga kecepatan pengiriman data akan meningkat dengan sangat cepat. Pengirim meningkatkan kecepatan secara eksponensial dengan cara menaikkan nilai CongWin sebesar 1 MSS setiap kali mendapatkan ACK dari segment yang dikirimkan. Sebagai contoh, mula-mula pengirim mentransmisikan sebuah segment, apa bila segment tersebut mendapatkan acknowledgment (ACK diterima oleh pengirim) maka pengirim akan meningkatkan nilai CongWin sebesar 1 MSS dan mengirimkan 2 buah segment

lagi.

Apabila

kedua

buah

segment

tersebut

mendapatkan

acknowledgment, maka sekarang pengirim akan meningkatkan nilai CongWin sebanyak 1 MSS lagi untuk setiap segment yang telah menerima ACK sehinggal nilai CongWin saat ini telah menjadi 4 MSS dan selanjutnya pengirim mengirimkan 4 buah segment lagi. Demikian seterusnya sampai kongesi di dalam jaringan terjadi. Pada fase inisialisasi slow start semacam ini terlihat bahwa nilai CongWin meningkat dua kali lipat setiap RTT.

c. Fast Recovery Pada bagian sebelumnya telah dijelaskan bagaimana TCP melakukan proses inisialisasi kecepatan pengiriman data dengan menggunakan metoda slow start. Proses inisialisasi slow start akan berakhir pada saat TCP mendeteksi adanya kongesi pada jaringan, dan selanjutnya TCP akan menggunakan metoda AIMD seperti dijelaskan di atas.

Akan tetapi pada keadaan yang sebenarnya TCP bereaksi secara berbeda untuk kedua cara deteksi adanya kongesi dalam jaringan, yaitu melalui time-out atau pengirim menerima 3 duplikasi ACK. •

Apabila pengirim mendeteksi adanya kongesi dalam jaringan melalui adanya 3 duplikasi ACK yang datang, nilai dari CongWin akan diturunkan menjadi setengah dan selanjutnya meningkat secara linier seperti dijelaskan dalam metoda AIMD.

•

Sebaliknya, apabila pengirim mendeteksi adanya kongesi dalam jaringan melalui adanya time-out, maka TCP pada sisi pengirim akan menetapkan nilai CongWin sebesar 1 MSS dan pengirim memasuki fase slow start. Berikutnya nilai CongWin akan meningkat secara eksponensial sampai mencapai setengah dari nilai CongWin sebelum time-out terjadi. Selanjutnya nilai CongWin akan meningkat secara linier sebagaimana halnya terjadi pada saat pengirim duplikasi 3 ACK.

Pertanyaan yang muncul sekarang adalah kapan TCP mengetahui saat fase slow start berakhir dan kapan fase congestion acoidance dimulai? Dalam hal ini TCP menetapkan sebuah variabel yang disebut dengan Threshold. Variabel ini mendefinisikan ukuran dari CongWin pada saat fase slow star berakhir dan saat fase congestion avoidance dimulai. Variabel threshold pada awalnya ditetapkan dengan nilai cukup besar, dalam praktek disarankan sebesar 65 Kbyte. Apabila terjadi kongesi dalam jaringan maka nilai threshold akan diturunkan menjadi setengah dari nilai CongWin. Misalnya, sebelum terjadi kongesi nilai CongWin sebesar 32 Kbyte, sesaat setelah terjadi kongesi nilai threshold adalah 16 Kbyte.

Algoritma congestion control pada TCP dapat dirangkumkan sebagai berikut: •

Apabila kongesi window berada di bawah nilai threshold, maka kecepatan pengiriman data oleh pengirim berada pada fase slow start dan nilai CongWin akan meningkat secara eksponensial.

•

Apabila kongesi window berada di atas nilai threshold, maka kecepatan pengiriman data oleh pengirim berada pada fase congestion avoidance dan nilai CongWin akan meningkat secara linier.

•

Apabila pengirim menerima duplikasi 3 ACK, nilai threshold akan ditetapkan menjadi setengah dari nilai CongWin saat sebelum terjadi kongesi dan nilai CongWin ditetapkan menajdi sama dengan nilai threshold.

•

Apabila pengirim mengalami time-out, nilai threshold akan ditetapkan menjadi setengah dari nilai CongWin dan nilai CongWin ditetapkan menjadi 1 MSS.

Dengan mengikuti penjelasan di atas, terlihat bahwa TCP bereaksi secara berbeda untuk kondisi dimana pengirim mendeteksi kongesi melalui time-out atau menerima

duplikasi 3 ACK. Pada saat awal protokol TCP dibuat, TCP akan menurunkan nilai CongWin menjadi 1 MSS untuk selanjutnya memasuki fase slow start baik setelah menerima duplikasi 3 ACK atau mengalami time-out. Model ini dikenal dengan nama TCP Tahoe. Versi terbaru dari TCP adalah TCP Reno. TCP Reno membuang fase slow start pada saat mendeteksi kongesi melalui diterimanya 3 duplikasi ACK. Untuk selanjutnya proses ini disebut dengan nama Fast Recovery. Pada saat pengirim menerima 3 duplikasi ACK maka nilai threshold akan diturunkan menjadi setengah dari nilai CongWin saat sebelum terjadi kongesi, dan nilai CongWin ditetapkan sama dengan nilai threshold dan selanjutnya kecepatan pengiriman data akan meningkat secara linier. Perbedaan antara TCP Tahoe dan TCP Reno dapat dilihat dalam Gambar 2.16.

Gambar 2.16. Congestion control pada TCP dengan TCP Tahoe dan TCP Reno

Seperti terlihat dalam Gambar 2.16, TCP pada awalnya menginisialisasi nilai CongWin sebesar 1 MSS, asumsikan 1 MSS adalah 1 KB. Kecepatan pengiriman data akan meningkat secara ekponensial sampai nilai CongWin mencapai 16 KB yaitu nilai threshold. Setelah mencapai nilai threshold nilai CongWin hanya akan meningkat secara linier. Pada pengirim menerima 3 duplikasi ACK, berarti terjadi kongesi dalam jaringan, TCP Tahoe akan menurunkan nilai CongWin menjadi 1 MSS dan berikutnya kecepatan akan naik secara eksponensial. Sedangkan pada TCP Reno nilai CongWin hanya akan diturunkan setengah dari nilai CongWin sebelumnya, selanjutnya kecepatan akan naik secara linier.

Implementasi TCP saat ini menggunakan algoritma TCP Reno. Tetapi dengan semakin berkembangnya pemakaian Internet, banyak modifikasi terhadap algoritma congestion control pada TCP dilakukan. Sebagai contoh terdapat algoritma baru seperti TCP Vegas dan TCP Roma.

Tugas 3. Jelaskan bagaimana konsep dari algoritma congestion control TCP Vegas dan TCP Roma. Cari informasi dalam beberapa buku dan paper!

2.1.8. Terminasi koneksi pada TCP Proses terminasi koneksi dapat dilakukan oleh pengirim dan penerima. Implementasi terminasi koneksi dapat dilakukan dengan menggunakan salah satu dari 2 cara, yaitu: three-way handshaking atau four-way handshaking with a hald-close option.

Three-way handshaking. Urutan proses dari three-way handshaking untuk penutupan koneksi adalah sebagai berikut (lihat Gambar 2.17). 1) Pada saat Client akan melakukan penutupan koneksi, maka terminal tersebut mengirimkan segment FIN kepada Server. Segment FIN adalah segment TCP dengan nilai flag FIN diaktifkan. Segment FIN ini dapat merupakan file terakhir dari data yang dikirimkan oleh Client atau merupakan segment sendiri dengan 1 sequence number saja. 2) Pada saat Server menerima segment FIN, maka sebagai konfirmasi Server akan mengirimkan segment FIN+ACK. Pada saat yang sama segment ini juga berarti deklarasi penutupan koneksi yang dilakukan oleh terminal Client. Segment FIN+ACK ini dapat merupakan file terakhir dari data yang dikirimkan oleh Server atau merupakan segment sendiri dengan 1 sequence number saja. 3) Langkah terakhir, Client mengirimkan segment ACK sebagai konfirmasi bahwa ia telah menerima segment FIN dari Server. Segment ini mengandung nomor ACK dengan nilai 1 ditambah sequence number di dalam segment FIN yang telah dikirimkan oleh Server. Karena segment ini tidak mengandung data, maka segment ini tidak melakukan penambahan sequence number sama sekali.

Gambar 2.17. Ilustrasi penutupan koneksi pada TCP dengan three-way handshaking. Four-way handshaking. TCP memungkinkan kondisi dimana sebuah terminal telah selesai melakukan pengiriman data tetapi pada saat yang sama masih sedang menerima data. Kondisi ini disebut sebagai half-close. Baik Client atau Server dapat melakukan permintaan half-close ini. Sebagai contoh adalah proses pengurutan data. Misalnya, Client mengirimkan data ke Server untuk diurutkan, pada saat Client telah selesai melakukan pengiriman data Client dapat melakukan penutupan koneksi, tetapi pada saat yang sama Server belum selesai menerima data karena itu koneksi dalam posisi half-close. Lihat Gambar 2.18.

Seperti terlihat dalam Gambar 2.18, Client meminta half-close dengan mengirimkan segment FIN, selanjutnya server menanggapi permintaan tersebut dengan mengirimkan ACK. Pada saat ini Client telah berhenti mengirimkan data, tetapi Server masih dapat melakukan pengiriman data. Pada saat Server telah selesai melakukan proses pengiriman data, Server melakukan pengiriman segment FIN sebagai indikasi penutupan koneksi. Koneksi tertutup pada saat Client membalas dengan pengiriman segment ACK.

Client

Server

Termination Request Send FIN=1, Seq=x, Ack=y

Receive FIN=0 Seq=y-1, ACK=x+1

Receive FIN=1 Send FIN=0 Seq=y-1, ACK=x+1 nt o Clie rver t Server e S : Data lient to C Ack:

Send FIN=1 Seq=z, ACK=x+1

Send FIN=0 Seq=x, ACK=z+1 Receive FIN=0, Seq=x, ACK=z+1

Gambar 2.18. Ilustrasi penutupan koneksi pada TCP dengan half-close.

2.2.

User Datagram Protocol (UDP)

2.2.1. Struktur segment UDP UDP didefinisikan di dalam RFC 768 adalah protokol pada lapisan transport di samping protokol TCP. Protokol UDP memiliki kesamaan dengan protokol TCP dalam hal melakukan proses multiplexing dan demultiplexing komunikasi, tetapi dalam hal lain UDP sangat berbeda dengan TCP. Protokol UDP hanya menambahkan sedikit header pada data yang berasal dari lapisan aplikasi untuk selanjutnya diberikan kepada lapisan network di bawahnya. Pada saat menerima data dari lapisan aplikasi, protokol UDP menambahkan port sumber dan port tujuan (untuk kebutuhan multiplexing dan demultiplexing) dan beberapa field kecil yaitu length dan checksum (untuk pengecekan kesalahan). Lihat Gambar 2.19. Perhatikan bahwa UDP tidak melakukan proses handshaking antara Client dan Server untuk membangun koneksi sebelum mengirimkan segment UDP, karena hal inilah maka UDP disebut sebagai protokol conectionless.

Gambar 2.19. Struktur segment dari protokol UDP

Field checksum sebagaimana halnya pada TCP digunakan untuk mendeteksi kesalahan bit pada proses pengiriman data, sedangkan field length berisi informasi tentang panjang segment UDP termasuk header dalam ukuran byte.

Kalau dibandingkan dengan protokol TCP terlihat bahwa protokol UDP sangat sederhana. Hal ini secara natural akan memunculkan pertanyaan “jika demikian untuk apa orang menggunakan protokol semacam ini?” Berikut ini adalah beberapa alasan:

•

Protokol UDP memiliki header yang kecil jika dibandingkan dengan protokol TCP. Header TCP adalah 20 byte sedangkan header UDP hanya 8 byte, sehingga terlihat bahwa secara keseluruhan throughput dari data yang dikirimkan dengan protokol UDP lebih besar (overhead kecil) daripada protokol TCP.

•

Protokol UDP tidak membutuhkan fase penetapan koneksi sebagaimana halnya pada TCP, sehingga waktu tunda (delay) untuk membangun koneksi antara Client dan Server menjadi lebih kecil. Dan inilah satu-satunya alasan bagi protokol Domain Name System (DNS) memilih menggunakan protokol UDP daripada protokol TCP.

•

Protokol UDP tidak mencatat state dari koneksi seperti jumlah memori (buffer) pada sisi pengirim dan penerima, parameter-parameter untuk keperluan congestion

control,

sequence

number

dan

acknowledgment

number

sebagaimana halnya pada TCP. Keuntungan dari tidak disimpannya informasi state koneksi adalah Server aplikasi yang menggunakan protokol UDP dapat menerima jumlah Client yang aktif lebih banyak daripada menggunakan protokol TCP. •

Karena itu UDP tidak memiliki proses congestion control dan flow control yang cukup kompleks, dengan demikian waktu tunda pengiriman data secara keseluruhan menjadi sangat kecil. Tidak demikian halnya dengan protokol TCP, protokol congestion control akan membuat pengirim menurunkan kecepatan pengiriman data apabila terjadi kongesi pada jaringan. Di samping itu protokol TCP mengharuskan adanya urutan segment, sehingga proses pengiriman data hanya

dapat

dikatakan

berhasil

apabila

pengirim

telah

menerima

acknowledgment tanpa mempedulikan berapapun waktu yang dibutuhkan sampai segment ACK diterima. Karena itu untuk aplikasi-aplikasi tertentu yang

membutuhkan kecepatan pengiriman data akan memilih menggunakan protokol UDP daripada protokol TCP.

2.2.2. UDP Checksum Sebagaimana dijelaskan di atas, field checksum pada UDP digunakan untuk mendeteksi kesalahan data pada proses pengiriman data. Misalnya data dalam bentuk bit yang mengalir dari satu terminal ke terminal lain dapat terganggu oleh adanya noise sehingga salah satu atau beberapa bit berubah dari 0 menjadi 1 atau sebaliknya. Proses deteksi kesalahan ini didefiniskan dalam RFC 1071. Dalam melakukan proses deteksi kesalahan UDP menggunakan konsep komplemen 1 terhadap hasil penjumlahan dari semua data berukuran 16 bit di dalam sebuah segment, dengan catatan bahwa lebihan bit hasil penjumlahan dibuang (Note: TCP juga menggunakan proses deteksi kesalahan dengan konsep komplemen 1).

Sebagai contoh terdapat sebanyak 3 buah data 16 bit sebagai berikut:

0100011011011100 0011101000110101 1000111100111001

Apabila dua buah data pertama dijumlah akan memberikan hasil sebagai berikut:

0100011011011100 0011101000110101 1000000100010001

Berikutnya jumlahkan dengan data ketiga:

1000000100010001 1000111100111001

0001000001001010

Maka komplemen 1 dari hasil penjumlah tersebut dilakukan dengan cara membalik bit 1 menjadi 0 dan demikian pula bit 0 menjadi 1. Dengan demikian komplemen 1 dari 3 buah data di atas adalah: 1110111110110101. Hasil komplemen 1 inilah yang diisikan kedalam field checksum.

Pada sisi penerima ke-3 buah data sepanjang 16 bit tersebut dan checksum sepanjang 16 bit dijumlahkan secara bersama-sama. Apabila data yang dikirimkan tidak memiliki kesalahan maka hasil penjumlahan akan memberikan nilai 1111111111111111. Dengan demikian apabila terdapat satu atau lebih bit salah maka hasil penjumlahan bukan merupakan deretan 16 bit angka 1, dan dari sinilah penerima mengetahui adanya kesalahan pada proses pengiriman data.

Akan tetapi sekalipun terdapat proses mendeteksi kesalahan pada protokol UDP, UDP tidak melakukan proses pemulihan data sama sekali apabila mendeteksi adanya kesalahan pengiriman data. Beberapa aplikasi akan langsung membuang segment yang salah tersebut atau mengirimkan kepada lapisan aplikasi dengan peringatan tentang adanya kesalahan data.