1. Posix APIとは
POSIX API (ポータブル オペレーティング システム インターフェイス API) は、異なる UNIX 系オペレーティング システム間の互換性を高めるためのポータブル オペレーティング システム インターフェイスのセットです。API は、一連の標準関数と定数に加え、ファイル システム階層、プロセス制御、信号処理、スレッド管理、メモリ管理などを含むその他の多くの仕様を定義します。POSIX API を使用すると、開発者は移植性の高いアプリケーションを作成できます。
2. ネットワークプロトコルスタック
1. TCPヘッダー
| 分野 | 長さ (バイト) | 桁数 | 説明 |
|---|---|---|---|
| 送信元ポート | 2 | 16 | 送信者のアプリケーションポート番号を識別します |
| ターゲットポート | 2 | 16 | 受信者のアプリケーションポート番号を識別します |
| シリアルナンバー | 4 | 32 | データ伝送の信頼性を確保し、データセグメントのシーケンスを識別するために使用されます。 |
| 予約番号 | 4 | 32 | 受信したデータセグメントに応答し、受信が予想される次のシーケンス番号を確認するために使用されます。 |
| 頭の長さ | 4 | 4 | TCPヘッダーの長さと含まれるオプションの長さを指定します |
| 予約ビット | 6 | 6 | 予約ビットは0でなければなりません |
| 制御ビット | 6 | 6 | URG、ACK、PSH、RST、SYN、FIN などの TCP 制御ビット |
| ウィンドウサイズ | 2 | 16 | 輻輳を引き起こさずにピアが送信できるデータ量を定義する |
| チェックサム | 2 | 16 | TCPヘッダーとデータのチェックサムを計算します。 |
| 緊急ポインタ | 2 | 16 | 緊急データの場所を示すために使用されます |
| オプション | 変数 | 変数 | 最大セグメント サイズ、タイムスタンプなどの高度な機能を提供します。 |
0 15 16 31
+---------------------------+------------------------+
| 源端口 | 目的端口 |
+---------------------------+------------------------+
| 序列号 |
+----------------------------------------------------+
| 确认号（如果A标志设置则存在） |
+---------------------------+------------------------+
| 数据偏移/长度 | 保留 | 控制位 |
+---------------------------+------------------------+
| 窗口大小 |
+---------------------------+------------------------+
| 校验和（如果需要则存在） |
+---------------------------+------------------------+
| 紧急指针（如果URG标志设置则存在） |
+---------------------------+------------------------+
| 选项（可选） |
+---------------------------+------------------------+
2. UDPパケット
| 分野 | 桁数 | 説明 |
|---|---|---|
| 送信元ポート番号 | 16 | 送信ポート番号 |
| ターゲットポート番号 | 16 | 受信ポート番号 |
| 長さ | 16 | UDP データグラムの長さ (バイト単位) (UDP ヘッダーとデータ部分を含む) |
| チェックサム | 16 | UDP データグラム チェックサム。送信者によって計算され、受信者によって検証されます。 |
+------+------+-------+-------+------------------------------+
| UDP头部 | 数据部分 |
+-----------+------------+-------+----------+----------------+
| 源端口号 | 目标端口号 | 长度 | 检验和 | 数据部分 |
+-----------+------------+-------+----------+----------------+
|<----------------------------UDP报文------------------------>|
3. IPプロトコル
| フィールド名 | 長さ（単位：ビット） | 説明 |
|---|---|---|
| バージョン | 4 | IPプロトコルのバージョン番号 |
| 頭の長さ | 4 | IP ヘッダーの長さ (32 ビット ワード単位) |
| 差別化されたサービス | 8 | IP データグラムの処理方法を分類してマークする |
| 全長 | 16 | ヘッダーとデータを含む IP データグラムの全長 |
| ロゴ | 16 | 識別子は、断片化と再構成のためにデータグラムを一意にマークします。 |
| 記号 | 3 | 断片化なし、断片化、または最後の断片化などの断片化を制御するために使用されます。 |
| シャードオフセット | 13 | 元のデータグラムに対するフラグメントの開始位置を決定するために使用されます。 |
| 生存時間 | 8 | IP データグラムがネットワーク内で通過できるネットワーク セグメントの最大数 |
| プロトコル | 8 | データグラム内の上位層プロトコル (TCP、UDP など) を識別します。 |
| ヘッダーチェックサム | 16 | IPヘッダーの健全性チェックのためのチェックサム |
| 送信元アドレス | 32 | 送信者のIPアドレス |
| ターゲットアドレス | 32 | 受信者のIPアドレス |
| オプション | 変数 | 追加情報を提供するためのオプションのフィールド |
| データ | 変数 | 実際の送信データ |
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| IHL |Type of Service| Total Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification |Flags| Fragment Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time to Live | Protocol | Header Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3. プロトコルスタックに関するよくある質問
1. TCP スリーウェイ ハンドシェイク プロセス
TCP 3 ウェイ ハンドシェイクとは、TCP 接続を確立するときにクライアントとサーバーの間で送信される 3 つの異なるデータ パケットのシーケンスを指します。
初回: クライアントはサーバーへの接続を要求するデータ パケット (SYN) を送信します。
2 回目: サーバーはクライアントのリクエストを受信した後、リクエストの受信を確認するデータ パケット (ACK) と自身のリクエスト接続のデータ パケット (SYN) で応答します。
3 回目: サーバーからの応答を受信した後、クライアントはサーバー要求の接続の受信を確認するデータ パケット (ACK) で応答し、この時点で接続が正常に確立されます。
2. TCP 4 ウェーブ プロセス
初回: 終了側が FIN メッセージを送信し、接続の終了を要求します。
2 回目: FIN メッセージを受信した後、相手はクローズ要求の受信を確認する ACK メッセージで応答し、CLOSE_WAIT 状態に入り、接続を閉じる準備ができていることを示します。
3 回目: 相手が FIN メッセージを送信し、接続を閉じる準備ができていることを示します。
4 回目: FIN メッセージを受信した後、クロージング側は ACK メッセージで応答してクロージング要求の受信を確認し、TIME_WAIT 状態に入り、遅延メッセージの可能性を待ちます。ACK メッセージを受信した後、相手は接続を閉じることができます。
データ送信の信頼性を確保するために、プロセス全体を通じて、各メッセージは次のステップに進む前に相手側の確認を待つ必要があることに注意してください。同時に、最後の手を振った後、相手がすべてのデータを受信したことを確認し、不必要な再送信を避けるために、一定時間 (通常はセグメントの最大有効期間の 2 倍) 待つ必要があります。
3. 接続を確立するには 3 ウェイ ハンドシェイクが必要ですが、切断するには 4 ウェイ ハンドシェイクが必要なのはなぜですか
TCP プロトコルでは、双方が自分が送信したデータを相手が受信できることを確認する必要があり、接続を確立するときに確認が必要なため、接続を確立するには 3 ウェイ ハンドシェイクが必要です。
TCP は全二重通信であるため、切断には 4 方向ハンドシェイクが必要であり、一方が接続を切断したい場合は、送信するデータがないことを相手に伝え、相手の確認を待ってから待機する必要があります。相手が接続を閉じるようにします。
4. TIME_WAIT 状態の期間と理由
TIME_WAIT 状態は通常、MSL (最大セグメント存続期間)、つまり TCP プロトコルでデータ パケットが最長で存続できる期間の 2 倍持続します。Linux システムでは、デフォルト値は 60 秒であるため、TIME_WAIT 状態は通常 120 秒続きます。
TIME_WAIT 状態の理由は、ネットワーク上のすべてのパケットが受信側で正常に受信および処理されていることを確認し、以前に送信された ACK の損失によって後続の接続要求が到着しないなどの問題を防ぐためです。
その主な目的は次のとおりです。
- ピアが切断要求を受信したことを確認する
- アクティブクローズ中に同じポート番号が再利用されないようにする
- ネットワークの遅延やパケットの順序が狂うことによるデータ損失やエラーを処理する
TIME_WAIT 状態が存在すると、メモリや CPU リソースなどの特定のリソースが占有されますが、この場合の消費量は比較的小さいです。TIME_WAIT 状態が長時間続くと、システムのパフォーマンスに影響を与える可能性があります。
5. タイムアウト再送と高速再送
タイムアウト再送信と高速再送信はどちらも、TCP プロトコルの再送信メカニズムです。
タイムアウト再送信とは、送信者がデータを送信した後、一定時間 (タイムアウト期間と呼ばれます) 待機し、確認応答を受信しない場合にデータを再送信することを意味します。この再送メカニズムは不安定なネットワーク状況に適していますが、タイムアウトを長く設定しすぎると、ネットワークの伝送速度が遅くなります。
高速再送信とは、受信側が不連続なデータグラムを受信したときに、2 番目のデータ パケット以前のすべてのデータ パケットが受信されたことを示すために繰り返し ACK を送信することを意味します。送信者が 3 回繰り返される ACK を受信すると、タイムアウトを待たずに、未確認のデータ パケットをただちに再送信します。この再送メカニズムにより、タイムアウト設定が長すぎることによって引き起こされるネットワーク伝送速度の低下の問題を回避し、データ伝送速度を高速化できます。
6. TCP ヘッダーのフィールドとは何ですか
- 送信元ポート番号 (16 ビット): 送信側アプリケーションのポート番号を識別します。
- 宛先ポート番号 (16 ビット): 受信側アプリケーションのポート番号を識別します。
- シリアル番号 (32 ビット): データ ストリーム全体における TCP セグメントの最初のデータ バイトの位置、つまり TCP シリアル番号を決定します。
- 確認番号（32ビット）：相手の次のセグメントの最初のデータバイトの通し番号、つまりTCP確認番号を受け取ることを期待します。
- データオフセット（4ビット）：TCPヘッダーの長さを4バイト単位で示します。最小値は 5 (オプションのフィールドを除く)、最大値は 15 (すべてのオプションのフィールドを含む) です。
- 予約済み (6 ビット): 予約済みビット、使用されません。
- 制御ビット (6 ビット): TCP 接続の確立、維持、解放を制御するために使用されます。URG、ACK、PSH、RST、SYN、FIN の 6 つの制御ビットを含みます。
- ウィンドウ サイズ (16 ビット): 受信側が受信できるデータのバイト数、つまり TCP ウィンドウ サイズを示します。
- チェックサム (16 ビット): TCP ヘッダーとデータの送信エラーを検出するために使用されます。
- 緊急ポインタ (16 ビット): 緊急データの場所を提供します。URG フラグが設定されている場合にのみ有効です。
- オプション (可変長): 最大パケット長、タイムスタンプなどの追加の TCP ヘッダー情報を提供します。オプションフィールドの長さは可変で、0 バイトまたはそれ以上のバイトにすることができます。
7. TCP がリッスンしているときのパラメータ バックログの重要性
リッスン時の TCP のパラメータ バックログは、システム内の未処理の接続キューの最大長を示します。具体的には、TCP サーバーが listen 関数を呼び出すと、次の 2 つのキューが維持されます。
- 完了した接続キュー
- 未解決の接続キュー
完了接続キューには、確立され、サーバーによる受け入れを待機しているクライアント接続が含まれます。一方、不完全接続キューには、SYN セグメントを受信したが、まだ 3 ウェイ ハンドシェイクが完了していないクライアント接続が含まれます。
backlog パラメータは、未処理の接続のキューの最大長を制御します。未処理の接続のキューがいっぱいの場合、サーバーはキューに空きができるまで新しい接続要求を受け入れません。したがって、バックログの値は、サーバーの予想される負荷に応じて設定する必要があります。バックログの設定が小さすぎると、接続リクエストが拒否される可能性があり、設定が大きすぎると、メモリ リソースが過剰に消費される可能性があります。
backlog パラメータの重要性は、未処理の接続キューのサイズを制御して、サーバーができるだけ多くの接続要求を処理できるようにし、サービス拒否やメモリ リソースの枯渇などの問題を回避することです。
8. スリーウェイ ハンドシェイクのどのステップで承認が発生しますか?
「Accept」という単語は通常、TCP 接続が確立された後に使用され、スリーウェイ ハンドシェイクのどのステップでも使用されません。
9. 3 ウェイ ハンドシェイク プロセスにおける不安点は何ですか
- SYN フラッド攻撃: 攻撃者は大量の SYN リクエストを送信し、サーバーが通常のリクエストを処理できなくなる可能性があります。
- IP スプーフィング: 攻撃者は送信元 IP アドレスを偽造して SYN リクエストを送信し、サーバーを欺くことができます。
- リプレイ攻撃: 攻撃者は、古い 3 ウェイ ハンドシェイク プロセスを傍受して改ざんし、サーバーのセキュリティ対策をバイパスすることによって攻撃する可能性があります。
- 中間者攻撃: 攻撃者は、情報を不正に取得したり、通信を妨害したりする目的を達成するために、通信プロセス中にデータを傍受して改ざんすることができます。
10. TCPとUDPの違い
- 接続方式: TCP はコネクション型プロトコルです。送信前に、接続を確立するために 3 回のハンドシェイクが必要です。送信完了後、接続を閉じるために 4 回のハンドシェイクが必要です。UDP はコネクションレス型プロトコルであり、各データ パケットが送信されます。接続を確立せずに独立して。
- 送信の信頼性: TCP はデータ送信の信頼性を保証し、シーケンス番号や確認応答などのメカニズムを通じてデータが宛先に正確に送信されることを保証しますが、UDP はデータ送信の信頼性を保証せず、データ パケットが失われたり、失われる可能性があります。繰り返される送信。
- データ伝送効率: UDP は、接続の確立とデータ検証のための追加のオーバーヘッドがなく、ブロードキャストおよびマルチキャストを通じて効率的なデータ伝送を実現できるため、データ伝送効率の点で TCP よりも優れています。
- フロー制御: TCP はネットワーク状況に応じて輻輳を制御できるフロー制御をサポートし、データ送信をより安定させますが、UDP にはフロー制御メカニズムがないため、ネットワークの輻輳が発生しやすくなります。
- アプリケーション シナリオ: TCP は、ファイル転送、電子メール送信など、高い伝送信頼性を必要とするアプリケーション シナリオに適しています。一方、UDP は、音声やビデオなど、高い伝送速度と低いデータ伝送信頼性要件を必要とするアプリケーション シナリオに適しています。通信、ゲームなど
ゼロサウンドアカデミーの無料公開講座がおすすめ 個人的に先生の教え方が良かったと思うのでシェアしたいと思います。