tcp连接资源消耗(tcp连接占用什么资源)

      最后更新:2023-04-29 21:09

      tcp业务无故消耗流量是怎么回事?

      TCP是指传输控制协议,是一种面向连接(连接导向)的、可靠的、基于字节流的运输层通信协议。您可在网上搜索有关“TCP”的相关信息。您可以发送“ATTX”至10010开通每日流量短信提示了解流量使用进度,或者登录我司网上营业厅 http://www.10010.com/ 首页,点击“话费查询”>“详单查询”>“上网流量”/“手机上网记录”查询上网流量详单及记录。如查询后仍存在异议,可以联系归属地客服进行解决。
      tcp业务无故消耗流量是怎么回事?

      为了消除重复连接请求的三次握手方法是怎样工作的?

      所谓的“三握手”:对每次发送的数据量是怎样跟踪进行协商使数据段的发送和接收同步,根据所接收到的数据 量而确定的数据确认数及数据发送、接收完毕后何时撤消联系,并建立虚连接。为了提供可靠的传送,TCP 在发送新的数据之前,以特定的顺序将数据包的序号,并需要这些包传送给目标机之后的确认消息。TCP 总是用来发送大批量的数据。当应用程序在收到数据后要做出确认时也要用到TCP。 [编辑本段]三次握手-释意  TCP握手协议 在TCP/IP协议中,TCP协议提供可靠的连接服务,采用三次握手建立一个连接。第一次握手:建立连接时,客户端发送syn包(syn=j)到服务器,并进入SYN_SEND状态,等待服务器确认;第二次握手:服务器收到syn包,必须确认客户的SYN(ack=j+1),同时自己也发送一个SYN包(syn=k),即SYN+ACK包,此时服务器进入SYN_RECV状态;三次握手协议第三次握手:客户端收到服务器的SYN+ACK包,向服务器发送确认包ACK(ack=k+1),此包发送完毕,客户端和服务器进入ESTABLISHED状态,完成三次握手。完成三次握手,客户端与服务器开始传送数据,在上述过程中,还有一些重要的概念:未连接队列:在三次握手协议中,服务器维护一个未连接队列,该队列为每个客户端的SYN包(syn=j)开设一个条目,该条目表明服务器已收到SYN包,并向客户发出确认,正在等待客户的确认包。这些条目所标识的连接在服务器处于Syn_RECV状态,当服务器收到客户的确认包时,删除该条目,服务器进入ESTABLISHED状态。Backlog参数:表示未连接队列的最大容纳数目。SYN-ACK 重传次数 服务器发送完SYN-ACK包,如果未收到客户确认包,服务器进行首次重传,等待一段时间仍未收到客户确认包,进行第二次重传,如果重传次数超过系统规定的最大重传次数,系统将该连接信息从半连接队列中删除。注意,每次重传等待的时间不一定相同。半连接存活时间:是指半连接队列的条目存活的最长时间,也即服务从收到SYN包到确认这个报文无效的最长时间,该时间值是所有重传请求包的最长等待时间总和。有时我们也称半连接存活时间为Timeout时间、SYN_RECV存活时间。[1] * SYN:同步标志同步序列编号(Synchronize Sequence Numbers)栏有效。该标志仅在三次握手建立TCP连接时有效。它提示TCP连接的服务端检查序列编号,该序列编号为TCP连接初始端(一般是客户端)的初始序列编号。在这里,可以把TCP序列编号看作是一个范围从0到4,294,967,295的32位计数器。通过TCP连接交换的数据中每一个字节都经过序列编号。在TCP报头中的序列编号栏包括了TCP分段中第一个字节的序列编号。*ACK:确认标志确认编号(Acknowledgement Number)栏有效。大多数情况下该标志位是置位的。TCP报头内的确认编号栏内包含的确认编号(w+1,Figure-1)为下一个预期的序列编号,同时提示远端系统已经成功接收所有数据。*RST:复位标志复位标志有效。用于复位相应的TCP连接。*URG:紧急标志紧急(The urgent pointer) 标志有效。紧急标志置位,*PSH:推标志该标志置位时,接收端不将该数据进行队列处理,而是尽可能快将数据转由应用处理。在处理 telnet 或 rlogin 等交互模式的连接时,该标志总是置位的。*FIN:结束标志带有该标志置位的数据包用来结束一个TCP回话,但对应端口仍处于开放状态,准备接收后续数据。 [编辑本段]三次握手协议-工作原理  由于TCP 需要时刻跟踪,这需要额外开销,使得TCP 的格式有些显得复杂。下面就让我们看一个TCP 的三次握手协议经典案例,这是后来被称为MITNICK 攻击中KEVIN 开创了两种攻击技术:TCP 会话劫持和SYN FLOOD(同步洪流)在这里我们讨论的是TCP 会话劫持的问题。先让我们明白TCP 建立连接的基本简单的过程。为了建设一个小型的模仿环境我们假设有3 台接入互联网的机器。A 为攻击者操纵的攻击机。B 为中介跳板机器(受信任的服务器)。C 为受害者使用的机器(多是服务器),这里把C 机器锁定为目标机器。A 机器向B机器发送SYN 包,请求建立连接,这时已经响应请求的B 机器会向A 机器回应SYN/ACK表明同意建立连接,当A 机器接受到B 机器发送的SYN/ACK 回应时,发送应答ACK 建立A 机器与B 机器的网络连接。这样一个两台机器之间的TCP 通话信道就建立成功了。B 终端受信任的服务器向C 机器发起TCP 连接,A 机器对服务器发起SYN 信息,使C 机器不能响应B 机器。在同时A 机器也向B 机器发送虚假的C 机器回应的SYN 数据包,接收到SYN 数据包的B 机器(被C 机器信任)开始发送应答连接建立的SYN/ACK 数据包,这时C 机器正在忙于响应以前发送的SYN 数据而无暇回应B 机器,而A 机器的攻击者预测出B 机器包的序列号(现在的TCP 序列号预测难度有所加大)假冒C 机器向B 机器发送应答ACK 这时攻击者骗取B 机器的信任,假冒C 机器与B 机器建立起TCP 协议的对话连接。这个时候的C 机器还是在响应攻击者A 机器发送的SYN 数据。 TCP 协议栈的弱点:TCP 连接的资源消耗,其中包括:数据包信息、条件状态、序列号等。通过故意不完成建立连接所需要的三次握手过程,造成连接一方的资源耗尽。通过攻击者有意的不完成建立连接所需要的三次握手的全过程,从而造成了C 机器的资源耗尽。序列号的可预测性,目标主机应答连接请求时返回的SYN/ACK 的序列号是可预测的。
      为了消除重复连接请求的三次握手方法是怎样工作的?

      tcp 保持长连接 需要 占用 网络带宽吗?

      需要。 TCP协议中有长连接和短连接之分。短连接在数据包发送完成后就会自己断开,长连接在发包完毕后,会在一定的时间内保持连接,即我们通常所说的Keepalive(存活定时器)功能。www.2cto.com 默认的Keepalive超时需要7,200,000 milliseconds,即2小时,探测次数为5次。它的功效和用户自己实现的心跳机制是一样的。开启Keepalive功能需要消耗额外的宽带和流量,尽管这微不足道,但在按流量计费的环境下增加了费用,另一方面,Keepalive设置不合理时可能会因为短暂的网络波动而断开健康的TCP连接。
      tcp 保持长连接 需要 占用 网络带宽吗?

      在TCP/IP连接的时候,消耗,电脑的CPU和内存资源吗?

      是要消耗的。cup主要用来生成和处理数据,内存在TCP/IP连接时候用做缓冲来处理数据。
      当然会消耗,而且和你的工作量成正比 比如你从网上邻居拷东西的时候,电脑会很卡,就这个道理
      肯定有消耗。
      针对单机来说,我个人认为 只要有工作量的产生 多少都会有消耗,只是多少问题。 不知这么解释您能否明白!
      在TCP/IP连接的时候,消耗,电脑的CPU和内存资源吗?

      TCP 连接详解

      1、先提出一个问题, 可以不进行三次握手直接往服务端发送数据包吗?是不可以的,也是可以的;1)不可以是因为现在的TCP连接标准和规范要求传输数据前先确认两端的状态,有一端状态不OK的话,发数据包有什么用呢;2)说可以是站在网络连接的角度,像 UDP 协议;2、TCP三次握手1)标志位、随机序列号和确认序列号是在数据包的 TCP 首部里面;2)几个状态是指客户端和服务端连接过程中 socket 状态;3)第一次握手,客户端向服务端发送数据包,该数据包中 SYN 标志位为 1,还有随机生成的序列号c_seq,客户端状态改为 SYN-SENT;4)第二次握手,服务端接收到客户端发过来的数据包中 SYN 标志位为 1,就知道客户端想和自己建立连接,服务端会根据自身的情况决定是拒绝连接,或确定连接,还是丢弃该数据包;拒绝连接,会往客户端发一个数据包,该数据包中 RST 标志位为 1,客户端会报 Connection refused;丢弃客户端的数据包,超过一定时间后客户端会报 Connection timeout;确定连接时会往客户端发一个数据包,该数据包中 ACK 标志位为 1,确认序列号 ack=c_seq+1,SYN 标志位为 1,随机序列号 s_seq,状态由 LISTEN 改为 SYN-RCVD;5)第三次握手,客户端接收到数据包会做校验,校验ACK标志位和确认序列号 ack=c_seq+1,如果确定是服务端的确认数据包,改自己的状态为 ESTABLISHED,并给服务端发确认数据包;6)服务端接到客户端数据包,会校验ACK标志位和确认序列号 ack=s_seq+1,改自己的状态为 ESTABLISHED,之后就可以进行数据传输了;7)建立连接时的数据包是没有实际内容的,没有应用层的数据;8)建立连接之后发起的请求数据包,每个数据包都会封装各层协议的头部信息,标志位ACK为1,其他标志位变动;9)网络进程间的通信,一台服务器内部的进程间通信不用这样;3、TCP 连接三次握手抓包1)Socket 在 linux 系统中是一种特殊的文件,因为 linux 系统的理念就是【一切皆文件】,是系统内核级的功能;2)以上定义比较具体,可以抽象来理解,是一个内核级的用于通信的功能层,包含一组接口函数,这些函数实际就是操作 socket 文件句柄文件描述符;一个 TCP 连接由四要素【源IP、源Port、目标IP、目标Port】唯一标识,也即 socket 由这四要素唯一确定;一个 TCP 连接的建立也就是客户端、服务端创建了相对应的一对 socket,客户端和服务端之间的通信也就是这对 socket 间的通信(物理层面是网卡在发送/接收比特流数据);3)一个服务与另一个服务建立连接,他们的端口是什么呢?客户端发出请求端口号是随机的,服务端是进程监听的端口号;2、socket 主要函数介绍1、进程通信,一个进程只有一个监听 socket,connect socket 是针对一个客户的一个连接的,有很多个; 2、connect 函数内部在发起请求前会找系统随机一个端口号; 3、连接建立后,客户端发起请求传输数据,服务端会直接交给 connect socket 处理,不会交给监听 socket 处理;4、监听 socket 在处理客户端请求时,如果此时其他客户端发请求过来,监听 socket 是没法处理的,此时系统会维护请求队列由 backlog 参数指定;全连接队列(completed connection queue)半连接队列(incomplete connection queue)Linux 内核 2.2 版本之前,backlog 的大小等于全连接队列和半连接队列之和;Linux 内核 2.2 版本之后,backlog 的大小之和全连接队列有关系:半连接队列大小由 /proc/sys/net/ipv4/tcp_max_syn_backlog 文件指定,可以开很大;全连接队列大小由 /proc/sys/net/core/somaxconn 文件和 backlog 参数指定,取两个中的最小值;tomcat acceptCount 就是配置全连接队列大小;3、socket 函数在建立连接和数据传输的大概使用情况4、TCP首部结构1)2的16次方等于 65536,所以系统中端口号的限制个数为 65536,一般1024以下端口被系统占用;2)标志位这里是 6 个,还有其他标志位的,只是这 6 个标志位常用;3)seq 序列号,ack 确认序列号,序列号在数据传输时分包用到。三次握手时 seq 序列号是随机的,没有实际意义;4)TCP 包首部后面接着的是 IP 包首部,再紧接着的是以太网包首部,其实都是加 0101010101 二进制位;几个常用标志位,首先一个标志位占一个 bit 位,只能是二进制中的 1 或 0;1)SYN,简写 S,请求标志位,用来建立连接。在TCP三次握手中收到带有该标志位的数据包,表示对方想与己方建立连接;2)ACK,简写【.】,请求确认/应答标志位,用于对对方的请求进行应答,对方收到含该标志位的数据包,会知道己方存在且可用。也会用在连接建立之后,己方发送响应数据给对方的数据包中;3)FIN,简写 F,请求断开标志位,用于断开连接。对方收到己方的含该标志位的数据包,就知道己方想与它断开连接,不再保持连接;4)RST,简写 R,请求复位标志位,因网络或己方服务原因导致有数据包丢失,己方接收到的数据包序列号与上一个数据包的序列号不衔接,那己方会发送含该标志位的数据包告诉对方,对方接收到含该标志位的数据包就知道己方要求它重新三次握手建立连接并重新发送丢失的数据包,一般断点续传会用到该标志位;还有就是如果对方发过来的数据错了,有问题,己方也会发送含该标志位的数据包;5)PSH,简写 P,推送标志位,表示收到数据包后要立即交给应用程序去处理,不应该放在缓存中,read()/write() 都有缓存区;6)URG,简写 U,紧急标志位,该标志位表示 tcp 包首部中的紧急指针域有效,督促中间层尽快处理;7)ECE,在保留位中;8)CWR,在保留位中;5、TCP 抓包1)服务端会根据自身情况,没有要处理的数据时会把第二次和第三次挥手合并成一次挥手,此时标志位 FIN=1 / ACK=1;2)MSL 是 Maximum Segment Lifetime 缩写,指数据包在网络中最大生存时间,RFC 建议是 2分钟;详细描述:1)客户端、服务端都可以主动发起断开连接;2)第一次挥手,客户端向服务端发送含 FIN=1 标志位的数据包,随机序列号 seq=m,此时客户端状态由 ESTABLISHED 变为 FIN_WAIT_1;3)第二次挥手,服务端收到含 FIN=1 标志位的数据包,就知道客户端要断开连接,服务端会向客户端发送含 ACK=1 标志位的应答数据包,确认序列号 ack=m+1,此时服务端状态由 ESTABLISHED 变为 CLOSE_WAIT;4)客户端收到含 ACK=1 标志位的应答数据包,知道服务端的可以断开的意思,此时客户端状态由 FIN_WAIT_1 变为 FIN_WAIT_2;(第一、二次挥手也只是双方交换一下意见而已)5)第三次挥手,服务端处理完剩下的数据后再次向客户端发送含 FIN=1 标志位的数据包,随机序列号 seq=n,告诉客户端现在可以真正的断开连接了,此时服务端状态由 CLOSE_WAIT 变为 LAST_ACK;6)第四次挥手,客户端收到服务端再次发送的含 FIN=1 标志位的数据包,就知道服务端处理好了可以断开连接了,但是客户端为了慎重起见,不会立马关闭连接,而是改状态,且向服务端发送含 ACK=1 标志位的应答数据包,确认序列号 ack=n+1,此时客户端状态由 FIN_WAIT_2 变为 TIME_WAIT;等待 2 个MSL时间还是未收到服务端发过来的数据,则表明服务端已经关闭连接了,客户端也会关闭连接释放资源,此时客户端状态由 TIME_WAIT 变为 CLOSED;也就是说 TIME_WAIT 状态存在时长在 1~4分钟;7)服务端收到含 ACK=1 标志位的应答数据包,知道客户端确认可以断开了,就立即关闭连接释放资源,此时服务端状态由 LAST_ACK 变为 CLOSED;SYN 洪水攻击(SYN Flood)是一种 DoS攻击(拒绝服务攻击),大概原理是伪造大量的TCP请求,服务端收到大量的第一次握手的数据包,且都会发第二次握手数据包去回应,但是因为 IP 是伪造的,一直都不会有第三次握手数据包,导致服务端存在大量的半连接,即 SYN_RCVD 状态的连接,导致半连接队列被塞满,且服务端默认会发 5 个第二次握手数据包,耗费大量 CPU 和内存资源,使得正常的连接请求进不来;
      TCP 连接详解

      本文由 在线网速测试 整理编辑,转载请注明出处。

          热门文章

          文章分类