TCP连接建立、断开过程详解

TCP连接建立过程需要经过三次握,断开过程需要经过四次挥手,为什么? 有没有其他的连接建立、断开方式?

一、 TCP连接建立过程

1. 三次握手

TCP正常的建立连接过程如下图所示:

  1. 客户端发送的TCP报文中标志位SYN置1,初始序号seq=x(随机选择)。Client进入SYN_SENT状态,等待Server确认。
  2. 服务器收到数据包后,根据标志位SYN=1知道Client请求建立连接,Server将标志位SYN和ACK都置为1,ack=x+1,随机产生一个初始序号seq=y,并将该数据包发送给Client以确认连接请求,Server进入SYN_RCVD状态。
  3. Client收到确认后,检查ack是否为x+1,ACK是否为1,如果正确则将标志位ACK置为1,ack=y+1,并将该数据包发送给Server。Server检查ack是否为y+1,ACK是否为1,如果正确则连接建立成功,Client和Server进入ESTABLISHED状态,完成三次握手,随后Client与Server之间可以开始传输数据了。

2. 同时打开

同时打开连接是指通信的双方在接收到对方的SYN包之前,都进行了主动打开的操作并发出了自己的SYN包。由于一个四元组(源IP、源端口、目的IP、目的端口)标识一个TCP连接,一个TCP连接要同时打开需要通信的双方知晓对方的IP和端口信息才行,这种场景在实际情况中很少发生。同时打开的流程如下图:

  1. A的应用程序使用端口7777向B的端口8888发送TCP连接请求
  2. B的应用程序使用端口8888向A的端口7777发送TCP连接请求
  3. A收到B的ACK(实际上是SYN+ACK)后进入ESTABLISHED状态
  4. B收到A的ACK(实际上是SYN+ACK)后也进入ESTABLISHED状态

注意:

  • 对于同时打开它仅建立一条TCP连接而不是两条
  • 连接建立过程需要四次握手
  • 两端的状态变化都是由CLOSED->SYN_SENT->SYN_RCVD->ESTABLISHED
  • 双方发出的SYN+ACK报文中,seq均未递增。比如对于A,发送SYN时seq为x,发送SYN+ACK时seq仍为x

3. 自连接

执行下面的脚本,过一段时间通过netstat查看,是不是建立了本地连接。

while true
do
    telnet 127.0.0.1 50000 
done

尽管我的机器上并未监听5000端口,但是却建立了一条TCP连接。

Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State      
tcp        0      0 192.168.88.228:445      192.168.88.167:52324    ESTABLISHED
tcp        0    216 192.168.88.228:22       192.168.88.167:58738    ESTABLISHED
tcp        0      0 127.0.0.1:50000         127.0.0.1:50000         ESTABLISHED

自连接是同时打开的一个特例。一条TCP连接由四元组(源IP、源端口、目的IP、目的端口)来决定,在上面的例子中,源IP、目的IP、目的端口都是确定的,唯一不确定的是源端口。如果系统选择的源端口与目的端口相同,那么Client和Server(实际上不存在Server这个实体)就是相同的TCP实体。

  1. Cient向127.0.0.1:50000发送SYN,进入SYN_SENT状态
  2. 由于Client已经打开了端口50000,所以不会产生RST报文;相反系统以为50000端口有服务器在监听,就接收了这个SYN报文,并从SYN_SENT状态变为SYN_RCVD状态
  3. 由于TCP状态从SYN_SENT状态变为SYN_RCVD状态,需要发送了SYN+ACK报文
  4. 参考同时打开的状态图,SYN+ACK报文将TCP状态从SYN_RCVD变为ESTABLISHED

二、 TCP连接断开过程

1. 四次挥手

TCP连接断开过程如下图所示:

  1. Client发送一个FIN,用来关闭Client到Server的数据传送,Client进入FIN_WAIT_1状态。
  2. Server收到FIN后,发送一个ACK给Client,确认序号为u + 1(与SYN相同,一个FIN占用一个序号),Server进入CLOSE_WAIT状态。
  3. Server发送一个FIN,用来关闭Server到Client的数据传送,Server进入LAST_ACK状态。
  4. Client收到FIN后,Client进入TIME_WAIT状态(主动关闭方才会进入该状态),接着发送一个ACK给Server,确认序号为w + 1,Server进入CLOSED状态,完成四次挥手。

2. 同时关闭连接

同时关闭和前面同时打开的四次握手过程基本类似,流程如下:

注意:

  1. 两端的状态变化都是由ESTABLISHED->FIN_WAIT_1->CLOSING->TIME_WAIT->CLOSED
  2. 两端都需要经历TIME_WAIT状态

三、 常见问题

1. 为什么要三次握手建立连接

TCP连接是可靠的双工通信,在连接建立阶段必须确认双向通信都是OK的。理论上来讲这需要至少四次交互:

  1. Client发送SYN
  2. Server响应ACK
  3. Server发送SYN
  4. Client响应ACK(如果没有这一步,Server无法知道Client能否收到自己的消息)

1、2两步让Client知道自己和Server之间的双向通信是OK的,3、4两步让Server知道自己和Client之间的双向通信是OK的。 实际应用中,2、3两步合并了,所以最终就只有三次握手。

三次握手还可以解决网络中延迟的重复分组问题。假设TCP连接建立过程只有两次握手:

  1. Client发送SYN
  2. Server响应ACK

如果出现下面的情况,服务端就会出问题:

  1. Client发送SYN
  2. Client端超时未收到Server的ACK,重发SYN
  3. Server端收到Client重发的SYN,响应ACK
  4. Client收到ACK后,和Server正常数据交互,然后关闭连接
  5. Client第一次发送的SYN并未丢失,而是由于网络延迟,现在才到达Server端
  6. Server发送ACK(Server认为TCP连接已建立)
  7. Client收到Server的ACK,由于Client认为自己并未请求连接,所以会忽略该ACK(不同于SYN,ACK报文不需要回复)
  8. 这时Server认为连接已经建立,一直等待客户端数据;客户端却根本不知道有这么一条连接

2. 为什么要四次挥手断开连接

TCP连接是全双工的,因此每个方向都必须单独进行关闭:当一方完成它的数据发送任务后就发送一个FIN来终止这个方向的连接,对端收到后回复一个ACK报文,这样双向就需要四次交互。

Client主动关闭的情况下,Server收到Client的FIN报文时,仅仅表示Client没有数据发送给Server了;但Server可能还有数据要发送给Client,所以Server可能并不会立即关闭SOCKET,而是先回复一个ACK报文,告诉Client“你发的FIN报文我收到了”。只有等到Server所有的报文都发送完了,才发送FIN报文。也就是说,被动关闭方的ACK和FIN报文多数情况下都是分开发送的,所以需要四次交互。

3. 为什么TIME_WAIT状态需要经过2MSL才能返回到CLOSE状态

  • 为了保证主动关闭方发送的最后一个ACK报文能够到达被动关闭方。因为这个ACK有可能无法到达对端,这样对端会重发FIN报文,这时候主动关闭方需要重发ACK。
  • 保证本连接的所有报文在网络上消失。如果没有这个机制,可能会对新连接产生干扰。举例如下:
    1. A和B正常建立TCP连接,数据传输,然后断开连接。但是由于网络传输原因,A发给B的seq为100的报文滞留在了网络上。
    2. A和B再次建立连接,所用IP和端口与1中相同,二者数据传输过程中,B正好请求A发送seq为100的数据,这时1中滞留的报文到达B,TCP认为该报文合法,就接收了这个报文。

四、 参考资料

  1. http://sgros.blogspot.hk/2013/08/tcp-client-self-connect.html
  2. https://networkengineering.stackexchange.com/questions/24068/why-do-we-need-a-3-way-handshake-why-not-just-2-way
  3. https://www.quora.com/Network-Protocols-In-TCP-3-way-handshake-why-we-need-the-third-ACK

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏武培轩的专栏

TCP和UDP的区别

TCP TCP(Transmission Control Protocol,传输控制协议)是面向连接的协议,也就是说,在收发数据前,必须和对方建立可靠的连接。 ...

2975
来自专栏Java进阶架构师

动图详解TCP的三次握手与四次挥手

原文:https://blog.csdn.net/qzcsu/article/details/72861891

1464
来自专栏Golang语言社区

Golang语言--UDP实现

UDP IN GO Go语言对UDP的支持并没有像TCP那样被众多的博客和论坛关注。UDP作为一个重要的传输层协议,是构成很多应用层软件协议的基础。 net包支...

4148
来自专栏武培轩的专栏

TCP三次握手和四次挥手

TCP三次握手 所谓三次握手(Three-Way Handshake)即建立TCP连接,就是指建立一个TCP连接时,需要客户端和服务端总共发送3个包以确认连接的...

3264
来自专栏章鱼的慢慢技术路

网络笔试面试题整理

首部字段只有 8 个字节,包括源端口、目的端口、长度、检验和。12 字节的伪首部是为了计算检验和临时添加的。

3062
来自专栏遊俠扎彪

Linux操作系统中删除ARP缓存的命令

在Windows下,使用比较多的两个操作ARP缓存的命令是arp -a和arp -d,前者是查看所有ARP条目,后者是删除所有ARP条目。

3529
来自专栏Janti

基础巩固——你应该这么理解TCP的三次握手和四次挥手

网络传输层负责最底层的底层链路连接。两台主机之间进行互联,基于网线的物理硬件上的协议。在这个侧面,主机与主机之间只认得硬件mac编码。并不认识IP。

662
来自专栏北京马哥教育

TCP恋爱史:三次握手和四次分手

TCP恋爱史:三次握手和四次分手 ---- 一个应用占用CPU很高,除了确实是计算密集型应用之外,通常原因都是出现了死循环。 以我们最近出现的 TCP协议非常重...

2623
来自专栏程序猿DD

TCP之三次握手四次挥手

TCP报头中的源端口号和目的端口号同IP数据报中的源IP与目的IP唯一确定一条TCP连接。

17310
来自专栏javathings

Java 中什么是无锁编程?

多线程环境下,为了保证数据不受到并发操作的影响,通常会采用加锁的策略保证一致性。除了加锁之外,还有一种方式就是采用无锁编程。

2602

扫码关注云+社区

领取腾讯云代金券