【网络】关于 TCP重传率

TCP的错误恢复特性是我们用来定位、诊断并最终修复网络高延迟的最好工具。

常见的TCP错误恢复特性有：TCP重传、TCP重复确认和快速重传。
重传数据包是TCP最基本的错误恢复特性之一，用来对付数据包的丢失。

数据包丢失可能原因有很多，如：出故障的应用程序、流量负载沉重的路由器或临时性的服务中断。

数据包层次上的移动速度非常快，而且数据包丢失通常都是暂时的，因此TCP能否检测到数据包丢失并恢复至关重要。
如何决定是否重传：

决定是否重传数据包的主要机制叫做：重传计时器，这个计时器负责维护一个重传超时（RTO--Retransmission timeout）的值。

当使用TCP传输一个数据包时，就启动重传计时器，当收到这个数据包的ACK应答时，计时器就停止。从发送数据包到接收ACK确认之间的时间被称为往返时间（Round-Trip time，RTT），若干个这样的时间平均下来，可计算出最终的RTO值。

一旦RTO值确定下来，重传计时器就被用于每个传输的数据包，以确定数据包是否丢失。
当报文发送之后，但接收方尚未发送TCP ACK报文，发送方假设源报文丢失并将其重传。重传之后，RTO值加倍；如果在2倍RTO值到达之前还是没有收到ACK报文，就再次重传。如果仍然没有收到ACK，那么RTO值再次加倍。如此持续下去，每次重传RTO都翻倍，直到收到ACK报文或发送方达到配置的最大重传次数。
最大重传次数取决于发送 *** 作系统的配置值。

默认情况下，Windows主机默认重传5次。大多数Linux系统默认最大15次，两种 *** 作系统都可配置。
TCP重传率是网络质量的体现，网络这块我们主要看 TCP重传率 ，这个基本在大点的公司都有这块监控。
TCP重传率=单位时间内TCP重传包数量/TCP发包总数
我们可以把 TCP重传率 视为 网络质量和服务器稳定性 的一个只要衡量指标。

还是根据我们的经验，这个TCP重传率越低越好，越低代表我们的网络越好，如果TCP重传率保持在002%（以自己的实际情况为准）以上，或者突增，就可以怀疑是不是 网络问题 了。
比如这张图一样，要是和心电图一样，基本上网络问题就没跑了。
一分钟理解TCP重传

>没有信令服务器，各个WebRTC之间是没办法通信的。
传递媒体数据有两个信息，必须经过信令服务器进行交换

通过SDP来表示，如编解码器是什么？是否支持音频视频？编码方式是什么？等
这些信息是通过SDP协议描述出来，通过信令服务器中转的

两个WebRTC客户端会尽可能选择P2P进行连接，那么进行连接前是如何发现对方的？就是通过信令服务器。
首先将你所有网络相关信息传到信令服务器，服务器帮你交换到对端，对端拿到你的信息后，
若在同一局域网内，直接通过P2P传输；若不在，首先进行P2P穿越，看是否能打通，打通则传输，打不通则中转等。

还有一点也需要信令服务器进行传输，比如加入房间，离开房间，禁言等功能

在传输时，一般有两种协议 TCP和 UDP
底层协议使用 UDP主要用于流媒体传输（音频视频）还有文本，文字聊天等，但 UDP是不可靠传输，是可以丢包的，当然音频视频是可以丢包的，丢失一帧只会卡顿下，还可以继续工作。
但信令服务器不能丢失数据，所有的包必须保证到达，否则断开连接，所以信令服务器一般使用TCP可靠性传输。
websocket底层使用的就是 TCP协议， socketio 使用的也是TCP

在websocket官方中，是有三个服务器的，ROOM服务器（提供用户进出房间服务）、信令服务器、流媒体（中转）服务器
选用socketio 即不用单独写ROOM服务器，这里ROOM和信令是同一个服务器

socketio是一个基于Nodejs的库，在现有的Node Server上增加个socketio即可

在任何终端都可以引入socketio客户端的库，通过客户端的库就可以连接到 Nodejs中 socketio服务器上
这样就可以建立连接，然后就可以创建，加入房间，这样房间内的人就可以通信了

多个 sockeio可以串行通信。

首先，我们需要明确， 只有主动断开的那一方才会进入 TIME_WAIT 状态 ，且会在那个状态持续 2 个 MSL（Max Segment Lifetime）。

为了讲清楚 TIME_WAIT，需要先介绍一下 MSL 的概念。
MSL（报文最大生存时间）是 TCP 报文在网络中的最大生存时间。这个值与 IP 报文头的 TTL 字段有密切的关系。

IP 报文头中有一个 8 位的存活时间字段（Time to live, TTL）如下图。 这个存活时间存储的不是具体的时间，而是一个 IP 报文最大可经过的路由数，每经过一个路由器，TTL 减 1，当 TTL 减到 0 时这个 IP 报文会被丢弃。

TTL 经过路由器不断减小的过程如下图所示，假设初始的 TTL 为 12，经过下一个路由器 R1 以后 TTL 变为 11，后面每经过一个路由器以后 TTL 减 1

从上面可以看到 TTL 说的是「跳数」限制而不是「时间」限制，尽管如此我们依然假设 最大跳数的报文在网络中存活的时间不可能超过 MSL 秒 。

Linux 的套接字实现假设 MSL 为 30 秒，因此在 Linux 机器上 TIME_WAIT 状态将持续 60秒。
要构造一个 TIME_WAIT 非常简单，只需要建立一个 TCP 连接，然后断开某一方连接，主动断开的那一方就会进入 TIME_WAIT 状态，我们用 Linux 上开箱即用的 nc 命令来构造一个。

过程如下图：
在机器 c2 上用nc -l 8888启动一个 TCP 服务器

在机器 c1 上用 nc c2 8888 创建一条 TCP 连接

在机器 c1 上用 Ctrl+C 停止 nc 命令，随后在用netstat -atnp | grep 8888查看连接状态。
第一个原因是：数据报文可能在发送途中延迟但最终会到达，因此要等老的“迷路”的重复报文段在网络中过期失效，这样可以避免用相同源端口和目标端口创建新连接时收到旧连接姗姗来迟的数据包，造成数据错乱。
比如下面的例子
假设客户端 10211552 的 61594 端口与服务端 102115510 的 8080 端口一开始建立了一个 TCP 连接。

假如客户端发送完 FIN 包以后不等待直接进入 CLOSED 状态，老连接 SEQ=3 的包因为网络的延迟。过了一段时间 相同 的 IP 和端口号又新建了另一条连接，这样 TCP 连接的四元组就完全一样了。

恰好 SEQ 因为回绕等原因 也正好相同，那么 SEQ=3 的包就无法知道到底是旧连接的包还是新连接的包了，造成新连接数据的混乱。

TIME_WAIT 等待时间是 2 个 MSL，已经足够让一个方向上的包最多存活 MSL 秒就被丢弃，保证了在创建新的 TCP 连接以后，老连接姗姗来迟的包已经在网络中被丢弃消逝，不会干扰新的连接。
第二个原因是确保可靠实现 TCP 全双工终止连接。

关闭连接的四次挥手中，最终的 ACK 由主动关闭方发出，如果这个 ACK 丢失，对端（被动关闭方）将重发 FIN，如果主动关闭方不维持 TIME_WAIT 直接进入 CLOSED 状态，则无法重传 ACK，被动关闭方因此不能及时可靠释放。
如果四次挥手的第 4 步中客户端发送了给服务端的确认 ACK 报文以后不进入 TIME_WAIT 状态，直接进入 CLOSED状态，然后重用端口建立新连接会发生什么呢？

如下图所示
主动关闭方如果马上进入 CLOSED 状态，被动关闭方这个时候还处于LAST-ACK状态，主动关闭方认为连接已经释放，端口可以重用了， 如果使用相同的端口三次握手发送 SYN 包，会被处于 LAST-ACK状态状态的被动关闭方返回一个 RST，三次握手失败。

为什么时间是两个 MSL？

1 个 MSL 确保四次挥手中主动关闭方最后的 ACK 报文最终能达到对端

1 个 MSL 确保对端没有收到 ACK 重传的 FIN 报文可以到达

2MS = 去向 ACK 消息最大存活时间（MSL) + 来向 FIN 消息的最大存活时间（MSL）

在一个非常繁忙的服务器上，如果有大量 TIME_WAIT 状态的连接会怎么样呢？

连接表无法复用

socket 结构体内存占用
连接表无法复用  因为处于 TIME_WAIT 的连接会存活 2MSL（60s），意味着相同的TCP 连接四元组（源端口、源 ip、目标端口、目标 ip）在一分钟之内都没有办法复用，通俗一点来讲就是“占着茅坑不拉屎”。

假设主动断开的一方是客户端，对于 web 服务器而言，目标地址、目标端口都是固定值（比如本机 ip + 80 端口），客户端的 IP 也是固定的，那么能变化的就只有端口了，在一台 Linux 机器上，端口最多是 65535 个（ 2 个字节）。

如果客户端与服务器通信全部使用短连接，不停的创建连接，接着关闭连接，客户端机器会造成大量的 TCP 连接进入 TIME_WAIT 状态。
可以来写一个简单的 shell 脚本来测试一下，使用 nc 命令连接 redis 发送 ping 命令以后断开连接。
如果在 60s 内有超过 65535 次 redis 短连接 *** 作，就会出现端口不够用的情况，这也是使用 连接池 的一个重要原因。
针对 TIME_WAIT 持续时间过长的问题，Linux 新增了几个相关的选项，netipv4tcp_tw_reuse 和 netipv4tcp_tw_recycle。

下面我们来说明一下这两个参数的用意。 这两个参数都依赖于 TCP 头部的扩展选项：timestamp
TCP 头部时间戳选项（TCP Timestamps Option，TSopt）

除了我们之前介绍的 MSS、Window Scale 还有以一个非常重要的选项：时间戳（TCP Timestamps Option，TSopt）
它由四部分构成：类别（kind）、长度（Length）、发送方时间戳（TS value）、回显时间戳（TS Echo Reply）。

时间戳选项类别（kind）的值等于 8，用来与其它类型的选项区分。长度（length）等于 10。两个时间戳相关的选项都是 4 字节。

如下图所示：

是否使用时间戳选项是在三次握手里面的 SYN 报文里面确定的。

下面的包是 curl githubcom 抓包得到的结果：

发送方发送数据时，将一个发送时间戳 1734581141 放在发送方时间戳 TSval 中

接收方收到数据包以后，将收到的时间戳 1734581141 原封不动的返回给发送方，放在 TSecr 字段中，同时把自己的时间戳 3303928779 放在 TSval 中

后面的包以此类推
有几个需要说明的点：

1 时间戳是一个单调递增的值，与我们所知的 epoch 时间戳不是一回事。 这个选项不要求两台主机进行时钟同步

2 timestamps 是一个双向的选项，如果只要有一方不开启，双方都将停用 timestamps。

比如下面是curl >>需要在服务器上实现个TCP服务器, 由于已安装了nginx, 所以在nginx中给TCP开个口子。

网上文章的说法都是, 190版之后nginx开始具有TCP/UDP的代理转发功能, 但需要手动安装stream模块

我用 nginx -V 命令(注意V是大写, 可查询nginx已安装模块)查了一下, 我的nginx是1160版本, 并且已经安装了stream模块(命令输出包含 --with-stream ), 所以我就不用手动安装了

首先要明确的一点, 关于TCP转发的配置, 是TCP层面的, 它和>socketBeginAccept(delegate (result) { Socket socket = (Socket)resultAsyncState; },socket); 接着在回调内部调用socket的EndAccept就可以获取端口了，,

TCP代理池（TCP Proxy Pool）是一种可以管理和分配多个代理服务器的工具，它可以为客户端提供多个可用的代理服务器，并自动切换代理服务器以确保高可用性和稳定性。当客户端需要访问某个目标服务器时，TCP代理池会自动从代理池中选择一个可用的代理服务器，并将客户端的请求转发给该代理服务器。如果该代理服务器无法访问目标服务器，TCP代理池会自动切换到另一个可用的代理服务器。TCP代理池常用于爬虫、数据采集等需要频繁访问互联网资源的场景中。

1、TCP和UDP都属于socket通信协议，前者是以100个数据流的方式进行通信，后者是以数据包的方式进行通信。

2、TCP是有向连接协议，UDP是无向连接协议。

3、当tcpclient和服务器建立连接时，它们需要三个握手协议。UDP不需要握手，直接发送数据包。

4、TCP通信不会丢失数据，UDP通信会丢失数据包。

5、在通信可靠性方面，TCP比UDP更可靠。

6、安全性上，TCP安全保密要比UDP高。

7、TServerSocket/TClientSocket，是兼容的消息通知的非阻塞异步模式。

扩展资料：

在使用TCP通讯建立连接时采用客户端服务器模式，这种模式又常常被称为主从式架构，简称为C/S结构，属于一种网络通讯架构，将通讯的双方以客户端（Client ）与服务器 (Server) 的身份区分开来。

使用C/S结构的通信常见的还有S7通信， ISO-on-TCP通信。

服务器的特征：被动角色，等待来自客户端的连接请求，处理请求并回传结果。

客户端的特征：主动角色，发送连接请求，等待服务器的响应。

TCP/IP是供已连接因特网的计算机进行通信的通信协议。
TCP/IP协议TransmissionControlProtocol/InternetProtocol的简写，中译名为传输控制协议/因特网互联协议，又名网络通讯协议，是Internet最基本的协议、Internet国际互联网络的基础，由网络层的IP协议和传输层的TCP协议组成。
TCP/IP传输协议，即传输控制/网络协议，也叫作网络通讯协议。它是在网络的使用中的最基本的通信协议。TCP/IP传输协议对互联网中各部分进行通信的标准和方法进行了规定。并且，TCP/IP传输协议是保证网络数据信息及时、完整传输的两个重要的协议。
TCP/IP传输协议是严格来说是一个四层的体系结构，应用层、传输层、网络层和数据链路层都包含其中。

---