Design Exercise: A Generic Network Protocol

I spent some idle time thinking about the topic lately, and I think that this can be a pretty good blog post. The goal is to have a generic application level network protocol for client/server and server/server communication. There are a lot of them out there, and this isn’t actually design work that I intend to implement. It is a thought exercise that run through a lot of the reasoning behind the design.
There are network protocols that are specific for a purpose, and that is reflected in a lot of hidden assumptions they have. I’m trying to conceive of a protocol that would be generic enough to be used for a wide variety of cases. Here are the key points in my thinking.


HTTP/2 Server Push

The new version of the HTTP protocol, HTTP/2 lets the server to push content to the client before the client requests the particular content. There are many other modifications in the protocol if we compare the previous version 1.1 with the new version 2, but, in this article, I will focus on the push functionality. I will discuss briefly how it can be used in a servlet, and I will also discuss a bit about how to test and see that it really works at all or not. Before writing this article my original intention was to create a demonstration of HTTP/2 showing how much faster the sample page load is with the push than it is without. It is going to be one chapter in my video tutorial that is published by PACKT. During the development of the sample application I faced several problems, I have read some tutorials and debugged the sample code a bit using what I gathered during this experience. In this article, I share this experience with you. That way this article is a bit more than just a simple introductory tutorial. Nevertheless, it is also a bit longer, so TLDR; if you are impatient.
HTTP Versions
HTTP/2 is a new version of the HTTP protocol. The protocol had three versions prior to 2. They were 0.9, 1.0, and 1.1. The first one was only an experiment starting in 1991. The first real version was 1.0 released in 1996. This was the version that you probably met if you were using the internet at that time and you still remember the Mosaic browser. This version was soon followed by version 1.1 in 1997. The major difference between 1.0 and 1.1 was the Host header field that made it possible to operate several websites on one machine, one server, one IP address, and one port.


Musings on HTTP/2 and Bundling

HTTP/2 has been one of my areas of interest. In fact, I’ve written a few articles about it just in the last year. In one of those articles I made this unchecked assertion:
If the user is on HTTP/2: You’ll serve more and smaller assets. You’ll avoid stuff like image sprites, inlined CSS, and scripts, and concatenated style sheets and scripts.
I wasn’t the only one to say this, though, in all fairness to Rachel, she qualifies her assertion …

Musings on HTTP/2 and Bundling is a post from CSS-Tricks


HTTP/2: How to Get Ready for the Future

HTTP/2 is the future of browser communication, and as such, it offers many opportunities to users, developers, and DevOps. Read this blog post to learn how HTTP/2 works, what makes it better than HTTP/1.1 (or maybe not) and where it still needs to improve.
A Brief History of HTTP, HTTP/1.1, SPDY, and HTTP/2
HTTP, or Hypertext Transfer Protocol, is the method of communication used by browsers to communicate to web servers. The most commonly used version of HTTP is HTTP/1.1, which was introduced in 1997. However, its last major release was in 1999, when browsers were a different animal, not to mention the concept of the Internet as a whole. Today’s websites contain more data and resources than before, sometimes hundreds of them, and they are generally larger in size because they are much more interactive and contain more components and elements. HTTP/1.1 isn’t able to deal with all of these improvements, and communication is slower and more complex than necessary.


ES6 modules support lands in browsers: is it time to rethink bundling?

Modules, as in, this kind of syntax right in JavaScript:
import { myCounter, someOtherThing } from ‘utilities’;
Which we’d normally use Webpack to bundle, but now is supported in Safari Technology Preview, Firefox Nightly (flag), and Edge.
It’s designed to support progressive enhancement, as you can safely link to a bundled version and a non-bundled version without having browsers download both.
Stefan Judis shows:

<script src=”app/index.js" type="module"></script>
<!– in case ES6 modules …

ES6 modules support lands in browsers: is it time to rethink bundling? is a post from CSS-Tricks


HTTP/2 With Server Push Proof of Concept for ASP.NET Core HttpSysServer

Recently I’ve been playing a lot with HTTP/2 and with ASP.NET Core but I didn’t have a chance to play with both at once. I’ve decided it’s time to change that. Unfortunately, the direct HTTP/2 support for Kestrel is still in backlog as it this blocked due to its missing ALPN support in SslStream. You can get some of the HTTP/2 features when using Kestrel (like header compression or multiplexing) if you run it behind a reverse proxy like IIS or NGINX but there is no API to play with. Luckily Kestrel is not the only HTTP server implementation for ASP.NET Core.
HttpSysServer (Formerly WebListener)
The second official server implementation for ASP.NET Core is Microsoft.AspNetCore.Server.WebListener which was renamed to Microsoft.AspNetCore.Server.HttpSys in January. It allows exposing ASP.NET Core applications directly (without a reverse proxy) to the Internet. Under the hood, it’s implemented on top of the Windows Http Server API which on one side limits hosting options to Windows only but on the other allows for leveraging the full power of Http.Sys (the same power that runs the IIS). Part of that power is support for HTTP/2 based on which I’ve decided to build a proof of concept API.