問題タブ [data-link-layer]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
networking - イーサネットと OSI モデル
初歩的な質問ですみません。私は現在、7 つの OSI レイヤー モデルを学習していますが、1 つのことに出くわしました。2 番目のデータ リンク層にあるイーサネットは、LAN 経由でエンド ツー エンドの接続を提供しますよね。WiFi 経由でインターネットに接続していても、どこかで接続が LAN 経由で実行されているということですか?
ありがとう
tcp - WindowsでのiperfのパフォーマンスがLinuxでのiperfと比較して悪いのはなぜですか？
Androidデバイスとアクセスポイント間のTCPスループットを測定しようとしています。設定：-
もう一方の端でLinuxラップトップを使用した場合、iperfは5〜8Mbpsの高出力を提供します。
使用したiperfバージョン-Windowsでは2.0.5。Linuxでは2.0.4。
誰もがこの振る舞いについて何か考えを持っています..？
networking - ビットスタッフィングの例
私は読む例を調べています
ビットスタッフィング。次のビット文字列がネットワーク層からデータリンク層によって受信されたと仮定します：01110111101111101111110。ビットスタッフィングの結果の文字列は何ですか？追加された各ビットを太字にします。
答え：
この答えはどのように到達しますか？私の理解では、ビットスタッフィングは、フレームの最初と最後に特定のビットシーケンス（フラグ値と呼ばれる）を挿入することによって機能します。私が得られないのは：
- 旗の値は知らされていません！
- フレームの大きさはわかりませんが、旗を置く場所をどのようにして知ることができますか？
追加情報：このネットワークはイーサネットだと思います。
追加情報2：ビットフラグは01111110
正直なところ、私は理解していると思いますが、フラグ01111110を最後または最初に追加しなかったため、答えは不完全ではありませんか？そのビットのパターンがメッセージに表示されたとき、彼らはただ世話をしました。
他の例：ここでも彼らはそれをします。
networking - データリンク層とリンク層の違いは何ですか?
データリンク層とリンク層の違いは何ですか? 同じ意味ですか？
checksum - イーサネットフレームの最後にフレームチェックシーケンスがあり、他の場所にはないのはなぜですか
イーサネットフレームチェックシーケンスは、データリンク層のフレームの最後に常に追加されます。フレームの最後に追加され、他の場所には追加されないのはなぜですか？
私はそれについて考え、CRCチェックサムの計算方法や、フレームの構造がヘッダー+crc+ペイロードではなくヘッダー+ペイロード+crcの方がハードウェアで実行しやすいことと関係があるのではないかと考えました。
CRCは（データ+パディング）/除数の形式のXOR除算を実行し、最後のフレームではパディングが余りに置き換えられます。次に、受信機は（データ+剰余）/除数を計算し、結果が0の場合にフレームを受け入れます。
tcp - インターネット プロトコル スイート用の低レベル ネットワーク ライブラリはありますか?
インターネット プロトコル スイート用の低レベル ネットワーク ライブラリはありますか?
キャプチャと送信Ethernet frames(リンク層)、処理IPとICMPパケット (インターネット層)、トランスポート層などのライブラリ。
c - C (Linux) でネットワークに raw パケットを挿入する
バイトストリーム（イーサネットヘッダーと、おそらくイーサネットパケット内にカプセル化された上位層プロトコルも含む）を取得し、特定のインターフェイスのネットワークに送信する関数を作成しようとしています。
これが私のコードの要約です：
エラーが発生します
このエラーを修正するにはどうすればよいですか?
私の最初の推測では、これは引数が原因であると考えられsaます。他のすべての引数はかなり標準的であり、うまくいかないことはあまりないからです。この例sockaddr_llのように、これをtypeの引数に置き換えることもできますが、これはヘッダー情報を から抽出することを意味し、既にそこにあり、準備ができているため、これは少し無意味に思えます。もっと良い方法があるはずですか？カプセル化、カプセル化解除、再カプセル化、送信には不要な手順が多すぎるようです。既存のコードの基礎となるインターフェイスを作成しているため、データリンク層のヘッダーが含まれないように入力を調整する方法はありません。buf
networking - IP パケットはどのように再構成されますか
合計サイズが 12000 バイトの IP パケットがあり、このパケットをデータリンク層を介してステーション A からステーション B に送信するとします。1 つのイーサネット フレームは最大 1500 バイトのペイロード データを運ぶことができるので、12000 バイトの IP パケットを送信するには、合計で 8 つのイーサネット フレームが必要になりますね。
最初のイーサネット フレーム (IP ヘッダーを運ぶ) が送信中に文字化けし、IP ヘッダーの TotalLength フィールドに実際の長さが含まれておらず、ナンセンスな値が含まれているとします。ステーション B がヘッダー チェックサムが有効でなくなったことに気づき、フレームを破棄したとしても、ステーション B は次の IP パケットが着信データ ストリームのどこから始まるかをどうやって知ることができるでしょうか? 最初の IP パケットのペイロードが何バイトかはわかりませんよね?
それとも、IP パケットのサイズは、基礎となるデータリンク フレームが処理できるペイロードの最大長によって効果的に制限されますか?