1 00:00:00,240 --> 00:00:07,590 Informasi dapat disegmentasi atau dipecah menjadi potongan-potongan kecil atau transmisi di media fisik unit 2 00:00:08,010 --> 00:00:15,040 transmisi maksimum atau mengosongkan Anda dari antarmuka keluar tergantung pada media fisik. 3 00:00:15,090 --> 00:00:20,640 Sebagai contoh mereka mengosongkan Anda dari Ethan Ini adalah 5400 byte. 4 00:00:20,850 --> 00:00:28,650 Namun TZP secara teoritis dapat mendukung enam puluh lima ribu empat ratus sembilan puluh lima byte dalam satu 5 00:00:28,650 --> 00:00:29,380 paket. 6 00:00:29,460 --> 00:00:35,370 Ketika itu dikirim ke lapisan bawah model ozon yang perlu dipecah menjadi 7 00:00:35,560 --> 00:00:42,330 fragmen untuk transmisi di media fisik yang misalnya hanya mendukung 50 atau 100 byte. 8 00:00:42,330 --> 00:00:49,890 Oleh karena itu, data dipecah menjadi potongan yang lebih kecil dan penerima yang menggunakan TZP perlu menyatukan kembali 9 00:00:49,890 --> 00:00:51,180 potongan-potongan itu. 10 00:00:51,510 --> 00:00:58,950 Ukuran segmen maksimum atau MSA adalah jumlah terbesar data dalam byte yang bersedia dikirim oleh TZP 11 00:00:58,950 --> 00:01:02,010 dalam satu segmen untuk kinerja terbaik. 12 00:01:02,010 --> 00:01:08,700 MSA cukup kecil untuk menghindari fragmentasi Arpey yang dapat menyebabkan transmisi ulang yang 13 00:01:08,700 --> 00:01:15,550 berlebihan jika ada paket DCP kehilangan sesuatu yang disebut ukuran segmen maksimum dan jeda. 14 00:01:15,600 --> 00:01:23,400 MT You discovery atau Porth penemuan unit transmisi maksimum dengan pengirim dan penerima dapat secara otomatis 15 00:01:23,400 --> 00:01:31,260 menentukan apa unit transmisi maksimum berada di jalur di antara mereka dan TZP hanya akan memasukkan 16 00:01:31,260 --> 00:01:39,840 data yang cukup ke dalam satu paket yang sesuai dengan yang kosong sehingga menghindari fragmentasi paket dan 17 00:01:39,840 --> 00:01:46,620 sehingga menghindari overhead yang terkait dengan fragmentasi dan menyatukan fragmen IP ke dalam 18 00:01:46,620 --> 00:01:55,440 penemuan Anda adalah opsional dalam IP versi 4 yang sekarang menjadi wajib dalam IP versi 6 karena efisiensi 19 00:01:55,860 --> 00:02:02,820 yang dibawanya ke transmisi TZP dan fakta bahwa IP versi 6 tidak mendukung fragmentasi 20 00:02:03,420 --> 00:02:12,190 pada router di sepanjang jalur antara dua host UDP tidak mendukung ini dan memerlukan protokol tingkat yang lebih 21 00:02:12,550 --> 00:02:22,000 tinggi untuk memilah-milah kontrol aliran fragmen GCP menggunakan kontrol aliran ujung ke ujung untuk menghindari pengirim mengirim data terlalu 22 00:02:22,000 --> 00:02:27,370 cepat untuk penerima untuk menerimanya dan memprosesnya dengan andal. 23 00:02:27,580 --> 00:02:33,700 Jika sama dengan pengiriman data yang lebih cepat daripada yang bisa ditangani penerima, 24 00:02:33,700 --> 00:02:40,780 penerima akan menjatuhkan data yang akan membutuhkan pengiriman ulang pengiriman ulang akan menghabiskan waktu dan sumber daya 25 00:02:40,780 --> 00:02:49,410 jaringan yang menjadi alasan mengapa sebagian besar mekanisme kontrol aliran mencoba memaksimalkan transfer diperkosa sambil meminimalkan persyaratan untuk mentransmisikan kembali. 26 00:02:49,470 --> 00:02:57,930 Sebagai contoh, Anda dapat memiliki PC dengan kemampuan mengirim data yang kuat ke PDA genggam yang hanya dapat memproses data dengan 27 00:02:57,930 --> 00:03:00,400 kecepatan yang jauh lebih rendah. 28 00:03:00,420 --> 00:03:07,710 Oleh karena itu PDA harus mengatur aliran data sehingga tidak kewalahan dalam kontrol aliran dasar 29 00:03:07,710 --> 00:03:15,400 TZP diimplementasikan oleh pengakuan dari penerima dalam menerima data yang dikirimkan EECP menggunakan sesuatu yang 30 00:03:15,400 --> 00:03:19,440 disebut jendela geser untuk mengontrol aliran data. 31 00:03:19,530 --> 00:03:25,810 Windowing akan memungkinkan komputer penerima untuk mengiklankan berapa banyak data yang dapat diterima sebelum 32 00:03:25,810 --> 00:03:28,330 mengirim pemberitahuan ke komputer pengirim. 33 00:03:28,780 --> 00:03:34,720 Di setiap segmen TZP penerima akan menentukan di bidang jendela terima. 34 00:03:34,870 --> 00:03:41,200 Jumlah data yang diterima tambahan dalam byte yang bersedia buffer untuk koneksi 35 00:03:41,200 --> 00:03:48,400 host pengirim hanya dapat mengirim hingga jumlah data sebelum Miss White ketika pengakuan dan 36 00:03:48,400 --> 00:03:54,610 pembaruan ukuran jendela dari host penerima UDP tidak menerapkan kontrol aliran. 37 00:03:55,520 --> 00:04:02,090 Dan dalam lingkungan VOIP sebagai contoh yang menggunakan UDP meskipun tidak ada koneksi fisik antara 38 00:04:02,090 --> 00:04:08,990 dua handset yang terlibat dalam panggilan telepon, panggilan akan tetap aktif dan pengirim akan terus mengirim 39 00:04:08,990 --> 00:04:11,010 data dalam jumlah besar. 40 00:04:11,180 --> 00:04:18,770 Meskipun penerima tidak dapat memproses data yang diterima, UDP mengandalkan protokol Hi-Lo untuk menerapkan 41 00:04:18,770 --> 00:04:20,280 kontrol aliran. 42 00:04:20,480 --> 00:04:28,850 Sekali lagi TZP berorientasi koneksi dan UDP adalah koneksi yang kurang TZP akan membuat koneksi 43 00:04:29,300 --> 00:04:33,080 dan mempertahankan koneksi selama seluruh transmisi. 44 00:04:33,080 --> 00:04:37,220 Setelah transmisi selesai, sesi diakhiri. 45 00:04:37,280 --> 00:04:43,980 UDP tidak mengatur sesi dan hanya akan mengirim data dengan harapan penerima akan menerimanya. 46 00:04:45,180 --> 00:04:52,770 Sekali lagi TZP mengimplementasikan keandalan di mana setiap segmen yang ditransmisikan diakui dan 47 00:04:52,770 --> 00:04:59,070 jika segmen tersebut hilang, transmisi ulang UDP tidak menerapkan keandalan. 48 00:04:59,220 --> 00:05:07,890 Dan sekali lagi bergantung pada protokol Hailo untuk mengimplementasikan keandalan apa pun jika diperlukan dalam kasus-kasus tertentu seperti 49 00:05:07,890 --> 00:05:12,940 voice over IP atau video yang dikirimkan melalui infrastruktur IP. 50 00:05:13,140 --> 00:05:15,550 Keandalan tidak diperlukan. 51 00:05:15,600 --> 00:05:25,910 Tidak ada gunanya mentransmisikan kembali paket suara terakhir sehingga perbandingan cepat antara UDP dan TZP atau protokol yang dapat diandalkan 52 00:05:25,910 --> 00:05:33,870 dan upaya terbaik atau protokol yang tidak dapat diandalkan TZP sekali lagi berorientasi koneksi. 53 00:05:34,120 --> 00:05:41,440 Tidak ada data yang dikirimkan sebelum sesi dibuat, jabat tangan tiga arah terjadi sebelum data 54 00:05:41,440 --> 00:05:42,930 apa pun dikirimkan. 55 00:05:42,940 --> 00:05:49,130 Ada ucapan terima kasih atas data yang diterima dan nomor urut untuk melacak pengiriman data. 56 00:05:49,510 --> 00:05:56,850 UDP di sisi lain koneksi kurang dan tidak melacak data dan tidak menjamin pengiriman data. 57 00:05:57,850 --> 00:06:00,080 TCAP adalah urutan angka. 58 00:06:00,190 --> 00:06:12,190 UDP tidak aplikasi yang menggunakan TZP termasuk email HGP dan aplikasi FGP yang menggunakan UDP termasuk aplikasi streaming suara seperti 59 00:06:12,190 --> 00:06:18,370 voice over IP dan aplikasi streaming video karena sifat VoIP 60 00:06:18,370 --> 00:06:20,400 atau video. 61 00:06:20,530 --> 00:06:28,270 Tidak ada alasan untuk mengirim ulang di lingkungan VOIP pembicara akan diminta untuk mengulangi apa yang mereka 62 00:06:28,270 --> 00:06:28,820 katakan. 63 00:06:28,840 --> 00:06:33,960 Jika pendengar tidak dapat menguraikan apa yang dikomunikasikan. 64 00:06:34,450 --> 00:06:41,890 Jika Anda pernah menggunakan Skype kadang-kadang mungkin terdengar seperti orang yang berbicara di bawah air atau mereka lebih 65 00:06:41,890 --> 00:06:45,570 mirip mesin daripada orang yang Anda kenal berbicara. 66 00:06:46,300 --> 00:06:52,240 Tetapi Anda mungkin masih bisa memahami apa yang mereka katakan dan dengan demikian meskipun data 67 00:06:52,240 --> 00:06:54,080 hilang percakapan dapat dilanjutkan. 68 00:06:54,190 --> 00:07:01,580 Atau jika itu menjadi cukup buruk Anda akan meminta pembicara untuk mengulangi apa yang mereka katakan dalam lingkungan streaming video. 69 00:07:01,600 --> 00:07:08,020 Anda mungkin memperhatikan bahwa bagian gambar tidak disegarkan dengan benar tetapi Anda masih dapat mengikuti apa 70 00:07:08,020 --> 00:07:13,990 yang terjadi di video karena sifat suara dan video yang sensitif terhadap waktu. 71 00:07:14,050 --> 00:07:19,350 Ini adalah pengiriman ulang data yang tidak berguna dan karenanya TZP tidak digunakan dalam lingkungan ini. 72 00:07:19,360 --> 00:07:24,780 UDP digunakan sehingga UDP adalah protokol lapisan transport. 73 00:07:24,810 --> 00:07:32,430 Itu berada di lapisan ketika ketika model itu menyediakan aplikasi dengan akses ke lapisan jaringan semua 74 00:07:32,440 --> 00:07:38,390 lapisan 3 tanpa overhead atas mekanisme tanggung jawab seperti yang dibahas. 75 00:07:38,390 --> 00:07:42,380 Ini sangat ideal untuk aplikasi voice over IP atau video. 76 00:07:42,530 --> 00:07:49,730 Ini koneksi yang kurang dari satu arah datagram tujuan pusat tanpa pemberitahuan terlebih dahulu 77 00:07:49,730 --> 00:07:51,430 ke perangkat tujuan. 78 00:07:51,500 --> 00:07:55,440 Tidak ada komunikasi sebelum pengiriman data. 79 00:07:55,820 --> 00:08:01,690 Data baru saja tiba di penerima dan diharapkan penerima menangani data itu. 80 00:08:02,030 --> 00:08:08,940 UDP mampu memberikan kesalahan yang sangat terbatas saat memeriksa datagram UDP tidak termasuk pemeriksaan 81 00:08:08,940 --> 00:08:16,080 opsional beberapa nilai yang dapat digunakan perangkat penerima untuk menguji integritas data header UDP juga 82 00:08:16,080 --> 00:08:23,490 menyertakan nomor port tujuan dan jika datagram itu diarahkan ke aktif kode pada perangkat penerima 83 00:08:23,490 --> 00:08:29,900 pesan balasan dapat dikirim untuk menunjukkan bahwa kode itu tidak dapat dijangkau. 84 00:08:29,910 --> 00:08:32,830 Saya akan membahas nomor port lebih terinci sebentar lagi. 85 00:08:33,090 --> 00:08:36,100 Ini konsep yang sangat penting untuk dipahami. 86 00:08:36,150 --> 00:08:39,170 UDP memberikan yang terbaik jika saat pengiriman. 87 00:08:39,180 --> 00:08:47,160 Tidak ada jaminan bahwa data yang dikirim paket mungkin salah diarahkan digandakan atau hilang dalam 88 00:08:47,160 --> 00:08:48,840 perjalanan ke tujuan. 89 00:08:48,870 --> 00:08:57,970 Tidak ada jaminan penerimaan protokol perlu menerapkan keandalan jika diperlukan. 90 00:08:58,030 --> 00:09:01,600 Mereka juga tidak memiliki fitur pemulihan data di UDP. 91 00:09:01,600 --> 00:09:07,800 Sekali lagi protokol Hiler perlu dipulihkan dari paket yang rusak terakhir. 92 00:09:07,960 --> 00:09:17,440 TFT sebagai contoh memiliki mekanisme bawaan untuk menangani kehilangan data dan TFT P menggunakan UDP memiliki 93 00:09:17,530 --> 00:09:25,480 mekanisme sekuensing dan transmisi ulang karena tidak dapat mengandalkan UDP untuk menerapkan keandalan. 94 00:09:25,480 --> 00:09:27,650 Kepala UDP sangat sederhana. 95 00:09:27,820 --> 00:09:35,810 Ini memiliki nomor port sumber 16 bit 16 tetapi Port ke nomor tujuan sehingga ditentukan nomor port yang 96 00:09:35,810 --> 00:09:40,780 digunakan oleh sumber dan nomor port yang digunakan oleh tujuan. 97 00:09:41,000 --> 00:09:47,500 Ini memiliki bidang panjang 16 bit ETP yang menentukan panjang dalam byte dari seluruh datagram. 98 00:09:47,510 --> 00:09:54,020 Dengan kata lain header dan data panjang minimum untuk datagram UDP adalah 8 byte 99 00:09:54,020 --> 00:09:55,990 karena itu panjang header. 100 00:09:56,030 --> 00:10:01,550 Secara teoritis ukuran maksimum adalah enam puluh lima ribu lima ratus tiga puluh lima byte. 101 00:10:01,740 --> 00:10:08,940 Tetapi IP versi 4 akan memberlakukan batas maksimum enam puluh lima ribu lima ratus tujuh byte. 102 00:10:09,080 --> 00:10:13,970 Opsional checksum UDP dapat digunakan untuk pengecekan kesalahan. 103 00:10:13,970 --> 00:10:19,150 Ini opsional IP versi 4 tetapi bukan opsional IP versi 6.