跳至內容
主選單
主選單
移至側邊欄
隱藏
導覽
首頁
近期變更
隨機頁面
MediaWiki說明
Taiwan Tongues 台語維基
搜尋
搜尋
外觀
建立帳號
登入
個人工具
建立帳號
登入
檢視 自動重傳請求 的原始碼
頁面
討論
臺灣正體
閱讀
檢視原始碼
檢視歷史
工具
工具
移至側邊欄
隱藏
操作
閱讀
檢視原始碼
檢視歷史
一般
連結至此的頁面
相關變更
特殊頁面
頁面資訊
外觀
移至側邊欄
隱藏
←
自動重傳請求
由於以下原因,您無權編輯此頁面:
您請求的操作只有這些群組的使用者能使用:
使用者
、taigi-reviewer、apibot
您可以檢視並複製此頁面的原始碼。
'''自動重傳請求'''(Automatic Repeat-reQuest,ARQ)是 OSI 模型中數據鏈路層佮傳輸層的錯誤糾正協議之一。伊通過使用確認和超過這兩个機制,佇無可靠服務的基礎上實現可靠的信息傳輸。若發送方咧發送了後一段時間是內底無收著確認講伊的,伊通常會重新發送。ARQ 可能包括停止等待 ARQ 協議佮連紲 ARQ 協議,錯誤檢測(Error Detection)、 正面確認(Positive Acknowledgment)、 超時重傳(Retransmission after Timeout)佮負面確認佮重傳(Negative Acknowledgment and Retransmission)等機制。 ==停止並等待 ARQ 協議(stop-and-wait)== 停止並等待協議的工課原理如下: 一 . 發送點著接收點發送數據包,然後等待接收點回復 ACK 並且開始咧計時間。 二 . 佇咧等待過程當中,發送點停止發送新的數據包。 三 . 當數據包無成功予人接收點接收的時陣,接收點袂發送 ACK。按呢發送點佇咧等待一定時間了後,重新發送數據包。 四 . 重複以上步數直到收著對接收點發送的 ACK。 發送點的等待時間應當至少大於傳輸點數據包發送時間(數據包容量除以發送點傳輸速度), 接收點 ACK 接收的時間(ACK 容量除了接收點傳輸速度), 數據佇連接著的傳送時間,接收點檢驗接收數據敢有正確的時間佮。佇實際應用當中,等待時間是這佮的二倍到三倍。 這个協議的缺點是較長的等待時間致使低的數據傳輸的速度。佇低速傳輸時,著連接頻道的利用率較好,毋過佇咧高速傳輸的時陣,頻道的利用率會明顯下降。 ==連紲 ARQ 協議(Continuous ARQ)== 為著克服停止並等待 ARQ 協議長時間等待 ACK 的缺點。這个協議會連紲發送一組數據包,然後閣等待遮的數據包的 ACK。 ===回退 N 重傳 ( Go-Back-N )=== * 接收點擲捒對頭一个無收著的數據包開始的所有數據包。 * 發送點收著 NACK 後,對 NACK 中指明的數據包開始重新發送。 ===選擇重傳 ( Selective Repeat )=== * 發送點連紲發送數據包毋過對每一个數據包攏設有一个計時器。 * 當佇一定時間內無收著某一个數據包的 ACK 時,發送點只有重新發送彼無 ACK 的數據包。 ==方法== ARQ 協議著錯誤糾正的方法是: * 擲捒已經接收的含有錯誤的數據包。 * 向發送點請求重新發送數據包。 ==應用== UMTS 的 ARQ 機制是佇基地台控制站(Radio Network Controller,RNC), 使用安置佇協議數據單元(Protocol Data Unit,PDU)前的序號來做敢有封包擲失的依據,有袂少的延遲時間。 ==優點佮缺點== ARQ 協議的優點是伊非常的簡單。因為按呢生廣泛的應用佇分組交換網路內底。 ARQ 協議的缺點是需要接收方發送 ACK,按呢增加網路的負擔嘛影響傳輸速度。重複發送數據包來糾正錯誤的方法嘛嚴重的影響矣伊的傳輸速度。 ==參見== * HARQ * 選擇重傳 ARQ ==參考文獻== [[分類: 待校正]]
返回到「
自動重傳請求
」。