Computer Network Experiment: TCP vs QUIC (Linux Guide)

This guide adapts the Windows-based experiment manual for a Linux environment.

1. Prerequisites

Ensure you have the following installed:

gcc (Compiler)
quiche library (Headers and Shared Object installed)
openssl (For certificates)
tcpdump or wireshark (For packet capture)
iproute2 (For tc traffic control)

2. Compilation

Compile all programs using the provided Makefile:

make

This will generate:

tcp_server, tcp_client (Task 1)
quic_server, quic_client (Task 2)
tcp_perf_server, tcp_perf_client (Task 3 Performance)
quic_perf_server, quic_perf_client (Task 3 Performance)

Note: If quiche is not in the standard system path, edit the Makefile to point to the include/lib directories.

3. Task 1: Basic TCP Client-Server

Start the Server:
```
./tcp_server
```
Run the Client (in a new terminal):
```
./tcp_client
```
Expected Output: The client sends "Hello...", server receives it and replies.

4. Task 2: Basic QUIC Client-Server

Start the Server:
```
./quic_server
```
Run the Client (in a new terminal):
```
./quic_client
```
Expected Output: QUIC handshake completes, client sends data on a stream, server echoes it back.

5. Task 3: Performance Analysis

3.1 Connection Establishment Time

Start capture on loopback:
```
sudo tcpdump -i lo -w handshake.pcap
```
(Or use Wireshark on the lo interface)
Run the TCP or QUIC client/server pairs again.
Open handshake.pcap in Wireshark to analyze the time difference between the first packet (SYN for TCP, Initial for QUIC) and the completion of the handshake.

3.2 Throughput Test (100MB Transfer)

Baseline (Normal Network):

Run TCP Perf Server: ./tcp_perf_server
Run TCP Perf Client: ./tcp_perf_client
Record the MB/s output.
Repeat for QUIC (./quic_perf_server, ./quic_perf_client).

Simulating Network Conditions (Packet Loss / Delay):

We use Linux tc (Traffic Control) with netem instead of clumsy.

Scenario A: 5% Packet Loss

Apply 5% loss to the loopback interface:

sudo tc qdisc add dev lo root netem loss 5%

Run the perf tests again.
Important: Remove the rule after testing!
```
sudo tc qdisc del dev lo root
```

Scenario B: 100ms Delay

Apply 100ms delay:

sudo tc qdisc add dev lo root netem delay 100ms

Run the perf tests again.
Remove the rule:
```
sudo tc qdisc del dev lo root
```

3.3 Advanced Test: Multiplexing vs Multi-Connection

This task compares the performance of 5 parallel TCP connections against a single QUIC connection with 5 concurrent streams.

Scenario 1: TCP Multi-Connection Establish 5 TCP connections simultaneously, each transferring 20MB (Total 100MB).

Start TCP Multi-Connection Server:
```
./tcp_multi_server
```
Run TCP Multi-Connection Client:
```
./tcp_multi_client
```
Record total time and throughput from the server output.

Scenario 2: QUIC Single-Connection Multi-Streaming Establish 1 QUIC connection and open 5 streams concurrently, each transferring 20MB (Total 100MB).

Start QUIC Multi-Stream Server:
```
./quic_multi_server
```
Run QUIC Multi-Stream Client:
```
./quic_multi_client
```
Record the performance statistics.

Analysis Points:

Compare completion times in a normal network.
Use tc to simulate packet loss (e.g., 5%). Observe how QUIC's multiplexing avoids TCP's Head-of-Line (HoL) blocking, where a single lost packet in one TCP connection doesn't stall the other streams in QUIC.

3.8 KiB Raw Blame History