들어오는 TCP 연결을 통해 데이터를 보내려는 공급자 (A)가 있습니다. 불행하게도 소비 서비스 (B)는 인바운드 TCP 연결을 수신 할 수 없습니다. 또한 고정 IP가 없으며 다른 요구 사항이 있습니다.
이를 해결하는 한 가지 방법은 들어오는 TCP A 포트를 다른 TCP 포트 B에 연결하여 소비자가 B에 대한 아웃 바운드 연결을 만들 수있는 서비스입니다.
이것은 독특한 문제가 아니며 [1] [2] , socat을 사용하면 내가 원하는 것에 매우 가까운 것을 만들 수 있습니다.
socat -d -d -d -u TCP4-LISTEN:PORT-A,reuseaddr TCP4-LISTEN:PORT-B,reuseaddr
그러나 다음과 같은 문제가 있습니다.
- B 연결이 끊어지면 다시 연결할 수 없습니다. 을 사용하면
TCP4-LISTEN:PORT-B,reuseaddr,fork
연결할 수는 있지만 데이터를받지는 않습니다. - A가 연결을 설정하기 전에 B는 연결할 수 없습니다 (추가 가능)
- 하나의 연결 만 설정 가능
PORT-B
(추가 가능)
“영구”되고 고장에 저항하도록 명령을 조정하는 방법이 있습니까?
답변
중요한 질문은 A가 연결 손실 또는 연결 거부에 어떻게 대응할 것인가입니다. 단일 TCP 연결이 영원히 유지 될 것이라고 가정하는 것은 취약합니다. 그것은 단지 인터넷의 본질입니다.
서비스 socat
로 설정하는 것은 [x]inetd
어떻습니까?
xinetd
PORT-B에서 수신 대기하도록 설정 socat -u TCP4-LISTEN:PORT-A,reuseaddr STDIO
하고 B 측이 연결되는 즉시 시작하십시오 .
xinetd
들어오는 트래픽을 B 측에서 표준 입력으로 전달 socat
하고 표준 출력을 포착 socat
하여 B 측으로 전달합니다.
B의 연결이 끊어지면 socat
프로세스를 종료 할 수 있습니다. xinetd
B가 다시 연결 되 자마자 새로운 것을 시작합니다. B의 연결이 끊어지면 A에 “연결 거부”오류가 발생합니다.
예전 HP-UX 시스템에서 비슷한 작업을 수행해야했습니다.
답변
현실은 지저분합니다.
실제 환경에서는 때때로 TCP 연결이 끊어 지는데, 이는 예를 들어 상태 저장 방화벽 또는 NAT가 재부팅되는 경우, 트래픽없이 연결이 너무 오래 지속되는 경우, 기본 연결이 너무 오랫동안 다운 된 경우에 발생할 수 있습니다.
또한 연결이 끊어지면 대칭 적으로 죽지 않습니다. 많은 데이터를 전달하는 연결이 끊어지면 발신자가 수신자보다 오래 전에 죽었 음을 알 수 있습니다. 여기에는 몇 가지 부작용이 있습니다.
- 발신자에서 수신자로 연결이 시작되면 기존 연결이 아직 활성 상태 인 동안 새 연결이 시작될 수 있습니다.
- 수취인에서 발신인으로 연결이 시작되면 발신자가 연결이 끊어진 것을 감지하고 수취인이 해당 사실을 감지하고 재 연결을 트리거하는 것 사이에 상당한 지연이있을 수 있습니다.
또한 TCP 연결은 메시지 스트림이 아닌 바이트 스트림이므로 연결이 끊어지면 부분 메시지가 수신 될 수 있습니다.
이로 인해 강력한 솔루션은 솔루션이 이해할 수 있도록 응용 프로그램 프로토콜에 대한 이해가 필요하다는 결론을 내릴 수 있습니다.
- 새로운 연결이 올 때 스트림을 연결하는 방법.
- 데이터 소스가 데이터 수신자에 의해 연결될 때 메시지를 저장해야하는지 여부입니다.
- 메시지 손실을 막기 위해 엔드-엔드 승인 메커니즘이 적절한 지 여부
- 연결 끊김 감지 속도를 높이기 위해 일종의 응용 프로그램 수준 “핑”메커니즘이 필요한지 여부