1. Design and Implementation of a Server Director Project for the LCCN Lab at the Technion

2. 2 Design and Implementation of a Server Director Submitted by: Eyal Skulski, 032033862 Pasha Glozman,310073085 Amir Idar,028593606

3. 3 Design and Implementation of a Server Director Contents Introduction System Operation Modules description and algorithms  Clients Module Clients Module  Director Layer 5 Module Director Layer 5 Module  Director Layer 4 Module Director Layer 4 Module  NAT Module and Connection Table NAT Module and Connection Table  Servers Module Servers Module  Scheduler Module Scheduler Module Main Data Structures

4. 4 Design and Implementation of a Server Director 1. Introduction Designers of internet servers which encounter large volumes of simultaneous TCP traffic (CNN.com for example), implement one of several designs for traffic management. One possible solution is the introduction of a "Director" – a server which acts as an entry gate to several other servers holding the actual content. The Director's job is to accept each incoming http request ("Get") from the clients, to forward it to the chosen server, and to send back the reply to the requesting client. The match of client to server is done in one of two primary ways –  In the first, the incoming message is not analyzed, but is delivered to a content server based on general considerations such as the server's current load. In the second, the data is analyzed, the client will be "connected" with the server holding the first requested page, and related topics.  The second method is generally preferable, as it uses a more knowledgeable decision base, however – analyzing each incoming request is a timely process, wasting a considerable amount of time and diminishing this method's efficiency. The goal of our project is to test one possible solution to the inefficiency of testing each request – a Director which tests only the “get” request for each client, and then switches into a kind of "router", connecting this client to the server chosen by examination of the first request without further examination of packets from/to this client. We will implement such a Director on a Linux system, with web browsers as the clients, and two web servers as the proxies.

5. 5 Design and Implementation of a Server Director 23. Director Layer 5 removes rules from NAT, and entry from connection Table 2. System Operation 2. Director Layer 4 adds initial entry to Connection Table 1 6 3 4 5 7 8 Director Layer 5 CLIENTS SERVERS Director Layer 4 Global Local Scheduler NAT Connection Table 9 13 10 11 12 14 15 18 23 17 19 21 22 1.Client initiates TCP connection with Director 2 3-5. Completion of 3-way Handshake between client and Director (Schematic) 6. GET request by client7. Director Layer 5 calls Scheduler to select a server for the client’s GET request 8. Director Layer 5 updates entry with: ServerIP, ServerPort(80) 9. Director Layer 5 continues TCP connection to selected server via Layer 4 Action: 10. Director Layer 4 updates entry with: Server Seq. #, Director-Server Seq. #, Director Port (server) 11-13. Completion of 3-way handshake between Director and selected server (schematic) 14. Director Layer 5 adds 2 rules to the NAT table – from server and from client 15. Director Layer 5 sends the GET request it has saved to the selected server 17. IP’s, Sequence numbers, and checksums are updated by the NAT mechanism 20. IP’s, Sequence numbers, and checksums are updated by the NAT mechanism 18. Server response and ACK reaches the client 19. Client ACK is sent to Director 20 21. Client ACK is sent to Server, (updated as Director ACK) 22. Server FIN16. Server sends response and ACK to the GET request 16

6. 6 Design and Implementation of a Server Director 3. Modules description and algorithms Clients Module: No module for the clients is implemented within the project framework. Clients are web browsers running on one of the Lab computers. Each client initiates a TCP connection to port 80 as in a usual handshake, and requests http pages as if connecting to a regular server with the Director's IP address.

7. 7 Design and Implementation of a Server Director Director Layer 5 Module: This module is implemented in Linux User Mode. It is responsible for creating the initial TCP connection with clients, matching clients to their appropriate servers, based on the URL they request in the GET packet, creating the connection with the selected server, and adding/removing NAT rules in the rules table. 3. Modules description and algorithms – cont.

8. 8 Design and Implementation of a Server Director Director Layer 5 Module Algorithm : 1. Wait for incoming TCP connections passed by Layer 4. 2. Upon receiving a new connection, create a thread to handle it, and process handshake until completed. 3. When receiving a GET request from a recognized client, pass the requested URL to the scheduler to choose the server for handling it, and save the request to enable sending it to the server shortly. 4. Update the Connections Table with the IP of the selected server, (port is always 80). 5. Create a TCP connection with the selected server, through Layer 4. 6. After Layer 4 updates the final details for the connection in the Connection Table, add bi- directional NAT rules. 7. Send the saved GET request which was received from the client to the server. * Comment: at this stage Layer 5 has finished its handling of the connection, since when the server sends the reply to the client, the rules are already updated in the NAT table, and from there on Layer 4 will automatically handle the communication. 8. Goto 1) 3. Modules description and algorithms – cont.

9. 9 Design and Implementation of a Server Director Director Layer 4 Module: This module is implemented by alterations on the Linux kernel, within the framework of a module called IPVS, which we use as a NAT. It is responsible for maintaining TCP connections and a TCP stack, for connections between clients/servers and Layer 5 until the NAT rules are set for each connection, at which stage it serves as a NAT "router", automatically updating packets so they are passed to/from clients/servers through the Director. 3. Modules description and algorithms – cont.

10. 10 Design and Implementation of a Server Director Director Layer 4 Module Algorithm : 1. Wait for incoming TCP connections on Port 80. 2. Upon receiving a connection request – process request as usual, but add new client IP and port, client sequence number, and director to client sequence number to the Connections Table. (all IP packets are checked, and those coming to port 80 are filtered and checked whether they are TCP SYN packets, then TCP stack is simulated, creating real TCP connection etc., but we will not elaborate further, since these actions are made by the operating system). 3. Upon Director's initiation of a TCP connection with a selected server, update the Connection Table with server sequence number, Director to server sequence number, and Director (server) port. 4. For all packets destined for Director, call the NAT module to update their headers, if their source appears within a NAT rule. 5. Go to Step 1) 3. Modules description and algorithms – cont.

11. 11 Design and Implementation of a Server Director NAT Module and Connection Table: This module is part of a module for the Linux system, which we adapted for our needs. It is responsible for maintaining the Connection Table, used for matching client and server IPs, as well as "updating" necessary fields in TCP/IP packet headers (source/destination IPs, sequence numbers), and for maintaining the NAT rules. 3. Modules description and algorithms – cont.

12. 12 Design and Implementation of a Server Director Servers Module This module is simulated by two web servers on Lab computers. It is responsible for replying with appropriate http contents to GET requests from Director Layer 4 (on behalf of clients). Comment: This module is implemented on the Lab computers, and we do not intend to change it. 3. Modules description and algorithms – cont.

13. 13 Design and Implementation of a Server Director Scheduler Module : This module is in charge of selecting a server to handle the a given URL according to predetermined rules described by regular expressions, and passing the selected server IP back to Layer 5. 3. Modules description and algorithms – cont.

14. 14 Design and Implementation of a Server Director 4. Main Data Structures Connection Table: This table supports efficient two-way connection between client IP's and ports to their selected server IP's and ports and vice-versa. Server Seq. # Server Port Server IP Director - Server Seq. # Director to Server Port Director -Client Seq. # Director to Client Port Client Seq. # Client Port Client IP

15. 15 Design and Implementation of a Server Director Server Content Table Used by the Scheduler module to determine which server to match with a client, based on the client's requested URL. This table is defined statically within the Director class constructor. 4. Main Data Structures – cont. Server PortServer IPURL

16. 16 Design and Implementation of a Server Director NAT Rule Table Note: Detailed descriptions of the implementation in code of the modules, as well as technical notes – appear in the project’s Final Report file. 4. Main Data Structures – cont. Client Seq.# Server Seq.# Dest. PortDest. IPVirtual Port Virtual IP Client Port Client IP