做视频网站需要多大的带宽,深圳网址排名,网易邮箱企业邮箱怎么注册,免费的高清视频素材网站TCP协议(传输层) 文章目录 TCP协议(传输层)1. TCP报文格式2. TCP相关机制2.1 确认应答机制2.2 超时重传机制2.3 连接管理机制#xff08;重点#xff09;2.3.1 三次握手2.3.2 四次挥手 2.4 滑动窗口机制2.5 流量控制机制2.6 拥塞控制机制2.7 延迟应答机制2.8 捎带应答机制 3.…TCP协议(传输层) 文章目录 TCP协议(传输层)1. TCP报文格式2. TCP相关机制2.1 确认应答机制2.2 超时重传机制2.3 连接管理机制重点2.3.1 三次握手2.3.2 四次挥手 2.4 滑动窗口机制2.5 流量控制机制2.6 拥塞控制机制2.7 延迟应答机制2.8 捎带应答机制 3. TCP异常处理3.1 粘包问题3.2 异常中断3.2.1 进程崩溃3.2.2 主机关机3.3.3 主机掉电3.3.4 网线断开 4. TCP和UDP的对比 1. TCP报文格式 TCP即Transmission Control Protocol传输控制协议。
源/目的端口号表示数据是从哪个进程来到哪个进程去32位序号发送数据的第一个字节的序列号32位确认号期望接收的序列号4位TCP报头长度表示该TCP头部有多少个32位bit有多少个4字节所以TCP头部最大长度是15 * 4 606位标志位: URG紧急指针是否有效ACK确认号是否有效PSH提示接收端应用程序立刻从TCP缓冲区把数据读走RST对方要求重新建立连接我们把携带RST标识的称为复位报文段SYN请求建立连接我们把携带SYN标识的称为同步报文段FIN通知对方本端要关闭了我们称携带FIN标识的为结束报文段 16位窗口大小取流量控制和拥塞控制的较小值16位校验和发送端填充CRC校验。接收端校验不通过则认为数据有问题。此处的检验和不光包含TCP首部也包含TCP数据部分。16位紧急指针标识哪部分数据是紧急数据40字节头部选项包括选项列表结束、误操作、最大段长度、窗口扩展因子、时间戳
2. TCP相关机制 TCP对数据传输提供的管控机制主要体现在两个方面可靠传输和效率可靠传输是TCP 的初心。这些机制和多线程的设计原则类似保证数据传输可靠的前提下尽可能的提高传输效率。下面会介绍一些TCP协议的机制帮助你理解TCP协议传输层。
2.1 确认应答机制 确认应答机制是保证TCP可靠传输的核心机制TCP将每个字节的数据进行编号每一个ACK都带有对应的确认序列号意思是告诉发送者我已经收到了哪些数据下一次你从哪里开始发送。 确认序号就是TCP报文中的32位确认序号这个序号以可以确保应答报文和数据对应在出现“后发先至”这样的情况时程序可以按照正确的顺序组织数据。 可靠传输并不是指数据能够百分百到达对端因为现实网络环境是非常复杂的受到各种因素的综合制约。这里的可靠传输主要有两方面含义
发送发发出数据后能够知道对方是否收到数据。如果对方没有收到则可以采取“补救措施”如重传等。 如何区分一个TCP数据报是普通报文还是应答报文呢TCP报文中ACK这一位为1表示当前数据时一个应答报文此时该数据报中的32位确认序号字段就会生效反之同理。 TCP可靠传输是通过以确认应答为核心加以其他机制超时重传连接管理等共同完成的。
2.2 超时重传机制 确认应答是在应答报文一定能被收到的理想情况下但是应答报文也可能会丢包。那么为什么会产生“丢包”呢 我们发送的数据在发送途中经过路由器、交换机的转发但是交换机的处理能力是有限的如果同一时间的流量过大路由器、交换机不会积压这些数据而会之久丢弃一部分只在自己的承受范围内处理数据而被丢弃的数据也就永远的消失在了网络上了。 如果应答报文ACK丢包了那么发送方也就无法得知是否发送成功此时可靠传输也就无从谈起了。引入“超时重传”机制就可以在应答报文或者普通报文发出后一段时间内无响应后选择进行重新传输。 超时重传的丢包有数据报丢包、应答报文丢包两种情况而发送方根本无法区分这两种情况会“一视同仁”的进行重传操作。由于重传后到达对端的概率会大大增加如果重传多次还未收到对端ACK说明网络上已经出现了严重故障。TCP对重传成功到达对端这件事是抱有“悲观预测”的超时的等待时间也会逐渐变长当传输一定次数后还没有收到对端的ACK此时就会触发TCP的重置连接操作。
2.3 连接管理机制重点 我们之前说过TCP协议是有连接的这个连接的建立过程就是三次挥手打招呼断开连接就是四次挥手。 这里“挥手” handshake类似于打招呼发起连接的一方向对方发送不包含业务数据的数据报用来唤起对方的注意从而触发后续的操作。
2.3.1 三次握手 1. 客户端主动发起建立连接的请求向服务器发送一个不携带业务数据的数据报syn 同步报文段 2. 服务器接收到客户端的建立连接请求后会返回一个应答报文ack并且也会向客户端发送一个syn并且这两个报文是合并为一个报文发送的报文中SYN 和 ACK 都为1【此时服务器验证了自己的接收能力】 3. 客户端收到服务器发来的应答报文和同步报文段也会向服务器返回一个ack【客户端验证了自己的接收能力和发送能力】 4. 服务器收到客户端发来的ack连接建立完成。 TCP的初心还是可报传输如果此时网络已经存在重大故障可靠传输也就无从谈起了。
三次握手核心作用
投石问路确认当前无网络是否畅通验证发送发和接收方的收发能力让通信的双方在握手过程中针对一些重要的参数进行协商。比如报文序号等系列参数。
2.3.2 四次挥手 四次握手中的ACK和FIN一般不能合并ACK和FIN的触发时机不同ACK在内核收到数据后会立即进行响应而FIN要在应用程序中调用close()方法后才能触发。这两个操作一般是不会合并的但是在延时应答机制和捎带应答机制下也可能合并。 这里只介绍了四次挥手完成正常的连接断开不分异常断开的情况会在下文的异常处理中介绍到。 由于丢包状况的存在前三次挥手若丢包都能正确触发重传但是如果最后一次挥手丢包了而客户端又早早地进入CLOSED状态连接断开那么服务器就会等待ACK报文又因为客户端以及断开连接不会触发超时重传所以服务器永远也等待不到客户端的ACK了。 在这种情况下客户端子啊第三次挥手之后不会立即进入CLOSED状态而是进入TIME_WAIT状态等待一段时间若ACK丢了就会触发服务器的超时重传重发FIN进而客户端再次进行ACK响应。 这里的TIME_WAIT的等待时间一般会设为2*MSLMSL是网络上两个节点的最大消耗时间确保挥手留有客户端ACK到达服务器和ACK丢包服务器超时重传的时间。
2.4 滑动窗口机制 前面介绍的确认应答、超时重传、连接管理机制都是为了保证可靠传输而可靠传输必定要牺牲一定的效率而滑动窗口机制则是一种”亡羊补牢“的措施。让TCP的效率尽可能的高一点。 在原来的机制下没发送一个TCP数据报都要等待对端返回ACK后才能继续发送而滑动窗口机制则是先发送一批数据对这一批数据进行集中等待ACK收到某个ACK窗口就可以往下滑动。在不等待的情况下批量发送多少数据的上限成为”窗口大小“。 在这个过程中如果产生丢包有两种情况。 一是ACK丢了这种情况是不需要进行重传的因为ACK在滑动窗口机制下被赋予了新的含义是从xxx个字节之前的数据都收到了如果在这之前的ACK丢失并不会影响到现在的判断。 二是数据丢了数据丢失后接受方会将这个之后的数据丢弃不断向发送方索要该序号的数据等待该数据报的到来。 何时回触发TCP的滑动窗口机制呢如果收发双方传输的数据量比较小也不平频繁此时不会触发滑动窗口机制任然是按照确认应答和超时重传机制传输。但是如果收发双方传输的数据量较大比较频繁就会触发滑动窗口机制进行批量发送快速重传。
2.5 流量控制机制 通过滑动窗口机制传输数据效率得到了一定的提升但是这个窗口也不是越大越好为了控制窗口大小引入了流量控制机制和拥塞控制机制。分别从接收方的处理能力和网络路线的状况来优化窗口大小动态调整。 由于接收端处理数据的速度是有限的。如果发送端发的太快导致接收端的缓冲区被打满这个时候如果发送端继续发送就会造成丢包继而引起丢包重传等等一系列连锁反应。TCP支持根据接收端的处理能力来决定发送端的发送速度。这个机制就叫做流量控Flow Control - 生产者消费者模型。 流量控制机制是站在接收方的角度反向制约发送方的发送速度发送方的发送速度不应该超过接收方的处理能力。发送方会根据接受方缓冲区的剩余空间大小来作为衡量窗口大小的指标这就意味着
剩余空间越大消费速度越快处理能力越强窗口大小越大发送速度更快剩余空间越小消费速度越慢处理能力越弱窗口大小越小发送速度更慢 TCP报文中的16位窗口大小就是用于接收方将自己当前的缓冲区大小反馈给发送方。这个窗口大小只有16位这是否以为这最大只能是64kb呢TCP报文中的选项中有一部分叫做窗口扩展因子如果当前传输情况理想窗口是可以更大的。 在这个过程中如果接收方的接收缓冲区满了那么发送方就会停止发送等待接收方对接收缓冲区内的数据进行处理那么停止多久呢此时发送方会周期性的发送一个不携带业务数据的”窗口探测包“这个数据报知识为了得到接收方的ACK从而判断接收方的接收缓冲区的大小从而做出进一步判断。
2.6 拥塞控制机制 流量控制机制是站在接收方的数据处理能力视角上对窗口大小进行优化这里的拥塞控制则是站在网络传输路径是否畅通通信中间节点的情况对窗口大小进行优化最终的窗口大小要取两者的较小值。 由于木桶效应发送速度收到整个通信状况中的最短板决定所以这里的拥塞控制会在不大于接收方的处理能力的情况下逐渐增大 增大到某个临界点出现丢包时再将窗口大小进行调整此处也是动态变化的。 如果在刚开始阶段就发送大量的数据可能引发问题。因为网络上有很多的计算机可能当前的网络状态就已经比较拥堵。在不清楚当前网络状态下贸然发送大量的数据是很有可能引起雪上加霜的。TCP拥塞控制是一种慢启动机制先发少量的数据探探路摸清当前的网络拥堵状态再决定按照多大的速度传输数据我们先看一个经典的拥塞控制。 刚开始从一个比较小的速度开始发送指数级递增当达到某个阈值时停止指数增长改为线性增长假发增大如果出现拥塞那么直接从速度归零重新进行“慢开始”。 这种经典的拥塞控制一旦遭遇拥塞那么就会重新慢开始下降速度太快有一种开进版的拥塞控制遭遇拥塞后在原有阈值的基础上计算出新的阈值从这个新的阈值开始线性增长。
2.7 延迟应答机制 如果接收数据的主机立刻返回ACK应答这时候返回的窗口可能比较小。 在保证网络不会拥塞的情况下窗口越大网络吞吐量就越大传输效率就越高。我们的目标是在保证网络不拥塞的情况下尽量提高传输效率。 当收到发送方的数据时不必立即反馈ACK等待接收方进行数据处理让缓冲区空间剩余大小进行增长此时窗口就会尽可能的大。
2.8 捎带应答机制 捎带应答实在延时应答的基础上进一步做出的效率上的优化延时应答后将应答报文和数据报文进行合并一次性发送给发送方。减少了中间的封装和分用的开销。在这种情况下TCP断开连接的四次挥手也是可能三次挥完的。
3. TCP异常处理
3.1 粘包问题 由于TCP是面向字节流的在接收方接收到数据从缓冲区读取数据时就无法区分应用层数据报之间的边界。如果同时到来多个那么就可能出现粘包问题。 相比较之下UDP则是面向数据报的UDP的接收缓冲区中是一个个的DatagramPacket对象应用程序读取时可以明确的知道边界就不会出现粘包问题。 要解决TCP的粘包问题我们只需要明确TCP-应用层数据包间的边界。
使用分割符 如 \n这种行文本使用长度进行标识在数据包之前加上长度让应用程序明确一个包多大。 此处的应用层协议可以自定义如xml、json、protobuffer等边界明确的当然也可以自定义应用层协议。
3.2 异常中断
3.2.1 进程崩溃 进程没了异常终止了。进场的文件描述符表也就释放了。相当于调用socket.close()此时就会触发FIN,对方收到之后会返回FIN和ACK,这边再进行ack (正常的四次挥手断开连接的流程tcp的连接可以独立于进程存在。(进程没了tcp连接还在
3.2.2 主机关机 在进行关机操作时会先触发强制关闭进程相当于进程崩溃。此时就会触发FIN对方收到就就会返回 ACK和FIN但不仅仅是进程结束了操作系统也关闭了。
如果操作系统关闭之前对端返回的ACK和FIN到了此时系统还是可以返回ACK进行正常的四次挥手正常断开连接。如果操作系统关闭之前对端返回的ACK和FIN还未到ACK和FIN迟到后操作系统已经关机无法对ACK和FIN进行回应站在发送方的角度以为是丢包了然后进行重传多次重传后都没有响应也就放弃连接了。
3.3.3 主机掉电 主机掉电是一瞬间的事情对端是来不及反应的。
接收方掉电发送方就会一直等待ACK然后触发超时重传进一步触发TCP的连接重置发出复位报文段如果复位报文段发出后没有得到响应连接也就会断开发送方掉电此时接收方是无法区分是发送方没有进行数据发送还是挂了TCP中提供了”心跳包“机制接收方会周期性的给发送方发送一个心跳包不携带业务数据期待得到对端的应答如果没有得到应答在重复多次后连接也会断开。
3.3.4 网线断开 假设A给B发送数据一旦网线断开A就会触发超时重传 重置连接 断开连接。B就会 触发心跳包 对端未响应 断开连接【TCP的心跳包周期较长】
4. TCP和UDP的对比 TCP 的优势在于可靠传输TCP可以适用于绝大部分场景。 UDP的优势在于效率跟高适用于对”可靠性不敏感效率敏感“的场景同一个机房内部的数据传输就会优先考虑UDP因为同一个机房内丢包的概率不大希望数据能够更快的传输。在需要广播的场景下UDP也有得天独厚的优势UDP天然支持广播所谓广播就是将数据发给当前局域网的所有设备。 如果本篇文章对你有帮助请点赞、评论、转发你的支持是我创作的动力。
