nginx1.25.0 mainline已经支持了HTTP3和QUIC了

需要 编译工具 gcc g++ cmake go

yum install -y g++ gcc cmake go git

git clone https://boringssl.googlesource.com/boringssl

#这是nginx的旧方式, 也可以

cd boringssl && mkdir build && cd build && cmake .. && make && cd ../../

#新方式, 有点bug

#cd boringssl && mkdir build && cmake -B build && make -C build && cd ../

编译最新版boringssl go的版本>1.18.9, 我的1.16版本出错了升级后正常, CMake 3.10 or higher is required

这里开始编译nginx, 注意跟quic.nginx.org的测试版有不同, 没有了quic_stream模块

cd nginx-1.25.0
./configure
    --with-debug
    --with-http_v3_module
    --with-cc-opt="-I../boringssl/include"
    --with-ld-opt="-L../boringssl/build/ssl
                   -L../boringssl/build/crypto"
make && make install 

配置, 这里跟quic.nginx.org的测试版有不同, 没有了http3 取而代之的是listen 443 quic

http {
    log_format quic '$remote_addr - $remote_user [$time_local] '
                    '"$request" $status $body_bytes_sent '
                    '"$http_referer" "$http_user_agent" "$http3"';

    access_log logs/access.log quic;

    server {
        # for better compatibility it's recommended
        # to use the same port for quic and https
        listen 443 quic reuseport;
        listen 443 ssl http2 reuseport backlog=8192;;

        ssl_certificate     certs/example.com.crt;
        ssl_certificate_key certs/example.com.key;

        location / {
            # required for browsers to direct them to quic port
            add_header Alt-Svc 'h3=":443"; ma=86400';
        }
    }
}

这里解释下配置:

listen 443 quic reuseport; #配置H3协议守护, 注意reuseport 放在默认虚机即可

add_header Alt-Svc ‘h3=”:443″; ‘; #这个是告知客户端支持H3, 需要这个才会访问到H3

参考文档:

https://nginx.org/en/docs/quic.html

https://boringssl.googlesource.com/boringssl/+/HEAD/BUILDING.md

range request in nginx reverse proxy

nginx proxy_cache 模式下是否支持range, 取决于源站是否返回了: Accept-Range Header 

在源站没有明确支持range的请求下, 即便nginx cache 了整个文件, 也不会响应任何range 请求, 会返回整个文件

这个行为方式可以通过 修改proxy_force_range on;来修改

This directive appeared in version 1.7.7.

Enables byte-range support for both cached and uncached responses from the proxied server regardless of the “Accept-Ranges” field in these responses.

nginx 有个特殊的模块叫做http_slice_module, 可以支持分片回源

比如如下配置, 会以1M为文件块跟源站回源, 并存成多份1M分割的cache

从测试看, 即便开启了proxy_force_range on和slice range 回源, 在源站没有明确返回Accept-Range的情况下, nginx 依然不会使用slice range回源, 保持了良好的适配性

http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_force_ranges

https://forum.nginx.org/read.php?2,281946,281946#msg-281946

            location /v {
                proxy_pass https://gs.x.sohu.com;
            }
看个简单的例子, 一般为了方便我们会直接把域名写在proxy_pass的后边, 这会导致当这个域名无法解析的时候,比如机房下线了,比如第三方回源的域名被摘掉了, 导致nginx restart失败
建议的写法是:
                location /v {
                     set $new_host "gs.x.sohu.com";
                     proxy_pass https://$new_host;
                }
两者的不同之处在于: 
1. proxy_pass直接跟域名的话, 会且只会在nginx 服务起来的时候解析一次, 失败则起不来
2. proxy_pass跟一个域名变量的话, 是调用resolver的, 跟随resolver的配置, 包括有效时间等, 有请求的时候才解析, 失败了也不影响全局服务

使用过长的url通过H2访问的时候, 容易出现请求被reset掉, 但是HTTP/1.1请求没事

• TLSv1.2 (IN), TLS alert, close notify (256):
• Empty reply from server
• Connection #0 to host api.k.sohu.com left intact
curl: (52) Empty reply from server
• Closing connection 0

打开nginx debug 日志可以看到

client sent too large header field while processing HTTP/2 connection

这是因为HTTP2有一套自己的优化参数, 主要跟两个参数有关:

http2_max_header_size 和 http2_max_field_size

http2_max_field_size 是HPACK压缩的header大小(H2的特性, 头部压缩), 默认值4k

http2_max_header_size HPACK解压后的header大小,默认16k

需要特别留意的是, 1.19.7版本以后统一使用large_client_header_buffers 来控制

这几个参数都可以根据单独server 来使用的

http://nginx.org/en/docs/http/ngx_http_v2_module.html#http2_max_field_size

参考文档:

https://phabricator.wikimedia.org/T209590

线上有个业务需要使用到指定版本的chromium源代码, 这里记录下

一、安装 depot_tools 项目构建工具

1. 克隆 depot_tools git仓库

$ git clone https://chromium.googlesource.com/chromium/tools/depot_tools.git

2. 添加环境变量

$ export PATH="$PATH:/path/to/depot_tools"

Tip: /path/to/depot_tools， 为你 depot_tools 本地的路径

二、使用 depot_tools 下载源码

1. 创建一个用于存在 chromium 的目录 (您可以任意命令，并存放在任何您喜欢的位置，只要是路径路径并且没有空格即可）

$ mkdir chromium && cd chromium

2. 使用 depot_tools 的 fetch 命令，来检查代码及其依赖关系。

$ fetch  chromium
//Don't use fetch --no-history chromium, 我们需要切换到历史版本

Tip: –no-history： 代表不需要历史记录， 完整仓库大约40G 源码大小大概 8G 左右，下载时间因网速而议，请耐心等待

三、切换到指定的tags

# Make sure you are in 'src'.
# This part should only need to be done once, but it won't hurt to repeat it. The first
# time checking out branches and tags might take a while because it fetches an extra
# 1/2 GB or so of branch commits. 
gclient sync --with_branch_heads --with_tags

# You may have to explicitly 'git fetch origin' to pull branch-heads/
git fetch

# Checkout the branch 'src' tree.
git checkout -b branch_$BRANCH tags/$BRANCH

# Checkout all the submodules at their branch DEPS revisions.
gclient sync --with_branch_heads --with_tags

到这一步做完就可以校验下了

$cat chrome/VERSION

参考文档:

https://www.chromium.org/developers/how-tos/get-the-code/working-with-release-branches

https://github.com/aidevjoe/ChromiumBuild