1. Support Layer7 Nf_conntrack really do not need to do after the obsession, you will feel the need to quickly change "based on five-tuple data flow" to "data flow based on application layer protocol fixed offset", hurriedly hands, the faster the better! This person adds several fields to the Nf_conn on the Linux 3.17 kernel that supports zone Conntrack:
BOOL L7; A Boolean that indicates whether to make a layer7 match.
U32 offset; Apply the offset of the laminar flow indicator
U32 Offlen; Length of application of laminar flow markers
The above three fields are set in CT target and are also set with zone, which indicates:
All packets belonging to zone $id identify a stream with a fixed-length stream identity defined by the application-layer fixed offset, instead of using a traditional five-tuple to identify a stream. Redefining a tuple also adds a bool type L7, indicating whether it is the flow identifier of the application layer, and adding an array sid of Max_idlen length, which means that stream recognizes the maximum Max_idlen bytes.
The above is the basic data definition, then in the code logic, the modification is not difficult, mainly to modify the RESOLVE_NORMAL_CT function, remove the Tmpl template L7, if it is not 0, it indicates the need to "apply laminar flow identification" to identify the flow, at this time according to the offset, Offlen field, navigate to [Iphdr+iphdrlen+transphdrlen] This position, take out offlen bytes of data, as the hash of the key to calculate the hash value, before __nf_conntrack_find_get, The tuple is populated with the SID of the application layer and the L7 of the tuple, which means that at the time of Find Conntrack, the SID value of the tuple is compared instead of the five-tuple. Finally, at the time of Conn confirm, the SID (which has been placed in a tuple structure, by its char payload]; field is identified by Conntrack in accordance with the Sid[max_idlen information of its Offset,offlen location. To insert them.
It took less than two hours to modify, compile, and test (bought imac too TMD!!) )。 With the sex, with the play, eat something, drink tea, began to get a little. This man is me!
It is also a process of introspection to begin to think about the meaning of what you do! I found out suddenly that everything I did was meaningless. The conntrack structure does not hold anything for the application layer, although I have extended it myself, to allow it to save a lot of things, such as routing, sockets, etc., but in fact there is no place to really use these, that is, they are nothing to play with things. The most important information stored in Conntrack is the NAT information, the tuple information, which is based on the traditional 5-tuple, you think, if I use SessionID-based application layer information to identify a tuple, what about NAT? If the IP address of the client changes, even if the SessionID is not changed, Nat still has to be re-done, or there is no benefit. My intention is to save because of the IP address, the port changes after the series of re-operation, but ultimately there is no province, because the change is the IP and port, need to re-modify or decorate the IP and port is still the information.
If the above code is written on paper, it is clear that I will tear it up and throw it into the dustbin ...
2. Reuseport that support Layer7 arbitrary payload hash calculation is powerful
The latest Linux kernel already supports the UDP reuseport option, which can be a good service for UDP load balancing, if you do not know can Bing. It can be load balanced, it is through a fixed 5-tuple to calculate a fixed hash, and then based on the fixed hash to distribute a packet to a fixed socket, if the IP address does not change, everything will be fine, but the IP address in the mobile environment will change, This means that the 5-tuple information is changed, and the recalculated hash will also change (no change that is a collision!). , which means that the next UDP packet sent by the client that changed the IP will probably be distributed to other sockets, which is not expected in long UDP-based connection services. The following is the __udp4_lib_lookup core code:
Begin:result = NULL; badness =-1; SK_NULLS_FOR_EACH_RCU (SK, node, &hslot->head) {//SessionID version of the hash calculation, the service side do not identify sport/saddr for the wonderful! Score = Compute_score (SK, net, saddr, Hnum, Sport, DADDR, Dport, DIF); if (Score > badness) {result = SK; Badness = score; Reuseport = sk->sk_reuseport; if (reuseport) {//5-tuple stream version, calculates a hash value based on a 4-tuple//hash = INET_EHASHFN (NET, daddr, Hnum, Saddr, Hto NS (sport)); Sid Stream version, calculated hash based on SessionID. The question is how this SID is spread here ... Overhaul Bar hash = Sid_based_hash (SID,); matches = 1; }} else if (score = = Badness && reuseport) {matches++; Whether or not the SK replaced the last match to the SK, see the hash value of the effect of the IF (((u64) hash * matches) >> = = 0) {result = SK; } hash = hash * 1664525 + 1013904223; }}/* * If the nulls value we gotAt the end of this lookup was * not the expected one, we must restart lookup. * We probably met an item that is moved to another chain. */if (Get_nulls_value (node)! = slot) goto begin;
The note mentions the overhaul, which means that I have to upload a skb to this place in order to get the SID based on the setsockopt parameter Reuseport flag, Sid's Offset,sid Offlen, and then calculate the hash, but this repair is easy, Recompile the kernel.
It is very cool to use SessionID to identify a stream in UDP's Reuseport, because the data is now at the transport layer, except that the repackaged packets are basically up to one of the UDP services of this machine, and the packets have arrived here. The 5-tuple-related identification, such as NAT, has been completely passed, the next step is to send data to the application layer, at this time according to the application layer SID to identify a stream, can ensure that even if the client IP is changed, it sends the request can also reach the same UDP service thread ... This also provides a good reality for the mobile era, in the five-yuan group of frequent replacement of the era, how to keep the application layer constantly open ...
Layer7 Data Flow (connection tracking) identification problem in Linux streaming load balancing
