TCP协议详解--三握四挥

Posted 前端大联盟

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了TCP协议详解--三握四挥相关的知识,希望对你有一定的参考价值。

茫茫人海中与你相遇

相信未来的你不会很差


来源:http://47.98.159.95/my_blog/nav/


001. TCP 和 UDP 的区别?
首先概括一下基本的区别:

TCP是一个面向连接的、可靠的、基于字节流的传输层协议。
UDP是一个面向无连接的传输层协议。(就这么简单,其它TCP的特性也就没有了)。
具体来分析,和 UDP 相比, TCP 有三大核心特性:

  1. 面向连接。所谓的连接,指的是客户端和服务器的连接,在双方互相通信之前,TCP 需要三次握手建立连接,而 UDP 没有相应建立连接的过程。
  2. 可靠性。TCP 花了非常多的功夫保证连接的可靠,这个可靠性体现在哪些方面呢?一个是有状态,另一个是可控制。
  • TCP 会精准记录哪些数据发送了,哪些数据被对方接收了,哪些没有被接收到,而且保证数据包按序到达,不允许半点差错。这是有状态。

  • 当意识到丢包了或者网络环境不佳,TCP 会根据具体情况调整自己的行为,控制自己的发送速度或者重发。这是可控制。

  • 相应的,UDP 就是无状态, 不可控的。


  1. 面向字节流。UDP 的数据传输是基于数据报的,这是因为仅仅只是继承了 IP 层的特性,而 TCP 为了维护状态,将一个个 IP 包变成了字节流。


002: 说说 TCP 三次握手的过程?为什么是三次而不是两次、四次?


恋爱模拟



以谈恋爱为例,两个人能够在一起最重要的事情是首先确认各自爱和被爱的能力。接下来我们以此来模拟三次握手的过程。


第一次:

男: 我爱你。
女方收到。
由此证明男方拥有 的能力。


第二次:


女: 我收到了你的爱,我也爱你。
男方收到。
OK,现在的情况说明,女方拥有 被爱 的能力。


第三次:


男: 我收到了你的爱。
女方收到。
现在能够保证男方具备 被爱 的能力。
由此完整地确认了双方 被爱 的能力,两人开始一段甜蜜的爱情。


真实握手


当然刚刚那段属于扯淡,不代表本人价值观,目的是让大家理解整个握手过程的意义,因为两个过程非常相似。对应到 TCP 的三次握手,也是需要确认双方的两样能力: 发送的能力 接收的能力 。于是便会有下面的三次握手的过程:


TCP协议详解--三握四挥


从最开始双方都处于 CLOSED 状态。然后服务端开始监听某个端口,进入了 LISTEN 状态。
然后客户端主动发起连接,发送 SYN , 自己变成了 SYN-SENT 状态。
服务端接收到,返回 SYN ACK (对应客户端发来的SYN),自己变成了 SYN-REVD
之后客户端再发送 ACK 给服务端,自己变成了 ESTABLISHED 状态;服务端收到 ACK 之后,也变成了 ESTABLISHED 状态。


另外需要提醒你注意的是,从图中可以看出,SYN 是需要消耗一个序列号的,下次发送对应的 ACK 序列号要加1,为什么呢?只需要记住一个规则:
凡是需要对端确认的,一定消耗TCP报文的序列号。
SYN 需要对端的确认, 而 ACK 并不需要,因此 SYN 消耗一个序列号而 ACK 不需要。


为什么不是两次?


根本原因: 无法确认客户端的接收能力。


分析如下:


如果是两次,你现在发了 SYN 报文想握手,但是这个包滞留在了当前的网络中迟迟没有到达,TCP 以为这是丢了包,于是重传,两次握手建立好了连接。


看似没有问题,但是连接关闭后,如果这个滞留在网路中的包到达了服务端呢?这时候由于是两次握手,服务端只要接收到然后发送相应的数据包,就默认建立连接,但是现在客户端已经断开了。


看到问题的吧,这就带来了连接资源的浪费。


为什么不是四次?


三次握手的目的是确认双方 发送 接收 的能力,那四次握手可以嘛?
当然可以,100 次都可以。但为了解决问题,三次就足够了,再多用处就不大了。


三次握手过程中可以携带数据么?


第三次握手的时候,可以携带。前两次握手不能携带数据。


如果前两次握手能够携带数据,那么一旦有人想攻击服务器,那么他只需要在第一次握手中的 SYN 报文中放大量数据,那么服务器势必会消耗更多的时间和内存空间去处理这些数据,增大了服务器被攻击的风险。


第三次握手的时候,客户端已经处于 ESTABLISHED 状态,并且已经能够确认服务器的接收、发送能力正常,这个时候相对安全了,可以携带数据。


同时打开会怎样?


如果双方同时发 SYN 报文,状态变化会是怎样的呢?
这是一个可能会发生的情况。
状态变迁如下:
TCP协议详解--三握四挥
在发送方给接收方发 SYN 报文的同时,接收方也给发送方发 SYN 报文,两个人刚上了!
发完 SYN ,两者的状态都变为 SYN-SENT
在各自收到对方的 SYN 后,两者状态都变为 SYN-REVD
接着会回复对应的 ACK + SYN ,这个报文在对方接收之后,两者状态一起变为 ESTABLISHED
这就是同时打开情况下的状态变迁。

003: 说说 TCP 四次挥手的过程


过程拆解


TCP协议详解--三握四挥


刚开始双方处于 ESTABLISHED 状态。
客户端要断开了,向服务器发送 FIN 报文,在 TCP 报文中的位置如下图:


TCP协议详解--三握四挥



发送后客户端变成了 FIN-WAIT-1 状态。注意, 这时候客户端同时也变成了 half-close(半关闭) 状态,即无法向服务端发送报文,只能接收。
服务端接收后向客户端确认,变成了 CLOSED-WAIT 状态。
客户端接收到了服务端的确认,变成了 FIN-WAIT2 状态。
随后,服务端向客户端发送 FIN ,自己进入 LAST-ACK 状态,
客户端收到服务端发来的 FIN 后,自己变成了 TIME-WAIT 状态,然后发送 ACK 给服务端。


注意了,这个时候,客户端需要等待足够长的时间,具体来说,是 2 个 MSL ( Maximum Segment Lifetime,报文最大生存时间 ), 在这段时间内如果客户端没有收到服务端的重发请求,那么表示 ACK 成功到达,挥手结束,否则客户端重发 ACK。


等待2MSL的意义


如果不等待会怎样?


如果不等待,客户端直接跑路,当服务端还有很多数据包要给客户端发,且还在路上的时候,若客户端的端口此时刚好被新的应用占用,那么就接收到了无用数据包,造成数据包混乱。所以,最保险的做法是等服务器发来的数据包都死翘翘再启动新的应用。


那,照这样说一个 MSL 不就不够了吗,为什么要等待 2 MSL?


  • 1 个 MSL 确保四次挥手中主动关闭方最后的 ACK 报文最终能达到对端
  • 1 个 MSL 确保对端没有收到 ACK 重传的 FIN 报文可以到达


这就是等待 2MSL 的意义。


为什么是四次挥手而不是三次?


因为服务端在接收到 FIN , 往往不会立即返回 FIN , 必须等到服务端所有的报文都发送完毕了,才能发 FIN 。因此先发一个 ACK 表示已经收到客户端的 FIN ,延迟一段时间才发 FIN 。这就造成了四次挥手。


如果是三次挥手会有什么问题?
等于说服务端将 ACK FIN 的发送合并为一次挥手,这个时候长时间的延迟可能会导致客户端误以为 FIN 没有到达客户端,从而让客户端不断的重发 FIN


同时关闭会怎样?


如果客户端和服务端同时发送 FIN ,状态会如何变化?如图所示:


TCP协议详解--三握四挥




TCP协议详解--三握四挥

我们在虚拟的空间与你相遇,期待可以碰撞出不一样的火花


公众号ID:前端大联盟

扫码关注最新动态




以上是关于TCP协议详解--三握四挥的主要内容,如果未能解决你的问题,请参考以下文章

网络协议万文长篇,带你深入理解 TCP;场景复现,掌握鲜为人知的细节(上)

TCP和UDP的区别

图解 | 原来这就是 IO 多路复用

[底层原理]Socket 究竟是什么? 为啥网络离不开 Socket?

深入理解网络编程,Linux 网络发包过程详细解析

万字详解TCP协议