目录

传输层端口代码,多路径重用,多路径分解

1.1,运输层端口编号

端口号的基本概念

TCP/IP系统应用层通用协议中使用的知识端口代码

1.2.多路径重用和多路径分解运输层

编辑面向连接的运输:TCP

2.1TCP连接

2.2TCP和UDP协议的比较

2.3TCP报告表格

2.4TCP三手(创建连接)

2.4.1TCP为了确保连接的可靠性,每次通过三个握手建立一个可靠的连接

2.4.2使用tcpdump命令获取构建过程

可以握手两次吗(面试问题)

2.5TCP四波(免费连接)

2.5.1TCP使用四个哨声去切断;编辑

2.5.2使用tcpdump命令抓取以查看分离过程

2.5.3时间等待时间有太多的时间,为什么?(面试问题)

2.5.在 TIME_WAIT状态中,是否可以强制使用由连接所占用的插座地址?这是怎样实现的?(面试)

2.6TCP连接SYN洪水攻击

现场计时器2.7TCP功能

2.8显示TCP建立与切断状态图

2.8TCP流量控制

2.9TCP拥堵控制

2.9.以三种方式解释交通堵塞的原因和交通堵塞成本(书中解释);

2.9.2拥堵控制方法

它开始缓慢,避免拥挤

2.9.4快速重传和快速恢复

2.10TCP超时再传输的时间选择

2.10.超时转播的极端情况

2.10.1往返时间估计数及加班费

2.11TCP总结

TCP端口编程(c++实现代码)

TCP编程流程

客户端

服务器端

参考文献

传输层端口代码,多路径重用,多路径分解

1.1,运输层端口编号

端口号的基本概念

在网络编程中,我们经常能听到端口数的概念,TCP协议是例外,那么端口数是什么?

举个简单的例子:如果IP用于定位街道,然后港口是每个街道的门的数目.在通讯过程中，数据通过各种通信协议进入设备(例如计算机)后,这里的设备相当于一条街区,还有许多程序在设备计算机内运行,数据进来之后，你必须给它相应的门号(即港口号),这 是 促进 后续 行动 的 程序 。端口号是传输协议的一部分,因此我们可以说，数据通过IP地址向指定设备发送相应的数据,数据通过端口号码发送到指定的服务或程序。

TCP/IP系统的传输层使用端口编号来区分应用程序层中的不同的应用程序进程。

端口号使用16位元,所以值范围为0~65535;

port 号 按 范围 划分 为 三 类, 如下 :

• 熟知端口号：0~1023,IANA将这些端口编号分配到TCP/IP系统中最重要的应用协议中,例如FTP使用21/20、HTTP使用80、DNS使用53;
• 登记端口号：1024-49151,对于没有数字端口号的参考程序,这些端口号必须按照规定程序在IANA注册,以防止重复,例如: Microsoft RDP Microsoft Remote Desktop使用端口号3389。
• 短暂端口号当服务器进程从客户端进程接收消息时,客户端进程所使用的动态端口号码是知道的。 通信完成后,该端口号码可用于其他客户端进程使用。

TCP/IP系统应用层通用协议中使用的知识端口代码

协议及服务器	端口号
HTTP	80/8080/3128/8081/9098
HTTPS	443/tcp  443/udp
SOCKS代理协议服务器	1080
.FTP协议	21
特尔网协议	23
FTP	21/tcp
TFTP	69/udp
SSH(安全登录),SCP(文件传输)	22/tcp
SMTP	25/tcp
POP3（E-mail）	110/tcp
Webshpere应用程序	9080
webshpere管理工具	9090
JBOSS	8080
TOMCAT	8080
赢得2003年远程登录	3389
MS SQL*SERVER数据库服务器	1433/tcp 1433/udp
MS SQL*SERVER数据库监控器	1434/tcp 1434/udp
DNS	53/udp
Mysql数据库	3306
BGP	179

1.2.多路径重用和多路径分解运输层

为了解释分解和复制的过程,这里是一个简单的例子:

家庭中的每一个孩子都以他们的名字标识。假设安的家人寄给比尔一封信;当比尔从邮局收到一包信时,然后检查收件人的名字,把信交给他的兄弟姐妹,他所进行的手术是解体;安娜从她的兄弟姐妹那里拿来手机短信,交给邮政员时,她所进行的操作是多路径复制;

给出了多路径复制和多路径分解的概念:

• 在接收端：传输层检查这些字段,识别接收端的接口,然后将消息节指向该接口。 将传输层声明中的数据送到正确的接口的任务叫做复数。
• 在源主机： 源主机从不同的插座收集数据块,并对每个数据块的第一个信息进行封装(然后将被分解),生成一个消息段,然后被传递到网络层,所有这些都称为多重化。

如图所示,多路径重用和分解的过程是:

面向连接的运输:TCP

2.1TCP连接

TCP称为连接导向(connection-oriented)，这是因为在一个应用程序进程开始向另一个应用程序进程发送数据之前,这两个过程必须先握手.也就是说,他们必须互相发送一些筹备声明,建立参数以确保数据传输。作为TCP连接的组成部分,连接的两边都启动许多与TCP连接相关的TCP状态变量。

TCP为每个客户端数据设置一个TCP头条,这会创建多个TCP段。这些段落被传递到网络层中,网络层将它单独封入网络层IP数据消息中.然后这些IP数据消息被发送到网络上。当TCP在另一端接收消息段时,消息段的数据将放在TCP连接接收缓存中,如上图所示。应用程序从缓存中读取数据流.每个连接端都有自己的发送和接收缓存。

2.2TCP和UDP协议的比较

• TCP协议提供:面向连接、可靠、字节流服务。TCP协议必须首先为双向通信建立连接。然后你可以开始读写数据。双方必须分配连接所需的核心资源,管理连接状态和数据传输。TCP连接完全双功能,双方的数据可以通过连接读写.完成数据交换之后，通信双方必须切断连接,以释放系统资源.
• UDP数据报告服务特点:发送程序每次执行写字操作,UDP模块将它包入UDP数据消息中。接收者必须为每个UDP数据消息及时执行读取操作,否则就会丢包。并且，如果用户没有指定足够的应用程序缓冲区读取UDP数据,那么UDP数据将被中断。

下图可以帮助记忆：

2.3TCP报告表格

TCP消息部分由第一个字段和一个数据字段组成。数据字段包含应用程序数据。MSS限制消息字段数据字段的最大长度。当TCP发送一个大的文件时,例如,在网页上的图片,TCP通常是将文件的增长率分成多个MSS块(除了最后一个,它通常比MSS更小。然而，交互式应用程序通常传输比MSS小的数据块。例如，对于像Telnet这样的远程登录应用程序,其TCP消息字段的数据字段通常只有一个字节。因为TCP的标题通常是20字节(比UDP的标题多12字节),因此,Telnet发送的消息段可能只有21字节长。

下面的图示了TCP消息段的结构:

• 源端口： 用于识别主机端口号码。
• 目的端口号：用于识别目标主机的端口号码。
• 序号: 32位元,值范围[0,最后一个序列被添加后,下一个序列返回0。TCP消息字段数据负载的第一个字母序列。
• 确认号:32位元,值范围[0,在确认数加到最后一个后, 下一个确认数返回0. 它指示了从另一方的下一个TCP消息中预期接收的数据负载的第一个字节的序列,以及所有先前接收的数据的确认。 如果数值=n被确认,它表示到n-1序列的所有数据已经被正确接收,并期望接收n序列的数据。
• 确认标志位ACK:该值仅适用于一个小时确认字段;该值不适用于0小时确认字段。TCP 规定, 在 建立 连接 后 发送 的 所有 TCP 消息 段 都 必须 使用 ACK 代替 1.
• 数据偏移: 它由4位元组成,并由4位元组成。 表示TCP消息段的数据负载部分的起点与TCP消息段的起点有多远。这 一 领域 实际上 指 到 方案 协调 会 报告 段 第 一 级 的 部长级 。
• 保留: 6位元,预留将来使用,但现在应该设置为0。
• 窗口:它是六位字节。 指向接收窗口,一方面发送该条文本。接收器的窗口值允许发送者为其发送窗口设置基础,由接收器接收接收发送器发送的能力控制,称为流量控制。
• 校验和:对于16位元,检查范围包括TCP声明的第一个部分和数据负载的两个部分。在计算校正和验证时,在TCP声明段前加上12字节的假标题。
• 同步标志位SYN:它用于在建立TCP连接时同步序列数(tcp三手配置1)。
• 终止标志位FIN:用于释放TCP连接(Four hands on FIN position 1)。
• 推送标志位PSH:接收器的TCP接收到1号信号的位数尽快。 没有等待接收缓存的填充和传送,提交应用程序过程。
• 紧急标志位URG:值为1小时紧急标记字段有效;值为0小时紧急标记字段无效。
• 紧急指针:占用16位元, 单位字节, 指示紧急数据的长度.当发送者有紧急数据时,紧急数据插件可以放在发送缓存的前面,并立即封入发送的TCP消息部分。
• 填充:由于选项的变长,填充是用来确保报告段头部分可以缩小4字(因为数据转移字段,即第一个部长字段,由4字节统一)
• 选项：TCP消息段落的功能可以扩展,包括以下:
• （1）最大消息段落长度MSS选项:TCP消息段的数据负载部分的最大长度。
• （2） 窗口扩大选项: 扩大窗口(增加吞吐率)
• （3）时间戳选项:它用于计算返回时间RTT用于处理序列溢出,也被称为防止序列逆转PAWS。

2.4TCP三手(创建连接)

2.4.1TCP为了确保连接的可靠性,每次通过三个握手建立一个可靠的连接

• 第一步：客户端的TCP首先发送一个特殊的TCP消息到服务器的TCP。报告不包含应用程序层数据。然而,段落的第一部分的一个符号(即SYN bit)被放置为1。因此，这个特别报告段称为SYN报告段。另外，客户端将随机选择一个初始序列(seq=x)并将其置于初始TCP SYN消息字段的序列字段中。该消息将包含在IP数据消息中,并发送给服务器。
• 第二步：一旦包含TCP SYN消息字段的IP数据消息到达服务器主机(假设是!),服务器从数据报告中提取TCP SYN声明,分配TCP缓存和TCP连接的变量,并发送给客户端的TCP允许的连接消息。这些缓存和变量在三个握手的第三步之前分配,使得TCP更容易被拒绝服务SYN洪水攻击。允许连接的报告部分不包含应用程序层数据。但是，报告第一部分载有三个重要的资料。首先，SYN bit 设置为 1.其次，TCP消息的第一部分的确认字段缺口设置为x+1。最后，服务器选择自己的初始序列(seq=y),并将其放在TCP消息的第一部分的序列字段中。允许连接的声明实际上表示:"我收到了您为创建连接发起的SYN子组,该组具有初始序列 client_is 。我同意建立该连接。我的初始序列是y。允许连接的报告段称为SYNACK报告段。
• 第三步:收到 SYNACK 的 意见 后,客户端还将缓存和变量分配给连接。客户端主机向服务器发送另一个消息;这个最后的消息Ack确认服务器的允许连接到消息(客户端将y+1值传递到TCP消息的第一个确认字段完成这项任务)。自从连接建立以来,因此SYN bit 设置为0。三个握手的第三阶段可以从客户端到服务器的数据在报告字段负载中。

2.4.2使用tcpdump命令获取构建过程

在Ubuntu下使用命令tcpdump,您可以抓取并观察TCP连接的建立和关闭。命令需要管理员的特权,格式如下 ( 假设测试的两个主机的IP地址是和 ) :

可以握手两次吗(面试问题)

不可以

假设客户端向服务器发送请求建立连接(SYN声明),然而,由于某些原因,它未能及时到达服务器端;基于TCP协议的加班重传输机制,客户端发送第二个SYN消息,以建立连接,服务器收到之后，确认向客户端发送的SYN消息段,上述三个握手的第二步;我们完成连接(两个握手)并发送数据等,直到连接关闭;在关闭状态的服务器收到客户端发送的第一SYN消息(建立连接),服务器响应它(进入已建立的连接阶段),但客户端是关闭的(服务器不知道),所以服务器端继续传递预期从客户端接收的数据;该过程在图中显示:

2.5TCP四波(免费连接)

2.5.1TCP使用四波切断连接;

• 第一步：客户端进程发送连接释放消息,并且停止发送数据。释放数据报文首部，FIN=1，其序列数为 seq=u(等于序列数加上先前传输的数据最后一个字母),此时,客户端输入Fin-WAIT-1(停止等待1)状态。 TCP规定，即使 FIN 没有 数据,也要消耗一个序号。
• 第二步：服务器收到连接释放消息,发出确认报文，ACK=1，确认序列号是u+1,并带你自己的序列号seq=v,此时,服务端进入CLOSE-WAIT状态。TCP服务器通知高级应用程序进程,客户端向服务器方向释放,现在,它处于半封闭状态,也就是说,客户没有发送数据,但是如果服务器发送数据,客户端依然要接受。这种状况将持续一段时间,这就是整个CLOSE-WAIT状态的持续时间。
• 第三步： 在客户端收到服务器的确认请求后,客户端输入Fin-WAIT-2(停止等待2)状态并等待服务器发送连接释放消息(在此之前,服务器发送的最终数据必须被接受)
• 第四步：服务器完成发送最终数据后,向客户端发送连接释放消息,FIN=1，确认序号为u+1，由于在半关闭状态，服务器可能会发送更多的数据,假设这个序列数是 seq=w,此时，服务器输入LAST-ACK(最后确认)状态,等待客户端的确认。
• 第五步：客户端收到服务器的连接释放消息后,必须发出确认，ACK=1，确认序号为w+1，他自己的序列数是u+1,此时，客户端输入时间等待(TIME)状态。注意,TCP连接尚未发布,在2*MSL(最长的报告期间)之后,当客户取消相应的TCB时,只进入封闭状态。
• 第六步：服务器一旦收到客户端的确认,就会进入CLOSED状态。 类似地,TCB退出后,TCP连接终止。
• MSL的报告时间最长,RFC793建议2分钟;(现在网络可能更短);

2.5.2使用tcpdump命令抓取以查看分离过程

2.5.3时间等待时间有太多的时间,为什么?(面试问题)

答案是不多多余；

如图，假设时间等待被取消,当客户端发送确认消息时,因为没有时间等待,如果客户端发送的确认消息丢失,则该客户端将直接关闭。如图所示，然后服务器将等待客户端的确认消息,进行不停的重传，一直无法关闭；

2.5.在 TIME_WAIT状态中,是否可以强制使用由连接所占用的插座地址?这是怎样实现的?(面试)

是的;服务器程序可以通过设置索克选项SO_REUSEADDR来强制在 TIME_WAIT状态中使用由连接占用的索克地址。

2.6TCP连接SYN洪水攻击

正如我们在讨论TCP的三个握手时所看到的那样,服务器分配和初始化连接变量和缓存以响应接收的SYN。然后服务器发送一个SYNACK来响应,然后等待顾客的ACK消息.如果客户不发送ACK完成三个握手的第三步,最终(通常在超过一个小时后)服务器终止半开连接并恢复资源。该TCP连接管理协议为经典的DoS攻击提供了环境,即SYN洪水攻击。在这种攻击中，攻击者发送大量TCPSYN消息,没有完成震动的第三步。随着SYN的报道不断,服务器不断分配资源(但从未使用)到这些半开放的连接中,这使得服务器的连接资源耗尽。这个SYN洪灾攻击是许多报告的DoS攻击中第一个(CERTSYN 1996)。幸运的是，现在有一个有效的防御系统,叫SYN cookie [ RFC 4987 ],它们被部署在大多数主流操作系统中。SYN的cookie工作如下:

• 1.当服务器接收SYN消息段时,它 不知道 该 段落 是 合法 使用 的,户，它也是SYN洪水袭击的一部分。因此,服务器不会为消息段生成半开连接。相反，服务器生成一个初始的TCP序列号码,序列数是SYN消息字段的源和目的地IP地址和端口数,以及一个复杂的函数(散射函数),只有服务器知道秘密数。这个复杂的初始序列数称为“cookie!”。服务器发送这个特殊的初始序列编号的SYNACK子集。重要的是，服务器不会记住 cookie 或 任何与 SYN 相符的其他状态信息.
• 如果客户合法,然后它返回一个ACK声明段落。当服务器接收ACK时,必须验证ACK是否与先前发送的SYN相符。如果服务器没有维护SYN消息节的内存,这是怎样完成的呢?正如你可能猜想的那样,这是用饼干做的。对合法的ACK,确认字段中的值等于 SYNACK字段中的值(现在是cookie值)加上1。服务器将使用源和目的地IP地址和端口号在SYNACK消息节(与初始SYN一样)中,并运行相同的散布函数和秘密数目。如果函数添加1的结果与客户端SYNACK中的确认(cookie)值相同,服务器认为ACK与以前SYN报告段相符,因此它是合法的。服务器与一个接口生成一个完全开放的连接。
• 另一方面,如果客户端不返回ACK声明,初始SYN不会伤害服务器,因为服务器没有分配任何资源给它。

寿命计时器2.7TCP功能

如图所示,TCP服务器如何检测一个TCP客户端故障?

使用保活计时器；

• (一)每当TCP服务器进程接收TCP客户端进程数据时,它重新设置和启动备份计时器(计时2小时);
• (二)在主动计时器的预定期间未收到TCP客户端进程的数据,计时器准备好后,TCP服务器进程向TCP客户端发送检测消息然后每75秒发送一次。 如果在一系列发送的10个检测消息中仍没有TCP客户端进程响应,TCP服务器进程认为TCP客户端进程的主机不正常,然后关闭连接;

2.8显示TCP建立与切断状态图

客户端TCP在启动时处于CLOSED(关闭)状态。客户端应用程序启动新的TCP连接.这使得客户端的TCP向服务器的TCP发送SYN消息。发送SYN声明后,客户端TCP输入了SYN_SENT状态。当客户端TCP处于SYN_SENT状态时,它等待从TCP服务器确认客户端消息字段,SYN位作为一个消息字段。收到 这种 声明 后,客户端进入“建立”状态。处于停滞状态时,TCP客户端可以发送和接收包含有效的负载数据的TCP消息段(即由应用程序层生成的数据)。

假设客户端应用程序决定关闭连接。(请注意,服务器也可以选择关闭连接。这使得客户端TCP发送一个TCP消息,其 FIN位数设置为1,然后输入Fin_WAIT_1状态。在 FIN_WAIT1状态时,客户端TCP等待由服务器确认的TCP消息。当 收到 报告 的 一段 时,客户端TCP输入Fin_WAIT2状态。在 FIN_WAIT 2 状态时,等待服务器 FIN 位的客户端被放置在另一个报告段的1;收到该报告段后,客户端TCP确认服务器的消息部分,然后输入时间等待状态。假定ACK丢失，TIME_WAIT状态返回最终确认消息给TCP客户端。在Time_Wait状态中花费的时间与具体实现有关,典型的值为30秒、1分钟或2分钟。经过等待后，连接就正式关闭，所有客户端资源(包括端口号码)将被释放。

2.8TCP流量控制

我们知道,TCP连接的每个主机都为该连接设置接收缓存.当TCP连接接收正确的、有序的部门时,它将数据输入接收缓冲器。应用程序进程将从缓存中读取数据事实上,接收机应用程序可能忙于其他任务,读取数据可能需要很长时间。如果应用程序读取数据相对缓慢,发送者发送过多,过快,发送的数据很容易溢出连接的接收缓存。

因此TCP向其应用程序提供一个流量控制服务,以消除发送者造成接收者缓存过流的可能性。 因此,交通控制是一个速度匹配服务,即发送者的发送速度与接收者的应用程序的读速度相匹配。 TCP发送器也可能受到IP网络的拥堵;这种形式的发送器控制被称为拥堵控制,虽然交通控制和拥堵控制的行动非常相似(与发送器的拥堵),但它们显然是完全不同的原因采取的措施。

TCP通过允许发送者维护一个叫做接收窗口的变量来提供流量控制。通俗地说，接收窗口用于给发送者指示接收机有多少缓存空间。因为TCP是完全双重通信,两端的发送者都保持一个接收窗口。在文件传输中,我们研究接收窗口.假设主机A通过TCP连接向主机B发送一个大的文件。主机B将接收缓冲器分配给连接,并使用RevBuffer来表示它的大小。主机B上的应用程序过程从时到时从缓存中读取数据。我们定义以下变量：

• LastByteRead:B主机的应用程序进程读取缓存数据流的最后一个字节代码;
• LastByteRcvd:已置于主机B接收器缓存中的网络数据流的最后字节;

由于TCP不允许分配的缓存溢出,必须建立以下公式:

接收窗口由rwnd表示,它根据可用缓冲空间的数量设置:

由于时间和空间不断变化, rwnd是动态的。

将当前rwnd值放在它发送到A、B主机的消息字段的窗口字段中,通知A主机在连接缓存中可用空间的数量。开始时，主机B设置 rwnd = RcvBuffer.为了实现这点，主机B必须跟踪与连接相关的多个变量主机A旋转跟踪两个变量,LastByteSent和 LastByteAcked,这两个变量的意义是显而易见的。注意两个变量 LastByteSent E LastByteAcked之间的区别,它是A主机发送到连接的数据量,但未被确认。通过控制rwnd内未确定的数据量,这确保A主机不会重载B主机接收缓存。因此，主机A 应 在 连接 的 整个 生命 周期 中 确保 :

那么假设主机B的接收缓冲器已经满了,使得rwnd=0。在宣布rwnd=0给主机A后,假设主机B没有发送给主机A的数据。此时，想想可能发生什么事。因为在主机B上的应用程序进程将空缓冲,TCP 不会发送 host A 的新消息段,其中 rwnd 为新值;事实上,TCP只发送消息给A主机,当它有数据或确认发送时。所以主机A不能知道主机B的接收缓冲器有新的空间。即, 主机A被封锁,不能再发送数据!

为了解决这个问题,TCP规范要求: 当主机B的接收窗口为0时,主机A继续发送一个仅发送一个字节的数据消息段。 这些声明将由接收者确认。

如图所示,假设主机A主机B发送以下消息;

根据上文所述,下面的图表显示了一种过程:

2.9TCP拥堵控制

2.9.以三种方式解释交通堵塞的原因和交通堵塞成本(书中解释);

情况一：两个发送者和一个路由器,具有无限缓存;

我们假设A主机的应用程序以平均每秒 λn 字节的速度发送数据到连接(例如通过一个接口传递数据到传输层协议)。这些数据是初始数据,这意味着每个数据元素只能一次发送到插座上。下面的运输层协议是简单的.数据被包装和发送;没有错误恢复(如重新传输),流量控制或拥挤控制。忽略增加运输层和下层标题信息所引起的额外费用,在第一 种情况下，主机A-to-router提供每秒 λn 字节的速度的流量。主机B也同样运作,为了简化问题，我们假设它也以每秒 λin 字节的速度发送数据。自动机A组件和主机B组件通过路由器,分段容量通过R的共享产出链传输。该路由器带有缓存，可以用于存储“人类子群”,当一个子群达到输出链的速度超过输出链的容量时。在此第一种情况下，我们假设路由器有无限缓冲空间.
下面的图表在第一个情况下显示了主机A的连接性能。左边的图显示了每个连接的吞吐量(接收器接收的每秒字节数)和连接的传输速率之间的函数关系。当传输速率介于0和R/2之间,接收器的吞吐量等于发送器的速度,也就是说,所有发送者发送的数据在有限的延迟后到达接收者。然而,当传输速率超过R/2时,它的容量只有R/2。这种吞吐能力是由两个连接之间的共享链路容量引起的。链子完全不能在比R/2的稳态速度下向接收器发送子集。不管东道主A和东道主B的传输率有多高,他们不能看到超过R/2的吞吐量。

取得每个R/2连接的吞吐量实际上看起来是个好事情,因为链被充分利用在交付分组到目的地的过程。但是，图b显示了运行速度接近链的容量的后果。当传输速率接近R/2时(从左到右),平均延迟的时间越来越长。当传输速率超过R/2时,路由器中的平均队列子集将无限增长,源和目的地之间的平均延迟也会变成无限的(假设这些连接运行无限长并且有无限的缓存量)。因此，尽管从吞吐量的角度来看,在接近R的总吞吐量下运行可能是理想的状态,但从时延角度看，但它远远没有理想。即使在这种(极端)理想化中,我们发现拥堵网络的成本,也就是说,当分组到达率接近链的容量时,他们遇到了巨大的队列延迟.

情况二：两台发射器和一个路由器,内存有限

现在我们将在两个方面对第1个情况作一些改变。首先，假设路由器的缓存容量有限。现实世界这一假设的结果是,当一个子组到达一个已经完全的缓存时,它就会被丢弃。其次，我们假设每一个连接都是可靠的。如果包含传输层消息段的子集在路由器中被丢弃,然后最终将重新发送给发件人。因为分组可以重新传输,因此,我们现在需要更仔细地使用传输速度的术语。特别是,我们再次表示每秒 λin 字节是应用程序发送初始数据到插座的速度。传输层向网络发送消息的速率(包含初始数据或重传输数据)是使用的:字节/秒。λ有时被称为网络的传波负载。

首先，考虑到一个不真实的情况,也就是说,主机A可以以某种方式(难以想象!)确定路由器中的缓存是否空,因此,仅当缓存是自由时才发送一个子集。在这种情况下，将不会产生丢包，λin等于 λin',并且连接是等于 λin 。这 是 下面 的 图 a 中 描述 的 。从吞吐量的角度看，性能是理想的，即, 每个发送的子组都是收到的.在这方面注意到,平均主机传输速度不能超过R/2,因为假设不会有群体损失。
然后考虑一个更现实的情况,发送者只在被识别为丢失的子集时重新发送。(同样，所作的假设具有一定的灵活性.然而，发送主机可能设置过时时间足够长,让它不可见,以确保未被确认的小组已经丢失。)在这种情况下，性能可能与下图b所示相似。为了了解当时发生的事情,考虑 Supply load λ'in (初始数据传输 plus the total transmission speed) 等于 R/2。根据下图b所示,在这一供应负荷值下,数据发送给接收者应用程序的速度是R/3。因此，在发送的5R单元数据中,从平均的角度说，每秒0.33R字节是初始数据,每秒0.166R字节是重新传输的数据。这里我们可以看到另一个网络拥堵的成本,也就是说,发送者必须执行重新传输,以补偿因缓存溢出而丢弃(丢失)的子集。最后，我们考虑以下情形: 发送者可能提前加班,以及延迟但没有在队列中丢失的转播组。在这种情况下，初始数据子集和重新传输子集可以到达接收机。当然，接收器只需要一个这样的子组的副本,重传分组将被丢弃。在这种情况下，重新传递的路由器的初始子集拷贝是徒劳的,因为接收者已经收到分组的初始版本。路由器可以利用链路的传输能力发送另一个子集。这里，我们还看到网络拥挤的另一个成本,也就是说,在发送者大量延迟的情况下,不必要重新传输将导致路由器使用其链带宽传输不必要子集拷贝。图c显示,如果每个子集被路由器传送(平均)两次,吞吐量和供电负荷的比较.因为每个分组被发送两次,当其供电负荷接近R/2时,其密度将逐渐接近R/4。

情况三：四台传送器和多个路由器具有有限的缓存和多个跳跃路径

有四个主机发送分组,每一条通过双重叠叠的跳跃路径传送,如图所示。再次,我们假设每个主机使用过时/重传输机制来提供可靠的数据传输服务。所有主机都具有相同的 λ 值,所有路由器的链路容量为每秒R字节。我们考虑从主机A到主机C的连接,连接通过R1和R2路由器。A-C连接和D-B连接共享路由器R1,它也连接到B-D共享路由器R2.对极小的λ值，路由器缓存的溢出是罕见的(如拥挤情况1和拥挤情况2),吞吐量大致等于供电负荷.对于稍大的 λ 值,相应的吞吐量也较大,因为更多的初始数据被发送到网络并交付到目的地,溢出仍然很少。因此，对于较小的λ日，λin的增加会导致 λout的增加。

在考虑非常小流量的情况后,下面是对 λin ( 因此 λin' ) 大时的情况的分析。考虑路由器R2。不管 λm 的值有多大,向路由器R2(路由器R1继电器后向路由器R2的A-C流量)的速率大于R,即,从R1到R2的链容量。如果 λi为所有连接(包括B-D连接)的巨大值,那么在R2上，B-D流量的到达率可能比A-C流量的到达率高得多。因为A-C和B-D的流量必须在路由器R2上竞争有限的缓冲空间,所以当B-D连接的供电负荷增加时,通过R2的成功的A-C连接(即不会因缓存溢出而丢失)越来越少。在极限情况下，当供应负荷接近无限时,R2的空缓存将立即由B-D连接的子组填充,因此,R2上的A-C连接接近0。这又一次说明
在负荷限制下,A-C端到端的吞吐量将接近零。 这些考虑导致了供应负荷和吞吐量之间的差距
的权衡，如图所示。考虑网络浪费的工作量时,由于供应负荷增加,吞吐量最终减少的原因是显而易见的.在上述大流量的情况下,每当第二跳步路由器丢弃一个子集时,第一个跳跃者将团队转移到第二个跳跃者所做的工作是“徒劳”。如果第一个跳跃路由器只是丢弃子组并保持空,网络上的情况很幸运(更确切地说,很糟糕)。需要指出的是，第一个跳跃者用来将一个子集转移到第二个跳跃者使用的传输能力对于不同的子集的转移可能更有效。

从以上知识,我们可以总结交通堵塞控制的原因:

• 在某些情况下,如果网络中的资源需求超过该资源的可用部分,网络性能就会恶化。
• 网络资源包括网络容量(即带宽),计算机网络的交换点的缓存和处理器。
• 如果没有控制的情况下出现拥塞,总网络的吞吐量随着输入负载的增加而减少。

​​

2.9.2拥堵控制方法

四种方法即 slow start congestion 避免快速的重新传输快速的恢复

• 发送者保持一个状态变量,称为拥挤窗口cwnd,其值取决于网络中的拥挤程度,并动态变化。
• 拥挤窗口 cwnd维护原则:只要网络没有拥挤,拥挤窗口就会增加;但是只要网络拥挤,拥挤窗口就会减少。
• 网络拥塞的原因是没有及时的确认消息(即超时再传输)要收到。
• 发送者使用拥挤窗口作为发送窗口swnd,即swnd=cwnd。
• 保持慢启动阈值 ssthresh状态变量:
• 当cwnd < ssthresh时, 使用慢开始算法;
• 当cwnd > ssthresh时，停止使用慢开始算法而改用拥塞避免算法;
• 当cwnd = ssthresh时,可以使用慢启动算法,也可以避免拥挤的冷算法;

它开始缓慢,避免拥挤

当TCP连接启动时,cwnd的值通常最初设置为一个MSS的较小值,这使得初始传输速率接近MSS/RTT。例如，如果MSS=500字节和RTT=200ms,初始传输速率约为20kbps。因为对于TCP发送者来说,可用的带宽可能比MSS/RTT大得多,TCP发送方我们希望尽快找到可用的带宽量.

慢启动:cwnd的值从一个MSS开始,每当传输的消息段第一次确认时,都会增加一个MSS。TCP将第一个消息发送到网络,等待确认。当该确认到达时，TCP发送器将添加一个RMSS到拥挤窗口,并发送两个最大长度消息段。报告 的 两 段 得到 证实,然后发送者将添加一个MSS到每个确认消息节到拥挤窗口,把拥挤窗口改为4个MSS,并这样下去。这个过程每次转会都会发生,发送速率就翻番。因此，TCP传输速度开始缓慢,但缓慢的开始阶段是指数增长。

ssthresh：慢启动阈值;在检测拥挤时重新设置到窗口的一半。

拥塞避免模式：因此,当cwnd值等于 ssthresh时,慢启动结束,TCP将转移到避免拥堵模式。

假设初始如图所示：

2.9.4快速重传和快速恢复

• 有时,在网络中单独的段落会丢失,但实际上网络并不拥挤。 (这会使发送者重新传输超时,误以为网络已经拥挤;
• 发送者重新设置了拥挤窗口的最低值为1,并且错误地启动了慢启动算法,从而降低了传输效率。

快速重传算法允许发送者尽可能早地知道消息的各个段落的丢失发生。

• 所谓快速重传输是让发送者尽可能快地进行重传输,而不是等待超时重传输计时器重新传输。
• 要求接收者不要等待数据发送,而是立即发送确认;
• 即使 收到 的 段落 不符 合 时, 应 立即 重新 确认 收到 的 段落 。
• 一旦发件人收到三次连续的重复确认,则该消息的相应部分立即重新发送,而不是等待该部分消息的超时再发送者重新发送

快重传：当出现超时时，TCP拥堵避免了相同的算法行为。跟慢启动一样,当数据包丢失时,cwnd的值设置为1MSS,ssthresh值更新为cwnd值的一半。然而，前面提到的丢失事件也可以由三个冗余的ACK事件触发。在这种情况下，网络继续从接收者发送消息段(如 redundant ACK 接收的指示)。因此,TCP对这个数据包丢失事件的行为,与包装的加班指令相比,不应如此剧烈:TCP将cwnd值降低一半(为了提高测量结果,增加三个MSS到三个冗余的ACK),当三个冗余的ACK被接收时, ssthresh的值记录为cwnd的一半。下一步是进入快速恢复模式。
快恢复： 在快速恢复中，对于导致TCP输入快速恢复状态的缺失消息段,对于每个冗余的ACK接收, cwnd的值增加了一个MSS。最终，当ACK到达缺失消息段时,在减少交通堵塞后,TCP能够避免交通堵塞.如果出现超时事件，在执行慢启动和避免拥挤的动作后快速恢复,进入慢启动状态:当发生包丢失事件时,cwnd的值设置为一个MSS, ssthresh的值设置为cwnd的一半。快速恢复是TCP推荐的,而不是必要的组成部分。TCP的早期版本叫做TCPTahoe,是否存在过时指示包装事件,ACK指出还有三个冗余的包丢失事件,所有无条件地将交通拥挤的窗口减少到一个MSS,并进人慢启动阶段。新版本的TCP,TCP Reno,结合快速恢复。

2.10TCP超时再传输的时间选择

2.10.超时转播的极端情况

我们知道,TCP协议已经通过超时/重传处理报告段落丢失的机制虽然从概念上来说很简单,但在执行超时/重传输机制时,如TCP等实时协议时,会出现许多微妙的问题。

RTT：实例RTT是发送消息(即给IP)和接收消息的确认之间的时间。

情况一：如图所示,RTT时间(overtime retransmission time)比RTT时间少,不需要重发消息;

情况二： RTO(超时再传输时间)比RTT时间长得多,如图所示,再传输时间太长,因此网络自由时间增加;

问题：这个间隔应该有多大?我应该在开始时如何估计返回时间和返回时间? 是否应该为所有未识别的报告段落设置计时器?

2.10.1往返时间估计数及加班费

大多数TCP实现只一次测量一个RTT(样品RTT)。而不是测量每个发送消息段的RTT.这就是说，在任意时刻，估计只发送但尚未确认消息段的RTT,这将生成一个新的RTT值,接近每个RTT。另外，TCP从不计算再传输的消息段的RTT;它只测量一次传输的消息段。
由于路由器拥挤和终端系统负载的变化,这些段落的RTT值将相应波动。由于这种波动，任何给定的RTT值可能不是典型的。因此，为估计一个典型的RTT,采用某种平均的方法来处理转帐.TCP 保持 RTT 的统一值.一旦你得到新的RTT,TCP将根据以下公式更新RTT:

• 如果 a 非常接近 0, 新 RTT 样本对 RTT 产生较小的影响;
• 如果 a 非常接近 1, 新 RTT 样本 对 RTT 的 影响 更大;

新RTT值是以前RTT值和新RTT值的组合。[RFC 6298]中的a值为α=0.125(即 1/8);

RFC6298建议使用以下计算:

我们 可以 看到, RRTT 和 RRTTd 都 与 新 的 RRTT 样本 有关 ; 但 也 发生 了 下列 两 个 情况 :

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