-
666
找到
2
篇与
http
相关的结果
-
10 个最常见的 HTTP 状态代码 作为一个典型的互联网用户，没有什么比等待网页显示更令人沮丧的了，只收到”未找到页面”404错误状态代码。 当然，我们尝试重新加载页面，有时，让格林林斯开始工作，但大多数时候，问题是我们掌握的。 对于我们所有的典型用户，我们要么去下一件事，要么找到一个不同的网站。 在我们大多数人完全不知道的背景中发生了很多事情。 但是，对于 Web 开发人员来说，HTTP 状态代码错误可能令人讨厌。 据互联网工程特别工作组（IEFT）称，开发和推广互联网标准的组织有60多个不同的HTTP状态代码。 HTTP 状态代码分为以下五组：1xx 信息响应。 收到并理解的请求。 请求处理将继续。2xx 成功。 已成功接收、理解和接受该操作。3xx 重定向。 客户端必须采取进一步操作才能完成请求。4xx 客户端错误。 可能是客户端导致的错误。 请求包含错误的语法或无法实现。5xx 服务器错误。 服务器遇到错误，无法满足请求。请务必注意，并非所有这些状态代码都被视为”错误”，有些只是信息或操作的响应，并且不需要故障排除或修正。 下面是 10 个最常见的 HTTP 状态代码及其含义。通用 HTTP 状态代码状态代码 200 = 这是成功 HTTP 请求的标准”确定”状态代码。 返回的响应取决于请求。 例如，对于 GET 请求，响应将包含在消息正文中。 对于 PUT/POST 请求，响应将包括包含操作结果的资源。状态代码 201 – 这是确认请求成功并由此创建新资源的状态代码。 通常，这是在 POST/PUT 请求后发送的状态代码。状态代码 204 = 此状态代码确认服务器已满足请求，但不需要返回信息。 此状态代码的示例包括删除请求或请求是通过表单发送的，响应不应导致刷新表单或加载新页面。状态代码 304 = 用于浏览器缓存的状态代码。 如果响应尚未修改，则客户端/用户可以继续使用相同的响应/缓存版本。 例如，如果资源已自特定时间以来被修改，浏览器可以请求。 如果没有，则发送状态代码 304。 如果已修改，则发送状态代码 200 以及资源。状态代码 400 = 服务器由于客户端错误而无法理解和处理请求。 缺少数据、域验证和无效格式是导致发送状态代码 400 的一些示例。状态代码 401 = 当需要身份验证但失败或未提供身份验证时，将发生此状态代码请求。状态代码 403 – 与状态代码 401 非常相似，状态代码 403 在发送有效请求时发生，但服务器拒绝接受。 如果客户端/用户需要必要的权限，或者他们可能需要帐户来访问资源，则会发生这种情况。 与状态代码 401 不同，身份验证将不适用于此处。状态代码 404 = 普通用户将看到的最常见状态代码。 当请求有效，但无法在服务器上找到资源时，将发生状态代码 404。 即使这些代码分组在客户端错误”存储桶”中，它们通常是由于不正确的 URL 重定向造成的。状态代码 409 – 当请求与资源的当前状态冲突时，将发送状态代码 409。 这通常是同时更新或版本相互冲突的问题。状态代码 410 = 请求的资源不再可用，并且将不再可用。 了解网络错误 410。状态代码 500 – 用户通常看到的另一个状态代码，500 系列代码类似于 400 系列代码，因为它们是真正的错误代码。 当服务器由于意外问题无法完成请求时，将发生状态代码 500。 Web 开发人员通常必须对服务器日志进行梳理，以确定问题的确切问题来自何处。 -
Nginx-Quic重新编译Nginx支持HTTP3 HTTP3协议HTTP/3 的基础即谷歌多年探索的基于 UDP 的 QUIC 协议。与 TCP 相比，使用 UDP 可以提供更大的灵活性，并且可以使 QUIC 完全于用户空间中实现——对协议实现的更新不像 TCP 那样需要绑定到操作系统更新。使用 QUIC，可以简单地将 HTTP 级别的流映射到 QUIC 流的顶部，从而继承 HTTP/2 的所有优点，而不会产生队头阻塞。HTTP/3 虽仍处于草案状态，但很多用户已经跃跃欲试。优势HTTP/3 利用 QUIC 加速 HTTP 请求，QUIC 提供比 TCP 和 TLS 更高的加密和性能QUIC 是一种默认加密的新传输协议，旨在加快 HTTP 传输速度以及使其更加安全HTTP/3 基于 UDP，如果数据包丢失，只会中断一个流，而不会中断所有流，提高了同时获取多个对象的性能支持 0-RTT，消除服务器的 TLS 确认，使后续连接的启动速度更快.Nginx-Quic项目Nginx-Quic项目是Nginx官方推出的，跟上面说的Cloudflare的quiche没有关系，只是在Nginx的主线（mainline）版本的基础上推出的实验性质的项目，根据Nginx官方文档的说法，这项目是quic的分支，目前Nginx的版本为最新的Nginx 1.19.6，以后可能会将HTTP3相关功能合并进主线。正因为是实验性质项目，所以官方也不推荐在正式环境使用，但是我一个小博客，怕啥，不差这一回当小白鼠了，毕竟折腾的过程才是最有意思的。安装相关的依赖环境为了实现QUIC，NGINX编译必须用到quiche的相关库及BoringSSL的库文件,BoringSSL编译需要CMake 3.0或更高版本 、 需要Perl 、GCC、Clang 、Go环境。QUICHE需要 Rust 1.38或更高版本才能构建。CMAKE# 前往 https://cmake.org/files/ 选择最新版本下载 wget https://cmake.org/files/v3.21/cmake-3.21.0-rc2.tar.gz tar xvzf cmake-3.21.0-rc2.tar.gz cd cmake-3.21.0-rc2/ ./bootstrap make make installPERL# 前往 https://www.cpan.org/src/ 选择最新版本下载 wget https://www.cpan.org/src/5.0/perl-5.34.0.tar.gz tar -xzf perl-5.34.0.tar.gz # 编译安装 cd perl-5.34.0 ./Configure -des -Dprefix=/usr/mysf make make test make install # 建立新的软链接 mv /usr/bin/perl /usr/bin/perl.bak ln -s /usr/mysf/bin/perl /usr/bin/perl # 检查是否安装成功 perl -vRustcurl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | shGolangwget https://golang.org/dl/go1.17.1.linux-amd64.tar.gz tar -zxvf go1.17.1.linux-amd64.tar.gz -C /usr/local # 修改系统默认的go文件 ln -s /usr/local/go/bin/go /usr/bin/go #环境变量 export GOROOT=/usr/local/go export GOBIN=$GOROOT/bin export PATH=$PATH:$GOBIN export GOPATH=/home/gopath #环境变量请根据实际情况配置，如果没有特殊要求可以使用上方指令 BoringSSLgit clone --depth=1 https://github.com/google/boringssl.git cd boringssl mkdir build cd build cmake -GNinja .. ninja cd ../.. mkdir -p boringssl/.openssl/lib cp boringssl/build/crypto/libcrypto.a boringssl/build/ssl/libssl.a boringssl/.openssl/lib cd boringssl/.openssl ln -s ../include . cd ../..编译Nginx-Quic剩下的nginx的编译安装步骤就和正常的nginx编译安装基本一致，只是需要额外的参数来开启HTTP/3支持并使用Boringssl替代默认的OpensslNginx-Quic分支的官网是：hg.nginx.org/nginx-quic由于仍在开发所以没有稳定版本，前往官网后找到左侧栏中的“tar”按钮，点击下载后重命名为 nginx-quic.tar.gz 后上传到服务器即可。#假设你已经上传nginx-quic.tar.gz tar -zxvf nginx-quic.tar.gz cd nginx-quic #请根据自身需求更改下列指令参数，下方只是一个最基础的版本 ./auto/configure --prefix=/www/nginx --with-http_ssl_module --with-http_v2_module --with-http_v3_module --with-http_gzip_static_module --with-cc-opt="-I../boringssl/include" --with-ld-opt="-L../boringssl/build/ssl -L../boringssl/build/crypto" #最后编译即可 make && make install编写配置文件以下是一个最基础的配置文件，请根据自己的需要进行更改server { listen 80; listen 443 ssl http2; listen 443 http3 quic reuseport; # UDP listener for QUIC+HTTP/3 server_name blog.nannan.cool; #以下为TLS配置 ssl_protocols TLSv1.2 TLSv1.3; ssl_ecdh_curve X25519:P-256:P-384; ssl_ciphers TLS13-CHACHA20-POLY1305-SHA256:TLS13-AES-256-GCM-SHA384:TLS13-AES-128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-CHACHA20-POLY1305:EECDH+CHACHA20:EECDH+AES128; ssl_certificate /www/nginx/ssl/blog_nannan/certificate.pem; ssl_certificate_key /www/nginx/ssl/blog_nannan/private.key; add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload"; # 该选项用于开启address validation，但是会和下方的0-RTT冲突 #quic_retry on; # 开启 TLS 1.3 0-RTT ssl_early_data on; # 添加 Early-Data 头告知后端, 防止重放攻击 proxy_set_header Early-Data $ssl_early_data; # 参考nginx官方目前支持的http3版本，我们添加对应的header add_header Alt-Svc 'h3=":443"; ma=2592000,h3-29=":443"; ma=2592000,h3-T051=":443"; ma=2592000,h3-Q050=":443"; ma=2592000,h3-Q046=":443"; ma=2592000,h3-Q043=":443"; ma=2592000,quic=":443"; ma=2592000; v="46,43"'; #HTTP_TO_HTTPS_START if ($server_port !~ 443){ rewrite ^(/.*)$ https://$host$1 permanent; } #HTTP_TO_HTTPS_END }测试：当你修改完配置文件后，请重启你的Nginx服务，然后就可以前往 Geekflare 的 HTTP3 测试工具去测试你的网站啦！https://www.http3check.net 网站提供了网站的HTTP/3支持检测以下是我的博客测试的结果，如果你按照上面的方法进行了配置的话，应该也是可以成功的。
