Chapter 18.9.2 Protokol Kontrol Transmisi Terpilih Nirkabel (WP-TCP)
Salah satu spesifikasi yang baru diperkenalkan oleh lapisan transport WAP2
Arsitektur adalah Wireless Profiled TCP (WP-TCP) yang digunakan untuk menyediakan
layanan berorientasi koneksi Implementasi WP-TCP didefinisikan dalam
OMA WAP-225-TCP-20010331-spesifikasi. Manfaat direalisasikan dari yang baru ini
implementasi meliputi:
Transfer data yang besar
Keamanan end-to-end
Kepatuhan terhadap protokol IETF
Penggunaan WP-TCP bisa menggunakan satu dari dua pendekatan.
Pendekatan split-TCP
Pendekatan split-TCP sangat erat mencerminkan model WAP 1.x. Di dalam
pendekatan, proxy ada antara klien WAP dan server asal, dan dua
koneksi dibuat Koneksi pertama dibuat menggunakan WP-TCP,
dan ada antara klien WAP dan proxy WAP. Koneksi kedua,
didirikan di atas TCP, ada antara proxy WAP dan server asal. Ini
diilustrasikan pada Gambar 18-8.
Menggunakan pendekatan semacam itu memungkinkan server WAP dan server proxy WAP masuk
Keuntungan dari pengoptimalan yang ada di WP-TCP tapi tidak di TCP saja. Ini adalah
Terutama penting karena ada banyak aspek pada koneksi nirkabel
yang menciptakan lingkungan yang tidak sesuai untuk TCP (ini didefinisikan dalam "WP-TCP
pengoptimalan "di halaman 676).
Namun, optimasi WP-TCP dirancang khusus untuk memungkinkan
Protokol menjadi lebih efisien dalam lingkungan seperti itu. Dengan membelah koneksi,
WP-TCP mampu beroperasi di lingkungan nirkabel, dan TCP mampu
beroperasi di lingkungan kabel. Informasi lebih lanjut tentang yang spesifik
Optimalisasi ada pada "optimasi WP-TCP" di halaman 676.
Pendekatan end-to-end
WP-TCP sesuai dengan RFC 0793 dan 1122. Oleh karena itu, setiap WP-TCP
Implementasi juga bisa berkomunikasi dengan komunikasi TCP, meski
koneksi yang dihasilkan akan kekurangan optimasi yang dirancang pada WP-TCP. Dalam mengimplementasikan koneksi end-to-end, WP-TCP berperilaku seperti TCP lainnya
aplikasi, membangun koneksi langsung dengan server asal. Ini adalah
diilustrasikan pada Gambar 18-9.
Keputusan untuk menerapkan pendekatan end-to-end melalui pendekatan split-TCP
biasanya ditentukan oleh service, server, dan hardware provisioning atau
kebutuhan khusus dari lapisan aplikasi.
Optimasi WP-TCP
Seperti disebutkan sebelumnya, skenario tertentu ada pada jaringan nirkabel yang membuat a
Koneksi TCP murni kurang diminati. Skenario tersebut meliputi:
Sering kehilangan paket
Ukuran jendela yang lebih kecil
Lama hening atau kehilangan koneksi karena eksponen back-off
mekanisme transmisi ulang
Transmisi redundan
Periode pemutusan karena kurangnya cakupan
Profil TCP untuk WP-TCP berusaha mengoptimalkan protokol untuk mengimbanginya
untuk skenario ini Secara khusus, delapan optimasi disertakan dalam WP-TCP.
Ini adalah:
Ukuran jendela yang besar: Built in to TCP adalah penggunaan Produk Delay Bandwidth
(BDP), dihitung dari bandwidth yang tersedia dan waktu pulang-pergi
hitung ukuran jendela minimum. Ini juga menghitung jendela maksimum
ukuran menggunakan nilai terkecil dari send atau receive buffer. WP-TCP bisa memilih
untuk menggunakan ukuran jendela maksimal, mengandalkan kontrol kemacetan
Mekanisme dibangun ke dalam TCP untuk mengatur data sesuai kebutuhan. WP-TCP
spesifikasi menunjukkan bahwa implementasi dari optimasi ini adalah
direkomendasikan, tapi tidak diperlukan
Opsi skala jendela: Entitas yang memilih untuk menggunakan ukuran jendela besar adalah
diperlukan juga untuk mengimplementasikan opsi skala jendela yang ditentukan oleh RFC 1323. Jika
sebuah entitas tidak mendukung optimasi ukuran jendela besar, implementasi
dari optimasi skala jendela bersifat opsional.
Pengukuran waktu round-trip: Juga didefinisikan dalam RFC 1323, round-trip time
pengukuran (RTTM) direkomendasikan untuk digunakan oleh entitas yang menerapkannya
Ukuran jendela lebih besar dari 64 K. Ini juga membutuhkan penggunaan cap waktu pilihan. Jendela awal yang besar: Implementasi TCP standar mencakup initial jendela sampai dua segmen dalam ukuran Namun, WP-TCP menggunakan ekstensi didefinisikan dalam RFC 2414 yang memungkinkan WP-TCP untuk mengirim jendela awal dari tiga atau empat segmen Ini terbatas pada 4380 byte. Implementasi ini
optimasi adalah opsional Jalur penemuan MTU: WP-TCP sekarang mendukung prosedur, yang didefinisikan dalam RFC 1191 dan 1981, digunakan untuk menemukan unit transmisi maksimum (MTU) dari
jalan yang diberikan Hal ini memungkinkan WP-TCP untuk mengoptimalkan jumlah data yang dikirim masuk
setiap paket untuk menghindari fragmentasi atau menjatuhkan paket. Implementasi dari
Optimalisasi ini direkomendasikan, namun tidak diperlukan.
MTU lebih besar dari MTU IP default: Jika sebuah entitas tidak dapat mendukung jalur MTU
temukan (misalnya, jika beberapa router di jalan tidak mendukungnya
dibutuhkan pesan ICMP), implementasi WP-TCP dapat mengasumsikan sebuah nilai
melebihi nilai default IPv4 atau IPv6. Namun, nilai yang diasumsikan harus
tidak melebihi 1500 byte, dan harus mencerminkan ukuran segmen maksimum
dinegosiasikan saat membuat koneksi TCP.
Pengakuan selektif: Algoritma pemulihan cepat, yang didefinisikan dalam RFC
2581, cenderung kurang efisien saat mencoba pulih dari banyak
kerugian dalam satu jendela Skenario ini sangat mungkin terjadi pada wireless
koneksi, dan karena itu, alternatif untuk algoritma fast recover itu
diimplementasikan Pengakuan selektif (SACK) didefinisikan dalam RFC 2018
dan memungkinkan WPT-TCP untuk mengirim ucapan terima kasih selektif, menunjukkan apa
data perlu dipancarkan ulang. Implementasi optimasi ini adalah
wajib.
Pemberitahuan kemacetan eksplisit (ECN): Ditetapkan di RFC 2481, ECN mengizinkan Penerima WP-TCP memberi tahu pengirim data kemacetan di jaringan. Hal ini memungkinkan pengirim untuk mengurangi kemacetan jendela. Implementasi optimasi ini bersifat opsional.
EmoticonEmoticon