tcp被动连接(tcp连接app下载)

      最后更新:2024-04-12 06:10:39 手机定位技术交流文章

      TCP三次握手原理

      本文主要内容1、TCP数据包格式TCP数据包格式如下:注意到中间还有几个标志位:数据包格式当中,最重要的是理解序号和确认序号。TCP为什么是稳定可靠的,与序号与确认序号这套机制紧密相关,这也是TCP的精髓。2、TCP的三次握手众所周知,TCP协议是可靠的,而UDP协议是不可靠的。在一些场景中必须用TCP,比如说用户登录,必须给出明确答复是否登录成功等。而有些场景中,用户是否接收到数据则不那么关键,比如网络游戏当中,玩家射出一颗子弹,另外的玩家是否看到,完全取决于当前网络环境,如果网络卡顿,就会有玩家已经被射杀,但界面仍然刷新不出来的情况。这种情形适合UDP。为了保证TCP协议可靠,在建立连接之时就要得到保证。最初两端的TCP进程都处于CLOSED关闭状态,A主动打开连接,而B被动打开连接。(A、B关闭状态CLOSED——B收听状态LISTEN——A同步已发送状态SYN-SENT——B同步收到状态SYN-RCVD——A、B连接已建立状态ESTABLISHED)B服务器进程就处于LISTEN(收听)状态,等待客户的连接请求。若有,则作出响应。3、TCP的传输和确认TCP 传输的可靠性,可以用一句话归结:每收到对方数据,就发送 ACK 进行确定,发送方发送后没有收到 ACK 就隔一段时间重发。就是 A 向 B 发送消息(下面将 TCP 的报文直接看做是消息,消息一词跟 TCP 报文混用),B 收到消息后需要向 A 发送 ACK。这个 ACK 相当于返回结果,没有返回结果,A 就重新发送消息。归纳起来,A 有 3 种消息需要确认。另外 A 也可以发送 RST 消息,代表出错了。出错消息不需要确认。RST 也可以当成返回接口,替代正常的 ACK。返回 ACK,表示消息发送并处理成功,返回 RST 表示消息处理失败。因为通过网络传输,还有第三种结果,就是不确定成功失败。这样归纳起来。就有三种返回结果。这两种具体情况,A 根本识别不了,都只能重发。4、TCP的序号和确认序号A 向 B 发送消息,假如同时发送 a、b、c、d 消息,因为通过网络,这些消息的顺序并非固定的。而 B 返回 ACK 结果,这样就有一个问题,这个结果到底对应了哪个消息?另外当 A 超时重发后,原来的消息延时一段时候,又重新到达了 B,这样 B 就收到两条相同的消息,那么 B 怎么确定这两条消息是相同的呢?为了解决这个对应问题,每一条消息都需要有一个编号,返回结果也应该有一个编号。TCP 的序号可以看成是发送消息的编号,确认序号可以看成是返回结果的编号。有了编号,重复的消息才可以忽略,返回结果(ACK)才可以跟消息对应起来。当建立连接的时候,TCP 选定一个初始序号,之后每发送一个数据包(消息),就将序号递增,保证每发送不同的数据包,数据包的序号都是不同的。TCP 是这样处理的:SYN、FIN 也需要递增序号。不然 A 向 B 重发多个 SYN 或者 FIN, B 根本判断不了 SYN 是否相同,这样就不可以忽略重复的数据包了。当 TCP 发送 ACK 时,相当于返回结果,需要带有确认序号,以便跟发送的消息对应起来。当发送包编号为 a,递增长度为 len。其中 SYN 和 FIN 可以看成是递增长度为 1。这条消息可以这样表示为:现在来回顾三次握手过程。 A 发送序列号x给 B , B 回复 A 确认号 x+ 1,同时发送序列号 y, A 接收到 B 的回复后,再回复确认号 y+1,同时发送序列号 x+1。给对方的回复一定是接收到的序号加1(或者是数据长度),这样对方才能知道我已经收到了,这样才能保证TCP是可靠的。
      TCP三次握手原理

      TCP那些事儿

      目录:以前我也认为TCP是相当底层的东西,我永远不需要去了解它。虽然差不多是这样,但是实际生活中,你依然可能遇见和TCP算法相关的bug,这时候懂一些TCP的知识就至关重要了。(本文也可以引申为,系统调用,操作系统这些都很重要,这个道理适用于很多东西)这里推荐一篇小短文, 人人都应该懂点TCP使用TCP协议通信的双方必须先建立TCP连接,并在内核中为该连接维持一些必要的数据结构,比如连接的状态、读写缓冲区、定时器等。当通信结束时,双方必须关闭连接以释放这些内核数据。TCP服务基于流,源源不断从一端流向另一端,发送端可以逐字节写入,接收端可以逐字节读出,无需分段。需要注意的几点:TCP状态(11种):eg.以上为TCP三次握手的状态变迁以下为TCP四次挥手的状态变迁服务器通过 listen 系统调用进入LISTEN状态,被动等待客户端连接,也就是所谓的被动打开。一旦监听到SYN(同步报文段)请求,就将该连接放入内核的等待队列,并向客户端发送带SYN的ACK(确认报文段),此时该连接处于SYN_RECVD状态。如果服务器收到客户端返回的ACK,则转到ESTABLISHED状态。这个状态就是连接双方能进行全双工数据传输的状态。而当客户端主动关闭连接时,服务器收到FIN报文,通过返回ACK使连接进入CLOSE_WAIT状态。此状态表示——等待服务器应用程序关闭连接。通常,服务器检测到客户端关闭连接之后,也会立即给客户端发送一个FIN来关闭连接,使连接转移到LAST_ACK状态,等待客户端对最后一个FIN结束报文段的最后一次确认,一旦确认完成,连接就彻底关闭了。客户端通过 connect 系统调用主动与服务器建立连接。此系统调用会首先给服务器发一个SYN,使连接进入SYN_SENT状态。connect 调用可能因为两种原因失败:1. 目标端口不存在(未被任何进程监听)护着该端口被TIME_WAIT状态的连接占用( 详见后文 )。2. 连接超时,在超时时间内未收到服务器的ACK。如果 connect 调用失败,则连接返回初始的CLOSED状态,如果调用成功,则转到ESTABLISHED状态。客户端执行主动关闭时,它会向服务器发送一个FIN,连接进入TIME_WAIT_1状态,如果收到服务器的ACK,进入TIME_WAIT_2状态。此时服务器处于CLOSE_WAIT状态,这一对状态是可能发生办关闭的状态(详见后文)。此时如果服务器发送FIN关闭连接,则客户端会发送ACK进行确认并进入TIME_WAIT状态。流量控制是为了控制发送方发送速率,保证接收方来得及接收。接收方发送的确认报文中的窗口字段可以用来控制发送方窗口大小,从而影响发送方的发送速率。将窗口字段设置为 0,则发送方不能发送数据。如果网络出现拥塞,分组将会丢失,此时发送方会继续重传,从而导致网络拥塞程度更高。因此当出现拥塞时,应当控制发送方的速率。这一点和流量控制很像,但是出发点不同。流量控制是为了让接收方能来得及接收,而拥塞控制是为了降低整个网络的拥塞程度。TCP 主要通过四种算法来进行拥塞控制:慢开始、拥塞避免、快重传、快恢复。在Linux下有多种实现,比如reno算法,vegas算法和cubic算法等。发送方需要维护一个叫做拥塞窗口(cwnd)的状态变量,注意拥塞窗口与发送方窗口的区别:拥塞窗口只是一个状态变量,实际决定发送方能发送多少数据的是发送方窗口。为了便于讨论,做如下假设:发送的最初执行慢开始,令 cwnd=1,发送方只能发送 1 个报文段;当收到确认后,将 cwnd 加倍,因此之后发送方能够发送的报文段数量为:2、4、8 ...注意到慢开始每个轮次都将 cwnd 加倍,这样会让 cwnd 增长速度非常快,从而使得发送方发送的速度增长速度过快,网络拥塞的可能也就更高。设置一个慢开始门限 ssthresh,当 cwnd >= ssthresh 时,进入拥塞避免,每个轮次只将 cwnd 加 1。如果出现了超时,则令 ssthresh = cwnd/2,然后重新执行慢开始。在接收方,要求每次接收到报文段都应该对最后一个已收到的有序报文段进行确认。例如已经接收到 M1 和 M2,此时收到 M4,应当发送对 M2 的确认。在发送方,如果收到三个重复确认,那么可以知道下一个报文段丢失,此时执行快重传,立即重传下一个报文段。例如收到三个 M2,则 M3 丢失,立即重传 M3。在这种情况下,只是丢失个别报文段,而不是网络拥塞。因此执行快恢复,令 ssthresh = cwnd/2 ,cwnd = ssthresh,注意到此时直接进入拥塞避免。慢开始和快恢复的快慢指的是 cwnd 的设定值,而不是 cwnd 的增长速率。慢开始 cwnd 设定为 1,而快恢复 cwnd 设定为 ssthresh。发送端的每个TCP报文都必须得到接收方的应答,才算传输成功。TCP为每个TCP报文段都维护一个重传定时器。发送端在发出一个TCP报文段之后就启动定时器,如果在定时时间类未收到应答,它就将重发该报文段并重置定时器。因为TCP报文段最终在网络层是以IP数据报的形式发送,而IP数据报到达接收端可能是乱序或者重复的。TCP协议会对收到的TCP报文进行重排、整理,确保顺序正确。TCP报文段所携带的应用程序数据按照长度分为两种:交互数据和成块数据对于什么是粘包、拆包问题,我想先举两个简单的应用场景:对于第一种情况,服务端的处理流程可以是这样的:当客户端与服务端的连接建立成功之后,服务端不断读取客户端发送过来的数据,当客户端与服务端连接断开之后,服务端知道已经读完了一条消息,然后进行解码和后续处理...。对于第二种情况,如果按照上面相同的处理逻辑来处理,那就有问题了,我们来看看第二种情况下客户端发送的两条消息递交到服务端有可能出现的情况:第一种情况:服务端一共读到两个数据包,第一个包包含客户端发出的第一条消息的完整信息,第二个包包含客户端发出的第二条消息,那这种情况比较好处理,服务器只需要简单的从网络缓冲区去读就好了,第一次读到第一条消息的完整信息,消费完再从网络缓冲区将第二条完整消息读出来消费。第二种情况:服务端一共就读到一个数据包,这个数据包包含客户端发出的两条消息的完整信息,这个时候基于之前逻辑实现的服务端就蒙了,因为服务端不知道第一条消息从哪儿结束和第二条消息从哪儿开始,这种情况其实是发生了TCP粘包。第三种情况:服务端一共收到了两个数据包,第一个数据包只包含了第一条消息的一部分,第一条消息的后半部分和第二条消息都在第二个数据包中,或者是第一个数据包包含了第一条消息的完整信息和第二条消息的一部分信息,第二个数据包包含了第二条消息的剩下部分,这种情况其实是发送了TCP拆,因为发生了一条消息被拆分在两个包里面发送了,同样上面的服务器逻辑对于这种情况是不好处理的。我们知道tcp是以流动的方式传输数据,传输的最小单位为一个报文段(segment)。tcp Header中有个Options标识位,常见的标识为mss(Maximum Segment Size)指的是,连接层每次传输的数据有个最大限制MTU(Maximum Transmission Unit),一般是1500比特,超过这个量要分成多个报文段,mss则是这个最大限制减去TCP的header,光是要传输的数据的大小,一般为1460比特。换算成字节,也就是180多字节。tcp为提高性能,发送端会将需要发送的数据发送到缓冲区,等待缓冲区满了之后,再将缓冲中的数据发送到接收方。同理,接收方也有缓冲区这样的机制,来接收数据。发生TCP粘包、拆包主要是由于下面一些原因:既然知道了tcp是无界的数据流,且协议本身无法避免粘包,拆包的发生,那我们只能在应用层数据协议上,加以控制。通常在制定传输数据时,可以使用如下方法:写了一个简单的 golang 版的tcp服务器实例,仅供参考:例子参考和推荐阅读书目:注释:eg.
      TCP那些事儿

      TCP与UDP的区别

      在介绍TCP和UDP协议之前,有必要先了解下TCP/IP模型,TCP/IP中的两个具有代表性的传输协议:TCP和UDP。 TCP/IP 是互联网相关的各类协议族的总称,比如:TCP,UDP,IP,FTP,HTTP,ICMP,SMTP 等都属于 TCP/IP 族内的协议。TCP/IP模型是互联网的基础,它是一系列网络协议的总称。这些协议可以划分为四层,分别为链路层、网络层、传输层和应用层。TCP协议全称是传输控制协议,是一种面向连接、可靠的、基于字节流的传输层通信协议,由IETF的RFC 793定义。流就是指不间断的数据结构,可以想象成水管中的水流。TCP 在传送数据之前必须先建立连接,数据传送结束后要释放连接。TCP 不提供广播或多播服务。由于 TCP 要提供可靠的,面向连接的运输服务(TCP 的可靠体现在 TCP 在传递数据之前,会有三次握手来建立连接,而且在数据传递时,有确认、窗口、重传、拥塞控制机制,在数据传完后,还会断开连接用来节约系统资源),这难以避免增加了许多开销,如确认,流量控制,计时器以及连接管理等。这不仅使协议数据单元的首部增大很多,还要占用许多处理机资源。最初客户端和服务端都处于CLOSED(关闭)状态,客户端主动打开连接,服务端被动打开连接。--- 为了防止已经失效的连接请求又突然被服务端接收,从而产生错误。比如:A发出的第一个连接请求报文段并没有丢失,而是在网络结点时间长了,以致于延误到连接释放以后的某个时间段才到达B,但是B收到此失效的请求后,就误以为A又发出一次新的连接请求,于是就向A发出确认报文段,同意建立连接。出现失效的连接请求报文段被服务端接收的情况,从而产生错误。UDP协议全称是用户数据报协议,在网络中它与TCP协议一样用于处理数据包,是一种无连接的协议。在OSI模型中,在第四层——传输层,处于IP协议的上一层。UDP有不提供数据包分组、组装和不能对数据包进行排序的缺点,也就是说,当报文发送之后,是无法得知其是否安全完整到达的。UDP在传送数据之前不需要建立连接,远地主机在收到UDP报文后,不需要给出任何确认。虽然UDP不提供可靠交付,但在某些情况下,UDP却是最有效的一种比如QQ语音、QQ视频、直播等即时通信应用。因此 UDP 的头部开销小,只有八字节,相比 TCP 的至少二十字节要少得多,在传输数据报文时是很高效的1、连接的区别TCP面向连接,即发送数据之前先建立连接。UDP是无连接的,即发送数据之前是不需要建立连接的。2、安全方面的区别TCP是全双工的可靠通信,提供可靠的服务,通过TCP连接传送的数据,无差错,不丢失,不重复,且按序到达。使用流量控制和拥塞控制。UDP是不可靠传输,尽最大努力交付,即不保证可靠交付。3、传输效率的区别TCP传输效率较低。UDP传输效率高,适用于对高速传输和实时性有较高要求的通信或广播通信。4、连接对象数量的区别TCP连接只能是点到点,一对一的。UDP支持一对一,一对多,多对一和多对多的交互通信。5、传输方式的区别TCP面向字节流,实际上是TCP把数据看成一连串无结构的字节流。适用于要求可靠传输的应用比如文件传输等。UDP面向报文,没有拥塞控制,因此网络出现拥塞不会使源主机的发送速率降低,对实时应用很有用比如实时视频会议等。6、首部开销TCP首部开销最小20字节,最大60字节。 UDP首部开销小,只有8个字节。
      TCP与UDP的区别

      禁止tcp被动连接有何作用

      首先先要知道,TCP的ACK值,ACK=0,代表主动发起连接,ACK=1,代表被动连接。 比如,对你来说,被动连接就是外部网络设备对你的设备发起主动的TCP连接。这时候,这时候,外部网络设备ACK=0,而你的设备是被动的,所以ACK=1。禁止TCP被动连接可以保护内部网络的主机安全。防止黑客的TCP半连接攻击。一直以来,UDP相对于TCP来说,它是比较被人忽略的,即使是管理员在安全检查的时候,对UDP端口的开放情况也是很不太重视的,正因为如此,才使得UDP木马流行起来,Back Orifice木马就是一个很经典的例子.对于一名入侵者来说,对目标主机进行UDP端口进行探测是很有必要的,因为我们有可能从此得到很多有用的信息及 可以利用的漏洞,几个常见的开放在UDP上的服务有:69(TFTP) 小文件传输协议,其安全性极差,因为它不带任何的安全认证,经常用来夺取远程主机的密码文件.161(SNMP) 简单网络管理协议,在win2k上默认情况其community string密码为"public",在默认情况下,可以利用该服务得到系统版本,用户列表,共享列表,进程列表,所开服务...... 所以,要禁止UDP端口被动扫描。
      禁止tcp被动连接有何作用

      在TCP连接中,主动发起连接建立的进程是____,被动等待连接的进程是____。

      在TCP连接中,主动发起连接建立的进程是: 客户 被动等待连接的进程是: 服务器。
      在TCP连接中,主动发起连接建立的进程是____,被动等待连接的进程是____。

      本文由 在线网速测试 整理编辑,转载请注明出处,原文链接:https://www.wangsu123.cn/news/317958.html

          热门文章

          文章分类