衛(wèi)星寬帶通信系統(tǒng)-文庫(kù)吧資料
2024-08-28 21:18本頁(yè)面
【正文】 用迅速啟動(dòng) (speedy start)和迅速恢復(fù) (speedy recovery)算法取代了突發(fā)啟動(dòng)和高速恢復(fù)算法 ? 使用未確認(rèn)報(bào)文段 (Outstanding Segment)代替 TCPPeach中的虛報(bào)文段。 e n d 。 f o r ( i = 1 t o R W N D 1 )w a i t ( τ ) 。 τ = R T T / R W N D 。期望的速率等于傳輸窗口除以基本往返程時(shí)間，基本往返程時(shí)間則是迄今為止測(cè)得的最小往返程時(shí)間 ?基本思想是：如果網(wǎng)絡(luò)中沒(méi)有擁塞，測(cè)量的速率應(yīng)接近于期望的速率 34 衛(wèi)星網(wǎng)絡(luò)中的 TCP協(xié)議 續(xù) 28 ? TCP Vegas ?使用了 2個(gè)門(mén)限值來(lái)觸發(fā)傳輸速率的增或減，依賴于信道是未充分利用或超載 ?TCPReno在沒(méi)有報(bào)文段丟失時(shí)總是增大其擁塞窗口，因此將周期性地導(dǎo)致包丟失和窗口大小的波動(dòng) ?TCP Vegas能夠減小其窗口以避免擁塞，因此在達(dá)到平衡狀態(tài)后不會(huì)使得窗口大小的產(chǎn)生波動(dòng) ?發(fā)送端測(cè)得的往返程時(shí)間更多時(shí)候是由反向鏈路上的擁塞造成，而不是前向鏈路，因此 TCP Vegas在不對(duì)稱信道情況下的工作性能不理想 35 衛(wèi)星網(wǎng)絡(luò)中的 TCP協(xié)議 續(xù) 29 ? TCP Peach 突 發(fā) 啟 動(dòng)S u d d e n _ S t a r t ( )擁 塞 避 免C o n g e s t i o n _ A v o i d a n c e ( )超 時(shí) ？接 收 到 n 個(gè)重 復(fù) 確 認(rèn)快 速 重 傳F a s t _ R e t r a n s m i t ( )高 速 恢 復(fù)R a p i d _ R e c o v e r y ( )是是不 是36 衛(wèi)星網(wǎng)絡(luò)中的 TCP協(xié)議 續(xù) 30 ? TCP Peach ?虛報(bào)文段是由發(fā)送端產(chǎn)生的低優(yōu)先級(jí)的報(bào)文段，是最近傳輸?shù)臄?shù)據(jù)報(bào)文段的復(fù)制 ?發(fā)送端使用虛報(bào)文段來(lái)探查有效網(wǎng)絡(luò)資源：如果TCP連接路徑上的某個(gè)路由器發(fā)生了擁塞，它會(huì)首先丟棄攜帶虛報(bào)文段的 IP分組?？焖倩謴?fù)和快速重傳 )混合使用，如 Reno+SACK ?在長(zhǎng)延時(shí)、中等報(bào)文段丟失率 (低于窗口尺寸的 50％ )的情況下， TCP SACK的性能良好 ?SACK能夠顯著地降低超時(shí)的出現(xiàn)次數(shù)，與其它的非 SACK版本相比也未表現(xiàn)出過(guò)度的侵略性 30 衛(wèi)星網(wǎng)絡(luò)中的 TCP協(xié)議 續(xù) 24 ? 選擇性確認(rèn) SACK ?在不同的地面 Inter設(shè)置條件下，采用 SACK時(shí)平均吞吐率提高約 15％～ 50％ ?在鏈路的差錯(cuò)率很大的情況下，采用 TCP SACK也不能防止大量超時(shí)的出現(xiàn)， TCP的平均吞吐率會(huì)低于 15％ ?采用 SACK選項(xiàng)時(shí)，需要對(duì) TCP的收發(fā)端協(xié)議棧進(jìn)行大量的修改 31 衛(wèi)星網(wǎng)絡(luò)中的 TCP協(xié)議 續(xù) 25 ? 慢啟動(dòng)后的延遲確認(rèn) DAASS ?在慢啟動(dòng)后才使用延遲確認(rèn)，這樣在 TCP連接主動(dòng)增加擁塞窗口大小時(shí)提供了足夠多的確認(rèn)，而在TCP連接穩(wěn)定后減少確認(rèn)數(shù)目以節(jié)約網(wǎng)絡(luò)資源 ?DAASS的主要問(wèn)題是如何實(shí)現(xiàn)：接收端必須知道發(fā)送端什么時(shí)候開(kāi)始慢啟動(dòng)過(guò)程，從而決定是否使用延遲確認(rèn) 32 衛(wèi)星網(wǎng)絡(luò)中的 TCP協(xié)議 續(xù) 26 ? 顯式擁塞通告 ECN ?在網(wǎng)絡(luò)開(kāi)始擁塞時(shí)，顯式通告機(jī)制將 IP包頭中 1比特ECN域設(shè)置為 1來(lái)通知終端節(jié)點(diǎn) ?相應(yīng)地，終端節(jié)點(diǎn)減小其傳輸速率，因此可以避免網(wǎng)絡(luò)出現(xiàn)嚴(yán)重的擁塞現(xiàn)象并導(dǎo)致大量不必要的報(bào)文段丟失 ?發(fā)送端可以在重傳定時(shí)器超時(shí)或接收到 3個(gè)重復(fù)確認(rèn)之前就可以收到顯式的擁塞信息，因此，如果一個(gè)報(bào)文段丟失而沒(méi)有擁塞指示，則該報(bào)文段的丟失就一定是有鏈路的差錯(cuò)造成的，發(fā)送端無(wú)需降低其傳輸速率 ?ECN方法的實(shí)現(xiàn)要求 IP支持 ECN域，要求 TCP能夠獲得 IP包頭中的信息，因此需要對(duì) TCP/IP協(xié)議棧中的部分協(xié)議進(jìn)行相應(yīng)的修改 33 衛(wèi)星網(wǎng)絡(luò)中的 TCP協(xié)議 續(xù) 27 ? TCP Vegas ?TCP Vegas不以包丟失作為擁塞指示，而是使用傳輸速率來(lái)實(shí)現(xiàn)擁塞控制 ?在每一個(gè)往返程時(shí)間，發(fā)送端基于傳輸窗口和測(cè)量的往返程時(shí)間來(lái)計(jì)算傳輸速率。 Peach+， TCP Swift ?基于中間件的解決方法，或性能增強(qiáng)代理，包括TCP分裂 (Splitting)和 TCP欺騙 (spoofing) 25 衛(wèi)星網(wǎng)絡(luò)中的 TCP協(xié)議 續(xù) 19 ? 大窗口 (LW)選項(xiàng) ?RFC 1323定義了一系列窗口擴(kuò)展選項(xiàng)，以供在包含衛(wèi)星鏈路的具有大的帶寬延時(shí)積的網(wǎng)絡(luò)中使用 ?具有較大帶寬延時(shí)積的網(wǎng)絡(luò)，如 ATM網(wǎng)絡(luò)、 Gigabit以太網(wǎng)、包交換同步光纖網(wǎng)絡(luò)和衛(wèi)星網(wǎng)絡(luò)等，都需要大窗口的支持，因此幾乎所有的商用 TCP實(shí)現(xiàn)都支持該選項(xiàng) 26 衛(wèi)星網(wǎng)絡(luò)中的 TCP協(xié)議 續(xù)
黨政相關(guān)相關(guān)推薦
鄂ICP備17016276號(hào)-1