TCP 백로그 캡처는 포트 X에서 수신 대기하는 Stratus 모듈의 서버 응용 프로그램이 동일한 클라이언트에서 포트 X. 연결에 연결하려는 클라이언트와의 연결을 성공적으로 만들지 못하도록 하는 효과입니다. 일반적인 해결책은 서버 응용 프로그램을 종료하고 다시 시작하는 것입니다. 이 게시물은 백로그 캡처가 발생하는 이유와 다른 덜 과감한 솔루션을 설명합니다.
TCP 백로그는 수신되었지만 아직 수락되지 않은 연결 요청인 보류 중인 연결의 큐입니다. OpenVOS 17.1 이전 릴리스 및 OpenVOS 17.1에 컴파일된 응용 프로그램에서 컴파일되었지만 POSIX 라이브러리가 없으면 응용 프로그램에서 승인이 전송되지 않습니다. 클라이언트는 증가하는 간격으로 연결 요청 패킷을 3~10회 다시 보냅니다. 정확한 세부 정보는 클라이언트 운영 체제와 구성 방법에 따라 달라집니다. 어떤 시점에서 서버 응용 프로그램은 연결 요청을 수락하고 STCP 스택은 승인을 보냅니다. 클라이언트가 포기하기 전에 승인이 수신되는 한 연결이 완료되고 통신이 시작될 수 있습니다.
백로그 캡처 시나리오에는 여러 조건이 필요합니다.
- 서버와 클라이언트 간에 일시적인 네트워크 오류가 있습니다(클라이언트와 서버 간에는 그렇지 않음). 이렇게 하면 서버에서 클라이언트의 연결 요청을 수신할 수 있지만 클라이언트에서 서버의 연결 승인이 수신되지 않도록 합니다.
또는
서버 응용 프로그램은 어떤 이유로 수락 함수를 호출하는 것을 지연시합니다.
- 클라이언트는 계속해서 연결 요청을 전송합니다. 현재 요청 시간이 클라이언트가 새 요청을 보내는 경우입니다. 클라이언트의 시간 초과 값은 서버의 시간 초과 값보다 짧아야 합니다.
- 상태 관리 방화벽 또는 클라이언트와 서버 사이의 어딘가에 있는 다른 장치는 클라이언트의 연결 요청을 시간 내어 서버에 응답을 다시 보내지 않고 서버의 연결 승인을 삭제합니다. 이 시간 초과 값은 서버의 시간 초과 값보다 짧아야 합니다.
불행히도 이러한 조건의 조합은 처음 나타날 수도 있는 것만큼 낮지 않습니다.
일반적으로 서버의 패킷이 클라이언트에 도달하지 못하도록 하지만 클라이언트의 패킷이 서버에 도달할 수 있도록 하는 네트워크 중단으로 시작합니다. 클라이언트의 연결 요청 패킷이 서버에 도달하면 백로그 큐에 배치됩니다. 서버 응용 프로그램이 수락 코드에 전화를 걸 때 코드는 백로그 큐에서 연결 요청을 가져오고 연결 승인을 보냅니다. 서버가 패킷에 대한 승인을 받지 못하므로 네트워크가 끊어졌기 때문에 연결 승인을 다시 전송합니다. 클라이언트의 TCP 스택도 승인되지 않았기 때문에 연결 요청을 다시 전송합니다. 잠시 후 클라이언트의 TCP 스택이 포기하고 클라이언트 응용 프로그램은 새 요청을 보냅니다. 서버는 첫 번째 요청에 계속 응답합니다. 1분 반(기본적으로) 서버가 시간을 단축하고 백로그 큐에서 다음 요청을 가져옵니다. 한편 클라이언트는 두 번째 요청을 분개하고 세 번째 요청에있을 수 있습니다. 이러한 요청은 백로그 큐에도 있습니다. 다른 클라이언트가 백로그 큐에 연결 요청을 배치할 수 있지만 성공적으로 완료하려면 백로그 큐에서 연결 요청의 위치를 곱한 서버 시간 초과보다 큰 시간 제한이 필요할 수 있습니다. 네트워크 중단이 수정되면 상태 별 방화벽이 서버 시간 초과보다 짧은 시간 동안만 상태를 보유하기 때문에 더 이상 상태가 없다는 연결 승인을 자동으로 삭제하여 중단을 영속시합니다.
여러분은 이것을 어떻게 인식합니까?
먼저 백로그가 가득 찼거나 적어도 채워져 있습니다. 이 명령과의 연결에 대한 백로그 큐를 표시할 수 있습니다.
analyze_system -request_line(문자열 일치 백로그-또는 싱크대(바이트 3Bx) dump_st +
cbq -풀 -lport 7654 -페이드 드 0x) -종료
오픈보스 릴리즈 17.0.2au, analyze_system 릴리즈 17.0.2au
현재 공정은 154, ptep 91CC7100, Noah_Davids.CAC
싱크대 6
백로그 5
준비 11:41:19
|
lport 값은 로컬 포트 번호, 7654이 경우입니다. 외부 주소(페이드더) 값이 0으로 제한하면 출력을 청취 소켓으로만 제한합니다. 백로그 값과 1이 syncnt 값과 같으면 백로그가 가득 찼습니다. 스니싱크가 0보다 크고 백로그 큐를 올라가면 채워지고 있습니다. 백로그 큐의 크기는 듣기 함수를 호출할 때 응용 프로그램에서 설정합니다.
둘째 네트워크 프로토콜 추적을 확인해야 합니다. 추적은 이전 연결 요청에 대한 연결 승인이 있고 이러한 승인이 어떤 종류의 응답을 받지 못하는 동안 마지막 연결 요청이 승인되지 않음을 보여줍니다.
그림 1의 추적은 이를 보여줍니다. 각 연결은 스트림 인덱스로 레이블이 지정되고 색상으로도 코딩됩니다. 클라이언트의 첫 번째 연결 요청은 0시 프레임 1에 있습니다. 승인은 프레임 2로 전송된 다음 프레임 3에서 다시 전송됩니다. 프레임 4는 연결 요청을 다시 전송하는 클라이언트입니다. STCP는 이미 연결 승인 프레임 4를 보내고 있기 때문에 프레임 5에서 TCP 승인만 트리거합니다. 프레임 6과 7은 다시 전송된 연결 승인입니다. 프레임 8은 클라이언트에서 다시 전송된 연결 요청입니다. 프레임 9는 다시 전송된 연결 요청에 의해 트리거된 TCP 승인이며 프레임(10)은 또 다른 다시 전송된 연결 승인입니다. 프레임 11은 클라이언트의 또 다른 연결 요청이지만 새 두 번째 연결의 경우입니다. 응답이 없고 프레임(12)에는 다시 전송된 연결 요청이 표시됩니다. 프레임 13은 연결 승인을 표시하지만 첫 번째 연결은 여전히 합니다. 프레임(14)은 두 번째 연결 요청의 재전송입니다. 프레임 14는 두 번째 연결 요청의 또 다른 재전송입니다. 프레임 15는 클라이언트의 새로운 세 번째 연결 요청을 표시하고 프레임 16 및 17은 다시 전송됩니다. 프레임(18)은 첫 번째 연결에 대한 연결 승인의 또 다른 재전송입니다. 프레임(19)은 프레임 20 및 21프레임이 있는 또 다른 연결 요청으로 재전송 및 프레임(22)은 네 번째 새로운 연결 요청이다. 마지막으로 프레임 23 STCP는 첫 번째 연결 요청을 포기하고 프레임 25의 재전송으로 두 번째 연결 요청에 대한 연결 승인을 통해 프레임 24에 따라 재설정을 보냅니다. 이 시점에서 나는 당신이 아이디어를 얻을 생각합니다.
STCP는 프레임 0에서 프레임 23까지 총 106.9초의 시간 아웃을 기록했습니다. 클라이언트가 시간 외 때 재설정을 보내지 않지만 두 번째 및 세 번째 연결 요청(프레임 11 ~ 프레임 15)의 시작 사이의 시간은 29.152초이고 세 번째와 네 번째(프레임 15및 19) 사이의 시간은 25.8초입니다. STCP보다 훨씬 빠릅니다.
이를 방지하기 위해 무엇을 할 수 있습니까?
가장 좋은 방법은 OpenVOS 17.1로 업그레이드하고 POSIX 라이브러리를 사용하여 응용 프로그램을 다시 컴파일하는 것입니다. 이렇게 하면 STCP가 응용 프로그램이 수락을 요청할 때까지 기다리지 않고 즉시 연결 승인을 보내기 때문에 문제가 발생하지 않습니다. 그러나 응용 프로그램의 다른 동작을 변경할 수 있으며 응용 프로그램의 신중한 테스트가 수행되어야 합니다. 업그레이드 및 재컴파일이 불가능한 경우
- 연결 승인을 삭제하는 상태 관리 네트워크 장치를 다시 구성하여 재설정으로 응답합니다. STCP가 재설정을 받으면 백로그 큐의 다음 연결 요청으로 이동합니다. 그 결과 상태 풀이 있는 장치에서 시간 으로 시간 별로 수행된 연결 요청이 큐에서 빠르게 배수됩니다. 추가 연결 승인은 클라이언트가 처리하여 자체 재설정을 보내거나 승인합니다.
- 서버 백로그 큐가 비워지때까지 클라이언트가 연결 요청을 하지 못하도록 중지합니다.
- 서버 응용 프로그램의 수신 소켓을 닫고 다시 엽니다. 일반적으로 응용 프로그램은 이 작업을 수행하도록 설계되지 않으므로 서버 응용 프로그램을 중지하고 다시 시작해야 합니다.
- 클라이언트의 시간 초과 값보다 짧은 값으로 syn_rcvd_abort 값을 구성합니다. analyze_system 요청set_stcp_param으로 값이 변경됩니다.
analyze_system -request_line 'set_stcp_param syn_rcvd_abort 15' -quit 오픈보스 릴리즈 17.0.2au, analyze_system 릴리즈 17.0.2au 현재 공정은 151, ptep 91530AC0, Noah_Davids.CAC tcp SYN_RCVD 시간 시간(syn_rcvd_abort)을 15로 변경 준비 완료 11:07:44위의 예에서 시간 초과는 15초로 설정됩니다. 유효한 값은 기본값(약 100초)을 사용하는 것을 의미하는 값이 0인 1에서 180 사이입니다.
이렇게 하면 단일 클라이언트가 백로그 큐에서 큰 빌드업을 만들지 못하게 됩니다. 값이 얼마나 짧게 되어야 하는지 많은 클라이언트가 동시에 서버에 액세스할 수 있는 데 따라 달라집니다. 이 방법의 문제는 모든 클라이언트와 모든 서버 포트에 영향을 미치며 한 포트 집합에 대해 하나의 값과 다른 포트 집합에 대해 하나의 값을 가질 수 없다는 것입니다. 또한 값이 너무 낮으면 타이머가 길어지면 일부 연결이 대기 시간 링크를 초과하여 실패할 수 있습니다. 최적의 가치를 선택하는 것은 과학보다 예술입니다.