コンピュータネットワーク（TCP / UDP）

UDP

プロトコルの学習は、多くの場合、メッセージ形式の研究です。

UDPプロトコル側の形式

データグラム全体（UDPヘッダー+ UDPデータ）の最大長を示す16ビットUDP長。
チェックサムが間違っている場合は直接破棄されます。
送信元ポート番号：送信者
ポート番号宛先ポート番号：受信者ポート番号
UDP長さ： UDPヘッダー全体の長さとデータ
チェックサムの長さの合計：送信中にUDPデータパケットにエラーがあるかどうかを検出し、エラーを破棄します。

ここでUDPのポートを4バイトのようなものに変更できますか？

変更できません...
メッセージの長さは2バイトで、UDPは最大65535=>64kです。

UDP機能

1.无连接:知道对端的IP和端口号就直接进行传输，不需要建立连接.
2.不可靠:没有任何安全机制，发送端发送数据报以后，如果因为网络故障该段无法发到对方，UDP协议层也不会给应用层返回任何错误信息.
3.面向数据报:应用层交给UDP多长的报文，UDP原样发送，既不会拆分，也不会合并.
4.缓冲区:UDP只有接收缓冲区，没有发送缓冲区.
5.全双工:UDP的socket既能读，也能写.
6.大小受限:UDP协议首部中有一个16位的最大长度。也就是说一个UDP能传输的数据最大长度是64K（包含UDP首部）.

TCP

TCPプロトコル側の形式

送信元ポート番号：送信者ポート番号

宛先ポート番号：受信者ポート番号

シリアル番号：送信されるデータの場所データが送信されるたびに、データバイトのサイズが累積されます。

確認シーケンス番号：次回受信するデータのシーケンス番号。

ヘッダーの長さ： TCPヘッダーの32ビットビット（4バイトの数）の数を示します。したがって、TCPヘッダーの最大長は15 * 4=60です。

予約済み：将来の拡張のために、その長さは4ビットです。通常は0に設定されます。このフィールドで受信したパケットが0でなくても、破棄されません。

これらの6つのフラグビットは、TCPメッセージのコアフィールドです
。URG：1の場合、緊急に処理する必要があるパケット内のデータを示します。ACKの場合
：1の場合、確認応答のフィールドが有効になります。
.PSH：1の場合、受信データはすぐに上位層のアプリケーションプロトコルに送信されます。0の場合、すぐに送信する必要はありませんが、
RSTが最初にキャッシュされます。 1は、TCPとの接続に異常があり、接続を強制的に切断し、セグメント
SYNをリセットする必要があることを意味します。1の場合、接続を確立したいことを意味します。SYNフラグは同期セグメント
FINと呼ばれます：1の場合、送信するデータがなくなることを意味し、接続が切断されることが望まれます。FINフラグは終了セグメントです。

ウィンドウサイズ：同じTCPヘッダー内の確認応答番号が指す位置から受信できるデータのサイズ（8ビットバイト）を通知します。

チェックサム：目的は、送信者と受信者の間のTCPヘッダーとデータの変更を検出することです。受信者がチェックサムエラーを検出した場合、TCPセグメントは単に破棄されます。

緊急ポインタ： URG制御ビットが1の場合に有効（ある場合とない場合、1つ以上ある場合があります）

TCP機能

1.有连接
2.可靠
3.面向字节流
4.缓冲区:TCP有接收缓冲区，有发送缓冲区.
5.全双工
6.大小不受限

応答を確認する

信頼性の高い送信を確保するためのコアメカニズム送信者がデータを送信した後、相手がデータを受信したかどうかを知ることができます。
重要なのは、受信者がメッセージを受信した後、確認メッセージ（ACK、ackknowledge）を送信者に返すことです。
例：
クラスメートがクラスメートBにメッセージを送信します。

タイムアウト再送信

これは、確認応答を補足することと同じです。確認応答は、ネットワークが正常な場合であり、送信者はACKを介して受信したことを通知されます。パケット損失がある場合は、タイムアウト再送信メカニズムが役割を果たします。
这主要是发送端没发送成功,还有接收端没应答成功,都会触发重传....

通常の状況では、2つの連続したパケット損失の確率はまだ非常に低いです。パケット損失の確率を10％とすると、2つの連続した回数は10％* 10％=> 1％です。再送信が常に失敗する場合は、これは、ネットワークが現時点で深刻な問題に遭遇した可能性があり、あきらめる（TCP接続を自動的に切断する）ことしかできないことを意味します。

接続管理

これは、TCPが信頼性を確保するためのメカニズムでもあります...
1）接続を確立する方法：
三次握手:

3ウェイハンドシェイクの用途は何ですか？それは信頼性と何の関係がありますか？

3ウェイハンドシェイクは、「道を尋ねる石を投げる」に相当します。現在のネットワークの状況が信頼できる伝送の基本条件を満たしているかどうかを確認します。現時点でネットワークが非常に貧弱な場合、TCP伝送を強制することも多くのことを伴います。パケット損失具体的には、3ウェイハンドシェイクは、電話をかけるのと同じように、送信能力と受信能力が正常であるかどうか、通信の両側を実際にテストしていると見なすことができます。側：「ねえ、ねえ、聞こえますか？」、反対側は「はい。聞こえます、聞こえますか？」と答え、「聞こえます」と答えました。現時点では、これらの4つのステップを判断できます。使いやすく、信頼性の高い送信の前提条件が満たされていることを意味します... 3つのハンドシェイクが発生し、通信の両方の当事者がそれぞれの送受信機能に問題がないことを確認してから、後続の送信を実行できます。

2）切断する方法：

四次挥手:

スライドウィンドウ

スライディングウィンドウの存在の重要性は、信頼性を確保することを前提として、伝送効率を可能な限り向上させることです!!!

ここで、操作を実行するたびにACKを待つ必要があり、ACKに多くの時間が費やされていることがわかります。

このように、一度に4セットのデータを送信しましたが、この4セットのデータを送信する過程で、4セットすべてのデータが送信されるまで待たずに、団結して待ちました...

如果一次批量发送数据N,统一等待一波,此时这里N称为"窗口大小"

"滑动"的意思,并不用把N组数据的ACK都等到,才能继续往下发送,而是收到一个ACK,就继续往下发送一组,当前这图里发了四组,只要1001到了,就可以发送(4001 ~ 5000)这组数据了,依次发送

当然,如果在这里发生了丢包该如何重传?

この場合のACKが失われた場合はどうなりますか？

没事,不必要处理!!!,在发送4001之前,发现只收到了2001,1001没收到.
他2001表示:2001之前的数据都已确认收到,只需要保证最后一个ACK收到了,前面的都是收到了的

この状況では、再送信がトリガーされます。

由于1001 ~ 2000 这个数据丢了,然后B就会反复的索要1001这个数据,即使A给B已经往后发了,这时B任然在索要1001,当若干次后,A就发现了,就触发了重传,
A重传1001 ~ 2000后,2001 ~ 7000这些数据都是已经传过的,这些就没必要重传了,接下来B 就向 A 索要 7001 开始的数据..

フロー制御

フロー制御はスライディングウィンドウの拡張であり、信頼性を確保することを目的としています。スライディングウィンドウでは、ウィンドウが大きいほど伝送速度が高くなります。これには、送信者だけでなく受信者も考慮する必要があります。送信者の場合泥棒を高速で送信すると、受信者はそれをまったく処理できなくなり、受信者は新しく受信したパケットを失い、送信者は再送信するため、送信者のライトマップは高速ではありません。

フロー制御の鍵は、レシーバーのレートを測定することです。ここでは、レシーバーの受信バッファーの残りのスペースを直接使用して、現在の処理能力を測定します。

接收方通过ACK报文来告知发送方剩余空间多大
16ビットのウィンドウサイズは、現在の受信者の残りのスペースを測定するために使用されます。送信者がこのデータを受信した後、送信速度を柔軟に調整します（ウィンドウサイズを調整します）（実際には16ビットと言いましたが、ウィンドウのサイズは64kを超え、大きくなる可能性があります）

輻輳制御

これもスライディングウィンドウの拡張であり、スライディングウィンドウの速度も制限します。
輻輳制御は、送信側と受信側の間、およびこのリンク間の輻輳（処理能力）を測定します。

遅延応答

これは、フロー制御の延長に相当します。フロー制御は、ブレーキを踏んで、速すぎず、応答を遅らせることです。これと同じように、ウィンドウをできるだけ大きくすることができます。

これは、同時に水を注ぐようなものです。波を注入するたびに、現在のプールにどれだけのスペースが残っているかを尋ねられます。対策は、すぐに答えるのではなく、後で答えることです。 、後で答えると、この時間の間に、より多くの水が生成されます。すぐに答えると、残りの30トンを注入できますが、少し遅れて答えると、残りの注入量は40トンになります（10トン）。転送速度が少し上がった可能性があります

ピギーバック

これは、遅延応答の拡張です。

バイトストリーム指向（スティッキーパケットの問題）

これは、TCPのスティッキーパケットの問題だけでなく、ファイルの読み取りなどの他のバイトストリーム指向のメカニズムでも
あります。TCPスティッキーパケットのスティッキーの問題は、アプリケーション層のデータグラムです。TCP受信バッファでは、いくつかのアプリケーション層のデータバッグが混ざっていて、誰が誰なのかわからない…

TCPの例外処理

1）プロセスが終了しました

プロセスの準備ができていない場合、プロセスは突然終了します。この時点でのプロセスのTCP接続は何ですか？==>TCP接続はSocketを介して確立されます。Socketは基本的にプロセスによって開かれたファイルです。ファイルは実際にはItです。プロセスのPCBに存在するファイル記述子テーブルです。ファイル（ソケットを含む）が開かれるたびに、アイテムがファイル記述子テーブルに追加されます。ファイルが閉じられるたびに、ファイル記述子テーブルから削除されます。 。1行、プロセスを直接強制終了すると、PCBがなくなり、その中のファイル記述子テーブルもなくなります。ここでのファイルは「自動的に閉じられる」と同等です。このプロセスは、実際にはソケットの呼び出しと同じです。 close（）を手動で実行します。ウェーブを4回トリガーします〜）

2）マシンの電源がオフになっている

通常のプロセスに従ってシャットダウンすると、オペレーティングシステムはすべてのプロセスを強制終了し、プロセスの終了と同じように再度シャットダウンします。

3）マシンの電源がオフになっている/ネットワークケーブルが切断されている

デスクトップコンピュータと同じように、電源を直接抜くと、オペレーティングシステムには応答時間がなく、処理手段もありません。

面接の質問

UDPプロトコルに基づいて信頼性の高い伝送を実現するにはどうすればよいですか？

この質問は、実際にはTCPのテストです。これは、基本的に、アプリケーション層でUDPに基づいてTCPを複製するメカニズムです。

    实现确认应答机制. 每个数据收到之后,都要反馈一个ACK(应用程序自己定义一个 ack包)
    实现序号/确认序号,以及实现去重
    实现超时重传.
    实现连接管理
    要想提高效率,实现滑动窗口
    为了限制滑动窗口,实现流量控制/拥塞控制
    实现延时应答,捎带应答,心跳机制…

TCPの使用に適したシナリオの種類とUDPの使用に適したシナリオの種類

1:啥时候使用TCP? =>对可靠性有一定要求,(日常开发中的大多数情况,都基于TCP)
2:如果传输的单个数据报比较长(超过 64k) -> 首选 TCP
3:啥时候使用UDP? =>对可靠性要求不高,对于效率的要求更高(机房内部的主机之间通信,分布式系统中,广播就是首选UDP)