0% found this document useful (0 votes)
7 views13 pages

Understanding Request Response

The document explains the request-response communication design pattern commonly used in backend systems, detailing how clients send requests and servers process and respond to them. It covers various protocols like HTTP, DNS, SSH, RPC, and APIs, highlighting their structures and interactions. Additionally, it discusses challenges and solutions related to data transmission, such as resumability for large files.

Uploaded by

Aayush Sinha
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
7 views13 pages

Understanding Request Response

The document explains the request-response communication design pattern commonly used in backend systems, detailing how clients send requests and servers process and respond to them. It covers various protocols like HTTP, DNS, SSH, RPC, and APIs, highlighting their structures and interactions. Additionally, it discusses challenges and solutions related to data transmission, such as resumability for large files.

Uploaded by

Aayush Sinha
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd

😄

Understanding Request-
Response
This is classic and most famous communication design pattern for the backend.

In a request response model, the client sends what we call a request. But what
does a request actually mean? In a networking environment, defining what a
request is essential. A request can contain continuous stream of data (usually
underneath, TCP which delivers a continuous stream of bytes) and that the
server needs to parse the data to look for the start of the request and the end
of the request.

Once the request is parsed , it needs to be processed on the server side. Once
the processing is finished, it sends response back to client and then the Client
parses the response and continues

Where is request-response cycle used


Request-response is used in multiple places including

Web i.e, HTTP, DNS and SSH protocols

Understanding Request-Response 1
HTTP

In HTTP the communication flow between a client (like a web browser) and a
server (like a web server).

When a client (like a web browser) retrieves information, it sends a payload of


data to a server as a request. This request is made up of three main parts:

A Request line, containing three pieces of information:

the HTTP verb (also called an HTTP method) for sending or retrieving
information

the URI path of the resource where we’re sending or retrieving


information

the version of the HTTP protocol our “client” software is using, usually
HTTP/1.1

Headers, which are key/value pairs, which contain supplemental


information about our request

An optional body; we only send data to the server in the body when we are
creating or modifying something

When a server or web application is finished processing a request, it sends


a response which is a payload of data, back to the client. This response
contains three main parts:

Understanding Request-Response 2
a status line, containing three pieces of information:

The version of the HTTP protocol that this response is using

a 3-digit numeric “status code”.

a user-friendly string description of what the “status code” means

Headers, also sent as key/value pairs similar to the HTTP request

An optional body; almost all responses will contain additional data in the
body.

DNS

The DNS (Domain Name System) request-response cycle involves a client


querying a DNS server to translate a domain name (like example.com) into an IP
address, which the client then uses to connect to the server.

SSH

The SSH protocol (also referred to as Secure Shell) is a method for secure
remote login from one computer to another. It provides several alternative
options for strong authentication, and it protects communications security and

Understanding Request-Response 3
integrity with strong encryption.

The protocol works in the client-server model, which means that the
connection is established by the SSH client connecting to the SSH server.

The SSH client drives the connection setup process and uses public key
cryptography to verify the identity of the SSH server. After the setup phase the
SSH protocol uses strong symmetric encryption and hashing algorithms to
ensure the privacy and integrity of the data that is exchanged between the
client and server.

RPC (Remote Procedure Call)

A Remote Procedure Call (RPC) is a protocol that allows a program on one


computer to execute a procedure or function on another computer.

It simplifies distributed system development by hiding the complexities of


network communication, making it easier to create applications where different
parts run on separate machines.

The client application initiates a call to a remote procedure on the server. The
client's request, including the procedure to be called and any necessary
parameters, is transmitted to the server.

The server receives the request, identifies the requested procedure, and
executes it. After processing the request, the server generates a response

Understanding Request-Response 4
containing the result of the procedure, any return values, and potentially status
information. The server sends the response back to the client.

The client receives the response and can then process the returned data or
status.

SQL and Database Protocols

When your application calls, say, a JDBC or ODBC driver hands off the SQL
text over a wire protocol (A wire protocol is the format for interactions between
a database server and its clients). The database engine explores many ways to
execute the query, estimates costs, and picks the best plan. The chosen plan’s
operators (scans, joins, filters, etc.) run and fetch or modify data. The final rows
(or status) are packaged and sent back to your client.

APIs (REST/GraphQL)

APIs—whether RESTful or GraphQL—follow a structured pipeline from the


moment a client issues a request to when it receives the response.

At a high level, the cycle involves:

the client formulating an HTTP (or GraphQL) request;

network transmission and protocol‐level handling;

server‐side routing, authentication, and middleware processing;

request parsing/validation; business‐logic execution (controllers in


REST, resolvers in GraphQL) with data fetching;

response construction (including status codes or shaped JSON);

and finally serialization back over HTTP to the client.

While REST typically exposes multiple URL endpoints mapped to CRUD


operations, GraphQL centralizes everything at a single /graphql endpoint and
emphasizes a typed schema, AST‐based parsing, and response shapes that
mirror the request.

Understanding Request-Response 5
Anatomy of Request-Response
A request structure is defined by both client and server and they have to agree
on it based on the
protocol being used.

POST /HTTP/1.1
Headers
<CRLF>
BODY

An HTTP request consists of four main components in the following order: the
request line, the header fields, a blank line (CRLF), and the optional message
body.

The very first line of an HTTP request is called the start line or request line,
and it contains Method (GET, POST, PUT etc.), request-uri to identify
resource on server, and HTTP version

Immediately after the request line come one or more header fields, each on
its own line, providing metadata like Host, Content-Type, Content-Length

A single empty line—represented by CRLF (i.e., \r\n )—separates the header


section from the body. This blank line signals to the server that no more
header fields follow, and that the next bytes, if any, belong to the message
body

If the request method allows or requires a payload (e.g., POST , PUT ), the
message body comes after the blank line. The body can carry form-
encoded data, JSON, binary content, etc. Its presence and length are
governed by header fields such as Content-Length

The client and server must adhere to a predefined request format, which is
typically handled for us behind the scenes. It's all done for us as backend
engineer by library such as HTTP library.

Understanding Request-Response 6
All the libraries that you reference is doing work behind the scenes, and the
key of understanding what these libraries do is the key to becoming a better
software engineer

Request has a boundary and it's defined by the protocol and the message
format.

Request-Response Visual

In essence, every interaction between a client and a server unfolds in a


sequence of timed phases:

1. Request Preparation & Send – the client spends time composing


(serializing) and flushing the request out to the network

Understanding Request-Response 7
2. Network Transfer to Server – the request is broken into TCP segments and
IP packets, routed through the Internet (with potential reordering latency)

3. Server Processing – once fully received and deserialized, the server


executes whatever business logic is required

4. Response Preparation & Send – the server serializes its response and
flushes it back onto the network

5. Network Transfer to Client – the response packets traverse the network


(with reordering and reassembly costs)

6. Client Receipt & Deserialization – the client reassembles and parses the
response, completing the cycle.

Case study
Let's say we want to build a back end application that uploads an image and we
want to use request-response pattern for it

One solution is to , take the whole image from the client and literally just send
that entire image in the wire to the server. Problem with this solution is that
there are limits. A large file is difficult to send in the wire to server

Another solution is resumability—dividing images into smaller chunks and


sending each chunk with its own unique identifier in separate requests.

Understanding Request-Response 8
Technically, both the solutions still uses request response under the hood

In following notes, we will see where request - response pattern fail (like
notification service or chat application)

curl demo
Lets practically see a request-response pattern using curl

curl -v --trace out.txt http://google.com


cat out.txt

You will see a response similar to this one

== Info: Host google.com:80 was resolved.


== Info: IPv6: 2404:6800:4009:807::200e
== Info: IPv4: 142.250.207.174
== Info: Trying [2404:6800:4009:807::200e]:80...
== Info: Connected to google.com (2404:6800:4009:807::200e) port 80
=> Send header, 73 bytes (0x49)
0000: 47 45 54 20 2f 20 48 54 54 50 2f 31 2e 31 0d 0a GET / HTTP/1.1..
0010: 48 6f 73 74 3a 20 67 6f 6f 67 6c 65 2e 63 6f 6d Host: google.com
0020: 0d 0a 55 73 65 72 2d 41 67 65 6e 74 3a 20 63 75 ..User-Agent: cu
0030: 72 6c 2f 38 2e 35 2e 30 0d 0a 41 63 63 65 70 74 rl/8.5.0..Accept
0040: 3a 20 2a 2f 2a 0d 0a 0d 0a : */*....
<= Recv header, 32 bytes (0x20)
0000: 48 54 54 50 2f 31 2e 31 20 33 30 31 20 4d 6f 76 HTTP/1.1 301 Mov
0010: 65 64 20 50 65 72 6d 61 6e 65 6e 74 6c 79 0d 0a ed Permanently..
<= Recv header, 34 bytes (0x22)
0000: 4c 6f 63 61 74 69 6f 6e 3a 20 68 74 74 70 3a 2f Location: http:/
0010: 2f 77 77 77 2e 67 6f 6f 67 6c 65 2e 63 6f 6d 2f /www.google.com/
0020: 0d 0a ..
<= Recv header, 40 bytes (0x28)
0000: 43 6f 6e 74 65 6e 74 2d 54 79 70 65 3a 20 74 65 Content-Type: te
0010: 78 74 2f 68 74 6d 6c 3b 20 63 68 61 72 73 65 74 xt/html; charset
0020: 3d 55 54 46 2d 38 0d 0a =UTF-8..
<= Recv header, 245 bytes (0xf5)

Understanding Request-Response 9
0000: 43 6f 6e 74 65 6e 74 2d 53 65 63 75 72 69 74 79 Content-Security
0010: 2d 50 6f 6c 69 63 79 2d 52 65 70 6f 72 74 2d 4f -Policy-Report-O
0020: 6e 6c 79 3a 20 6f 62 6a 65 63 74 2d 73 72 63 20 nly: object-src
0030: 27 6e 6f 6e 65 27 3b 62 61 73 65 2d 75 72 69 20 'none';base-uri
0040: 27 73 65 6c 66 27 3b 73 63 72 69 70 74 2d 73 72 'self';script-sr
0050: 63 20 27 6e 6f 6e 63 65 2d 79 44 6b 79 72 66 70 c 'nonce-yDkyrfp
0060: 55 51 37 2d 6e 64 39 65 4b 31 32 5f 58 4d 67 27 UQ7-nd9eK12_XM
g'
0070: 20 27 73 74 72 69 63 74 2d 64 79 6e 61 6d 69 63 'strict-dynamic
0080: 27 20 27 72 65 70 6f 72 74 2d 73 61 6d 70 6c 65 ' 'report-sample
0090: 27 20 27 75 6e 73 61 66 65 2d 65 76 61 6c 27 20 ' 'unsafe-eval'
00a0: 27 75 6e 73 61 66 65 2d 69 6e 6c 69 6e 65 27 20 'unsafe-inline'
00b0: 68 74 74 70 73 3a 20 68 74 74 70 3a 3b 72 65 70 https: http:;rep
00c0: 6f 72 74 2d 75 72 69 20 68 74 74 70 73 3a 2f 2f ort-uri https://
00d0: 63 73 70 2e 77 69 74 68 67 6f 6f 67 6c 65 2e 63 csp.withgoogle.c
00e0: 6f 6d 2f 63 73 70 2f 67 77 73 2f 6f 74 68 65 72 om/csp/gws/other
00f0: 2d 68 70 0d 0a -hp..
<= Recv header, 37 bytes (0x25)
0000: 44 61 74 65 3a 20 4d 6f 6e 2c 20 31 39 20 4d 61 Date: Mon, 19 Ma
0010: 79 20 32 30 32 35 20 31 39 3a 33 35 3a 35 36 20 y 2025 19:35:56
0020: 47 4d 54 0d 0a GMT..
<= Recv header, 40 bytes (0x28)
0000: 45 78 70 69 72 65 73 3a 20 57 65 64 2c 20 31 38 Expires: Wed, 18
0010: 20 4a 75 6e 20 32 30 32 35 20 31 39 3a 33 35 3a Jun 2025 19:35:
0020: 35 36 20 47 4d 54 0d 0a 56 GMT..
<= Recv header, 40 bytes (0x28)
0000: 43 61 63 68 65 2d 43 6f 6e 74 72 6f 6c 3a 20 70 Cache-Control: p
0010: 75 62 6c 69 63 2c 20 6d 61 78 2d 61 67 65 3d 32 ublic, max-age=2
0020: 35 39 32 30 30 30 0d 0a 592000..
<= Recv header, 13 bytes (0xd)
0000: 53 65 72 76 65 72 3a 20 67 77 73 0d 0a Server: gws..
<= Recv header, 21 bytes (0x15)
0000: 43 6f 6e 74 65 6e 74 2d 4c 65 6e 67 74 68 3a 20 Content-Length:
0010: 32 31 39 0d 0a 219..
<= Recv header, 21 bytes (0x15)
0000: 58 2d 58 53 53 2d 50 72 6f 74 65 63 74 69 6f 6e X-XSS-Protection
0010: 3a 20 30 0d 0a : 0..
<= Recv header, 29 bytes (0x1d)

Understanding Request-Response 10
0000: 58 2d 46 72 61 6d 65 2d 4f 70 74 69 6f 6e 73 3a X-Frame-Options:
0010: 20 53 41 4d 45 4f 52 49 47 49 4e 0d 0a SAMEORIGIN..
<= Recv header, 2 bytes (0x2)
0000: 0d 0a ..
<= Recv data, 219 bytes (0xdb)
0000: 3c 48 54 4d 4c 3e 3c 48 45 41 44 3e 3c 6d 65 74 <HTML><HEAD>
<met
0010: 61 20 68 74 74 70 2d 65 71 75 69 76 3d 22 63 6f a http-equiv="co
0020: 6e 74 65 6e 74 2d 74 79 70 65 22 20 63 6f 6e 74 ntent-type" cont
0030: 65 6e 74 3d 22 74 65 78 74 2f 68 74 6d 6c 3b 63 ent="text/html;c
0040: 68 61 72 73 65 74 3d 75 74 66 2d 38 22 3e 0a 3c harset=utf-8">.<
0050: 54 49 54 4c 45 3e 33 30 31 20 4d 6f 76 65 64 3c TITLE>301 Moved
<
0060: 2f 54 49 54 4c 45 3e 3c 2f 48 45 41 44 3e 3c 42 /TITLE></HEAD><
B
0070: 4f 44 59 3e 0a 3c 48 31 3e 33 30 31 20 4d 6f 76 ODY>.<H1>301 Mo
v
0080: 65 64 3c 2f 48 31 3e 0a 54 68 65 20 64 6f 63 75 ed</H1>.The docu
0090: 6d 65 6e 74 20 68 61 73 20 6d 6f 76 65 64 0a 3c ment has moved.<
00a0: 41 20 48 52 45 46 3d 22 68 74 74 70 3a 2f 2f 77 A HREF="http://w
00b0: 77 77 2e 67 6f 6f 67 6c 65 2e 63 6f 6d 2f 22 3e ww.google.com/">
00c0: 68 65 72 65 3c 2f 41 3e 2e 0d 0a 3c 2f 42 4f 44 here</A>...</BOD
00d0: 59 3e 3c 2f 48 54 4d 4c 3e 0d 0a Y></HTML>..
== Info: Connection #0 to host google.com left intact

Lets understand this

Name Resolution & TCP Connection

== Info: Host google.com:80 was resolved.


== Info: IPv6: 2404:6800:4009:807::200e
== Info: IPv4: 142.250.207.174
== Info: Trying [2404:6800:4009:807::200e]:80...
== Info: Connected to google.com (2404:6800:4009:807::200e) port 80

Understanding Request-Response 11
curl resolves “google.com” to both IPv6 and IPv4 addresses, then opens a TCP
protocol connection over one of them.

Port 80 is the default TCP/IP port for Hypertext Transfer Protocol (HTTP) traffic,
used for web browsing and data transfer between web servers and clients. It's
the port your web browser uses when you visit a website, unless a specific port
is specified in the URL

Sending the HTTP Request

=> Send header, 73 bytes (0x49)


0000: 47 45 54 20 2f 20 48 54 54 50 2f 31 2e 31 0d 0a GET / HTTP/1.1..
0010: 48 6f 73 74 3a 20 67 6f 6f 67 6c 65 2e 63 6f 6d Host: google.com
0020: 0d 0a 55 73 65 72 2d 41 67 65 6e 74 3a 20 63 75 ..User-Agent: cu
0030: 72 6c 2f 38 2e 35 2e 30 0d 0a 41 63 63 65 70 74 rl/8.5.0..Accept
0040: 3a 20 2a 2f 2a 0d 0a 0d 0a : */*....

Raw bytes: curl shows the exact bytes sent.

Request line: GET / HTTP/1.1 asks for the root document.

Headers:

Host: google.com specifies which virtual host to reach.

User-Agent: curl/8.5.0 identifies the client.

Accept: */* indicates it can accept any content type.

End‑of‑headers: the double CRLF ( 0d 0a 0d 0a ) marks the end of the header


section.

Receiving the HTTP Response

curl logs every header chunk as it arrives:

<= Recv header, 32 bytes (0x20)


0000: 48 54 54 50 2f 31 2e 31 20 33 30 31 20 4d 6f 76 HTTP/1.1 301 Mov

Understanding Request-Response 12
...
<= Recv header, 34 bytes (0x22)
0000: 4c 6f 63 61 74 69 6f 6e 3a 20 68 74 74 70 3a 2f Location: http://ww
w.google.com/
...
<= Recv header, 40 bytes (0x28)
0000: 43 6f 6e 74 65 6e 74 2d 54 79 70 65 3a 20 74 65 Content-Type: tex
t/html; charset=UTF-8
...
<= Recv header, … [other headers continue]
...
<= Recv header, 21 bytes (0x15)
0000: 43 6f 6e 74 65 6e 74 2d 4c 65 6e 67 74 68 3a 20 Content-Length: 2
19
...

Key response headers:

Status: HTTP/1.1 301 Moved Permanently tells the client the resource is now at
another URL.

Location: http://www.google.com/ indicates where to redirect.

Content-Type: text/html; charset=UTF-8 shows the body format.

Cache-Control, Expires, etc.: control caching behavior.

Content-Length: 219: the body that follows will be exactly 219 bytes.

Receiving the Response Body

<= Recv data, 219 bytes (0xdb)


0000: 3c 48 54 4d 4c … <HTML><HEAD>…<H1>301 Moved</H1>…<A HR
EF="http://www.google.com/">here</A>…

curl reads and logs the raw HTML payload, which is a simple page informing
the user of the permanent redirect and providing a clickable link.

Understanding Request-Response 13

You might also like