신뢰할 수 있는 세션을 위한 최선의 방법

아티클
04/07/2023

이 항목에서는 신뢰할 수 있는 세션을 위한 최선의 방법에 대해 설명합니다.

MaxTransferWindowSize 설정

WCF(Windows Communication Foundation)의 신뢰할 수 있는 세션은 전송 창을 사용하여 클라이언트 및 서비스에서 메시지를 보관합니다. 구성 가능한 속성 MaxTransferWindowSize는 전송 창이 보관할 수 있는 메시지 수를 나타냅니다.

발신자의 경우 이 값은 전송 창이 승인을 기다리는 동안 보관할 수 있는 메시지 수를 나타내고, 수신자의 경우 서비스에 대해 버퍼링할 수 있는 메시지 수를 나타냅니다.

적절한 크기를 선택하면 네트워크의 효율성과 서비스의 최적 용량에 영향을 줄 수 있습니다. 다음 단원에서는 이 속성에 대한 값을 선택할 때 고려할 사항 및 그 값이 주는 영향에 대해 자세하게 설명합니다.

기본 전송 창 크기는 8개 메시지입니다.

네트워크의 효율적인 사용

이 컨텍스트에서 용어 ‘네트워크’는 클라이언트(발신자)와 서비스(수신자) 간 통신의 기본으로 사용되는 모든 것을 의미합니다. 여기에는 SOAP 라우터 또는 HTTP 프록시/방화벽을 비롯한 전송 연결 및 중간 매개자 또는 중간 브리지가 포함됩니다.

네트워크를 효율적으로 사용하려면 네트워크 용량을 최대한 사용합니다. 네트워크를 통해 초당 전송할 수 있는 데이터 양(‘데이터 전송 속도’) 및 발신자에서 수신자로 데이터를 전송하는 데 걸리는 시간(‘대기 시간’)은 네트워크를 효율적으로 사용하는 데 영향을 줍니다.

발신자의 경우 MaxTransferWindowSize 속성은 전송 창이 승인을 기다리는 동안 보관할 수 있는 메시지 수를 나타냅니다. 네트워크 대기 시간이 긴 경우 발신자가 신속하게 응답하고 네트워크를 효율적으로 사용하려면 전송 창 크기를 늘려야 합니다.

예를 들어, 발신자가 데이터 전송 속도를 지속적으로 유지하는 경우에도 발신자와 수신자 간에 여러 매개자가 있거나 데이터가 손실 매개자 또는 네트워크를 통과해야 하는 경우 대기 시간이 길어질 수 있습니다. 따라서 발신자는 새 메시지를 네트워크를 통해 보내는 것을 허용하기 전에 전송 창의 메시지에 대한 승인을 기다려야 합니다. 대기 시간이 긴 버퍼가 적을수록 네트워크 사용 효율성이 떨어집니다. 반면에 전송 창 크기가 너무 클 경우 서비스가 클라이언트에서 전송한 데이터의 빠른 전송 속도를 따라가야 하기 때문에 서비스에 영향을 줄 수 있습니다.

용량에 맞게 서비스 실행

네트워크를 효율적으로 사용하려면 이론적으로 최적의 용량에 맞게 서비스를 실행해야 합니다. 수신자의 전송 창 크기 속성은 수신자가 버퍼링할 수 있는 메시지 수를 나타냅니다. 이 메시지 버퍼링은 네트워크 흐름 제어에 도움을 줄 뿐만 아니라 서비스를 최대 용량으로 실행할 수 있도록 합니다. 예를 들어, 버퍼가 1개 메시지이고 메시지가 서비스가 처리할 수 있는 속도보다 빨리 도착하는 경우 네트워크에서는 메시지를 삭제하고 용량을 불필요하게 사용하거나 충분히 사용하지 않을 수 있습니다.

버퍼를 사용하면 메시지를 동시에 수신하고 버퍼링하면서 이전에 수신된 메시지를 처리하기 때문에 서비스 가용성이 향상됩니다.

발신자 및 수신자 모두에 대해 동일한 MaxTransferWindowSize를 사용하는 것이 좋습니다.

흐름 제어 사용

‘흐름 제어’는 발신자와 수신자가 서로 속도를 맞출 수 있는 메커니즘입니다. 즉, 메시지가 생성되는 속도에 따라 메시지를 사용하고 작업을 수행합니다. 클라이언트 및 서비스의 전송 창 크기는 발신자와 수신자가 적절한 동기화 창 내에 있도록 합니다.

WCF 클라이언트와 WCF 서비스 간에 신뢰할 수 있는 세션을 사용하는 경우 속성 FlowControlEnabled를 true로 설정하는 것이 좋습니다.

MaxPendingChannels 설정

서로 다른 클라이언트와의 신뢰할 수 있는 세션 통신을 사용하는 서비스를 작성하는 경우 동시에 여러 클라이언트가 서비스에 대해 신뢰할 수 있는 세션을 설정할 수 있습니다. 이 경우 서비스 응답은 MaxPendingChannels 속성에 따라 달라집니다.

발신자가 수신자에 대해 신뢰할 수 있는 세션 채널을 만드는 경우 발신자와 수신자 간의 핸드셰이크에서 신뢰할 수 있는 세션이 설정됩니다. 신뢰할 수 있는 세션이 설정된 후 채널은 서비스에서 허용할 수 있도록 보류 중인 채널 큐에 저장됩니다. MaxPendingChannels 속성은 이 상태에 있을 수 있는 채널 수를 나타냅니다.

서비스가 더 많은 채널을 허용할 수 없는 상태에 있을 수 있습니다. 큐가 가득 찬 경우 신뢰할 수 있는 세션 설정 시도가 거부되므로 클라이언트는 다시 시도해야 합니다.

또한 큐에 있는 보류 중인 채널이 장시간 동안 큐에 남아 있을 수 있습니다. 이 과정에서 신뢰할 수 있는 세션에 대한 비활성 시간 제한이 발생하여 채널이 오류 상태로 전환될 수 있습니다.

여러 클라이언트를 동시에 제공하는 서비스를 작성하는 경우 해당 요구 사항에 적합한 값을 설정해야 합니다. MaxPendingChannels 속성에 대해 너무 높은 값을 설정하면 작업 집합에 영향을 줍니다.

MaxPendingChannels의 기본값은 4개의 채널입니다.

신뢰할 수 있는 세션 및 호스팅

웹에서 신뢰할 수 있는 세션을 사용하는 서비스를 호스트하는 경우 다음과 같은 중요한 고려 사항이 있습니다.

신뢰할 수 있는 세션은 상태 저장 세션이며 상태는 AppDomain에 유지됩니다. 따라서 신뢰할 수 있는 세션의 일부인 모든 메시지는 동일한 AppDomain에서 처리되어야 합니다. 팜 또는 가든의 크기가 1개 노드보다 큰 웹 팜 및 웹 가든은 이러한 제약 조건을 보장할 수 없습니다.
이중 HTTP 채널을 사용하는 신뢰할 수 있는 세션(예를 들어 WsDualHttpBinding 사용)은 기본값인 클라이언트당 2개 HTTP 연결 수보다 많은 연결이 필요할 수 있습니다. 즉, 동시 애플리케이션 및 프로토콜 메시지가 주어진 시간에 각 방향으로 전송될 수 있으므로 신뢰할 수 있는 이중 세션에는 각 방향에 최대 2개의 연결이 필요할 수 있습니다. 특정 조건 하에서 서비스의 메시지 교환 패턴에 따라 이중 HTTP 및 신뢰할 수 있는 세션을 사용하는 웹 호스팅 서비스에 교착 상태가 발생할 수 있습니다. 클라이언트당 허용 가능한 HTTP 연결 수를 늘리려면 다음을 관련 구성 파일(예를 들어 해당 서비스의 web.config)에 추가합니다.
```
<configuration>
  <system.net>
    <connectionManagement>
      <add name="*" maxconnection="4" />
    </connectionManagement>
  </system.net>
</configuration>
```
maxconnection 특성의 값은 필요한 연결의 수입니다. 이 경우 최솟값은 4개의 연결이어야 합니다.

다음을 통해 공유