あらためてマスタリングTCP/IP 入門編第6版を読む

「マスタリングTCP/IP 入門編第6版」を読んでいます。読書メモ。

なぜ読もうと思ったか

ALBのパケロス事例からTCP/IPをおさらいしたかった
積読だった

マスタリングTCP/IP　入門編（第6版） | Ohmsha 本書は、ベストセラーの『マスタリングTCP/IP入門編』を時代の変化に即したトピックを加え、内容を刷新した第6版として発行するものです。豊富な脚注と図版・イラストを用いたわかりやすい解説により、TCP/IPの基本をしっかりと学ぶことができます。プロトコル、インターネット、ネットワークについての理解を深める最初の一歩として活用ください。 www.ohmsha.co.jp

期待すること

インターネットの基本を理解する（いまさry）

感想

1日目

交互に音読していくスタイル
第2章 TCP/IPの基礎知識から開始
30min
10ページくらいしか進まなかった
ARPANETという研究目的のネットワークから生まれた
- TCP/IPが生まれたのは1975年！
- ARPANETでTCP/IPが採用されたのは1993年！
- 「The Internet」と呼ばれた
- かっこいい
TCP/IPは郡
- 3層のIP、4層のTCPだけをさすのではなく、TCP/IPに関連するものを全てさす（HTTPとかFTPとかSSHとかも含まれる）
OSIよりTCP/IPがなぜ普及したのか？
- 思想による
- 実装ありき（意識して）で仕様を考えた
- 実装重視
- 動かすことが大事
- やってみてだめなら考え直すのトライアンドエラー
- 急速な技術革新に対応するプロトコルの決定や改良を行える仕組み
- この仕組みが良かったそうだ
RFCとIETF
- 楽しい
- iD->Proposed Standard->Draft Standard->Standard
- QUICもやっと「Proposed Standard」

Information on RFC 9000 » RFC Editor www.rfc-editor.org

2日目

2.3 インターネットの基礎知識から
- 広義のインターネット。狭義のインターネット。
  - 今はもう世界につながるもの = インターネット
- 地域ネット
  - もう廃れてる？よくわからん。ケーブルテレビの回線とか？
  - https://www.nic.ad.jp/sc-sendai/program/iwsc-sendai-d1-1.pdf
- IX
  - 単一障害点ではない
- 海底ケーブルが世界をつなげている
  - ありがとう
  - 沖縄近海？に分岐点？Hub？みたいなのがあることを噂で聞いた
  - 天敵はサメ
    - https://www.gizmodo.jp/2014/08/post_15292.html
- TCP/IPの階層モデルとOSI参照モデルは兄弟だった
  - OSI参照モデルの一部のようなイメージだった。3層、4層の。
  - 下位の方がデータの損失について保証はない
    - アプリケーションで
  - インターネット層 IP
    - 住所を見て相手に届けるよのプロトコル
  - トランスポート層
    - TCP
      - 届けるものの中身を保証するよ
      - いろいろなチェックするよ（相手が繋がってるかとか3way）
      - ちっちゃいデータだと無駄が多いよ
      - 一定間隔で届けるのも向いてないよ（ビデオとか）
    - UDP
      - 相手のことは気にしないよ
      - ビデオとかむいてるよ
- パケットヘッダ
  - イーサネットヘッダ（IPヘッダ）（TCPヘッダ）（データ）
    - IPヘッダ（TCPヘッダ）（データ）
      - TCPヘッダ（データ）
- ドラクエに例えると
  - A町: 毒消し草
    - TCPヘッダ: 毒消し草（データ）を包む
      - IPヘッダ: A町からB町まで届けるよ（TCPヘッダ: 毒消し（データ）を包む）
        イーサネットヘッダ近くにいるスライムさんを経由するよ（IPヘッダ: A町からB町まで届けるよ（TCPヘッダ: 毒消し草（データ）を包む））
  - スライムさん: イーサネットヘッダ- IPヘッダを見て「B町まで行きたいんだな」「次はCさんだな」 - イーサネットヘッダ近くにいるドラキーさんを経由するよ（IPヘッダ: A町からB町まで届けるよ（TCPヘッダ: 毒消し草（データ）を包む））
  - ドラキーさん: イーサネットヘッダ- IPヘッダを見て「B町まで行きたいんだな」「B町まで持っていこう」 - イーサネットヘッダ近くにいるB町へ持ってくよ（IPヘッダ: A町からB町まで届けるよ（TCPヘッダ: 毒消し草（データ）を包む））
  - B町: 何が入ってるかな。あけるよ
    - 分解：イーサネットヘッダ（IPヘッダ: A町からB町まで届けるよ（TCPヘッダ: 毒消し草（データ）を包む））
      - 分解：IPヘッダ（TCPヘッダ: 毒消し草（データ）を包む）
        分解：TCPヘッダ: 毒消し草（データ）を包む
        毒消し草ゲット

3日目

2.5から
- パケットヘッドの話続き
  - パケットヘッダにMACアドレスを持ってる
    - え、なんで？
    - IPは相手の場所
      - IPヘッダで持っている
- イーサネットヘッダでMACアドレスを持っている
  - なんで？
  - 経由地（ルーターとか）を辿っていくため
  - 経由していくのにイーサネットヘッダは経由地到着→破棄→経由地到着→破棄を繰り返す
  - MACアドレスで繋がっていく :hoe-:
  - 87ページの図2.19がめちゃめちゃわかりやすかった
- データリンク層(イーサネットヘッダのところ)にはFCSがつけられる
  - ノイズなどでパケット破壊を検出
  - 届いた先で壊れていれば再送信を要求する
  - TCPでパケロスチェックしているやん。
    - そことは別（かも）
    - チェックしているのはフレーム（データリンク層の部分）のチェックをしているっぽい
      - 後で出てくるためそこでチェックする
わからないこと
- アプリケーション（CurlとかのHTTPクライアント）はパケットヘッドのどこまで作るのか
  - パケットヘッドはどこまで誰が作るのか
    - データまででは。
    - TCP/UDPヘッダ、IPヘッダ、イーサネットはOSが作るのでは？（pp）
    - IPヘッダで持ってるIPアドレスとかとかHTTPクライアントから渡されるよね。
      - 渡して作る感じかね
- FCSでチェックできる範囲ってどこまで？
  - FCSがあれば再受信するからパケロスなんて起きえないのでは？
    - そんなことはなさそうだけどよくわからない

4日目

第3章.データリンクの役割
- イーサネットのところ
- 通信媒体で直接接続された機器間で通信するための仕様を定めている
- データリンクはネットワークの最小単位といっていいよ
  - 世界中のインターネットはデータリンクの塊といっても過言ではないよ
- MACアドレス
  - イーサネットや無線LAN以外も使うよbluetoothとか
  - ベンダ識別子3~24bit
  - ベンダ内識別子25~48
  - 感想 MACアドレスがなんでNICあるんだろうと思ってた。なんらかの通信のためにしか使わないから。当然だな。
- MACアドレスを使った通信の仕組みは色々ある
  - 半2重/全2重
  - コンテンション方式CSMA/CD方式（一方通行）（トランシーバーみたいな通信）
    - 衝突前提
  - トークンパッシング方式
  - これらはマシン同士を直接繋ぐような仕組み
- 媒体共有型のネットーワーク
  - 今は主流
  - 全2重
  - スイッチ（はぶ）を経由して通信
  - スイッチとマシンは直接つながる -　よくある感じの会社のネットワークとか
- 全体通してへーという感じ
- 次回3.2.5から

5日目

3.2.5
- :he-: みたいなのが増えてきた
- リンクアグリゲーション
  - 設計したことあるとのこと
  - フロアをまたいで集約して外に出る場合などに利用
  - 複数ないと1つがだめになった場合にだめになる
    - 耐障害性
- VLAN タグ
  - 複数スイッチを跨いだ場合にセグメントを指定できる
- イーサネット
  - ほかのNIC
    - イーサネット以外のNICがあったってこと？
    - FDDIなど？

3424 - ファイバ分散データインタフェース（FDDI） www.blackbox.co.jp

- LANと光ファイバの違い

ネット回線で使われるメタルケーブルの種類と仕組み・構造を解説 現在、通信回線の大部分を担っているのは「メタルケーブル」と「光ファイバー」です。特にメタルケーブルの歴史は古く、国内で本格的に利用され始めたのは1950年代初頭。ここでは長らく利用されてきたメタル simpc.jp

- もともと半2重のCSMA/CD衝突検知
  - イーサネットの高速化は難しいとされていた
  - 10Mbps止まり
- ATMで培われたスイッチ技術の進歩とカテゴリ5のUTP（ツイストペアケーブル）によって超高速化
- 同軸なくなりポートとコンピューターを1対1でつないだ接続
  - ツイストペアケーブルには８本の線（4本2セット）があり、送信の線、受信の線が1つのケーブルでできるようになったとさ。爆速！
- 次回3.3.4から

6日目

3.3.4 イーサネットのフレームフォーマットから
- 1オクテット - 1バイト
  - なんでバイトって言わないの？
    - バイトは特殊なコンピューターで6bitとか7bitとか9bitとかいうからだって
- プリアンブル（イーサネットの先頭）
  - イーサネットがここから始まるよ。という接頭辞みたいなもん
- フレーム
  - 6オクテット宛先Macad 6オクテット送信もとMacad みたいな
  - ２オクテットの「タイプ」でデータがなにかを判別
  - 最後にFCS（壊れてないかの判定）
  - でっかいデータにはジャンボフレームもあるよ
  - 図がわかりやすいよ
- 無線
  - 無線PAN　Bluetoothのこと
    - かわいい。使っていく
  - 無線LANと無線RAN（200KM-700KM届くやつ）
    - 読み方がネイティブなら違うはず。発音もとむ
  - 802.11 xxxx が紹介されてる
    - 802.11 xxx は物理層の方式の話だったんだ。飛ばすから。
  - Wi-Fi4（802.11n）,Wi-Fi5（802.11ac）,Wi-Fi6（802.11ax）と呼ぶ。わかりにくいから

「Wi-Fi 4」「Wi-Fi 5」「Wi-Fi 6」の違い - PCと解 pctrouble.net

- 電子レンジの話。802.11gを使ってる時に電子レンジを使い困っている人には11aを勧めると良い（実話pp）

目標ができた
- DNS Over QUICの論文を読みたい
- https://arxiv.org/pdf/2202.02987.pdf

One to Rule them All? A First Look at DNS over QUIC TheDNSisoneofthemostcrucialpartsoftheInternet.SincetheoriginalDNSspecificationsdefinedUDPandTCPastheunderlyingtransportprotocols,DNSqueriesareinherentlyunencrypted,makingthemvulnerabletoeavesdroppingandon-pathmanipulations.Consequently,concernsaboutDNSprivacyhavegainedattentioninrecentyears,whichresultedintheintroductionoftheencryptedprotocolsDNSoverTLS(DoT)andDNSoverHTTPS(DoH).AlthoughtheseprotocolsaddressthekeyissuesofaddingprivacytotheDNS,theyareinherentlyrestrainedbytheirunderlyingtransportprotocols,whichareatstrifewith,e.g.,IPfragmentationormulti-RTThandshakes-challengeswhichareaddressedbyQUIC.Assuch,therecentadditionofDNSoverQUIC(DoQ)promisestoimproveupontheestablishedDNSprotocols.However,nostudiesfocusingonDoQ,itsadoption,oritsresponsetimesexisttothisdate-agapweclosewithourstudy.OuractivemeasurementsshowaslowlybutsteadilyincreasingadoptionofDoQandrevealahighweek-over-weekfluctuation,whichreflectstheongoingdevelopmentprocess:AsDoQisstillinstandardization,implementationsandservicesundergorapidchanges.AnalyzingtheresponsetimesofDoQ,wefindthatroughly40%ofmeasurementsshowconsiderablyhigherhandshaketimesthanexpected,whichtracesbacktotheenforcementofthetrafficamplificationlimitdespitesuccessfulvalidationoftheclient'saddress.However,DoQalreadyoutperformsDoTaswellasDoH,whichmakesitthebestchoiceforencryptedDNStodate. arxiv.org

7日目

次回3.4.8から

8日目

TCPとUDP
- 知ってるよねーというところ
  - P2PとかQUIC、WebRTCの話に派生
- ソケット
  - アプリケーションから見たときには、send()とrecv()APIを使う
  - asyncioもそう
- IPヘッダとTCPヘッダ

9日目

QUICの話
- QUICのHappy Eyeballsってどうやってるの？Happy Eyeballsってなんだっけ？

HTTP3/QUIC接続と同時に、もしくはわずかな差で、HTTP2/TLS/TCPの接続試す先につながったほうを使う異なる通信手段の並行で動作させて最適なものを選ぶ、いわゆる Happy Eyeballs (RFC8305) に類する手法

(

え! QUIC無効化するの？ HTTP over QUIC or TCPの接続選択を考える HTTP/3overQUICorHTTP/2overTCPの接続選択の仕組みや、QUICとNATルータとの関係について考察します。不用意なQUIC無効化を避けるためにも、実装の挙動を正しく把握したいと思って執筆しました。 medium.com

ゲームの配信の話
- 何で通信しているの？TCPなのUDPなの？
- だいたいこれに書いてあった
- ゲームの種類による
- RUDPというのもある
  - RUDPは、UDPを拡張し、メッセージを失うことなく送信先に届けるようにするもの

ネットワークゲームにおけるTCPとUDPの使い分け ネットワークゲームにおけるTCPとUDPの使い分け-DownloadasaPDForviewonlineforfree www.slideshare.net

tracerouteコマンド
- 第3層でのルートが見れる
- ❯ traceroute www.google.com みたいな感じ
- Macの場合UDPで繋ぐ？
Publish/Subscribe
- 配信者とサブスクライブしているユーザー
  - 配信者は1つのコンテンツをサブスクライバーに配信するよ
Producer/Consumer
- よく出てくるあれ
  - キューに積んでコンシューマー（消費者）が消費していく
  - スレッドのあれ
口内炎
- ビタミンB2, B6が効く
  - だいたいレバー
    - だめならショコラBB
  - 歯石は歯周病の原因になる

10日目

6.4.2. シーケンス番号と確認応答で信頼性を提供
- 「あいよー」ACKだよ
- 「え？なんて」NACKだよ
6.4.3. 再送
- RTT（Round Trip Time）
  - 往復の時間だよ
- ゆらぎ
  - RTTのゆらぎ
6.4.4. コネクション管理
- SYNから始まりFINで終わる7つだよ
  - 3WAYハンドシェイク
  - FIN -> FIN/ACK -> ACK は間違っていて、正しくは FIN/ACK -> FIN/ACK -> ACK であったという話
    - 本では FIN -> FIN/ACK -> ACK になっている

FIN -> FIN/ACK -> ACK という TCP の幻想 - kawasin73のブログ 掴んで離さぬコネクション。どうも、かわしんです。しがみつかずに適切なタイミングで離しましょう。この１週間でRFCを読みながらTCP/IPプロトコルスタックを自作した1のですが、その時にコネクションの終了処理でハマったので後学のために書き残しておきます。一言でまとめるとFIN->FIN/ACK->ACKは間違っていて、正しくはFIN/ACK->FIN/ACK->ACKであったという話です。ちなみに、僕が自作したTCP/IPプロトコルスタックはこれです。github.com現象それはTCPのリスナーとclose処理が出来上がってコネクショ… kawasin73.hatenablog.com

KLABさんでTCP/IP プロトコルスタックを実装するイベント（新卒向け）をやっているのを知る
- https://kawasin73.hatenablog.com/entry/2019/08/30/174424
- https://klab-hr.snar.jp/jobboard/detail.aspx?id=pcato1a0obc
  - おもしろそうだ
ウィンドウ制御の話
- この辺よく知らなかった
  - HTTPのストリームの話の内側の話
- 複数のセグメントを並列に確認応答する
- さらにこれの再送の話
  - 多少ACKが返ってこなくっても次のACKで確認応答パケットを確認する
  - さらに高速再送制御のため、確認応答パケットが3つ続くとそいつをだけを再送する仕組み
    - P.250図6.18を参照する
- そしてフロー制御でクライアント側がどれだけ受け取るか、ウィンドウサイズを返している
  - ウインドウスロープ
  - P.251図243ページを確認する

11日目

ふくそう制御の話
- 完全に理解した
- ふくそう - 混雑
- ふくそう制御 - 混雑しないように制御する
- その手法
  - スロースターター制御
    - 最初はふくそうウインドウとシーケンスを少なく。徐々に指数関数的に増やしていく
    - ACKがあるたびに増やす
      - でも増えすぎる。
      - そのためスロースターター閾値を追加した
      - 指数関数的に増えてしまったことが原因で、タイムアウトや重複確認要求（ACKの重複 3回重複するとサーバー側が再送する）
      - が発生している場合、次の再送信をするときに閾値を設ける
  - 時間かかった。

12日目

QUIC
- UDP+QUICで1つのトランスポートプロトコル
- QUICが認証と暗号化を行う
- TCPにあってUDPにない信頼性はどうなってる？
  - UDPには送信元ポート、宛先ポートlength、チェックサムしかない
  - ACKとかない
  - 例えば再送制御、コネクション管理（TCPの3wayハンドシェイク）
    - これをQUICが行う
  - TLSのハンドシェイク
    - これも
  - なんでQUICはUDP？
    - TCPの課題を解決するため
      - TCPの課題って
      - 例えば暗号化、例えば多重化
    - 新しいプロトコルだと使われない
      - UDPなら使ってもらえる
        Try and Errorができる
  - Happy eyeballsの話とか
    - 奥さんのトークで

まとめ

通しては読んでいなかった
知ってることも知らないこともあった。学べた。
また付き合ってくれたtakappに感謝
- インフラエンジニアだったため、リンクアグリゲーションの設計経験など他では聞けない話が聞けた
- めちゃめちゃ多岐にわたって詳しかった。本当に感謝。
次はこれを読もう
- DNS Over QUICの論文を読みたい
- https://arxiv.org/pdf/2202.02987.pdf

以上

本メモ

なぜ読もうと思ったか

期待すること

感想

1日目

2日目

3日目

4日目

5日目

6日目

7日目

8日目

IPヘッダとTCPヘッダ

9日目

10日目

11日目

12日目

まとめ