网站悬浮窗,互站网源码,怎么优化网站打开速度,秦皇岛市建设局网站关于装配式专家TCP状态机介绍
在网络协议栈中#xff0c;目前只有TCP提供了一种面向连接的可靠性数据传输。而可靠性#xff0c;无非就是保证#xff0c;我发给你的#xff0c;你一定要收到。确保中间的通信过程中#xff0c;不会丢失数据和乱序。在TCP保证可靠性数据传输的实现来看目前只有TCP提供了一种面向连接的可靠性数据传输。而可靠性无非就是保证我发给你的你一定要收到。确保中间的通信过程中不会丢失数据和乱序。在TCP保证可靠性数据传输的实现来看超时重传、序列号及数据的应答 这三个特征 就是实现可靠性的最基本保证而对于tcp窗口大小等等设置也是保证可靠性的一个方面。所有的目的只为一个保证传输数据的完整性。为了解决传输线路的不稳定性造成数据包的丢失情况tcp 使用了发送方超时重传和接收方数据应答的策略。概括而言就是一种“状态协议“保证通信双方数据收发的一致性。 TCP_CLOSE关闭状态一个新建的TCP socket 会处于该状态。TCP_LISTEN 监听状态一般服务器端套接字在调用Listen系统调用后即处于该状态。TCP_SYN_SENT同步信号已经发送状态这个状态一般是指客户端发送SYN建立连接的同步数据包后所处的状态tcp三次握手的第一个包。在接收到远端服务器端的应答后即从该状态进入TCP_ESTABLISHED状态。TCP_SYN_RECEIVED:同步信号已经接受状态服务器端在接受到远端客户端SYN数据包后进行相应的处理创建通信套接字等然后发送应答数据包tcp三次握手的第二个包并将新创建的通信套接字状态设置为TCP_SYN_RECEIVED在接受到客户端的应答后即进入TCP_ESTABLISED状态。TCP_ESTABLISED:建立连接状态这是双方进行正常通信所处的状态。TCP_FIN_WAIT_1本地发送FIN(用于结束连接的数据包后即可进入该状态等待对方的应答。一般一端发送完其所要发送的数据后即可发送FIN数据包此时发送通道被关闭但仍可继续接受远端发送的数据包。在接受到远端发送的对于FIN数据包的应答后将进入TCP_FIN_WAIT_2状态。TCP_FIN_WAIT_2:进入该状态表示本地已经接受到远端发送的对于本地之前发送的FIN数据包的应答。进入该状态后本地仍然可以继续接受远端发送给本地的数据包。在接受到远端发送的FIN数据包后表示远端也已经发送完数据本地将发送一个应答数据包并进入TCP_TIME_WAIT状态。TCP_TIME_WAIT状态存在的时间被称为2MSL时间这一方面是为避免本地发送的应答数据包丢失另一方面避免一个新创建的套接字接收到旧套接字中遗留的数据包。TCP_TIME_WAIT该转状态呗称为2MSL等待状态。如果在此期间接收到远端发送的FIN数据包则表示之前在TCP_FIN_WAIT_2状态发送的ACK应答数据包在传输中丢失或者长时间被延迟从而造成了远端重新发送了FIN数据包此时重复ACK应答数据包。一旦2MSL时间到期则将进入TCP_CLOSED状态即完成关闭操作。TCP_CLOSE_WAIT该状态存在于后关闭的一端。当接收到远端发送的FIN数据包后本地发送一个ACK应答数据包并将该套接字状态从TCP_ESTABLISED设置为TCP_CLOSE_WAIT。本地可以继续向远端发送数据包在发送完所有的数据后本地将发送一个FIN数据包关闭本地发送通道并将状态设置为TCP_LAST_ACK状态等待远端对FIN数据包的应答数据包。TCP_CLOSING:如果通信双方同时发送FIN数据包则同时进行关闭操作则双方将同时进入TCP_CLOSING状态。具体的本地发送一个FIN数据包以结束本地数据包发送如果在等待应答期间接收到远端发送的FIN数据包则本地将状态设置为TCP_CLOSING状态。在接收到应答后再继续装入到TCP_CLOSE_WAIT状态。TCP_LAST_ACK作为后关闭的一方在发送FIN数据包后即进入TCP_LAST_ACK状态。此时等待远端发送应答数据包在接收到应答数据包后即完成关闭操作进入TCP_CLOSE状态。
三次握手 三次握手过程
三次握手过程是客户端主动向正在监听的服务发起交换序号、建立连接的过程三次握手过程如下:
第一次握手 客户端主动发送SYN包到服务器其中包含客户端的初始序号seqx并进入SYN_SENT状态等待服务器确认。其中SYN1ACK0表示这是一个TCP连接请求数据报文序号seqxx是随机数表明传输数据时的第一个数据字节的序号是x。第二次握手 服务器收到请求后必须确认客户的数据包同时自己也发送一个SYN包即SYNACK包此时服务器进入SYN_RECV状态。其中确认报文段中标识位SYN1ACK1表示这是一个TCP连接响应数据报文并含服务端的初始序号seqyy是随机数以及服务器对客户端初始序号的确认号ack(服务器)seq(客户端)1x1。第三次握手 客户端收到服务器的SYNACK包向服务器发送确认包seqx1acky1此包发送完毕客户端和服务器进入ESTAB_LISHED(TCP连接成功)状态完成三次握手。
三次握手交换各自的序号建立起连接。
握手过程为什么是三次而不是两次、四次
TCP作为一种可靠传输控制协议其核心思想既要保证数据可靠传输又要提高传输的效率而用三次恰恰可以满足以上两方面的需求
为了实现可靠数据传输 TCP 协议的通信双方 都必须维护一个序列号 以标识发送出去的数据包中 哪些是已经被对方收到的。 三次握手的过程即是通信双方相互告知序列号起始值 并确认对方已经收到了序列号起始值的必经步骤
两次握手的场景
两次握手过程其实只有三次握手的前两次握手没有第三次握手
两次握手至多只有连接发起方的起始序列号能被确认 另一方选择的序列号则得不到确认。
想象一个场景client向server发送一个连接请求由于一些原因导致client发出的连接请求在一个网络节点逗留了比较多的时间。此时client会将此连接请求作为无效处理 又重新向server发起了一次新的连接请求server正常收到此连接请求后建立了连接数据传输完成后释放了连接。如果此时client发出的第一次请求又到达了serverserver会以为client又发起了一次连接请求。如果是两次握手此时连接就建立了server会维持连接一直等待client发送数据从而白白浪费server的资源。 如果是三次握手由于client没有发起连接请求也就不会理会server的连接响应server没有收到client的确认连接就会关闭掉本次连接。如果第一次握手大量延时或者第二次握手大量丢失 就会造成“SYN的洪水攻击”效果。
四次握手的场景
四次握手其实就是将第二次握手发送ACK与SYN分开进行这样子有违高效的原则。
序列号与确认号
wireshark中序列号默认显示相对序列号序列号是从0开始实际序列号是在三次握手过程双方随机选取的。可以通过设置来显示真实的序列号【编辑】-【首选项】-【Protocols】-【TCP】-【Relative sequence numbers(Requires “Analyer TCP sequence numbers”)】复选框去掉通过流量图来分析序列号与确认号。【统计】-【流量图】-【流类型】选择【TCP Flows】
通过HTTP请求的TCP流量图分析序列号与确认号
第一次握手client发送SYN包请求建立TCP连接初始化序列号seq 4129057982,随机生成的 确认号ack 0一般都是0;第二次握手server对请求进行确认ack 4129057982 1SYN虽没负载数据但消耗一个序列号同时进行SYNseq 4200111240随机第三次握手client对server的SYN包发送ACK包ack 4200111240 1seq 4129057983第四个包client发送负载725字节的HTTP请求包seq 4129057983注意ACK没有消耗seq序号跟第三次握手的seq一样, ack 4200111241第五个包server响应tcp确认包seq 4200111241, ack 4129057983 725 4129058708
四次挥手
四次挥手主要是关闭tcp建立起来的连接释放相关资源
四次挥手过程
在实际应用中客户端主动关闭到服务器的连接服务器在检测到客户端关闭连接后关闭对应的连接。
第一次挥手: 客户端发送一个FIN用来关闭客户端到服务器的数据传送服务器的确认。其中终止标志位FIN1序列号sequ.第二次挥手: 服务器收到这个FIN它发送一个ACK确认ack为收到的序号加一。第三次挥手: 关闭服务器到客户端的连接发送一个FIN给客户端。第四次挥手: 客户端收到FIN后并发回一个ACK报文确认并将确认序号seq设置为收到序号加一。首先进行关闭的一方将执行主动关闭而另一方执行被动关闭。
客户端发送FIN后进入终止等待状态服务器收到客户端连接释放报文段后就立即给客户端发送确认服务器就进入CLOSE_WAIT状态此时TCP服务器进程就通知高层应用进程因而从客户端到服务器的连接就释放了。此时是“半关闭状态”即客户端不可以发送给服务器服务器可以发送给客户端。 此时如果服务器没有数据报发送给客户端其应用程序就通知TCP释放连接然后发送给客户端连接释放数据报并等待确认。客户端发送确认后进入TIME_WAIT状态但是此时TCP连接还没有释放然后经过等待计时器设置的2MSL后才进入到CLOSED状态。
2.为什么需要2MSL时间 首先MSL即Maximum Segment Lifetime就是最大报文生存时间是任何报文在网络上的存在的最长时间超过这个时间报文将被丢弃。《TCP/IP详解》中是这样描述的MSL是任何报文段被丢弃前在网络内的最长时间。RFC 793中规定MSL为2分钟实际应用中常用的是30秒、1分钟、2分钟等。
TCP的TIME_WAIT需要等待2MSL当TCP的一端发起主动关闭三次挥手完成后发送第四次挥手的ACK包后就进入这个状态等待2MSL时间主要目的是防止最后一个ACK包对方没有收到那么对方在超时后将重发第三次握手的FIN包主动关闭端接到重发的FIN包后可以再发一个ACK应答包。在TIME_WAIT状态时两端的端口不能使用要等到2MSL时间结束才可以继续使用。当连接处于2MSL等待阶段时任何迟到的报文段都将被丢弃。
3.为什么是四次挥手而不是三次或是五次、六次 双方关闭连接要经过双方都同意。所以首先是客服端给服务器发送FIN要求关闭连接服务器收到后会发送一个ACK进行确认。服务器然后再发送一个FIN客户端发送ACK确认并进入TIME_WAIT状态。等待2MSL后自动关闭。
总结 1为了保证客户端发送的最后一个ACK报文段能够到达服务器。即最后一个确认报文可能丢失服务器会超时重传然后服务器发送FIN请求关闭连接客户端发送ACK确认。一个来回是两个报文生命周期。
如果没有等待时间发送完确认报文段就立即释放连接的话服务器就无法重传因此也就收不到确认就无法按步骤进入CLOSED状态即必须收到确认才能close。 2防止已经失效的连接请求报文出现在连接中。经过2MSL在这个连续持续的时间内产生的所有报文段就可以都从网络消失。
参考
TCP状态机状态解析TCP 为什么三次握手而不是两次握手正解版TCP 为什么是三次握手而不是两次或四次TCP为什么是三次握手和四次挥手SDN手册
