You see a web, I see:

CLIENT: TCP SYN
SERVER: TCP SYN ACK
CLIENT: HTTP Get
SERVER: HTTP Response
...
CLIENT: TCP FIN
SERVER: TCP FIN ACK

All I’m saying is that this spider has a clear understanding of Transfer Control Protocol.

--- HTTP/3 is coming! And it won't use TCP! ---

A recent announcement reveals that HTTP - the protocol used by browsers to communicate with web servers - will get a major change in version 3!

Before, the HTTP protocols (version 1.0, 1.1 and 2.2) were all layered on top of TCP (Transmission Control Protocol).
TCP provides reliable, ordered, and error-checked delivery of data over an IP network.
It can handle hardware failures, timeouts, etc. and makes sure the data is received in the order it was transmitted in.
Also you can easily detect if any corruption during transmission has occurred.
All these features are necessary for a protocol such as HTTP, but TCP wasn't originally designed for HTTP!
It's a "one-size-fits-all" solution, suitable for *any* application that needs this kind of reliability.
TCP does a lot of round trips between the client and the server to make sure everybody receives their data. Especially if you're using SSL. This results in a high network latency.
So if we had a protocol which is basically designed for HTTP, it could help a lot at fixing all these problems.
This is the idea behind "QUIC", an experimental network protocol, originally created by Google, using UDP.

Now we all know how unreliable UDP is: You don't know if the data you sent was received nor does the receiver know if there is anything missing. Also, data is unordered, so if anything takes longer to send, it will most likely mix up with the other pieces of data. The only good part of UDP is its simplicity.
So why use this crappy thing for such an important protocol as HTTP?
Well, QUIC fixes all these problems UDP has, and provides the reliability of TCP but without introducing lots of round trips and a high latency! (How cool is that?)

The Internet Engineering Task Force (IETF) has been working (or is still working) on a standardized version of QUIC, although it's very different from Google's original proposal.
The IETF also wants to create a version of HTTP that uses QUIC, previously referred to as HTTP-over-QUIC. HTTP-over-QUIC isn't, however, HTTP/2 over QUIC.
It's a new, updated version of HTTP built for QUIC.

Now, the chairman of both the HTTP working group and the QUIC working group for IETF, Mark Nottingham, wanted to rename HTTP-over-QUIC to HTTP/3, and it seems like his proposal got accepted!
So version 3 of HTTP will have QUIC as an essential, integral feature, and we can expect that it no longer uses TCP as its network protocol.

We will see how it turns out in the end, but I'm sure we will have to wait a couple more years for HTTP/3, when it has been thoroughly tested and integrated.

Thank you for reading!

"We don't need to invest in security - noone is going to hack us anyway" == "We don't need a fire department in our city - fire is not going to start here anyway"

We don't need to invest in security - everything is public anyway" == "We don't need a fire department in our city - our buildings are made out of straws anyway"

-- my thoughts after seing a line in client's spec: "sensitive data is transferred via a secure tcp channel (https) and all the public data is transferred via an unencrypted tcp (http) channel"

Some companies be like-

.. In job posting - We are the next big thing. We are going to change the industry. We are like Google / Facebook etc...

..in Introduction - We are the next big thing. We are going to change the industry. We are like Google / Facebook etc...

.. in Interviews - We are the next big thing. We are already changing the industry. Think of us like Google / Facebook etc...

.. during Interviews - Our interview process is rigorous because we are the next big thing. We are going to change the industry. We are like Google / Facebook etc...

.. questions in interviews - Since we are Google / Facebook, please answer questions on Java, C/C++, JS, react, angular, data structure, html, css, C#, algorithms, rdbms, nosql, python, golang, pascal, shell, perl...
.. english, french, japanese, arabic, farsi, Sinhalese..
.. analytics, BigData, Hadoop, Spark,
.. HTTP(s), tcp, smpp, networking,.

..

..

..

.. starwars, dark-knight, scarface, someShitMovie..

You must be willing to work anytime. You must have 'no-excuses' attitude

.........................................

Now in Salary - Oh... well... yeah... see.... that actually depends on your previous package. Stocks will be given after 24 re-births. Joining bonus will be given once you lease your kidneys.

But hey, look... We got free food.

Well, SHOVE THAT FOOD UPTO YOUR ASS.

FUCK YOU...
FUCK YOUR 'COOL aka STUPID PIZZA BEER - CULTURE'.
FUCK YOUR 'FLAT- HIERARCHY'.
FUCK YOUR REVOLUTIONARY-PRODUCT.

FUCK YOU!

First lecture of computer networks. Let's shove all of these abbreviations with their meaning, and possibly a associated port number in one 1.5 hour lecture:

HTTP, HTTPS, FTP, FTPS, SFTP, TCP, IP, UDP, ISP, DSL, DNS, LAN, WLAN, WDM, P2P, TELNET, PGP, TLS, SSL, SSH, MIME, SMTP, POP3, IMAP, IANA, DHT, RTT, DHCP

I really feel sorry for students who didn't have previous knowledge about this stuff..

By heavens creating your own api server with the Go standard lib is so easy it should be fucking criminal.

Now....on to add authentication and a nice frontend stack(prob React) to make it all spiffy and show it to my manager and see if she lets me put this shit to use at work.

It will make it more interesting. It took me nearly 1 hour to get what I needed from the docs, build it using the net package first(das right babe, pure TCP) and just a couple of minutes more for net/http and boom. Ferching info and shit left and right

Man I love this shit. Wish I could do this for a living. Stuck fucking around with css, Java and php at work instead ;____;

What does the year 2030 have in store for us?😂

So here I am reinventing the wheel making an HTTP server in C.
Finished implementing HTTP/1.1 and WebSockets support and now I find out the current thingy is HTTP/2.
Well that's fine, I'll add support for that later. In fact I kinda dig it since it uses binary conventions instead of plain text ones.
I dig a little bit and find out there already is an HTTP/3 going around which uses UDP.
Why me.

This evening for curiosity i executed a nmap over my android phone expecting (like everyday) all port closed.
But i see
9080/tcp open glrpc
Wtf??
Let me check something....
--adb shell
$cat /etc/net/tcp

And the first line provied me the UID of the app that was running on 9080 port (2378 in hex)
So let me check which app is that
$dumpsys package | grep -A1 "userId=*UID*"

And the answer is com.netflix.mediaclient

Wtf??
Why netflix is running a http server on 9080/tcp on and android phone??

When some other team wants to blame us because they're getting a HTTP Status Code 0....

That's not even a valid status... IT MEANS YOU ABORTED THE REQUEST AND KILLED THE CONNECTION...

OH STILL OUR FAULT... WELL DO U KNOW ABOUT NETWORK ISSUES AND SERVER OVERLOADING WHEN U SPAM IT WITH TOO MANY REQUESTS?

OH YOU RETRIED? HOW DID YOU RETRY? BETTER NOT BE SPAMMING US WITH MORE REQUESTS...

EVER HEARD OF TCP/IP BACK OFF LOGIC....

So client wants an android app that implements some legacy Epson printer SDK, works on a chinese Windows device with an android Emulator on it, connects to local Webservice that had to be configurated and ran (local Network) , sends and tracks data, if Server down then handle it on the Client and reconnect as soon as Server up, running own TCP Server on Android device that listens for specific http requests, which make the android connect to an Epson printer to start printing. The stuff that is being printed? A png file that has to be converted to a Bitmap, a QR Code that has to be generated by the bugged base64 encrypted stuff coming via http in (webserver-> Android TCP server)
Dont forget the Software Design (MVP), documentation, research etc.. Im about to finish the app , its my 5th day on this Project, the 6th day was planned to be full testing. Client Calls me and ask me how far I am, I reply, he says ok. 30 minutes later he tells me he wont pay me next time that much because this work should take 3 days, or even 2. "A senior Android developer could do this in 2 days"... When i sent him my notices he called me a liar, his webdev has alot of experience and told him it should take 2-3 days...ffs

*revving chainsaw noises*

Today I started nuking leftover project code.

At the end, some projects shrunk by roughly up to 40 % .

Can anyone explain to me why programmers have such an awful hoarding syndrome?

Why do you keep shit that might unleash complete havoc cause it hasn't been touched since years and noone knows id it still works?

It's like having a leg with gangrene and keeping it cause "it doesn't look that bad".

For fucks sake. Clean up and remove shit when it's not necessary anymore.

Reason why I did a bloody gore massacre in nearly a dozen projects... After all the rework of networking, it's finally evident which projects have a bad / nasty behaviour of "fucked up" connection handling (HTTP 1.1).

And when my gory massacre removal goes life, I think 25-35 % of persistent connections on the loadbalancers will vanish. Maybe even more, since some very nasty stuff was in some projects.

Like "let's implement monitoring without having any clue about how monitoring works and even less clues about how TCP/ HTTP works."

*Bangs devs heads on table*

Stop. Doing. Stupid. Things.

For fucks sake.

:@ :@

FUCK YOU FUCKING AZURE FUCKING FUNCTIONS:

EITHER LIMIT MY NUMBER OF TCP CONNECTIONS (before violently crashing)

or

FORCE ME TO USE THE GODDAMN PORT-PISSING, BARELY-MULTITHREAD-USABLE, SETTINGS-IGNORING EXCUSE OF A PATHETIC BUILT-IN HTTPCLIENT ON FUCKING CRACK (Seriously .net people fix that shit).

But not both... both are not okay!

If your azure function just moderately uses outgoing Http requests you will inevitably be fucked up by the dreaded connection exhaustion error. ESPECIALLY if using consumption plans.

I Swear, every day i am that much closer to permanently swearing off everything cloud based in favor of VM's (OH BUT THEN YOU HAVE TO MAINTAIN THE VM's BOO HOO, I HAVE TO BABYSIT THE GODDAMN CLOUD INFRASTRUCTURE AS WELL AT LEAST I CAN LOG IN TO A VM TO FIX SHIT, fuck that noise)

I am in my happy place today. At least I'm having great success diving into minecraft modding on the side, that shit is FUN!

So I just spent 2 hours debugging a script that fetches data from an API. Thats all it was supposed to do. Http get some data.

It wasnt working and was giving a "parse error". Worked fine in browser.

So it turns out it was using http 0.9 (first documented http version, defined in 1991) and wasnt sending any headers. And js cant do no headers...

So yea I now have to write a tcp / http 0.9 client in js

I would like to call out the moron who decided to control docker through HTTP when the maximum time the server can take to finish the task is longer than the HTTP timeout.
If you expect things might time out, you don't use a HTTP request. You use a resource and poll it, or Websockets, or possibly SSE.
Shoehorning your API into a frame that obviously doesn't fit doesn't help anyone. Just admit that you don't know what HTTP is and use a regular TCP socket with regular pings.

PSA: If you do reverse proxying stuff, prefer unix domain sockets over localhost internet sockets, if it's on the same machine (and if it's forwarded over ssh too). You can even serve HTTP as a unix socket.

Unix domain sockets don't have the overhead of IP, so generally speaking, data will flow to your other process with much less overhead.

I've recently stopped being lazy at this, and it's worth it.

Today I have created a server application on Python Tornado which can forward TCP Packets directly to HTTP request queue without any intermediate caching.

Our remote IOT devices (microcontrollers with sensors attached) send sensor reading over TCP Socket to our server and all the connected web applications can show the data instantly using long polling and the above mentioned technique.

So I was talking microservices architecture with some lead techs.
And I started asking how did they combine/connect their microservices.

And despite having a lot, they use HTTP as the main transporter.
So the put some API-Gateway, all inside traffic has to go through it, to connect to the final client.

And I said that I do meshing microservices, and we use Nats as man transporter, so our messages go through UDP and not TCP.

And they freaked out. Saying UDP is too low level and not useful...

My question: if you do microservices oriented architecture, and not SOA, do you use HTTP? Did you use it simply because "it works"?

I‘m currently writing a http proxy server (something like the proxy mod in Apache, but more special). One the one hand is is nice that HTTP 1.1 can use one TCP connection multiple times, but on the other hand it is very annoying. Because I need to rewrite the Host header. And therefore I need the start of the HTTP header. I solved it after some time, but now my code is more complicated than before.

Is there a cloud service that does nothing but redirect incoming HTTP requests to your home server without the need to have a static IP or an open TCP port ? Sort of like proxy

So I’m going through a CKAD course. There is a section about checking the status of our Pods or the application running in it through Readiness/Liveness Probes— they mostly use an HTTP test, but there is a TCP option as well. My question is, how will the TCP test work on HTTP/2 given that it does not have TCP (it rather uses QUIC)? Sorry if this is a dumb question.