у меня есть Линод сервер, который не будет возвращать случайные запросы GET моему обычному интернет-провайдеру (но никогда не застревает на одном и том же каждый раз). Если я переключусь на провайдера или использую Opera VPN, все работает хорошо.
Линод говорит, что им все в порядке. Ресурсы сервера в порядке (это сервер разработки, который в настоящий момент используется только для тестирования, поэтому очень небольшой трафик и накладные расходы). Говорят уточнить у моего провайдера. Мой интернет-провайдер говорит, что все выглядит хорошо, но они попросят инженеров взглянуть на это.
Поскольку я ожидаю от интернет-провайдера ответа «мы ничего не нашли», я пытаюсь найти объективные доказательства того, что происходит, благодаря своим очень ограниченным знаниям в области диагностики. Я отряхнул Wireshark и приступили к диагностике.
Если я использую проблемного интернет-провайдера, с точки зрения браузера это немного случайно. Иногда страница загружается нормально, иногда - нормально, но другие ресурсы не загружаются (css, js, jpeg и т. Д.). Иногда сама страница не загружается и остается «загружающейся» бесконечно без ответа сервера.
http.time > 1 в Wireshark подтвердил, что проблема не столько в тайм-аутах или длительном времени загрузки, а в том, что запрос либо загружается, либо нет.
В моих заголовках нет ничего необычного, например:
GET /theme/css/style.css HTTP/1.1
Host:site.com
Accept:text/css,*/*;q=0.1
Accept-Language:en-ie
Accept-Encoding:gzip, deflate
Connection:keep-alive
Pragma:no-cache
User-Agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_4) AppleWebKit/603.1.30 (KHTML, like Gecko) Version/10.1 Safari/603.1.30
Referer:http%3a//site.com/section/
DNT:1
Cache-Control:no-cache
Когда я снимаю с Wireshark, Я не вижу особой обратной связи, когда запрос останавливается в браузере. Однако в последний раз, когда я попытался это сделать, я получил повторный запрос:
localhost server TCP 66 [TCP Retransmission] 61162 → 80 [FIN, ACK]
транслировать каждую минуту, пока не закончится [RST, ACK] в конце, хотя браузер по-прежнему показывал, что страница зависает при загрузке.
Я пробовал писать подробный текст curl запросы к отдельным ресурсам на сервере (в данном случае jpeg). Мой запрос на загрузку jpeg работал нормально первые три раза, единственная аномалия (если это не ожидалось?) Заключается в том, что количество байтов, загружаемых для одного и того же файла, может измениться при некоторых запросах. Например:
запрос curl 1:
< Content-Type: image/jpeg
<
{ [2642 bytes data]
* Curl_http_done: called premature == 0
100 384k 100 384k 0 0 994k 0 --:--:-- --:--:-- --:--:-- 995k
curl запрос 2:
< Content-Type: image/jpeg
<
{ [1194 bytes data]
* Curl_http_done: called premature == 0
100 384k 100 384k 0 0 852k 0 --:--:-- --:--:-- --:--:-- 853k
запрос curl 3:
< Content-Type: image/jpeg
<
{ [2642 bytes data]
26 384k 26 101k 0 0 493k 0 --:--:-- --:--:-- --:--:-- 493k
* Curl_http_done: called premature == 0
100 384k 100 384k 0 0 1000k 0 --:--:-- --:--:-- --:--:-- 1000k
И тогда четвертый запрос не загрузит файл, не сообщит об ошибке или не закроет соединение. Такое же поведение я наблюдаю в браузере. Байты данных застревают на работающем таймере, приближаясь к 2 минутам:
Content-Type: image/jpeg
<
{ [1194 bytes data]
5 384k 5 22914 0 0 66 0 1:39:18 0:05:43 1:33:35 0
Такое ощущение, что запрос доходит до сервера, а потом мне не доходит обратная связь. Вот этот последний запрос полностью (через 30 секунд):
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0* Trying (IP ADDRESS)...
* TCP_NODELAY set
0 0 0 0 0 0 0 0 --:--:-- 0:00:05 --:--:-- 0* Connected to serverdomain.com (IP ADDRESS) port 80 (#0)
0 0 0 0 0 0 0 0 --:--:-- 0:00:06 --:--:-- 0> GET /images/user/176131.jpg HTTP/1.1
> Host: serverdomain.com
> User-Agent: curl/7.51.0
> Accept: */*
>
< HTTP/1.1 200 OK
< Date: Fri, 18 Aug 2017 14:04:20 GMT
< Server: Apache/2.4.18 (Ubuntu)
< Last-Modified: Thu, 17 Aug 2017 09:04:47 GMT
< ETag: "60048-556ef4de2cad8"
< Accept-Ranges: bytes
< Content-Length: 393288
< Connection: close
< Content-Type: image/jpeg
<
{ [1194 bytes data]
5 384k 5 22914 0 0 50 0 2:11:05 0:07:36 2:03:29 0