计算机网络 - TCP三次握手、四次挥手总结

最近在复习计算机网络,发现之前课堂上学过的知识许多地方都模糊了。现在将一些内容记录在这里,整合网上的资料个人的一些理解,可能存在错误,有问题请提出,感谢❤。

一.TCP是传输层的协议,传输层的传输单位是报文,以下是TCP数据包的结构:

在这里插入图片描述

源端口号( 16 位):(连同源主机 IP 地址)标识源主机的一个应用进程。

目的端口号( 16 位):(连同目的主机 IP 地址)标识目的主机的一个应用进程。
【这两个值加上 IP 报头中的源主机 IP 地址和目的主机 IP 地址唯一确定一个 TCP 连接。】

顺序号 seq( 32 位):用来标识从 TCP 源端向 TCP 目的端发送的数据字节流,它表示在这个报文段中的第一个数据字节的顺序号。如果将字节流看作在两个应用程序间的单向流动,则TCP 用顺序号对每个字节进行计数。序号是 32bit 的无符号数,序号到达 2 的 32 次方 - 1 后又从 0 开始。当建立一个新的连接时, SYN 标志变 1 ,顺序号字段包含由这个主机选择的该连接的初始顺序号 ISN ( Initial Sequence Number,随机生成 )。

确认号 ack( 32 位):标识发送确认的一端所期望收到的下一个顺序号。因此,确认序号应当是上次已成功收到数据字节顺序号加 1 。只有 ACK 标志为 1 时确认序号字段才有效。
【TCP 为应用层提供全双工服务(数据能在两个方向上独立地进行传输。),因此,连接的每一端必须保持每个方向上的传输数据顺序号。】

TCP 报头长度( 4 位):给出报头中 32bit 字的数目(图中一横行4个字节),它实际上指明数据从哪里开始。需要这个值是因为任选字段的长度是可变的。这个字段占 4bit ,因此 TCP 最多有 60 字节的首部。然而,没有任选字段,正常的长度是 20 字节。

保留位( 6 位):保留给将来使用,目前必须置为 0 。

控制位( control flags , 6 位):在 TCP 报头中有 6 个标志比特,它们中的多个可同时被设置为 1 。依次为:

  • URG :为 1 表示紧急指针有效,为 0 则忽略紧急指针值。
  • ACK :为 1 表示确认号有效,为 0 表示报文中不包含确认信息,忽略确认号字段。
  • PSH :为 1 表示是带有 PUSH 标志的数据,指示接收方应该尽快将这个报文段交给应用层而不用等待缓冲区装满。
  • RST :用于复位由于主机崩溃或其他原因而出现错误的连接。它还可以用于拒绝非法的报文段和拒绝连接请求。一般情况下,如果收到一个 RST 为 1 的报文,那么一定发生了某些问题。
  • SYN :同步序号,为 1 表示连接请求,用于建立连接和使顺序号同步( synchronize )。
  • FIN :用于释放连接,为 1 表示发送方已经没有数据发送了,即关闭本方数据流。

窗口大小( 16 位):数据字节数,本报文的源方可以接收的数据的字节数,即源方接收窗口大小。窗口大小是一个 16bit 字段,因而窗口大小最大为 65535 字节。
-可用于解决网络阻塞和接收端数据处理不及时的问题

校验和( 16 位):此校验和是对整个的 TCP 报文段,包括 TCP 头部和 TCP 数据,以 16 位字进行计算所得。这是一个强制性的字段,一定是由发送端计算和存储,并由接收端进行验证。

紧急指针( 16 位):只有当 URG 标志置 1 时紧急指针才有效。TCP 的紧急方式是发送端向另一端发送紧急数据的一种方式。

**选项:**最常见的可选字段是最长报文大小,又称为 MSS(Maximum Segment Size) 。每个连接方通常都在通信的第一个报文段(为建立连接而设置 SYN 标志的那个段)中指明这个选项,它指明本端所能接收的最大长度的报文段。选项长度不一定是 32 位字的整数倍,所以要加填充位,使得报头长度成为整字数。

数据: TCP 报文段中的数据部分是可选的。在一个连接建立和一个连接终止时,双方交换的报文段仅有 TCP 首部。如果一方没有数据要发送,也使用没有任何数据的首部来确认收到的数据。在处理超时的许多情况中,也会发送不带任何数据的报文段。

二.数据传输连接建立的三次握手

在这里插入图片描述
第一次握手:主机 A 发送控制位 SYN=1,随机产生序列码 seq number=x 的数据包到服务器;

第二次握手:(主机 B 会由 控制位SYN=1 得知,A 要求建立联机)主机 B 收到请求后要确认联机信息,向A发送确认号 ack number=( 主机 A 的
seq number +1 ),SYN=1,ACK=1,随机产生序列码seq number=y 的数据包

第三次握手:主机 A 收到B的确认信息时检查 ack number 是否正确(即第一次发送的 seq number+1),以及位码ack 是否为 1,若正确,主机 A 会再发送确认号 ack number=(主机 B 的 seq number +1 ),ack=1的数据包,并进入“已建立连接”的状态,主机 B 收到后确认信息正确后进入“已连接状态”

关于为什么需要第三次握手的问题(两次握手不是能保证A和B可以建立连接了么,为什么需要第三次握手?):
参考:https://blog.csdn.net/lengxiao1993/article/details/82771768(个人觉得其下的讨论也很精彩)

教材中的回答是:

“防止已失效的连接请求又传送到服务器端而产生错误”(原来滞留在网络中的连接请求到达服务器端)

参考博客的回答:

“为了实现可靠数据传输, TCP 协议的通信双方, 都必须维护一个序列号, 以标识发送出去的数据包中, 哪些是已经被对方收到的。三次握手的过程即是通信双方相互告知序列号起始值, 并确认对方已经收到了序列号起始值的必经步骤”

“如果只是两次握手,至多只有连接发起方的起始序列号能被确认, 另一方选择的序列号则得不到确认”

参考博客中认为教材的回答是有误的,但我个人认为参考博客和教材的回答都合理吧。

个人认为参考博客的回答强调TCP协议的保证数据的顺序,客户端和服务端都需要确认对方收到序列号的起始值才能建立连接。按上图来说,如果没有第三次握手,不会有ack number = y+1,即连接发起方没有要求主机B发送下一个数据包的seq number。那这是B可以发送其他序列号的数据包,导致数据的乱序(A此时要的是seq number = y+1的数据包)。

而教材的回答片面些,如果有第三次握手,如上图所示,主机A就知道下一个要接收的数据包是序列号y+1的数据包,当滞留的连接请求到达B,B再发送第二次握手的请求确认的数据包时,数据包序列号不符合,主机A会丢弃这个包从而连接失败。所以个人认为也是序列号顺序问题。
借用参考博客中的一条评论:

这不是设计三次请求的原因,而是如果设计成两次请求会出现的错误,而真正设计成三次就是为了消息的保真和有序,同时能避免那个问题而已

三.数据传输连接断开的四次挥手

在这里插入图片描述
TCP 连接是全双工的(即数据可在两个方向上同时传递)所以进行关闭时每个方向上都要单独进行关闭。这个单方向的关闭就叫半关闭。当一方完成它的数据发送任务,就发送一个 FIN 来向另一方通告将要终止这个方向的连接。
第一次挥手:关闭客户端到服务器的连接:首先客户端 A 发送一个 FIN,用来关闭客户到服务器的数据传送,然后等待服务器的确认。其中终止标志位 FIN=1,序列号 seq=u

第二次挥手: 服务器收到这个 FIN,它发回一个 ACK,确认号 ack 为收到的序号加 1。

第三次挥手: 关闭服务器到客户端的连接:也是发送一个 FIN 给客户端。

第四次挥手: 客户端收到 FIN 后,并发回一个 ACK 报文确认,并将确认序号 seq 设置为收到序号加 1。 首先进行关闭的一方将执行主动关闭,而另一方执行被动关闭。

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值