Streaming vs. progressive download: Understanding the聽difference
January 12, 2009 by Kent
Streaming vs. progressive download: Understanding the difference
One of the most frequently asked questions about delivering video online is 鈥?鈥淲hat鈥檚 the difference between streaming video and progressive download?鈥?As a user clicking a video link on a website, you will not often know which delivery method is being used, unless you do some poking around. Although the end result may look the same to the end user, streaming and progressive download are very different delivery methods, each with their own strengths and weaknesses. Here we will take a look at the two delivery methods and help you to decide which will work best for you.
Delivering a file via HTTP:
Delivery of聽a file over HTTP is normally referred to as 鈥榩rogressive download鈥? or 鈥榟ttp streaming鈥? In reality, it is not streaming at all but a very simple bulk download of a video file to the end user鈥檚 computer.A temporary copy of the video file is then stored on the local computer so that the viewer can watch the file over and over without having to download the file each time.
Let鈥檚 assume you have a video file encoded at 500kbps. The server delivering the file does not know or care that your video file is encoded at 500kbps; it simply pushes data to the host machine as quickly as it can. This can sometimes give the illusion that the file is being streamed because playback can start as soon as enough of the file is available on the local machine. This obviously restricts the users from skipping to parts of the file that have not yet been downloaded.
If the bandwidth available to the machine downloading the file is smaller than the encoded bit-rate there may be a wait before the file will start to play. For example, on a 56kbps dial-up modem, trying to play a file that is encoded at 500kbps you may have to wait a fairly long time before enough of the file has been downloaded for it to start playing. On a 500kbps internet connect, or faster, playback should start almost immediately and the file should download faster than it will play, meaning that playback will not have to stop because not enough data has been downloaded.
HTTP(Hypertext transport protocol) operates over TCP(Transport control protocol) which controls the actual transport of the packets over the network. TCP is optimized for guarantee of delivery, regardless of file format or size. If a packet is skipped during the transfer of a file, it will request a resend of that packet. Resend requests take time and bandwidth and could increase the load on the server. TCP is not designed for efficient real time delivery or careful bandwidth control, but for accurate and reliable delivery of every bit.
Delivering from a streaming server:
Effectively, a streaming server is a piece of software which deals with video requests. Unlike a standard web server delivering a video file over HTTP (progressive download), a streaming server opens a conversation with the local machine. There are two sides to this conversation, one is for transferring the video and the other is for control messages between the media player and the server. These control messages include commands such as 鈥榩lay鈥? 鈥榩ause鈥? 鈥榮top鈥?and 鈥榮eek鈥?
If you have a 56kbps connection, you will not be able to receive a stream encoded at 500kbps; you will have to settle for a lower quality video encoded for 56kbps connections. Streaming does however have many advantages.
1. You can begin video playback at any point of the video, or skip through the video as you see fit. This is very convenient for users.
2. It makes a lot more efficient use of bandwidth as you are only using bandwidth for part of the video that are actually watched as opposed to HTTP delivery where the whole file gets delivered.
3. The video file is not stored on the viewer鈥檚 computer 鈥?the video data is played and then discarded by the media player. This lets you maintain more control over your content.
Streaming servers use a specific set of protocols to deliver streams, such as RTSP(Real time streaming protocol), RTMP(Real time messaging protocol)and MMS(Microsoft media services). These protocols are all more suited to delivering video streams because they are more focussed with continuous delivery than they are with 100% accuracy. Unlike TCP, they do not send resend requests for missing packets but instead continue with the rest of the video file. The idea is that it is better to have a momentary glitch in audio or video than for the playback to stop altogether and wait for the missing data.
Conclusion:
In conclusion, both streaming and progressive download have their own benefits and limitations. If you are trying to reach viewers with slower connections and need the quality to be high, progressive download would be your best option. On the other hand, if you know that your viewers will all have a fast enough connection to view your stream, you might save on bandwidth by streaming the video. Without knowing who your video will be served to, progressive download will always be a safer option because no matter what connection they have, they will be able to view your video. For live streaming, a streaming server has to be used. This cannot be done over HTTP.
Original posted at http://blog.mydeo.com/2009/01/12/streaming-vs-progressive-download-understanding-the-difference/
]]>
MSS: Maxitum Segment Size 鏈澶у垎孌靛ぇ灝?br />
PPPoE: PPP Over Ethernet錛堝湪浠ュお緗戜笂鎵胯澆PPP鍗忚錛?br />
[鍒嗘瀽榪囩▼]
鍏堣璇磋繖MTU鏈澶т紶杈撳崟鍏冿紝榪欎釜鏈澶т紶杈撳崟鍏冨疄闄呬笂鍜岄摼璺眰鍗忚鏈夌潃瀵嗗垏鐨勫叧緋伙紝璁╂垜浠厛浠旂粏鍥炲繂涓涓婨thernetII甯х殑緇撴瀯DMAC+SMAC+Type+Data+CRC鐢變簬浠ュお緗戜紶杈撶數姘旀柟闈㈢殑闄愬埗錛屾瘡涓互澶綉甯ч兘鏈夋渶灝忕殑澶у皬64bytes鏈澶т笉鑳借秴榪?518bytes錛屽浜庡皬浜庢垨鑰呭ぇ浜庤繖涓檺鍒剁殑浠ュお緗戝撫鎴戜滑閮藉彲浠ヨ涔嬩負閿欒鐨勬暟鎹撫錛屼竴鑸殑浠ュお緗戣漿鍙戣澶囦細涓㈠純榪欎簺鏁版嵁甯с傦紙娉細灝忎簬64Bytes鐨勬暟鎹撫涓鑸槸鐢變簬浠ュお緗戝啿紿佷駭鐢熺殑“紕庣墖”鎴栬呯嚎璺共鎵版垨鑰呭潖鐨勪互澶綉鎺ュ彛浜х敓鐨勶紝瀵逛簬澶т簬1518Bytes鐨勬暟鎹撫鎴戜滑涓鑸妸瀹冨彨鍋欸iant甯э紝榪欑涓鑸槸鐢變簬綰胯礬騫叉壈鎴栬呭潖鐨勪互澶綉鍙ｄ駭鐢燂級銆?br />
鐢變簬浠ュお緗慐thernetII鏈澶х殑鏁版嵁甯ф槸1518Bytes榪欐牱錛屽埁鍘諱互澶綉甯х殑甯уご錛圖MAC鐩殑MAC鍦板潃48bit=6Bytes+SMAC婧怣AC鍦板潃48bit=6Bytes+Type鍩?bytes錛?4Bytes鍜屽撫灝綜RC鏍￠獙閮ㄥ垎4Bytes錛堣繖涓儴闂ㄦ湁鏃跺欏ぇ瀹朵篃鎶婂畠鍙仛FCS錛夛紝閭ｄ箞鍓╀笅鎵胯澆涓婂眰鍗忚鐨勫湴鏂逛篃灝辨槸Data鍩熸渶澶у氨鍙兘鏈?500Bytes榪欎釜鍊兼垜浠氨鎶婂畠縐頒箣涓篗TU銆傝繖涓氨鏄綉緇滃眰鍗忚闈炲父鍏沖績鐨勫湴鏂癸紝鍥犱負緗戠粶灞傚崗璁瘮濡侷P鍗忚浼氭牴鎹繖涓兼潵鍐沖畾鏄惁鎶婁笂灞備紶涓嬫潵鐨勬暟鎹繘琛屽垎鐗囥傚氨濂芥瘮涓涓洅瀛愭病娉曡涓嬩竴澶у潡闈㈠寘錛屾垜浠渶瑕佹妸闈㈠寘鍒囨垚鐗囷紝瑁呭湪澶氫釜鐩掑瓙閲岄潰涓鏍風殑閬撶悊銆傚綋涓ゅ彴榪滅▼PC浜掕仈鐨勬椂鍊欙紝瀹冧滑鐨勬暟鎹渶瑕佺┛榪囧緢澶氱殑璺敱鍣ㄥ拰鍚勭鍚勬牱鐨勭綉緇滃獟浠嬫墠鑳藉埌杈懼绔紝緗戠粶涓笉鍚屽獟浠嬬殑MTU鍚勪笉鐩稿悓錛屽氨濂芥瘮涓闀挎鐨勬按綆★紝鐢變笉鍚岀矖緇嗙殑姘寸緇勬垚錛圡TU涓嶅悓 錛夐氳繃榪欐姘寸鏈澶ф按閲忓氨瑕佺敱涓棿鏈緇嗙殑姘寸鍐沖畾銆?br />
瀵逛簬緗戠粶灞傜殑涓婂眰鍗忚鑰岃█錛堟垜浠互TCP/IP鍗忚鏃忎負渚嬶級瀹冧滑瀵規按綆＄矖緇嗕笉鍦ㄦ剰瀹冧滑璁や負榪欎釜鏄綉緇滃眰鐨勪簨鎯呫傜綉緇滃眰IP鍗忚浼氭鏌ユ瘡涓粠涓婂眰鍗忚涓嬫潵鐨勬暟鎹寘鐨勫ぇ灝忥紝騫舵牴鎹湰鏈篗TU鐨勫ぇ灝忓喅瀹氭槸鍚︿綔“鍒嗙墖”澶勭悊銆傚垎鐗囨渶澶х殑鍧忓灝辨槸闄嶄綆浜嗕紶杈撴ц兘錛屾湰鏉ヤ竴嬈″彲浠ユ悶瀹氱殑浜嬫儏錛屽垎鎴愬嬈℃悶瀹氾紝鎵浠ュ湪緗戠粶灞傛洿楂樹竴灞傦紙灝辨槸浼犺緭灞傦級鐨勫疄鐜頒腑寰寰浼氬姝ゅ姞浠ユ敞鎰忥紒鏈変簺楂樺眰鍥犱負鏌愪簺鍘熷洜灝變細瑕佹眰鎴戣繖涓潰鍖呬笉鑳藉垏鐗囷紝鎴戣瀹屾暣鍦伴潰鍖咃紝鎵浠ヤ細鍦↖P鏁版嵁鍖呭寘澶撮噷闈㈠姞涓婁竴涓爣絳撅細DF錛圖onot Fragment錛夈傝繖鏍峰綋榪欎釜IP鏁版嵁鍖呭湪涓澶ф緗戠粶錛堟按綆￠噷闈級浼犺緭鐨勬椂鍊欙紝濡傛灉閬囧埌MTU灝忎簬IP鏁版嵁鍖呯殑鎯呭喌錛岃漿鍙戣澶囧氨浼氭牴鎹姹備涪寮冭繖涓暟鎹寘銆傜劧鍚庤繑鍥炰竴涓敊璇俊鎭粰鍙戦佽呫傝繖鏍峰線寰浼氶犳垚鏌愪簺閫氳涓婄殑闂錛屼笉榪囧垢榪愮殑鏄ぇ閮ㄥ垎緗戠粶閾捐礬閮芥槸MTU1500鎴栬呭ぇ浜?500銆?br />
瀵逛簬UDP鍗忚鑰岃█錛岃繖涓崗璁湰韜槸鏃犺繛鎺ョ殑鍗忚錛屽鏁版嵁鍖呯殑鍒拌揪欏哄簭浠ュ強鏄惁姝ｇ‘鍒拌揪涓嶇敋鍏沖績錛屾墍浠ヤ竴鑸琔DP搴旂敤瀵瑰垎鐗囨病鏈夌壒孌婅姹傘?br />
瀵逛簬TCP鍗忚鑰岃█灝變笉涓鏍蜂簡錛岃繖涓崗璁槸闈㈠悜榪炴帴鐨勫崗璁紝瀵逛簬TCP鍗忚鑰岃█瀹冮潪甯稿湪鎰忔暟鎹寘鐨勫埌杈鵑『搴忎互鍙婃槸鍚︿紶杈撲腑鏈夐敊璇彂鐢熴傛墍浠ユ湁浜汿CP搴旂敤瀵瑰垎鐗囨湁瑕佹眰---涓嶈兘鍒嗙墖錛圖F錛夈?br />
鑺卞紑涓ゆ湹錛屽悇琛ㄤ竴鏋濓紝璇村畬MTU鐨勬晠浜嬫垜浠璁茶浠婂ぉ鐨勭浜屼釜鐚剼---PPPoE鎵璋揚PPoE灝辨槸鍦ㄤ互澶綉涓婇潰璺慞PP鍗忚錛屾湁浜哄鎬簡錛孭PP鍗忚鍜孍thernet涓嶉兘鏄摼璺眰鍗忚鍚楋紵鎬庝箞涓涓摼璺眰璺戝埌鍙﹀涓涓摼璺眰涓婇潰鍘諱簡錛岄毦閬撳崌綰ф垚緗戠粶灞傚崗璁簡涓嶆垚銆傚叾瀹炶繖鏄釜璇尯錛氬氨鏄煇灞傚崗璁彧鑳芥壙杞芥洿涓婁竴灞傚崗璁備負浠涔堜細浜х敓榪欑濂囨殑闇姹傚憿錛熻繖鏄洜涓洪殢鐫瀹藉甫鎺ュ叆錛堣繖縐嶅甯︽帴鍏ヤ竴鑸負Cable Modem鎴栬厁DSL鎴栬呬互澶綉鐨勬帴鍏ワ級鐢變簬浠ュお緗戠己涔忚璇佽璐規満鍒惰屼紶緇熻繍钀ュ晢鏄氳繃PPP鍗忚鏉ュ鎷ㄥ彿絳夋帴鍏ユ湇鍔¤繘琛岃璇佽璐圭殑錛屾墍浠ュ氨鍑轟簡榪欎箞涓涓儙錛歅PPoE銆?br />
PPPoE甯︽潵浜嗗ソ澶勶紝涔熷甫鏉ヤ簡涓浜涘潖澶勶紝姣斿錛氫簩嬈″皝瑁呰楄垂璧勬簮錛岄檷浣庝簡浼犺緭鏁堣兘絳夌瓑錛岃繖浜涘潖澶勪亢涔熶笉澶氳浜嗭紝鏈澶х殑鍧忓灝辨槸PPPoE瀵艱嚧MTU鍙樺皬浜嗕互澶綉鐨凪TU鏄?500錛屽啀鍑忓幓PPP鐨勫寘澶村寘灝劇殑寮閿錛?Bytes錛夛紝灝卞彉鎴?492銆傚鏋滀袱鍙頒富鏈轟箣闂寸殑鏌愭緗戠粶浣跨敤浜哖PPoE閭ｄ箞灝變細瀵艱嚧鏌愪簺涓嶈兘鍒嗙墖鐨勫簲鐢ㄦ棤娉曢氳銆傝繖涓椂鍊欏氨闇瑕佹垜浠皟鏁翠竴涓嬩富鏈虹殑MTU錛岄氳繃闄嶄綆涓繪満鐨凪TU錛岃繖鏍鋒垜浠氨鑳藉欏哄埄鍦拌繘琛岄氳浜嗐?br />
褰撶劧瀵逛簬TCP搴旂敤鑰岃█榪樻湁鍙﹀鐨勮В鍐蟲柟妗堛傞┈涓婅鍑轟粖澶╃涓変綅鐚剼錛歁SS銆侻SS鏈澶т紶杈撳ぇ灝忕殑緙╁啓錛屾槸TCP鍗忚閲岄潰鐨勪竴涓蹇點侻SS灝辨槸TCP鏁版嵁鍖呮瘡嬈¤兘澶熶紶杈撶殑鏈澶ф暟鎹垎孌點備負浜嗚揪鍒版渶浣崇殑浼犺緭鏁堣兘TCP鍗忚鍦ㄥ緩绔嬭繛鎺ョ殑鏃跺欓氬父瑕佸崗鍟嗗弻鏂圭殑MSS鍊鹼紝榪欎釜鍊糡CP鍗忚鍦ㄥ疄鐜扮殑鏃跺欏線寰鐢∕TU鍊間唬鏇匡紙闇瑕佸噺鍘籌P鏁版嵁鍖呭寘澶寸殑澶у皬20Bytes鍜孴CP鏁版嵁孌電殑鍖呭ご20Bytes錛夋墍浠ュ線寰MSS涓?460銆傞氳鍙屾柟浼氭牴鎹弻鏂規彁渚涚殑MSS鍊煎緱鏈灝忓肩‘瀹氫負榪欐榪炴帴鐨勬渶澶SS鍊箋?br />
浠嬬粛瀹岃繖涓変綅鐚剼,鎴戜滑鍥炶繃澶存潵鐪嬪墠璦閲岄潰鐨勯偅涓棶棰橈紝鎴戜滑璇曟兂涓涓嬶紝濡傛灉鎴戜滑鍦ㄤ腑闂磋礬鐢卞櫒涓婃妸姣忔TCP榪炴帴鐨勬渶澶SS榪涜璋冩暣榪欐牱浣垮緱閫氳繃PPPoE閾捐礬鐨勬渶澶SS鍊煎姞涓婃暟鎹寘澶村寘灝句笉浼氳秴榪嘝PPoE鐨凪TU澶у皬1492榪欐牱灝變笉浼氶犳垚鏃犳硶閫氳鐨勯棶棰?鎵浠ヤ笂闈㈢殑闂鍙互閫氳繃ip tcp adjust-mss 1452鏉ヨВ鍐?褰撶劧闂涔熷彲浠ラ氳繃淇敼PC鏈虹殑MTU鏉ヨВ鍐熾?br />
涓嶆敼MSS浼氬浣曪紵鏈夊彲鑳戒細鍑虹幇閮ㄥ垎緗戠珯鎵撲笉寮錛屼緥濡傞櫠瀹濓紝鍦ㄧ嚎閾惰浠涔堢殑銆傛垨鑰呭紑緗戦〉鎱紝閮藉彲鑳藉拰MSS鏈夊叧緋葷殑銆?br /> 淇敼鍔炴硶錛?927鐗堟湰錛?br /> IP==>>Firwwall==>>Mangle==>>鐐?鍙?=>>
General欏?br /> Chain:forward
Protocol:tcp
Advanced欏?br /> Tcpflags閫塖YN
Action欏?br /> action:Change mss
new tcpmss:1472
鍏充簬MSS鏁板肩殑澶氬皯錛屼互鍙婂彇鍊煎姙娉晘
鍦╓indows鐜涓嬶紝ping 鐩爣緗戠珯 -f -l 1500 鐒跺悗鐪嬭兘鍚ING閫氾紝濡傛灉PING涓嶉氾紝灝變互4涓哄崟浣嶅線涓嬪噺錛岀洰鏍囩綉绔欏彲浠ユ槸
浣犳兂璁塊棶錛屼絾璁塊棶涓嶄簡錛屼篃鍙互鏄叾浠栦竴浜涚綉绔欙紝榪欎釜瑕佹眰涓嶅銆傘?br /> 姣斿鎴慞ING 鐧懼害
ping www.baidu.com -f -l 1500
寰楀埌浠ヤ笅鎻愮ず錛?br />
C:\>ping www.baidu.com -f -l 1500
Pinging www.a.shifen.com [202.108.22.5] with 1500 bytes of data:
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Ping statistics for 202.108.22.5:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
榪欏氨璇存槑錛?500榪欎釜MSS鏁板間笉鍙彇錛岄渶瑕佸線涓嬩簡鎹紝閭ｄ箞灝變互4浣嶅崟浣嶅線涓嬪噺錛屽噺鍒伴氫負姝紝灝辨槸1500-4=錛燂紵錛熻嚜宸卞幓綆椾簡銆傛垜榪欓噷鏄?472鎵嶉氱殑錛屾墍浠ユ垜鏀圭殑灝辨槸1472
C:\>ping www.baidu.com -f -l 1472
Pinging www.a.shifen.com [202.108.22.5] with 1472 bytes of data:
Reply from 202.108.22.5: bytes=1472 time=29ms TTL=53
Reply from 202.108.22.5: bytes=1472 time=29ms TTL=53
Reply from 202.108.22.5: bytes=1472 time=29ms TTL=53
Reply from 202.108.22.5: bytes=1472 time=29ms TTL=53
Ping statistics for 202.108.22.5:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 29ms, Maximum = 29ms, Average = 29ms
榪欏氨鏄氫簡錛屽熀浜庣粰鍦扮綉緇滅姸鍐典笉鍚岋紝鎵浠SS涔熶笉浠呯浉鍚岋紝澶у瑕佽嚜宸辨祴璇曪紝澶氬仛璇曢獙銆?
杞嚜 http://www.clxp.net.cn/article.asp?id=253
]]>
]]>