http分塊上傳
1. HTTP通信
HTTP通信過程包括從客戶端發往伺服器端的請求以及從伺服器端返回客戶端的響應.
用於HTTP協議交互的信息成為HTTP報文. 請求端發送的HTTP報文成為請求報文，響應端的叫做響應報文.
HTTP報文分為報文首部+空行+報文主體,通常並不一定有報文主體.
請求報文首部的結構如下:
響應報文首部的結構如下:
HTTP在傳輸數據時可以按照數據的原貌傳輸, 也可以在傳輸過程中編碼提升傳輸速率. 通過在傳輸時編碼, 能有效地處理大量的訪問請求. 但是編碼是計算機來完成的, 因此會需要消耗更多的CPU等資源.
報文(message):是HTTP通信的基本單位，由8位組位元組流組成，通過HTTP通信傳輸.
實體(entity):作為請求和響應的有效載荷數據(補充項)被傳輸，其內容由實體首部和實體主體組成.
HTTP報文的主體用於傳輸請求和響應的實體主體.
通常，報文主體等於是實體主體，只有當傳輸中進行編碼操作時，實體主體的內容發生變化，才導致它和報文主體產生差異. 個人理解為實體主體是編碼以後的報文主體.
HTTP協議中有一種被稱為 內容編碼 的功能可以實現壓縮內容的效果,內容編碼是在 實體內容 上的編碼格式,並保持實體信息原樣壓縮,內容編碼後的實體由客戶端接收並負責解碼.
內容編碼的常見幾種方式:
分塊傳輸編碼是將實體主體分割成多個部分(塊), 每一塊都會用十六進制來標記塊的大小,而實體主體的最後一塊會用"0"來標記.客戶端負責解碼,恢復到編碼前的實體主體.
MIME(Multipurpose Internet Mail Extensions, 多用途網際網路郵件擴展)機制, 允許郵件處理文本, 圖片, 視頻等各個不同類型的數據.
可以發送文本,圖片,視屏等不同類型的數據.
HTTP協議中也採納了多部分對象集合,發送的一份報文主體內可以包含多類型實體,通常在圖片或文本上傳時使用.
在HTTP報文中使用多部分對象集合時, 需要在首部欄位中加上Content-type欄位, Content-type欄位說明了實體主體內對象的媒體類型.
使用boundary欄位來劃分多部分對象集合指明的各類實體, 在boundary字元串指定的各個實體的起始行之前插入"--"標記做為開始, 在多部分對象集合對應的字元串的最後插入"--"標記做為結束. 如上以"--AbB03x"做為開始, 以"--AbB03x--"做為結束.
狀態碼的職責是當客戶端想伺服器端發送請求時, 描述返回的請求結果. 藉助狀態碼, 用戶可以知道伺服器端是正常的處理了請求還是出現了錯誤.
200:OK, 請求成功
204:No Content, 服務端接收的請求已經成功處理,但是返回的響應報文中不包含實體的主體部分,
另外也不允許返回任何實體的主體.
206:Partial Content, 客戶端進行了范圍請求,而伺服器成功執行了這部分的GET請求.
3xx的響應表明客戶端需要執行某些特殊的處理才能正確請求.
301:Moved Permanently, 永久性重定向, 表示請求的資源已經被分配到了新的URI, 以後請求都是用現在所指的URI.
302:Found, 臨時性重定向, 表示請求的資源已被分配到新的URI, 希望用戶(本次)能使用新的URI訪問.和301狀態類似，但是302狀態碼代表的資源不是被永久移動，只是臨時性質的。
303:See Other，該狀態碼表示由於請求對應的資源存在著另一個URI，應使用GET方法定向獲取請求的資源。303狀態碼和302狀態碼有著相同的功能，但是303狀態碼表明客戶端應採用GET方法獲取資源，這點與302狀態碼有區別。
304:Not Modified，改狀態表示客戶端發送附帶條件的請求時，服務端允許請求訪問資源，但未滿足條件的情況。304狀態碼返回時不包含響應的主體部分。304雖然被劃分在3XX，但是與重定向無關。
307:Temporary Redirect，臨時重定向，與302有相同的含義，但是307不會將POST改為GET。
4xx的響應結果表明客戶端是發送錯誤的原因所在.
400:Bad Request, 請求報文中存在語法錯誤.
401:Unauthorized, 請求需要有通過HTTP認證(BASIC認證,DIGEST認證)的信息.
403:Forbidden, 表明對請求資源的訪問被伺服器拒絕了.
404:Not Found, 表明伺服器上無法找到請求的資源.
5xx的響應結果表明伺服器本身發送錯誤.
501:Internal Server Error, 表明伺服器端在執行請求時發生了錯誤.
503:Service Unavailable, 表明伺服器暫時處在超負荷或者正在進行停機維護,現在無法請求.如果事先得知解除以上狀況需要的時間, 最好寫入Retry-After首部欄位返回給客戶端.
HTTP協議的請求和響應報文中必定包含HTTP首部, 我們來看一下HTTP首部的結構以及各欄位的用法.
請求報文首部:請求行+請求首部欄位+通用首部欄位+實體首部欄位+其他.
請求行包括方法(GET POST), URI, HTTP版本.
響應報文首部:狀態行+響應首部欄位+通用首部欄位+實體首部欄位+其他.
狀態行包括HTTP版本, 狀態碼.
HTTP首部欄位是構成HTTP報文的要素之一, 在客戶端和服務端之間以HTTP協議通信的過程中, 首部欄位起到傳遞額外重要信息的作用. 首部欄位可以提供報文主體大小, 所使用的語言, 認證信息等內容.
HTTP首部欄位的結構為 首部欄位名: 欄位值 , 指令的參數是可選的, 多個指令之間用","分隔, 例如首部欄位'Cache-Control'的指令用於請求以及響應時:
HTTP首部欄位分為: 通用首部欄位, 請求首部欄位, 響應首部欄位, 實體首部欄位.
通用首部欄位是請求報文和響應報文都會用到的首部.
從客戶端發送請求到服務端使用的首部.補充了請求的附加內容,客戶端信息,響應內容優先順序等信息.
從服務端向客戶端返回響應報文時使用的首部.補充了相應的附加內容.
針對請求報文和響應報文的實體部分使用的首部.
HTTP協議中可能存在信息竊聽或身份偽裝等安全問題, 使用HTTPS通信機制可以有效地防止這些問題.
HTTP協議存在一下不足之處:
HTTP本身不具備加密的功能, 無法對通信整體進行加密, HTTP報文使用明文的方式進行傳輸.
互聯網中都是相通的, 在通信線路上的某些網路設備, 光纜, 計算機都可能遭到惡意窺視, 竊取通信數據, 為了防止信息被惡意竊聽, 可以使用加密技術.
通信的加密 : 將通信進行加密, HTTP通過和SSL或TLS的組合使用, 加密HTTP的通信, 使用SSL建立安全通信線路之後, 就可以在安全的通信線路上進行通信, 與SSL組合使用的HTTP稱為HTTPS.
在HTTP通信時, HTTP協議中的請求和響應不會對通信方進行確認, 任何人都可以發起請求, 伺服器接收到請求以後就會返回響應, 這里就存在安全問題, 客戶端可能是冒充的客戶端, 伺服器可能是冒充的伺服器.
使用SSL可以解決這個問題, SSL不僅提供加密處理, 還使用了一種被稱為證書的手段. 證書是值得信任的第三方機構頒發, 用來證實伺服器和客戶端的身份, 證書偽造在技術上是異常困難的一件事, 所以只要能夠確認通信方持有的證書, 就可以判斷通信方的身份.
HTTP協議無法證明通信的報文完整性, 不能保證發送請求以後, 接收到的響應就是對應客戶端的響應, 中間可能被攔截篡改.
添加了加密和認證機制的HTTP稱為HTTPS.
HTTPS並非一種新協議, 只是在HTTP通信介面部分用SSL和TLS協議替換, 通常HTTP直接和TCP通信, 當使用SSL時, HTTP先和SSL通信, SSL再和TCP通信, HTTP就擁有了HTTPS的加密, 證書和完整性保護功能.
SSL採用一種叫做公開秘鑰加密的加密方式, 加密演算法是公開的, 秘鑰是保密的. 加密和解密都用到秘鑰, 如果秘鑰被其他人竊取, 那麼加密就無意義了.
加密和解密使用同一個秘鑰的方式成為 共享密鑰加密 , 也成為對稱密鑰加密. 以共享密鑰方式加密時必須將密鑰發送給對方, 問題來了, 怎麼講共享密鑰安全發送給對方呢? 如果共享密鑰在發送的過程中被攔截, 那麼加密還有什麼意義..
為了解決這個問題, 我們來引入 公開密鑰 的概念, 公開密鑰加密使用一對非對稱的密鑰, 一把是私有密鑰一把是公開秘鑰, 私有密鑰只有自己知道, 公開密鑰可以任意公開.
客戶端和服務端各有一對密鑰, 客戶端發送請求的時候使用服務端的公開密鑰對內容進行加密, 服務端接收到客戶端的請求, 使用自己的私有密鑰對內容進行解密, 然後使用客戶端的公開密鑰對響應進行加密, 客戶端接收到響應以後使用自己的密鑰對響應進行解密.
HTTPS採用共享密鑰加密和公開密鑰兩者並用的 混合加密機制 , 公開密鑰加密相比共享密鑰加密, 公開密鑰加密的處理速度相對較慢, 所以我們來考慮共享密鑰的加密處理, 共享密鑰的加密處理的問題在於我們如何將密鑰安全的傳達給對方.
我們可以考慮使用公開密鑰的加密方式將共享密鑰作為內容傳遞給對方, 對方使用自己的密鑰將內容解密以獲取到共享密鑰, 這樣共享密鑰就被安全傳達, 以後的通信就使用共享密鑰加密的方式進行通信.
至此, 還有一個問題需要考慮, 我們在使用公開密鑰進行加密時, 如何 保證公開密鑰的正確性 ?
比如我們在和某台伺服器在公開密鑰加密的方式下通信時, 如何確保我們收到的公開密鑰就是我們要通信的那台伺服器的公開密鑰呢? 很可能在公開密鑰傳輸的過程中, 公開密鑰已經被篡改了.
為了解決這個問題, 我們要讓公開密鑰和我們所說的這台伺服器最對應, 可以使用由數字證書認證機構(CA, Certificate Authority)和其相關機關頒發的公開密鑰證書.
數字證書認證機構是在客戶端和伺服器都信賴的第三方認證機構的立場上. 伺服器的運營認證人員向數字證書認證機構提出公開密鑰的申請, 數字證書認證機構在確定申請者的身份後對公開密鑰進行簽名, 生成數字證書, 或者叫做證書. 然後分配這個已簽名的公開密鑰.
在通信的時候, 伺服器會將這個證書發送給客戶端, 客戶端接收到這個證書, 使用伺服器的公開密鑰對證書進行驗證, 如果驗證通過, 客戶端可以確認伺服器的公開密鑰是值得信賴的, 此處伺服器的公開密鑰必須安全的轉交給客戶端, 如何安全的將公開密鑰轉交是一件很困難的事情, 因此, 很多瀏覽器開發商發布版本時, 會事先在內部植入常見認證機構的公開密鑰, 那麼上邊我們所說的保證公開密鑰正確性的問題就解決了.
客戶端已經完成了對服務端身份的驗證, 那麼服務端是否可以對客戶端的身份做驗證呢?
HTTPS中可以使用客戶端證書, 使用客戶端證書可以對客戶端進行認證, 其作用和伺服器證書類似.
但是這里存在一個問題, 就是客戶端證書的獲取以及證書的發布. 由於客戶端證書是收費的, 也就是有多少用戶就要購買多少客戶端證書, 這個在大天朝來說是不太現實的. 而且購買完證書以後, 客戶端需要手動安裝, 這個對不同的用戶來說也是不太容易實現的.
但是對於一些安全性要求很高的業務來說, 客戶端認證還是有必要的, 比如銀行的網上銀行就採用了客戶端證書.
2. HTTP CHUNK分塊傳輸
HTTP協議之chunk編碼(分塊傳輸編碼)
分塊傳輸編碼（Chunked transfer encoding）是超文本傳輸協議（HTTP）中的一種數據傳輸機制，允許HTTP由應用伺服器發送給客戶端應用（ 通常是網頁瀏覽器）的數據可以分成多個部分。分塊傳輸編碼只在HTTP協議1.1版本（HTTP/1.1）中提供。
通常，HTTP應答消息中發送的數據是整個發送的，Content-Length消息頭欄位表示數據的長度。數據的長度很重要，因為客戶端需要知道哪裡是應答消息的結束，以及後續應答消息的開始。然而，使用分塊傳輸編碼，數據分解成一系列數據塊，並以一個或多個塊發送，這樣伺服器可以發送數據而不需要預先知道發送內容的總大小。通常數據塊的大小是一致的，但也不總是這種情況。
3. HTTP協議（HyperText Transfer Protocol）
通過HTTP或者HTTPS協議請求的資源由統一資源標識符來標識，以發布和接收HTML頁面的方法為目的在互聯網上廣泛應用的網路協議。
HTTP/1.1協議中共定義了八種方法（也叫「動作」）來以不同方式操作指定的資源：
這個方法可使伺服器傳回該資源所支持的所有HTTP請求方法。用'*'來代替資源名稱，向Web伺服器發送OPTIONS請求，可以測試伺服器功能是否正常運作。
與GET方法一樣，都是向伺服器發出指定資源的請求。只不過伺服器將不傳回資源的本文部分。它的好處在於，使用這個方法可以在不必傳輸全部內容的情況下，就可以獲取其中「關於該資源的信息」（元信息或稱元數據）。
向指定的資源發出「顯示」請求。使用GET方法應該只用在讀取數據，而不應當被用於產生「副作用」的操作中，例如在Web Application中。其中一個原因是GET可能會被網路蜘蛛等隨意訪問。參見安全方法
向指定資源提交數據，請求伺服器進行處理（例如提交表單或者上傳文件）。數據被包含在請求本文中。這個請求可能會創建新的資源或修改現有資源，或二者皆有。
向指定資源位置上傳其最新內容。
請求伺服器刪除Request-URI所標識的資源。
回顯伺服器收到的請求，主要用於測試或診斷。
HTTP/1.1協議中預留給能夠將連接改為渠道方式的代理伺服器。通常用於SSL加密伺服器的鏈接（經由非加密的HTTP代理伺服器）。
假如在不考慮諸如錯誤或者過期等問題的情況下，若干次請求的副作用與單次請求相同或者根本沒有副作用，那麼這些請求方法就能夠被視作「冪等」的
PUT是冪等方法，POST不是。所以PUT用於更新、POST用於新增比較合適。
HTTP協議詳解
HTTP狀態碼
持續連接-分塊傳輸編碼
put or post?
4. http協議分塊編碼（Transfer-Encoding: chunked）
Transfer-Encoding，是一個 HTTP 頭部欄位（響應頭域），字面意思是「傳輸編碼」。最新的 HTTP 規范里，只定義了一種編碼傳輸：分塊編碼(chunked)。
分塊傳輸編碼（Chunked transfer encoding）是超文本傳輸協議（HTTP）中的一種數據傳輸機制，允許HTTP由網頁伺服器發送給客戶端的數據可以分成多個部分。分塊傳輸編碼只在HTTP協議1.1版本（HTTP/1.1）中提供。
數據分解成一系列數據塊，並以一個或多個塊發送，這樣伺服器可以發送數據而不需要預先知道發送內容的總大小。
具體方法
在頭部加入 Transfer-Encoding: chunked 之後，就代表這個報文採用了分塊編碼。這時，報文中的實體需要改為用一系列分塊來傳輸。
每個分塊包含十六進制的長度值和數據，長度值獨佔一行，長度不包括它結尾的 CRLF(\r\n)，也不包括分塊數據結尾的 CRLF。
最後一個分塊長度值必須為 0，對應的分塊數據沒有內容，表示實體結束。
例：
Content-Encoding 和 Transfer-Encoding 二者經常會結合來用，其實就是針對 Transfer-Encoding 的分塊再進行 Content-Encoding壓縮。
注意 ：如果最末尾 不是以0\r\n\r\n結束 的話，會導致 解析失敗 (此處是一個坑！！)。
附：java解析十六進制的chunked類型報文
原文地址： https://www.cnblogs.com/xuehaoyue/p/6639029.html
5. HTTP——報文和實體
本文為《圖解HTTP》第三章摘錄+總結。
HTTP報文本身是由多行數據構成的 字元串文本 ，由報文首部和報文主體構成，並不一定要有報文主體。首部是請求或響應的內容及屬性，主體是應被發送的數據。
首先弄清兩個概念， 報文 和 實體 。可將報文看作傳輸中的「箱子」，而實體是「箱子」里的「貨物」，即我們真正想要傳送給對方的東西本身，也就是數據。實體由實體首部和實體主體構成，實體首部主要是一些有關實體主體的描述性信息。
在實際中，通過編碼來提升傳輸的速率。有兩種編碼方式：壓縮傳輸的內容和分塊傳輸。
HTTP協議中有一種被稱為內容編碼的功能可以對實體信息進行壓縮，壓縮後的實體由客戶端接收並進行解碼。
在傳輸大量內容時，通過把數據分割成多塊，讓瀏覽器逐步顯示。這種編碼方式被稱為分塊傳輸編碼。
HTTP協議中採用 多部分對象集合 （Multipart）的方法，來容納多份不同的類型的數據。發送的一份報文可含有 多類型實體 。通常是在圖片或文本文件等上傳時使用。Multipart集合包含的對象有：
首部欄位Range用來指定資源內的byte范圍。而使用了Range發送的請求被稱為 范圍請求 ，即只請求某個資源的一部分。用於應對網路中斷的情況，可以從中斷處繼續載入，而不是從頭開始。
針對范圍請求，響應會返回狀態碼為206 Partial Content的響應報文。另外，對於多重范圍請求，響應會在首部欄位Content-Type標明multipart/byteranges後返回響應報文。
如伺服器無法響應范圍請求，則返回狀態碼200 OK和完整的實體內容。
同一個web網站可能存在多份相同內容的頁面，例如英文版和中文版。當瀏覽器的默認語言為英語或中文時，web頁面對應顯示相應語言。這樣的機制稱為內容協商。內容協商機制是指客戶端和伺服器端就響應的資源內容進行交涉，然後提供給客戶端最為合適的資源。
包含在請求報文中的某些首部欄位就是判斷的基準：Accept、Accept-Charset、Accept-Encoding、Accept-Language、Content-Language。
內容協商技術有3種類型：
6. 什麼是HTTP協議響應流
一般情況下，伺服器接收並處理客戶端發過來的請求後會返回一個HTTP的響應消息。
HTTP響應也由四個部分組成，分別是：狀態行、消息報頭、空行和響應正文。
第一部分：狀態行，由HTTP協議版本號， 狀態碼， 狀態消息 三部分組成。
第一行為狀態行，（HTTP/1.1）表明HTTP版本為1.1版本，狀態碼為200，狀態消息為（ok）
第二部分：消息報頭，用來說明客戶端要使用的一些附加信息
第二行和第三行和第四行為消息報頭，
Date:生成響應的日期和時間；Content-Type:指定了MIME類型的HTML(text/html),編碼類型是ISO-8859-1
第三部分：空行，消息報頭後面的空行是必須的
第四部分：響應正文，伺服器返回給客戶端的文本信息。
空行後面的html部分為響應正文。
7. http能傳輸500g的文件嗎
可以。早期互聯⽹上傳輸的基本上都是只有⼏ K ⼤⼩的⽂本和⼩圖⽚，現在的情況則⼤有不同。⽹頁⾥包含的信息實在是太多了，隨隨便便⼀個主頁 HTML 就有可能上百 K，⾼質量的圖⽚都以 M 論，更不要說那些電影、電視劇了，⼏ G、⼏⼗ G 都有可能。
數據壓縮
瀏覽器在發送請求時都會帶著 Accept-Encoding 頭欄位，⾥⾯是瀏覽器⽀持的壓縮格式列表，例如 gzip、deflate、br 等，這樣伺服器就可以從中選擇⼀種壓縮演算法，放進 Content-Encoding 響應頭⾥，再把原數據壓縮後發給瀏覽器。如果壓縮率有 50%，那麼 100k 的數據壓完之後只剩 50k，相當於在帶寬不變的情況下⽹速快了⼀倍。
分塊傳輸
除了壓縮⽂件之外，另⼀種辦法就是分塊傳輸。它們的原理差不多，都是把⼤⽂件變⼩傳輸。分塊傳輸會把⼀個⼤⽂件切成很多⼩塊，把這些⼩塊依次發給瀏覽器，瀏覽器收到之後再組裝復原。這樣瀏覽器和伺服器都不⽤在內存中保存全部⽂件，每次只收發⼀⼩部分，⽹絡也不會被⼤⽂件長時間占⽤，內存、帶寬等資源也就節省下來了。