CHAPTER 20-24 Disusun Guna Memenuhi Salah Satu Tugas Mata Kuliah Jaringan Komputer Dosen: Aryawan Agung Nugroho, S.T.
Disusun oleh: 1. Nugraha Agung Mahardika
09105241004
2. Tri Wahyuni
09105241023
3. Henny Riska Pratiwi
09105241024
4. Siti Zulaikhah R.
09105241032
5. Nunung Wulandari
09105241036
TEKNOLOGI PENDIDIKAN FAKULTAS ILMU PENDIDIKAN UNIVERSITAS NEGERI YOGYAKARTA 2011
BAB 20 PROTOKOL TRANSPOR Pada suatu arsitektur protokol, protokol transpor berada dalam jaringan atau dalam lapisan internetwork, yang menyediakan layanan-layanan yang berhubungan dengan jaringan dan hanya dibawah aplikasi dan protokol-protokol pada lapisan yang lebih tinggilainnya. Protokol transpor menyediakan layananlayanan bagi pemakai layanan transpor (LT),seperti FTP, SMTP, dan TELNET.Etentitas transpor lokal berkomunikasi dengan beberapa itensitas transpor yang berjauhan, dengan menggunakan layanan dari beberapa lapisan yang lebih rendah, seperti protokol internet. Layanan yang disediakan oleh protokol transpor adalah transpor data dari ujung-ke ujung dengan cara membebaskan pemakaian LT dari detail-detail sistem komunikasi yang dipakai. Pertama-tama bab ini akan mengulas mekanisme protokol yang diperlukan untuk menyediakan layanan-layanan ini.
17.1 Mekanisme Protokol Transpor yang Berorientasi Koneksi Dua jenis transpor dasar adalah layanan berorientasi koneksi dan layanan nirkoneksi atau layanan datagram. Layanan yang berorientasi koneksi tersedia untuk menetapkan, memelihara, dan menghentikan suatu koneksi
MIME
BGP
FTP
HTTP
SMTP
TELNET
TPC
SNMP
UDP
ICMP
IGMP
OSPF
IP
1
RSVP
logik diantara pemakai LT. Bentuk penuh protokol transpor yang berorientasi koneksi, seperti TCP, bersifatkompleks. Layanan Jaringan Sequensing yang Andal Contoh-contoh jaringan semacam itu adalah sebagai berikut :
Jaringan highly reliable packet-switching dengan interface X.25
Jaringan frame relay dengan menggunakan protokol kontrol LAPF.
IEEE 802.3 LAN dengan menggunakan layanan LLC yang berorientasi koneksi Pada semua kasus ini ,protokol transpor digunakan sebagai protokol dari
ujung ke-ujung diantara dua sistem ujung yang terpasang ke jaringan yang sama. Asumsi mengenai layanan jaringan sequensing yang andal memungkinkan penggunaan suatu protokol transpor yang benar-benar sederhana. Terdapat empat hal yang perlu dialamatkan ,yakni
Pengalamatan,
Multiplexing,
Kontrol aliran, dan
Penetapan / pemutusan koneksi.
Pengalamatan Hal sederhana yang berkaitan dengan pengalamatan adalah, pemakai dari entitas transpor tertentu ingin menetapkan sebuah koneksi atau ingin membuat data tranfer kepemakai dari beberapa entitas transpor lainnya. Pemakai sasarannya perlu ditentukan dengan cara sebagai berikut.
Identifikasi pemakai
Identifikasi entitas transpor
Alamat host
Nomor jaringan Protokol transpor harus mampu mendapatkan informasi-informasi seperti
diatas dari alamat pemakai LT. Biasanya, alamat pemakai ditetapkan sebagai (
2
Host,Port). Variabel port menunjukkan suatu pemakai LT khusus pada Host yang tertentu. Berikutnya , alamat tersebut juga mencangkup penandaan tipe protokol transpor ( misalnya TCP,UDP ). Dalam hal jaringan tunggal , Host menentukan sebuah perangkat yang terpasang ke jaringan. Sedangkan dalam hal internet, Host adalah alamat internet global. Dalam TCP, kombinasi antara port dan host disebut socket. Satu pernyataan yang akan muncul ialah, bagaimana pemakai LT awal mengetahui alamat pemakai LT tujuan ? Dalam hal ini ada dua strategi statis dan dua strategi dinamis yang bisa digunakan. 1. Pemakai LT mengetahui alamat yang ingin ia gunakan waktu ke depan. Pada dasarnya ini merupakan fungsi konfigurasi sistem. 2. Beberapa layanan yang sering digunakan dianggap “ Well-known addresses”. ( misalnya, pembagian waktu dan pengolahan data). 3. Tersedia server nama. Pemakai LT yang meminta layanan melalui beberapa nama generik atau nama global. Permintaan ini dikirim ke server nama ,yang kemudian melakukan pencarian direktori dan mengembalikan alamat yang diminta.Lalu entitas transpor meneruskan koneksi. 4. Pada beberapa kasus lainnya ,pemakai tujuan dianggap sebagai proses yang diperbanyak pada saat diminta. Pemakai yang memulai proses bisa mengirim permintaan proses ke alamat yang sudah diketahui dengan baik. Pemakai pada alamat ini merupakan proses sistem yang mempunyai hak istimewa yang akan memperbanyak proses baru dan mengembalikan alamat.
Multiplexing Entitas transpor juga bisa menampilkan fungsi multiplexing dengan mempertimbangkan layanan-layanan jaringan yang digunakan , mengingat bahwa kita menetapkan upward multiplexing sebagai koneksi multiplexing dari koneksikoneksi multipel pada suatu koneksi tunggal pada level yang lebih rendah , dan downward multiplexing sebagai pemisah suatu koneksi tunggal di antara koneksikoneksi multipel pada level yang lebih rendah.
3
Di lain pihak,downward multiplexing atau pemisahan bisa digunakan untuk meningkatkan laju penyelesaian. Sebagai contoh , setiap sirkuit virtual X.25 dibatasi untuk nomor urut 3 bit atau 7 bit. Jarak deretan yang lebih besar diperlukan untuk jaringan berkecepatan tinggi
dan jaringan dengan tingkat
penundaan yang tinggi. Tentu laju penyelesaiannya hanya dapat ditingkatkan sejauh itu. Bila terdapat suatu jalur simpul-host tunggal di jalur tempat semua sirkuit virtual di-multiplexing kan sehingga ,laju penyelesaian koneksi transpor tidak bisa melebihi jalur rate data tersebut.
Kontrol Aliran Mekanisme kontrol aliran merupakan mekanisme yang relatif sederhana pada lapisan link, namun merupakan mekanisme yang rumit pada lapisan transpor, hal ini disebabkan oleh hal-hal berikut.
Penundaan transmisi diantara entitas transpor umumnya panjang bila dibandingkan dengan waktu transmisi aktual.
Karena lapisan transpor berorientasi pada jaringan atau internet, jumlah penundaan transmisi sangat mudah berubah-ubah. Ini menyulitkan penggunaan
mekanisme
melebihi
waktu
secara
efektif
untuk
mentransmisiskan ulang data yang hilang. Umumnya ,terdapat dua alasan mengapa satu entitas transpor ingin menahan rate pentransmisian segmen pada suatu koneksi dari entitas transpor yang lain.
Pemakai dari entitas transpor penerima tidak mampu mengikuti aliran data.
Entitas transpor penerima dengan sendirinya tidak mampu mengikuti aliran segmen-segmen. Salah satu dari dua permasalahan yang baru saja disebut bisa
menyebabkan penyangga kepenuhan. Jadi, entitas transpor perlu mengambil langkah menghentikan atau memperlambat aliran segmen agar penyangga tidak kepenuhan. Persyaratan ini tentu saja tidak mudah dipenuhi karena mempengaruhi periode waktu antara pengirim dan receiver. Kita beralih ke poin ini sebentar. 4
Pertama, kita tampilkan empat hal agar persyaratan tersebut terpenuhi. Entitas transpor penerima bisa : 1. Tidak melakukan apa-apa. 2. Menolak menerima segmen-segmen berikutnya dari layanan jaringan, 3. Menggunakan protokol jendela-bergeser tetap,atau 4. Menggunakan suatu skema kredit. Alternatif pertama berarti bahwa segmen-segmen yang memenuhi penyangga dibuang. Entitas transpor pengirim , yang gagal mendapat balasan ,akan melakukan transmisi ulang. Alternatif kedua adalah mekanisme pengiriman balik yang bergantung pada layanan jaringan dalam melakukan hal tersebut. Bila sebuah penyangga entitas transpor penuh, ia akan menolak data-data
tambahan dari layanan
jaringan. Hal ini mempercepat prosedur kontrol aliran di dalam jaringanyang pada awalnya memperlambat layanan jaringan pada pihak pengirim. Layanan ini sebaliknya menolak segmen-segmen tambahan dari entitas transpornya. Alternatif ketiga sudah diketahui dari pembahasan mengenai protokol lapisan link pada bab 7, yang unsur utamanaya:
Penggunaan urutan nomor untuk unit-unit data.
Penggunaan jendela berukuran tertentu.
Penggunaan balasan untuk menaikkan jendela.
Alternatif keempat yakni skema kredit, menyediakan derajat kontrol atasa aliran dan bagi data reseiver. Meski tidak benar –benar diperlukan dengan jaringan yang handal, skema kredit akan berhasil dalam aliran lalu lintas yang lebih halus. Selanjutnya akan menjadi skema yang lebih efektif dengan jaringan yang tidak andal, sebagaimana yang akan kita lihat nanti. Skema kredit memisahkan balasan dari kontrol aliran. Pada protokol jendela bergeser tetap, seperti X.25 dan HDLC, kedua-duanya sinonim. Pada skema kredit, segmen bisa mendapat balasan tampa menanggung kredit baru, dan begitu seterusnya. Untuk skema kredit, setiap octed data individu yang ditransmisikan dianggap memiliki sebuah nomor urut. Sebagai tambahan bagi data,setiap segmen yang ditransmisikan memasukkan kedalam headernya tiga bidang yang berkaitan 5
dengan kontrol aliran,yakni nomor urut,nomor balasan ,dan jendela. Bila suatu entitas transpor mengirim sebuah segmen,ia memasukkan nomor urut octed pertama dalam bidang data segmen.Entitas transpor membalas segmen yang datang dengan sebuah segmen kembali yang mencangkup ( AN = i, W= j). Dengan interpretasi sebagai berikut.
Semua octed sepanjang nomor urut SN =i-1 dibalas, octed yang diharapkan berikutnya memiliki nomor urut i.
Ijin ditanggung agar mengirim jendela tambahan sebesar W = j octed data, maksudnya, j octed berhubungan dengan nomor urut i di sepanjang i + j-1
Gambar dibawah menggambarkan mekanismenya.
Penetapan dan Pengakhiran Koneksi Bahkan dengan suatu layanan jaringan yang andal sekalipun, prosedurprosedur penetapan dan pengakhiran koneksi tetap diperlukan. Penetapan koneksi memilikitiga tujuan utama,sebagai berikut.
Memungkinkan setiap pihak memastikan bahwa pihak yang lainnya eksis.
Memungkinkan
negoisasi
dalam
hal
parameter-parameter
pilihan
(misalnya ,ukuran segmen maksimum,ukuran jendela maksimum ,dan mutu layanan). 6
Menggerakan pengalokasian sumber daya entitas transpor ( misalnya ruang penyangga dan masukkan untuk tabel koneksi ). Penetapan koneksi dilakukan melalui kesepakatan mutualisme dan bisa
dicapai lewat serangkaian segmen kontrol dan perintah pemakai sederhana,seperti yang
ditunjukkan
dalam
diagram
status
dalam
Gambar
17.4
untuk
memulainya,pemakai LT berada dalam status CLOSED ( misalnya , tidak ada koneksi transpor terbuka ). Dari status CLOSED ,pemakai LT bisa membuka koneksi dengan cara mengeluarkan sebuah perintah Active Open, yang menginsruksikan entitas transpor agar mengupayakan penetapan koneksi dengan pemakai LT yang berjauhan, yang menggerakkan entitas transpor agar mengirim sebuah segmen SYN ( untuk mensinkronkan). Segmen ini dibawa menuju entitas transpor penerimaan dan diartikan
Sebagai suatu permintaan koneksi untuk sebuah port tertentu. Bila entitas transpor tujuan berada dalam status LISTEN untuk port tersebut, maka koneksi ditetapkan melalui beberapa tindakan yang dilakukan oleh entitas transpor penerimaan ,diantaranya sebagai berikut.
Mensinyalkan pemakai LT bahwa koneksi telah dibuka.
7
Mengirim sebuah SYN sebagai konfirmasi kepada entitas transpor yang berjauhan.
Meletakkan objek koneksi di dalam status ESTAB (establised )
Bila SYN terkait diterima oleh entitas transpor yang melakukan inisiasi, ia juga bisa mengubah koneksi ke status ESTAB. Koneksi digagalkan sejak dini bila salah satu pemakai LT mengeluarkan perintah Close. Pembaca mungkin bertanya apa yang akan terjadi bila SYN datang sewaktu pemakai LT yang diminta berada dalam keadaan idle( tideak mendengar). Ada tiga masalah yang bisa terjadi sebagai berikut.
Entitas transpor bisa menolak permintaan dengan cara mengirim segmenRST (reset) kembalikke entitas transpor lainnya.
Permintaan bisa diartikan sampai perintah OPEN yang sesuai dikeluarkan oleh pemakai LT agar memberitahukannya dari permintaan yang ditunggu.
Penghentian koneksi dikendalikan dengan cara yang sama. Salah satu pihak ,atau kedua-duanya,bisa memulai perintah close.Koneksi ditutup melalui kesepakatan bersama. Strategi ini memungkinkan salah satu pihak menghentikan koneksi secara kasar atau halus.Agar nantinya tercapai ,koneksi yang berada dalam status CLOSE WAIT harus terus menerima segmen-segmen data sampai segmen FIN (finish) diterima. Gambar 17.4 juga menetapkan prosedur untuk penghentian koneksi yang halus.
8
Layanan Jaringan yang Tidak Andal Kasus yang lebih sulit dalam protokol transpor adalah protokol transpor dari layanan jaringan yang tidak anadal. Contoh dari jaringan semacam itu adalah
Internetwork yang menggunakan IP.
Jaringan frame relay yang hanya menggunakan protokol inti LAPF.
LAN IEEE 802.3 yang menggunakan layanan LLC nirkoneksi tampa balasan.
Problemnya tidak hanya segmen-segmen kadangkala hilang,namun segmen – segmen tersebut tidaj sesuai urutan akibat dari penundaan transit yang berupa variabel.
Strategi Transmisi Ulang Terdapat
dua
peristiwa
yang
memerlukan
transmisi
ulang
segmen.Pertama, segmen bisa rusak saat transit namun tetap tiba di tujuan.Kontigensi kedua adalah saat segmen gagal tiba di tujuan. Untuk mengatasi kontigensi ini ,kita perlu menggunakan skema balasan positif. Receiver harus membalasa
seipa
segmenyang
bisa
diterima
dengan
baikdengan
cara
mengembalikan segmen yang memuat nomor balasan. Untuk efisiensinya kita tidak memerlukan satu balasan per segmen.
Pendeteksian Duplikat Bila sebuah segmen hilang dan kemudian dilakukan transmisi ulang, jika ACK hilang,, maka satu segmen akan ditransmisikan ulang dan bila mereka tiba dengan baik, kan menjadi duplikat segmen-segmen sebelumnya yang sudah diterima.
9
Pendeteksian Duplikat Bila ACK hilang, satu segmen atau lebih akan ditransrnisikan ulang dan bila mereka tiba dengan baik, akan menjadi duplikat segmen-segmen yang sebelumnya sudah diterima. Jadi, receiver harus mampu mengenali duplikatduplikat tersebut. Kenyataannya, masing-masing segmen yang membawa nomor urut turut membantu, namun, mendeteksi dan menangani duplikat bukanlah hal yang mudah. Ada dua hal yang patut diperhatikan.
Sebuah duplikat diterima sebelurn penutupan koneksi.
Sebuah duplikat diterima setelah penutupan koneksi.
Pada kasus lain, diperlukan dua taktik untuk mengatasi suatu duplikat yang diterima sebelum penutupan koneksi.
Receiver harus berasumsi bahwa balasannya hilang dan karenanya harus membalas duplikat. Akibatnya, pengirim tidak dapat dikacaukan bila ia menerirna balasan-balasan ganda untuk segmen yang sama.
Jarak nomor urut harus cukup panjang sehingga tidak dapat terulang dalam kurang waktu dari waktu-hidup segmen maksimum yang memungkinkan.
Gambar 17.6 menampilkan alasan bagi persyaratan-persyaratan berikutnya. Dalam contoh ini, jarak urutannya sepanjang 1600, maksudnya, setelah SN =1600, nomor siklus berputar kembali dan dimulai dengan SN = 1. Untuk menyederhanakannya, kita mengasumsikan suatu protokol kredit jendela bergeser dengan ukuran jendela sebesar 600. Anggap bahwa A telah mentransmisikan segmen-segmen data dengan SN = 1, 201, dan 401, serta tidak menerima balasan. Akhirnya, waktunya habis dan melakukan transmisi ulang terhadap segmen SN = 1. B telah menerirna dua segmen dengan SN = 201 dan 401, namun SN = I ditunda saat transit. Jadi, B tidak menginim balasan apapun. Bila duplikat segmen SN = 1 tiba, B membalas 1, 201, dan 401 dengan AN = 601. Sementara itu, A waktunya habis lagi dan rnentransmisikan ulang SN = 201, sehingga B membalas dengan AN = 601 lainnya. Segala sesuatunya kini tampak mengurutkan diri sendiri dan data transfer terus berlanjut. Bila jarak urutan dihabiskan, A berputar kembali ke SN = 1 dan terus berlanjut. 10
Yang membuat kondisi sulit, segmen SN = 1 yang lama rnembuat pemunculannya terlambat dan diterima oleh B sebelum segmen SN = 1 baru tiba.
Kontrol Aliran Mekanisme kontrol aliran pengalokasian kredit yang telah digambarkan sebelumnya, benar-benar mampu dalam menghadapi layanan jaringan yang tidak andal dan memerlukan sedikit peningkatan. Sebagairnana yang telah kita sebut, segmen yang berisikan (AN = i, W = j) menerima seluruh octet mulai dari nomor i-1 dan memberi kredit untuk j octet tambahan Yang dimulai dengan octet i. Mekanisme pengalokasian kredit i benar-benar fleksibel.
Penetapan Koneksi Seperti halnya mekanisme protokol lainnya, penetapan koneksi harus mernpertimbangkan ketidakandalan layanan jaringan. Ingat bahwa suatu penetapan koneksi menghendaki pertukaran SYN, suatu prosedur yang kadang-
11
kadang disebut sebagai jabat tangan dua arah. Anggap bahwa A mengeluarkan sebuah SYN ke B. A mengharapkan bisa mendapat sebuah SYN kembali, mengonfirmasikan koneksi tersebut. Dua hal yang bisa salah dalam hal ini, SYN A hilang atau SYN jawaban B yang hilang. Kedua kasus ini bisa ditangani dengan menggunakan pewaktu SYN transmisi ulang (Tabel 17.1). Setelah A mengeluarkan sebuah SYN, ia akan mengeluarkan SYN kembali bila pewaktu berakhir. Hal ini memberi perkembangan, secara potensial, membuat duplikat SYN. Bila SYN asli A hilang, tidak akan dibuat duplikat-duplikatnya. Bila respons B hilang, maka B bisa menerima dua SYN dari A. Selanjutnya, bila respon B tidak hilang, namun hanya ditunda begitu saja, A bisa mendapat dua SYN. Semua ini berarti bahwa A dan B harus mengabaikan duplikat SYN begitu saja sekali koneksi ditetapkan. Terdapat problem-problem lainnya yang harus dihadapi. Hanya saat SYN yang ditunda atau respons yang hilang dapat memberi SYN duplikat, segmen data yang ditunda atau balasan yang hilang dapat memberi segmen-segmen data duplikat, sebagaimana yang terlihat dalam Gambar 17.6. Segmen data yang diduplikasikan atau ditunda semacam itu bisa mengganggu penetapan koneksi, seperti yang diilustrasikan dalam Gambar 17.7. Asumsikan bahwa dengan setiap koneksi baru, masing-masing entitas protokol transpor mulai memberi nomor segmen-segmen datanya dengan nomor urut 1. Dalam gambar tersebut, salinan duplikat segmen SN = 401 dari koneksi lama tiba selama masa koneksi baru dan dikinini ke B sebelum pengiriman segnien data SN = 401 yang sah. Salah satu cara mengatasi masalah ini adalah dengan memulai setiap koneksi baru dengan nomor urut yang berbeda yang jauh terpisah dari nomor urut terakhir dari koneksi yang paling akhir. Untuk tujuan ini, permintaan koneksi berasal dari bentuk SYN i, dan i adalah nomor urut segmen data pertama yang akan dikirim pada koneksi ini. Sekarang amati bahwa sebuah duplikat SYN i bisa mempertahankan pemutusan koneksi.Gambar 17.8 menggambarkan problem yang bisa terjadi. SYN i lama tiba di B
12
Setelah koneksi dihentikan. B mengasumsikan bahwa ini merupakan permintaan baru dan meresponsnya dengan SYN j, yang berarti bahwa B menerima permintaan koneksi dan akan mulai melakukan transmisi dengan SN = j. Sementara itu, A telah memutuskan untuk membuka suatu koneksi baru dengan B dan mengirim SYN k. B membuang ini sebagai duplikat. Sekarang kedua pihak telah melakukan transmisi dan berturut-turut menerima sebuah segmen SYN, dan karenanya berpikir bahwa koneksi yang sahih telah ada. Namun, bila A mengawali transfer data dengan sebuah segmen bernomor k, B menolak segmen saat keluar dari urutan. Salah satu cara keluar dari problem ini adalah dengan masing-masing pihak agar membalas nomor urut dan SYN lainnya secara eksplisit. Prosedurnya disebut juga sebagai jabat tangan tiga arah. Diagram status koneksi yang direvisi, yang dipakai oleh TCP, ditunjukan di bagian atas Gambar 17.9. Sebuah status baru ditambahkan (SYN RECEIVED). Dalam status ini, entitas transpor selama pembukaan koneksi ragu-ragu untuk memastikan bahwa segmen-segmen SYN dikirim oleh kedua pihak yang dibalas sebelum koneksi yang dinyatakan ditetapkan. Sebagai tambahan untuk status baru tersebut, terdapat sebuah segmen kontrol (RST) untuk mengeset kembali pihak yang lain saat duplikat SYN terdeteksi.
13
Gambar 17.10 menggambarkan operasi jabat tangan tiga arah khusus. Dalam Gambar 17.10a, entitas transpor A mengawali koneksi dengan sebuah SYN termasuk nomor urut pengiriman i. SYN yang terkait membalas nomor tersebut dan mencakup
nomor urut untuk pihak lainnya. A membalas SYN/ACK di dalam segmen data pertamanya. Gambar 17.10b menunjukkan situasi ketika SYN i lama tiba di B setelah penutupan koneksi yang relevan. B berasumsi bahwa ini merupakan sebuah permintaan baru dan meresponsnya dengan SYN j, AN = i. Bila A menerima pesan ini, ia meyakini bahwa ini bukan merupakan koneksi yang diminta dan karenanya mengirim sebuab RST, AN = j. Perlu dicatat bahwa bagian darl pesan RST AN = j sangat penting sehingga duplikat RST lama tidak menggagalkan penetapan koneksi yang sah. Gambar 17.10c menunjukkan suatu kasus ketika SYN/ACK lama tiba di tengah-tengah penetapan koneksi yang baru. Karena menggunakan
urut dalam balasan-balasannya, peristiwa ini tidak
menyebabkan kekacauan. Untuk menyederhanakannya, bagian teratas dari Gambar 17.9 tidak mencakup transisi tempat RST dikirim. Aturan dasarnya ialah, mengirim RST bila status koneksi belum OPEN dan ACK invalid (yang tidak menunjukkan ada sesuatu yang dikirim) diterima. Pembaca bisa mencoba beberapa kornbinasi kejadian agar bisa melihat betapa prosedur penetapan koneksi ini bisa bekerja dengan baik dari berbagai kombinasi segmen yang lama dan hilang.
14
Pengakhiran Koneksi Diagram status dalam Gambar 17.4 menetapkan penggunaan jabat tangan dua arab sederhana untuk penetapan koneksi, yang bisa dianggap tidak memuaskan bila layanan jaringan tidak andal. Hampir sama dengan itu, jabat tangan dua arah yang ditetapkan dalam diagram tersebut untuk mengakhiri koneksi ternyata tidak cukup memadai untuk layanan jaringan yang tidak andal. Skenario berikut ini bisa disebabkan karena segmen yang datang berurutan tidak terurut. Entitas transpor dalam status CLOSE WAIT mengirim segmen data terakhirnya, diikuti oleh sebuah segmen SYN, namun segmen FIN tiba di sisi lain sebelum segmen data terakhir. Entitas transport penerimaan akan menerima SYN tersebut, menutup koneksi, dan kehilangan segmen data terakhir. Untuk menghindari problem ini, nomor urut bisa diasosiasikan dengan FIN, yang bisa ditetapkan nomor urut berikutnya setelah octet terakhir dari data yang ditransmisikan. Dengan perbaikan ini, entitas transpor penerimaan, dalam penerimaan FIN, akan menunggu data yang tiba belakangan, bila perlu sehelum menutup koneksi. Problem yang lebih seriius berkaitan dengan hilangnya segmen-segmen dan kehadiran segmen kuno. Gambar 17.9 menunjukkan prosedur pemutusan yang mengadopsi solusi yang sama dengan yang digunakan untuk menetapkan koneksi.
15
Masing-masing pihak harus saling membalas FIN satu sama lain secara eksplisit, dengan menggunakan sebuah ACK dengan nomor urut FIN untuk dibalas. Untuk penutupan yang halus, entitas transpor memerlukan hal-hal sebagai berikut.
Harus mengirim sebuah FIN i dan menerima AN = i.
Harus menerirna sebuah FIN j dan mengirirn AN = j.
Harus menunggu interval setara dengan dua kali waktu hidup maksimum yang diharapkan
16
Pemulihan Tabrakan Bila sistem berdasarkan atas entitas transpor mengalami kegagalan dan berturut-turut melakukan start ulang, informasi status dari seluruh koneksi aktif hilang. Koneksi yang terpengaruh menjadi setengah terbuka karena pihak yang tidak mengalami kegagalan belum menyadari problem tersebut. Pihak koneksi setengah terbuka yang masih aktif bisa menutup koneksi dengan rnenggunakan pewaktu ketekunan. Pewaktu ini mengukur waktu ketika mesin transpor akan terus menunggu balasan (atau jawaban yang sesuai lainnya) dari segmen yang ditransmisikan setelah segmen berhasil melakukan transmisi ulang terhadap jumlah waktu maksimum. Bila pewaktu berakhir, entitas transpor mengasumsikan bahwa entitas transpor lainnya atau jaringan yang menghalangi telah gagal, menutup koneksi, dan mensinyalkan penutupan tidak normal kepada pemakai LT. Pada peristiwa ketika sebuah entitas transpor mengalami kegagalan dan melakukan start ulang dengan cepat, koneksi setengah terbuka bisa dihentikan 17
lebih cepat dengan menggunakan segmen RST. Pihak yang gagal mengembalikan RST i ke setiap segmen i yang menerimanya. Bila RST i mencapai pihak yang lainnya, ia harus mengecek validitasnya berdasarkan nornor unit i, karena RST bisa jadi merupakan respon terhadap segmen yang lama. Bila reset dianggap valid, entitas transport menampilkan pemutusan tak normal. Pengukuran-pengukuran ini menjernihkan situasi pada level transpor. Keputusan saat apakah harus membuka koneksi kembali tergantung pada pemakai LT. Masalahnya adalah sinkronisasi. Pada saat terjadi kegagalan, kemungkinan akan ada satu atau lebih segmen yang belum terselesaikan pada masing-masing arah. Pemakai LT yang berada pada pihak yang tidak mengalami kegagalan mengetahui berapa banyaknya data yang diterima, sedangkan pemakai lainnya tidak bisa mengetahuinya, bila informasi statusnya hilang. Jadi, sangat berbahaya bila beberapa data pemakai hilang atau terduplikasi.
17.2 TCP Dua protokol level transpor yang umumnya digunakan sebagai bagian dari suite TCP/ IP, yakni: Transmission Control Protocol (TCP), yang berorientasi koneksi, serta User Datagram Protocol (UDP), yang nirkoneksi. Di bagian ini kita mengamati TCP (yang ditetapkan dalarn RFC 793), pertama-tarna pada layanan yang tersedia bagi para pemakai dan kemudian beralih pada detail-detail protokol internal.
Layanan TCP TCP' dirancang sedemikian rupa agar mampu menyediakan komunikasi yang andal di antara sepasang proses (para pemakai TCP) pada berbagai jenis internet dan jaringan yang andal maupun yang tidak andal. TCP menyediakan dua fasilitas yang sangat berguna untuk pelabelan data, yaitu paksa dan desak.
Paksa deretan data
Pensinyalan data mendesak
18
Tabel 17.2 Primitive Permintaan Layanan TPC
Format Header TCP TCP hanya menggunakan sebuah jenis tunggal protocol data unit, yang disebut segmen TCP. Headernya ditunjukkan dalam Gambar 17.11. Karenanya satu header harus mampu menampilkan seluruh mekanisme protokol yang cukup besar, dengan panjang minimum sebesar 20 octet. Bidang-bidangnya adalah sebagai berikut.
Port sumber(16 bit): pemakai TCP sumber
Port tujuan (16 bit): pemakai ICP tujuan
Nomor urut (32 bit): nomor urut octet data pertama di dalam segmen ini kecuali bila tanda SYN diset, ini merupakan nomor urut awal (initial sequence number (ISN) dan octet data pertamanya ialah ISN + 1.
Nomor balasan (32 bit): balasan yang berlebihan. Memuat nomor urut octet data berikutnya tempat entitas TCP berharap menerima.
19
Tabel 17.3 Primitive Respons Layanan TCP
Data offset (4 bit): berjumlah 32 bit kata di dalam header.
Reserved (6 bit) : dimaksudkan untuk penggunaan-penggunaan selanjutnya.
Tanda-tanda (6 bit) : URG : bidang penunjuk urgen yang signifikan ACK : hidang balasan yang signifikan PSH: fungsi push RST: reset koneksi SYN : menyinkronkan nomor unit FIN : tidak ada data lagi darl pengirim
Jendela (16 bit): pengalokasian kredit kontrol aliran, dalam octet. Memuat sejumlah octet data yang dimulai dengan satu yang ditunjukkan di dalam bidang balasan bahwa pengirim ingin menerima.
Checksum (16 bit): bidang ones complements dari sum modulo 216 – 1 dari seluruh word 16 bit di dalam segmen ditambah dengan pseudoheader, yang akan dijelaskan kemudian.
20
Pointer Urgen (16 bit): menunjuk pada octet terakhir dalam urutan data urgen. Ini memungkinkan receiver bisa mengetahui berapa banyaknya data urgen yang datang.
Tabel 17.4 Parameter-parameter Layanan TCP
Gambar 17.11 Header TCP
21
Pilihan (Variabel): contoh pilihan yang menentukan ukuran segmen maksimum yang akan diterima. Nomor urut dan nomor balasan lebih membatasi octet daripada segmen-
segmen secara keseluruhan. Sebagai contoh, bila segmen memuat nomor urut 1001 dan mencakup 600 octet data, nomor urutnya menunjuk pada octet pertama di dalam bidang data, segmen berikutnya dalam perintah logik akan memiliki nomor urut 1601. Jadi, TCP berorientasi deratan secara logik: menerima aliran octet darl pemakai, mengelompokkannya ke dalam segmen-segmen yang berukuran sesuai, dan menjumlahkan setiap octet di dalam aliran. Bidang checksum berlaku untuk seluruh segmen ditambah dengan pseudoheader yang dicocokkan dengan header pada saat penghitungan (baik pada transmisi atau pada penerimaan). Psudoheader mencakup bidang-hidang sebagai berikut dari header IP: protokol serta alamat internet sumber dan tujuan, ditambah dengan bidang panjang segmen. Dengan mencakup pseudoheader, TCP melindungi dirinya sendiri dan kesalahan pengiriman lewat IP. Maksudnya, bila IP mengirim sebuah segmen ke host yang keliru, bahkan bila segmen tidak berisikan bit yang mengalami kesalahan, entitas TCP penerimaan akan mendeteksi kesalahan dalam pengiriman. Dengan membandingkan header TCP terhadap interface pemakai TCP yang ditetapkan dalam Tabel 17.2 dan 17.3, pembaca bisa merasakan bahwa beherapa item telah hilang dari header TCP tersehut yang termasuk dalam hal mi. TCP dirancang khusus agar bisa bekerja dengan IF. Karenanya, beberapa parameter pemakai TCP dilintaskan oleh TCP menuju IP untuk pencantuman di dalam header IF. Berikut ini adalah hal-hal yang relevan.
Precedence: hidang 3-bit
Normal-delay/low-delay
Normal-throughput/ high-throughput
Normal-reliability/high-reliability
Security: bidang 11-bit
Sangat manfaat mengamati bahwa hubungan TCP/IP ini berarti bahwa overhead müurn yang diperlukan untuk setiap unit data sebenarnya adalah 40 octet. 22
Mekanisme TCP Kita dapat mengelompokkan mekanisme-mekanisme TCP ke dalam kategori penetapan koneksi, dan pengakhiran koneksi.
Penetapan Koneksi Koneksi di dalam ICP selalu menggunakan jabat tangan tiga arah. Bila tanda SYN diset, pada intinya segmen berupa permintaan akan koneksi dan berfungsi seperti yang dijelaskan dalam Bagian 17.1. Untuk mengawali suatu koneksi, entitas mengirim SYN, SN = X, dengan X adalah nomor urut awal. Receiver meresponnya dengan SYN, SN = Y, AN = X + 1 dengan mengisi tanda SYN dan ACK. Perlu dicatat bahwa balasan menunjukkan bahwa kini receiver berharap menerima segmen yang dimulai dengan octet data X + 1 dan membalas SYN, yang menempati SN = X. Terakhir pemula merespons dengan AN = Y + 1. Bila kedua pihak mengeluarkan SYN yang bertentangan, tidak akan ada masalah: kedua pihak merespon dengan ACK. Suatu koneksi ditetapkan secara khusus oleh port sumber dan tujuan. Jadi, suatu saat hanya akan ada suatu koneksi TCP tunggal di antara sepasang port khusus. Namun, port tertentu bisa mendukung koneksi ganda, masing-masing dengan sebuah port pasangan yang berbeda.
Transfer Data Meskipun data ditransfer di dalam segmen-segmen selama koneksi transpor, transfer data secara logik dipandang terdiri dan aliran octet-octet. Karenanva, setiap octet diberi nomor modulo 232. Setiap segmen berisikan nomor urut octet pertama di dalam bidang data. Kontrol aliran diamati dengan menggunakan skema pengalokasian kredit tempat kredit diberi nomor octet dan bukannya nomor segmen, seperti yang dijelaskan di Bagian 17.1. Data disangga oleh entitas transpor baik pada pentransmisian maupun pada penerimaan. Normalnya, TCP menggunakan kebijakannya sendiri sama
23
seperti saat menyusun segrnen untuk pentransmisian dan saat pengeluaran data yang diterima ke pemakai. Tanda PUSH digunakan untuk memaksa data sehingga terakumulasi dan dikirim melalui transmitter dan dilintaskan ke receiver. Hal ini memulai fungsi endo-for-block. Pemakai bisa menetapkan blok data sebagai urgen. TCP akan menandai ujung blok didalam pointer urgen dan mengirim.kannva di dalam aliran data biasa. Pemakai penerimaan diperingatkan bahwa data urgen sedang diterima. Bila, selama pertukaran data dilakukan, segmen yang tiba bukan merupakan akibat dari koneksi yang terjadi, tanda RST diset pada segmen keluar. Contohcontoh dari situasi ini adalah duplikat SYN yang tertunda dan balasan data yang belum terkirim.
Pengakhiran Koneksi Arti yang biasa dari pemutusan koneksi adalah penutupan secara halus. Setiap pemakai TCP harus mengeluarkan sebuah primitive CLOSE. Entitas transpor menge-set bit FIN pada segmen terakhir yang dikirim keluar, yang juga memuat bagian akhir data untuk dikirim pada koneksi ini.
Pilihan Kebijakan Implementasi TCP Standar-standar TCP menyediakan spesifikasi yang tepat mengenai protokol yang digunakan di antara entitas-entitas TCP. Namun, aspek-aspek tertentu dari protokol ini menerima beberapa pilihan implementasi yang memungkinkan. Meskipun kedua implementasi yang melakukan pilihan-pilihan alternatif bisa dioperasikan, tetap ada implikasi yang mempengaruhi kinerjanya. Daerah-daerah rancangan tempat pilihan-pilihan tersebut ditetapkan adalah sebagai berikut.
Kebijakan kirim
Kebijakan penyampai
Kebijakan terima
Kebijakan transmisi ulang
Kebijakan balas 24
Kebijakan Kirim Jika tidak ada data yang didorong dan jendela pentransmisian tertutup (lihat Gambar 17.3a), entitas TCP pengiriman bebas mentransmisikan data sesuai keinginannya. Saat data dikeluarkan oleh pemakai, data-data tersebut disangga di dalam penyangga transmisi. TCP bisa menyusun segmen untuk masing-masing data batch yang disediakan oleh pemakainya atau bisa menunggu sampai datadata dalam jumlah tertentu terakumulasi sebelum segmen tersusun dan dikirirn. Kebijakan ini tergantung pada kinerjanya. Bila pentransmisian jarang dan dalam jumlah besar, hanya ada sedikit overhead dalam pengertian generasi dan pengolahan segmen. Sebaliknya, bila pentransmisian sering dan dalam jumlah kecil, maka sistem mampu menyediakan respons yang sangat cepat.
Kebijakan Penyampai Jika tidak ada Push, entitas TCP penerimaan bebas mengirim data ke pemakai sesuai keinginannya. la bisa menginim data saat masing-masing segmen yang diperintahkan diterima, atau bisa juga menyangga data dari sejumlah segmen di dalam penyangga penenimaan sebelum mengirimkannya. Kebijakan ini tergantung pada kinerjanya. Bila pengiriman tidak sering dilakukan dan dalam jumlah besar, pemakai tidak akan menerima data secepat yang diinginkan. Sebaliknya, bila pengiriman sering dilakukan dan dalam jumlah kecil, kemungkinan akan ada pengolahan yang tidak diperlukan baik pada TCP maupun dalam software pemakai, sebagaimana dengan. sejumlah interupsi sistem operasi yang sehenannya tidak perlu.
Kebijakan Terima Bila semua data tiba sesuai perintah pada suatu koneksi TCP, TCP menempatkan data di dalam penyangga penerimaan untuk dikirim ke pemakai. Namun, hal ini tetap memungkinkan bagi segmen-segmen tersebut tiba tidak sesuai dengan yang diperintahkan. Dalam hal ini, entitas TCP penerimaan memiliki dua pilihan yakni sebagai berikut.
25
Dalam-urutan: hanya menerima segmen-segmen yang tiba sesuai urutan; sedangkan segmen-segmen yang tidak sesuai urutan dibuang.
Dalam-jendela: menerima semua segmen yang berada di dalam jendela penerimaan (lihat Gambar 17.3b).
Kebijakan dalam-urutan memungkinkan implementasi yang sederhana namun membatasi fasilitas networking, seperti TCP pengiriman yang merupakan waktu habis dan mentransmisikan ulang segmen-segmen yang tidak bisa diterirna dengan baik namun dibuang karena urutan kacau ini. Selanjutnya, bila sebuah segmen tunggal hilang saat singgah, maka seluruh suburutan segmen harus ditransmisikan ulang pada saat TCP pengiriman kehabisan waktu atas segmensegmen yang hilang.
Kebijakan Transmisi Ulang TCP mempertahankan antrian segmen yang telah dikirim yang belum mendapat
balasan.
Spesifikasi
TCP
menyatakan
bahwa
TCP
akan
mentransmisikan ulang segmen bila ia gagal menerima balasan dalam waktu tertentu. Implernentasi TCP bisa menerapkan salah satu dari ketiga strategi berikut.
Yang pertama saja: mempertahankan satu pewaktu transmisi ulang untuk seluruh antrian.
Batch: mempertahankan satu pewaktu transmisi ulang untuk seluruh antrian. Bila balasan diterima, memindahkan segmen yang sesuai atau segmen-segmen dari antrian dan mereset pewaktu. Bila pewaktu berakhir, mentransmisikan ulang semen di dalam antrian dan mereset pewaktu.
Individual: mempertahankan satu pewaktu untuk setiap segmen di dalam antrian. Kebijakan yang pertama saja, efisien dalam hal lalu lintas yang dihasilkan,
karena hanya segmen-segmen yang hilanglah yang ditransmisikan ulang (atau segmen yang memiliki ACK yang hilang). Karena pewaktu untuk segmen kedua di dalam antrian belum diset sampai segmen pertama mendapat balasan, maka kemungkinan akan ada penundaan. Kebijakan individu bisa mengatasi problem mi 26
dalam hal biaya implementasinva yang lebih rumit. Sedangkan kebijakan batch juga bisa mengurangi kemungkinan penundaan panjang namun menyebabkan dilakukannya transmisi ulang yang sebenarnya tidak diperlukan. Kebijakan Balas Bila suatu segmen data tiba dan tetap berada dalam urutannya, entitas penerimaan TCP memiliki dua pilihan berkaitan dengan pewaktuan balasan.
Segera: bila data diterima, segera rnentransmisikan segmen kosong (tanpa data) yang berisikan nomor balasan yang sesuai.
Kumulatif: bila data diterima, mencatat kebutuhan akan balasan, namun menunggu segmen luar dengan data supaya mendapat balasan berkali-kali. Untuk menghindari pcnundaan yang cukup panjang, mengeset pewaktu jendela (Tabel 17.1). Bila pewaktu berakhir sebelum balasan dikirim, mentransrnisikan sehuah segmen kosong yang berisikan nomor balasan yang sesuai. Kebijakan segera tampak sederhana dan mampu memastikan entitas TCP
pengiriman henar-henar diinforrnasikan, yang membatasi transmisi ulang yang tidak perlu. Namun, kehijakan ini mengakibatkan pentransmisian segmen tambahan, yakni, segmen-segmen kosong yang hanya digunakan untuk ACK. Selanjutnya, kebijakan ini juga menambah beban pada jaringan. Amati ketika suatu entitas TCP menerima segmen dan segera rnengirimkannya ke ACK. Kemudian data di dalarn segmen tersebut dirilis ke dalam aplikasi, yang memperluas jendela penerimaan, menggerakkan segmen TCP kosong lainnya agar menyediakan kredit tambahan bagi entitas TCP pengiriman. Karena overhead potensial dari kebijakan segera, maka biasanya kebijakan kumulatiflah yang digunakan. Namun, penggunaan kebijakan ini memerlukan upaya pengolahan yang lebih banyak pada ujung penerimaan dan menyulitkan tugas estimasi penundaan round-trip lewat entitas TCP pengiriman.
17.3 KONTROL KONGESTI TCP Mekanisme kontrol aliran berbasis kredit TCP dirancang sedemikian rupa sehingga memungkinkan bagi tujuan membatasi aliran segmen dari sumber untuk 27
menghindarkan agar penyangga tidak sampai kebanjiran pada tujuan. Mekanisme kontrol aliran yang sama ini saat ini juga digunakan dalam berbagai macam cara untuk menyediakan kontrol kongesti pada internet di antara sumber dan tujuan. Kongesti, seperti yang sering disebut di buku ini, memiliki dua efek utama. Pertama, saat kongesti mulai terjadi, waktu transit di sepanjang jaringan atau internetwork meningkat. Kedua, kongesti semakin berat, paket-paket atau segmen dibuang melalui simpul-simpul internet atau jaringan. Mekanisme kontrol aliran TCP bisa digunakan untuk mengenali awamnya kongesti (dengan cara mengenali waktu penundaan yang meningkat dan segmen-segmen yang dibuang) serta untuk bereaksi dengan cara mengurangi aliran data. Bila beberapa entitas TCP beroperasi di sepanjang jaringan yang menggunakan pengurutan semacam ini, kongesti internet bisa dikurangi. Sejak publikasi RFC 793, diterapkan sejumlah teknik yang ditujukan untuk meningkatkan karakteristik kontrol kongesti TCP. Tidak satu pun dari teknik ini memperluas atau melanggar standar TCP yang asli: melainkan mewakili kebijakan-kebijakan implementasi yang berada dalam jangkauan spesifikasi TCP. Sebagian besar teknik ini dimaksudkan untuk digunakan bersama-sama dengan TCP dalam RFC 1122, kebutuhan dan host internet, sementara beberapa di antaranya ditetapkan dalam RFC 201. Teknik-teknik tersebut secara umum bisa dikelompokkan ke dalam dua kategori, yakni, manajemen pewaktu transmisi ulang dan manajemen jendela. Di bagian ini, kita membahas hal-hal terpenting dan yang paling banyak diterapkan dari teknik-teknik ini.
Manajemen Pewaktu Transmisi Ulang Saat kondisi internet atau jaringan berubah, pewaktu transmisi ulang statis kemungkinan tampak terlalu panjang atau bahkan terlalu singkat. Karenanya, secara virtual semua implementasi TCP berupaya memperkirakan penundaan round-trip yang ada dengan cara mengamati pola penundaan untuk segmensegmen yang ada, dan kemudian mernasang pewaktu pada nilai yang lebih besar dari penundaan round-trip yang diperkirakan.
28
Rata-rata Sederhana Satu pendekatan sederhana yang dilakukan adalah dengan membuat rata-rata waktu roud-trip yang diamati pada sejumlah segmen. Bila rata-rata ini mampu memprediksikan penundaan round-trip secara akurat, maka pewaktu transmisi ulang yang diperoleh akan menunjukkan kinerja yang baik. Metode perkiraan sederhana ini bisa dinyatakan sebagai berikut.
Keterangan : RTT (i) adalah waktu round-trip yang diamati untuk segmen yang ditransmisikan ke-i , dan ARTT (K) adalah rata-rata waktu round-trip untuk segmen K pertama. Pernyataan ini bisa ditulis lagi sebagai berikut :
Dengan rumus ini, tidak perlu menghitung kembali seluruh penjumlahan setiap saat.
Rata-rata Eksponensial Perlu dicatat bahwa masing-masing ketentuan di dalam penjumlahan ini memiliki bobot yang sama, masing-masing ketentuan dikalikan dengan konstanta yang sama 1/(K + 1). Biasanya, kita lebih suka memberi bobot yang lebih besar untuk pengaruh-pengaruh terbaru karena mereka tampak lebih mampu merefleksikan perilaku di masa datang. Teknik yang umum digunakan untuk memprediksikan nilai berikutnya yang berdasarkan atas rangkaian kejadian dari nilai-nilai sebelumnya, dan teknik yang ditetapkan dalam RFC 793, adalah ratarata eksponen sebagai berikut.
Keterangan : SRTT (K) disebut estimasi round-trip halus dan kita tetapkan SRTT(0) = 0. Bandingkan dengan Persamaan 17.2. dengan menggunakan nilai 29
konstanta sebesar α (0 < α < 1), yang tergantung pada pengamatan lama, kita berada dalam keadaan saat semua nilai-nilai lama harus dipertimbangkan, namun nilai-nilai yang terlalu lama mempunyai bobot yang sedikit. Untuk lebih jelasnya, amati perluasan Persamaan (17.3) berikut.
Karena baik α maupun (1- α) kurang dari satu, setiap ketentuan dalam persamaanpersamaan sebelumnya lebih kecil. Sebagai contoh, untuk α – 0,8, perluasannya ialah
Urutan pengamatan yang kecil juga dimasukkan dalam rata-rata tersebut. Semakin kecil nilai α, semakin besar nilai bobot diberikan ke pengamatan yang baru. Untuk α = 0,5, secara virtual semua bobot diberikan ke empat atau lima pengamatan baru, mengingat untuk α = 0,875, rata-ratanya menyebar secara efektif ke sepuluh atau lebih dari pengamatan yang terbaru. Keuntungan dengan menggunakan nilai yang lebih kecil dari α adalah rata-ratanya segera merefleksikan perubahan yang sangat cepat dalam hal jumlah yang diamati. Sedangkan kekurangannya adalah bila terdapat perbedaan kecil dalam nilai jumlah yang diamati dan kemudian menurun terhadap nilai-nilai konstanta relatif, penggunaan nilai yang lebih kecil dari α akan menghasilkan rata-rata yang berubah secara mengejutkan. Gambar 17.12 membandingkan rata-rata sederhana dengan rata-rata eksponensial (untuk dua nilai α yang berbeda). Di bagian a dari gambar tersebut, nilai yang diamati dimulai dari 1, kemudian secara bertahap ke nilai 10, dan tetap pada nilai tersebut. Pada bagian b dari gambar tersebut, nilai yang diamati dimulai dari 20, kemudian secara bertahap menurun ke nilai 10, dan tetap pada nilai tersebut. Perlu dicatat bahwa rata-rata eksponensial mengakibatkan perubahanperubahan dalam memproses perilaku lebih cepat daripada melakukan rata-rata sederhana dan bahwa nilai yang lebih kecil daripada α menghasilkan reaksi yang lebih cepat terhadap perubahan nilai yang diamati. 30
Persamaan (17.3) digunakan dalam RFC 793 untuk memperkirakan waktu roundtrip. Seperti yang telah disebutkan, pewaktu transmisi ulang harus dipasang pada nilai yang lebih besar daripada waktu round-trip yang diestimasikan. Salah satu kemungkinannya adalah dengan menggunakan nilai konstanta berikut.
Keterangan: RIO adalah pewaktu transmisi uang (disebut juga waktu habis transmisi ulang) dan
adalah konstanta. Kekurangannya ialah bahwa
sebanding dengan SRTT. Untuk nilai yang lebih besar dari SRTT,
tidak
relatif kecil
dan fluktuasi dalam RTT aktual akan menyebabkan transmisi ulang yang sebenarnya tidak diperlukan. Untuk nilai yang lebih kecil dari SRTT,
relatif
besar dan menyebabkan penundaan yang tidak diperlukan dalam pentransmisian ulang segmen-segmen rang hilang. Karenanya, RFC 793 menetapkan penggunaan pewaktu yang nilainya sebanding dengan SRTT, di dalam batas-batas berikut.
Keterangan: UBOUND dan LBOUND adalah untuk nilai batas atas dan batas bawah yang dipilih lebih dulu untuk nilai pewaktu dan
adalah konstanta. RFC
793 tidak merekomendasikan nilai-nilai khusus namun mendaftar α di antara 0,8 dan 0,9 dan 1 diantara 1,3 dan 2,0 sebagai "nilai-nilai contoh".
Estimasi Variasi RTT (Algoritma Jacobson) Teknik yang ditetapkan dalam standar ICP, dan digambarkan dalam Persamaan (17.3) dan (17.4), memungkinkan entitas TCP beradaptasi dengan perubahan-perubahan dalam waktu round-trip. Namun, tidak mencakup situasi saat waktu round-trip menunjukkan variasi yang relatif tinggi. [ZHAN86] menunjuk tiga sumber tingkat variasi yang tinggi. 1. Bila rate data pada koneksi TCP relatif rendah, maka penundaan transmisi akan relatif besar dibandingkan dengan waktu perambatan dan variasi penundaan yang berkaitan dengan variasi ukuran datagram IP akan 31
menjadi signifikan. Jadi, estimator SRIT sangat dipengaruhi oleh karakteristik-karakteristik yang menjadi sifat data dan bukan jaringan. 2. Kondisi dan muatan lalu lintas internet bisa berubah secara tiba-tiba berkaitan dengan lalu-lintas dari sumber-sumber lainnya, menyebabkan perubahan-perubahan mendadak dalam RTT. 3. Entitas TCP yang sebanding mungkin tidak membalas masing-masing segmen dengan segera yang disebabkan karena penundaan pengolahannya dan karena menjalankan haknya untuk balasan-balasan kumulatif, Spesifikasi TCP asli berupaya menghitung variabilitas ini dengan cara mengalikan estimator RIT dengan faktor konstanta, seperti yang ditunjukkan dalam Persamaan (17.4). Di lingkungan yang stabil, dengan variasi RTT yang rendah, rumus ini akan memberi nilai RTO tinggi yang tidak diperlukan, sedangkan di lingkungan yang tidak stabil, nilai
= 2 keniungkinan tidak cukup
memadai untuk menghindari transmisi ulang yang tidak perlu. Pendekatan yang lebih efektif adalah dengan membuat estimasi variabilitas dalam nilai-nilai RII dan dengan menggunakannya sebagai input di dalam penghitungan RIO. Pengukuran variabilitas yang mudah digunakan untuk membuat estimasi adalah deviasi nilai tengah (mean deviation), yang ditetapkan sebagai Konstanta yang sama 1/( K+1) lebih memberi bobot yang lebih besar untuk pengaruh yang lebih baru. Sama halnya dalam RCF 793 definisi persamaan (17.3) SRTT adalah estimasi halus secara eksponesial mengenai RTT, dengan ( 1-g ) ekuivalen terhadap a.(17.4),perkalian deviasi nilai tangah yang diperkirakan ditambahkan ke SRTT untuk pembentuk pewaktu transmisi ulang. Berdasarkan atas eksperimen pewaktunya,Jacobson mengajukan nilai-nilai berikut ini untuk konstanta dalam karya tulisnya [ JACO88] g = 1/8 = 0,125 h = ¼ = 0,25 f=2
32
Gambar 17.3 menggambarkan penggunaan persamaan 17.5 pada susunan data yang sama seperti yang digunakan dalam gambar 17.12. Begitu waktu kedatangan stabil, estimasi variasi SDEV menurun. Nilai RTO untuk f = 2 dan f = 4 benarbenar konservatif selama RTT berubah,namun kemudian mulai bertemu dengan RTT bila ia stabil.
Backoff RTO Eksponesial Kebijakan yang lebih baik menyatakan bahwa sumber TCP meningkatkan RTO nya setiap segmen yang sama ditransmisikan ulang disebut backoff . Teknik sederhana dalam menerapkan RTO backoff adalah dengan mengalikan RTO untuk segmen dengan nilai konstanta untuk setiap transmisi ulang. RTO = q x RTO Persamaan diatas mengakibatkan RTO berkembang secara eksponesial dengan setiap transmisi ulang. Nilai q yang paling sering digunakan adalah 2.
Algoritma Karn Bila tidak terdapat segmen yang harus ditransmisikan ulang ,proseas pemeriksaanuntuk algoritma Jacobson tampak jelas.RTT untuk setiap segmen bisa dimasukkan ke dalam perhitungan. Akan tetapi anggap saja waktu segmen habis dan harus ditransmisikan ulang. Bila balasan diterima secara berturut-turut, kemungkinan yang terjadi adalah sebagai berikut. 1. Ini merupakan ACK untuk pentransmisian pertama segmen. Dalam hal ini, RTT lebih panjang daripada yang diharapkan namun merupakan refleksi kondisi jaringan yang akurat. 2. Ini merupakan ACK untuk pentransmisian kedua.
Manajemen Jendela Sebagai tambahan teknik untuk meningkatkan keefektifan pewaktu transmisi ulang, ditetapkan sejumlah pendekatan untuk menangani pengiriman jendela.
33
Permulaan yang Pelan Semakin besar pengiriman jendela yang digunakan dalam TCP, semakin banyak segmen sumber TCP bisa melakukan pengiriman sebelum menunggu balasan. Hal inin menimbulkan masalah bila kineksi ditetapkan untuk pertama kalinya, karena entitas TCP bebas membuang seluruh jendela data yang ada pada internet. Suatu strategi yang bisa dilakukan adalah untuk mengirim TCP agar mulai melakukan pengiriman dari beberapa jendela yang relatif besar namun bukan ukuran jendela maksimum, berharap memperkirakan ukuran jendela yang pada akhirnya disediakan oleh koneksi tersebut. Jacobson [ JACO88 ] merekomendasikan suatu prosedur yang disebut permulaan yang pelan-pelan. TCP yang menggunakan jendela kongesti, lebih sering diukur dalam segmen-segmen dibanding dalam octed.
Pengukuran Jendela Dinamik untuk Kongesti Algoritma permulaan yang pelan ( slow start ) dianggap sangat efektif untuk mengawali suatu koneksi. Algoritma tersebut juga memungkinkan pengirim TCP menentukan ukuran jendela yang sesuai dengan cepat untuk koneksi yang dimaksud.
UDP Sebagai tambahan untuk TCP, terdapat satu protokol level transpor lainnya yang umum digunakan sebagai bagian dari suite protokol TCP/IP yaitu User Datagram Protokol ( UDP ), yang diterapkan dalam RFC 768. UDP menyediakan layanan nirkoneksi untuk prosedur-prosedur level aplikasi. Jadi UDP adalah layanan yang tidak andal karena perlindungan duplikasi dan pengiriman tidak terjamin. Namun, UDP ini mampu mengurangi overhead protokol dan sesuai untuk beberapa kasus tertentu. Contoh penggunaan UDP adalah dalam konteks manajemen jaringan, seperti yang digambarkan dalam Bab 19.
34
BAB 21 KEAMANAN JARINGAN
18.1 PERSYARATAN KEAMANAN DAN SERANGAN Keamanan jaringan dan komputer memiliki tiga syarat utama, yaitu :
Kerahasiaan : agar data-data hanya bisa diakses dan dibaca oleh pihakpihak yang memang memiliki otorisasi terhadap data-data tersebut.
Integritas : agar data-data bisa dimodifikasikan hanya oleh pihak-pihak yang berwenang.
Ketersediaan : agar data bisa tersedia untuk pihak-pihak yang berwenang. Kategori serangan terhadap pengamanan jaringan yang utama terdapat
2 macam serangan, yaitu : 1. Serangan Pasif Serangan pasif terjadi dalam hal eavesdropping atau memantau pentransmisian. Tujuan penyerang adalah agar bisa memperolah informasi yang sedang ditransmisikan. Dua jenis serangan pasif adalah membuka isi pesan dan analisis lalu lintas. Serangan pasif sangat sulit dideteksi karena tidak melibatkan pengubahan data. 2. Serangan Aktif Serangan aktif melibatkan beberapa modifikasi aliran data atau penciptaan aliran palsu yang bisa dibagi menjadi empat kategori, yaitu penyamaran, jawaban, modifikasi pesan, dan penolakan layanan. “Penyamaran” dilakukan bila satu entitas berpura-pura sebagai entitas yang berbeda. “Jawaban” melibatkan penangkapan secara pasif suatu unit data berikut transmisi ulangnya berturut-turut untuk mendapatkan efek yang tidak terotorisasi. “Modifikasi pesan” berarti beberapa bagian dari pesan asli diubah, atau pesan-pesan tersebut ditunda atau diubah,
35
agar menghasilkan efek yang tidak terotorisasi. Serangan “penolakan layanan”, mencegah atau menunjukkan penggunaan normal atau manajemen fasilitas-fasilitas komunikasi. Serangan ini kemungkinan memiliki tujuan tertentu, misalnya entitas bisa menahan semua pesan yang menuju secara langsung ke suatu tujuan tertentu (misalnya layanan audit rahasia). Bentuk penolakan layanan lainnya adalah gangguan jaringan secara keseluruhan, baik dengan cara melumpuhkan jaringan atau memenuhi jaringan dengan pesan-pesan sehingga mengurangi kinerjanya.
18.2 KERAHASIAAN DENGAN ENKRIPSI KONVENSIONAL Cara umum untuk menjaga kerahasiaan data-data yang ditransmisikan yaitu dengan enkripsi konvensional. 1. Enkripsi Konvensional Enkripsi konvensional juga disebut sebagai enkripsi simetrik atau enkripsi kunci tunggal. Enkripsi konvensional memiliki lima unsur utama, yaitu : a. Teks asli : merupakan data atau pesan asli yang dimasukkan ke dalam algoritma sebagai input. b. Algoritma enkripsi : menyediakan berbagai macam substitusi dan transformasi pada teks asli. c. Kunci rahasia : merupakan input bagi algoritma enkripsi. Substitusi dan transformasi eksak yang ditampilkan oleh algoritma tergantung pada kunci. d. Teks rahasia : adalah pesan yang dihasilkan sebagai output. Tergantung pada teks asli dan kunci rahasia. e. Algoritma dekripsi : merupakan kebalikan dari algoritma enkripsi. Menggunakan teks rahasia dan kunci rahasia serta menghasilkan teks asli. Ada dua persyaratan untuk mengamankan penggunaan enkripsi konvensional : 36
a. Kita membutuhkan algoritma enkripsi yang kuat. b. Pengirim dan penerima harus mampu mendapatkan salinan kunci rahasia dengan diam-diam dan harus menyimpan kunci rahasia tersebut. Ada dua pendekatan umum untuk menyerang skema enkripsi konvensional. Serangan pertama disebut “pemecahan rahasia” dan serangan kedua disebut “brute force” (paksaan).
2. Algoritma Enkripsi Algoritma enkripsi konvensional yang paling umum digunakan ialah blok rahasia. Suatu blok rahasia memproses teks asli masuk ke dalam blok-blok berukuran tertentu dan menghasilkan suatu blok teks rahasia dengan ukuran yang setara untuk masing-masing blok teks asli. Yang terpenting adalah keduanya merupakan blok rahasia, yaitu SED dan AEDT.
Standar Enkripsi Data (SED) Skema enkripsi yang paling banyak digunakan ditetapkan dalam Standar Enkripsi Data (SED) yang diadopsi pada tahun 1977 oleh National Bureau Standards, kini Natioanal Institute of Standards and Technology (NIST), sebagai Federal Information Processing Standard 46 (FIPS PUB 46). Pada tahun 1994, NIST menetapkan SED untuk pemakaian federal untuk lima tahun lainnya dalam FIPS PUB 46-2. Algoritma ini sendiri disebut juga Algoritma Enkripsi Data (AED).
Kekuatan SED Sampai
akhir
tahun
1970-an,
para
pakar
telah
mengingatkan bahwa masa-masa SED sebagai algoritma aman yang diberi nomor tinggal masalah waktu saja sampai mampu meningkatkan kecepatan processor dan menurunkan biaya hardware yang dibuat sesederhana mungkin untuk mendongkrak SED dengan cepat. Hasil akhirnya terwujud pada bulan Juli 1998, 37
Electronic Frontier Foundation (EFF) mengumumkan bahwa ia telah menemukan SED baru dengan memakai mesin ”kraker SED”. Serangan itu hanya berlangsung selama kurang dari tiga hari. EFF telah mempublikasikan suatu gambaran yang mendetail mengenai mesin tersebut, yang memungkinkan bagi pihak lain membangun krakernya sendiri (EFF98). Dan tentunya, harga hardware semakin menurun sedangkan kecepatan processor meningkat, membuat SED tidak cukup berharga. Untungnya ada sejumlah alternatif di pasaran, yaitu : AED Triple (AEDT), pertama-tama diajukan oleh Tuchman dan pertama kali distandarkan untuk digunakan dalam aplikasiaplikasi finansial standar ANSI, X9.17 pada tahun 1985. 3. Lokasi Perangkat Enkripsi Pendekatan yang paling canggih dan umum untuk menghadapi ancaman terhadap pengamanan jaringan ialah enskripsi. Dengan menggunakan enskripsi, kita perlu memutuskan apa yang harus dienskripsikan dan di mana titik enkripsi yang harus ditempatkan. Terdapat dua alternatif mendasar yakni : a. Enkripsi Jalur : setiap jalur komunikasi yang mudah diserang dilengkapi dengan suatu perangkat enskripsi pada kedua ujungnya. Kekurangan dari pendekatan ini adalah pesan harus dideskripsikan setiap saat pesan tersebut memasuki paket switch. b. Enkripsi dari ujung ke ujung : proses enskripsi dilakukan pada kedua ujung sistem. Pendekatan ini tampaknya mampu mengamankan transmisi dari serangan terhadap jalur-jalur atau switch jaringan. 4. Distribusi Kunci Agar enkripsi konvensional bisa bekerja, dua pihak yang mengamankan proses pertukaran harus memiliki kunci yang sama, dan kunci tersebut harus dilindungi agar tidak diakses oleh orang lain. Kekuatan sistem pembacaan sandi tersebut adalah dengan teknik
38
distribusi kunci, yaitu suatu istilah yang menunjuk pada cara pengiriman sebuah kunci kepada kedua pihak yang ingin melakukan pertukaran data tanpa memperbolehkan pihak lain mengetahui kunci tersebut. Distribusi kunci bisa dilakukan melalui beberapa cara, yaitu : a. Suatu kunci yang dipilih oleh A dapat dikirim secara fisik kepada B. b. Yaitu dengan bantuan pihak ketiga, ia memilih kunci dan secara fisik bisa mengirimkannya ke A dan B. c. Bila A dan B sudah dan masih menggunakan kunci, salah satu pihak bisa mentransmisikan kunci baru ke pihak lainnya, yang dienkripsikan dengan menggunakan kunci lama. d. Bila
A
dan
B
masing-masing
memiliki
koneksi
yang
dienkripsikan ke pihak C, C dapat mengirim sebuah kunci pada jalur yang dienkripsikan ke A dan B.
5. Pelapisan lalu Lintas Dengan menggunakan enkripsi jalur, header paket dienkripsikan, mengurangi peluang akan analisis lalu lintas. Namun, dalam kondisi seperti itu, masih memungkinkan bagi penyerang menilai jumlah lalu lintas pada jaringan dan mengamati jumlah lalu lintas yang memasuki dan meninggalkan setiap ujung sistem. Tindakan balasan yang efektif untu serangan ini adalah pelapisan lalu lintas. Pelapisan lalu lintas adalah suatu fungsi yang menghasilkan teks rahasia secara terus menerus, bahkan bila tidak ada teks asli.
18.3 PEMBUKTIAN KEASLIAN PESAN DAN FUNGSI HASH Enkripsi melindungi terhadap serangan pasif (eavesdropping). Suatu persyaratan yang berbeda adalah untuk melindungi terhadap serangan aktif (pemalsuan data dan transaksi). Perlindungan terhadap serangan seperti ini dikenal sebagai pembuktian keaslian pesan.
39
1. Pendekatan untuk Pembuktian Keaslian Pesan Suatu pesan, file, dokumen, atau sekumpulan data lainnya dikatakan otentik bila asli dan datang dari sumber yang dinyatakannya. Keaslian pesan merupakan prosedur yang memungkinkan pihak-pihak yang berkomunikasi melakukan verifikasi bahwa pesan-pesan yang diterima bersifat asli. a. Pembuktian Keaslian Menggunakan Enkripsi Konvensional. Bila kita berasumsi bahwa hanya pengirim dan penerima yang berbagi sebuah kunci sebagaimana mestinya, maka hanya pengirim aslilah yang mampu melakukan enkripsi dengan baik terhadap pesan untuk pihak lainnya. b. Pembuktian Keaslian Pesan Tanpa Enkripsi Pesan. Di bagian ini, kita mengamati beberapa pendekatan untuk pembuktian keaslian pesan yang tidak tergantung pada enkripsi. Dalam keseluruhan pendekatan ini, tanda pembuktian keaslian dihasilkan dan dilampirkan ke setiap pesan untuk transmisi. Pesan itu sendiri tidak dienkripsikan dan bisa dibaca pada tujuan yang terpisah dari fungsi pembuktian keaslian yang ada di tujuan. DAV189 menyarankan tiga situasi saat pembuktian keaslian pesan tanpa kerahasiaan bisa dipilih yaitu : 1) Terdapat sejumlah aplikasi bagi pesan yang sama disiarkan ke sejumlah tujuan. 2) Skenario yang memungkinkan lainnya ialah pertukaran ketika salah satu pihak memiliki muatan yang penuh dan tidak mampu memberi waktu untuk mendekripsikan semua pesan yang masuk. 3) Pembuktian keaslian dari suatu program komputer di dalam teks asli merupakan layanan yang menarik. c. Kode Pembuktian Keaslian Pesan Adalah
satu
teknik
pembuktian
keaslian
yang
melibatkan
penggunaan kunci rahasia untuk menggerakkan blok data berukuran kecil. Bila kita mengasumsikan bahwa hanya penerima dan pengirim
40
saja yang mengetahui identitas kunci rahasia, dan bila kode yang diterima sesuai dengan kode yang dikalkulasi, maka prosesnya adalah sebagai berikut : 1) Penerima diyakinkan bahwa pesan tidak diubah. 2) Penerima diyakinkan bahwa pesan berasal dari pengirim yang terduga. 3) Bila pesan mencakup nomor urut, maka penerima bisa diyakinkan bahwa nomornya sesuai, karena penyerang tidak berhasil mengganti nomor urut. d. Fungsi One Way Hash Adalah variasi pada kode keaslian pesan yang telah menerima banyak perhatian baru-baru ini. Dalam fungsi one way hash, ada dua cara dalam membuktikan keaslian suatu pesan, yaitu : 1) Intisari
pesan
dapat
dienkripsikan
dengan
enkripsi
konvensional. 2) Pesan juga dapat dienkripsikan dengan menggunakan enkripsi kunci umum. Pendekatan kunci umum memiliki dua kelebihan,
yakni
sebagaimana pendistribusian
menyediakan
keaslian kunci
pesan bagi
tanda dan
tangan
tidak
pihak-pihak
digital
memerlukan yang
sedang
berkomunikasi. 2. Fungsi Hash yang Aman a. Syarat-syarat Fungsi Hash : 1) H bisa diterapkan untuk blok-blok data dengan bermacammacam ukuran. 2) H menghasilkan output dengan panjang tertentu. 3) H(x) relatif mudah menghitung x tertentu, sehingga implementasi hardware dan software mudah dilakukan. 4) Untuk kode h tertentu, menurut perhitungan tidak mudah menemukan x seperti pada H(x) = h.
41
5) Untuk blok x tertentu, menurut perhitungan tidak mudah menemukan y ≠ x dengan H(y) = H(x). 6) Menurut perhitungan tidak mudah menemukan sepasang (x,y) seperti pada H(y) = H(x). b. Fungsi Hash yang Aman SHA-1. Algoritma hash yang aman dikembangkan oleh National Institute of Standards and Technology (NIST) dan diterbitkan sebagai Federal Information Processing Standard (FIPS PUB 18) pada tahun 1995 dan pada umumnya disebut SHA-1. Input untuk algoritma ini adalah pesan dengan panjang lebih kecil daripada 2 pangkat 64 bit dan menghasilkan sebuah perpendekan pesan 160 bit. Inputnya diproses dalam blok-blok 512 bit. Berikut langkah-langkah
pemprosesan
pesan
untuk
menghasilkan
perpendekan pesan, yakni : Langkah 1 : bit-bit pelapisan tambahan. Langkah 2 : panjang tambahan. Langkah 3 : memulai penyangga MD. Langkah 4 : proses pesan dalam blok 512 bit (16 word). Langkah 5 : output.
18.4 ENKRIPSI KUNCI UMUM DAN TANDA TANGAN DIGITAL Enkripsi kunci umum memiliki kegunaan dalam pembuktian keaslian pesan dan distribusi kunci.
1. Enkripsi Kunci Umum. Pertama kali diajukan secara besar-besaran oleh Diffie dan Hellman pada tahun 1976 ( DIFF76 ). Untuk satu hal tertentu, algoritma kunci umum lebih didasarkan atas fungsi matematis daripada atas operasi sederhana pada pola-pola bit. Lebih penting lagi, pembacaan sandi kunci
42
umum bersifat asimetris, melibatkan penggunaan dua kunci terpisah, bertolak belakang dengan enkripsi konvensional simetris yang hanya menggunakan satu kunci. Enkripsi kunci umum memiliki enam unsur, yakni : a. Teks asli : pesan atau data yang mampu dibaca yang dimasukkan ke dalam algoritma sebagai input. b. Algoritma enkripsi : menyediakan berbagai macam transformasi pada teks asli. c. Kunci umum dan kunci pribadi : transformasi eksak yang ditampilkan oleh algoritma enkripsi tergantung pada kunci umum atau kunci pribadi yang tersedia sebagai input. d. Teks rahasia : untuk sebuah pesan tertentu, dua kunci yang berlainan akan menghasilkan dua teks rahasia yang berbeda pula. e. Algoritma dekripsi : algoritma yang menerima teks rahasia dan kunci yang sesuai serta menghasilkan teks asli yang asli. Langkah-langkah pentingnya adalah sebagai berikut : a. Setiap pemakai menggerakkan sepasang kunci yang digunakan untuk enkripsi dan dekripsi pesan. b. Setiap pemakai menempatkan salah satu dari dua kunci di dalam rekaman umum atau file yang bisa diakses lainnya. c. Bila si A ingin mengirim sebuah pesan pribadi kepada si B, maka si A mengenkripsikan pesan tersebut dengan menggunakan kunci umum milik si B. d. Bila si B menerima pesan tersebut, ia mendekripsikannya dengan menggunakan kunci pribadinya. 2. Tanda Tangan Digital Seluruh pesan yang dienkripsikan bertindak sebagai tanda tangan (digital signature), sehingga pesan dibuktikan keasliannya menurut ketentuan sumber dan menurut syarat-syarat integritas.
43
3. Algoritma Enkripsi Kunci Umum RSA Salah satu skema kunci umum yang pertama dikembangkan pada tahun 1977 oleh Ron Rivest, Adi Shamir, dan Len Adleman di MIT dan pertama kali dipublikasikan pada tahun 1978 (RIVE78). Skema RSA sejak hari itu dianggap sebagai satu-satunya pendekatan terhadap enkripsi kunci umum yang paling banyak diimplementasikan dan diterima. RSA adalah suatu blok sandi rahasia tempat teks asli dan teks rahasia merupakan bilangan bulat antara 0 dan n-1 untuk beberapa n. Enkripsi dan deskripsi berasal dari beberapa bentuk berikut ini, untuk beberapa blok teks asli M dan blok teks rahasia C. C = Me mod n M = Cd mod n = (Me)d mod n = Med mod n Baik pengirim maupun penerima harus mengetahui nilai n dan e,dan hanya penerima saja yang mengetahui nilai d. Ini merupakan algoritma enkripsi kunci umum dengan kunci umum sebesar KU = {e, n} dan kunci khusus sebesar KR = {d, n}. Agar algoritma ini bisa memenuhi syarat sebagai enkripsi kunci umum yang baik, maka harus memenuhi ketentuan sebagai berikut : Pembangkitan Kunci
Memilih p, q
p dan q keduanya prima
Menghitung n = p x q Enkripsi Menghitung ɸ (n) = (p - 1) (q - 1) Memilih Teks aslibilangan bulat e Teks Rahasia Menghitung d
gcd(ɸ(n),e) = 1; 1 < e ˂ ɸ(n) M
a. Kemungkinan menemukan nilai e, d, n sedemikian rupa sehingga Kunci umum Teks asli ed
KU C = {e, n}
Kunci pribadi Teks rahasia
d n} KR M ==C{d, (mod n)
M =M
b. Relatif mudah menghitung Me dan Cd untuk semua nilai M < n. c. Tidak mudah menentukan d, yang diberi e dan n.
44
4. Manajemen Kunci Bagaimana cara mendistribusikan kunci-kunci rahasia dengan aman adalah problem tersulit bagi enkripsi konvensional. Problem ini dipecahkan dengan enkripsi kunci umum karena pada kenyataannya memang kunci pribadi tidak pernah didistribusikan. Misalkan Bob ingin berkomunikasi dengan Alice, Bob dapat melakukan hal-hal sebagai berikut : a. Menyiapkan suatu pesan b. Mengenkripsi
pesan
tersebut
dengan
menggunakan
enkripsi
konvensional dengan kunci sesi sekali pakai konvensional. c. Mengenkripsi kunci sesi dengan menggunakan enkripsi kunci umum dengan kunci umum milik Alice. d. Melampirkan
kunci
sesi
yang
dienkripsi
pada
pesan
dan
mengirimkankannya ke Alice. Hanya Alice saja yang mampu mendekripsi kunci sesi dan karenanya memperoleh pesan yang asli kembali. Namun, tampak bahwa kita telah mengganti stau problem dengan problem lainnya. Kunci pribadi milik Alice aman karena ia tidak perlu mengungkapkannya, namun, Bob harus yakin bahwa kunci umum dengan nama Alice yang tertulis benar-benar sama dengan kunci umum Alice. Orang lain dapat menyiarkan suatu kunci umum dan berkata bahwa itu adalah kunci umum milik Alice. Cara umum untuk mengatasinya problem ini bisa dengan berbagai macam cara, menggunakan enkripsi kunci umum untuk membuktikan keaslian kunci umum tersebut.
18.5 PENGAMANAN IPv4 DAN IPv6 Pada tahun 1994, IAB (Internet Architecture Board) mengeluarkan sebuah laporan berjudul Security in the Internet Architecture (RFC 1636). Laporan tersebut menyatakan mufakat umum bahwa internet membutuhkan 45
pengamanan yang lebih banyak dan lebih baik, dan menetapkan daerah kunci untuk mekanisme pengamanan. Jenis serangan yang paling serius mencakup pengubahan IP, saat pengacau menciptakan paket-paket dengan alamat IP yang salah dan mengeksploitasikan
aplikasi-aplikasi
yang
menggunakan
pembuktian
keaslian berbasis alamat IP; dan berbagai macam bentuk eavesdropping dan pemalsuan
packet,
tempat
penyerang
membaca
informasi
yang
ditransmisikan, termasuk informasi logon dan isi basis data. 1. Aplikasi-aplikasi IPSec IPSec menyediakan kapabilitas mengamankan komunikasi di sepanjang LAN, WAN swasta dan umum, dan internet. Contoh penggunaannya mencakup hal-hal berikut : a. mengamankan konektivitas kantor cabang di internet b. mengamankan akses remote di internet c. menetapkan konektivitas ekstranet dan intranet dengan para partner d. meningkatkan pengamanan perdagangan elektronik 2. Jangkauan IPSec IPSec menyediakan tiga fasilitas utama, yaitu : a. Fungsi
pembuktian
keaslian
saja
yang
disebut
sebagai
Authentication Header (AH) b. Suatu kombinasi fungsi pembuktian keaslian/enkripsi yang dinamakan Encapsulating Security Payload (ESP) c. Fungsi pertukaran kunci Sebagian menggunakan memungkinkan
besar ESP
implementasinya daripada
dilakukannya
AH.
tampaknya Fungsi
pertukaran
kunci
lebih
pertukaran secara
banyak kunci manual
sebagaimana dalam skema otomatis. Spesifikasi IPSec cukup kompleks dan meliputi sejumlah dokumen. Yang terpenting dalam hal ini, diterbitkan pada bulan November 1998, yaitu RFC 2401, 2402, 2406, dan 2408. 3. Asosiasi Pengaman
46
Asosiasi pengaman secara khusus diidentifikasikan melalui tiga parameter : a. Indeks Parameter Keamanan (IPK) b. Alamat tujuan IP c. Pengenal protokol keamanan Asosiasi pengamanan ditetapkan melalui parameter-parameter berikut : a. Pencacah nomor urut b. Limpahan pencacah urut c. Jendela antibalasan d. Informasi AH e. Informasi ESP f. Asosiasi umur hidup pengaman ini g. Mode protokol IPSec h. MTU Path
4. Model Transpor dan Terowongan a. Model Transpor Model transpor menyediakan perlindungan utamanya untuk protokol-protokol pada lapisan teratas. Maksudnya, perlindungan model transpor sampai dengan payload paket IP. ESP dalam model transpor mengenkripsikan dan bisa memilih melakukan pembuktian keaslian payload IP namun tidak untuk header IP. AH dalam model transpor membuktikan keaslian payload IP dan bagian terpilih dari header IP. b. Model Terowongan Model terowongan menyediakan perlindungan terhadap paket IP secara keseluruhan. Model terowongan digunakan bila salah satu atau kedua ujung SA berupa keamanan gateway, seperti firewall atau router yang menerapkan IPSec.
47
ESP dalam model terowongan mengenkripsikan dan bisa memilih melakukan pembuktian keaslian seluruh paket IP dalam, termasuk header IP dalam. AH dalam model terowongan membuktikan keaslian seluruh paket IP dalam dan bagian tertentu dari header IP luar.
5. Header Pembuktian Keaslian Header pembuktian keaslian menampilkan dukungan akan integritas data dan keaslian paket-paket IP. Pembuktian keaslian didasarkan atas penggunaan Kode Pembuktian Keaslian Pesan (KPKP). Karenanya dua pihak harus saling berbagi kunci rahasia.
Header pembuktian keaslian terdiri dari bidang-bidang berikut ini : a. Header berikut (8 bit) b. Panjang payload (8 bit) c. Dicadangkan (16 bit) d. Indeks parameter keamanan (32 bit) e. Nomor urut (32 bit) f. Data keamanan (variabel) Bidang data pembuktian keaslian dikalkulasikan melalui beberapa hal berikut: a. Bidang header IP baik yang tidak berubah saat transit, maupun yang bisa diperkirakan nilainya pada saat kedatangan pada ujung AH SA. b. Header AH lain dengan bidang data pembuktian keaslian. c. Seluruh data protokol pada level teratas, yang diasumsikan tetap saat transit.
6. Encapsulating Security Payload Encapsulating Security Payload menyediakan layanan yang bersifat rahasia, termasuk kerahasiaan isi pesan dan kerahasiaan aliran lalu lintas terbatas. Sebagai suatu bentuk pilihan, ESP juga dapat menyediakan layanan pembuktian keaslian yang sama seperti AH.
48
Format paket ESP memuat bidang-bidang sebagai berikut : a. Indeks parameter keamanan (32 bit) b. Nomor urut (32 bit) c. Data payload (variabel) d. Pelapisan (0-255 byte) e. Panjang pelapisan (8 bit) f. Header berikut (8 bit) g. Data pembuktian keaslian (variabel)
7. Manajemen Kunci Bagian manajemen kunci dari IPSec melibatkan penentuan dan distribusi kunci rahasia. Dokumen arsitektur IPSec menyatakan dukungan terhadap dua tipe manajemen kunci, yaitu manual dan otomatis. Protokol manajemen kunci otomatis default untuk IPSec disebut sebagai AKIPMK/Oakley, yang terdiri dari unsur-unsur berikut : a. Protokol determinasi kunci Oakley b. Asosiasi Keamanan Internet dan Protokol Manajemen Kunci (AKIPMK). c.
BAB 23 APLIKASI-APLIKASI TERDISTRIBUSI
19.1 Abstract Syntax Notation One (ASN.1) ASN.1 adalah suatu bahasa dan notasi penting yang digunakan dalam beberapa standar networking level atas. ASN.1 biasa digunakan untuk menentukan format protokol serta semantik dan struktur basis data. ASN.1 paling banyak digunakan dalam pengembangan standar-standar yang berkaitan dengan OSI dan TPC/IP. ASN.1 digunakan untuk menentukanformat protocol data unit (PDU), gambaran informasi terdistribusi, dan operasi-operasi yang ditampilakan pada data-data yang ditransmisikan.
49
MIME
BGP
FTP
HTTP
SMTP
TELNET
SNMP
TPC
UDP
ICMP
IGMP
OSPF
IP
Gambar protocol-protokol level aplikasi menurut konteks
Sintaks Abstrak mengambarkan struktur generic data yang terpisah dari teknik
encoding
yang
digunakan
untuk
menampilkan
data.
Sintaks
memungkinkan tipe-tipe data ditetapkan dan nilai-nilai dari tipe-tipe tersebut ditentukan. Sintaks abstrak memiliki sejumlah kesamaan dengan aspek-aspek definisi tipe data dari bahas pemrograman konvensional seperti pascal, C, dll. Protocol-protokol aplikasi menggunakan PDU-nya menurut sintaks abstrak. Use r
Use r Local storage (e.g, MIB)
user presentation
user presentation
mapping
mapping
local
Application
Abstract
mappin g
component
Syntax
encodin g
(e.g., ASN.1)
Local storage (e.g, MIB)
Application
local
component
mappin g
encoding rules
rules data transfer
data transfer
component
Transfer
component
(e.g, TCP, OSI
Syntax
(e.g, TCP, OSI
session)
(e.g., BER)
session)
50
RSVP
Penggunaan sintaks abstraksi dan sintaks transfer
Sintaks abstrak ini digunakan dalam pertukaran informasi diantara komponen-komponen aplikasi dalam system yang berbeda-beda. Pertukaran tersebut terdiri dari PDU-PDU level aplikasi, yang memuat informasi kontrol protokol dan data pemakai. Di dalam suatu sistem, informasi yang digambarkan dengan mnggunakan suatu sintaks abstrak harus dipetakan menjadi beberapa bentuk sebagai gambaran untuk pemakai manusia. Hampir sama dengan itu, sintaks abstrak ini harus dipetakan menjadi beberapa format lokal untuk penyimpanan. Sebagai contoh pemetaan semacam itu digunakan dalam hal informasi manajemen jaringan. Selain itu, sintaks abstrak menajdi semakin umum digunakan untuk menentukan elemen-elemen data untuk penyimpanan lokal. Jadi, notasi sintaks abstrak dipekai oleh pemakai untuk menjelaskan informasi manajemen jaringan, kemudian aplikasi tersebut harus mengubah definisi ini menjadi bentuk yang sesuai untuk penyimpanan lokal. Komponen tersebut juga harus menerjemahkan antara sintaks abstrak dari aplikasi tersebut dan sintaks transfer yang mengambarkan nilai-nilai data dalam bentuk biner, yang sesuai untuk interaksi dengan komponen transfer data. Sebagai contoh, suatu sintak abstrak bisa mencakup suatu tipe karakter data, sintaks transfer juga dapat menentukan pengkodean EBCDIC atau IRA. Jadi, sintaks transfer harus menentukan gamabaran data untuk diubah di antara komponen-komponen transfer data. Penerjemahan dari sintaks abstrak ke sintaks transfer bisa dicapai melalui peraturan-peraturan pengkodean yang menetapkan gambaran setiap nilai data dari setiap tipe data.
Konsep ASN.1 Definisi modul ASN.1 adalah suatu bahasa yang digunakan untuk menentukan struktur data. Suatu definisi struktur berbentuk modul yang memiliki nama. Nama modul
51
tersebut kemudian digunakan untuk menunjukan strukturnya. Sebagai contoh nama modul bisa digunakan sebagai nama sintaks abstrak. <modulerefence>DEFINITION::= BEGIN EXPORTS IMPORTS Assignment List End
Tipe data abstrak ASN.1 adalah suatu notasi untuk tipe data abstrak berikut nilai-nilainya. Suatu tipe bisa dipandang sebagai sekumpulan nilai. Jumlah nilai tipe yang diambil bisa terbatas. Sebagai contoh tipe INTEGER memiliki jumlah nilai yang terbatas. Kita dapat mengklasifikasi tipe ke dalam empat kategori :
Tipe Sederhana adalah tipe yang ditetapkan dengan cara menentukan susunan nilai-nilainya secara langsung (berupa tipe atomik, tanpa komponen-komponen). Contoh nama tipe : boolean, integer, bit string, real,dll.
Tipe Terstruktur adalah tipe-tipe yang terdiri dari berbagai komponen. ASN.1 menyediakan empat tipe terstruktur untuk membentuk tipe data lengkap dari tipe data sederhana. SEQUENCE SEQUENCE OF SET SET OF
Tipe Bertanda adalah suatu tipe yang misnomer karena semua tipe data di dalam ASN.1 memiliki sebuah tanda berasosiasi. Standar ASN.1 menetapkan tipe bertanda sebagai berikut Suatu tipe yang ditetapkan dengancara menunjuj tipe tunggal yang sudah ada dan subuah tanda, tipe baru adalah isomorphic ke tipe yang sudah ada, 52
namun berbeda dari itu. Di dalam seluruh skema pengkodean nilai suatu tipe baru bisa berbeda dari nilai tipe lama. Ada dua tipe implisit (menganti tanda) dan eksplisit (menambahkan tanda)
Tipe CHOICE dan ANY adalah tipe-tipe data tanpa tanda. Alasan di balik ini ialah bahwa suatu tipe bisa dipandang ssebagai kumpulan nilai. Tipe CHOICE adalah perpaduan kelompok nilai-nilai dari semua tipe-tipe komponen yang terdaftar dalam tipe CHOICE. Tipe ini sangat berguna bila nilai-nilai yang digambarkan tersebut berasal dari tipe-tipe yang berlainan
tergantung
dari
keadaannya,
dan
semua
tipe
yang
memungkinkan diketahui lebih dulu. Notasi untuk menentukan tipe CHOICE adalah sebagai berikut : ChoiceType ::=CHOICE (AlternativeTypeList) AlternativeTypeList ::= NamedType | AlternativeTypeLIst NamedType
Tipe ANY mengambarkan niali berubah-ubah dari tipe yang juga berubahubah, notasinya ialah : AnyType ::= ANY
Subtipe Subtipe, diperoleh dari suatu tipe induk dengan cara membatasi kelompok nilai-nilai yang ditetapkan untuk tipe induk. Subtipe antara lain :
Subtipe nilai tunggal : suatu daftar eksplesit dari seluruh nilai yang dimuat subtype. Exe: SmallPrime ::= INTEGER (2|3|5|7|11|13|17|19|23|29)
Subtipe bermuatan : digunakan untuk membentuk subtipe-subtipe baru dari subtipe yang telah ada, (mencakup se,ua nilai dari subtipe yang dimuatnya) Exe :
53
First-half ::= Month (INCLUDES First-quarter|INCLUDES Secondquarter)
Subtipe rentang nilai : hanya dipakai untuk tipe INTEGER dan REAL. Ditentukan dengan cara menetapkan nilai-nilai numeric dari ujung rentang
Pembatas abjad yang diperbolehkan, hanya bisa diterapkan muntuk tipe deretan karakter, terdiri dari semua nilai (deretan) yang bisa dibangun dengan menggunakan subabjad tipe induk. Exe : TouchToneButtons ::= IA5String (FROM (“0”|”1”|”2”|”3”|”4”|”5”|”6”|”7”|”8”|”9”|*”|”#”)
Pembatas ukuran, membatasi item di dalam sebuah tipe. Hanya dapat diterapkan untuk tipe-tipe deretan ( deretan bit, deretan octet, deretan karakter dan untuk tipe SEQUENCE OF dan SET OF).
Pembatas subtipe inner, bisa diterapkan untuk tipe SEQUENCE, SEQUENCE OF, SET, SET OF dan CHOICE
19.2 MANAJEMEN JARINGAN – SNMP Jaringan dan system pemrosesan terdistribusi adalah titik perkembangan yang penting dalam dunia bisnis, pemerintah, dan organisasi-organisasi lainnya. Di dalam suatu organisasi tertentu, jaringan cenderung semakin besar dan rumit serta mampu mendukung lebih banyak aplikasi dan pemakai. Jika skala jaringan ini semakin luas ada dua fakta yang menjadi bukti penting.
Jaringan dan sumber terasosiasinya serta aplikasi-aplikasi terdistribusi menjadi tidak bisa dipisahkan dari organisasi.
Banyak hal yang tidak berjalan sebagaimana mestinya, melumpuhkan jaringan keseluruhan atau menurunkan kinerja sampai pada tingkatan yang tidak bisa diterima lagi.
Sistem Manajemen Jaringan
54
Adalah sekumpulan perangkat untuk memantau dan mengontrol jaringan yang terintegrasi dalam beberapa hal berikut :
Interface operator tunggal dengan serangkaian perintah yang sangat kuat namun mudah digunakan untuk menampilkan sebagian atau seluruh tugas manajeman jaringan.
Peralatan terpisah dari jumlah minimal. Maksudnya, sebagian besar hardware dan software yang diperlukan untuk manajemen jaringan digabungkan ke dalam peralatan pemakai yang sudah ada.
Sistem manajemen jaringan terdiri dari tamabahan hardware dan software yang diimplementasikan diantara komponen-komponen jaringan yang sudah ada. Software yang digunakan untuk menyelesaikan tugas-tugas manajemen jaringan terletak pada komputer host dan pemroses komunikasi. Sistem manajemen jaringan dirancang sedemikian rupa untuk memandang jaringan secara keseluruhan sebagai panduan arsitek , dengan alamat-alamat dan label-label yang diterapkan pada titik ujung dan atribut-atribut tertentu dari masing-masing elemen dan link yang sudah diketahui sistem. Elemen aktif jaringan menyediakan feedback reguler atas informasi status untuk pusat kontrol jaringan. Sistem manajemen jaringan menggabungkan elemen-elemen dasar berikut :
1. Stasiun manajemen atau manajer Berupa peragkat yang erdiri sendiri namun bisa juga berupa suatu kapabilitas yang diimplementasikan pada sistem bersama. Stasiun manajemen minimal memiliki hal-hal sebagai berikut :
Serangkaian aplikasi manajemen untuk analisis data, pemulihan kesalahan dan sebagainya.
Sebuah interface tempat manajer jaringan bisa memantau dan mengontrol jaringan.
Kemampuan menerjemahkan ketentuan-ketentuan manajer jaringan ke dalam pemantauan dan kontrol elemen-elemen yang berjauhan di dalam jaringan secara aktual. 55
Basis data informasi manajeman jaringan yang disarikan dari basisbasis data seluruh entitas yang diatur dalam jaringan.
2. Agen Adalah elemen aktif lainnya di dalam sistem manajemen jaringan. Platform seperti host, bridge, router dan hub, dilengkapi dengan software agen sehingga bisa diatur dari setasiun manajemen. Agen merespons permintaan informasi dari stasiun manajemen, merespons permintaan akan tindakan-tindakan dari
stasiun
manajemen, dan serta asinkronus
melengkapi stasiun manajemen dengan informasi penting dan tersedia begitu saja. 3. Basis informasi manajemen BIM berfungsi sebagai kumpulan aksesn poin pada agen untuk stasin manajemen. 4. Protokol manajemen jaringan Adalah penghubung antara stasiun manajemen dan agen
Simple Network Manajement Protocol Versi 2 (SNMPv2) SNMP adalah suatu perangkat sederhana untuk menngelola jaringan. SNMP menetapkan basis informasi manajemen (BIM) yang terbatas dan mudah diimplementasikan dari variabel skalar dan tabel-tabel dua dimensi, serta menetapkan protokol streamlined sehingga memungkinkan bagi manajer mendapat dan memasang variabel-variabel BIM sekaligus memungkinkan agen mengelarkan notifikasi yang tersedia tanpa diminta, yang disebut traps. SNMP mudah diterapkan dan dikonsumsi sumber jaringan dan prosessornya sedangsedang saja. Selain itu struktur protokol dan BIM-nya tidak sulit diaplikasikan di antara beberapa stasiun manajemen dan software agen dari berbagai vendor. Karena sudah bnyak digunakan, defisiensi SNMP menjadi terlihat jelas. Defisiensi ini meliputi defisiensi fungsional dan kurangnya fasilitas pengamanan. Karena itu versi pengembangannya diterbitkanlah SNMPv2 pada tahun 1993.
Elemen-elemen SNMPv2
56
SNMPv2 sama sekali tidak menyediakan manajemen jaringan, SNMPv2 bahkan menyediakan suatu kerangka kerja untuk membangun aplikasi-aplikasi manajemen jaringan. Aplikasi-aplikasi tersebut seperti, manajemen eror, pemantauan kinerja, akunting,dll. SNMPv2 menyediakan infrastruktur bagi manajemen jaringan.
Gambar konfigurasi manajemen SNMPv2
Struktur Informasi Manajemen Struktur informasi manajemen (SIM) menetapkan kerangka kerja umum sehingga BIM bisa ditetapkan dan dibangun. SIM menentukan tipe-tipe data yang bisa digunakan dalam BIM, srta bagaimana sumber di dalam BIM ditampilkan dan diberi nama. Filosofi di balik SIM adalah untuk menonjolkan kesederhanaan dan eksistensibilitas di dalam BIM. Jadi BIM hanya mampu menyimpan tipe-tipe
57
data sederhana yaitu scalar dan larik sacral dua dimensi. SIM tidak tidak mampu mendukung kreasi atau perolehan kembali struktur data secara lengkap. Tabel tipe-tipe data yang diperbolehkan dalam SNMPv2
Operasi Protokol Inti dari kerangkan kerja SNMPv2 adalah protokol itu sendiri. Protokol menyediakan mekanisme dasar dan jelas untuk pertukaran informasi manajemen antara manajer dan agen.
Simple Network Manajement Protocol Versi 3 (SNMPv3) Untuk memperbaiki defisiensi pengamanan SNMPv1/v2 maka dikeluarkan SNMPv3 sebagai rangkaian standar yang diusulkan pada bulan januari 1998. rangkaian ini tidak menampilkan kapabilitas SNMP secara lengkap namun menetapkan arsitektur SNMP secara keseluruhan berikut rangkaian kapabilitas pengamanan yang ditujukan agar bisa digunakan bersama-sama dengan SNMPv3 yang telah ada. SNMPv3 menyediakan layanan-layanan penting, yaitu pembuktian keaslian, kerahasiaan, dan kontrol akses. Mekanisme pembuktian keaslian dalam User Based Security (USM) mengasumsikan bahwa sebuah pesan yang diterima ditransmisikan oleh pokok ynag pengenalnya muncul sebagai sumber di dlam header pesan. Fasilitas kerahasiaan dari USM memungkinkan bagi manajer dan agen melakukan enkripsi terhadap pesan. Fasilitas kontrol akses memungkinkan dilakukannya konfigurasi
58
agen untuk menyediakan level-level akses yang berlainan terhadap BIM agen untuk beberapa manajemen berbeda.
19.3 Surat Elektronik – SMTP dan MIME Aplikasi yang paling banyak digunakan dalam sistem terdistribusi virtual adalah surat elektronik. Sejak awal, simple mail transfer protocol (SMTP) telah menjadi kuda beban suite TPC/IP. Walaupun pada awalnya SMTP sudah dibatasi dalam hal pengiriman pesan-pesan teks sederhana, dalam beberapa tahun terakhir ini, terdapat suatu permintaan akan kapabilitas pengiriman surat yang memuat berbagai macam tipe data, termasuk suara, gambar dan video klip. Untuk memenuhi permintaan ini maka ditetapkan suatu standar surat elektronik baru yang dibangun di atas SMTP yaitu Multi Purpose Internet Mail Extension (MIME).
Simple Mail Transfer Protocol (SMTP) Adalah protokol standar untuk mentransfer surat antar host dalam suite TCP/IP yang ditetapkan dalam RFC 821. Meskipun pesan-pesan yang ditransfer melalui SMTP biasanya mengikuti format yang ditetapkan RFC 882 namun SMTP tidak memperhatikan format atau isi pesan itu sendiri, tentunya dengan dua pengecualian. Konsep ini sering dinyatakan dengan kata-kata bahwa SMTP menggunakan informasi tertulis pada amplop surat (header surat). Dua pengecualian tersebut adalah sebagai berikut: 1. SMTP menstandarkan kelompok karakter pesan sebagai ASCII 7-bit 2. SMTP menambah sebuah informasi ke permulaan pesan yang dikirim menunjukan path yang diambil pesan.
Operasi Surat Elektronik Dasar
59
(b) incomming mail
Gambar aliran surat SMTP
Gambar di atas menunjukan gambaran surat secara keseluruhan dalam suatu sistem khusus. Meskipun banyak dari aktivitas ini keluar dari jangkauan SMTP, gambaran tersebut mampu menunjukan gambaran konteks bagaimana SMTP beroprasi. Pengirim SMTP mengambil pesan dari antrian surat keluar dan mentransmisikan ke host tujuan (TCP/menuju port 25). Protokol SMTP digunakan untuk mentransfer pesan dari pengirim SMTP ke penerima SMTP melalui TCP SMTP, kemudian receiver SMTP menerima setiap pesan yang tiba dan menempatan ke mailbox pemakai yang tepat. Pada awalnya surat diciptakan melalui program agen pemakai sebagai respons terhadap pemakai yang memasukan. Setiap pesan yang dibuat terdiri dari sebuah header yang mencakup informasi berikui alamat surat elektronik penerima, serta batang tubuh surat elektronik yang memuat pesan yang dikirim. Pesan-pesan ini dapat kemudian diantrikan dengan beberapa macam cara dan tampilan sebagai input untuk program sender SMTP, yang biasanya merupakan program server yang selalu ada pada host.
60
Meskipun struktur antrian surat keluar akan berbeda tergantung pada sistem operasi milik host, setiap pesan yang diantrikan secara konseptual memiliki dua bagian : 1. Tesk pesan, terdiri dari : Header RFC 882, ini merupakan amplop pesan dan mencakup indikasi penerima atau penerima-penerima yang diyuju. Batang tubuh pesan, disusun oleh pemakai. 2. Daftar tujuan surat.
Gambaran SMTP Operasi SMTP terdiri dari serangkaian perintah dan respons yang saling dipertukarkan di antara pengirim dan penerima SMTP. Pertama-tama pengirim SMTP menetapkan kkoneksi TCP. Sekali koneksi ditetapkan pengirim SMTP mengirim perintah-perintah di sepanjang koneksi tersebut kepada penerima. Setiap perintah pasti akan menggerakan satu jawaban dari penerima SMTP. Tabel perintah-perintah SMTP
Tabel di atas menempilkan daftar perintah (command) SMTP. Setiap perintah terdiri dari sebaris teks tunggal yang dimulai dengan kode perintah empat huruf, yang pada hal-hal tertentu diikuti dengan bidang argumen. Sebagian besar jawaban berupa satu baris tunggal, meskipun kemungkinan juga ada jawaban dalam beberapa baris. Tabel tersebut menunjukan bahwa perintah-perintah
61
tersebut harus bisa dikenali penerima. Perintah-perintah lainnya bersifat opsional dan bisa diabaikan penerima.
Tabel jawaban-jawaban SMTP
Setiap jawaban dimulai dengan kode tiga digit dan diikuti dengan informasi tambahan. Digit utama menunjukan kategori jawaban sebagai berikut :
Positive completion repley : tindakan yang diminta telah berhasil diselesaikan, permintaan baru bisa dimulai lagi.
Positive intermediate reply : perintah telah diterima namun tindakan yang diminta sedang ditunda, menunggu tanda terima informasi berikutnya. Pengirim SMTP bisa mengirim perintah lainnya untuk menetapkan informasi ini. Jawaban ini digunakan dalam kelompok urutan perintah.
62
Transient negative completion reply : perintah tidak diterima dan tindakan yang diminta tidak dipenuhi. Namun kondisi kesalahan bersifat sementara dan tindakan bisa diminta lagi.
Permanent negative completion reply : perintah tidak diterima dan tindakan yang diminta tidak dipenuhi.
Operasi SMTP dasar muncul dalam tiga fase : set up koneksi, pertukaran satu atau lebih pasangan command-respons, dan pemutusan koneksi.
Set up koneksi Pengirim SMTP berusaha men-set up koneksi TPC dengan host target bila mmiliki satu persatu surat atau lbih untuk dikirim ke host tersebut.
Transfer Surat Setelah koneksi ditetapkan, pengirim SMTP bisa mengirim satu pesan atau lebih ke penerima SMTP
Mail command Memberi reseve path (jalur balik), yang dapat digunakan untuk melaporkan kesalahan.
RCPT command Menunjukan individu penerima mail data, sedangkan penerima multiple ditetapkan oleh penggunaan multiple perintah ini.
Penutupan koneksi Pengirim SMTP menutup koneksi dengan dua langkah. 1) pengirim mengirim perintah ”QUIT” dan menunggu jawaban, 2) Mengawali operasi penutupan TCP, receiver mengawali penutupan TPC setelah mengirim jawaban terhadap perintah ”QUIT”
RFC 822 63
Menetapkan format untuk pesan teks yang dikirim dengan menggunakan surat elektronik Contoh pesan : Date: Tue, 16 Jan 1996 10:37:17 (EST) From: "William Stallings" <
[email protected]: Subject: The Syntax in RFC 822 To: SmithOOther-host.com Cc: JonesOYet-Another-Host.com
Multipurpose Internet Mail Extension (MIME) MIME merupakan perluasan kerangkan kerja RFC 822 yang dimaksudkan untuk mengarahkan beberapa problem dan pembatasan penggunaan SMTP dan RFC 822 akan daftar surat elekronik {MURH98} menampilkan daftar keterbatasan skema SMTP/ 822 sebagau berikut : 1. SMTP tidak dapat mentransmisikan file eksekusi atau objek-objek biner lainnya. Sejumlah skema sedang digunakan untuk mengubah file-file biner menjadi bentuk teks yang bisa digunakan melalui SMTP system mail, termasuk skema popular Uuencode/Uudecode UNIX. Namun , tidak satupun dari skema-skema ini yang merupakan sebuah standar atau bahkan suatu standar de facto. 2. SMTP tidak dapat mentransmisikan data teks yang mencakup karakterkarakter bahasa nasional karena karakter-karakter itu dilambangkandengan kode 8 bit dengan nilai-nilai sebesar 128 desimal atau lebih tinggi, sedangkan SMTP dibatasi sampai 7-bit ASCII 3. Serve SMTP bisa menolak pesan surat pada ukuran tertentu. 4. Gateway SMTP yang menterjemahkan antara ASCII dank ode karakter EBCDIC tidak menggunakan kelompok pemetaan yang konsisten, sehingga menyebabkan problem-problem dalam penerjemahan. 5. Gateway SMTP ke jaringan surat elektronik X.400 tidak dapat menangani data nontekstual yang mencakup dalam pesan-pesan X.400.
64
6. Berbeda implementasi SMTP tidak melekat secara lengkap terhadap standar-standar SMTP yang ditetapkan slam RCF. Problem-problem yang umum mencakup : penghapusan, penambahan atau pengulangn pesanan carriage return dan linefeed.
Gambaran Spesifikasi MIME mencakup elemen-elemen berikut : 1. Lima bidang header pesan yang baru ditetapkan, yang termasuk dalam header RFC 822. bidang ini menyediakan informasi mengenai tubuh pesan. 2. Sejumlah format isi ditetapkan, sehingga menstandarkan gambaran-gambaran yang mendukung surat elektronik multimedia. 3. Pengkodean transfer ditetapkan sehingga memungkinkan pengkonvensionalan format isi menjadi bentuk yang terlindung dari berbagai pergantian lewat system mail. Lima bidang header yang ditetapkan dalam MIME sebagai berikut : 1. MIME-Version : harus memiliki nilai parameter 1.0 bidang ini menunjukan bahwa pesan sesuai dengan RFC. 2. Content-Type : mengambarkan data-data yang dimuat dalam batang tubuh dengan detail yang memadai sehingga agen pemakai dapat memilih agen yang tepat atau mekanisme untuk menunjukan data-data kepada pemakai atau sebaliknya berkaitan dengan data-data dengan cara yang sesuai. 3. Content-Transfer-Encoding : menunjukan tipe transformasi yang telah digunakan untuk menunjukan batang tubuh pesan sedemikian rupa sehingga bisa diterima untuk transport mail. 4. Content-ID : digunakan secara unik untuk mengidentifikasi entitas-entitas MIME menurut konteks multiple. 5. Content-Description : deskripsi plain text dari objek dengan batang tubuh, berguan bila objeknya tidak bisa dibaca (misal data audio).
Tipe-tipe content MIME
65
MIME transfer Encoding Komponen utama lainnya dari spesifikasi MIME, sebagai tambahan terhadap spesifikasi tipe isi, adalah definisi pengkodean transfer untuk batang tubuh pesan. Tujuannya adalah untuk menyediakan pengiriman yang andal pada lingkungan yang luas Pengkodean transfer MIME
7 bit : data adalah semua yang ditampilkan melalui baris pendek karakter ASCII
8 bit : barisnya pendek, namun berupa karakter non ASCII (octet dengan rangkaian bit orde-tinggi)
Biner : tidak hanya berupa karakter non-ASCII yang ada namun barisnya tidak harus pendek untuk transport SMTP
Quoted-printable : mengkodekan data sedemikian rupa sehingga bila data yang sedang dikodekan sebagian besar berupa teks ASCII, bentuk data yang dikodekan tersebut bisa dikenali manusia.
Base64 : mengkodekan data dengan cara memetakan blok-blok input 6 bit ke blok-blok output 8 bit, semuanya merupakan karakter ASCII yang dapat dicetak.
X-token : pengkodean nonstandard yang diberi nama
66
Chapter 23 Internet Aplication Key topics :
Pertumbuhan yang cepat dalam penggunaan Web adalah karena tion standardiz dari semua elemen yang mendukung aplikasi Web. Sebuah elemen kunci adalah HTTP, yang merupakan protokol untuk pertukaran informasi berbasis web antara browser Web dan server Web.
Tiga jenis perangkat menengah dapat digunakan dalam sebuah jaringan HTTP: proxy, gateway, dan terowongan.
HTTP menggunakan permintaan / respon gaya komunikasi.
Domain Name System (DNS) adalah layanan direktori lookup yang menyediakan pemetaan antara nama host di Internet dan alamat numerik.
DNS membuat penggunaan database, didistribusikan hirarkis untuk mempertahankan pemetaan dari nama ke alamat dan untuk memberikan informasi terkait tentang host di Internet.
Bab ini membahas dua bab aplikasi areas.This paling banyak digunakan dan lebih maju internet dan berikutnya harus memberikan pembaca merasakan kisaran dan keragaman aplikasi yang didukung oleh arsitektur komunikasi. Bab ini dimulai dengan DNS, yang merupakan nama penting / alamat layanan direktori pencarian untuk Internet.Then kita melihat HTTP, yang merupakan protokol yang mendukung World Wide Web (WWW) beroperasi.
INTERNET DIRECTORY SERVICE Domain Name System (DNS) adalah layanan direktori lookup yang menyediakan pemetaan antara nama host di Internet dan alamat numerik. DNS adalah penting untuk fungsi Internet. Hal ini didefinisikan dalam RFC 1034 dan 1035. Empat unsur terdiri dari DNS.
Domain ruang nama: DNS menggunakan ruang nama pohon-terstruktur untuk mengidentifikasi sumber daya di Internet.
67
Database DNS: Secara konseptual, setiap node dan daun dalam struktur pohon ruang nama nama satu set informasi (misalnya, alamat IP, jenis sumber daya) yang terkandung dalam catatan sumber daya (RR) Pengumpulan dari semua RR ini diatur dalam. didistribusikan database.
Nama server: Ini adalah server yang program yang menyimpan informasi tentang sebagian dari struktur nama domain pohon dan RR terkait.
Resolvers: Ini adalah program yang mengekstrak informasi dari server nama dalam menanggapi permintaan klien. Permintaan klien khas adalah untuk alamat IP yang sesuai dengan nama domain yang diberikan Dalam dua bagian berikutnya, kita memeriksa nama domain dan database
DNS, masing - masing. Kami kemudian menggambarkan operasi DNS, yang mencakup diskusi dari server nama dan resolvers.
Nama Domain Alamat IP 32-bit menyediakan cara unik mengidentifikasi perangkat yang terkait ke Internet. Alamat ini ditafsirkan sebagai memiliki dua komponen: sebuah nomor jaringan, yang mengidentifikasikan sebuah jaringan di Internet, dan alamat host, yang mengidentifikasikan sebuah host yang unik pada jaringan. Penggunaan praktis dari alamat IP menyajikan dua masalah: 1. Router merancang jalan melalui internet berdasarkan nomor jaringan. Jika setiap router yang dibutuhkan untuk menjaga meja master yang terdaftar setiap jaringan dan jalur jaringan yang lebih suka, pengelolaan tabel akan rumit dan memakan waktu. Akan lebih baik ke grup jaringan sedemikian rupa untuk menyederhanakan fungsi routing. 2. Alamat 32-bit biasanya ditulis sebagai empat angka desimal, sesuai dengan empat oktet dari skema nomor address.This efektif untuk pemrosesan komputer tetapi tidak nyaman bagi pengguna, yang dapat lebih mudah mengingat nama daripada alamat numerik.
Masalah ini ditangani oleh konsep dari domain. Secara umum, domain mengacu pada sekelompok host yang berada di bawah kontrol administratif dari 68
sebuah entitas tunggal, seperti perusahaan atau instansi pemerintah. Domain diatur secara hirarki, sehingga domain yang diberikan dapat terdiri dari sejumlah domain bawahan. Nama ditugaskan untuk domain dan mencerminkan organisasi hirarkis. Gambar 23.1 menunjukkan sebagian dari pohon penamaan domain. Pada tingkat paling atas adalah sejumlah kecil domain yang mencakup seluruh Internet. Tabel 23.1 daftar saat ini didefinisikan top-level domain. Setiap tingkat bawahan diberi nama dengan awalan nama bawahan nama di tingkat tertinggi berikutnya. Sebagai contoh,
Edu merupakan domain tingkat perguruan tinggi lembaga pendidikan AS.
Mit.edu adalah domain untuk M.I.T. (Massachusetts Institute of Technology).
lcs.mit.edu adalah domain untuk Laboratorium untuk Ilmu Komputer di M.I.T.
Gambar 23.1 Portion of Internet Domain Tree
69
Table 23.1 Top-Level Internet Domains
Ketika Anda bergerak ke bawah pohon penamaan, Anda akhirnya mendapatkan node daun yang mengidentifikasi host tertentu di Internet. Host ini ditugaskan alamat Internet. Sebuah organisasi Internet-lebar bertanggung jawab untuk menetapkan nama domain sehingga setiap nama domain adalah unik. Tugas
70
sebenarnya dari alamat yang didelegasikan bawah hirarki. Dengan demikian, domain mil diberikan sebuah kelompok besar alamat. Departemen Pertahanan AS (DoD) kemudian mengalokasikan bagian-bagian dari ruang alamat ini ke organisasi DoD berbagai tugas akhirnya ke host. Sebagai contoh, tuan rumah utama di MIT, dengan nama domain mit.edu, memiliki empat alamat IP: 18.7.21.77, 18.7.21.69, 18.7.21.70, dan 18.7.21.110. Para lcs.mit.edu domain bawahan memiliki alamat IP 18.26.0.36.1
Database DNS DNS adalah didasarkan pada database hirarki yang berisi catatan sumber daya (RR) yang termasuk nama, alamat IP, dan informasi lain tentang fitur kunci hosts.The dari database adalah sebagai berikut: Variabel mendalam hirarki untuk nama: DNS memungkinkan tingkat dasarnya terbatas dan menggunakan waktu sebagai pemisah tingkat dalam nama dicetak, seperti yang dijelaskan sebelumnya (.). Didistribusikan database: database berada di server DNS yang tersebar di seluruh internet dan intranet swasta. Distribusi dikontrol oleh database: database DNS adalah dibagi menjadi zona terpisah ribuan dikelola, yang dikelola oleh administrator yang terpisah. Perangkat lunak database kontrol distribusi dan memperbarui catatan.
Menggunakan database ini, server DNS menyediakan layanan direktori nama-to-address untuk aplikasi jaringan yang perlu untuk mencari server yang spesifik. Sebagai contoh, setiap kali pesan e-mail akan dikirim atau halaman Web diakses, harus ada nama DNS lookup untuk menentukan alamat IP dari server e-mail atau Web server. Gambar 23.2 menunjukkan struktur dari RR. Ini terdiri dari unsur-unsur berikut:
71
Domain Name: Meskipun sintaks dari nama domain dalam pesan, dijelaskan kemudian, adalah tepat didefinisikan, bentuk nama domain dalam suatu RR
dijelaskan dalam istilah umum. Pada intinya, nama domain di RR harus sesuai dengan bentuk yang dapat dibaca manusia, yang terdiri dari serangkaian karakter alfanumerik label atau tanda hubung, dengan masingmasing pasangan label yang dipisahkan oleh periode.
Tipe: Mengidentifikasi jenis sumber daya dalam berbagai jenis RR.The tercantum pada Tabel 23.2.2
Kelas: Mengidentifikasi keluarga protokol. Satu-satunya nilai yang umum digunakan adalah DI, untuk Internet.
Time to Live: Biasanya, ketika RR diambil dari server nama, anjing akan cache RR sehingga tidak perlu query server nama berulang kali. Bidang ini menentukan interval waktu bahwa catatan sumber daya mungkin cache sebelum sumber informasi lagi harus consulted.A nilai nol adalah ditafsirkan bahwa RR hanya dapat digunakan untuk transaksi berlangsung dan tidak harus di-cache.
Rdata Lapangan Length: Panjang bidang Rdata dalam oktet.
Rdata: Variabel string panjang oktet yang menggambarkan sumber daya. Format informasi ini bervariasi sesuai dengan jenis RR. Sebagai contoh,
72
untuk tipe A, Rdata adalah alamat IP 32-bit, dan untuk jenis CNAME, Rdata adalah nama domain.
Operasi DNS DNS operasi biasanya meliputi langkah-langkah berikut (Gambar 23.3): 1. Sebuah program permintaan pengguna alamat IP untuk nama domain. 2. Sebuah modul resolver di host lokal atau ISP lokal merumuskan sebuah query untuk server nama lokal dalam domain yang sama dengan resolver. 3. Server nama lokal memeriksa untuk melihat apakah nama dalam database lokal atau cache, dan, jika demikian, mengembalikan alamat IP untuk pemohon. Jika tidak, nama server query server lain nama yang tersedia, mulai turun dari akar pohon DNS atau sebagai tinggi pohon mungkin. 4. Ketika respon yang diterima di server nama lokal, menyimpan pemetaan nama / alamat dalam cache lokal dan dapat mempertahankan entri untuk jumlah waktu yang ditentukan dalam waktu untuk hidup bidang RR diambil. 5. Program pengguna diberikan alamat IP atau pesan error.
73
Hasil dari balik layar kegiatan terlihat oleh pengguna dengan cara yang diilustrasikan pada Gambar 23.4. Di sini, pengguna mengajukan permintaan koneksi Telnet ke locis.loc.gov.This diselesaikan oleh DNS untuk alamat IP 140.147.254.3. Database DNS terdistribusi yang mendukung fungsi DNS harus diperbarui sering karena pertumbuhan yang cepat dan terus dari Internet. Dengan demikian, fungsi memperbarui dinamis untuk DNS telah didefinisikan. Pada intinya, server nama DNS secara otomatis mengirimkan update ke server lain nama relevan sebagai kondisi memungkinkan. Hirarki server. Database DNS didistribusikan secara hirarki, yang berada di server nama DNS yang tersebar di seluruh Internet. Nama server dapat dioperasikan oleh setiap organisasi yang memiliki domain, yaitu, setiap organisasi yang memiliki tanggung jawab untuk subtree dari ruang nama domain hirarkis. Setiap name server dikonfigurasi dengan subset dari ruang nama domain, yang dikenal sebagai zona, yang
74
adalah kumpulan dari satu atau lebih (atau semua) subdomain dalam domain, bersama dengan RR terkait. Ini set data disebut berwibawa, karena ini nama server bertanggung jawab untuk menjaga set akurat atau RR untuk ini bagian dari struktur hirarkis nama domain hierarchy.The dapat memperpanjang ke depth.Thus, sebagian dari ruang nama yang ditetapkan ke server nama otoritatif dapat didelegasikan ke server nama bawahan dengan cara yang sesuai dengan struktur dari domain
nama pohon. Sebagai contoh, nama server sesuai dengan ibm.com domain. Sebagian dari domain yang didefinisikan oleh watson.ibm.com nama, yang sesuai dengan watson.ibm.com node dan semua node cabang dan daun bawah watson.ibm.com simpul. Di bagian atas hirarki server 13 root server nama yang berbagi tanggung jawab untuk zona tingkat atas (Tabel 23.3). Replikasi ini adalah untuk mencegah server akar dari menjadi hambatan. Meskipun demikian, setiap server akar individu cukup sibuk. Sebagai contoh, laporan internet Software Consortium
75
bahwa server-nya (F) jawaban hampir 300 juta permintaan DNS harian (www.isc.org/layanan/masyarakat/f-rootserver.html). Pertimbangkan query dengan program pada host pengguna untuk query watson.ibm.com.This dikirim ke server lokal dan langkah-langkah berikut terjadi: 1. Jika server lokal sudah memiliki alamat IP untuk watson.ibm.com dalam cache lokal, ia mengembalikan alamat IP. 2. Jika nama tidak dalam cache server nama lokal, itu mengirimkan query ke server akar server.The akar pada gilirannya meneruskan permintaan ke server dengan catatan NS untuk ibm.com. Jika server ini memiliki informasi untuk watson.ibm.com, ia mengembalikan alamat IP. 3. Jika ada server nama didelegasikan hanya untuk watson.ibm.com, maka server
nama
ibm.com
meneruskan permintaan ke server
nama
watson.ibm.com, yang mengembalikan alamat IP.
Biasanya, pertanyaan tunggal dilakukan di atas UDP. Query untuk sekelompok nama dilakukan melalui TCP. Resolusi nama. Seperti Gambar 23.3 menunjukkan, setiap permintaan dimulai pada name resolver terletak di sistem host pengguna (misalnya, gethostbyname di UNIX). Setiap penyelesai dikonfigurasi untuk mengetahui nama dan alamat server nama DNS lokal. Jika resolver tidak memiliki nama yang diminta dalam cache, ia akan mengirimkan permintaan DNS ke server DNS lokal, yang bisa mengembalikan alamat segera atau melakukannya setelah query satu atau lebih server lainnya. Sekali lagi, resolver menggunakan UDP untuk pertanyaan tunggal dan TCP untuk permintaan kelompok. Ada dua metode yang query diteruskan dan hasil kembali. Misalkan server nama (A) ke depan permintaan DNS untuk name server lain (B). Jika B memiliki nama / alamat dalam cache lokal atau database lokal, dapat kembali alamat IP untuk A. Jika tidak, maka B dapat melakukan salah satu dari berikut: 1. Query server lain nama untuk hasil yang diinginkan dan kemudian mengirim hasilnya kembali ke A. Ini adalah dikenal sebagai teknik rekursif.
76
2. Kembali ke A alamat dari server berikutnya (C) kepada siapa permintaan harus dikirim. A kemudian mengirimkan sebuah permintaan DNS baru untuk C. Hal ini dikenal sebagai teknik iteratif. Dalam pertukaran antara server nama, baik iteratif atau teknik rekursif dapat digunakan. Untuk permintaan dikirim oleh name resolver, teknik rekursif digunakan.
Pesan DNS. Pesan DNS menggunakan format tunggal, ditunjukkan pada Gambar 23.5. Ada lima bagian mungkin untuk pesan DNS: header, pertanyaan, jawaban, otoritas, dan catatan tambahan. Bagian header selalu hadir dan terdiri dari bidang-bidang berikut:
Identifier: Ditugaskan oleh program yang menghasilkan setiap jenis query. Identifier yang sama digunakan dalam respon apapun, memungkinkan pengirim untuk mencocokkan permintaan dan tanggapan.
Respon Pertanyaan: Menunjukkan apakah pesan ini adalah query atau respon.
Opcode: Menunjukkan apakah ini adalah permintaan standar, sebuah query terbalik (alamat ke nama), atau permintaan status server. Nilai ini ditetapkan oleh originator dan disalin ke respon.
Resmi Jawaban: Hari dalam respon, dan menunjukkan apakah nama server menanggapi adalah otoritas untuk nama domain yang dimaksud.
Truncated: Menunjukkan apakah pesan respon itu dipotong karena panjang lebih besar maka diizinkan pada saluran transmisi. Jika demikian, pemohon akan menggunakan sebuah koneksi TCP untuk mengirim query.
Rekursi Diinginkan: Jika di set, mengarahkan server untuk mengejar query rekursif.
Rekursi Tersedia: Mengatur atau dibersihkan pada respon untuk menunjukkan apakah dukungan permintaan rekursif tersedia di server nama.
Respon Kode: nilai-nilai yang mungkin adalah: tidak ada kesalahan, kesalahan format (server yang tidak mampu menafsirkan permintaan), 77
kegagalan server, kesalahan nama (nama domain tidak ada), tidak diimplementasikan (semacam ini query tidak didukung), dan menolak (untuk kebijakan alasan).
QDcount: Jumlah entri dalam bagian pertanyaan (nol atau lebih).
ANcount: Jumlah RR di bagian jawaban (nol atau lebih).
NScount: Jumlah RR di bagian otoritas (nol atau lebih).
ARcount: Jumlah RR di bagian catatan tambahan (nol atau lebih). Bagian Pertanyaan berisi query untuk server nama. Jika ada, biasanya
hanya berisi satu entri. Setiap entri berisi berikut:
Nama Domain: Sebuah nama domain direpresentasikan sebagai urutan label, di mana setiap label terdiri dari oktet panjang diikuti oleh jumlah oktet. Nama domain berakhir dengan oktet panjang nol untuk label nol akar.
78
Query Type: Menunjukkan jenis nilai query.The untuk bidang ini mencakup semua nilai yang valid untuk kolom Jenis dalam format RR (Gambar 23.2), bersama dengan beberapa kode yang lebih umum yang sesuai dengan lebih dari satu jenis RR.
Kelas Pertanyaan: Menentukan kelas Internet query, biasanya. Bagian Jawaban berisi RR yang menjawab pertanyaan; bagian otoritas
berisi RR yang mengarah ke server nama otoritatif; bagian catatan tambahan berisi RR yang berhubungan dengan query tetapi tidak ketat jawaban untuk pertanyaan itu.
23.2 WEB ACCES--HTTP Hypertext Transfer Protocol (HTTP) adalah protokol dasar dari World Wide Web (WWW) dan dapat digunakan dalam aplikasi client / server yang melibatkan hypertext. Nama ini agak menyesatkan di HTTP yang bukan merupakan protokol untuk mentransfer hypertext, melainkan adalah sebuah protokol untuk transmisi informasi dengan efisiensi yang diperlukan untuk membuat melompat hypertext. Data ditransfer oleh protokol dapat plaintext, hypertext, audio, gambar, atau informasi Internet yang dapat diakses. Kita mulai dengan gambaran konsep HTTP dan operasi dan kemudian melihat beberapa rincian, mendasarkan pembahasan kita pada versi terbaru untuk diletakkan di jalur standar Internet, HTTP 1.1 (RFC 2616). Sejumlah istilah penting yang didefinisikan dalam spesifikasi HTTP dirangkum dalam Tabel 23.4, ini akan diperkenalkan sebagai hasil diskusi.
IKHTISAR HTTP HTTP adalah klien berorientasi transaksi / protokol server. Penggunaan paling khas dari HTTP adalah antara browser Web dan server Web. Untuk menyediakan keandalan, HTTP membuat penggunaan TCP. Namun demikian, HTTP adalah "stateless" protokol: Setiap transaksi diperlakukan secara independen. Dengan demikian, implementasi khas akan membuat koneksi TCP yang baru antara klien dan server untuk setiap transaksi dan kemudian mengakhiri 79
koneksi secepat transaksi selesai, meskipun spesifikasi tidak mendikte hubungan satu-ke-satu antara transaksi dan tahan koneksi. Sifat stateless HTTP cocok untuk sesi khas application.A normal pengguna dengan browser Web melibatkan mengambil urutan halaman Web
dan dokumen. Urutannya adalah, idealnya, dilakukan dengan cepat, dan lokasi dari berbagai halaman dan dokumen mungkin sejumlah server didistribusikan secara luas. Fitur penting lainnya dari HTTP adalah bahwa fleksibel dalam format yang dapat handle.When beberapa masalah klien permintaan ke server, mungkin termasuk daftar prioritas format yang dapat menangani, dan balasan server dengan format yang sesuai. Sebagai contoh, browser Lynx tidak dapat menangani
80
gambar, sehingga server Web tidak perlu mengirim setiap gambar pada halaman Web. Pengaturan ini mencegah transmisi informasi yang tidak perlu dan memberikan dasar untuk memperluas set format dengan spesifikasi standar dan proprietary baru.
Gambar 23.6 mengilustrasikan tiga contoh kasus operation.The HTTP paling sederhana adalah satu di mana user agent menciptakan suatu hubungan langsung dengan agen server.The asal pengguna adalah klien yang memulai permintaan, seperti Web browser yang dijalankan atas nama user.The akhir server asal adalah server di mana sumber daya kepentingan berada; contoh adalah server Web di mana sebuah halaman Web yang diinginkan berada di rumah. Untuk kasus ini, klien akan membuka koneksi TCP yang end-to-end antara klien dan server. Klien kemudian isu-isu permintaan HTTP. Permintaan terdiri dari perintah tertentu, disebut sebagai sebuah metode, alamat [disebut sebagai Uniform Resource Locator (URL)], 3 dan pesan MIME-seperti mengandung parameter
81
permintaan, informasi tentang klien, dan mungkin beberapa konten tambahan informasi. Ketika server menerima permintaan, ia mencoba untuk melakukan aksi yang diminta dan kemudian mengembalikan sebuah respon HTTP. Tanggapan mencakup informasi status, kode keberhasilan / error, dan pesan MIME-seperti berisi informasi server aboutthe, informasi tentang jawaban itu sendiri, dan isi tubuh mungkin. Koneksi TCP kemudian ditutup. Bagian tengah Gambar 23,6 menunjukkan kasus di mana tidak ada koneksi end-toend TCP antara agen pengguna dan server asal. Sebaliknya, ada satu atau lebih sistem intermediate dengan koneksi TCP antara sistem logis yang berdekatan. Setiap sistem intermediate bertindak sebagai relay, sehingga permintaan diprakarsai oleh
klien disampaikan melalui sistem menengah untuk server, dan respon dari server disampaikan kembali ke klien.
82
Tiga bentuk sistem intermediate didefinisikan dalam spesifikasi HTTP: proxy, gateway, dan terowongan, semua yang diilustrasikan pada Gambar 23.7.
PROXY. Proxy bertindak atas nama klien lain dan permintaan hadiah dari klien lain ke proxy server.The bertindak sebagai server dalam berinteraksi dengan klien dan sebagai klien dalam berinteraksi dengan server. Ada dua skenario bahwa panggilan untuk penggunaan proxy:
Keamanan perantara: klien dan server dapat dipisahkan oleh sebuah perantara keamanan seperti firewall, dengan proxy pada sisi klien firewall. Biasanya, klien adalah bagian dari jaringan dijamin oleh firewall dan server eksternal ke jaringan dijamin. Dalam hal ini, server harus mengotentikasi sendiri untuk firewall untuk mengatur koneksi dengan proxy. Proxy menerima respon setelah mereka telah melewati firewall.
Berbagai versi dari HTTP: Jika klien dan server menjalankan versi yang berbeda HTTP, maka proxy dapat melaksanakan kedua versi dan melakukan pemetaan yang diperlukan.
Singkatnya, proxy adalah agen forwarding, menerima permintaan untuk objek URL, memodifikasi permintaan, dan forwarding permintaan terhadap server diidentifikasi dalam URL.
GATEWAY. Sebuah gateway adalah server yang muncul untuk klien seolah-olah server asal. Bertindak atas nama dari server lain yang tidak mungkin dapat berkomunikasi langsung dengan client.There adalah dua skenario di mana gateway dapat digunakan.
Keamanan perantara: klien dan server dapat dipisahkan oleh sebuah perantara keamanan seperti firewall, dengan gateway pada sisi server firewall. Biasanya, server terhubung ke jaringan yang dilindungi oleh firewall, dengan klien eksternal ke jaringan. Dalam hal ini klien harus 83
mengotentikasi sendiri untuk gateway, yang kemudian dapat lulus permintaan ke server.
Non-server HTTP: browser Web telah dibangun ke dalam mereka kemampuan untuk menghubungi server untuk protokol selain HTTP, seperti FTP dan server Gopher. Kemampuan ini juga dapat disediakan oleh gateway. Klien membuat permintaan HTTP ke server server.The gerbang gerbang kemudian kontak FTP atau server Gopher yang relevan untuk mendapatkan hasil yang diinginkan. Hasil ini kemudian diubah menjadi bentuk yang sesuai untuk HTTP dan dikirim kembali ke klien.
TUNNEL. Tidak seperti proxy dan gateway, terowongan tidak melakukan operasi pada permintaan HTTP dan tanggapan. Sebaliknya, terowongan hanyalah titik relay antara dua koneksi TCP, dan pesan HTTP dilewatkan tidak berubah seolaholah ada koneksi HTTP tunggal antara user agent dan server asal. Terowongan digunakan ketika harus ada sistem perantara antara klien dan server tetapi tidak diperlukan untuk sistem untuk memahami isi pesan. Contohnya adalah firewall di mana klien atau server eksternal ke jaringan yang dilindungi dapat membangun koneksi otentik dan kemudian mempertahankan bahwa koneksi untuk tujuan transaksi HTTP.
CACHE. Kembali ke Gambar 23,6, bagian terendah dari angka tersebut menunjukkan contoh dari cache. Cache adalah fasilitas yang dapat menyimpan dan tanggapan permintaan sebelumnya untuk menangani permintaan baru. Jika permintaan baru tiba yang sama sebagai permintaan yang disimpan, maka cache dapat menyediakan respon disimpan daripada mengakses sumber daya yang ditunjukkan dalam cache URL.The dapat beroperasi pada klien atau server atau pada sistem intermediate selain terowongan . Dalam gambar, B perantara memiliki cache transaksi permintaan / respon, sehingga permintaan baru sesuai
84
dari klien tidak perlu perjalanan seluruh rantai ke server asal, tetapi ditangani oleh B. Tidak semua transaksi dapat di-cache, dan klien atau server dapat mendikte bahwa suatu transaksi tertentu mungkin cache hanya untuk batas waktu tertentu.
MESSAGE. Cara
terbaik
untuk
menjelaskan
fungsi
HTTP
adalah
untuk
menggambarkan elemen individu dari pesan HTTP. HTTP terdiri dari dua jenis pesan: permintaan dari klien ke server, dan tanggapan dari server ke klien. Pesan Struktur umum ofsuch ditunjukkan pada Gambar 23,8. Lebih formal, menggunakan ditingkatkan BNF (Backus-Naur Form). Notasi 4. (Table 23.5).
85
HTTP-Message = Simple-Request | Simple-Response | Full-Request | Full-Response Full-Request = Request-Line *( General-Header | Request-Header | Entity-Header ) CRLF [ Entity-Body ] Full-Response = Status-Line *( General-Header | Response-Header | Entity-Header ) CRLF [ Entity-Body ] Simple-Request = “GET” SP Request-URL CRLF Simple-Response = [ Entity-Body ]
Pesan-pesan sederhana-sederhana-Permintaan dan Respon didefinisikan dalam HTTP/0.9. Permintaan adalah perintah GET sederhana dengan URL yang diminta; respon hanyalah sebuah blok yang berisi informasi yang diidentifikasi dalam URL. Pada HTTP/1.1, penggunaan bentuk-bentuk sederhana adalah dianjurkan karena mencegah klien dari menggunakan negosiasi konten dan server dari mengidentifikasi jenis media dari entitas kembali. Dengan penuh permintaan dan tanggapan, bidang-bidang berikut digunakan:
Permintaan-Line: Mengidentifikasi jenis pesan dan sumber daya yang diminta
Status-Line: Memberikan informasi status tentang tanggapan ini
General-header: Berisi bidang yang berlaku bagi permintaan dan pesan respon tapi itu tidak berlaku untuk entitas yang ditransfer
Permintaan-header: Berisi informasi tentang permintaan dan klien
Respon-header: Berisi informasi tentang respon
Badan-header: Berisi informasi tentang sumber daya diidentifikasi oleh permintaan dan informasi tentang tubuh entitas
Badan-Badan: Tubuh pesan 86
Semua header HTTP terdiri dari urutan bidang, mengikuti format generik yang sama sebagai RFC 822 (dijelaskan dalam Bab 22). Setiap bidang dimulai pada baris baru dan terdiri dari nama field diikuti oleh titik dua dan nilai lapangan. Meskipun mekanisme transaksi dasar sederhana, ada sejumlah besar bidang dan parameter yang didefinisikan dalam HTTP. Dalam sisa bagian ini, kita melihat field header umum. Bagian berikut menjelaskan header permintaan, header respon, dan entitas.
GENERAL HEADER FIELD. Header Umum dapat digunakan dalam kedua permintaan dan pesan respon. Bidang ini berlaku pada kedua jenis pesan dan berisi informasi yang tidak secara langsung berlaku untuk entitas yang ditransfer. Bidang adalah sebagai berikut:
Cache-Control: Menentukan arahan yang harus dipatuhi oleh setiap mekanisme caching sepanjang rantai permintaan / respon. Tujuannya adalah untuk mencegah cache dari buruk campur dengan permintaan tertentu atau respon.
Koneksi: Berisi daftar kata kunci dan nama field header yang hanya berlaku untuk hal ini koneksi TCP antara pengirim dan penerima nontunnel terdekat.
Tanggal: Tanggal dan waktu di mana pesan tersebut berasal.
Forwarded: Digunakan oleh gateway dan proxy untuk menunjukkan langkah-langkah perantara sepanjang rantai permintaan atau respon. Setiap gateway atau proxy yang menangani pesan dapat melampirkan bidang Forwarded yang memberikan URL-nya.
Jaga-Alive: Dapat hadir jika kata kunci tetap-hidup hadir dalam medan Koneksi masuk, untuk memberikan informasi kepada pemohon dari koneksi persisten. Bidang ini mungkin menunjukkan waktu maksimum yang pengirim akan sambungan tetap terbuka menunggu untuk permintaan berikutnya atau jumlah maksimum permintaan tambahan yang akan diizinkan pada koneksi persisten saat ini. 87
MIME-Version: Menunjukkan bahwa pesan sesuai dengan versi ditunjukkan MIME.
Pragma: Berisi implementasi khusus arahan yang berlaku untuk setiap penerima di sepanjang rantai permintaan / respon.
Upgrade: Digunakan dalam permintaan untuk menentukan apa protokol tambahan klien mendukung dan ingin menggunakan; digunakan dalam respon untuk menunjukkan protokol yang akan digunakan.
PERMINTAAN PESAN Sebuah pesan permintaan penuh terdiri dari baris status diikuti oleh satu atau lebih permintaan umum,, dan header entitas, diikuti oleh badan entitas opsional.
PERMINTAAN METODE. Sebuah pesan permintaan penuh selalu dimulai dengan Line Permintaan-, yang memiliki format berikut:
Request-Line = Method SP Request-URL SP HTTP-Version CRLF
Parameter Metode menunjukkan perintah permintaan yang sebenarnya, yang disebut metode dalam HTTP. Permintaan-URL URL dari sumber daya yang diminta, dan HTTPVersion adalah nomor versi HTTP yang digunakan oleh pengirim. Metode permintaan berikut didefinisikan dalam HTTP/1.1:
OPSI: Permintaan untuk informasi tentang pilihan yang tersedia untuk rantai permintaan / respon diidentifikasi oleh URL ini.
GET: Permintaan untuk mengambil informasi yang diidentifikasi dalam URL dan mengembalikannya dalam tubuh entitas. GET adalah bersyarat jika Jika-Diubah-Sejak header bidang termasuk dan parsial jika kolom header Rentang disertakan.
KEPALA: Permintaan ini identik dengan GET, kecuali bahwa respon server tidak harus menyertakan sebuah badan entitas; semua field header 88
di respon adalah sama seperti tubuh entitas yang hadir. Hal ini memungkinkan klien untuk mendapatkan informasi tentang sumber daya tanpa mentransfer entitas tubuh.
POST: Permintaan untuk menerima entitas dilampirkan sebagai bawahan baru untuk entitas diidentifikasi diposting URL.The adalah bawahan bahwa URL dengan cara yang sama bahwa suatu file bawahan ke direktori yang berisi itu, artikel berita adalah bawahan ke newsgroup untuk yang diposting, atau merekam adalah bawahan ke database.
PUT: Permintaan untuk menerima entitas terpasang dan menyimpannya di bawah URL yang disediakan. Ini mungkin menjadi sumber daya baru dengan URL baru atau penggantian isi dari sebuah sumber daya yang ada dengan URL yang ada. • PATCH: Mirip dengan PUT, kecuali bahwa entitas berisi daftar perbedaan dari isi sumber daya asli yang diidentifikasi dalam URL.
COPY: Permintaan bahwa salinan dari sumber daya diidentifikasi oleh URL di Garis Permintaan-akan disalin ke lokasi (s) diberikan dalam bidang URL-header di Header Entitas-pesan ini.
PINDAHKAN: Permintaan bahwa sumber daya diidentifikasi oleh URL di Garis Permintaan-dipindahkan ke lokasi (s) diberikan dalam bidang URLheader di Header Entitas-pesan ini. Setara dengan COPY diikuti oleh suatu DELETE.
DELETE: Permintaan bahwa server asal menghapus sumber daya diidentifikasi oleh URL di Line Permintaan-.
LINK: Menetapkan hubungan menghubungkan satu atau lebih dari sumber daya diidentifikasi dalam Permintaan-line.The link yang didefinisikan dalam bidang Link di Header Entitas.
Unlink: Menghapus satu atau lebih hubungan link dari sumber daya diidentifikasi dalam Line Permintaan-. Link yang didefinisikan dalam bidang Link di Header Entitas-.
89
Trace: Permintaan bahwa pengembalian apapun server yang diterima sebagai badan entitas response.This dapat digunakan untuk pengujian dan tujuan diagnostik.
Dibungkus: Memungkinkan klien untuk mengirim satu atau lebih permintaan dienkapsulasi. Permintaan dapat dienkripsi atau diproses secara lain. Server harus membuka permintaan dan proses yang sesuai.
Ekstensi-metode: Memungkinkan metode tambahan untuk didefinisikan tanpa mengubah protokol, tetapi metode ini tidak dapat diasumsikan untuk dapat dikenali oleh penerima.
PERMINTAAN HEADER FIELDS. Permintaan field header berfungsi sebagai pengubah permintaan, memberikan informasi tambahan dan parameter yang terkait dengan bidang-bidang berikut request.The didefinisikan dalam HTTP/1.1:
Menyetujui: Daftar jenis media dan rentang yang dapat diterima sebagai respon terhadap permintaan ini.
Terima-Charset: Daftar karakter set diterima untuk tanggapan.
Terima-Encoding: Daftar pengkodean konten yang dapat diterima bagi tubuh
badan.
Pengkodean
konten
terutama
digunakan
untuk
memungkinkan dokumen yang akan dikompresi atau dienkripsi. Biasanya, sumber daya disimpan dalam pengkodean ini dan hanya diterjemahkan sebelum digunakan sebenarnya.
Terima-Bahasa: Membatasi set bahasa alami yang disukai untuk respon.
Otorisasi: Berisi nilai bidang, disebut sebagai kredensial, yang digunakan oleh klien untuk mengotentikasi dirinya ke server.
Dari: Alamat e-mail Internet bagi pengguna manusia yang mengontrol user agent meminta.
Host: Menentukan host Internet dari sumber daya yang diminta.
Jika-Diubah-Sejak: Digunakan dengan metode GET. Header ini mencakup sebuah parameter tanggal / waktu, sumber daya yang akan ditransfer
90
hanya jika telah dimodifikasi sejak tanggal / waktu yang ditentukan. Fitur ini memungkinkan untuk memperbarui cache efisien. Mekanisme caching berkala dapat mengeluarkan pesan GET ke server asal, dan hanya akan menerima pesan respon kecil kecuali pembaruan tersebut diperlukan.
Proxy-Authorization: Memungkinkan klien untuk mengidentifikasi sendiri ke proxy yang memerlukan otentikasi.
Range: Untuk studi di masa depan. Tujuannya adalah bahwa, dalam pesan GET, klien dapat meminta hanya sebagian dari sumber daya diidentifikasi.
Referrer: URL dari sumber daya dari mana Permintaan-URL adalah obtained.This memungkinkan server untuk menghasilkan daftar back-link.
Kecuali: Serupa dengan fungsi Jika-Diubah-Sejak lapangan, dengan dua perbedaan: (1) Hal ini tidak terbatas pada metode GET, dan (2) perbandingan didasarkan pada nilai field Entitas-header bukan tanggal / nilai waktu.
User-Agent: Berisi informasi tentang user agent yang berasal request.This ini digunakan untuk tujuan statistik, pelacakan pelanggaran protokol, dan pengakuan otomatis agen pengguna untuk menyesuaikan respon demi untuk menghindari keterbatasan agen pengguna tertentu.
RESPON PESAN Sebuah pesan respon penuh terdiri dari baris status diikuti oleh satu atau lebih tanggapan umum,, dan header entitas, diikuti oleh badan entitas opsional.
STATUS KODE. Sebuah pesan respon penuh selalu dimulai dengan Line Status-, yang memiliki format berikut: Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF
Nilai Versi HTTP adalah nomor versi HTTP yang digunakan oleh pengirim. Status-Code adalah bilangan bulat tiga digit yang menunjukkan respon
91
terhadap permintaan diterima, dan Alasan-Frasa memberikan penjelasan tekstual pendek dari kode status. HTTP/1.1 mencakup sejumlah agak besar kode status, disusun dalam kategori berikut:
Informational: Permintaan tersebut telah diterima dan pengolahan berlanjut. Tidak ada entitas tubuh menyertai respons ini. • Sukses: Permintaan itu berhasil diterima, dipahami, dan diterima. Informasi yang kembali di pesan respon tergantung pada metode permintaan, sebagai berikut:
-
GET: Isi tubuh entitas-sesuai dengan sumber daya yang diminta.
-
KEPALA: Tidak ada entitas tubuh dikembalikan.
-
POST: Entitas menggambarkan atau berisi hasil dari tindakan.
-
TRACE: entitas ini berisi pesan permintaan.
-
Lain-lain metode: entitas ini menggambarkan hasil dari tindakan.
Redirection: tindakan lebih lanjut diperlukan untuk menyelesaikan permintaan.
Kesalahan Klien: Permintaan mengandung kesalahan sintaks atau permintaan tidak dapat dipenuhi.
Server Error: Server gagal untuk memenuhi permintaan yang tampaknya sah.
RESPONSE HEADER FIELDS. Respon field header memberikan informasi tambahan yang terkait dengan respon yang tidak dapat ditempatkan dalam Status-line.The bidang-bidang berikut didefinisikan dalam HTTP/1.1:
Lokasi: Mendefinisikan lokasi yang tepat dari sumber daya diidentifikasi oleh Request-URL.
Proxy-Otentikasi: Termasuk dengan respon yang memiliki kode status Diperlukan Otentikasi Proxy. Bidang ini berisi "tantangan" yang menunjukkan skema otentikasi dan parameter yang diperlukan.
Umum: Daftar metode tidak standar yang didukung oleh server ini. 92
Mengulang-Setelah: Termasuk dengan respon yang memiliki kode status Service Unavailable, dan menunjukkan berapa lama layanan ini diharapkan akan tersedia.
Server: Mengidentifikasi produk perangkat lunak yang digunakan oleh server asal untuk menangani permintaan.
WWW-Otentikasi: Termasuk dengan respon yang memiliki kode status tidak sah. Bidang ini berisi "tantangan" yang menunjukkan skema otentikasi dan parameter yang diperlukan.
ENTITAS Entitas terdiri dari header dan tubuh entitas entitas dalam permintaan atau pesan respon. Sebuah entitas mungkin merupakan sumber data, atau mungkin merupakan informasi lain yang disediakan dengan permintaan atau respon.
ENTITY HEADER FIELDS. Entitas field header opsional memberikan informasi tentang tubuh badan atau, jika tubuh tidak hadir, tentang sumber daya diidentifikasi oleh bidang-bidang berikut request.The didefinisikan dalam HTTP/1.1:
Izinkan: Daftar metode didukung oleh sumber daya diidentifikasi dalam Request URL-. Bidang ini harus disertakan dengan respon yang memiliki kode status Metode Tidak Diizinkan dan dapat dimasukkan dalam tanggapan lain.
Content-Encoding: Menunjukkan apa pengkodean konten telah diterapkan ke sumber daya. Pengkodean hanya saat ini didefinisikan adalah kompresi zip.
Content-Language: Mengidentifikasi bahasa alami (s) dari audiens dari entitas tertutup.
Content-Length: Ukuran tubuh entitas dalam oktet.
Content-MD5: Untuk studi di masa depan. MD5 mengacu pada fungsi kode hash MD5, dijelaskan dalam Bab 21.
93
Content-Range: Untuk maksud study.The masa depan adalah bahwa ini akan menunjukkan sebagian dari sumber daya teridentifikasi yang disertakan dalam tanggapan ini.
Content-Type: Menunjukkan jenis media entitas tubuh.
Isi-Version: Sebuah versi tag yang berhubungan dengan entitas yang berkembang.
Berasal-Dari: Menunjukkan tag versi sumber daya dari mana entitas ini berasal sebelum modifikasi yang dilakukan oleh medan sender.This dan bidang-Versi Konten dapat digunakan untuk mengelola beberapa update oleh sekelompok pengguna.
Habis: Tanggal / waktu setelah mana entitas harus dipertimbangkan basi.
Last-Modified: Tanggal / waktu yang pengirim percaya sumber daya terakhir diubah.
Link: Mendefinisikan link ke sumber informasi lainnya.
Judul: Judul tekstual untuk entitas.
Transfer-Encoding: Menunjukkan jenis transformasi telah diterapkan ke tubuh pesan untuk mentransfer dengan aman antara pengirim dan penerima. Pengkodean hanya didefinisikan dalam standar ini chunked. Opsi chunked mendefinisikan suatu prosedur untuk memecahkan suatu badan entitas ke dalam potongan berlabel yang dikirim secara terpisah.
URL-Header: Menginformasikan penerima URL lain dengan sumber daya yang dapat diidentifikasi.
Ekstensi-Header:
Memungkinkan
bidang
tambahan
untuk
didefinisikan tanpa mengubah protokol, tetapi bidang ini tidak dapat diasumsikan untuk dapat dikenali oleh penerima.
ENTITY BODY. Sebuah badan entitas terdiri dari urutan oktet sewenang-wenang. HTTP dirancang untuk dapat mentransfer semua jenis konten, termasuk teks, data biner,
94
audio, gambar, dan video.When badan entitas hadir dalam pesan, interpretasi dari oktet dalam tubuh ditentukan oleh header entitas bidang Content-Encoding, Content-Type,
dan
Transfer-Encoding.These
mendefinisikan
tiga
lapis,
memerintahkan Model pengkodean: entity-body = Transfer-Encoding (Content-Encoding(Content-Type(data)))
Data adalah isi dari sumber daya diidentifikasi oleh bidang Content-Type URL.The menentukan cara di mana data interpreted.A Content-Encoding dapat diterapkan untuk data dan disimpan di URL bukan data. Akhirnya, pada transfer, Transfer-Encoding dapat diterapkan untuk membentuk tubuh badan pesan.
BAB 24 APLIKASI INTERNET-MULTIMEDIA 24,1 Kompresi Audio dan Video 24.2 Real-Time Traffic 24,3 Voice over IP dan Dukungan-SIP Multimedia 24,4 Real-Time Transport Protocol (RTP) KUNCI TOPIK •
Session Initiation Protocol (SIP) adalah kontrol aplikasi tingkat protokol untuk mendirikan, mengubah, dan mengakhiri sesi real-time antara peserta melalui jaringan data IP.
•
SIP
menggunakan Session Description Protocol (SDP) untuk menggambarkan
konten media yang akan digunakan selama sesi. •
Real-Time Transport Protocol (RTP) adalah alternatif-transport-level ke TCP atau UDP untuk mendukung real-time lalu lintas.
Sebelum terjadi ledakan yang cukup canggih dari penelitian hal ini, para ilmuwan percaya bahwa burung tidak membutuhkan kesadaran khusus atau intelijen untuk melakukan migrasi, navigasi dan homing prestasi. Penelitian menunjukkan bahwa selain melakukan tugas-tugas sulit mengoreksi perpindahan (oleh badai, angin, pegunungan, dan
95
rintangan lainnya), burung mengintegrasikan berbagai akumulasi menakjubkan langit, atmosfer, dan geologi informasi untuk perjalanan rumah antara musim dingin dan musim panas.
Secara
mengumpulkan
singkat, berbagai
navigasi isyarat
burung
ditandai
informasi
dan
dengan
kemampuan
untuk
menafsirkan
untuk dan
mengkoordinasikan mereka agar bergerak lebih dekat menuju sasaran. The Human Nature of Birds, Theodore Barber Dengan meningkatnya ketersediaan akses broadband ke Internet telah datang suatu peningkatan minat aplikasi Multimedia berbasis Web dan Internet berbasis multimedia. Multimedia mengacu pada penggunaan berbagai bentuk informasi, termasuk teks, gambar, audio, dan video.Pembaca mungkin menemukan gunanya meninjau Bagian 2.6 sebelum melanjutkan. Perlunya diskusi mendalam tentang aplikasi multimedia adalah hal yang baik di luar ruang lingkup buku ini. Dalam bab ini, kita fokus pada topik-topik kunci. Pertama, kita melihat kompresi audio dan video, yang cukup umum dalam aplikasi multimedia.Kemudian kita memeriksa beberapa karakteristik kunci dari lintas real-time. Selanjutnya kita melihat SIP dan penggunaannya untuk mendukung voice over IP. Akhirnya, kita memeriksa real-time-transport protokol. 24.1 KOMPRESI AUDIO DAN VIDEO Dalam Bab 3, kita melihat beberapa karakteristik mendasar dari audio dan transmisi video. Kemudian Bab 5 memperkenalkan teknik seperti kode pulsa modulasi (PCM) untuk digitalisasi data audio dan video untuk transmisi digital. Untuk aplikasi multimedia, penting untuk membuat penggunaan kapasitas transmisi yang seefisien mungkin. Maka dari itu, banyak perhatian telah diberikan untuk
mengembangkan
kompresi algoritma baik untuk audio maupun transmisi video. Bagian ini memberikan gambaran umum. Teknik-teknik yang dibahas dalam bagian ini adalah standar oleh Moving Picture Expert Group (MPEG). MPEG, di bawah naungan International Organization for Standardization (ISO), telah mengembangkan standar terkait video dan audio dalam bentuk digital, dimana bentuk digital dapat disimpan pada berbagai perangkat, seperti CD-ROM, kaset, dan disk optik writable, dan ditransmisikan pada saluran komunikasi seperti ISDN dan LAN. Upaya MPEG tidak hanya mencakup kompresi video, tetapi juga kompresi audio dan isu-isu sistem yang terkait dan format. Premis dari usaha MPEG adalah bahwa sinyal video dapat dikompres untuk bit rate sekitar 1,5 Mbps dengan
96
kualitas yang dapat diterima dan efisisensi yang sesuai dapat dicapai untuk transmisi audio. Sebelum melanjutkan, kami memperkenalkan dua istilah. Kompresi data terbagi ke dalam dua kategori: lossless dan lossy. Kompresi lossless, tidak ada informasi yang hilang dan data didekompresi identik dengan data yang tidak terkompresi asli. Efisiensi kompresi lossless terbatas pada entropi, atau redundansi dari sumber data. Dengan kata lain, kompresi terbatas pada proses menghilangkan beberapa atau semua dari redundansi dalam bit stream, sehingga tidak ada informasi yang hilang. Adapun kompresi lossy, data dekompres mungkin merupakan pendekatan yang dapat diterima (menurut beberapa kriteria kebenaran) ke data asli yang belum terkompresi. Misalnya, untuk kompresi gambar atau video, mungkin gambar didekompresi tidak dapat dibedakan dari aslinya di mata manusia. Berikutnya, kita akan melihat bahwa kompresi lossy digunakan baik untuk audio dan video. Namun, dalam kasus audio, kebenaran output begitu tinggi sehingga untuk semua tujuan praktis kompresi yang digunakan adalah lossless. Kompresi Audio Langkah pertama dalam pengembangan algoritma kompresi audio untuk mendigitalkan sinyal audio, menggunakan teknik seperti PCM. Penting untuk dicatat bahwa PCM atau teknik serupa sebenarnya tidak memberikan ukuran kompresi. Ingat dari Bab 5 yang menyatakan teorema sampling yang jika sinyal f (t) adalah sampel di reguler interval waktu dan pada tingkat yang lebih tinggi dari dua kali frekuensi sinyal tertinggi, maka sampel berisi semua informasi dari sinyal asli. Fungsi f (t) dapat direkonstruksi dari sampel-sampel dengan menggunakan filter lowpass. Untuk teknik ini, untuk mereproduksi sinyal asli, sampel harus memiliki nilai-nilai analog yang telah terbatas presisi; ini dikenal sebagai Pulse Amplitudo Modulation (PAM). Untuk membuat sinyal digital, setiap sampel adalah terkuantisasi ke nilai yang dapat direpresentasikan oleh sejumlah nomor bit tetap, menghasilkan Pulse Code Modulation (PCM). Sebuah sinyal PCM-encoded hanya menghasilkan perkiraan dari sinyal asli. Jika terbatas kebenaran yang diperlukan, maka jumlah bit terbatas akan diperlukan untuk setiap sampel. Kenyataan bahwa tetap, jumlah bit terbatas yang digunakan setiap hasil sampel, pada dasarnya, dalam kompresi. Mengambil pendekatan yang berpikiran sederhana, kompresi lebih lanjut dapat dicapai dengan mengurangi frekuensi sampling atau mengurangi jumlah bit per sampel. Namun, ada pendekatan lain yang dapat menghasilkan kompresi yang signifikan saat yang sama mempertahankan kebenaran yang setara dengan
97
lossless kompresi. Seperti Pendekatan yang diambil dalam standar MPEG, standar MPEG untuk kompresi audio cukup kompleks dan di luar lingkup kita. Bahkan, standar memberikan tiga lapisan kompresi. Lapisan 3, dikenal sebagai MP3, menyediakan rasio kompresi 10 : 1. Selanjutnya, kita melihat pada pendekatan dasar yang digunakan dalam semua algoritma kompresi audio MPEG. Kompresi audio yang efektif memperhitungkan fisiologi pendengaran manusia. Algoritma kompresi memanfaatkan fenomena yang dikenal sebagai simultan auditory masking. Ini adalah efek yang dihasilkan oleh sistem saraf manusia dalam menyerap suara. Pada intinya, jika dua sinyal cukup dekat antara satu dengan yang lain, dan satu nada lebih kuat, maka sinyal yang lebih lemah tidak dirasakan sama sekali. Alat pendengaran manusia menutupinya. Dengan demikian, pendengar akan mengerti apakah ada nada lemah atau tidak. Gambar 24 secara umum menunjukkan, bagaimana masking digunakan untuk mengkodekan sinyal audio. Input dibagi menjadi waktu frame mulai dalam durasi dari 2 sampai 50 ms. Setiap waktu-frekuensi modul analisis menguraikan masing-masing frame. Secara sederhana, modul ini menentukan amplitudo di setiap urutan frekuensi yang sempit menuju analisis algoritma yang lebih kompleks yang khas. Dalam kasus apapun, output dari modul ini adalah satu set parameter yang mendefinisikan sinyal akustik dalam jangka waktu tertentu, dan yang dapat dikuantisasi. Secara paralel, modul frame psychoacoustic menganalisis waktu untuk efek masking dan properti lainnya yang dapat dieksploitasi untuk mencapai kompresi. Berdasarkan analisis, modul alokasi bit memutuskan bagaimana untuk membagi jumlah bit kode yang tersedia untuk kuantitas dari sinyal subband. Sinyal yang dihasilkan kemudian dikuantisasi dimasukkan ke dalam modul lossless coding yang menghilangkan redudansi pada sinyal digital untuk mencapai kompresi maksimum. Gambar 24.1b menunjukkan operasi invers dilakukan pada sistem tujuan untuk mereproduksi sinyal audio asli. Modul yang terbongkar menemukan kembali sinyal terkuantisasi dengan membalik sinyal kompresi lossless. Sinyal yang dihasilkan kemudian diproses untuk menghasilkan output audio.
98
99
Kompresi Video Sebuah gambar bergerak hanyalah sebuah suksesi gambar diam. Dengan demikian, seseorang dapat mencapai tingkat kompresi secara independen mengompresi setiap gambar diam dalam urutan yang membentuk gambar bergerak. Bahkan dalam gambar bergerak dengan banyak tindakan, perbedaan antara gambar diam umumnya kecil dibandingkan dengan jumlah informasi dalam satu gambar diam. Hal ini menunjukkan bahwa pengkodean perbedaan antara kedekatan gambar diam adalah pendekatan yang bermanfaat untuk kompresi, inilah alat yang digunakan dalam MPEG.
Sekilas Gambar Video Kompresi Algoritma 24,2 menggambarkan skema kompresi video MPEG. Masukan untuk kompresi modul MPEG adalah urutan frame video. Setiap frame diproses secara terpisah, diperlakukan sebagai sebuah gambar diam. Sementara pengkode MPEG berada di intraframe modus. Dalam mode ini, algoritma melakukan langkahlangkah berikut:
1. Scaling awal dan konversi warna. Setiap frame diubah menjadi representasi terstandar yang dikenal sebagai Source Input Format (SIF), dan warna informasi diterjemahkan ke dalam skema yang dikenal sebagai YUV.
100
2. Subsampling warna. Kecerahan adalah komponen warna dominan yang dilihat oleh mata manusia, sedangkan corak warna adalah kurang penting. Dengan demikian, algoritma ini dapat mengurangi informasi rona sekitar 75% dengan sedikit efek pada kebenaran subjektif.
3. Kosinus diskrit transformasi (Discrete Cosine Transformation). Proses ini memetakan setiap 8 x 8 blok poin (pixel) menjadi satu set angka mirip dengan blok transformasi Fourier. Pada dasarnya, DCT memberikan representasi domain frekuensi gambar. Transformasi ini tidak menghasilkan kompresi apapun tetapi cocok untuk menyediakan masukan tahap selanjutnya.
4. Kuantisasi. Nilai-nilai DCT terkuantisasi menjadi jumlah terbatas dari nilai kemungkinan (mirip dengan pulsa-kode modulasi kuantisasi). Kuantisasi tingkat lebih yang digunakan, lebih besar kebenaran gambar, tetapi semakin sedikit jumlah kompresi.
5. Run-length encoding. Nilai-nilai DCT terkuantisasi yang diwakili menggunakan teknik run-lenght encoding.
6. Huffman coding. Aliran data dari langkah sebelumnya dikompresi menggunakan Huffman coding, teknik kompresi lossless yang memberikan urutan bit paling umum dari langkah sebelumnya untuk simbol yang sesingkat mungkin. Meskipun kompresi yang signifikan dapat dicapai dengan hanya memproses sinyal video sebagai urutan gambar diam, seperti yang baru saja dijelaskan, pendekatan ini gagal untuk mengeksploitasi redundansi yang cukup besar hadir dalam semua rangkaian video. Biasanya, banyak dari pixel akan berubah sangat sedikit atau tidak sama sekali dari satu frame ke frame berikutnya, atau berubah hanya melibatkan pergerakan pola piksel dari satu lokasi pada frame ke lokasi yang dekat pada frame berikutnya. Penelitian MPEG mengindikasikan addinasional kompresi pada urutan faktor dari 3 [GALL91] dengan memanfaatkan redudansi ini dalam mode interframe. Untuk modus interframe, blok serupa piksel umum untuk dua atau lebih frame berturut-turut diganti oleh pointer yang merujuk salah satu blok. Komplikasi utama harus dilakukan dengan urutan frame. Kadang-kadang akan lebih mudah untuk mengacu pada blok dalam frame sebelumnya. Di lain waktu akan lebih mudah untuk merujuk ke blok dalam frame mendatang. Dalam kasus yang terakhir ini, encoder menggantikan blok dengan pointer dan juga membalikkan urutan frame. Rutinitas dekompresi harus menempatkan kembali frame dalam rangka tepat sebelum ditampilkan. Gambar 24.3 menunjukkan teknik
101
interframe dalam cara yang sangat umum. Setelah fase DCT dan kuantisasi dalam pengolahan frame, frame berjalan melalui proses sebaliknya (dequantization, invers DCT) dalam rangka untuk memulihkan frame yang identik dengan yang akan dipulihkan oleh algoritma dekompresi. Frame ini kemudian disimpan dan digunakan dalam modus interframe untuk dibandingkan frame yang berhasil. Dalam merancang algoritma kompresi video, kelompok studi MPEG mengidentifikasi sejumlah fitur yang penting dalam rangka memenuhi berbagai aplikasi dari MPEG. Dua hal ini relevan dengan diskusi kita: •
Random Acces: Sebuah video bit stream yang dikompres harus dapat diakses di setiap titik dalam urutan frame video, dan frame apapun harus membaca kode dalam waktu yang terbatas. Hal ini menyiratkan adanya frame akses, yang mana frame hanya dikodekan dalam mode intraframe dan karenanya dapat diterjemahkan tanpa referensi ke frame lain.
•
Fast forward/reverse searches: harus memungkinkan untuk memindai bit stream yang dikompres dan menggunakan frame akses yang sesuai, menampilkan frame yang dipilih untuk mendapatkan efek fast forward or fast reverse. Fitur ini pada dasarnya lebih menuntut bentuk fitur akses acak.
Kompensasi Gerak Dasar dari kompresi interframe MPEG adalah kompensasi gerak. Ide dibalik kompensasi gerak adalah bahwa sebagian dari gambar dalam satu frame akan sama atau sangat mirip dengan porsi yang sama besar dalam frame di dekatnya. Skema MPEG menggunakan dua bentuk kompensasi gerak: prediksi dan interpolasi. Prediksi MPEG memanfaatkan blok 16 x 16 piksel, yang disebut blok makro (berberbeda dengan yang lebih kecil, yaitu blok 8 x 8 digunakan dalam pengkodean DCT), untuk tujuan kompensasi gerak. Sebuah frame diproses dalam mode prediksi dibagi menjadi macrobloknya, masing-masing dikodekan secara terpisah. Pengkodean dilakukan dengan mengacu jangkar frame yang mendahului frame saat itu. Setiap makroblok dalam frame sekarang akan diwakili oleh pointer, yang disebut vektor gerak, untuk itu makroblok dalam rangka jangkar yang paling dekat sesuai dengan makroblok ini. Vektor gerak memberikan perpindahan makroblok dalam frame saat ini sehubungan dengan kesesuaian di frame jangkar.
102
Hal ini ditampilkan di bagian kiri dua-pertiga dari Gambar 24.3. Dalam contoh ini, setiap frame video terdiri dari 64 x 64 piksel dikelompokkan menjadi 16 blok makro. Bagian yang diarsir dari arus frame adalah makroblok yang bagian pixel atas kiri dalam posisi x-y (16, 8). Kesesuaian untuk blok ini pada frame sebelumnya adalah di posisi (24, 4). Tanda panah garis pendek di frame sebelah kiri mewakili vektor gerak, yang dalam hal ini adalah (8, -4). Kunci aspek prediksi pengkodean: 1. Makroblok yang cocok di frame sebelumnya tidak perlu pada batas 16-piksel. 2. Pencocokan ini tidak dilakukan terhadap sumber video frame sebelumnya melainkan terhadap frame video yang telah melalui kompresi dan dekompresi karena modul dekompresi tidak memiliki akses ke sumber video frame tetapi hanya untuk versi didekompresi dari frame asli. Setelah menentukan blok yang sesuai dari frame sebelumnya, algoritma MPEG mencatat vektor gerak dan kesalahan prediksi, yang mana 16 x 16 matriks perbedaan antara makroblok saat ini, dalam frame c, dan referensi makroblok, dalam frame r:
Dimana Ec (x, y) adalah kesalahan prediksi, Ii (x, y) adalah nilai dari pixel yang terletak pada posisi (x, y) di frame i, dan Mij adalah vektor gerak untuk frame j relatif terhadap frame i.
103
Dengan demikian, frame saat ini dipetakan ke dalam sebuah matriks nilai kesalahan prediksi, satu untuk setiap posisi pixel, dan nilai-nilai gerak vektor, satu untuk setiap makroblok. Prediksi kesalahan matriks akan memiliki banyak nilai nol. Matriks ini dikodekan menggunakan teknik DCT-kuantisasi dan harus menghasilkan rasio kompresi lebih tinggi dari pengkodean sederhana piksel matriks asli. Standar MPEG tidak mendikte bagaimana proses pencocokan yang harus dilakukan. Biasanya, vektor gerak untuk sebuah makroblok diperoleh dengan meminimalkan biaya fungsi yang mengukur perbedaan antara makroblok dan prediktor setiap kandidat. Perhitungan dapat dinyatakan sebagai berikut:
Dimana
Nilai m yang meminimalkan ekspresi sebelumnya digunakan sebagai gerak vektor Mrc untuk blok ini. Rentang pencarian dapat mencakup lingkup kecil pemindahan atau bisa berkisar hingga ukuran seluruh frame. Interpolasi Meskipun demikian, hasil prediksi rasio kompresi lebih tinggi daripada kompresi frame-by frame sederhana lebih dapat dilakukan. Secara khusus, MPEG memungkinkan beberapa frame video yang akan dikodekan menggunakan dua frame referensi, satu di masa lalu dan satu di masa mendatang. Pendekatan ini, disebut interpolasi dua arah, hasil kompresi rasio yang lebih tinggi dari prediksi didasarkan pada satu frame referensi. Untuk melihat mengapa interpolasi dua arah dapat meningkatkan hasil, pertimbangkan adegan yang bergerak sehubungan dengan frame foto pada tingkat setengah pixel per frame. Jika kita mencoba untuk memprediksi makroblok pada frame saat ini seketika dengan frame sebelumnya, justru blok yang bersesuaian tidak ditemukan. Demikian pula, tidak ada yang tepat cocok untuk makroblok akan ditemukan dalam frame selanjutnya. Bagaimanapun juga, rata-rata kecocokan terbaik dari frame
104
sebelumnya dan berikutnya menyediakan prediksi yang tepat, sehingga kesalahan matriks semuanya nol. Gambar 24.3 menggambarkan teknik yang digunakan dalam interpolasi dua arah. Para frame saat ini, disebut sebagai frame B, diproses terhadap dua frame referensi, satu frame sebelum dan satu frame setelahnya di waktu itu. Setiap makroblok dapat dikodekan menggunakan satu blok dari frame sebelumnya (prediksi ke depan), frame berikut
(prediksi mundur), atau satu blok dari setiap frame referensi (rata-rata), mana saja yang memberikan kesalahan matriks minimal. Tabel 24.1 merangkum perhitungan untuk setiap opsi, dengan frame 1 menjadi frame saat ini, frame 0 frame referensi sebelumnya, dan frame 2 frame referensi berikutnya. Dalam kasus interpolasi dua arah, informasi lebih lanjut harus dikodekan. Seperti frame yang diprediksi, matriks perbedaan diproduksi dan kemudian dikodekan menggunakan DCT. Selain itu, setiap makroblok dikodekan dengan indikasi modus prediksi (maju, mundur, rata-rata) dan satu atau dua vektor gerak. Frame Pengurutan Tiga jenis frame didefinisikan dalam MPEG: •
Intraframe (I): Dikodekan dalam gaya JPEG sebagai gambar yang masih independen
•
Prediksi (P): Dikodekan dengan mengacu ke frame jangkar sebelumnya
•
Interpolasi Du Arah (B): Dikodekan dengan mengacu pada frame jangkar sebelumnya dan frame jangkar berikutnya. Frekuensi relatif dari jenis frame dalam aliran video adalah parameter
terkonfigurasi dan harus memenuhi beberapa pengorbanan. Pertama, ada kebutuhan untuk memenuhi persyaratan untuk akses acak dan pencarian fast forward/reverse,
105
dijelaskan sebelumnya. Persyaratan ini menempatkan keterikatan yang lebih rendah pada fraksi I frame dalam aliran dikodekan. Kedua, ada tradeoff antara kompleksitas komputasi dan jumlah frame B: lebih banyak frame B berarti lebih banyak komputasi. Akhirnya, frame B hanya dapat diproses sehubungan dengan frame I dan P, yaitu, satu Frame B tidak dapat berfungsi sebagai frame acuan bagi selain frame B. Oleh karena itu, lebih tinggi fraksi frame B, semakin besar jarak rata-rata antara frame B dengan referensinya dan yang korelasi kurang antara frame B dan referensi framenya. Aturan untuk encoding adalah sebagai berikut. Setiap frame I dikodekan menggunakan coding intraframe saja. Setiap frame P dikodekan berdasarkan yang paling terakhir sebelum frame I atau P, mana yang terdekat. Setiap frame B dikodekan dengan yang paling dekat sebelum atau sesuBYE frame I atau P. Gambar frame dalam MPEG disusun dalam kelompok. Setiap kelompok terdiri dari frame tunggal I diikuti oleh sejumlah frame P dan frame B. Karena frame B tidak dapat diterjemahkan sampai kedua-nya, frame sebelum dan sesuBYEnya referensi diterjemahkan, anggota kelompok direorganisasi sehingga setiap frame B mengikuti kedua referensi frame tersebut.
106
Gambar 24.4 memberikan contoh. Enam frame pertama membentuk kelompok. Frame 4 disimpan setelah frame 1, karena digunakan sebagai prediksi frame ke depan untuk B frame 2 dan 3. Frame 5 dan 6 ditukarkan untuk alasan yang sama. B frame 7 dicatat sebagai bagian dari kelompok berikutnya karena dikodekan setelah I frame 8. 24.2 REAL-TIME TRAFFIC Penyebaran luas LAN dan WAN kecepatan tinggi dan peningkatan dalam garis kapasitas Internet dan Internets lainnya telah membuka kemungkinan menggunakan jaringan berbasis IP untuk pengangkutan lintas real-time. Namun, cukup penting untuk mengakui bahwa persyaratan real-time traffic berbeda dari tinggi-kecepatannya namun lalu lintas non-real-time. Dengan aplikasi internet tradisional, seperti transfer file, surat elektronik, aplikasi dan klien / server termasuk Web, metrik kinerja dari ketertarikan umumnya terbatas dan lambat. Juga menjadi perhatian dengan keandalan dan mekanisme
107
yang digunakan untuk memastikan bahwa tidak ada data yang hilang, rusak, atau salah tujuan selama pengangkutan. Sebaliknya, aplikasi real-time lebih memperhatikan masalah waktu. Dalam kebanyakan kasus, ada persyaratan bahwa data akan disampaikan pada tingkat yang konstan sama dengan tingkat pengiriman. Dalam kasus lain, tenggat waktu terkait dengan setiap blok data, seperti bahwa data tidak dapat digunakan setelah batas waktu telah berakhir.
Karakteristik Traffic Real-Time Gambar 24.5 mengilustrasikan tipe lingkungan real-time. Di sini, server menghasilkan audio yang akan ditransmisikan pada 64 kbps. Audio yang digitalkan ditransmisikan dalam paket yang berisi 160 oktet data, sehingga satu paket dikeluarkan setiap 20 ms. Paket ini dilewatkan melalui internet dan dikirimkan ke PC multimedia,
108
yang memainkan audio secara real time. Namun, karena keterlambatan variabel dikenakan oleh Internet, waktu interarrival antara paket tidak dipertahankan tetap pada 20 ms di tempat tujuan. Untuk mengkompensasi hal ini, paket-paket masuk buffer, tertunda sedikit, dan kemudian dilepaskan pada tingkat konstan untuk perangkat lunak yang menghasilkan audio. Kompensasi yang diberikan oleh penundaan buffer adalah terbatas. Untuk memahami hal ini, kita perlu mendefinisikan konsep jitter delay, yang merupakan variasi maksimum dalam keterlambatan yang dialami oleh paket dalam satu sesi. Sebagai contoh, jika minimum penundaan end-to-end yang dilihat oleh semua paket adalah 1 ms dan maksimal adalah 6 ms, maka penundaan jitternya adalah 5 ms. Sepanjang waktu penundaan buffer, penundaan paket masuk dengan minimal 5 ms, maka output dari buffer akan mencakup semua paket yang masuk. Namun, jika penyangga paket tertunda hanya dengan 4 ms, maka setiap paket masuk yang telah berpengalaman, penundaan relatifnya lebih dari 4 ms (keterlambatan absolut lebih dari 5 ms) harus dibuang sehingga paket yang rusak tidak akan dimainkan kembali. Deskripsi real-time traffic sejauh ini menyiratkan serangkaian paket ukuran-sama yang dihasilkan pada rate konstan. Hal ini tidaklah selalu berupa profil lalu lintas.
Gambar 24,6 menggambarkan beberapa kemungkinan umum: •
Sumber data yang terus-menerus: ukuran paket tetap dihasilkan pada interval yang tetap. Ciri aplikasi ini yang terus-menerus menghasilkan data, memiliki sedikit redudansi, dan yang sangat penting untuk kompres dalam lossy way. Contohnya , kontrol radar lalu lintas udara dan simulasi real-time.
•
Sumber on/ off: Sumber bergantian antara periode ketika paket berukuran tetap dihasilkan pada interval yang tetap dan periode dari ketidakaktifan. Sebuah sumber suara, seperti dalam konferensi telepon atau konferensi audio, cocok dengan profil ini.
109
•
Ukuran Paket Variabel: Sumber menghasilkan paket variabel-panjang pada interval seragam. Sebuah contoh adalah video digital di mana frame yang berbeda mungkin berpengalaman rasio kompresi yang berbeda untuk tingkat kualitas output yang sama.
Persyaratan komunikasi Real-Time [ARAS94] mendata hal berikut sebagai sifat yang diinginkan untuk komunikasi real-time: •
Jitter rendah
•
Latency rendah
•
Kemampuan untuk mengintegrasikan non-real-time dan real-time dengan mudah
•
Beradaptasi secara dinamis dengan perubahan kondisi jaringan dan lalu lintas
•
Kinerja baik untuk jaringan besar dan sejumlah besar koneksi
•
Persyaratan buffer sederhana dalam jaringan
•
Utilisasi kapasitas tinggi yang efektif
•
Overhead rendah dalam bit header per paket
•
Overhead pemrosesan per paket rendah dalam jaringan dan pada sistem akhir Persyaratan ini sulit untuk bertemu di sebuah wilayah yang jaringan berbasis IP
atau Internet-nya luas. Baik TCP maupun UDP dengan sendirinya adalah cocok. Kita akan melihat bahwa RTP menyediakan landasan wajar untuk mengatasi masalah ini. Hard and Soft Real-Time Applications Suatu pembedaan harus dibuat antara aplikasi komunikasi hard dan soft realtime. Aplikasi soft real-time dapat mentolerir kehilangan beberapa bagian dari data yang dikomunikasikan, sementara aplikasi hard real-time memiliki nol toleransi kerugian. Secara umum, aplikasi soft real-time memberlakukan persyaratan yang lebih sedikit pada jaringan, dan oleh karena itu diperbolehkan untuk fokus memaksimalkan pemanfaatan jaringan, bahkan pada biaya dari beberapa paket yang hilang atau salah pesan. Dalam aplikasi hard real-time, deterministik
batas atas jitter dan kehandalan yang tinggi
didahulukan atas pertimbangan pemanfaatan jaringan.
110
24,3 Voice over IP dan DUKUNGAN MULTIMEDIA -SIP Session Initiation Protocol (SIP), yang didefinisikan dalam RFC 3261, adalah sebuah aplikasi tingkat kontrol protokol untuk mendirikan, mengubah, dan mengakhiri sesi realtime antara peserta melalui jaringan data IP. Latar belakang yang mendorong adanya SIP adalah untuk memungkinkan telepon Internet, juga disebut sebagai voice over IP (VoIP). SIP dapat mendukung semua jenis media tunggal atau sesi multimedia, termasuk telekonferensi. SIP mendukung lima aspek dalam membangun dan mengakhiri komunikasi multimedia: •
Lokasi user: Pengguna dapat pindah ke lokasi lain dan mengakses telepon atau fitur aplikasi lain dari lokasi terpencil.
•
Ketersediaan User: Penentuan kesediaan pihak dipanggil untuk terlibat dalam komunikasi.
•
Kemampuan User : Penentuan media dan parameter media yang akan digunakan.
•
Sesi setup: setup up point-to-point dan panggilan multipartai, dengan parameter sesi yang disetujui.
•
Manajemen Sesi: Termasuk transfer dan pemutusan sesi, memodifikasi parameter sesi, dan memanggil layanan. SIP menggunakan elemen desain yang dikembangkan untuk protokol
sebelumnya. SIP berbasis pada HTTP seperti permintaan / respon model transaksi. Setiap transaksi terdiri dari permintaan klien yang memanggil metode tertentu, atau fungsi, pada server dan setidaknya satu tanggapan. SIP menggunakan sebagian besar field header, aturan pengkodean, dan kode status HTTP. Ini menyediakan sebuah format berbasis teks yang dapat dibaca untuk menampilkan informasi. SIP juga menggunakan konsep serupa dengan rekursif dan iteratif pencarian DNS. SIP menggabungkan penggunaan Session Description Protocol (SDP), yang mendefinisikan konten sesi menggunakan satu set tipe yang sama dengan yang digunakan dalam MIME. Komponen SIP dan Protokol Sebuah jaringan SIP dapat dilihat dari komponen yang menyususn yang didefinisikan pada dua dimensi: klien/ server dan elemen jaringan individu. RFC 3261 mendefinisikan klien dan server sebagai berikut:
111
•
Klien: Klien adalah setiap elemen jaringan yang mengirimkan permintaan SIP dan menerima tanggapan SIP. Klien mungkin atau tidak mungkin berinteraksi langsung dengan pengguna manusia. Agen klien pengguna dan proxy adalah klien.
•
Server: Server adalah elemen jaringan yang menerima permintaan untuk layanan permintaan tersebut dan mengirimkan kembali tanggapan terhadap permintaan tersebut. Contoh server adalah proxy, server agen pengguna, redirect server, dan pendaftar. Unsur-unsur individu jaringan SIP standar adalah sebagai berikut:
•
User Agent: berada di setiap stasiun akhir SIP. Bertindak dalam dua peran:
-
User Agent Client (UAC): permintaan isu SIP
-
User Agent Server (UAS): menerima permintaan SIP dan menghasilkan respon yang menerima, menolak, atau mengalihkan permintaan.
•
Redirect Server: Digunakan selama sesi inisiasi untuk menentukan alamat dari perangkat yang dipanggil. Redirect Server mengambalikan informasi ini ke perangkat menelepon, mengarahkan UAC untuk menghubungi URI alternatif. Ini adalah analogi untuk pencarian iteratif dalam DNS.
•
Proxy Server: Sebuah perantara entitas yang bertindak baik sebagai server dan klien untuk tujuan membuat permintaan atas nama klien lainnya. A server proxy lainnya terutama memainkan peran routing, yang berarti tugasnya adalah untuk memastikan bahwa permintaan dikirim ke entitas lain lebih dekat kepada pengguna yang ditargetkan. Proxy juga berguna untuk menegakkan kebijakan (misalnya, memastikan pengguna diperbolehkan untuk membuat panggilan). Sebuah proxy menafsirkan, dan, jika perlu, menulis ulang bagian-bagian tertentu dari sebuah pesan sebelum menyampaikannya. Inilah analog untuk pencarian rekursif dalam DNS.
•
Pendaftar: Sebuah server yang menerima permintaan DAFTAR dan menempatkan informasi yang diterimanya (alamat SIP dan alamat IP yang terkait dari perangkat pendaftaran) dalam permintaan tersebut ke lokasi layanan untuk domain yang ditangani.
•
Lokasi Layanan: Sebuah layanan lokasi tersebut digunakan oleh pengalih SIP atau server proxy untuk mendapatkan informasi tentang lokasi kemungkinan memanggil. Untuk tujuan ini, layanan lokasi memelihara sebuah database alamat-SIP / pemetaan IP-address. Berbagai server didefinisikan dalam RFC 3261 sebagai perangkat logis.
112
Berbagai server tersebut bisa jadi diimplementasikan sebagai server terpisah yang terkonfigurasi di Internet atau mereka mungkin digabungkan menjadi sebuah aplikasi tunggal yang berada dalam server fisik. Gambar 24.7 menunjukkan bagaimana beberapa komponen SIP berhubungan satu sama lain dan protokol yang dipekerjakan. Seorang agen pengguna bertindak sebagai klien (dalam hal ini UAC alice) menggunakan SIP untuk mendirikan sebuah sesi dengan agen pengguna yang akan bertindak sebagai server (dalam hal ini kasus UAS bob). Dialog sesi inisiasi menggunakan SIP dan melibatkan satu atau lebih server proxy untuk meneruskan permintaan dan respon antara dua agen pengguna. Para agen pengguna juga memanfaatkan Deskripsi Session Protocol (SDP), yang digunakan untuk menggambarkan sesi media.
Server proxy juga dapat bertindak sebagai server redirect yang diperlukan. Jika redirection dilakukan, server proxy perlu untuk berkonsultasi dengan database lokasi layanan, yang mungkin menempatkan dengan server proxy ataukah tidak. Antara server proxy dan layanan lokasi adalah di luar lingkup standar SIP. DNS adalah juga merupakan
113
bagian yang penting dari operasi SIP. Biasanya, UAC akan membuat permintaan menggunakan nama domain dari UAS, daripada alamat IP. Sebuah server proxy perlu berkonsultasi dengan server DNS untuk menemukan server proxy untuk target domain. SIP biasanya berjalan di atas UDP untuk alasan kinerja, dan memberikan kehandalan mekanisme sendiri, tetapi juga dapat menggunakan TCP. Jika transportasi, aman terenskripsi mekanisme yang diinginkan, pesan SIP alternatif dapat diteruskan Transportasi Layer Security (TLS) protokol, dijelaskan dalam Bab 21. Terkait dengan SIP adalah Session Description Protocol (SDP), didefinisikan dalam RFC 2327. SIP digunakan untuk mengundang satu atau lebih peserta ke sesi, sementara SDP- tubuh dikodekan dari pesan SIP berisi informasi tentang media apa yang dikodekan (misalnya, suara, video) para pihak dapat dan akan digunakan. Setelah informasi ini dipertukarkan dan diakui, semua peserta menyadari peserta alamat IP, kapasitas transmisi yang tersedia, dan jenis media. Kemudian transmisi data dimulai, menggunakan protokol transport yang sesuai. Biasanya, Transportasi Real-Time Protokol (RTP), dijelaskan kemudian, digunakan. Sepanjang sesi, peserta dapat membuat perubahan pada parameter sesi, seperti jenis media baru atau pihak baru sesi, menggunakan pesan SIP. SIP Uniform Resource Identifier Sebuah sumber daya dalam jaringan SIP diidentifikasi oleh sebuah Uniform Resource Identifier (URI). Contoh sumber daya komunikasi meliputi: •
Seorang pengguna dari sebuah layanan online
•
Sebuah tampilan pada telepon multiline
•
Sebuah kotak pesan pada sistem pesan
•
Sebuah nomor telepon pada layanan gerbang
•
Sebuah kelompok (seperti "penjualan" atau "helpdesk") dalam sebuah organisasi SIP URI memiliki format berdasarkan format alamat email, yaitu user @ domain.
Ada dua pola umum. Sebuah SIP biasa adalah dalam bentuk sip:
[email protected]
114
URI mungkin juga termasuk password, nomor port, dan parameter terkait. Jika transmisi yang aman diperlukan, "sip:" diganti dengan "sips:". Dalam kasus terakhir, pesan SIP diangkut melalui TLS. Contoh Operasi Spesifikasi SIP cukup kompleks; dokumen utama, RFC 3261, adalah sepanjang 269 halaman. Untuk memberikan beberapa perasaan untuk operasinya, kami menyajikan beberapa contoh. Gambar 24.8 menunjukkan upaya gagal oleh pengguna Alice untuk membangun sesi dengan user Bob, yang mana URI
[email protected] UAC Alice dikonfigurasi untuk komunikasi dengan server proxy (server outbound) dalam domainnya dan mulai dengan mengirim pesan INVITE ke server proxy yang menunjukkan keinginannya untuk mengundang UAS Bob ke sesi (1); server mengakui permintaan (2) Meskipun UAS Bob diidentifikasi oleh URInya, server proxy outbound perlu mempertimbangkan kemungkinan bahwa Bob saat ini tidak tersedia atau bahwa Bob telah telah berpindah. Maka, outbound proxy server harus meneruskan permintaan INVITE ke server proxy yang bertanggungjawab untuk domain biloxi.com. Outbond proxy berkonsultasi dengna server DNS lokal untuk mendapatkan alamat IP dari server biloxi.comproxy (3), dengan meminta catatan sumber daya SRV (Tabel 23.2) yang berisi informasi pada server proxy untuk biloxi.com. Server DNS merespon (4) dengan alamat IP dari server proxy biloxi.com (server inbound). Proxy server Alice sekarang dapat mengirim pesan INVITE untuk server proxy inbound (5), yang mengakui pesan (6). Proxy server inbound sekarang berkonsultasi dengan server lokasi untuk menentukan lokasi Bob (7), dan server lokasi menjawab bahwa Bob tidak masuk, dan karena itu pesan SIP tidak tersedia (8). Informasi ini dikomunikasikan kembali ke outbound server proxy (9, 10) dan kemudian ke Alice (11, 12). 1Gambar 24.8 melalui 24,11 diadaptasi dari salah satu yang dikembangkan oleh Profesor Charles H. Baker dari Southern Methodist University.
115
Contoh berikutnya (Gambar 24.9) menggunakan dua jenis pesan yang belum merupakan bagian dari standar SIP, tetapi yang didokumentasikan dalam RFC 2848 dan kemungkinan akan dimasukkan dalam revisi jenis pesan SIP kemudian. Tipe pesan ini mendukung aplikasi telpon. Pada bagian akhir contoh sebelumnya, Alice diberitahu bahwa Bob tidak tersedia. UAC Alice kemudian mengisukan pesan SUBSCRIBE (1), menunjukkan bahwa ia ingin menginformasikan ketika Bob telah tersedia. Permintaan ini diteruskan melalui dua proxy dalam contoh ke server PINT (PSTN-Internet Networking)2 (2, 3). Sebuah server PINT bertindak sebagai gateway antara jaringan IP yang mendatangkan permintaan untuk menempatkan telepon panggilan dan jaringan telepon yang mengeksekusi panggilan dengan menghubungkan ke tujuan telepon. Dalam contoh ini, kita berasumsi bahwa logika server PINT adalah ditempatkan dengan lokasi layanan. Hal ini juga bisa menjadi kasus bahwa Bob terpasang ke Internet lebih dari PSTN, dalam
116
hal ini setara dengan logika PINT diperlukan untuk menangani permintaan SUBSCRIBE. Dalam contoh ini, kita mengasumsikan yang terakhir itu dan menganggap bahwa fungsi PINT diimplementasikan dalam layanan lokasi. Dalam kasus apapun, layanan lokasi kewenangan berlangganan dengan mengembalikan pesan OK (4), yang dilewatkan kembali ke Alice (5, 6) Layanan lokasi kemudian. Segera mengirim pesan NOTIFY dengan
status tidak masuk Bob (7, 8, 9), yang UAC Alice nyatakan (10, 11, 12)
2PSTN adalah jaringan telepon umum diaktifkan.
Gambar 24,10 melanjutkan contoh dari Gambar 24.9. Bob sign on dengan mengirimkan DAFTAR pesan ke proxy dalam domainnya (1). Proxy meng-update database di lokasi layanan untuk mencerminkan pendaftaran (2). Pembaruan ini dikonfirmasi ke proxy (3), yang mng-confirm pendaftaran kepada Bob (4). Fungsionalitas PINT belajar mempelajari status baru Bob dari lokasi server (di sini kita mengasumsikan bahwa mereka ditempatkan) dan mengirim pesan NOTIFY berisi status baru Bob (5),
117
yang diteruskan ke Alice (6, 7). UAC Alice menjawab penerimaan pemberitahuan (8, 9, 10). Sekarang Bob terdaftar, Alice dapat mencoba kembali untuk mendirikan sesi, seperti yang ditunjukkan pada Gambar 24.11. Angka ini menunjukkan aliran yang sama seperti Gambar 24.8, dengan beberapa perbedaan. Kita berasumsi bahwa proxy server Alice memiliki cache alamat IP dari proxy server untuk domain biloxi.com, dan karena itu tidak perlu berkonsultasi dengan DNS server. Sebuah respon dering dikirim dari Bob kembali ke Alice (8, 9, 10) sedangkan UAS di Bob menyiagakan aplikasi media lokal (misalnya, telepon). Ketika aplikasi media menerima panggilan, UAS Bob mengirimkan kembali suatu respon OK untuk Alice (11, 12, 13). Akhirnya, UAC Alice mengirim pesan jawaban untuk UAS Bob untuk mengkonfirmasi penerimaan respon akhir (14). Dalam contoh ini, ACK dikirim langsung dari Alice ke Bob, melewati dua proxy. Hal ini terjadi karena poin akhir telah mempelajari masing-masing alamat dari pertukaran INVITE/200 (OK), yang tidak diketahui kapan inisial INVITE dikirim. Sesi media sekarang dimulai, Alice dan Bob dapat bertukar data melalui koneksi RTP.
118
Pesan SIP Seperti telah disebutkan, SIP adalah protokol berbasis teks dengan sintaks yang mirip dengan HTTP. Ada dua jenis SIP, permintaan pesan dan tanggapan. Perbedaan format antara dua jenis pesan terlihat di baris pertama. Baris pertama dari permintaan memiliki metode, mendefinisikan sifat permintaan dan Permintaan-URI, menunjukkan di mana permintaan harus dikirim. Baris pertama dari sebuah respon memiliki sebuah kode pesan. Semua pesan termasuk header, yang terdiri dari angka baris, setiap baris dimulai dengan label header pesan. Sebuah pesan juga dapat berisi tubuh, seperti deskripsi media SDP. Permintaan SIP RFC 3261 mendefinisikan metode berikut: •
DAFTAR: Digunakan oleh agen pengguna untuk memberitahukan jaringan SIP tentang alamat IP saat ini dan URL yang akan menerima panggilan
•
INVITE: Digunakan untuk membangun sebuah sesi media antara agen pengguna
•
ACK: mengkonfirmasi pertukaran pesan yang dapat diandalkan
•
BATAL: Menghentikan permintaan yang tertunda, tetapi tidak membatalkan panggilan yang selesai
•
BYE: Menghentikan sesi antara dua pengguna dalam sebuah konferensi
119
• PILIHAN: mengumpulkan informasi tentang kemampuan callee, tetapi tidak membuat panggilan Misalnya, header pesan (1) pada Gambar 24,11 mungkin terlihat seperti ini: INVITE sip:
[email protected] SIP/2.0 Via: SIP/2.0/UDP 12.26.17.91:5060 Max-Forwards: 70 To: Bob <sip:
[email protected]> From:Alice <sip:
[email protected]>;tag=1928301774 Call-ID:
[email protected] CSeq: 314159 INVITE Contact: <sip:
[email protected]>
120
Content-Type: application/sdp Content-Length: 142 Jenis tebal yang digunakan untuk label header tidak khas tetapi digunakan di sini untuk kejelasan. Baris pertama berisi nama metode (INVITE), SIP URI, dan versi jumlah SIP yang digunakan. Garis-garis yang mengikuti adalah daftar kolom header. Contoh ini berisi set minimum yang diperlukan. Via header menunjukkan jalan permintaan telah diambil dalam jaringan SIP (sumber dan intervensi proxy) dan digunakan untuk tanggapan rute kembali sepanjang jalan yang sama. Dalam pesan (1), hanya ada satu Via header, yang dimasukkan oleh Alice. Baris Via berisi Alamat IP (12.26.17.91), nomor port (5060), dan protokol transport (UDP) yang Alice inginkan Bob untuk menggunakannya dalam responnya. Proxy selanjutnya menambahkan tambahan Via header. Max-Forwards berfungsi untuk membatasi jumlah permintaan hop yang dapat membuat di jalan menuju tujuannya. Ini terdiri dari integer yang dikurangi oleh satu oleh setiap proxy yang meneruskan permintaan tersebut. Jika nilai Max-Forwards mencapai 0 sebelum permintaan mencapai tujuan, maka akan ditolak dengan respon kesalahan 483 (Hops Terlalu Banyak). Untuk mengetahui nama tampilan (Bob) dan URI SIP atau SIPS (sip:
[email protected]) ke arah mana permintaan itu mula-mula diarahkan. Dari juga berisi nama tampilan (Alice) dan sebuah SIP atau SIPS URI (sip:
[email protected]) yang mengindikasikan pemula dari permintaan. Kolom header juga memiliki tag parameter berisi string acak (1928301774) yang ditambahkan ke URI oleh UAC. Hal ini digunakan untuk mengidentifikasi sesi. Call-ID berisi pengenal global yang unik untuk panggilan ini, yang dihasilkan oleh kombinasi string acak dan nama host atau alamat IP. Kombinasi dari To tag, From tag, dan Call-ID benar-benar mendefinisikan hubungan SIP peer-to-peer antara Alice dan Bob dan disebut sebagai dialog. CSeq atau Command Sequence (urutan perintah) berisi integer dan nama metode. Nomor CSeq diinisialisasi pada awal panggilan (314159 dalam contoh ini), tambahan untuk setiap permintaan baru dalam dialog, dan merupakan nomor urut tradisional. CSeq ini digunakan untuk membedakan transmisi dari sebuah permintaan baru. Contact Header berisi URI SIP untuk komunikasi langsung antara UAs. Ketika kolom Via header mengatakan unsur-unsur lain di mana mengirim respon, Contact header mengatakan unsur-unsur lain di mana mengirim permintaan mendatang untuk dialog ini. Content-
121
Type menunjukkan jenis badan pesan. Content-Length memberikan panjang dalam oktet tubuh pesan. Respon SIP Jenis respon didefinisikan dalam RFC 3261 adalah kategori sebagai berikut: •
Provisional (Sementara) (1xx): Permintaan diterima dan sedang diproses.
•
Success (Sukses) (2xx): Tindakan tersebut berhasil diterima, dipahami, dan diterima.
•
Redirection (3xx): Tindakan selanjutnya perlu diambil dalam rangka untuk menyelesaikan permintaan.
•
Client Error (Kesalahan Klien) (4xx): Permintaan berisi sintaks yang buruk atau tidak dapat dipenuhi pada server ini.
•
Server Error (5xx): Server gagal untuk memenuhi permintaan yang tampaknya sah.
•
Global Failure (Kegagalan global) (6xx): Permintaan tidak dapat dipenuhi pada server apapun.
Misalnya, header pesan (11) pada Gambar 24,11 mungkin terlihat seperti ini: SIP/2.0 200 OK Via: SIP/2.0/UDP server10.biloxi.com Via: SIP/2.0/UDP bigbox3.site3.atlanta.com Via: SIP/2.0/UDP 12.26.17.91:5060 Untuk: Bob <sip:
[email protected]>; tag = a6c85cf Dari: Alice <sip:
[email protected]>; tag = 1928301774 Call-ID:
[email protected] CSeq: 314159 INVITE Kontak: sip:
[email protected] Content-Type: application / sdp Content-Length: 131
122
Baris pertama berisi nomor versi SIP yang digunakan dan kode respon dan namanya . Baris yang mengikuti adalah daftar kolom header. Via, Untuk, Dari, Call- ID, dan kolom header CSeq disalin dari permintaan INVITE. (Ada tiga nilai-nilai kolom header Via yang ditambahkan oleh SIP UAC Alice, satu ditambah dengan atlanta.com proxy, dan satu ditambahkan oleh proxy biloxi.com) SIP telepon Bob telah menambahkan parameter tag ke kolom header. Tag ini akan disatukan oleh kedua endpoint ke dalam dialog dan akan dimasukkan dalam semua permintaan mendatang dan tanggapan dalam panggilan ini. Sesi Deskripsi Protokol Session
Description
Protocol
(SDP),
didefinisikan
dalam RFC
2327,
menggambarkan isi sesi, termasuk aplikasi telepon, radio internet, dan multimedia. SDP mencakup informasi tentang hal berikut [SCHU99]: •
Media stream: Sesi dapat mencakup beberapa aliran konten yang berbeda. SDP saat ini mendefinisikan audio, video, data, kontrol, dan aplikasi sebagai aliran jenis, mirip dengan jenis MIME yang digunakan untuk mail Internet (Tabel 22.3).
•
Addresses (Alamat): Menunjukkan alamat tujuan, yang mungkin alamat multicast, untuk streaming media.
•
Ports: Untuk setiap aliran, nomor port UDP digunakan untuk mengirim dan menerima yang yang ditentukan.
•
Payload Types (Muatan jenis): Untuk setiap jenis media stream yang digunakan (misalnya, telepon), payload type menunjukkan format media yang dapat digunakan selama sesi.
•
Waktu Start dan Stop: ini berlaku untuk menyiarkan sesi, seperti televisi atau program radio. Mulai, berhenti, dan waktu ulangi sesi ditunjukkan.
•
Originator (Asal): Untuk sesi siaran, originator ditentukan, dengan kontak informasi. Ini mungkin berguna jika penerima menghadapi kesulitan teknis.
24,4 REAL-TIME TRANSPORT PROTOCOL (RTP) Protokol transport-tingkat yang paling banyak digunakan adalah TCP. Meskipun TCP telah terbukti nilainya dalam mendukung berbagai aplikasi terdistribusi, namun TCP tidak cocok digunakan dengan aplikasi real-time terdistribusi. Dengan aplikasi real-time terdistribusi, kita mengartikan satu di mana sumber menghasilkan aliran data pada tingkat
123
konstan, dan satu atau lebih tujuan harus menyampaikan bahwa data ke aplikasi berada pada tingkat yang sama. Contoh aplikasi tersebut termasuk audio dan video konferensi, distribusi video langsung (tidak untuk penyimpanan tetapi untuk bermain langsung), berbagi ruang kerja, remote diagnosis medis, telepon, komando dan kontrol sistem, simulasi interaktif terdistribusi, game, monitoring dan real-time. Sejumlah fitur TCP mendiskualifikasi itu untuk digunakan sebagai protokol transport untuk aplikasi berikut: 1. TCP merupakan protokol point-to-point yang membuat sebuah koneksi antara dua end- points. Oleh karena itu, tidak cocok untuk distribusi multicast. 2. TCP mencakup mekanisme untuk pengiriman ulang segmen yang hilang, yang kemudian tiba telah rusak. Segmen tersebut tidak dapat digunakan di sebagian besar aplikasi real-time. 3. TCP berisi mekanisme tidak nyaman untuk menghubungkan informasi waktu dengan segmen, yang merupakan kebutuhan real-time. Lainnya secara luas digunakan protokol transport, UDP, dua yang pertama tidak menunjukkan karakteristik terdaftar tapi, seperti TCP, tidak memberikan informasi waktu. Dengan sendirinya, UDP tidak menyediakan alat keperluan umum yang berguna untuk aplikasi real-time. Meskipun setiap aplikasi real-time dapat mencakup mekanisme sendiri untuk mendukung transportasi real-time, ada sejumlah fitur-fitur umum yang menjamin definisi protokol umum. Sebuah protokol yang dirancang untuk tujuan ini adalah Real-Time Transport Protocol (RTP), didefinisikan dalam RFC 1889. RTP paling cocok untuk komunikasi soft real-time. Ini tidak memiliki mekanisme yang diperlukan untuk mendukung lintas real-time keras. Bagian ini memberikan ikhtisar tentang RTP. Kita mulai dengan diskusi persyaratan transportasi real-time. Selanjutnya, kita memeriksa pendekatan filosofis RTP. Sisa bagian ini dikhususkan untuk dua protokol yang membentuk RTP: yang pertama hanya disebut RTP dan merupakan protokol transfer data, yang lain adalah kontrol protokol dikenal sebagai RTCP (RTP Control Protocol). Protokol RTP Arsitektur Dalam RTP, ada kopling yang dekat antara fungsionalitas RTP dan fungsionalitas aplikasi. Memang, RTP yang terbaik adalah dipandang sebagai suatu frame kerja yang aplikasinya dapat digunakan secara langsung untuk menerapkan protokol. Tanpa informasi spesifik aplikasi, RTP bukan protokol yang lengkap. Di sisi lain, RTP
124
membebankan struktur dan mendefinisikan fungsi umum sehingga aplikasi real-time individu dibebaskan dari bagian beban mereka. RTP mengikuti prinsip-prinsip desain arsitektur protokol yang diuraikan dalam kertas oleh Clark dan Tennenhouse [CLAR90]. Dua kunci konsep yang disajikan dalam kertas adalah aplikasi level framing dan pengolahan lapisan terintegrasi. Aplikasi-Level Framing dalam protokol transport tradisional, seperti TCP, bertanggung jawab untuk memulihkan bagian data yang hilang yang dilakukan secara transparan pada lapisan transport. [CLAR90] mendata dua skenario yang mungkin akan lebih tepat untuk memulihkan data yang hilang yang akan dilakukan oleh aplikasi: 1. Aplikasi, dalam keterbatasan, dapat menerima kurang dari kesempurnaan pengiriman dan melanjutkan unchecked. Ini adalah kasus untuk real-time audio dan video. Untuk aplikasi tersebut, mungkin perlu untuk menginformasikan sumber dalam istilah yang lebih umum tentang kuliatas pengiriman daripada meminta pengiriman ulang. Jika data terlalu banyak yang hilang, sumber mungkin akan pindah ke transmisi yang kualitasnya lebih rendah yang menempatkan tuntutan yang lebih rendah pada jaringan, untuk meningkatkan kemungkinan pengiriman. 2. Mungkin lebih baik untuk memiliki aplikasi daripada protokol transport menyediakan data untuk transmisi ulang. Hal ini berguna dalam konteks berikut: (A) Pengiriman aplikasi dapat menghitung ulang data yang hilang daripada menyimpanya. (B) aplikasi pengiriman dapat memberikan nilai revisi bukan hanya mentransmisi nilainilai yang hilang, atau mengirim data baru yang "memperbaiki" konsekuensi dari kerugian asli. Untuk mengaktifkan aplikasi untuk memiliki kontrol atas fungsi retransmisi, Clark dan Tennenhouse mengusulkan bahwa lapisan yang lebih rendah, seperti presentasi dan transport, berurusan dengan data dalam unit yang menentukan aplikasi. Aplikasi harus mematahkan aliran data ke dalam aplikasi-tingkat unit data (ADUs), dan lapisan rendah harus melestarikan batas Users-ADU karena mereka proses data.The aplikasiframe level adalah unit pemulihan kesalahan. Jadi, jika sebagian dari ADU hilang dalam transmisi, aplikasi biasanya akan mampu memanfaatkan sisa porsi. Dalam kasus seperti itu, lapisan aplikasi akan membuang semua bagian yang tiba dan mengatur pengiriman ulang dari seluruh ADU, jika perlu.
125
Lapisan Terpadu Pengolahan Dalam arsitektur protokol berlapis khas, seperti TCP / IP atau OSI, setiap lapisan arsitektur berisi subset dari fungsi yang harus dilakukan untuk komunikasi, dan setiap lapisan logikanya harus terstruktur sebagai bagian modul tingkat systems. Maka, pada transmisi, sebuah blok data mengalir ke bawah melalui dan diproses berurutan oleh setiap lapisan struktur arsitektur. Hal ini membatasi pelaksana dari memanggil fungsi-fungsi tertentu secara paralel atau keluar dari tatanan berlapis untuk mencapai efisiensi yang lebih besar. Proses lapisan terpadu, seperti yang diusulkan dalam [CLAR90], menangkap gagasan bahwa lapisan yang berdekatan dapat digabungkan secara erat dan pelaksana harus bebas untuk melaksanakan fungsi lapisan tersebut dengan cara yang menggabungkan yang ketat. Gagasan bahwa suatu lapisan protokol yang ketat dapat menyebabkan inefisiensi telah dikemukakan oleh sejumlah peneliti. Sebagai contoh, [CROW92] memeriksa ketidakefisienan penjalanan remote prosedur panggilan (RPC) di atas TCP dan menyarankan kopling ketat dari dua lapisan. Para peneliti berpendapat bahwa lapisan terintegrasi pendekatan proses adalah lebih baik untuk transfer data yang efisien. Gambar 24.12 mengilustrasikan cara di mana RTP menyadari prinsip proses lapisan yang terintegrasi. RTP dirancang untuk berjalan di atas protokol transportasi tanpa koneksi seperti UDP. UDP menyediakan fungsionalitas dasar port yang menangani lapisan transport. RTP berisi fungsi-fungsi tingkat transportasi lebih lanjut, seperti sekuensing. Namun, RTP dengan sendiri tidaklah lengkap. Hal ini dilengkapi dengan modifikasi dan / atau penambahan pada header RTP untuk memasukkan aplikasifungsionalitas lapisan. Angka tersebut menunjukkan bahwa standar yang berbeda untuk data encoding video dapat digunakan dalam konjungsi dengan RTP untuk transmisi video. Protokol Transfer Data RTP Kami pertama melihat konsep dasar dari protokol transfer data RTP dan kemudian menguji format header protokol. Seluruh bagian ini, RTP jangka panjang akan mengacu pada RTP protokol transfer data.
126
Konsep RTP RTP mendukung transfer data real-time antara sejumlah peserta dalam sebuah sesi. Sebuah sesi hanyalah suatu kaitan yang logis antara dua atau lebih entitas RTP yang dipertahankan selama transfer data. Sebuah sesi didefinisikan oleh: •
nomor port RTP: Alamat Port tujuan yang digunakan oleh semua peserta untuk RTP transfer. Jika UDP adalah lapisan yang lebih rendah, nomor port ini muncul dala m kolom port tujuan (lihat Gambar 2.3) dari header UDP.
•
nomor port RTCP: Alamat Port tujuan yang digunakan oleh semua peserta untuk transfer RTCP.
•
Participant IP adressess (Peserta alamat IP): ini bisa juga berupa alamat IP multicast, sehingga grup multicast mendefinisikan peserta, atau satu set alamat IP unicast. Proses menyiapkan sesi di luar lingkup RTP dan RTCP. Meskipun RTP dapat
digunakan untuk unicast transmisi real-time, kekuatannya terletak pada kemampuannya untuk mendukung transmisi multicast. Untuk tujuan ini, setiap unit data RTP termasuk sumber pengenal yang mengidentifikasi anggota kelompok yang mana menghasilkan data. Ini juga termasuk timestamp sehingga waktu yang tepat bisa kembali dibuat pada
127
akhir penerimaan menggunakan buffer delay. RTP juga mengidentifikasi format payload dari data yang ditransmisikan. RTP memungkinkan penggunaan dua jenis relay RTP: translator dan mixer. Pertama kita perlu mendefinisikan konsep operasi relay. Sebuah relay pada lapisan protokol yang diberikan adalah antara sistem yang bertindak, baik sebagai tujuan dan sumber dalam transfer data. Misalnya, sistem A ingin mengirim data ke sistem B tetapi tidak bisa melakukan secara langsung. Kemungkinan alasan adalah bahwa B mungkin berada di balik firewall atau B mungkin tidak dapat menggunakan format yang ditularkan oleh A. Dalam kasus seperti itu, A dapat mengirim data ke relay R selanjutnya. R menerima unit data, membuat setiap perubahan yang diperlukan atau melakukan pemrosesan apapun yang diperlukan, dan kemudian mengirimkan data ke B. Mixer adalah sebuah relay RTP yang menerima aliran paket RTP dari satu atau lebih banyak sumber, menggabungkan aliranaliran ini, dan mengirimkan aliran paket RTP untuk satu atau lebih tujuan. Mixer dapat mengubah format data atau hanya melakukan fungsi pencampuran. Karena waktu antara beberapa input tidak biasanya disinkronkan, mixer menyediakan informasi waktu dalam aliran paket gabungan dan mengidentifikasi dirinya sebagai sumber sinkronisasi. Sebuah contoh dari penggunaan mixer adalah untuk menggabungkan sejumlah on / off sumber seperti audio. Misalkan bahwa sejumlah sistem adalah anggota dari sebuah sesi audio dan masing-masing menghasilkan aliran RTP-nya. Seringkali hanya satu sumber yang aktif, meskipun kadang-kadang lebih dari satu sumber akan "berbicara" pada waktu yang sama. Sebuah sistem mungkin baru ingin bergabung dengan sesi, tetapi link untuk jaringan mungkin tidak memiliki kapasitas yang cukup untuk membawa semua aliran RTP. Sebaliknya, mixer bisa menerima semua aliran RTP, menggabungkan mereka ke dalam aliran tunggal, dan memancarkan kembali aliran ke anggota sesi baru. Jika lebih dari satu aliran masuk aktif pada waktu yang sama, mixer hanya akan menjumlah nilai PCM secara sederhana. Header RTP yang dihasilkan oleh mixer termasuk identifier (s) dari sumber (s) yang memberikan kontribusi ke data di setiap paket. Translator adalah perangkat sederhana yang menghasilkan satu atau lebih paket keluaran RTP untuk masing-masing translator paket. Translator dapat mengubah format data dalam paket atau menggunakan deretan protokol tingkat rendah yang berbeda untuk
128
mentransfer dari satu domain ke domain lain. Contoh penggunaan translator adalah sebagai berikut: •
Sebuah penerima potensial mungkin tidak mampu menangani sinyal video berkecepatan tinggi yang digunakan oleh peserta lainnya. Translator mengkonversi video ke format kualitas lebih rendah yang membutuhkan tingkat data yang lebih rendah.
•
Sebuah firewall level-aplikasi dapat mencegah penyampaian paket RTP. Dua translator digunakan, satu di setiap sisi firewall, dengan satu di luar membangun semua paket multicast yang diterima melalui sambungan aman ke translator di dalam firewall. Di dalam translator kemudian mengirimkan paket RTP ke grup multicast yang dilindungi oleh firewall.
•
Translator dapat meniru sebuah paket RTP multicast yang masuk dan mengirimkannya ke sejumlah tujuan unicast.
RTP Fixed Header Setiap paket RTP adalah termasuk header tetap dan juga tambahan aplikasispesifik kolom header. Gambar 24,13 menunjukkan header tetap. 12 octet pertama (bagian yang diarsir) selalu hadir dan terdiri dari kolom berikutnya: •
Versi (2 bit): Versi saat ini adalah 2.
•
Padding (1 bit): Menunjukkan apakah oktet bantalan muncul di akhir payload. Jika demikian, oktet terakhir dari payload berisi hitungan jumlah bantalan oktet. Padding (bantalan) digunakan jika aplikasi membutuhkan muatan multiple integer dari beberapa panjang, seperti 32 bit.
•
Ekstensi (1 bit): Jika di set, header tetap diikuti oleh tepatnya satu ekstensi header, yang digunakan untuk ekstensi eksperimental RTP.
•
CSRC Count (4 bit): Jumlah CSRC (sumber berkontribusi) pengidentifikasi yang mengikuti header tetap.
129
•
Marker (1 bit): Penafsiran dari bit penanda tergantung pada jenis muatan (payload type); biasanya digunakan untuk menunjukkan batas dalam aliran data. Untuk video, suBYE diatur untuk menandai akhir dari frame. Untuk audio, suBYE diatur untuk menandai awal dari lonjakan bicara.
•
Payload Type (7 bit): Mengidentifikasi format payload RTP, yang mengikuti header RTP.
•
Sequence Number (Urutan Nomor) (16 bit): Setiap sumber dimulai dengan nomor urutan acak, yang ditambah dengan satu untuk setiap paket data RTP yang dikirim. Hal ini memungkinkan untuk kehilangan deteksi dan pengurutan paket dalam serangkaian paket dengan jumlah timestamp yang sama. Sebuah paket berurutan mungkin memiliki waktu sama jika mereka secara logis dihasilkan pada saat yang sama, beberapa contoh adalah paket yang memiliki frame video yang sama.
•
Timestamp (32 bit): Sesuai dengan generasi instan oktet pertama data dalam payload. Unit waktu dari bidang ini tergantung pada jenis muatan. Nilai-nilai harus dihasilkan dari jam lokal pada sumbernya.
130
•
Sinkronisasi Source Identifier: Sebuah nilai acak yang unik mengidentifikasi sumber dalam sesi.
•
Setelah header tetap, mungkin ada satu atau lebih bidang berikut:
•
Contributing Source Identifier: Mengidentifikasi sumber yang berkontribusi untuk payload. Pengidentifikasi ini dipasok oleh mixer. Kolom Payload Type mengidentifikasi jenis media dari payload dan format
data, termasuk penggunaan kompresi atau enkripsi. Dalam kondisi mapan, satu sumber harus menggunakan satu jenis muatan selama sesi, namun dapat mengubah payload type dalam merespon terhadap kondisi yang berubah, seperti yang ditemukan oleh RTCP. Tabel 24.2 merangkum jenis muatan yangdidefinisikan dalam RFC 1890.
RTP Control Protocol (RTCP) Protokol transfer data RTP hanya digunakan untuk transmisi data pengguna, khususnya dalam mode multicast antara semua peserta dalam sesi. Sebuah kontrol protokol terpisah (RTCP) juga beroperasi dalam mode multicast untuk memberikan umpan balik sumber-sumber data RTP sebaik mungkin kepada semua peserta sesi. RTCP menggunakan layanan transportasi dasar yang sama sebagai RTP (biasanya UDP) dan sebuah nomor port yang terpisah. Pada waktu tertentu masing-masing menerbitkan
131
sebuah paket RTCP untuk semua anggota sesi lain. RFC 1889 menguraikan empat fungsi yang dilakukan oleh RTCP: •
Kualitas layanan (QoS) dan kontrol kongesti: RTCP memberikan umpan balik tentang kualitas distribusi data. Karena paket RTCP adalah multicast, semua anggota sesi dapat menilai seberapa baik anggota lain yang melakukan dan menerima. Laporan Pengirim memungkinkan penerima untuk memperkirakan tingkat data dan kualitas transmisi. Penerima laporan menunjukkan adanya masalah yang dihadapi oleh penerima, termasuk paket yang hilang dan jitter yang berlebihan. Sebagai contoh, aplikasi audio-video mungkin memutuskan untuk mengurangi tingkat transmisi speed link lebih rendah jika kualitas lalu lintas selama link tidak cukup tinggi untuk mendukung tingkat saat ini. Arus umpan balik dari penerima ini juga penting dalam mendiagnosis kesalahan distribusi. Dengan pemantauan dari semua penerima sesi, pengelola jaringan dapat mengetahui apakah masalahnya khusus untuk user tunggal atau lebih luas.
•
Identifikasi: paket RTCP membawa deskripsi tekstual terus-menerus dari sumber RTCP. Hal ini memberikan informasi lebih lanjut tentang sumber data paket daripada pengidentifikasi acak SSRC dan memungkinkan pengguna untuk menghubungkan beberapa stream dari sesi yang berbeda. Sebagai contoh, sesi terpisah untuk audio dan video dapat berlangsung.
•
Sesi estimasi ukuran dan skala: Untuk melakukan dua fungsi pertama, semua peserta mengirimkan paket RTCP secara periodik. Transmisi paket tersebut harus diperkecil karena jumlah partisipan bertambah. Dalam sebuah sesi dengan beberapa peserta, paket RTCP dikirim pada tingkat maksimum satu setiap lima detik. RFC 1889 mencakup algoritma yang relatif kompleks dengan pembatasan masing-masing peserta tingkat RTCP pada basis populasi sesi total. Tujuannya adalah untuk membatasi lalu lintas RTCP agar kurang dari 5% dari lalu lintas sesi total.
•
Sesi kontrol: RTCP secara opsional menyediakan informasi sesi kontrol yang minimal. Contohnya adalah sebuah identifikasi peserta yang akan ditampilkan pada antarmuka pengguna. Transmisi RTCP terdiri dari sejumlah paket yang terpisah RTCP yang diikat dalam sebuah datagram UDP tunggal (atau unit data tingkat rendah lainnya).
Berikut jenis paket yang didefinisikan dalam RFC 1889:
132
•
Sender Report (Pengirim Laporan) (SR)
•
Receiver Report (Penerima Laporan) (RR)
•
Source Description (Sumber Deskripsi) (SDES)
•
Goodbye (Selamat tinggal) (BYE)
•
Aplikasi Tertentu
Gambar 24,14 menggambarkan format jenis paket ini. Masing-masing paket dimulai dengan 32-bit kata yang berisi bidang-bidang berikut: •
Version (Versi) (2 bit): Versi saat ini adalah 2.
•
Padding (1 bit): Jika di set, menunjukkan bahwa paket ini mengandung bantalan oktet di akhir informasi kontrol. Jika demikian, oktet terakhir dari padding berisi hitunga jumlah bantalan oktet.
•
Count (5 bit): Jumlah blok laporan penerimaan terkandung dalam SR atau paket RR (RC), atau jumlah sumber item yang terkandung dalam SDES atau paket BYE.
•
Packet Type (Tipe Packet) (8 bit): Mengidentifikasi jenis paket RTCP.
•
Lenght (Panjang) (16 bit): Panjang paket ini 32 bit kata-kata, minus satu.
•
Selain itu, Laporan Pengirim dan Penerima Paket berisi kolom berikut:
•
Synchronization Source Identifier (Sinkronisasi Identifier Sumber) : Mengidentifikasi sumber dari paket RTCP.
Kita sekarang beralih ke deskripsi dari masing-masing jenis paket. Pengirim Laporan (SR) Penerima RTCP memberikan penerimaan umpan balik berkualitas menggunakan Laporan Pengirim atau Penerima Laporan, tergantung pada apakah penerima juga merupakan pengirim selama sesi ini. Gambar 24.14a menunjukkan format Laporan Pengirim. Laporan pengirim terdiri dari header, already described, sebuah blok informasi pengirim; dan nol atau lebih blok penerimaan laporan. Blok informasi pengirim meliputi bidang-bidang berikut: •
Timestamp NTP (64 bit): Waktu jam dinding mutlak ketika laporan ini dikirim, ini adalah nomor fixed-point unsigned dengan bagian bilangan bulat dalam 32 bit pertama dan bagian pecahan dalam 32 bits. Ini bisa digunakan oleh pengirim dalam
133
kombinasi dengan timestamp dalam laporan penerima untuk mengukur putaran perjalanan waktu untuk penerima.
•
Timestamp RTP (32 bit): Ini adalah waktu relatif digunakan untuk membuat Xmenempatkan laporan ini di waktu yang sesuai urutan waktu dengan paket data RTP dari sumber ini.
•
Sender’s Packet Count (Packet Pengirim Count) (32 bit): Jumlah total paket data RTP yang ditransmisikan oleh pengirim sejauh ini dalam sesi ini.
•
Pengirim oktet Count (32 bit): Jumlah payload oktet RTP yang ditransmisikan oleh pengirim sejauh ini dalam sesi ini. Setelah blok informasi pengirim adalah nol atau lebih laporan penerimaan blok.
Satu blok penerimaan disertakan untuk setiap sumber dari mana peserta ini telah menerima data selama sesi ini. Setiap blok mencakup bidang-bidang berikut: •
SSRC_n (32 bit): Mengidentifikasi sumber disebut dengan laporan blok ini.
134
•
Fraction Lost (Fraksi yang Hilang) (8 bit): paket data RTP dari SSRC_n hilang sejak sesi ini.
•
Cumulative Number of Packets Lost (Kumulatif jumlah paket yang hilang) (24 bit): Jumlah RTP Data paket-paket dari SSRC_n hilang selama sesi ini.
•
Extended Highest Sequence Number Received (Perpanjangan urutan tertinggi Jumlah Diterima) (32 bit): Yang paling signifikan 16 bit merekam data RTP mencatat jumlah waktu nomor urut telah dibungkus kembali ke nol.
•
Interarrival Jitter (32 bit): Perkiraan pengalaman jitter pada paket-paket data RTP dari SSRC_n, dijelaskan nanti.
•
Last SR Timestamp (32 bit): Pertengahan dari 32 bit dari timestamp NTP di paket terakhir yang diterima dari SSRC_n SR. Penagkapan ini paling signifikan setengah dari bilangan bulat dan paling signifikan dari bagian pecahan dari timestamp dan harus memadai.
•
Delay Since Last SR (32 bit): Keterlambatan, dinyatakan dalam satuan 2-16 detik, antara penerimaan paket SR terakhir dari SSRC_n dan transmisi blok laporan ini. Kedua bidang terakhir dapat digunakan oleh sumber untuk memperkirakan waktu pulang-pergi untuk penerima tertentu. Mengingatkan bahwa penundaan jitter didefinisikan sebagai variasi dalam
pengalaman delay maksimum oleh paket dalam sesi. Tidak ada cara sederhana untuk mengukur kuantitas ini pada penerima, tetapi mungkin untuk memperkirakan rata-rata jitter dengan cara berikut. Pada penerima tertentu, menentukan parameter berikut untuk sumber tertentu: S (I) Timestamp dari paket data RTP I. R (I) Waktu kedatangan untuk paket data RTP I. dinyatakan dalam unit timestamp RTP. Penerima harus menggunakan frekuensi clock yang sama (Interval kenaikan) sebagai sumber, tetapi tidak perlu menyinkronkan nilai waktu dengan sumber. D (I) perbedaan antara waktu interarrival pada penerima dan jarak antara paket data RTP yang berdekatan yang meninggalkan sumbernya. J (I) Perkiraan jitter interarrival rata-rata sampai penerimaan data paket RTP I.
135
Jadi, D (I) mengukur berapa banyak jarak antara paket-paket yang tiba yang berbeda
dari
jarak antara paket yang ditransmisikan. Dengan tidak adanya jitter, jarak akan sama dan D (I) akan memiliki nilai 0. jitter interarrival dihitung secara berkelanjutan karena setiap paket data I diterima, sesuai dengan formula
Dalam persamaan ini, J (I) dihitung sebagai average3 eksponensial dari nilai-nilai yang diamati dari D (I). Hanya berat badan kecil yang diberikan kepada observasi yang paling baru-baru ini, sehingga sementara fluktuasi tidak membatalkan estimasi. Nilai-nilai dalam Laporan Pengirim memungkinkan pengirim, penerima, dan pengelola jaringan untuk memonitor kondisi pada jaringan yang berkaitan dengan sesi tertentu. Misalnya, paket nilai kerugian memberikan indikasi kemacetan terus-menerus, sedangkan jitter mengukur kemacetan sementara. Pengukuran jitter dapat memberikan peringatan peningkatan kemacetan sebelum mengarah ke paket yang hilang. Penerima Laporan (RR) Format untuk Laporan Receiver (Gambar 24.14b) adalah sama dengan Laporan Pengirim, kecuali kolom Jenis paket memiliki nilai berbeda dan tidak ada blok informasi pengirim.
136
Sumber Deskripsi (SDES) Paket Deskripsi Sumber (Gambar 24.14d) digunakan oleh sumber untuk memberikan informasi lebih lanjut tentang dirinya sendiri. Paket ini terdiri dari 32-bit header yang diikuti oleh nol atau lebih potongan, masing-masing berisi informasi yang menggambarkan sumber ini. Setiap potongan dimulai dengan pengidentifikasi untuk sumber ini atau untuk sumber kontribusi. Hal ini diikuti oleh daftar item deskriptif. Tabel 24.3 mendata jenis item deskriptif yang didefinisikan dalam RFC 1889. 3 Untuk perbandingan, lihat Persamaan (20.3).
Goodbye (BYE) Paket BYE menunjukkan bahwa satu atau lebih sumber tidak aktif lagi. Hal ini menegaskan kepada penerima yang diam berkepanjangan adalah karena berangkat dari kegagalan jaringan. Jika paket BYE diterima oleh mixer, diteruskan dengan daftar sumber yang tidak berubah. Format paket BYE terdiri dari sebuah header 32-bit diikuti oleh satu atau lebih sumber identifier. Secara bebas, paket termasuk deskripsi tekstual dari alasan untuk meninggalkan. Application-Defined Packet Paket ini ditujukan untuk penggunaan eksperimental untuk fungsi dan fitur yang spesifik aplikasinya. Pada akhirnya, sebuah eksperimen Jenis paket yang terbukti berguna biasanya dapat diberikan jenis nomor paket dan menjadi bagian dari RTCP standar.
137
