≡ Menu

What is SYN_SENT socket status?

  •  
  •  
  •  

Say you are troubleshooting a connectivity issue between two devices. For instance, let’s say you believe your Web Server is not able to connect to your Application Server, because you are seeing Connection timed out or Connection Refused error all over your log files. One of the easiest (yet critical) ways to check the connectivity is using netstat command. You might use netstat command something like the following:

netstat -an

or

netstat -an | grep 

The output shows all the sockets that in the system. Each socket has various status. For example, a socket can be in ESTABLISHED status or in LISTENING status. These are the good statuses.

However, if you are having a bad day, you might see this weird SYN_SENT status.

➜ ~ netstat -an | grep 23.96.52.51
tcp4 0 0 192.168.0.4.49876 23.96.52.53.22 SYN_SENT

The goal of this post is to demystify what SYN_SENT is and how you can go about fixing it.

But first let’s take a quick look at how TCP/IP works when a network connection is formed.

TCP/IP 101

 

TCP/IP (Transmission Control Protocol/Internet Protocol) is a set of protocols used to transmit and receive data. US Department of Defence invented it, and it’s been the language of the Networks since early 80s (right, some of you had not been born yet). Internet buzzes on top of TCP/IP. While the protocol was designed to work on any physical medium, practically all the networks you will deal with nowadays are Ethernet and/or WiFi.

In a distributed applications/services setup (which most of us ar dealing with), the Network architecture involved is the Client-Server architecture. Let’s first look at how this looks.

client_server

In the above diagram, Web Server is the client and Application Server is the Server. In a Client-Server architecture, the Server listens on a particular port. Ports are used to identify a particular application/program. For instance, here are some of the well-known Server applications and their port numbers.

Screen Shot 2018-08-12 at 10.06.58 PM

In our example, our application server listens on port 8080 (and incidentally is also a web server. We don’t need to dwell deep in to this fact, but as you may know, many application servers have a small footprint web server embedded in them).

 

Another quick note about how HTTP relates to TCP:

TCP/IP uses a 5 layer reference model (This is little different from the original 7 layer OSI model).

HTTP is an application layer protocol. And it relies on underlying TCP protocol in the transport layer. To lay this out approximately:

Screen Shot 2018-08-12 at 9.32.43 PM

Digging deep into a TCP Connection

 

TCP is a connection-oriented transport service (unlike UDP – User Datagram Protocol, which is a connection-less transport service). What do I mean by connection-oriented transport service? I mean the following:

  1. It ensures guaranteed data delivery to the destination
  2. It has built-in error checks. And in case of errors, the protocol provides for re-transmission of data
  3. The order of the data packets are guaranteed to be accurate.

When the client initiates a connection to Server, there is a three-way handshake happening. here’s what’s going on.

tcp-hand-shake

  1. First client sends a TCP segment with SYN control bit (synchronize) set.
  2. If server receives client’s data (Yay!!), it sends acknowledgement along with its own SYN request
  3. Client sends acknowledgement. Connection is established.

 

Checking the status of a TCP connection

 

A TCP connection progresses through several statuses.

LISTEN

SYN-SENT

SYN-RECEIVED

ESTABLISHED

FIN-WAIT-1

FIN-WAIT-2

CLOSE-WAIT

CLOSING

LAST-ACK

TIME-WAIT

CLOSED

You can reveal a connection status by using netstat.

netstat -an

You would typically be grepping the output of netstat for your remote IP address.

➜ ~ netstat -an | grep 23.96.52.51 

tcp4 0 0 192.168.0.4.49876 23.96.52.53.22 SYN_SENT

Now, based on the knowledge you’ve gained so far, you can readily tell that this connection is waiting for the server to respond. This most probably means the client’s request never got to the Server. And 99% of the time, this indicates some sort of Network block due to a firewall.

fw

Note that the SYN_SENT status will not remain for long time. It only lasts for couple of seconds. So, you have to be quick in running the netstat command (perhaps in another terminal window)

There you have it. Next time when you see SYN_SENT, you know who to reach out to. Your Network team. 🙂

Good luck.


  •  
  •  
  •  

Comments on this entry are closed.