위성 연결의 RTT는 일반적으로 약 500ms입니다. TCP 승인이 도착하는 데 너무 오랜 시간이 걸리기 때문에 대역폭이 높음에도 불구하고 일반적으로 연결의 전송 속도가 최적이 아닙니다.
제가 이해한 바에 따르면 TCP 연결에서 이 문제를 해결하는 좋은 방법은 TCP 창 크기를 연결 속도(비트 단위)에 RTT(초 단위)를 곱한 값으로 설정하는 것입니다. 따라서 위성을 통한 1mbps 연결의 창 크기는 512kb입니다.
여기에는 어떤 함정이 관련되어 있습니까? 위성 연결을 최적화하기 위해 수행해야 할 다른 유사한 조정이 있습니까? 많은 최신 운영 체제가 창 크기를 자동으로 수정한다는 것을 알고 있습니다. 하지만 창 크기를 위성 통신에 사용할 수 있을 만큼 크게 만들 만큼 공격적일까요?
여담이지만, 패킷을 자주 삭제하는 네트워크에서는 큰 창 크기가 바람직하지 않다고 가정하겠습니다. 왜냐하면 재전송은 창 크기에 따라 이루어지며 많은 대역폭을 재전송 오버헤드에 할당할 수 있기 때문입니다.
감사합니다. 저는 아직 네트워킹에 관해 많은 것을 배우고 있으며 귀하의 의견에 감사드립니다.
답변1
일반적으로 적절한 창 크기 조정을 구현하는 TCP 스택을 사용해야 합니다. 그러나 물론 창 크기가 대역폭 지연 곱(BDP)에 도달해야 한다는 것은 맞습니다. 다양한 BDP가 있는 경우 일반적인 "최악의" 경우로 예상되는 크기로 창 크기를 설정할 수 있습니다. 흥미롭게도 창 크기가 BDP보다 큰 경우 대부분의 연결은 큰 문제를 겪지 않습니다.방법물론 너무 큽니다). 하지만 창 크기가 BDP보다 훨씬 작으면 성능이 저하됩니다.
TCP/IP 스택이 창 크기를 적절하게 늘리고 있는지 확인하려면 Wireshark나 기타 트래픽 스니퍼를 사용해야 합니다. 헤더에서 창 크기 플래그를 직접 볼 수도 있습니다(배율 인수를 염두에 두세요!). Wireshark는 배율 인수를 고려하여 효과적인 창 크기를 표시할 수도 있습니다.
TCP 창 크기를 시간 함수로 표시하는 방법에 대한 이 튜토리얼을 확인하세요.여기.
답변2
아무도 위성 연결을 통해 TCP를 실행하지 않기 때문에 이것은 완전히 학문적입니다. 나는 이 작업을 수행하는 단일 위성 공급자를 모릅니다. 이들은 모두 위성을 통해 위성별 프로토콜을 실행하고 TCP 종점을 지상국에 배치합니다.
네트워크의 시스템이 TCP SYN 패킷을 위성 터미널로 보내면 위성 터미널은 TCP 프록시 요청을 위성으로 보냅니다. 이는 지상국에 인터넷의 일부 서버에 대한 TCP 연결을 열도록 지시합니다. 지상국은 TCP를 인터넷 서버에 전달합니다. 위성 터미널은 위성을 통해 TCP를 사용하지 않고 대신 위성 사용에 최적화된 프로토콜을 사용합니다. 지상국은 위성 단말기와 인터넷 서버 사이의 프록시 역할을 합니다.
답변3
편의를 위해 대역폭 지연 곱 계산기를 사용할 수 있습니다. 그러한 계산기 중 하나는 다음과 같습니다.여기. 패킷 손실 시 문제를 일으키는 큰 창에 관해서는 이것이 바로 TCP 창 작업이 가변적인 이유입니다. 패킷이 손실되면 창 크기가 줄어들어 전송 중인 데이터가 줄어들고 결과적으로 전송 속도가 감소합니다. 일정 시간이 지나면 창 크기가 재협상됩니다.
실제로 위성의 경우 지연 시간이 그다지 나쁘지 않습니다. 1초 RTT @ 1M은 125K 창에 불과합니다. 상당수의 최신 운영 체제는 즉시 이 기능을 쉽게 지원하므로 추가 수정이 필요하지 않을 수도 있습니다.
여담이지만, 일부 사람들은 시중에서 구할 수 있는 다양한 WAN 최적화 프로그램을 사용하여 매우 행운을 누렸습니다. 이는 TCP 창 크기를 최적화할 뿐만 아니라 캐싱 및 압축을 활용하여 링크를 통해 더 많은 정보를 전달하고 명백한 응답성을 향상시키는 경향이 있습니다.