대부분의 응용 프로그램 공급업체 설명서에는 응용 프로그램이 최적의 상태로 작동하도록 하기 위한 특정 TCP 및 이더넷 설정이 포함되어 있습니다. 일반적으로 이러한 설정은 최적의 IP 기반 스토리지 성능을 제공하기에 충분합니다.

이 기술을 통해 클라이언트는 발신자에게 데이터 전송을 일시적으로 중단할 것을 요청할 수 있습니다. 이 요청은 보통 수신자가 유입되는 데이터를 빠르게 처리할 수 없을 때 이루어집니다. 이와 동시에, 발신자에게 전송 중단을 요청할 때는 버퍼가 가득 차서 수신자가 패킷을 폐기할 때보다 중단 시간이 짧습니다. 이는 이제 오늘날 운영 체제에서 사용되는 TCP 스택의 사례가 아닙니다. 사실, 흐름 제어는 해결하는 문제보다 야기하는 문제가 더 많습니다.

최근 들어 이더넷 흐름 제어가 초래하는 성능 문제가 증가해 왔는데 이는 이더넷 흐름 제어가 물리적 계층에서 작동하기 때문입니다. 네트워크 구성에서 호스트 운영 체제에서 이더넷 흐름 제어 요청을 스토리지 시스템으로 전송하도록 허용하는 경우, 연결된 모든 클라이언트의 I/O가 중지됩니다. 단일 스토리지 컨트롤러가 처리하는 클라이언트의 수가 증가하면 이러한 클라이언트가 하나 이상의 흐름 제어 요청을 보낼 가능성이 높아집니다. 방대한 운영 체제 가상화를 구현한 고객 사이트에서 문제가 자주 관찰되었습니다.

NetApp 시스템의 NIC는 흐름 제어 요청을 수신하면 안 됩니다. 이러한 결과를 얻기 위해 사용하는 방법은 네트워크 스위치 제조업체에 따라 다릅니다. 대부분의 경우 이더넷 스위치의 흐름 제어는 으로 설정할 수 있습니다 receive desired 또는 `receive on`다시 말해, 흐름 제어 요청이 스토리지 컨트롤러로 전달되지 않습니다. 스토리지 컨트롤러의 네트워크 연결이 흐름 제어 비활성화를 허용하지 않는 경우도 있습니다. 이 경우 호스트 서버 자체의 NIC 구성 또는 호스트 서버가 연결되는 스위치 포트를 변경하여 클라이언트가 흐름 제어 요청을 전송하지 않도록 구성해야 합니다.

CPU와 네트워크 오버헤드를 줄여 1Gb 네트워크에서 성능을 개선하기 위해 점보 프레임이 사용되어온 것으로 나타났지만 대부분은 이점이 크지 않습니다.

10Gb 네트워크에서는 점보 프레임을 거의 의무적으로 사용해야 합니다. 대부분의 10Gb 구현에서 10Gb 표시에 도달하기 전에 점보 프레임이 없이는 초당 패킷 한계에 도달하기 때문입니다. 점보 프레임을 사용하면 OS, 서버, NIC, 스토리지 시스템에서 처리되는 패킷의 수가 줄어들었지만 크기가 더 커질 수 있기 때문에 TCP/IP 프로세싱의 효율성이 개선됩니다. NIC에 따라 달라지기는 하지만 상당한 성능 개선이 이루어집니다.

점보 프레임 구현의 경우 연결된 모든 장치가 점보 프레임을 지원해야 하며 MTU 크기가 완전히 일치해야 한다는 잘못된 인식이 일반적입니다 연결을 설정할 때 2개의 네트워크 엔드 포인트는 상호 허용되는 최대 프레임 크기를 협상합니다. 일반적인 환경에서 네트워크 스위치는 MTU 크기 9216으로 설정되며 NetApp 컨트롤러는 9000, 클라이언트는 9000과 1514의 혼합으로 설정됩니다. 9000의 MTU를 지원하는 클라이언트는 점보 프레임을 사용할 수 있으며 1514만 지원하는 클라이언트는 더 낮은 값을 협상할 수 있습니다.

이 방식의 문제는 완전히 스위칭된 환경에서는 자주 사용되지 않는다는 것입니다. 하지만 점보 프레임을 단편화하도록 강제 적용되는 중간 라우터가 없는 라우팅 환경에서는 주의하십시오.

3가지 설정, 즉 TCP 타임스탬프, 선택적 승인(Selective Acknowledgment, SACK), TCP 윈도우 확장이 잘못 구성되는 경우가 많습니다. 인터넷상의 오래된 문서들은 이러한 매개 변수를 하나 이상 비활성화하여 성능을 개선할 것을 권장합니다. CPU 용량이 훨씬 낮았고 가능할 때마다 TCP 처리 오버헤드를 줄여 이점을 얻을 수 있었던 몇 해 전에는 이 권장사항이 어느 정도 가치가 있었습니다.

그러나 최신 운영 체제에서 이러한 TCP 기능을 비활성화하면 일반적으로 어떤 이점도 얻을 수 없는 반면 성능 저하가 야기될 수도 있습니다. 성능 저하는 특히 가상화된 네트워킹 환경에서 발생할 가능성이 높은데 이들 기능이 패킷 손실을 효율적으로 처리하고 네트워크 품질을 바꾸는 데 필요하기 때문입니다