基本的なServerSocketサーバーに対するNettyの利点は？
比較的単純なJava tcp/ipサーバーを作成する必要があり、Nettyのようなものを使用するか、単純なServerSocketとInputStream/OutputStreamをそのまま使用するかを判断するのに少し問題があります。
本当に要求をリッスンし、新しいクライアントのソケットを新しいスレッドの処理コードに渡すだけです。そのスレッドは、処理が完了して応答が送信されると終了します。
私はNettyのパイプライン、デコーダーなどのアイデアが好きですが、そのような単純なシナリオでは、追加の開発時間を追加する価値はないようです。当初の要件では少々やり過ぎに思われますが、考慮していないことがたくさんあるので、少し緊張しています。そのような単純な要件に対するNettyの利点は何ですか？何を考慮していませんか？
ストリームを使用したソケットの単純な読み書きに対するNettyの主な利点は、Nettyが非ブロッキング、非同期I/O（JavaのNIO APIを使用）をサポートすることです。ストリームを使用してソケットから読み書きする場合（およびServerSocketから受け入れられる接続ごとに新しいスレッドを開始する場合）、ブロッキング同期I/Oを使用しています。
Nettyアプローチははるかに適切に拡張されます。これは、システムが多数（数千）の接続を同時に処理できる必要がある場合に重要です。システムを多数の同時接続に拡張する必要がない場合は、Nettyのようなフレームワークを使用しても問題はありません。
いくつかの背景情報：スレッドは、オペレーティングシステムでは比較的高価なリソースです。各スレッドには、スタック用のメモリが必要です（たとえば、サイズが2 MBになる場合があります）。何千ものスレッドを作成すると、大量のメモリが消費されます。また、オペレーティングシステムでは、作成できるスレッドの数に制限があります。したがって、受け入れられた接続ごとに新しいスレッドを開始する必要はありません。非同期I/Oの概念は、スレッドを接続から切り離すことです（1対1の関係はありません）。スレッドよりも多くの接続が存在する可能性があり、接続の1つで何らかのイベントが発生すると（たとえば、データが受信されると）、イベントを処理するためにスレッドプールのスレッドが一時的に使用されます。
nettyを使用するメリットはすぐには得られませんが、実際には後で行われます要件が変更され、プロジェクトのメンテナンスがより複雑になる場合。 NettyはHTTPプロトコルの組み込みの理解をもたらすため、シンプルなRESTful Webサービスを提供できます。また、nettyがフレームワークとして提供する非同期要求処理を利用するオプションがあるため、パフォーマンスを向上させ、数桁の同時要求にサービスを提供できる可能性があります。
まず、サービスのロジックを記述して、通信レイヤーから独立するようにします。
Victor Sorokinが言ったように、自分で行うことには学習上の利点があります。したがって、ソケットを使用してそれを書く価値があるはずです。それは開始するためのより少ない労力を含みます、そしてそれが十分にうまくいくならば、あなたはレースに出かけます。
後でさらにスケーラビリティ/堅牢性が必要になる場合は、nettyに切り替えることができます。サービスロジックレイヤーと通信する新しいnettyレイヤーを記述し、それらを交換するだけです。