TCP实现的不一致性

Question

TCP实现的不一致性

3

我正在使用C/Obj-C实现TCP。
我注意到不同的服务器在某些情况下会增加序列号，而其他服务器则不会。具体来说，在拆除过程中，当服务器发送FIN/ACK时，一些服务器会将ACK号增加1，而另一些则不会。
为了澄清问题：
服务器1：ACK号已增加至2。 Working TCP-Teardown

服务器2：ACK号仍为1。 ACK号未增加 http://img853.imageshack.us/img853/1248/zf70.png
关于第二个服务器，我的程序输出：

    FIN(/ACK)# was 18238 but should have been 18239

我应该如何处理代码中出现的服务器端实现变体？

- 0xfee1dead

1

你的目的是什么？你是在实现TCP/IP协议栈（通常是操作系统的一部分），还是在编写TCP客户端或TCP服务器（应用程序）？ - kol

我正在实现TCP/IP协议栈，从创建IP头部到解析TCP数据包。 - 0xfee1dead

2

如果您对确认号不满意，则应使用RST中止。如图所示。 - Hans Passant

2

请记住波斯特尔法则。 - msw

1个回答

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Gautam · Accepted Answer

您是否在实现过程中参考了一些RFC文档？我不知道哪个RFC包含正确的行为（增加ACK号码还是不增加）在发送FIN+ACK时，但我猜测ACK号码确实应该被增加。

话虽如此，我们都知道“符合RFC标准”的实现可能有多么不靠谱...（不仅仅是TCP实现）!! 特别是对于拆除连接的消息交换，编写软件的人必须特别小心。所以现在您有两个选择：

在您的代码中处理两种情况-当ACK被增加和当它没有被增加-并适当关闭您的连接端口，或者
针对错误的ACK使用RST（请参阅RFC获取正确的行为），但仍然适当关闭您的连接端口

这是处理相同标准的不同实现时经常遇到的问题（这本来就违背了标准的初衷）。因此，请注意，这可能只是您可能会遇到的这类问题中的第一个。

我经常不得不添加额外的代码来处理特定情况，当给定RFC的实现在Linux上工作得很好，但在Windows上却无法通过最基本的测试。