共用方式為


TCP/IP 特性

TCP/IP 具有特性,可讓通訊協定以標準化實作需求來運作。 這些特性可以結合導致效能不佳的開發選擇。 這些 TCP/IP 特性對應用程式的影響取決於應用程式是交易式還是串流。

交易式應用程式會受到連線建立和終止所需的額外負荷所影響。 例如,每次在乙太網路上建立連線時,必須傳送大約 60 個位元組的三個封包,交換需要大約一個 RTT。 發生連線終止時,會交換四個封包。 這適用于每個連線;開啟和關閉連線的應用程式通常會在每個發生時產生此額外負荷。

TCP/IP 的另一個層面是 慢速啟動,每當建立連線時就會發生。 慢速啟動是在收到這些區段通知之前可傳送的資料區段數目的人工限制。 慢速啟動的設計目的是要限制網路壅塞。 建立透過乙太網路的連線時,不論接收者的視窗大小為何,由於啟動緩慢,4 KB 傳輸最多可能需要 3-4 RTT。

稱為 Nagle 演算法的 TCP/IP 優化也可以限制連線上的資料傳送速率。 Nagle 演算法的設計目的是為了減少傳送少量資料的應用程式通訊協定額外負荷,例如 Telnet,一次傳送單一字元。 堆疊不會立即傳送含有許多標頭和少量資料的封包,而是在繼續之前,先等候應用程式的資料或通知。

延遲通知通常稱為 延遲的 ACK,也設計成 TCP/IP,以在傳回資料從接收端應用程式傳入時,啟用更有效率的通知回送。 可惜的是,如果此資料未來臨,且傳送端正在等候通知,則每個傳送的延遲大約 200 毫秒可能會發生。

當 TCP 連線關閉時,起始關閉的節點連線資源會進入等候狀態,稱為 TIME-WAIT,以在網路中重複的封包等待時防範資料損毀。 這可確保兩端都已完成連線。 當應用程式經常開啟和關閉連線時,這可能會導致每個連線所需的資源耗盡,例如 RAM 和埠。

除了受到延遲 ACK 和其他壅塞避免配置的影響之外,串流應用程式也會受到接收端上太小的預設接收視窗大小影響。

應用程式行為

高效能的 Windows 通訊端應用程式

Nagle 演算法