day35ネットワーク通信

今日のコンテンツ:
トランスポート層tcp \ udp
アプリケーション層:
プロトコルをカスタマイズできます= "ヘッダー+データ部分
http https ftp


5層プロトコル
コンピューター1:コンピューター2:

アプリケーション層

ソケットソケット

トランスポート層セグメントトランスポート層
ネットワーク層パケットネットワーク層
データリンク層フレームデータリンク層
物理層<===========インタラクティブマシン===========>物理層


クライアントソフトウェア送信サーバーソフトウェアrecv
オペレーティングシステムオペレーティングシステム
コンピューターハードウェア<====物理メディア=====>コンピューターハードウェア

 

イーサネットヘッダー+ ipヘッダー+ tcpヘッダー+アプリケーションレイヤーヘッダー+アプリケーションレイヤーデータ

#一:トランスポートレイヤーtcp \ udp =》ポート
ポート範囲0-65535に基づいて、0-1023はシステムによって占有されています
ip +ポート=》世界のネットワーク通信に基づいた固有のアプリケーションを識別します


TCPプロトコルに基づく通信の前:双方向通信のリンクを確立する必要があります
C --------------------> S
C <------------ -------- S

リンクを確立するための3ウェイハンドシェイク:リンクの
確立は、データ送信の準備、3ウェイハンドシェイクです。

リンクを切断するために4つの手を振るリンクを切断する場合
、リンクでのデータ送信のために4つの切断が必要です。

tcpは信頼性の高い伝送です。
データの送信は、相手が確認した後に完了する必要がありますその後、自身のメモリ内のデータがクリアされます。

ps:サーバーがTIME_WAIT状態の場合、サーバーで高い並行性が発生していることを意味します


TCP半接続プール:
バックログ
[リンク要求1、リンク要求2、リンク要求3、リンク要求5]

#2:アプリケーション層:
プロトコルをカスタマイズできます= "ヘッダー+データパーツ
カスタムプロトコルで注意する必要がある問題:
1. 2つの主要コンポーネント=ヘッド+データパーツ
ヘッダー:次の
ようなデータの説明情報を入力します:誰に、データのタイプ、データの長さ
、データ部分:送信したいデータ

2.
受信側はヘッダーを介して受信データの詳細情報を取得する必要があるため、ヘッダーの長さを固定する必要があります
http https ftp


ネットワーク通信-トランスポート層
トランスポート層機能:ポート間通信の確立
補足:ポート範囲0-65535、そのうち0-1023はシステムが占有するポートであり、カスタマイズ時に0-1023の範囲で
tcpプロトコルを使用することは推奨されません
信頼性の高い伝送(オープン双方向チャネル伝送)、TCPデータパケットには長さの制限がなく、理論的には無限に長くすることができますが、ネットワークの効率を確保するために、通常、TCPデータパケットの長さはIPデータパケットの長さを超えず、単一のTCPデータパケットを保証しますこれ以上分割する必要はありません。
udpプロトコルは
信頼できる伝送ではありません(相手が受信できるかどうかに関係なく、伝送のみを担当します)。「ヘッダー」部分の合計は8バイトのみで、全長は65,535バイトを超えません。IPデータパケットを置くだけです。
tcpメッセージ

tcp 3ウェイハンドシェイクと4つのウェーブされたハンド(SYN = 1 ACK = 1)
3ウェイハンドシェイク
'' '
3ウェイハンドシェイクは、クライアントとサーバー間の双方向パスを確立するために必要です。
1.クライアントはSYNメッセージをサーバーに送信し、接続の確立を要求します。このとき、クライアントはSYN_SENT状態です
。2。サーバーは、クライアントのSYNメッセージを確認して受信した後、クライアントにACKを返し、クライアントに対しても
開始します。接続要求SYNパケットを確立し、サーバは状態SYN_RCVDます
3は、クライアントは、サーバがサーバ応答をクライアントに戻した後の状態を表現ESTABLASHEDなる受け取る
受信した後に、サービス側チャネルが正常に確立されます
サーバーからリクエストメッセージが送信された後、確認のためにACKもサーバーに返されます。サーバーがクライアントから返されたACKを受信すると、それはESTABLASHEDになります。
最後に、サーバーからクライアントへの送信チャネルが確立されます。サーバーとの双方向チャネルの確立が完了し
ましたこれは、3ウェイハンドシェイクです。
'' '

#なぜ2番目のハンドシェイクにできないのですか?(要するに、2番目のハンドシェイクはリソースの浪費になります)
'' '
双方向ハンドシェイクシナリオの場合:
クライアントは、接続確立要求を送信した後に待機状態に入り、サーバーが確認した後に確立状態に入ります。
サーバーは、確認接続確立要求メッセージを送信した後も(クライアントが応答するかどうかに関係なく)確立状態に入ります。
これは、AがBに電話するようなものです。A:聞こえますか?B:聞こえますが、AもBも相手は自分の声が聞こえると思います。
しかし、Bさんのマイが悪いという状況もあり、AさんはBさんのスピーチがまったく聞こえないので、AさんはBさんからの返事をもらえませんが、BさんはAさんに聞いてもらえると思い、Aさんの
発言を待っていました。 ..これにより、Bは肉体的にも精神的にも疲れ果てます。

スリーウェイハンドシェイク:
クライアントは、接続確立要求メッセージを送信した後、待機状態に入り、サーバー
が接続の確立を確認する通知を返すのを待ちます待機状態では、
クライアントはサーバーから送信された確認要求メッセージと接続確立要求メッセージをサーバーから受信します。確立状態に入り、
接続確認要求メッセージをサーバーに送信します。サーバーはクライアントから接続確立確認メッセージを受信し、確立された状態になります
A:聞こえますか?B:聞こえますが、聞こえますか?
A:あなたの声も聞こえます。(確立済み)B:(確立済み)AとBの両方が、相手が確実に自分自身を聞くことができることを明確に知ることができる

もちろん、4ウェイハンドシェイクまたはn-ウェイハンドシェイクがあってもよいが、接続を確立するための時間が長すぎるので、必ずしも、その効果も大幅に低減されるわけではありません
「」 '


SYNフラッド攻撃
「」 '
SYNフラッド攻撃:TCP契約は限り、サーバーが受信するサーバにリクエストを送信しても、クライアントを確立しようとして、良い男、どのようなクライアントに関係なくある
そして。SYNフラッド攻撃は、多数の仮想IPを使用してリクエストをサーバーに送信し、送信後に消えます。現時点では、サーバーは多数の
仮想IP 満たされ、「SYN_RCVD」の状態になっているため、実際のクライアントはサーバーにアクセスする方法はありません
(乞食のグループが会社のドアをふさぐのと同じで、会社の従業員が会社に入ることを防ぎます)
'' '

4つの手を振る
#リンクを切断するとき、リンクでのデータ送信のために4つの切断が必要です


ネットワーク通信- アプリケーションレイヤーでの
カスタムプロトコル
アプリケーションレイヤーで他の人のプロトコルが複雑すぎると思われる場合は、プロトコルをカスタマイズできます= "ヘッダー+データパーツ
#カスタムプロトコルは注意する必要があります:"
''
1、2つの主要コンポーネントパーツ=ヘッダー+データパーツ
ヘッダー:データの説明情報を入力し
ます。例:データの送信先、データのタイプ、データの長さ
。データパーツ:送信するデータ

2.
受信側はヘッダーを介して受信した受信データの詳細情報を取得する必要があるため、ヘッダーの長さを固定する必要があります
''

#アプリケーション層プロトコル:http https ftp

おすすめ

転載: www.cnblogs.com/python--wang/p/12722750.html