Hypertext Transfer Protocol Version 2.0 (HTTP/2)
Hypertext Transfer Protocol (HTTP) has been the de facto Internet protocol since the late 1990s because of its ability to carry connections across IPv4 NAT middleboxes. People have tried to improve HTTP by adding persistent connections and connection reuse (HTTP version 1.1 [RFC 2068]) and security (HTTP Secure (HTTPS) with SSL, and then TLS).
One such effort to reduce the latency of HTTP connections was SPDY (pronounced as "SPeeDY"). SPDY was a research effort by Google to improve the speed of the Chrome browser. SPDY has multiplexed streams to allow for simultaneous fetches, request prioritization, HTTP header compression, and server push. This work on SPDY has now led to the newest optimized version of HTTP.
Hypertext Transfer Protocol Version 2.0 (HTTP/2) is the most current version of HTTP that supports the SPDY features and is now an industry standard. In 2015, the HTTP/2 protocol was standardized with IETF RFC 7540. HTTP/2 has gained substantial industry support across web browsers and adopted by numerous content providers. Content delivery networks such as CloudFlare and Akamai now offer this to their customers. You may be using HTTP/2 today and not even realize it.
Quick UDP Internet Connections (QUIC)
Most web connections are established over TCP HTTP connections using TLS. This method of creating connections to fetch web page contents adds overhead and increased latency. In this fast-paced online world, every millisecond counts against excellent end-user experience and long page load times drive your customers to your competitors.
Quick UDP Internet Connections (QUIC) offers a way to create web connections of UDP that results in higher performance of UDP, but the same reliability of TCP. QUIC allows for multiplexed connections that do not require TCP's connection establishment. At last year's NANOG64 conference there was a good session titled "QUIC: Next generation multiplexed transport over UDP" by Brian Rogan and Ian Swett of Google that reviewed how QUIC worked and its benefits.
Google has been the primary proponent of QUIC and has implemented it into Chromium and the open source code is available for review. Google has published a good QUIC Geek FAC and has been working on integration into the Chrome web browser and creating a web server with QUIC integration. Google is even dog-fooding it on some of their own projects. QUIC is being proposed to the IETF and is currently in draft form, but may become a standard soon.
HTTP Strict Transport Security (HSTS)
In recent years, there has been increased awareness of Internet eavesdropping and more companies have a desire to use encryption on their primary customer-facing web sites. Despite the Heartbleed OpenSSL vulnerability in 2014, there is a greater percentage of sites using HTTP (TLS) than ever before. Initiatives such as the Let's Encrypt movement help organizations learn about how to enable HTTPS and encourage them to use TLS. Another way to help web sites negotiate HTTPS connections is to enforce this behavior through another protocol.
HTTP Strict Transport Security (HTTPS) is a policy mechanism that helps prevent web connections from falling back and downgrading to using unencrypted HTTP and for web servers to encourage web browsers to connect with HTTPS. Several years ago, HSTS was defined and standardized in an IETF RFC 6797. The web server can signal to the client that only HTTPS is allowed to interact. This is done when the web server sends a HTTP Response Header field "Strict-Transport-Security" to the web browser (user agent) indicating a preference for HTTPS. The client behaves by automatically turning any "http://" links into "https://" links. While, HSTS is not a TCP/IP transport protocol, it has the ability to influence and control how Internet connections are established and help them be more secure.
Datagram Congestion Control Protocol (DCCP)
Some Internet architects feel that TCP has too much overhead for some applications, and UDP has too few options for controlling congestion. This leaves room for protocols that occupy the middle-ground between TCP and UDP to provide options for applications that need the speed of a streaming protocol and some congestion notification, but don't need in-order packet delivery and acknowledgements.
The Datagram Congestion Control Protocol (DCCP) hopes to be this protocol that hits the sweet spot between TCP and UDP. The DCCP IETF working group created the primary DCCP (RFC 4340) and specified the DCCP service codes (RFC 5595) along with the TCP Friendly Rate Control (TFRC) (RFC 5348). DCCP has been implemented into the Linux 2.6 kernel, but has struggled to gain further adoption by vendors.