On Tue, Jan 26, 2010 at 3:02 AM, Pascal Hambourg <pascal.mail@xxxxxxxxxxxxxxx> wrote: > Hello, > > Felipe W Damasio a écrit : >> >> 2010/1/25 Jan Engelhardt <jengelh@xxxxxxxxxx>: >>> The issue is that you would need to replay the tcp handshake. >>> >>> Case 1: >>> - do TCP handshake >>> - read out Host: header >>> - if proxied >>> - good >>> - if not, >>> - have to replay TCP handshake to next host (eww :-) >> >> Would this be so bad? :-) > > Yes, quite, because it must be transparent to the client. However the > new server may have a lower MSS and not support some TCP options such as > windows scaling, ECN, selective ACK, window scaling, timestamps... that > the previous one supported and which are transmitted only during the > handshake, so the client would not know about. how about learning this info from the next hop by sending a SYN packet with all options set and the largest MSS. It sounds like TCP splicing and SYN proxy. And I heard some one had implemented SYN proxy in Linux, and xBSD also support SYN proxy. Is there any chance to integrate SYN proxy and TCP splicing into Linux? > Not to mention that of > course it will use a different initial sequence number and it would have > to be translated by the bridge in each packet. NAT also need to take care of this, so we can reuse the code already in the kernel maybe. -- Regards， Changli Gao(xiaosuo@xxxxxxxxx) -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
