0

I am trying to understand the differences between NetScaler Monitor types HTTP-ECV and TCP-ECV and used case scenarios? I want to understand the rationale behind using these monitors since they both use the send string and expects a response from the server. When do one need to use TCP-ECV or HTTP-ECV?

current_me
  • 35
  • 1
  • 4

2 Answers2

0

Maybe you should begin by indentifying your needs before chosing monitor types. The description of these monitors is pretty self-descriptive.

tcp-ecv:

Specific parameters: send [””] - is the data that is sent to the service. The maximum permissible length of the string is 512 K bytes. recv [””] - expected response from the service. The maximum permissible length of the string is 128 K bytes.
Process: The Citrix ADC appliance establishes a 3-way handshake with the monitor destination. When the connection is established, the appliance uses the send parameter to send specific data to the service and expects a specific response through the receive parameter. Different servers send different sizes of segments. However, the pattern must be within 16 TCP segments.

http-ecv:

Specific parameters: send [””] - HTTP data that is sent to the service; recv [””] - the expected HTTP response data from the service
Process: The Citrix ADC appliance establishes a 3-way handshake with the monitor destination. When the connection is established, the appliance uses the send parameter to send the HTTP data to the service and expects the HTTP response that the receive parameter specifies. (HTTP body part without including HTTP headers). Empty response data matches any response. Expected data may be anywhere in the first 24K bytes of the HTTP body of the response.

As for web service monitoring (is that's what you need?), if you try to ensure some HTTP headers is present in a response, then use tcp-ecv. For HTML body checks use http-ecv.

Mikhail Tumashenko
  • 1,683
  • 2
  • 21
  • 28
  • tcp-ecv won't use HTTP headers. The system calls tcp send(). The tcp recv() call is normally used only on a connected socket. – Paul Dawson Dec 18 '19 at 14:53
  • Thanks so much for the response. @Mikhail an elaboration on your comment would be deeply appreciated. Thanks – current_me Dec 20 '19 at 04:22
  • There's no need for tcp-ecv to use HTPP headers, but tcp recv() will show them and I can't see any problem to perform any checks. – Mikhail Tumashenko Dec 23 '19 at 13:00
0

TCP-ECV - Layer 4 check - If you want to determine that a TCP port/socket is open and you are happy with the service being marked as up as a result of the completion of a TCP 3-way handshake and TCP send() data being sent expecting TCP recv() response then use the TCP-ECV. This is simply a TCP layer 4 check. It has no application awareness.

HTTP-ECV - Layer 5 check - If a simple TCP check is not enough and you want to send HTTP protocols message over the TCP connection once it is established then use the HTTP-ECV. This will send an HTTP protocol control message over the TCP connection and will wait for an HTTP response message back. Typically you would configure the response to expect a 200 OK as a success and a 404/503 as a failure.

Paul Dawson
  • 1,332
  • 14
  • 27
  • Thank you for the response. So if I understand you right, the only difference is that one happens at layer 4(TCP-ECV) and the other at layer 5? Because I can see that they all send a GET request which challenges the server for a response. – current_me Dec 20 '19 at 04:21
  • Yes, the TCP-ECV monitor can be used to send strings to non HTTP services, which is why the documentation details the permitted length of the string which can be sent in the monitor. If there is a `GET` in the send string of the TCP-ECV monitor then effectively you are doing the same as the HTTP-ECV, but you will be limited by the constraints mentioned. – Paul Dawson Dec 20 '19 at 08:16