Tcp Notes

== Http Keep Alive == so, how http request and response works before http 2 is for each request a new tcp connection is opened. so, like for example to fetch a webpage, one will fetch the html, next the style, in next the other resources like images. we can see there are multiple tcp connection just to fetch a single web page. what keep alive header does is it notifies the server to not close the tcp connection after sending the response, so this way client can ask for more resources on the same underlying tcp connection, there’s a term for this, can’t remember rn. in http 2 it’s the default behavior, client can send multiple request without need to open new connections. the header was was mostly prevalent in http 1.1, from what i remember http 1.2 also added this as default behavior…

also, a http server can have a timeout which will close the underlying tcp connection, if it receives no request within some time(but it’s a server impl specific thing, when it will close the tcp connection) one thing to note here is this, timeout is not tcp’s specification, it’s the server’s impl. the server ask asks tcp socket to close itself, which sends the required fin packets to the other side to notify it going to close itself.

== tcp keep alive == now we are getting somewhere, this is a different concept altogether. but for it to understand we need to know a bit more about tcp,

== tcp connection ==

tcp is a connection oriented protocol. and when we say “connection oriented”, tcp follows that strictly. so, if a handshake is done, the connection will remain till eternity, that’s in theory in practice os has some checks which will close the connection after some time, in one exp done by some guys, a tcp connection remain opened more than 48 hours without any activity. so, how do we know if a connection is broken, by writing to it. Broken connection, can occur due to broken link in low layers. like wifi got disconnected, or ethernet unplugged, etc… when we write to a tcp socket with a broken connection, tcp still assumes that the connection is there, so it will try to write to that, but when it writes, it won’t receive the ack back since the connection is actually broken. we can configure for how much time it should wait till an ack comes(SO_TIMEOUT), and concluding the connection is broken and closing it. also many packets it should send, before concluding we are getting no ack, and connection is broken, but they are “os configs”, for more info, https://blog.cloudflare.com/when-tcp-sockets-refuse-to-die/

so how does, keep alive fit in here, keep-alive is a way to detect if the connection is broken, how??? it’s easy you just send some keep alive packets at regular intervals, if there’s no activity. keep-alive’s no activity time is also “os specific”. like, after how much inactivity keep alive packet should be sent.

also, as i said the connection is always there, a broken tcp connection can be restored without creating new connection/handshake. let’s suppose, the link got broken, but non of the side tried to write anything. so, for both of them the connection is there, now let’s suppose the link got fixed and we send some packet. the old connection will just work seamlessly…

ok one last thing what is, == java’s read timeout == java’s socket read timeout is nothing more than a timeout for block read. when you call read on java socket it blocks the call till it read anything, we can set a read timeout there, if it didn’t read anything in the given time it will just throw read timeout exception. but it does not close the underlying socket. we can again issue read on the socket. it is useful when multithreading, and you don’t want to block the thread, so you can set some read timeout and if we didn’t read anything, we can go on to do something else and again come back and issue the read again on the socket…

== points to remember == when i said, os specific they are os specific, you can’t set these things from java/jvm… and it’s obvious in different os you have different ways to set them, sometimes they are so obfuscated it’s hard to change… for more info, https://blog.cloudflare.com/when-tcp-sockets-refuse-to-die/