納格算法
納格演算法是以減少封包傳送量來增進TCP/IP網路的效能。它由約翰·納格任職於Ford Aerospace時命名。
納格的文件[注 1]描述了他所謂的「小封包問題」－某個應用程式不斷地送出小單位的資料，且某些常只佔1位元組大小。因為TCP封包具有40位元組的標頭資訊（TCP與IPv4各佔20位元組），這導致了41位元組大小的封包只有1位元組的可用資訊，造成龐大的浪費。這種狀況常常發生於Telnet工作階段－大部分的鍵盤操作會產生1位元組的資料並馬上送出。更糟的是，在慢速的網路連線下，這類的封包會大量地在同一時點傳輸，造成壅塞碰撞。
納格演算法的工作方式是合併（coalescing）一定數量的輸出資料後一次送出。特別的是，只要有已送出的封包尚未確認，傳送者會持續緩衝封包，直到累積一定數量的資料才送出。
演算法
if有新資料要傳送
if訊窗大小>= MSS and可傳送的資料>= MSS
立刻傳送完整MSS大小的segment
else
if管線中有尚未確認的資料
在下一個確認（ACK）封包收到前，將資料排進緩衝區佇列
else
立即傳送資料
MSS = 最大分段大小
该算法与 TCP延迟确认 会有不好的相互作用，例如当程序发送端进行两次连续的小段写再跟着读时，接收端接收到第一次写后因TCP延迟确认而等待第二次写后一并发送ACK，发送端则因第二次写数据长度小于MSS而等待第一次写的ACK（如上算法所示），最终将导致两对端都进入等待直到ACK延迟超时。因为这个原因，TCP实现通常为应用程序提供一个禁用Nagle算法的接口（通常称为TCP_NODELAY选项）。用户级解决方案是避免套接字上的 写-写-读 序列。 写-读-读 和 写-写-写 都是没问题的。但 写-写-读 则是性能杀手。所以，如果可以的话，缓冲你对TCP的小段写，然后一次发送它们。在每次读之前使用标准的UNIX I/O包并冲刷写缓存通常能起作用。
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.
