16
클라이언트/서버 TCP 연결이 얼마나 오래 지속될 것으로 예상 할 수 있습니까?TCP 연결 수명
나는 영구히 연결되어 있기를 원하지만 일이 생기면 클라이언트가 다시 연결해야합니다. 어느 시점에서 일부 외부 장비에 문제가있는 것이 아니라 코드에 문제가 있다고합니까?
A
답변
14
나는 Zan Lynx에 동의합니다. 아무런 보장은 없지만 연결 또는 대역폭 문제가 없다고 가정하면 데이터를 전송하여 연결을 거의 무기한 유지할 수 있습니다.
일반적으로 응용 프로그램 수준의 Keep-Alive 방식을 사용했지만 클라이언트 사양에 포함되어 있기 때문에 일반적으로 사용했습니다. 그러나 몇 분 정도의 짧은 데이터를 보내 주시면 몇 분 정도의 승인을 받으실 것입니다.
실패한 연결이 사용자에게 달려 있으므로 하나의 응답 실패를 계산할지 여부는 사용자가 결정합니다. 일반적으로 이것은 과거에 내가 한 일이었습니다. 3 개의 실패한 응답이 연속적으로 끊어지기를 기다렸던 사례가 있었지만, 연결의 다른 끝에있는 응용 프로그램은 "당신이 거기 있습니까? ? " 요청.
연결이 실패하면 동일한 네트워크에있는 컴퓨터를 사용해도 연결이 실패하면 다시 연결하십시오. 설정 한 횟수 이상 실패하면 문제가 발생합니다. 연결이 잠시 동안 지속 된 후에도 연결이 계속 실패하면 문제가 발생합니다. 대부분의 경우 두 경우 모두 코드보다는 네트워크 문제 일 수도 있고 컴퓨터의 TCP/IP 스택과 관련된 문제 일 수도 있습니다 (알려진 바 있습니다. 이전 버전의 QNX에서이 문제가 발생했습니다. 무작위로 넘어집니다). 소프트웨어 문제가있을 수 있으며, 디버거를 부착하거나 거기에 로그인하는 것이 확실한 유일한 방법입니다. 예 : 당신은 항상 성공적으로 연결할 수 있지만, 다시 연결 한 후에도 ACK를 얻지 못하게되면 서버가 교착 상태에 빠지거나 반복문 등에 걸릴 수 있습니다.
정말로 유용한 기능은 다양한 부하 조건에서 일련의 장기 실행 테스트를 설정하는 것입니다. 단 몇 분만 대기 상태로 보내거나 요청/응답을 보내서 서버를 완전히 망가 뜨리는 것입니다.이것은 일반적으로 소프트웨어 구성 요소에 대해 더 많은 자신감을 가지게 될 것이고, 실제로 발생하는 트랜잭션에 문제를 일으킬 수는 있지만 실제로 연결에 문제를 일으키지 않는 일부 이상한 문제를 떨쳐 내는데 유용 할 수 있습니다. 예를 들어, 저는 전화 번호 변환과 같은 서비스를 제공하는 통신 애플리케이션 서버를 한 번 작성했으며, 한 번에 며칠 씩 실행되도록했습니다. 문제는 토요일이 온다는 것이 었습니다. 하루 종일 전화가 걸려 왔을 때 전화 요청 건수는 수백만 건에 달했지만 이유는 알 수 없었습니다. 토요일에만 문제를 일으킨 날짜 변환 코드에서 오타가 하나 발생했기 때문입니다.
희망이 있습니다.
7
정말 중요하지 않습니다. 원하는 동작이면 자동으로 다시 연결되도록 코드를 디자인해야합니다.
6
정말 말할 길이 없습니다. 특정 시간이 지나면 연결이 끊어지는 원인이되는 TCP에는 본질적인 것이 없습니다. 안정적인 연결을하는 사람은 몇 년 동안 가동 시간을 가질 수 있지만 다른 연결을 사용하는 사람은 5 분마다 다시 연결해야합니다. 말하거나 추측 할 길이 없습니다.
-2
값을 지정하십시오. 1 시간마다 한 방울 정도 괜찮을 것입니다. 예상치 못한 5 분 안에 연결이 끊어지면 문제가 있음을 나타냅니다.
TCP 연결은 일반적으로 트래픽없이 약 2 시간 동안 지속됩니다. 양쪽 끝은 keep-alive 패킷을 보낼 수 있습니다. 이것은 마지막으로받은 패킷의 ACK입니다. 이것은 일반적으로 모든 TCP 연결에서 소켓 또는 기본적으로 설정할 수 있습니다.
응용 프로그램 수준 유지도 가능합니다. FTP, SMTP, POP 또는 IMAP과 같은 텔넷 스타일 프로토콜의 경우 리턴, 개행 문자 전송 및 명령 프롬프트 복원과 같은 것입니다.
+0
TCP keepalive는 다음에 따라 달라지는 타이머입니다. OS이므로 2 시간은 특정 환경에 따라 다를 수 있습니다. – benc
2
정기적으로 연결을 통해 데이터를 유지해야합니다. 많은 OS 또는 방화벽이 비활성 연결을 끊습니다.
11
여기서 가장 중요한 아이디어는 이론 대 실습이라고 생각합니다.
원래의 이론은 연결에 수명이 없다는 것이 었습니다. 연결되어있는 경우 이벤트가 종료 될 때까지 트래픽이 없더라도 영원히 열어 두었습니다.
새로운 이론은 대부분의 OS 릴리스에서 연결 유지 타이머가 켜져 있다는 것입니다. 즉, 다른 쪽 시스템이 가끔씩 TCP 레벨 교환에 응답하는 한 연결은 영원히 지속됩니다.
사실 많은 기준과 상황으로 시간이 지나면 많은 연결이 종료됩니다.
두 가지 좋은 예는 다음과 같습니다. 원격 클라이언트가 DHCP를 사용 중이고 임대 기간이 만료되고 IP 주소가 변경됩니다.
또 다른 예는 점점 지능화되는 것처럼 보이는 방화벽이며, keepalive 트래픽과 실제 데이터를 식별하고 높은 기준, 특히 유휴 시간을 기준으로 연결을 닫을 수 있습니다.
재 연결 논리를 구현하려는 방법은 아키텍처, 작업 환경 및 성능 목표에 따라 크게 달라집니다.
정확한 KeepAlive 간격이있는 경우 언제든지 : http://stackoverflow.com/questions/3907537/keep-alive-tcp-ip-connected-sockets-over-the-internet-when-how-and- how-much/5149662 # 5149662 – markmnl
1999 년에 어떤 사람들이 대답 했습니까? https://ask.slashdot.org/story/99/09/19/2150236/longest-open-tcp-connection – user3041714