This is our old Q&A Site. Please post any new questions and answers at

I have a Java-based client that uses HTTPS to talk -- over the Internet -- with an Apache web server. When this client is run behind my firewall, some HTTP requests (about 5% of them) take far too long to complete (e.g. 15 seconds instead of the normal 20 milliseconds). Some requests, like ~750 KB file uploads, seemingly never complete.

When the firewall is bypassed, everything works fine.

It's usually HTTP POST/PUT messages with large (32k+) payloads in the message body that encounter trouble, but sometimes small messages with no payload have problems. I am trying to use Wireshark to understand the pathology of the problem, but I am relatively inexperienced with debugging SSL/TLS. I am able to decrypt the communication, but all that has allowed me to do is isolate a conversation which had trouble:

alt text

I'm not quite sure how to proceed here. What should I look for? Are the Unknown Records of concern? What's triggering the retransmissions? Do I need to do a simultaneous packet capture at the firewall as well? Any advice or insight is appreciated. Thanks!

asked 22 Mar '12, 17:08

Mike%20Clark's gravatar image

Mike Clark
accept rate: 100%

edited 02 Apr '12, 08:58

It turned out to be a duplex mismatch between our firewall's NIC and a router's NIC. The firewall NIC was set to autonegotiate, and the router's NIC was set to full duplex. After setting both to full duplex, the problem went away.

Because one of the key symptoms for diagnosing duplex mismatch is packet loss, it was important to take a capture at both ends of the conversation to see which packets were arriving and which weren't. After analyzing packet captures from both ends of the conversation, I found that the captured behavior matched very closely with Wikipedia's description of the TCP symptoms of duplex mismatch:

The lost packets force the TCP protocol to perform error recovery, but the initial (streamlined) recovery attempts fail because the retransmitted packets are lost in exactly the same way as the original packets. Eventually, the TCP transmission window becomes full and the TCP protocol refuses to transmit any further data until the previously-transmitted data is acknowledged. This, in turn, will quiesce the new traffic over the connection, leaving only the retransmissions and acknowledgments. Since the retransmission timer grows progressively longer between attempts, eventually a retransmission will occur when there is no reverse traffic on the connection, and the acknowledgment are finally received. This will restart the TCP traffic, which in turn immediately causes lost packets as streaming resumes.

As mentioned in the article, a key TCP symptom that indicates duplex mismatch is the TCP connection devolving into almost entirely delayed retransmissions and ACKs, resulting in a TCP connection that is "alive" and "active" but transmitting data at an incredibly slow rate.

permanent link

answered 28 Mar '12, 13:02

Mike%20Clark's gravatar image

Mike Clark
accept rate: 100%

edited 28 Mar '12, 16:49

Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here



Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text]( "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:


question asked: 22 Mar '12, 17:08

question was seen: 5,251 times

last updated: 02 Apr '12, 08:58

p​o​w​e​r​e​d by O​S​Q​A