博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
分别描述TCP的3次握手和四次挥手的定义、目的和过程
阅读量:3947 次
发布时间:2019-05-24

本文共 1971 字,大约阅读时间需要 6 分钟。

定义

  1. 三次握手是指建立TCP连接协议时,需要在客户端和服务器之间发送三个包,握手过程中传送的包里不包含数据,三次握手完毕后,客户端与服务器才正式开始传送数据。
  2. 四次挥手是指终止TCP连接协议时,需要在客户端和服务器之间发送四个包,四次挥手完毕后,客户端与服务器TCP连接完全断开。

过程

UDP的报文结构

在这里插入图片描述
TCP的报文结构
在这里插入图片描述
UDP报文的头部只有8个字节,相对TCP的20字节。

三次握手是指建立TCP连接协议时,需要在客户端和服务器之间发送三个包,握手过程中传送的包里不包含数据,三次握手完毕后,客户端与服务器才正式开始传送数据。

在这里插入图片描述

第一次握手:客户端发送第一个包,其中SYN标志位为1, ACK=0,发送顺序号sequence=X(随机int)。客户端进入SYN发送状态,等待服务器确认。
第二次握手:服务器收到这个包后发送第二个包,其中包SYN、ACK标志位为1,发送顺序号seq=Y(随机int),接收顺序号ACK=X+1,此时服务器进入SYN接收状态。
第三次握手:客户端收到服务器传来的包后,向服务器发送第三个包,SYN=0, ACK=1,接收顺序号ACK = Y+1,发送顺序号seq=X+1。此包发送完毕,客户端和服务器进入ESTABLISHED建立成功状态,完成三次握手。

在这里插入图片描述

四次握手是指终止TCP连接协议时,需要在客户端和服务器之间发送四个包

第一次挥手:主动关闭方发送第一个包,其中FIN标志位为1,发送顺序号seq为X。

第二次挥手:被动关闭方收到FIN包后发送第二个包,其中发送顺序号seq为Z,接收顺序号ack为X+1。
第三次挥手:被动关闭方再发送第三个包,其中FIN标志位为1,发送顺序号seq为Y,接收顺序号ack为X。
第四次挥手:主动关闭方发送第四个包,其中发送顺序号为X,接收顺序号为Y。至此,完成四次挥手。
超时重传指的是,发送数据包在一定的时间周期内没有收到相应的ACK,等待一定的时间,超时之后就认为这个数据包丢失,就会重新发送。这个等待时间被称为RTO.

深入讨论:

1、为什么建立连接协议是三次握手,而关闭连接却是四次握手呢?

建立连接时,ACK和SYN可以放在一个报文里来发送。而关闭连接时,被动关闭方可能还需要发送一些数据后,再发送FIN报文表示同意现在可以关闭连接了,所以它这里的ACK报文和FIN报文多数情况下都是分开发送的。

2、为什么TIME_WAIT状态还需要等2MSL后才能返回到CLOSED状态?

两个存在的理由:1、无法保证最后发送的ACK报文会一定被对方收到,所以需要重发可能丢失的ACK报文。2、关闭链接一段时间后可能会在相同的IP地址和端口建立新的连接,为了防止旧连接的重复分组在新连接已经终止后再现。2MSL足以让分组最多存活msl秒被丢弃。

3、为什么必须是三次握手,不能用两次握手进行连接?

记住服务器的资源宝贵不能浪费!  如果在断开连接后,第一次握手请求连接的包才到会使服务器打开连接,占用资源而且容易被恶意攻击!防止攻击的方法,缩短服务器等待时间。两次握手容易死锁。如果服务器的应答分组在传输中丢失,将不知道S建立什么样的序列号,C认为连接还未建立成功,将忽略S发来的任何数据分组,只等待连接确认应答分组。而S在发出的分组超时后,重复发送同样的分组。这样就形成了死锁。

目的

  1. 三次握手可以防止失效的连接请求报文段被服务端接收,从而产生错误。
    PS:失效的连接请求:若客户端向服务端发送的连接请求丢失,客户端等待应答超时后就会再次发送连接请求,此时,上一个连接请求就是『失效的』。
    若建立连接只需两次握手,客户端并没有太大的变化,仍然需要获得服务端的应答后才进入ESTABLISHED(就绪)状态,而服务端在收到连接请求后就进入ESTABLISHED(就绪)状态。此时如果网络拥塞,客户端发送的连接请求迟迟到不了服务端,客户端便超时重发请求,如果服务端正确接收并确认应答,双方便开始通信,通信结束后释放连接。此时,如果那个失效的连接请求抵达了服务端,由于只有两次握手,服务端收到请求就会进入ESTABLISHED(就绪)状态,等待发送数据或主动发送数据。但此时的客户端早已进入CLOSED(关闭)状态,服务端将会一直等待下去,这样浪费服务端连接资源。
  2. TCP连接是双向的,因此在四次挥手中,前两次挥手用于断开一个向的连接,后两次挥手用于断开另一方向的连接。
  3. 为什么A要先进入TIME-WAIT状态,等待2MSL时间后才进入CLOSED状态?
    这也是为了保证B(被动方)能收到A(主动方)的确认应答。
    若A发完确认应答后直接进入CLOSED状态,那么如果该应答丢失,B等待超时后就会重新发送连接释放请求,但此时A已经关闭了,不会作出任何响应,因此B永远无法正常关闭

转载地址:http://glrwi.baihongyu.com/

你可能感兴趣的文章
iOS常用代码块
查看>>
iOS常用宏命令大全
查看>>
YYKit - YYModel 使用方法
查看>>
OC网络封装工具
查看>>
iOS-浅谈block
查看>>
Socket介绍
查看>>
swift-闭包产生的循环引用以及解决办法
查看>>
gitbook安装与使用
查看>>
Apache服务器搭建方法
查看>>
Mac终端常用命令
查看>>
常用算法-冒泡排序代码实现
查看>>
swift 中的 感叹号 问号 和 双问号用法详解
查看>>
C代码:二分法求三次方程近似根
查看>>
swift-自己封装的一个网络工具
查看>>
APP第三方登录实现步骤
查看>>
iOS-数据存储方式介绍
查看>>
KVO & KVC 比较 - KVC
查看>>
iOS-tableView联动
查看>>
iOS--Masonry解决 tableViewCell 重用时约束冲突
查看>>
git 与 svn 的主要区别!
查看>>