Right now, there's a high coupling between front and back sockets in most proxy implementations, especially due to the BufferQueue implementation and the HTTP implementation.
For HTTP/2 it would be useful to separate protocol halves, ie:
server for HTTP 1 front
client for HTTP 1 back
server for HTTP/2 front
client for HTTP/2 back
pipe (should be the same for both front and back)
We could still keep some specific implementations, to keep good performance for the HTTP 1 only proxy, or to reintroduce TCP splicing.
This work would pave the way for easy integration of new protocols, like GRPC or MQTT.
The most pressing issue: separating front and back HTTP 1 implementations.
We will then be able to reuse parts of it for backend connections in the HTTP/2 proxy.
Right now, there's a high coupling between front and back sockets in most proxy implementations, especially due to the BufferQueue implementation and the HTTP implementation.
For HTTP/2 it would be useful to separate protocol halves, ie:
We could still keep some specific implementations, to keep good performance for the HTTP 1 only proxy, or to reintroduce TCP splicing.
This work would pave the way for easy integration of new protocols, like GRPC or MQTT.
The most pressing issue: separating front and back HTTP 1 implementations. We will then be able to reuse parts of it for backend connections in the HTTP/2 proxy.