TCP Slow Start: Feature, Problem, and Solutions for Backend Engineers

혼잡 제어 기능인 TCP 느린 시작은 처음에는 데이터 전송을 제한하다가 점차 증가하여 대용량 파일을 전송할 때 성능에 영향을 줍니다.

### TCP 느린 시작: 웹 애플리케이션 성능에 미치는 영향
* 💡 TCP 느린 시작은 **네트워크 혼잡을 제어**하기 위해 도입된 TCP 프로토콜의 기능입니다.  클라이언트가 서버에 데이터를 전송할 때 중간 네트워크 과부하를 방지하는 역할을 합니다.
* 📈 초기에는 작은 **최대 세그먼트 크기(MSS)**로 시작하여, 확인 응답을 받으면 점진적으로 창 크기를 늘려 데이터 전송량을 증가시킵니다.  
* ⚠️  하지만 이 과정에서 패킷 손실이나 오류가 발생하면 창 크기가 줄어들어 성능 저하가 발생할 수 있습니다. 특히 **대용량 파일 업로드** 시 초기 전송 속도가 느려지는 현상이 나타납니다.
* 🚗 이는 자동차 엔진 예열과 유사하며, 처음 TCP 연결을 설정할 때 **대량의 데이터 전송** 시 성능에 영향을 미칠 수 있습니다.
* 🤔  **해결책**으로는 TCP 연결을 미리 열어두고(프록시 서버에서 활용)  가상 데이터를 전송하여 "워밍업"하는 방법이 있습니다.  이는 특히 **프록시 서버**에서 유용합니다.
* 🤝  **백엔드 엔지니어**는 애플리케이션 설계 시 TCP 느린 시작을 고려해야 합니다.  대용량 데이터 전송 시 초기 성능 저하를 예상하고 이를 완화할 수 있는 전략을 세워야 합니다.
* ⏳ TCP 핸드셰이크 자체에도 시간이 소요되며, 이는 느린 시작과는 별개의 문제입니다.  **FastOpen** 기능을 사용하면 핸드셰이크 시간을 단축할 수 있습니다.
* 💡  결론적으로 TCP 느린 시작은 네트워크 혼잡 방지를 위한 필수 기능이지만, 대용량 데이터 전송 시에는 성능 저하를 유발할 수 있으므로 **애플리케이션 설계 시 주의**해야 합니다.

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

Hussein Nasser

TCP 느린 시작(Slow Start) 기능 소개 및 목적

TCP 느린 시작은 의도적으로 설계된 기능이며, 버그가 아님

네트워크 혼잡 제어를 위한 기능으로, 클라이언트에서 서버로 전송되는 데이터 양을 조절

클라이언트는 브라우저, curl, C# 앱, Python 앱 또는 웹 서버(Apache, Node.js 등)일 수 있음

최대 세그먼트 패킷 크기의 작은 창으로 시작하여, 확인 응답을 받으면 창 크기를 증가시키며 데이터 전송

패킷 확인 응답 실패 시 창 크기 감소

네트워크 용량을 테스트하고, 최적의 성능을 위한 창 크기를 조정하는 과정

전송 중 오류 발생 시 서버 과부하 또는 확인 응답 실패로 창 크기 감소

초기 TCP 연결 시 대량의 데이터 전송 시 성능 저하 발생 가능성

1GB 파일 업로드 시 느린 시작으로 인한 초기 전송 속도 저하 예시

느린 시작 문제 해결 방안 및 고려 사항

소량의 데이터 전송에는 영향이 적음

TCP 연결 초기 시작 시에만 문제 발생

프록시 서버에서 TCP 연결 미리 연결하여 성능 향상

백엔드 엔지니어는 연결 관리 및 타임아웃 설정 중요성 인지 필요

TCP 연결 지연 로딩보다 즉시 로딩 권장

느린 시작은 TCP의 중요한 기능이며, 네트워크 혼잡 방지에 필수적

서버리스 환경의 콜드 스타트 문제와 유사하며, 클라우드 제공업체들의 해결 노력 언급

애플리케이션 설계 시 느린 시작 고려 및 메모리 사용량과의 균형 필요