佛山做礼物的网站,做小程序商城,wordpress首页文件打不开,网页编辑工具2022目录
一. 前言
二. TCP 报文的头部结构
三. 三次握手
3.1. 三次握手过程
3.2. 为什么要三次握手
四. 四次挥手
4.1. 四次挥手过程
4.2. 为什么要四次挥手
五. 大白话说
5.1. 大白话说三次握手
5.2. 大白话说四次挥手
六. 总结 一. 前言 TCP 是一种面向连接的、可靠…目录
一. 前言
二. TCP 报文的头部结构
三. 三次握手
3.1. 三次握手过程
3.2. 为什么要三次握手
四. 四次挥手
4.1. 四次挥手过程
4.2. 为什么要四次挥手
五. 大白话说
5.1. 大白话说三次握手
5.2. 大白话说四次挥手
六. 总结 一. 前言 TCP 是一种面向连接的、可靠的、基于字节流的传输层通信协议在发送数据前通信双方必须在彼此间建立一条连接。所谓的“连接”其实是客户端和服务端保存的一份关于对方的信息如IP 地址、端口号等。TCP 可以看成是一种字节流它会处理 IP 层或以下的层的丢包、重复以及错误问题。在连接的建立过程中双方需要交换一些连接的参数。这些参数可以放在 TCP 头部。一个 TCP 连接由一个4元组构成分别是两个 IP 地址和两个端口号。一个 TCP 连接通常分为三个阶段连接、数据传输、退出关闭。通过三次握手建立一个链接通过四次挥手来关闭一个连接。当一个连接被建立或被终止时交换的报文段只包含 TCP 头部而没有数据。 所谓“任 TCP 虐我千百遍我仍待 TCP 如初恋”。“不管面试 Java 、C/C、Python 等开发岗位 TCP 的知识点可以说是的必问的了。我们都知道TCP是面向连接的三次握手就是用来建立连接的四次挥手就是用来断开连接的。
二. TCP 报文的头部结构
在了解 TCP 连接之前先来了解一下 TCP 报文的头部结构 TCP Header 上图中有几个字段需要重点介绍下 1序号seq 序号占32位用来标识从 TCP 源端向目的端发送的字节流发起方发送数据时对此进行标记。 2确认序号ack 序号占32位只有 ACK 标志位为1时确认序号字段才有效ackseq1。 3标志位共6个即 URG、ACK、PSH、RST、SYN、FIN 等具体含义如下
ACK确认序号有效。FIN释放一个连接。PSH接收方应该尽快将这个报文交给应用层。RST重置连接。SYN发起一个新连接。URG紧急指针urgent pointer有效。需要注意的是不要将确认序号 ack 与标志位中的ACK 搞混了。确认方 ack 发起方 seq1两端配对。
三. 三次握手 三次握手的本质是确认通信双方收发数据的能力。首先我让信使运输一份信件给对方对方收到了那么他就知道了我的发件能力和他的收件能力是可以的。于是他给我回信我若收到了我便知道我的发件能力和他的收件能力是可以的并且他的发件能力和我的收件能力是可以。然而此时他还不知道他的发件能力和我的收件能力到底可不可以于是我最后回馈一次他若收到了他便清楚了他的发件能力和我的收件能力是可以的。这就是三次握手。 3.1. 三次握手过程 我们来看一下三次握手的过程
1. 准备阶段 一开始客户端和服务端都处于 CLOSED 状态。客户端主动打开连接服务端被动打卡连接结束CLOSED 状态开始监听进入 LISTEN 状态。
2. 第一次握手 客户端会随机初始化序号client_isn将此序号置于 TCP 首部的「序号」字段中同时把 SYN 标志位置为 1 表示 SYN 报文。接着把第一个 SYN 报文发送给服务端表示向服务端发起连接该报文不包含应用层数据之后客户端处于 SYN-SENT 状态。
3. 第二次握手 服务端收到客户端的 SYN 报文后首先服务端也随机初始化自己的序号server_isn将此序号填入 TCP 首部的「序号」字段中其次把 TCP 首部的「确认应答号」字段填入 client_isn 1, 接着把 SYN 和 ACK 标志位置为 1。最后把该报文发给客户端该报文也不包含应用层数据之后服务端处于 SYN-RCVD 状态。
4. 第三次握手 客户端收到服务端报文后还要向服务端回应最后一个应答报文首先该应答报文 TCP 首部 ACK 标志位置为 1 其次「确认应答号」字段填入 server_isn 1 最后把报文发送给服务端这次报文可以携带客户到服务器的数据之后客户端处于 ESTABLISHED 状态。
好了经过三次握手的过程客户端和服务端之间的确定连接正常接下来进入 ESTABLISHED 状态服务端和客户端就可以快乐地通信了。
这里有个动态过程的图示 这里有个小细节第三次握手是可以携带数据的这是面试常问的点。
3.2. 为什么要三次握手
为什么要三次握手呢两次不行吗
为了防止服务器端开启一些无用的连接增加服务器开销防止已失效的连接请求报文段突然又传送到了服务端因而产生错误。
由于网络传输是有延时的要通过网络光纤和各种中间代理服务器在传输的过程中比如客户端发起了 SYN1 的第一次握手。
如果服务器端就直接创建了这个连接并返回包含 SYN、ACK 和 Seq 等内容的数据包给客户端这个数据包因为网络传输的原因丢失了丢失之后客户端就一直没有接收到服务器返回的数据包。
如果没有第三次握手告诉服务器端客户端收的到服务器端传输的数据的话服务器端是不知道客户端有没有接收到服务器端返回的信息的。服务端就认为这个连接是可用的端口就一直开着等到客户端因超时重新发出请求时服务器就会重新开启一个端口连接。
这样一来就会有很多无效的连接端口白白地开着导致资源的浪费。
这个过程可理解为 还有一种情况是已经失效的客户端发出的请求信息由于某种原因传输到了服务器端服务器端以为是客户端发出的有效请求接收后产生错误 所以我们需要“第三次握手”来确认这个过程 通过第三次握手的数据告诉服务端客户端有没有收到服务器“第二次握手”时传过去的数据以及这个连接的序号是不是有效的。若发送的这个数据是“收到且没有问题”的信息接收后服务器就正常建立 TCP 连接否则建立 TCP 连接失败服务器关闭连接端口。由此减少服务器开销和接收到失效请求发生的错误。
四. 四次挥手
4.1. 四次挥手过程
还是先上图 四次挥手 聚散终有时TCP 断开连接是通过四次挥手方式。双方都可以主动断开连接断开连接后主机中的「资源」将被释放。
上图是客户端主动关闭连接
第一次挥手 客户端打算关闭连接此时会发送一个 TCP 首部 FIN 标志位被置为 1 的报文也即 FIN 报文之后客户端进入 FIN_WAIT_1 状态。
第二次挥手 服务端收到该报文后就向客户端发送 ACK 应答报文接着服务端进入 CLOSED_WAIT 状态。
第三次挥手 客户端收到服务端的 ACK 应答报文后之后进入 FIN_WAIT_2 状态。等待服务端处理完数据后也向客户端发送 FIN 报文之后服务端进入 LAST_ACK 状态。
第四次挥手
1. 客户端收到服务端的 FIN 报文后回一个 ACK 应答报文之后进入 TIME_WAIT 状态 2. 服务器收到了 ACK 应答报文后就进入了 CLOSED 状态至此服务端已经完成连接的关闭 3. 客户端在经过 2MSL 一段时间后自动进入 CLOSED 状态至此客户端也完成连接的关闭。
你可以看到每个方向都需要一个 FIN 和一个 ACK因此通常被称为四次挥手。
4.2. 为什么要四次挥手
为什么要挥手四次
再来回顾下四次挥手双方发 FIN 包的过程就能理解为什么需要四次了。
关闭连接时客户端向服务端发送 FIN 时仅仅表示客户端不再发送数据了但是还能接收数据。服务器收到客户端的 FIN 报文时先回一个 ACK 应答报文而服务端可能还有数据需要处理和发送等服务端不再发送数据时才发送 FIN 报文给客户端来表示同意现在关闭连接。
从上面过程可知服务端通常需要等待完成数据的发送和处理所以服务端的 ACK 和 FIN 一般都会分开发送从而比三次握手导致多了一次。
为什么客户端在 TIME-WAIT 阶段要等 2MSL 为的是确认服务器端是否收到客户端发出的 ACK 确认报文当客户端发出最后的 ACK 确认报文时并不能确定服务器端能够收到该段报文。
所以客户端在发送完 ACK 确认报文之后会设置一个时长为 2MSL 的计时器。
MSL 指的是 Maximum Segment Lifetime一段 TCP 报文在传输过程中的最大生命周期。
2MSL 即是服务器端发出为 FIN 报文和客户端发出的 ACK 确认报文所能保持有效的最大时长。
服务器端在 1MSL 内没有收到客户端发出的 ACK 确认报文就会再次向客户端发出 FIN 报文
如果客户端在 2MSL 内再次收到了来自服务器端的 FIN 报文说明服务器端由于各种原因没有接收到客户端发出的 ACK 确认报文。
客户端再次向服务器端发出 ACK 确认报文计时器重置重新开始 2MSL 的计时。
否则客户端在 2MSL 内没有再次收到来自服务器端的 FIN 报文说明服务器端正常接收了 ACK 确认报文客户端可以进入 CLOSED 阶段完成“四次挥手”。
所以客户端要经历时长为 2SML 的 TIME-WAIT 阶段这也是为什么客户端比服务器端晚进入 CLOSED 阶段的原因。
这里同样有个动态过程的图示 四次挥手 五. 大白话说
5.1. 大白话说三次握手
在二十年前的农村电话没有普及手机就更不用说了所以通信基本靠吼。
老张和老王是邻居这天老张下地了结果家里有事热心的邻居老王赶紧跑到村口开始叫唤老王
老王老张唉我是老王你能听到吗老张一听是老王的声音老王老王我是老张我能听到你能听到吗老王一听嗯没错是老张老张我听到了我有事要跟你说。
老王你老婆要生了赶紧回家吧
老张风风火火地赶回家老婆顺利地生了个带把的大胖小子。
握手的故事充满了幸福和美满。 5.2. 大白话说四次挥手
假如博主有一个女朋友——只是“假如”该死的这不争气的眼泪怎么止不住地滴在键盘上。
由于博主上班九九六下班肝博客导致没有时间陪女朋友女朋友忍无可忍
女朋友臭男人最近你都不理我你是不是不爱我了你是不是外面有别的狗子了我要和你分手沙雕博主一愣怒火攻心分手就分手不陪你闹了等我把东西收拾收拾。
沙雕博主小心翼翼地装起了自己的青轴机械键盘
哼蠢女人我已经收拾完了我先滚为敬再见女朋友滚滚的远远的越远越好我一辈子都不想再见到你。
唉挥手的故事总充满了悲伤和遗憾 六. 总结 《TCP/IP详解 卷1:协议》有一张TCP状态变迁图很具有代表性有助于大家理解三次握手和四次挥手的状态变化。如下图所示粗的实线箭头表示正常的客户端状态变迁粗的虚线箭头表示正常的服务器状态变迁。
