You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@trafficserver.apache.org by "Assaf Yaari (JIRA)" <ji...@apache.org> on 2013/08/06 17:28:48 UTC
[jira] [Commented] (TS-1424) Transparent proxy with
proxy.config.http.use_client_source_port==1 has problems if the client is
keep-alive and the origin server is not.
[ https://issues.apache.org/jira/browse/TS-1424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13730858#comment-13730858 ]
Assaf Yaari commented on TS-1424:
---------------------------------
Unfortunately the commit of this issue doesn't solve the issue. Tested with ATS 3.2.5 merged with commit 096f0308d7fba17a4ab820d5e88d2fe807b32bbc when ATS working in tr-full mode.
The issue can happen also when both client and server works in HTTP/1.1 and have connection keep-alive.
The server still might close the TCP connection when the connection is idle between HTTP transactions and the client connection still remain open.
When the client will try to send another request on that connection, the ATS fails to connect to the origin server (probably because of the TIME-WAIT issue described above) and then it responds with status 502:
-- State Machine Id: 349
[Aug 6 18:54:39.295] Server {0x2b7ee35ef700} DEBUG: (http_seq) [HttpTransact::HandleResponse] Response not valid
[Aug 6 18:54:39.295] Server {0x2b7ee35ef700} DEBUG: (http_trans) [handle_response_from_server] (hrfs)
[Aug 6 18:54:39.295] Server {0x2b7ee35ef700} DEBUG: (http_trans) [5] failed to connect [5] to 173.194.112.232
[Aug 6 18:54:39.295] Server {0x2b7ee35ef700} DEBUG: (http_trans) [retry_server_connection_not_open] attempts now: 6, max: 6
[Aug 6 18:54:39.295] Server {0x2b7ee35ef700} DEBUG: (http_trans) [handle_response_from_server] Error. Retrying...
[Aug 6 18:54:39.295] Server {0x2b7ee35ef700} DEBUG: (http) [349] State Transition: ORIGIN_SERVER_OPEN -> ORIGIN_SERVER_OPEN
[Aug 6 18:54:39.295] Server {0x2b7ee35ef700} DEBUG: (http_track) entered inside do_http_server_open
[Aug 6 18:54:39.295] Server {0x2b7ee35ef700} DEBUG: (http) [349] open connection to s.ytimg.com: 173.194.112.232:80
[Aug 6 18:54:39.296] Server {0x2b7ee35ef700} DEBUG: (http_seq) [HttpSM::do_http_server_open] Sending request to server
[Aug 6 18:54:39.296] Server {0x2b7ee35ef700} DEBUG: (http) calling netProcessor.connect_re
[Aug 6 18:54:39.296] Server {0x2b7ee35ef700} DEBUG: (http) [349] [HttpSM::main_handler, NET_EVENT_OPEN_FAILED]
[Aug 6 18:54:39.296] Server {0x2b7ee35ef700} DEBUG: (http_track) entered inside state_http_server_open
[Aug 6 18:54:39.296] Server {0x2b7ee35ef700} DEBUG: (http) [349] [&HttpSM::state_http_server_open, NET_EVENT_OPEN_FAILED]
[Aug 6 18:54:39.296] Server {0x2b7ee35ef700} DEBUG: (http_trans) [HttpTransact::HandleResponse]
[Aug 6 18:54:39.296] Server {0x2b7ee35ef700} DEBUG: (http_seq) [HttpTransact::HandleResponse] Response received
[Aug 6 18:54:39.296] Server {0x2b7ee35ef700} DEBUG: (http_trans) [ink_cluster_time] local: 1375804479, highest_delta: 0, cluster: 1375804479
[Aug 6 18:54:39.296] Server {0x2b7ee35ef700} DEBUG: (http_trans) [HandleResponse] response_received_time: 1375804479
+++++++++ Incoming O.S. Response +++++++++
-- State Machine Id: 349
[Aug 6 18:54:39.296] Server {0x2b7ee35ef700} DEBUG: (http_seq) [HttpTransact::HandleResponse] Response not valid
[Aug 6 18:54:39.296] Server {0x2b7ee35ef700} DEBUG: (http_trans) [handle_response_from_server] (hrfs)
[Aug 6 18:54:39.296] Server {0x2b7ee35ef700} DEBUG: (http_trans) [handle_response_from_server] Error. No more retries.
[Aug 6 18:54:39.296] Server {0x2b7ee35ef700} DEBUG: (http_trans) [handle_server_connection_not_open] (hscno)
[Aug 6 18:54:39.296] Server {0x2b7ee35ef700} DEBUG: (http_seq) [HttpTransact::handle_server_connection_not_open]
[Aug 6 18:54:39.296] Server {0x2b7ee35ef700} DEBUG: (http_trans) [ink_cluster_time] local: 1375804479, highest_delta: 0, cluster: 1375804479
[Aug 6 18:54:39.296] Server {0x2b7ee35ef700} DEBUG: (http) [349] hostdb update marking IP: 173.194.112.232:80 as down
[Aug 6 18:54:39.296] Server {0x2b7ee35ef700} DEBUG: (http) server info = 173.194.112.232:80
[Aug 6 18:54:39.296] Server {0x2b7ee35ef700} DEBUG: (http_trans) [WUTS code generation] Hit/Miss: 49, Log: 97, Hier: 50, Status: 805
+++++++++ Proxy's Response 2 +++++++++
-- State Machine Id: 349
HTTP/1.1 502 internal error - server connection terminated
Date: Tue, 06 Aug 2013 15:54:39 GMT
Connection: keep-alive
A simple reproduce of this, is to work in full transparent mode with use_client_source_port set to '1'. Surf to www.youtube.com, wait ~15sec and hit the refresh button. The client tries to reuse the existing connections but get back 502.
What is desired, is to close the client connection whenever the origin server close its connection.
> Transparent proxy with proxy.config.http.use_client_source_port==1 has problems if the client is keep-alive and the origin server is not.
> -----------------------------------------------------------------------------------------------------------------------------------------
>
> Key: TS-1424
> URL: https://issues.apache.org/jira/browse/TS-1424
> Project: Traffic Server
> Issue Type: Bug
> Environment: 3.2 with transparent (TProxy) interception + proxy.config.http.use_client_source_port = 1
> Reporter: B Wyatt
> Assignee: Alan M. Carroll
> Fix For: 3.3.2
>
>
> As keep-alive is hop-to-hop ATS will happily support client keep-alive in instances where an Origin Server terminates the connection after each transaction.
> However, when using proxy.config.http.use_client_source_port this behavior can cause some sites to break.
> When the client is kept alive, subsequent requests are made rapidly and with the same 4-tuple for addressing. Since ATS is trying to match the 4-tuple (due to proxy.config.http.use_client_source_port) it enters a 3-way race between:
> # the FIN, FIN/ACK packets being exchanged with the origin server and the new request packets from the client. If the OS is slow it is possible that ATS will attempt to reconnect with the same port/address before the connection is legitimately closed.
> # Kernel timers for PAWS and recently closed sockets. This is different (and much shorter) than the time-wait state and there is no way to disable it
> # Everything working out just fine and the connection establishing like normal
> The best repro case I've seen is a slow origin server that serves pages in <frame> tags from the same host but does not support keep-alive (http://publib.boulder.ibm.com/infocenter/lnxinfo/v3r0m0/index.jsp for instance)
> It is possible that simply respecting a servers keep-alive settings when using proxy.config.http.use_client_source_port would work as the original client would change the 4-tuple address for its next connection.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira