TCP RST acak di situs web tertentu, apa yang terjadi?

Versi singkat: Satu mesin Windows Server 2012 di jaringan saya semakin gigih tetapi RST TCP terputus-putus saat terhubung ke situs web tertentu. Entah dari mana asalnya. Lihat log wireshark untuk analisis & pertanyaan saya.

Versi panjang:

Kami menjalankan caching web-proxy di salah satu server kami untuk melayani kantor kecil kami. Seorang rekan kerja dilaporkan mendapatkan banyak kesalahan 'Reset Koneksi' atau 'Halaman tidak dapat ditampilkan' saat menghubungkan ke situs tertentu, tetapi penyegaran biasanya memperbaikinya.

Saya memverifikasi perilaku browser, dan kemudian lebih langsung dengan mencoba browser yang tidak diproksikan di server itu sendiri. Tetapi ping & traceroutes ke situs yang bermasalah tidak menunjukkan masalah, masalahnya tampaknya terbatas pada koneksi tcp.

Saya kemudian membuat skrip untuk menguji situs yang terpengaruh dengan mengirimkan langsung permintaan HTTP HEAD melalui cURL & memeriksa seberapa sering mereka berhasil. Tes khas terlihat seperti ini: (ini tidak diproksikan, berjalan langsung di server yang buruk)

C:\sdk\Apache24\htdocs>php rhTest.php
Sending HTTP HEAD requests to "http://www.washingtonpost.com/":
20:21:42: Length: 0     Response Code: NULL (0%)
20:22:02: Length: 0     Response Code: NULL (0%)
20:22:22: Length: 0     Response Code: NULL (0%)
20:22:42: Length: 0     Response Code: NULL (0%)
20:23:02: Length: 3173  Response Code: HTTP/1.1 302 Moved Temporarily (20%)
20:23:22: Length: 3174  Response Code: HTTP/1.1 302 Moved Temporarily (33.33%)
20:23:43: Length: 0     Response Code: NULL (28.57%)
20:24:03: Length: 3171  Response Code: HTTP/1.1 302 Moved Temporarily (37.5%)
20:24:23: Length: 3173  Response Code: HTTP/1.1 302 Moved Temporarily (44.44%)
20:24:43: Length: 3172  Response Code: HTTP/1.1 302 Moved Temporarily (50%)
20:25:03: Length: 0     Response Code: NULL (45.45%)

Dalam jangka panjang, hanya sekitar 60% dari permintaan yang berhasil, sisanya tidak menghasilkan apa-apa, dengan kode kesalahan keriting: "kesalahan CURL (56): Gagal saat menerima data dari rekan" Perilaku buruk konsisten untuk situs web I uji (tidak ada situs yang pernah 'menjadi lebih baik') dan itu cukup gigih, saya sudah memecahkan masalah selama seminggu sekarang, dan rekan kerja melaporkan masalah telah ada di sana selama berbulan-bulan rupanya.

Saya menguji skrip permintaan KEPALA pada mesin lain di jaringan kami: tidak ada masalah, semua koneksi melewati semua situs pada daftar pengujian saya. Lalu saya mengatur proxy di desktop pribadi saya, dan ketika saya menjalankan permintaan HEAD dari server yang bermasalah, semua koneksi akan lewat. Jadi apa pun masalahnya, itu sangat spesifik untuk server ini.

Selanjutnya saya mencoba mengisolasi situs web mana yang memperlihatkan perilaku reset-koneksi:

• Tidak ada satu pun situs intranet kami (192.168.xx) yang memutuskan koneksi.
• Tidak ada situs ipv6 yang saya uji koneksi drop. (Kami adalah tumpukan ganda)
• Hanya sebagian kecil situs ipv4 internet yang memutuskan koneksi.
• Setiap situs yang menggunakan cloudflare sebagai CDN (yang telah saya uji) menjatuhkan koneksi. (tetapi masalahnya tampaknya tidak eksklusif untuk situs cloudflare)

Sudut ini tidak berkembang menjadi sesuatu yang sangat membantu, jadi selanjutnya saya menginstal wireshark untuk melihat apa yang terjadi ketika permintaan gagal. Permintaan HEAD yang gagal terlihat seperti ini: (tangkapan layar yang lebih besar di sini: http://imgur.com/TNfRUtX )

127 48.709776000    192.168.1.142   192.33.31.56    TCP 66  52667 > http [SYN, ECN, CWR] Seq=0 Win=8192 Len=0 MSS=8960 WS=256 SACK_PERM=1
128 48.728207000    192.33.31.56    192.168.1.142   TCP 66  http > 52667 [SYN, ACK, ECN] Seq=0 Ack=1 Win=42340 Len=0 MSS=1460 SACK_PERM=1 WS=128
129 48.728255000    192.168.1.142   192.33.31.56    TCP 54  52667 > http [ACK] Seq=1 Ack=1 Win=65536 Len=0
130 48.739371000    192.168.1.142   192.33.31.56    HTTP    234 HEAD / HTTP/1.1 
131 48.740917000    192.33.31.56    192.168.1.142   TCP 60  http > 52667 [RST] Seq=1 Win=0 Len=0
132 48.757766000    192.33.31.56    192.168.1.142   TCP 60  http > 52667 [ACK] Seq=1 Ack=181 Win=42240 Len=0
133 48.770314000    192.33.31.56    192.168.1.142   TCP 951 [TCP segment of a reassembled PDU]
134 48.807831000    192.33.31.56    192.168.1.142   TCP 951 [TCP Retransmission] http > 52667 [PSH, ACK] Seq=1 Ack=181 Win=42240 Len=897
135 48.859592000    192.33.31.56    192.168.1.142   TCP 951 [TCP Retransmission] http > 52667 [PSH, ACK] Seq=1 Ack=181 Win=42240 Len=897
138 49.400675000    192.33.31.56    192.168.1.142   TCP 951 [TCP Retransmission] http > 52667 [PSH, ACK] Seq=1 Ack=181 Win=42240 Len=897
139 50.121655000    192.33.31.56    192.168.1.142   TCP 951 [TCP Retransmission] http > 52667 [PSH, ACK] Seq=1 Ack=181 Win=42240 Len=897
141 51.564009000    192.33.31.56    192.168.1.142   TCP 951 [TCP Retransmission] http > 52667 [PSH, ACK] Seq=1 Ack=181 Win=42240 Len=897
143 54.452561000    192.33.31.56    192.168.1.142   TCP 951 [TCP Retransmission] http > 52667 [PSH, ACK] Seq=1 Ack=181 Win=42240 Len=897

Cara saya membaca ini (koreksi saya jika saya salah, ini bukan bidang saya) adalah:

• Kami membuka koneksi tcp ke server web
• server web ACK
• Permintaan HEAD HTTP dikirim
• Ada paket RST, ditandai sebagai dari server web IP, yang membunuh koneksi.
• Server web mengirim ACK
• Server web (mencoba) untuk menanggapi permintaan HEAD dengan data HTTP yang valid (Balasan 951 byte berisi tajuk HTTP yang benar)
• Webserver mentransmisikan ulang (beberapa kali selama beberapa detik) respons HTTP yang valid, tetapi tidak berhasil karena koneksi telah RST

Jadi jika server web telah mengirim RST yang valid, mengapa tetap mencoba untuk mengisi permintaan? Dan jika server web tidak menghasilkan RST, apa yang terjadi?

Hal-hal yang saya coba tidak berpengaruh:

• Menonaktifkan tim NIC
• Mengganti adaptor jaringan (pengganti NIC diketahui berfungsi)
• Menetapkan ip statis.
• Menonaktifkan ipv6.
• Menonaktifkan bingkai jumbo.
• Menghubungkan server langsung ke modem kami suatu malam, melewati switch & router kami.
• Mematikan windows firewall.
• Menyetel ulang pengaturan TCP melalui netsh
• Menonaktifkan hampir semua layanan lain di server. (Kami sebagian besar menggunakannya sebagai fileserver, tetapi ada apache & DB pasangan)
• Memukul kepala di meja (berulang kali)

Saya curiga ada sesuatu di server yang menghasilkan paket RST, tetapi untuk kehidupan saya, saya tidak dapat menemukannya. Saya merasa seperti jika saya tahu: mengapa hanya server ini? ATAU mengapa hanya beberapa situs web? itu akan banyak membantu. Sementara saya masih penasaran, saya semakin cenderung untuk nuklir dari orbit & memulai dari awal.

Gagasan / Saran?

-Terima kasih

Pengambilan paket Anda memiliki sesuatu yang tidak biasa: Bit ECN diatur dalam paket SYN keluar.

Pemberitahuan kongesti eksplisit adalah ekstensi protokol IP yang memungkinkan host untuk bereaksi lebih cepat terhadap kemacetan jaringan. Ini pertama kali diperkenalkan ke Internet 15 tahun yang lalu, tetapi ada masalah serius yang dicatat ketika pertama kali digunakan. Yang paling serius adalah banyak firewall yang akan menjatuhkan paket atau mengembalikan RST ketika menerima paket SYN dengan bit-bit ECN yang disetel.

Akibatnya, sebagian besar sistem operasi menonaktifkan ECN secara default, setidaknya untuk koneksi keluar. Akibatnya, saya menduga bahwa banyak situs (dan vendor firewall!) Tidak pernah memperbaiki firewall mereka .

Hingga Windows Server 2012 dirilis. Microsoft mengaktifkan ECN secara default dimulai dengan versi sistem operasi ini.

Sayangnya tidak ada dalam memori baru-baru ini melakukan pengujian signifikan terhadap tanggapan situs-situs Internet terhadap ECN, jadi sulit untuk mengukur apakah masalah yang terlihat pada awal 2000-an masih ada, tetapi saya sangat curiga mereka ada dan bahwa lalu lintas Anda, setidaknya beberapa saat, melewati peralatan seperti itu.

Setelah mengaktifkan ECN di desktop saya dan kemudian menyalakan Wireshark, hanya beberapa detik sebelum saya menangkap contoh host yang darinya saya mendapatkan RST ke paket dengan set SYN dan ECN, meskipun sebagian besar host tampaknya berfungsi dengan baik. Mungkin saya akan memindai Internet sendiri ...

Anda dapat mencoba menonaktifkan ECN di server Anda untuk melihat apakah masalah terselesaikan. Ini juga akan membuat Anda tidak dapat menggunakan DCTCP, tetapi di kantor kecil sangat tidak mungkin Anda melakukannya atau perlu melakukannya.

netsh int tcp set global ecncapability=disabled