瀏覽器在傳送請求時都會帶著 accept-encoding 頭欄位，裡面是瀏覽器支援的壓縮格式列表，例如 gzip、deflate、br 等，這樣伺服器就可以從中選擇一種壓縮演算法，放進 content-encoding 響應頭里，再把原資料壓縮後發給瀏覽器。
如果壓縮率有 50%，那麼 100k 的資料壓完之後只剩 50k，相當於在頻寬不變的情況下網速快了一倍。
除了壓縮檔案之外，另一種辦法就是分塊傳輸。它們的原理差不多，都是把大檔案變小傳輸。分塊傳輸會把乙個大檔案切成很多小塊，把這些小塊依次發給瀏覽器，瀏覽器收到之後再組裝復原。這樣瀏覽器和伺服器都不用在記憶體中儲存全部檔案，每次只收發一小部分，網路也不會被大檔案長時間占用，記憶體、頻寬等資源也就節省下來了。
具體實現是在 response 響應報文裡用頭字段 transfer-encoding: chunked 來表示，表示報文裡的 body 部分不是一次性發過來的，而是分成了許多的塊（chunk）逐個傳送。當 chunk 為 0 時說明是最後乙個，傳輸結束。
transfer-encoding 和 content-length 兩個欄位是互斥的，不能同時出現。乙個響應報文的長度要麼是已知的，要麼是未知的。
為什麼會有範圍請求？
你看電影時，想跳過開頭直接看正片，這實際上是想獲取乙個大檔案其中的片段資料，而分塊傳輸沒有這個能力。
http 協議為了滿足這種需求，提出了「範圍請求」的概念，允許客戶端在請求頭里使用專用欄位來表示只獲取檔案的一部分。
範圍請求不是 web 伺服器必須實現的功能，所以伺服器必須在響應頭里使用字段 「accept-ranges: bytes 」明確告知客戶端自己支援範圍請求。如果不支援的話，伺服器就會傳送「accept-ranges：none」或者不傳送此欄位。這樣客戶端就只能收發整塊檔案了。
請求頭 range 是 http 範圍請求的專用字段，格式是「bytes=x-y」，其中的 x 和 y 是以位元組為單位的資料範圍。要注意 x、y 表示的是「偏移量」，範圍必須從 0 計數，例如前 10 個位元組表示為「0-9」，第二個 10 位元組表示為「10-19」，而「0-10」實際上是前 11 個位元組。
range 的格式也很靈活，起點 x 和終點 y 可以省略，能夠很方便地表示正數或者倒數的範圍。假設檔案是 100 個位元組，那麼：
「0-」表示從文件起點到文件終點，相當於「0-99」，即整個檔案；
「10-」是從第 10 個位元組開始到文件末尾，相當於「10-99」；
「-1」是文件的最後乙個位元組，相當於「99-99」；
「-10」是從文件末尾倒數 10 個位元組，相當於「90-99」。
伺服器收到 range 欄位後，需要做四件事。
第一，它必須檢查範圍是否合法，比如檔案只有 100 個位元組，但請求「200-300」，這就是範圍越界了。伺服器就會返回狀態碼 416，表示範圍請求有誤，無法處理。
第二，如果範圍正確，伺服器就可以根據 range 頭計算偏移量，讀取檔案的片段了，返回狀態碼 206 partial content，表示 body 只是原資料的一部分。
第三，伺服器要新增乙個響應頭欄位 content-range，告訴片段的實際偏移量和資源的總大小，格式是 「bytes x-y/length」，與 range 頭區別在沒有「=」，範圍後多了總長度。例如，對於「0-10」的範圍請求，值就是「bytes 0-10/100」。
最後剩下的就是傳送資料了，直接把片段用 tcp 發給客戶端，乙個範圍請求就算是處理完了。
Linux傳輸大檔案（分割傳輸）
1.分拆為多個檔案的命令 cat workspace 2018.tar.gz split b 1g workspace 2018.tar.gz.命令解釋 拆分成1g的小檔案 workspace 2018.tar.gz.是拆分後檔案的字首，預設分拆後檔名稱為workspace 2018.tar.gz....
用 VC socket 傳輸大檔案
在這個程式中，客戶端讀取桌面的乙個 1.48 gb 1,597,701,030 位元組 的rar檔案傳送給伺服器。因為這裡僅用於學習，所以客戶端要連線的目標位址使用127.0.0.1。伺服器端接將收的檔案檔案儲存在c盤根目錄下。為保證程式的可靠傳送，程式採用tcp協議。經過反覆試驗得出結論，程式中的...
怎麼遠端傳輸大檔案？
傳統的傳輸方式主要分為 http與ftp。我們常用的郵件傳送就是http的一種，其主要是便捷，簡單。然後很多http 伺服器對鏈結超時 檔案大小等都用種種限制，這主要是因為其最初是為了網頁進行開發設計的一種協議。而ftp是另外一種較為常用的傳輸工具，其優點與http相似，雖然網路頻寬的增加，ftp的...