https://zh.wikipedia.org/wiki/WebRTC
https://webrtc.org/
https://blog.gtwang.org/web-development/webrtc-media-stream/
WebSocket與MSE:
https://kknews.cc/zh-tw/tech/anvlzgn.html
example:b站
TCP v.s. UDP
http://opencourse.ncyu.edu.tw/ncyu/file.php/15/week10/TCP%E8%88%87UDP.pdf
Polling、Long-Polling 與 Streaming:
輪詢（polling）的做法是讓瀏覽器每隔一段時間就自動送出一個 HTTP 請求給伺服器
這個我像就是我最初作的方式，setTimeout
長時間輪詢（long-polling）則是讓伺服器在接收到瀏覽器所送出 HTTP 請求後，伺服器會等待一段時間，若在這段時間裡面伺服器有新的資料，它就會把最新的資料傳回給瀏覽器，如果等待的時間到了之後也沒有新資料的話，就會送一個回應給瀏覽器，告知瀏覽器資料沒有更新。
雖然長時間輪詢可以減少產生原本輪詢（polling）造成網路頻寬浪費的狀況，但是如果在資料更新很頻繁的狀況下，長時間輪詢並不會比傳統的輪詢有效率，而且有時候資料量很大時，會造成連續的 polls 不斷產生，反而會更糟糕。
這個我想前端的做法還是一樣的，不一樣的是後端
串流（streaming）是讓伺服器在接收到瀏覽器所送出 HTTP 請求後，立即產生一個回應瀏覽器的連線，並且讓這個連線持續一段時間不要中斷，而伺服器在這段時間內如果有新的資料，就可以透過這個連線將資料馬上傳送給瀏覽器。
這個方式雖然不錯，但是由於他是建立在 HTTP 協定上的一種傳輸機制，所以有可能會因為代理伺服器（proxy）或防火牆（firewall）將其中的資料存放在緩衝區中，造成資料回應上的延遲，因此許多使用串流的 Comet 實作會在偵測到有代理伺服器的狀況時，改用長時間輪詢的方式處理。另外透過 TLS（SSL）的連線也可以避免緩衝區的問題，但是這個方式除了設定麻煩之外，也會造成伺服器額外的負擔。
這個狀況在你要擴充系統的規模時會更糟糕，使用 HTTP 來實作雙向的資料傳輸是一件很麻煩的事情，在維護很容易出問題，擴充也會有困難，縱使你的使用者感覺這樣即時性的網頁應用程式很好用，但是使用這樣的架構同時會讓你的伺服器與網路承受很大的工作負載量。
這個不知道實際是怎麼做的，但也比較退流行了，先不研究
雙工（duplex）， 指二台通訊裝置之間，允許有雙向的資料傳輸
WebSocket 通訊協定
WebSocket 是定義在 HTML5 標準中的一個新的網頁傳輸方式，可在一條連線上提供全雙工、雙向的資料傳輸，在這樣的標準下你可以很容易實作一個兼具可擴充性與即時性的網頁應用程式。另外因為 WebSocket 提供瀏覽器一個原生（native）的 socket，所以直接解決了 Comet 架構很容易出錯的問題，而在整個架構的複雜度上也會比傳統的做法簡單很多。
瀏覽器與伺服器之間若要建立一條 WebSocket 連線，在一開始的交握（handshake）階段中，要先從 HTTP 協定升級為 WebSocket 協定，瀏覽器送出：
https://blog.gtwang.org/web-development/websocket-protocol/
https://blog.csdn.net/xuchen16/article/details/81064196 (流的示例程式碼跟之前看到的原理接不起來..這部分沒看懂)
http://www.websocket.org/ 官網
多人連線，後端自動發送:
前端:
後端:
https://medium.com/enjoy-life-enjoy-coding/javascript-websocket-%E8%AE%93%E5%89%8D%E5%BE%8C%E7%AB%AF%E6%B2%92%E6%9C%89%E8%B7%9D%E9%9B%A2-34536c333e1b
websocket(訊息傳遞)不能取代streaming(影片串流)
Polling、Long-Polling 與 Streaming:
輪詢（polling）的做法是讓瀏覽器每隔一段時間就自動送出一個 HTTP 請求給伺服器
這個我像就是我最初作的方式，setTimeout
長時間輪詢（long-polling）則是讓伺服器在接收到瀏覽器所送出 HTTP 請求後，伺服器會等待一段時間，若在這段時間裡面伺服器有新的資料，它就會把最新的資料傳回給瀏覽器，如果等待的時間到了之後也沒有新資料的話，就會送一個回應給瀏覽器，告知瀏覽器資料沒有更新。
雖然長時間輪詢可以減少產生原本輪詢（polling）造成網路頻寬浪費的狀況，但是如果在資料更新很頻繁的狀況下，長時間輪詢並不會比傳統的輪詢有效率，而且有時候資料量很大時，會造成連續的 polls 不斷產生，反而會更糟糕。
這個我想前端的做法還是一樣的，不一樣的是後端
串流（streaming）是讓伺服器在接收到瀏覽器所送出 HTTP 請求後，立即產生一個回應瀏覽器的連線，並且讓這個連線持續一段時間不要中斷，而伺服器在這段時間內如果有新的資料，就可以透過這個連線將資料馬上傳送給瀏覽器。
這個方式雖然不錯，但是由於他是建立在 HTTP 協定上的一種傳輸機制，所以有可能會因為代理伺服器（proxy）或防火牆（firewall）將其中的資料存放在緩衝區中，造成資料回應上的延遲，因此許多使用串流的 Comet 實作會在偵測到有代理伺服器的狀況時，改用長時間輪詢的方式處理。另外透過 TLS（SSL）的連線也可以避免緩衝區的問題，但是這個方式除了設定麻煩之外，也會造成伺服器額外的負擔。
這個狀況在你要擴充系統的規模時會更糟糕，使用 HTTP 來實作雙向的資料傳輸是一件很麻煩的事情，在維護很容易出問題，擴充也會有困難，縱使你的使用者感覺這樣即時性的網頁應用程式很好用，但是使用這樣的架構同時會讓你的伺服器與網路承受很大的工作負載量。
這個不知道實際是怎麼做的，但也比較退流行了，先不研究
雙工（duplex）， 指二台通訊裝置之間，允許有雙向的資料傳輸
WebSocket 通訊協定
WebSocket 是定義在 HTML5 標準中的一個新的網頁傳輸方式，可在一條連線上提供全雙工、雙向的資料傳輸，在這樣的標準下你可以很容易實作一個兼具可擴充性與即時性的網頁應用程式。另外因為 WebSocket 提供瀏覽器一個原生（native）的 socket，所以直接解決了 Comet 架構很容易出錯的問題，而在整個架構的複雜度上也會比傳統的做法簡單很多。
瀏覽器與伺服器之間若要建立一條 WebSocket 連線，在一開始的交握（handshake）階段中，要先從 HTTP 協定升級為 WebSocket 協定，瀏覽器送出：
https://blog.gtwang.org/web-development/websocket-protocol/
https://blog.csdn.net/xuchen16/article/details/81064196 (流的示例程式碼跟之前看到的原理接不起來..這部分沒看懂)
http://www.websocket.org/ 官網
多人連線，後端自動發送:
前端:
ws.onmessage = function(evt) {
console.log(evt)
後端:
ws.on('message', data => {
//取得所有連接中的 client
let clients = wss.clients //多人連線
//做迴圈，發送訊息至每個 client
clients.forEach(client => {
client.send(data)
})
})
const sendNowTime = setInterval(()=>{ //後端自動發送
ws.send(String(new Date()))
},1000)
ws.on('close', () => {
clearInterval(sendNowTime)
console.log('Close connected')
})
websocket(訊息傳遞)不能取代streaming(影片串流)
沒有留言:
張貼留言