A. 瀏覽器端生成的blob數據怎麼上傳給伺服器端的TP處理
1. 首先嘛，你得在瀏覽器里輸入要網址:
2. 瀏覽器查找域名的IP地址
導航的第一步是通過訪問的域名找出其IP地址。DNS查找過程如下：
瀏覽器緩存 – 瀏覽器會緩存DNS記錄一段時間。 有趣的是，操作系統沒有告訴瀏覽器儲存DNS記錄的時間，這樣不同瀏覽器會儲存個自固定的一個時間（2分鍾到30分鍾不等）。
系統緩存 – 如果在瀏覽器緩存里沒有找到需要的記錄，瀏覽器會做一個系統調用（windows里是gethostbyname）。這樣便可獲得系統緩存中的記錄。
路由器緩存 – 接著，前面的查詢請求發向路由器，它一般會有自己的DNS緩存。
ISP DNS 緩存 – 接下來要check的就是ISP緩存DNS的伺服器。在這一般都能找到相應的緩存記錄。
遞歸搜索 – 你的ISP的DNS伺服器從跟域名伺服器開始進行遞歸搜索，從.com頂級域名伺服器到Facebook的域名伺服器。一般DNS伺服器的緩存中會有.com域名伺服器中的域名，所以到頂級伺服器的匹配過程不是那麼必要了。
DNS遞歸查找如下圖所示：
DNS有一點令人擔憂，這就是像wikipedia.org 或者 facebook.com這樣的整個域名看上去只是對應一個單獨的IP地址。還好，有幾種方法可以消除這個瓶頸：
循環 DNS 是DNS查找時返回多個IP時的解決方案。舉例來說，Facebook.com實際上就對應了四個IP地址。
負載平衡器 是以一個特定IP地址進行偵聽並將網路請求轉發到集群伺服器上的硬體設備。 一些大型的站點一般都會使用這種昂貴的高性能負載平衡器。
地理 DNS 根據用戶所處的地理位置，通過把域名映射到多個不同的IP地址提高可擴展性。這樣不同的伺服器不能夠更新同步狀態，但映射靜態內容的話非常好。
Anycast 是一個IP地址映射多個物理主機的路由技術。 美中不足，Anycast與TCP協議適應的不是很好，所以很少應用在那些方案中。
大多數DNS伺服器使用Anycast來獲得高效低延遲的DNS查找。
3. 瀏覽器給web伺服器發送一個HTTP請求
因為像Facebook主頁這樣的動態頁面，打開後在瀏覽器緩存中很快甚至馬上就會過期，毫無疑問他們不能從中讀取。
所以，瀏覽器將把一下請求發送到Facebook所在的伺服器：
GET HTTP/1.1
Accept: application/x-ms-application, image/jpeg, application/xaml+xml, [...]
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; [...]
Accept-Encoding: gzip, deflate
Connection: Keep-Alive
Host: facebook.com
Cookie: datr=1265876274-[...]; locale=en_US; lsd=WW[...]; c_user=2101[...]
GET 這個請求定義了要讀取的URL： 「」。 瀏覽器自身定義 (User-Agent 頭)， 和它希望接受什麼類型的相應 (Accept and Accept-Encoding 頭). Connection頭要求伺服器為了後邊的請求不要關閉TCP連接。
請求中也包含瀏覽器存儲的該域名的cookies。可能你已經知道，在不同頁面請求當中，cookies是與跟蹤一個網站狀態相匹配的鍵值。這樣cookies會存儲登錄用戶名，伺服器分配的密碼和一些用戶設置等。Cookies會以文本文檔形式存儲在客戶機里，每次請求時發送給伺服器。
用來看原始HTTP請求及其相應的工具很多。作者比較喜歡使用fiddler，當然也有像FireBug這樣其他的工具。這些軟體在網站優化時會幫上很大忙。
除了獲取請求，還有一種是發送請求，它常在提交表單用到。發送請求通過URL傳遞其參數(e.g.: )。發送請求在請求正文頭之後發送其參數。
像「」中的斜杠是至關重要的。這種情況下，瀏覽器能安全的添加斜杠。而像「http: //example.com/folderOrFile」這樣的地址，因為瀏覽器不清楚folderOrFile到底是文件夾還是文件，所以不能自動添加 斜杠。這時，瀏覽器就不加斜杠直接訪問地址，伺服器會響應一個重定向，結果造成一次不必要的握手。
4. facebook服務的永久重定向響應
圖中所示為Facebook伺服器發回給瀏覽器的響應：
HTTP/1.1 301 Moved Permanently
Cache-Control: private, no-store, no-cache, must-revalidate, post-check=0,
pre-check=0
Expires: Sat, 01 Jan 2000 00:00:00 GMT
Location:
P3P: CP="DSP LAW"
Pragma: no-cache
Set-Cookie: made_write_conn=deleted; expires=Thu, 12-Feb-2009 05:09:50 GMT;
path=/; domain=.facebook.com; httponly
Content-Type: text/html; charset=utf-8
X-Cnection: close
Date: Fri, 12 Feb 2011 05:09:51 GMT
Content-Length: 0
伺服器給瀏覽器響應一個301永久重定向響應，這樣瀏覽器就會訪問「」 而非「」。
為什麼伺服器一定要重定向而不是直接發會用戶想看的網頁內容呢？這個問題有好多有意思的答案。
其中一個原因跟搜索引擎排名有 關。你看，如果一個頁面有兩個地址，就像 和，搜索引擎會認為它們是兩個網站，結果造成每一個的搜索鏈接都減少從而降低排名。而搜索引擎知道301永久重定向是 什麼意思，這樣就會把訪問帶www的和不帶www的地址歸到同一個網站排名下。
還有一個是用不同的地址會造成緩存友好性變差。當一個頁面有好幾個名字時，它可能會在緩存里出現好幾次。
5. 瀏覽器跟蹤重定向地址
現在，瀏覽器知道了「」才是要訪問的正確地址，所以它會發送另一個獲取請求：
GET HTTP/1.1
Accept: application/x-ms-application, image/jpeg, application/xaml+xml, [...]
Accept-Language: en-US
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; [...]
Accept-Encoding: gzip, deflate
Connection: Keep-Alive
Cookie: lsd=XW[...]; c_user=21[...]; x-referer=[...]
Host:
頭信息以之前請求中的意義相同。
6. 伺服器「處理」請求
伺服器接收到獲取請求，然後處理並返回一個響應。
這表面上看起來是一個順向的任務，但其實這中間發生了很多有意思的東西- 就像作者博客這樣簡單的網站，何況像facebook那樣訪問量大的網站呢！
Web 伺服器軟體
web伺服器軟體（像IIS和阿帕奇）接收到HTTP請求，然後確定執行什麼請求處理來處理它。請求處理就是一個能夠讀懂請求並且能生成HTML來進行響應的程序（像ASP.NET,PHP,RUBY...）。
舉 個最簡單的例子，需求處理可以以映射網站地址結構的文件層次存儲。像這個地 址會映射/httpdocs/folder1/page1.aspx這個文件。web伺服器軟體可以設置成為地址人工的對應請求處理，這樣 page1.aspx的發布地址就可以是。
請求處理
請求處理閱讀請求及它的參數和cookies。它會讀取也可能更新一些數據，並講數據存儲在伺服器上。然後，需求處理會生成一個HTML響應。
所 有動態網站都面臨一個有意思的難點 -如何存儲數據。小網站一半都會有一個SQL資料庫來存儲數據，存儲大量數據和/或訪問量大的網站不得不找一些辦法把資料庫分配到多台機器上。解決方案 有：sharding （基於主鍵值講數據表分散到多個資料庫中），復制，利用弱語義一致性的簡化資料庫。
委 托工作給批處理是一個廉價保持數據更新的技術。舉例來講，Fackbook得及時更新新聞feed，但數據支持下的「你可能認識的人」功能只需要每晚更新 （作者猜測是這樣的，改功能如何完善不得而知）。批處理作業更新會導致一些不太重要的數據陳舊，但能使數據更新耕作更快更簡潔。
7. 伺服器發回一個HTML響應
圖中為伺服器生成並返回的響應：
HTTP/1.1 200 OK
Cache-Control: private, no-store, no-cache, must-revalidate, post-check=0,
pre-check=0
Expires: Sat, 01 Jan 2000 00:00:00 GMT
P3P: CP="DSP LAW"
Pragma: no-cache
Content-Encoding: gzip
Content-Type: text/html; charset=utf-8
X-Cnection: close
Transfer-Encoding: chunked
Date: Fri, 12 Feb 2011 09:05:55 GMT
2b3Tn@[...]
整個響應大小為35kB，其中大部分在整理後以blob類型傳輸。
內容編碼頭告訴瀏覽器整個響應體用gzip演算法進行壓縮。解壓blob塊後，你可以看到如下期望的HTML：
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"">
<html xmlns="" xml:lang="en"
lang="en" id="facebook" class=" no_js">
...
關於壓縮，頭信息說明了是否緩存這個頁面，如果緩存的話如何去做，有什麼cookies要去設置（前面這個響應里沒有這點）和隱私信息等等。
請注意報頭中把Content-type設置為「text/html」。報頭讓瀏覽器將該響應內容以HTML形式呈現，而不是以文件形式下載它。瀏覽器會根據報頭信息決定如何解釋該響應，不過同時也會考慮像URL擴展內容等其他因素。
8. 瀏覽器開始顯示HTML
在瀏覽器沒有完整接受全部HTML文檔時，它就已經開始顯示這個頁面了：
9. 瀏覽器發送獲取嵌入在HTML中的對象
在瀏覽器顯示HTML時，它會注意到需要獲取其他地址內容的標簽。這時，瀏覽器會發送一個獲取請求來重新獲得這些文件。
下面是幾個我們訪問facebook.com時需要重獲取的幾個URL：
圖片
…
CSS 式樣表
…
JavaScript 文件
…
這些地址都要經歷一個和HTML讀取類似的過程。所以瀏覽器會在DNS中查找這些域名，發送請求，重定向等等...
但 不像動態頁面那樣，靜態文件會允許瀏覽器對其進行緩存。有的文件可能會不需要與伺服器通訊，而從緩存中直接讀取。伺服器的響應中包含了靜態文件保存的期限 信息，所以瀏覽器知道要把它們緩存多長時間。還有，每個響應都可能包含像版本號一樣工作的ETag頭（被請求變數的實體值），如果瀏覽器觀察到文件的版本 ETag信息已經存在，就馬上停止這個文件的傳輸。
試著猜猜看「fbcdn.net」在地址中代表什麼？聰明的答案是"Facebook內容分發網路"。Facebook利用內容分發網路（CDN）分發像圖片，CSS表和JavaScript文件這些靜態文件。所以，這些文件會在全球很多CDN的數據中心中留下備份。
靜態內容往往代表站點的帶寬大小，也能通過CDN輕松的復制。通常網站會使用第三方的CDN。例如，Facebook的靜態文件由最大的CDN提供商Akamai來託管。
舉例來講，當你試著ping static.ak.fbcdn.net的時候，可能會從某個akamai.net伺服器上獲得響應。有意思的是，當你同樣再ping一次的時候，響應的伺服器可能就不一樣，這說明幕後的負載平衡開始起作用了。
10. 瀏覽器發送非同步（AJAX）請求
在Web 2.0偉大精神的指引下，頁面顯示完成後客戶端仍與伺服器端保持著聯系。
以 Facebook聊天功能為例，它會持續與伺服器保持聯系來及時更新你那些亮亮灰灰的好友狀態。為了更新這些頭像亮著的好友狀態，在瀏覽器中執行的 JavaScript代碼會給伺服器發送非同步請求。這個非同步請求發送給特定的地址，它是一個按照程式構造的獲取或發送請求。還是在Facebook這個例 子中，客戶端發送給ajax/chat/buddy_list.php一個發布請求來獲取你好友里哪個 在線的狀態信息。
提起這個模式，就必須要講講"AJAX"-- 「非同步JavaScript 和 XML」，雖然伺服器為什麼用XML格式來進行響應也沒有個一清二白的原因。再舉個例子吧，對於非同步請求，Facebook會返回一些JavaScript的代碼片段。
除了其他，fiddler這個工具能夠讓你看到瀏覽器發送的非同步請求。事實上，你不僅可以被動的做為這些請求的看客，還能主動出擊修改和重新發送它們。AJAX請求這么容易被蒙，可著實讓那些計分的在線游戲開發者們郁悶的了。（當然，可別那樣騙人家~）
Facebook聊天功能提供了關於AJAX一個有意思的問題案例：把數據從伺服器端推送到客戶端。因為HTTP是一個請求-響應協議，所以聊天伺服器不能把新消息發給客戶。取而代之的是客戶端不得不隔幾秒就輪詢下伺服器端看自己有沒有新消息。
這些情況發生時長輪詢是個減輕伺服器負載挺有趣的技術。如果當被輪詢時伺服器沒有新消息，它就不理這個客戶端。而當尚未超時的情況下收到了該客戶的新消息，伺服器就會找到未完成的請求，把新消息做為響應返回給客戶端。
B. java spring mvc 後端怎麼接收blob二進制數據處理
不明白數據來源是什麼。在java語言http請求中二進制會以文件的形式上傳，如果使用spring的話下面這個類是處理文件上傳的。你說blob 在java中沒有對應類型。
org.springframework.web.multipart.commons.CommonsMultipartResolver。具體這個類的時候請參考，http://blog.csdn.net/swingpyzf/article/details/20230865
C. js前端接受blob對象數組怎麼去操作
可以合成一個大的Blob，再放到src上進行播放。
vartheBigBlob=newBlob(blobsArr,{
type:"video/mp4"
});
document.getElementById("re-video").src=URL.createObjectURL(blob);另外，請問你知道怎麼只取一段blob嗎，這個blob數組只有從前面開始取才能播放，單個的好像不能播放，我想只取後面幾個連續的一部分
D. asp 前台ajax提交的blob數據在後台怎麼接受
你不應該上傳blob,這是前端的對象.除非你在後端完美的模擬一個blob類來解析你接收的數據.
你應該直接post圖片的位元組流或者base64字元串或者使用使用前後端協調的協議來封裝數據,這也是序列化的意義所在.
E. 關於前端如何導出後台傳來的excel介面
題主所說的導出指的是讓前端去下載後台的Excel還時還要有其他操作呢？
如果單純去下載，可以基於XMLHttpRequest請求，請求一個伺服器或者後端的Excel文件，然後設置responseType為blob二進制流來傳輸。例如：
var excelFilePath = 'resources/Excel/importExcel.xlsx';
var xhr = new XMLHttpRequest();
xhr.open('GET', excelFilePath, true);
xhr.responseType = 'blob';
xhr.onload = function(e) {
var blob = this.response;
}
之後onload裡面的blob就是這個Excel文件的二進制流，接下來只要將blob轉成文件進行下載就可以了，JS中有很多開源的第三方類庫可以做到，例如filesaver。如果是用filesaver的話，調用其中的saveAs方法就可以將該blob轉成對應文件進行下載
例如
var fileName = "test.xlsx"
saveAs(blob, fileName);
把上述方法加到onload 方法中，前端就會下載一個名為test.xlsx的Excel文件，內容就是後端傳過來的Excel
如果還要有其他操作例如展示或者在線的編輯，就需要一些第三方控制項來完成了，比如SpreadJS
上述的方法也是在他們的官方論壇中學到的，參考網址：
網頁鏈接
F. ajax傳遞到後台的blob格式的音頻，php端如何把接收的blob轉換成MP3儲存在伺服器
ajax傳遞到後台的blob格式的音頻，php端如何把接收的blob轉換成MP3儲存在伺服器
$.ajax({
url: 'upload.php',
method: "POST",
data: blob,
success:function(data){
alert('上傳成功');
},
error:function(){
alert('上傳出錯');
}
})
請問 這個upload.php裡面的應該怎麼寫
我來答
分享
舉報 瀏覽 132 次
2個回答
#活動#參與《復聯4》問答討論，贏免費影票！
79099818
2019-03-11
按你的方法提交的數據，試下用php://input
file_put_contents('test.mp3',$dat
G. asp如何獲取前台的blob
前端通過js的window.XMLHttpRequest對象（或者ajax），把blob發給伺服器。
varfd=newFormData();
fd.append("blob",blobData);
varxhr;
if(window.XMLHttpRequest){//codeforIE7+,Firefox,Chrome,Opera,Safari
xhr=newXMLHttpRequest();
}
else{//codeforIE6,IE5
xhr=newActiveXObject("Microsoft.XMLHTTP");
}
xhr.open("POST",url);//url是自己要訪問的伺服器的路徑
xhr.send(fd);
}
後端獲取
HttpPostedFilefile=Request.Files["blob"];
H. 後端如何返回blob對象
使用jdk中的方法進行傳輸。在ResultSet 中有getBlob()方法，在PreparedStatement中有setBlob()方法，所以大多數人都會嘗試setBlob。
js沒有所謂byte，只有一個ArrayBuffer，而且ArrayBuffer又不能通過http傳遞。要麼你是用ajax的response直接獲取blob對象的，要麼你從伺服器返回的是base64編碼的字元串，js自己再decode然後轉化成ArrayBuffer得到blob對象。
SLICE方法：
Blob對象的slice方法使用三個參數，均為可選參數，如果三個參數均省略時，相當於把一個Blob對象中的原始二進制數據原樣復制到一個新建的Blob對象(即slice方法的返回值)中。
Blob對象的slice方法的第一個參數start的參數值為一個整數值，代表起始復制位置在Blob對象所代表的原始二進制數據中的位置，當start參數值為0時代表從該數據的起始位置(即第一個位元組)開始復制數據；如果start參數值為負數值且Blob對象的size屬性值+start參數值大於等於0。
則起始復制位置為Blob對象的size屬性值+start參數值；如果start參數值為負數值且Blob對象的size屬性值+start參數值小於0，則起始復制位置為Blob對象所代表的原始二進制數據的起始位置；如果start參數值為正數值且大於等於Blob對象的size屬性值。
I. 我想問一下神通廣大的各位網友，為什麼我前端使用websocket通信的時候後台可以接收到我客戶端發送的消息
樓主可以檢查下你websocket客戶端的接收方式是否有問題哦。
你能發送成功，說明發送代碼沒問題，要好好對比檢查下接收代碼是否有問題。另外伺服器端發送的數據格式跟客戶端要接收的數據格式是否一致，也要好好檢查下的。
樓主是自己開發的websocket服務哇，我們之前也是自己開發，但是穩定性是一個大問題，後來試用了【GoEasy】的websocket集成服務，還是很滿意的。
J. 前端上傳文件的幾種方法
1.表單上傳
最傳統的圖片上傳方式是form表單上傳，使用form表單的input[type=」file」]控制項，打開系統的文件選擇對話框，從而達到選擇文件並上傳的目的。
form表單上傳
表單上傳需要注意以下幾點：
(1).提供form表單，method必須是post。
(2).form表單的enctype必須是multipart/form-data。
javascript學習交流群：453833554
enctype 屬性規定在發送到伺服器之前應該如何對表單數據進行編碼。默認地，表單數據會編碼為 "application/x-www-form-urlencoded"。就是說，在發送到伺服器之前，所有字元都會進行編碼。HTML表單如何打包數據文件是由enctype這個屬性決定的。enctype有以下幾種取值：
application/x-www-form-urlencoded：在發送前編碼所有字元(默認)(空格被編碼為』+』，特殊字元被編碼為ASCII十六進制字元)。
multipart/form-data：不對字元編碼。在使用包含文件上傳控制項的表單時，必須使用該值。
text/plain：空格轉換為 「+」 加號，但不對特殊字元編碼。
默認enctype=application/x-www-form-urlencoded，所以表單的內容會按URL規則編碼，然後根據表單的提交方法：
method=』get』 編碼後的表單內容附加在請求連接後，
method=』post』 編碼後的表單內容作為post請求的正文內容。