이 가이드는 Go의 HTTP 응답 처리에서 버퍼링 문제를 다룹니다. 여기서 응답은 일반적으로 버퍼링되어 블록 단위로 전송됩니다. 요청이 처리된 후 클라이언트. 스트리밍 시나리오의 경우 이는 바람직하지 않을 수 있습니다.
제공된 코드 조각은 두 줄의 데이터가 스트리밍되어야 하지만 버퍼링으로 인해 동시에 전송되는 문제를 보여줍니다.
이 문제를 해결하는 한 가지 접근 방식은 응답 버퍼를 명시적으로 플러시하는 것입니다. Go의 ResponseWriter는 Flush 메서드를 제공하지만 그 가용성은 특정 구현에 따라 다릅니다.
예를 들어 다음 수정 코드는 플러싱을 통합합니다.
func handle(res http.ResponseWriter, req *http.Request) { fmt.Fprintf(res, "sending first line of data") if f, ok := res.(http.Flusher); ok { f.Flush() } sleep(10) //not real code fmt.Fprintf(res, "sending second line of data") }
외부 명령 출력 스트리밍과 같은 특정 시나리오에서는 직접 플러시만으로는 충분하지 않을 수 있습니다. Go의 파이프 메커니즘을 사용하면 명령 출력과 응답 작성기 간의 직접 스트리밍이 가능합니다.
다음은 샘플 구현입니다.
pipeReader, pipeWriter := io.Pipe() cmd.Stdout = pipeWriter cmd.Stderr = pipeWriter go writeCmdOutput(res, pipeReader) err := cmd.Run() pipeWriter.Close() func writeCmdOutput(res http.ResponseWriter, pipeReader *io.PipeReader) { buffer := make([]byte, BUF_LEN) for { n, err := pipeReader.Read(buffer) if err != nil { pipeReader.Close() break } data := buffer[0:n] res.Write(data) if f, ok := res.(http.Flusher); ok { f.Flush() } //reset buffer for i := 0; i < n; i++ { buffer[i] = 0 } } }
더 많은 유연성을 위해 , TCP 연결을 직접 제어할 수 있는 TCP Hijacker를 사용할 수 있습니다. 그러나 이 접근 방식은 네트워크 프로그래밍에 대한 깊은 이해가 필요하며 일반적인 사용 사례에는 덜 권장됩니다.
버퍼링은 네트워크 구성 요소나 클라이언트 애플리케이션 내에서 계속 발생할 수 있으므로 주의하세요. 명시적 플러시 또는 대체 솔루션의 필요성을 결정하기 위해 특정 사용 사례를 평가하는 것이 중요합니다.
위 내용은 Golang에서 HTTP 응답을 스트리밍하고 기본 버퍼링을 방지하려면 어떻게 해야 합니까?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!