【问题标题】:net.DialTCP produces "connection refused" error on Linux but not on Windowsnet.DialTCP 在 Linux 上产生“连接被拒绝”错误,但在 Windows 上没有
【发布时间】:2020-08-10 13:47:32
【问题描述】:

代码

要重现需要两个应用程序运行并通过 TCP 相互连接。所以我做了一个很小的 ​​repo,其中还包括 powershell 构建脚本。 link to the full repo

但是为了避免额外的点击,这里是clientA.go的代码。

package main

import (
    "fmt"
    "net"
    "time"
)

func main() {
    clientA, err := net.ResolveTCPAddr("tcp4", fmt.Sprintf(":%v", "2222"))
    if err != nil {
        fmt.Println(err)
        return
    }

    clientB, err := net.ResolveTCPAddr("tcp4", fmt.Sprintf(":%v", "3333"))
    if err != nil {
        fmt.Println(err)
        return
    }

    for {
        clientAtoB, err := net.DialTCP("tcp4", clientA, clientB)
        if err != nil {
            fmt.Println(err)
        } else {
            defer clientAtoB.Close()
            clientAtoB.SetLinger(0)
            clientAtoB.SetNoDelay(true)
            clientAtoB.SetKeepAlive(false)
            fmt.Println("connected as Client A!")
            buffer := make([]byte, 64)
            _, err = clientAtoB.Read(buffer)
            if err != nil {
                continue
            }
        }
        time.Sleep(time.Second)
    }
}

clientB.go 的代码是相同的,只是本地和远程端点交换了:

clientBtoA, err := net.DialTCP("tcp4", clientB, clientA)

问题

我为 Windows 和 Linux 构建了相同的 go 代码,但在运行时应用程序会产生不同的结果。特别是在每个平台上如何拨打 TCP 连接。

在 Windows 上,当我运行两个可执行文件 clientA.execlientB.exe(由 bu​​ild.ps1 脚本构建)时,我得到了想要的结果。如此屏幕截图所示:

但是,当我上传并执行 Linux 二进制文件时,结果却有所不同:

ubuntu@ip-172-31-16-224:~/go/src/github.com/fanmanpro/dial-vs-listen$ sudo chmod +x clientA clientB
ubuntu@ip-172-31-16-224:~/go/src/github.com/fanmanpro/dial-vs-listen$ ls -la
total 10984
drwxrwxr-x 3 ubuntu ubuntu    4096 Apr 27 03:09 .
drwxrwxr-x 4 ubuntu ubuntu    4096 Apr 27 03:08 ..
drwxrwxr-x 8 ubuntu ubuntu    4096 Apr 27 03:08 .git
-rw-rw-r-- 1 ubuntu ubuntu   11255 Apr 27 03:12 A.txt
-rw-rw-r-- 1 ubuntu ubuntu   11255 Apr 27 03:12 B.txt
-rw-rw-r-- 1 ubuntu ubuntu     247 Apr 27 03:08 build.ps1
-rwxrwxr-x 1 ubuntu ubuntu 2950662 Apr 27 03:08 clientA
-rw-rw-r-- 1 ubuntu ubuntu 2642944 Apr 27 03:08 clientA.exe
-rw-rw-r-- 1 ubuntu ubuntu     718 Apr 27 03:08 clientA.go
-rwxrwxr-x 1 ubuntu ubuntu 2950662 Apr 27 03:08 clientB
-rw-rw-r-- 1 ubuntu ubuntu 2642944 Apr 27 03:08 clientB.exe
-rw-rw-r-- 1 ubuntu ubuntu     718 Apr 27 03:08 clientB.go
ubuntu@ip-172-31-16-224:~/go/src/github.com/fanmanpro/dial-vs-listen$ ./clientA > A.txt & ./clientB > B.txt &
[1] 24914
[2] 24915
ubuntu@ip-172-31-16-224:~/go/src/github.com/fanmanpro/dial-vs-listen$ cat A.txt
dial tcp4 :2222->:3333: connect: connection refused
ubuntu@ip-172-31-16-224:~/go/src/github.com/fanmanpro/dial-vs-listen$ cat B.txt
dial tcp4 :3333->:2222: connect: connection refused
ubuntu@ip-172-31-16-224:~/go/src/github.com/fanmanpro/dial-vs-listen$                                               

我不希望出现connection refused 错误,因为这两个应用程序在同一环境下运行,因此没有防火墙生效,并且权限相同。

无论平台如何,我怎样才能获得相同的结果?或者为什么它们一开始就不同?

编辑

Windows 上的成功连接不仅仅是时机的运气。在 Windows 上,我可以运行 A 5 分钟,然后当我运行 B 时,都连接成功。

更新(2020-04-27)

在收到 Go 开发人员的反馈后,我被告知这可能是 Linux 配置问题,而不是 Go 特有的问题。除了权限之外,我无法阻止同一环境中的两个应用程序建立这样的 TCP 连接? (这些低级 Linux 的东西并不是我的强项。)

【问题讨论】:

  • 我不明白它是怎么工作的这里。即使使用无限重试 for 循环,也不确定事情是否会神奇地正确排列,从而发生连接。这段代码纯靠运气,这是不正确的。
  • @mh-cbon 在 Windows 上,我可以运行 A 5 分钟,然后当我运行 B 时,它连接成功。
  • 难以置信。在这两个平台上,您都应该收到一系列“连接被拒绝”消息,直到服务器端启动,然后才成功。根据您发布的代码,没有理由只收到一条此类消息然后退出该过程。

标签: linux windows go tcp


【解决方案1】:

为什么这在 Linux 上不起作用是很明显的。 A 和 B 都是连接到需要监听的对方的客户端。在 Linux(或 UNIX)上,如果您尝试运行 ClientA,它将尝试拨入 ClientB 的地址和端口。如果 没有进程已经在监听这个地址和端口来接受连接,那么 ClientA 将立即以 connection refused 错误结束(这并不完全正确,但大多数情况下,请参阅我的在答案末尾编辑)。

在 Windows 上,Golang 在底层使用(用于 tcp、tcp4 和 tcp6 协议)ConnectEx API,用于面向连接的套接字。此 API 的行为不同于 Linux connect API。如果ConnectEx 无法立即连接,它会返回错误代码ERROR_IO_PENDING 并在后台等待/重试,直到连接被接受并建立(或者它放弃并使其最终失败)然后通知回来 - 这称为重叠 I/ O。

MSDN ConnectEx 文档的相关部分:

面向连接的套接字通常无法立即完成它们的连接,因此会启动操作并且函数会立即返回 ERROR_IO_PENDING 或 WSA_IO_PENDING 错误。当连接操作完成并实现成功或失败时,使用 lpOverlapped 中指示的完成通知机制报告状态。

现在,您在 Windows 上发生的情况是您尝试从双方ConnectEx 并且操作系统为您连接这些套接字。这仅在另一端在一定时间内连接时才有效。如果您尝试在两个客户端(例如 17 和 28)中合理地增加 time.Sleep 间隔,您甚至可以在 Windows 上看到它们将很难再连接。

您的问题的答案是,您现在编写的代码取决于 Windows 上 Golang 中 TCP 拨号的操作系统特定行为,并且不可移植。 修复您的软件以便在任何Golang 支持的平台,您可能想要更改逻辑,以便 ClientA 和 ClientB listen 接收传入连接,并定期尝试 connect 到另一端。

编辑:我并不是说您的代码根本不能在 Linux 上运行。它实际上使用称为 TCP 同时连接 的罕见连接模式,您可以在其中连接两个进程而无需其中任何一个进程listen。拨号双方同时发送他们的 SYN,因此每一方都以 SYN/ACK 和 ACK 响应,以完成 3 次握手和 ESTABLISH 连接。这需要在两个客户端中对connect 调用进行非常精确的计时和同步。如果在 Linux 内核中允许 TCP 同时连接并且实现connects 之间的同步,双方将连接(仅通过手动或从同一脚本运行两个客户端几乎无法完成;即使在同一进程和线程中进行模拟也不是那么容易) .

【讨论】:

  • 嗨,OP 代码中的另一个奇怪的事情是两个客户端使用相同的端口号,只反转那些监听,一个拨号。我不清楚这是否合法。我相信一个用来拨号的端口不能用来监听。虽然,这段特定的代码让我怀疑。
  • @mh-cbon 这在某种程度上是正确的。我编辑了我的答案,还提到了这种非常罕见的 TCP 连接模式,称为 TCP 同时连接,您可以在不听的情况下连接两个拨号进程。但是,OP 有意这样做的可能性很小。
  • 相当有趣的是,我成为这种独特场景的牺牲品。还好奇在 Windows 上它可能会以某种方式被滥用吗? (我正在考虑在正确的时间通过一些恶意应用程序拨号到客户端,以伪造一个所谓的安全服务器连接......)
  • @FanusduToit 我不是网络/winapi 安全专家,所以这只是评论。我不认为这种拨号方式会产生额外的攻击面。您可以诱使客户端连接到“通常编写的”恶意服务器,也就是listening。如果原始服务器已经在侦听指定的端口和地址,您将无法在恶意软件中bind 这些。我编辑了我的答案并添加了 3 路 TCP 握手在您的情况下的工作方式,这也适用于 Linux,您只需要更精确的时间来使其与 Windows 上的行为相同。
猜你喜欢
  • 2017-08-15
  • 2016-04-12
  • 1970-01-01
  • 2013-06-13
  • 2017-08-18
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多