-
Notifications
You must be signed in to change notification settings - Fork 9.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Delayed sending request #8411
Comments
Have no idea why there was a delay. But noticed that the [SYN] packet from source to destination, which initiates handshake, was missing in your wireshark log. By the way, how did you record the request time? This information might help with pinpointing the issue. Thanks. |
I suspect the delay is waiting for an IPv4 dns response. You can confirm that by decorating DNS and printing out when it returns. |
@Endeavour233 Thank you for your reply. Before requesting, my program will output the log to logger.info, so I can clearly see the time when this logic is entered. To find the corresponding request from the message. Regarding the [SYN] request, I'm sorry, it should be that my NPM mirroring traffic is not mirrored. But this should not affect it. Are there any other ways to look at this issue? |
@yschimke Hello, like the message I mentioned above, the entire process of dns query should only take about 10ms. |
If you record the events with an event listener, it should confirm that. That's usually easier to tie back to OkHttp stages than wireshark. |
@yschimke Can you provide guidance or send relevant documents? |
@yschimke Thank you, I will add debugging |
@yschimke At the same time, what if the delay in the secureConnectEnd stage is high? |
I was thinking that [SYN] marks the initialization of handshake, and since it was missing in the log, we could not assume that there was a delay as large as 800ms between DNS return and handshake initialization. Anyway, after using eventlistener to track the request, hopefully we'll find out where the delay happens~ |
I'll update the progress~ I have added EventListener, below the output of EventListener:
I see that the time spent is all in the secureConnectEnd phase. I see that the time is spent in the secureConnectEnd phase. |
From my view, your last 2 logs both indicated that most time was spent on TLS handshake(as per my understanding of okhttp, when |
Is this happening on every request? or just the first one with each OkHttpClient instance? If it's only on the first, then TLS initialisation is probably a factor. |
Test on Android emulator with two requests, forced to reconnect.
Similar time, so maybe it's just the handshake. Going to close this out, as expected. |
@yschimke @Endeavour233 receive. Thank you, it looks like a server-side problem |
My Env:
okhttp version is 4.9.1
java version is Java(TM) SE Runtime Environment (build 1.8.0_333-b02)
Problems encountered:
I'm using okhttp to make requests to the website, GET&POST methods.
I am using okhttp to access a domain name website (https://test-rights-platform.e-buy.com). My program will record the request time. I found that in some cases, the delay in requesting this website is It will be extremely large (nearly 1 second), but I can ensure that my network outgoing network is normal.
In response to the above situation, I deliberately captured the data packets when this happened. I found that after obtaining the IP address returned by DNS, the program waited nearly 800ms before initiating the TCP three-way handshake. I understand that when dns returns the IP address, it should immediately initiate the TCP three-way handshake instead of waiting for a while before handshaking.
I'm not sure about the entire process of okhttp requesting a domain name. Is this normal? I have repeatedly checked my network environment, there is no packet loss, and the network outgoing delay is normal. But this problem still occurs occasionally, or there is something wrong with my okhttp usage or configuration.
Hope to get your reply~
Datagram
After completing the DNS query, it waited nearly 800ms before sending out the tcp syn packet. I don't know if this is controlled by okhttp. .
The text was updated successfully, but these errors were encountered: