내 질문 중 하나에서 ("TCP 연결 흐름을 임의로 조작하면 문제가 발생할 수 있나요?") TCP 연결의 자발적인 지연으로 인해 문제가 발생할 수 있는지 물었습니다.
내 HTTP 프록시는 클라이언트와 서버 사이에 위치하며 내부적으로 우선 순위 대기열 메커니즘을 가지고 있습니다. 즉, 클라이언트나 서버의 패킷이 우선 순위 대기열로 푸시되고 삭제자 스레드가 우선 순위 대기열에서 가장 높은 우선 순위 패킷을 제거합니다.
나는 들었다
문제는 TCP가 재정렬 문제를 해결하기 위한 명시적인 메커니즘을 가지고 있다는 것입니다. 여기에는 보낸 사람이 패킷을 다시 보내도록 강제하는 NACK가 포함될 수 있습니다.
TCP 스트림에서 바이트를 "우선순위"로 재정렬하면 기껏해야 많은 양의 데이터가 재전송되므로 "우선순위"가 모든 것을 낮춥니다. 그러나 TCP 흐름이 너무 많이 중단되면 어느 쪽이든 포기할 가능성이 매우 높습니다.
나는 TCP가 손실된 패킷의 재전송 및 기타 모든 기능을 갖춘 신뢰할 수 있는 프로토콜이라는 것을 알고 있지만 클라이언트나 서버로부터 데이터를 수신하고 데이터를 서버로 즉시 보내는 대신 큐에 푸시할 때 또는 TCP가 일부 반대의견이 있다는 점을 고려하지 않았습니다. 클라이언트의 경우 이러한 지연이 발생합니다.
바보 같은 나. (제 생각에는) 요청이 서버에 전송되면 서버에 패킷 전송을 기다리라고 지시할 방법이 없기 때문에 패킷 손실에 대한 TCP의 허용치를 조정할 수 있는 방법이 있습니까? 손실된 것이 아니고 우선순위 대기열에 푸시되었으며 삭제 스레드가 자신의 차례라고 생각하면 대상으로 전송되지만 TCP 신뢰성은 동의하지 않을 수 있습니다.