2017-05-18 10:08 GMT+01:00 Adrian Popa :
> 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
> RLUG@lists.lug.ro
> http://lists.lug.ro/mailman/listinfo/rlug
>
___
RLUG mailing list
RLUG@lists.lug.ro
http://lists.lug.ro/mailman/listinfo/rlug
