关键字：播放音乐, 提取mp3, 网页音频, 技术思考, 短连接, 长连接, 开发者模式, IE临时缓存, 网络流量捕获, URL下载, 三次握手, 数据传输, 阻塞, 实时数据
两种方式可以获取，第一种更为直接，第二种通用一些：
一、从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向服务器实时显示运动轨迹的请求，用户需要实时上报自己的最新位置信息给服务器，服务器收到后将绘制好的最新运动轨迹返回给用户，双向的数据传输过程。这个过程应该会一直保持连接在线，不会每上报一次就建立一次连接，太麻烦。假设用户每上报一次就建立一次连接，建立连接之前还要经过三次握手，过程太复杂。不如用户第一次与服务器建立建立后，就一直保持连接在线，后续的每次用户上报及服务器返回都复用这个连接。
因为这个场景下的用户请求是实时的，每个请求之间的间隔几乎可以被忽略，没必要去频繁的重复断开旧连接再去建立新的连接的过程。双向的用户与服务器实时传递数据(数据分段传输，最后汇总整合后形成最终数据)的场景适合用长连接。
