疑難雜症系列 - 1: 傳輸中斷
更新於 2024/12/08閱讀時間約 3 分鐘
這個系列將介紹一些在工作中遇到的奇形怪狀(?)的問題，這些問題更偏向於情境本身，而非程式語言的漏洞。我們將採用問答的方式，讓大家能夠一起思考。那麼，第一集我們就來探討：傳輸中斷。
問題描述
原本後台有一個下載/觀看影片的功能，這個功能行之有年，幾乎從未出錯。然而，近期卻有許多客戶反映，下載常常在一半的時候就失敗了。
已知情況
- 並不是所有影片都會失敗。
- 解析度越高的影片越容易下載失敗。
- 下載不一定一開始就失敗，通常是在進度條運行一段時間後，頁面突然當機導致失敗。
- 所有格式的影片檔都有可能發生下載失敗。
- 查看近一個月的 log 檔(更久之前的紀錄已被刪除)，發現下載檔案的 API 用量在三週前明顯增加，而在兩週前開始頻繁出現錯誤。
- 調整 API 的連線時間後，情況似乎有稍微好轉。
=================思考分隔線=================
解決方式
深入調查後，發現問題是由於檔案大小過大，導致接收回傳時出現中斷。這種情況在影片或高畫質圖片的檔案傳輸中尤為常見。其原因可能有多種，例如伺服器端的連線時長問題或使用者端的網路連線不穩等，都可能導致這一現象。
解決方法其實很簡單，只需將要傳送的檔案利用 byte-range 的方式進行分段傳輸即可。這部分可以參考 RFC 9110: HTTP Semantics。
另外需要特別注意的是，由於某些瀏覽器或 proxy 會檢查 header 的長度以避免不正常傳輸，因此這部分需要額外進行調整喔！
參考資料
留言0
查看全部
你可能也想看
Google News 追蹤
本文探討了複利效應的重要性，並藉由巴菲特的投資理念，說明如何選擇穩定產生正報酬的資產及長期持有的核心理念。透過定期定額的投資方式，不僅能減少情緒影響，還能持續參與全球股市的發展。此外，文中介紹了使用國泰 Cube App 的便利性及低手續費，幫助投資者簡化投資流程，達成長期穩定增長的財務目標。
訊息的即時傳遞已然成為現代社會的趨勢了， 影音也是如此， 即時！ 即時！ 即時！ 已經是目前使用者體驗的必要元素了， 在這邊我們要分享的主題是如何在python程式語言的情境下使用ffmpeg來將音檔串流的轉換格式， 為什麼會有這樣的需求呢？ 因為我們處理音檔時可能會需要統一輸出的格式， 當然背後也
在網路速度有限的情況下，依序記錄不斷產生的資訊，能統計使用者在頁面上操作了哪些功能。
需求情境：
在設計畫面時，資料來源是後台的 api，每一次畫面細節的修修改改，都會觸發 Xcode Preview 程序，導致不斷呼叫後台。此時若資料結構和大小都具有一定規模，就會導致效率低落，不斷等待，且消耗伺服器資源甚鉅。
解決方案：
將後台傳回的資料以檔案形式暫存在本地端，每次 pr
更快、更短、更即時是串流傳輸必要的元素， 而我們常常在使用Python請求API時都是等待式回應， 也就是一個請求過去之後， 待對方處理完畢後再行回應， 但假設需要下載的檔案、內容非常大時， 是不是使用者只能傻傻的等待整個傳輸結束後才能顯示？ 這樣的使用者體驗也實在太糟糕了， 對於使用者來說除了完全
在讀取檔案時，最怕路徑的問題，常常會有路徑錯誤造成的異常報錯。
為了避免諸如此類的問題發生，明白程式的當前目錄與檔案的路徑是很重要的。
可以利用os 模組是 Python 中的一個標準庫，提供了許多與操作系統的功能。
以下是一些常用的 os 模組基本操作及其範例：
1. os.getcwd
我們在「【🎓 Python的深度問答集】torchaudio 對部分段落進行音訊解碼」有分享到如何對一包包的封包進行音訊解碼， 但隨著音檔越大， 最終解碼的速度會越來越慢， 而這並非串流的本意， 串流應該就像水管一樣， 收到多少資料就運算多少量， 並不會隨著累積的容量越大而導致效能下降。
但實際
當你在開發程式時，難免會遇到各種錯誤和異常情況。這些錯誤可能是因為代碼中的錯誤、外部資源無法訪問或其他不可預期的狀況。為了提高程式的可靠性、穩定性和可維護性，我們使用「例外處理」來處理這些異常情況。
Request內容
package main
import (
"fmt"
"log"
"net/http"
"strings"
)
func request(w http.ResponseWriter, r *http.Request) {
//這些資訊是輸出到伺服器端的列印訊息
本文探討了複利效應的重要性，並藉由巴菲特的投資理念，說明如何選擇穩定產生正報酬的資產及長期持有的核心理念。透過定期定額的投資方式，不僅能減少情緒影響，還能持續參與全球股市的發展。此外，文中介紹了使用國泰 Cube App 的便利性及低手續費，幫助投資者簡化投資流程，達成長期穩定增長的財務目標。
訊息的即時傳遞已然成為現代社會的趨勢了， 影音也是如此， 即時！ 即時！ 即時！ 已經是目前使用者體驗的必要元素了， 在這邊我們要分享的主題是如何在python程式語言的情境下使用ffmpeg來將音檔串流的轉換格式， 為什麼會有這樣的需求呢？ 因為我們處理音檔時可能會需要統一輸出的格式， 當然背後也
在網路速度有限的情況下，依序記錄不斷產生的資訊，能統計使用者在頁面上操作了哪些功能。
需求情境：
在設計畫面時，資料來源是後台的 api，每一次畫面細節的修修改改，都會觸發 Xcode Preview 程序，導致不斷呼叫後台。此時若資料結構和大小都具有一定規模，就會導致效率低落，不斷等待，且消耗伺服器資源甚鉅。
解決方案：
將後台傳回的資料以檔案形式暫存在本地端，每次 pr
更快、更短、更即時是串流傳輸必要的元素， 而我們常常在使用Python請求API時都是等待式回應， 也就是一個請求過去之後， 待對方處理完畢後再行回應， 但假設需要下載的檔案、內容非常大時， 是不是使用者只能傻傻的等待整個傳輸結束後才能顯示？ 這樣的使用者體驗也實在太糟糕了， 對於使用者來說除了完全
在讀取檔案時，最怕路徑的問題，常常會有路徑錯誤造成的異常報錯。
為了避免諸如此類的問題發生，明白程式的當前目錄與檔案的路徑是很重要的。
可以利用os 模組是 Python 中的一個標準庫，提供了許多與操作系統的功能。
以下是一些常用的 os 模組基本操作及其範例：
1. os.getcwd
我們在「【🎓 Python的深度問答集】torchaudio 對部分段落進行音訊解碼」有分享到如何對一包包的封包進行音訊解碼， 但隨著音檔越大， 最終解碼的速度會越來越慢， 而這並非串流的本意， 串流應該就像水管一樣， 收到多少資料就運算多少量， 並不會隨著累積的容量越大而導致效能下降。
但實際
當你在開發程式時，難免會遇到各種錯誤和異常情況。這些錯誤可能是因為代碼中的錯誤、外部資源無法訪問或其他不可預期的狀況。為了提高程式的可靠性、穩定性和可維護性，我們使用「例外處理」來處理這些異常情況。
Request內容
package main
import (
"fmt"
"log"
"net/http"
"strings"
)
func request(w http.ResponseWriter, r *http.Request) {
//這些資訊是輸出到伺服器端的列印訊息