Ruby、Railsでアプリケーションを作ってみましたが、ネットワークではどのような動きでwebページが表示されるのかといったことが全くわかっていませんでした
そこでTCP/IPを学びアプリケーションからどのような通信が行われれているのか学習した備忘録です
解釈間違いやそもそもの間違い等ございましたら、コメントにてご指摘いただけると幸いです

TCP/IPとは一体？

TCP/IP(Transmission Control Protocol/Internet Protocol)の略
インターネット通信において最も利用されている通信プロトコルのことです。
簡単に言うと、インターネットを使うときの通信ルールです。
このモデルでは、インターネット通信のプロトコル群の中でもTCPとIPがよく使われることからTCP/IPモデルと呼ばれています。

全体像

TCP/IPモデルではコンピュータネットワークでの通信を実現するため、様々な処理や機器が働いています。
この役割や動きを明確にするためにTCP/IPモデルでは下記4つの階層モデルが決められています。
アプリケーション層
トランスポート層
インターネット層
ネットワークインターフェース層
ざっくりとした動きは下図のようになります

アプリケーション層で相手に送るデータを準備します。
その後、トランスポート層、インターネット層、ネットワークインタフェース層へとそれぞれの層でヘッダーを付与された後、次の層へ渡されていきます
最終的にネットワークインターフェース層で電気信号に変換され、通信ケーブルを通して受信側のネットワークインターフェース層へ運ばれます。
受信側は送るときとは逆でネットワークインターフェス層についたデータはインターネット層、トランスポート層、アプリケーション層の順にヘッダーの情報を元に渡され、データを受け取ることができます。
層に入るごとにその層で特有のヘッダーというものが元のデータに付与されていきます。
ヘッダーとは処理情報のことで、宛先の情報を付与したり、様々な情報があります。
例えば、送信するデータがアプリケーション層に入り、HTTPなどのヘッダーが付与されます。
トランスポート層へ移ると元のデータ、アプリケーション層で付与されたヘッダーが合体したものに更にトランスポート層でヘッダーが付与されます。
この上位層の処理情報をヘッダーとして下位層で更にヘッダーを付与して包み込んでいくことをカプセル化といいます。
逆に付与されたヘッダーを外していくことは非カプセル化といいます。

まとめ

データを送る際には通信のための層で送り先の位置情報などをヘッダーとして元のデータに付与していき、電気信号として送信する
受信側でそれを受信すると、送信のときとは逆のヘッダーを外していく非カプセル化を行い、最終的にデータを取り出すことができる

各層の役割と詳細について

それぞれの層でデータを送る時に行われている処理について見ていきます

アプリケーション層

ユーザーが直接触れる層です
アプリケーションが通信機能を使うときのルール（プロトコル）が定義されています
具体的に以下のようなプロトコルがあります

例えば、Webページを表示したいときはHTTPが使われますし、メールの送信がしたい場合はSMTPが使われるということです
どうやってコンピュータ側がプロトコルを選んでいるのかと疑問に思いました
おそらくアプリケーション自体にどの通信をするのかの記述があるのではないかと思います
Rubyであれば、routes.rbにHTTPメソッドのgetやpostといった記述をしますよね
そのため、アプリ側でどの通信を行うかの記述をしており、それに応じた処理をアプリケーション層ではしてくれるのではないかと思いました
（詳しく調べきれず、自分の想像なので詳しく分かる方いれば教えて下さい）

トランスポート層

トランスポート層でTCP/IPのTCPがでてきます
トランスポート層では
「アプリケーション層から受け取ったデータをインターネット層に渡す」
「インターネット層から届いたデータを適切なアプリケーションへ渡す」といった役割があります
トランスポート層とインターネット層の間にポート番号というドアのようなものがあり、このポート番号を元にアプリケーション層のどのプロトコルに渡すか識別します
webページの表示に関するデータであれば、HTTPに渡されますし、メールの受信に関するデータであれば、POPに渡されます
このデータを渡すときにどのプロトコルに渡すのかを識別する番号がポート番号です

ポート番号

ポート番号について詳しく見ていきます
ポート番号では、0~65535番までの数値を利用します。
数値の範囲によって以下の３つに分かれています
ウェルノウンポート：0~1023番
レジスタードポート：1024~49151番
ダイナミックポート：41952~65535番
クライアントがリクエストを送り、サーバーからレスポンスを返す流れを考えてみます
クライアント側にはデータ通信の際にその都度ダイナミックポート番号が与えられ、どのクライアントからリクエストが来たかわかるようになっています
サーバー側ではあらかじめウェルノウンポート番号が決められています
リクエストの種類によって対応するリクエストにあったポート番号を通ってアプリケーション層へ渡されます
そこで取得したデータはリクエストのあったクライアントのポート番号を通して返します
例えば、webページが見たい場合は
クライアントがあるページを表示するリクエストを送る
クライアント側にダイナミックポート番号が与えられ、サーバーへリクエストが進む
webページの表示はHTTPの80番ポートを通ってwebサーバーへリクエストが渡される
レスポンスがリクエストのあったダイナミックポート番号へ返される
クライアントがwebページを見ることができる
ざっくりとはこんなイメージでポート番号を使ってリクエストとレスポンスがやりとりされています
トランスポート層では、アプリケーション層からのリクエストとレスポンスをポート番号を使って受け取り、元のクライアントに返しています

ウェルノウンポート

あらかじめ決められているポート番号です。
webページを表示するときはプロトコルとしてHTTPの80番が使われます。
その他にも、SSHは22番、SMTPは25番などがこのウェルノウンポートになります。

レジスタードポート

ウェルノウンポート番号以外でよく使われるサーバーアプリケーションを認識するためのポート番号です。
例えば、リモートデスクトップはポート番号3389、Microsft SQL Serverは1433が登録されています。

ダイナミックポート

クライアントを識別するためのポート番号です。
特に固定されておらず、リクエストの度にその時空いている番号がクライアントに割り当てられます。

まとめ

クライアントからのリクエストはポート番号を使って、トランスポート層に渡される
サーバーではリクエストに応じたポート番号が用意されている(HTTPやSSH、SMTPなど)
サーバーからのレスポンスは始めにリクエストを送ってきたクライアントの使ったポート番号に返されることで、リクエストをしたユーザーへきちんとレスポンスが返される

TCPがデータを届ける仕組み

トランスポート層で使われるプロトコルにはTCPとUDPの２つがあります
TCPが一般的に使われており、データを確実に届けることができるプロトコルです
UDPはリアルタイムの動画や音声などに使われており、不確実ながらも素早い通信が可能なプロトコルです

確実にデータを届けるTCP

TCP(Transmission Control Protocol)は確実にデータを届けたい通信で使われます
確実に届けたい通信とは、web、メール、FTP(ファイルの送受信)などです
TCPでは、受信がうまくできるように通信速度の調整や届かなかったデータの再送などを行います

TCPヘッダーを使ったデータ送信

TCPではデータを分割し、TCPセグメントが作られます
TCPセグメントはデータ本体とTCPヘッダーから成ります
TCPヘッダーには以下のような様々な情報が入っています

シーケンス番号：送信済みのバイト数を表します
確認応答番号：受信済みのバイト数を表します
コントロールフラグ：現在の状況を相手に伝え、TCPによる通信を制御する働きを持ちます
通信経路の混雑による送信量を減らしたことを伝えるCWR
データ送信が完了し、通信を終了したことを伝えるFIN
接続開始時にONとなるSYN
確認応答番号と合わせて使われ、確認したことを伝えるACKなどがあります

TCPの通信開始から終了までの流れ

全体の流れとしては下図になります

通信開始(コネクション確立）

TCPでの通信はコネクション確立から始まります
このコネクション確立が3ステップで行われるため3ウェイハンドシェイクと呼ばれています
通信開始の図で見ると、
①クライアントからサーバーへコネクション確立の要求
TCPヘッダにあるコントロールフラグのSYNが1、ACKが0、シーケンス番号はランダムな値が与えられます
SYNは接続開始を制御するフラグ、ACKは接続の確認をするフラグです
これらのフラグは1ビットでデータを持つため、ONとOFFの２つは0(OFF)と1(ON)で表されます
つまり接続開始を始め、相手からの応答は確認されていないという状態です
②サーバーがクライアントのコネクション要求を受け入れ、相手へも要求
SYNは1、ACKは1、シーケンス番号は0、確認応答番号は1です
サーバー側からはデータ送信をしていないのでシーケンス番号は0です
確認応答番号は受信済みのデータサイズを表します
コネクション確立では相手から受信したシーケンス番号に1を加算した値となります
つまりここでは
クライアントからのコネクション確立の要求をサーバーが受け入れた
サーバー側からクライアント側にもコネクション確立の要求をしたという状態です
③クライアントがサーバーからのコネクション確立の要求を受け入れる
SYKは0、ACKは1、シーケンス番号は1、確認応答番号は1です
接続は完了したので、SYKは0です
サーバーからの応答を確認したので、ACKが1となります
サーバーからの確認応答番号が1（送ったデータ量が1）なので、シーケンス番号は1になります
確認応答番号は相手から受信したシーケンス番号に1加算したものなので1です
シーケンス番号は送ったデータ量の帳簿、確認応答番号は受信したデータ量の帳簿です
なので、①でクライアントから最初に送ったデータ量は1、②の確認応答番号が1なので送ったデータは１とわかります
次にサーバーから同様の要求がクライアントにされたので、クライアント側では確認応答番号が1となり、既に1bitのデータを送っているので次のシーケンス番号は最初の0に1加算された数値になります

通信中

コネクション確立が終わったらデータのやり取りができる状態になります
データの送信の流れはコネクション開始時と同じです
送る側は送ったデータ量がシーケンス番号に加算されていきます
受け取る側は送られてきたデータが確認応答番号へ加算されていきます

最大セグメントサイズMSS（Maximum Segment Size）

コネクション確立時に最大セグメントサイズMSSのすり合わせが行われています
これは一度にやりとりできる最大のデータ量のことです
クライアント側、サーバー側のそれぞれで定義されており、小さい方にあわせてデータ通信が行われます
例えば、MSSが1000バイトとなった場合に⑤では2000バイト送っているため一度に送信することができません
この場合はサーバー側が1000バイト送る、クライアントが受信確認を送る、サーバー側が再度1000バイト送るといった流れになります

通信終了

データのやり取りが終わったら通信終了のためコネクションを切断します
コネクション確立は3ステップで行っていましたが、コネクション切断は4ステップが一般的なようです(3ステップでの切断もできるようです)
⑧FINが1、ACKが1、シーケンス番号が1301、確認応答番号が3001です
クライアント側の通信の内訳
データの送信：コネクション確立で1バイト、④の800バイト、⑥の500バイト
データの受信：コネクション確立で1バイト、⑤の2000バイト、⑦の1000バイト
となっているので、送ったデータ量のシーケンス番号は1301、受信したデータ量の確認応答番号は3001となっています
帳簿のイメージとはこのことで、送ったデータ量と受信したデータ量がシーケンス番号と確認応答番号で管理されています
FINはデータの送受信が終わり、通信を終了することを伝えるコントロールフラグです
ACKが１なので、データを受け取った確認と通信の終了を伝えるFINが１となっています
⑨FINが0、ACKが1、シーケンス番号が3001、確認応答番号が1302です
サーバー側は切断の要求を受け入れるだけで、切断要求はしていません
そのためFINは0、要求を受けたのでACKが1を返します
サーバー側の通信の内訳
データの送信：コネクション確立で1バイト、⑤の2000バイト、⑦の1000バイト
データの受信：コネクション確立で１バイト、④の８００バイト、⑥の500バイト、FINでの切断要求で1バイト
送ったデータの総量が3001バイトなので、シーケンス番号は3001
受信したデータの総量が1302バイトなので、確認応答番号は1302となっています
FINが1で切断要求が1バイトのデータとして送られてきているため、通信中にやりとりした1301バイトに1バイト加算して1302となります
これでクライアント側からは切断された状態となりました
⑩FINが1、ACKが1、シーケンス番号が3001、確認応答番号が1302です
サーバー側からも切断要求を行い、両者がコネクションを切断することで完全に通信が終了になります
⑧、⑨と同じ処理がサーバー側から行われます
⑪FINが0、ACKが1、シーケンス番号が1302、確認応答番号が3002です
コネクション切断のため1バイト受け取っていますので⑧確認応答番号に1が加算されます
以上の流れでコネクション確立から通信を行い、コネクションの切断が行われる流れになります
ちなみに、切断が3ステップになるときは⑨、⑩がまとめて行われます

送信失敗の判断

TCPでの通信でデータ（パケット）が届かなかった場合はデータを再送するという仕組みがあります
データの送信側、受信側はデータを送信後一定時間応答がない場合に再度データを送信します
これは確認応答番号を使って行われます
確認応答番号は受信したデータ量が分かる帳簿のため、これを確認して記録されていない部分からデータを再度送信します

通信の高速化

これまでの通信方法はわかりやすく１つのパケットをどのように送信し受け取られ、完了するかまでの流れでしたが、全てのデータで1つ1つ応答を待ってから送っていたのでは時間がかかります
そこで高速にデータをやり取りできる方法があります
例えば3000バイトのデータがあってMSSが1000の場合は1000バイトのデータを応答を待たずに1000バイトずつ送ります
その後、それぞれの応答が返ってくるという流れです

バッファによる一時記憶

通信の高速化のため、まとめてデータを送るのは良いのですが、受信側が処理しきれなくなることがあります
この問題を解決するため、送信側・受信側それぞれにバッファという一時的にデータを貯めておく記憶領域があります
TCPヘッダーのウィンドウサイズにバッファの空き領域を入れて送ることで、お互いがどれくらいまでまとめて受信できるか伝え合うことができます
バッファが満杯になるとウィンドウサイズ0の確認応答が送られ、データの送信が一旦ストップします。
送信再開のタイミングを知るために、送信側からウィンドウローブと呼ばれるパケットが送られ、その確認応答でウィンドウサイズを調べ送信の再開をします

ネットワーク混雑の検出

バッファに空きがあったり、処理能力に余裕があってもネットワークの経路が混雑していて通信速度を落とさなければならないことがあります
この場合にインターネット層のヘッダーについている混雑フラグがONになることで、TCPヘッダーのコントロールフラグのECEフラグとCWRフラグで通信速度を落とします
ECEフラグは通信速度の混雑により、パケットを受信できなくなる恐れがあることを知らせるフラグです
CWRフラグは通信経路の混雑のため送信量を減らしたことを伝えるフラグです

速度重視のUDP

UDP(User Datagram Protocol)は単純にデータを送るだけのプロトコルです
データの抜け落ちなどが発生しますが、VoIPなどの音声・映像はデータが抜け落ちてもノイズが入る程度のため主にUDPが使われています
VoIPとはインターネットを使って声のやり取りをするためのプロトコルでLINEやSkypeなどでVoIPが使われています

UDPヘッダー

UDPでもTCP同様に送信するデータにヘッダーがつけられて次のインターネット層へ渡されます
UDPヘッダーは単純に送信するためのプロトコルのため、TCPよりもヘッダーが小さいです

UDPではパケットに相当するものがデータグラムと呼ばれます

ブロードキャストとマルチキャスト

TCPにない機能として、UDPではブロードキャストとマルチキャストという1対Nでデータを送る機能があります
１つのデータを対複数人に向けて送信する場合にブロードキャストやマルチキャストといった機能が使われます

まとめ

TCPとUDPでは正確さと速度の違いがある
TCPでは3ウェイハンドシェイクによって接続を確立してからデータを送り、相手の応答によってデータの欠落があれば再送するといった仕組みによって抜けもれなく正確にデータを送受信することができる
UDPは単純にデータを送るだけのプロトコル
接続が確立されたことを確認せず送信を開始し、途中で欠落したり、バッファから溢れたデータも気にせずどんどん送っていく
そのため欠落の確認の時間などがなく速い速度でデータの送信ができる
ただデータの欠落が原因でたまに音声や映像は乱れる

インターネット層

インターネット層の役割は宛先のコンピュータまでデータを届けることです
宛先を決めるために、世界中にある無数のコンピュータを区別する必要があります
そこで、IPアドレスという重複しない識別番号が割り振られています
IPアドレスはネットワーク単位でまとめて割り当てられています
IPアドレスを見れば所属ネットワークがわかりますが、直接送れるわけではなく間に様々なネットワークのつながりがあります
このネットワークのつながりをルーターというネットワーク機器が仲介しており、データを送る際にはこのルーターがIPアドレスをたどって宛先にデータを送る手助けをしてくれます

IPアドレス

IPアドレスにはIPv4(Internet Protocol Version 4)とIPv6があります
違いは、IPv4は32bitのIPアドレスに対し、IPv6は128ビットのIPアドレスでコンピュータを識別します
主流はIPv4ですが、IPアドレスが足りなくなってきてIPv6への以降が必要となってきています
ちなみに、IPv4とIPv6は全くの別物なので互換性がありません。
そのため両者の共存には１つの機器に２つのIPアドレスを割り当てるデュアルスタックや
IPv4ネットワークを通過するときにはIPv4のパケット内にIPv6パケットを入れて送るトンネリングといったような技術が使われています

IPヘッダー

トランスフォーム層ではデータ本体にTCPやUDPのヘッダーがついたセグメント・パケットにしました
それらがインターネット層に入ると、IPヘッダーが付与されます
このまとまりをIPデータグラムといいます
IPヘッダーに含まれる情報は下図になります

IPパケットの生存期間

IPパケットには生存期間がヘッダーに定義されます
様々な理由で到着しないIPパケットがネットワーク上に存在すると混雑してしまうため、
IPヘッダーに定義された生存期間をすぎると消滅させられます

パケットの分割と再構築

一度に転送できるデータサイズ(MTU=Maximum Transmission Unit)は経路によって決まっています
そこで、ルーターにはパケットを必要に応じて分解して送る機能が備わっています
ヘッダーにある識別子、分割フラグ、フラグメントオフセットはこのデータの分割にかかわる部分です
識別子は分割したデータをもとに戻す時に目印としてつけるものです
分割フラグは分割の許可フラグと分割断片の続きを表すフラグをもっています
フラグメントオフセットは分割したデータが元データの中でどの位置にあるものかを伝える数値です
識別子でバラバラにしたものを１つに集め直し、分割フラグで分割してもよいものか、した後に過不足なく集まっているか確認し、フラグメントオフセットで元に位置に集まったデータを戻して元データを復元するといったイメージです

ルーターとルーティング

データを宛先のIPアドレスまで届けるにはルーターがどのルーターとつながっているか調べていき、宛先までの経路を見つけるといった作業がされています
これを探し出す仕組みをルーティングといい、
各ネットワークのルーター同士がどこにつながっているか情報を交換する際のプロトコルをルーティングプロトコルといいます
ルーターにはルーティングテーブルという情報を持っています
ルーティングテーブルは宛先のホストが属するネットワークにたどり着くためにはどのルーターに接続すべきかという情報が書かれています

トラブルを通知するICMP

ICMP(Internet Control Message Protocol)はデータ転送中のトラブルの通知などに使われるプロトコルです
例えば、回線が混雑していてデータが到着しなかった場合には
回線混雑によってデータが到着しなかったことを送信元へ知らせることで、適切に対処することができます
ICMPは以下の図で表され、タイプの部分に通信状況やエラー内容についての情報がはいります

アドレス変換

プライベートIPアドレスはネットワーク内でのみで有効なIPアドレスです。
そのため、インターネットに接続する際にはプライベードIPアドレスをグローバルIPアドレスに変換する必要があります
このプライベートIPアドレスをグローバルIPアドレスに変換する技術がNAT(Network Address Translation)です
NATでは同じポート番号でインターネットに接続できてしまうため、ネットワーク内の１つ１つのホストを識別して接続することができません。
そのため、返ってきたデータをどのホストに返すかわからなくなってしまいます。
そこで同じポート番号を使えないように、ポート番号も含めて変換を行うNAPT(Network Address Port Translation)という技術でポート番号が重ならないように置き換えてから送信することでホストを見分けることができます

ドメイン名

IPアドレスは覚えにくいため、より人間にわかりやすくドメイン名として使うための仕組みがあります
例えばgoogleのサイトにアクセスしようとした時に
グローバルIPアドレスをブラウザのアドレス入力欄にいれるとそのサイトにアクセスすることができます
以下はgoogleのグローバルIPアドレスです
172.217.31.163
ただ、この数字の羅列を覚えることはできませんよね
そこでこのIPアドレスに対応するホスト名とドメイン名を紐付けることでアルファベットでアドレスを入力することでそのサイトにアクセスすることができます
https://www.google.com

DNSサーバー

ドメイン名はDNS(Domain Name System)によって管理されています
新しいドメイン名を使う場合にはDNSサーバーにIPアドレスとあわせて登録する必要があります
ドメイン名に対応するIPアドレスを知るためには、DNSサーバーに問い合わせなければなりません
例えばgoogleにアクセスしたい時にはhttps://www.google.comと入力します
すると、DNSサーバーへIPアドレスを問い合わせそのIPアドレスにアクセスするといった流れでgoogleのページにアクセスできます

ネットワークインターフェース層

ネットワークインターフェース層ではネットワークのハードウェアを制御する層です
ここでのハードウェアはネットワークカードやLANケーブル、光ケーブルといったようなもののことです
これらを制御することで、インターネット層などの上位の層がハードウェアの違いを気にすることなく同じように動作させることがこの層の役割です

イーサネットフレーム

イーサネットフレームはイーサネットの通信を行う時に使われるデータのフォーマットです
TCP/IPでいうパケットのかわりに、イーサネットではフレームという用語で使われます

プリアンブルはデータの始まりを表します
データ本体にIPパケットなどが含まれています
FCSは受信したデータに誤りがないかどうかを調べるために付与されるデータです

MACアドレス

MAC(Media Access Control)アドレスはネットワークカード(NIC=Network Interface Card)に振られている識別番号です
MACアドレスは装置間のやりとりを行うためのアドレスで、IPアドレスに似ています
最終的な宛先を示すIPアドレスは変わることはありませんが、
MACアドレスは隣の装置・ルーターまでの宛先を示すものなので、一度装置が変わると新しいフレームに載せ替えられるため次の宛先MACアドレスに変わります

ARPで宛先のMACアドレスを問い合わせる

イーサネットでデータを送るには相手のMACアドレスを知る必要があります
しかしながらIPアドレスとMACアドレスは自動的な関連付けがないため、ARP(Address Resolution Protocol)を使うことで宛先のMACアドレスを知ることができます
問い合わせる側のホストがIPアドレスを格納した要求パケットをブロードキャストし、受け取った側のホストが自分のIPアドレスであれば応答パケットを送り返してMACアドレスをアドレスを知らせます
ブロードキャストはネットワークに繋がっている不特定多数に向けて同じデータを送ることです（学校の全体放送みたいなイメージ）

回線収容局から家庭やオフィスまでの通信

回線収容局から家庭やオフィスまでの通信には光ケーブルのFTTxやメタルケーブルのxDSLが使われています

光ケーブルを使ったFTTx

光ファイバーにレーザー光を通して通信する光回線では数kmの遠距離でも高度な通信が可能です
家庭まで直接ケーブルを引く場合はFTTH(Fiber To The Home)と呼ばれ、引き込み方が異なるものをまとめてFTTxと呼びます
回線を専有する占有型と複数の信号を１つの回線に載せ分割する共有型があります

メタルケーブルでつなげるxDSL

ADSL(Asymmetric Digital Subscriber Line)やVDSL(Very high bitrate Digital Subscriber Line)がメタルケーブルを使った回線です
通信方式や速度・距離の違いによって規格があり、まとめてxDSLと呼びます
ADSLは電話回線を利用した回線で通話で使用しない高周波数でデジダルデータのやりとりをしています

PPPとPPPoE

PPP(Point to Point Protocol)遠隔地にあるコンピューターを一対一で接続するためのプロトコルです
PPPでは接続の確立、ユーザー認証、通信、切断といった段階を踏んだ通信を可能にします。
FTTxやADSLではイーサネットフレームを利用しますが、イーサネットには接続の確立や認証、切断の仕組みがありません
そこでイーサネットのフレーム内にPPPのヘッダーを入れるPPPoE(PPP over Ethernet)を利用して通信します
PPPoE接続を使ってIP通信を行うにはDiscoveryステージとPPPセッションステージの２つのステップを踏む必要があります
PPPoEセッションを確立するまでをDiscoveryステージ、その後のPPPによるやりとりをPPPセッションステージといいます

Discoveryステージ

PPPoEセッションを確立するPPPoEクライアントとPPPoEサーバーのMACアドレスを特定し、PPPoEセッションIDの割当を行います
①PPPoEクライアントからPPPoEサーバーを探索するパケットをブロードキャストします
②PPPoEサーバーからPPPoEクライアントへ確認応答します
③PPPoEクライアントからPPPoEサーバーへセッション開始の要求をします
④PPPoEサーバーが受け入れればセッションIDを通知します(拒否の場合はエラーパケットを送信)

PPPセッションステージ

Discoveryステージで④のセッションIDが通知されるとPPPセッションステージへ移行します
PPPセッションステージによって認証が成功しPPPoEサーバーから適切なIPアドレスが割り当てられるとPPPoE接続は完了となり、IP通信ができるようになります

参考

書籍　スラスラわかるネットワーク&TCP/IPのきほん第２版

3ウェイハンドシェイクについて
https://www.infraexpert.com/study/tcpip9.html
TCP再送制御
https://www.infraexpert.com/study/tcpip10.html
PPPoE
https://www.infraexpert.com/study/wan9.html