tcp三次断开是什么问题(POS机tcp连接断开是什么意思)

      最后更新:2023-06-10 08:03

      TCP协议中的三次握手和四次断开的标志是什么?

      TCP协议为传输控制协议,是一种基于可靠机制的传输协议。。。 标志就是数据被完整的送到目的地,如果中途丢包会重传该数据段,以保证数据的完整性。
      TCP协议中的三次握手和四次断开的标志是什么?

      为什么TCP连接需要三次握手分开需要四次握

      参考下面的图,可以理解一下。不过因为被动断开方可以把FIN和ACK用一个包发送,所以多数教材或资料上也是把断开理解为三次握手。1、当主机A确认发送完数据且知道B已经接受完了,想要关闭发送数据口(当然确认信号还是可以发),就会发FIN给主机B。2、主机B收到A发送的FIN,表示收到了,就会发送ACK回复。3、但这是B可能还在发送数据,没有想要关闭数据口的意思,所以FIN与ACK不是同时发送的,而是等到B数据发送完了,才会发送FIN给主机A。4、A收到B发来的FIN,知道B的数据也发送完了,回复ACK, A等待2MSL以后,没有收到B传来的任何消息,知道B已经收到自己的ACK了,A就关闭链接,B也关闭链接了。
      TCP建立连接要进行3次握手,而断开连接要进行4次,这是由于TCP的半关闭造成的,因为TCP连接是全双工的( 即数据可在两个方向上同时传递)所以进行关闭时每个方向上都要单独进行关闭,这个单方向的关闭就叫半关闭.关闭的方法是一方完成它的数据传输后,就发送一个FIN来向另一方通告将要终止这个方向的连接.当一端收到一个FIN,它必须 通知应用层TCP连接已终止了这个方向的数据传送,发送FIN通常是应用层进行关闭的结果.
      为什么TCP连接需要三次握手分开需要四次握

      tcp连接的断开

      TCP的断开就是经过四次挥手: 这是正常的情况,客户端主动tcp连接断开的过程。客户端先是发送一个FIN为一的报文,然后进入FIN_WAIT_1的状态。服务器收到FIN报文后,发送一个ACK报文,然后进入CLOSED_WAIT状态。客户端收到服务器的ACK报文进入FIN_WAIT_2状态。等到服务器觉得他数据处理好了,可以关闭的时候,会发送一个FIN报文,然后进入LAST_ACK。等待最后一个应答。让客户端收到服务器FIN报文,就进入TIME_WAIT状态了,随后发送最后一个ACK报文,然后close。客户端再等待2msl后也自己主动关闭。而只有主动关闭的情况下,才会有TIME_WAIT。那么为什么四次挥手需要四次呢?三次握手其实就是在第二次把ACK和SYN两个报文合并成一个发,但是断开的过程可能还有一方需要处理下数据,需要延长点时间,等处理好再发FIN,所以就比三次握手多了一次。这里还有一个问题,为什么需要TIME_WAIT,然后到close需要2msl的时间呢?先说下什么是MSL,也就是报文的最长生存时间,超过这个时间的报文就要被丢弃掉。tcp是基于ip的,ip上有个生存时间TTL,是ip报文可以经过的最大路由数量,每经过一个路由就减1,减到0,ip报文就丢弃掉,然后通过ICMP通知源主机,我们的ping也算是经过这个。当然msl和ttl还是有区别的,msl是时间,ttl是路由数量,msl也是大于等于ttl的。在linux中,2msl默认是60秒。前文也说了,只有主动发起断开连接的进程才会有time wait状态。time wait+2msl有两个原因:1.防止旧连接的数据包像这个seq 301的包,如果因为网络的原因被延迟了,而没有time wait或者很短,那么连接断开后,又建立新的连接,这个时候这个包到了,可能就导致数据紊乱了。而2msl可以保证两个方向的包在断开前丢弃掉。2.保证正确的断开连接2msl的时间也是保证第四个报文的ack可以被被动关闭方接收到。如图,假设time wait比较短或者没有,当最后的ack报文丢失的时候。客户端已经close了,而服务器一直处于last ack的状态。这样连接就不能正常断开了。而如果有time wait +2msl这个情况就可以避免。假设服务器没有收到最后一个ack报文,服务器会重发FIN等待客户端的ack。这样就可以保证不会出现一端断开,另外一端没有断开的情况了。有时候我们在服务器上会看到很多time wait。time wait一般就是服务器主动发起的断开请求才会产生的状态。所以time wait过多,第一个是系统资源会大量消耗,还有是端口如果占的太多,会导致没办法创建新连接。这个时候可以把linux的net.ipv4.tcp_tw_reuse开启,置为1,可以复用time wait超过1秒的连接。这边再说说tcp的保活机制。也就是怎么长期维持客户端和服务端的连接。在一个时间段内,如果没有连接等相关活动,tcp的保活机制会定期发探测报文,如果连续几个探测报文就没有回应,就将错误信息报告给系统,系统通知上层应用。在 Linux 内核可以有对应的参数可以设置保活时间、保活探测的次数、保活探测的时间间隔,以下都为默认值:tcp_keepalive_time=7200:表示保活时间是 7200 秒(2⼩时),也就 2 小时内如果没有任何连接相关的活动,则会启动保活机制tcp_keepalive_intvl=75:表示每次检测间隔 75 秒;tcp_keepalive_probes=9:表示检测 9 次无响应,认为对⽅方是不不可达的,从⽽而中断本次的连接。也就是说在 Linux 系统中,最少需要经过 2 小时 11 分 15 秒才可以发现一个「死亡」连接。 当然这个时间也可以自己配置。
      tcp连接的断开

      简述TCP三次握手四次挥手过程及各过程中客户端和服务器端的状态。

      #三次握手 客户端向服务器端发送SYN包,客户端进入SYN_SEND状态服务器端收到客户端发送的包返回ACK+SYN包,服务器端进入SYN_RECV状态客户端收到服务器端返回的包再发回ACK包,客户端进入ESTABLISHED状态,服务器端收到包也进入ESTABLISHED状态客户端状态:SYN_SENDESTABLISHED服务器端状态:SYN_RCVEESTABLISHED#四次挥手客户端发送FIN包询问服务器端是否能断开,客户端进入FIN_WAIT_1状态服务器端收到客户端发送的包并返回ACK包,服务器端进入CLOSE_WAIT状态服务器端准备好断开后,发送FIN包给客户端,服务器端进入LAST_ACK状态客户端收到服务器端发送的包后返回ACK包,客户端进入TIME_WAIT状态,服务器端收到包后进入CLOSED状态客户端状态:FIN_WAIT_1FIN_WAIT_2TIME_WAIT服务器端状态:CLOSE_WAITLAST_ACKCLOSED 如果有什么不懂的话可以去看看《Linux就该这么学》这本书,非常适合新手学习Linux。
      三次握手: 第一次握手:客户端发送syn包(syn=x)到服务器,并进入SYN_SEND状态,等待服务器确认;第二次握手:服务器收到syn包,必须确认客户的SYN(ack=x+1),同时自己也发送一个SYN包(syn=y),即SYN+ACK包,此时服务器进入SYN_RECV状态;第三次握手:客户端收到服务器的SYN+ACK包,向服务器发送确认包ACK(ack=y+1),此包发送完毕,客户端和服务器进入ESTABLISHED状态,完成三次握手。握手过程中传送的包里不包含数据,三次握手完毕后,客户端与服务器才正式开始传送数据。理想状态下,TCP连接一旦建立,在通信双方中的任何一方主动关闭连接之前,TCP 连接都将被一直保持下去。四次挥手与建立连接的“三次握手”类似,断开一个TCP连接则需要“四次握手”。第一次挥手:主动关闭方发送一个FIN,用来关闭主动方到被动关闭方的数据传送,也就是主动关闭方告诉被动关闭方:我已经不 会再给你发数据了(当然,在fin包之前发送出去的数据,如果没有收到对应的ack确认报文,主动关闭方依然会重发这些数据),但是,此时主动关闭方还可 以接受数据。第二次挥手:被动关闭方收到FIN包后,发送一个ACK给对方,确认序号为收到序号+1(与SYN相同,一个FIN占用一个序号)。第三次挥手:被动关闭方发送一个FIN,用来关闭被动关闭方到主动关闭方的数据传送,也就是告诉主动关闭方,我的数据也发送完了,不会再给你发数据了。 第四次挥手:主动关闭方收到FIN后,发送一个ACK给被动关闭方,确认序号为收到序号+1,至此,完成四次挥手。
      简述TCP三次握手四次挥手过程及各过程中客户端和服务器端的状态。

      什么是tcp三次握手协议的缺陷造成的

      答: 服务器的SYN泛洪攻击。大致是这样的,在三次握手过程当中,服务器在第二次握手中就进行TCP相关资源分配,而对于一些恶意程序来说,它可以伪造大量的SYN,然后使得服务器不断地为其分配资源,而恶意程序不对其发送ACK确认,因此导致大量的服务器资源被耗尽。
      什么是tcp三次握手协议的缺陷造成的

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

          热门文章

          文章分类