Java ネットワークプログラミング (1) ネットワークの基礎 [通信プロトコル HTTP|WebSocket|TCP/IP|UDP]

概要

コンピュータネットワークとは、ネットワークオペレーティングシステム、ネットワーク管理ソフトウェア、およびネットワーク通信プロトコルの管理と調整の下で、リソースの共有と情報を実現するために、地理的に異なる場所にある独立した機能を持つ複数のコンピュータとその外部デバイスを通信回線を通じて接続することを指します。

ネットワークの分類

ローカルエリアネットワーク(LAN)
- ローカルエリアネットワークは、狭いエリアで使用される複数のコンピュータで構成されるネットワークであり、サービス範囲は通常 10 キロメートルに制限され、企業または部門によって確立された小さなエリアに属します。
首都圏ネットワーク (MAN)
- メトロポリタンエリアネットワークは、ワイドエリアネットワークとローカルエリアネットワークの間にあるネットワークです。そのネットワークカバレッジは通常、都市全体に広がります。通信光ファイバの助けを借りて、複数のローカルエリアネットワークが公共都市に接続されます。ネットワークを統合して大規模なネットワークを形成し、ローカルエリアネットワーク内のリソースを共有するだけでなく、LAN 間のリソースも共有することができます。
ワイドエリアネットワーク(WAN)
- 広城ネットワークは長距離通信を伴う長距離ネットワークであり、複数の国、さらには全世界をカバーできます。WAN は地理的距離が長すぎるため、情報の減衰が非常に深刻であり、この種のネットワークでは通常、ルーティングの問題を解決するために、インターフェイス情報処理プロトコルと回線を介して接続され、メッシュ構造を形成する専用の専用線が必要です。

ネットワーク通信プロトコル

コンピュータネットワークで通信を実現するには、通信プロトコルといういくつかの規則が必要です。レート、伝送符号、符号構造、伝送制御ステップ、誤り制御などの規格が含まれます。一般的なネットワーク通信プロトコルには、TCP/IP プロトコル、IPX/SPX プロトコルなどがあります。2 つのノード間の対話を可能にするためには、それらの間で情報交換を可能にする通信ツール (つまり、ポート) を確立する必要があります。

TCP/IP プロトコル: 伝送制御プロトコル/インターネットプロトコル (Transmission Control Protocol/Internet Protocol)。インターネットの最も基本的で広く普及しているプロトコルです。コンピュータをインターネットに接続する方法と、コンピュータ間でデータを転送する方法に関する標準を定義します。内部でデータ通信を処理するための一連のプロトコルが含まれており、4層の階層モデルを採用しており、各層は次の層が提供するプロトコルを呼び出して独自のニーズを満たします。

アプリケーション層: 主に HTTP プロトコル、FTP プロトコルなどのアプリケーションプロトコルを担当します。
トランスポート層: 主にネットワークプログラムの通信を可能にし、ネットワーク経由で通信する場合は、TCP プロトコルまたは UDP プロトコルを使用できます。
ネットワーク層: ネットワーク層は TCP/IP プロトコル全体の中核であり、主に送信データをグループ化し、グループ化されたデータをターゲットコンピュータまたはネットワークに送信するために使用されます。
データリンク層: リンク層は、物理伝送チャネルを定義するために使用されます。通常は、光ファイバーやネットワークケーブルに提供されるドライバーなど、特定のネットワーク接続デバイス用のドライバープロトコルです。

HTTP

概要

HTTP (Hyper Text Transformer Protocol) は通信プロトコルです。HTML や画像ファイルを送信するための TCP/IP 通信プロトコルに基づくアプリケーションプロトコルです。その主な目的は、送信を実現するクライアント (ブラウザ) とサーバーを定義することです。およびさまざまなリソース (HTML ページ、画像、音声、ビデオなど) へのアクセス。

HTTPプロトコルの特性
- リクエストレスポンスモードに基づく
  - HTTP プロトコルはクライアント/サーバーアーキテクチャモデルを採用しており、クライアントはサーバーにリクエストを送信し、サーバーは対応する応答を返します。このモードは、アプリケーションロジックを効果的に分離し、システムの保守性と拡張性を向上させることができます。
- 接続がありません
  - HTTP プロトコルはコネクションレス型プロトコルであり、各リクエストは独立しており、サーバーはリクエストの処理後すぐに接続を閉じます。これによりリソースを節約できますが、接続を再確立する必要がある、同じヘッダー情報を繰り返し送信する必要があるなど、いくつかの欠点も生じます。
- 伝送効率 | 高信頼性
  - ステートレス: データ送信中に履歴やステータス情報が保存されません。
  - トランスポート層プロトコルとして TCP を使用する
- マルチメディア伝送をサポート
  - HTTP プロトコルは、HTML、XML、JSON、画像、音声、ビデオなどのさまざまな種類のデータを送信できます。これにより、HTTP プロトコルは、さまざまな種類のアプリケーションシナリオに適したユニバーサルネットワーク伝送プロトコルになります。
- 優れた互換性
  - B/S、C/Sモードをサポート
不十分なHTTPプロトコル
- HTTP プロトコルはクリアテキストで送信されるため、簡単に盗聴、改ざん、または偽造される可能性があります。
- 要求/応答モデルでは、各要求で新しい TCP 接続を確立する必要があるため、ネットワーク通信のオーバーヘッドが増加します。
- HTTP プロトコルは、基本認証やダイジェスト認証などの単純な ID 認証のみを実行できます。この認証方法は攻撃に対して脆弱であり、十分なセキュリティを提供できません。

HTTPリクエスト応答処理

HTTPメッセージ

リクエストメッセージ

HTTP リクエストメッセージは、リクエスト行、リクエストヘッダー、空行、リクエストデータの4 つの部分で構成されます。

リクエストヘッダー

応答メッセージ

応答メッセージも、ステータス行、メッセージヘッダー、空行、応答本文の 4 つの部分で構成されます。

応答ヘッダー

HTTPバージョン

HTTP1.0

HTTP/1.0 は、通信においてバージョン番号を指定した最初の HTTP プロトコルバージョンであり、現在でもプロキシサーバーで広く使用されています。サーバーは、各クライアントを追跡したり、過去のリクエストを記録したりしません (ステートレス)。このステートレス性により、ID 認証とステータス記録に Cookie/セッションメカニズムを使用できます。同時に、デフォルトで短い接続を使用します。つまり、HTTP1.0 が提供するブラウジングブラウザはサーバーとの短い接続を維持します。ブラウザの各リクエストはサーバーとの TCP 接続を確立する必要があります。サーバーが処理を完了すると、TCP 接続はすぐに切断されます (接続なし)。

不具合は以下の通りです

接続なし: 接続は再利用できず、要求ごとに TCP 接続を再作成する必要があるため、ネットワーク通信のコストが増加します。
行頭ブロック: 1.0 では、前のリクエストに対する応答が到着した後に次のリクエストを送信する必要があると規定しています。それ以外の場合は待機状態でなければなりません。

HTTP1.1

長い接続: HTTP1.1 では Connection フィールドが追加されており、Keep-Alive を設定すると、HTTP 接続を開いたままにし、クライアントとサーバーが要求するたびに TCP 接続の確立、解放、確立を繰り返す必要がなくなり、ネットワークの使用率が向上します。クライアントが HTTP 接続を閉じたい場合は、リクエストヘッダーに Connection: false を含めて、サーバーにリクエストを閉じるように指示できます。
リクエストパイプライン（パイプライン）対応：HTTP1.1ロングコネクションをベースに、リクエストパイプラインが可能です。つまり、前の応答が返されるのを待たずに、同じ TCP 接続上で複数の要求を同時に送信できるため、ネットワーク伝送効率がさらに向上します。

HTTP2.0

多重化: 単一の HTTP/2 接続を通じて複数の要求/応答メッセージを同時に開始できるようにします。
バイナリフレーミング: HTTP/2 は、アプリケーション層 (HTTP/2) とトランスポート層 (TCP または UDP) の間にバイナリフレーミング層を追加します。HTTP/1.x のセマンティクス、メソッド、ステータスコード、URI、ヘッダーフィールドを変更することなく、HTTP1.1 のパフォーマンス制限を解決し、送信パフォーマンスを向上させ、低遅延と高スループットを実現します。

HTTPステータスコード（共通）

200 OK
302 Found は永続的なリダイレクトではなく、一時的なリダイレクトを意味します
401 Unauthorized は、現在のリクエストにユーザーの検証が必要であることを示します。
403 Forbidden は、サーバーがリクエストを理解したが、実行を拒否したことを意味します。
404 Not Found は、リクエストが失敗し、リクエストされたリソースがサーバー上に見つからなかったことを意味します。
500 内部サーバーエラーは、リクエストの処理を完了できないことを意味します。通常はサーバー側の内部エラーです。

HTTPプロトコルのセキュリティ

HTTP プロトコルはクリアテキストで送信されます。つまり、すべてのリクエストと応答はクリアテキストで送信されます。これは、送信中に盗聴、改ざん、または偽造される可能性があることを意味します。HTTP プロトコルのセキュリティ問題を解決するために、HTTPS プロトコルが登場しました。HTTPS プロトコルは、HTTP プロトコルに SSL/TLS プロトコルを追加し、デジタル証明書 (対称暗号化と復号化、非対称暗号化と復号化、デジタル署名などを含む暗号化および認証テクノロジ) を通じてデータセキュリティを確保します。HTTPS プロトコルを使用すると、クライアントとサーバー間のすべての通信が暗号化され、第三者による盗聴や改ざんは不可能になります。さらに、HTTPS は証明書認証もサポートしています。これにより、サーバーの ID を検証し、偽造や中間者攻撃を防ぐことができます。

ウェブソケット

コンセプト

WebSocket プロトコルは、HTTP プロトコルに依存し、TCP プロトコルに基づいたネットワークプロトコルです。ブラウザとサーバー間の全二重通信を実現します。つまり、クライアントがサーバーに情報を送信する一方で、サーバーもクライアントに積極的に情報を送信することができます。

特徴は以下の通りです

双方向通信が可能なリアルタイム通信プロトコル
HTTP プロトコルに基づいて構築されており、ハンドシェイクプロトコルを通じて永続的な接続が確立されます。
バイナリプロトコルを使用してデータをより高速に送信します。
クロスドメイン通信をサポートします。
サーバープッシュデータのサポート

WebSocket プロトコルの理由

WebSocket プロトコルが登場する前は、クライアントとクライアント間の二重通信は HTTP ポーリング (ポーリング技術は一般的にブラウザーの setInerval または setTimeout を使用します)、つまりクライアントがホストに結局のところ、HTTP の本来の目的は双方向通信ではありませんでした)。さらに、HTTP リクエストの送信はクライアントによってのみ開始でき、サーバーからクライアントへの送信は開始できません。クライアントとサーバー間の双方向通信を実現するために、WebSocket プロトコルは長年の開発を経て 2008 年に誕生しました。

動作原理

**HTTP プロトコルと WebSocket プロトコルに基づくクライアントとサーバーのワークフロー**

WebSocket の動作原理は、ハンドシェイク、データ転送、切断の3 つの段階に分けることができます。

握手
- クライアントが WebSocket 接続を開始すると、WebSocket プロトコルは HTTP ハンドシェイク要求プロセスを再利用し、特別な HTTP 要求ヘッダーをサーバーに送信して接続を確立します。サーバーはリクエストヘッダーの特定のフィールドをチェックして WebSocket プロトコルをサポートしていることを確認した後、ハンドシェイク確認のための特別な HTTP レスポンスヘッダーを送信します。ハンドシェイクが成功すると、両者は WebSocket 接続を確立し、その後のデータ送信を実行できるようになります。
データ送信
- WebSocket 接続が正常に確立されると、クライアントとサーバーは接続を通じて双方向のリアルタイムデータ送信を実行できるようになります。双方がメッセージを送受信でき、メッセージはフレームの形式で送信されます。WebSocket プロトコルは、さまざまなタイプのデータを送信するために、テキストフレームやバイナリフレームなどのさまざまなタイプのフレームを定義します。
切断する
- 接続が不要になった場合、クライアントまたはサーバーは接続を閉じるリクエストを開始できます。両当事者は特別なクローズフレームを交換して接続の終了をネゴシエートし、両方の当事者がクローズ要求を確実に受信できるようにします。

WebSocketアプリケーション

WebSocket API (フロントエンドの例)

WebSocket API は、WebSocket プロトコルを使用してメッセージを送受信するための全二重チャネルを確立するインターフェイスです。クライアントとサーバー間の最初のハンドシェイク中に、http プロトコルが WebSocket プロトコルにアップグレードされ、接続が確立されます。基礎となる層は TCP プロトコルです。接続が確立されると、WebSocket インターフェイスを通じてメッセージを繰り返し送信できます。
WebSocket API は純粋にイベント駆動型であり、全二重接続が確立されると、サーバーがデータまたはリソースをクライアントに送信するときに、データとステータス変更の通知を自動的に送信できます。
一般的に使用される WebSocket イベント: onopen、onmessage、onclose など。
一般的に使用される WebSocket メソッド: send() および close()
WebSocket プロパティ：readyState(オープン、接続中、クローズ、クローズド)

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>Websocket</title>
</head>
<body>
<script>
    var socket;
    if (window.WebSocket) {
        socket = new WebSocket("ws://localhost:9999/hello");
        //相当于channelRead0,读取服务器端的消息
        socket.onmessage = function(ev){
            var rt = document.getElementById("responseText");
            rt.value = rt.value + "\n" + ev.data;
        }
        //开启连接
        socket.onopen = function(ev){
            var rt = document.getElementById("responseText");
            rt.value = "开启连接成功！";
        }
        //连接关闭
        socket.onclose = function(ev){
            var rt = document.getElementById("responseText");
            rt.value = rt.value + "\n" + "连接关闭成功！";
        }
    }
    //发送消息给服务器
    function send(msg){
        if(!window.socket){ //是否已创建socket
            return;
        }
        if(socket.readyState == WebSocket.OPEN){
            socket.send(msg);
        }else{
            alert("socket未连接");
        }
    }
</script>
<form onsubmit="return false">
    <textarea name="message" style="height:300px;width:300px"></textarea>
    <input type="button" value="Send" onclick="send(this.form.message.value)">
    <textarea id="responseText" style="height:300px;width:300px"></textarea>
    <input type="button" value="Clear" onclick="document.getElementById('responseText').value=''">
</form>
</body>
</html>

TCP

伝送制御プロトコル (Transmission Control Protocol)、TCP プロトコルはコネクション指向の通信プロトコルであり、データを送信する前に、送信者と受信者が論理的な接続を確立してからデータを送信し、信頼性が高くエラーのないデータを提供します。 2 台のコンピュータ間の送信。TCP 接続では、クライアントとサーバーを明確に定義する必要があります。クライアントはサーバーに接続要求を送信します。各接続の作成には「3 ウェイハンドシェイク」が必要です。TCP クライアントとサーバーが切断されるとき、4回振る

3回の握手

最初のハンドシェイク: クライアントは SYN (SEQ=x) メッセージをサーバーに送信し、SYN_SEND 状態に入ります。(クライアントはサーバーに接続リクエストを送信し、サーバーからの確認を待ちます)
2 回目のハンドシェイク: サーバーは SYN メッセージを受信し、SYN (SEQ=y) ACK (ACK=x+1) メッセージで応答し、SYN_RECV 状態に入ります (サーバーはクライアントに応答を送り返し、クライアントにその旨を通知します)接続要求を受信しました)
3 回目のハンドシェイク: クライアントはサーバーから SYN メッセージを受信し、ACK (ACK=y+1) メッセージで応答し、確立状態に入ります (クライアントは接続を確認するために確認情報をサーバーに再度送信します)。

3 ウェイハンドシェイクが終了し、TCP クライアントとサーバーが正常に接続を確立し、データを送信できるようになります~

4回手を振る

クライアントはコネクションを終了する際に、TCP ヘッダの FIN フラグビットを 1 に設定したメッセージ、つまり FIN メッセージを送信し、FIN_WAIT_1 状態に移行します。
メッセージを受信したサーバーは、クライアントに ACK 応答メッセージを送信し、CLOSED_WAIT 状態に入ります。
サーバーから ACK 応答メッセージを受信した後、クライアントは FIN_WAIT_2 状態に入ります。
サーバーがデータを処理するのを待った後、クライアントに FIN メッセージも送信し、サーバーは LAST_ACK 状態に入ります。
クライアントはサーバーから FIN メッセージを受信した後、ACK 応答メッセージを返し、TIME_WAIT 状態に入ります。
サーバーは ACK 応答メッセージを受信した後、CLOSE 状態に入り、この時点でサーバーは接続のクローズを完了します。
2MSL の時間が経過すると、クライアントは自動的に CLOSE 状態になり、この時点でクライアントは接続の終了も完了します。

上の図からわかるように、各方向に FIN と ACK が必要であるため、通常は 4 つの波と呼ばれます。この点に関する注意: 接続を積極的に閉じた場合にのみ、TIME_WAIT 状態に入ることができます。

UDP

ユーザーデータグラムプロトコル (データグラムは UDP ネットワーク伝送の基本単位です)
UDP はコネクションレス型の通信プロトコルです。つまり、データの送信者と受信者は、データ送信中に論理接続を確立しません。つまり、あるコンピュータが別のコンピュータにデータを送信するとき、送信側はデータを送信する前に受信側が存在するかどうかを確認せず、同様に、受信側がデータを受信するときに、データが存在するかどうかを送信側にフィードバックしません。受け取られました。
UDP プロトコルは、消費リソースが少なく、通信効率が高いため、通常、音声、ビデオ、および通常のデータの送信に使用されます。たとえば、ビデオ会議では、1 つまたは 2 つのデータパケットが送信されても UDP プロトコルが使用されます。まれに紛失することがありますが、破損はありませんが、受信結果に大きな影響を与えます。
ただし、UDP プロトコルを使用してデータを送信する場合、UDP はコネクションレスであるため、データの完全性が保証されないため、重要なデータを送信する場合には UDP プロトコルを使用することはお勧めできません。

IPプロトコル

コンセプト

IP プロトコル (インターネットプロトコル) は、インターネットプロトコルとも呼ばれ、ネットワーク間の相互接続をサポートするデータパケットプロトコルです。このプロトコルはネットワーク層で動作し、その主な目的はネットワークのスケーラビリティを向上させることです。トランスポート層の TCP と比較して、IP プロトコルは TCP に似た、コネクションレス/信頼性の低いベストエフォート型のパケット送信サービスを提供します。プロトコル (伝送制御プロトコル) は一緒になって TCP/IP プロトコルスイートの中核を形成します

分類

IPv4: ネットワークに接続されている各ホストに 32 ビットアドレスを割り当てます。TCP/IP 規制によれば、IP アドレスはバイナリで表され、各 IP アドレスの長さは 32 ビット、つまり 4 バイトです。使いやすさを考慮して、IP アドレスは「192.168.1.66」のようなドット付き 10 進表記を使用します。
IPv6: インターネットの急速な発展により、IP アドレスの需要が増加しています。アドレス空間を拡大するために、 IPv6 によるアドレスの定義には128 ビットのアドレス長が使用され、ネットワークアドレスリソースの不足の問題が解決されます。

常用命令：
① ipconfig：查看本机 IP 地址(Linux下对应ifconfig)
② ping IP 地址：检查网络是否连通。

他の

WebSocketとHTTPプロトコルの違い

同じ点

どちらも、クライアントとサーバーの間でデータを送信するために使用されるアプリケーション層プロトコルです。

違い

接続を確立するにはさまざまな方法があります
- HTTP では、リクエストごとに接続を再確立する必要があります。Web ページがサーバーにリクエストを継続的に送信する必要がある場合、リクエストごとに接続を再確立する必要があるため、接続のオーバーヘッドとネットワーク遅延が発生します。
- WebSocketでは、クライアントとサーバー間で一度接続を確立するだけで、その後は接続を維持して双方向通信が可能です。
データ通信方式が異なる
- HTTP では、データは要求応答モデルを通じて送信されます。クライアントがリクエストを送信 -> サーバーがレスポンスを返すこのプロセスにおけるクライアントとサーバー間の通信はテキストを介して行われます。
- WebSocket では、クライアントとサーバー間の通信はバイナリ形式で行われます。これは、WebSocket がデータをより高速に転送し、より複雑なデータ型を処理できることを意味します。
サポートされているデータ型が異なります
- HTTP では、サポートされるデータ型が制限されています。通常、テキスト、画像、オーディオなどの静的データ型のみがサポートされます。
- WebSocket では、データ送信がバイナリ形式であるため、ビデオストリームやリアルタイムゲームデータなど、より複雑なデータタイプをサポートできます。
セキュリティが違う
- HTTP ではデータが平文で送信されるため、盗まれたり改ざんされたりする可能性があります。この問題を解決するために HTTPS が導入されました
- WebSocket では、データはバイナリ形式で送信されるため、より安全であり、簡単に盗まれたり改ざんされたりすることはありません。
異なるリアルタイム
- HTTP の要求応答モデルにより、クライアントはサーバーから応答を受信した後にのみデータを更新できます。つまり、リアルタイム要件が高いアプリケーションでは、HTTP では要件を満たすことができない可能性があります。
- WebSocket はリアルタイムの双方向通信を実現できるため、リアルタイム性の要件が高いアプリケーションに適しています。