认识TCP协议 与 三次握手 、四次挥手!!

认识TCP

TCP协议顾名思义,传输控制协议,是传输层的协议。负责控制数据的传输过程,负责数据能从发送端发送到接收端。

是一种面向连接、可靠传输和面向字节流的特性的协议。

TCP协议格式

在这里插入图片描述

  • 源端口和目标端口:数据从哪来发送到哪去
  • 序列号:用来表示源端向目的端发送数据,表示在这个报文段所发送的数据的第一个字节。(TCP会对传送的每个数据流中的每一个字节都编上一个序号)
  • 确认号:期望收到对方下一个发送的数据的第一个字节序号
  • 首部长度:表示该TCP头部有多少个4字节。最大15*4=60个字节
  • 保留字段:以后使用目前置为0
    1. 紧急URG:当为1时,表明数据中有紧急数据,应当尽快传送
    2. 确认ACK:只有为1时有效
    3. 推送PSH:接收TCP收到PSH=1,就尽快交付应用进程,而不是等到整个缓存都填满了再向上交付
    4. 复位RST:当为1时,表明连接出现了差错,必须释放连接,重新连接
    5. 同步SYN:当为1时,表明这是一个连接请求或连接接受报文
    6. 终止FIN:用来释放一个连接,为1时表明此发送端的数据传输完毕,要求释放运输连接。
  • 窗口大小:让对方设置发送窗口的依据,单位为字节
  • 检验和:检验范围包括首部和数据两部分,计算检验和时,要在TCP报文段前面加上12字节的伪首部
  • 紧急指针:指向数据中的紧急数据

TCP的特点

  1. TCP 是面向连接的。(就好像打电话一样,通话前需要先拨号建立连接,通话结束后要挂机释放连接);
  2. 每一条 TCP 连接只能有两个端点,每一条 TCP 连接只能是点对点的(一对一);
  3. TCP 提供可靠交付的服务。通过 TCP 连接传送的数据,无差错、不丢失、不重复、并且按序到达;
  4. TCP 提供全双工通信。TCP 允许通信双方的应用进程在任何时候都能发送数据。
  5. 面向字节流。TCP 中的“流”(Stream)指的是流入进程或从进程流出的字节序列。“面向字节流”的含义是:虽然应用程序和 TCP 的交互是一次一个数据块(大小不等),但 TCP 把应用程序交下来的数据仅仅看成是一连串的无结构的字节流。

三次握手

在这里插入图片描述

客户端首先是关闭closed状态,服务器是监听listen状态。

第一次握手:客户端向服务器端发出连接请求,报文段同步SYN =1,同时选择一个初始序号。处于SYN_SENT状态。
第二次握手:如果服务器端收到连接请求后,同意连接,则向客户端发送确认。同步SYN=1,确认ACK =1,确认号为 seq+1,同时选择一个自己的序列号。处于SYN_RCEVD状态。
第三次握手:客户端收到服务器端的确认,还要向服务器端发送确认。确认报文段ACK=1,确认序号ack = y+1。TCP已经建立,双方进入ESTABLISHED状态。

为什么要三次握手

  • 两次不安全。

为了防止已经失效的连接请求报文段突然又传送到了服务端,因而产生错误

A 发出的第一个连接请求报文段并没有丢失,而是在网路结点长时间滞留了,以致于延误到连接释放以后的某个时间段才到达 B。本来这是一个早已失效的报文段。但是 B 收到此失效的链接请求报文段后,就误认为 A 又发出一次新的连接请求。于是就向 A 发出确认报文段,同意建立连接。

对于上面这种情况,如果不进行第三次握手,B 发出确认后就认为新的运输连接已经建立了,并一直等待 A 发来数据。B 的许多资源就这样白白浪费了。

如果采用了三次握手,由于 A 实际上并没有发出建立连接请求,所以不会理睬 B 的确认,也不会向 B 发送数据。B 由于收不到确认,就知道 A 并没有要求建立连接。

  • 四次没必要。

我们需要明白一点,完全可靠的通信协议是不存在的。在经过三次握手之后,客户端和服务端已经可以确认之前的通信状况,都收到了确认信息。所以即便再增加握手次数也不能保证后面的通信完全可靠,所以是没有必要的。

四次挥手

在这里插入图片描述

在断开连接之前,双方都是建立ESTABLISHED状态。

第一次挥手:客户端向服务器端发送释放报文段请求,并停止自己再发送数据。报文段结束FIN = 1,序号为最后一次传送数据的序号加1.这时客户端进入FIN_WAIT_1状态。
第二次挥手:收到请求立即发出确认,确认号为u+1,服务端就进入CLOSE_WAIT状态。客户端处于FIN_WAIT_2状态。

此时的TCP处于半关闭状态,客户端不能发送数据,服务器端发送数据,客户端仍要收。

第三次挥手:若服务端没有数据要发送了,其应用进程就通知TCP释放连接。这时服务器端向客户端发送请求,FIN = 1,ack = u +1。服务器端就进入LAST_ACK状态。

第四次挥手:客户端收到服务器端的释放连接请求,对此发出确认,就进入TIME_WAIT状态。

现在TCP连接还没有掉,客户端必须经过等待计时器设置的时间 2MSL(MSL:最长报文段寿命)后,客户端才能进入CLOSED状态,结束这次连接。

为什么要四次挥手

当服务器执行第二次挥手以后,此时证明客户端不能向服务器端发送数据,但是服务器端还可以给客户端发送数据(可能是上一次客户端请求的资源还没有发送完毕),所以此时服务端会把数据发送完成之后再发送自己的关闭请求。

为什么要等待2MSL

  1. 为了保证 A 发送的最后一个 ACK 报文段能够到达 B。这个 ACK 报文段有可能丢失,因而使处在 LAST-ACK 状态的 B 收不到对已发送的 FIN + ACK 报文段的确认。B 会超时重传这个 FIN+ACK 报文段,而 A 就能在 2MSL 时间内(超时 + 1MSL 传输)收到这个重传的 FIN+ACK 报文段。接着 A 重传一次确认,重新启动 2MSL 计时器。最后,A 和 B 都正常进入到 CLOSED 状态。如果 A 在 TIME-WAIT 状态不等待一段时间,而是在发送完 ACK 报文段后立即释放连接,那么就无法收到 B 重传的 FIN + ACK 报文段,因而也不会再发送一次确认报文段,这样,B 就无法按照正常步骤进入 CLOSED 状态。

  2. 防止已失效的连接请求报文段出现在本连接中。A 在发送完最后一个 ACK 报文段后,再经过时间 2MSL,就可以使本连接持续的时间内所产生的所有报文段都从网络中消失。这样就可以使下一个连接中不会出现这种旧的连接请求报文段。

保活计时器

除时间等待计时器外,TCP 还有一个保活计时器(keepalive timer)。设想这样的场景:客户已主动与服务器建立了 TCP 连接。但后来客户端的主机突然发生故障。显然,服务器以后就不能再收到客户端发来的数据。因此,应当有措施使服务器不要再白白等待下去。这就需要使用保活计时器了。

服务器每收到一次客户的数据,就重新设置保活计时器,时间的设置通常是两个小时。若两个小时都没有收到客户端的数据,服务端就发送一个探测报文段,以后则每隔 75 秒钟发送一次。若连续发送 10个 探测报文段后仍然无客户端的响应,服务端就认为客户端出了故障,接着就关闭这个连接。

已标记关键词 清除标记
©️2020 CSDN 皮肤主题: 1024 设计师:上身试试 返回首页