TCPステータスコード
ここではインターネットから得た 3 つの説明方法を使用します。
方法1
Closed: アクティブまたは進行中の接続はありません
listen: サーバーは着信呼び出しを待機しています
syn_recv: 接続要求が到着し、確認を待っています
syn_sent: アプリケーションが開始され、接続がオープンされています
確立: 通常のデータ転送ステータス
fin_wait1: アプリケーション完了したと言っています
fin_wait2 : 相手側がリリースに同意しました
itmed_wait : すべてのパケットが死ぬのを待ちます
close : 双方が同時にクローズしようとします
time_wait : 相手側がリリースを初期化しました
last_ack : すべてのパケットが死ぬのを待ちます
方法 2
close : 開始点、つまり初期状態;
listen : 受動的にオープンされ、サーバー側の状態が listen 状態 (監視) に変更されます;
syn-recvd (同期受信): サーバー側が syn を受信した後、ステータスはsyn、および syn+ack を送信します。syn
-sent (同期が送信された): アプリケーションが syn を送信した後、ステータスは syn-sent になります。
確立された(確立された接続): syn-recvd が ack を受信した後、ステータスが確立され、syn -sent は syn+ack を受信し、 ack を送信し、ステータスが確立されます。
close_wait (クローズ待機): fin を受信した後、サーバーは ack を送信し、ステータスは close_wait に変わります。この時点でサーバーにまだ送信するデータがある場合、このとき、サーバーは fin を送信し、ステータスは last-ack;
fin-wait-1 : アプリケーションは fin を送信し、TCP 接続の切断準備をし、ステータスが変わります確立から fin-wait-1 に変更;
fin-wait-2 : アプリケーション クライアントはサーバーから ack 信号のみを受信し、fin 信号を受信しませんでした。これは、サーバーにまだ送信するデータがあることを示しているため、セミ-connection at this time;
time_wait : この状態に入るには 2 つの方法があります。
- 1. fin-wait-1 から入力すると、アプリケーション ポートは fin+ack を受信し、ack をサーバー ポートに送信します。
- 2. fin-wait-2 が入ります この時点で、アプリケーション ポートは fin を受信し、サーバーに ack を送信します。
time-waitは TCP 全二重接続の信頼性を実現するために使用され、失われた可能性のある ack メッセージを再送信するために使用されます。2 msl 継続する必要があります。アプリケーション ポートが time_wait を入力してから 2 msl 以内に fin を受信しない場合は、 、アプリケーションによって送信された最後の ack が受信されたことを示します。
方法 3
Closed : 初期状態。TCP 接続が「閉じられている」または「開かれていない」ことを示します。
listen : サーバー上のソケットが listen 状態にあり、クライアントからの接続を受け入れることができることを示します。
syn_rcvd : サーバーが接続を要求するクライアントから syn メッセージを受信したことを示します。通常の状況では、この状態は、サーバー側ソケットが TCP 接続を確立するときの 3 ウェイ ハンドシェイク セッション中の中間状態であり、非常に短期間です。基本的に、監視しない限り、netstat を使用してこの状態を確認することは困難です。プログラムはスリーウェイ ハンドシェイクを変更するために意図的に書かれているため、TCP ハンドシェイク中の最後の ack メッセージは送信されません。TCP 接続がこの状態にある場合、クライアントから ACK メッセージを受信した後、確立状態になります。
syn_sent : この状態は syn_rcvd 状態をエコーします。クライアント ソケットが connect() を実行して接続すると、最初に syn メッセージが送信され、次に syn_sent 状態に入り、サーバーが 3 ウェイ ハンドシェイクで 2 番目のメッセージを送信するのを待ちます。 。syn_sent ステータスは、クライアントが syn メッセージを送信したことを示します。
確立: TCP 接続が正常に確立されたことを示します。
fin_wait_1 : この状態については注意して説明する必要がありますが、実際には、fin_wait_1 と fin_wait_2 の両方の状態の本当の意味は、相手の fin メッセージを待つことです。これら 2 つの状態の違いは次のとおりです: fin_wait_1 状態は、実際には、ソケットが確立された状態にあるときに、接続を積極的に閉じて相手に fin メッセージを送信することを意味します。このとき、ソケットは fin_wait_1 状態に入ります。 。相手が ack メッセージで応答すると、fin_wait_2 状態になります。もちろん、実際の通常の状況では、相手がどのような状況であっても、すぐに ack メッセージに応答する必要があるため、fin_wait_1 ステータスは一般に確認するのが困難ですが、fin_wait_2 ステータスは netstat を使用して確認できる場合もあります。
fin_wait_2 : この状態の起源は上で説明しましたが、実際、 fin_wait_2 状態のソケットは半接続を表しており、一方の当事者が close() を呼び出し、積極的に接続を閉じるように要求しています。注: fin_wait_2 にはタイムアウトがありません (time_wait 状態とは異なります)。この状態では、相手がクローズしない (4 つのウェーブ プロセスを完了するために協力しない) 場合、この fin_wait_2 状態はシステムが再起動するまで残ります。 fin_wait_2 状態がさらに多くなり、カーネル クラッシュが発生します。
time_wait : 相手のfinメッセージを受信し、ackメッセージを送信したことを示します。time_wait 状態の TCP 接続は、2*msl (最大セグメント存続期間、最大セグメント存続期間、インターネット上での TCP メッセージの最長存続時間を指します。特定の各 TCP プロトコル実装では、特定の MSL 値、rfc を選択する必要があります) の間待機します。 1122 では 2 分が推奨されていますが、従来の BSD 実装では 30 秒が使用されます。Linux は cat /proc/sys/net/ipv4/tcp_fin_timeout) によってこのマシンのこの値を確認し、閉じられた使用可能な状態に戻ることができます。fin_wait_1 状態で、相手が fin フラグと ack フラグの両方を持つメッセージを受信した場合、fin_wait_2 状態を経由せずに直接 time_wait 状態に移行することができます。(この状況は4つの手を振ると3つの手を振る状況になるはずです)
終了: この状態は実際の状況ではまれであり、比較的まれな例外状態です。通常の状況では、一方の当事者が fin メッセージを送信する場合、まず相手方の ack メッセージを受信 (または同時に受信) し、次に相手方の fin メッセージを受信するのが当然です。ただし、クローズ ステータスは、一方が fin メッセージを送信した後、他方の ack メッセージを受信せず、代わりに他方の fin メッセージを受信したことを意味します。どのような状況でこのようなことが起こるでしょうか? つまり、両方の当事者がほぼ同時にソケットを close() すると、両方の当事者が同時に fin メッセージを送信することになり、この場合、両方の当事者がソケット接続を閉じていることを示すクローズ状態が表示されます。
close_wait : クローズ待ちであることを示します。どのように理解すればよいでしょうか？相手がソケットをクローズ () し、自分自身に fin メッセージを送信すると、システムは間違いなく相手に ack メッセージで応答することになり、このとき、tcp 接続は close_wait 状態になります。次に、相手に送信するデータがまだあるかどうかを確認する必要があります。ない場合は、ソケットを close() して、相手に fin メッセージを送信します。つまり、相手との接続を閉じます。データが存在する場合、プログラムのポリシーに応じて送信または破棄が続行されます。簡単に言えば、close_wait 状態にあるときに行う必要があるのは、接続が閉じるまで待つことです。
last_ack : 受動的に閉じられた側が fin メッセージを送信した後、相手の ack メッセージを待つとき、last_ack 状態になります。相手から ack メッセージを受信した後、クローズおよび使用可能な状態に入ることができます。
ビット コードは TCP フラグであり、マーキングには次の 6 種類があります。
ACK（送達確認）
PSH（プッシュ送信）
FIN（終了）
RST（リセット）
URG（緊急）
SYN（同期コネクション確立）
Sequence Number（シーケンス番号）
Acknowledge Number（確認番号）
TCP 接続と切断の全体プロセスの図は次のとおりです。
TCP 状態移行プロセス:
客端：
CLOSED->SYN_SENT->ESTABLISHED->FIN_WAIT_1->FIN_WAIT_2->TIME_WAIT->CLOSED
服务端
CLOSED->LISTEN->SYN_RECEIVED->ESTABLISHED->CLOSE_WAIT->LAST_ACK->CLOSE
[TCP/IP] 一般的な HTTP ステータス コード
1XX 情報ステータス コード 受け入れられたリクエストは処理中です
2XX 成功ステータス コード リクエストの処理が完了しました
3XX リダイレクト ステータス コード リクエストを完了するには追加のアクションが必要です
4XX クライアント エラー ステータス コード サーバーはリクエストを処理できませんでした
5XX サーバー エラー ステータス コード サーバーには、リクエストの処理中にエラーが発生しました
14 の一般的な HTTP ステータス コード
1 200 OK
一切正常，对GET和POST请求的应答文档跟在后面
2 204 No Content
没有新文档，浏览器应该继续显示原来的文档。如果用户定期地刷新页面，而Servlet可以确定用户文档足够新
3 206 Partial Content
客户端发送了一个带有Range头的GET请求，服务器完成了它
4 301 Moved Permanently
客户请求的文档在其他地方，新的URL在Location头中给出，浏览器应该自动地访问新的URL。
5 302 Found
类似于301，但新的URL应该被视为临时性的替代，而不是永久性的。
6 303 See Other
类似于301/302，不同之处在于，如果原来的请求是POST，Location头指定的重定向目标文档应该通过GET提取
7 304 Not Modified
客户端有缓冲的文档并发出了一个条件性的请求（一般是提供If-Modified-Since头表示客户只想比指定日期更新的文档）。服务器告诉客户，原来缓冲的文档还可以继续使用。
8 307 Temporary Redirect
和302（Found）相同。许多浏览器会错误地响应302应答进行重定向，即使原来的请求是 POST，即使它实际上只能在POST请求的应答是303时才能重定向。由于这个原因，HTTP 1.1新增了307，以便更加清楚地区分几个状态代码： 当出现303应答时，浏览器可以跟随重定向的GET和POST请求；如果是307应答，则浏览器只能跟随对GET请求的重定向。
9 401 Unauthorized
客户试图未经授权访问受密码保护的页面。应答中会包含一个WWW-Authenticate头，浏览器据此显示用户名字/密码对话框，然后在填写合适的Authorization头后再次发出请求。
10 403 Forbidden
资源不可用。
11 404 Not Found
无法找到指定位置的资源
12 406 Not Acceptable
指定的资源已经找到，但它的MIME类型和客户在Accpet头中所指定的不兼容
13 500 Internal Server Error
服务器遇到了意料不到的情况，不能完成客户的请求
14 503 Service Unavailable
服务器由于维护或者负载过重未能应答。例如，Servlet可能在数据库连接池已满的情况下返回503。服务器返回503时可以提供一个Retry-After头