3 ms·

I looked at DPDK for our GCP instances. It seems a bit fussy and, from my understanding of it, requires a second VPC for the second network interface. Also, on

I looked at DPDK for our GCP instances. It seems a bit fussy and, from my understanding of it, requires a second VPC for the second network interface. Also, one of the user-space stacks seems to be available via binary blob only. I'm hoping io_uring will be good enough for higher QPS. One concern with custom HTTP handling is that HTTP/2 and HTTP/3 seem to be non-trivial to hand-roll. HTTP/1 is a pretty simple request-reply design.

tsimionescu 6y ago
HTTP is normally handled entirely in user space, both on the client and the server side, so I don't think it has much to add to this discussion.
- secondcoming 6y ago
  How do you think the packets containing HTTP information get to user space?
  - tsimionescu 6y ago
    I mean, the TCP/IP stack doesn't normally know much about what the TCP payload is. For example, there is no logic in the TCP/IP stack that implements the TLS side, no logic that knows about what an HTTP header is, no logic that knows how HTTP/2 multiplexes requests over TCP connections etc. Sure, the kernel is implementing the TCP/IP stack, but once the right socket has been identified based on IP address and TCP port, and once the packet has been re-assembled, all checksums verified, and the ACK sent to the sender, the bytes of the TCP payload are delivered to the user-space read() or equivalent call, and it's up to user space code to interpret that as an encrypted HTTP request or response, decide if the entire request has been received etc. This is why OpenSSL or GnuTLS are libraries that you can find on your system. And the actual HTTP implementation is part of Apache or NGINX or other web servers, or by browsers and other clients.
    - secondcoming 6y ago
      Did you read the article?
      - tsimionescu 6y ago
        What part of the article do you think contradicts my explanation? Edit: maybe I still wasn't clear enough. All I'm saying is that, whether the TCP/IP stack is in kernel or user space, the specific HTTP(S) handling is always in user-space in all OSS that I know of - so there is no choice to be made for HTTP itself in this regard. You can put any HTTP 1, 2 or 3 implemention that you like over either DPDK or the traditional Linux TCP/IP stack.
      - dang 6y ago
        Could you please review the site guidelines? https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html They explicitly ask commenters not to post like this.
deathanatos 6y ago
> HTTP/2 and HTTP/3 seem to be non-trivial to hand-roll. HTTP/1 is a pretty simple request-reply design. HTTP/1 has enough edge-cases to balance that scale back out: * chunked transfer encoding; there can be extensions with chunks * trailers (headers that appear after the body) * Expect & 100-continue can mean >1 "response" for a single request; also, you can't process this header for a HTTP/1.0 client, as it didn't exist then. (And you can't send it inadvertently to a /1.0 server, as you'll never get a 100-continue back!) * HEAD is an absolute anomaly in terms of handling the response-body; you have to know you sent the HEAD, as the response will likely contain something like "Content-Length: 100" but there won't be 100 bytes of body to follow. * If you handle obs-folded headers, obs-folded headers. Though, they're now an optional part of the specification, as they're obsolete. (But in that case, one still has to correctly 400 the request.) Some of these exist, of course, in some manner in HTTP/2, but they're often more straight-forward to parse due to the binary nature of the protocol.
aloknnikhil 6y ago
> It seems a bit fussy and, from my understanding of it, requires a second VPC for the second network interface Curious, why would it need a second VPC? DPDK, albeit on AWS, allows me to attach a second NIC to the instance on the same VPC.
- jrwr 6y ago
  GCE does not allow one instance to have two nics on the same VPC

tsimionescu 6y ago

HTTP is normally handled entirely in user space, both on the client and the server side, so I don't think it has much to add to this discussion.

secondcoming 6y ago
How do you think the packets containing HTTP information get to user space?
- tsimionescu 6y ago
  I mean, the TCP/IP stack doesn't normally know much about what the TCP payload is. For example, there is no logic in the TCP/IP stack that implements the TLS side, no logic that knows about what an HTTP header is, no logic that knows how HTTP/2 multiplexes requests over TCP connections etc. Sure, the kernel is implementing the TCP/IP stack, but once the right socket has been identified based on IP address and TCP port, and once the packet has been re-assembled, all checksums verified, and the ACK sent to the sender, the bytes of the TCP payload are delivered to the user-space read() or equivalent call, and it's up to user space code to interpret that as an encrypted HTTP request or response, decide if the entire request has been received etc. This is why OpenSSL or GnuTLS are libraries that you can find on your system. And the actual HTTP implementation is part of Apache or NGINX or other web servers, or by browsers and other clients.
  - secondcoming 6y ago
    Did you read the article?
    - tsimionescu 6y ago
      What part of the article do you think contradicts my explanation? Edit: maybe I still wasn't clear enough. All I'm saying is that, whether the TCP/IP stack is in kernel or user space, the specific HTTP(S) handling is always in user-space in all OSS that I know of - so there is no choice to be made for HTTP itself in this regard. You can put any HTTP 1, 2 or 3 implemention that you like over either DPDK or the traditional Linux TCP/IP stack.
    - dang 6y ago
      Could you please review the site guidelines? https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html They explicitly ask commenters not to post like this.

deathanatos 6y ago

> HTTP/2 and HTTP/3 seem to be non-trivial to hand-roll. HTTP/1 is a pretty simple request-reply design. HTTP/1 has enough edge-cases to balance that scale back out: * chunked transfer encoding; there can be extensions with chunks * trailers (headers that appear after the body) * Expect & 100-continue can mean >1 "response" for a single request; also, you can't process this header for a HTTP/1.0 client, as it didn't exist then. (And you can't send it inadvertently to a /1.0 server, as you'll never get a 100-continue back!) * HEAD is an absolute anomaly in terms of handling the response-body; you have to know you sent the HEAD, as the response will likely contain something like "Content-Length: 100" but there won't be 100 bytes of body to follow. * If you handle obs-folded headers, obs-folded headers. Though, they're now an optional part of the specification, as they're obsolete. (But in that case, one still has to correctly 400 the request.) Some of these exist, of course, in some manner in HTTP/2, but they're often more straight-forward to parse due to the binary nature of the protocol.

aloknnikhil 6y ago

> It seems a bit fussy and, from my understanding of it, requires a second VPC for the second network interface Curious, why would it need a second VPC? DPDK, albeit on AWS, allows me to attach a second NIC to the instance on the same VPC.

jrwr 6y ago
GCE does not allow one instance to have two nics on the same VPC