이 단원에서는 신뢰할 수 있는 세션을 위한 최선의 방법에 대해 설명합니다.
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 사용)은 클라이언트당 기본 HTTP 연결 수(2)보다 많은 연결이 필요할 수 있습니다. 즉, 동시 응용 프로그램 및 프로토콜 메시지가 주어진 시간에 각 방향으로 전송될 수 있으므로 신뢰할 수 있는 이중 세션에는 각 방향에 최대 2개의 연결이 필요할 수 있습니다. 이는 특정 조건 하에서 서비스의 메시지 교환 패턴에 따라 이중 HTTP 및 신뢰할 수 있는 세션을 사용하는 웹 호스팅 서비스에 교착 상태가 발생할 수 있음을 의미합니다. 클라이언트당 허용 가능한 HTTP 연결 수를 늘리려면 다음을 관련 구성 파일(예를 들어 해당 서비스의 web.config)에 추가합니다.
<configuration>
<system.net>
<connectionManagement>
<add name = "*" maxconnection = "XX" />
</connectionManagement>
</system.net>
</configuration>
여기서 “XX”는 필요한 연결 수입니다. 이 경우 최소값은 4이어야 합니다.