使用golang诊断从unix套接字读取的速度非常慢（netcat中1分钟vs 1秒）

Question

Background Im writing a few packages to communicate with the OpenVas vulnerability scanner - the scanner uses a few different propitiatory protocols to communicate - are all comprised of either xml or text strings sent over a unix socket or tcp connection (im using unix socket).

The issue I'm having is with the OTP protocol (OpenVas internal protocol which is not well documented)

I can run the following command using netcat and I will get a response back in under a second:

echo -en '< OTP/2.0 > CLIENT <|> NVT_INFO ' | ncat -U /var/run/openvassd.sock

This results in a fairly large response which looks like this in terminal:

< OTP/2.0 >
SERVER <|> NVT_INFO <|> 201802131248 <|> SERVER
SERVER <|> PREFERENCES <|>
cache_folder <|> /var/cache/openvas
include_folders <|> /var/lib/openvas/plugins
max_hosts <|> 30
//lots more here

So for example, I previously had some code like this for reading the response back:

func (c Client) read() ([]byte, error) {

    // set up buffer to read in chunks
    bufSize := 8096
    resp := []byte{}
    buf := make([]byte, bufSize)

    for {
        n, err := c.conn.Read(buf)
        resp = append(resp, buf[:n]...)
        if err != nil {
            if err != io.EOF {
                return resp, fmt.Errorf("read error: %s", err)
            }
            break
        }
        fmt.Println("got", n, "bytes.")

    }
    fmt.Println("total response size:", len(resp))

    return resp, nil
}

I get the full result but it comes in small pieces (i guess line by line) so the output I see is something like this (over the course of a minute or so before showing full response):

got 53 bytes.
got 62 bytes.
got 55 bytes.
got 62 bytes.
got 64 bytes.
got 59 bytes.
got 58 bytes.
got 54 bytes.
got 54 bytes.
got 54 bytes.
got 64 bytes.
got 59 bytes.
... (more)

SO I decided to try ioutil.ReadAll:

func (c Client) read() ([]byte, error) {
    fmt.Println("read start")
    d, err := ioutil.ReadAll(c.conn)
    fmt.Println("read done")
    return d, err
}

This does again return the full response, but the time between "read start" and "read done" is around a minute compared to the < 1sec the command is expected to take.

Any thoughts on why the read via golang is so slow compared to netcat - how can I diagnose/fix the issue?**

Answer 1

It appears the service is waiting for more input, and eventually times out after a minute. In your CLI example, once the echo command completes that side of the pipe is shutdown for writes, in which case the service is notified by a 0-length recv.

In order to do the same in Go, you need to call CloseWrite on the net.UnixConn after you have completed sending the command.

c.conn.(*net.UnixConn).CloseWrite()