インタビュアー：私は尋ねますネッティー

ネッティー

FTP、SMTP統合JBOSSが提供する最も人気のNIOフレームワーク、HTTPプロトコル

1. シンプルなAPI
2. 成熟し安定しました
3. ・アクティブなコミュニティ
4. 大規模な検証（インターネット、ビッグデータ、ネットワークゲーム、電気通信）後
   elasticsearch、Hadoopのサブプロジェクトアブロプロジェクト、アリのオープンソースフレームワークダボ、ネッティーを使用

バイオ

長所：単純なモデル、簡単なエンコーディング欠点：パフォーマンスのボトルネック、リクエスト、およびスレッドの数N：高い同時実行の下にNの関係、スイッチング損失をCPUスレッドコンテキストは偉大なケースです：疑似NIO：Tomcatの7は、BIO、7後のNIO改善される前に、 、ハンドルロジックにスレッドプールを使用します

IOモード

かどうか洗濯の服を見て、タイミングを他のことを行うには> - - 投げ服非同期の非ブロッキング自分の服を洗った後、乾燥させる>：同期のブロッキング：服を投げ - - >洗濯機の洗濯>非ブロック同期ドライ服に行きます：投げ服 - 問題他のことを行うには>、および洗浄服は自動的に十分に乾燥し、あなたがよく乾かし通知します

I / Oモデル5種類

I / Oモデルの五種類：IOをノンブロッキング、IOをブロックし、駆動信号IOをIOを多重化し、非同期IO、最初の4つの同期IO、ユーザ空間カーネルデータには、コピーがブロックされています

IOをブロック

IOをノンブロッキング

IO多重化

コアは：複数の接続を同時に処理することができ、そして選択システムは、各ソケットへのrecvfrom関数を呼び出しは、非ブロッキングブロッキング機能ブロック選択ソケットは欠点をブロックされていないです。接続数が高くない場合、パフォーマンスは、マルチスレッドよりも必ずしもよりありません+ブロックIO良い（複数選択機能を呼び出します）

駆動信号

非同期IO

メカニズムを使用して、将来、リスナー

IO操作は2つのステップに分けられます。

1. データの準備を待って、IO要求を開始
2. 実際のIO操作は、データをカーネルからプロセスにコピーされる
   ことを除いてIO、IOブロッキング、非ブロッキング開始するIO要求ブロックする
   同期IOを、実際の書き込み処理要求がブロックされているIO非同期IO
   ブロックされたスレッドは、非ブロッキング状態で
   同期が非同期通知メカニズムは、メッセージで
   同期が非同期データを読み書きするためにイニシアチブを取る必要はありません、データを読み書きするためのイニシアチブを必要とする
   ユーザーのための同期および非同期IO IOインタラクティブなアプリケーションを、カーネル

IO多重化

I / O、ネットワークI / O、手段を多重化TCP接続の複数の多重手段は一つまたは複数のスレッドを指します。簡単に言えば：複数のTCP接続を処理するための1つまたは複数のスレッドを使用することがあり、最大の利点は、オーバーヘッド削減することである、プロセスのあまりにも多くのスレッドを作成しない、プロセスでこれらのスレッドを維持する必要はありません

選択する

ファイルディスクリプタwritefds、readdfs、exceptfds30w接続がライブにブロックされ、その他のデータ読み出し、書き込み可能な、異常な、または配列全体がイベントを処理するfdsetが発生している見つけることができ横断することにより復帰後に正常にタイムアウト関数の戻り値を、選択し、準備を見つけるためにほぼすべてのサポートされるプラットフォーム、クロスプラットフォームのサポートとの良好な欠点にディスクリプタfd、対応するIO操作、：

1. ファイル記述子FDの性能劣化の数の増加に伴ってポーリングを使用してスキャンファイルディスクリプタ、すべてのスキャンを選択。
2. Slect各コール（）は、カーネルモード、及びトラバース（ユーザ空間へのカーネル・メッセージングの両方）へのユーザーモードからコピーされたfdを設定する必要があります
3. 最大の欠点は、単一のプロセスのオープンFDの限界があるということです。デフォルトは1024です

投票

カーネル・モード、及びトラバースにユーザーモードからコピーされたfdを設定するために必要なように同様の基本的なプロセスを選択し、ポーリング処理が記述子の複数である、記述子は、状態に応じて処理されます。差は（FD記憶されたリンクリストを使用して）は、最大ポーリングファイル記述子の制限がありませんです

epollを

記述子のみ、イベント通知を使用したら、コピーしたユーザーモードカーネルモードに限定されるものではなく、登録epoll_ctlは、FD、準備FDたら、対応する利点を有効にするには、カーネルのコールバックメカニズムを使用してfdは：

1. FD制限はありませんが、FD上限は、オペレーティング・システムのファイル番号でサポートされる最大である（65535）ハンドル、接続されている単語の数百万人のための1Gメモリサポート10Wおそらくハンドル支持、16Gメモリを扱うことができます
2. 高効率、代わりにポーリングのコールバック通知の使用は、数FD増加効率と低下しません。
3. コールバック機構を通知することにより、カーネルとユーザスペースが実現するためにメモリの同じ部分をのmmap
   欠点：
   選択/ポーリング複合体よりもプログラミングモデル
   Linuxカーネルのコア機能を
4. epoll_create（）システムが起動し、それがB +木、Linuxカーネルのファイルシステムに適用される、リターンのepollオブジェクトはFDです
5. epoll_ctl（）操作のepollオブジェクト、対応するリンクFDを削除追加、変更オブジェクト、バインドコールバック関数
6. 対応するIO操作を決定し、完了するためのイベントがepoll_wait（）
   の例を：100W接続を選択し、世論調査では、性能、中にファイルディスクリプタについてどのようにより積極的な1W、
   選択：マクロ定義を変更しない、100Wをサポートするために、1000のプロセスを必要としますが接続されて
   投票を：100W接続、しかし、すべてをトラバースのコピーに応じて、リソースを大量に消費するスペースがあり
   ませんトラバースFD、カーネル空間とユーザ空間データをコピーしません：ファイルディスクリプタ
   であれば接続100W、95Wアクティブ、ほとんどの世論調査とのepollは、

Java的i/o

1. JDK1.4は、同期ブロッキングモデル（BIO）の使用である前に
   オペレーティングシステムが直接非同期IO（AIO）を提供することができるので、大規模なサービスは、一般に、C / C ++を使用し
2. NIOのJDK1.4の導入後、IO、jdk1.7アップグレード打ち上げNIO2.0を非ブロック、AIOはIO非同期機能、サポートファイルやネットワークソケットを提供

ネッティースレッドモデルと原子炉モデル

反応器パターン（リアクターのデザインモード）、イベント駆動型、イベント駆動型アプリケーション、1つ以上のクライアント要求およびスケジューリング分離に基づくデザインパターンです。イベント駆動型のアプリケーションでは、同期的、秩序ある処理は複数のサービス要求を受け入れます。同期の非ブロッキングIOの利点に属します：

1. 反応器自体が同期されているがないため、単一の同期の高速応答は、ブロックされました
2. プログラミングは比較的簡単であり、最大はマルチスレッドおよびマルチスレッドを避けるために、同期、処理切替オーバーヘッドの複雑さを避けるために
3. 原子炉の数によってスケーラビリティは、簡単にCPUリソースの例のをフルに活用することができます
   欠点を：
4. デバッグするために、比較的複雑で困難
5. 原子炉のモデルは、基盤となるシステムのサポートを必要としています。たとえば、オペレーティングシステムの選択Javaサポートは、selectシステムコールをサポートしています

原子炉シングルスレッドモデル

1. NIOサーバーとして、クライアントは、TCP接続を受け入れ、NIOのクライアントは、サーバーへのTCP接続を開始します
2. 書き込み要求に応じて、サーバ要求データとリードレスポンス、クライアントと読ん
   シーンを：
   対応するサービスは、小型、シンプルで高負荷、高同時実行不適切なため、コーディングに適しています。要求を処理NIOスレッドが多すぎる、負荷が高く、スレッドが使用不可掛けた場合の応答は、要求がタイムアウトの多数で、その結果、分解されます

原子炉のマルチスレッドモデル

アクセプターは、ときにそのような認証時間のかかる操作の操作を担当して行われる必要があるとき、会うほとんどのシナリオ、：アクセプタスレッド、NIOは、一般的に独自のスレッドプールを使用するスレッドグループは、タスクキューおよび複数のスレッド可能なシーンが含まれていますそれは、高い同時実行でのパフォーマンスの問題を持っています

メインスレッドモデルから原子炉

アクセプターは、スレッドではなく、NIOスレッドのグループは、スレッドが2つのスレッド・プールはIOアクセスと処理シナリオを処理するように、IO NIOスレッドのセットです：現時点では、ほとんどのシーンを満たす、ネッティーもスレッドモデルBossGroupの使用を推奨しましたサービス接続を処理するワークグループプロセス

代わりに、NIO AIOを使用してのネッティー

Linuxシステムでは、基礎となる実装AIOがまだファイルディスクリプタを使用して、NIOは、性能網状全体的なアーキテクチャの反応器モデルにおける明確な利点は、ファイルディスクリプタの機構を使用して、同じ存在しない、IOが多重化非ブロッキング同期モデルは、Java網状に基づいています非同期非ブロック、イベント駆動型、高性能、高信頼性、高カスタマイズ性：非同期通信を実装NIO Frameworkクラスライブラリを備えています。

エコーサービス

サービスを試運転し、テストするためのエコーサービス

ソース解析

イベントループ和EventLoopGroup

三つの要素の高性能RPCフレームワーク：スレッドのようなモデルイベントループをスレッドIOモデル、データ・プロトコル（HTTP、brotobuf /倹約）、イベントループは、複数のチャンネルを提供することができ、チャンネルは唯一のイベントループである、あなたは、最適化のリソースへの複数のイベントループを作成することができます接続、EventLoopGroup責任イベントループ、EventLoopGroup Cahnnelで使用、
受け入れる接続、読み取り、writeEventLoopGroupスレッドのデフォルト数で作成された2 * CPUコアの数である：NIO（複数のチャネルを処理するシングルスレッド）BIO（チャネル処理スレッド）イベントが

ブートストラップ

1. グループ：スレッドを設定モデル、スレッドモデル比較EventLoopGroup炉
   1）シングルスレッド。

EventLoopGroup g = new NioEventLoopGroup(1);
ServerBootstrap strap = new ServerBootstrap();
strap.group(g)复制代码

2）マルチスレッド3）メインスレッドから

チャネル

NioServerSocketChannelOioServerSocketChannelEpollServerSocketChannelKQueueServerSocketChannel

childHandler

各チャネルの内部のデータ処理

childOption

作動受け入れるように接続された後、

オプション

新しく作成されたの役割についての各チャネルは、TCP接続のいくつかのパラメータを設定します

• ChannelOption.SO_BACKLOGの
  店は、3ウェイハンドシェイクの要求を完了したの待ちキューの最大長
  根本的な知識へのLinuxサーバーのTCPコネクション：
  SYNキュー：ハーフ接続キュー、フラッド攻撃（大量の偽のIP最初のハンドシェイクパケットを送信する）、TCP 最大 syn_backlog（半修正接続VIに/etc/sysctl.conf）
  キュー受け入れ：最大接続数に接続されたキュー完全net.core.somaxconn現在のマシンを
  バックログがSOMAXCONNより大きい場合、後者が優先してシステムSOMAXCONNのデフォルトパラメータは、十分な大きさでなければなりません
  
• ChannelOption.TCP_NODELAYの
  デフォルトでは、Nagleアルゴリズムができるだけでなく（そして、伝送時間を短縮するために、送信された特定のサイズを蓄積するNagleアルゴリズムと）、送信データ、真の値がNagleアルゴリズムをオフにしたときに直ちに、高いリアルタイム要件、偽でありますネットワークのACKパケットに存在している
  （TCP SYNACKは、第三のハンドシェイクのACKを受信しない場合の再試行は、回復セミジョイン= 0を加速し、再試行は行われず、デフォルト値は5で、各待っ30S、約半分保留ライブ接続を180Sは、TCP SYNは、デフォルト値は5で再試行、SYN + ACKパケットを受信しなかったクライアント、SYNパケットの送信を再試行するクライアント5）

childOption

リンクされた後の役割を受け入れるために、

childHandler

各チャネルの内部のデータ処理

チャネル

• チャネル
  接続チャネルを確立するために、クライアントとサーバー
• ChannelHandler
  チャンネルの論理処理を担当します
• ChannelPipeline
  整然としたChannelHandlerコンテナの管理を担当

AチャンネルChannelPipelineを含む、順次ChannelPipeline内のすべてChannelHandlerに添加されます。チャンネルときの状態が変化し、対応するイベントをトリガ

ステータス：

• channelRegistered
  チャンネルはイベントループに登録され、バインドセレクター
• channelUnRegistered
  チャンネルが作成されましたが、イベントループ結合されていない内部、およびセレクタに登録されていません
• channelActiveは
  、リモートホストへの接続アクティブになり、データを受信し、送信することができます。
• channelInActive
  チャンネルがアクティブで、リモートホストへの接続はありません

ChannelHandler和ChannelPipeline

ChannelHandlerライフサイクル：handlerAdded：exceptionCaught呼をChannelHandler ChannelPipelineから除去するとき：handlerRemoved ChannelHandler ChannelPipelineコールに加えられたとき実行例外が存在する場合にスローされる二つのサブ呼び出しChannelHandlerインタフェース：ChannelInboundHandler（インバウンド）は：入力データを処理する状態のタイプチャネルを変更チャンネルアダプタプロセス出力データ：ChannelInboundHandlerAdapter（アダプターデザインパターン）、一般SimpleChannelInboundHandlerChannelOutboundHandler（アウトバウンド）アダプタ

ChannelPipeline：パイプライン工場などのような上記複数のChannelHandlerに添加することができるので、ユーザができることを、チャネル出力イベントインターセプト入力を介して、ChannelPilelineはインターセプターの高度形態を実装する、ChannelHandler例の束として見ることができます治療とChannelHandler間のイベントの上にインタラクティブなゲイン完全に制御

ChannelHandlerContext

1. ChannelHandlerとChannelPipelineとの間のブリッジとしてchannelHandlerContext
   ChannelHandlerContext方法の一部とチャネルとChannelPipleline一致である、のような書き込み方法を呼び出す
   ChannelHandlerContextが書き込みメソッドを呼び出すことができ、チャネル、ChannelPipelineを、最初の二つは、パイプライン内の流れ全体に伝播するが、唯一の後続ChannelHandlerContextにされていますのスプレッドのハンドラ
2. AbstractChannelHandlerContext
   二重にリンクされたリスト構造、次/前の後継者、先行ノード
3. DefaultChannelHandlerContextは、実装クラスですが、それらのほとんどは親クラスが完了している、全体が単に主なものは、ハンドラの種類を決定することである方法のいくつかを達成するために
   火の下で火災を呼び出すことはありません、ハンドラを呼び出します

ハンドラの実行順序

InboundHandlerのオーダー実行、OutboundHandler逆順の実行

channel.pipeline().addLast(new OutboundHandler1());
channel.pipeline().addLast(new OutboundHandler2());
channel.pipeline().addLast(new InboundHandler1());
channel.pipeline().addLast(new InboundHandler2());复制代码

InboundHandler1 InboundHandler2 OutboundHandler2 OutboundHandler1InboundHandler1はOutboundHandlerctx.write（MSG）メッセージの送信に転送ctx.writeによってfireChannelRead（）メソッドInboundHandler（MSG）を介して呼び出される間、インバウンドの端部に配置される必要がある、発信した後、outboundHandlerは、他のチャネルを使用して、実行しません.WRITE（MSG）、またはpipline.write（MSG）、考えられなかったでしょう（伝播メカニズム）クライアント：アウトバウンドサーバーへの着信、その後を開始要求し、要求を受け入れるには、：まず、インバウンド、アウトバウンド、その後、要求を受け入れ、その要求を送信します

ChannelFuture

I / 0操作が開始されると、：ChannelFutureは、I / 0業績や未完成の状態に関する情報を提供する一方ネッティーすべてのI / 0操作は、すぐに任意のI / 0呼び出しが戻ることを意味し、非同期であります新しいオブジェクト、最初に新しい未完成の、それもない成功を作成し、またI / 0操作が完了していないによるキャンセルされました。完了：I / 0操作にかかわらず、成功、失敗またはキャンセルの完了すると、ある特定の情報を完了したときに、そのような失敗の原因として失敗したとして、今後はマークされているが、そのノートを喜ばでも失敗ifと完了状態属しキャンセル。注：Doが同期とのawaitでchannelhandlerで呼び出すことはできません同期メソッドを呼び出し、IOスレッドで将来のオブジェクトを待っていません

ChannelPromise

結果をさらに拡大するための継承ChannelFutureは、IO操作を設定するために使用しました

コーデック

Javaのシリアライズ/デシリアライゼーションの、URLコーデック、base64でJavaのコーデック連載の欠点があります：

1. 言語を横断することができません。
2. コードシリアル化されたストリームは、データパケットが大きすぎる、大きすぎます
3. シリアライズとデシリアライズ比較的パフォーマンスの低下

他の業界コーデックフレームワーク：PB、倹約、マーシャリング、KYRO

コーデック内部ネッティー：

• デコーダー：インバウンドInboundHandlerの処理を担当
• エンコーダ：アウトバウンドOutBoundHandler処理を担当
  ネッティーデフォルトのコーデックを、だけでなく、コーデックのカスタム
  エンコーダ（エンコーダ）、デコーダ（デコーダ）、コーデック（CODEC）

ネッティーデコーダーデコーダー

デコーダはChannelInboundHandlerに相当し、メインメッセージは、バイト配列オブジェクトのメソッドに変換されます。

• デコード：コモン
• decodeLastは：最後の数バイトを処理し、最後のメッセージcahnnelが得られ、閉じている
  デコーダ。
• ByteToMessageDecoder
  メッセージにバイトのため、十分なバッファがあるかどうかをチェックするバイト
• ReplayingDecoder
  継承ByteToMessageDecoderは、十分なデータバッファがあるかどうかを確認する必要が、スピードはByteToMessageDecoderよりも若干遅くはありません
• MessageToMessageDecoder
  （例えばPOJO POJOに）メッセージの別の一種の復号化メッセージのための
  共通のデコーダ:(主に下層のTCPパケットとアンパック粘度の問題を解決するために）
• DelimiterBasedFrameDecoder：メッセージ・デリミタ復号を行います
• LineBasedFrameDecoder：改行マークとしてデコーダの端
• FixedLengthFrameDecoder：固定長デコーダ
• LengthFieldBasedFrameDecoder：ユニバーサルデコーダ復号の長さに基づいてメッセージ=ヘッダ+ボディ、
• StringDecoder：テキストデコーダ、列に受信されたメッセージは、通常、上記のいくつかと合わせ、次いでバックサービス・ハンドラを追加します

ネッティーエンコーダエンコーダ

エンコーダ対応は、ChannelOutboundHandlerあるメッセージオブジェクトエンコーダにバイト配列を変換します。

• MessageToByteEncoderの
  バイト配列、書き込みメソッドの呼び出し、サポートされていない場合、現在のエンコーダが、送信されるメッセージのタイプをサポートするかどうかをまず判断し、パススルーにメッセージ
• 符号化された別のメッセージに一つのメッセージからMessageToMessageEncoder

ネッティー組成コーデックコーデック

利点は：ペアで、符号化及び復号化するクラスの欠点で行われる：結合、乏しいスケーラビリティ

• ByteToMessageCodec
• MessageToMessageCode

TCPスティックパッケージ、開梱

開梱TCP：完全なパッケージは、スティッキーTCPパケットを送信したTCPパケットを複数に分けることができる：大きなパケットの送信中にカプセル化された小パケットを複数受信した場合、データパケットの数は、クライアント、サーバ粘着送信しますパケットの送信および受信側は、送信者が発生することがあり、この理由の理由である：TCPデフォルト理由Nagleアルゴリズムの受信者が使用する：TCP受信されたデータがキャッシュ内に配置され、アプリケーションは、キャッシュより遅い非粘性UDPパケットから読み出されます問題開梱、国境協定があります

TCPは読み半パックソリューションを書きます

送信者：閉じるNagleアルゴリズムの受信者：TCPは全く流れ境界がなく、取引スティックパッケージ現象に機構がない、そしてプロトコル自体がスティックパッケージを避けることができない、半分パックリーダーの発生は、アプリケーション層での半分のパケット処理アプリケーション層ソリューションを必要としメソッドを読み取りおよび書き込み：

1. 設定された固定長のメッセージ（10文字）
   abcdefgh11abcdefgh11abcdefgh11
2. メッセージの境界を設定する（$$カット）
   dfdsfdsfdf $$ dsfsdfdsf $ dsfdsfsdf
3. メッセージヘッダ、メッセージヘッダ長情報開始識別子と、メッセージにメッセージを格納すると、プロトコル
   ヘッダ+ボディ

ネッティーは、TCPの半分パックリテラシープログラムを解決するために来ます

• DelimiterBasedFrameDecoder：指定メッセージデコーダデリミタ
• LineBasedFrameDecoder：改行マークとしてデコーダの端
• FixedLengthFrameDecoder：固定長デコーダ
• LengthFieldBasedFrameDecoder：ユニバーサルデコーダ復号の長さに基づいてメッセージ=ヘッダ+ボディ、

実際の半分パックリーダー

LineBasedFrameDecoder：文字列にオブジェクトデコーダStringDecoderデコーダフラグを終了する改行

カスタム区切り解決TCPリテラシーの問題

DelimiterBasedFrameDecodermaxLength：行の最大長を表し、長さはまだTooLongFrameExceptionfailFastスローカスタム区切り文字の上に検出されない：falseは、その後、メッセージが完了するまでデコードされた場合は、直ちにtrueの場合後、その後のmaxLength TooLongFrameExceptionの上に投げ、デコードし続けるには、実行されません後に、次いでTooLongFrameExceptionstripDelimiterスロー：デコードされたメッセージは、除去デリミタ区切り文字であるかどうか：セパレータ、タイプByteBuf

半分パックリーダーのカスタム長LengthFieldBasedFrameDecoder

バイトの数を表すlengthFieldLength長フィールド（メッセージ本文フィールドはバイトの指定された長さの後にスキップする）maxFrameLengthパケット長lengthFieldOffset最大オフセット長さフィールドは、データフィールドの長さフィールドのフレーム長は、それ自体が始まります通常長lengthAdjustmentヘッダ+ボディは、補正値は、それが負、ヘッダ長フィールドは、メッセージ全体のパケットの長さであることを開発者であれば,,網状最初復号化されたフレームからの対応する数を減算する必要があり、長さフィールドに追加されinitialBytesToStrip倍のバイト数を除去した後、完成した完全なパケットを取得し、長さバイトの前の指定された数を無視し、パケット長フィールドなしにデコーダを得るために適用されます

ByteBuf

バイトコンテナ、

• JDKのByteBufferは、ネイティブに
  読み取りと書き込みの公共インデックスを、操作のたびに（）フリップする必要があり
  、トラブルの拡大を、しかし、拡大は可能性が高い原因の無駄にされた後、
• 網状ByteBufは
  、オペレータ便利異なるインデックスを使用して読み取り
  、便利な自動拡張を

作成方法とコモンモードByteBuf

ByteBuf：バイトデータByteBufコンテナの配信方法を作成します。

1. ByteBufAllocator
   、パフォーマンスを向上させるメモリの断片化を最小限に抑えるためにプールされた（PooledByteBufAllocator）を使用した後ネッティー4.xのデフォルトでは、
   プールされていない：UnPooledByteBufAllocator毎回復帰の新しいインスタンスを
2. Unpooled：非プールByteBufを作成するための静的メソッドを提供し、あなたはヒープメモリとダイレクトメモリバッファを作成することができます

使用パターンByteBuf：

1. バッファスタック
   利点：ヒープJVMでヒープバッファメモリ空間、高速割当ておよび解放
   短所：各バッファは、（外側のヒープメモリ）の使用に直接コピーされる前に
2. ダイレクトバッファ
   ダイレクトバッファ
   利点：ヒープメモリの外のに保存されているJVMのヒープメモリ、で占められていない
   短所：メモリの割り当てと解放、そしてより多くのスタックバッファよりも複雑
3. 複合バッファを
   一緒に入れ、その後、いくつかの異なるByteBufを作成したが、唯一つのビュー

選択：書き込みIOデータ、直接キャッシュ、コーデックスタックバッファとサービスメッセージの数が多いです

ネッティーデザインパターン

Builderの設定モード：責任のデザインパターンのServerBootstrapチェーン：パイプライン事故スプレッドファクトリパターン：チャネルアダプタモードを作成します。HandlerAdapter

ネッティー単一百万戦闘

1. ネットワークIOモデル
2. Linuxのファイル記述子
   単一プロセスファイル記述子（ハンドル）、各プロセスは、最大ファイル記述子の制限有する
   グローバルファイルハンドルは、また、デフォルト値を有し、システムの異なるバージョンは異なるであろう
3. 独自のTCPコネクションを決定する方法
   IP、送信元ポート、宛先IP、宛先ポートのソース：4タプルTCPを
   サーバーのポート範囲（65535から1024）
   
   65545
   最適化：
4. 須藤VIM /etc/security/limits.confを再起動するように修飾されたローカルFDの数を変更は、ulimitは、各プロセスFDの現在の最大数を表示するようにユーザに-n

root soft nofile 1000000
root hard nofile 1000000
* soft nofile 1000000
* hard nofile 1000000复制代码

1. sudoのvimの/etc/sysctl.confの変更グローバルナンバーFD

fs.file-max=1000000复制代码

sysctlを-pパラメータ効果の再起動の猫を/ proc / sys / fs /ファイル-maxのビューグローバル番号のFDを取ります

1. 再起動しを有効にするには再起動します

-Xms5g -Xmx5g -XX：NewSizeパラメータ= 3グラム-XX：MaxNewSize = 3グラム

データリンク

「ブラウザカーネルスケジューラ - - 」ローカルDNS解決 - 「リモートDNS解決 - 」IP-は「多層ルーティングジャンプ - 」目的のサーバーに同じリソースが同時負荷の数次のドメイン名を制限している、我々は別のドメインの異なるリソースをお勧めしますブラウザは、ドメイン名を入力します。 - 「サーバーコア - 」アプリケーション

ブログ記事複数のプラットフォームからこの記事OpenWriteリリース！