获取中...

-

Just a minute...

《计算机网络自顶向下方法》第三章读书笔记

概述和运输层服务

传输层位于应用层和网络层之间,是分层的网络体系结构中重要的部分,该层为运行在不同主机上的应用进程提供直接的通信服务起着至关重要的作用

1.网络层提供了主机之间的逻辑通信,运输层为在不同主机上的进程之间提供了逻辑通信。

2.运输层协议只在主机起作用,运输层能够提供的服务受制于网络层协议的服务模型

3.网络应用可以使用多种传输层协议,因特网有两种传输层协议,即TCP和UDP,不同的传输层协议提供不同的运输层服务

运输层和网络层的关系

1.网络层提供了主机 之间的逻辑通信。而运输层为运行在不同主机上的进程 提供逻辑通信。

2.运输层协议只工作在端系统上

3.运输协议能提供的服务受制于底层网络协议的服务模型,如果网络层协议无法为主机之间的通信提供时延和带宽保证的话,运输层协议也就无法为进程之间发送的应用程序报文提供时延或者带宽保证

4.网络层协议,即 IP 协议,其服务模型是 尽力而为交付服务 ,但不做任何的保证。是 不可靠服务

解释运输层和网络层关系:

  • 运输层服务受制于网络层服务: (邮政大哥若三天来一次,Ann和Bill就不可能两天收发一次信)

  • 多种运输层协议,多种服务模型: (Ann 和 Bill 外出,Susan 和 Harvey来收信发信,结果年龄太小,收发邮件次数少,也老丢信)

  • 运输层协议能为应用程序提供可靠数据传输服务:(若邮政大哥把信弄脏弄丢弄混,Ann 和 Bill 可以清理整理信件,或者让对方下次重新发一次)

  • 运输层协议能确保应用程序报文不受入侵读取:(尽管邮政大哥可能被别人骗或者强行看了信件,Ann 和 Bill 也能规定加密方式对信的内容进行加解密,弟弟妹妹们只需要看信的内容)

  • 多路分解: Bill 和 Ann从邮递大哥拿到信件,看收信人名字(端口号),然后分别交到他们手上

  • 多路复用: Bill 和 Ann从弟弟妹妹手里拿到信件,帮他们装填信封写上信息

因特网运输层概述

1.UDP(用户数据报协议) 提供了一种不可靠、无连接的服务。

2.TCP(传输控制协议) 提供了一种可靠的、面向连接的服务。

3.进程到进程的数据交付和差错检测是两种最低限度的运输层服务,也是 UDP 能提供的仅有的两种服务

4.运输层分组也被称为报文段

5.UDP和TCP最基本的责任就是将IP提供的主机间交付服务扩展到不同端系统上两个个进程之间的服务。这也被称为传输层的多路分解和多路复用

多路复用和多路复解

多路分解: 将运输层报文段中的数据交付到正确的套接字。

多路复用: 在源主机从不同的套接字中收集数据块,并为每个数据块封装上首部信息从而生成报文段,然后将报文传递到网络层。

运输层多路复用要求:

①套接字有唯一标识符。

②每个报文段有特殊字符(端口号)来指示该报文段所要交付到的套接字。

端口号: 一个 16 比特的数,在 0 ~ 65535 之间。其中 0 ~ 1023 是周知端口号,是受限制的。

无连接的多路复用和多路分解:

创建UDP套接字:

①用 clientSocket = socket(socket.AF_INET, socket.SOCK_DGRAM)创建一个 UDP 套接字时,系统会自动为该套接字分配一个未被其他 UDP 套接字使用的端口号。

②用clientSocket.bind(('',23333)) 显式的分配一个端口号。

  • 通常,应用程序的客户端让运输层自动地分配端口号,而服务器则分配一个特定的端口号
  • 一个 UDP 套接字由(目的IP地址,目的端口号)标识。注意是用来标识,不是只有这两个相关字段,还有源端口号、源IP地址字段。源端口号和目的端口号按传递方向反转

面向连接的多路复用和多路分解

  • TCP 套接字是由一个四元组(源 IP 地址,源端口号,目的 IP 地址,目的端口号)来标识的
  • TCP服务器在12000端口listen,TCP客户创建一个套接字并发送一个连接建立请求报文段,当服务器接收到该请求时,服务器会定位12000端口等待的进程并为其创建一个套接字,用[源IP,源端口,目的IP,目的端口]来标识,则可以建立与源端口的连接。服务器主机可以支持很多并行的TCP套接字,每个套接字与一个进程连接,从而提供并行的服务。当今高性能的服务器通常只有一个进程,而是为每个新客户连接创建一个具有新套接字的线程。

无连接运输UDP

选择UDP的原因:

①关于何时、发送什么数据的应用层控制更为精细。

②UDP无需建立连接。 TCP数据传输之前会经过三次握手,UDP不需要准备就能传输数据,UDP不会引入建立连接的时延

③无连接状态。 TCP需要在端系统维护连接状态

④分组首部开销小。 只有8个字节,比TCP的20个字节的首部要短

  • UDP支持一对一、一对多、多对一、多对多的交互通信
  • UDP没有拥塞控制,对于实时应用很有效。
  • UDP是面向报文的,对应用程序交下来的报文,在添加首部之后直接交付给IP层。应用层交给UDP多长的报文,UDP就照样发送,即一次发送一个报文
  • UDP使用最大努力交付,不保证可靠交付。

UDP报文段结构

  • UDP首部只有4个字段,每个字段占用两个字节,分别是:源端口号、目的端口号、长度和校验和
  • 长度表示包含首部在内的UDP报文段长度,以字节为单位

UDP检验和

IP数据报的检验和只检验IP数据报的首部,但是UDP的检验和是把首部和数据部分一起都检验。

检验方法:

①将 UDP 报文按 16 比特进行分组。

②将两个 16 比特的数字相加得到一个 32 位的数。

③将 2 中得到的 32 比特数的 高 16 位和低 16 相加。

④重复第 2 步直到得到的和的高 16 位为 0。

⑤将得到的 16 比特的数按位取反即为 检验和。

注:计算之前的检验和为 0

如果传输没有出错,则在接收方处计算的的检验和将是 11111111111111。若不是,则数据有错。

可靠数据传输原理

可靠数据传输协议(reliable data transfer protocol)。由于可靠数据传输协议的下层协议也许是不可靠的,因此这是一项困难的任务。
单向数据传输(unidirectional data transfer)即数据传输是从发送端到接收端的。

双向数据传输(bidirectional data transfer)(即全双工数据传输)

可靠数据传输协议往往建立在不可靠IP网络层协议之上。

TCP发送的报文段是交给IP层传送的。但IP层只能提供尽最大努力服务,也就是说TCP下面的网络所提供的是不可靠的传输。因此,TCP必须采用适当的措施才能使得两个传输层之间的通信变得可靠。

可靠数据传输为上层实体提供的服务抽象是:数据可以通过一套可靠的信道进行传输,借助于可靠信道,传输数据就不会受到损坏或者丢失;并且所有数据都可以按照其发送顺序进行交付。而这正是TCP向调用它的应用所提供的服务模型

单方向的可靠数据传输流程大概是这样的:可靠数据传输->不可靠数据传输->不可靠的传输信道->可靠数据接收->上传Data

构造可靠数据传输协议

经完全可靠信道的可靠数据传输:rdt1.0

底层信号完全可靠,然而这在实际中不能实现

有限状态机(FSM):

箭头指示了协议从一个状态变迁到另一个状态

引起变迁的事件显示在横线的上方。

事件发生时所采取的动作显示在横线的下方。

^ 表示什么都不做。

FSM初始状态用虚线表示

发送方:

rdt_send(data): 接收较高层的数据。

make_pkt(data): 将数据打包成分组。

udt_send(packet): 将分组发送到信道中。

接收方:

rdt_rcv(data): 从底层信道接收一个分组。

extract(packet,data): 从分组中取出数据。

deliver_data(data): 将数据传送给较高层

经具有比特差错信道的可靠数据传输:rdt 2.0

底层信道传输的数据可能会有比特差错。但是仍然不会丢包
自动重传请求协议(ARQ)当发送方处于等待 ACK 或 NAK 的状态时,它不能从上层获得数据

三种协议功能来处理存在比特差错的情况

差错检测

接收方反馈

肯定确认(ACK)

否定确认(NAK)

重传

接收到有差错的分组时,发送方重传该分组。

停等协议

所谓停等协议是指发送方发送完分组A后,需要等待接收方对分组A的反馈分组,如果收到肯定分组,那么就发送下一个分组;如果收到否定分组,那么就重新发送当前分组;值得注意的是,有些协议中只有肯定分组,肯定分组包含一个分组号K,表示标号为K的分组已经收到,发送方可以发送标号为K+1的分组;如果发送方此时等待的正好是对K的确认分组,那么发送方就会发送标号为K+1的分组;如果发送方接收到对K-1的确认,表示接收方并没有收到编号为K的分组,需要重发;另外,停等协议中只需要一个定时器用来监听超时事件
简单来说,停等协议就是要等到上一个分组得到正确接收的确认后才能处理下一个分组。它存在一个致命的缺陷。尤其是我们没有考虑到ACK或NAK分组受损的可能性。

考虑处理受损ACK和NAK的3种可能性


    第一种:接收方对受损的ACK或NAK继续做错误反馈,由于发出的错误反馈可能再次受损,这样就有可能进入死循环。

    第二种:增加足够的检验和比特,使发送方不仅可以检测差错,还可以恢复差错。对于会产生差错但不丢失分组的信道,这就可以直接解决问题。

    第三种:当接收方收到含糊不清的ACK或NAK分组时,只需重传当前数据分组即可。这种方法在发送方到接收方的信道中引入了冗余分组(duplicate packet)。冗余分组的根本困难在于接收方不知道他上次所发送的ACK或NAK是否被发送方正确的收到。因此他无法事先知道接收到的分组是新的还是一次重传。

    对于第三种情况,解决这个新问题的的简单方法是在数据分组中添加一新字段,让发送方对其数据分组编号,即将发送数据分组的序号(sequence number)放在该字段。

经具有比特差错的丢包信道的可靠数据传输:rdt3.0(比特交替协议)

  • 发送方负责检测和回复丢包工作,对每一个分组维护一个定时器。如果在一个时间段内没收到ACK,则判定为丢包,重传分组,这也引入了冗余数据分组的可能性(时延很大的情况)

  • 检测丢包的方法:倒计数定时器用于实现基于时间的重传机制

  • 总结可靠传输需要的技术:检验和、序号、定时器、肯定和否定确认分组

流水线可靠数据传输协议

dt 3.0 是一个功能正确的协议,但是由于它是一个停等协议,大部分的时间都浪费在等待确认上面,所以性能不好。

解决这种特殊性能问题的一个简单的方法是:不使用停等方式运行,允许发送方发送多个分组而无需等待确认。这种技术被称为 流水线。
要使用流水线技术,则须:

①增加序号范围。因为要传送多个分组,而每个传输中的分组必须有一个单独的序号。

②协议的发送方和接收方两端必须能缓存多个分组。发送方至少得能缓存那些已发送但未确认的分组,而接收方或许也需要缓存那些已经正确接收的分组。
所需序号的范围和对缓冲的要求取决于数据传输协议如何处理丢失、损坏及延时过大的分组。

③流水线的差错恢复有两种基本方法:

  • 回退 N 步

  • 选择重传

回退n步

回退N步(GBN):允许发送端发送多个分组,但在流水线中未被确认的分组数不能大于N,N被称为窗口长度,GBN协议也被称为滑动窗口协议。如果出现超时,发送方会重传所有已发送但未被确认的分组,即回退N步,从而保证接收端可以按序将数据交付给上层。

  • 基序号(base)为最早的未确认分组的序号。
  • 下一个序号(nextseqnum)为下一个待发分组的的序号。
  • N 常被称为 窗口长度,GBN 协议也常被称为 滑动窗口协议。
  • GBN 的发送方必须响应三种类型的事件:

①上层的调用:若窗口未满,则产生一个分组将其发送

②收到一个 ACK:对序号为 n 的分组的确认采取 累积确认,表明接收方已正确接收到包括 n 的序号在内的 n 的以前的所有分组

③超时事件:只使用一个定时器,即最早的已发送但未被确认的分组所使用的定时器。如果出现超时,则发送方重传所有已发送但还未被确认的分组。如果收到一个 ACK,但仍有已发送但未被确认的分组,则重启定时器。如果没有已发送但未确认的分组,该定时器被终止

GBN正常传输:

GBN丢失帧

选择重传

选择重传(SR):GBN中单个分组的错误会引起重传大量分组。选择重传协议通过让发送端仅重传那些它怀疑在接收方出错的分组。

发送方需要响应的时间有三个

  • 上层调用:基本上同GBN一致;
  • 收到ACK:如果该分组号在base-next sequence-1之间,将其标记为已到;如果等于base,则移动窗口到最下的待确认的分组序号处;在GBN中,接收方根本不会收到非base的ACK,但是怎么收,还的看怎么发;
  • 超时事件:同GBN不一样的是,选择重传需要为每一个分组建立一个定时器,如果某个已发送但未被确认的分组超时,发送方重发该分组;

SR 接收方的事件与动作:

  • 序号在 [rcv_base, rcv_base + N -1] 内的分组被正确接收:在此情况下,收到的分组落在接收方的窗口内,一个选择 ACK 被回送给发送方。如果该分组以前没收到过,则缓存该分组。如果该分组的序号等于接收窗口的基序号,则该分组及以前缓存的序号连续的分组交付给上层。
  • 序号在 [rcv_base - N, rcv_base - 1] 内的分组被正确接收: 产生一个 ACK,即使该分组是接收方以前已确认过的分组。
  • 其他情况:忽略该分组。

面向连接的运输TCP

TCP是因特网运输层的面向连接的可靠的运输协议

  • TCP是面向连接的

通信前需要建立连接,通信结束需要释放连接。

  • TCP提供全双工通信

TCP的两端既可以作为发送端,也可以作为接收端

  • TCP提供可靠交付服务

TCP发送的数据无重复、无丢失、无错误、与发送端顺序一致。

  • TCP是面向字节流的

TCP以字节为单位。虽然传输的过程中数据被划分成一个个数据报,但这只是为了方便传输,接收端最终接受到的数据将与发送端的数据一模一样。

  • 一条TCP连接的两端只能有两个端点

TCP只能提供点到点的通信,而UDP可以任意方式的通信。

TCP连接

  • 由于 TCP 协议只在端系统中运行,而不在中间的网络元素(路由器和链路层交换机)中运行,所以中间的网络元素不会维持 TCP 连接状态,不会为该连接分配任何缓存和变量。其连接状态完全保留在两个端系统中。
  • TCP 建立连接需要 三次握手,其中,前两次握手不承载”有效荷载“,第三次握手可以承载有效荷载。
  • 通过套接字发送数据

  • TCP 将数据引导到该连接的 发送缓存 里,接下来 TCP 就会不时地从发送缓存里取出一块数据。

  • TCP 可从缓存中取出并放入报文段的数据数量受限于 最大报文段长度(MSS)。该长度是指报文段里应用层数据的最大长度,而不是包括 TCP 首部的 TCP 报文段的最大长度

TCP报文段结构

  • 16 比特的 源端口号 和 16 比特的目的 端口号 。用于多路分解和多路复用。

  • 32 比特的 序号(sequence number) 字段。 一个报文段的序号 是该报文段数据字段首字节的序号。

  • 32 比特的 确认号(Acknowledgement number) 字段。主机 A 填充进报文段的确认号是主机 A 期望从主机 B 收到的下一字节的序号

  • 16 比特的 接收窗口(Receive window) 字段。用于指示接收方愿意接收的字节数量。

  • 4 比特的 首部长度(header length) 字段。指示了以 32 比特的字为单位的 TCP 首部长度。

可变与变长的 选项(options) 字段。用于发送方与接收方协商最大报文段长度时,或在高速网络环境下作用窗口调节因子时使用。

  • 6 比特的 标志(flag) 字段。
    ACK 是对成功接收一个报文段的确认。
    RST、SYN 和 FIN 用于连接的建立和拆除。
    PSH 被设置时,指示接收方应立即将数据交给上层。
    URG 比特用来指示报文段里存在着被发送端上层实体置为“紧急”的数据。紧急的最后一个字节由 16 比特的 紧急数据指针(Urgent data pointer)字段 指出。
  • 检验和,2字节;紧急指针,2字节

序号和确认号: TCP把数据看做有序无结构的字节流,用序号对每个传输的字节进行编号。由于TCP是全双工服务,在主机A向主机B发送报文的同时A也会接收B发送的报文,确认号则是接收方希望发送方发送的下一字节的序号。例如A已收到B发送的序号为0-535的所有字节,则A会在发给B的报文段的确认号中填入536。如果A在收到536-899之前收到900-1000,则确认号仍为536,这叫TCP的累积确认。

往返时间的估计和超时

估计往返时间:

报文段的样本RTT:SampleRTT

SampleRTT 均值:EstimatedRTT

EstimatedRTT=0.875∗EstimeatedRTT+0.125∗SampleRTT

设置和管理超时重传时间 :

TimeoutInterval=EstimatedRTT+4∗DevRTT

超时间隔 = 估计RTT + 4*偏差RTT

设置TCP超时值:

应大于RTT:但RTT是变化的

太短: 过早超时,不必要的重传

太长: 对报文段的丢失响应太慢

TCP采用超时/重传机制处理报文段丢失

可靠数据传输

网络层传输的数据单元为数据报 ,传输层的数据单元为报文段 ,为了方便起见可以统称为分组

TCP 发送方

TCP 发送方有三个与发送和重传有关的事件:

①从上层应用程序接收数据

②定时器

③收到 ACK

三种情况:

①A向B发送一个报文段,序号92,包含8字节,交给IP后开始等待一个来自B的确认号为100的报文段。然而确认报文段丢失,超时,A又重发相同报文段。B收到后对比序号发现已经收到过该报文段的一些字节,于是B的TCP确认后,将报文段重复的字节丢弃

②A连续发了两个报文段,92,8和100,20(序号和字节)。B收到两个报文段并发送确认100和200。超时前没有一个确认到达A,超时后A重传92,8的报文,重启定时器。只要第二个报文的ACK在新的超时以前发生到达,第二个报文就不会重传。

③和上面一种一样,A发送两个报文段,第一个报文段的确认在网络丢失,但是超时之前收到了第二个报文段的确认报文。因为累积确认机制,A知道B已经收到第二个以及之前的报文,不会重传了

快速重传

超时间隔加倍会增加端到端时延。而由于接收端累积确认,在未收到期望序号报文段时会不断的发送相同的ACK确认号,此为冗余ACK。当接收端收到3个冗余ACK时,TCP就执行快速重传,在定时器过期前重传丢失的报文段。

  • TCP 接收方的 ACK 接收策略

###回退N步还是选择重传

  • TCP确认是累积式的,正确接收但失序的报文段是不会被接收方逐个确认的,像GBN风格,但是TCP和GBN有显著区别
  • 许多TCP实现会将正确接收但失序的报文段缓存起来
  • GBN不仅重传未确认分组,还会重传之后所有分组,TCP只传一个或不传(若其后面的ACK超时前到来)
  • 选择确认,允许接收方有选择地确认失序报文段,而不是累积确认最后一个正确接收的有序报文段。该机制与选择重传机制结合(跳过重传已确认报文段),TCP看起来像SR
  • TCP的差错恢复机制是GBN协议和SR协议的混合体

流量控制

  • 什么是流量控制?

如果发送者发送过快,接收者来不及接收,那么就会有分组丢失。为了避免分组丢失,控制发送者的发送速度,使得接收者来得及接收,这就是流量控制。
流量控制是一个速度匹配服务,发送方发送速率与接收方程序读取速率相匹配

  • 流量控制的目的?

流量控制根本目的是防止分组丢失,它是构成TCP可靠性的一方面。

  • 如何实现流量控制?

由滑动窗口协议(连续ARQ协议,如GBN和SR)实现,TCP让发送方维护一个称为接收窗口rwnd的变量,用于给发送方指示接收方还有多少可用缓存。因为是全双工通信,双方都维护接收窗口变量。B把rwnd值放入给A的报文段接收窗口字段中,通知A自己还有多少缓存空间,A控制未确认的数据量小于rwnd,即发送方的发送窗口不可以大于接收方发回的窗口大小。

滑动窗口协议既保证了分组无差错、有序接收,也实现了流量控制。

  • 流量控制引发的死锁

考虑一种特殊的情况,就是接收方若没有缓存足够使用,就会发送零窗口大小的报文,此时发送放将发送窗口设置为0,停止发送数据。之后接收方有足够的缓存,发送了非零窗口大小的报文,但是这个报文在中途丢失的,发送者一直等待下去,而接收者以为发送者已经收到该应答,等待接收新数据,这样双方就相互等待,从而产生死锁。

  • 持续计时器

为了避免流量控制引发的死锁,TCP使用了持续计时器。每当发送者收到一个零窗口的应答后就启动该计时器。时间一到便主动发送报文询问接收者的窗口大小。若接收者仍然返回零窗口,则重置该计时器继续等待;若窗口不为0,则表示应答报文丢失了,此时重置发送窗口后开始发送,这样就避免了死锁的产生。

  • 一条TCP连接每一侧主机都设置了缓存,当TCP连接收到正确有序的字节后,将数据放入缓存,应用从缓存中读取。若应用较忙,发送方发送太快太多,可能会造成缓存溢出

  • TCP发送方因为IP网络的拥塞而降速(超时间隔加倍),属于拥塞控制,不属于流量控制,虽然都是降速

  • UDP无流量控制,缓存溢出就溢出了

TCP连接管理

TCP三次握手

TCP协议中,主动发起请求的一端称为客户端,被动连接的一端称为服务端。不管是客户端还是服务端,TCP连接建立完后都能发送和接收数据。起初,服务器和客户端都为CLOSED状态。在通信开始前,双方都得创建各自的传输控制块(TCB)。 服务器创建完TCB后遍进入LISTEN状态,此时准备接收客户端发来的连接请求。

第一次握手:

客户端向服务端发送连接请求报文段。该报文段的头部中SYN=1,ACK=0,seq=x。请求发送后,客户端便进入SYN-SENT状态

PS1:SYN=1,ACK=0表示该报文段为连接请求报文。

PS2:x为本次TCP通信的字节流的初始序号。

TCP规定:SYN=1的报文段不能有数据部分,但要消耗掉一个序号。

第二次握手:

服务端收到连接请求报文段后,如果同意连接,则会发送一个应答:SYN=1,ACK=1,seq=y,ack=x+1。

该应答发送完成后便进入SYN-RCVD状态。

PS1:SYN=1,ACK=1表示该报文段为连接同意的应答报文。

PS2:seq=y表示服务端作为发送者时,发送字节流的初始序号。

PS3:ack=x+1表示服务端希望下一个数据报发送序号从x+1开始的字节

第三次握手:

当客户端收到连接同意的应答后,还要向服务端发送一个确认报文段,表示:服务端发来的连接同意应答已经成功收到。

该报文段的头部为:ACK=1,seq=x+1,ack=y+1。

客户端发完这个报文段后便进入ESTABLISHED状态,服务端收到这个应答后也进入ESTABLISHED状态,此时连接的建立完成!

三次握手后:

发送方通过套接字向TCP的发送缓存中传输数据,当数据达到最大报文段长(MSS)时TCP就将缓存加上一个TCP首部形成报文段发送给接收方的TCP接收缓存。

为什么连接建立需要三次握手,而不是两次握手?
防止失效的连接请求报文段被服务端接收,从而产生错误。
失效的连接请求:若客户端向服务端发送的连接请求丢失,客户端等待应答超时后就会再次发送连接请求,此时,上一个连接请求就是失效的。
若建立连接只需两次握手,客户端并没有太大的变化,仍然需要获得服务端的应答后才进入ESTABLISHED状态,而服务端在收到连接请求后就进入ESTABLISHED状态。此时如果网络拥塞,客户端发送的连接请求迟迟到不了服务端,客户端便超时重发请求,如果服务端正确接收并确认应答,双方便开始通信,通信结束后释放连接。此时,如果那个失效的连接请求抵达了服务端,由于只有两次握手,服务端收到请求就会进入ESTABLISHED状态,等待发送数据或主动发送数据。但此时的客户端早已进入CLOSED状态,服务端将会一直等待下去,这样浪费服务端连接资源。

四次挥手:

第一次挥手:

若A认为数据发送完成,则它需要向B发送连接释放请求。该请求只有报文头,头中携带的主要参数为:

FIN=1,seq=u。此时,A将进入FIN-WAIT-1状态。

PS1:FIN=1表示该报文段是一个连接释放请求。

PS2:seq=u,u-1是A向B发送的最后一个字节的序号。

第二次挥手:

B收到连接释放请求后,会通知相应的应用程序,告诉它A向B这个方向的连接已经释放。此时B进入CLOSE-WAIT状态,并向A发送连接释放的应答,其报文头包含:

ACK=1,seq=v,ack=u+1。

PS1:ACK=1:除TCP连接请求报文段以外,TCP通信过程中所有数据报的ACK都
为1,表示应答。

PS2:seq=v,v-1是B向A发送的最后一个字节的序号。

PS3:ack=u+1表示希望收到从第u+1个字节开始的报文段,并且已经成功接收
了前u个字节。

A收到该应答,进入FIN-WAIT-2状态,等待B发送连接释放请求。

第二次挥手完成后,A到B方向的连接已经释放,B不会再接收数据,A也不会再发送数据。但B到A方向的连接仍然存在,B可以继续向A发送数据。

第三次挥手:

当B向A发完所有数据后,向A发送连接释放请求,请求头:FIN=1,ACK=1,seq=w,ack=u+1。B便进入LAST-ACK状态。

第四次挥手:

A收到释放请求后,向B发送确认应答,此时A进入TIME-WAIT状态。该状态会持续2MSL时间,若该时间段内没有B的重发请求的话,就进入CLOSED状态,撤销TCB。当B收到确认应答后,也便进入CLOSED状态,撤销TCB。

拆除过程

①(客户端关闭)客户TCP发送一个特殊报文段到服务器,该报文段中FIN位被置1;

②服务器收到后向发送方回送一个ACK报文段;

③(服务器端关闭)服务器端发送FIN报文段给客户端;

④客户端发送ACK对该报文段进行确认;

拥塞控制原理

在计算机网络中的链路量(即带宽)、交换结点中的缓存和处理机制等,都是网络的资源。在某段时间,若对网络中某一资源的需求超过了该资源所能提供的可用部分,网络性能就要变坏。这种情况就叫做拥塞

拥塞原因和代价

计算机网络拥塞的原因是因为网络中的分组太多,而链路带宽和路由器缓存容量都是有限的

  • 情况一:两个发送方和一台无穷大缓存的路由器

容量为R的共享式输出链路上传输

当发送速率超过R/2时,路由器的排队分组就会无限增加,源和目的平均时延变成无穷大

  • 情况二:两个发送方和一台有限缓存的路由器

分组到达一个已满的缓存时会被丢弃,发送方必须执行重传以补偿因为缓存溢出丢弃的分组

发送方遇到高时延时,进行的不必要重传引起路由器转发不必要的分组副本

  • 情况三:4个发送方和具有优先缓存的多台路由器及多条路径

当一个分组沿一条路径被丢弃时,每个上游路由器用于转发该分组到丢弃该分组使用的传输容量被浪费

拥塞控制 和 流量控制 的区别

拥塞控制:拥塞控制是作用于网络的,它是防止过多的数据注入到网络中,避免出现网络负载过大的情况;

流量控制:流量控制是作用于接收者的,它是控制发送者的发送速度从而使接收者来得及接收。

拥塞控制的目的

缓解网络压力

保证分组按时到达

拥塞控制的方法

①端到端拥塞控制,网络层并没有为运输层的拥塞控制提供支持,TCP运用的方式,只能推断是否发生拥塞。

②网络辅助的拥塞控制,路由器可以向发送端反馈网络的拥塞情况,但还未被用于TCP中。

TCP拥塞控制(加性增、乘性减(AIMD)拥塞控制方法)

TCP必须用端到端拥塞控制,因为IP层不向端系统提供显式网络拥塞反馈

TCP让每一个发送方根据感知到的拥塞程度限制其发送速率

限制速率

①维护拥塞窗口cwnd值(注意流量控制使用接收窗口rwnd值)

②发送方未确认数据量 <= min { cwnd , rwnd }

感知是否存在拥塞

丢包:超时或收到3个冗余ACK

TCP发送方如何确定发送速率

1.一个丢失的报文意味着拥塞,当丢失报文段时应当降低速率(当前速度不能正常交付,得慢点)

2.先前未确认报文段的确认到达时,增加发送方速率(当前速度能够正常交付,说明可以再快点)

3.带宽探测(试探):TCP发送方增加速率,丢包,从该速率后退,再往前探测….(因为拥塞情况是波动的,得尽力保持在最高速率)

TCP拥塞控制算法

慢启动算法拥塞避免算法

  • 发送方维护一个发送窗口,发送窗口的大小取决于网络的拥塞情况和接收窗口的大小,发送窗口是动态变化的。

  • 发送方还维护一个慢启动门限

发送窗口 < 慢启动门限:使用慢启动算法

发送窗口 > 慢启动门限:使用拥塞避免算法

发送窗口 = 慢启动门限:使用慢启动算法或拥塞避免算法

  • TCP拥塞控制算法:慢启动,拥塞避免,快速恢复

慢启动

  • 一开始cwnd只设为一个MSS的较小值(这就是『慢』,不过瞬间指数级加速

  • 收到一个确认,cwnd增加一个MSS ——> 每过一个RTT,cwnd翻番,发送速率翻倍(1,2,4…每次发的也多一个)

  • 丢包(拥塞)结束慢启动

①将ssthresh(慢启动阈值)设置为cwnd/2,cwnd置为1重新开始慢启动

②当cwnd=ssthresh时,结束慢启动,TCP转移到拥塞避免模式

③收到3个冗余ACK,执行快速重传,进入快速恢复模式

拥塞避免

  • 进入拥塞避免状态,cwnd值是上次遇到拥塞时的一半

  • 每个RTT只将cwnd值增加一个MSS/cwnd字节

  • 丢包,结束拥塞避免

  • 超时:ssthresh更新为cwnd的一半,cwnd置为1个MSS,返回慢启动状态

冗余ACK:ssthresh更新为cwnd的一半,cwnd值减半,进入快速恢复状态

快速恢复

  • 快速恢复中,每个冗余ACK,cwnd 增加一个MSS,当丢失报文的ACK到达时,TCP降低cwnd,进入拥塞避免状态

  • 超时:同慢启动和拥塞避免

公平性

在K条TCP连接经过传输速率为R的链路时,如果每条连接的平均传输速率接近R/K,则认为该拥塞控制是公平的。在每条TCP连接的RTT相等的情况下,TCP拥塞控制是公平的,但实际中RTT小的连接会有更高的吞吐量。

相关文章
评论
分享
  • 计算机网络中的安全

    《计算机网络自顶向下方法》第八章读书笔记 什么是网络安全安全通信具有下列所需要的特性: 机密性。仅有发送方和希望的接收方能够理解传输报文的内容。因为窃听者可以截获报文,这必须要求报文在一定程度上进行加密,是截取的报文无法被截获者所...

    计算机网络中的安全
  • 无线网络和移动网络

    《计算机网络自顶向下方法》第七章读书笔记 概述 基站 是无线网络基础设施的一个关键部分。基站在有线网络中没有明确的对应设备,它负责向与之关联的无线主机发送数据和从主机那里接收数据。基站通常负责协调与之相关联的多个无线主机的传输。当...

    无线网络和移动网络
  • 链路层和局域网

    《计算机网络自顶向下方法》第六章读书笔记 链路层信道分为两种: 广播信道:局域网,无限LAN,卫星和混合光纤 点对点的通信链路 链路层的概念运行链路层协议的任何设备称为节点。把沿着通信路径连接相邻节点的通信信道称为链路 链路层采取...

    链路层和局域网
Please check the parameter of comment in config.yml of hexo-theme-Annie!