TCP 수신 흐름 제어
정상적인 링크에서도 TCP가 일시 중단될 수 있는 이유는?
수신 시스템은 애플리케이션이 읽을 때까지 TCP 데이터를 저장합니다. 수신 공간이 없어지면 제로 윈도우를 알릴 수 있습니다. 송신 측은 이 제한을 준수하며 현재 윈도우 정보를 확인하기 위해 프로브를 보냅니다. 읽기가 이루어지면 윈도우가 다시 열릴 수 있지만, 프로브만으로는 멈춘 애플리케이션을 복구할 수 없습니다. 이는 일반적인 개념이며, 제품 측정값이나 고정된 복구 시간을 의미하지 않습니다.
버퍼
데이터는 애플리케이션이 읽기 전까지 시스템 버퍼에서 대기할 수 있습니다.
피드백
수신 측은 자신의 수신 한도를 송신 측에 알립니다.
다시 열림
읽기를 통해 수신 공간을 확보할 수 있으며, 프로브는 현재 윈도우 상태를 확인하는 데 도움이 됩니다.
어느 연결에서 어떤 엔드포인트가 제로 윈도우를 알리는지 기록합니다.
윈도우 변화를 애플리케이션 읽기 및 리소스 로그와 시간상으로 맞춰 분석합니다.
승인된 테스트에서 연속 읽기와 지연 읽기를 비교합니다.
선정 및 검증 체크리스트 — 펼치기
| 점검 항목 | 확인할 사항 | 검증 방법 |
|---|---|---|
| 접속 | 엔드포인트 및 방향 | 주소와 포트 쌍 기록 |
| 수신 측 | 애플리케이션이 읽는 중 | 애플리케이션 로그와 버퍼 상태 비교 |
| 복구 | 윈도우가 실제로 다시 열림 | 프로브, 윈도우 업데이트 및 재개된 데이터 전송의 상관관계 분석 |
장치가 온라인 상태이고 링크 표시등도 켜져 있지만, 송신 애플리케이션이 일시 중단된 것처럼 보일 수 있습니다. 패킷 캡처에는 제로 윈도우가 표시될 수 있습니다. 이것이 반드시 케이블 단선이나 스위치 대역폭이 0임을 의미하지는 않습니다. TCP 수신 측이 현재 수신 공간이 일시적으로 없다고 상대 측에 알리는 것일 수 있습니다. 그 이유를 이해하려면 네트워크 도착부터 시스템 버퍼링을 거쳐 애플리케이션 읽기까지의 경로를 살펴봐야 합니다.
네트워크 포트 도착이 여정의 끝은 아닙니다
산업용 게이트웨이, 시리얼 디바이스 서버 및 감시용 컴퓨터는 TCP를 사용하여 데이터를 교환할 수 있습니다. TCP는 순서가 보장되는 바이트 스트림을 제공하며, 해당 바이트가 온도 기록인지, 상태 메시지인지, 명령인지는 애플리케이션이 결정합니다. 이더넷이 프레임을 전달한 것은 전체 경로의 일부만 완료된 것입니다.
시스템은 TCP 데이터를 수신한 후 프로토콜에 따라 검사하고, 수용 가능한 데이터를 해당 연결의 수신 버퍼에 넣은 다음 애플리케이션이 읽기를 기다립니다. 우편물 수발실을 생각해 보세요. 접수대에 배달되었다고 해서 수신자가 소포를 열어 처리했다는 뜻은 아닙니다. 이 비유는 저장과 소비를 구분하기 위한 것이며, 실제 시스템은 시퀀스 번호, 윈도우 정보 및 메모리 상태를 관리합니다.
애플리케이션이 디스크 쓰기를 기다리거나, 이전 메시지를 처리하거나, 읽기 스레드를 스케줄링하지 않으면 데이터가 쌓일 수 있습니다. 정상적인 네트워크 카드와 스위치도 애플리케이션 대신 해당 바이트를 읽을 수는 없습니다. 포트 트래픽만 살펴보면 경로 끝에서 이루어지는 소프트웨어 처리를 놓칠 수 있습니다.
수신 윈도우는 어떤 용량을 알리나요?
TCP 헤더에는 수신 측이 현재 수용할 의사가 있는 데이터 범위를 알리는 윈도우 필드가 포함되어 있습니다. 이 범위는 버퍼링과 시스템 정책에 따라 달라집니다. 장치의 미사용 물리 메모리와 같을 필요는 없으며, 스위치 송신 큐의 공간을 뜻하는 것도 아닙니다. 제로 윈도우는 해당 방향에서 현재 새 데이터를 수신할 수 있는 윈도우가 없다는 뜻입니다.
게이트웨이가 수집 기록을 감시용 컴퓨터로 계속 전송한다고 가정해 보겠습니다. 해당 애플리케이션의 읽기 속도가 느려지면 시스템은 알리는 윈도우를 줄이다가 결국 제로 윈도우를 알릴 수 있습니다. 송신 측은 새 데이터를 무제한으로 보내는 대신 이 제한을 준수해야 합니다. 연결의 반대 방향은 독립적인 상태를 가지므로, 한쪽의 제로 윈도우만으로 양방향의 모든 교환이 중단되었다고 판단할 수는 없습니다.
캡처 도구는 원시 윈도우 값이나 윈도우 스케일 옵션을 반영한 계산값을 표시할 수 있습니다. 윈도우 스케일링은 연결 설정 과정에서 협상되며, 더 큰 수신 윈도우를 사용할 수 있게 합니다. 0이 아닌 값을 해석하기 전에 핸드셰이크와 표시 방식을 확인하세요. 0을 스케일링해도 결과는 0이므로, 일시 중단을 이해하기 위해 공식을 계산할 필요는 없습니다.
확인 응답과 윈도우 크기를 구분해야 하는 이유는?
TCP 확인 응답 번호는 수신 측이 다음에 기대하는 바이트의 시퀀스 번호를 나타내며, 송신 측이 확인 응답된 연속 데이터를 추적할 수 있게 합니다. 윈도우는 수신 측이 다음에 수용할 의사가 있는 범위를 나타냅니다. 하나는 이전 데이터가 어디까지 수신되었는지에 답하고, 다른 하나는 추가 수신에 관한 것입니다. 두 정보는 함께 표시되지만 목적은 서로 다릅니다.
수신 시스템은 제로 윈도우를 알리면서도 이미 수용한 데이터에 확인 응답을 보낼 수 있습니다. 해당 바이트는 애플리케이션이 읽지 않은 채 버퍼에 있을 수 있습니다. 또한 TCP 확인 응답만으로 업무 처리가 성공했다고 판단할 수는 없습니다. 데이터베이스 레코드가 커밋되었는지 또는 명령이 수락되었는지는 애플리케이션 수준의 응답이 필요합니다.
마찬가지로 확인 응답 번호가 변하지 않는다고 해서 곧바로 패킷 손실이 입증되는 것은 아닙니다. 방향, 윈도우 변화, 전송 내용 및 타이밍을 함께 살펴보세요. 한 장애 상황에서 재전송, 중복 확인 응답, 제로 윈도우가 함께 나타날 수 있지만, 캡처 도구의 색상 레이블 각각이 독립적인 진단 결과는 아닙니다.
제로 윈도우 이후 프로브를 보내는 이유는?
수신 애플리케이션이 다시 읽기 시작하면 시스템은 사용 가능한 윈도우를 알릴 수 있습니다. 이 업데이트는 전송 도중 손실될 수 있습니다. 수신 측은 이미 업데이트를 보냈다고 생각하는데 송신 측이 아무것도 보내지 않고 무한정 기다린다면, 양측이 서로를 기다리게 될 수 있습니다. TCP는 상대 측의 현재 윈도우 상태를 다시 확인하기 위한 제로 윈도우 프로빙을 규정합니다.
송신 측은 프로토콜 요구사항과 구현에 따라 프로브 전송 일정을 정하고, 수신 측은 현재 상태를 담아 확인 응답을 보냅니다. 프로브가 애플리케이션 데이터 전송의 재개를 의미하지는 않으며, 애플리케이션이 읽기를 시작했음을 입증하지도 않습니다. 알린 윈도우가 0인 동안에는 일반적인 새 데이터 전송이 계속 제한됩니다. 프로브 간격과 리소스 관리는 구현에 따라 달라지므로, 단일 캡처만으로 모든 제품에 적용되는 타이밍 매개변수를 정할 수는 없습니다.
프로브는 전혀 읽지 않는 애플리케이션의 정지 상태를 자동으로 해소할 수 없습니다. TCP는 연결 유지 및 프로빙 동작을 규정하지만, 운영체제 정책, 애플리케이션 타임아웃, 장치 리소스 한계도 결과에 영향을 미칩니다. 제로 윈도우 상태의 연결이 절대 종료되지 않는다거나 일정한 지연 후 항상 복구된다고 보장해서는 안 됩니다.
이더넷 PAUSE 프레임과는 어떻게 다른가요?
TCP 수신 윈도우는 연결의 엔드포인트 사이에서 이루어지는 전송 계층 피드백입니다. 이더넷 PAUSE 프레임은 인접 링크에서 전송을 일시 중단하도록 요청합니다. 스위치 큐의 혼잡과 호스트 애플리케이션의 느린 읽기는 모두 트래픽을 느리게 할 수 있지만, 발생 위치, 피드백 수신 대상 및 관찰 가능한 필드는 서로 다릅니다.
대역폭이 더 큰 스위치라도 소켓을 읽지 않는 애플리케이션의 복구를 보장할 수는 없습니다. 반대로 호스트의 수신 윈도우가 정상이라고 해서 중간 경로에 혼잡이 없다고 입증되는 것도 아닙니다. 인터페이스 오류와 폐기, 경로 부하는 호스트 버퍼, 프로세스 부하 및 애플리케이션 로그와 별도로 점검하세요.
시리얼 디바이스 서버에서는 시리얼 측 속도, TCP 연결 및 내부 버퍼링을 구분해야 합니다. 네트워크 제한 중에도 시리얼 바이트가 계속 들어오는지, 버퍼가 가득 차면 어떻게 되는지는 실제 모델, 펌웨어 및 흐름 제어 설정에 따라 달라집니다. TCP 지원만으로 무제한 시리얼 입력을 손실 없이 처리할 수 있다고 판단할 수는 없습니다.
장애 상황을 설명할 근거 수집
먼저 제로 윈도우를 알리는 연결과 방향을 식별하고, 엔드포인트 주소, 포트, 장치 및 애플리케이션 버전을 기록합니다. 핸드셰이크와 장애 전후의 트래픽을 살펴보세요. 하나의 시간축에서 수신 윈도우, 확인 응답 번호, 프로브 및 윈도우 재개방을 비교하세요. Zero Window 레이블의 스크린샷만 남기지 말고 캡처 자체를 보존하세요.
이 시간축을 수신 측 애플리케이션 로그와 맞춰 보세요. 애플리케이션이 읽고 있었나요? 디스크, 데이터베이스 작업 또는 다른 스레드를 기다리고 있었나요? 시스템 리소스에 이상이 있었나요? 송신 측이 계속 데이터를 생성한다면 송신 측 큐와 업무 처리 타임아웃도 살펴보세요. 적체를 송신 측으로 옮기는 것만으로는 근본적인 처리 문제가 해결되지 않습니다.
승인된 환경에서 통제된 소량 테스트를 수행하여 연속 읽기와 일시적으로 지연된 읽기를 비교하고, 알리는 윈도우가 그에 따라 변하는지 확인할 수 있습니다. 진단 레이블을 없애려고 중요한 생산 프로세스를 중단하거나 무작정 버퍼를 늘리거나 타임아웃을 비활성화하지 마세요. 버퍼링은 적체가 드러나는 시점을 늦출 수 있지만, 지속적인 처리 용량 부족은 여전히 해결해야 합니다.
각 문제를 올바른 단계에서 파악하기
제로 윈도우가 가장 직접적으로 나타내는 것은 수신 측이 알리는 수신 한도입니다. 이는 조사 방향을 제시하지만, 애플리케이션이 느려진 이유까지 입증하지는 않습니다. 네트워크 포트 도착, TCP 버퍼링, 애플리케이션 읽기, 업무 처리의 네 단계를 연결해 살펴보세요. 이러한 구분은 네트워크 경로, 시스템 리소스 또는 애플리케이션 로직 중 무엇을 점검할지 판단하는 데 도움이 됩니다.
FCTELE에서 공개한 관리형 산업용 스위치 정보는 산업용 이더넷 액세스 및 포워딩을 다룹니다. 실제 인터페이스, 관리 기능 및 지원 기능은 해당 제품 문서를 확인하세요. 이 가이드는 일반적인 TCP 동작을 특정 모델의 내부 설계로 제시하지 않으며, 버퍼 용량이나 복구 시간을 임의로 만들어 제시하지도 않습니다. 장비 선정과 시정 작업에는 엔드포인트 프로토콜 세부 정보, 제품 문서 및 현장 검증이 필요합니다.
참고 자료
RFC 9293: 제로 윈도우 프로빙;Microsoft: TCP 윈도우 및 스케일링;Linux TCP 인터페이스 및 버퍼링;FCTELE 관리형 산업용 스위치 정보. 일반적인 개념도이며, 제품 측정값이 아닙니다.
다음 중국어 기술 문서에서 번역: 중국어 원문 읽기.
자주 묻는 질문
제로 윈도우는 케이블 단선을 의미하나요?
아니요. 이는 TCP 엔드포인트가 알리는 수신 한도입니다. 경로뿐 아니라 애플리케이션의 읽기와 시스템 상태도 살펴보세요.
TCP 확인 응답은 업무 처리가 끝났음을 입증하나요?
아니요. 시스템이 수용한 바이트를 애플리케이션이 아직 소비하거나 처리하지 않았을 수 있습니다.
프로브로 멈춘 애플리케이션을 복구할 수 있나요?
아니요. 프로브는 현재 윈도우 정보를 확인합니다. 읽기 작업이 계속 막혀 있다면 별도로 조사해야 합니다.
범위 및 추가 읽을거리
일반적인 TCP 개념이며, 특정 제품의 회로나 측정된 타이밍을 나타내지 않습니다.
