Today, I want to discuss the TCP slow-start feature, and yes, it's a feature. It's not really—I mean, it is

sometimes a problem, but it is not a bug or a problem that has been accidentally introduced. It was introduced on purpose.

So, if you're interested, stay tuned. What's going on, guys? My name is Russain, and I discussed back-end engineering in

this channel, sometimes networking aspects of that, that kind of touches on back-end engineering and performance, like

slow start. So, if you're interested, check out the channel, subscribe, like this video, and let's just jump in and do it. And

yeah, slow start. So, TCP slow-start has been introduced into the TCP protocol to solve a problem, and that problem is

called congestion control, right? So, we want to control how much data and packets we send from the client, which could

be a browser, it could be curl, it could be a C# app, it could be a Python app, or a

server, that is a web server—Apache, Node.js, Express, anything, right? And the more data you send, the server might

actually be able to receive this data; however, the intermediate network in the middle cannot handle this much data for

one reason or another. Thus, their protocol, which is TCP, has this ability to control the congestion, right? So, and

slow start starts with a smaller window of the maximum segment packet that you can send—the size, right?—and starts with a

small size, and sends. And if we acknowledge it immediately, we start increasing and start sending that, and

then we start increasing that window, the packets we can send, and we do that until we reach the maximum size

the server can handle. And during this process, if anything, while we are increasing the window size, that packet

Size right. What will happen if any of those packets didn't acknowledge correctly, or we got double acknowledgment, or got something like...

that? We will... the TCP protocol will back... will back up and then say, okay, oh, this looks like we increased too much, and in

this case, we're gonna stop that. So, slow start is this ability to... like, we're gonna start from a small window size and

so we'll slowly increase the window size, right? So what's the problem with this? What's the good thing about it? Good

thing about it is like we kind of play with the network, say, okay, let's test the network. This test and

then it's work more like... it will test this. Okay, can you handle this? Can you handle this? Can you handle it? All looks

like you're a... no, let's increase in case, and until you kind of reach a state where you're happy with that, with the

performance, and then... and there are no lost packets or low... there are no errors, right? But during this idea, like this is

not always the case, right? Maybe during the transmission, errors might be introduced. As a result, the server gets overwhelmed,

or the server is no longer acknowledging. So the client will start reducing that congestion window size until it

reaches a comfortable window, right? So yeah, congestion control is a very interesting feature in the TCP stack. Okay, it's a feature; however, that slow

start could cause some problems, and here's why: because when I first initiate the TCP connection, three-way

handshake, and then if you have a huge payload to send immediately after initiating the request, you will feel the

performance impact because of the slow start. Let's say you're uploading a file; that file's a 1-gigabyte file,

your server and you both parties actually accept large window sizes. You have good bandwidth; you have a great big window.

sizes so you both are capable; however, because of the slow start problem, you just established the TCP connection and

you're about to send that huge file, which will be broken into smaller packets. Those packets will be

very fine and very small in the beginning because of the slow start, right? Because it's like, okay, listen,

just a few parts at first, then a few more, and then as the connection goes on, it will...

It's like warming up your car in the morning. I don't think that was...

I don't think people warm their cars anymore, or if you do, that's late. I

don't do that, right? But yeah, it's just like warming up the engine; you do it the first time, very similar.

And that's the problem with the TCP slow start. If both parties actually know that you're good and you

can handle it, I'm afraid that I don't think there's a way around the slow start TCP slow-start problem,

especially when you're sending a huge amount of data. If you're sending small packets, I don't think slow start will

affect you much. Because if you're sending a GET request—well, if you're sending GET requests and those GET

records are so small and tiny, then the request will make it to the destination server, right? Because you're

not going to break up this GET request into smaller packets unless you're sending, I don't know, a huge URL or something. A

POST request with a huge body, right? Then you might start feeling it again. This is only at the beginning of the TCP

startup, right? That's what people recommend: warming up or pre-warming the TCP connections, especially at

the proxies, if you have a proxy and those proxies have like upstream servers, you need to kind of start the TCP connection and

start sending garbage data just to warm up the client and the server. So some proxies do that actually, so they

they pre-warm this TCP connection so that whenever a fresh request comes in, we have those beautiful TCP

connections running and we can just start sending the data. So now we don't have this slow start problem in TCP.

Right, obviously that's... oh, so the TCP handshake itself takes a little bit of time, and I'm going to talk about the fast

open feature in TCP in another video and how you can speed that up. Just the handshake has nothing to do with slow

start, right? That's the fast open, fast opening there. Handshake and then this little... okay, can't... obviously, so that's

why not only opening and closing connections is expensive. As a backend engineer, if you're building... if you

have proxies, you should be aware of this. Timeouts play with those timeouts as much as possible. If you're building an

application, even talking to your other engineers, right? If you're opening an HTTP connection, I mean if you're in

the browser, you don't have to worry about any of that. What am I saying, right? The browser

takes care of opening and closing HTTP connections for us, which is awesome, right? However, if you're building your own

Python application or your own... what is it called? Electron application. I think Electron still uses a browser, so it

doesn't count. Yeah, yeah. If you're building... you don't use C-sharp because you know... Python application, you have to establish an

HTTP connection, and when you establish that TCP connection or HTTP connection, which has a TCP connection obviously if it's HTTP, one below, right? That has a

cost in it, right? Make sure you warm this connection. So if you have like a splash screen opening your application, start

those TCP connections as much as possible. Leave them open, even if you're not using them yet, right? Open them, warm them up.

Right, and so that's where I recommend eager loading versus lazy loading of the TCP connection. Lazy loading the TCP connection is not a good

idea because of those problems that we just...because TCP first, there is a three-way handshake, which can be avoided

by fast open, but again the server has to support it. And then the slow start—again, slow start only is a problem

if we're sending huge amounts of data in the beginning of the request, of the establishment of the TCP connection, right? So

yeah, I'm gonna make another video. Very short; I don't want to make it longer than that. That's the idea of a slow

start. It is a feature in TCP; however, just pay attention to it. Know that it exists; be aware of it as a back-end

engineer and also a front-end engineer. Be aware of these things, right? You don't have to do anything with it, but just

having the fundamental knowledge of these low-level concepts gives you an edge as an engineer, in order to tweak things. You can play with

things like...same thing with serverless, right? Serverless has this huge problem today, which is cold

start, and TCP is one of them. So Amazon and Azure and Microsoft and Google, they tried to solve this with a

lot of neat engineering—very cool engineering tricks—to solve these problems. So just keep this in mind: slow start is a feature in the TCP stack; you

don't—you cannot do much about it. We need it so we don't flood the network; the internet, without it, London will just

shut down, right? So we need this congestion control; otherwise, we're going to lose packets; otherwise, you you'll have

performance issues, so we need to control this. Right, so in the application, just be aware of the slow start feature.

property of TCP, and then just think about it while you're designing your architecture in your application.

while you're building your front-end applications. For that reason, obviously you have to kind of measure

that with the memory footprint. Having too many open TCP connections could be a better idea than having HTTP/2, which

kind of multiplexes those requests into one TCP connection. It's always a good idea. All right, guys. See you in the

next one. You guys stay awesome! What should I discuss next? Right below in the comment section below. See you. Bye!

What is TCP Slow Start and how Does it affect your Web Application Performance?

Join me as we discuss various software engineering topics with examples and add fun elements to them. We always try to learn by example here in this educational Youtube channel which we believe is the right way to learn. I love Software engineering (especially the backend) and I strive to be a better software engineer every day. Join me on this journey and let us learn together.  

All opinions, suggestions, and tips I provide in all of this channel's content are my own. Information provided is for educational purposes only. 

Consider becoming a member to support the channel
https://www.youtube.com/channel/UC_ML5xP23TOWKUcc-oAE_Eg/join

Stay awesome!
Hussein Nasser,
http://www.husseinnasser.com
Feel free to shoot me an email h@husseinnasser.com
twitter: @hnasr