安徽省工程建设信息官方网站,谁做的四虎网站是多少钱,新闻发布会主题,wordpress禁止拖拽文章目录 一. TCP和UDP简介二. UDP 协议详解1. UDP报文格式2. UDP的使用场景 三. TCP 协议详解1. TCP报文格式2. TCP协议的重要机制确认应答#xff08;保证可靠传输的最核心机制#xff09;超时重传连接管理#xff08;三次握手、四次挥手#xff09;#xff01;#xf… 文章目录 一. TCP和UDP简介二. UDP 协议详解1. UDP报文格式2. UDP的使用场景 三. TCP 协议详解1. TCP报文格式2. TCP协议的重要机制确认应答保证可靠传输的最核心机制超时重传连接管理三次握手、四次挥手滑动窗口流量控制拥塞控制延时应答捎带应答面向字节流异常情况处理 3. TCP的使用场景 前言 本文是对计算机网络学习中传输层两个重要协议 TCP和UDP 特性的介绍和部分细节的详细说明。
一. TCP和UDP简介 TCPTransmission Control Protocol中文名为传输控制协议是一种面向连接的、可靠的、基于字节流的传输层通信协议。 UDPUser Datagram Protocol中文名为用户数据报协议是一种无连接、不可靠的、面向数据报的传输层通信协议。 TCP和UDP 有以下特点
TCP是有连接的UDP是无连接的TCP提供可靠传输UDP提供不可靠传输TCP数据传输面向字节流UDP面向数据报TCP和UDP都是全双工的共同点 有连接 VS 无连接
“连接”是一种抽象的概念指客户端和服务器在进行数据传输前需要保存对端的关键信息如IP地址、端口号等并且依靠保存的信息来发送/接收数据。
TCP 要想通信需先建立连接只有连接完成后才能完成后续的通信若连接过程中一方拒绝了则无法进行数据的发送或接收。例如当我们通过社交软件或电话向某人发起通话请求时只有对方接听才可进行后续通信过程。 相比之下 UDP 无需经过对方的同意即可直接发送数据且不会保存对方的信息。由于 UDP 这种“健忘”的特点客户端/服务器每次发送数据时都需指定 IP和端口号 才能完成数据的传输由写程序的人指定。
可靠传输 VS 不可靠传输
在复杂的网络环境中数据传输可能存在丢包的情况这些缺失的数据可能导致得到的信息不能被正确解析。面对这种情况TCP 会将丢失的数据包重新传输来保证通信双方都尽量得到正确的数据原因是 TCP 内部提供了一系列重要机制来保证这种可靠传输而 UDP 则没有这种可靠传输机制如果数据包在网络传输过程中丢失了UDP 是“没有感知”的因此不会将丢失数据包重传。
看起来 TCP 提供的传输机制似乎“很香”那么为啥 UDP 不实现可靠传输呢 原因其实很简单1. 保证可靠传输需要实现更多复杂的机制 2. 可靠传输以传输效率作为交换条件因此 TCP的传输效率远比 UDP更低。
面向字节流 VS 面向数据报
TCP 与文件操作一样都是以字节为单位进行数据传输的所有的数据都被视为一连串的字节流在传输时会被分割成若干大小合适的数据段到达后再按顺序被重新组装成完整的字节流。 由于数据以一连串字节流的形式存在因此在写入或读取时没有严格的对应关系即数据读取时可根据需要读取任意字节数的数据。
UDP 是面向数据报传输数据的所有的数据都被视为一个个的数据报其中每个 UDP数据报都包含了完整的数据以及源/目的端口等信息因此数据在写入/读取时以单个数据报位为单位。
TCP与UDP 都是全双工
全双工即通信双方既可以发送数据也能够接收数据且发送和接收数据能够同时进行不需要等待对方完成其中某个操作。 二. UDP 协议详解
1. UDP报文格式 源/目的端口号用于绑定通信双方主机上的进程表示数据从哪个进程发出由哪个进程接收。 UDP报文长度UDP报头大小 UDP载荷大小即整个UDP报文的大小。它可以表示一个2个字节的数据最大为 2^16 - 1 65535 ≈ 64Kb单位为字节因此一个UDP数据报最大可以携带 64KB的数据。 实际上最大可传输的数据大小应为 64K - 8 字节报头部分但由于8与64K相差较大一般可忽略不计。 UDP校验和即将UDP载荷中的数据通过一定方式计算得到的16位数据用于检测UDP头部和数据部分在传输过程中是否发生错误。
为什么需要校验和 我们都知道数据是通过 光信号/电信号的“频率”和“强弱”来表示的其中高电频表示 1低电频表示 0。数据在网络传输过程中由于受到某些外部因素的干扰如电场、磁场、高能离子等可能让表示0的低电频变为表示1的高电频也称作比特翻转导致数据在传输的过程发生错误。因此数据包携带的校验和就变得十分必要。
如何通过校验和验证数据是否出错 先将数据在发送前进行校验和的计算并将校验和与数据等信息一起发送给通信对端当数据送达后接收方再通过收到的数据进行校验和的计算然后将得到的校验和与数据包中的校验和进行比较若比较的结果不一致则说明数据在传输的过程中大概率出错了。
这时候可能有人会好奇如果接收方收到的数据只有非常少的地方不同那么是否可能得到一样的校验和 答案是否定的因为就算只有十分微小的不同计算出来的校验和往往是天差地别的。如MD5它是一种hash算法能够把任意长度的原始数据映射成为 128bit 的数据。如下图只改变一个字母计算出来的结果差别非常大
也许也有人会有这种疑问如果数据传输过程中出错了并且校验码也发生了错误那么是否可能得到一样的校验和 答案是理论上存在这种可能但是概率非常非常小基本可以忽略不计。
2. UDP的使用场景
UDP适用于对高速传输和实时性要求较高、对稳定性和可靠性要求不高、可以容忍少量数据丢失的场景。如早期的QQ、音视频传输、广播等。
基于 UDP 的部分应用层协议
NFS网络文件系统TFTP简单文件传输协议DHCP动态主机配置协议BOOTP启动协议用于无盘设备启动DNS域名解析协议 三. TCP 协议详解
1. TCP报文格式 由TCP报文格式我们可以粗略知道以下信息 源/目的端口号这里的端口号与UDP报文中的端口号作用一致都用于定位通信双方主机的进程。 校验和用于检查 TCP头部和数据部分是否发生错误。 首部长度也称作 “数据偏移”用于确认 TCP首部 的长度它表示一个 0 ~ 15 的数据单位为 4个字节。由于 TCP拥有固定20字节的首部因此数据偏移最小值为 5 若数据偏移小于5则该TCP报文违反了TCP协议的规范被视为格式错误又因此一个 TCP数据包的大小为 20 ~ 60字节。 保留位表示一个 6位 的数据目前暂未使用置为0。保留位的作用是为了将来改进 TCP协议时提供一定的灵活性和可拓展性以适应不断变化的网络环境和应用需求。 校验和用于检测 TCP首部和数据部分在传输过程是否发生错误。 除了以上信息TCP 相比于 UDP 还存在许多额外的字段来 保证TCP的可靠传输 及 支持其他功能。
序列号占4个字节范围是 0 ~ 2^32 - 1当序列号超过最大值重置为0序列号用于标识此次发送数据的顺序它的值为该报文段中数据部分的第一个字节的序号。例如某个 TCP报文的序列号为101发送的数据为 200字节则下一个 TCP报文的序列号应该为 301……如下图 确认序列号确认序列号的值为某个TCP数据包中 序列号 数据的字节数。用于确认接收到的数据表示在该值之前的所有数据都已确认接收到且期待数据发送方下一次发送的数据为确认序列号后的数据。如下图
TCP首部中的 6个标志位用于控制 TCP连接的建立、终止和数据传输过程中的各种状态。各标志位作用如下
URGUrgent当URG被置为1时表示紧急指针字段的值有效该标志位的作用是告知接收方该 TCP报文中紧急指针字段所指示的数据被视为紧急数据需要优先处理。ACKAcknowledgment当ACK被置为1时表示确认序列号字段的值有效它用于确认接收到的数据。在 TCP连接的数据传输过程中数据接收方每次收到数据后都会返回一个带有ACK标志位的 TCP报文通知发送端已成功接收到数据。PSHPush当PSH被置为1时表示数据接收端应尽快把接收到的数据推送给应用层而不是等待缓冲区满后再传输。RSTReset当RST标志位被置为1时表示发生了严重的错误或连接出现异常需要中断TCP连接并重置连接状态。SYNSynchronized当SYN标志位被置为1时表示当前通信双方处于正在建立连接的状态通常出现在“三次握手”中。FINFinish当FIN标志位被置为1时表示发起方已经完成了数据发送告知接收方即将断开 TCP连接。 窗口大小表示数据接收端允许发送端发送的最大数据量。紧急指针表示紧急数据的结束位置在数据流中的偏移量与URG标志位配合使用。选项为可选字段且长度不定用于提供一些额外的功能和控制信息。若使用了选项则该字段的大小为 4字节的倍数最大为偏移量的最大值 15 * 4 - 20 60 - 20 40字节。
2. TCP协议的重要机制
TCP 相比于 UDP 之所以有更多的应用场景最最核心的因素就是 TCP提供可靠传输初心可靠传输并不是要求网络数据被 100% 送达而是当数据包丢失时TCP 能够依靠内部一系列重要机制实施相应的“补救”措施。下面是对 TCP 内部一些重要的机制的介绍。
确认应答保证可靠传输的最核心机制
在使用 TCP 进行网络通信时当发送方把数据发给接收方之后接收方如果收到数据会返回一个 “应答报文”当发送方收到“应答报文”后就可以知道自己的数据是否发送成功了。这个返回“应答报文”的机制就是确认应答确认应答是 TCP保证可靠传输最核心的机制。
确认应答的实现主要依靠 序列号和确认序列号 这两个字段来完成。 若通信双方约定好开始传输数据时的起始序列号为 1发送方每次发送的数据为 1000个字节即此次数据的“编号”为 1 ~ 1000则接收方收到数据后会返回一个不携带业务数据、确认序列号为 1001的 TCP报文发送方收到该报文后就知道了 1001之前的所有数据都已成功送达若数据发送方收到 确认序列号为 4001 的报文则意味着序号为 3001 ~ 4000 的数据已成功送达且期待发送方下次发送序号 4001 后的数据……如下图
在真实的网络环境中网络线路往往十分复杂每个 TCP 数据包经过哪些路线到达目的地是不确定的因此可能出现数据“晚发先至”的情况导致数据被错误解析。如下图 面对数据“后发先至”的情况 传输层会将接收到的 TCP报文都存放到缓冲区因此先到达的数据会“等一等”晚到达的数据并将所有数据根据 序列号 进行排序保证数据顺序的正确性。
序列号和确认序列号 作用总结
确认数据是否成功送达。确保发送数据与应答报文能够一一对应确保出现“后发先至”的情况时应用程序能够按照正确的顺序进行解析。
超时重传
由于网络环境存在复杂性当出现网络拥塞、链路错误、路由器故障等情况时网络数据包可能出现丢失的情况。 当数据发送方超过一定时间都没有收到ACK报文时会将原先的 TCP数据包进行重传。触发超时重传可能存在两种情况1.发送方发送的数据包丢失 2. 数据接收方返回的 ACK数据包丢失。 发送数据包丢失 当发送的数据包丢失时接收方没有收到数据则一定不会返回应答报文这时发送方由于迟迟没有收到 ACK为1 的TCP数据包在经过一定时间后便将 数据2 进行重发。 应答报文丢失 由于接收方返回的应答报文在传输过程中丢失了发送方无法收到应答报文但它不能确定是 发送的数据丢失还是ACK数据包丢失因此会将数据2进行重发然后等待数据接收方第二次返回的应答报文当确认数据送达后再继续发送后续的数据。 在这个过程中数据接收方会收到两份同样的数据如果不对这两份数据进行相应的处理可能会造成一些严重后果如在进行扣款操作时付款人已经完成了一次扣款由于返回的应答报文丢失触发了超时重发导致多进行了一次扣款操作。 因此当收到多份同样的数据时接收方会将多余的 TCP数据包丢掉。
思考若传输过程中数据包丢失经历重传操作后发送方仍然没有收到应答报文那发送方是否无限制触发重传操作呢 答案是否定的。这里我们假设当前网络数据包的单次丢包率为 20%这个概率是非常大的在正常的网络通信中基本不会达到这个值则两次数据传输的丢包率为 4%三次传输的丢包率为 0.8%……可以发现随着重传次数的提高数据被正确送达的概率会大大提高。 因此当重传达到一定次数后发送方可能会采取 直接断开或断开重置 TCP连接的操作。在数据重传过程中触发重传的间隔会逐渐增长对数据传输成功持悲观态度原因是随重传次数增加丢包率逐渐降低如果多次重传都没有响应说明当前网络已经出现了严重故障。
连接管理三次握手、四次挥手
建立连接三次握手
在网络通信中通信双方若通过 TCP协议传输数据需要在数据传输前通过发送不协议业务数据的 TCP数据包 建立连接。如下图 如上图所示通信双方都需要发送SYN和收到ACK 为1的 TCP数据包完成上述过程后才算真正地建立连接。
可能有人会好奇不是叫三次握手吗为什么上述交互过程有 4个步骤 原因是当对端收到建立连接的请求后会立即返回 ACK报文而一个 TCP报文中有 6个标志位因此可以在返回 TCP报文时把 ACK和SYN 同时置为1将两个报文合二为一因此通信双方建立连接总共经历了 “3次握手”。如下图
或许有人还有疑问为什么一定是“3次握手”不能“2次握手”、“4次握手”吗 假设有以下通话过程电话刚接通
为了保证后续正常的通信交流小明和小红需要先用约定好的特殊暗号向对方“打招呼”以确认双方的麦克风和听筒都是正常工作的状态。对方只有在听到前面的暗号才会按照约定进行下一步的回应。如下图
“三次握手”的核心作用
起到“投石问路”的作用确认当前网络是否通畅让通信双方确认各自的发送能力和接收能力是否正常针对通信过程中一些重要的参数进行“协商”
因此为什么经过“3次握手”是显而易见的如果是“2次握手”则一方不能得到通信所需要的全部信息而“4次握手”实际上是可行的但第4次握手其实是多余的因为“3次握手”就可完成信息交换的操作。 断开连接四次挥手 为避免占用网络资源和系统资源导致的性能下降或资源耗尽当数据传输完毕后应断开 TCP连接。如下图
如上图所示通信双方都需要发送FIN和收到ACK 为1的 TCP数据包完成上述过程后才算真正地断开连接。
思考一可以发现断开连接的过程与建立连接的过程非常相似唯一的不同之处就是“3次握手”过程中 ACK SYN标志位可以合并那断开连接的过程中客户端发送的 ACK FIN标志位是否也能合并为1个 TCP报文呢 答案是不一定。原因是当客户端收到 FIN 为1的 TCP报文时操作系统内核会立即返回 ACK为1的 TCP报文而是否立即发送 FIN取决于客户端的代码实现中是否存在其他代码逻辑需要处理因此通常情况下断开连接过程中ACK 和 FIN 往往不能合并发送。
思考二当服务器收到 带有FIN标志位的TCP报文时可以知道客户端已确认释放连接但为什么没有立刻进入 CLOSED状态断开连接而是进入 TINE_WAIT状态等待一段时间后再真正释放连接 如果服务器收到 FIN后立即断开连接、销毁了之前保存的对方信息而返回带有 ACK的TCP报文在网络传输的过程中丢失了。由于客户端迟迟没有收到最后一个ACK它会触发超时重传等待服务器重发的 ACK又因为服务器此时已经销毁了客户端的 IP、端口号等信息对于接收到的FIN它并不知道要如何处理。而客户端经过多次重传无果后才会强制断开 TCP连接非正常断开。 因此之所以服务器收到 FIN后会等待一段时间后再断开连接是为了防止最后一个 ACK丢失时能够对客户端重发的 FIN进行响应。
滑动窗口
当通信双方利用 TCP 进行数据传输时实际上并不是每发送一条数据等待收到 ACK确认应答再继续发送下一条数据因为那样做虽然保证了数据的可靠传输但效率十分低下。因此在实际通信过程中发送方往往是一次性发送多条数据收到其中某个响应再继续发送数据。如下图 在上图中主机A发出第一条数据还没等 ACK回来便发送第二、三条数据……在这样“批量发送”的机制下数据的传输效率会大大提高。理论情况下当一次性发送的数据量越大数据传输效率越高但在实际情况中因为受到接收方的数据处理能力、网络畅通程度、网络链路中结点的拥塞情况等因素的影响数据发送方在不等待的情况下能够批量传输的数据有一个上限值这个值称为“窗口大小”。
在窗口大小固定的情况下当主机A接收到第一个返回的ACK时可立即发送余下的数据在视觉上就像一个会滑动的窗口因此发送方批量发送数据的机制也称作“滑动窗口”。 思考1若在数据的传输过程中主机B已接收到主机A发送的所有数据但某个返回的 ACK 在传输过程中出现丢失主机B需要重传吗 答案是不需要。因为确认应答报文中确认序列号的作用是“说明该确认序列号前的所有数据已经收到”。因此就算前面的 ACK丢失了只要主机A收到后面的 ACK就说明主机B已成功接收前面的数据。
思考2由于主机A是批量发送数据的若某条数据在传输过程中出现丢失主机B收到其他数据会怎样返回应答报文如下图 如上图所示若序号为 1001 ~ 2000 的数据在传输过程丢失了又因为 1 ~ 1000 的数据已经收到主机B“期望”下次收到序列号为 1001的 TCP数据包因此每次收到数据时都会对 TCP首部进行检查若不是想要的数据则继续返回确认序列号为 1001的确认报文直到收到数据为止。 虽然主机B 期望得到 1001 ~ 2000的数据但对于已经接收的其他数据包并不会直接丢弃而是在缓冲区中保存着等到收到期待的数据下次返回的应答报文中确认序列号则为所有收到数据中最大序号的下一位数。
流量控制
滑动窗口的机制就是在保证可靠传输的前提下尽量提高数据传输效率。理论情况下窗口值越大等待 ACK 的时间就越长数据的传输效率也就越高但如果数据的发送量太大且超过了接收方的处理能力一些数据包可能会被接收方直接丢弃因此数据接收方也需要采取某些手段去限制数据发送方即限制窗口大小。 如上图所示主机A 发送的数据会通过网络到达主机B的操作系统内核中在操作系统 API 提供的TCP Socket对象中有一个数据接收缓冲区由主机A发送过来的数据会先到达该缓冲区中应用程序再采用read()方法从缓冲区中读取数据。 上述场景就是一个典型的生产者消费者模型数据发送方称为生产者数据接收方称为消费者。当发生方的生产能力超过了接收方的消费能力时缓冲区的空间会逐渐变小直到缓冲区被占满时多余的数据会被直接丢弃此时主机A 再发送数据是“没有意义”的应先暂停对数据的发送。
思考1在数据传输过程中主机A是如何得知主机B的缓冲区还有多大空间的呢 答案是接收方在返回的应答报文中通过 TCP报文中 “窗口大小”字段来告知数据发送方此时自己最多还能接收多少数据通过减小“窗口大小”去限制发送方数据的发送。
思考2当窗口大小为 0 时发送方会暂停发送数据那它如何知道何时可以重新发送数据呢 答案是虽然发送方暂时不传输业务数据但仍然会周期性的发送一个“不带业务数据的窗口探测包”发送该探测包主要是为了触发ACK通过返回的应答报文来得知此时窗口的大小由此判断是否恢复数据的发送及可发送的数据量。
如下图
拥塞控制
数据在实际的网络传输过程中不仅要权衡发送方和接收方的数据发送和接收能力还需考虑通信过程中间节点的情况。如下图 由“木桶原理”可知整个通信过程中数据传输量取决于数据处理能力最弱的节点。即使接收方能够处理发送方发送的数据但由于某些因素导致中间节点数据处理能力下降也会出现丢包的情况。
在实际的网络通信链路中存在很多的节点、传输路径路径上的每个节点处理能力达到上限都可能对发送方产生影响影响到可靠传输。因此我们往往将网络上的所有传输节点当作一个整体通过“测试”的方法在发送方发送能力、接收方数据处理能力、中间节点数据处理能力之间找到一个“平衡点”进而确认一个合适的“窗口大小”。
如何进行测试TCP 引入了慢启动机制在刚开始传输数据时先发送少量的数据“探探路”“探路”是为了以摸清当前的网络拥塞情况若当前网络已存在严重阻塞盲目发送大量数据反而会造成“雪上加霜”的情况。随后逐渐加大数据的传输量最后再决定按照多大的传输速率去传输数据。如下图 上图的拥塞窗口反映了数据发送量的大小可以发现刚开始只发送少量数据随后数据发送量呈指数形增长当发送量达到“慢启动的阈值”ssthresh后呈线性增长直到出现网络拥塞后数据发送量会直线下降到 1 。后面数据的发送量增长趋势与之前相似但每一次增长都会重新确定一个“阈值”以避免过快的增长导致数据发送量出现频繁“大起大落”从而白白消耗网络资源。
上图中窗口值出现的“断崖式下降”其实也是不科学的因为网络出现拥塞的情况可能是短暂的并不需要将拥塞窗口一下子降为 1而是降到一个合适的值这样同样保持数据在网络的稳定传输。因此后来TCP协议对拥塞窗口的变化也进行了改善。如下图
注意发送方每次发送数据包的时候会将拥塞窗口和流量控制中反馈的窗口大小做比较取较小的值作为实际发送的窗口。
延时应答
正常情况下接收方收到数据时操作系统内核立即返回 ACK但在某些情况下操作系统也可能等一会再返回 ACK。这种“等一等再返回ACK”的机制称为延时应答。
延时应答本质上是为了提高传输效率。在流量控制中数据接收方是通过数据缓冲区剩余空间的大小来决定返回窗口值大小的而窗口值决定了发送方的传输速率如果让窗口值更大也就提高了数据的传输效率。 因此操作系统如果适当延时返回 ACK应用程序就能从缓冲区中读取更多数据从而增大了应答报文中的窗口值。例如如果接收缓冲区的大小为5MB在某一刻接收方收到了 512K的数据如果立即返回响应则窗口大小为 4.5MB但如果此时接收端处理数据的速度很快只需 100ms 就能将这 512KB 的数据处理完那么延时 100ms 后再返回 ACK窗口的大小就仍为 5MB。
捎带应答
在应用层中不同主机上的进程的交互通常也是“一问一答”的形式。如主机A发送“查询余额”服务器回复“当前剩余金额为100元”。正常情况下数据到达传输层后操作系统内核会立即返回 ACK接着数据再被应用层的程序读取等待数据处理完毕后将响应封装成 TCP数据包发送给主机A。
在上述过程中经历了两次 TCP数据包的封装和发送。但由于延时应答机制的存在ACK可以不被立即返回等待应用程序处理完数据后将数据与 ACK 统一封装再发送给客户端。这种通过延时应答将响应数据与ACK统一返回的机制称为捎带应答。
面向字节流
由于 TCP 是以字节流的形式传输数据因此可能出现“粘包”问题面向字节流的机制都存在类似情况。
什么是粘包问题什么情况会出现粘包问题 “粘包”中的包指应用层数据包当多个应用层数据包被同时传过去时就可能出现“粘包”问题。如下图 如上图在接收缓冲区中3个 TCP数据包 所携带的应用层数据以字节流的形式仅仅挨在一起的。接收方的应用程序在读取数据时可以一次性读取 1个字节的数据也可以读 2个字节的数据具体取决于程序的实现字节流形式的数据虽然能被自由读取但也带来了应用程序无法区别哪些数据是一个完整的应用层数据包的问题。
相比之下使用 UDP 传输数据则不存在这样的问题因为 UDP 是以一个个 UDP报文传输数据的因此每个报文都有明显的分界线并且每个 UDP 数据包携带的就是完整的数据。
思考如何解决字节流的“粘包”问题 答案是1. 引入分隔符 2. 引入长度
引入分隔符使用“约定好的分隔符”作为每条完整的应用层数据的分界线。如下图 引入长度在每条完整的数据之前引入该数据的长度应用程序在读取数据时先确定该条数据的长度再根据长度读取对应的字节数以读取完整的应用层数据包。
异常情况处理
在使用 TCP 传输数据时可能出现某些意外当意外发生时通信双方会如何处理 进程崩溃 进程崩溃属于进程异常终止文件描述符表也就释放相当于调用了 socket.close()触发FIN对方收到 FIN后自然也会返回 ACK和FIN此时最后一个 ACK仍然可以被正常返回这个过程相当于完成了正常4次挥手的流程。原因是虽然进程结束了但 TCP 连接是可以独立于进程之外存在的。 主机关机正常流程 当主动关闭电源时计算机会在真正关闭之前销毁正在运行的进程此时也相当于调用了 socket.close()触发FINTCP连接的对端收到 FIN后会返回 ACK和FIN假如在 ACK和FIN 到达之后计算机还没真正被关闭就仍然可以返回ACK完成4次挥手的过程如果 ACK和FIN到达之前计算机已经销毁掉所有进程且被关闭了则不能返回 ACK因此对方会进行多次超时重传多次重传仍无响应则自动放弃连接把持有的对端信息删除。 主机掉电非正常 主机掉电是一瞬间的事情来不及杀进程也来不及发送FIN便直接停机了。面对这种情况作为 TCP连接的对端可能存在两种处理情况。 1如果掉电的是数据发送方对端作为数据接收方。接收方面对长期没有数据送达的情况其实并不知道是对端没有发消息还是对方挂了。TCP 内部提供了“心跳包”的机制 面对上述情况数据接收方会周期性地向对方发送一个不携带任何业务数据的 TCP数据包发送该数据包是为了得到对方的响应。如果多次发送“心跳包”无果后接收方会认为对方已经挂了随后放弃 TCP连接。
2如果掉电方是数据接收方对端作为数据发送方。发送方在发送了若干数据后都没有收到应答报文此时会触发超时重传多次重传无果后便触发 TCP 连接重置功能即将复位报文段 RST 置为1若依然没有效果则直接释放连接。
网线断开 网线断开与主机掉电的情况非常类似。若掉电方为数据发送方则接收方会周期性发送“心跳包”如果没有得到任何响应则最终放弃连接若掉电方为数据接收方则发送方会先触发超时重传重传无果后尝试进行连接重置若连接重置也没有效果则放弃 TCP连接。
3. TCP的使用场景
TCP适用于对可靠性、对数据传输的完整性有较高要求的场景。如文件传输、Web浏览、电子邮件、远程登录等。
基于 TCP 的部分应用层协议
HTTPHTTPSSSHTelnetFTPSMTP 以上就是本篇文章的全部内容了如果这篇文章对你有些许帮助你的点赞、收藏和评论就是对我最大的支持。 另外文章的不足之处也希望你可以给我一点小小的建议我会努力检查并改进。
