kazuho

It is true that RSA operation over IPC is slower than doing it internally. But the latter is by magnitudes faster than the former, therefore the slowdown is negligible in practice.

You can find the numbers in the FAQ section of the linked website.

Wrong.

You seem to have confusion between TLS handshakes and RSA operations.

In OpenSSL (which is used by many servers including node.js, nginx), RSA operation is always synchronous. Therefore, using Neverbleed does not impose new limits regarding concurrency.

I assume you are referring to Keyless SSL. https://blog.cloudflare.com/keyless-ssl-the-nitty-gritty-tec...

For Keyless SSL, it is necessary to make RSA operations asynchronous, since the operations are requested over the TCP network (which may have big delays).

OTOH Neverbleed degelates the operations within the same server using Unix sockets. So there is no fear of such delays. And the server spawn a dedicated thread to each client thread. In other words, the delay is practically _no worse_ than what it is without Neverbleed.

And discussing _how worse_ it is, calculations related to TLS handshakes may block the server for a few milliseconds. It may sound bad, but generally speaking it is negligible comparing to the latency over a public network.

Libh2o (the protocol implementation) support both libuv and evloop (our tailor-made event loop).

The default event loop of libh2o is libuv, since libuv is popular and has bindings to other protocols (which you would need if you want to implement an application using libh2o).

OTOH the standalone server uses evloop for performance.

Thank you for your comment.

I doubt if anybody is using the mruby handler in production, considering the fact that functions necessary to modify the requests in the handler was committed this week :-)

Unfortunately the block was always found on the test machine. The test was conducted using a VM running running on a host on which the web browsers were run, so there were no noise or packet loss; the results were reproducible.

Thank you for the suggestion.

In case of the benchmark, I run the server as a VM instance on the client machine so that the results would be reproducible (with network latency added by `tc qdisc` command).

PS. PageSpeed is a really nice service; and I agree that it is a useful tool for evaluating the speed in the real-world.

As described in note 5, "the network chart of Chrome includes a 0.2 second block before initianting the TCP connection, which has been subtracted from the numbers written in this blog text". That explains the differences of the numbers on the charts you pointed out.

Thank you for the comment.

I think you did not understand my comment.

It is true that the software is used for MITM. It is true that _Superfish_ is in the middle, decrypting the communication.

OTOH the author claimed that it might be likely for _others_ as well to possibly MITM the communication, by using the recovered key. My comment is that such a situation is unlikely under the premise that the public-key encryption technology was used correctly (from technical standpoint, not ethical).

EDIT: Even if it was the case that the recovered private key was used by the MITM server running locally for communicating with the web browsers, it wouldn't mean that others could use the key to decrypt data transmitted over the wire by using the key, since all the communication encrypted by the key would terminate within the local machine.

EDIT2: Ah sorry, now I understand. The root certificate installed by the adware was using the recovered private key. That would mean that others can MITM the communication by DNS spoofing, etc. together with a server certificate signed with the recoverd key.

why minus votes?

While the blogpost is interesting, I am skeptical of the author's claim that the recovered private key may be used for decrypting user data transmitted over the wire, since private keys cannot be used for encrypting data sent to somebody else.

What it can all do by itself is to decrypt data sent from others, or to digitally sign some data.

I would suspect that the bundled private key was used for digitally signing data to show that it was actually generated by the software. The approach is not perfect (since the private key may get decrypted as the author did), but in general it would work effectively for kicking out third party software.

If the developer's intention was to encrypt the data transferred through the public network, then he/she should have used TLS with server-side authentication, with optionally using clear-text credentials transmitted over the encrypted channel to authenticate the software (e.g. basic authentication over HTTPS).

If it gets proved that private information could be decrypted from data transmitted over the public network by using the recovered private key, then this would be an interesting case of misusing public-key cryptography.

A new product by frsyuki, the original developer of Fluentd / MessagePack.

His presentation slides can be found at http://www.slideshare.net/frsyuki/embuk-making-data-integrat...

Kind of off-topic, but I wonder when they will release OpenSSL 1.0.2.

1.0.2 includes important fixes (e.g. support for ALPN which is mandatory in HTTP/2, adds support for cross-root certificate validation).

Yes, assuming that you wanted to say: "web-browser connect to H2O via HTTPS".

Sorry for the confusion.

HTTP and HTTPS (both version 1 and 2) are supported for downstream connections (i.e. connection bet. H2O and web browsers). Only plain-text HTTP/1 is supported for upstream connections (connection bet. H2O and web application servers).

Contributors are highly welcome, obviously!

For myself, developing H2O is part of my job at DeNA (one of the largest smartphone game providers in Japan).

Thank you for the comments.

The configuration file format is YAML, and the directives can be seen by running `h2o --help` (the output of version 0.9.0 is: https://gist.github.com/kazuho/f15b79211ea76f1bf6e5).

Unfortunately they are not compatible with that of Nginx. I do not think it is possible to take such approach considering the differences in the internals of both servers.

The author claims roughly 2x performance when compared against Unicorn. https://twitter.com/kazeburo/status/545034467190898688

I am sorry to point this out, but the patent license of Proxygen does not look similar to that of Apache License for two reasons.

- the license is terminated when one files a claim against _any_ of Facebook's software or services (IIRC Apache License gets terminated only when filed against the software)

- the license also terminates when you claim that "any right in any patent claim of Facebook is invalid or unenforceable"

The second clause seems very agressive (or pro-patent) to me, which makes me feel sorry for the developers of Proxygen, since IMO such a clause would harm the acceptance of the software outside Facebook.

It would be great if you reconsider the patent license.

Disclaimer: I am developer of H2O, an open-source HTTP/1 and HTTP/2 library, so there is obviously a conflict of interest here. But I wanted to leave a comment anyways since, honestly, I feel sorry if my friends at Facebook needs to go with this kind of license.

Presentation slides at HTTP/2 conference by the developer. See also: https://news.ycombinator.com/item?id=8342131

That's a very good question.

My understanding is that the main motivation behind the introduction of iostream was to make a type-safe variant of printf. So with iostreams the _type_ of the value is determined at compile-time, but the representation (e.g. should it be stringified as dec or hex? should it be left-align or right?) needs to be determined at run-time.

In other words, the design issue is only partially solved with iostreams in terms of performance.

Please read my other comment here https://news.ycombinator.com/item?id=8342684

It is hard to argue the secureness of a software, but I would say that if there are problems in the library it would be taken seriously.

picohttpparser is the core of HTTP::Parser::XS which is used by many HTTP application servers for Perl (see http://plackperl.org). There are many deployments using it.

As the author of H2O, I would like to leave a comment here.

First of all, the development is still in early stages, please forgive me for the lack of documentation.

That said, below are some high-level design issues that are not addressed by the README.

- it is designed to be pluggable (though not as flexible as Apache), by providing virtual-host-based configuration of generators, output filters and loggers

  - lib/file.c and lib/chunked.c would be a good place to understand their interface if you are interested

  - I am (at the moment) not interested in providing support for input filters

ab has not been the bottleneck in the benchmarks since both servers were pinned to a single core. It is true that ab is too slow for benchmarking a HTTP server running on multiple CPU cores, but it is at least faster than a server only using one core.

Regarding the performance of the HTTP parser, I have heard that picohttpparser (the HTTP/1 parser used by H2O) is much faster than the HTTP parser used by nginx. https://github.com/kazuho/picohttpparser

If that is true, it is likely due to the difference between the approaches the parsers take. Unlike most parsers, picohttpparser does not have a callback-based API. Instead it uses a loop for parsing the HTTP request and header lines.

note: This comment might be biased since I am the author of H2O and picohttpparser.

Type inference and operator overloading often leads to less-readable code.

IMO when evaluating programming languages, we should not only consider writability but also its readability. This is especially true if many engineers are going to be involved in the development.

It is good to have type inference and operator overloading in terms of writability. Nobody wants to type verbose code.

OTOH some verbosity within the source code helps reading the code. And type information (which type inference and operator overloading tries to hide) is one of them.

So I can respect Go's decision not to support operator overloading / only support some part of type inference.