Git Product home page Git Product logo

h2o's Introduction

H2O - an optimized HTTP server with support for HTTP/1.x, HTTP/2 and HTTP/3 (experimental)

CI Coverity Scan Build Status Fuzzing Status

Copyright (c) 2014-2019 DeNA Co., Ltd., Kazuho Oku, Tatsuhiko Kubo, Domingo Alvarez Duarte, Nick Desaulniers, Marc Hörsken, Masahiro Nagano, Jeff Marrison, Daisuke Maki, Laurentiu Nicola, Justin Zhu, Tatsuhiro Tsujikawa, Ryosuke Matsumoto, Masaki TAGAWA, Masayoshi Takahashi, Chul-Woong Yang, Shota Fukumori, Satoh Hiroh, Fastly, Inc., David Carlier, Frederik Deweerdt, Jonathan Foote, Yannick Koechlin, Harrison Bowden, Kazantsev Mikhail

H2O is a new generation HTTP server. Not only is it very fast, it also provides much quicker response to end-users when compared to older generations of HTTP servers.

Written in C and licensed under the MIT License, it can also be used as a library.

For more information, please refer to the documentation at h2o.examp1e.net.

Reporting Security Issues

Please report vulnerabilities to [email protected]. See SECURITY.md for more information.

h2o's People

Contributors

antoniofastly avatar chenbd avatar cubicdaiya avatar devnexen avatar deweerdt avatar doohara avatar gfx avatar hfujita avatar i110 avatar jbenoist avatar jdamato-fsly avatar jfoote avatar jhatala avatar jxck avatar kazuho avatar matsumotory avatar miyagawa avatar nalramli avatar naritta avatar omasanori avatar pldubouilh avatar robguima avatar sharksforarms avatar sleepybishop avatar syohex avatar tagomoris avatar toru avatar u5surf avatar yannick avatar zlm2012 avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

h2o's Issues

example h2o.conf doesn't allow running as root user ?

With h2o 0.9.0 your examples h2o.conf doesn't allow running as root user ? can it run as root user ? if you need a user added, maybe add a commented out entry in example h2o.conf ?

cowardly refusing to run as root; you can use the `user` directive to set the running user

also where in h2o.conf do you add the user as i get

failed to parse configuration file:/usr/local/h2o/h2o.conf:line 3:mapping values are not allowed in this context

libyaml -> libucl?

File this under "strongly flavoured", but there's a charm to how the nginx configs looks like. I've been very impressed by the relatively new library called libucl (link to github account), currently in deployment for FreeBSD's new pkg software (but usage is growing over time). It has a nginx-like syntax, but also parses json.

I know suggesting replacing stuff like this (or even generalising configuration management) is far-fetched at best, but at least this issue could then be used as a pointer for similar future issues (which very likely will pop up).

Error with libcrypto

Hi. First, thanks in advance for your project.
I try to build and run the server following your readme. But when I run "make h2o", I got an error:
Linking C executable h2o
/usr/local/ssl/lib/libcrypto.a(dso_dlfcn.o): In function dlfcn_globallookup': dso_dlfcn.c:(.text+0x21): undefined reference todlopen'
dso_dlfcn.c:(.text+0x34): undefined reference to dlsym' dso_dlfcn.c:(.text+0x3f): undefined reference todlclose'
/usr/local/ssl/lib/libcrypto.a(dso_dlfcn.o): In function dlfcn_bind_func': dso_dlfcn.c:(.text+0x354): undefined reference todlsym'
dso_dlfcn.c:(.text+0x3fb): undefined reference to dlerror' /usr/local/ssl/lib/libcrypto.a(dso_dlfcn.o): In functiondlfcn_bind_var':
dso_dlfcn.c:(.text+0x474): undefined reference to dlsym' dso_dlfcn.c:(.text+0x52e): undefined reference todlerror'
/usr/local/ssl/lib/libcrypto.a(dso_dlfcn.o): In function dlfcn_load': dso_dlfcn.c:(.text+0x5a4): undefined reference todlopen'
dso_dlfcn.c:(.text+0x612): undefined reference to dlclose' dso_dlfcn.c:(.text+0x640): undefined reference todlerror'
/usr/local/ssl/lib/libcrypto.a(dso_dlfcn.o): In function dlfcn_pathbyaddr': dso_dlfcn.c:(.text+0x6be): undefined reference todladdr'
dso_dlfcn.c:(.text+0x721): undefined reference to dlerror' /usr/local/ssl/lib/libcrypto.a(dso_dlfcn.o): In functiondlfcn_unload':
dso_dlfcn.c:(.text+0x77a): undefined reference to `dlclose'
collect2: ld returned 1 exit status
make[3]: *** [h2o] Error 1
make[2]: *** [CMakeFiles/h2o.dir/all] Error 2
make[1]: *** [CMakeFiles/h2o.dir/rule] Error 2
make: *** [h2o] Error 2
Can you tell me how can I fix it?

Misleading benchmark

You should add the following to the nginx.conf

tcp_nopush on;

otherwise the comparison is unfair.

BTW,we found nginx outperforms h2o significantly when using webbench.

curl leads to 404 not found for h2o served files despite showing up in browser ok?

I setup h2o on CentOS 6.6 server and in web browser it works on my virtualbox test server which already has my Centmin Mod Nginx server installed.

For example in browser http://192.168.0.xxx:8080/nginx-logo.png shows the nginx-logo.png ok.

But when I curl the file I get 404 not found status instead ?

For h2o

curl -I http://192.168.0.xxx:8080/nginx-logo.png
HTTP/1.1 404 File Not Found
Date: Sat, 27 Dec 2014 14:34:21 GMT
Server: h2o/0.9.0
Connection: keep-alive
Content-Length: 9
content-type: text/plain; charset=utf-8

for Nginx shows fine in curl though

curl -I http://192.168.0.xxx/nginx-logo.png   
HTTP/1.1 200 OK
Server: nginx centminmod
Date: Sat, 27 Dec 2014 14:26:37 GMT
Content-Type: image/png
Content-Length: 15382
Last-Modified: Wed, 29 Oct 2014 07:25:20 GMT
Connection: keep-alive
ETag: "54509660-3c16"
Expires: Mon, 26 Jan 2015 14:26:37 GMT
Cache-Control: max-age=2592000
Cache-Control: public, must-revalidate, proxy-revalidate
Accept-Ranges: bytes

The h2o.conf looks like

# to find out the configuration commands, run: h2o --help

listen: 8080
user: nginx
listen:
  port: 8081
  ssl:
    certificate-file: /usr/local/h2o/server.crt
    key-file: /usr/local/h2o/server.key
hosts:
  "127.0.0.1:8080":
    paths:
      /:
        file.dir: /usr/local/nginx/html
    access-log: /usr/local/h2o/logs/access.log
  "alternate.127.0.0.1.xip.io:8081":
    listen:
      port: 8081
      ssl:
        certificate-file: /usr/local/h2o/alternate.crt
        key-file: /usr/local/h2o/alternate.key
    paths:
      /:
        file.dir: /usr/local/nginx/html.alternate
    access-log: /usr/local/h2o/logs/access.log

Command to start h2o is

/usr/local/bin/h2o -c /usr/local/h2o/h2o.conf &

Listening ports for nginx and h2o

netstat -plunt | egrep 'nginx|h2o'
tcp        0      0 0.0.0.0:8081                0.0.0.0:*                   LISTEN      3372/h2o            
tcp        0      0 0.0.0.0:8080                0.0.0.0:*                   LISTEN      3372/h2o            
tcp        0      0 0.0.0.0:80                  0.0.0.0:*                   LISTEN      2418/nginx          
tcp        0      0 :::8081                     :::*                        LISTEN      3372/h2o            
tcp        0      0 :::8080                     :::*                        LISTEN      3372/h2o

From the logs/access.log file i setup

In browser working entry

192.168.0.yyy - - [27/Dec/2014:14:59:43 +0000] "GET /nginx-logo.png HTTP/1.1" 304 0 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/39.0.2171.95 Safari/537.36 OPR/26.0.1656.60"

Curl 404 entry

192.168.0.yyy - - [27/Dec/2014:15:00:48 +0000] "HEAD /nginx-logo.png HTTP/1.1" 404 9 "-" "curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.15.3 zlib/1.2.3 libidn/1.18 libssh2/1.4.2"

However, judging from siege benchmarks the h2o served nginx-logo.png is working just not for curl as both tests show same amount of data transferred ?

h2o siege benchmarked

siege -q -b -c10 -r10 http://192.168.0.xxx:8080/nginx-logo.png
      done.

Transactions:             100 hits
Availability:          100.00 %
Elapsed time:            0.06 secs
Data transferred:           1.47 MB
Response time:           0.00 secs
Transaction rate:        1666.67 trans/sec
Throughput:             24.45 MB/sec
Concurrency:             6.67
Successful transactions:         100
Failed transactions:             0
Longest transaction:          0.03
Shortest transaction:         0.00

nginx siege benchmarked

siege -q -b -c10 -r10 http://192.168.0.xxx/nginx-logo.png
      done.

Transactions:             100 hits
Availability:          100.00 %
Elapsed time:            0.06 secs
Data transferred:           1.47 MB
Response time:           0.00 secs
Transaction rate:        1666.67 trans/sec
Throughput:             24.45 MB/sec
Concurrency:             6.83
Successful transactions:         100
Failed transactions:             0
Longest transaction:          0.03
Shortest transaction:         0.00

Program received signal SIGPIPE, Broken pipe.

When stressing h2o via lo interface, h2o quit silently.

Related info:
./wrk -c 10 -d 1 -t 1 http://xxx.xxx.xxx.190:8090/hessian-serialization.html

  [190 html]$ ll hessian-serialization.html 
  -rw-r--r-- 1 root root 68814 Mar 24  2014 hessian-serialization.html

backtrace:

Program received signal SIGPIPE, Broken pipe.
0x0000003db3ae0c1b in __libc_writev (fd=<value optimized out>, vector=0x7fffffffe320, count=<value optimized out>)
    at ../sysdeps/unix/sysv/linux/writev.c:51
51          result = INLINE_SYSCALL (writev, 3, fd, CHECK_N (vector, count), count);
Missing separate debuginfos, use: debuginfo-install keyutils-libs-1.4-4.el6.x86_64 krb5-libs-1.10.3-10.el6_4.6.x86_64 libcom_err-1.41.12-18.el6.x86_64 libselinux-2.0.94-5.3.el6_4.1.x86_64 openssl-1.0.1e-16.el6_5.x86_64 zlib-1.2.3-29.el6.x86_64
(gdb) bt
#0  0x0000003db3ae0c1b in __libc_writev (fd=<value optimized out>, vector=0x7fffffffe320, count=<value optimized out>)
    at ../sysdeps/unix/sysv/linux/writev.c:51
#1  0x000000000040d07e in write_core (fd=10, bufs=0x7fffffffe308, bufcnt=0x7fffffffe300)
    at /home/wangbin/github/h2o/h2o/lib/socket/evloop.c.h:150
#2  0x000000000040d16e in do_write (_sock=0x66b5f0, bufs=0x7fffffffe320, bufcnt=1, cb=<value optimized out>)
    at /home/wangbin/github/h2o/h2o/lib/socket/evloop.c.h:230
#3  0x0000000000407168 in finalostream_send (_self=<value optimized out>, req=<value optimized out>, 
    inbufs=<value optimized out>, inbufcnt=<value optimized out>, is_final=1)
    at /home/wangbin/github/h2o/h2o/lib/http1.c:348
#4  0x0000000000405b91 in do_proceed (_self=0x67c390, req=0x65aa38) at /home/wangbin/github/h2o/h2o/lib/file.c:84
#5  0x000000000040db72 in on_write_complete (loop=0x65a250) at /home/wangbin/github/h2o/h2o/lib/socket.c:252
#6  run_socket (loop=0x65a250) at /home/wangbin/github/h2o/h2o/lib/socket/evloop.c.h:360
#7  run_pending (loop=0x65a250) at /home/wangbin/github/h2o/h2o/lib/socket/evloop.c.h:378
#8  h2o_evloop_run (loop=0x65a250) at /home/wangbin/github/h2o/h2o/lib/socket/evloop.c.h:391
#9  0x000000000040feb8 in run_loop (_config=<value optimized out>) at /home/wangbin/github/h2o/h2o/src/main.c:182
#10 0x0000000000413b60 in main (argc=<value optimized out>, argv=<value optimized out>)
    at /home/wangbin/github/h2o/h2o/src/main.c:246

External event loop

This library looks really promising. I didnt dig into sources yet but is there any support for external event loop? Instead of libuv I would love to use it from C++ and handle sockets with boost.asio. Ideally I can imagine api that would allow me to pass callbacks that will be called instead libuv socket stuff.

Thanks!

[QUESTION]Why h2o is faster 2x than Nginx?

Nginx http://github.com/nginx/nginx/blob/master/src/event/modules/ngx_epoll_module.c and h2o http://github.com/kazuho/h2o/blob/master/lib/socket/evloop/epoll.c.h both use epoll http://man7.org/linux/man-pages/man7/epoll.7.html under Linux Kernel

Only benchmark http://github.com/kazuho/h2o#benchmark is not enough to prove that h2o is faster 2x than Nginx, isn't? I argue that you need to write a Paper or something to list 1, 2, ... n optimization compare with Nginx.

number of upstream connections kept alive should be configurable

Support for persistent connections to upstream have landed to master in commit ba44789 however the leftover is that there is no way to limit the number of connections upstream (such a feature was not mandatory until now since there was no support for keep-alive).

To do this, we need to add a way to signal a worker thread (waiting for a upstream connection to become available).

Examples simple.c with keep alive takes forever

I did compiled the simple.c after removing "-luv" from linking and using:
make C_DEFINES="-DH2O_USE_EPOLL" examples-simple

Also changing inexisting h2o_accept(&ctx, sock) by h2o_accept_ssl(&ctx, sock, ssl_ctx) and uncommenting:
ssl_ctx = h2o_ssl_new_server_context("server.crt", "server.key", h2o_http2_tls_identifiers);
h2o_register_access_logger(&ctx, "server.log" //dev/stdout"/);

But the logger is not used, I should somehow connect it because it's only created but not used anywhere.

Any help on make this work ?

I needed to interrupt it with ^C.

ab -k -n 1000 -c 5 https://127.0.0.1:7890/index.html
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking 127.0.0.1 (be patient)
^C

Server Software:
Server Hostname: 127.0.0.1
Server Port: 7890
SSL/TLS Protocol: TLSv1/SSLv3,AES256-SHA,512,256

Document Path: /index.html
Document Length: 0 bytes

Concurrency Level: 5
Time taken for tests: 29.403 seconds
Complete requests: 25
Failed requests: 10
(Connect: 0, Receive: 0, Length: 10, Exceptions: 0)
Write errors: 0
Non-2xx responses: 15
Keep-Alive requests: 15
Total transferred: 24690 bytes
HTML transferred: 16035 bytes
Requests per second: 0.85 #/sec
Time per request: 5880.697 ms
Time per request: 1176.139 [ms](mean, across all concurrent requests)
Transfer rate: 0.82 [Kbytes/sec] received

Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 3 2.9 4 8
Processing: 0 4003 5002.4 3 10008
Waiting: 0 1 0.9 0 3
Total: 4 4007 4999.6 9 10008
WARNING: The median and mean for the waiting time are not within a normal deviation
These results are probably not that reliable.

Percentage of the requests served within a certain time (ms)
50% 8
66% 10005
75% 10005
80% 10006
90% 10007
95% 10007
98% 10008
99% 10008
100% 10008 (longest request)

is h2o ready for production?

I dont see an official release. I run some tests and it looks very good but I am not so sure if this is production ready. Can you confirm ?

compile error on freebsd due undeclared identifier 'IPPROTO_TCP'

h2o/lib/http1client.c:265:25: error: use of undeclared identifier 'IPPROTO_TCP'
    hints.ai_protocol = IPPROTO_TCP;

the simple fix (which works on linux as well):

diff --git a/lib/http1client.c b/lib/http1client.c
index 6e93ea8..17bac43 100644
--- a/lib/http1client.c
+++ b/lib/http1client.c
@@ -22,6 +22,7 @@
 #include <netdb.h>
 #include <sys/socket.h>
 #include <sys/types.h>
+#include <netinet/in.h>
 #include "h2o/string_.h"
 #include "h2o/http1client.h"

SPDY3 how hard ?

Also posted on http://blog.kazuhooku.com/2014/12/ann-initial-release-of-h2o-and-why.html

Meanwhile how hard would be for h2o to have a spdy3 compatibility mode to benefit from it right now ?

Also it's not scaling with increasing number of threads is this expected ?

I did some tests on a machine with 8 cores and it seems that it doesn't scale beyound 2 threads.
On my test with ab on localhost it do not go beyound 260,000 requests by second when I increment the number of threads and it even goes bellow that mark.

ab -n 500000 -c 1000 -k http://127.0.0.1:8020/

Server Software: h2o/0.9.1-alpha1
Server Hostname: 127.0.0.1
Server Port: 8020

Document Path: /
Document Length: 180 bytes

Concurrency Level: 1000
Time taken for tests: 2.122 seconds
Complete requests: 500000
Failed requests: 0
Keep-Alive requests: 500000
Total transferred: 199500000 bytes
HTML transferred: 90000000 bytes
Requests per second: 235596.24 #/sec
Time per request: 4.245 ms
Time per request: 0.004 [ms](mean, across all concurrent requests)
Transfer rate: 91799.70 [Kbytes/sec] received

1 thread : Requests per second: 113803.63 #/sec
2 threads: Requests per second: 243651.89 #/sec
3 threads: Requests per second: 246776.48 #/sec
4 threads: Requests per second: 248771.81 #/sec
5 threads: Requests per second: 236967.72 #/sec
6 threads: Requests per second: 235596.24 #/sec

Any idea if this is the expected behavior ?

h2o.config

num-threads: 2
listen: 8020
listen:
port: 8021
ssl:
certificate-file: examples/h2o/server.crt
key-file: examples/h2o/server.key
hosts:
"127.0.0.1.xip.io:8020":
paths:
/:
file.dir: examples/doc_root
access-log: /dev/null
"alternate.127.0.0.1.xip.io:8081":
listen:
port: 8021
ssl:
certificate-file: examples/h2o/alternate.crt
key-file: examples/h2o/alternate.key
paths:
/:
file.dir: examples/doc_root.alternate
access-log: /dev/null

Also executing ab on two terminals in parallel I've got:

with 2 threads: Requests per second: 119658.69 #/sec
with 4 threads: Requests per second: 156863.82 #/sec

It seems that with 4 threads and the two ab executed in parallel we get around 300,000 requests by second.

h2o crashed with HTTP/2 CONTINUATION

I observed that h2o got crashed when I sent HTTP/2 CONTINUATION frame.

To send CONTINUATION frame, I use following command line:

nghttp -nvu http://localhost:8080 -m2 --continuation

Backtrace follows:

$ gdb ./h2o
GNU gdb (Debian 7.7.1-2) 7.7.1
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./h2o...done.
(gdb) set args -c examples/h2o.conf
(gdb) run
Starting program: /work/h2o/h2o -c examples/h2o.conf
*** Error in `/work/h2o/h2o': realloc(): invalid next size: 0x0000000000657250 ***

Program received signal SIGABRT, Aborted.
0x00007ffff71f8407 in __GI_raise (sig=sig@entry=6)
    at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
56  ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0  0x00007ffff71f8407 in __GI_raise (sig=sig@entry=6)
    at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1  0x00007ffff71f97e8 in __GI_abort () at abort.c:89
#2  0x00007ffff7236394 in __libc_message (do_abort=do_abort@entry=1, 
    fmt=fmt@entry=0x7ffff7329010 "*** Error in `%s': %s: 0x%s ***\n")
    at ../sysdeps/posix/libc_fatal.c:175
#3  0x00007ffff723bb6e in malloc_printerr (action=1, 
    str=0x7ffff73251cc "realloc(): invalid next size", ptr=<optimized out>)
    at malloc.c:4996
#4  0x00007ffff723e94b in _int_realloc (
    av=av@entry=0x7ffff7566620 <main_arena>, oldp=oldp@entry=0x657240, 
    oldsize=oldsize@entry=8208, nb=nb@entry=16400) at malloc.c:4234
#5  0x00007ffff723f949 in __GI___libc_realloc (oldmem=0x657250, bytes=16392)
    at malloc.c:3029
#6  0x000000000040a2d3 in h2o_realloc (sz=16392, oldp=0x657250)
    at /work/h2o/include/h2o.h:725
#7  h2o_allocate_input_buffer (_inbuf=_inbuf@entry=0x667ac0, 
    initial_size=initial_size@entry=8192)
    at /work/h2o/lib/memory.c:145
#8  0x000000000040c625 in on_read_core (input=0x667ac0, fd=6)
    at /work/h2o/lib/socket/evloop.c.h:108
#9  read_on_ready (sock=0x667ab0)
    at /work/h2o/lib/socket/evloop.c.h:198
#10 run_socket (sock=0x667ab0)
    at /work/h2o/lib/socket/evloop.c.h:353
#11 run_pending (loop=0x667dd0)
    at /work/h2o/lib/socket/evloop.c.h:366
#12 h2o_evloop_run (loop=0x667dd0)
    at /work/h2o/lib/socket/evloop.c.h:379
#13 0x00000000004038e7 in main (argc=<optimized out>, argv=<optimized out>)
    at /work/h2o/src/main.c:183
(gdb) 

Handle path-level configuration in core

At the moment, all handlers (generators, filters, loggers) are registered at host-level. Each of them implement their own path-matching logic to determine whether they should handle a request.

It is preferable to provide an interface so that the handlers could be registered at path-level.

Performance degradation with main.c

Hello I made some tests with h2o and there is a big performance degradation (97 rqs / 35075 rqs) when requesting a file like src/main.c compared to the examples/doc_root/index.html see bellow:

All tests on ubuntu 14.04 celeron 2 core

=========examples/doc_root/index.html

ab -n 10000 -c 500 -k http://127.0.0.1:8080/
This is ApacheBench, Version 2.3 <$Revision: 1528965 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking 127.0.0.1 (be patient)
Completed 1000 requests
Completed 2000 requests
Completed 3000 requests
Completed 4000 requests
Completed 5000 requests
Completed 6000 requests
Completed 7000 requests
Completed 8000 requests
Completed 9000 requests
Completed 10000 requests
Finished 10000 requests

Server Software:
Server Hostname: 127.0.0.1
Server Port: 8080

Document Path: /
Document Length: 180 bytes

Concurrency Level: 500
Time taken for tests: 0.285 seconds
Complete requests: 10000
Failed requests: 0
Keep-Alive requests: 10000
Total transferred: 3900000 bytes
HTML transferred: 1800000 bytes
Requests per second: 35075.04 #/sec
Time per request: 14.255 ms
Time per request: 0.029 [ms](mean, across all concurrent requests)
Transfer rate: 13358.66 [Kbytes/sec] received

Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 2.8 0 22
Processing: 0 5 2.5 5 16
Waiting: 0 5 2.5 5 16
Total: 0 5 4.0 5 30

Percentage of the requests served within a certain time (ms)
50% 5
66% 6
75% 7
80% 7
90% 8
95% 10
98% 16
99% 27
100% 30 (longest request)

=========examples/doc_root/main.c (basically no cpu load)

ab -n 10000 -c 500 -k http://127.0.0.1:8080/main.c
This is ApacheBench, Version 2.3 <$Revision: 1528965 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking 127.0.0.1 (be patient)
Completed 1000 requests
Completed 2000 requests
Completed 3000 requests
Completed 4000 requests
Completed 5000 requests
Completed 6000 requests
Completed 7000 requests
Completed 8000 requests
Completed 9000 requests
Completed 10000 requests
Finished 10000 requests

Server Software:
Server Hostname: 127.0.0.1
Server Port: 8080

Document Path: /main.c
Document Length: 7963 bytes

Concurrency Level: 500
Time taken for tests: 103.088 seconds
Complete requests: 10000
Failed requests: 5000
(Connect: 0, Receive: 0, Length: 5000, Exceptions: 0)
Non-2xx responses: 5000
Keep-Alive requests: 5000
Total transferred: 306610000 bytes
HTML transferred: 297830000 bytes
Requests per second: 97.00 #/sec
Time per request: 5154.386 ms
Time per request: 10.309 [ms](mean, across all concurrent requests)
Transfer rate: 2904.55 [Kbytes/sec] received

Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 49 306.1 0 3006
Processing: 0 5004 5000.3 9999 10024
Waiting: 0 2 2.8 1 17
Total: 0 5052 4960.9 9999 10024

Percentage of the requests served within a certain time (ms)
50% 9999
66% 10001
75% 10003
80% 10004
90% 10006
95% 10008
98% 10011
99% 10015
100% 10024 (longest request)

Will correct this fix? Could you make sure lib/socket/uv-binding.c.h

I executed following command.

make libh2o

Part of output is following.

In file included from /Users/mochizukitakamasa/private/github/h2o/h2o/lib/socket.c:71:
/Users/mochizukitakamasa/private/github/h2o/h2o/lib/socket/uv-binding.c.h:162:43: error: passing 'struct sockaddr *' to parameter of incompatible type 'struct sockaddr_in'
    if (uv_tcp_connect(&sock->_creq, tcp, addr, on_connect) != 0) {
                                          ^~~~
/usr/local/include/uv.h:727:24: note: passing argument to parameter 'address' here
    struct sockaddr_in address, uv_connect_cb cb);
                       ^

I try to edit this file. uv-binding.c.h#L162

    if (uv_tcp_connect(&sock->_creq, tcp, addr, on_connect) != 0) {
    if (uv_tcp_connect(&sock->_creq, tcp, *(struct sockaddr_in)addr, on_connect) != 0) {

Will correct this fix? Or not used?

http://blog.kazuhooku.com/2014/09/the-reasons-why-i-stopped-using-libuv.html

(I'm sorry in poor English.)

use TCP_DEFER_ACCEPT

As of commit fc5ecd4 the application protocol layer tries to read any data if available after the connection is accepted (this change was necessary since we might have already received some application data when SSL handshake succeeds).

The fact means that it would be easy to start using TCP_DEFER_ACCEPT. IMO, we should always call read(2) after accept(2) (regardless of whether if TCP_DEFER_ACCEPT is used), and avoid NULL checks against sock->input in the application protocol layer.

support upstream server using HTTPS (was: proxy.reverse.url acts like a redirect)

Hi,
I use this simple configuration file to get content from a public cloud storage:

listen: 80
hosts:
  default:
    paths:
      /:
        proxy.reverse.url: http://foo.googledrive.com/host/bar/
    access-log: /var/log/h2o 

The similar config in Nginx would be:

server {
        listen       80;
        location / {
           proxy_pass http://foo.googledrive.com/host/bar/;
        }
    }

But instead of having h2o proxy the content from the cloud storage, my browser gets redirected to http://foo.googledrive.com/host/bar/. (By 301 Moved Permanently)

compile error on Ubuntu with libuv 0.1.0 installed

$ make libh2o
[  4%] Building C object CMakeFiles/libh2o.dir/deps/picohttpparser/picohttpparser.c.o
[  8%] Building C object CMakeFiles/libh2o.dir/lib/access_log.c.o
/home/kim/compile/h2o/lib/access_log.c: In function ‘log_access’:
/home/kim/compile/h2o/lib/access_log.c:324:5: warning: ignoring return value of ‘write’, declared with attribute warn_unused_result [-Wunused-result]
     write(self->fd, line, pos - line);
     ^
[ 13%] Building C object CMakeFiles/libh2o.dir/lib/chunked.c.o
[ 17%] Building C object CMakeFiles/libh2o.dir/lib/context.c.o
[ 21%] Building C object CMakeFiles/libh2o.dir/lib/configurator.c.o
[ 26%] Building C object CMakeFiles/libh2o.dir/lib/configurator/access_log.c.o
[ 26%] Building C object CMakeFiles/libh2o.dir/lib/configurator/file.c.o
[ 30%] Building C object CMakeFiles/libh2o.dir/lib/configurator/proxy.c.o
[ 34%] Building C object CMakeFiles/libh2o.dir/lib/file.c.o
[ 39%] Building C object CMakeFiles/libh2o.dir/lib/headers.c.o
[ 43%] Building C object CMakeFiles/libh2o.dir/lib/http1.c.o
[ 47%] Building C object CMakeFiles/libh2o.dir/lib/http1client.c.o
[ 47%] Building C object CMakeFiles/libh2o.dir/lib/http2/connection.c.o
[ 52%] Building C object CMakeFiles/libh2o.dir/lib/http2/frame.c.o
[ 56%] Building C object CMakeFiles/libh2o.dir/lib/http2/hpack.c.o
[ 60%] Building C object CMakeFiles/libh2o.dir/lib/http2/stream.c.o
[ 65%] Building C object CMakeFiles/libh2o.dir/lib/memory.c.o
[ 69%] Building C object CMakeFiles/libh2o.dir/lib/mimemap.c.o
[ 73%] Building C object CMakeFiles/libh2o.dir/lib/proxy.c.o
[ 73%] Building C object CMakeFiles/libh2o.dir/lib/request.c.o
[ 78%] Building C object CMakeFiles/libh2o.dir/lib/rproxy.c.o
[ 82%] Building C object CMakeFiles/libh2o.dir/lib/socket.c.o
In file included from /home/kim/compile/h2o/lib/socket.c:73:0:
/home/kim/compile/h2o/lib/socket/uv-binding.c.h: In function ‘do_read_start’:
/home/kim/compile/h2o/lib/socket/uv-binding.c.h:103:40: warning: passing argument 2 of ‘uv_read_start’ from incompatible pointer type
         uv_read_start(sock->uv.stream, alloc_inbuf_tcp, on_read_tcp);
                                        ^
In file included from /home/kim/compile/h2o/include/h2o/socket/uv-binding.h:25:0,
                 from /home/kim/compile/h2o/include/h2o/socket.h:60,
                 from /home/kim/compile/h2o/lib/socket.c:28:
/usr/include/uv.h:599:15: note: expected ‘uv_alloc_cb’ but argument is of type ‘void (*)(struct uv_handle_t *, size_t,  struct uv_buf_t *)’
 UV_EXTERN int uv_read_start(uv_stream_t*, uv_alloc_cb alloc_cb,
               ^
In file included from /home/kim/compile/h2o/lib/socket.c:73:0:
/home/kim/compile/h2o/lib/socket/uv-binding.c.h:103:57: warning: passing argument 3 of ‘uv_read_start’ from incompatible pointer type
         uv_read_start(sock->uv.stream, alloc_inbuf_tcp, on_read_tcp);
                                                         ^
In file included from /home/kim/compile/h2o/include/h2o/socket/uv-binding.h:25:0,
                 from /home/kim/compile/h2o/include/h2o/socket.h:60,
                 from /home/kim/compile/h2o/lib/socket.c:28:
/usr/include/uv.h:599:15: note: expected ‘uv_read_cb’ but argument is of type ‘void (*)(struct uv_stream_t *, ssize_t,  const struct uv_buf_t *)’
 UV_EXTERN int uv_read_start(uv_stream_t*, uv_alloc_cb alloc_cb,
               ^
In file included from /home/kim/compile/h2o/lib/socket.c:73:0:
/home/kim/compile/h2o/lib/socket/uv-binding.c.h:105:40: warning: passing argument 2 of ‘uv_read_start’ from incompatible pointer type
         uv_read_start(sock->uv.stream, alloc_inbuf_ssl, on_read_ssl);
                                        ^
In file included from /home/kim/compile/h2o/include/h2o/socket/uv-binding.h:25:0,
                 from /home/kim/compile/h2o/include/h2o/socket.h:60,
                 from /home/kim/compile/h2o/lib/socket.c:28:
/usr/include/uv.h:599:15: note: expected ‘uv_alloc_cb’ but argument is of type ‘void (*)(struct uv_handle_t *, size_t,  struct uv_buf_t *)’
 UV_EXTERN int uv_read_start(uv_stream_t*, uv_alloc_cb alloc_cb,
               ^
In file included from /home/kim/compile/h2o/lib/socket.c:73:0:
/home/kim/compile/h2o/lib/socket/uv-binding.c.h:105:57: warning: passing argument 3 of ‘uv_read_start’ from incompatible pointer type
         uv_read_start(sock->uv.stream, alloc_inbuf_ssl, on_read_ssl);
                                                         ^
In file included from /home/kim/compile/h2o/include/h2o/socket/uv-binding.h:25:0,
                 from /home/kim/compile/h2o/include/h2o/socket.h:60,
                 from /home/kim/compile/h2o/lib/socket.c:28:
/usr/include/uv.h:599:15: note: expected ‘uv_read_cb’ but argument is of type ‘void (*)(struct uv_stream_t *, ssize_t,  const struct uv_buf_t *)’
 UV_EXTERN int uv_read_start(uv_stream_t*, uv_alloc_cb alloc_cb,
               ^
In file included from /home/kim/compile/h2o/lib/socket.c:73:0:
/home/kim/compile/h2o/lib/socket/uv-binding.c.h: In function ‘do_export’:
/home/kim/compile/h2o/lib/socket/uv-binding.c.h:138:5: error: unknown type name ‘uv_os_fd_t’
     uv_os_fd_t fd;
     ^
/home/kim/compile/h2o/lib/socket/uv-binding.c.h:140:5: warning: implicit declaration of function ‘uv_fileno’ [-Wimplicit-function-declaration]
     if (uv_fileno((uv_handle_t*)sock->uv.stream, &fd) != 0)
     ^
/home/kim/compile/h2o/lib/socket/uv-binding.c.h: In function ‘h2o_socket_connect’:
/home/kim/compile/h2o/lib/socket/uv-binding.c.h:211:9: error: incompatible type for argument 3 of ‘uv_tcp_connect’
     if (uv_tcp_connect(&sock->_creq, (void*)sock->uv.stream, addr, on_connect) != 0) {
         ^
In file included from /home/kim/compile/h2o/include/h2o/socket/uv-binding.h:25:0,
                 from /home/kim/compile/h2o/include/h2o/socket.h:60,
                 from /home/kim/compile/h2o/lib/socket.c:28:
/usr/include/uv.h:726:15: note: expected ‘struct sockaddr_in’ but argument is of type ‘struct sockaddr *’
 UV_EXTERN int uv_tcp_connect(uv_connect_t* req, uv_tcp_t* handle,
               ^
In file included from /home/kim/compile/h2o/lib/socket.c:73:0:
/home/kim/compile/h2o/lib/socket/uv-binding.c.h: In function ‘schedule_timer’:
/home/kim/compile/h2o/lib/socket/uv-binding.c.h:231:46: warning: passing argument 2 of ‘uv_timer_start’ from incompatible pointer type
     uv_timer_start(&timeout->_backend.timer, on_timeout, entry->registered_at + timeout->timeout - h2o_now(timeout->_backend.timer.loop), 0);
                                              ^
In file included from /home/kim/compile/h2o/include/h2o/socket/uv-binding.h:25:0,
                 from /home/kim/compile/h2o/include/h2o/socket.h:60,
                 from /home/kim/compile/h2o/lib/socket.c:28:
/usr/include/uv.h:1223:15: note: expected ‘uv_timer_cb’ but argument is of type ‘void (*)(struct uv_timer_t *)’
 UV_EXTERN int uv_timer_start(uv_timer_t* handle,
               ^
CMakeFiles/libh2o.dir/build.make:537: recipe for target 'CMakeFiles/libh2o.dir/lib/socket.c.o' failed
make[3]: *** [CMakeFiles/libh2o.dir/lib/socket.c.o] Error 1
CMakeFiles/Makefile2:252: recipe for target 'CMakeFiles/libh2o.dir/all' failed
make[2]: *** [CMakeFiles/libh2o.dir/all] Error 2
CMakeFiles/Makefile2:260: recipe for target 'CMakeFiles/libh2o.dir/rule' failed
make[1]: *** [CMakeFiles/libh2o.dir/rule] Error 2
Makefile:184: recipe for target 'libh2o' failed
make: *** [libh2o] Error 2
$ whereis uv.h
uv: /usr/include/uv.h
$ ls /usr/lib/x86_64-linux-gnu/libuv.so*
/usr/lib/x86_64-linux-gnu/libuv.so  /usr/lib/x86_64-linux-gnu/libuv.so.0.10
$ uname -a
Linux Dynabook 3.16.0-28-generic #38-Ubuntu SMP Fri Dec 12 17:37:40 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

This error is confusing because you can't tell if h2o is broken or installed library is not supported.
I think you should check the library version.

pluggable prioritization logic

H2O already implements a tiny prioritization logic based on HTTP/2, that would work fine in terms of browser rendering performance (see #41).

OTOH the prioritization order is not following the guidelines of the HTTP/2 spec. Following the guidelines would degrade the browser rendering performance unless their implementation gets revised.

Also @igrigorik has suggested at HTTP2 Conference that some people have expressed concerns for a different prioritization logic.

Considering the facts, it might be better to add a hook to customize the prioritization algorithm.

fatal error: 'yaml.h' file not found

h2o/deps/yoml/yoml-parser.h:28:10: fatal error: 'yaml.h' file not found
#include <yaml.h>
         ^
1 error generated.
make[3]: *** [CMakeFiles/h2o.dir/src/main.c.o] Error 1
make[2]: *** [CMakeFiles/h2o.dir/all] Error 2
make[1]: *** [CMakeFiles/h2o.dir/rule] Error 2
make: *** [h2o] Error 2

Mac OSx 10.9.4

Support for parsing and building query strings, form data, multipart form data

I'm curious to know more about the scope of libh2o... Are you aiming for an implementation of the HTTP1.x and 2.x client/server transport protocols-only or are you planning to provide a more complete solution by handling the encoding/decoding of form data and query string params?

The reason I ask is that I have a small project that uses libh2o as an HTTP server and I've written some simple functions for parsing query strings, form data, and multipart form data out of the request path and entity vectors. If those were generalized into utility functions, I could see it being a useful addition to the library.

Edit: I didn't see this earlier but it might be worth looking at, seems to provide the needed functionality.. http://www.gnu.org/software/cgicc/ (C++ though). Maybe there are some other projects like it out there..

h2o reverse proxy crashed when front end connections were dropped

I setup h2o in reverse proxy mode like this:

hosts:
  default:
    paths:
      /:
        proxy.reverse.url: http://127.0.0.1:18080
        proxy.keepalive: ON

And start load testing with h2load. While load testing, I terminated h2load then h2o crashed with these messages:

h2o: /path/h2o/lib/proxy.c:235: on_generator_dispose: Assertion `self->client == ((void *)0)' failed.

Wrapper callback for blocking operations

Sometimes it is necessary to make blocking calls, would it be possible to provide a wrapper like libeio does to wrap a blocking call ? This would make development easy without having to hack on the H2O event loop. Or do you have a different recommendation how to tackled this ?

compile error on freebsd / macosx due to missing 'alloca.h'

h2o does not compile on freebsd / macosx since it uses these kind of snippets:

#include <alloca.h>

since freebsd / macosx do not have this header this is a little annoyance :)

luckily, the alloca(3) function is declared via the <stdlib.h> header: on linux, on freebsd, on macsox, on openbsd etc etc.

this patch fixes the issue:

diff --git a/lib/chunked.c b/lib/chunked.c
index 11e6a98..fb12692 100644
--- a/lib/chunked.c
+++ b/lib/chunked.c
@@ -19,7 +19,6 @@
  * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
  * IN THE SOFTWARE.
  */
-#include <alloca.h>
 #include <assert.h>
 #include <stdio.h>
 #include <stdlib.h>
diff --git a/lib/http1.c b/lib/http1.c
index df10199..7c09051 100644
--- a/lib/http1.c
+++ b/lib/http1.c
@@ -19,7 +19,6 @@
  * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
  * IN THE SOFTWARE.
  */
-#include <alloca.h>
 #include <inttypes.h>
 #include <stddef.h>
 #include <stdio.h>

Improve HTTP/2 memory usage

H2O uses push model. Contents are pushed by the generators / filters to the protorol handler.

The model works fine for handling HTTP/1.x and also for handling proxied responses on HTTP/2. OTOH it wastes memory in case of serving static files over HTTP/2. In the worst case, each HTTP/2 connection would allocate 1MB of buffer (16 concurrent requests being handled x 64KB buffer each). The number is not bad considering how much memory we can use on a typical server nowadays, but it is not good in terms of cache hit ratio.

So we should better add a short-cut for serving static files over HTTP/2, that pulls the content from the generator (if no filters are used).

It seems like that such approach is possible:

  • by checking in lib/file.c that the output filter is that of the HTTP2 stream after calling h2o_start_response
  • and in such case, pull the content when h2o_http2_stream_send_pending_datais invoked

Configuration with SSL?

Hello,

Is there an example of configuration with SSL? h2o --help does not provide information how to specify the certificate.

(And thanks for the advices, now I have it up and running).

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.