1 00:00:08,060 --> 00:00:12,560 因此，任何對組播影片的介紹都必須從基礎知識開始 2 00:00:12,560 --> 00:00:17,880 多播的概念、它是什麼、在哪裡使用以及如何識別多播 3 00:00:17,880 --> 00:00:22,180 第 3 層的資料包和第 2 層的多播乙太網路訊框。 4 00:00:22,180 --> 00:00:24,540 這就是我們現在要關注的。 5 00:00:24,540 --> 00:00:27,560 那麼讓我們開始討論為什麼要組播。 6 00:00:27,560 --> 00:00:31,640 所以多播就是我們所說的一對多。 7 00:00:31,640 --> 00:00:34,780 換句話說，我相信您知道什麼是單播，對嗎？ 8 00:00:34,780 --> 00:00:38,700 單播是指有一些 Web 伺服器正在傳送封包 9 00:00:38,700 --> 00:00:42,280 單播到您的筆記型電腦並且僅您的筆記型電腦。 10 00:00:42,280 --> 00:00:44,980 該資料包包含一個網頁或其中的某些內容。 11 00:00:44,980 --> 00:00:46,980 這是一對一的傳輸。 12 00:00:46,980 --> 00:00:48,600 我相信你知道什麼是廣播，對吧？ 13 00:00:48,600 --> 00:00:51,020 廣播是向所有人傳播的東西。 14 00:00:51,020 --> 00:00:53,740 我們知道路由器會殺死廣播。 15 00:00:53,740 --> 00:00:57,900 當廣播到達路由器的第 3 層介面時，它就會停止。 16 00:00:57,900 --> 00:01:01,380 或在具有交換虛擬介面的多層交換器的情況下， 17 00:01:01,380 --> 00:01:04,860 如果您將交換器用作路由器，也是一樣。 18 00:01:04,860 --> 00:01:09,780 任何第 3 層介面都會停止廣播。 19 00:01:09,780 --> 00:01:13,900 所以多播就像中間一樣，我們稱之為一對多。 20 00:01:13,900 --> 00:01:19,000 例如，多播的典型用例是所謂的串流傳輸 21 00:01:19,000 --> 00:01:26,120 影片.舉例來說，我公司的執行長已安排 22 00:01:26,120 --> 00:01:31,580 今天下午2點送上公司的國情咨文。 23 00:01:31,580 --> 00:01:33,520 好吧，讓我們把它說得更具體一些。 24 00:01:33,520 --> 00:01:36,200 工程狀態地址，好嗎？ 25 00:01:36,200 --> 00:01:38,840 所以他要站起來專門談工程 26 00:01:38,840 --> 00:01:42,360 部門、工程重點與願景。 27 00:01:42,360 --> 00:01:44,880 這就是他要談論的內容。 28 00:01:44,880 --> 00:01:50,060 所以在我們的工程部門，我們可能有 100 名分散的員工 29 00:01:50,060 --> 00:01:51,440 整個校園。 30 00:01:51,440 --> 00:01:52,420 他們並不都坐在一起。 31 00:01:52,420 --> 00:01:54,560 它們到處都是口袋裡的東西。 32 00:01:54,560 --> 00:02:00,000 好吧，我們在 2 點鐘位置安裝了一台攝影機，對準我的執行長。 33 00:02:00,000 --> 00:02:03,340 然後，該攝影機將返回到正在數位化的伺服器 34 00:02:03,340 --> 00:02:06,520 影片.所以現在我們必須考慮，好吧，我該如何發送它 35 00:02:06,520 --> 00:02:09,760 向這 100 名員工發送視訊串流嗎？ 36 00:02:09,760 --> 00:02:13,160 也許並不是所有人都想看到它，對吧？ 37 00:02:13,160 --> 00:02:17,000 也許其中一些員工正在度假，他們的筆記型電腦在這裡 38 00:02:17,000 --> 00:02:17,520 他們正在奔跑。 39 00:02:17,520 --> 00:02:19,960 它們被鎖在桌子上，但就這樣消失了。 40 00:02:19,960 --> 00:02:21,740 員工不在這裡。 41 00:02:21,740 --> 00:02:23,780 其他人則可能不太關心。 42 00:02:23,780 --> 00:02:26,660 他們認為執行長充滿了誇誇其談，他們不看視頻 43 00:02:26,660 --> 00:02:28,800 不再了。他們不看直播。 44 00:02:28,800 --> 00:02:33,040 因此，將會有一部分員工和工程人員想要 45 00:02:33,040 --> 00:02:34,300 觀看此視訊串流。 46 00:02:34,300 --> 00:02:35,420 那我們要如何把它交給他們呢？ 47 00:02:35,420 --> 00:02:41,280 假設這 100 名員工中，可能有 60、60 個人想看 48 00:02:41,280 --> 00:02:42,580 這個視訊串流。 49 00:02:42,580 --> 00:02:47,420 好吧，如果您曾經研究過有關多播影片的任何內容，其中之一 50 00:02:47,420 --> 00:02:51,500 群播影片的特點是通常非常佔用頻寬 51 00:02:51,500 --> 00:02:55,640 飢餓的。群播影片會消耗大量頻寬，尤其是當您 52 00:02:55,640 --> 00:02:59,700 談論高清就像高清視訊串流。 53 00:02:59,700 --> 00:03:02,140 它確實會消耗大量頻寬。 54 00:03:02,140 --> 00:03:06,500 因此，如果我有我的多播伺服器，以便它連接到該攝影機，那就是 55 00:03:06,500 --> 00:03:10,120 數位化，變成 MPEG 或 ABI 或類似的東西，它是 56 00:03:10,120 --> 00:03:14,180 將其作為多播發送出去，好吧，我們有一些選擇。 57 00:03:14,180 --> 00:03:18,060 我們可以將其作為單播流發送出去，其中 60 名員工中的每一位 58 00:03:18,060 --> 00:03:22,700 必須點擊某個網頁，該網頁會向我的伺服器發送單播訊息 59 00:03:22,700 --> 00:03:27,820 然後我的伺服器的 CPU 必須建立資料包的副本並將其發送 60 00:03:27,820 --> 00:03:32,200 給那個人。現在想像一下，如果 60 個人都這麼做的話 61 00:03:32,200 --> 00:03:34,900 會要求該伺服器做很多工作。 62 00:03:34,900 --> 00:03:37,960 它必須採用該視訊串流，這可能是，讓我們製作它 63 00:03:37,960 --> 00:03:41,140 很簡單，每秒 256 kb。 64 00:03:41,140 --> 00:03:42,560 這是一個相當慢的流。 65 00:03:42,560 --> 00:03:44,580 這是相當小的頻寬流。 66 00:03:44,580 --> 00:03:50,360 想像一下每秒 256 kb 的封包，它必須複製這 60 個封包 67 00:03:50,360 --> 00:03:54,640 60 個單獨的單播流的時間。 68 00:03:54,640 --> 00:03:58,520 伺服器很可能會很難做到這一點。 69 00:03:58,520 --> 00:04:01,960 想像一下這會為實際網路基礎設施帶來什麼樣的負載。 70 00:04:01,960 --> 00:04:07,620 這相當於 256 kbps 乘以 60 個單播流。 71 00:04:07,620 --> 00:04:09,640 可能不想這樣做。 72 00:04:09,640 --> 00:04:11,760 你說，好吧，我為什麼不直接廣播呢？ 73 00:04:11,760 --> 00:04:15,420 嗯，第一，廣播無法覆蓋所有人，因為我們知道 74 00:04:15,420 --> 00:04:17,560 路由器丟棄廣播。 75 00:04:17,560 --> 00:04:21,020 我說這些員工分散在整個園區。 76 00:04:21,020 --> 00:04:22,700 他們並不都坐在一起。 77 00:04:22,700 --> 00:04:28,300 即使理論上我可以讓我的路由器強迫它們淹沒 78 00:04:28,300 --> 00:04:33,820 這次廣播將會影響我公司的每個人。 79 00:04:33,820 --> 00:04:37,560 這將影響工資、人力資源和 80 00:04:37,560 --> 00:04:43,000 行銷部門，因為他們所有的連結都將飽和 81 00:04:43,000 --> 00:04:46,440 包含視訊的廣播流量。 82 00:04:46,440 --> 00:04:49,060 這就是多播發揮作用的地方。 83 00:04:49,060 --> 00:04:54,400 因此，透過多播，伺服器只需建立一個流量流， 84 00:04:54,400 --> 00:04:56,180 一股交通流。 85 00:04:56,180 --> 00:04:59,940 一股流量將流向一個特殊的群體，他們稱之為群體 86 00:04:59,940 --> 00:05:02,760 目標位址或 GDA。 87 00:05:02,760 --> 00:05:06,020 等一下，我將向您展示它們的樣子。 88 00:05:06,020 --> 00:05:10,220 現在，您可能想知道，我們如何將其到達所有 89 00:05:10,220 --> 00:05:14,420 在我公司裡，只有那 60 位工程人員真正會 90 00:05:14,420 --> 00:05:16,080 獲取該串流。 91 00:05:16,080 --> 00:05:17,400 這是如何運作的？ 92 00:05:17,400 --> 00:05:20,040 嗯，這基本上是一個多部分的過程。 93 00:05:20,040 --> 00:05:24,820 所以第一，員工必須有某種應用程序 94 00:05:24,820 --> 00:05:28,060 他們的筆記型電腦。它可能會嵌入到他們的網頁瀏覽器中。 95 00:05:28,060 --> 00:05:31,440 但他們必須有一些可以點擊查看清單的東西 96 00:05:31,440 --> 00:05:35,260 目前正在發生的所有多播流，例如 97 00:05:35,260 --> 00:05:37,520 目錄，如節目指南。 98 00:05:37,520 --> 00:05:39,220 你可能會想到。 99 00:05:39,220 --> 00:05:45,980 通常情況下，您的筆記型電腦，那些員工的筆記型電腦，會看到各種各樣的 100 00:05:45,980 --> 00:05:47,120 乙太網路幀。 101 00:05:47,120 --> 00:05:49,940 如果你想一想，如果你現在坐在一個立方體裡，而你實際上 102 00:05:49,940 --> 00:05:54,140 透過硬連線乙太網路連接進行硬連線，該乙太網路連接 103 00:05:54,140 --> 00:05:56,580 看到很多不同的乙太網路幀，對嗎？ 104 00:05:56,580 --> 00:05:58,400 不僅僅是為您準備的框架。 105 00:05:58,400 --> 00:06:03,460 因此，在第二層，您的乙太網路 NIC 卡會說，好吧，如果每個幀 106 00:06:03,460 --> 00:06:07,180 我看到，每秒可能有數以萬計的飛行 107 00:06:07,180 --> 00:06:11,080 通過，它會查看每一個的目標 MAC 位址 108 00:06:11,080 --> 00:06:13,920 幀。它問自己一個問題。 109 00:06:13,920 --> 00:06:17,260 它說，該目標 MAC 位址是廣播嗎？ 110 00:06:17,260 --> 00:06:21,560 如果是，我必須把它撿起來，發送到我的 CPU 並處理它。 111 00:06:21,560 --> 00:06:26,360 或者說，是單播MAC位址，也就是我的MAC位址嗎？ 112 00:06:26,360 --> 00:06:29,000 如果是這樣，我會把它撿起來並處理它。 113 00:06:29,000 --> 00:06:32,560 如果答案是否定的，對於其中任何一個問題，就讓它飛吧 114 00:06:32,560 --> 00:06:34,240 就過去了，不要撿起來。 115 00:06:34,240 --> 00:06:35,640 不要處理它。 116 00:06:35,640 --> 00:06:39,220 因此，當您進入多播應用程式、目錄、程式時 117 00:06:39,220 --> 00:06:40,600 指導，而你... 118 00:06:40,600 --> 00:06:44,880 所以首先，必須有一些伺服器，對嗎？ 119 00:06:44,880 --> 00:06:49,280 可能是一個網頁伺服器正在提供這個網頁，這個頁面 120 00:06:49,280 --> 00:06:50,120 你正在看。 121 00:06:50,120 --> 00:06:54,660 而且，你知道，當你訪問該伺服器時，當你訪問 employee.stream 時 122 00:06:54,660 --> 00:06:58,980 .com 或類似的東西，然後你就會得到這個網頁，這個網頁 123 00:06:58,980 --> 00:07:02,700 列出現在正在播放或將在某個時間播放的每個節目 124 00:07:02,700 --> 00:07:07,740 預定的時間。然後你可能在 GUI 中看不到這一點， 125 00:07:07,740 --> 00:07:11,860 還有在背景傳送到您的筆記型電腦時的網頁 126 00:07:11,860 --> 00:07:18,320 應該列出每個節目的多播組地址。 127 00:07:18,320 --> 00:07:22,220 所以當你點擊它時，你實際上在做的是編程 128 00:07:22,220 --> 00:07:25,440 你的網卡。你告訴網卡好不好，除了挑 129 00:07:25,440 --> 00:07:29,840 向我發送廣播和單播，現在我要你尋找 130 00:07:29,840 --> 00:07:33,700 特殊的二層MAC位址，即組播MAC位址。 131 00:07:33,700 --> 00:07:37,140 如果您看到該內容，請將其也發送到我的處理器。 132 00:07:37,140 --> 00:07:41,540 我想看到它，以便它顯示在我的 Windows Media Player 或我的 133 00:07:41,540 --> 00:07:44,440 Real Player，無論您正在觀看什麼。 134 00:07:44,440 --> 00:07:45,760 這是發生的一件事。 135 00:07:45,760 --> 00:07:49,520 必須發生一些事情，你的網卡才會說，啊，我現在需要 136 00:07:49,520 --> 00:07:50,620 尋找別的東西。 137 00:07:50,620 --> 00:07:52,220 我需要尋找這個多播。 138 00:07:52,220 --> 00:07:56,420 現在，此外，當您單擊該連結時喚醒您的網絡 139 00:07:56,420 --> 00:08:00,240 卡上，您還會產生 IGMP 封包。 140 00:08:00,240 --> 00:08:03,180 我們將在後續影片中詳細介紹這一點，但您要發送 141 00:08:03,180 --> 00:08:07,000 一個 IGMP 封包傳送到您的路由器、您的預設網關，然後您會說： 142 00:08:07,000 --> 00:08:10,540 嘿，如果你看到這個多播，請將其發送給我。 143 00:08:10,540 --> 00:08:14,540 我有興趣。我希望收到該流量。 144 00:08:14,540 --> 00:08:17,620 因此，在多播術語中，這意味著您的筆記型電腦就是所謂的 145 00:08:17,620 --> 00:08:19,640 多播接收器。 146 00:08:19,640 --> 00:08:21,300 您現在已成為接收者。 147 00:08:21,300 --> 00:08:25,520 我的例子是我的 60 名工程員工想要觀看 148 00:08:25,520 --> 00:08:29,680 在串流中，每個人都必須打開瀏覽器或打開一些 149 00:08:29,680 --> 00:08:34,580 應用程式並點擊該鏈接，上面寫著“首席執行官致力工程” 150 00:08:34,580 --> 00:08:37,100 今天下午 2 點所以他們點擊了那個。 151 00:08:37,100 --> 00:08:40,860 在這樣做的過程中，它會對他們的網卡進行編程，所以他們現在 152 00:08:40,860 --> 00:08:42,580 注意那些框架。 153 00:08:42,580 --> 00:08:45,900 他們的每台筆記型電腦都會向其預設網關發送 IGMP 訊息 154 00:08:45,900 --> 00:08:47,900 說，嘿，我想看看這個。 155 00:08:47,900 --> 00:08:52,080 然後在後台，他們的預設網關呼叫多播 156 00:08:52,080 --> 00:08:54,700 路由協議，可能是 PIM。 157 00:08:54,700 --> 00:08:58,780 然後 PIM 參與進來，PIM 構建了這個，這就是所謂的多播 158 00:08:58,780 --> 00:09:05,500 樹，這樣最終當該伺服器發送它的第一個多播時 159 00:09:05,500 --> 00:09:10,860 當資料包命中時，可能包含十分之一秒的視頻 160 00:09:10,860 --> 00:09:15,640 連接到該伺服器的第一個路由器，該路由器說， 161 00:09:15,640 --> 00:09:19,020 啊，我知道該發送到哪裡，因為我收到了一條 PIM 訊息，只有幾條 162 00:09:19,020 --> 00:09:23,220 幾分鐘前我的快速乙太網路介面說，要小心 163 00:09:23,220 --> 00:09:24,940 為了這。我要它。 164 00:09:24,940 --> 00:09:29,320 我還在我的快速乙太網路 1-1 介面上收到了來自另一個的訊息 165 00:09:29,320 --> 00:09:31,280 校園的一部分說，我想要它。 166 00:09:31,280 --> 00:09:34,160 所以現在路由器有責任接受這一組播 167 00:09:34,160 --> 00:09:36,700 傳入的資料包並複製它。 168 00:09:36,700 --> 00:09:41,640 它從一個介面發送一份副本，從另一個介面發送另一份副本。 169 00:09:41,640 --> 00:09:45,400 當這些多播封包從 170 00:09:45,400 --> 00:09:51,140 來源，即伺服器，當它到達路由器時，每個路由器依次詢問 171 00:09:51,140 --> 00:09:55,680 本身，我的多播路由表中是否有一個條目可以讓我知道 172 00:09:55,680 --> 00:09:57,040 這東西去哪了？ 173 00:09:57,040 --> 00:10:01,080 如果答案是肯定的，我是否有多個條目？ 174 00:10:01,080 --> 00:10:04,640 我是否需要複製此資料包並將其發送到多個介面？ 175 00:10:04,640 --> 00:10:10,000 最終它到達了其中一位工程人員的預設網關。 176 00:10:10,000 --> 00:10:14,760 預設網關說，啊，是的，我有一個通過 IgMP 的接口， 177 00:10:14,760 --> 00:10:17,560 我了解到那裡有一個主機，一個接收器想要接收 178 00:10:17,560 --> 00:10:20,700 它會將多播轉發給該人。 179 00:10:20,700 --> 00:10:23,440 所以只有有興趣的接收者才能得到它。 180 00:10:23,440 --> 00:10:28,180 其他筆記型電腦都沒有得到它，因為他們沒有點擊該連結。 181 00:10:28,180 --> 00:10:32,120 他們沒有對 NIC 卡進行編程以使其對多播感興趣 182 00:10:32,120 --> 00:10:35,840 MAC位址。這就是我們所說的一對多。 183 00:10:35,840 --> 00:10:39,460 對很短的子彈的長答案。 184 00:10:39,460 --> 00:10:42,780 因此，多播有很多有用的應用。 185 00:10:42,780 --> 00:10:45,760 正如我所提到的，例如視訊、視訊會議。 186 00:10:45,760 --> 00:10:49,800 很多時候，如果您在組織內部，多播將是 187 00:10:49,800 --> 00:10:51,200 用於視訊會議。 188 00:10:51,200 --> 00:10:54,160 正如我所提到的，某種企業溝通，首席執行官 189 00:10:54,160 --> 00:10:57,560 在一天中的某個時間發出多播。 190 00:10:57,560 --> 00:11:01,080 有時遠距學習也會使用它。 191 00:11:01,080 --> 00:11:04,820 例如，當你觀看我時，你會看到這個視頻 192 00:11:04,820 --> 00:11:08,260 現在，如果您實際上是現場觀眾的一部分，那麼您實際上可能是 193 00:11:08,260 --> 00:11:10,060 透過多播接收此資訊。 194 00:11:10,060 --> 00:11:13,360 我知道我們使用一家名為 BitGravity 的公司。 195 00:11:13,360 --> 00:11:16,400 這就是我們用來在整個範圍內傳播這一點的實際公司 196 00:11:16,400 --> 00:11:20,580 世界。我認為 BitGravity 實際上確實使用多播來傳遞它 197 00:11:20,580 --> 00:11:22,580 向下。但不確定。 198 00:11:22,580 --> 00:11:25,960 但你當然可以在你自己的本地打開像 Wireshark 這樣的嗅探器 199 00:11:25,960 --> 00:11:28,280 筆記型電腦並找出答案。 200 00:11:28,280 --> 00:11:33,140 有時會分發軟體、股票行情、新聞等等 201 00:11:33,140 --> 00:11:37,060 這些東西也經常用於多播。 202 00:11:37,060 --> 00:11:43,100 現場觀眾中也有人提到了多播的另一個好用途 203 00:11:43,100 --> 00:11:48,740 他說，在機場，有使用組播的 IP 攝影機。 204 00:11:48,740 --> 00:11:49,760 良好的觀察力。 205 00:11:49,760 --> 00:11:53,860 因此，安全部門可能會在航站樓內使用這些攝影機來 206 00:11:53,860 --> 00:11:54,380 觀察一切。 207 00:11:54,380 --> 00:12:01,520 它被多播回停車場的某些伺服器或攝影機， 208 00:12:01,520 --> 00:12:03,420 多播一切。 209 00:12:03,420 --> 00:12:09,480 太棒了。謝謝約翰提到這一點。 210 00:12:09,480 --> 00:12:13,480 所以我們討論了一些關於定位多播伺服器的問題。 211 00:12:13,480 --> 00:12:21,280 換句話說，你的筆記型電腦一開始並不知道什麼是多播 212 00:12:21,280 --> 00:12:25,060 正在發生。它不知道那裡是否有組播伺服器， 213 00:12:25,060 --> 00:12:27,740 從技術上講，我們稱之為多播源。 214 00:12:27,740 --> 00:12:33,520 因此必須先打開某種單播應用程序，這將 215 00:12:33,520 --> 00:12:37,780 為您顯示清單、目錄清單或節目指南 216 00:12:37,780 --> 00:12:40,620 各種可用的多播。 217 00:12:40,620 --> 00:12:47,180 這就是您的筆記型電腦首先了解來源的方式。 218 00:12:47,180 --> 00:12:49,720 現在，它可能不知道來源。 219 00:12:49,720 --> 00:12:54,380 例如，也許在我的例子中，執行長將要做 220 00:12:54,380 --> 00:12:56,140 視訊會議. 221 00:12:56,140 --> 00:13:01,580 我們整個校園裡有幾個不同的媒體工作室，對吧？ 222 00:13:01,580 --> 00:13:03,980 也許我的校園遍布整個城市。 223 00:13:03,980 --> 00:13:06,740 我在整個城市有大約 10 個不同的校區。 224 00:13:06,740 --> 00:13:10,900 我公司的每個園區都有一個視訊工作室 225 00:13:10,900 --> 00:13:15,320 一個攝影機和一個伺服器，能夠將某些內容多播出去。 226 00:13:15,320 --> 00:13:19,780 所以這是因為它遍布我的組織，那些伺服器 227 00:13:19,780 --> 00:13:22,440 具有明顯不同的 IP 位址。 228 00:13:22,440 --> 00:13:26,080 它們在地理位置上並不都位於同一子網路中。 229 00:13:26,080 --> 00:13:31,420 所以我們在多播發生之前不知道實際的IP位址是什麼 230 00:13:31,420 --> 00:13:34,760 是要執行此操作的伺服器，因為你和我 231 00:13:34,760 --> 00:13:38,960 坐在我們的辦公桌上，我們不知道執行長是哪個特定的工作室 232 00:13:38,960 --> 00:13:42,820 也許他們甚至故意保守這個秘密，因為 233 00:13:42,820 --> 00:13:46,120 他們不希望有人攻擊和轟炸那個工作室或其他地方。 234 00:13:46,120 --> 00:13:51,460 誰知道？所以很多時候當你的筆記型電腦第一次了解到多播時 235 00:13:51,460 --> 00:13:56,520 透過列出該節目指南的目錄進行串流傳輸，它會知道什麼 236 00:13:56,520 --> 00:13:58,100 目的地址是。 237 00:13:58,100 --> 00:14:01,320 他們會說，好吧，如果我收到這個視頻，它就會 238 00:14:01,320 --> 00:14:02,920 這個目的地址。 239 00:14:02,920 --> 00:14:04,320 這就是我想要了解的。 240 00:14:04,320 --> 00:14:09,200 但它可能不知道實際的來源位址是什麼 241 00:14:09,200 --> 00:14:12,320 該多播流的單播來源。 242 00:14:12,320 --> 00:14:14,240 順便說一句，這是一個非常關鍵的點。 243 00:14:14,240 --> 00:14:21,040 多播位址 99% 的時間，並非總是，但僅 99% 的時間 244 00:14:21,040 --> 00:14:26,040 顯示在乙太網路 MAC 位址的目標部分或目標中 245 00:14:26,040 --> 00:14:28,080 之前的 IP 或 IPP。 246 00:14:28,080 --> 00:14:30,300 所以它將是 6 個資料包。 247 00:14:30,300 --> 00:14:33,020 非常非常少會出現在原始碼中。 248 00:14:33,020 --> 00:14:37,240 大多數時候，來源位址是單播位址，因為它是 249 00:14:37,240 --> 00:14:41,580 來自一台正在進行多播的實體伺服器。 250 00:14:41,580 --> 00:14:45,100 現在，我聽說有一些防火牆和其他東西可以解決問題 251 00:14:45,100 --> 00:14:48,720 奇怪的多播，他們在源中這樣做，這就是一個整體 252 00:14:48,720 --> 00:14:52,260 其他蠕蟲球，但大多數時候，多播地址將 253 00:14:52,260 --> 00:14:53,860 只在目的地。 254 00:14:53,860 --> 00:14:56,740 所以我的筆記型電腦不知道來源是什麼。 255 00:14:56,740 --> 00:15:02,800 它說，看，我想看我的首席執行官，它說目的地地址， 256 00:15:02,800 --> 00:15:06,360 我會點擊它，對我的針織車進行編程，但它不知道來源。 257 00:15:06,360 --> 00:15:10,720 所以有時這些組播路由協定的啟動方式是 258 00:15:10,720 --> 00:15:14,960 路由器也不知道來源在哪裡。 259 00:15:14,960 --> 00:15:17,300 源剛開始。 260 00:15:17,300 --> 00:15:20,880 多播伺服器只需開始將多播資料泵送到 261 00:15:20,880 --> 00:15:25,460 電線。然後當第一個路由器得到它時，所以你可能 262 00:15:25,460 --> 00:15:28,120 說出該伺服器的預設網關。 263 00:15:28,120 --> 00:15:32,420 當第一個路由器收到它時，他說，嗯，好吧，這是第一個 264 00:15:32,420 --> 00:15:35,480 是時候我看到這個來源發送流了。 265 00:15:35,480 --> 00:15:39,200 不知道有沒有人有興趣看，畢竟 266 00:15:39,200 --> 00:15:42,500 其他路由器都不會與這個人交談，因為他們有 267 00:15:42,500 --> 00:15:44,460 不知道來源在哪裡。 268 00:15:44,460 --> 00:15:48,800 所以這個路由器可能會說，好吧，好吧，我在這裡有兩個選擇。 269 00:15:48,800 --> 00:15:52,720 如果我沒有運行多播路由協議，則丟棄流量，只需 270 00:15:52,720 --> 00:15:58,600 殺掉它。如果我正在運行多播路由協議，很可能 271 00:15:58,600 --> 00:16:02,980 接收多播的路由器會說，好吧，我不知道在哪裡 272 00:16:02,980 --> 00:16:05,880 接收者在哪裡，主機在哪裡想要得到這個。 273 00:16:05,880 --> 00:16:11,580 但是我的拓撲中有一些中央路由器正在運行一個特殊的 274 00:16:11,580 --> 00:16:14,480 我的路由多播路由協定的功能。 275 00:16:14,480 --> 00:16:19,040 他知道每個人在哪裡，因為每個人都告訴他所有的路由器 276 00:16:19,040 --> 00:16:23,960 我說過，嘿，喬路由器，如果你收到這個多播，我不知道 277 00:16:23,960 --> 00:16:24,880 如果你是或不是。 278 00:16:24,880 --> 00:16:28,060 但如果您看到這個目的地，請將其發送給我們。 279 00:16:28,060 --> 00:16:31,280 所以這裡有一些中央路由器的拓撲結構說，好吧， 280 00:16:31,280 --> 00:16:34,660 我聽過這個介面，這個介面，這個介面 281 00:16:34,660 --> 00:16:36,020 下面有人。 282 00:16:36,020 --> 00:16:39,800 等待取得這個特定的多播目的地。 283 00:16:39,800 --> 00:16:43,060 現在預設網關說，讓我接受這個多播並發送 284 00:16:43,060 --> 00:16:47,460 給他。然後他可以將其分發到樹上。 285 00:16:47,460 --> 00:16:51,360 所以很多時候在典型的多播中，來源位址在哪裡 286 00:16:51,360 --> 00:16:53,660 它的來源將是未知的。 287 00:16:53,660 --> 00:16:56,520 在某些情況下它是已知的，我們將討論這一點， 288 00:16:56,520 --> 00:17:01,520 尤其是當我們達到 GMP 第三版時。 289 00:17:01,520 --> 00:17:05,780 我們還必須討論多播分發方法，即推送與 290 00:17:05,780 --> 00:17:11,420 拉模型。讓我在這裡快速畫一些東西來證明這一點。 291 00:17:11,420 --> 00:17:16,880 假設這是我的多播伺服器。 292 00:17:16,880 --> 00:17:21,680 他已連接到路由器一。 293 00:17:21,680 --> 00:17:35,280 然後我們來畫一些其他的路由器。 294 00:17:35,280 --> 00:17:42,440 好吧，我們就說路由器二、三、四、五、六、七、八， 295 00:17:42,440 --> 00:17:51,680 九。好的，有兩種不同的高級方式進行多播 296 00:17:51,680 --> 00:17:54,360 路由協定起作用。 297 00:17:54,360 --> 00:17:57,460 一種方法就是我們所說的推送模型。 298 00:17:57,460 --> 00:18:02,120 您也會經常聽到這被稱為密集模式協議。 299 00:18:02,120 --> 00:18:08,820 因此，在密集模式協議中，會發生的情況是，假設我感興趣 300 00:18:08,820 --> 00:18:13,680 接收器就在這裡，就在這裡。 301 00:18:13,680 --> 00:18:18,200 所以這兩台紅色的電腦是唯一曾經表達過任何訊息的電腦 302 00:18:18,200 --> 00:18:22,440 有興趣接收多播視訊或音訊。 303 00:18:22,440 --> 00:18:28,600 嗯，在密集模式應用程式中，我們稱之為推送模型，當 304 00:18:28,600 --> 00:18:33,540 多播伺服器開始發送流量，一切都被淹沒了。 305 00:18:33,540 --> 00:18:39,760 它像這樣發送到每個路由器。 306 00:18:39,760 --> 00:18:43,360 是的，它實際上會到達我們的客戶手中。 307 00:18:43,360 --> 00:18:48,600 這個想法是，當它到達對此不感興趣的路由器時 308 00:18:48,600 --> 00:18:52,820 多播流量，他們會發回某種信令訊息， 309 00:18:52,820 --> 00:18:59,360 會修剪掉不需要的樹枝。 310 00:18:59,360 --> 00:19:03,460 所以最後，在這種推動發生之後，哎呀，我不想 311 00:19:03,460 --> 00:19:05,600 要刪除那個，那個就必須存在。 312 00:19:05,600 --> 00:19:10,720 在進行推送並進行修剪之後， 313 00:19:10,720 --> 00:19:14,060 現在我們只剩下多播僅轉發出介面 314 00:19:14,060 --> 00:19:15,660 它需要去哪裡。 315 00:19:15,660 --> 00:19:21,280 現在，如果所有這些鏈接都是非常高速的鏈接，例如所有 316 00:19:21,280 --> 00:19:25,460 其中一部分位於您的校園內，所有這些連結都相當於 10 GB 317 00:19:25,460 --> 00:19:28,980 連結或更快，你知道，太比特連結或其他東西，那麼你可以 318 00:19:28,980 --> 00:19:32,200 這樣做可能是因為您有足夠的空閒頻寬。 319 00:19:32,200 --> 00:19:35,160 你知道，誰在乎多播是否被淹沒在介面上 320 00:19:35,160 --> 00:19:37,800 它不需要去，因為無論如何你都有足夠的頻寬，所以 321 00:19:37,800 --> 00:19:39,420 把它剪掉就可以了。 322 00:19:39,420 --> 00:19:43,260 但很可能，您的網路可能不是這樣的。 323 00:19:43,260 --> 00:19:46,820 您可能有某些鏈接，我們的慢速鏈接，也許還有其他鏈接 324 00:19:46,820 --> 00:19:50,320 由於非常受歡迎而通常會出現擁塞的鏈接， 325 00:19:50,320 --> 00:19:53,780 而且您確實不希望您的多播被淹​​沒到各處。 326 00:19:53,780 --> 00:19:57,340 因此，在這種情況下，您想要的多播分發方法類型 327 00:19:57,340 --> 00:20:01,540 使用不是推模型，而是拉模型。 328 00:20:01,540 --> 00:20:06,120 這就是我到目前為止一直在談論的內容。 329 00:20:06,120 --> 00:20:16,800 因此，在拉模型中，通常首先要做的是多播 330 00:20:16,800 --> 00:20:23,180 接收器，即我的筆記型電腦，必須發送某種資料包來指示 331 00:20:23,180 --> 00:20:28,200 他們對這種多播感興趣，說，嘿，我想接收它。 332 00:20:28,200 --> 00:20:33,560 然後通常會在該網路中設定一些路由器 333 00:20:33,560 --> 00:20:36,340 具有非常特殊的功能。 334 00:20:36,340 --> 00:20:42,700 假設它是路由器二，我將使用字母 RP。 335 00:20:42,700 --> 00:20:46,620 現在，當您了解 PIM 協議時，您將了解更多相關內容 336 00:20:46,620 --> 00:20:51,760 第三層獨立多播，但這稱為集合點 337 00:20:51,760 --> 00:20:55,300 觀點。現在想想第二次約會這個詞，對嗎？ 338 00:20:55,300 --> 00:20:58,960 如果我和我的朋友說話，我會說，嘿，你今天想在哪裡見面 339 00:20:58,960 --> 00:21:00,220 那我們可以吃午餐了嗎？ 340 00:21:00,220 --> 00:21:04,220 也許我的朋友會說，哦，我們週五在 TGI 那個餐廳見面吃午餐吧。 341 00:21:04,220 --> 00:21:08,640 我可能會說，好吧，我會在那裡和你會合，這意味著會合。 342 00:21:08,640 --> 00:21:11,420 我會在那個地點與你會面。 343 00:21:11,420 --> 00:21:15,420 因此，在多播世界中，集合點基本上服務於 344 00:21:15,420 --> 00:21:21,180 相同的目的。所以一旦我的接收器，這些很可能會 345 00:21:21,180 --> 00:21:27,160 是 IGMP，或者如果我們談論的是 IPv6、MLDP、多播偵聽器 346 00:21:27,160 --> 00:21:30,120 協議，無論哪種方式，我都會在這裡完成它們。 347 00:21:30,120 --> 00:21:34,080 實際上，我們暫時保留 IPv4。 348 00:21:34,080 --> 00:21:44,800 所以 IGMP。所以我的接收者對他們的預設網關表示了興趣。 349 00:21:44,800 --> 00:21:50,860 現在，沒有人知道來源的實際 IP 位址是什麼 350 00:21:50,860 --> 00:21:52,640 的多播。 351 00:21:52,640 --> 00:21:56,080 或者實際上，即使來源確實存在，這也可能只是 352 00:21:56,080 --> 00:21:59,620 一個測試流，它甚至還沒有配置。 353 00:21:59,620 --> 00:22:03,080 所以，但是這些路由器，如果它們正在運行多播匯聚協議， 354 00:22:03,080 --> 00:22:07,660 他們所知道的是這個傢伙的IP位址，路由器二，我們的集合點 355 00:22:07,660 --> 00:22:13,300 觀點。因此，一旦他們從接收器收到指示， 356 00:22:13,300 --> 00:22:17,940 接收者想要接收多播，現在這些路由器要發送 357 00:22:17,940 --> 00:22:24,060 特殊訊息，一些多播路由訊息，直到集合點 358 00:22:24,060 --> 00:22:29,020 點，說，嘿，路由器二，如果你碰巧看到多播 359 00:22:29,020 --> 00:22:32,240 與這個目的地相匹配，我們就在這裡。 360 00:22:32,240 --> 00:22:33,600 我們想要得到它。 361 00:22:33,600 --> 00:22:36,320 現在集合點說，好吧，我還沒有收到任何東西 362 00:22:36,320 --> 00:22:41,680 還沒有，但如果我這樣做了，我會在這個介面上收到一條訊息，並且這個 363 00:22:41,680 --> 00:22:45,080 那裡有人想要取得它的介面。 364 00:22:45,080 --> 00:22:48,280 所以現在集合點就在他擺弄拇指的地方， 365 00:22:48,280 --> 00:22:50,880 等待查看多播是否會啟動。 366 00:22:50,880 --> 00:22:56,080 現在，我們只說幾分鐘或一小時後，實際的多播 367 00:22:56,080 --> 00:23:01,980 確實啟動了。好吧，這太棒了，因為現在我們有了這棵樹 368 00:23:01,980 --> 00:23:03,540 準備就緒並等待。 369 00:23:03,540 --> 00:23:06,200 所以這裡的這些線，這些紅線剛剛形成了一棵樹。 370 00:23:06,200 --> 00:23:09,540 這些是從集合點向下延伸的樹的分支 371 00:23:09,540 --> 00:23:12,740 到我們的接收者，我們的接收者已準備好並等待接收 372 00:23:12,740 --> 00:23:18,180 這。因此，一旦多播實際啟動，請查看此處的路由器一。 373 00:23:18,180 --> 00:23:21,400 他從未收到任何這些紅色箭頭。 374 00:23:21,400 --> 00:23:27,020 一號路由器從未收到過對此流的請求，因為他 375 00:23:27,020 --> 00:23:31,460 不是集合點，而且他也不在集合點的路徑上。 376 00:23:31,460 --> 00:23:35,840 但就像所有其他路由器一樣，他知道誰是集合點 377 00:23:35,840 --> 00:23:41,080 是。因此，他獲取該多播並將其轉發到集合點。 378 00:23:41,080 --> 00:23:45,800 現在集合點說，哦，好吧，有人已經問過 379 00:23:45,800 --> 00:23:49,540 為了它。他們要求將多播拉給他們，我知道 380 00:23:49,540 --> 00:23:53,380 他們在哪裡。所以現在我們將以這種方式發送多播，它 381 00:23:53,380 --> 00:23:56,500 發送給我預定的接收者。 382 00:23:56,500 --> 00:23:59,220 所以我們稱之為拉模型。 383 00:23:59,220 --> 00:24:02,840 記住在推送模型中，也就是我們所說的密集模式協議， 384 00:24:02,840 --> 00:24:05,660 多播開始並被淹沒到各處。 385 00:24:05,660 --> 00:24:09,220 由路由器向上游發送訊息說，嘿， 386 00:24:09,220 --> 00:24:10,240 我從來不想要這個。 387 00:24:10,240 --> 00:24:12,020 別再把它淹沒給我了。 388 00:24:12,020 --> 00:24:16,860 在拉模型（我們通常稱為稀疏模式協定）中，稀疏 389 00:24:16,860 --> 00:24:22,300 模式，這是接收者必須表明他們的興趣的地方，並且 390 00:24:22,300 --> 00:24:27,440 然後路由器必須將該興趣轉送到某個中央路由器 391 00:24:27,440 --> 00:24:29,100 我們稱之為集合點。 392 00:24:29,100 --> 00:24:33,300 所以我們提前預建路徑。 393 00:24:33,300 --> 00:24:37,500 然後，一旦多播進入，所有路由器都知道路徑是什麼 394 00:24:37,500 --> 00:24:40,820 是，以及將該多播轉發到哪裡。 395 00:24:40,820 --> 00:24:46,600 以上就是組播路由協定的兩種典型模式，push 396 00:24:46,600 --> 00:24:51,560 模式和拉模式，或稱為密集模式協定和稀疏模式