TCP协议解析
主要特点:面向连接、面向字节流、全双工通信、通信可靠。优缺点:应用场景:要求通信数据可靠时,即 数据要准确无误地传递给对方。如:传输文件:HTTP、HTTPS、FTP等协议;传输邮件:POP、SMTP等协议ps:首部的前 20 个字节固定,后面有 4n 字节根据需要增加。故 TCP首部最小长度 = 20字节(最大60个字节)。TCP报头中的源端口号和目的端口号同IP数据报中的源IP与目的IP唯一确定一条TCP连接。重要字段:客户端与服务器来回共发送三个TCP报文段来建立运输连接,三个TCP报文段分别为:(1)客户端A向服务器B发送的TCP请求报段“SYN=1,seq=x”;(2)服务器B向客户端A发送的TCP确认报文段“SYN=1,ACK=1,seq=y,ack=x+1”;(3)客户端A向服务器B发送的TCP确认报文段“ACK=1,seq=x+1,ack=y+1”。ps:在建立TCP连接之前,客户端和服务器都处于关闭状态(CLOSED),直到客户端主动打开连接,服务器才被动打开连接(处于监听状态 = LISTEN),等待客户端的请求。TCP 协议是一个面向连接的、安全可靠的传输层协议,三次握手的机制是为了保证能建立一个安全可靠的连接。通过上述三次握手,双方确认自己与对方的发送与接收是正常的,就建立起一条TCP连接,即可传送应用层数据。ps:因 TCP提供的是全双工通信,故通信双方的应用进程在任何时候都能发送数据;三次握手期间,任何1次未收到对面的回复,则都会重发。为什么两次握手不行呢?结论:防止服务器接收了早已经失效的连接请求报文,服务器同意连接,从而一直等待客户端请求,最终导致形成死锁、浪费资源。ps:SYN洪泛攻击:(具体见下文)为什么不需要四次握手呢?SYN 同步序列编号(Synchronize Sequence Numbers) 是 TCP/IP 建立连接时使用的握手信号。在客户机和服务器之间建立正常的 TCP 网络连接时,客户机首先发出一个 SYN 消息,服务器使用 SYN-ACK 应答表示接收到了这个消息,最后客户机再以 ACK确认序号标志消息响应。这样在客户机和服务器之间才能建立起可靠的 TCP 连接,数据才可以在客户机和服务器之间传递。如何来解决半连接攻击?如何来解决全连接攻击?请注意,现在 TCP 连接还没有释放掉。必须经过时间等待计时器设置的时间 2MSL(MSL:最长报文段寿命)后,客户端才能进入到 CLOSED 状态,然后撤销传输控制块,结束这次 TCP 连接。当然如果服务器一收到 客户端的确认就进入 CLOSED 状态,然后撤销传输控制块。所以在释放连接时,服务器结束 TCP 连接的时间要早于客户端。TCP是全双工的连接,必须两端同时关闭连接,连接才算真正关闭。简言之,客户端发送了 FIN 连接释放报文之后,服务器收到了这个报文,就进入了 CLOSE-WAIT 状态。这个状态是为了让服务器端发送还未传送完毕的数据,传送完毕之后,服务器才会发送 FIN 连接释放报文,对方确认后就完全关闭了TCP连接。举个例子:A 和 B 打电话,通话即将结束后,A 说“我没啥要说的了”,B回答“我知道了”,但是 B 可能还会有要说的话,A 不能要求 B 跟着自己的节奏结束通话,于是 B 可能又巴拉巴拉说了一通,最后 B 说“我说完了”,A 回答“知道了”,这样通话才算结束。ps:设想这样一个情景:客户端已主动与服务器建立了 TCP 连接。但后来客户端的主机突然发生故障。显然,服务器以后就不能再收到客户端发来的数据。因此,应当有措施使服务器不要再白白等待下去。这就需要使用TCP的保活计时器。基本原理:tcp11种状态及变迁其实基本包含在正常的三次握手和四次挥手中,除开CLOSING。正常的三次握手包括4中状态变迁:服务器打开监听(LISTEN)->客户端先发起SYN主动连接标识->服务器回复SYN及ACK确认->客户端再确认即三次握手TCP连接成功。这里边涉及四种状态及变迁:正常的四次握手包含6种tcp状态变迁,如主动发起关闭方为客户端:客户端发送FIN进入FIN_WAIT1 -> 服务器发送ACK确认并进入CLOSE_WAIT(被动关闭)状态->客户端收到ACK确认后进入FIN_WAIT2状态 -> 服务器再发送FIN进入LAST_ACK状态 -> 客户端收到服务器的FIN后发送ACK确认进入TIME_WAIT状态 -> 服务器收到ACK确认后进入CLOSED状态断开连接 -> 客户端在等待2MSL的时间如果期间没有收到服务器的相关包,则进入CLOSED状态断开连接。CLOSING状态:连接断开期间,一般是客户端发送一个FIN,然后服务器回复一个ACK,然后服务器发送完数据后再回复一个FIN,当客户端和服务器同时接受到FIN时,客户端和服务器处于CLOSING状态,也就是此时双方都正在关闭同一个连接。在进入CLOSING状态后,只要收到了对方对自己发送的FIN的ACK,收到FIN的ACK确认就进入TIME_WAIT状态,因此,如果RTT(Round Trip Time TCP包的往返延时)处在一个可接受的范围内,发出的FIN会很快被ACK从而进入到TIME_WAIT状态,CLOSING状态持续的时间就特别短,因此很难看到这种状态。我们知道网络层,可以实现两个主机之间的通信。但是这并不具体,因为,真正进行通信的实体是在主机中的进程,是一个主机中的一个进程与另外一个主机中的一个进程在交换数据。IP协议虽然能把数据报文送到目的主机,但是并没有交付给主机的具体应用进程。而端到端的通信才应该是应用进程之间的通信。应用场景:UDP协议比TCP协议的效率更高,TCP协议比UDP协议更加安全可靠。下面主要对数据传输出现错误/无应答/堵塞/超时/重复等问题。注意:TCP丢包:TCP是基于不可靠的网路实现可靠传输,肯定会存在丢包问题。如果在通信过程中,发现缺少数据或者丢包,那边么最大的可能性是程序发送过程或者接受过程中出现问题。总结:为了满足TCP协议不丢包,即保证可靠传输,规定如下:注意:TCP丢包有三方面的原因,一是网络的传输质量不好,二是安全策略,三是服务器性能瓶颈先理解2个基础概念:发送窗口、接收窗口工作原理:注意点:关于滑动窗口的知识点:滑动窗口中的数据类型:ARQ解决的问题:出现差错时,让发送方重传差错数据:即 出错重传类型:流量控制和拥塞控制解决的问题:当接收方来不及接收收到的数据时,可通知发送方降低发送数据的效率:即 速度匹配流量控制:注意:拥塞控制:慢开始与拥塞避免:快重传和快恢复:补充:流量控制和拥塞控制的区别什么情况造成TCP粘包和拆包?解决TCP粘包和拆包的方法:传输层无法保证数据的可靠传输,只能通过应用层来实现了。实现的方式可以参照tcp可靠性传输的方式,只是实现不在传输层,实现转移到了应用层。最简单的方式是在应用层模仿传输层TCP的可靠性传输。下面不考虑拥塞处理,可靠UDP的简单设计。https://www.jianshu.com/p/65605622234bhttp://www.open-open.com/lib/view/open1517213611158.htmlhttps://blog.csdn.net/dangzhangjing97/article/details/81008836https://blog.csdn.net/qq_30108237/article/details/107057946https://www.jianshu.com/p/6c73a4585eba

tcp段中源端口字段的作用
tcp段中源端口字段的作用是区分服务类别和在同一时间进行多个会话。tcp是一种面向连接的、可靠的、基于字节流的传输层通信协议,由IETF的RFC 793定义。TCP旨在适应支持多网络应用的分层协议层次结构。 连接到不同但互连的计算机通信网络的主计算机中的成对进程之间依靠TCP提供可靠的通信服务。TCP假设它可以从较低级别的协议获得简单的,可能不可靠的数据报服务。 原则上,TCP应该能够在从硬线连接到分组交换或电路交换网络的各种通信系统之上操作。互联网络与单个网络有很大的不同,因为互联网络的不同部分可能有截然不同的拓扑结构、带宽、延迟、数据包大小和其他参数。TCP的设计目标是能够动态地适应互联网络的这些特性,而且具备面对各种故障时的健壮性。

分析tcp协议原理
原理四个主要方面:一、tcp协议之连接建立、断开二、tcp协议之超时重传三、tcp协议之窗口管理四、tcp协议之拥塞控制TCP是一种面向有连接的协议,也就是说必须确认对方存在时才能发送数据而TCP通过检验和、序列号、确认应答、重发控制、连接管理、窗口控制等机制来实现可靠传输。1. 目的:TCP三次握手是客户端和服务器总共发三个数据包,通过三个数据包来确认主动发送能力和被动接收能力是否正常。2. 实质:通过指定的四元组(源地址、源端口、目标地址、目标端口)来建立TCP连接,同步双方各自发送序列号seq和确认号ACK,同时也会交换窗口大小信息三次握手过程的实现方式就是交换序列号seq。随便在网上找个地址,如果通过域名想看ip地址,可以ping下看连接。① 192.168.3.7发送[SYN]报文段至222.169.228.146,告知序列号x为0。② 222.169.228.146发送[SYN,ACK]报文段至192.168.3.7,告知序列号y为0,确认号ACK为x+1=1。③192.168.3.7发送[ACK]报文段至222.169.228.146,告知确认号ACK为y+1=1。报文段中的其他参数:MSS=1460:允许从对方接收到的最大报文段,图中为1460字节(指承载的数据,不包含报文段的头部)。win=8192:滑动窗口的大小为8192字节。SACK_PERM=1:开启选择确认。为什么会使用SACK:tcp确认方式不是一段报文段一确认,而是采用累积确认方式。服务器接收到的报文段无序所以序列号也是不连续,服务器的接收队列会出现空洞情况。为了解决空洞,提前了解当前空洞,应对丢失遗漏,采取重传。提前了解方式就是通过SACK选项信息,SACK信息包含接收方已经成功接收的数据块的序列号范围。而SACK_PERM字段为1表明,选择开启了SACK功能。网络层可能会出现丢失、重复、乱序的问题,tcp是提供可靠的数据传输服务的,为了保证数据的正确性,tcp协议会重传它认为的已经丢失的包。重传两种机制:一种基于时间重传,一种基于确认报文段提供的信息重传。RTT:数据完全发送完(完成最后一个比特推送到数据链路上)到收到确认信号的时间(往返时间)。RTO:重传超时时间(tcp发送数据时设置一个计时器,当计时器超时没有收到数据确认信息,引发超时而重传,判断的标准就是RTO)。思考:发送序列号为1、2、3、4这4个报文段,但是出现了序列号2报文段丢失,怎么办?发送端接收到seq1的确认报文(ACK=2)后,等待seq=2的确认报文。接收端当收到序列号为3的报文(2已丢失),发送ack为4的确认报文,发送端正等待ack为2的确认报文,面对跳跃的报文,那么发送端会一直等待,直到超出指定时间,重传报文2。为什么不跳跃确认呢?tcp是累积确认方式,如果确认报文3,那么意味着报文1和报文2都已经成功接收。超时处理方式:思考:上面计时器是以时间为标准重传,那么可以通过确认报文的次数来决定重传。发送端接收到seq1的确认报文(ACK=2)后,等待seq=2的确认报文。接收端收到报文3、4、5,但是没收到报文2,那么接收端发送三个ACK为2的确认报文,发送端收到这个三个确认报文,重传报文2。思考:如果快速重传中丢失包的地方很多(报文2,报文,7,报文9,报文30,报文300....),那么需要从头到尾都重传,这很蛋疼?思考:SACK重传对于接收到重复数据段怎样运作没有明确规定,通过DSACK重传可以让发送方知道哪些数据被重复接收了,而且明确是什么原因造成的。发送端没有收到100-199的ACK包,超过指定时间,重传报文。接收端都已经收到200-299的发送报文了,又来100-199是重复报文。再向发送端发送一个ACK报文,设置SACK 100-199,告知发送端,已经收到了100-199包,只是回应ACK包丢失。发送端发送包100-199,由于网络延迟,一直没有达到接收端。接收端连续发送三个ACK 200确认报文,触发快速重传,发送端收到了ACK 500的确认报文,表明之前的报文都已经交付成功。接收端又收到了延迟的报文100-199,再次向发送端发送一个SACK 100-199的ACK 500报文。发送端发现这是重复报文,判断为网络延迟造成的。计时器重传:根据超时,重传。快速重传:根据接收三次相同ACK报文,重传。选择确认重传:根据接收端提供的SACK信息,重传。DSACK重传:根据重复报文,明确丢失ACK报文还是网络延迟。Category1:已发送且已确认(已经收到ACK报文的数据)。Category2:已发送但未收到确认。Category3:即将发送。Category4:窗口移动前都不能发送。可用窗口:46-51字节。发送窗口:32-51字节。RCV.NXT:左边界RCV.WND:接收窗口RCV.NXT+RCV.WND:右边界接收端接收到序列号小于左边界,那么被认为重复数据而被丢弃。接收端接收到序列号大于右边界,那么被认为超出处理范围,丢弃。注意:tcp协议为累积ACK结构,只有当达到数据序列号等于左边界时,数据才不会被丢弃。如果窗口更新ACK丢失,对于发送端,窗口左边界右移,已发送数据得到ACK确认之后,左右边界距离减小,发送端窗口会减小,当左右边界相等时,称为零窗口。零窗口之后:接收端发送窗口更新能会发生窗口更新ACK丢失。<>解释:TCP是通过接收端的通告窗口来实现流量控制的,通告窗口指示了接收端可接收的数据量。当窗口值变为0时,可以有效阻止发送端继续发送,直到窗口大小恢复为非零值。当接收端重新获得可用空间时,会给发送端传输一个窗口更新告知其可继续发送数据。这样的窗口更新通常都不包含数据(纯ACK),接收端向发送端发送的窗口更新ACK可能丢失。结果双方处于等待状态,发生死锁。解决方案:发送端会采用一个持续计时器间歇性地查询接收端,看其窗口是否已增长。触发窗口探测,强制要求接收端返回ACK。发送几次探测,窗口大小还是0,那么断开连接。出现SWS的情况:① 接收端通告窗口太小。② 发送端发送的数据太小。解决方案:① 针对接收端:不应通告小窗口值[RFC1122]描述:在窗口可增至一个全长的报文段(接收端MSS)或者接收端缓存空间的一半(取两者中较小值)之前,不能通告比当前窗口更大的窗口值。标准:min(MSS , 缓存空间/2)。② 针对发送端:不应发送小的报文至少满足以下其一:(1)可以发送MSS字节的报文。window size >= MSS或者 数据大小>=MSS(2)数据段长度>=接收端通告过的最大窗口值的一半,才可以发送。收到之前发送的数据的ack回包,再发送数据,否则一直攒数据。(3) -1 没有未经确认的在传数据或者-2 连接禁用Nagle算法。tcp基于ACK数据包中的通告窗口大小字段实现了流量控制。当网络大规模通信负载而瘫痪,默认网络进入拥塞状态,减缓tcp的传输。发送方和接收方被要求承担超负荷的通信任务时,采取降低发送速率或者最终丢弃部分数据的方法。反映网络传输能力的变量称为拥塞窗口(cwnd)。通告窗口(awnd)。发送窗口swnd=min(cwnd,awnd)目的:tcp在用拥塞避免算法探寻更多可用带宽之前得到cwnd值,帮助tcp建立ACK时钟。[RFC5681] :在传输初始阶段,由于未知网络传输能力,需要缓慢探测可用传输资源,防止短时间内大量数据注入导致拥塞。慢启动算法针对这一问题而设计。在数据传输之初或者重传计时器检测到丢包后,需要执行慢启动。拥塞窗口值:每收到一个ACK值,cwnd扩充一倍。所以假设没有丢包且每个数据包都有相应ACK值,在k轮后swnd=,成指数增长。SMSS是发送方的最大段大小。慢启动阶段,cwnd会指数增长,很快,帮助确立一个慢启动阙值(ssthresh)。有了阙值,tcp会进入拥塞避免阶段,cwnd每次增长值近似于成功传输的数据段大小,成线性增长。实现公式:cwnd+=SMSS*SMSS/cwnd刚建立连接使用慢启动算法,初始窗口为4,收到一次ACK后,cwnd变为8,再收到一次ACK后,cwnd变为16,依次继续,32、64,达到阙值ssthresh为64。开始使用拥塞避免算法,设置ssthresh为ssthresh/2,值为32。重新从初始窗口4,线性递增到ssthresh=32。当cwnd < ssthresh时,使用慢启动算法当cwnd > ssthresh时,使用拥塞避免算法应用快速恢复算法时机:启动快速重传且正常未失序ACK段达到之前。启动快速恢复算法。实现过程:① 将ssthresh设置为1/2 cwnd,将cwnd设置为ssthresh+3*SMSS。② 每接收一个重复ACK,cwnd值暂时增加1 SMSS。③当接收到新数据ACK后,将cwnd设置为ssthresh。参考:<>

TCP协议头主要由哪些字段组成?
4位版本+4位首部长度+8位服务类型+16位总长度+16位标识+3位标志+13位片偏移+8位生存周期+8位协议+16位首部校验和+32源地址+32位目的地址

【网络协议笔记】第四层:传输层(Transport)TCP协议简介(1)
TCP有以下几个知识点。图片备用地址图片备用地址TCP的几个要点:可靠传输、流量控制、拥塞控制、连接管理(建立和释放连接)。也正因为这几点使得首部变得很复杂。占4位,取值范围是0x0101 ~ 0x1111。乘以4就是首部长度(Header Length)。所以取值范围是5 ~ 60字节,由于首部固定部分占用20字节,所以可选部分至多占用40字节(和网络层首部一样)。为什么叫数据偏移?因为相对TCP报文向右偏移首部长度后就是数据部分。UDP的首部中有个16位的字段记录了整个UDP报文段的长度(首部 + 数据)。但是,TCP的首部中仅仅有个4位的字段记录了TCP报文段的首部长度,并没有字段记录TCP报文段的数据长度。分析:UDP首部中占16位的长度字段是冗余的,纯粹是为了保证首部是32bit对齐。TCP/UDP的数据长度,完全可以由IP数据包的首部推测出来,传输层的数据长度 = 网络层的总长度 - 网络层的首部长度 - 传输层的首部长度。占6位,目前全为0。与UDP一样,TCP检验和的计算内容:伪首部 + 首部 + 数据。伪首部占用12字节,仅在计算检验和时起作用,并不会传递给网络层。图片备用地址一共占6位或9位。有些资料中,TCP首部的保留(Reserved)字段占3位,标志(Flags)字段占9位。Wireshark中也是如此。是因为标志位中的前3位是无用的,所以两种说法都不能说是错的。图片备用地址图片备用地址意思:紧急。当URG=1时,紧急指针字段才有效。表明当前报文段中有紧急数据,应优先尽快传送。紧急指针存放的是长度值,表示TCP的前多少字节是需要紧急优先处理的。意思:确认。当ACK=1时,确认号字段才有效。意思:推。一般用在交互式网络中。PUSH标志位所表达的是发送方通知接收方传输层应该尽快的将这个报文段交给应用层。意思:重置。当RST=1时,表明连接中出现严重差错,必须释放连接,然后再重新建立连接。意思:同步。当SYN=1 & ACK=0时,表明这是一个建立连接的请求。若对方同意建立连接,则回复SYN=1 & ACK=1。请求方再发送SYN=0 & ACK=1时表明开始传输数据。这也是三次握手的流程。意思:完成。表明数据已经发送完毕,要求释放连接。占4字节。首先,传输的每一个字节都会有一个编号(连续的字节编号也是连续的)。在建立连接后,序号代表这一次传给对方的TCP数据部分的第一个字节的编号。占4字节。在建立连接后,确认号代表期望对方下一次传过来的TCP数据部分的第一个字节的编号。占2字节。这个字段有流量控制功能,用以告知对方下一次允许发送的数据大小(字节为单位)。ARQ(Automatic Repeat-reQuest), 自动重传请求。图片备用地址无差错情况A发送数据M1到B,B收到数据M1后向A发送确认信号M1;A收到确认信号M1后,继续向B发送数据M2,B接收后向A发送确认信号M2。超时重传A发送数据M1到B,A在发送数据途中丢包或B发现数据M1有错误直接丢掉,导致B无法向A发送确认信号M1;A在一定时间间隔后发现没有收到B发送的确认信号M1,A会继续向B发送数据M1;B收到数据M1后向A发送确认信号M1,A收到确认信号M1后,继续向B发送M2数据。通过确认与超时重传机制实现可靠传输,在发送完一个分组后,必须暂时保留已发送的分组的副本。分组和确认分组都必须进行编号。超时计时器的重传时间应当比数据在分组传输的平均往返时间更长一些。图片备用地址确认丢失A发送数据M1到B,B接收到数据M1后,向A发送确认信号M1;B在向A发送确认信号M1中途丢包,此时A在一定时间间隔后发现没有收到B发送的确认信号M1,A会继续向B发送数据M1;B收到数据M1后会丢弃重复的数据M1(之前已经收到数据M1,只是A不知道),继续向A发送确认信号M1;A收到确认信号M1后,继续开始发送M2数据。确认迟到A发送数据M1到B,B接收到数据M1后,向A发送确认信号M1;B在向A发送确认信号M1时,由于网络延迟等原因导致A在一定时间段内未收到确认信号;A会继续向B发送数据M1,B收到数据M1后丢弃重复的数据M1,并向A发送确认信号M1;A收到确认信号M1后,继续开始发送M2数据,M2数据刚发送出去,此时A刚好接收到B在第一次发送的确认信号M1,但由于之前已经成功接收并处理了第二次的确认信号M1,所以A在收到确认信号后什么也不做。出现差错或丢失的时候,发送方会将自己备份的副本再重传一次,直到收到接收的确认信息。当接收方收到重复的数据时,会直接丢弃,但是会给发送方请确认自己已经收到了。上面的停止等待协议每发送一组数据就必须等到接收方回复确认后,再发起第二组数据,如果出现超时重传的话,效率更低。因此为了提高传输的效率,改进了等待传输协议。连续ARQ协议和滑动窗口协议的机制是以接收方回复确认为单位,每次连续发送一个滑动窗口指定的数据组。图片备用地址A发送数据给B时,一次性发送M1~M4(A和B建立连接时,B告诉A自己的缓存池可以容纳多少字节数据,A根据这个缓存池的大小构建一个同大小的发送窗口–也可以理解为发送缓存池),此时A开始等待确认,B收到全部数据后会向A发送确认信号M4(以最后一个编号为准);A收到确认信号后,继续向B发送M5 M8(A把之前构建的窗口滑动并锁定到对应大小的数据段上,即M5 M8),以此往复直到数据传输完毕。如果接收窗口最多能接收4个包(窗口大小),但发送方只发了2个包,接收方如何确定后面还有没有2个包?答案:接收方会在等待一定时间后发现没有第3个包,就会返回收到2个包的确认信号给发送方。滑动窗口是由发送方维护的类似指针的变量,在每收到一个接收方的确认消息后,该指针向前移动并发送数据,到窗口指定大小的数据组时停下,等待接收方的确认。图片备用地址累积确认机制: 发送方不对收到的分组逐个发送确认,而是对按序到达的最后一个分组发送确认,这样就表示:到这个分组为止的所有分组都已正确收到了。优点:容易实现,即使确认丢失也不必重传。缺点:不能向发送方反映出接收方已经正确收到的所有分组的信息。Go-back-N(回退 N): 为了解决上述同一窗口中数据组不能完整确认的问题,连续ARQ协议采用了回退机制。比如说:发送方发送了前5个分组,而中间的第3个分组丢失了。这时接收方只能对前两个分组发出确认。发送方无法知道后面三个分组的下落,而只好把后面的三个分组都再重传一次。这就叫做 Go-back-N(回退 N),表示需要再退回来重传已发送过的N个分组。结论:当通信线路质量不好时,连续ARQ协议会带来负面的影响。可能还不如传统的停止等待协议。TCP连接的每一端都必须设有两个窗口——一个发送窗口和一个接收窗口。TCP的可靠传输机制用字节的序号进行控制。TCP所有的确认都是基于序号而不是基于报文段。TCP两端的四个窗口经常处于动态变化之中。TCP连接的往返时间RTT也不是固定不变的。需要使用特定的算法估算较为合理的重传时间。滑动窗口是面向字节流的,为了方便记住每个分组的序号,现在假设有一个1200字节的数据,分12组,每一组数据是100个字节,代表一个数据段的数据(每一个数据都有自己的TCP首部),每一组给一个编号(1~12)。图片备用地址图片备用地址TCP通信时,如果发送序列中间某个数据包丢失,TCP会通过重传最后确认的分组后续的分组,这样原先已经正确传输的分组也可能重复发送,降低了TCP性能。SACK(Selective Acknowledgment,选择确认)技术,使TCP只重新发送丢失的包,不用发送后续所有的分组,而且提供相应机制使接收方能告诉发送方哪些数据丢失,哪些数据已经提前收到等。在建立TCP连接时,就要在TCP首部的选项中加上“允许SACK”的选项,而双方必须都事先商定好。原来首部中的“确认号字段”的用法仍然不变。只是以后在TCP报文段的首部中都增加了SACK选项,以便报告收到的不连续的字节块的边界。图片备用地址Kind:占1个字节,值为5代表这是SACK选项。Length:占1个字节,表明SACK选项一共占用多少字节。Left Edge:占4个字节,左边界。Right Edge:占4个字节,右边界。图片备用地址上图的着色模块代表已接收数据,空白代表未接收数据。左右边界意思是会把未接收完毕的TCP数据包的已接收数据进行左右标记。由于TCP的选项不能超过40个字节,去除Kind和Length占用的2个字节,还剩下38个字节给左右边界使用。一组边界占用8个字节(左右边界各占4个字节),所以边界不能超过4组。也能够因此推断出SACK选项的最大占用字节数是4 * 8 + 2 = 34。思考:超过选项边界的数据怎么办?超过边界的数据需要重新传输,但这已经很大程度提高了传输效率。重传机制是TCP中最重要和最复杂的问题之一。TCP每发送一个报文段,就对这个报文段设置一次计时器。只要计时器设置的重传时间到但还没有收到确认,就要重传这一报文段。那么这个重传时间到底应该设置多少呢?建议跳过,有兴趣的可以去查阅相关资料。图片备用地址为什么选择在传输层就将数据分割成多个段,而不是等到网络层再分片传递给数据链路层?-->网络层没有可靠传输协议,丢包无法只发送一个报文段,所以需要分割成多个段。如果在传输层不分段,一旦出现数据丢失,整个传输层的数据都得重传如果在传输层分段了,一旦出现数据丢失,只需要重传丢失的那些段即可欢迎大家的意见和交流email: li_mingxie@163.com

本文由 在线网速测试 整理编辑,转载请注明出处,原文链接:https://www.wangsu123.cn/news/311950.html。