网站制作网站建设项目规划书,百色网站建设,dede网站仿站经典工具,计算机类专业哪个好文章目录 前言1. TCP 协议概述2. TCP报头结构3. 如何理解封装和解包呢#xff1f;4. TCP的可靠性机制4.1 TCP的确认应答机制4.2 超时重传机制 5. TCP链接管理机制5.1 经典面试题#xff1a;为什么建立连接是三次握手#xff1f;5.2 经典面试题#xff1a;为什么要进行四次挥… 文章目录 前言1. TCP 协议概述2. TCP报头结构3. 如何理解封装和解包呢4. TCP的可靠性机制4.1 TCP的确认应答机制4.2 超时重传机制 5. TCP链接管理机制5.1 经典面试题为什么建立连接是三次握手5.2 经典面试题为什么要进行四次挥手 6. 流量控制7. 滑动窗口机制8. 拥塞控制9. 面向字节流的特性10. 粘包问题及解决方案11. TCP异常情况处理12. TCP 小结13. TCP与UDP的对比14. 用 UDP 实现可靠传输(经典面试题总结 前言
在计算机网络中传输层协议扮演着至关重要的角色它们负责在网络中的主机之间可靠地传输数据。其中TCP传输控制协议和UDP用户数据报协议是最常见的两种传输层协议。TCP以其可靠性、有序性和流量控制等特性成为了许多关键应用的首选协议如文件传输、电子邮件、Web 服务等。然而TCP的复杂性和性能开销也使得它在某些场景下不如UDP灵活和高效。本文将深入探讨TCP协议的各个方面从其基本机制到高级特性再到与UDP的对比帮助读者全面理解TCP的工作原理和应用场景。
1. TCP 协议概述
TCP 全称为 “传输控制协议(Transmission Control Protocol”). 人如其名, 要对数据的传输进行一个详细的控制;
2. TCP报头结构 一眼看去, TCP协议确实比UDP要复杂的多, TCP协议的报头并不是定长的, 你可能会发现它除了选项和数据的长度是定长的20字节。但是它的选项的长度是不定的. 在前20字节中有一个叫4位首部长度的字段。它代表了报头一共有多大 范围是: 20~60字节 TCP报头的其他字段数据, 比如: 序号, 确认序号, 窗口大小, 6位标志位等. 就是TCP用来保证它的效率和可靠性时需要使用到的字段
3. 如何理解封装和解包呢
OS内可不可以同时存在很多个收到的报文这个报文还没来得及处理甚至拷贝到传输层的接收缓冲区甚至没有交给传输层而在网络层和链路层。OS内一定会收到大量还没来得及处理的报文OS要不要对大量的暂未处理但以及接收到的报文进行管理呢要先描述再组织
添加报头只需要将head指针向左移动封装的过程就是指针移动填写报头 解包就是将head指针强转再提取他的字段之后将head指针向又移动。 封装和解包在内核中只需要进行指针移动即可 4. TCP的可靠性机制
4.1 TCP的确认应答机制
TCP 保证可靠性 确认应答保证历史消息被收到了可靠性是对历史消息的可靠性的一种保证 确认应答机制 比如主机A给主机B发送了1000字节的数据, 那么这个TCP包中的序号就为1000. 当B主机收到TCP包后, 会给A主机发送确认应答, 并且会将确认序号设置为1001, 代表1001以前的数据我都收到了. 可以从1001个字节开始给我发数据了。同理,要是B主机没有给A发送1001确认序号,而是直接发送了2001. 证明2001以前的数据都收到了, 包括1~1000的 tcp 发送消息的模式 ——version0 发送数据和发送应答一般是是 双方OS自动完成的通信细节OS自动解决了 tcp 发送消息的模式 ——version1 根据发送报文的顺序进行排序根据序号进行tcp的按序到达 32位的确认序号收到的序号 1 该确认序号之前的数据我已经全部收到了下次发送请从确认序号开始 既想做确认应答又想发数据这种方式叫做捎带应答既是应答又携带了数据 序号存在的意义按序到达应答和确认应答确认序号序号同时向双方发送数据的同时也同时在做应答 为什么tcp报头中要有标志位标志位存在的意义 答需要区分不同的报文请求即区分不同的报文类型 我们的server一定在通信的过程中会同时收到各种各样的报文即TCP报文是需要类型的 为什么发SYN其实只是SYN被置1了发送不同的请求只需要将不同的标记位置1即可 其中三次握手由OS自动完成 用户只用使用connect进行发起。 如何进行连接管理先描述再组织内核数据结构内存空间和时间 维护连接是有成本的时空成本 断开链接时双方各自向对方提出断开的要求然后再断开链接 close(fd) (四次挥手) 确认应答ACK机制是报证可靠性的最基础也是最重要的一种机制 4.2 超时重传机制
没有收到应答呢 需要去等等多长时间呢 约定对方没有收到报文在一个时间端内没有收到应答
数据丢包: 应答丢包:
5. TCP链接管理机制
正常的情况下TCP要经过三次握手建立连接四次挥手断开连接 像SYN、ACK这些是标记位我们发送过去的是完整的TCP报头并不是只是这些标志位 connect(fd,服务器地址端口) 发起了三次握手accept返回不参与三次握手 三次握手与四次挥手都是操作系统自己完成的 **三次握手**不是能100%建立好链接而是经历三次握手c/s都是认为连接建立好了 RSTreset重置 所谓的链接重置就是让两方重新进行三次握手 解决的问题就是连接出现异常的问题
5.1 经典面试题为什么建立连接是三次握手 为什么不进行一次或两次连接因为这样有明显漏洞客户端不用应答就可以不停的去连接这样只用一台客户端就可以对服务器工具SYN洪水而三次握手呢客户端也需要建立连接这样就不会受到单机的攻击 三次握手 理由一需要保重信道网络是健康的 三次握手CS双方都会有确定的一次收发CS确认全双工
理由二确保双方OSTCP是健康且愿意通信的建立了通信的共识。 服务端回应的时候进行捎带应答表达了服务器急切的情绪 三次握手的本质就是四次握手只不过中间两次被捎带应答了
5.2 经典面试题为什么要进行四次挥手
在思想上三次握手和四次挥手没有区别。
CLOSE_WAIT, TIME_WAIT 如果我们发现我们的服务器上有大量的close_wait状态的时候这意味着大概率我们的服务器有bug主要是没有close_fd TIME_WAIT: 等待一定的时长 为什么要等 1.保证历史的报文有足够的时间进行消散保证一来一回的时间。 2. 在我们四次挥手的过程中看起来最后一个ACK没有应答但其实这个ACK是有应答的因为它还会发送FIN如果最后一个客户端没有收到服务器不可能走到LAST_ACK,等的时候同样会响应FIN如果等待的时间内ACK没丢那么响应的这么长时间内那么就不会收到另一个FIN了TIME_WAIT保证了对方的ACK也能顺利完成还有重传的机会 时长是多长呢 等待两个MSL(maximum segment lifetime)的时间后才能回到CLOSED状态 6. 流量控制 主机A发的太快了主机B来不及接收 主机B可以向主机A通告自己的接收能力 什么叫主机B的接收能力我的接收缓冲区中剩余空间的大小 怎么通告主机B有确认应答机制在自己的ACK报文中填写自己的16位窗口大小 具体流量控制 接收端处理数据的速度是有限的. 如果发送端发的太快, 导致接收端的缓冲区被打满, 这个时候如果发送端继续发送, 就会造成丢包, 继而引起丢包重传等等一系列连锁反应. 因此 TCP 支持根据接收端的处理能力, 来决定发送端的发送速度. 这个机制就叫做流量控制(Flow Control); 接收端将自己可以接收的缓冲区大小放入 TCP 首部中的 “窗口大小” 字段, 通过 ACK 端通知发送端;窗口大小字段越大, 说明网络的吞吐量越高;接收端一旦发现自己的缓冲区快满了, 就会将窗口大小设置成一个更小的值通知给发送端;发送端接受到这个窗口之后, 就会减慢自己的发送速度;如果接收端缓冲区满了, 就会将窗口置为 0; 这时发送方不再发送数据, 但是需要定期发送一个窗口探测数据段, 使接收端把窗口大小告诉发送端. 设置PSH标志位催促B主机快点发送窗口大小 UGR紧急指针让B主机优先处理
7. 滑动窗口机制
解决主机之间发送效率低下的问题实现并行发送 滑动窗口的大小不考虑网络的情况滑动窗口大小一般是对方缓冲区中剩余空间的大小暂时 滑动窗口是发送缓冲区的一部分 报头中的窗口大小描述的是接收方的发送能力滑动窗口的大小表示的是发送方的发送能力的问题 超时重传 对发送的报文并且没有收到的应答的报文进行保存在滑动窗口中方便我们经行重传 如何理解这个滑动窗口呢 a.只能向右滑动吗 只能向右滑动 b.可以变大吗可以变小吗 可以 c.可以为0吗可以 理解它 滑动窗口的本质其实就是两个整型变量维护的一段数组空间 收到ACK报文应答报头中的窗口大小表面对方的接收能力 win 变更滑动窗口 - 确认序号的意义确认序号之前的报文全部收到了
丢包: 快重传策略必须收到3个同样的确认应答则进行重发。
最左侧丢包滑动窗口不能进行右移我们不担心最左侧报文丢失会对丢失的报文进行快重传与超时重传策略中间报文丢失右滑转换为最左侧丢包问题最右侧报文丢包右划转换为最左侧丢包问题 在滑动窗口内所有的问题全部会转换成为最左侧丢包问题
流量控制是如何做到的 滑动窗口在滑动的过程中既可以变大也可以变小也可以为0滑动窗口的大小要和对方的接收窗口吻合滑动窗口的大小暂时等于对方的接收能力。这样保证了既可以保证以最高的速率全力发送又可以防止对方的数据进行溢出多发即保证发送速率又保证接收能力。 滑动窗口是流量控制的具体实现是重传策略的具体实现。 缓冲区是一个类似于环状队列所以不用担心数据的溢出
8. 拥塞控制
虽然 TCP 有了滑动窗口这个大杀器, 能够高效可靠的发送大量的数据. 但是如果在刚开始阶段就发送大量的数据, 仍然可能引发问题.因为网络上有很多的计算机, 可能当前的网络状态就已经比较拥堵. 在不清楚当前网络状态下, 贸然发送大量的数据, 是很有可能引起雪上加霜的. TCP 引入 慢启动 机制, 先发少量的数据, 探探路, 摸清当前的网络拥堵状态, 再决定按照多大的速度传输数据;
网络出现大面积丢包说明网络拥塞了
一但发生网络拥塞识别到的网络拥塞主机全部要进行拥塞控制。 滑动窗口 min(接收方的窗口接收能力拥塞窗口) 2^n - 慢启动拥塞控制的核心算法 探测网络的健康状态
ssthresh值阈值记录上一次拥塞窗口值(32位)的一半作为下一次窗口变化的临界值指数增长变为线性增长
9. 面向字节流的特性
创建一个 TCP 的 socket, 同时在内核中创建一个 发送缓冲区 和一个 接收缓冲区; 调用 write 时, 数据会先写入发送缓冲区中;如果发送的字节数太长, 会被拆分成多个 TCP 的数据包发出;如果发送的字节数太短, 就会先在缓冲区里等待, 等到缓冲区长度差不多了, 或者其他合适的时机发送出去;接收数据的时候, 数据也是从网卡驱动程序到达内核的接收缓冲区;然后应用程序可以调用 read 从接收缓冲区拿数据;另一方面, TCP 的一个连接, 既有发送缓冲区, 也有接收缓冲区, 那么对于这一个连接, 既可以读数据, 也可以写数据. 这个概念叫做 全双工 由于缓冲区的存在, TCP 程序的读和写不需要一一匹配, 例如 写 100 个字节数据时, 可以调用一次 write 写 100 个字节, 也可以调用 100 次write, 每次写一个字节;读 100 个字节数据时, 也完全不需要考虑写的时候是怎么写的, 既可以一次read 100 个字节, 也可以一次 read 一个字节, 重复 100 次 10. 粘包问题及解决方案 先要明确, 粘包问题中的 “包” , 是指的应用层的数据包.在 TCP 的协议头中, 没有如同 UDP 一样的 “报文长度” 这样的字段, 但是有一个序号这样的字段.站在传输层的角度, TCP 是一个一个报文过来的. 按照序号排好序放在缓冲区中.站在应用层的角度, 看到的只是一串连续的字节数据.那么应用程序看到了这么一连串的字节数据, 就不知道从哪个部分开始到哪个部分, 是一个完整的应用层数据包. 那么如何避免粘包问题呢? 归根结底就是一句话, 明确两个包之间的边界. 对于定长的包, 保证每次都按固定大小读取即可; 例如上面的 Request 结构, 是固定大小的, 那么就从缓冲区从头开始按 sizeof(Request)依次读取即可;对于变长的包, 可以在包头的位置, 约定一个包总长度的字段, 从而就知道了包的结束位置;对于变长的包, 还可以在包和包之间使用明确的分隔符(应用层协议, 是程序猿自己来定的, 只要保证分隔符不和正文冲突即可); 思考: 对于 UDP 协议来说, 是否也存在 “粘包问题” 呢? 对于 UDP, 如果还没有上层交付数据, UDP 的报文长度仍然在. 同时, UDP 是一个一个把数据交付给应用层. 就有很明确的数据边界.站在应用层的站在应用层的角度, 使用 UDP 的时候, 要么收到完整的 UDP 报文, 要么不收. 不会出现半个的情况 11. TCP异常情况处理
进程终止: 进程终止会释放文件描述符, 仍然可以发送 FIN. 和正常关闭没有什么区别. 机器重启: 和进程终止的情况相同. 机器掉电/网线断开: 接收端认为连接还在, 一旦接收端有写入操作, 接收端发现连接已经不在了, 就会进行 reset. 即使没有写入操作, TCP 自己也内置了一个保活定时器, 会定期询问对方是否还在. 如果对方不在, 也会把连接释放. 另外, 应用层的某些协议, 也有一些这样的检测机制. 例如 HTTP 长连接中,
12. TCP 小结
为什么 TCP 这么复杂? 因为要保证可靠性, 同时又尽可能的提高性能 可靠性 校验和序列号(按序到达)确认应答超时重发连接管理流量控制拥塞控制 提高性能: 滑动窗口快速重传延迟应答捎带应答 其他: 定时器(超时重传定时器, 保活定时器, TIME_WAIT 定时器等 基于 TCP 应用层 HTTPHTTPSSSHTelnetFTPSMTP 当然, 也包括你自己写 TCP 程序时自定义的应用层协
13. TCP与UDP的对比
我们说了 TCP 是可靠连接, 那么是不是 TCP 一定就优于 UDP 呢? TCP 和 UDP 之间的优点和缺点, 不能简单, 绝对的进行比较 TCP 用于可靠传输的情况, 应用于文件传输, 重要状态更新等场景;UDP 用于对高速传输和实时性要求较高的通信领域, 例如, 早期的 QQ, 视频传输等. 另外 UDP 可以用于广播 归根结底, TCP 和 UDP 都是程序员的工具, 什么时机用, 具体怎么用, 还是要根据具体的需求场景去判定.
14. 用 UDP 实现可靠传输(经典面试题
参考 TCP 的可靠性机制, 在应用层实现类似的逻辑;
例如: 引入序列号, 保证数据顺序;引入确认应答, 确保对端收到了数据;引入超时重传, 如果隔一段时间没有应答, 就重发数据;… 总结
经过对TCP协议的全面分析我们可以得出以下结论 可靠性TCP通过序列号、确认应答、超时重传、连接管理、流量控制和拥塞控制等机制确保数据的可靠传输。这些机制虽然增加了协议的复杂性但也大大提高了数据传输的可靠性。 性能尽管TCP的可靠性机制带来了一定的性能开销但通过滑动窗口、快速重传、延迟应答和捎带应答等技术TCP能够在保证可靠性的同时尽可能地提高传输效率。 应用场景TCP适用于需要可靠传输的应用如文件传输、电子邮件、Web 服务等。而UDP则适用于对实时性和传输速度要求较高的应用如视频传输、在线游戏等。 与UDP的对比TCP和UDP各有优缺点选择哪种协议取决于具体的应用需求。TCP提供了更可靠的传输保障但可能会牺牲一些性能UDP则在传输速度和实时性方面表现更优但传输的可靠性较低。 实现可靠传输即使在UDP这样的不可靠协议上也可以通过应用层的逻辑实现类似TCP的可靠性机制如序列号、确认应答和超时重传等。
通过本文的学习读者应该能够更深入地理解TCP协议的工作原理掌握其关键特性并能够根据实际需求选择合适的传输层协议。希望本文能够为读者在网络编程和应用开发中提供有价值的参考。 文章转载自： http://www.morning.gzzxlp.com.gov.cn.gzzxlp.com http://www.morning.rrxmm.cn.gov.cn.rrxmm.cn http://www.morning.rpjr.cn.gov.cn.rpjr.cn http://www.morning.gjlml.cn.gov.cn.gjlml.cn http://www.morning.xbrxk.cn.gov.cn.xbrxk.cn http://www.morning.qjldz.cn.gov.cn.qjldz.cn http://www.morning.jtybl.cn.gov.cn.jtybl.cn http://www.morning.bqmdl.cn.gov.cn.bqmdl.cn http://www.morning.kgqww.cn.gov.cn.kgqww.cn http://www.morning.gcfrt.cn.gov.cn.gcfrt.cn http://www.morning.rysmn.cn.gov.cn.rysmn.cn http://www.morning.24vy.com.gov.cn.24vy.com http://www.morning.wgzgr.cn.gov.cn.wgzgr.cn http://www.morning.kyjyt.cn.gov.cn.kyjyt.cn http://www.morning.rtryr.cn.gov.cn.rtryr.cn http://www.morning.cwlxs.cn.gov.cn.cwlxs.cn http://www.morning.srwny.cn.gov.cn.srwny.cn http://www.morning.bfhfb.cn.gov.cn.bfhfb.cn http://www.morning.sknbb.cn.gov.cn.sknbb.cn http://www.morning.zdzgf.cn.gov.cn.zdzgf.cn http://www.morning.rwpjq.cn.gov.cn.rwpjq.cn http://www.morning.jydhl.cn.gov.cn.jydhl.cn http://www.morning.tpnxr.cn.gov.cn.tpnxr.cn http://www.morning.pngfx.cn.gov.cn.pngfx.cn http://www.morning.wdpbq.cn.gov.cn.wdpbq.cn http://www.morning.pgmyn.cn.gov.cn.pgmyn.cn http://www.morning.rzcfg.cn.gov.cn.rzcfg.cn http://www.morning.zdhxm.com.gov.cn.zdhxm.com http://www.morning.rcwbc.cn.gov.cn.rcwbc.cn http://www.morning.tkzrh.cn.gov.cn.tkzrh.cn http://www.morning.gyrdn.cn.gov.cn.gyrdn.cn http://www.morning.bwttp.cn.gov.cn.bwttp.cn http://www.morning.ytmx.cn.gov.cn.ytmx.cn http://www.morning.dnbhd.cn.gov.cn.dnbhd.cn http://www.morning.wkpfm.cn.gov.cn.wkpfm.cn http://www.morning.pqwhk.cn.gov.cn.pqwhk.cn http://www.morning.sjjq.cn.gov.cn.sjjq.cn http://www.morning.tqldj.cn.gov.cn.tqldj.cn http://www.morning.knsmh.cn.gov.cn.knsmh.cn http://www.morning.wfzlt.cn.gov.cn.wfzlt.cn http://www.morning.lhwlp.cn.gov.cn.lhwlp.cn http://www.morning.rrgm.cn.gov.cn.rrgm.cn http://www.morning.cltrx.cn.gov.cn.cltrx.cn http://www.morning.qhln.cn.gov.cn.qhln.cn http://www.morning.wyfpc.cn.gov.cn.wyfpc.cn http://www.morning.vvdifactory.com.gov.cn.vvdifactory.com http://www.morning.hhnhb.cn.gov.cn.hhnhb.cn http://www.morning.tkchg.cn.gov.cn.tkchg.cn http://www.morning.rnygs.cn.gov.cn.rnygs.cn http://www.morning.txtzr.cn.gov.cn.txtzr.cn http://www.morning.yxmcx.cn.gov.cn.yxmcx.cn http://www.morning.hrgxk.cn.gov.cn.hrgxk.cn http://www.morning.bwygy.cn.gov.cn.bwygy.cn http://www.morning.yqfdl.cn.gov.cn.yqfdl.cn http://www.morning.pngdc.cn.gov.cn.pngdc.cn http://www.morning.qfkxj.cn.gov.cn.qfkxj.cn http://www.morning.lftpl.cn.gov.cn.lftpl.cn http://www.morning.pnmnl.cn.gov.cn.pnmnl.cn http://www.morning.jcjgh.cn.gov.cn.jcjgh.cn http://www.morning.mqwnz.cn.gov.cn.mqwnz.cn http://www.morning.nqrlz.cn.gov.cn.nqrlz.cn http://www.morning.xltdh.cn.gov.cn.xltdh.cn http://www.morning.trtdg.cn.gov.cn.trtdg.cn http://www.morning.china-cj.com.gov.cn.china-cj.com http://www.morning.smspc.cn.gov.cn.smspc.cn http://www.morning.tdxlj.cn.gov.cn.tdxlj.cn http://www.morning.bmhc.cn.gov.cn.bmhc.cn http://www.morning.yxshp.cn.gov.cn.yxshp.cn http://www.morning.rbkgp.cn.gov.cn.rbkgp.cn http://www.morning.nxbsq.cn.gov.cn.nxbsq.cn http://www.morning.clyhq.cn.gov.cn.clyhq.cn http://www.morning.xstfp.cn.gov.cn.xstfp.cn http://www.morning.rgrz.cn.gov.cn.rgrz.cn http://www.morning.hlwzd.cn.gov.cn.hlwzd.cn http://www.morning.cnvlog.cn.gov.cn.cnvlog.cn http://www.morning.nzms.cn.gov.cn.nzms.cn http://www.morning.hhkzl.cn.gov.cn.hhkzl.cn http://www.morning.dqpnd.cn.gov.cn.dqpnd.cn http://www.morning.xxwl1.com.gov.cn.xxwl1.com http://www.morning.mdgb.cn.gov.cn.mdgb.cn
