IConfiguration vs IOptions NET
Synchronous and Asynchronous in .NET Core
Model Binding and Validation in ASP.NET Core
ControllerBase vs Controller in ASP.NET Core
ConfigureServices and Configure methods
IHostedService interface in .NET Core
ASP.NET Core request processing
 | NET Core Performance Best Practices | kubernates |  |
TCP/IP communication |
TCP/IP communication refers to the suite of communication protocols used to interconnect network devices on the internet and private networks. TCP/IP stands for Transmission Control Protocol/Internet Protocol, which are the two main protocols in this suite. TCP/IP is responsible for breaking down data into packets, transmitting them over the network, and reassembling them at the destination.
Think of TCP/IP as the postal system of the internet. You want to send a message (say, a photo or a WhatsApp text) from your phone to a friend’s computer. Here's how it works in simple terms:
Your app (like Gmail or WhatsApp) creates the message. This is the Application Layer—it knows what you want to say.
The Transport Layer (TCP) breaks your message into smaller chunks (called packets), numbers them, and ensures they arrive safely and in order.
The Internet Layer (IP) adds the destination address—like your friend’s IP address—so the network knows where to send it.
The Network Access Layer physically sends the data over cables, Wi-Fi, or mobile networks—like the postman delivering the envelope.
Their device reassembles the packets, checks for errors, and shows the full message—just like opening the envelope and reading the letter.
Imagine sending a book by courier, but you tear out each page and send them in separate envelopes. TCP makes sure:
That’s TCP/IP in action.
Here’s a visual diagram of TCP/IP communication—your internet’s postal system in action: This shows how data flows between two devices (Host 1 and Host 2) through the four layers of the TCP/IP stack:
Each layer adds its own header and passes the data down. On the receiving end, each layer strips its header and passes the data up. Like peeling an onion, but with purpose.
The full TCP/IP stack is implemented inside your operating system (Windows, Linux, etc.).
It handles:
Think of this as your personal post office—sending and receiving packets with full control over how they’re packed, tracked, and delivered.
Routers do not run full TCP/IP stacks like end systems.
They mostly operate at the Internet Layer:
They don’t handle TCP or UDP sessions—those are managed by the devices at either end of the communication.
Routers are like traffic controllers—they don’t care what’s inside the packet, just where it needs to go.
| Component | TCP/IP Role | Executes Full Stack? |
|---|---|---|
| Your PC/Phone | Sends/receives data, manages sessions | ✅ Yes |
| Server | Hosts services, manages connections | ✅ Yes |
| Router | Routes packets, manages IP addresses | ❌ Partial (IP only) |
If you’re architecting a driver or service, the TCP/IP stack you interact with is inside your OS kernel or networking libraries. Routers just forward your packets—they don’t parse or respond to them unless they’re acting as a proxy or firewall.
The foundational work was done by:
TCP/IP isn’t versioned like a software library—it evolves through RFCs (Request for Comments). But here’s a simplified timeline:
| Year | Milestone | Notes |
|---|---|---|
| 1974 | RFC 675 | First spec of TCP/IP (combined protocol) |
| 1981 | RFC 791 & RFC 793 | Split into IP and TCP; this is IPv4 and classic TCP |
| 1994 | IPng (IP Next Generation) | Led to IPv6, standardized in RFC 2460 |
| 2000s–Present | TCP Variants | TCP Tahoe, Reno, NewReno, CUBIC, BBR etc. (used in Linux, Windows, macOS) |
TCP has over 100+ variants proposed in literature, with CUBIC being the default in Linux and Windows today.
The protocol suite is governed by:
Here's a breakdown of the most widely used TCP congestion control algorithms
| Feature | TCP Reno | TCP CUBIC | TCP BBR (Bottleneck Bandwidth & RTT) |
|---|---|---|---|
| 📅 Introduced | 1995 | 2006 (Linux default) | 2016 (Google) |
| 📈 Growth Strategy | Linear increase, halving on loss | Cubic curve (fast ramp-up) | Bandwidth estimation + RTT probing |
| 🧠 Intelligence | Loss-based | Loss-based with time scaling | Model-based (not loss-driven) |
| 🌐 Ideal Use Case | Low-latency, low-bandwidth | High-speed, long-distance links | Streaming, real-time, cloud apps |
| 🔁 Reaction to Loss | Halves congestion window | Reduces based on cubic curve | Doesn’t react to loss immediately |
| 🚀 Throughput Potential | Moderate | High | Very High |
| 🧪 Fairness | Good with similar flows | Better in mixed environments | Can be aggressive vs legacy TCP |
Use SocketsHttpHandler with HttpClient to leverage OS-level TCP stack.
For Linux-hosted apps, check and tune:
sysctl net.ipv4.tcp_congestion_controlYou can switch between reno, cubic, or bbr if supported.
If you're profiling a high-throughput .NET Core service:
🧠 1. MAC Address (Media Access Control)
This is a unique hardware identifier assigned to your network device (like a Wi-Fi card or Ethernet adapter). It operates at the Data Link Layer of the OSI model.
🔍 Key Facts:
- It’s a 48-bit hexadecimal number, like D4-BE-D9-8D-46-9A.
- Assigned by the device manufacturer and burned into the hardware.
- Used for local network communication (e.g., LAN).
- Helps routers and switches identify devices on the network.
| | NET Core Performance Best Practices | kubernates | |