TCP

TCP 协议合订本出了

(最后修改: Networking #TCP/IP #RFC #TCP #IETF #Standards

我们现在所说的 TCP 协议通常是指 1981 年 9 月 发表的 RFC 793 和一系列后续 RFC 定义的协议,其主体定义距今已经超过 40 年了(当然如果细究下去的话, 第一份正式的文档是 RFC 675, 而 RFC 793 本身也是针对一年前的 RFC 761 的修正,不过大部分实现者使用的基础依然是 RFC 793)。

阅读全文… ( 本文约 356 字,阅读大致需要 1 分钟 )

TCP 协议合订本出了

(最后修改: Networking #TCP/IP #RFC #TCP #IETF #Standards

我们现在所说的 TCP 协议通常是指 1981 年 9 月 发表的 RFC 793 和一系列后续 RFC 定义的协议,其主体定义距今已经超过 40 年了(当然如果细究下去的话, 第一份正式的文档是 RFC 675, 而 RFC 793 本身也是针对一年前的 RFC 761 的修正,不过大部分实现者使用的基础依然是 RFC 793)。

阅读全文… ( 本文约 356 字,阅读大致需要 1 分钟 )

SMB协议 vs TCP的延迟ACK特性

(最后修改: Kernel #SMB #TCP #delayed ACK #Networking #Windows

之前一直没什么概念,今天看了微软的 KB 321169 的解释,大致如此:

  • 客户端 (SMB Redirector) 如果启用了 security signature,则必须等待命令处理完成才会发出下一条SMB;
  • 服务器端如果启用了延迟ACK,则可能需要过200ms (Windows 2000)才会给出ACK回应

不过感觉这个解释依然不是很有说服力—-文档上说,SMB服务器端是需要对 NT_TRANSACT_NOTIFY_CHANGE 给出回应的,那么这种情况下ACK不就回应回来了吗?或者说,只要收到了 ACK 就说明服务器端已经处理了这条 SMB?哪位帮忙理解一下?

参与评论