Masalah sambungan panjang proksi terbalik Nginx

Question

Saya ada beberapa server A, B, C, D, E... Antaranya, A boleh akses ke rangkaian luar, tetapi yang lain tidak boleh saya gunakan kaedah http_proxy untuk mengakses rangkaian luar melalui A. Tujuan utama adalah untuk akses antara muka rakan kongsi, seperti http ://api.xxx.com/get/user, mungkin beratus kali sesaat.

Dalam beberapa hari yang lalu, saya telah mencuba untuk melihat sama ada saya boleh mengekalkan sambungan yang panjang antara A dan pelayan rakan kongsi (diandaikan sebagai Z Selepas pengubahsuaian dan ujian, pengepala yang dikembalikan oleh Z sudah menunjukkan bahawa http/1.1 sambungan kekal-hidup, tetapi Masa-tunggu soket adalah Ia masih sangat tinggi Selain itu, dalam log A, parameter $sambungan nginx sentiasa meningkat

Berikut ialah konfigurasi pas proksi pada A:

server{

  resolver 10.10.2.118;

  listen 1080;
  error_log   /var/log/nginx/proxy.error.log   error;
  access_log  /var/log/nginx/proxy.access.log  proxy_access;

  location / {
    proxy_pass http://$host$request_uri;
    proxy_redirect off;
    proxy_set_header  Host $host;
    proxy_set_header  X-Real-IP $remote_addr;
    proxy_set_header  X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header  Connection "keep-alive";
    proxy_http_version 1.1;
    proxy_ignore_client_abort on;
    proxy_connect_timeout 600;
    proxy_read_timeout 600;
    proxy_send_timeout 600;
    proxy_buffer_size 64k;
    proxy_buffers   4 32k;
    proxy_busy_buffers_size 64k;
    proxy_temp_file_write_size 64k;

    allow 10.0.0.0/8;
    deny all;
  }
}

Adakah ini masalah dengan konfigurasi saya? Saya tidak memahami Internet dan saya hanya bermain-main

Answer 1

Saya melihat blog rasmi dan memajukan soalan ini, jadi saya datang untuk membantu anda menyemaknya. Saya tidak tahu sama ada anda telah menyelesaikannya sendiri

Pertama sekali, mari bercakap tentang konfigurasi anda. Saya tidak tahu dari mana asalnya. Ia mempunyai banyak parameter tentang proksi Mari kita ambil proxy_pass sebagai contoh menunjuk ke konfigurasi asal anda, contohnya, akses 10.0.0.100/api/pengguna mesin A anda (diandaikan sebagai 10.0.0.100), dengan $host ialah 10.0.0.100, $request_uri is/api/user, jadi sesuatu yang pelik berlaku, akses A kemudian wakilkan kepada A. Adakah saya mengantuk sedikit. Saya tidak akan terus menerangkan apa yang akan berlaku dalam situasi ini. Saya hanya akan memberitahu anda penyelesaian yang mudah ----------------Keputusan ditangan anda, hulu------------------
Di sini, tetapkan IP rangkaian luaran yang anda perlukan untuk akses kepada 123.123.123.123, $host$request_uri就是指向你原来的地址，例如访问你的A机器（假设为10.0.0.100）的10.0.0.100/api/user，其中$host就是10.0.0.100，$request_uri就是/api/user,所以这里奇葩的事情发生了，访问A然后又代理到A，是不是已经崩溃了，有点儿困，我就不继续解释这种情况下到底会发生什么了，直接说下简单地解决办法
----------------就决定是你了，upstream----------------
这里设你需要访问的外网ip为123.123.123.123，

upstream backend {
    server 123.123.123.123;
    keepalive 10;
}
location / {
    proxy_pass http://$backend;
    proxy_http_version 1.1;
    proxy_ignore_client_abort on;
    proxy_connect_timeout 600;
    proxy_read_timeout 600;
    proxy_send_timeout 600;
    proxy_buffer_size 64k;
    proxy_buffers   4 32k;
    proxy_busy_buffers_size 64k;
    proxy_temp_file_write_size 64k;

    allow 10.0.0.0/8;
    deny all;
}

还有就是有些参数你不知道是啥意思，就不要加进去，不一定适合你的业务场景的
这里着重解释一下upstream里面的这个keepalive rrreee
Selain itu, jika anda tidak tahu maksud sesetengah parameter, jangan tambahkannya mungkin tidak sesuai untuk senario perniagaan anda
Di sini kami menumpukan pada menerangkan parameter keepalive di hulu

Kami tahu bahawa dalam spesifikasi HTTP 1.1, tiada pengecam permintaan seperti dalam HTTP/2 Sambungan TCP keepalive hanya boleh menghantar satu permintaan http pada satu masa Permintaan kedua tidak boleh dihantar sehingga permintaan itu kembali prestasi Mengapa pelayan web (seperti Tengine) menggabungkan fail statik seperti js menjadi satu (untuk menjimatkan masa dan sambungan)

Mengapa saya menggunakan nombor 10 di sini? Dengan mengandaikan bahawa ia mengambil masa 100ms untuk meminta hos luaran dan mengembalikannya, satu TCP boleh menyelesaikan 10 permintaan dalam 1s Untuk melengkapkan keperluan anda sebanyak 100 kali sesaat, ia memerlukan sambungan yang panjang , kira-kira Algoritma adalah seperti ini Dalam situasi sebenar, anda boleh mengkonfigurasi nombor ini supaya lebih besar daripada nilai yang dikira, dan kestabilan mungkin lebih baik

. 🎜Jika anda mempunyai sebarang pertanyaan, tinggalkan mesej🎜

Answer 2

Maafkan saya: Jika pelayan bahagian belakang adalah dinamik pada masa ini, bagaimana untuk menggunakan keepalive huluan untuk memastikan bahawa nginx dan bahagian belakang mempunyai sambungan yang panjang? Terima kasih!