核心内容摘要
九一看片
3 传输层 TCP/UDP承接上文 HTTP数据经过应用层就到传输层但数据到传输层之前需要先获得服务端的 IP 地址这就涉及到DNS域名解析。
1 DNS
3.
1 DNS 讲解主机的真正地址是IP问题是IP地址不方便人们记忆就像你拿手机给张三打电话难道你能瞬间说出张三电话号码么手机里做一个名字跟电话的映射即可想通话时直接从通讯录找到张三就可以找到对应的手机号在网络请求时候也是需要映射的而域名服务器Domain Name System就是干这个事的深入讲DNS前先了解下域名。
我们在浏览器地址栏中输入的每一个地址都是一个域名比如 www.baidu.com。
域名是由.和不同级别域的域名组成。
通常我们在书写时会省略根域名即域名结尾的.如www.baidu.com.。
由于域名是老外发明的所以从左到右范围逐步变大且以.分割。
DNS分层由上到下域名之间相互包含跟嵌套根域名服务器是关键必须是众所周知的找到了它下面的各级域名服务器才能找到否则域名解析就无从谈起了。
我们看下请求 www.baidu.com 的 DNS 解析流程首先访问根域名服务器根域名是不做域名解析只是给你指路用的现在你获取 com 顶级域名服务器的地址。
请求 com 顶级域名服务器返回 baidu.com 域名服务器的地址。
然后请求 baidu.com 域名服务器返回 www.baidu.com 的地址。
这样进行 DNS 的流程是OK的但问题是全球数十亿的PC电脑如果每个电脑请求上网都按照上面流程走一波那上面的 DNS 核心解析系统瞬间爆炸解决办法就是用缓存很多大公司跟运营商都会搭建自己的 DNS 服务器来代替用户请求核心 DNS 系统如果查到的话可以缓存查询记录再次收到请求的号如果有缓存结果或者缓存未过期则直接返回原来的缓存结果知名的 Google
8.
8.
8DNS 解析服务器就是 Google 自建的非权威域名服务器。
除了非权威域名服务器我们经常看到的有浏览器缓存操作系统缓存比如/etc/hosts文件等。
3.
2 DNS 样例DNS域名解析用户输入网址先看下浏览器的DNS缓存是否过期没过期直接拿来用。
过期了看看本地操作系统缓存 /etc/hosts 文件等。
请求本地配置的 非权威域名服务器 DNS resolver。
DNS resolver 将网址转发到根域名请求返回 com 域名地址。
DNS resolver 将网址转发到 com 域名的服务器请求返回跟 baidu.com 相关的 权威DNS解析器。
DNS resolver 将网址转发权威 DNS 解析器继续请求然后返回真正的目标域名IP。
DNS resolver 最终将目标 IP 返回给用户继续接下来的访问请求。
2 TCP
3.
1 TCP 头部讲解TCP 是一个是面向连接的、可靠的、基于字节流的、工作在传输层的数据传输服务。
用 TCP 传输数据能确保接收端接收的网络包是无损坏、无间隔、非冗余、有序。
这里需注意 TCP 是一对一连接的。
TCP头部 HTTP发送端口是一个大于 1023 的 16 位数字由基于TCP应用程序的用户进程随机选择。
目的端口指明接收者所用的端口号一般由应用程序来指定。
序列号建立连接时客户端生成随机数作为初始值通过 SYN 包传给接收端主机每发送一次数据就累加一次。
序列号达到最大值会出现序列号回绕再次从0 开始。
核心作用就是接收方去重数据 按序接收。
确认号用来解决不丢包的问题指定下一次希望收到的数据的序列号发送端收到这个确认应答以后可以认为在这个序号以前的数据都已经被正常接收。
数据偏移表示 TCP 报文段的首部长度4 位二进制最大表示15由于TCP首部包含个可变长度选项需要指定这个 TCP 报文段到底有多长。
它指出 TCP 报文段的数据起始处距离 TCP 报文段的起始处有多远。
该字段的单位是4字节所以TCP首部最大15*4 60字节。
保留保留6位未使用应置零。
下面的7~12是控制位用来表示说明报文段的性质URG表示本报文段中发送的数据是否包含紧急数据。
只有当 URG1 时后面的紧急指针字段urgent pointer才有效。
ACK表示是否前面确认号字段是否有效。
只有当 ACK1 时前面的确认号字段才有效。
TCP 规定连接建立后 ACK1带 ACK 标志的TCP报文段称为确认报文段。
PSH提示接收端需立即从 TCP 接收缓冲区中读走数据为接收后续数据腾出空间。
为1表示对方应当立即把数据提交给上层应用如果应用程序不将接收到的数据读走就会一直停留在 TCP 接收缓冲区中。
RST收到一个 RST1 的报文说明与主机的连接出现了严重错误必须释放连接然后再重新建立连接。
或者说明上次发送给主机的数据有问题主机拒绝响应带 RST 标志的 TCP 报文段称为复位报文段。
SYN建立连接时用来同步序号。
SYN1 说明这是一个请求建立连接或同意建立连接的报文。
只有在前两次握手中 SYN 才置为1带 SYN 标志的 TCP 报文段称为同步报文段。
当 SYN1 且 ACK0 时表示这是一个请求建立连接的报文段。
当 SYN1 且 ACK1 时表示对方同意建立连接。
FIN通知对方本端要关闭连接了标记数据是否发送完毕。
如果 FIN1 告诉对方释放连接带FIN标志的TCP报文段称为结束报文段。
窗口大小表示现在允许对方发送的数据量告诉对方从本报文段的确认号开始允许对方发送的数据量达到此值需要ACK确认后才能再继续传送后面数据。
校验和提供额外的可靠性。
紧急指针标记紧急数据在数据字段中的位。
选项部分选项部分的最大长度可根据TCP首部长度进行推算。
TCP首部长度用4位表示选项部分最长为(2^4-
*
字节。
TCP 只规定了一种选项即TCP报文段最大长度 MSS通常是1460字节整个TCP报文段的长度 数据字段的长度 TCP 首部的长度 。
填充这里需注意为了网络设备硬件设计和处理方便 数据传输过程中首部长度必须是4字节的整数倍。
3.
2 TCP 三次握手TCP三次握手一开始客户端跟服务器都处于closed状态然后服务端主动监听某个客户端端口此时服务端处于listen状态。
客户端随机初始化序列号seq client_isn同时将SYN 1表示这是SYN报文接着把该SYN报文发给服务器注意此时报文不包含引用层数据客户端处于syn-sent状态。
服务端收到客户端的SYN报文后也随机初始化个序号seq server_isn并且将确认序号ack client_isn 1接着把SYN 1跟ACK 1然后该报文发送给客户端服务器处于syn-rcvd状态。
客户端收到服务器的报文后将ACK 1确认应答号ack server_isn 1然后把报文发送给服务器本次报文可发送数据同时客户端处于established状态。
服务器收到客户端的应答报文后也进入established状态。
客户端和服务端建立好了连接可以相互发送数据。
这里你可能发现了客户端跟服务器的初始化序列号是各自随机的原因是网络中的报文会重发、会延迟、也有可能丢失为避免相互影响干脆各用各的为好。
同时通过流程发现前两次握手是不带数据的第三次可携带数据。
3.
3 TCP 数据传输大致流程前面在HTTP时候就说过了数据到TCP层跟IP层都会拆分发送有人可能会问既然IP会分帧那为什么TCP层还分层呢原因是如果TCP不分层只用IP层分帧数据发送如果有一帧出现丢失则会导致整个IP报文分帧全部重传。
本质在于IP层没有重传机制而TCP层可以实现数据的超时重传、丢失重传。
信息传输大致流程
3.
4 TCP 状态查询服务器一般用netstat查看 tcpudp 的端口和进程等相关情况。
netstat -tunlp | grep 端口号-t (tcp) 仅显示tcp相关选项 -u (udp) 仅显示udp相关选项 -n 拒绝显示别名能显示数字的全部转化为数字 -l 仅列出在Listen(监听)的服务状态 -p 显示建立相关链接的程序名netstat样例
3.
5 TCP 为啥三次握手TCP是不区分客户端和服务端连接的建立是双向的过程。
所以客户端要给服务器通讯的话两次握手是必须的。
第一次握手客户端发个连接请求给服务端服务端收到后知道自己可以跟客户端连接了但是此时客户端不知道啊所以必须的执行第二次握手反馈下信息给客户端。
第一次握手请求连接如果因为网络导致延迟直到连接释放后信息才到达服务端那此时服务端也会给客户端进行第二次握手回复关键是客户端已经不要这个连接了此时服务端会一直在等待接收客户端信息造成资源浪费。
如果用了三次握手则客户端会发送 RST 报文告知服务端请终止本次旧连接。
如果还不太理解我们用个生活常识说明下。
晚上你在小区里散步不远处看见一位漂亮妹子迎面而来因为路灯有点暗不能100%确认所以要通过招手的方式来确定对方是否认识自己。
你首先向妹子招手 syn。
妹子看到你向自己招手后向你点头微笑 ack。
她也需要确认一下你有没有可能你是在看别人呢妹子也向你招手 syn。
你看到妹子微笑ack后确认了妹子成功辨认出了自己进入established状态。
妹子给你招手 syn了你也微笑 ack回复妹子收到后也进入established状态。
因为妹子连续进行了两个动作先是点头微笑然后再次招手所以可以将这两个动作合成一个动作招手的同时点头和微笑。
于是这四个动作就简化成了三个动作。
你与妹子的相识
3.
6 TCP 三次握手的意义避免历史连接客户端建立连接时发送多次 SYN 报文由于网络拥堵可能旧的 SYN 报文比新的 SYN 报文先到服务器服务器不管新旧收到就回复 SYN ACK 给客户端三次握手情况下客户端可以根据序列号或超时时间判断回复的连接是否是历史连接如果是历史连接直接发送 RST 报文给服务端来终止连接。
同步双方初始序列号TCP 协议的通信双方都在维护各自的序列号且必须要让对方知道。
只有通过三次握手才可以实现。
避免服务端资源浪费二次握手情况下如果客户端的 SYN 阻塞导致重复发送多次 SYN 报文那么服务器在收到请求后就会建立多个冗余的无效链接造成不必要的资源浪费。
而三次握手发现无效链接可在第三次给服务器端发送终止指令。
3.
7 TCP 连接中客户端忽然挂掉咋办TCP还设有一个保活计时器服务器每收到一次客户端的请求后都会重新复位这个计时器时间通常是设置为2小时若两小时还没有收到客户端的任何数据服务器就会发送一个探测报文段以后每隔75秒发送一次。
若一连发送10个探测报文仍然没反应服务器就认为客户端出了故障接着就关闭连接。
3.
8 TCP 如何避免 SYN 攻击TCP 连接时会经过三次握手在第一次握手后服务端收到 SYN 报文 就会发出 ACK SYN 报文 同时进入 SYN_RCVD 状态如果有黑客伪造 n 个不同 IP 发出请求会导致服务器的 SYN_RCVD 队列 爆满最终无法对外提供服务。
解决方法设置 SYN_RCVD 最大值服务端超过处理能力时直接将新的 SYN 请求 RST 丢弃。
可缩短 SYN Timeout 时间通过缩短从接收到 SYN 报文到确定这个报文无效并丢弃该连接的时间可以降低服务器负荷。
设置SYN Cookie给每个请求连接的 IP 地址分配一个 Cookie如果短时间内收到同一个 IP 的重复 SYN 报文则以后从这个 IP 地址来的包会被丢弃。
3.
9 TCP 四次挥手客户端跟服务端都可以发出端口请求TCP 断开连接是通过四次挥手方式。
TCP四次挥手客户端停止发送数据并且发出释放连接的报文报文中FIN 1FIN报文段即使不携带数据也要消耗一个序号此时序列号seq uu 前面已经传输过来数据最后一个字节序号加1客户端进入FIN-WAIT-1状态。
服务器收到连接释放报文发出确认报文ACK1应答确认好acku1并且带上自己的序列号seqv此时服务端就进入了CLOSE-WAIT状态。
TCP 服务器通知高层的应用进程进入半闭状态即客户端已经没有数据要发送了但是服务器若发送数据客户端依然要接受。
这个状态还要持续一段时间也就是整个CLOSE-WAIT状态持续的时间。
客户端收到服务器的确认请求后此时客户端就进入FIN-WAIT-2状态等待服务器发送连接释放报文在这之前还需要接受服务器发送的最后的数据。
服务器将最后的数据发送完毕后就向客户端发送连接释放报文FIN1acku1由于在半关闭状态服务器很可能又发送了一些数据假定此时的序列号为seqw此时服务器就进入了LAST-ACK状态等待客户端的确认。
客户端收到服务器的连接释放报文后必须发出确认ACK1ackw1sequ1此时客户端就进入了TIME-WAIT状态。
注意此时 TCP 连接还没有释放必须经过最长报文段寿命2MSL的时间后当客户端撤销相应的TCB后才进入CLOSED状态。
服务器只要收到了客户端发出的确认立即进入CLOSED状态。
同样撤销TCB后就结束了这次的 TCP 连接可以看到服务器结束TCP连接的时间要比客户端早一些。
我们还以你跟妹子碰面交流为例你俩彼此确认后交流几分钟后你打算结束这个谈话毕竟交流太久没老婆发现就凉了。
你跟妹子挥手离别
3.
10 TCP 为什么四次挥手其实分析下整个关闭的流程就知道为什么必须是四次挥手而不是三次挥手了。
关闭连接时客户端向服务端发送FIN时仅仅表示客户端不再发送数据出去了但是还是能接收数据。
服务器收到客户端的FIN报文时先回一个ACK应答报文意思是不再接受数据了但服务端可能还有数据需往外发送等服务端不再发送数据时才发送FIN报文给客户端来表示同意现在关闭连接。
这里注意服务端的ACK跟FIN是分开发的。
客户端收到服务端的ACK后再给服务端发送ACK最终客户端跟服务器都进入close状态。
3.
11 TCP 挥手为什么需要 TIME_WAIT 状态MSL 定义Maximum Segment Lifetime 报文最大生存时间意思是网络传输的报文在网络上存在的最长时间超过这个时间报文将被丢弃。
而数据之所以可以被抛弃是因为TCP层的下面的IP层有个TTL来记录报文传输过程中经过的最大路由次数。
TIME_WAIT 定义TIME_WAIT 2* MSL原因是 发送方数据到接受方后接收方会返回响应这样一来一回正好2 倍的MSL。
Time_wait 是从客户端接收到 FIN 后发送 ACK 开始计时的如果在 TIME-WAIT 时间内客户端的 ACK 没有传输到服务端客户端又接收到了服务端重发的 FIN 报文那 2MSL 将重新计时。
TIME_WAIT 存在意义防止旧连接的数据包被重新消费上一次连接时候如果有网络震荡导致服务端数据在网络游荡如果因为 time_wait 时间太短新的连接可能会重新接受到游荡的消息。
有了延迟时间可以避免消耗游荡的数据。
确保连接正确关闭TIME-WAIT 作用是等待足够的时间以确保最后的 ACK 能让被动关闭方接收从而帮助其正常关闭。
TIME_WAIT 发生场景在高并发短连接的 TCP 服务器上当服务器处理完请求后立刻主动正常关闭连接。
这个场景下会出现大量 socket 处于 TIME_WAIT 状态。
如果客户端的并发量持续很高因为端口有限内存有限会导致此时部分客户端显示连接不上。
在Linux内核中 TIME_WAIT 60秒。
避免 TIME_WAIT 过多取消短连接改用长连接方式设定阈值一旦超过阈值系统会将所有time_wait 连接重置。
修改客户端程序代码。
3.
12 TCP 如何保证数据传输可靠校验和发送跟接受数据都会进行检验的如果不一致那么传输有误。
确认应答序列号TCP进行传输时数据都进行了编号每次接收方返回ACK都有确认序列号。
超时重传如果发送方发送数据一段时间后没有收到ACK那么就重发数据。
并且自带去重功能。
连接管理三次握手和四次挥手的过程。
流量控制TCP协议报头包含16位的窗口大小接收方会在返回ACK时同时把自己的即时窗口填入发送方就根据报文中窗口的大小控制发送速度。
拥塞控制刚开始发送数据的时候拥塞窗口是1以后每次收到ACK则拥塞窗口1然后将拥塞窗口和收到的窗口取较小值作为实际发送的窗口如果发生超时重传拥塞窗口重置为1。
这样做的目的就是为了保证传输过程的高效性和可靠性。
3 UDPUDP 为应用程序提供了一种无需建立连接就可以发送封装的 IP 数据包的方法它的协议很简单头部只有八个字节UDP头部两个十六位的端口号分别为源端口和目标端口。
包长度该字段 UDP首部长度 数据长度。
校验和整个数据报文的检验和该字段用于发现头部信息和数据中的错误。
3.
1 UDP 特点UDP有不提供数据包分组、组装和不能对数据包进行排序的缺点当报文发送之后是无法得知其是否安全完整到达的。
面向无连接UDP 不会进行三次握手建立连接想建立连接就建立连接并且也只是数据报文的搬运工不会对数据报文进行任何拆分和拼接操作。
在发送端应用层将数据传递给传输层的 UDP 协议UDP 只会给数据增加一个 UDP 头标识下是 UDP 协议然后就传递给网络层了。
在接收端网络层将数据传递给传输层UDP 只去除 IP 报文头就传递给应用层不会任何拼接操作有单播、多播、广播的功能UDP 不止支持一对一的传输方式同样支持一对多多对多多对一的方式也就是说 UDP 提供了单播多播广播的功能。
UDP面向报文发送方的UDP对应用程序交下来的报文在添加首部后就向下交付IP层。
UDP对应用层交下来的报文既不合并也不拆分而是保留这些报文的边界。
因此应用程序必须选择合适大小的报文不可靠性不可靠性体现在无连接上通信都不需要建立连接想发就发这样的情况肯定不可靠。
收到什么数据就传递什么数据并且也不会备份数据发送数据也不会关心对方是否已经正确接收到数据了。
没有拥塞控制一直会以恒定的速度发送数据。
网络不好可能导致丢包在某些实时性要求高的场景比如视频电话就需要使用 UDP。
头部开销小UDP 的头部开销小只有八字节相比 TCP 的至少二十字节要少得多在传输数据报文时是很高效的
3.
2 TCP 跟 UDP 对比
3.
3 TCP UDP 共有端口你可能经常被问到TCP和UDP为何可以共用同一端口这是因为从网络层的角度来看它是不知道端口这个概念的TCP/UDP 都是包裹在 IP 协议内的IP 协议只需要知道 IP 对应的硬件地址就可以把远端的网络包发送到目的主机上。
端口这个概念是由操作系统划分的。
因为内核不可能把所有网络数据都发送给所有的进程所以为了区分哪些数据该划分给哪些进程便在传输层的协议中定义了端口。
而TCP和UDP协议中的端口号占位都是16位所以操作系统能绑定的端口也就只有65535个。
如果你查看 C 语言有关 Socket 编程中的socket跟bind函数你会发现系统是以 协议 ip 端口来绑定端口的所以不同协议相同的ip和端口也是可以绑定成功的。
4 TCP 进阶
1 TCP 重传机制为保证数据安全到达接受端TCP引入了超时重传、快速重传、SACK、D-SACK。
4.
1 超时重传以时间为基准在发送数据时设置个定时器如果期限内没收到接受者的ACK就会重新发送数据一般数据包丢失或确认应答丢失会导致超时重传这里先普及两个跟时间相关的参数跟一些规则。
RTTRound-Trip Time 往返时间指的是数据从发送到接受的耗时时间。
RTORetransmission Timeout 超时重传时间。
动态RTT 收到网络波动是动态变化的同理RTO也是动态变化的。
RTO翻倍每遇到一次超时重传系统都会将下一次RTO翻倍。
RTO跟RTTRTT跟RTO之间的关系十分微妙。
RTO 较小时可能导致数据本来就没丢失只是还没被响应 又重发会增加网络拥塞导致更多的超时重发。
RTO较大时候可能导致数据已经丢了好久才重发数据。
所以离线情况下 RTO稍微大于RTT是最好的。
具体规则有兴趣的可自行百度。
4.
2 快速重传TCP有累计确认机制当接收端收到比期望序号大的报文段时便会重复发送最近一次确认的报文段的确认信号我们称之为冗余ACKduplicate ACK。
如图所示报文段1成功接收并被确认ACK 2接收端的期待序号为2当报文段2丢失报文段3失序到来与接收端的期望不匹配接收端重复发送冗余ACK 2。
快速重传机制发送端如果在超时重传定时器溢出之前接收到连续的三个重复冗余ACK其实是收到4个同样的ACK第一个是正常的后三个才是冗余的发送端便知晓哪个报文段在传输过程中丢失了于是重发该报文段不需要等待超时重传定时器溢出最后客户端收到 2因为345已经回复过了返回ACK6。
为啥是3次呢你要明白发送端即使按序发送接收端也是会出现乱序的。
乱序也会造成冗余ACK发送那冗余ACK是乱序导致还是丢包导致呢经过权衡把3次冗余ACK作为判定丢失的准则其本身就是估计值。
数据接收情况A为发送端B为接收端A的待发报文段序号为 【N-1,N,N1,N2】假设报文段N-1成功到达。
在没丢失的情况下有40%的可能出现3次冗余ACK在乱序的情况下必定是2次冗余ACK。
在丢失的情况下必定出现3次冗余ACK。
基于这样的概率选定3次冗余ACK作为阈值也算是合理的。
实际抓包时大多数的快速重传都会在大于3次冗余ACK后发生。
快速重传解决了超时问题可是重传时是重传之前的一个还是重传所有它是定不了的。
4.
3 SACK既然快速重传搞不定就用 Selective Acknowledgment 选择性确认原理也很简单服务端给客户端回复的时候多加个字段SACKSACK的内容就是告知发送端服务端收到了哪些。
这样服务端可以根据收到的信息选择性发送丢失的包。
4.
4 D-SACKDSACK是在SACK的基础上做了一些扩展主要用于对收到的重复报文进行了处理。
DSACK同样使用了与SACK一样的报文格式。
核心关注点是发送的时候出问题了还是回复的时候出问题了。
如果发送端发送数据A延时而触发了快速重传机制快速重传机制发送过来的信息新A然后老A又到了接收端会回复SACK 意思是网络震荡导致的。
如果服务端的ACK 客户端没收到客户端重发的时候服务端会回复SACK意思就是你的数据发送重复了。
2 TCP 滑动窗口如果没有滑动窗口的机制传输N份文件就需要等待N次应答时间。
总的传输时间 N份传输时间 N份应答传输时间。
保证可靠性的前提下TCP 引入了窗口概念滑动窗口可以让我们进一步提高传输效率。
在窗口内的数据无需等待确认应答就可以继续发送数据。
窗口的本质是OS开辟的一个缓存空间然后进行批量传输只要接收方没确认应答那么缓存中会一直存在。
总的传输时间 N分数据传输时间叠加成一份时间N份应答传输时间重叠成一份时间窗口大小为4000字节窗口大小一般是接收方来决定的接收方会告知发送方自己有多少缓存可接受数据如果超过这个数据量接收方就无法接收了。
4.
1 发送滑动窗口滑动窗口在一的状态下发送方收到一个请求序列号2001的确认应答ACK则2001前数据被标记为传输完毕系统会进行窗口滑动变为二的样子。
窗口左边是已经发送并且受到服务器的ACK的数据这些数据可以从缓存删除。
窗口内的数据其实也分为两类一类是发送还没接收到ACK的一类是还未发送的。
在收到整个窗口的确认应答ACK之前如果数据有丢失发送端仍然需要重传。
所以发送端需要有缓存保留可能被重传的数据直到收到服务端ACK。
收到服务端ACK后发送端会将窗口滑动到确认应答中的序列号的位置。
这样可以顺序地将多个段同时发送提高通信性能。
这种机制也别称为滑动窗口控制。
窗口模式下发送方也会根据接收方的能力来进行发送数据来进行流量控制。
4.
2 窗口数据丢失这里的数据丢失其实跟前面说到的重传机制类似主要分为两种接收端收到信息但是返回ACK失败了如果丢失ACK不需要做任何处理如3001这个ACK丢了但是4001ACK却已经发送给主机A说明2001~3000这个数据也顺利到达3001ACK丢了无所谓只要当前序号开始就说明之前的数据已经正确传输到达主机B收到数据但ACK丢失发送端发送数据中途数据丢失了如下图
数据包丢了而
,
都顺利到达此时接收方反馈的ACK确认序号始终是1001发送方如果发现接收方连续发送ACK都是1001接收方就明白
这个数据丢包就会重新传送当接收方重新收到丢失的
数据后直接返回ACK4001因为
已经接受过放到缓存区了接下来ACK直接从4001开始。
发送时丢失
3 拥塞控制前面说到的流量控制只是单纯的对于发送方跟接受方而已但是我们要知道网络一般都是公用的别的服务器也可以能将网络搞阻塞因为阻塞导致重发然后重发导致更阻塞最后陷入恶性循环。
为了控制发送方的数据量避免数据阻塞整个网络发送方维护着一个叫拥塞窗口的东西前面说到过发送窗口跟接受窗口现在由于有了拥塞窗口此时 发送窗口swnd min(拥塞窗口cwnd接受窗口rwnd)。
拥塞窗口的大小是动态变化的当网络没阻塞就会变大网络中有阻塞就会变小。
判断阻塞的依据就是如果发送方在指定时间内没收到数据那就是阻塞了。
拥塞控制主要通过慢开始快重传快恢复和避免拥塞来实现的。
4.
1 慢开始TCP建立连接后系统有个慢启动的过程意思就是一点一点的提高发送数据包的数量慢启动的原则就是当发送方每收到一个 ACK拥塞窗口 cwnd 的大小就会加 1。
有一个叫慢启动门限 slow start threshold 状态变量来充当最大值。
cwnd ssthresh 时使用慢启动算法。
cwnd ssthresh 时使用拥塞避免算法。
4.
2 拥塞避免算法一般情况下 slow start threshold 65535字节系统进入拥塞避免算法后每当收到一个 ACK 时拥塞窗口就增加 1/拥塞窗口。
拥塞避免算法存在的意义就是将慢开始的那种指数增长变化为线程增长。
4.
3 快重传进入拥塞避免算法后的数据随着不断增长最终会导致网络阻塞最终引发丢包。
然后会采用前面说到的超时重传跟快速重传。
超时重传ssthresh cwnd/2 同时 cwnd 重置为 1然后重新开始慢启动回到了起点。
快速重传cwnd cwnd/2 同时 ssthresh cwnd 然后进入快速恢复算法。
4.
4 快恢复快恢复与快重传配合使用当发送方接收到连续三个重复确认请求为了避免网络拥塞执行快速重传(cwnd cwnd/2 同时 ssthresh cwnd )执行快速恢复算法。
cwnd ssthresh 3重传丢失的数据包收到重复ACK则 cwnd 累加 1。
收到新ACK后设置 cwnd ssthresh进入拥塞避免算法。