コンピュータネットワークの知識の要約
第7層-アプリケーション層
アプリケーション層プロトコルは、アプリケーションプロセス間の相互作用と通信のルール、および転送されるメッセージのタイプ、形式、フィールドなど、さまざまなホストのアプリケーションプロセスがメッセージを相互に転送する方法を定義します。
HTTPプロトコル
HTTPはハイパーテキスト転送プロトコルです、クライアントとサーバー間でメッセージを交換する形式と方法を定義し、デフォルトでポート80が使用されます。データ転送の信頼性を確保するために、トランスポート層プロトコルとしてTCPを使用します。
HTTPはステートレスプロトコルです、HTTPサーバーはクライアントに関する情報を保存しません。
HTTPには2つの接続モードがあります。1つは継続的接続で、もう1つは非永続的接続です。。
非持続的接続とは、サーバーが要求されたオブジェクトごとに新しい接続を確立して維持する必要があることを意味します。連続接続では、TCP接続はデフォルトでは閉じられず、複数の要求によって多重化できます。
連続接続を使用する利点は、TCP接続ごとに3ウェイハンドシェイクを確立するのにかかる時間を回避できることです。HTTP1.0より前に使用されていた非持続的接続ですが、接続を追加できます。TCP接続を閉じないようにサーバーに要求するときにライブを維持します。HTTP1.1以降、デフォルトでは継続接続が使用されます。現在、同じドメインに対して、ほとんどのブラウザは同時に6つの持続的接続の確立をサポートしています。
HTTPリクエストメッセージ
HTTPメッセージには2つのタイプがあります。1つは要求メッセージで、もう1つは応答メッセージです。
HTTPリクエストメッセージの形式は次のとおりです。
GET / HTTP/1.1
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5)
Accept: */*
HTTP要求メッセージの最初の行は要求行と呼ばれ、次の行はヘッダー行と呼ばれ、エンティティ本体の後にヘッダー行を続けることができます。リクエストヘッダーの後に空白行があります。この空白行は省略できません。ヘッダーとエンティティを分割するために使用されます。
リクエスト行には、メソッドフィールド、URLフィールド、HTTPバージョンフィールドの3つのフィールドが含まれています。
メソッドフィールドは、通常GET、POST、HEAD、PUT、およびDELETEなどのいくつかの異なる値を取ることができます。通常、GETメソッドは、サーバーからデータを取得するためにのみ使用されます。
- POSTメソッドは、エンティティを指定されたリソースに送信するために使用されます。これにより、通常、サーバーリソースが変更されます。
- HEADメソッドはGETメソッドに似ていますが、返される応答にはリクエストオブジェクトが含まれていません。
- PUTメソッドは、ファイルをサーバーにアップロードするために使用されます。
- DELETEメソッドは、サーバー上のオブジェクトを削除するために使用されます。
リクエストする方法はたくさんありますが、それは意味上の違いであり、POSTがGETではできないことを実行できるという意味ではありません。主に選択方法によって異なります。
HTTP応答メッセージ
HTTPメッセージには、要求メッセージと応答メッセージの2種類があります。
HTTP応答メッセージの形式は次のとおりです。
HTTP/1.0 200 OK
Content-Type: text/plain
Content-Length: 137582
Expires: Thu, 05 Dec 1997 16:00:00 GMT
Last-Modified: Wed, 5 August 1996 15:55:28 GMT
Server: Apache 0.84
<html>
<body>Hello World</body>
</html>
HTTP応答メッセージの最初の行はステータス行と呼ばれ、次の行は最初の行であり、最後の行はエンティティ本体です。
ステータス行には、プロトコルバージョンフィールド、ステータスコード、および対応するステータス情報の3つのフィールドが含まれています。
物理的な部分はメッセージの主要部分であり、要求されたオブジェクトが含まれています。
一般的な状態は次のとおりです。
200要求が成功した
202-サーバは、要求メッセージを受信したが、それは処理されていない
301-永久ムーブ
302、一時的移動
304、要求されたリソースが変更されていない
400構文エラー
によって要求されたクライアントを404-要求されたリソースは存在しません
500-内部サーバーエラー。
通常、1XXは要求を受信したサーバーを表し、2XXは成功を表し、3XXはリダイレクトを表し、4XXはクライアント側のエラーを表し、5XXはサーバー側のエラーを表します。
HTTPSの概要
HTTPSは、ハイパーテキスト転送セキュリティプロトコルを指します。HTTPSはHTTPプロトコルに基づいていますが、TLS / SSLを使用してデータを暗号化します。
TLS / SSLプロトコルを使用すると、すべての情報が暗号化され、第三者が盗聴する方法はありません。また、検証メカニズムを提供します。情報が改ざんされると、通信の2つの当事者がすぐにそれを見つけます。また、IDが偽造されるのを防ぐためのID証明書も装備されています。
TLSハンドシェイクプロセス
- 最初のステップで、クライアントはサーバーへの要求を開始します。要求には、使用されるプロトコルバージョン番号、生成される乱数、およびクライアントでサポートされている暗号化方法が含まれます。
- 2番目のステップでは、サーバーは要求を受信した後、両方の当事者が使用する暗号化方法を確認し、サーバーの証明書とサーバーによって生成された乱数を提供します。
- 3番目のステップでは、クライアントがサーバー証明書が有効であることを確認した後、新しい乱数を生成し、デジタル証明書の公開鍵を使用して乱数を暗号化してから、サーバーに送信します
。また、サーバーが検証するために、以前のすべてのコンテンツのハッシュ値も提供します。 - 4番目のステップでは、サーバーは独自の秘密鍵を使用して、クライアントから送信された乱数を復号化します。そして、クライアントが検証できるように、以前のすべてのコンテンツのハッシュ値を提供します。
- 5番目のステップでは、クライアントとサーバーは、合意された暗号化方法に従って前の3つの乱数を使用して、会話の秘密鍵を生成します。この秘密鍵は、後続の会話中に情報を暗号化するために使用されます。
実現原理
TLSハンドシェイクプロセスは、送信のセキュリティを確保するために主に3つの方法を使用します。
-
1つ目は対称暗号化の方法です
対称暗号化の方法は、両方の当事者が同じ秘密鍵を使用してデータを暗号化および復号化することです。ただし、対称暗号化には問題があります。つまり、秘密鍵はネットワークを介して送信され、他の人が秘密鍵を取得すると、暗号化プロセス全体が送信されるため、秘密鍵送信のセキュリティを確保する方法に問題があります。役に立たない。これには、非対称暗号化を使用する必要があります。
-
非対称暗号化方式はい、2つの秘密鍵があります。1つは公開鍵で、もう1つは秘密鍵です。公開鍵は公開されており、秘密鍵は秘密にされています。
対応する公開鍵のみが秘密鍵で暗号化されたデータを復号化でき、対応する秘密鍵のみが公開鍵で暗号化されたデータを復号化できます。
公開鍵を公開することができ、通信を希望するお客様は、提供された公開鍵を使用してデータを暗号化できるため、秘密鍵を使用して復号化できるため、データのセキュリティが保証されます。
ただし、非対称暗号化の欠点は、暗号化プロセスが非常に遅いことです。したがって、各通信に非対称暗号化を使用すると、待機時間が長すぎるという問題が発生します。
暗号化
だから私たちはできる対称暗号化と非対称暗号化の組み合わせを使用する、対称暗号化の欠点は、秘密鍵の安全な送信を保証できないことです。
また、非対称暗号化を使用して対称暗号化キーを送信し、次に対称暗号化を使用して将来の通信を暗号化することもできます。これにより、2つの方法のそれぞれの問題が解決されます。
ただし、取得した公開鍵が安全な公開鍵である必要があることを確認する方法がないため、現在の方法は必ずしも安全ではありません。相手から送信された公開鍵を傍受し、自分の公開鍵を送信する仲介者がいる可能性があります。公開鍵を使用して送信情報を暗号化すると、秘密鍵で復号化できます。 。それから彼は私たちが同じようにお互いに情報を送るふりをして、私たちの情報が盗まれるのですが、私たちはまだ知りません。
データ転送セキュリティの問題を解決する方法
このような問題を解決するために、デジタル証明書を使用できます。
まず、ハッシュアルゴリズムを使用して公開鍵やその他の情報を暗号化し、情報ダイジェストを生成します。
次に、信頼できる認証センター（略してCA）に、メッセージダイジェストを秘密鍵で暗号化して署名を作成させます。
最後に、元の情報と署名が組み合わされます。これはデジタル証明書と呼ばれます。
受信者がデジタル証明書を受信すると、最初に同じハッシュアルゴリズムを使用して元の情報に基づいてダイジェストを生成し、次に公証人の公開鍵を使用してデジタル証明書のダイジェストを復号化し、最後に復号化されたダイジェストとダイジェストを使用します生成した比較することで、取得した情報が変更されているかどうかを確認できます。
この方法で最も重要なことは、認証局の信頼性です。通常、最上位の認証局の証明書はブラウザに組み込まれているため、自動的に信頼されます。この方法でのみ、データのセキュリティを保証できます。 。
DNSプロトコル
DNSプロトコルが提供するのは、ホスト名からIPアドレスへの変換サービスです。これは、ドメインネームシステムと呼ばれることがよくあります。これは、階層型DNSサーバーで構成される分散データベースであり、ホストがこの分散データベースにクエリを実行する方法を定義するアプリケーション層プロトコルです。
DNSプロトコルはUDPプロトコル上で実行され、ポート53を使用します。
ドメイン名の階層
ドメイン名の階層構造は次のとおりです。
主机名.次级域名.顶级域名.根域名
# 即
host.sld.tld.root
ドメイン名の階層構造に応じて、さまざまなレベルでドメイン名を管理するサーバーは、ルートドメインネームサーバー、トップレベルドメインネームサーバー、および権限のあるドメインネームサーバーに分けることができます。
DNSクエリプロセス
DNSクエリの一般的なプロセスは、最初にDNS要求をローカルDNSサーバーに送信し、ローカルDNSサーバーがその代わりに要求を行うことです。
- 「ルートドメインネームサーバー」から「トップドメインネームサーバー」のNSレコードとAレコード（IPアドレス）を検索します。
- 「トップレベルドメインネームサーバー」から「セカンダリドメインネームサーバー」のNSレコードとAレコード（IPアドレス）を検索します。
- 「セカンダリドメインネームサーバー」から「ホスト名」のIPアドレスを調べます。
たとえば、www.baidu.comのIPアドレスを照会する場合は、最初にローカルDNSサーバーにリクエストを送信します。ローカルDNSサーバーは、ドメイン名のキャッシュがあるかどうか、およびあるかどうかを判断します。存在しない場合は、ルートドメインネームサーバーに送信されます。1つのリクエストで、ルートドメインネームサーバーは、.comを担当するトップレベルのドメインネームサーバーのIPアドレスのリストを返します。
次に、ローカルDNSサーバーが.comを担当するトップレベルドメインネームサーバーの1つに要求を送信し、.comを担当するトップレベルドメインネームサーバーが.baiduを担当する権限のあるドメインネームサーバーのIPアドレスリストを返します。 。
次に、ローカルDNSサーバーが権限のあるドメインネームサーバーの1つに要求を送信し、最後に権限のあるドメインネームサーバーがホスト名に対応するIPアドレスのリストを返します。
DNSレコードとメッセージ
DNSサーバーは情報をリソースレコードの形式で格納し、各DNS応答メッセージには通常複数のリソースレコードが含まれます。リソースレコードの特定の形式は次のとおりです。
（Name，Value，Type，TTL）
TTLは、リソースレコードの存続時間であり、他のDNSサーバーがリソースレコードをキャッシュできる期間を定義します。
一般的に使用されるタイプ値は、A、NS、CNAME、MXの合計4つです。タイプ値が異なれば、対応するリソースレコードの意味も異なります。
- Type = Aの場合、Nameはホスト名であり、Valueはホスト名に対応するIPアドレスです。したがって、レコードはAのリソースレコードであり、標準の
ホスト名からIPアドレスへのマッピングを提供します。 - Type = NSの場合、Nameはドメイン名であり、Valueはドメイン名を担当するDNSサーバーのホスト名です。このレコードは、主にDNSチェーン
クエリに使用され、次のレベルでクエリする必要があるDNSサーバーの情報を返します。 - Type = CNAMEの場合、Nameはエイリアスであり、Valueはホストの正規のホスト名です。このレコードは、ホスト名に対応する正規のホスト名をクエリを実行するホストに返すために使用されます。これにより、クエリを実行するホストに、ホスト名のIPアドレスをクエリするように指示します。ホストエイリアスの主な目的は、いくつかの複雑なホスト名に対して覚えやすい単純なエイリアスを提供することです。
- Type = MXの場合、Nameはメールサーバーのエイリアスであり、Valueはメールサーバーの正規のホスト名です。その機能はCNAMEと同じです。どちらも、メモリに適さない標準化されたホスト名の欠点を解決するためのものです。
再帰クエリと反復クエリ
再帰クエリこれは、クエリ要求が送信された後、ドメインネームサーバーが次のレベルのドメインネームサーバーに代わって要求を送信し、最終的にクエリの最終結果をユーザーに返すことを意味します。再帰クエリを使用すると、ユーザーはクエリ要求を1回行うだけで済みます。
反復クエリこれは、クエリ要求の後、ドメインネームサーバーが単一のクエリの結果を返すことを意味します。次のレベルのクエリがユーザーによって要求されます。反復クエリでは、ユーザーは複数のクエリリクエストを発行する必要があります。
一般に、ローカルDNSサーバーにリクエストを送信する方法は再帰クエリです。これは、リクエストを1回行うだけで、ローカルDNSサーバーが最終的なリクエスト結果を返すためです。
ローカルDNSサーバーが他のドメインネームサーバーを要求するプロセスは、反復クエリプロセスです。これは、各ドメインネームサーバーが単一のクエリの結果のみを返し、次のレベルのクエリがローカルDNSサーバー自体によって実行されるためです。
DNSキャッシュ
DNSキャッシングの原理は非常に単純です。リクエストチェーンでは、DNSサーバーがDNS応答を受信すると、ローカルストレージの応答に情報をキャッシュできます。返されたリソースレコードのTTLは、レコードのキャッシュ時間を表します。
負荷分散のためのDNS
DNSを使用して、冗長サーバーで負荷分散を実現できます。現在、ほとんどの大規模Webサイトは複数のサーバーを使用してサービスを提供しているため、ドメイン名は複数のサーバーアドレスに対応している場合があります。
ユーザーがウェブサイトのドメイン名に対してDNS要求を開始すると、DNSサーバーはこのドメイン名に対応するサーバーIPアドレスのセットを返しますが、各回答でこれらのIPアドレスの順序がループされ、ユーザーは通常、リクエストを送信するために最初にランク付けされたアドレス。
このようにして、ユーザーの要求は異なるサーバーに均等に分散され、負荷分散を実現します。
第4層-トランスポート層
トランスポート層プロトコルは、主に、異なるホスト上の異なるプロセス間の論理通信機能を提供します。トランスポート層はエンドシステムでのみ機能します。
多重化と逆多重化
トランスポート層セグメントのデータを正しいソケットに配信する作業は、逆多重化と呼ばれます。
ソースホスト上のさまざまなソケットからデータを収集し、ヘッダー情報をカプセル化してメッセージセグメントを生成し、メッセージセグメントをネットワーク層に渡します。このプロセスは多重化と呼ばれます。
コネクションレス型の多重化と逆多重化は、UDPソケットの割り当てプロセスを指します。UDPソケットは、宛先アドレスと宛先ポート番号を含む2つのタプルによって識別されます。
したがって、送信元アドレスとポート番号が異なるUDPセグメントがホストに到着した後、宛先アドレスと宛先ポート番号が同じである場合、異なるセグメントは同じUDPソケットに転送されます。
コネクション型の多重化と逆多重化は、TCPソケットの割り当てプロセスを指します。TCPソケットは4つのタプルで識別されます。この4つのタプルには、送信元IPアドレス、送信元ポート番号、および宛先が含まれます。アドレスと宛先ポート番号。
したがって、TCPセグメントがネットワークからホストに到着すると、ホストは4つの値すべてを使用して、セグメントを対応するソケットに転送します。
UDPプロトコル
UDPは、コネクションレス型で信頼性の低いトランスポート層プロトコルです。トランスポート層が実装する必要のある最小限の機能のみを提供します。多重化/分解機能と少量のエラー検出を除いて、IPにほとんど何も追加しません。UDPプロトコルは、高いリアルタイムパフォーマンスを必要とするアプリケーションシナリオに適しています。
特徴：
- UDPを使用する場合、メッセージセグメントを送信する前に、2つのパーティ間にハンドシェイクプロセスがないため、UDPはコネクションレス型トランスポート層プロトコルと呼ばれます。TCPと比較して、ハンドシェイクプロセスがないため
、接続の確立に遅延はありません。接続がないため、接続の状態をエンドシステムに保存する必要はありません。 - UDPはベストエフォート型の配信サービスを提供します。つまり、UDPプロトコルはデータの信頼性の高い配信を保証しません。
- UDPには輻輳制御およびフロー制御メカニズムがないため、UDPセグメントの送信速度に制限はありません。
- UDPソケットは、宛先アドレスと宛先ポートのみを使用して識別するため、UDPは、1対1、1対多、多対1、および多対多の対話型通信をサポートできます。
- UDPヘッダーは小さく、8バイトしかありません。
UDPセグメント構造
UDPメッセージセグメントは、ヘッダーデータとアプリケーションデータで構成されます。メッセージセグメントのヘッダーには、4つのフィールドが含まれています。これらは、送信元ポート番号、宛先ポート番号、長さ、およびチェックサムです。
- 各フィールドの長さは2バイトです。長さフィールドは、ヘッダーとアプリケーションデータのサイズを含む、メッセージセグメント全体の長さを示します。
- チェックサムは、UDPが提供するエラーチェックメカニズムです。エラーチェックメカニズムが提供されていますが、UDPはエラーから回復する力がありません。
TCPプロトコル
TCPプロトコルは、信頼性の高いデータ転送サービスを提供するコネクション型のトランスポート層プロトコルです。
特徴：
- TCPプロトコルはコネクション型です。両者が通信する前に、3ウェイハンドシェイクを介して接続を確立する必要があります。エンドシステム内の2者間の接続のステータス情報を維持する必要があります。
- TCPプロトコルは、シーケンス番号、確認番号、タイミング再送信、チェックサムなどのメカニズムを通じて、信頼性の高いデータ送信サービスを提供します。
- TCPプロトコルは、ポイントツーポイントサービスを提供します。つまり、単一の送信者と単一の受信者の間の接続です。
- TCPプロトコルは全二重サービスを提供します。つまり、接続の両方の当事者が相互にデータを送受信できます。
- TCPは、ネットワークが輻輳しているときにデータを送信する速度を制御する輻輳制御メカニズムを提供します。これにより、データパケットの損失を減らし、ネットワークの輻輳の程度を減らすことができます。
- TCPは、両方の当事者の送信速度と受信速度が同じであることを保証するフロー制御メカニズムを提供します。受信者が受信できるバッファが非常に小さい場合、送信者は送信
レートを下げて、バッファがいっぱいになることによるパケット損失を回避します。
TCPセグメント構造
TCPセグメントはヘッダーとデータで構成され、そのヘッダーは通常20バイトです。
送信元ポート番号と宛先ポート番号は、メッセージセグメントの多重化と分解に使用されます。
32ビットシリアル番号と32ビット確認番号は、信頼性の高いデータ転送サービスを実現するために使用されます。
16ビットの受信ウィンドウフィールドは、フロー制御を実装するために使用されます。このフィールドは、受信者が受信しようとしているバイト数を示します。
4ビットこのフィールドは、TCPヘッダーの長さを32ビットワード単位で示します。
6ビットACKフィールドは、確認シーケンス番号の値が有効であることを示すために使用され、RST、SYN、およびFINビットは接続の確立とティアダウンに使用されます。PSHフィールドを設定すると、受信者はデータをすぐに上位層に配信する必要があり、URGフィールドは、メッセージセグメントに緊急データがあることを示すために使用されます。チェックサムは、データのエラー検出を提供します。
TCPスリーウェイハンドシェイクプロセス
最初の握手、クライアントはSYN接続要求メッセージセグメントをサーバーに送信します。メッセージセグメントのヘッダーのSYNフラグの位置は1で、シーケンス番号フィールドはオプションの乱数です。クライアントデータの初期シーケンス番号を表します。
2回目の握手サーバーは、クライアントから送信されたSYN接続要求セグメントを受信した後、最初にTCPバッファーと変数を接続に割り当て、次にSYNACKセグメントをクライアントに送信します。SYNフラグとACKフラグはセグメントのヘッダーにあります。ビットはすべて1に設定されます。これは、SYN接続要求の確認であることを意味します。同時に、シリアル番号フィールドは、サーバーによって生成されるオプションのランダム番号であり、サーバー側の初期シリアル番号を表します。データ。確認番号フィールドは、クライアントから送信されたシーケンス番号に1を加えたものです。
3回目の握手クライアントはサーバーの確認を受信すると、このTCP接続にバッファーと変数を割り当て、同時にサーバーのメッセージセグメントの確認をサーバーに送信します。3番目のハンドシェイクは、メッセージセグメントでデータを伝送できます。
素人の言葉で言えば、TCPスリーウェイハンドシェイクで接続を確立するプロセスは、初期シーケンス番号を相互に確認するプロセスです。、メッセージセグメントのどのシーケンス番号を正しく受信できるかを相手に伝えます。3番目のハンドシェイクの機能は、サーバーの初期シリアル番号をクライアントが確認することです。2つのハンドシェイクのみが使用されている場合、サーバーはシリアル番号が確認されているかどうかを知る方法がありません。同時に、これは無効な要求メッセージセグメントがサーバーによって受信されてエラーが発生するのを防ぐためでもあります。
TCPは4回振った
TCP接続は全二重であるため、通信の両方の当事者が相手方とメッセージを送受信できるため、切断には両方の当事者の確認が必要です。
初めて手を振る、クライアントは、サーバーに送信するデータがないと考え、FINセグメントをサーバーに送信し、クライアントからサーバーへの接続を切断するように要求します。送信後、クライアントはFIN_WAIT_1状態になります。
第二波サーバーは、接続を解放するクライアントの要求を受信した後、接続を解放するクライアントの要求を受信したことを示す確認メッセージセグメントをクライアントに送信し、今後クライアントからデータを受信しなくなります。ただし、接続は全二重であるため、現時点では、サーバーはクライアントにデータを送信することもできます。サーバーはCLOSE_WAIT状態になります。確認を受け取った後、クライアントはFIN_WAIT_2状態に入ります。
第三波サーバーがすべてのデータを送信した後、サーバーはFINセグメントをクライアントに送信し、サーバーからクライアントへの接続を切断するように要求します。送信後、LAST_ACK状態に入ります。
第4波クライアントはFIN要求を受信すると、確認応答をサーバーに送信し、TIME_WAITフェーズに入ります。
この段階は一定期間続きます。この時間はネットワーク内のセグメントの最大存続期間です。サーバーがこの期間内に要求を再送信しない場合、クライアントはCLOSED状態になります。
サーバーからの再送信要求を受信すると、確認セグメントが再送信されます。サーバーは、クライアントから確認セグメントを受信した後、CLOSED状態になり、全二重接続が解放されます。
TCPが4つのウェーブを使用する理由TCP接続は全二重であるため、両方の当事者がそれぞれ反対側への接続を解放する必要があります。片側の接続の解放は、これ以上データを反対側に送信できないことを意味するだけであり、接続はハーフリリース状態です。
クライアントが最後のウェーブを閉じる前に一定期間待機する理由は、サーバーに送信された確認メッセージが失われたり間違ったりして、サーバーが正常にシャットダウンできなくなるのを防ぐためです。
第3層-ネットワーク層
ネットワーク層プロトコルは、主に異なるホスト間の論理通信機能を実現します。ネットワーク層プロトコルは、2つの主要コンポーネントで構成されています。1つはIPインターネットプロトコルで、もう1つはルーティングプロトコルです。
IPインターネットプロトコルは、ネットワーク層のアドレス指定と転送方法を規定しています。たとえば、ネットワークにアクセスするホストにはIPアドレスが割り当てられます。IPV4などの一般的に使用されるアドレスは32ビットを使用してアドレスを割り当て、IPv6は128ビットを使用します。アドレスを割り当てる。
ルーティングプロトコルは、距離ベクトルルーティングアルゴリズムなど、データグラムが送信元から宛先に移動するパスを決定します。
第2層-データリンク層
データリンク層によって提供されるサービスは、単一の通信リンクを介してノードから隣接ノードにデータグラムを移動する方法です。各ホストには一意のMACアドレスがあります。これは、ネットワークアダプターによって決定され、世界で一意です。
最初の層-物理層
物理層が提供するサービスは、物理デバイスとネットワークを構成する伝送媒体との違いを可能な限りシールドすることであるため、データリンク層はネットワークの特定の伝送媒体を考慮する必要がありません。