記事ディレクトリ

Linux 運用保守エンジニアの面接での質問 (2)

Linux 運用保守エンジニアの面接での質問 (2)

希望の仕事が見つかるよう、皆さんの幸運を祈っています。
継続的な学習がなくなることはありません。
地球は爆発しないし、私たちは休暇も取らない。
チャンスは常に準備ができている人に与えられます。
さあ、労働者を殴ってください！

1 Webサイトにアクセスするまでの流れ

ブラウザを開いて URL を入力します。まずローカルキャッシュを探し、存在する場合はページを開き、存在しない場合はドメイン名解決に DNS を使用します。
ブラウザは DNS リクエストを発行して、Web サイトの IP アドレスを再帰的に検索します。HOSTS テーブル --> ローカル DNS --> 上位層 DNS (ルート DNS を含む)。
DNS 分析後、URL は IP アドレスに変換され、指定された Web サーバーが IP アドレスを通じて検出され、サーバーとの TCP スリーウェイハンドシェイクが確立されます。
ハンドシェイクが成功すると、ブラウザは HTTP リクエストを送信します。デフォルトのリクエストは、index.html です。
リクエストを受信した後、サーバーは Web ページファイルをブラウザに送り返します。
ブラウザは、サーバーから返された Web ページファイルを受信した後、HTML ファイルを解析し、レンダリングされた Web ページファイルをユーザーに表示します。
ブラウザーは、返されたデータとステータスコードをキャッシュに保存し、後で簡単にアクセスできるようにします。

2 TCP 3 ウェイハンドシェイク、4 回振る

3回の握手

ここに画像の説明を挿入

クライアントは、ランダムに生成されたシーケンス番号 (x) を含む要求メッセージをサーバーに送信し、メッセージ内の SYN フィールドを 1 に設定して、TCP 接続要求を確立する必要があることを示します。
リクエストを受信した後、サーバーは、ランダムに生成された seq(y) シーケンス番号を含むリクエストメッセージで応答し、応答メッセージの SYN フィールドを 1 に設定します。これは、接続リクエストを確立する必要があることを示し、双方向です。確認が必要です。さらに、ACK 検証フィールドが生成され、ACK 確認メッセージフィールドが 1 に設定されます。ACK 検証フィールドの値は、クライアントによって送信された seq(x) シリアル番号に基づいて、応答の 1 を加えます。つまり、確認番号フィールドに対して ack(x+1) を応答します。これにより、クライアントが情報を受信すると、TCP 確立要求が確認されたことがわかり、ack は期待されるシーケンス番号の値としても理解できます。次回クライアントによって送信されます。
クライアントは、サーバから送信されたTCPコネクション確立要求を受信後、元のシリアル番号(x)に1を加算してシリアル番号seq(x+1)を再度送信し、同時にACK検証要求を返信し、マーキングを行います。 ACK フィールドを 1 にします。サーバーによって送信されたシーケンス (y) に 1 を追加します。つまり、ACK 確認制御フィールド (y+1) に応答します。これにより、サーバーが情報を受信すると、TCP が確立されたことがわかります。リクエストが確認され、同じ ack が次回サーバーから送信されると予想される seq シリアル番号の値としても理解できます。

3 ウェイハンドシェイクの目的は、両端のシリアル番号が確実に同期され、双方がデータを送受信できるようにすることです。最初のハンドシェイクが失敗した場合、クライアントは SYN パケットを繰り返し送信します。2 回目のハンドシェイクが失敗した場合、サーバーは SYN+ACK パケットも繰り返し送信します。3 回目のハンドシェイクが失敗した場合、クライアントは ACK パケットを再送信します。

四回手を振った

ここに画像の説明を挿入

クライアントは積極的に接続終了要求をサーバーに送信します。このとき、シーケンス番号 seq は u で、メッセージの FIN フィールドは 1 とマークされ、TCP 接続が終了することを示します。
メッセージを受信したサーバーは、検証のための ACK メッセージを送信し、ACK を 1 に設定し、同時に ack (u+1) 確認フィールドを送信します。このとき、シーケンス番号 seq は v であり、これはメッセージは終了要求が受信されたことを示します。
この時点では、サーバーにはまだ送信するデータがある可能性があるため、しばらく待つ必要があります。サーバーがデータの送信を完了すると、TCP 接続が終了したことを示す FIN パケットを送信し、FIN を 1、ACK を 1 としてマークします。このとき、シーケンス番号 seq は w、確認番号 ack は u になります。 +1;
FIN パケットを受信した後、クライアントは ACK パケットで応答し、終了要求が受信されたことを示し、ACK を 1、シーケンス番号 seq を u+1、ack を w+1 に設定し、TIME_WAIT を入力します。州。しばらく待った後、クライアントは接続を閉じます。サーバーは ACK パケットを受信した後、接続も閉じます。

4 つのウェーブの目的は、相手側が接続を終了し、それ以上データが送信されないことを両端に知らせることです。クライアントが FIN パケットの送信後に ACK パケットを受信しない場合、クライアントは FIN パケットを再送信できます。サーバーが FIN パケットの送信後に ACK パケットを受信しない場合、FIN パケットを再送信できます。クライアントは、TIME_WAIT 状態が終了する前に重複した FIN パケットを受信した場合、それを無視できます。

3 Apache と nginx にはどのような種類の仮想ホストがありますか

IPベースの仮想ホスティング
ドメインベースのウェブホスティング
ポート番号ベースの仮想ホスティング

4 TCPとUDPの違い

TCP はコネクション型プロトコルですが、UDP はコネクションレス型プロトコルです。TCP は 1 対 1 の送信であり、UDP は 1 対 1、1 対多、多対 1、および多対多の対話型通信をサポートします。
TCP は信頼性の高いデータ送信を提供し、データが完全かつ順序どおりに宛先に到達できることを保証しますが、UDP は信頼性を保証せず、データ送信が失われたり、繰り返されたり、順序が乱れたりする可能性があります。
TCP はデータをいくつかのデータセグメントに分割し、各データセグメントにはシーケンス番号が付いており、これによりデータの順序と整合性が保証されます。UDP はデータをデータグラムにカプセル化します。各データグラムは独立しており、失われたり、重複したり、順序が崩れたりする可能性があります。
TCP はバイト指向です。つまり、アプリケーション層からのメッセージをバイトストリームと見なし、バイトストリームをさまざまなサイズのデータブロックに分割し、TCP ヘッダーを追加します。UDP はメッセージ指向であり、パケットはメッセージ指向です
。アプリケーション層は分割またはマージされず、UDP ヘッダーのみが追加されます。
UDP は、TCP の信頼性保証や複雑なフロー制御、輻輳制御メカニズムを備えていないため、TCP よりも高速です。
UDP は、ビデオ、オーディオ、ゲームなど、伝送量は少ないが高い伝送速度が要求されるアプリケーションに適しており、TCP は、ファイル伝送、メールなど、伝送量は大きいが、高い信頼性と完全性が要求されるアプリケーションに適しています。
TCP は、パケットの送信順序の保証、再送信メカニズム、フロー制御、輻輳制御など、送信の信頼性に関するさまざまな手段をサポートしていますが、UDP は最も基本的なデータ送信機能のみを提供します。

5 nginxとapacheの違い

Nginx：

軽量で、C で書かれた同じ Web サービスは、メモリとリソースの使用量が少なくなります。
非同時実行性、nginx は開発モデルとして epoll と kqueue を使用し、リクエストの処理は非同期かつノンブロッキングであり、その負荷容量は Apache よりもはるかに高くなりますが、Apache はブロッキングします。高い同時実行性では、nginx は低いリソース消費と高いパフォーマンスを維持できますが、Apache は、PHP 処理が遅い場合やフロントエンドの負荷が高い場合にプロセス数が急増し、サービス拒否が発生する傾向があります。
nginx は静的ファイルを適切に処理し、その静的処理パフォーマンスは Apache の 3 倍以上です。
nginx の設計は高度にモジュール化されており、モジュールの作成は比較的簡単です。
nginx の設定はシンプルで、通常の設定を使用すると多くの作業が簡単になります。設定を変更した後、-t を使用して設定に問題があるかどうかをテストできます。Apache の設定は複雑です。再起動すると、設定が間違っているとクラッシュします。
負荷分散サーバーとして、nginx はレイヤー 4 とレイヤー 7 の負荷分散をサポートしており、レイヤー 7 の負荷は DDOS 攻撃を効果的に防止できます。
Nginx 自体はリバースプロキシサーバーであり、メールプロキシサーバーとしても使用できます。

アパッチ：

Apache の書き換えは nginx よりも強力です。頻繁に書き換えを行う場合は、Apache を使用してください。
Apache は現在まで開発されており、非常に多くのモジュールがあるため、基本的に思いついたものはすべて見つかります。
Apache はより成熟しており、バグが少ないのに対し、nginx には比較的多くのバグがあります。
Apache の PHP サポートは比較的単純で、nginx は他のバックエンドとともに使用する必要があります。
Apache は動的リクエストの処理に優れていますが、nginx はこの点では役に立ちません。一般に、動的リクエストは Apache で処理する必要があり、nginx は静的リクエストとリバースリクエストに適しています。
Apache は依然として現在の主流であり、豊富な機能、成熟したテクノロジー、開発コミュニティを備えています。

2 つの主な違いは、Apache は同期マルチプロセスモデルであり、1 つの接続が 1 つのプロセスに対応するのに対し、nginx は非同期であり、複数の接続 (1 万レベル) が 1 つのプロセスに対応できることです。

安定性のためには Apache が必要であり、高パフォーマンスのためには nginx が必要です

6 リバースプロキシ、フォワードプロキシとは何ですか?その違いは何ですか?

リバースプロキシとフォワードプロキシはどちらもプロキシサーバーの応用形態ですが、主な違いはプロキシの方向とプロキシオブジェクトが異なることです。

フォワードプロキシとは、クライアントと対象サーバーの間にプロキシサーバーを設置し、クライアントの代わりに対象サーバーにリクエストを送信することであり、クライアントは対象サーバーに直接アクセスすることはできません。フォワードプロキシサーバーは通常、暗号化、キャッシュ、アクセス制御、コンテンツフィルタリングなどの機能に使用されます。たとえば、回避ツールは一般的なフォワードプロキシアプリケーションです。

リバースプロキシは、ターゲットサーバーとクライアントの間にプロキシサーバーを設定し、ターゲットサーバーに代わってクライアントにサービスを提供します。クライアントはターゲットサーバーに直接アクセスできず、すべてのリクエストはリバースプロキシサーバーを経由する必要があります。リバースプロキシサーバーは、負荷分散と高可用性を実現するために、クライアントの要求に応じて異なるターゲットサーバーを選択できます。たとえば、一部の大規模な Web サイトやアプリケーションでは、負荷分散とキャッシュにリバースプロキシサーバーを使用しています。

2 つの主な違いは、エージェントの方向にあります。フォワードプロキシは、クライアントの要求をターゲットサーバーに転送するプロキシクライアントであり、リバースプロキシは、ターゲットサーバーの応答をクライアントに転送するプロキシサーバーです。

7 Cookieとセッションの違い

保存場所: Cookie はクライアントのブラウザに保存され、セッションはサーバー側に保存されます。
セキュリティ: Cookie はクライアントのブラウザに保存されるため、盗まれたり改ざんされたりする可能性があり、一定のセキュリティリスクがありますが、セッションはサーバー側に保存されるため、比較的安全です。
ストレージ容量: Cookie のストレージ容量には制限があり、通常は約 4KB のデータしか保存できませんが、セッションのストレージ容量には制限がなく、より多くのデータを保存できます。
スコープ: Cookie のスコープはドメイン名全体の下のすべてのページであり、データは複数のページ間で共有できますが、セッションのスコープは現在のユーザーとサーバー間のセッションであり、データは同じセッション内でのみ共有できます。。
有効期限: Cookie には有効期限を設定でき、クライアントのブラウザに長期間保存できます。セッションは通常、ユーザーがブラウザを閉じるか、一定期間操作しないと自動的に期限切れになります。

要約すると、Cookie はユーザー設定、ショッピングカート情報などの一部の機密データの保存に適しており、Session はユーザーのログインステータス、権限情報などの一部の機密データの保存に適しています。実際の開発では、通常、特定のアプリケーションのシナリオと要件に応じて適切なメカニズムが選択されます。

8 nginx のチューニング

作業プロセスのバインド、アップロードファイルの最大サイズ、イベントドリブンモデルの最適化、ファイル記述子の最適化、リーチ対策の最適化、ソフトウェア名とバージョン番号の非表示、ユーザーフレンドリーで禁止するための 404 や 502 などのデフォルトページの最適化悪意のあるドメイン名分析、IP アドレスによる Web サイトへのアクセスの禁止、Web サイトディレクトリのアクセス許可の厳密な設定、ロボットプロトコルと HTTP_USER_AGENT による爬虫類対策の最適化。DDOS 単一 IP 同時接続制御を防止します。ステータス監視モジュールをオンにする必要があります。limit_rate はアップロード速度を制限します。client_max_body_size では、ユーザーがアップロードするファイルの最大サイズを許可します。

チャットポイント：

作業プロセスの数を調整する: Nginx によってデフォルトで有効になる作業プロセスの数は CPU コアの数であり、サーバーのパフォーマンスとアプリケーションの負荷に応じて適切に調整できます。一般に、ワーカープロセスの数は、CPU コアの数の 2 倍または 3 倍に設定できます。
ファイルハンドル制限を調整する: Nginx のデフォルトのファイルハンドル制限は 1024 ですが、実際の状況に応じて適切に調整できます。ファイルハンドル制限は、システムパラメーターを変更するか、Nginx 構成ファイルで「worker_rlimit_nofile」パラメーターを設定することによって調整できます。
TCP 最適化パラメータを有効にする: Nginx は、「tcp_nopush」、「tcp_nolay」、「keepalive_timeout」などのパラメータを設定することで、TCP 接続のパフォーマンスと信頼性を向上できるいくつかの TCP 最適化パラメータを提供します。
Gzip 圧縮を有効にする: Gzip 圧縮を有効にすると、ネットワーク上で送信されるデータ量が削減され、ページの読み込み速度が向上します。Gzip 圧縮は、Nginx 構成ファイルで「gzip」パラメータを設定することで有効にできます。
HTTP キャッシュを有効にする: HTTP キャッシュを有効にすると、サーバーの負荷とページの読み込み時間が短縮されます。Nginx 構成ファイルで「proxy_cache_path」パラメータを設定して、HTTP キャッシュを有効にすることができます。
Nginx のメモリ使用量の調整: Nginx のデフォルトのメモリ使用量は低く、「worker_processes」や「worker_connections」などのパラメータを設定することで Nginx のメモリ使用量を調整し、パフォーマンスと信頼性を向上させることができます。

9 システム内の多数の time_wait 問題を解決する方法

事故によりサーバーがDDOS攻撃を受け、当社も大きな影響を受け、フロントエンドのユーザーアクセスポータルを閉鎖し、DDOS攻撃を一時停止しましたが、サーバー上での待ち時間が多大でしたその結果、新しい接続が失敗し、多くのシステムリソースが消費されるため、一時的な解決策は次のとおりです。
システム設定sysctl.confに2 つのパラメータを追加します

net.ipv4.tcp_tw_recycle = 1
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_fin_timeout = 300
net.ipv4.tcp_syncookies = 1

これを 1 に変更してsysctl -pコマンドすぐに有効になりますが、その後は遅くなります。

チャットポイント：

time_wait は TCP プロトコルの状態で、TCP 接続は閉じられていますが、遅延したデータパケットの到着を待つのにまだ時間がかかることを示します。システム内に time_wait 状態の接続が多数ある場合、システムリソースの無駄が発生し、パフォーマンスが低下する可能性があります。以下にいくつかの解決策を示します。

TCP パラメータの調整: tcp_tw_recycle、tcp_tw_reuse およびその他のパラメータを変更するなど、TCP パラメータを調整することで、time_wait の数と時間を制御できます。ただし、潜在的なリスクがあるため、運用環境でこれらのパラメータを調整することはお勧めできません。
サーバーリソースの増加: time_wait 状態の接続の数はシステムリソースに関連しています。サーバーリソースを増やすと、メモリ、CPU、ネットワーク帯域幅の増加など、システム内の time_wait 状態の接続の数が減少する可能性があります。
接続プールを使用する: 接続プールを使用すると、確立された TCP 接続を再利用できるため、接続の頻繁な確立と終了を回避できます。接続プーリングにより、time_wait 状態の接続の数が減り、システムのパフォーマンスが向上します。
TCP 高速リカバリテクノロジを使用する: TCP 高速リカバリテクノロジは、システムが time_wait 状態の接続を迅速にリカバリできるようにするタイムスタンプベースのテクノロジです。TCP 高速リサイクル技術は、net.ipv4.tcp_timestamps=1 を設定することで有効にできます。

つまり、time_wait 問題を解決する際には、システムのパフォーマンスと信頼性を向上させるために、特定のアプリケーションシナリオとシステムリソースの条件に応じて包括的に検討および調整する必要があります。同時に、潜在的なリスクを引き起こす可能性がある誤った調整パラメータと構成を避けるために注意を払う必要があります。

10 新しいサーバーを取得した後に行うべきこととシステムの最適化について

SSH のポートを変更し、パブリックネットワーク上のマシンでのパスワードログインを無効にし、キーログインの方法を選択します。

root ログインを禁止し、一般ユーザーを使用してシステムにログインしてみて、sudo 権限を追加します。

時刻同期を構成し、ネットワークカード名を eth0 の従来の命名方法に設定します。

ファイアウォールをオンにして、ファイアウォールルールを構成します。

カーネルパラメータの最適化、TCPパラメータの最適化などのリソース制限の変更、ファイル記述子の増加。

ローカルの yum ソースまたは国内ソースを構成し、tcpdump やその他のツールキットなどの一般的なソフトウェアパッケージをインストールします。

チャットポイント：

システムとソフトウェアパッケージを更新する: まず、オペレーティングシステムとソフトウェアパッケージを最新バージョンに更新して、最新のセキュリティパッチと機能を入手する必要があります。
ファイアウォールとセキュリティポリシーを構成する: ファイアウォールとセキュリティポリシーを構成すると、ネットワーク攻撃やマルウェアからサーバーを保護できます。
リモートアクセスの構成: リモートアクセスを構成すると、管理者はサーバーをリモートで管理しやすくなりますが、SSH 暗号化接続を使用するなど、セキュリティに注意する必要があります。
必要なソフトウェアをインストールする: エディター、ログ分析ツール、監視ツールなど、必要なソフトウェアをインストールすると、サーバーの管理とメンテナンスが容易になります。
システムリソース制限を構成する: 特定のプロセスがシステムリソースを占有しすぎて、システムクラッシュやパフォーマンスの低下が引き起こされるのを防ぐために、システムリソース制限を構成します。
システムパラメータを構成する: システムパラメータを構成すると、ファイルハンドルの数、メモリサイズ、ネットワークバッファなどの調整など、システムのパフォーマンスと信頼性が向上します。
システムログの構成: システムログを構成すると、管理者がシステムの動作ステータスとエラーメッセージを確認し、問題を適時に発見して解決することが容易になります。
システムバックアップを構成する: システムに問題が発生した場合にデータとサービスを復元するようにシステムバックアップを構成し、データ損失やサービスの中断を回避します。

上記は新しいサーバーに対する基本的な最適化の提案ですが、具体的な最適化の方法と手順は、特定のアプリケーションシナリオとシステム構成に応じて包括的に検討し、調整する必要があります。

上記の面接の質問は個人的な要約です。順序に関係なく、思いついたことを自由に書いてください。文章に何か問題がある場合は、コメントしてメッセージを残してください。すぐに修正します。

元のリンク: Linux 運用保守エンジニアの面接の質問 (2)