Re: [討論] 民視YT消失的44秒

※ 引述《goldenfire (耶穌流刑獄情指黑中心)》之銘言： : 這位不知道是不是資工系畢業的 : 但至少我是 : 雖然英文不怎樣、計網當初好像也讀得普普而已 : 現在在做演算法博士 : 不過這一點基礎知識也還是有 : 先說結論：你的問題根本不是計網讀不好 : 而是應該要有點英文閱讀能力 謝謝你還有 tsubasawolfy TonyQ femlro 的回覆 你們是比較有誠意出來討論的 因為每日發文限制的關係 我統一回覆在這裡 : ※ 引述《menesn (迷思)》之銘言： : 直播者-----A------Youtube Server -----B----- 看直播的 直播者跟觀看直播的是兩個傳輸點 中間不管經過多少網路節點 TCP通訊協議的定義 就是應該不掉包 除非是訊號源有問題 : 這篇文章就講出來了 : "I was capturing youtube video packets using wireshark. I saw it was http : tunneled over tcp packet." : 意思是，他是看直播的，不是開直播的人 : Youtube這裡的串流技術，是指轉播的B部分 其實StackOverflow問問題的人 主要想了解的是YT串流技術的背後 是使用哪一個通訊協定 他甚至用Wireshark去抓包 從封包的分析來看 是http tunneled over tcp的封包 底下有人留言 當YT後來有針對 如果有人在中間攔截串流的封包 (Man in the middle attack) 近期有特別做優化 也有實作UDP的部分 但是確實使用的協議是TCP The exact protocol is tcp; although YouTube has been switching over to UDP as of late : 所以Youtube為什麼不給你看，你要去問Youtube : 至於上傳端的部分 : 他們網頁就有寫了 : https://support.google.com/youtube/answer/2853702?hl=en : 上傳的部分是用 RTMP/RTMPS Streaming : 這部分就是使用UDP+TCP : 所以A部分掉包不要求重傳是很有可能的 這個網頁主要是在解釋 你在使用客戶端設定的時候 加密器的設定 (Encoder setting) 這完全是在針對使用者介面 做額外的說明而已 雖然他有提到RTMP/RTMPS 但是我剛才打開我的YoutubeStudio https://imgur.com/O888fPj 他預設就是RTMP 你把選項點開 也沒有RTMPS的選項給你選 RTMP背後也仍然是TCP : 你說的技術本身沒有問題 : 問題在於你連技術運用的對象是誰都不知道 : 是笨還是壞 : 就向民視陳經理說的 : 就交給大家判斷的 你是演算法博士 乃是國之棟樑 也是知識份子的代表 大家理性討論 也無需要用言語去貶低別人 酸說英語能力不好 貶低別人 可以滿足自我的優越感 但是無益於理性討論與交流 也不會增加閱聽者對您的尊敬 只是同溫層看到貶低不同意見者 會很爽而已 我在美國求學跟科技業共七年 不敢說自己英語能力有多強 但是看技術文件是絕對足夠的 --- 至於tsubasawolfy 在回文中提到 中間網路節點伺服器 以及VOD 其實也只是想混淆視聽而已 以通訊協議的定義來看 同一個點(都在民視直播間) 的區域網路 送出去的封包 送往FB的沒有中間截斷 但是 送往YT的確被中間截斷 (長達44秒) 代表這個區域網路 並沒有電力中斷 或者網路中斷等的現象發生 唯一可能 就是送出訊號源到YT的這端 有發生人為中斷訊號的現象 : 訊號不穩，觀眾端一定會LAG，VOD會留存到大lag前為止 這個腦捕的太嚴重了 不得不說 觀眾的客戶端是瀏覽器或者移動端的APP 根本沒有用到VOD(Video On Demand) 你到底想要偷渡甚麼概念? 觀眾的手機或者電腦 是要開甚麼VOD來側錄影片? 不要騙不懂技術的人 : 第一個如果像這PO說的，民視那邊有人手動斷開直播連結，那直播會被切成兩段才對 : 因為直播結束就結束了，你要重新拿一個新鑰匙 你以為我沒有用YT直播過嗎? 串流金鑰改變了 所以呢? 你民視有在串流的時候同時螢幕錄影 然後告訴大家說喔 我串流的金鑰沒有變 證明我沒有手動切斷 如果有 我很樂見民視公布完整的螢幕錄影 --- 至於TonyQ 的回文 : 而且這裡說的包是很多很微小的 bytes[] ，不是一整個影片。 : 所以不會因為你用了 tcp 就不掉包。下略很多字。 我講得包是Packet 一個Packet有64K bytes也不是甚麼微小數目了 44秒是真的很大一段 接下來你開始檢討應用層有問題 如果是應用層有問題 歡迎你提出，或者請民視提出 到底哪個用戶 真的在同樣的YT直播 收到完整的沒有44秒被中斷過的證據 最後你開始檢討YT後端伺服器有問題 老實說 我寧可相信YT工程師的實力 遠遠超過民視在操作直播的技術人員 我也自忖沒有這個實力 去檢討YT後端開發 會有甚麼問題 因為我很明白這個領域的專業度 (或許16年網頁工程師做過串流 有這個技術水平來指點一二? 你要把程式碼拿出來Review嗎? 我奉陪) 有人que我要回復TonyQ再推文的留言 以下是我看過後的回覆(12/22 9:11分左右) : 要做到即使斷線也不掉包，就是犧牲即時的速度， : 且要加上訊源端要能夠儲存足夠多cover中斷時間訊源的空間，另外再堆疊協議做到。 甚麼叫做 : 堆疊"協議" 我真是孤陋寡聞了 還有這種說法，你是寫甚麼code在應用層堆疊"協議"? : 問題是，這實際上跟先 buffer 個 n 分鐘再開始播， : 或者乾脆錄好事後再播的邏輯差不多了。 : 他是不是定義上的直播我都覺得問號。 訊號源要碼是使用YoutubeStudio的網頁介面 或者用OBS Studio或者Xsplit這些桌面應用層式 (這些都是很成熟的商業軟體喔 為什麼民視經理不說喔，那是我們使用的客戶端軟體有BUG 而是把問題推到YT身上?) 其實你提這麼多 就是想牽拖說阿這邊有問題那邊有問題 但是你忽略一個重點 就是同樣環境同個時間點 串流到臉書的居然沒問題 所以你去扯應用層網路環境都是在打假球而已 : tcp 不會掉包是嚴重的謬論 你在不同地方不斷提出 但是從來沒有解釋是怎樣的謬論 : 至於有沒有什麼是接收方（youtube）的環境問題，也是有可能的， : 甚至中午有人要加碼懷疑是ISP搞鬼，理論上也是有可能的。 請問民視直播間是用哪一間ISP? : 我們當前每個雲平台都有掛過一個小時以上的紀錄，gcp/azure/aws， : 我是覺得以他的量體來說，這些 edge case 我不覺得是容易抓完的問題。 我不確定你說的"我們"是指民視的網路技術部門 還是你現在工作的公司 雲平台掛掉一個小時 絕對不是AWS/GCP/Azure的問題 而是身為使用者的你們 技術力太弱? 拜託民視YT直播有多少人看? YT有過多少更大型的直播use case 你字裡行間真的自以為技術有多強也 有沒有github帳號 給眾網友瞻仰一下 : 以我自己用 rtsp 的經驗應該是可以續傳的，只是中間會有中斷。 : 是不是第二個直播，這是 ap 層的實作問題，與傳輸層無關。 中間有斷跟掉封包是兩回事 你難道不清楚嗎? 還是故意語焉不詳 來呼嚨閱聽者 : 我個人是覺得要怎麼陰謀論都可以，但是不要無視 ap 的風險， : 不要硬要鬼扯 TCP 一定不會掉包，或是 UDP 一定會掉包。 我還在等你解釋"tcp 不會掉包是嚴重的謬論" 甚麼叫做"無視 ap 的風險" AP層有問題 串到FB那邊的也會有問題啦 我早就提出質疑你能否證明 民視串流到YT跟FB 是在不同的區網還是不同的串流客戶端 到現在也沒有解釋 不是技術很強? 為什麼選擇性忽略? : 事實上我自己就偶爾會做流量大就放推的設計 （遮臉） 應用層的設計嗎? 還是傳輸層的實作? : 可能性太多了，硬要我猜的話， : 我個人推測會覺得是接收端那邊的 application 應該是被重分配了。 : 類似 container 被卸載重上之類的概念， : 所以出現了比較明顯的 downtime。 你以為拿普通人看不懂的名詞出來講 就可以唬弄過去 甚麼叫做接收端的application被重分配? 你的意思是YT伺服器把串流導到接收端的時候 出現分配不均勻的狀況嗎? 換言之，有些封包到了A點，有些封包到了B點 (A, B都是終端) container被卸載重上 接收端是哪裡有container啦 胡說八道 container(容器)在軟體工程是專有名詞 舉例，瀏覽器跟移動端的APP都是 直接安裝在原生的作業系統上 裡面並沒有內建容器 : 我當了那麼多年的軟工版板務。XD 所以你16年網頁工程師做過RTSP兼軟工板務嗎? 歡迎你把我的文章轉到軟工板 讓那邊的網友們檢視 : 這篇在軟體相關看板也撐得住的啦。 : 資料庫那段是在舉例應用實作的影響 你是串流串到資料庫裏面嗎? --- 至於femlro 你寫得內容 其實也就只是把網路 的一些概念 擷取一部分寫出來 告訴網友，喔其實這些網路 不同的分層應該是這樣子運作的啦 然後最後在天來一筆說 因為前面這樣那樣 所以太可能是民視手動干預 懂技術的人 看了就會覺得 你前面是在講廢話嗎? 然後結論到底怎麼突然跳出來 這跟民進黨政府 先編預算在編計畫的行為 有八十七分像 你是，先想好結論，再編理由 只是編的理由，漏洞百出 : 一個訊源三個輸出中有一個出現44秒的中斷 : 可能涉及到特定的應用層設定、伺服器資源管理、甚至是網絡路徑上的特定問題 我前面提到很多次 可能你沒看懂 一個訊號源在同一個區域網路 一個輸往FB終端 一個輸往YT終端 結果一個有問題一個沒有 那代表的就是 伺服器資源管理正常 網絡路徑沒有阻塞 至於應用層 我就說呀 民視經理在全國媒體面前 說有人收看沒問題 你們提得出證據嗎? 有人在你們YT頻道直播 的時候，看到"被消失的44秒嗎"? 不要只會貼甚麼二次元直播主啦 球賽啦 這種直播視頻跳秒數的影片 來混淆視聽 想要帶錯誤概念 直播視頻跳秒，跟掉封包完全是兩回事 認知作戰 也要拿出點水準來 如此低劣 -- 大道之行也，天下為公，選賢與能，講信修睦，故 人不獨親其親，不獨子其子，使老有所終，壯有所用，幼有所長， 鰥寡孤獨廢疾者皆有所養；男有分，女有歸， 貨 惡其棄於地也不必藏於己，力惡其不出於身也不必為己，是故 謀閉而不興，盜竊亂賊而不作， 故外戶而不閉，是謂大同。 -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 36.227.22.248 (臺灣) ※ 文章網址: https://www.ptt.cc/bbs/HatePolitics/M.1703171968.A.D0B.html