TCP三次握手与四次挥手

- TCP协议头部的格式

这里写图片描述

  • Source Port与Destination Port:分别占用16位,表示源端口号和目的端口号;用于区别主机中不同的进程,而IP地址是用来区分不同的主机的,源端口号与目的端口号配合上IP首部的源IP地址和目的IP地址,就可以确定一个TCP连接。
  • Sequence Number:用来识别从TCP发端向TCP收端发送的数据字节流,它表示在这个报文段中的第一个数据字节在数据流的序号;主要用于解决网络乱报序的问题。
  • Acknowledge Number:32位确认序列号包含发送确认的一端所期望收到的下一个序号。因此,确认序号应当是上次已成功收到数据字节序号加1。不过,只有当标志位中的ACK标志位为1时,该确认序列号的字段才生效。主要用来解决不丢包的问题。
  • Offset:给出首部中32bit字的数量,需要这个值是因为任选字段的长度是可变的。这个字段占4bit(4bit可以表示为0-15的数字),因此最多可以表示15个32bit的字。故TCP最多有60字节的首部。正常的长度是20字节。
  • TCP Flags:TCP首部中有6个标志比特,它们中多个可以同时设置为1,主要用于操纵TCP的状态机,依次为URG,ACK,PSH,SYN,FIN
    • URG:此标志表示TCP包的紧急指针域有效,用来保证TCP连接不会被中断,并且督促中间层设备要尽快处理这些数据。
    • ACK:此标志表示应答域有效,就是前面所说的TCP应答号将会包含在TCP数据报中,有2个取值:0或者1, 1表示应答域有效,0表示无效。
    • PSH:这个标志表示Push操作。所谓Push操作就是指在数据包到达接受端以后,立即传送给应用程序,而不是在缓冲区中排队。
    • RST:表示同步序号,用来建立连接。SYN标志位与ACK标志位搭配使用,当连接请求的时候:SYN=1,ACK=0;当连接被响应的时候,SYN=1,ACK=1。这个标志的数据包经常被用来进行端口扫描。扫描者发送一个只有SYN的数据包,如果对方主机响应了一个数据包回来,表明这台主机存在这个端口。但是由于这种扫描方式只是对TCP三次握手的第一次握手,因此这种扫描的成功表示被扫描的主机不很安全,一台安全的主机将会强制要求严格的进行TCP的三次握手。
    • FIN:表示发送端已经达到了数据末尾,也就是说双方的数据传送完成,没有数据可以传送了,发送FIN标志位的TCP数据包后,连接将被断开。这个标志的数据包也经常被用于进行端口扫描。
  • Window:窗口大小,也就是有名的滑动窗口,用来进行流量控制;这是一个复杂的问题。看别的

    这里写图片描述

- 三次握手

这里写图片描述
这里写图片描述

  • 第一次握手:建立连接。客户端发送请求报文段,将SYN位置设置为1,Sequence Number为x,然后客户端进入SYN_SEND状态,等待服务器的确认。
  • 第二次握手:服务器收到SYN报文段,需要对这个SYN报文段进行确认,设置Acknowledgment Number为x+1(Sequence Number + 1)。同时,自己还要发送SYN请求信息,将SYN设置为1,Sequence Number为y;服务器将上述所有信息放到一个报文段(即SYN+ACK)中,一并发送到客户端,此时服务器进入SYN_RECV状态。
  • 第三次握手:客户端收到服务器的SYN+ACK报文段。然后将Acknowledgment Number设置为y+1,向服务器发送ACK报文段,这个报文段发送完毕以后,客户端和服务端都进行Establish的状态,完成TCP三次握手。

- 四次挥手

这里写图片描述
这里写图片描述
这里写图片描述
* #### 第一次挥手:主机1(可以是客户端,或是服务器),设置Sequence Number和Acknowledgment Number,向主机2发送一个FIN报文段;此时,主机1进入FIN_WAIT_1状态,这表明主机1没有数据要发送给主机2了

  • 第二次挥手:主机2收到了主机1发送的FIN报文段,向主机1回一个ACK报文段,设置ACK Number为x(SEQ Number+1);主机1进入FIN_WAIT_2状态,主机2告诉主机1,我同意关闭。
  • 第三次挥手:主机2向主机1发送FIN报文段,请求关闭连接,同时主机2进入LAST_ACK状态。
  • 第四次挥手:主机1收到主机2发送的FIN报文段,向主机2发送ACK报文段,然后主机1进入TIME_WAIT状态;主机2收到主机1的ACK报文段以后,就关闭连接;此外,主机1等待2MSL后依然没有收到回复,证明Server端已经正常关闭,主机1也可以正常关闭了。

- 为什么是三次握手

  • 为了防止已失效的连接请求报文段突然又传送到了服务端,因而产生错误。防止服务器端的一直等待而浪费资源。
  • 例:“已失效的连接请求报文段”的产生在这样一种情况下:client发出的第一个连接请求报文段并没有丢失,而是在某个网络节点长时间的逗留,以致延误到连接释放以后的某个时间才到达server。本来这是一个早已失效的报文段。但server收到此失效的连接请求报文段后,被误以为是client再次发出的一个新的连接请求。于是就向client发出确认报文段,同意建立连接。假设不是“三次握手”,那么只要server发出确认,新的连接就建立了。由于现在client并没有发出建立连接的请求,因此不会理睬server的确认,也不会向server发送数据。但server却以为新的运输连接已经建立,并一直等待server发来数据。这样,server的资源就被白白浪费了。采用三次握手的办法可以防止上述现象的发生。例如上述情况,client不会向server的确认发出确认,server就懂了。

- 为什么要四次挥手

  • TCP是一种面向连接的、可靠的、基于字节流的运输层通信协议。TCP是全双工模式,他意味着,当主机1发出FIN报文段时,只是表明主机1已经没有数据要发送了,主机1告诉主机2,他的数据已经全部发送完毕。但是,这个时候主机1还是可以接受主机2的数据,当主机2返回ACK报文段时,表示它已经知道主机1没有数据发送,但是主机2还是可以发送数据到主机1的。当主机2也发送FIN报文段时,这个时候就表示主机2也没有数据要发送了,就会告诉主机1,我也没有数据要发送了,之后彼此就会愉快的中断这次TCP连接。我们需要了解四次分手过程中的状态变化。
    • FIN_WAIT_1:FIN_WAIT_1与FIN_WAIT_2状态的真正含义都是表示等待对方的FIN报文,区别在于:FIN_WAIT_1状态实际上是当SOCKET在ESTABLISHED状态时,它想主动关闭连接,向对方发送FIN报文,此时该SOCKET即进入到FIN_WAIT_1状态。而当对方回应ACK报文后,则进入到FIN_WAIT_2状态,当然在实际的正常情况下,无论对方何种情况下,都应该马上回应ACK报文,所以FIN_WAIT_1状态一般是比较难见到的,而FIN_WAIT_2状态还有时常常可以用netstat看到。(主动方)
    • FIN_WAIT_2:实际上FIN_WAIT_2状态下的SOCKET,表示半连接,也即有一方要求close连接,但另外还告诉对方,我暂时还有点数据需要传送给你(ACK信息), 稍后关闭连接。(主动方)
    • CLOSE_WAIT:这种状态的含义其实是表示在等待关闭。当对方close一个SOCKET后发送FIN报文给自己,你的系统毫无疑问会回应一个ACK报文给对方,此时则进入到CLOSE_WAIT状态。接下来,实际上你真正需要考虑的事情是查看你是否还有数据要发给对方。如果没有的话,就可以close这个SOCKET,发送FIN报文给对方,也即关闭连接。所以你在CLOSE_WAIT状态下,需要完成的事情是等待你去关闭连接。(被动方)
    • LAST_ACK:它是被动关闭一方在发送FIN报文中,最后等待对方的ACK报文。当收到ACK报文,也即进入CLOSED可用状态了。(被动方)
    • TIME_WAIT:表示收到了对方的FIN报文,并发送出了ACK报文,就等2MSL后即可回到CLOSED可用状态了。如果在FIN_WAIT_1状态下,收到了对方同时带FIN标志和ACK标志的报文时,可以直接进入到TIME_WAIT状态,而无须经过FIN_WAIT_2状态(主动方)
    • CLOSED:表示连接中断。
资源下载链接为: https://pan.quark.cn/s/3d8e22c21839 随着 Web UI 框架(如 EasyUI、JqueryUI、Ext、DWZ 等)的不断发展成熟,系统界面的统一化设计逐渐成为可能,同时代码生成器也能够生成符合统一规范的界面。在这种背景下,“代码生成 + 手工合并”的半智能开发模式正逐渐成为新的开发趋势。通过代码生成器,单表数据模型以及一对多数据模型的增删改查功能可以被直接生成并投入使用,这能够有效节省大约 80% 的开发工作量,从而显著提升开发效率。 JEECG(J2EE Code Generation)是一款基于代码生成器的智能开发平台。它引领了一种全新的开发模式,即从在线编码(Online Coding)到代码生成器生成代码,再到手工合并(Merge)的智能开发流程。该平台能够帮助开发者解决 Java 项目中大约 90% 的重复性工作,让开发者可以将更多的精力集中在业务逻辑的实现上。它不仅能够快速提高开发效率,帮助公司节省大量的人力成本,同时也保持了开发的灵活性。 JEECG 的核心宗旨是:对于简单的功能,可以通过在线编码配置来实现;对于复杂的功能,则利用代码生成器生成代码后,再进行手工合并;对于复杂的流程业务,采用表单自定义的方式进行处理,而业务流程则通过工作流来实现,并且可以扩展出任务接口,供开发者编写具体的业务逻辑。通过这种方式,JEECG 实现了流程任务节点和任务接口的灵活配置,既保证了开发的高效性,又兼顾了项目的灵活性和可扩展性。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值