(TCP)수신 측인 회원사에서 데이터를 처리하는 과정에서 딜레이가 발생하면(?)

REQUEST)
수신 측인 회원사에서 데이터를 처리하는 과정에서 딜레이가 발생하면(?)

RESPONSE)
TCP 통신에서 거래소가 증권 정보 데이터를 일방적으로 송신하고, 수신 측인 회원사에서 데이터를 처리하는 과정에서 딜레이가 발생하면 다음과 같은 현상이 벌어질 수 있습니다.

1. TCP 윈도우 크기 축소 (Flow Control)

• TCP는 수신 측의 데이터 처리 속도에 따라 송신 속도를 조절합니다.
• 회원사 쪽에서 데이터를 처리하지 못하고 수신 버퍼가 꽉 차면, 수신 측은 송신 측에 윈도우 크기를 줄이라는 신호를 보냅니다.
• 송신 측에서는 이를 인지하고 데이터 송신 속도를 줄입니다.
• 최악의 경우, 수신 측이 윈도우 크기 = 0 신호를 보내면 송신 측은 데이터를 전송하지 못하고 대기 상태에 빠집니다.

---

2. 송신 측의 데이터 큐 축적

• 회원사에서 데이터를 처리하지 못해 ACK 패킷이 늦게 도착하면, 송신 측의 데이터 큐에 전송 대기 데이터가 점점 쌓이게 됩니다.
• 이로 인해 송신 측의 메모리 사용량 증가 또는 송신 애플리케이션의 지연 문제가 발생할 수 있습니다.
• 데이터 큐가 한계에 도달하면 송신 애플리케이션은 데이터를 더 이상 보내지 못하거나 연결이 끊어질 수 있습니다.

---

3. 연결 끊김 가능성 (Timeout)

• TCP는 패킷 전송 후 수신 측으로부터 ACK를 받지 못하면 재전송을 시도합니다.
• 재전송을 여러 번 시도해도 응답이 없으면, 연결이 타임아웃되어 종료될 수 있습니다.
• 특히 네트워크가 불안정하거나 회원사 시스템이 과부하 상태라면 이런 상황이 빈번히 발생할 수 있습니다.

---

4. 증권 정보의 지연 전달

• 회원사가 데이터를 실시간으로 처리하지 못하면 증권 정보가 적시에 전달되지 않을 수 있습니다.
• 이는 주식 매매와 같은 실시간 거래에 큰 영향을 미쳐 시장의 신뢰성을 해칠 가능성이 있습니다.

---

해결 방안

1. 회원사 데이터 처리 속도 최적화
   • 데이터 처리 로직을 개선하거나 병렬 처리 등을 통해 처리 속도를 높입니다.
2. TCP 윈도우 크기 및 버퍼 관리 최적화
   • 수신 측에서 TCP 버퍼 크기를 늘리거나 송신 측에서 데이터 송신 속도를 조절합니다.
3. UDP 프로토콜 사용 검토
   • TCP의 신뢰성 보장을 위한 제어 메커니즘이 문제라면, 신뢰성보다는 속도가 중요한 경우 UDP를 사용하는 것도 고려할 수 있습니다.
4. 애플리케이션 레벨의 큐 처리
   • 데이터 처리 지연이 발생하더라도 송수신 사이에 임시 버퍼(큐)를 두어 데이터를 효율적으로 관리합니다.

이와 같은 현상은 네트워크 환경, 시스템 성능, 애플리케이션 설계 방식에 따라 다르게 나타날 수 있으니, 구체적인 원인 분석이 필요합니다.