Bagaimana untuk menyelesaikan sejumlah besar ralat http 400 dalam log akses nginx pelayan Linux

Rekod ralat dalam pelayan adalah serupa dengan ini:

124.65.133.242 – – [27/oct/2014:14:30:51 +0800] “ - ” 400 0 “-” “-”
124.65.133.242 – – [27/oct/2014:14:31:45 +0800] “-” 400 0 “-” “-”
124.65.133.242 – – [27/oct/2014:14:31:45 +0800] “-” 400 0 “-” “-”
124.65.133.242 – – [27/oct/2014:14:31:45 +0800 ] “-” 400 0 “-” “-”

Langkah keluar

Selepas menganalisis fail log nginx, didapati bahawa beberapa 400 dijana selepas normal akses. Ralat mungkin berlaku secara berterusan dari 1 hingga 6 setiap kali, dan tidak setiap lawatan pelanggan akan menghasilkan ralat 400.

Adalah perkara biasa untuk memerhatikan akses sebelumnya yang menghasilkan 400 kod status, fail biasa, sumber biasa, ejen pengguna biasa... semuanya harmoni, jadi mengapa 400 datang?

Melalui pemerhatian yang teliti, kami mendapati bahawa semua ejen pengguna lawatan sebelumnya yang menghasilkan 400 ralat ditinggalkan oleh penyemak imbas Google Chrome, yang bermaksud bahawa 400 ralat telah dihasilkan oleh penyemak imbas Chrome. Walau bagaimanapun, selepas tangkapan paket tempatan, didapati bahawa Chrome tidak menghantar permintaan atau paket data yang tidak normal kepada pelayan.

Dalam analisis tangkapan paket, didapati bahawa chrome memulakan lebih daripada satu sambungan apabila mengakses pelayan, biasanya antara 5 hingga 6. Jika sumber yang diminta tidak memerlukan begitu banyak sambungan, chrome akan menutupnya. Sambungan yang digunakan dipanggil pra-sambungan.

Biasanya apabila kita melawat tapak web, perkara pertama yang kita dapat ialah fail html utama, yang mengandungi pautan ke fail sumber media lain seperti css, js, gambar, dll yang diperlukan oleh halaman web fail sumber dan html utama Fail berada di bawah domain Pra-sambungan bermakna mewujudkan banyak sambungan tcp sebelum mendapatkan html, bukannya menunggu untuk mendapatkan fail html dan kemudian menyambung ke pelayan untuk mendapatkan fail lain pelayan mengambil sedikit masa, jadi Teknologi ini boleh mempercepatkan pemaparan halaman web pada tahap yang besar.

Jika sumber pautan HTML halaman web agak kecil, atau klien mempunyai cache dan tidak perlu menyambung untuk memuat turun, maka berkemungkinan hanya satu daripada 5-6 sambungan yang dikeluarkan oleh Penyemak imbas Chrome diperlukan, dan yang lain diperlukan Tutupnya, yang menimbulkan masalah: pelayan disambungkan tanpa menghantar sebarang permintaan. Dalam kes ini, nginx mengendalikannya sebagai ralat 400, tetapi kerana sambungan telah ditutup, mesej ralat tidak akan dihantar kepada klien Ini menyebabkan ralat direkodkan dalam fail log, tetapi tiada apa yang dapat dilihat dalam fenomena penangkapan paket.

Ujian
Untuk mengesahkan keputusan analisis di atas adalah sangat mudah, buka baris arahan cmd.exe, masukkan telnet serverip 80, tunggu sambungan berjaya, dan kemudian tutup cmd terus Periksa fail log nginx dan terdapat rekod ralat 400 tambahan.

Satu ulasan
Kelebihan prasambungan sudah sangat jelas, tetapi ia juga mempunyai kekurangan jika juruweb telah mengoptimumkannya dan menggunakan teknologi tanpa kuki, atau web halaman Jika anda menggunakan pelayan yang berbeza daripada sumber statik, maka sumber css dan js yang diperlukan oleh halaman web tidak berada dalam domain yang sama dengan html utama, dan mungkin tidak berada pada IP yang sama Kemudian pra-sambungan bukan sahaja tidak berguna , tetapi juga akan menyebabkan kesulitan kepada pelayan html utama beban yang diperlukan.

Sebab lain

Ramai orang di Internet telah menulis artikel berkaitan Kebanyakan sebabnya adalah kerana saiz pengepala melebihi saiz, menyebabkan respons sebanyak 400, memberitahu ia menjadi permintaan yang buruk. Tetapi sebenarnya ada kemungkinan lain, iaitu seperti alat ujian pelabuhan, yang hanya memeriksa sama ada pelabuhan itu hidup. Perkara seperti lvs juga boleh menyebabkan masalah seperti ini, dan kemudian banyak 400 ralat akan muncul dalam log.

Untuk masalah di atas, anda boleh meningkatkan kedua-dua client_header_buffer_size dan large_client_header_buffers dalam nginx.conf untuk mengurangkan masalah ini.

Atas ialah kandungan terperinci Bagaimana untuk menyelesaikan sejumlah besar ralat http 400 dalam log akses nginx pelayan Linux. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!