Pengertian dan perbedaan TCP dan UDP

IN BACKUP FTP, DOD, PORT, TCP/IP, UDP - ON 2:00 PM - NO COMMENTS

1. TCP
Pengertian TCP

Transmission Control Protocol (TCP) adalah salah satu jenis protokol yang memungkinkan kumpulan

komputer untuk berkomunikasi dan bertukar data didalam suatu network (jaringan). TCP merupakan

suatu protokol yang berada di lapisan transpor (baik itu dalam tujuh lapis model referensi OSI atau

model DARPA) yang berorientasi sambungan (connection-oriented) dan dapat diandalkan (reliable).

TCP dipakai untuk aplikasi-aplikasi yang membutuhkan keandalan data.

Awal Keberadaan TCP

Konsep TCP/IP berawal dari kebutuhan DoD (Departement of Defense) AS akan suatu komunikasi di

antara berbagai variasi komputer yg telah ada. Komputer-komputer DoD ini seringkali harus

berhubungan antara satu organisasi peneliti dg organisasi peneliti lainnya, dan harus tetap

berhubungan sehingga pertahanan negara tetap berjalan selama terjadi bencana, seperti ledakan

nuklir. Oleh karenanya pada tahun 1969 dimulailah penelitian terhadap serangkaian protokol TCP/IP. Di

antara tujuan-tujuan penelitian ini adalah sebagai berikut :

1. Terciptanya protokol-protokol umum, DoD memerlukan suatu protokol yg dapat ditentukan

untuk semua jaringan.

2. Meningkatkan efisiensi komunikasi data.

3. Dapat dipadukan dengan teknologi WAN (Wide Area Network) yg telah ada.

4. Mudah dikonfigurasikan.

Karakteristik TCP

Karakteristik dari TCP antara lain yaitu :

 1. Reliable berarti data ditransfer ke tujuannya dalam suatu urutan seperti ketika dikirim.

2. Berorientasi sambungan (connection-oriented): Sebelum data dapat ditransmisikan antara dua

host, dua proses yang berjalan pada lapisan aplikasi harus melakukan negosiasi untuk membuat

sesi koneksi terlebih dahulu. Koneksi TCP ditutup dengan menggunakan proses terminasi

koneksi TCP (TCP connection termination).

3. Full-duplex: Untuk setiap host TCP, koneksi yang terjadi antara dua host terdiri atas dua buah

jalur, yakni jalur keluar dan jalur masuk. Dengan menggunakan teknologi lapisan yang lebih

rendah yang mendukung full-duplex, maka data pun dapat secara simultan diterima dan

dikirim. Header TCP berisi nomor urut (TCP sequence number) dari data yang ditransmisikan

dan sebuah acknowledgment dari data yang masuk

4. Memiliki layanan flow control: Untuk mencegah data terlalu banyak dikirimkan pada satu

waktu, yang akhirnya membuat “macet” jaringan internetwork IP, TCP mengimplementasikan

layanan flow control yang dimiliki oleh pihak pengirim yang secara terus menerus memantau

dan membatasi jumlah data yang dikirimkan pada satu waktu. Untuk mencegah pihak penerima

untuk memperoleh data yang tidak dapat disangganya (buffer), TCP juga mengimplementasikan

flow control dalam pihak penerima, yang mengindikasikan jumlah buffer yang masih tersedia

dalam pihak penerima.

5. Melakukan segmentasi terhadap data yang datang dari lapisan aplikasi (dalam DARPA Reference

Model)

6. Mengirimkan paket secara “one-to-one“: hal ini karena memang TCP harus membuat sebuah

sirkuit logis antara dua buah protokol lapisan aplikasi agar saling dapat berkomunikasi. TCP

tidak menyediakan layanan pengiriman data secara one-to-many.

Cara Kerja TCP/IP

Adapun langkah-langkah cara kerja dari protokol TCP/IP ini adalah :

1. Pertama, datagram dibagi-bagi ke dalam bagian-bagian kecil yang sesuai dengan ukuran bandwith

(lebar frekuensi) dimana data tersebut akan dikirimkan.

 2. Pada lapisan TCP, data tersebut lalu “dibungkus” dengan informasi header yang dibutuhkan.

Misalnya seperti cara mengarahkan data tersebut ke tujuannya, cara merangkai kembali

kebagian-bagian data tersebut jika sudah sampai pada tujuannya, dan sebagainya.

3. Setelah datagram dibungkus dengan header TCP, datagram tersebut dikirim kepada lapisan IP.

4. IP menerima datagram dari TCP dan menambahkan headernya sendiri pada datagram tersebut.

5. IP lalu mengarahkan datagram tersebut ke tujuannya.

6. Komputer penerima melakukan proses-proses perhitungan, ia memeriksa perhitungan checksum

yang sama dengan data yang diterima.

7. Jika kedua perhitungan tersebut tidak cocok berarti ada error sewaktu pengiriman dan datagram

akan dikirimkan kembali.

Kelebihan TCP/IP

Beberapa kelebihan TCP/IP dibandingkan protokol yang lain antara lain:

1. TCP/IP adalah protokol yang bisa diarahkan. Artinya ia bisa mengirimkan datagram melalui

rute-rute yang telah ditentukan sebelumnya. Hal ini dapat mengurangi kepadatan lalu lintas

pada jaringan, serta dapat membantu jika jaringan mengalami kegagalan, TCP/IP dapat

mengarahkan data melalui jalur lain.

2. Memiliki mekanisme pengiriman data yang handal dan efisien.

3. Bersifat open platform atau platform independent yaitu tidak terikat oleh jenis perangkat keras

atau perangkat lunak tertentu.

4. Karena sifatnya yang terbuka, TCP/IP bisa mengirimkan data antara sistem-sistem komputer

yang berbeda yang menjalankan pada sistem-sistem operasi yang berbeda pula.

5. TCP/IP terpisah dari perangkat keras yang mendasarinya. Protokol ini dapat dijalankan pada

jaringan Ethernet, Token ring, X.25, dan bahkan melalui sambungan telepon.

6. TCP/IP menggunakan skema pengalamatan yang umum, maka semua sistem dapat mengirimkan

data ke alamat sistem yang lain.

Kegunaan TCP

Beberapa kegunaan dari TCP yaitu :

1. Menyediakan komunikasi logika antar proses aplikasi yang berjalan pada host yang berbeda

2. protokol transport berjalan pada end systems

3. Pengiriman file (file transfer). File Transfer Protokol (FTP) memungkinkan pengguna komputer

yg satu untuk dapat mengirim ataupun menerima file ke komputer jaringan. Karena masalah

keamanan data, maka FTP seringkali memerlukan nama pengguna (username) dan password,

meskipun banyak juga FTP yg dapat diakses melalui anonymous, lias tidak berpassword. (lihat

RFC 959 untuk spesifikasi FTP)

4. Remote login. Network terminal Protokol (telnet) memungkinkan pengguna komputer dapat

melakukan log in ke dalam suatu komputer didalam suatu jaringan. Jadi hal ini berarti bahwa

pengguna menggunakan komputernya sebagai perpanjangan tangan dari komputer jaringan

tersebut.( lihat RFC 854 dan 855 untuk spesifikasi telnet lebih lanjut)

5. Computer mail. Digunakan untuk menerapkan sistem elektronik mail.

6. Network File System (NFS). Pelayanan akses file-file jarak jauh yg memungkinkan klien-klien

untuk mengakses file-file pada komputer jaringan jarak jauh walaupun file tersebut disimpan

secara lokal. (lihat RFC 1001 dan 1002 untuk keterangan lebih lanjut)

7. remote execution. Memungkinkan pengguna komputer untuk menjalankan suatu program

didalam komputer yg berbeda. Biasanya berguna jika pengguna menggunakan komputer yg

terbatas, sedangkan ia memerlukan sumber yg banyak dalam suatu system komputer. Ada

beberapa jenis remote execution, ada yg berupa perintah-perintah dasar saja, yaitu yg dapat

dijalankan dalam system komputer yg sama dan ada pula yg menggunakan “prosedure remote

call system”, yg memungkinkan program untuk memanggil subroutine yg akan dijalankan di

system komputer yg berbeda. (sebagai contoh dalam Berkeley UNIX ada perintah “rsh” dan

“rexec”)

8. name servers. Nama database alamat yg digunakan pada internet (lihat RFC 822 dan 823 yg

menjelaskan mengenai penggunaan protokol name server yg bertujuan untuk menentukan nama

host di internet.)
Manajemen Koneksi TCP :

Pada saat Setup Koneksi

1. Client mengirimkan kontrol TCP SYN ke server, dengan memberikan sequence number inisial.

2. Server menerima TCP SYN, dan membalasnya dengan kontrol SYNACK.

o ACK yang menyatakan telah menerima SYN.

o Mengalokasikan buffer.

o Menghasilkan sequence number untuk ke client.

Pada saat Menutup Koneksi

1. Client mengirim kontrol TCP FIN ke server

2. Server menerima FIN, dan membalas dengan ACK. Menutup koneksi dan mengirimkan FIN ke

client.

3. Client menerima FIN dan membalas ACK

o Masuk pada masa menunggu balasan ACK terhadap dari server

4. Server menerima ACK dan koneksi tertutup.

Header TCP

Ukuran dari header TCP adalah bervariasi, yang terdiri atas beberapa field yang ditunjukkan dalam

gambar dan tabel berikut. Ukuran TCP header paling kecil (ketika tidak ada tambahan opsi TCP) adalah

20 byte. headerTCP-2

Port TCP

Port TCP mampu mengindikasikan sebuah lokasi tertentu untuk menyampaikan segmen-segmen TCP

yang dikirimkan yang diidentifikasi dengan TCP Port Number. Nomor-nomor di bawah angka 1024
merupakan port yang umum digunakan dan ditetapkan oleh IANA (Internet Assigned Number Authority).

Tabel berikut ini menyebutkan beberapa port TCP yang telah umum digunakan.

Port TCP merupakan hal yang berbeda dibandingkan dengan port UDP, meskipun mereka memiliki

nomor port yang sama. Port TCP merepresentasikan satu sisi dari sebuah koneksi TCP untuk protokol

lapisan aplikasi, sementara port UDP merepresentasikan sebuah antrean pesan UDP untuk protokol

lapisan aplikasi. Selain itu, protokol lapisan aplikasi yang menggunakan port TCP dan port UDP dalam

nomor yang sama juga tidak harus sama. Sebagai contoh protokol Extended Filename Server (EFS)

menggunakan port TCP dengan nomor 520, dan protokol Routing Information Protocol (RIP)

menggunakan port UDP juga dengan nomor 520. Jelas, dua protokol tersebut sangatlah berbeda!

Karenanya, untuk menyebutkan sebuah nomor port, sebutkan juga jenis port yang digunakannya,

karena hal tersebut mampu membingungkan (ambigu). PORTtcp-1

Aplikasi yang Menggunakan TCP

1. World Wide Web

Aplikasi ini pada prinsipnya mirip dengan aplikasi gopher, yakni penyediaan database yang dapat

diakses tidak hanya berupa text, namun dapat berupa gambar/image, suara, video. penyajiannya pun

dapat dilakukan secara live. Dengan demikian, jenis informasi yang dapat disediakan sangat banyak dan

dapat dibuat dengan tampilan yang lebih menarik. Hal ini dimungkinkan karena Web menggunakan

teknologi hypertext. Karena itu, protokol yang digunakan untuk aplikasi ini dikenal dengan nama

Hypertext-transfer-protocol (HTTP).

2. Archie

Aplikasi FTP memungkinkan kita mentransfer file dari manapun di seluruh dunia. Hal itu dengan

anggapan bahwa kita telah mengetahui lokasi di mana file yang kita cari berada. Namun jika kita belum

mengetahui di mana file yang kita cari berada, kita memerlukan aplikasi untuk membantu kita mencari

di mana file tersebut berada.

Cara kerja Archie dapat dijelaskan sebagai berikut. Server Archie secara berkala melakukan anonymous

ftp ke sejumlah FTP Server dan mengambil informasi daftar seluruh file yang ada pada FTP Server
tersebut. Daftar ini disusun berdasarkan letak file dalam direktori/sub direktori, sehingga mudah untuk

menemukan file tersebut. File-file yang berisi daftar file tiap FTP Server ini merupakan database dari

Archie Server. Jika ada query ke Archie Server yang menanyakan suatu file, server mencari dalam

daftar tadi dan mengirimkan seluruh jawaban yang berkaitan dengan file tersebut. Informasi yang

diberikan adalah alamat FTP Server yang memiliki file tersebut dan letak file tersebut dalam struktur

direktori.

3. Wide Area Information Services (WAIS)

WAIS merupakan salah satu servis pada internet yang memungkinkan kita mencari melalaui materi yang

terindeks dan menemukan dokumen/artikel berdasarkan isi artikel tersebut. Jadi pada dasarnya, WAIS

memberikan layanan untuk mencari artikel yang berisi kata-kata kunci yang kita ajukan sebagai dasar

pencarian.

Aplikasi WAIS biasanya berbasis text. Untuk membuat suatu dokumen dapat dicari melalaui WAIS

Server, harus dibuat terlebih dahulu index dari dokumen tersebut. Setiap kata dalam dokumen tersebut

diurut dan dihitung jumlahnya. Jika ada query dari client, index akan diperiksa dan hasilnya, yakni

dokumen yang memiliki kata-kata tersebut ditampilkan. Karena kemungkinan ada banyak dokumen

yang memiliki kata-kata yang kita ajukan, maka beberapa dokumen yang memiliki kata kunci tersebut

diberi skor/nilai. Dokumen yang paling banyak mengandung kata-kata kunci akan mendapat skor

tertinggi. Dengan demikian, user mendapatkan informasi kemungkinan terbesar dari bebarapa dokumen

yang mengandung kumpulan kata yang diajukannya.

4. FAX di Internet

Mesin FAX sebagai pengirim dan penerima berita tertulis melalaui telepon saat ini hampir dimiliki oleh

semua kantor. Melalaui gateway Internet FAX, pengiriman FAX dapat dilakukan melalaui e-mail.

Gateway akan menerjemahkan pesan e-mail tersebut dan menghubungi mesin FAX tujuan melalui jalur

telepon secara otomatis. Tentu saja, akses untuk ini terbatas (private).

2. UDP
Pengertian UDP
UDP, singkatan dari User Datagram Protocol, adalah salah satu protokol lapisan transpor TCP/IP yang

mendukung komunikasi yang tidak andal (unreliable), tanpa koneksi (connectionless) antara host-host

dalam jaringan yang menggunakan TCP/IP.

Karakteristik UDP

Karakteristik dari UDP antara lain, yaitu :

1. Connectionless (tanpa koneksi): Pesan-pesan UDP akan dikirimkan tanpa harus dilakukan proses

negosiasi koneksi antara dua host yang hendak berukar informasi.

2. Unreliable (tidak andal): Pesan-pesan UDP akan dikirimkan sebagai datagram tanpa adanya

nomor urut atau pesan acknowledgment. Protokol lapisan aplikasi yang berjalan di atas UDP

harus melakukan pemulihan terhadap pesan-pesan yang hilang selama transmisi. Umumnya,

protokol lapisan aplikasi yang berjalan di atas UDP mengimplementasikan layanan keandalan

mereka masing-masing, atau mengirim pesan secara periodik atau dengan menggunakan waktu

yang telah didefinisikan.

3. UDP menyediakan mekanisme untuk mengirim pesan-pesan ke sebuah protokol lapisan aplikasi

atau proses tertentu di dalam sebuah host dalam jaringan yang menggunakan TCP/IP.

HeaderUDP berisi field Source Process Identification dan Destination Process Identification.

4. UDP menyediakan penghitungan checksum berukuran 16-bit terhadap keseluruhan pesan UDP.

Kegunaan UDP:

UDP sering digunakan dalam beberapa tugas berikut:

1. Protokol yang “ringan” (lightweight): Untuk menghemat sumber daya memori dan prosesor,

beberapa protokol lapisan aplikasi membutuhkan penggunaan protokol yang ringan yang dapat

melakukan fungsi-fungsi spesifik dengan saling bertukar pesan. Contoh dari protokol yang

ringan adalah fungsi query nama dalam protokol lapisan aplikasi Domain Name System.
 2. Protokol lapisan aplikasi yang mengimplementasikan layanan keandalan: Jika protokol lapisan

aplikasi menyediakan layanan transfer data yang andal, maka kebutuhan terhadap keandalan

yang ditawarkan oleh TCP pun menjadi tidak ada. Contoh dari protokol seperti ini adalah

Trivial File Transfer Protocol (TFTP) dan Network File System (NFS)

3. Protokol yang tidak membutuhkan keandalan. Contoh protokol ini adalah protokol Routing

Information Protocol (RIP).

4. Transmisi broadcast: Karena UDP merupakan protokol yang tidak perlu membuat koneksi

terlebih dahulu dengan sebuah host tertentu, maka transmisi broadcast pun dimungkinkan.

Sebuah protokol lapisan aplikasi dapat mengirimkan paket data ke beberapa tujuan dengan

menggunakan alamat multicast atau broadcast. Hal ini kontras dengan protokol TCP yang hanya

dapat mengirimkan transmisi one-to-one. Contoh: query nama dalam protokol NetBIOS Name

Service.

Kelemahan UDP

1. UDP tidak menyediakan mekanisme penyanggaan (buffering) dari data yang masuk ataupun

data yang keluar. Tugas buffering merupakan tugas yang harus diimplementasikan oleh protokol

lapisan aplikasi yang berjalan di atas UDP.

2. UDP tidak menyediakan mekanisme segmentasi data yang besar ke dalam segmen-segmen data,

seperti yang terjadi dalam protokol TCP. Karena itulah, protokol lapisan aplikasi yang berjalan

di atas UDP harus mengirimkan data yang berukuran kecil (tidak lebih besar dari nilai Maximum

Transfer Unit/MTU) yang dimiliki oleh sebuah antarmuka di mana data tersebut dikirim.

Karena, jika ukuran paket data yang dikirim lebih besar dibandingkan nilai MTU, paket data

yang dikirimkan bisa saja terpecah menjadi beberapa fragmen yang akhirnya tidak jadi terkirim

dengan benar.

3. UDP tidak menyediakan mekanisme flow-control, seperti yang dimiliki oleh TCP.
Header UDP

Header UDP diwujudkan sebagai sebuah header dengan 4 buah field memiliki ukuran yang tetap.

Port UDP

Seperti halnya TCP, UDP juga memiliki saluran untuk mengirimkan informasi antar host, yang disebut

dengan UDP Port. Untuk menggunakan protokol UDP, sebuah aplikasi harus menyediakan alamat IP dan

nomor UDP Port dari host yang dituju. Sebuah UDP port berfungsi sebagai sebuah multiplexed message

queue, yang berarti bahwa UDP port tersebut dapat menerima beberapa pesan secara sekaligus. Setiap

port diidentifikasi dengan nomor yang unik, seperti halnya TCP, tetapi meskipun begitu, UDP Port

berbeda dengan TCP Port meskipun memiliki nomor port yang sama. Tabel di bawah ini mendaftarkan

beberapa UDP port yang telah dikenal secara luas.

Kelemahan UDP

1. UDP tidak menyediakan mekanisme penyanggaan (buffering) dari data yang masuk ataupun

data yang keluar. Tugas buffering merupakan tugas yang harus diimplementasikan oleh protokol

lapisan aplikasi yang berjalan di atas UDP.

2. UDP tidak menyediakan mekanisme segmentasi data yang besar ke dalam segmen-segmen data,

seperti yang terjadi dalam protokol TCP. Karena itulah, protokol lapisan aplikasi yang berjalan

di atas UDP harus mengirimkan data yang berukuran kecil (tidak lebih besar dari nilai Maximum

Transfer Unit/MTU) yang dimiliki oleh sebuah antarmuka di mana data tersebut dikirim.

Karena, jika ukuran paket data yang dikirim lebih besar dibandingkan nilai MTU, paket data

yang dikirimkan bisa saja terpecah menjadi beberapa fragmen yang akhirnya tidak jadi terkirim

dengan benar.

3. UDP tidak menyediakan mekanisme flow-control, seperti yang dimiliki oleh TCP.

Aplikasi yang Menggunakan UDP:

Digunakan untuk multimedia streaming, yang sangat memberikan toleransi kehilangan segment cukup

baik dan yang sangat tidak sensitive terhadap kerusakan atau kehilangan segment

Contoh protokol aplikasi yang menggunakan UDP :

 DNS (Domain Name System) 53

 SNMP, (Simple Network Management Protocol) 161, 162

 TFTP (Trivial File Transfer Protocol) 69

 SunRPC port 111.

3. Perbedaan TCP dan UDP

Berbeda dengan TCP, UDP merupakan connectionless dan tidak ada keandalan, windowing, serta fungsi

untuk memastikan data diterima dengan benar. Namun, UDP juga menyediakan fungsi yang sama

dengan TCP, seperti transfer data dan multiplexing, tetapi ia melakukannya dengan byte tambahan

yang lebih sedikit dalam header UDP.

UDP melakukan multiplexing UDP menggunakan cara yang sama seperti TCP. Satu-satunya perbedaan

adalah transport protocol yang digunakan, yaitu UDP. Suatu aplikasi dapat membuka nomor port yang

sama pada satu host, tetapi satu menggunakan TCP dan yang satu lagi menggunakan UDP—hal ini tidak

biasa, tetapi diperbolehkan. Jika suatu layanan mendukung TCP dan UDP, ia menggunakan nilai yang

sama untuk nomor port TCP dan UDP.

UDP mempunyai keuntungan dibandingkan TCP dengan tidak menggunakan field sequence dan

acknowledgement. Keuntungan UDP yang paling jelas dari TCP adalah byte tambahan yang lebih

sedikit. Di samping itu, UDP tidak perlu menunggu penerimaan atau menyimpan data dalam memory

sampai data tersebut diterima. Ini berarti, aplikasi UDP tidak diperlambat oleh proses penerimaan dan

memory dapat dibebaskan lebih cepat. Pada tabel, Anda dapat melihat fungsi yang dilakukan (atau

tidak dilakukan) oleh UDP atau TCP.

Tabel Perbedaan TCP dan UDP

Dibawah ini merupakan tabel perbedaan TCP dan UDP :

 No TCP UDP

Tidak berdasarkan konsep koneksi, jadi harus membuat

1. Beroperasi berdasarkan konsep koneksi.
kode sendiri.

Tidak ada jaminan bahwa pengiriman dan penerimaan

Jaminan pengiriman-penerimaan data data akan reliable dan teratur, sehingga paket data
2.
akan reliable dan teratur. mungkin dapat kurang, terduplikat, atau bahkan tidak
sampai sama sekali.

Secara otomatis memecah data ke Pemecahan ke dalam paket-paket dan proses

3.
dalam paket-paket. pengirimannya dilakukan secara manual.

Tidak akan mengirimkan data terlalu Harus membuat kepastian mengenai proses transfer data
4. cepat sehingga memberikan jaminan agar tidak terlalu cepat sehingga internet masih dapat
koneksi internet dapat menanganinya. menanganinya.

Jika paket ada yang hilang, perlu dipikirkan di mana

Mudah untuk digunakan, transfer paket
5. letak kesalahan yang terjadi dan mengirim ulang data
data seperti menulis dan membaca file.
yang diperlukan.

Secara garis besar perbedaan TCP dan UDP adalah :

No TCP UDP

Tidak dapat diandalkan Jika mengirimkan

Dapat diandalkan Jika sambungan terputus ketika
mengrim sebuah pesan maka server akan meminta
1.
bagian yang hilang. Jadi tidak akan terjadi data yang
korup ketika mentransfer sebuah data.
suatu pesan atau data, kita tidak akan tahu
apakah sudah terkirim atau belum dan
apakah sebagian dari pesan tersebut hilang
atau tidak ketika proses pengiriman. Jadi
akan ada kemungkinan terjadinya data yang
korup.

Berurutan Ketika mengrimkan dua pesan secara Tidak berurutan Ketika mengrimkan dua
2.
berurutan / satu demi satu. TCP akan pesan secara berurutan / satu demi satu.
 mengirimkannya secara berurutan. Tidak perlu Tidak dapat dipastikan data mana yang akan
khawatir data tiba dengan urutan yang salah. datang terlebih dahulu.

Berorientasi sambungan (connection-

oriented)Sebelum data dapat ditransmisikan antara Connectionless (tanpa koneksi)
dua host, dua proses yang berjalan pada lapisan Pesan-pesan UDP akan dikirimkan tanpa
3. aplikasi harus melakukan negosiasi untuk membuat harus dilakukan proses negosiasi koneksi
sesi koneksi terlebih dahulu. Koneksi TCP ditutup antara dua host yang hendak berukar
dengan menggunakan proses terminasi koneksi TCP informasi.
(TCP connection termination).

Ringan (Lightweight) Tidak ada permintaan

Ringan (Heavyweight) Ketika tingkat level
pesan, tidak ada trak koneksi dan yang
terendah dari TCP tercapai dalam urutan yang
lainnya, hanya menjalankan dan
salah,permintaan pengiriman ulang data harus
4. melupakannya. Ini berarti itu jauh lebih cepat
dikirm. dan bagian lainya harus dikembalikan
dan kartu jaringan / OS hanya melakukan
semua. Sehingga membutuhkan proses untuk
sedikit pekerjaan untuk menerjemahkan
menyatukannya
kembali data dari paket.

Streaming Data /paket dibaca sebagai satu alur Datagrams Paket dikirim secara individu
5. data. tanpa mengetahui batas setiap data berakhir dan dijamin utuh ketika tiba. Satu paket
dan data yang lain mulai. Ada kemungkinan dibaca per satu panggilan.
beberapa paket data dibaca per satu panggilan data.

Contoh
World Wide Web (Apache TCP port 80), e-mail
5.
(SMTP TCP port 25 Postfix MTA), File Transfer
Protocol (FTP port 21) and Secure Shell (OpenSSH
port 22) etc.
Contoh
Domain Name System (DNS UDP port 53),
streaming media applications such as IPTV
or movies, Voice over IP (VoIP), Trivial File
Transfer Protocol (TFTP) and online
multiplayer games etc

Internet memiliki 2 protokol utama dalam transpot layer, yaitu connectionless protocol dan
connection-oriented.Keduanya saling melengkapi satu sama lain.Connectionless protocol adalah
UDP. UDP tidak mengirimkan paket antar aplikasi, melainkan membiarkan aplikasi membangun
protokolnya sendiri sesuai dengan kebutuhannya.Connection oriented protocol adalah TCP. TCP
membuat koneks dan menambah keandalan dengan re-transmisi, bersama dengan flow control
dan congestion control.
1. UDP (User Datagram Protokol)
Internet protocol yang mendukung sebuah connectionless transport protocol disebut dengan
UDP. UDP menyediakan jalan untuk aplikasi untuk mengemas IP datagram tanpa membuat
sebuah koneksi.
UDP mentransmisikan segmen yang terdiri dari header 8-byte diikuti oleh payload. Header
ditunjukkan pada Gambar 6-27. Kedua port berfungsi untuk mengidentifikasi titik akhir dalam
mesin sumber dan tujuan. Ketika paket UDP tiba, payloadnya diserahkan ke proses yang
terhubung ke port tujuan. Lampiran ini terjadi ketika BIND primitif atau sesuatu yang serupa
digunakan, seperti yang kita lihat pada Gambar 6-6

Source Port diperlukan saat balasan harus dikirim kembali ke source. Dengan meng-copy field source port
dari segment yang datang ke destination port field dari segmen yang keluar, proses pengiriman balasan
dapat menentukan proses mana dalam mesin pengirim untuk didapatkan. Panjang UDP mencangkup 8
byte header dan data. The minimum length is 8 bytes, to cover the header. The maximum length is
65,515 bytes, which is lower than the largest number that will fit in 16 bits because of the size limit
on IP packets.
Untuk keandalan yang ekstra, tersedia juga optional checksum. Checksum memeriksa header,
data, dan conceptual IP pseudoheader. Saat melakukan perhitungan, field checksum diset ke nol dan
field data diisi dengan byte nol jika panjangnya ganjil. Algoritma checksum hanya untuk
menambahkan semua kata 16-bit dalam satu komplemen dan untuk mengambil satu
komplemen dari jumlah tersebut. Sebagai akibatnya, ketika penerima melakukan perhitungan
pada seluruh segmen, termasuk bidang Checksum, hasilnya harus 0. Jika checksum tidak
dihitung, itu disimpan sebagai 0, karena oleh kebetulan bahagia dari salah satu pelengkap
aritmatika benar dihitung 0 disimpan sebagai semua 1s. Namun, mematikannya adalah hal
yang bodoh kecuali kualitas datanya tidak penting (mis., Untuk pidato digital).Pseudoheader
untuk kasus IPv4 ditunjukkan pada Gambar 6-28. Ini berisi alamat IPv4 32-bit dari mesin
sumber dan tujuan, nomor protokol untuk UDP (17), dan jumlah byte untuk segmen UDP
(termasuk header). itu berbeda tetapi analog untuk IPv6. Termasuk pseudoheader dalam
perhitungan UDP checksum membantu mendeteksi paket yang salah pengiriman, tetapi
memasukkannya juga melanggar hierarki protokol karena alamat IP di dalamnya
termasuk dalam lapisan IP, bukan ke lapisan UDP. TCP menggunakan pseudoheader
yang sama untuk checksumnya.
Mungkin perlu disebutkan secara eksplisit beberapa hal yang tidak dilakukan UDP. Itu tidak melakukan
kontrol aliran, kontrol kemacetan, atau retransmisi setelah menerima segmen yang buruk. Semua itu
terserah pada proses pengguna. Apa yang dilakukannya adalah menyediakan antarmuka ke protokol IP
dengan fitur tambahan demultiplexing beberapa proses menggunakan port dan deteksi kesalahan end-
to-end opsional. Hanya itu saja. Untuk aplikasi yang perlu memiliki kontrol yang tepat atas alur paket,
kontrol kesalahan, atau pengaturan waktu, UDP hanya menyediakan apa yang diperintahkan dokter. Satu
area yang sangat berguna adalah dalam situasi server klien. Seringkali, klien mengirim permintaan singkat
ke server dan mengharapkan balasan singkat kembali. Jika salah satu permintaan atau balasan hilang,
klien hanya dapat waktu dan mencoba lagi. Tidak hanya kode sederhana, tetapi lebih sedikit pesan yang
diperlukan (satu di setiap arah) daripada dengan protokol yang membutuhkan pengaturan awal seperti
TCP.

Aplikasi yang menggunakan UDP dengan cara ini adalah DNS (Domain Name System), yang akan kita
pelajari di Chap. 7. Singkatnya, sebuah program yang perlu mencari alamat IP dari beberapa nama host,
misalnya, www.cs.berkeley.edu, dapat mengirim paket UDP yang berisi nama host ke server DNS. Server
membalas dengan paket UDP yang berisi alamat IP host. Tidak diperlukan pengaturan terlebih dahulu dan
tidak diperlukan rilis sesudahnya. Hanya dua pesan melewati jaringan.

782/5000

6.4.2 Panggilan Prosedur Jarak Jauh

Dalam arti tertentu, mengirim pesan ke host jarak jauh dan mendapatkan balasan
sangat mirip dengan membuat panggilan fungsi dalam bahasa pemrograman. Dalam
kedua kasus, Anda mulai dengan satu atau lebih parameter dan Anda mendapatkan
kembali hasilnya. Pengamatan ini telah mendorong orang untuk mencoba mengatur
interaksi permintaan-balasan pada jaringan untuk dilemparkan dalam bentuk panggilan
prosedur. Pengaturan seperti itu membuat aplikasi jaringan lebih mudah untuk
diprogram dan lebih akrab untuk ditangani. Sebagai contoh, bayangkan saja sebuah
prosedur bernama mendapatkan alamat IP (nama host) yang bekerja dengan mengirim
paket UDP ke server DNS dan menunggu balasan, waktu habis dan coba lagi jika salah
satu tidak cukup cepat datang. Dengan cara ini, semua detail jaringan dapat
disembunyikan dari programmer.
Pekerjaan utama di bidang ini dilakukan oleh Birrell dan Nelson (1984). Singkatnya, apa yang disarankan
oleh Birrell dan Nelson adalah memungkinkan program memanggil prosedur yang terletak di host jarak
jauh. Ketika proses pada mesin 1 memanggil prosedur pada mesin 2, proses panggilan pada 1
ditangguhkan dan pelaksanaan prosedur yang disebut berlangsung pada 2. Informasi dapat diangkut dari
pemanggil ke callee dalam parameter dan dapat kembali di hasil prosedur. Tidak ada pengiriman pesan
yang terlihat oleh programmer aplikasi. Teknik ini dikenal sebagai RPC (Remote Procedure Call) dan
telah menjadi dasar untuk banyak aplikasi jaringan. Secara tradisional, prosedur panggilan dikenal
sebagai klien dan prosedur yang disebut dikenal sebagai server, dan kami akan menggunakan nama-
nama itu di sini juga.
Gagasan di balik RPC adalah membuat tampilan prosedur jarak jauh sebanyak mungkin seperti yang
lokal. Dalam bentuk yang paling sederhana, untuk memanggil prosedur jarak jauh, program klien harus
terikat dengan prosedur pustaka kecil, yang disebut rintisan klien, yang mewakili prosedur server di ruang
alamat klien. Demikian pula, server terikat dengan prosedur yang disebut rintisan server. Prosedur ini
menyembunyikan fakta bahwa prosedur panggilan dari klien ke server tidak lokal.
Langkah-langkah sebenarnya dalam membuat RPC ditunjukkan pada Gambar 6-29. Langkah 1 adalah
klien
memanggil rintisan klien. Panggilan ini adalah panggilan prosedur lokal, dengan parameter
didorong ke tumpukan dengan cara biasa. Langkah 2 adalah stub klien yang mengemas parameter ke
dalam pesan dan membuat panggilan sistem untuk mengirim pesan. Pengepakan parameter disebut
marshaling. Langkah 3 adalah sistem operasi yang mengirim pesan dari mesin klien ke mesin server.
Langkah 4 adalah sistem operasi yang meneruskan paket yang masuk ke stub server. Akhirnya, langkah
5 adalah server stub yang memanggil prosedur server dengan parameter yang tidak jelas. Jawabannya
menelusuri jalur yang sama ke arah lain.
Butir utama yang perlu diperhatikan di sini adalah bahwa prosedur klien, yang ditulis oleh pengguna,
hanya membuat panggilan prosedur normal (yaitu, lokal) ke stub klien, yang memiliki nama yang sama
dengan prosedur server. Karena prosedur klien dan rintisan klien berada di ruang alamat yang sama,
parameter dilewatkan dengan cara biasa. Demikian pula, prosedur server disebut oleh prosedur di ruang
alamatnya dengan parameter yang diharapkannya. Untuk prosedur server, tidak ada yang tidak biasa.
Dengan cara ini, bukannya I / O yang dilakukan pada soket, komunikasi jaringan dilakukan dengan
memalsukan panggilan prosedur normal.
Meskipun konseptual elegan RPC, ada beberapa ular bersembunyi di bawah rumput. Yang besar adalah
penggunaan parameter penunjuk. Biasanya, memberikan pointer ke prosedur bukanlah masalah.
Prosedur yang disebut dapat menggunakan penunjuk dengan cara yang sama pemanggil dapat karena
kedua prosedur tersebut tinggal di ruang alamat virtual yang sama. Dengan RPC, melewatkan pointer
tidak mungkin karena klien dan server berada di ruang alamat yang berbeda.
Dalam beberapa kasus, trik dapat digunakan untuk memungkinkan melewati petunjuk. Misalkan
parameter pertama adalah pointer ke integer, k. Markas klien dapat marshal k dan mengirimkannya ke
server. Server stub kemudian membuat pointer ke k dan meneruskannya ke prosedur server, seperti yang
diharapkan. Ketika prosedur server mengembalikan kontrol ke stub server, yang terakhir mengirimkan k
kembali ke klien, di mana k baru disalin di atas yang lama, untuk berjaga-jaga jika server mengubahnya.
Akibatnya, urutan panggilan standar dari panggilan-oleh-referensi telah digantikan oleh call-bycopy-
restore. Sayangnya, trik ini tidak selalu berfungsi, misalnya, jika pointer menunjuk ke grafik atau struktur
data kompleks lainnya. Untuk alasan ini, beberapa pembatasan harus ditempatkan pada parameter untuk
prosedur yang disebut dari jarak jauh, seperti yang akan kita lihat.

Masalah kedua adalah bahwa dalam bahasa yang diketik lemah, seperti C, sangat legal untuk menulis
prosedur yang menghitung produk dalam dari dua vektor (array), tanpa menentukan seberapa besar salah
satunya. Masing-masing dapat diakhiri oleh nilai khusus yang hanya diketahui oleh pemanggilan dan
prosedur yang disebut. Dalam keadaan ini, pada dasarnya tidak mungkin bagi klien untuk mem-parsing
parameter: ia tidak memiliki cara untuk menentukan seberapa besar mereka.

Masalah ketiga adalah bahwa tidak selalu mungkin untuk menyimpulkan jenis-jenis parameter, bahkan
tidak dari spesifikasi formal atau kode itu sendiri. Contohnya adalah printf, yang mungkin memiliki
sejumlah parameter (setidaknya satu), dan parameter dapat berupa campuran bilangan bulat, celana
pendek, panjang, karakter, string, nomor floating-point berbagai panjang, dan jenis lainnya. Mencoba
memanggil printf sebagai prosedur jarak jauh praktis mustahil karena C begitu permisif. Namun, aturan
yang mengatakan bahwa RPC dapat digunakan asalkan Anda tidak memprogram dalam C (atau C ++) tidak
akan populer dengan banyak programmer.

Masalah keempat berkaitan dengan penggunaan variabel global. Biasanya, memanggil dan memanggil
prosedur dapat berkomunikasi dengan menggunakan variabel global, selain berkomunikasi melalui
parameter. Tetapi jika prosedur yang dipanggil dipindahkan ke mesin jarak jauh, kode akan gagal karena
variabel global tidak lagi dibagikan. Masalah-masalah ini tidak dimaksudkan untuk menunjukkan bahwa
RPC tidak ada harapan. Sebenarnya, itu banyak digunakan, tetapi beberapa pembatasan diperlukan untuk
membuatnya bekerja dengan baik dalam praktek. Dalam hal protokol lapisan transport, UDP adalah basis
yang bagus untuk mengimplementasikan RPC. Kedua permintaan dan balasan dapat dikirim sebagai paket
UDP tunggal dalam kasus yang paling sederhana dan operasi bisa cepat. Namun, implementasi harus
menyertakan mesin lain juga. Karena permintaan atau balasan mungkin hilang, klien harus menyimpan
pengatur waktu untuk mengirim ulang permintaan. Perhatikan bahwa balasan berfungsi sebagai
pengakuan implisit untuk permintaan, sehingga permintaan tidak perlu diakui secara terpisah. Terkadang
parameter atau hasilnya mungkin lebih besar dari maksimum

Ukuran paket UDP, dalam hal ini beberapa protokol diperlukan untuk menyampaikan pesan besar. Jika
beberapa permintaan dan balasan dapat tumpang tindih (seperti dalam kasus pemrograman bersamaan),
pengenal diperlukan untuk mencocokkan permintaan dengan balasan. Perhatian pada tingkat yang lebih
tinggi adalah bahwa operasi tidak boleh idempoten (yaitu, aman untuk diulangi). Itu

kasus sederhana adalah operasi idempoten seperti permintaan DNS dan balasan. Klien dapat dengan
aman mengirim ulang permintaan ini lagi dan lagi jika tidak ada balasan yang akan datang. Tidak masalah
apakah server tidak pernah menerima permintaan, atau itu adalah balasan yang hilang. Jawabannya,
ketika akhirnya tiba, akan sama (dengan asumsi database DNS tidak diperbarui untuk sementara). Namun,
tidak semua operasi idempoten, misalnya, karena mereka memiliki efek samping yang penting seperti
menambah penghitung. RPC untuk operasi ini membutuhkan semantik yang lebih kuat sehingga ketika
programmer memanggil suatu prosedur, itu tidak dijalankan beberapa kali. Dalam hal ini, mungkin perlu
untuk mengatur koneksi TCP dan mengirim permintaan di atasnya daripada menggunakan UDP.

1010/5000

6.4.3 Protokol Transportasi Real-Time

Client-server RPC adalah satu area di mana UDP digunakan secara luas. Satu lagi
untuk aplikasi multimedia waktu nyata. Secara khusus, seperti radio Internet, telepon
Internet, musik-on-demand, konferensi video, video-on-demand, dan aplikasi
multimedia lainnya menjadi lebih umum, orang-orang telah menemukan bahwa setiap
aplikasi menciptakan ulang lebih banyak atau lebih sedikit protokol transportasi real-
time yang sama. . Secara bertahap menjadi jelas bahwa memiliki protokol transportasi
real-time generik untuk beberapa aplikasi akan menjadi ide yang baik. Demikianlah
RTP (Transpor Transportasi Real-time) lahir. Ini dijelaskan dalam RFC 3550 dan
sekarang digunakan secara luas untuk aplikasi multimedia. Kami akan menjelaskan dua
aspek transportasi real-time. Yang pertama adalah protokol RTP untuk mengangkut
data audio dan video dalam paket. Yang kedua adalah pemrosesan yang terjadi,
sebagian besar pada penerima, untuk memutar audio dan video pada waktu yang
tepat. Fungsi-fungsi ini sesuai dengan tumpukan protokol seperti ditunjukkan pada
Gambar 6-30.
RTP biasanya berjalan di ruang pengguna di atas UDP (dalam sistem operasi). Ini beroperasi sebagai
berikut. Aplikasi multimedia terdiri dari banyak audio, video, teks, dan mungkin aliran lainnya. Ini
dimasukkan ke pustaka RTP, yang berada di ruang pengguna bersama dengan aplikasi. Perpustakaan ini
mengalikan aliran dan mengenkodenya dalam paket RTP, yang dimasukkan ke soket. Di sisi sistem operasi
dari soket, paket UDP dihasilkan untuk membungkus paket RTP dan diserahkan ke IP untuk transmisi
melalui tautan seperti Ethernet. Proses sebaliknya terjadi di penerima. Aplikasi multimedia akhirnya
menerima data multimedia dari pustaka RTP. Ia bertanggung jawab untuk memainkan media. Tumpukan
protokol untuk situasi ini ditunjukkan pada Gambar 6-30 (a). Paket bersarang ditunjukkan pada Gambar
6-30 (b).

Sebagai konsekuensi dari desain ini, agak sulit untuk mengatakan lapisan RTP mana yang masuk. Karena
berjalan di ruang pengguna dan terkait dengan program aplikasi, tentu saja terlihat seperti protokol
aplikasi. Di sisi lain, itu adalah protokol, generik aplikasi dependen yang hanya menyediakan fasilitas
transportasi, sehingga juga terlihat seperti protokol transportasi. Mungkin deskripsi terbaik adalah bahwa
itu adalah protokol transport yang kebetulan diterapkan di lapisan aplikasi, itulah sebabnya mengapa kita
mengetahuinya di bab ini

RTP — Protokol Transportasi Real-time

Fungsi dasar RTP adalah mengalikan beberapa aliran data real-time ke dalam satu aliran paket UDP. Aliran
UDP dapat dikirim ke satu tujuan (unicasting) atau ke beberapa tujuan (multicasting). Karena RTP hanya
menggunakan UDP normal, paketnya tidak diperlakukan secara khusus oleh router kecuali beberapa fitur
kualitas-layanan IP normal diaktifkan. Secara khusus, tidak ada jaminan khusus tentang pengiriman, dan
paket mungkin hilang, tertunda, rusak, dll. Format RTP berisi beberapa fitur untuk membantu penerima
bekerja dengan informasi multimedia. Setiap paket yang dikirim dalam aliran RTP diberi nomor satu ebih
tinggi dari pendahulunya. Penomoran ini memungkinkan tujuan untuk menentukan apakah ada paket
yang hilang. Jika paket hilang, tindakan terbaik untuk tujuan yang akan diambil adalah hingga ke aplikasi.
Ini mungkin melewatkan frame video jika paket membawa data video, atau untuk memperkirakan nilai
yang hilang dengan interpolasi jika paket membawa data audio. Pengiriman ulang bukanlah pilihan praktis
karena paket retransmisi mungkin akan tiba terlambat untuk menjadi berguna. Sebagai akibatnya, RTP
tidak memiliki ucapan terima kasih, dan tidak ada mekanisme untuk meminta transmisi ulang. Setiap
muatan RTP dapat berisi beberapa sampel, dan mereka mungkin dikodekan dengan cara apa pun yang
diinginkan oleh aplikasi. Untuk memungkinkan interworking, RTP menentukan beberapa profil (misalnya,
satu aliran audio), dan untuk setiap profil, beberapa format pengkodean dapat diizinkan. Sebagai contoh,
satu aliran audio dapat dikodekan sebagai sampel PCM 8 bit pada 8 kHz menggunakan penyandian delta,
pengkodean prediktif, pengkodean GSM, pengkodean MP3, dan sebagainya. RTP menyediakan kolom
header di mana sumber dapat menentukan pengkodean tetapi tidak terlibat dalam bagaimana
pengkodean dilakukan.

Fasilitas lain yang dibutuhkan banyak aplikasi waktu nyata adalah timestamping. Idenya di sini adalah
untuk memungkinkan sumber untuk mengasosiasikan timestamp dengan sampel pertama di setiap paket.
Stempel waktu relatif terhadap awal aliran, jadi hanya perbedaan antara stempel waktu yang signifikan.
Nilai absolut tidak memiliki arti. Seperti yang akan kami jelaskan secara singkat, mekanisme ini
memungkinkan tujuan untuk melakukan sejumlah kecil buffering dan memainkan setiap sampel jumlah
milidetik yang tepat setelah dimulainya aliran, terlepas dari kapan paket yang berisi sampel tiba.
Tidak hanya timestamping mengurangi efek variasi dalam penundaan jaringan, tetapi juga memungkinkan
beberapa aliran untuk disinkronkan satu sama lain. Misalnya, program televisi digital mungkin memiliki
aliran video dan dua aliran audio. Dua stream audio bisa untuk siaran stereo atau untuk menangani film
dengan soundtrack bahasa asli dan soundtrack dijuluki ke bahasa lokal, memberi pemirsa pilihan. Setiap
aliran berasal dari perangkat fisik yang berbeda, tetapi jika mereka stempel waktu dari satu penghitung,
mereka dapat diputar secara serentak, bahkan jika aliran ditransmisikan dan / atau diterima secara tidak
teratur.

Header RTP diilustrasikan pada Gambar 6-31. Ini terdiri dari tiga kata 32-bit dan berpotensi beberapa
ekstensi. Kata pertama berisi bidang Versi, yang sudah ada di 2. Mari kita berharap versi ini sangat dekat
dengan versi pamungkas sejak itu

hanya ada satu titik kode yang tersisa (walaupun 3 dapat didefinisikan sebagai berarti bahwa versi
sebenarnya adalah kata perpanjangan).

Bit P menunjukkan bahwa paket telah dipasangkan ke kelipatan 4 byte. Persen padding terakhir
menceritakan berapa banyak byte yang ditambahkan. Bit X menunjukkan bahwa ada header ekstensi.
Format dan arti dari header ekstensi tidak didefinisikan. Satu-satunya hal yang didefinisikan adalah bahwa
kata pertama dari ekstensi memberikan panjang. Ini adalah pintu keluar darurat untuk semua persyaratan
yang tidak terduga.

Bidang CC memberi tahu berapa banyak sumber yang berkontribusi, dari 0 hingga 15 (lihat di bawah). Bit
M adalah bit penanda aplikasi khusus. Ini dapat digunakan untuk menandai awal dari frame video, awal
kata di saluran audio, atau sesuatu yang lain yang dipahami aplikasi. Bidang Jenis muatan menunjukkan
algoritme pengkodean mana yang telah digunakan (mis., Audio 8-bit yang tidak terkompresi, MP3, dll.).
Karena setiap paket membawa bidang ini, pengkodean dapat berubah selama transmisi.

Nomor Urutan hanyalah sebuah penghitung yang bertambah pada setiap paket RTP yang dikirim. Ini
digunakan untuk mendeteksi paket yang hilang. Stempel Waktu dihasilkan oleh sumber streaming untuk
diperhatikan saat sampel pertama dalam paket dibuat. Nilai ini dapat membantu mengurangi variasi
waktu yang disebut jitter pada penerima dengan memisahkan pemutaran dari waktu kedatangan paket.
Pengidentifikasi sumber sinkronisasi memberitahu aliran mana paket itu milik. Ini adalah metode yang
digunakan untuk multipleks dan demultipleks beberapa aliran data ke dalam aliran tunggal paket UDP.
Akhirnya, pengidentifikasi sumber Berkontribusi, jika ada, digunakan ketika mixer hadir di studio. Dalam
hal ini, mixer adalah sumber sinkronisasi, dan aliran yang dicampur tercantum di sini.

RTCP — Protokol Kontrol Transportasi Waktu-Nyata

RTP memiliki protokol adik kecil (protokol saudara kecil?) Disebut RTCP (Realtime Transport Control
Protocol). Ini didefinisikan bersama dengan RTP di RFC 3550 dan menangani umpan balik, sinkronisasi,
dan antarmuka pengguna. Itu tidak mengangkut sampel media. Fungsi pertama dapat digunakan untuk
memberikan umpan balik tentang keterlambatan, variasi dalam penundaan atau jitter, bandwidth,
kemacetan, dan properti jaringan lainnya ke sumber. Informasi ini dapat digunakan oleh proses encoding
untuk meningkatkan laju data (dan memberikan kualitas yang lebih baik) ketika jaringan berfungsi dengan
baik dan untuk memotong kembali data menilai ketika ada masalah dalam jaringan. Dengan memberikan
umpan balik yang berkelanjutan, algoritma pengkodean dapat secara terus menerus disesuaikan untuk
memberikan kualitas terbaik yang mungkin dalam situasi saat ini. Sebagai contoh, jika bandwidth
meningkat atau menurun selama transmisi, pengkodean dapat beralih dari MP3 ke 8-bit PCM ke delta
encoding sesuai kebutuhan. Bidang Tipe muatan digunakan untuk memberi tahu tujuan apa yang
digunakan oleh algoritma pengkodean untuk paket saat ini, sehingga memungkinkan untuk
memvariasikannya sesuai permintaan.

Masalah dengan memberikan umpan balik adalah bahwa laporan RTCP dikirim ke semua peserta. Untuk
aplikasi multicast dengan grup besar, bandwidth yang digunakan oleh RTCP akan cepat tumbuh besar.
Untuk mencegah hal ini terjadi, pengirim RTCP mengurangi tingkat laporan mereka untuk secara kolektif
mengkonsumsi tidak lebih dari, katakanlah, 5% dari bandwidth media. Untuk melakukan ini, setiap
peserta perlu mengetahui bandwidth media, yang dipelajari dari pengirim, dan jumlah peserta, yang
diperkirakan dengan mendengarkan laporan RTCP lainnya.

RTCP juga menangani sinkronisasi interstream. Masalahnya adalah bahwa aliran yang berbeda dapat
menggunakan jam yang berbeda, dengan perincian yang berbeda dan tingkat penyimpangan yang
berbeda. RTCP dapat digunakan untuk menjaga mereka tetap sinkron. Akhirnya, RTCP menyediakan cara
untuk menamai berbagai sumber (misalnya, dalam teks ASCII). Informasi ini dapat ditampilkan di layar
penerima untuk menunjukkan siapa

sedang berbicara pada saat ini.

Informasi lebih lanjut tentang RTP dapat ditemukan di Perkins (2003).

Bermain dengan Buffering and Jitter Control

Setelah informasi media mencapai penerima, itu harus dimainkan di

waktu yang tepat. Secara umum, ini tidak akan menjadi waktu di mana paket RTP tiba

penerima karena paket akan membutuhkan waktu yang sedikit berbeda untuk transit

jaringan. Bahkan jika paket disuntikkan dengan interval yang tepat

mereka di pengirim, mereka akan mencapai penerima dengan kerabat yang berbeda

waktu. Variasi penundaan ini disebut jitter. Bahkan sejumlah kecil paket jitter

dapat menyebabkan artifak media yang mengganggu, seperti frame video yang tidak bagus dan tidak
dapat dipahami

audio, jika media hanya dimainkan saat tiba.

Solusi untuk masalah ini adalah menyangga paket-paket di receiver sebelum mereka

dimainkan untuk mengurangi jitter. Sebagai contoh, pada Gambar 6-32 kita melihat aliran

paket yang dikirimkan dengan sejumlah besar jitter. Paket 1 dikirim dari

server pada t = 0 detik dan tiba di klien pada t = 1 detik. Paket 2 mengalami

lebih banyak penundaan dan membutuhkan waktu 2 detik untuk tiba. Ketika paket tiba, mereka buffered

mesin klien.
Pada t = 10 detik, pemutaran dimulai. Saat ini, paket 1 hingga 6 telah

buffered sehingga mereka dapat dihapus dari buffer pada interval seragam untuk

bermain halus. Dalam kasus umum, tidak perlu menggunakan interval yang seragam karena

cap waktu RTP memberitahu kapan media harus dimainkan. Sayangnya, kita dapat melihat bahwa paket
8 telah tertunda begitu banyak

tidak tersedia ketika slot bermainnya muncul. Ada dua opsi. Paket 8 bisa

dilewati dan pemain dapat melanjutkan ke paket berikutnya. Atau, pemutaran

dapat berhenti sampai paket 8 tiba, menciptakan celah yang mengganggu dalam musik atau

film. Dalam aplikasi media langsung seperti panggilan voice-over-IP, paket biasanya akan

dilewati. Aplikasi langsung tidak berfungsi dengan baik saat ditahan. Dalam media streaming

aplikasi, pemain mungkin berhenti sebentar. Masalah ini dapat diatasi dengan menunda

waktu mulai bahkan lebih, dengan menggunakan buffer yang lebih besar. Untuk audio streaming atau

pemutar video, buffer sekitar 10 detik sering digunakan untuk memastikan bahwa pemain

menerima semua paket (yang tidak terjatuh di jaringan) pada waktunya. Untuk hidup

aplikasi seperti konferensi video, buffer pendek diperlukan untuk responsif.

Pertimbangan utama untuk kelancaran bermain adalah titik pemutaran, atau berapa lama

tunggu di penerima untuk media sebelum memainkannya. Memutuskan berapa lama menunggu

tergantung pada jitter. Perbedaan antara koneksi low-jitter dan high-jitter

ditunjukkan pada Gambar 6-33. Penundaan rata-rata mungkin tidak berbeda jauh antara

keduanya, tetapi jika ada jitter tinggi, titik pemutaran mungkin perlu lebih jauh

untuk menangkap 99% paket daripada jika ada jitter rendah.

Untuk memilih titik pemutaran yang bagus, aplikasi dapat mengukur jitter dengan melihat

pada perbedaan antara timestamps RTP dan waktu kedatangan. Setiap perbedaan

memberikan contoh penundaan (plus arbitrer, offset tetap). Namun, itu

penundaan dapat berubah seiring waktu karena lalu lintas lain yang bersaing dan rute yang berubah.

Untuk mengakomodasi perubahan ini, aplikasi dapat menyesuaikan titik pemutarannya sementara

mereka berlari. Namun, jika tidak dilakukan dengan baik, mengubah titik pemutaran dapat menghasilkan

kesalahan yang dapat diamati kepada pengguna. Salah satu cara untuk menghindari masalah ini untuk
audio adalah
untuk menyesuaikan titik pemutaran antara pembicaraan, di celah dalam percakapan. Tidak

orang akan melihat perbedaan antara keheningan pendek dan sedikit lebih lama. RTP

memungkinkan aplikasi mengatur bit penanda M untuk menunjukkan awal dari suatu pembicaraan baru
untuk

tujuan ini.

Jika penundaan mutlak hingga media dimainkan terlalu lama, aplikasi langsung

akan menderita. Tidak ada yang bisa dilakukan untuk mengurangi delay propagasi jika jalur langsung
sudah digunakan. Titik pemutaran dapat ditarik dengan hanya menerima itu

sebagian besar paket akan tiba terlambat untuk dimainkan. Jika ini tidak dapat diterima,

satu-satunya cara untuk menarik titik pemutaran adalah mengurangi jitter dengan menggunakan

kualitas layanan yang lebih baik, misalnya, penyampaian yang dipercepat dibedakan

layanan. Artinya, jaringan yang lebih baik diperlukan.