眾所周知，每一層加入自己的頭尾信息源于上一層傳來的信息。因此，一個包在自上而下通過網絡時，必須重復這一個過程許多次，時間被消耗于內存的分配之中(而自下而上則好得多，因為下層的頭尾信息可以被上層忽略)。這種拷貝方式同時伴隨著越來越大的消息，釋放老緩沖區(qū)。鏈接方式雖然不涉及多余的拷貝，但是卻將傳輸包的設備驅動程序代碼復雜化。

另一種替代的方式與基于設備驅動程序的方式相當吻合，如圖4所示。每次當協(xié)議棧創(chuàng)建或改變時，網絡服務模塊執(zhí)行一個查詢以確定整個協(xié)議棧的頭、尾信息和最大傳輸單元要求，這樣一來當應用程序向協(xié)議棧發(fā)消息時，網絡服務模塊相應地分配一些足夠大容納整個協(xié)議棧頭尾信息的緩沖區(qū)，每一層僅僅將頭尾信息填充至這些緩沖區(qū)，而不需內存分配或拷貝，這一機制對于性能有顯著的改善。
　　重傳緩沖區(qū)另一個效率不高的原因在于，協(xié)議層提供確認與重傳機制，一個可靠的協(xié)議層的實現(xiàn)通常包括為每個包分配一個重傳緩沖區(qū)，將包的內容拷貝至重傳緩沖區(qū)中。如果遠程系統(tǒng)的同一層確認了正確接收，重傳緩沖區(qū)將被釋放，然而，如果一個“NACK”發(fā)生，協(xié)議層重傳緩沖區(qū)的內容，同時再分配一個重傳緩沖區(qū)，拷貝內容至重傳緩沖區(qū)。
　　如果已經發(fā)出的包可以被協(xié)議層標記為“Unmarked”或“Reserved”的話，上述機制就可被取消，這種情況僅保存一個指針而不拷貝。當設備驅動程序完成傳送包并試圖釋放緩沖區(qū)，緩沖區(qū)系統(tǒng)確認此緩沖區(qū)保留，并不釋放包，僅僅將它標記為“已傳輸”，當相應的協(xié)議層收到確認(ACK)之后，就把包去掉標識，并且釋放緩沖區(qū)，通過把這一特性固化至網絡服務模塊中，整個協(xié)議棧的效率將大大提高。
4 細節(jié)
　　任何合理的基于驅動程序的協(xié)議棧都會包含相似的數(shù)據結構、數(shù)據和控制原語及模塊函數(shù)。下面介紹一下細節(jié)數(shù)據結構，以下是一些可能用到的數(shù)據結構。
　　(1) 設備入口提供實時操作系統(tǒng)和某一特殊的協(xié)議模塊的管道；
　　(2) 驅動程序靜態(tài)變量對于每一協(xié)議層僅分配一次，不管協(xié)議層下的網絡接口有多少，它是協(xié)議層的全局存儲區(qū)域；
　　(3) 邏輯單位靜態(tài)變量僅基于接口分配，所以如果你有一個設備驅動程序控制兩個接口，就應有兩個邏輯單位靜態(tài)變量，但是僅有一個驅動程序變量和一個設備條目數(shù)據結構；
　　(4) 路徑變量基于應用程序對協(xié)議的調用，僅分配一次。
　　基于上述四種定義，協(xié)議中的各種數(shù)據應被定義為最合適的類型，被選定的數(shù)據結構應當基于這個變量如何被使用：是被協(xié)議狀態(tài)機所使用，還是接口或是應用程序，例如，一個特定的網絡接口芯片在內存中的基址就應定義為邏輯單位靜態(tài)變量。
5 函數(shù)
　　如果你正開發(fā)不止一個協(xié)議棧，編寫一系列通用的函數(shù)會有幫助，表1、表2描述了一些基于驅動程序的協(xié)議?？蚣艿臄?shù)據和控制傳輸原語及參數(shù)。