NGINX R17がリリースされました

こんにちわ、サイオステクノロジーの原です。

2018年12月11日にNGINX Plus R17がリリースされました。
今回のリリースではTLS1.3のサポート、レート制限のメソッド追加、stream/zone_syncモジュールの更新となります。

以下、詳細を和訳し記載します。

——————————————————————————————————————————————–

  • ssl_protocolsディレクティブのTLSv 1.3パラメータを用いたTLS1.3のサポート 
  • 2段階レート制限のサポート。過度のリクエストに対して最初に遅延しつつ、最終的には拒否されます。
  • JSON Webトークン（JWT）モジュールへのEd25519およびEd448暗号アルゴリズムのサポートが追加されました。
  • auth_jwt_key_requestディレクティブでOpenID Connectを使用している場合、アイデンティティプロバイダ（IdP）から直接JSON Webキー（JWK）を取得する機能を追加されました。
  • 新しいproxy_socket_keepaliveディレクティブにより、NGINX Plusとプロキシされたサーバの間でTCP keepaliveを有効にすることができます
  • keepalive_timeoutディレクティブは、アイドル状態のHTTPキープアライブ接続がNGINX Plusとプロキシされたサーバ間で開いたままになる時間を制御します
  • streamモジュールのproxy_requestsディレクティブは、そのサーバへの新しいUDP「セッション」を開始する前に、NGINX Plusからプロキシされたサーバに送信されるパケットの数を定義します
  • zone_syncモジュールは、zone_sync_ssl_server_nameディレクティブを使用してサーバー名検証のためのクラスタノードに接続するときにSNIを使用してサーバー名を渡すことができるようになりました

    以下、NGINX Java Scriptモジュールが更新されました。

    • 引数オブジェクトのサポート
    • 非整数分数のサポート
    • 追加時間メソッドのサポート：console.time()およびconsole.timeEnd()
    • 変数と関数を再宣言出来るようになりました。
    • TCP/UDPアプリケーション用のNGINX streamモジュールとの統合は入力トラフィック変更するためのsend()メソッドなど、様々なreturn関数を使用出来るようにリファクタリングされました。また出力トラフィックはコールバックを介して利用できるようになりました。

——————————————————————————————————————————————–

以下、原文を記載します。

——————————————————————————————————————————————–

NGINX open source build 1.15.7, 11 December 2018

NGINX Plus R17 is a feature release:

  • Support for TLS 1.3 using TLSv1.3 parameter to ssl_protocols directive
  • Support for two stage rate limiting with the new delay= parameter; excessive requests are initially delayed and then ultimately rejected
  • Added support for the Ed25519 and Ed448 cryptographic algorithms to the JSON Web Token (JWT) module
  • Ability to fetch JSON Web Keys (JWK) directly from identity provider (IdP) when using OpenID Connect with the new auth_jwt_key_request directive
  • New proxy_socket_keepalive directive allows TCP keepalives to be enabled between NGINX Plus and the proxied server
  • New keepalive_timeout directive controls how long an idle HTTP keepalive connection will stay open between NGINX Plus and the proxied server
  • New proxy_requests directive for the stream module defines how many packets will be sent from NGINX Plus to the proxied server before starting a new UDP “session” to that server
  • The zone_sync module can now pass the server name using SNI when connecting to cluster nodes for server name verification with new zone_sync_ssl_server_name directive
  • The NGINX JavaScript module has been updated:
    • Support for arguments objects
    • Support for non-integer fractions
    • Support for additional time methods: console.time() and console.timeEnd()
    • Variables and functions can now be redeclared
    • Integration with the NGINX Stream module for TCP/UDP applications has been refactored to use various return functions, including a send() method for modifying ingress traffic. Egress traffic is now available through a callback.

——————————————————————————————————————————————–

NGINX Conf 2018 参加レポート in アトランタ

こんにちは、サイオステクノロジーの原です。
サイオステクノロジーは今年10月9日から10日（計2日間）、アトランタで開催されたNGINX Conf 2018に参加しました。

今年のカンファレンステーマは「Journey to Microservices」で、マイクロサービスへの転換の旅立ちに向けて
を開発者から運用者、アーキテクト達が有意義に情報を収集する時間であったと思います。

本記事では、ジェネラルセッションの内容を会場の雰囲気も交えながら要約してお伝え出来ればと思います。

会場

NGINX Conf 2018はジョージア州アトランタのLoews Atlanta Hotel Conference Roomにて執り行われました。

ジェネラルセッションの会場はこんな感じでした。
ロゴマークがいかにもマイクロサービスへの旅立ちを象徴しているようですね。

 

ジェネラルセッション（1日目）

初めにCEOのGus Robertson 氏が登壇しました。

内容としては、デジタル時代の企業に影響を与える最新動向、モダナイゼーションの手法、
そこでNGINXアプリケーションプラットフォームがどのように役立つか説明をされました。

デジタル時代を生き残っていくためには、インフラが柔軟性・俊敏性に富んでおり、サービスは独立化 / 分散化していくことが大切です。
今後、NGINXアプリケーションプラットフォームも動的なデリバリーゲートウェイ機能を重きに置いて展開されるようです。

続いてプロダクトマネージメントVP のSidney Rabsatt 氏が登壇しました。

NGINX,Inc が提供するテクノロジーと、ソリューションが企業組織に選択の自由を与え、モダナイゼーションを迅速にするために必要な要素、またアジャイルに実現する方法を説明されました。

ジェネラルセッション（2日目）

2日目はプロダクトマネージメント Sr.ディレクターの Owen Garrett氏が登壇し、
現在リリースされている製品全体の要約と今後の製品ロードマップ、コミュニティ版の主要な機能アップデートについて説明しました。

 

NGINX Controller 2.0では、各NGINX Plusで管理しているAPIもGUIベースで運用管理が行え、変更時に１台ずつ変更・修正を行う必要が無くなります。また、クライアントから各マイクロサービスへのAPI通信（1:n）も１回で済みます。そのため、数多のマイクロサービスを稼働しているユーザーには非常に運用管理コストが簡素化されます。

 

また、NGINX Unit 1.4では、SSL/TLS、Node.js対応により、セキュアでより軽量な動的アプリケーション作成が可能となり、マイクロサービス上でのパフォーマンス向上が見込まれます。

既存ユーザーでNGINX PlusはAPIゲートウェイとして40%も利用されているようです。その背景として、今年に入ってマイクロサービスへの移行化が本格的に始めている企業が増えていることにありそうです。

さいごに

海外では先行してマイクロサービス環境への投資/導入が進んでおり、来年度以降は“モノリシック / マイクロサービス”が混在したハイブリッド環境が主流となり、ますますサービスの独立化・Ingress Controller・APIゲートウェイの導入に拍車が掛かっているんだと思いました。

 

それとは裏腹に日本市場では、“マイクロサービス”への移行に踏み止まっている企業も多数あり、ロードバランサーでの提案で止まってしまっています。

そのため、現時点ではNGINX PlusでAPIゲートウェイの訴求が難しく、まずは“マイクロサービス”の費用対効果、移行プロセスをお客様、内部の経営層に理解・判断頂けるよう地道に啓蒙活動を行っていく必要性があると感じました。

Save the date! NGINXがRed Hat Forum Tokyo 、Japan Container Daysに登壇します！

もうお申込みはお済みでしょうか？

NGINXが、11/8(木) 開催のRed Hat Forum Tokyoではゴールドスポンサーとして、12/4(火)－5(水) 開催のJapan Container Daysではランチスポンサーとして、出展します！

いずれのイベントでも、NGINX社による講演と、展示ブースでの参加を予定しています。また、どちらのイベントでも、サイオステクノロジーがパートナーとして、共同でブース運営に参加します。

お申し込みは以下のサイトから。

 

 

ぜひ、皆さまのご来場をお待ちしております！

11/14(水)、NGINX MeetUp Tokyo #1 を開催します！

前回のMeetUp #0に続き、11/14（水）にNGINX MeetUp Tokyo #1 を開催します。

概要

日本のNGINXユーザー、また関心をお持ちの方に向けてNGINX最大のイベント NGINX .conf 2018 の最新情報とWeb Application Firewall機能のNGINX WAFをご紹介します。2つのセッションとセッション終了後には懇親会を用意しておりますので、NGINXを利用する方同士での交流もいただける場になっています。

これからNGINXを使ってみたいという方も、NGINXを使いこなしている方も、NGINXにご興味をお持ちの方、NGINXが大好きなかたまで皆様のご参加をお待ちしております。

なお、Meetupの内容は後日動画配信を予定しております。遠方の方は配信動画の公開をお待ち下さい。 NGINX MeetUp Japanのグループ登録も合わせてよろしくおねがいします！！

プログラム

  • 16:30～ 　　　受付

  • 17:00～17:10 オープニング ＆ NGINX Meetup Japan 立ち上げについて

  • 17:10～17:40 講演1 NGINX .conf 2018最新情報

    概要：サイオステクノロジーの原尚史が、アトランタで2018年10月6日〜8日に開催されたNGINX .conf 2018 の最新情報をお伝えします。
    現地で入手したNGINXの最新情報をどこよりも早くお伝えいたします。 

    講師：サイオステクノロジー株式会社 イノベーティブソリューション事業企画部　原 尚史

  • 17:40～18:10 講演2 NGINX WAFについて

    概要：サイオステクノロジーのセキュリティエヴァンジェリスト 面 和毅が、NGINX WAFについてご紹介します。
    コミュニティ版とPlus製品の違いを含めてご紹介予定です。 

    講師：サイオステクノロジー株式会社 セキュリティエヴァンジェリスト　面 和毅

  • 18:10～19:00 懇親会 NGINX ノベリティ抽選会！！

※講演資料は本サイトにて後日公開予定です。

イベント参加について

以下URLよりお願い致します。

【申し込みURL】

https://nginx-mj.connpass.com/event/103617/

ソフトウェアロードバランサーによるアジャイル実現

こんにちは、サイオステクノロジーの原です。
今回は“アジャイル”をテーマに、いかにソフトウェアロードバランサーがアジャイルに向いているかについてブログに記載したいと思います。

アジャイルとは

アジャイルは従来のウォーターフォール手法（“要求仕様 – 設計 –  テスト – 実装 – 保守”といった各フェーズを順を追って着実に進めていく）と違い、
各フェーズ毎で順を追わず、柔軟に対応することで工数削減に繋がる手法です。

例えば、各データセンターへのロードバランサー導入プロジェクトがあるとします。

ウォーターフォール手法では、要求仕様フェーズでスケジュール、納期、成果物等をお客様としっかり合意を得た上で仕様書を作成し、仕様書に基づいて設計書に起こします。
設計書が完成するとロードバランサーのテストが始まり、各テスト項目がクリアした段階で実装に向かいます。
着実にフェーズをこなしていくため、正確性はありますが俊敏性は欠けています。

一方アジャイルでは、要求仕様フェーズである程度の情報が整い次第、実装に向けて各担当チームは各フェーズ（設計・テストフェーズ）に移行します。

このように各フェーズを一つずつ着実にこなしてから次フェーズに移行していく必要が無く、同時並行で各担当フェーズを進めていくことが出来ます。
また不足部分は各担当チームと柔軟に連携して改良していくことが出来るので、正確性に加えて俊敏性も実現出来る点が特徴です。

 

ソフトウェアロードバランサーでアジャイル実現

ハードウェアロードバランサーではスペックが固定されており、柔軟にスケールアウトかつスケールアップが行えず、高トラフィック時はネットワーク運用チームとの連携が必要となり、
設定変更時のトラフィックの影響範囲の調査や場合によってルール変更も必要です。そのため、設定変更の際も数時間から数日掛かるケースがあります。

しかし、ソフトウェアロードバランサーではハードウェアに依存しませんので、柔軟にスケールアウトかつスケールアップが行えるため、各チームが機敏に運用を行うことが可能となります。
またDevOpsで完結出来るため、ネットワーク運用チームとの連携は不要となり、運用者は設定変更を行う場合にも数秒で設定変更が行えます。

ソフトウェアロードバランサー としてのNGINX 

ソフトウェアロードバランサーの中でもNGINXはスケールアウト・スケールアップといったスケーラビリティに優れている以外にも、性能面でも優れています。
基盤も高スペックのものでなくても、パフォーマンスを発揮します。（2CPU core / 4GB RAMで90,000RPS 4,000 RSA SSL TPS  4,500 ECC SSL TPS 1GB スループットを実現）

ですので、トラフィック増加により無駄に運用変更を行う機会も無くなります。

下記詳細なサイジング・パフォーマンス例がございますのでご参考までに。

【サイジング・パフォーマンス例】
Sizing-Guide-for-Deploying-NGINX-on-Bare-Metal-Servers

またNGINX Plusではリアルタイムパフォーマンスモニター機能もGUIで搭載していますので、問題となっている点もすぐに解明出来、運用変更が可能です。

現在、ハードウェアロードバランサーを運用されている方は一度ソフトウェアロードバランサー NGINXを検討してみてはいかがでしょうか。
無料で評価版も30日間提供しておりますので、お気軽に下記ページからお問合せ下さい。

【評価版申請ページ】
https://nginx.sios.jp/free-trial

 

【参考URL】
https://www.nginx.com/blog/how-hardware-load-balancers-are-killing-agile-development-and-competitive-advantage/

nginx 1.15.4と1.15.5がリリースされました。

こんにちは、サイオステクノロジーの原です。

nginx.orgで2018年9月25日に1.15.4、2018年10月2日に1.15.5が公開されました。
今回のバージョンアップではSSL関連のディレクティブ機能拡充、ワーカープロセス・gRPC・error_pageディレクティブ関連のバグ修正が含まれています。

以下、リリース内容の詳細を参考訳として記載します。

nginx 1.15.4 リリース内容

＜機能追加＞
*）”ssl_early_data”ディレクティブでOpenSSLを使用可能。

＜バグ修正＞

*）ngx_http_uwsgi_moduleのバグ修正。Chris Caputoさん、ありがとう。

*）keepaliveディレクティブ文を使用すると、いくつかのgRPCバックエンドとの接続はキャッシュされない可能性があった。

*）”error_page”ディレクティブを使用して初期要求処理エラー（特にコード400のエラー）をリダイレクトすると、ソケットリークが発生することがあった

*）リクエストが “error_page”指示でリダイレクトされた場合、エラーを返すときに “return”ディレクティブ文は応答コードを変更しなかった。

*）標準エラーページとngx_http_autoindex_moduleモジュールの応答では、”bgcolor”属性が使用され、ブラウザでカスタムカラー設定を使用すると
　  誤って表示されることがある。Nova DasSarmaさん、ありがとう。

＜仕様変更＞

*） “no suitable key share”および”no suitable signature algorithm”のSSLエラーのログレベルが「crit」から「info」に下げられました。

nginx 1.15.5 リリース内容

＜バグ修正＞

*）OpenSSL 1.1.0h以降を使用している場合、ワーカープロセスでセグメンテーションエラーが発生する可能性があった。バグは1.15.4でも発生していた。

*）潜在的なバグ修正。

 

【参考URL】

http://nginx.org/en/CHANGES

NGINX PlusのAPIゲートウェイソリューション

こんにちわ、サイオステクノロジーの原です。

今回はNGINX PlusのAPIゲートウェイ機能に焦点を当てたいと思います。

 

APIゲートウェイとは

Web APIを用いたクラウドインテグレーションを行なう為に必要となるアーキテクチャです。

企業ネットワーク内にデプロイされているアプリケーションとパブリッククラウドサービスとの間
にゲートウェイとして機能し、全ての通信はこのAPIゲートウェイを介して行ないます。

例えば、通常はクライアントからバックエンドの各マイクロサービスのAPIを数回に渡って
呼び出すことが必要であり、クライアント側で各マイクロサービスのAPIを管理する必要が
ありました。
このAPIゲートウェイを導入することにより、クライアントはAPIゲートウェイに対して1回だけ
APIを呼び出すだけで、後はAPIゲートウェイが各マイクロサービスのAPIの呼び出しを肩代わり
してくれます。

APIゲートウェイの使用例

下記の表はAPIゲートウェイとしてのNGINX Plusが外部ソースからのAPIリクエストを管理し、
内部サービスにルーティングするための要件を満たす方法を示しています。

  APIゲートウェイ要件 NGINX Plusソリューション
コアプロトコル REST（HTTPS）、gRPC HTTP、HTTPS、HTTP / 2、gRPC
その他のプロトコル TCP-borneメッセージキュー WebSocket、TCP、UDP
リクエストルーティング リクエストは、サービス（ホストヘッダー）、APIメソッド（HTTP URL）、およびパラメーターに基づいてルーティングされます ホストヘッダー、URL、およびその他の要求ヘッダーに基づいた非常に柔軟なリクエストルーティング
APIライフサイクルの
管理		 従来のAPIリクエストの書き換え、廃止予定のAPIへの呼び出しの拒否 要求に直接ルーティングまたは応答するための包括的な要求書き換えと豊富な意思決定エンジン
脆弱なアプリケーションの保護 APIとメソッドによるレート制限 送信元アドレス、要求パラメータを含む複数の基準によるレート制限。バックエンドサービスへの接続制限
オフロード認証 着信要求の認証トークンの検査 JWT、APIキー、外部認証サービス、OpenID Connectなどの複数の認証方法のサポート
変化するアプリケーショントポロジの管理 構成変更を受け入れ、青緑のワークフローをサポートするためのさまざまなAPIの実装 エンドポイントを特定するためのAPIとサービスディスカバリーの統合 ブルーグリーンデプロイメントやその他のユースケース用にAPIを編成できます

NGINX PlusではWebトラフィックを容易に管理出来、プロトコル（HTTP/2, HTTP, FastCGI, uwsgi）を変換し、一貫した設定とモニタリングGUIの提供が可能です。

NGINX PlusのAPIゲートウェイ機能

NGINXコミュニティ版はもとはHTTP（Web）トラフィックのゲートウェイとして開発されており、設定されているプリミティブはHTTPリクエストの観点から表現されています。
NGINX Plusではより複雑なAPIをマップし、多くの一般的なAPIゲートウェイタスクを処理します。

NGINX PlusによるAPIゲートウェイの各処理方法の詳細については以下のリンクを参照下さい。

【参考URL】

https://www.nginx.com/blog/consolidating-your-api-gateway-and-load-balancer-with-nginx/

9/7(金)、NGINX MeetUp Tokyo #0 を開催しました！

9月7日(金)、NGINX MeetUp Tokyo #0 と題し、サイオステクノロジー本社でNGINXにご興味のある30名の皆様とお会いできました！

今回のメインテーマは、ソフトウェアロードバランサーの優位性、中でもNGINX、NGINX Plusのロードバランサーとしての優れた機能や事例のご紹介です。

続きを読む

2018年 ロードバランサー価格・パフォーマンス比較：NGINX Plus vs F5 BIG-IP

こんにちは、サイオステクノロジーの原です。

今回はNGINX PlusとF5 BIG-IP ロードバランサーの機能、価格比較をテーマに記事を掲載していきます。

 

前回（2016年）に機能、価格比較をしましたが、この2年間でNGINX Plusはもちろんのこと、F5 BIG-IPの
ロードバランサーの機能・パフォーマンスも進化しています。
特にパフォーマンスが進化している点としては以下挙げられます。

  • HTTPリクエスト/秒（RPS）
  • SSL / TLSトランザクション/秒（TPS）
  • HTTPスループットはギガビット/秒（Gbps）

上記点を考慮し、F5 BIG-IP 製品群のパフォーマンスメトリックを比較していきます。

NGINX Plus　vs　F5 BIG-IP i2600

[Dell R330ハードウェアスペック]
Intel Xeon 4110 @ 2.1GHz 8Core およびIntel XL710 2×40 Gbeネットワーク・インターフェース・カード

 

　 F5 BIG-IP i2600 NGINX Plus（Dell R330）
コスト
ワンタイムハードウェアコスト $19,175 $2,200
年間8×5サポートとソフトウェアの
サブスクリプション費用		 $2,300 $2,500
総費用（1年目） $21,475 $ 4,700 
（78％節約）
総費用（3年目） $26,075 $ 9,700 
（63％節約）
総費用（5年目） $30,675 $11,700
（59％節約）
パフォーマンスメトリック
HTTP RPS 350,000 350,000
SSL / TLS TPS 2,500 14,000 1（5.6x）
スループット（Gbps） 10 40（4x）

1 OpenSSL 1.0.2dの使用

NGINX Plus　vs　F5 BIG-IP i5600

[Dell R630ハードウェアスペック]

Intel Xeon E5-2699 v4 @ 2.2 GHzデュアル22コアとデュアルIntel XL710 2×40 Gbeネットワーク・インターフェース・カード

 

　 F5 BIG-IP i5600 NGINX Plus（Dell R630）
コスト
ワンタイムハードウェアコスト $53,000 $10,000
年間8×5サポートとソフトウェアの
サブスクリプション費用		 $9,540 $3,500
総費用（1年目） $62,540 $13,500
（78％節約）
総費用（3年目） $81,620 $20,500
（75％節約）
総費用（5年目） $100,700 $27,500
（73％節約）
パフォーマンスメトリック
HTTP RPS 1.1M 1.2M(1.1x)
SSL / TLS TPS 20,000 61,000(3.1x)1
スループット（Gbps） 60 70(1.2x)

1 OpenSSL 1.0.2dの使用

結論

同等スペックのF5 BIG-IPと比較した結果、NGINX Plusではトータルコストも大幅に削減し、かつSSL / TLS TPSでの性能向上が顕著に表れています。

F5 BIG-IPは20年以上にわたりIT業界を牽引してきました。
しかし、今日ではハードウェアアプライアンスからクラウドネイティブなソリューションへの移行を検討する
企業も増えてきています。

そのソリューションの選択肢としてNGINX Plusのソフトウェアベースのロードバランサーを採用し、コスト面と
性能面で恩恵を受けています。

この機会に社内のアプリケーションデリバリーを見直してみてはいかがでしょうか？

 

NGINX Plus（30日間）評価版の申し込みにつきまして、絶賛受付中です。
是非お気軽にご連絡下さい。

評価版申請ページはこちら

 

【参考記事】
NGINX Plus vs. F5 BIG-IP: 2018 Price-Performance Comparison

NGINX R16がリリースしました。

こんにちわ、サイオステクノロジーの原です。

2018年9月5日にNGINX Plus R16がリリースされました。
今回のリリースではクラスタ機能の追加、UDPパケットの新たなプロトコルにも対応し、
更なるNGINXインスタンス可用性と拡張性が高まりました。

以下、詳細を和訳し記載します。

——————————————————————————————————————————————–

  • モジュールを使用したクラスタでのレート制限のサポートzone_sync
  • モジュールを使用してクラスタ内のキーバリューストアをサポートzone_sync
  • キーバリューストアモジュールのタイムアウトのサポート
  • randomロードバランシングアルゴリズムを2つの選択肢のオプションでサポートします。
    2つの選択肢を使用する場合、least_timeまたはleast_conn2つの負荷分散の決定に使用できます
  • streamクライアントからの複数のUDPパケットを新たにサポートし、拡張されたUDP負荷分散（モジュール）OpenVPN、VoIP、VDIなど、より複雑なUDPプロトコルをサポートします。
  • プロキシプロトコルv2（PPv2）ヘッダーのサポート、およびヘッダー内のカスタムTLV値の検査機能
  • AWS PrivateLinkのサポート、AmazonのVPCへのセキュアなトンネル作成技術
  • OpenIDの接続のリファレンス実装で、不明なセッショントークンをサポートするように拡張されました
  • TCP / IP streamプロキシを使用してトラフィックを転送する場合のSSL / TLSとその他のプロトコルを区別する新しい変数が追加されました。（$ssl_preread_protocol）
  • 新しい暗号化セッション動的モジュールが利用可能になりました。
  • NGINX JavaScriptモジュールが更新されました：
    • 各HTTPリクエストに関連付けられたリクエスト属性とレスポンス属性の両方にアクセスするための単一のobject（）が追加されました。
    • 新しい言語サポート：bytesFrom()、padStart()、padEnd()、getrandom()、getentropy()、およびバイナリリテラル

——————————————————————————————————————————————–

以下、原文を記載します。

——————————————————————————————————————————————–

NGINX open source build 1.15.2, 5 September 2018

NGINX Plus R16 is a feature release:

  • Support for rate limiting in a cluster using zone_sync module
  • Support for key-value store in a cluster using zone_sync module
  • Support for timeouts in key-value store module
  • Support random load balancing algorithm with option of two choices. When using use two choices, least_time or least_conn can be used for the load balancing decision between the two choices
  • Enhanced UDP load balancing (stream moddule) with new support for multiple UDP packets from the client. Support more complex UDP protocols such as OpenVPN, VOIP, and VDI.
  • Support for the Proxy Protocol v2 (PPv2) header, and the ability to inspect custom TLV values in the header
  • Support for AWS PrivateLink, Amazon’s technology for creating secure tunnels into a VPC
  • The OpenID Connect reference implementation has been extended to support opaque session tokens
  • New $ssl_preread_protocol variable to distinguish between SSL/TLS and other protocols when forwarding traffic using a TCP (stream) proxy
  • New Encrypted-Session dynamic module available
  • The NGINX JavaScript module has been updated:
    • There is now a single object (r) to access both request and response attributes associated with each HTTP request.
    • New language support: bytesFrom(), padStart(), padEnd(), getrandom(), getentropy(), and binary literals

——————————————————————————————————————————————–