TCP/IP 관련 문제
특정 프로그래밍 기술은 TCP/IP 구현과 연결된 성능 문제가 있습니다. 이러한 성능 문제는 TCP/IP가 비효율적이거나 성능 병목 상태임을 시사하지 않습니다. 오히려 이러한 문제는 TCP/IP 작업이 이해되지 않을 때 표시됩니다.
다음 문제는 TCP/IP 작업 및 네트워크 애플리케이션 개발 선택 항목의 조합으로 인해 성능이 저하되는 일반적인 시나리오를 식별합니다.
연결이 많은 애플리케이션.
일부 애플리케이션은 각 트랜잭션에 대해 새 TCP 연결을 인스턴스화합니다. TCP 연결 설정에는 시간이 걸리고, 추가 RTT가 기여하며, 느린 시작이 적용됩니다. 또한 닫힌 연결에는 시스템 리소스를 사용하는 TIME-WAIT가 적용됩니다.
연결이 많은 애플리케이션은 일반적으로 쉽게 만들 수 있기 때문입니다. 테스트 및 오류 처리는 매우 간단합니다. 영구 연결에서 오류를 감지하는 데 상당한 코드와 노력이 소요될 수 있으므로 완료되지 않는 경우가 있습니다.
TCP 연결을 다시 사용하여 이 상황을 해결합니다. 트랜잭션이 여러 연결을 통해 멀티플렉싱되지 않는 한 TCP 연결을 통해 직렬화가 발생할 수 있습니다. 이 방법을 사용하는 경우 연결 수를 2개로 제한해야 하며 애플리케이션 계층 프레이밍 및 고급 오류 처리가 필요합니다.
길이가 0인 송신 버퍼 및 차단 송신
setsockopt 함수를 사용하여 송신 버퍼(SO_SNDBUF)를 0으로 설정하여 버퍼링을 해제하는 것은 디스크 캐싱을 끄는 것과 비슷합니다. 송신 버퍼를 0으로 설정하고 차단 송신을 발급할 때 애플리케이션은 200밀리초 지연된 승인에 도달할 확률이 50%입니다.
모든 네트워크 환경에 미치는 영향을 고려하지 않는 한 송신 버퍼링을 해제하지 마세요. 한 가지 예외: 겹치는 I/O를 사용하는 스트리밍 데이터는 송신 버퍼를 0으로 설정해야 합니다.
Send-Send-Receive 프로그래밍 모델.
송신 수신을 수행하도록 애플리케이션을 구성하면 Nagle 알고리즘이 발생할 가능성이 높아지며 이로 인해 RTT+200ms가 지연됩니다. 마지막 전송이 TCP 최대 세그먼트 크기(MSS, 단일 데이터그램의 최대 데이터)보다 작은 경우 Nagle 알고리즘이 발생할 수 있습니다. MSS는 매우 큰 값(IPv4의 경우 64K, IPv6에서는 더 큰 값)일 수 있으므로 일반적으로 작은 MSS를 계산하지 마세요. 더 나은 옵션은 WSASend 또는 memcpy 함수를 사용하여 두 송신을 단일 송신으로 결합하는 것입니다.
많은 수의 동시 연결.
특수 용도 애플리케이션을 제외하고 동시 연결은 2개를 초과하면 안 됩니다. 두 개의 동시 연결을 초과하면 리소스가 낭비됩니다. 좋은 규칙은 최대 4개의 수명이 짧은 연결 또는 대상당 2개의 영구 연결을 갖는 것입니다.
관련 항목