Developing the fastest HTTP/2 server

This document discusses how to architect WebRTC applications for scalability. It begins by outlining some of the challenges in building scalable WebRTC apps. It then presents 4 approaches to building apps: 1) To the WebRTC standard, 2) Unbundled WebRTC, 3) Using open-source media servers, and 4) Using communications platform as a service (CPaaS). Each approach has tradeoffs around cost, difficulty, and features included. The document also discusses using selectice forwarding units or multipoint control units to scale apps and considers architectures using orchestration and containers. It concludes with recommendations around optimizations, load testing, and future technologies.

This document provides an overview of the Masakari project in OpenStack. Masakari is an instances high availability service that automatically recovers instances from failures. It aims to provide high availability for instances, especially for applications being migrated to the cloud. The document discusses Masakari's architecture, features, community, and how to get involved in contributing to the project.

Daniel Stenberg explains HTTP/3 and QUIC at GOTO 10, January 22, 2019. This is the slideset, see https://daniel.haxx.se/blog/2019/01/23/http-3-talk-on-video/ for the video. HTTP/3 is the designated name for the coming next version of the protocol that is currently under development within the QUIC working group in the IETF. HTTP/3 is designed to improve in areas where HTTP/2 still has some shortcomings, primarily by changing the transport layer. HTTP/3 is the first major protocol to step away from TCP and instead it uses QUIC. Why the new protocols are deemed necessary, how they work, how they change how things are sent over the network and what some of the coming deployment challenges will be. As you will see in this film, there are a lot of questions from an interested and educated audience. Daniel Stenberg is the founder and lead developer of the curl project. He has worked on HTTP implementations for over twenty years. He has been involved in the HTTPbis working group in IETF for ten years and he worked with HTTP in Firefox for years before he left Mozilla. He participates in the QUIC working group and is the author of the widely read documents ”HTTP2 explained” and ”HTTP/3 explained”.

Trabajo de fin de Ciclo Formativo Grado Superior en Administración de Sistemas en red (ASIR/ASIX). El trabajo consiste en un proyecto de virtualizacion de servidores para dar una alta disponibilidad (HA) mediante el sistema Proxmox. El servicio a dar en cuestión finalmente fue de un servidor proxy y web, por falta de tiempo y problemas con la configuración de Zentyal, fue imposible su instalación.

The document discusses protocols and the TCP/IP protocol suite. It describes protocols as mutually agreed upon conventions and rules that allow different computer systems to communicate. It introduces the concept of a layered protocol architecture with different layers providing services to upper layers. It then provides examples of the OSI reference model and the widely used TCP/IP protocol suite as standard protocol architectures. The TCP/IP model includes layers for applications, transport, internet, and network access. Key protocols discussed are IP, TCP, UDP, and several application layer protocols.

Backroll is not only a production-grade KVM backup solution. It is also being integrated inside Apache Cloudstack using the Backup and restore framework. Pierre and Quentin will show how it works, the feature list, and how the integration has been made. Quentin is in charge of DIMSI custom developments on Apache Cloudstack deployment : customer portal, backup solution. On a daily basis, he helps our customers and our developers to use and embrace Devops methodology, by building CI/CD pipelines (GitLab, Azure Devops), dockerizing apps and automate things as much as possible... When not DevOps'ing, Quentin loves to binge watch series and movies, play with his cat "Boogie" and is a crazy fan of street food.  Grégoire is a software architect who spends most of his time designing infrastructure applications and CRM systems, on-premise or multi-cloud based. He’s been using Apache Cloudstack for many years, and likes to keep knowledge and data outside black-boxes Father of 4 children, you can meet him in Southern Brittany, sailing Hobbie Cat or supporting Lorient football club at Moustoir stadium. Pierre is in charge of Backroll integration inside Cloudstack. Pierre has a proven track record of successful c# and Java projects. When not playing with his keyboard, Pierre is surfing, WingFoiling or bodyboarding on Brittany coast. ----------------------------------------- CloudStack Collaboration Conference 2022 took place on 14th-16th November in Sofia, Bulgaria and virtually. The day saw a hybrid get-together of the global CloudStack community hosting 370 attendees. The event hosted 43 sessions from leading CloudStack experts, users and skilful engineers from the open-source world, which included: technical talks, user stories, new features and integrations presentations and more.

Philipp explains the best performing Open Source software-defined storage software available to Apache CloudStack today. It consists of two well-concerted components. LINSTOR and DRBD. Each of them also has its independent use cases, where it is deployed alone. In this presentation, the combination of these two is examined. They form the control plane and the data plane of the SDS. We will touch on: Performance, scalability, hyper-convergence (data-locality for high IO performance), resiliency through data replication (synchronous within a site, 2-way, 3-way, or more), snapshots, backup (to S3), encryption at rest, deduplication, compression, placement policies (regarding failure domains), management CLI and webGUI, monitoring interface, self-healing (restoring redundancy after device/node failure), the federation of multiple sites (async mirroring and repeatedly snapshot difference shipping), QoS control (noisy neighbors limitation) and of course: complete integration with CloudStack for KVM guests. It is Open Source software following the Unix philosophy. Each component solves one task, made for maximal re-usability. The solution leverages the Linux kernel, LVM and/or ZFS, and many Open Source software libraries. Building on these giant Open Source foundations, not only saves LINBIT from re-inventing the wheels, it also empowers your day 2 operation teams since they are already familiar with these technologies. Philipp Reisner is one of the founders and CEO of LINBIT in Vienna/Austria. He holds a Dipl.-Ing. (comparable to MSc) degree in computer science from Technical University in Vienna. His professional career has been dominated by developing DRBD, a storage replication software for Linux. While in the early years (2001) this was writing kernel code, today he leads a company of 30 employees with locations in Austria and the USA. LINBIT is an Open Source company offering enterprise-level support subscriptions for its Open Source technologies. ----------------------------------------- CloudStack Collaboration Conference 2022 took place on 14th-16th November in Sofia, Bulgaria and virtually. The day saw a hybrid get-together of the global CloudStack community hosting 370 attendees. The event hosted 43 sessions from leading CloudStack experts, users and skilful engineers from the open-source world, which included: technical talks, user stories, new features and integrations presentations and more.

This document provides an overview of bandwidth estimation in the Janus WebRTC server. It discusses: - The importance of bandwidth estimation and congestion control for real-time media like WebRTC. - Challenges in applying existing bandwidth estimation algorithms designed for endpoints (like GCC) to servers that don't generate their own media. - An approach taken in Janus to develop a simpler, ad-hoc bandwidth estimation technique for servers based on acknowledged rate, losses, and delays - without relying on existing complex standards-track algorithms.

This is the slide deck I presented at the first CommCon event in the UK: it goes through some of the possible strategies for scaling WebRTC applications, mostly if you're using Janus but not only.

Presentation done at Amoocon 2010, Rostock, Germany - how to do SIP routing in Kamailio using embedded Lua interpreter.

This document discusses using Janus, an open-source WebRTC server, to facilitate access to Asterisk-based services from WebRTC. Janus acts as a gateway between legacy technologies like Asterisk and newer WebRTC technologies. It handles the WebRTC signaling and media processing, taking this load off of Asterisk. This allows Asterisk to focus on other tasks while Janus manages scaling of WebRTC services separately. Janus also provides benefits like supporting new WebRTC features that older systems like Asterisk 11/12 may not support yet.

Slides for the talk I made at the virtual edition of FOSDEM 2022, on how to use WHIP for WebRTC broadcasting ingestion, and how the distribution process could be done via WebRTC as well, e.g., via Janus (and the SOLEIL architecture).

Presentation from SCALE 17x (https://www.socallinuxexpo.org/scale/17x/presentations/fast-http-string-processing-algorithms): There are binary optimizations in HTTP/2, so the protocol becomes less about string processing. However, strings, sometimes quite large like URI or Cookie, stil exists in HTTP. A typical program working with HTTP, must perform various string operations, e.g. tokenization, string matching, searching for a pattern etc. Classic computer science describe many string processing algorithms, but HTTP strings are special and specialized algorithms can improve performance of the strings processing in several times. This talk describes: * How HTTP flood may make you HTTP parser the bottleneck x86-64 issues with branch mispredictions, caching and unaligned memory access * C compiler optimizations for multi-branch statements and autovectorization * switch-driven finite state machines (FSM) versus direct jumps (e.g. Ragel) * what makes HTTP strings special and why LIBC functions aren't good * strspn()- and strcasecmp()-like algorithms for HTTP strings using SSE and AVX * efficient custom filtering to prevent injection attacks using AVX * the cost of FPU context switch and how the Linux kernel works with SIMD * all the topics are illustrated with microbenchmarks

This document discusses media handling in FreeSWITCH. It covers topics like audio codecs, transcoding, codec negotiation, bypass media, proxy media, and Sangoma transcoding. The document provides details on common audio codecs supported by FreeSWITCH, how transcoding works in FreeSWITCH, codec negotiation algorithms, different media modes like bypass and proxy media, and Sangoma hardware transcoding cards. It aims to give an overview of key concepts around media and codecs in FreeSWITCH.

This document discusses using SIP and WebRTC together. It introduces Janus, an open-source WebRTC server with a modular plugin architecture. One plugin enables SIP gatewaying, allowing WebRTC clients to communicate with SIP networks without needing a SIP stack in the browser. The plugin handles SIP internally while exposing a simpler JSON API to clients. This avoids issues that could arise from putting SIP directly in the browser.

This document provides instructions for installing and configuring the FreeSWITCH open source telephony platform. It summarizes FreeSWITCH's capabilities as a PBX, softswitch, or media server. It then provides step-by-step instructions for downloading, compiling, and configuring a basic FreeSWITCH installation on Linux. It also demonstrates making calls between the FreeSWITCH server and a SIP softphone client.

This document discusses building a high availability NFS cluster based on CephFS. It first explains why NFS and CephFS are useful but have limitations. It then describes using multiple active NFS servers with CephFS for reliability, performance and scalability. The document outlines using the user-space NFS server NFS-Ganesha with CephFS and HA solutions like Pacemaker, CTDB and LVS to provide redundancy and load balancing. CTDB is highlighted for providing a clustered TDB database across NFS servers with virtual IPs and automatic failover.

Explains issues of HTTP/2, how they are to be solved, what can be done to control the protocol using ruby.

The document discusses optimizations to TCP and HTTP/2 to improve responsiveness on the web. It describes how TCP slow start works and the delays introduced in standard HTTP/2 usage from TCP/TLS handshakes. The author proposes adjusting the TCP send buffer polling threshold to allow switching between responses more quickly based on TCP congestion window state. Benchmark results show this can reduce response times by eliminating an extra round-trip delay.

Introduction to the H2O HTTP/2 server, and discusses the improvements in first-paint time from previous generation protocols

This document discusses programming TCP for responsiveness when sending HTTP/2 responses. It describes how to reduce head-of-line blocking by filling the TCP congestion window before sending data. The key points are reading TCP states via getsockopt to determine how much data can be sent immediately, and optimizing this only for high latency connections or small congestion windows to avoid additional response delays. Benchmarks show this approach can reduce response times from multiple round-trip times to a single RTT.

Presented at All Things Open 2018 Presented by Alexander Krizhanovsky with Tempesta Technologies INC 10/23/18 - 2:00 PM - Networking/Infrastructure Track

The new HTTP/2 protocol which is going to replace HTTP 1.1 was finished on February. Together with it, QUIC is being developed rapidly. Discover why are they so important for the Web and how will they influence the way we optimize the Web stack for the HTTP/2 era.

A technical description of http2, including background of HTTP what's been problematic with it and how http2 and its features improves the web. See the "http2 explained" document with the complete transcript and more: http://daniel.haxx.se/http2/ (Updated version to slides shown on April 13th, 2016)

Talk about HTTP/2, how it has been deployed, did it meet its promises and how QUIC is going to attempt to fix some of the remaining issues. Held in FOSDEM at Febyrar 2017.

This is my talk for HTML5 DevConf 2015. I describe the current status of HTTP/2 and explain how it works and what we can expect in the future.

- HTTP/2 aims to reduce HTTP response times by improving bandwidth efficiency and reducing the number of connections and messages needed. It allows requests to be multiplexed over a single connection. - While it can't reduce latency at the packet level, it aims to reduce overall response times through features like header compression, server push, and priority hints. - HTTP/2 is currently supported by major browsers and servers. Implementations so far show response time reductions of 5-60% compared to HTTP/1.1.

Intilop Corporation is a pioneer in developing and providing ‘Customizable Silicon IP’ in the area of Networking, Network Security, data storage-SAN/NAS and embedded applications that allows customers to differentiate their products and make quick enhancements. Intilop and its customers have successfully implemented these in several ASICs, SOCs, FPGAs and full-scale systems.

The document introduces HTTP/2 and discusses limitations of HTTP 1.1 including head of line blocking, TCP slow start, and latency issues. It describes key features of HTTP/2 such as multiplexing requests over a single TCP connection, header compression, and server push to reduce page load times. The presentation includes demos of HTTP/2 in Chrome dev tools and Wireshark to troubleshoot HTTP/2 connections.

The web has dramatically evolved over the last 20+ years, yet HTTP - the workhorse of the Web - has not. Web developers have worked around HTTP's limitations, but: --> Performance still falls short of full bandwidth utilization --> Web design and maintenance are more complex --> Resource consumption increases for client and server --> Cacheability of resources suffers HTTP/2 attempts to solve many of the shortcomings and inflexibilities of HTTP/1.1

This document provides instructions for upgrading a router's firmware and describes various router networking configuration options. It discusses upgrading firmware by dragging and dropping files, configuring NTP for time synchronization, using the router as a DNS server and cache, setting up DHCP for IP address leasing, implementing bandwidth management through speed limiting and queues, and using ARP for MAC address resolution.

This document provides a primer on browser networking. It begins with an introduction and overview of the target audience. The content includes an explanation of the TCP/IP network model and layers. Key aspects of TCP such as the three-way handshake, flow control, slow start, and head of line blocking are described. The history of web protocols like HTTP 0.9, HTTP 1.0, HTTP 1.1, and developments like HTTP 2.0, SPDY, and QUIC are summarized. Examples and diagrams are provided to illustrate concepts. Resources for further reading are included.

Are you tired of troubleshooting with TCPdump? The Avi Vantage Platform is here to help. Learn how you can reconsider your decades-old CPU-intensive logging tools – and gain intuitive, real-time analytics, faster time-to-resolution, modern SSL / TLS encryption, and (most importantly) happy IT teams focused on delivering applications. Watch this Avi webinar to learn: - Why TCPdump should be your tool of last resort - How headers compressed with HTTP/2, PFS, and distributed systems have rendered certain tools useless - How you can replace TCPdump with intelligent logs and analytics - How to future proof your troubleshooting tools with HTTP/3, TLS 1.3, containers and Kubernetes Watch on-demand here https://www.networkworld.com/resources/form?placement_id=de4979d3-4f46-498e-8285-2bdad91ca3fb&brand_id=512

В докладе рассказывается о расширении для стека протоколов TCP/IP в ОС Linux, которое необходимо для того, чтобы HTTPS работал в том же стеке, что TCP и IP. DDoS-атаки такого типа как HTTP-флуд на уровне приложений, как правило, подавляются HTTP-акселераторами или балансировщиками нагрузки HTTP. Однако интерфейс сокетов Linux, используемый программным обеспечением, не дает той продуктивности, которая необходима при предельных нагрузках, вызванных DDoS-атаками. HTTP-серверы на базе стеков TCP/IP в пространстве пользователя становятся популярными в связи с увеличением их эффективности, но стеки TCP/IP представляют собой масштабный и сложный код, поэтому неблагоразумно реализовывать и исполнять его дважды — в пространстве пользователя и пространстве ядра. Стек TCP/IP в пространстве ядра хорошо интегрирован со многими мощными инструментами, например IPTables, IPVS, tc, tcpdump, которые недоступны для стека TCP/IP в пространстве пользователя или требуют сложных интерфейсов. Докладчик представит решение Tempesta FW, которое передает обработку HTTPS ядру. HTTPS встроен в стек TCP/IP Linux. Исполняя функцию межсетевого экрана HTTP, Tempesta FW устанавливает набор ограничений по скорости передачи и набор эвристических правил для защиты от таких атак как HTTPS-флуд и Slow HTTP.

This document provides an introduction to IPv6 including a discussion of IPv6 addresses, headers, autoconfiguration, DNS, and the transition from IPv4. It describes key aspects of IPv6 such as the 128-bit addresses, extension headers, stateless address autoconfiguration, neighbor discovery, and duplicate address detection. The document also discusses DNS records for IPv6, transition technologies like dual-stack and tunneling, and some security considerations for IPv6 deployment.

This document summarizes a presentation about the QUIC protocol. It begins with an overview of QUIC and its goals of eliminating overhead from the strict layering of TCP, TLS, and HTTP. It then discusses problems with the traditional protocols like multiple roundtrips needed for HTTP requests, TCP handshake overhead, and inefficient usage of bandwidth. QUIC aims to address these by being UDP-based and combining connection establishment and encryption with sending and receiving data in one roundtrip or less. The presentation also covers how prior protocols like SPDY and HTTP/2 improved performance but were still bottlenecked by relying on TCP. It concludes with an explanation of bufferbloat and how excessive buffering in network nodes can increase latency and jitter.

This virtual meetup covered several topics related to RTBkit: 1. The developer spotlight featured Nicolas Emiliani, the RTB dev team lead at Motrixi, discussing getting an RTBKit installation running. 2. Attendees learned about Motrixi's traffic which includes up to 40k queries per second from US and Canada connected to several exchanges. 3. The meetup discussed isolating the RTBKit stack using a reverse proxy, important kernel parameters, and transitioning to HTTP interfaces for RTBkit 2.0.

The document discusses the performance of HTTP/2 compared to HTTP/1.1 across different network conditions. It summarizes results from testing 8 real websites under 16 bandwidth and latency combinations with varying packet loss rates. Overall, HTTP/2 performs better for document complete time and speed index, especially on slower connections, though results vary depending on the specific site and metrics measured.

QUICの標準化動向を日本語で解説。HTTP/2勉強会発表資料(2017/08/23) https://http2study.connpass.com/event/63998/

YAPC Hokkaido発表資料

slides at http2勉強会 #10

IETF報告会（5/10資料）