兩種方式可以獲取，第一種更爲直接，第二種逼格高一點：
從IE臨時緩存內容的本地路徑獲取，具體操作步驟如
- 打開工具欄(Alt+X)>打開Internet選項(Ctrl+O)>在彈出的常規Tab頁點擊設置(Alt+S)>(Ctrl+V)，找到IE臨時緩存內容的本地路徑（比如我本地是這個路徑是：C:\Users\Administrator\AppData\Local\Microsoft\Windows\Temporary Internet Files，每個人的路徑可能不同，請按照上述操作去找路徑）；
- 然後開始在網頁上播放音樂，播放音樂後，IE就會自動將正在播放的音樂的數據文件下載到該路徑下；
- 在該路徑下找到對應播放時間的名稱帶mp3的.dat格式文件，將此文件複製到本地要保存的其他路徑下，然後將文件名及其格式改爲"XXX.mp3"，即可。
通過開發者模式找到音頻文件所在URL，再用迅雷或其他下載工具下載
- 打開音樂播放網頁，點擊F12進入開發者模式，點擊網絡Tab頁，點擊右下角的綠色倒三角以便啓用網絡流量捕獲(F5)；
- 然後開始在網頁上播放音樂，播放音樂後，會監控到IE播放音樂時訪問的具體URL網址，可以看到mp3的url，一般按照【已接收】大小排序，就可以找到音樂所在的網址。右鍵包含mp3的那條記錄，點擊複製URL。
- 將複製的URL粘貼到迅雷進行下載，即可
具體操作過程截圖如下：
總結
IE音樂播放網頁播放音樂這一過程，其具體的技術實現過程的細節猜想如下：
- 用戶通過IE音樂播放網頁向音樂服務器發起播放音樂的請求，詢問是否可以連接；
- 音樂服務器受到詢問是否可以連接的請求後，給用戶做出可以連接的應答反饋；
- 用戶受到可以連接的通知，開始正式連接音樂服務器，這時用戶與音樂服務器直接的網絡傳輸連接建立；
- 用戶利用經由三次握手後建立起來的連接開始從音樂服務器Download音樂數據文件到用戶本地(在這一過程中用戶和音樂服務器之間應該是一直保持連接的)；
- 成功將音樂文件完整的Download到用戶本地，連接此時不再需要保持，斷開連接
- 用戶開始在用戶端對本地音樂數據文件進行解析播放等用戶端數據處理操作（這些處理與音樂服務器已經無關了）
這個過程說明每次用戶發起音樂播放請求，都會與音樂服務器進行一次三次握手及建立連接的過程，以前建立的連接在數據傳輸完畢後立即會斷開，不會被保存下來，後續的請求因此無法複用以前建立的連接，只能再去建立新的連接用完再斷開。這種方式屬於短連接。一次會話一次連接，請求和連接的關係屬於一對一。因爲這種場景下，每個請求間的時間間隔是不固定的，可能間隔很短就進行下一次播放音樂的請求，也可能會很久之後纔去進行下一次播放音樂的操作。如果連接建立後一直保持，實際上卻沒有被利用起來，不覺得很浪費麼。單向的由服務器端向用戶傳輸數據(數據需要保持完整性一次性傳輸到位)的場景適合用短連接。其實這個過程當中還涉及到阻塞的概念：由於用戶一次請求向音樂服務器下載一首歌時，必需要保證下載的是完整的一首歌的全部數據，所以在下載的過程是一個等待的過程即被阻塞的過程，會受到網絡帶寬和計算機處理速度的影響。(後續會補充關於阻塞的單獨章節進行詳細闡述)
既然提到短連接，有必要聊聊長連接。長連接中請求和連接的關係是多對一的。即以前的請求建立的連接可以被後續請求繼續使用，不會斷開。比如跑步APP實時顯示運動軌跡這一場景：用戶通過APP向服務器實時顯示運動軌跡的請求，用戶需要實時上報自己的最新位置信息給服務器，服務器收到後將繪製好的最新運動軌跡返回給用戶，雙向的數據傳輸過程。這個過程應該會一直保持連接在線，不會每上報一次就建立一次連接，太麻煩。假設用戶每上報一次就建立一次連接，建立連接之前還要經過三次握手，過程太複雜。不如用戶第一次與服務器建立建立後，就一直保持連接在線，後續的每次用戶上報及服務器返回都複用這個連接。因爲這個場景下的用戶請求是實時的，每個請求之間的間隔幾乎可以被忽略，沒必要去頻繁的重複斷開舊連接再去建立新的連接的過程。雙向的用戶與服務器實時傳遞數據(數據分段傳輸，最後彙總整合後形成最終數據)的場景適合用長連接。