From 16e1988507bdc8fcae3f8ede7434ee6b6563f2c6 Mon Sep 17 00:00:00 2001 From: Abhishek Chatterjee Date: Mon, 30 Mar 2026 20:21:06 +0530 Subject: [PATCH 1/3] docs(networking): IMDEEPMIND-28: updated the http docs --- docs/networking/protocols/layer-7/http.md | 190 ++++++++++++---------- 1 file changed, 108 insertions(+), 82 deletions(-) diff --git a/docs/networking/protocols/layer-7/http.md b/docs/networking/protocols/layer-7/http.md index 5b1fca28..a355fb97 100644 --- a/docs/networking/protocols/layer-7/http.md +++ b/docs/networking/protocols/layer-7/http.md @@ -4,6 +4,12 @@ sidebar_position: 1 # HTTP +:::tip[Status] + +This note is complete, reviewed, and considered stable. + +::: + HTTP (Hypertext Transfer Protocol) is the foundation of data communication on the World Wide Web. It is an application layer protocol used to request and transfer hypertext data between a client (usually a web browser) and a server (hosting the website or service). HTTP is stateless, meaning each request and response are independent, with no stored state between requests. It follows a client-server architecture, where the client sends requests, and the server responds with the appropriate resource or status message. Over time, several versions of HTTP have been released, each improving upon its predecessor. These versions—HTTP/0.9, HTTP/1.0, HTTP/1.1, HTTP/2, and HTTP/3—represent the evolution of the protocol from a simple, single-request mechanism to a highly complex, optimized framework for modern web communication. @@ -20,11 +26,14 @@ HTTP/0.9 was the first version of the protocol, characterized by simplicity. It **How it works**: - **Request**: The client sends a simple text-based request with no headers: - ``` + + ```text GET /index.html ``` + - **Response**: The server responds with the raw body (HTML text): - ``` + + ```text ... ``` @@ -56,7 +65,7 @@ HTTP/1.0 introduced more features like headers and status codes, allowing more f 1. **Request**: The client sends a request to the server that includes both a method (e.g., `GET`), a target resource (e.g., `/index.html`), and headers: - ``` + ```text GET /index.html HTTP/1.0 Host: www.example.com User-Agent: Mozilla/5.0... @@ -68,7 +77,7 @@ HTTP/1.0 introduced more features like headers and status codes, allowing more f 2. **Response**: The server responds with a status line, headers, and the requested body: - ``` + ```text HTTP/1.0 200 OK Content-Type: text/html Content-Length: 134 @@ -79,14 +88,16 @@ HTTP/1.0 introduced more features like headers and status codes, allowing more f - **Headers**: Provide metadata such as the type of content (`Content-Type: text/html`) and the length of the content. - **Body**: The actual HTML content. -
- ```mermaid - sequenceDiagram - participant Client as Client - participant Server as Server - Client->>Server: GET /index.html HTTP/1.0\nHost: www.example.com\nUser-Agent: Mozilla/5.0... - Server->>Client: HTTP/1.0 200 OK\nContent-Type: text/html\nContent-Length: 134\n... - ``` +
+ +```mermaid +sequenceDiagram + participant Client as Client + participant Server as Server + Client->>Server: GET /index.html HTTP/1.0 Host: www.example.com User-Agent: Mozilla/5.0... + Server->>Client: HTTP/1.0 200 OK Content-Type: text/html Content-Length: 134 ... +``` +
**Pros**: @@ -113,15 +124,18 @@ HTTP/1.1 improved upon HTTP/1.0 by introducing several new features, such as per - **Persistent Connections**: HTTP/1.1 allows for multiple requests and responses to be sent over a single TCP connection, significantly reducing connection overhead. - **Chunked Transfer Encoding**: The server can send data in chunks, allowing the client to start processing data before the entire response is available. - **Request**: - ``` + + ```text GET /index.html HTTP/1.1 Host: www.example.com Connection: keep-alive User-Agent: Mozilla/5.0... ``` + The connection is kept open for subsequent requests. - **Response**: - ``` + + ```text HTTP/1.1 200 OK Content-Type: text/html Content-Length: 134 @@ -129,15 +143,17 @@ HTTP/1.1 improved upon HTTP/1.0 by introducing several new features, such as per ... ``` -
- ```mermaid - sequenceDiagram - participant Client as Client - participant Server as Server - Client->>Server: GET /index.html HTTP/1.1\nHost: www.example.com\nConnection: keep-alive\nUser-Agent: Mozilla/5.0... - Server->>Client: HTTP/1.1 200 OK\nContent-Type: text/html\nContent-Length: 134\nTransfer-Encoding: chunked\n... - Server->>Client: HTTP/1.1 200 OK\nContent-Type: text/css\nContent-Length: 450\nTransfer-Encoding: chunked\n - ``` +
+ +```mermaid +sequenceDiagram + participant Client as Client + participant Server as Server + Client->>Server: GET /index.html HTTP/1.1 Host: www.example.com Connection: keep-alive User-Agent: Mozilla/5.0... + Server->>Client: HTTP/1.1 200 OK Content-Type: text/html Content-Length: 134 Transfer-Encoding: chunked ... + Server->>Client: HTTP/1.1 200 OK Content-Type: text/css Content-Length: 450 Transfer-Encoding: chunked +``` +
**Pros**: @@ -170,7 +186,7 @@ HTTP/2 introduced significant improvements in performance, including multiplexin 1. **Request**: - ``` + ```text :method: GET :path: /index.html :scheme: https @@ -179,21 +195,24 @@ HTTP/2 introduced significant improvements in performance, including multiplexin ``` 2. **Response**: - ``` + + ```text :status: 200 content-type: text/html content-length: 134 ... ``` -
- ```mermaid - sequenceDiagram - participant Client as Client - participant Server as Server - Client->>Server: :method: GET\n:path: /index.html\n:host: www.example.com - Server->>Client: :status: 200\ncontent-type: text/html\ncontent-length: 134\n... - ``` +
+ +```mermaid +sequenceDiagram + participant Client as Client + participant Server as Server + Client->>Server: :method: GET\n:path: /index.html\n:host: www.example.com + Server->>Client: :status: 200\ncontent-type: text/html\ncontent-length: 134\n... +``` +
**Pros**: @@ -227,7 +246,7 @@ HTTP/3 builds on HTTP/2 but uses the QUIC transport protocol, which is based on 1. **Request**: - ``` + ```text :method: GET :path: /index.html :scheme: https @@ -236,21 +255,24 @@ HTTP/3 builds on HTTP/2 but uses the QUIC transport protocol, which is based on ``` 2. **Response**: - ``` + + ```text :status: 200 content-type: text/html content-length: 134 ... ``` -
- ```mermaid - sequenceDiagram - participant Client as Client - participant Server as Server - Client->>Server: :method: GET\n:path: /index.html\n:host: www.example.com - Server->>Client: :status: 200\ncontent-type: text/html\ncontent-length: 134\n... - ``` +
+ +```mermaid +sequenceDiagram + participant Client as Client + participant Server as Server + Client->>Server: :method: GET :path: /index.html :host: www.example.com + Server->>Client: :status: 200 content-type: text/html content-length: 134 ... +``` +
**Pros**: @@ -286,7 +308,7 @@ When you visit a website, the web browser (client) sends an HTTP request to the The structure of an HTTP request looks like this: -``` +```text GET /index.html HTTP/1.1 Host: www.example.com User-Agent: Mozilla/5.0 @@ -297,14 +319,15 @@ Accept: text/html - **Headers**: Metadata such as `Host`, `User-Agent`, and `Accept`. - **Body**: Optional part, used in POST or PUT requests to send data to the server. -
- ```mermaid - sequenceDiagram - participant Client as Client (Browser) - participant Server as Server (Web Server) +
+ +```mermaid +sequenceDiagram + participant Client as Client (Browser) + participant Server as Server (Web Server) - Client->>Server: GET /index.html HTTP/1.1\nHost: www.example.com\nUser-Agent: Mozilla/5.0\nAccept: text/html - ``` + Client->>Server: GET /index.html HTTP/1.1 Host: www.example.com User-Agent: Mozilla/5.0 Accept: text/html +```
@@ -331,7 +354,7 @@ Once the server has processed the request, it sends an HTTP response back to the Example of an HTTP Response: -``` +```text HTTP/1.1 200 OK Content-Type: text/html Content-Length: 134 @@ -339,14 +362,15 @@ Content-Length: 134 ... ``` -
- ```mermaid - sequenceDiagram - participant Client as Client (Browser) - participant Server as Server (Web Server) +
+ +```mermaid +sequenceDiagram + participant Client as Client (Browser) + participant Server as Server (Web Server) - Server->>Client: HTTP/1.1 200 OK\nContent-Type: text/html\nContent-Length: 134\n... - ``` + Server->>Client: HTTP/1.1 200 OK Content-Type: text/html Content-Length: 134 ... +```
@@ -366,19 +390,20 @@ For example: ### Complete HTTP Request-Response Cycle Diagram -
- ```mermaid - sequenceDiagram - participant Client as Client (Browser) - participant Server as Server (Web Server) +
- Client->>Server: GET /index.html HTTP/1.1\nHost: www.example.com\nUser-Agent: Mozilla/5.0\nAccept: text/html - Server->>Client: HTTP/1.1 200 OK\nContent-Type: text/html\nContent-Length: 134\n... - Client->>Server: GET /style.css HTTP/1.1\nHost: www.example.com\nUser-Agent: Mozilla/5.0\nAccept: text/css - Server->>Client: HTTP/1.1 200 OK\nContent-Type: text/css\nContent-Length: 245\nbody { ... } - Client->>Server: GET /script.js HTTP/1.1\nHost: www.example.com\nUser-Agent: Mozilla/5.0\nAccept: application/javascript - Server->>Client: HTTP/1.1 200 OK\nContent-Type: application/javascript\nContent-Length: 500\nconsole.log('...') - ``` +```mermaid +sequenceDiagram + participant Client as Client (Browser) + participant Server as Server (Web Server) + + Client->>Server: GET /index.html HTTP/1.1 Host: www.example.com User-Agent: Mozilla/5.0 Accept: text/html + Server->>Client: HTTP/1.1 200 OK Content-Type: text/html Content-Length: 134 ... + Client->>Server: GET /style.css HTTP/1.1 Host: www.example.com User-Agent: Mozilla/5.0 Accept: text/css + Server->>Client: HTTP/1.1 200 OK Content-Type: text/css Content-Length: 245 body { ... } + Client->>Server: GET /script.js HTTP/1.1 Host: www.example.com User-Agent: Mozilla/5.0 Accept: application/javascript + Server->>Client: HTTP/1.1 200 OK Content-Type: application/javascript Content-Length: 500 console.log('...') +```
@@ -394,16 +419,17 @@ Once the browser has received all the resources and rendered the webpage, the co ### Final HTTP/1.1 Request-Response with Persistent Connection -
- ```mermaid - sequenceDiagram - participant Client as Client (Browser) - participant Server as Server (Web Server) - - Client->>Server: GET /index.html HTTP/1.1\nHost: www.example.com\nConnection: keep-alive - Server->>Client: HTTP/1.1 200 OK\nContent-Type: text/html\nContent-Length: 134\n... - Client->>Server: GET /style.css HTTP/1.1\nHost: www.example.com\nConnection: keep-alive - Server->>Client: HTTP/1.1 200 OK\nContent-Type: text/css\nContent-Length: 245\nbody { ... } - ``` +
+ +```mermaid +sequenceDiagram + participant Client as Client (Browser) + participant Server as Server (Web Server) + + Client->>Server: GET /index.html HTTP/1.1 Host: www.example.com Connection: keep-alive + Server->>Client: HTTP/1.1 200 OK Content-Type: text/html Content-Length: 134 ... + Client->>Server: GET /style.css HTTP/1.1 Host: www.example.com Connection: keep-alive + Server->>Client: HTTP/1.1 200 OK Content-Type: text/css Content-Length: 245 body { ... } +```
From 278a5a91b6556ed5f5de0e5db9b6d550059b654b Mon Sep 17 00:00:00 2001 From: Abhishek Chatterjee Date: Mon, 30 Mar 2026 20:24:36 +0530 Subject: [PATCH 2/3] docs(networking): IMDEEPMIND-28: updated the dns docs --- docs/networking/protocols/layer-7/dns.md | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/docs/networking/protocols/layer-7/dns.md b/docs/networking/protocols/layer-7/dns.md index 702d344d..2d5c3f52 100644 --- a/docs/networking/protocols/layer-7/dns.md +++ b/docs/networking/protocols/layer-7/dns.md @@ -4,6 +4,12 @@ sidebar_position: 2 # DNS +:::tip[Status] + +This note is complete, reviewed, and considered stable. + +::: + The **Domain Name System (DNS)** is a hierarchical and decentralized naming system used to resolve human-readable domain names (like `www.example.com`) into machine-readable IP addresses (such as `192.0.2.1`). It acts as the "phonebook" of the internet, translating friendly domain names into IP addresses that computers use to communicate with each other. In simple terms, DNS allows users to access websites, email services, and other online resources without needing to remember complex numeric IP addresses. From 60ef80ed40a3692df1da5337834aa6f39d588d08 Mon Sep 17 00:00:00 2001 From: Abhishek Chatterjee Date: Mon, 30 Mar 2026 20:27:16 +0530 Subject: [PATCH 3/3] docs(networking): IMDEEPMIND-28: updated the osi and client and server arch notes --- .../protocols/client-server-architecture.md | 40 +++++++++---------- docs/networking/protocols/osi-model.md | 26 ++++++------ 2 files changed, 33 insertions(+), 33 deletions(-) diff --git a/docs/networking/protocols/client-server-architecture.md b/docs/networking/protocols/client-server-architecture.md index 232ae8fe..dfa14fcb 100644 --- a/docs/networking/protocols/client-server-architecture.md +++ b/docs/networking/protocols/client-server-architecture.md @@ -12,7 +12,7 @@ This note is complete, reviewed, and considered stable. Client-Server Architecture is a foundational model in network computing that structures applications into two main components: **clients** and **servers**. This architecture facilitates resource sharing, scalability, and efficient management of networked systems. Below are detailed notes covering various aspects of Client-Server Architecture. -
+
```mermaid graph TD @@ -128,44 +128,44 @@ Protocols define the rules for data exchange between clients and servers. Common ### Request-Response Model - **Process**: - 1. **Client Request**: Client sends a request to the server. - 2. **Server Processing**: Server processes the request. - 3. **Server Response**: Server sends back the response to the client. + 1. **Client Request**: Client sends a request to the server. + 2. **Server Processing**: Server processes the request. + 3. **Server Response**: Server sends back the response to the client. - **Synchronous vs. Asynchronous**: - **Synchronous**: Client waits for the server response. - **Asynchronous**: Client can continue processing without waiting. ## Advantages -1. **Centralized Resources**: Easier management and maintenance. -2. **Scalability**: Servers can be scaled up or out to handle more clients. -3. **Security**: Centralized control over data and resources enhances security. -4. **Maintainability**: Updates and patches can be applied on the server side without affecting clients. -5. **Resource Sharing**: Efficient sharing of resources like databases, files, and applications. -6. **Performance Optimization**: Servers can be optimized for specific tasks, improving overall performance. +1. **Centralized Resources**: Easier management and maintenance. +2. **Scalability**: Servers can be scaled up or out to handle more clients. +3. **Security**: Centralized control over data and resources enhances security. +4. **Maintainability**: Updates and patches can be applied on the server side without affecting clients. +5. **Resource Sharing**: Efficient sharing of resources like databases, files, and applications. +6. **Performance Optimization**: Servers can be optimized for specific tasks, improving overall performance. ## Disadvantages -1. **Single Point of Failure**: Server outages can disrupt all client operations. -2. **Cost**: High-performance servers and robust infrastructure can be expensive. -3. **Complexity**: Designing and managing a client-server system can be complex. -4. **Network Dependency**: Requires reliable network connectivity; performance can be affected by network issues. -5. **Scalability Limits**: Although scalable, there are physical and practical limits to scaling server resources. +1. **Single Point of Failure**: Server outages can disrupt all client operations. +2. **Cost**: High-performance servers and robust infrastructure can be expensive. +3. **Complexity**: Designing and managing a client-server system can be complex. +4. **Network Dependency**: Requires reliable network connectivity; performance can be affected by network issues. +5. **Scalability Limits**: Although scalable, there are physical and practical limits to scaling server resources. ## Use Cases and Examples -1. **Web Applications**: +1. **Web Applications**: - Clients: Web browsers. - Servers: Web servers (e.g., Apache, Nginx). -2. **Email Services**: +2. **Email Services**: - Clients: Email clients (e.g., Outlook, Thunderbird). - Servers: Mail servers (e.g., Microsoft Exchange, Postfix). -3. **Database Systems**: +3. **Database Systems**: - Clients: Applications accessing data. - Servers: Database servers (e.g., MySQL, Oracle). -4. **File Sharing**: +4. **File Sharing**: - Clients: File explorer applications. - Servers: File servers (e.g., FTP servers, NAS devices). -5. **Enterprise Applications**: +5. **Enterprise Applications**: - Clients: Desktop or mobile applications. - Servers: Application servers handling business logic. diff --git a/docs/networking/protocols/osi-model.md b/docs/networking/protocols/osi-model.md index 9747cc19..28752ba3 100644 --- a/docs/networking/protocols/osi-model.md +++ b/docs/networking/protocols/osi-model.md @@ -12,7 +12,7 @@ This note is complete, reviewed, and considered stable. The **OSI (Open Systems Interconnection) model** is a conceptual framework used to understand and implement standard protocols in network communications. It divides the communication process into **seven distinct layers**, each with specific functions and responsibilities. -
+
```mermaid graph TD @@ -50,10 +50,10 @@ The OSI model was introduced in 1984 by the International Organization for Stand The OSI model is divided into two categories: -1. **Host Layers** (Application, Presentation, Session) -2. **Media Layers** (Transport, Network, Data Link, Physical) +1. **Host Layers** (Application, Presentation, Session) +2. **Media Layers** (Transport, Network, Data Link, Physical) -### Overview of Layers: +### Overview of Layers | **Layer** | **Layer Number** | **Data Unit** | **Primary Function** | | ------------ | ---------------- | ------------- | ----------------------------------------------------- | @@ -143,18 +143,18 @@ Transmission of raw binary data over a medium. ## Advantages of the OSI Model -1. **Standardized Framework**: Enables interoperability between different hardware and software systems. -2. **Modularity**: Encourages a structured approach to network design and troubleshooting. -3. **Scalability**: Supports upgrades and changes to individual layers without impacting others. -4. **Error Isolation**: Simplifies fault isolation and debugging. -5. **Flexibility**: Supports multiple communication protocols. +1. **Standardized Framework**: Enables interoperability between different hardware and software systems. +2. **Modularity**: Encourages a structured approach to network design and troubleshooting. +3. **Scalability**: Supports upgrades and changes to individual layers without impacting others. +4. **Error Isolation**: Simplifies fault isolation and debugging. +5. **Flexibility**: Supports multiple communication protocols. ## Disadvantages of the OSI Model -1. **Complexity**: The model's layered approach can sometimes introduce unnecessary overhead. -2. **Implementation Gap**: Real-world implementations like TCP/IP do not strictly adhere to the OSI model. -3. **Performance Overhead**: Additional layers may reduce system performance due to processing overhead. -4. **Theoretical Nature**: The OSI model is more conceptual and not always practical for all systems. +1. **Complexity**: The model's layered approach can sometimes introduce unnecessary overhead. +2. **Implementation Gap**: Real-world implementations like TCP/IP do not strictly adhere to the OSI model. +3. **Performance Overhead**: Additional layers may reduce system performance due to processing overhead. +4. **Theoretical Nature**: The OSI model is more conceptual and not always practical for all systems. ## Comparison with the TCP/IP Model