防止多個上傳

當您上傳檔案時，BITS 會建立會話標識碼，以識別 BITS 用戶端和 BITS 伺服器的上傳會話。 如果在 BITS 上傳檔案時，BITS 用戶端與伺服器之間的連線中斷，用戶端會使用會話標識碼嘗試繼續上傳。

如果 BITS 用戶端連線到與之前相同的伺服器，伺服器會辨識會話標識碼，而上傳將會從中斷點繼續。 不過，如果用戶端連接到不同的伺服器，客戶端必須從頭開始開始上傳，因為新伺服器沒有會話內容或先前上傳的數據。 當 BITS 伺服器裝載於 Web 伺服器陣列上，且未設定 BITS IIS 擴充屬性 BITSHostId 時，BITS 可能會連線到不同的伺服器。 BITSHostId 屬性會強制 BITS 用戶端連線到先前伺服器的唯一位址，而不是共用伺服器位址，以防止重新啟動。

BITS 伺服器只會嘗試將上傳檔案一次傳送至伺服器應用程式，但可能會多次傳送檔案。 例如，如果 BITS 伺服器將檔案傳送至伺服器應用程式，然後在等候伺服器應用程式的回復時終止，就會發生這種情況。 BITS 用戶端會收到 HTTP 層的錯誤碼，並在延遲之後重試上傳。 如果伺服器保持離線的時間超過 BITSHostIdFallbackTimeout 逾時，則客戶端最終會再次將要求傳送至共用伺服器位址;不同的BITS伺服器會收到檔案，並將它再次傳遞給伺服器應用程式。

即使單一前端伺服器也可能發生類似的情況。 例如，當用戶端將整個檔案上傳至伺服器時，最後一個區塊會導致伺服器將檔案轉送至伺服器應用程式。 如果 BITS 伺服器或伺服器應用程式在處理檔案之後終止，但在通知傳送至用戶端之前終止，則用戶端會收到錯誤碼，稍後再重試。 當用戶端重試時，BITS 伺服器會看到最後一個區塊已上傳，而且會再次將檔案轉送至伺服器應用程式。 如果收到上傳檔案多次是伺服器應用程式的問題，您應該考慮在數據中包含交易標識碼。