域名访问过程会不会影响网站访问,中国建筑工程门户商城,ssh小型购物网站开发,wordpress英文美食主题#x1f4a1;TCP的可靠不在于它是否可以把数据100%传输过去#xff0c;而是 1.发送方发去数据后#xff0c;可以知道接收方是否收到数据#xff1b;2.如果接收方没收到#xff0c;可以有补救手段#xff1b; 图1.TCP组成图 TCP的可靠性是付出代价的#xff0c;即传输效率… TCP的可靠不在于它是否可以把数据100%传输过去而是 1.发送方发去数据后可以知道接收方是否收到数据2.如果接收方没收到可以有补救手段 图1.TCP组成图 TCP的可靠性是付出代价的即传输效率和复杂程度 。 1.确认应答 发送方把数据发给接收方接收方收到数据需要给发送方返回一个应答报文确认序列号ackownledge,ack)发送方收到应答报文说明数据发送成功。 发送方连续发多条数据的情况这种情况会存在后发先至的情况。所以引入序列化此处TCP需要完成 1.确保发出去的数据与应答报文可以对号 2.确保在出现后发先至情况下可以按正确顺序解答 *序号按照字节编号初始序号一般不从1开始。通过使用序列号Sequence NumberSEQ和确认序列号ACKTCP协议可以实现可靠的数据传输。序列号用于标识和排序报文段而确认序列号用于确认已经接收到的报文段。 图2.确认应答ack图 eg当第一个数据报中有1000个字节的载荷数据其中第一个字节的序号是1就在TCP报头序号中写1即载荷数据中只记录这次传输的载荷数据的第一个字节的序号此时ack写入1001并返回。此时发送方就知道刚才发送的1~1000到了。——可靠传输确认应答就起到最核心作用 在图一中标志位ack为1表示它是应答报文此时数据报中的确认序号字段就能生效。 2.超时重传 ¹引入 上述确认应答是理想的状态网络传输中可能会出现丢包或者网络延迟TCP的超时重传可以保证可靠数据传输。当数据段丢失时发送方通过超时重传机制能够及时重新发送数据确保接收方最终能够正确接收到数据。 为啥会出现丢包呢 网络拥塞数据流量超过网络链路的容量过多的数据包同时竞争有限的带宽资源导致一些数据包无法及时传输或被丢弃。缓冲区溢出当接收方的缓冲区已满无法及时处理接收到的数据包时会导致数据包被丢弃。 了解 Linux中超时以500ms为一个单位进行控制每次判定超时重发的时间都是500ms的整数倍。重发一次还无应答就会以2*500在进行重传。仍得不到应答就等待4*500ms...... 指数递增。累计到一定程度TCP会认为网络对端主机有异常强制关闭连接。 ²丢包类型 在第一点确认应答情况下可能会出现两种类型的丢包 1.传输的数据丢了 2.返回的ack丢了 这两种情况发送方是无法区分的所以引入定时器。只不过这个定时器等待的时间会动态变化。如果时间等待的足够长那就会触发TCP的重置连接操作。 ³过程 当发送方向接收方发送数据时会启动一个定时器等待接收方对已发送数据的确认。如果在设定的超时时间内没有收到确认发送方会认为数据丢失并进行超时重传。 具体的超时重传过程如下 1. 发送方发送数据段并启动定时器发送方将数据段发送给接收方同时启动一个定时器等待确认。2. 接收方收到数据段并发送确认接收方收到数据段后会发送一个确认ACK给发送方确认接收到了数据段。3. 发送方收到确认发送方收到接收方的确认后停止定时器并继续发送下一个数据段如果有。4. 定时器超时如果在设定的超时时间内发送方没有收到接收方的确认发送方认为数据丢失gaolian发送方重新发送未收到确认的数据段并重新启动定时器等待新的确认。 ⁴注意 TCP的超时重传机制可能会导致网络的拥塞因为它会在丢包的情况下进行重传增加了网络的负载。因此TCP采用了一系列的拥塞控制算法来避免过多的重传造成网络拥塞。 如果因为超时重传其实上接收方接收到两个数据inputStream.read读取到两个一样的数据那❌会有严重的后果。eg:我去付款结果因为重传导致扣我两份的钱 TCP的解决办法是接收缓冲区保存当前收到的数据以及序号如果已经存在于接收缓冲区接收方会进行去重。而且TCP还会进行重新排序确保程序发送的顺序和应用程序读取的顺序一致。 太厉害了TCP设计人考虑好全面 3.连接管理 是对TCP可靠性的补充。TCP的连接管理包括三次握手和四次挥手用于建立和关闭连接。建立连接是客户端发起断开连接是客户端和服务器都可以主动发起。 三次握手Three-Way Handshake 第一次握手SYN客户端发送一个带有SYN标志的TCP报文段给服务器端请求建立连接。此时客户端进入SYN_SENT状态。syn同步数据段特殊的TCP数据包没有载荷的不携带业务数据业务数据就是应用层数据包当TCP组成中的六位标志位的syn为1表示它为同步报文段第二次握手SYNACK服务器端收到客户端的SYN报文段后发送一个带有SYN和ACK标志的TCP报文段作为响应确认客户端请求并提出自己请求建立连接。此时服务器端进入SYN_RECEIVED状态。都是内核触发的同一时机可以合并。第三次握手ACK客户端收到服务器端的SYNACK报文段后向服务器端发送一个带有ACK标志的TCP报文段确认连接建立。此时客户端和服务器端都进入已建立连接的ESTABLISHED状态。listen状态服务其创建好socket等待客户端连接established建立连接完成 三次握手 1.确定网络通信路径畅通 2.确定接收方和发送方的发送能力接受能力正常 3.双方对重要信息进行协商比如序号确认号窗口大小 协商的数据也避免了前朝的剑斩本朝的官 syn确认了对方身份ack保证了序列化 四次挥手Four-Way Handshake 第一次挥手FIN当客户端想要关闭连接时内核发送一个带有FIN标志的TCP报文段给服务器端表示不再发送数据。此时客户端进入FIN_WAIT_1状态。哪方主动断开哪方timewait,timewait存在的意义就是避免最后一个ack丢失如果没有timewait状态导致客户端直接closed服务器发起两次 fin,甚至更多就永远收不到ack了。so是为了处理重传的FIN这边返回ack,fin才有意义。等待时间2msl第二次挥手ACK服务器端收到客户端的FIN报文段后发送一个带有ACK标志的TCP报文段作为确认。此时服务器端进入CLOSE_WAIT状态而客户端进入FIN_WAIT_2状态。第三次挥手FIN当服务器端也准备关闭连接时应用程序发送一个带有FIN标志的TCP报文段给客户端server在socket对象调用close方法发起fin/进程结束表示不再发送数据。此时服务器端进入LAST_ACK状态。两次触发fin时机不同。具体相差时机看代码。如果close没写或者没执行到第二个fin有可能发不出去。如果正常四次挥手那就正常断开连接否则异常流程断开连接。第四次挥手ACK客户端收到服务器端的FIN报文段后发送一个带有ACK标志的TCP报文段作为确认。此时客户端进入TIME_WAIT状态服务器端收到确认后进入CLOSED状态。 通过三次握手客户端和服务器端建立起可靠的连接。而通过四次挥手双方完成数据传输后优雅地关闭连接。这样可 以确保数据的可靠性和完整性并释放连接使用的资源。 但是tcp的延时应答可以延时ack的时间ack和fin就可能可以合并。 4.滑动窗口效率 为了尽可能提高TCP传输的效率, 引入了滑动窗口机制。TCP滑动窗口TCP sliding window是用于流量控制和拥塞控制的一种机制。它表示发送方在不等待确认的情况下可以发送的数据量。在一定范围内窗口越大传输效率越高。如果通信双方传输数据量大比较频繁就会用到滑动窗口——快速重传。 滑动窗口是通过TCP协议中的窗口字段来实现的。这个窗口字段指示了发送方当前可用的缓冲区大小也就是可以发送的数据量。接收方通过发送确认报文来告知发送方它当前所能接收的数据量即接窗口大小。 滑动窗口本质是降低了确认应答机制中等待ACK的时间..集体的措施就是:批量发送,批量接受 把多份等待时间合并成一份(不等待的批量发送数据,使用一份的等待时间来等待一组数据的多个ACK),把能不用等待就能直接发送的数据的最大的量,称为滑动窗口的大小 滑动窗口的机制使得发送方和接收方能够根据网络状况进行动态调整以实现流量控制和拥塞控制。通过合理设置窗口大小可以避免发送方发送过多的数据导致接收方无法及时处理同时也可以防止网络拥塞的发生。 操作系统内核为了维护这个滑动窗口需要开辟 发送缓冲区 来记录当前还有哪些数据没有应答,只有确认应答过的数据才能从缓冲区删掉。 丢包 1.ACK丢失 ACK丢失后,不需要做任何的处理,在之前讲给数据编序号时,序号的定义就是,表示从序号往前所有的数据都确认到达了.也就是当收到2001这个ACK时,代表是1~2000就都传输成功了,2001这个ACK涵盖了上一个1001的ACK的信息 2.数据 5.流量控制 流量控制是一种干预发送窗口大小的机制滑动窗口越大,传输效率越高,但是窗口也不能无限大发送方的传输速率不能超过接收方的接受能力。否则可能出现接收方丢包还得重传影响到TCP核心目的可靠。窗口太大,完全不等待ACK,可靠性失去保障一直重传会影响效率。 nnh 流量控制就是根据接收方的处理能力协调发送方的发送速率 如何告诉发送方窗口大小呢? 当A给B发送一个数据后,将B的处理能力看作一个水池,B会计算剩余空间,将这个值通过ACK返回给发送方,A就根据这个值来确定发送速率,也就是窗口的大小 16位窗口字段就是存放了窗口 大小信息(报文是ACK的时候,这个字段才有效),16位是否意味着窗口最大是64kb呢?其实不是这样,TCP为了扩大窗口,在选项部分引入了窗口扩展因子.如果窗口大小是64,扩展因子为2.那么642256kb. 滑动窗口大小是不固定的随着传输过程动态调整。 当窗口大小为0,就要停止发送,等待过程中,会给接收方定期发送窗口探测报文*(不携带任何业务数据)为了触发ack查询窗口大小。 TCP中有应用程序和系统内核。当数据到达接收方的系统内核中tcp socket内部对象带有接收缓冲区A——》B的数据会先到达b的接收缓冲区b的应用程序会调用read方法把数据从接收缓冲区读取出来进一步处理一旦被read就可以从接收缓冲区中删除了。 就像生产者消费者模型。 生产者a,消费者b交易场所b的接受缓冲区消费能力就是b的处理能力具体去取决于b的应用程序的代码接收方缓冲区的剩余空间越大处理能力就越强。 6.拥塞控制 滑动窗口大小MIN(流量控制和拥塞控制)。 流量控制考虑接收方的能力拥塞控制考虑传输过程中中间节点的处理能力。 网络上有大量的计算机,也传输着大量的数据,网络状态被来就很拥堵,不清楚网络的状态情况下发送大量的数据,就会引起严重后果只要有一个节点达到处理能力的上限就会影响到可靠传输。 TCP引入 慢启动 机制先发少量的数据摸清当前的网络拥堵状态再决定按照多大的速度传输数据。敌进我退敌退我进发送方不断调整窗口大小进行试验。 慢启动只是初始比较慢,增长速度非常快 拥塞的窗口窗口大小传播速度传播伦次当前TCP第一次发送数据。指数增长-线性增长传输速度也越来越快then丢包网络拥塞一旦出现丢包就把窗口缩小重新进行前面的慢启动-指数-线性并且根据当前丢包的窗口大小重新指定线性增长阈值。少量丢包触发超时重传大量的丢包触发拥塞控制。 拥塞控制就是TCP尽可能将数据尽可能快的传给接收方但避免速度太快造成网络拥塞造成丢包的折中方案。 7.延时应答 延时应答也是提升效率的机制。——增大窗口大小 在流量控制那块就是根据缓冲区剩余空间大小来决定发送速度即窗口大小如果接收数据的主机立刻返回ACK应答这时候返回的窗口可能比较小.如果收到数据之后,不是立即返回ACK,而是等待接收方消耗一些数据,剩余空间就更大了返回的窗口就更大了。 sum延时返回ack给接收方更多时间来读取缓冲区数据。缓冲区剩余空间越大即窗口越大网络吞吐量就越大传输效率就越高。 但是延时应答也有限制 数量限制每隔N个包就应答一次(一般取2) 时间限制超过最大延迟时间就应答一次(一般200ms) 8.捎带应答 用于在发送数据包时同时携带其它的信息。通常情况下数据包中会包含应答ACKAcknowledgement信息来确认之前已经接收到的数据包。而捎带应答则是利用这个ACK信息的空余空间来携带其它信息。如三次挥手中第二次就携带了acksyn(同步报文段)在一些高延迟、高丢包的网络环境中捎带应答可能会导致额外的问题如增加网络拥塞和降低网络吞吐量等。 9.面向字节流 在TCP连接中数据被看作是一个连续的字节流而不是被分割成独立的消息或数据包。 而UDP的接收缓冲区是一个接一个的数据报这样应用程序读取时就知道那里到哪里是一个完整的数据。TCP面向字节流的特性意味着数据在发送端被分割成小的数据段并在接收端重新组装。TCP协议负责将数据流切分为适合网络传输的数据段并确保这些数据段按序到达接收端并进行正确的重组。 如果有多个应用层数据包同时被传输过去就会出现粘包问题。接收缓冲区中的数据就以字节形式仅仅连接在一起接收方的应用程序读取数据时就可以一次读1个2个......N个但是最终的目标是读取到完整的应用层数据包问题接收方的应用程序并不知道从哪到哪是一个完整的应用层数据包。 核心思路定义好应用层协议明确应用层数据包之间的边界。 1.引入分隔符2.引入长度在应用层协议的格式中常见的json,xml,protobuffer都明确了边界。 TCP粘包问题主要有两种情况 粘包多个数据包被接收方一次性接收到形成了一个粘包。这种情况下接收方需要额外的处理来正确地拆分和解析每个数据包。拆包一个数据包被拆分成多个片段发送接收方需要根据片段的顺序和边界重新组装数据包。 造成TCP粘包问题的原因主要有以下几点 发送端连续发送如果发送端连续发送多个数据包而接收端没有及时读取这些数据包就会被接收端一次性接收到形成粘包。缓冲区大小限制TCP接收端的缓冲区大小有限当接收端缓冲区无法容纳整个数据包时数据包会被拆分成多个片段进行传输从而产生拆包问题。延迟确认机制TCP的延迟确认机制可能会导致多个数据包被一起确认从而产生粘包。 为了解决TCP粘包问题可以采用以下方法 显式消息边界在传输的数据中加入消息边界标识如特殊字符或长度字段以便接收方可以准确地切分每个数据包。消息长度字段在发送数据时将数据长度作为一个固定长度的字段添加到数据包中以便接收方可以根据长度字段来正确解析每个数据包。使用定长数据包将发送的数据固定为固定长度的数据包无论实际数据长度如何都填充到固定长度这样接收方可以按照固定长度来解析每个数据包。清空缓冲区接收端可以及时读取和处理数据尽快清空接收缓冲区减少粘包和拆包的可能性。 10.TCP异常情况 传输过程中出现了不可抗力导致TCP异常 进程终止:进程终止会释放文件描述符相当于调用socket.close()触发FIN,进行四次挥手。和正常关闭没有什么区别。TCP的连接管理独立于进程而存在 机器重启/关机:触发强制终止进程和进程终止的情况相同 机器掉电/断网: 来不及杀进程来不及发送fin。接收端认为连接还在一旦接收端有写入操作接收端发现连接已经不在了就会 进行reset(重置)。即使没有写入操作TCP自己也内置了一个保活定时器(心跳包)会定期询问对方是否还在。如果对方不在也会把连接释放。 A-B: A超时重传——连接重置——单方面断开 B心跳包——对方无响应——单方面释放连接 TCPUDP 连接性 TCP是面向连接的协议通过三次握手建立连接确保通信双方能够可靠地传输数据并进行连接的关闭。UDP是无连接的协议不需要事先建立连接直接将数据包发送给目标地址。每个数据包都是独立的没有顺序要求。 可靠性 TCP提供可靠的数据传输通过序列号、确认应答、超时重传等机制来确保数据的可靠性。如果数据包丢失或损坏TCP会自动进行重传。UDP不提供可靠性保证数据包一旦发送出去就无法得知是否到达目标。它适用于对实时性要求较高的应用如音频和视频流。 传输效率 TCP通过流量控制、拥塞控制等机制来提供高效的传输服务。它可以自动调整发送速率和窗口大小以适应网络的变化。UDP没有流量控制和拥塞控制机制发送端会尽可能快地将数据发送出去适用于对实时性要求较高、容忍丢包的应用。 数据大小限制 TCP将应用层数据按照最大传输单元MTU进行分段可以传输任意大小的数据。TCP会确保数据的完整性和有序交付。UDP每个数据包有固定的大小限制最大长度为64KB。如果应用层数据超过了这个限制需要进行分片和重组。 应用场景 TCP适用于对数据可靠性和顺序性要求较高的应用如网页浏览、文件传输、电子邮件等。UDP适用于对实时性要求较高、如音频和视频流、在线游戏局域网内部的主机之间的通信等。它在传输速度和实时性方面更加高效。
