前言
默认情况下，Wireshark 的 TCP 解析器会跟踪每个 TCP 会话的状态，并在检测到问题或潜在问题时提供额外的信息。在第一次打开捕获文件时，会对每个 TCP 数据包进行一次分析，数据包按照它们在数据包列表中出现的顺序进行处理。可以通过 “Analyze TCP sequence numbers” TCP 解析首选项启用或禁用此功能。
TCP 分析展示
在数据包文件中进行 TCP 分析时，关于 “TCP Port numbers reused” 一般是如下显示的，包括：
- Packet List 窗口中的 Info 信息列，以 [TCP Port numbers reused] 黑底红字进行标注；
- Packet Details 窗口中的 TCP 协议树下，在 [SEQ/ACK analysis] -> [TCP Analysis Flags] 中定义该 TCP 数据包的分析说明。
TCP Port numbers reused 定义
实际在 TCP 分析中，关于 TCP Port numbers reused 的定义非常简单，如下，针对 SYN 数据包(而不是SYN+ACK)，如果已经有一个使用相同 IP+Port 的会话，并且这个 SYN 的序列号与已有会话的 ISN 不同时设置。
Set when the SYN flag is set (not SYN+ACK), we have an existing conversation using the same addresses and ports, and the sequence number is different than the existing conversation’s initial sequence number.
注意：官方文档此处说明的是 SYN，而非 SYN/ACK，和实际代码实现的却不一样，下述展开说明。
具体的代码如下，主要作用是处理 SYN 以及 SYN/ACK 数据包，判断是新连接还是已有连接的重传，并相应地创建新会话或更新会话的序列号等，并设置相关标志位。总的来说，这是 Wireshark 分析 TCP 流量时处理 SYN 和 SYN/ACK 数据包的一个重要环节，用于正确识别连接和更新状态信息。
/* If this is a SYN packet, then check if its seq-nr is different
* from the base_seq of the retrieved conversation. If this is the
* case, create a new conversation with the same addresses and ports
* and set the TA_PORTS_REUSED flag. (XXX: There is a small chance
* that this is an old duplicate SYN received after the connection
* is ESTABLISHED on both sides, the other side will respond with
* an appropriate ACK, and this SYN ought to be ignored rather than
* create a new conversation.)
*
* If the seq-nr is the same as the base_seq, it might be a simple
* retransmission, reattempting a handshake that was reset (due
* to a half-open connection) with the same sequence number, or
* (unlikely) a new connection that happens to use the same sequence
* number as the previous one.
*
* If we have received a RST or FIN on the retrieved conversation,
* create a new conversation in order to clear out the follow info,
* sequence analysis, desegmentation, etc.
* If not, it's probably a retransmission, and will be marked
* as one later, but restore some flow values to reduce the
* sequence analysis warnings if our capture file is missing a RST
* or FIN segment that was present on the network.
*
* XXX - Is this affected by MPTCP which can use multiple SYNs?
*/
if (tcpd != NULL && (tcph->th_flags & (TH_SYN|TH_ACK)) == TH_SYN) {
if (tcpd->fwd->static_flags & TCP_S_BASE_SEQ_SET) {
if(tcph->th_seq!=tcpd->fwd->base_seq || (tcpd->conversation_completeness & TCP_COMPLETENESS_RST) || (tcpd->conversation_completeness & TCP_COMPLETENESS_FIN)) {
if (!(pinfo->fd->visited)) {
conv=conversation_new(pinfo->num, &pinfo->src, &pinfo->dst, CONVERSATION_TCP, pinfo->srcport, pinfo->destport, 0);
tcpd=get_tcp_conversation_data(conv,pinfo);
if(!tcpd->ta)
tcp_analyze_get_acked_struct(pinfo->num, tcph->th_seq, tcph->th_ack, TRUE, tcpd);
tcpd->ta->flags|=TCP_A_REUSED_PORTS;
/* As above, a new conversation starting with a SYN implies conversation completeness value 1 */
conversation_is_new = TRUE;
}
} else {
if (!(pinfo->fd->visited)) {
/*
* Sometimes we need to restore the nextseq value.
* As stated in RFC 793 3.4 a RST packet might be
* sent with SEQ being equal to the ACK received,
* thus breaking our flow monitoring. (issue 17616)
*/
if(tcp_analyze_seq && tcpd->fwd->tcp_analyze_seq_info) {
tcpd->fwd->tcp_analyze_seq_info->nextseq = tcpd->fwd->tcp_analyze_seq_info->maxseqtobeacked;
}
if(!tcpd->ta)
tcp_analyze_get_acked_struct(pinfo->num, tcph->th_seq, tcph->th_ack, TRUE, tcpd);
}
}
}
else {
/*
* TCP_S_BASE_SEQ_SET being not set, we are dealing with a new conversation,
* either created ad hoc above (general case), or by a higher protocol such as FTP.
* Track this information, as the Completeness value will be initialized later.
* See issue 19092.
*/
if (!(pinfo->fd->visited))
conversation_is_new = TRUE;
}
tcpd->had_acc_ecn_setup_syn = (tcph->th_flags & (TH_AE|TH_CWR|TH_ECE)) == (TH_AE|TH_CWR|TH_ECE);
}
/* If this is a SYN/ACK packet, then check if its seq-nr is different
* from the base_seq of the retrieved conversation. If this is the
* case, set the TA_PORTS_REUSED flag and override the base seq.
* (XXX: Should this create a new conversation, as above with a
* SYN packet? We might have received the new connection's SYN/ACK before
* the SYN packet, or the SYN might be missing from the capture file.)
* If the seq-nr is the same as the base_seq, then do nothing so it
* will be marked as a retransmission later.
* XXX - Is this affected by MPTCP which can use multiple SYNs?
*/
if (tcpd != NULL && (tcph->th_flags & (TH_SYN|TH_ACK)) == (TH_SYN|TH_ACK)) {
if ((tcpd->fwd->static_flags & TCP_S_BASE_SEQ_SET) &&
(tcph->th_seq != tcpd->fwd->base_seq)) {
/* the retrieved conversation might have a different base_seq (issue 16944) */
/* XXX: Shouldn't this create a new conversation? Changing the
* base_seq will change how the previous packets in the conversation
* are processed in the second pass.
*/
tcpd->fwd->base_seq = tcph->th_seq;
if(!tcpd->ta)
tcp_analyze_get_acked_struct(pinfo->num, tcph->th_seq, tcph->th_ack, TRUE, tcpd);
tcpd->ta->flags|=TCP_A_REUSED_PORTS;
}
tcpd->had_acc_ecn_setup_syn_ack = ((tcph->th_flags & (TH_AE|TH_CWR)) == TH_CWR) ||
((tcph->th_flags & (TH_AE|TH_ECE)) == TH_AE);
}
Packetdrill 示例
首先可以通过 packetdrill 模拟出一次正常的 TCP 三次握手现象，同时经 tcpdump 捕获数据包后，得到 tcp_port_number_reused.pcap 数据包文件。
# cat tcp_port_number_reused.pkt
0 socket(..., SOCK_STREAM, IPPROTO_TCP) = 3
+0 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
+0 bind(3, ..., ...) = 0
+0 listen(3, 1) = 0
+0 < S 0:0(0) win 10000 <mss 1460>
+0 > S. 0:0(0) ack 1 <...>
+0.01 < . 1:1(0) ack 1 win 10000
+0 accept(3, ..., ...) = 4
#
通过 editcap 和 mergecap 对 pcap 文件做一定加工，复制出来一份之后再合并，最后得到 tcp_port_number_reused.pcapng 数据包文件。
editcap -t 0.1 tcp_port_number_reused.pcap tcp_port_number_reused_01.pcap
mergecap -w tcp_port_number_reused.pcapng tcp_port_number_reused.pcap tcp_port_number_reused_01.pcap
经 Wireshark 展示如下，可以看到 No.6 SYN 与之前 TCP 会话保持一样(源/目的 IP、源/目的端口)，且之前 TCP 会话存在 FIN/RST，则 No.6 标识成 [TCP Port numbers reused] 。
实例
关于 TCP Port numbers reused 的实例，实际上来说在客户端源端口不断变化的情况下，该现象并不是很常见，或者说就是看到了相关现象，也不是什么大问题，只是个 TCP 端口重用提示，并没有任何问题，仅仅是 Note 级别，信息为：[Expert Info (Note/Sequence): A new tcp session is started with the same ports as an earlier session in this trace]。
可能出现的场景，一是短时间客户端以固定源端口进行连接，但不断被服务器端 RST 或者客户端自身 RST 的情形，二是长时间捕获或者数据包很多时，客户端以同样的源端口又发起一次新连接，像是一些压测场景，再就是等等其他场景。
- 短时间重复 RST
以下是一个短时间重复 SYN RST 的场景，TCP Stream 6 发起 TCP 三次握手，但被服务器直接 RST 拒绝，之后间隔了 500ms，客户端又发起一个相同 TCP 源端口 52744 的新连接，但同样被服务器直接 RST 拒绝，之后不断反复，相同的 SYN 都会标识成 [TCP Port numbers reuserd] ，这种场景下找服务器 RST 连接的真实原因即可，[TCP Port numbers reuserd] 仅仅是不断发起 SYN 相同连接的提示而已。
再看一种短时间重复 SYN/ACK RST 的场景，相对来说更加少见，但总还是有的不是嘛~
- 长时间捕获重复 SYN
以下是一个长时间捕获的场景，TCP Stream 24 正常完成 TCP 三次握手、数据传输以及 TCP 四次挥手过程，再经过 2 个多小时的长期间捕获，客户端又发起一个相同 TCP 源端口 2266 的新连接，此时 No.48015 SYN 会标识成 [TCP Port numbers reuserd] ，这种场景下并没有任何问题，属于正常现象。
- 重复 SYN/ACK
以下介绍一个针对 SYN/ACK 重复以及设置 [TCP Port numbers reuserd] 的场景，也就是上面所说和官方文档说明不一致的地方，但是与代码一致。
首先是一个正常的捕获场景，No.1-2 为一次会话，No.3-4 为一次会话，其中 No.3 标记为 [TCP Port numbers reuserd]，紧接着 No.5-16 为一次会话，其中 No.5 标记为 [TCP Port numbers reuserd]。
如果此时出现了 No.5 SYN 未被捕获到的场景（这里可以通过 ignore 该数据包模拟实现），你会发现此时 No.6 SYN/ACK 标识成了 [TCP Port numbers reuserd]，也就是上述 SYN/ACK 代码部分所实现的判断逻辑。而 No.5 SYN 刚好未被捕获到的这种情形，你只能说极其少见，但确实不能完全排除，只能感慨，暗叹一句 Wireshark 牛批~
- 重复 SYN/ACK 的特例
也是在实验过程当中，发现了一个重复 SYN/ACK 的特别例子，首先基于以下数据包场景，正常两次会话，No.4 SYN 产生一次 [TCP Port numbers reuserd]。
如果此时出现了 No.4 SYN 未被捕获到的场景（这里可以通过 ignore 该数据包模拟实现），你会发现此时不仅 No.5 SYN/ACK 标识成了 [TCP Port numbers reuserd]，就连先前 No.2 SYN/ACK 也标识成了 [TCP Port numbers reuserd]，对于 No.2 这里所发生的情况百思不得其解。。。
甚至还有如下情形的，没有 RST 的情形，也会出现 [TCP Port numbers reuserd]。
待续，已提交 Issue，官方开发者确认为 Bug，静待修复。
补充：以上基于版本 4.2.x 测试，目前最新版本 4.4.0 已经解决。
总结
总结来说，以上体现了 Wireshark 代码在处理复杂 TCP 场景时的细致程度，明确区分了新老连接的不同情况。
