Golang实现HTTPS代理：数据读取结束判定及阻塞问题解决

我正在用Golang开发一款HTTPS代理，知道浏览器最初发送的请求头会以\r\n\r\n结尾，socket会阻塞在read()直到读取到这些字符。但在SSL/TLS加密且HTTP 1.1（保持连接）的场景下，有几个疑问：

1. 浏览器如何判定数据读取结束？
2. 是否会逐字节读取并通过特殊字符判断结束？这种方式处理大数据是否可行？
3. 还是会先发送数据长度（如TCP Socket相关建议所述）？
4. 作为代理，在流式传输或加载普通HTML页面时，该如何判定数据读取结束？

以下是部分代码，本地网络运行正常，但在VPS服务器上会阻塞在read()直到连接关闭：

func write(client_to_proxy net.Conn, browser_to_client net.Conn) {
    defer client_to_proxy.Close()
    buffer := make([]byte, 1024)

    reader := bufio.NewReader(browser_to_client)

    for {
        length, err := reader.Read(buffer)
        if length > 0 {
            fmt.Println(time.Now().Format(time.Stamp) + " READ from client to browser: " + strconv.Itoa(length))
            //fmt.Println(string(buffer[:readLeng]))

            writeLength, err := client_to_proxy.Write(buffer[:length])
            if writeLength > 0 {
                fmt.Println(time.Now().Format(time.Stamp) + " WRITE from client to browser: " + strconv.Itoa(writeLength))
            }
            if err != nil {
                fmt.Println("ERR6 ", err)
                return
            }
        }
        if err != nil {
            fmt.Println("ERR5 ", err)
            return
        }
    }
}

func read(client_to_proxy net.Conn, browser_to_client net.Conn) {
    defer browser_to_client.Close()
    buffer := make([]byte, 1024)

    reader := bufio.NewReader(client_to_proxy)
    length, err := reader.Read(buffer)

    fmt.Println(time.Now().Format(time.Stamp) + " READ from proxy to client: " + strconv.Itoa(length))
    fmt.Println(string(buffer))

    if length > 0 {
        writeLength, err := browser_to_client.Write(buffer[:length])
        fmt.Println(time.Now().Format(time.Stamp) + " WRITE from client to browser: " + strconv.Itoa(writeLength))
        if err != nil {
            fmt.Println("ERR7 ", err)
            return
        }
    }
    if err != nil {
        return
    }

    go write(client_to_proxy, browser_to_client)

    for {
        length, err := reader.Read(buffer)
        fmt.Println(time.Now().Format(time.Stamp) + " READ from proxy to client: " + strconv.Itoa(length))
        //fmt.Println(string(buffer[:length]))
        if length > 0 {
            writeLength, err := browser_to_client.Write(buffer[:length])
            fmt.Println(time.Now().Format(time.Stamp) + " WRITE from client to browser: " + strconv.Itoa(writeLength))
            if err != nil {
                fmt.Println("ERR8 ", err)
                return
            }
        }
        if err != nil {
            return
        }
    }
}

编辑补充：架构是浏览器->客户端->代理->目标网站，再反向返回。不需要加密数据！问题出在客户端应用，不知道该读取多少字节才能解除read()的阻塞！

1. 浏览器判定数据读取结束的方式 #

HTTP 1.1在长连接下，浏览器主要靠两种机制判断数据结束：

• Content-Length响应头：服务器提前明确返回响应体的字节长度，浏览器读取到对应长度后即判定数据结束。
• Transfer-Encoding: chunked：若无法提前确定响应体长度，服务器会采用分块传输——每个数据块开头是十六进制的块长度（带\r\n），随后是块内容，最后用长度为0的块（0\r\n\r\n）标记整个响应结束。

2. 逐字节读取+特殊字符判断的可行性 #

这种方式仅适用于明文HTTP头的判定（比如\r\n\r\n），在SSL/TLS加密场景下完全无效——加密后的数据流是二进制格式，不存在可识别的“特殊字符”。即便在明文场景下，逐字节读取效率极低，处理大数据时会严重拖慢性能，绝对不推荐。

3. 是否先发送数据长度 #

HTTP 1.1没有强制要求必须先发送数据长度，两种情况都存在：

• 当服务器能提前计算出响应体长度时（比如静态文件），会携带Content-Length头；
• 当响应体是动态生成（比如流式输出、实时数据）时，会采用chunked分块编码，每块单独携带自身长度。

4. 代理的处理方式 #

作为代理，你不需要手动判定“数据结束”——TCP是流式协议，代理的核心逻辑就是透传：

• 从连接一端读取数据，读到多少就往另一端写入多少，直到连接关闭或出现错误。
• 你的代码问题出在read函数逻辑混乱：第一次读取后启动write goroutine，自身还继续循环读取，导致同一个连接被两个goroutine同时读取，引发异常。正确做法是为每个连接启动两个独立goroutine，分别处理双向数据流。

代码修正建议 #

将逻辑简化为双向透传，无需关心数据结束时机：

// 单向数据流透传：从src读取数据，写入dst
func pipe(src, dst net.Conn) {
    defer src.Close()
    defer dst.Close()
    buffer := make([]byte, 4096) // 4096字节缓冲区比1024更高效
    for {
        n, err := src.Read(buffer)
        if n > 0 {
            if _, writeErr := dst.Write(buffer[:n]); writeErr != nil {
                fmt.Println("写入错误:", writeErr)
                return
            }
        }
        if err != nil {
            // 读取到EOF或连接错误，退出循环
            return
        }
    }
}

// 处理客户端与代理的双向连接
func handleClient(clientConn, proxyConn net.Conn) {
    // 启动两个goroutine分别处理双向数据流
    go pipe(clientConn, proxyConn)
    go pipe(proxyConn, clientConn)
    // 等待任意一个goroutine结束（连接关闭）
    select {}
}

每个方向的数据流由独立goroutine处理，只要连接未关闭就持续读写，直到某一端断开连接，Read返回EOF后goroutine自动退出，彻底解决阻塞问题。

内容的提问来源于stack exchange，提问作者user13954958