zabbix监控系统中tcp状态数量 监控传输协议tcp

　　TCP是面向连接的、可靠的、基于字节流(应用层传下来的报文看成字节流，把字节流组织成大小不等的数据块)的、拥有流量控制的协议。在一个TCP连接中。仅有连接双方进行通信。TCP为应用层提供全双工服务，数据能在两个方向上独立地进行传输。是一对一的通信。TCP可以表述为一个没有选择确认或否认的滑动窗口协议。

　　TCP将用户数据打包构成报文段；它发送数据后启动一个定时器（超时重传）；另一端对收到的数据进行确认，对失序的数据重新排序，丢弃重复数据；提供端到端的流量控制，并计算和验证一个强制性的端到端检验和。

报文格式

• 16位源端口号 /16位目的端口号：两个值加上IP首部中的源端IP地址和目的端IP地址唯一确定一个TCP连接。一个IP地址和一个端口号也称为一个插口（ socket）。
• 32位序号：序号用来标识从TCP发端向TCP收端发送的数据字节流，表示第一个字节的序号。如果将字节流看作在两个应用程序间的单向流动，则TCP用序号对每个字节进行计数。溢出后又重0开始。当建立一个新的连接时， SYN标志变1。序号字段包含由这个主机选择的该连接的初始序号ISN（Initial Sequence Number）。该主机要发送数据的第一个字节序号为这个ISN加1，因为SYN标志消耗了一个序号。
• 32位确认序号：确认序号包含发送确认的一端所期望收到的下一个序号。确认序号应当是上次已成功收到数据字节序号加1。只有A C K标志为1时确认序号字段才有效。在TCP中，ACK是累积的—它们表示接收方已经正确收到了一直到确认序号减1的所有字节,如确认4097，说明1到4096均已正确收到。
• 4位首部长度：给数首部中有多少个32bit。
• 6个标志比特：URG（urgent pointer）紧急指针有效；ACK确认序号有效；PSH接收方应该尽快将收到的数据交给应用进程；RST重建连接；SYN同步序号用来发起一个连接；FIN发端完成发送任务。
• 16位窗口大小：TCP的流量控制由连接的每一端通过声明的窗口大小来提供。窗口大小为字节数，起始于确认序号字段指明的值，这个值是接收端正期望接收的字节。窗口大小是一个16 bit字段，因而窗口大小最大为65535字节。
• 16位检验和：覆盖TCP首部+TCP数据。TCP的检验和与UDP的检验和相似，同样会有一个伪首部。 　　
• 16位紧急指针：只有当URG标志置1时紧急指针才有效。紧急指针是一个正的偏移量，和序号字段中的值相加表示紧急数据最后一个字节的序号。TCP的紧急方式是发送端向另一端发送紧急数据的一种方式。　　
• 选项：如下图。最常见的可选字段是最长报文大小，又称为MSS (Maximum Segment Size)，指明本端所能接收的最大长度的报文段。当一个连接建立时，连接的双方都要通告各自的MSS。

复位报文段

　　当一个报文段发往基准的连接出现错误， TCP都会发出一个复位报文段，RST置1的报文。

　　引发的原因有：

• 到不存的端口的连接请求。产生复位的一种常见情况是当连接请求到达时，目的端口没有进程正在听。对于UDP，当一个数据报到达目的端口时，该端口没在使用，它将产生一个ICMP端口不可达的信息。
• 异常终止一个连接。丢弃任何待发数据并立即发送复位报文段，RST的接收方会区分另一端执行的是异常关闭还是正常关闭。
• 检测半打开连接。如果一方已经关闭或异常终止连接而另一方却还不知道，我们将这样的TCP连接称为半打开的。

TCP的ICMP差错报文

　　TCP能够遇到的最常见的ICMP差错就是源站抑制、主机不可达和网络不可达。

• 一个接收到的源站抑制引起拥塞窗口cwnd被置为1个报文段大小来发起慢启动，但是慢启动门限ssthresh没有变化，所以窗口将打开直至它或者开放了所有的通路（受窗口大小和往返时间的限制）或者发生了拥塞。
• 一个接收到的主机不可达或网络不可达实际上都被忽略，因为这两个差错都被认为是短暂现象。

 

TCP建立连接：三次握手

 

1. 首先服务器B处于LISTEN（监听）状态，等待客户的连接请求。
2. 客户端A向B发送连接请求报文，SYN=1，ACK=0，选择一个初始的序号seq=x。
3. B收到连接请求报文，如果同意建立连接，则向A发送连接确认报文，SYN=1，ACK=1，确认号为ack=x+1，同时也选择一个初始的序号seq=y。
4. A收到B的连接确认报文后，还要向B发出确认，确认号为y+1，序号为x+1。
5. B收到A的确认后，连接建立。

　　三次握手的原因

　　第三次握手是为了防止失效的连接请求到达服务器，让服务器错误打开连接。客户端发送的连接请求如果在网络中滞留，那么就会隔很长一段时间才能收到服务器端发回的连接确认。客户端等待一个超时重传时间之后，就会重新请求连接。但是这个滞留的连接请求最后还是会到达服务器，如果不进行三次握手，那么服务器就会打开两个连接。如果有第三次握手，客户端会忽略服务器之后发送的对滞留连接请求的连接确认，不进行第三次握手，因此就不会再次打开连接。

TCP断开连接：四次挥手

1. 客户端A发送连接释放报文，FIN=1。
2. 服务器B收到之后发出确认，此时TCP属于半关闭状态，B能向A发送数据但是A不能向B发送数据。
3. 当B不再需要连接时，发送连接释放报文，FIN=1。
4. A收到后发出确认，进入TIME-WAIT状态，等待2MSL（最大报文存活时间）后释放连接。
5. B收到A的确认后释放连接。

　　四次挥手的原因

　　客户端发送了FIN连接释放报文之后，服务器收到了这个报文，就进入了CLOSE-WAIT状态。这个状态是为了让服务器端发送还未传送完毕的数据，传送完毕之后，服务器会发送FIN连接释放报文。

　　TIME_WAIT

　　客户端接收到服务器端的FIN报文后进入此状态，此时并不是直接进入CLOSED状态，还需要等待一个时间计时器设置的时间2MSL。这么做有两个理由：

• 确保最后一个确认报文能够到达。如果B没收到A发送来的确认报文，那么就会重新发送连接释放请求报文，A等待一段时间就是为了处理这种情况的发生。
• 等待一段时间是为了让本连接持续时间内所产生的所有报文都从网络中消失，使得下一个新的连接不会出现旧的连接请求报文。

同时打开和关闭

　　TCP是特意设计为了可以处理同时打开，对于同时打开它仅建立一条连接而不是两条连接。需要每一方使用一个对方熟知的端口作为本地端口。一个同时打开的连接需要交换4个报文段，比正常的三次握手多一个。

 

　　TCP协议也允许同时关闭。

完整状态转移图

　　

限制端口

TCP的交互数据流和成块数据流

TCP的通信量如果按照分组数量计算，约有一半的TCP报文段包含成块数据（如FTP、电子邮件和Usenet新闻），另一半则包含交互数据（如Telnet和Rlogin）。如果按字节计算，则成块数据与交互数据的比例约为90%和10%。这是因为成块数据的报文段基本上都是满长度的（通常为512字节的用户数据），而交互数据则小得多。TCP需要同时处理这两类数据，但使用的处理算法则有所不同。

　　通道的容量计算：带宽时延积 = 带宽 x 时延（是来回的时间RTT）。

 

TCP可靠传输（超时重传）

　　TCP的管理有4个定时器：1、重传定时器，用于等待对方的确认，超时重传保证可靠性；2、坚持定时器，使窗口大小信息保持不断流动，即使另一端关闭了其接收窗口；3、保活定时器，可检测到一个空闲连接的另一端何时崩溃或重启；4、2MSL定时器，测量一个连接处于TIMEWAIT状态的时间。

　　TCP超时重传中最重要的部分就是对一个给定连接的往返时间（ RTT）的测量。

RTT =αRTT + (1-α)M，RTT表示使用的估计时间往返值，M表示新测量的时间往返值。α是一个推荐值为0.9的平滑因子。每次进行新测量的时候，这个被平滑的RTT将得到更新。每个新估计的90％来自前一个估计，而10%则取自新的测量。

该算法在给定这个随RTT的变化而变化的平滑因子的条件下， RFC 793推荐的重传超时时间RTO（Retransmission TimeOut）的值应该设置为RTO = RTTβ，这里的β是一个推荐值为2的时延离散因子。

除了被平滑的RTT估计器，所需要做的还有跟踪RTT的方差。在往返时间变化起伏很大时，基于均值和方差来计算RTO，将比作为均值的常数倍数来计算RTO能提供更好的响应。M为最新往返时间测量值，A为被平滑的RTT值，Err为时间偏差，g为起加权作用的增量，h为偏差的增益，D为均值偏差。

　　当TCP超时重传时，它不一定要重传同样的报文段，允许进行重新分组而发送一个较大的报文段，这将有助于提高性能。因为TCP是使用字节序号而不是报文段序号来进行识别它所要发送的数据和进行确认。

TCP流量控制（滑动窗口）

　　TCP所使用的被称为滑动窗口协议的另一种形式的流量控制方法。由于发送方不必每发一个分组就停下来等待确认，因此该协议可以加速数据的传输。

窗口是缓存的一部分，用来暂时存放字节流。发送方和接收方各有一个窗口，接收方通过 TCP 报文段中的窗口字段告诉发送方自己的窗口大小，发送方根据这个值和其它信息设置自己的窗口大小。

　　发送窗口内的字节都允许被发送，接收窗口内的字节都允许被接收。如果发送窗口左部的字节已经发送并且收到了确认，那么就将发送窗口向右滑动一定距离，直到左部第一个字节不是已发送并且已确认的状态；接收窗口的滑动类似，接收窗口左部字节已经发送确认并交付主机，就向右滑动接收窗口。

　　接收窗口只会对窗口内最后一个按序到达的字节进行确认，例如接收窗口已经收到的字节为 {31, 34, 35}，其中 {31} 按序到达，而 {34, 35} 就不是，因此只对字节 31 进行确认。发送方得到一个字节的确认之后，就知道这个字节之前的所有字节都已经被接收。

窗口左右沿的运动有三种：1、窗口左边沿向右边沿靠近为窗口合拢。这种现象发生在数据被发送和确认时；2、窗口右边沿向右移动时将允许发送更多的数据，称为窗口张开。这种现象发生在另一端的接收进程读取已经确认的数据并释放了TCP的接收缓存时；3、右边沿向左移动时，我们称之为窗口收缩。因为窗口的左边沿已经是确认接收的数据了，因此不可能向左边移动。

 

TCP拥塞控制

　　当数据到达一个大的管道（如一个快速局域网）并向一个较小的管道（如一个较慢的广域网）发送时便会发生拥塞。当多个输入流到达一个路由器，而路由器的输出流小于这些输入流的总和时也会发生拥塞。如果网络出现拥塞，分组将会丢失，此时发送方会继续重传，从而导致网络拥塞程度更高。因此当出现拥塞时，应当控制发送方的速率。这一点和流量控制很像，但是出发点不同。流量控制是为了让接收方能来得及接收，而拥塞控制是为了降低整个网络的拥塞程度。

 

 

TCP主要通过四个算法来进行拥塞控制：慢启动、拥塞避免、快重传、快恢复。维护两个状态变量：一个拥塞窗口cwnd和一个慢启动门限ssthresh（到达这个上限值后不再使用慢启动中的策略）。慢开始和快恢复的快慢指的是 cwnd 的设定值，而不是 cwnd 的增长速率。慢开始 cwnd 设定为 1，而快恢复 cwnd 设定为 ssthresh。

 

　　慢启动与拥塞避免

　　拥塞避免算法和慢启动算法是两个目的不同、独立的算法。但是当拥塞发生时，我们希望降低分组进入网络的传输速率，于是可以调用慢启动来作到这一点。在实际中这两个算法通常在一起实现。

　　慢启动通过观察到新分组进入网络的速率应该与另一端返回确认的速率相同而进行工作。cwnd被初始化为1个报文段,每收到一个ACK，拥塞窗口就指数增加报文段（ cwnd以字节为单位，但是慢启动以报文段大小为单位进行增加）。发送方取拥塞窗口与通告窗口中的最小值作为发送上限。拥塞窗口是发送方使用的流量控制，而通告窗口则是接收方使用的流量控制。发送方开始时发送一个报文段，然后等待ACK。当收到该ACK时，拥塞窗口从1增加为2，即可以发送两个报文段。当收到这两个报文段的ACK时，拥塞窗口就增加为4。这是一种指数增加的关系。

　　拥塞避免在到达慢启动门限之前使用慢启动。流程如下：

1. 对一个给定的连接，初始化cwnd为1个报文段，ssthresh为65535个字节。TCP输出例程的输出不能超过cwnd和接收方通告窗口的大小中的最小值。
2. 当 cwnd >= ssthresh时，进入拥塞避免，收到ACK后，每个轮次只将 cwnd 加 1。如果出现了超时，则ssthresh被设置为当前窗口大小的一半（ cwnd和接收方通告窗口大小的最小值，但最少为2个报文段），然后重新执行慢开始。

　　快重传与快恢复

　　在接收方，要求每次接收到报文段都应该对最后一个已收到的有序报文段进行确认。例如已经接收到 M₁和M₂，此时收到M₄，应当发送对M₂的确认。由于我们不知道一个重复的ACK是由一个丢失的报文段引起的，还是由于出现了几个报文段的重新排序，所以当收到2个重复的ACK时不能确定报文丢失，需要收到连续3及以上重复的ACK时可以确定报文丢失。在发送方，如果收到3个重复确认，那么可以知道下一个报文段丢失，此时执行快重传，立即重传下一个报文段。例如收到三个 M₂，则 M₃丢失立即重传 M₃。

　　在这种情况下，只是丢失个别报文段，而不是网络拥塞。因此执行快恢复，令 ssthresh = cwnd / 2 ，cwnd = ssthresh，注意到此时直接进入拥塞避免，这就是快恢复。

　　

 

TCP坚持定时器

　　由于TCP只对数据进行确认，而不对ACK进行确认。所以如果接收方回传的关于更新窗口的一个确认丢失了，则双方就有可能因为等待对方而使连接终止：接收方等待接收数据（因为它已经向发送方通告了一个非0的窗口），而发送方在等待允许它继续发送数据的窗口更新。为防止这种死锁情况的发生，发送方使用一个坚持定时器来周期性地向接收方查询，以便发现窗口是否已增大，这些从发送方发出的报文段称为窗口探查。

 

TCP保活定时器

如过没有保活的情况下，我们可以启动一个客户与服务器建立一个连接，然后离去数小时、数天、数个星期或者数月，而连接依然保持。中间路由器可以崩溃和重启，电话线可以被挂断再连通，但是只要两端的主机没有被重启，则在两端看来连接依然保持建立。

　　一般保活由应用层实现，在连接空闲两个小时后，在一个连接上发送一个探查分组来完成保活功能。可能会发生4种不同的情况：对端仍然运行正常、对端已经崩溃、对端已经崩溃并重新启动以及对端当前无法到达。

 

TCP vs. UDP

• TCP和UDP均工作在传输层，检验和的计算相似，均有伪首部。
• TCP的检验和是必须的；UDP的检验和是可选的。
• TCP是面向连接的，一对一之间的通信；UDP是面向无连接的。
• TCP是基于字节流服务；UDP是基于报文；
• TCP具有超时重传，差错控制，流量控制；UDP没有。

参考

《TCP/IP详解卷1》

CS-Notes/计算机网络/传输层

菜鸟手记。