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
Send SYN=1,
Seq=y, ACK=x+1
Receive SYN=1,
Seq=y, ACK=x+1
Receive SYN=0,
Seq=x, ACK=y+1
Send 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.

F
I
N
S
Y
N
R
S
T
P
S
H
A
C
K
U
R
G
E
C
E
C
W
R
N
S

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 ACK 3
Send 3
Receive 2
Send ACK 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-Back-
N, 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 RTT
sampel
(t). TCP hanya menghitung
segment yang dikirimkan sekali saja, TCP tidak menghitung segment yang dikirimkan
ulang. Karena nilai RTT
sampel
(t) ini berbeda-beda dari waktu ke waktu, maka TCP tidak
dapat menggunakan RTT
sampel
(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 RTT
estimasi
(t). Estimasi terhadap RTT dilakukan secara online dengan
menggunakan rumusan (Jacobsons 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 RTT
estimasi
(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 RTT
var
(t) dirumuskan sebagai:

= 1

1 +

Nilai rekomendasi dari parameter = 0.25. Gambar 2.13 menunjukkan grafik dari nilai
RTT
sampel
(t) dan RTT
estimasi
(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

350
360
370
380
390
400
410
420
430
440
1 6 111621263136414651566166717681869196
RTT sampel
RTT estimasi
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 RTT
estimasi
(t) dan RTT
var
(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 berubah-
ubah 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=1
Send FIN=0
Seq=y-1, ACK=x+1
Receive FIN=0
Seq=y-1, ACK=x+1
Receive FIN=0,
Seq=x, ACK=z+1
Send FIN=0
Seq=x, ACK=z+1
D
a
ta
: S
e
rv
e
r to
C
lie
n
t
A
ck
: C
lie
n
t to
S
e
rv
e
r
Send FIN=1
Seq=z, ACK=x+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.