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=xReceive SYN=1

Send SYN=1,

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

FIN

SYN

RST

PSH

ACK

URG

ECE

CWR

NS

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 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 ∗ �������

350

360

370

380

390

400

410

420

430

440

1 6 11 1621 2631 364146 5156 6166 7176 8186 9196

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 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 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+1Receive FIN=0

Seq=y-1, ACK=x+1

Receive FIN=0,

Seq=x, ACK=z+1

Send FIN=0

Seq=x, ACK=z+1

Data: Ser

ver to Cli

ent

Ack: Clie

nt to Serv

er

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