2017-05-18 10:08 GMT+01:00 Adrian Popa <[email protected]>: > Salutare, > > Am un proxy squid prin care accesez o pagină web pe care fac un POST. Dacă > parametrii sunt tunați ca query-ul să nu dureze mult, atunci primesc > răspunsul. Dacă post-ul durează ~40 secunde, atunci nu mai primesc > răspunsul. > > Am făcut un tcpdump pe server și după 40s începe să "toarne" headere și > output, dar după 2 pachete primește un TCP RST de la serverul cu squid și > se oprește. > > În configul de squid am: > > read_timeout 100 minutes > connect_timeout 5 minutes > request_timeout 5 minutes > > ... dar nu par să conteze. > > Squid-ul raportează: > 192.168.238.77 - - [18/May/2017:11:49:46 +0300] "POST > http://my.internal.site.ro/webapp/form.pl HTTP/1.1" 0 0 " > http://my.internal.site.ro/webapp/"; "Mozilla/5.0 (X11; Ubuntu; Linux > x86_64; rv:53.0) Gecko/20100101 Firefox/53.0" TCP_MISS:FIRST_UP_PARENT > > M-am mai uitat și la iptables/conntrack, care are următorii parametrii > default TCP: > sysctl -a | grep conntrack > net.netfilter.nf_conntrack_generic_timeout = 600 > net.netfilter.nf_conntrack_tcp_timeout_syn_sent = 120 > net.netfilter.nf_conntrack_tcp_timeout_syn_recv = 60 > net.netfilter.nf_conntrack_tcp_timeout_established = 432000 > net.netfilter.nf_conntrack_tcp_timeout_fin_wait = 120 > net.netfilter.nf_conntrack_tcp_timeout_close_wait = 60 > net.netfilter.nf_conntrack_tcp_timeout_last_ack = 30 > net.netfilter.nf_conntrack_tcp_timeout_time_wait = 120 > net.netfilter.nf_conntrack_tcp_timeout_close = 10 > net.netfilter.nf_conntrack_tcp_timeout_max_retrans = 300 > net.netfilter.nf_conntrack_tcp_timeout_unacknowledged = 300 > net.netfilter.nf_conntrack_tcp_loose = 1 > net.netfilter.nf_conntrack_tcp_be_liberal = 0 > net.netfilter.nf_conntrack_tcp_max_retrans = 3 > net.netfilter.nf_conntrack_udp_timeout = 30 > net.netfilter.nf_conntrack_udp_timeout_stream = 180 > net.netfilter.nf_conntrack_icmpv6_timeout = 30 > net.netfilter.nf_conntrack_frag6_timeout = 60 > net.netfilter.nf_conntrack_frag6_low_thresh = 196608 > net.netfilter.nf_conntrack_frag6_high_thresh = 262144 > net.netfilter.nf_conntrack_icmp_timeout = 30 > net.netfilter.nf_conntrack_acct = 0 > net.netfilter.nf_conntrack_events = 1 > net.netfilter.nf_conntrack_events_retry_timeout = 15 > net.netfilter.nf_conntrack_max = 65536 > net.netfilter.nf_conntrack_count = 2520 > net.netfilter.nf_conntrack_buckets = 16384 > net.netfilter.nf_conntrack_checksum = 1 > net.netfilter.nf_conntrack_log_invalid = 0 > net.netfilter.nf_conntrack_expect_max = 256 > net.nf_conntrack_max = 65536 > > Mi s-a părut dubios net.netfilter.nf_conntrack_tcp_timeout_last_ack că e > 30s by default și l-am mărit la 300 (sysctl -w > net.netfilter.nf_conntrack_tcp_timeout_last_ack=300). N-am repornit nimic > altceva și văd că nu e nici o diferență. Nu sunt sigur pentru ce e > parametrul ăsta - o sesiune care așteaptă un ACK, sau o sesiune ESTABLISHED > care e idle și ăla e timpul trecut de la ultimul ACK? > https://www.kernel.org/doc/Documentation/networking/nf_ > conntrack-sysctl.txt > nu m-a lămurit. > > Singurul parametru interesant din netfilter e
net.netfilter.nf_conntrack_tcp_timeout_established = 432000 care e OK. (5 zile). Pune tcpdump pe o conexiune sa vedem exact ce se comunica. Ideal ar fi sa faci tcpdump si pe partea squid-> server si ce pune squid in loguri pentru requestul respectiv. Ai mai jos "tcp state diagram" de pe google ca sa te lamuresti. (pentru ca rlug nu permite sa pui o imagine in mesaj - suntem in 1999) https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.halu101/dwgl0004.gif > Ce îmi recomandați să mai încerc? > _______________________________________________ > RLUG mailing list > [email protected] > http://lists.lug.ro/mailman/listinfo/rlug > _______________________________________________ RLUG mailing list [email protected] http://lists.lug.ro/mailman/listinfo/rlug
