知識マップ: TCP再送で産業用カメラ通信が止まる原因と切り分け

記事「TCP再送で産業用カメラ通信が止まる原因と切り分け」の主張を、概念と関係(エッジ)に分解した知識グラフの全体です。各関係には根拠・確認日・確度が付いています。

産業用カメラ制御アプリで、まれに数秒だけ通信が止まる原因を切り分けた記事である。原因はアプリの停止ではなく、パケットロスによってACKが返らず、TCPが再送タイマ(RTO)の満了を待つ再送待ちだった。RTOは初期値1秒を基準に失敗のたびに倍化するため、条件が悪いと数秒単位の停止に見える。TCPタイムスタンプオプション(RFC1323/RFC7323)を有効にすると、Karnのアルゴリズムが禁じる再送セグメントからのRTT測定という制約を外し、RTOが過度に保守的なまま残る時間を抑えられたが、パケットロス自体を消す仕組みではない。Wiresharkでの再送と待ち時間の確認、SYN/SYN-ACKでのTSopt交渉確認が切り分けの基本になる。

flowchart LR
    accTitle: TCP再送とRFC1323タイムスタンプの知識マップ
    accDescr: パケットロスがTCP再送とRTO待ちを引き起こし数秒間の通信停止に見えること、TCPタイムスタンプオプションがKarnのアルゴリズムの制約を外して再送時のRTT測定の曖昧さを軽減すること、Wiresharkでの確認手順との関係を示す図
    tcp_retransmission["TCP再送(TCP Retransmission)"]
    tcp_rto["RTO(再送タイマ)"]
    tcp_timestamps_option["TCPタイムスタンプオプション"]
    packet_loss["パケットロス"]
    tcp_rtt["RTT(往復時間)"]
    intermittent_communication_stall["断続的な数秒間の通信停止"]
    wireshark["Wireshark"]
    rttm["RTTM(往復時間測定)"]
    paws["PAWS(シーケンス番号一周対策)"]
    karn_algorithm["Karnのアルゴリズム"]
    retransmission_rtt_ambiguity["再送時のRTT測定の曖昧さ"]
    fast_retransmit["fast retransmit(高速再送)"]
    duplicate_ack["Duplicate ACK(重複ACK)"]
    tcp_handshake["TCPの3-way handshake"]
    windows_tcp_timestamp_setting["WindowsのTCPタイムスタンプ設定"]
    packet_loss -->|"原因になり得る"| tcp_retransmission
    tcp_retransmission -.->|"前提とする"| tcp_rto
    tcp_rto -->|"利用する"| tcp_rtt
    tcp_retransmission -->|"原因になり得る"| intermittent_communication_stall
    intermittent_communication_stall -->|"で確認できる"| wireshark
    tcp_retransmission -->|"で確認できる"| wireshark
    packet_loss -->|"で確認できる"| wireshark
    tcp_timestamps_option -->|"利用する"| rttm
    tcp_timestamps_option -->|"利用する"| paws
    karn_algorithm -->|"軽減する"| retransmission_rtt_ambiguity
    tcp_timestamps_option -->|"軽減する"| retransmission_rtt_ambiguity
    tcp_timestamps_option -.->|"軽減する"| intermittent_communication_stall
    fast_retransmit -.->|"防止する"| tcp_rto
    fast_retransmit -->|"前提とする"| duplicate_ack
    packet_loss -->|"原因になり得る"| duplicate_ack
    tcp_timestamps_option -->|"前提とする"| tcp_handshake
    tcp_timestamps_option -.->|"で構成できる"| windows_tcp_timestamp_setting
    windows_tcp_timestamp_setting -->|"で確認できる"| wireshark
    tcp_rto -->|"利用する"| karn_algorithm

概念間の関係(全19件)

図と同じ関係を文章でも列挙します。表示している文と機械可読な意味データ(RDFa)は同じ要素に載っています。確度が「確立した関係」のものは直接の関係として、「条件付きの関係」のものは成立条件つきの言明(rdf:Statement)として表現しています。

• パケットロスはTCP再送(TCP Retransmission)の原因になることがあります。途中でパケットが失われるとACKが返らず、送信側はRTOの満了後に再送する / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• TCP再送(TCP Retransmission)はRTO(再送タイマ)を前提とします。ACKが来ない場合、送信側は再送タイマ(RTO)の満了を待ってから再送する(ただしDuplicate ACKが十分にたまればRTOの満了を待たずfast retransmitで再送されることもあり、TCP再送のすべてがRTO満了を前提とするわけではない) / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
• RTO(再送タイマ)はRTT(往復時間)を利用します。RTOはRTTの推定値をもとに計算される / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• TCP再送(TCP Retransmission)は断続的な数秒間の通信停止の原因になることがあります。初期RTOは1秒が基準で、タイムアウトが起きるたびに倍化するため、条件が悪いと数秒単位の停止に見える / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• 断続的な数秒間の通信停止はWiresharkで確認できます。Time delta from previous displayed packetとRetransmission表示で、停止時間がRTOの待ち方と噛み合うかを確認できる / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• TCP再送(TCP Retransmission)はWiresharkで確認できます。tcp.analysis.retransmissionなどの表示フィルタと、Bad TCP色分けの行で再送パケットを識別できる / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• パケットロスはWiresharkで確認できます。tcp.analysis.lost_segmentという表示フィルタでロスを確認できる / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• TCPタイムスタンプオプションはRTTM(往復時間測定)を利用します。TCPのtimestamps optionはRTTM(往復時間測定)の実現に使われる / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• TCPタイムスタンプオプションはPAWS(シーケンス番号一周対策)を利用します。同じtimestamps optionはPAWS(シーケンス番号一周対策)にも使われる / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• Karnのアルゴリズムは再送時のRTT測定の曖昧さを軽減します。再送されたセグメントからはRTTサンプルを取らないことで、どちらの送信へのACKか分からないという曖昧さの影響を避ける / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• TCPタイムスタンプオプションは再送時のRTT測定の曖昧さを軽減します。ACKに入るTSecrを見ればどのTSvalを持つセグメントへの応答かを識別できるため、再送時のRTT測定の曖昧さを外せる / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• TCPタイムスタンプオプションは断続的な数秒間の通信停止を軽減します。再送を含む場面でもRTTの見積もりを更新しやすくなり、RTOが古いまま保守的に残る時間を抑えられる場合があるが、パケットロス自体を消す仕組みではない / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
• fast retransmit(高速再送)はRTO(再送タイマ)を防ぎます。Duplicate ACKを3つ集められればRTOの満了を待たずに再送できるが、未ACKデータの少ない小さなrequest/response通信では十分に集まらず、RTO待ちが表に出やすい / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
• fast retransmit(高速再送)はDuplicate ACK(重複ACK)を前提とします。fast retransmitは、同じシーケンス番号を指すDuplicate ACKが一定数たまることをトリガーにする / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• パケットロスはDuplicate ACK(重複ACK)の原因になることがあります。途中に抜け(ロス)があると、受信側は同じシーケンス番号を指す重複ACKを返す。ただし重複ACKはロス以外にパケットの順序入れ替えや重複でも発生するため、ロスは重複ACKの原因の一つである / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• TCPタイムスタンプオプションはTCPの3-way handshakeを前提とします。timestamps optionはTCP接続の3-way handshake(SYN/SYN-ACK/ACK)で交渉されるため、既に張られている接続には効かず、新規接続からしか使われない / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• TCPタイムスタンプオプションはWindowsのTCPタイムスタンプ設定で構成できます。Windows環境では、netsh interface tcp set global timestamps=enabled、PowerShellのSet-NetTCPSetting -Timestamps Enabled、レジストリのTcp1323Optsのいずれかで設定できる。Linux等ではsysctlなど別の設定手段になる / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
• WindowsのTCPタイムスタンプ設定はWiresharkで確認できます。設定が効いているかは、設定値そのものより、SYN/SYN-ACKの実パケットにTSoptが乗っているかをWiresharkで確認するほうが確実 / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• RTO(再送タイマ)はKarnのアルゴリズムを利用します。バックオフしたRTOは新しいRTT測定が得られると元に戻るが、Karnのアルゴリズムにより再送したセグメントからはその測定を得られない / 確度: 確立した関係 / 確認日: 2026-08-01 出典

主要概念の定義

TCP再送(TCP Retransmission)

送信したパケットに対するACKが返ってこないとき、TCPが同じデータを再度送信する仕組みである。

RTO(再送タイマ)

この時間内にACKが返らなければ再送する、RTTの推定値から計算されるTCPの再送タイマである。

TCPタイムスタンプオプション

TCPヘッダーに付く、種別8・長さ10バイトのオプションで、RTTM(RTT測定)とPAWS(シーケンス番号一周対策)のために送信側の時刻値TSvalとその応答TSecrを運ぶ仕組みである。

パケットロス

送信されたパケットが途中の経路で失われ、受信側に届かなくなる現象である。

断続的な数秒間の通信停止

平均では速いのに、まれに数秒単位で応答が止まる通信症状で、多くはアプリの停止ではなくTCPの再送待ちが原因になる。

Karnのアルゴリズム

再送したセグメントに対するACKはどちらの送信への応答か分からないため、そこからRTTサンプルを取ってはいけないとする規則である。

fast retransmit(高速再送)

同じシーケンス番号を指すDuplicate ACKが一定数(Windowsの既定では3つ)たまったら、RTOの満了を待たずに再送する仕組みである。

WindowsのTCPタイムスタンプ設定

netsh interface tcp、PowerShellのSet-NetTCPSetting、レジストリのTcp1323Optsのいずれかで行う、WindowsのTCPタイムスタンプオプションの有効化設定である。

機械可読データ

• JSON-LD / Turtle ── この記事の知識グラフ全体
• 概念一覧 / 語彙(述語)の定義

このページはサイトの知識グラフ(_data/knowledge/)から自動生成されています。誤りの指摘はお問い合わせからお願いします。