【计算机网络自顶向下第三章运输层笔记】

计算机网络自顶向下第三章运输层笔记
哼哼

来自本人三四月份摸鱼边读边玩的成果记录，其中还有昆明ACM和蓝桥，记录计网成长，但愿自己是真的读进去了并且记在脑子里面，以后还是要多多复习和多多看书!!!

2.28第三章121-125

1.因特网协议：TCP,UDP运输层协议。

2.运输层协议为运行在不同主机上的进程之间提供了逻辑通信。进程使用逻辑通信通过路由器和不同类型链路相连彼此发送报文，无需考虑设施细节。

3.运输层协议在端系统中实现。在发送端运输层将报文转换成运输层分组，该分组称为运输层报文段。可能的实现方法是：将报文划分为小块，为每块加上一个运输层首部生成报文段。在发送端系统中，运输层将报文段传递给网络层，网络层将其封装成网络层分组（数据报）向目的地发送。

网络路由器仅仅作用于数据报的网络层字段，不检查封装在该数据报的运输层报文段的字段。接收端，网络层从数据报中提取运输层报文段并上交给运输层处理为之所用。

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

5.应用层报文=信封字符 进程=堂兄弟姐妹 主机=家庭 运输层协议=A和B 网络层协议=邮政服务

运输协议能够提供的服务受制于底层网络层协议。如果网络层协议无法为主机之间的运输层报文段提供时延或者带宽保证，运输层也无法为进程之间保证。

若底层网络协议不能在网络层提供服务，运输层协议却可以。即使底层网络协议不可靠，会使分组丢失篡改冗余，运输层也可以提供可靠的数据传输服务，即使网络层不保证运输层报文的机密性，运输协议也可以加密确保。

6.TCP可靠的面向连接，UDP不可靠无连接。运输层分组称为报文段，TCPUDP的分组称为报文段，网络层分组称为数据报。

7.因特网网络层协议IP,即网际协议，IP为主机之间提供了逻辑通信，IP的服务模型：尽力而为交付服务，尽最大努力交付报文段但不确保。不确保交付，不确保按序，不确保完整。因此是不可靠服务，每台主机至少有一个网络层地址IP地址。

8.UDPTCP将两个端系统间的IP交付扩展为运行在端系统两进程交付称为 运输层多路复用和多路分解。UDPTCP可以通过在报文段首部中包括差错检查字段而提供完整性检查。

进程到进程的数据交付和差错检查是两种最低限度的运输层服务，也是UDP仅仅能提供的两种。IPUDP均是不可靠服务。

9.TCP提供几种附加服务，可靠数据传输。通过流量控制，序号，确认和定时器，TCP确保正确的，按序的将数据交付。这样TCP将两个端系统不可靠IP服务转换成可靠数据传输服务。

还有拥塞控制，是提供给整个因特网的服务，防止任何一条TCP连接占用过多流量淹没通信主机之间的链路和交换设备，他力求为每一个通过一条拥塞网络链路连接平等的共享网络链路带宽，这可以通过调节TCP连接发送端的流量速率做到。UDP流量是不可调节的，使用UDP传输的应用程序可以以其愿意的任何速率发送数据。

10.多路复用和多路分解：网络层提供的主机之间交付到进程之间交付，是所有计网都需要的。

网络层传递报文到运输层，运输层将报文段中的数据交付给适当的应用程序进程。

一个进程有多个套接字，相当于从网络向进程互相传递数据的门户，接收主机中的运输层并没有直接将数据交付给进程，而是给了套接字，接收主机不止一个套接字，每个套接字都有一个唯一的标识符，标识符的格式取决于他是TCP还是UDP

每个运输层报文段具有几个字段，接收端中，运输层检查这些字段，标识出接受套接字，进而将报文段定向到该套接字。

多路分解：将运输端报文段中的数据交付到正确的套接字的工作

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

他们与在某层的单一协议何时被位于接下来的较高层的多个协议使用有关。

2.29第三章126-130

1.分发快递:分解 收集信件到中转处:多路复用

2.运输层多路复用的要求:①套接字有唯一标识符②每个报文段有特殊字段来指示套接字。这些特殊字段是源端口号字段+目的端口号字段

3.端口号:16比特的数，0-65535之间。0~1023是周知端口号受限制，保留给周知应用层协议，周知端口在RFC1700中。

4.运输层实现分解服务:主机上的每个套接字分配一个端口号，当报文段到达主机，运输层检查其中的目的端口号，定向到相应套接字，然后报文段数据通过套接字进入进程，UDP大体是这样。

5.如果代码实现是周知协议的服务器端，开发者必为其分配一个相应的周知端口号，客户端让运输层自动的分配端口号，服务器分配一个特定的端口号。

6.socket()创建UDP套接字自动分配未被使用的1024~65535的端口号。blind()为UDP套接字关联特定端口号。

7.主机A中一个进程( UDP端口1)发送一个数据块给主机B的另一进程( UDP端口2)。

主机A运输层创建一个运输层报文段(程序数据，源端口号，目的端口号，两个其他值)。然后运输层将得到的报文段传递给网络层，网络层将报文段封装到IP数据报，尽力而为将报文段交付给接收主机。

若报文段到达接收主机B，B运输层就检查报文段的目的端口号，将报文段交付给端口号标识的套接字。

8.每个进程都有自己的套接字和相应端口号。

当UDP报文段从网络到达，主机B检查报文段的目的端口号，定向分解到相应套接字。

9.一个UDP套接字是由一个二元组全面标识的，二元组(目的IP地址，目的端口号)。

10.源端口号用作返回地址一部分，B回发报文段给A，b到a的报文段中的目的端口号从a到b的报文段的源端口号中取值，完整返回地址(a的IP地址+源端口号)，recvfrom()从报文段提取源端口号作为目的端口号向客户发送新的报文段。

11.TCP套接字(源IP地址+源端口号+目的IP地址+目的端口号)当TCP报文段从网络到达主机，全部四个值将报文段定向分解到相应套接字，与UDP不同的是，两个具有不同源IP地址或者源端口号的到达TCP报文段将被定向到两个不同的套接字，除非报文段携带了初始创建连接的请求。

12.服务器主机可以支持很多并行的TCP套接字，每个套接字与一个进程相联系，由四元组标识每个套接字。

当TCP报文段到达主机，四个字段(源ip端口号目的ip端口号)将被用来定向分解到相应套接字

13.端口扫描器确定哪个应用程序正在监听哪些端口，最广泛是nmap，包括在大多数linux分发软件中，TCPnmap顺序扫描端口，寻找能接受TCP连接的接口，UDPnmap顺序扫描，寻找对报文段可以响应的端口。

两种情况下，nmap返回打开的，关闭的不可达的端口列表。运行nmap的主机能扫描因特网任何地方的目的主机。

14.两条连接有不同的源IP地址，服务器能正确分解这两个具有相同源端口号的连接。

15.每个进程都有自己的连接套接字，通过这些可以收到HTTP请求和发送HTTP响应。

16.连接套接字与进程并非总是一一对应。WEB服务器通常只使用一个进程，但是为每个新的客户连接创建具有新套接字的新线程。对于这样的服务器，任意给定时间都可能有具有不同标识的很多连接套接字连接到相同进程。

17.客户服务器持续HTTP:经由同一个服务器套接字交换HTTP报文。

客户服务器非持续HTTP:对每一对请求/响应都创建一个新的TCP连接并随后关闭，套接字也随后关闭，频繁会影响性能。

18.运输层最低限度必须提供一种复用/分解服务，以便在网络层与正确的应用级进程之间传递数据。

19.UDP只是做了运输协议能做的最少工作，除了分解复用少量的差错检测以外，几乎没有对IP增加别的东西，如果选择UDP差不多就是和IP打交道。

UDP从进程得到数据，附加上(用于多路复用分解的源目的端口号字段+其他两小字段)，将形成的报文段交给网络层，网络层将运输层报文段封装到IP数据报中，尽力而为交付给接收主机。

如果报文段到达接收主机，UDP使用目的端口号将数据交付给正确的应用进程。使用UDP发送报文段之前，发送方和接收方运输层实体没有握手，所以UDP无连接的。

20.DNS是一个通常使用UDP的应用层协议例子，当主机里的DNS程序想要进行查询时，构造了DNS查询报文交给UDP，无需执行与任何udp实体之间的握手，主机端的udp为此报文添加首部字段交给网络层。

网络层将udp报文段封装进ip数据报中，然后将其发送给一个名字服务器。查询主机中的DNS程序等待对查询的响应，若无响应(底层网络丢失查询或响应)要么向另一个名字服务器发查询，要么通知调用的程序他没响应。

3.2 第三章131-135

1.比起TCP，有很多应用更适合用UDP:

①发送什么数据以及何时发送的应用层控制更加精细，udp没有拥塞控制机制，实现额外功能 由于实时应用要求最小的发送速率，不希望过分延迟报文段发送，能容忍数据丢失。

②无需连接建立，udp不需要任何准备就可以数据传输，tcp要三次握手，udp没有建立连接的时延，这就是dns只运行在udp(快)的主要原因。 http使用tcp因为需要可靠性的文本数据，谷歌浏览器的QUIC协议运行在udp实现可靠

③无连接状态，udp不维护连接状态，不跟踪参数(接收发送缓存，拥塞控制参数，序号与确认号的参数)这些状态信息实现tcp可靠数传和拥塞

④分组首部开销小，tcp报文段20字节，udp8

2.电子邮件，远程终端访问，web，文件传输运行在tcp，这些都需要可靠数传。

udp用于承载网络管理数据snmp，这种必须在网络重压运行，难以实现可靠拥塞数传。dns运行在udp上避免tcp连接创建时延。

3.tcpudp都用于因特网电话，实时视频会议，流式存储音频与视频，都能容忍少量分组丢失。

tcp拥塞会使多媒体应用实时性能变差，所以通常运行在udp上。当分组丢包率低时，某些机构阻塞udp流量，tcp对流式媒体传输更好。

4.udp缺乏拥塞控制会导致udp发送方和接收方之间的高丢包率，挤垮tcp会话，这是潜在严重问题。

udp没有拥塞控制需要预防他进入，否则会有大量分组溢出，少量udp分组能成功传输，无控制udp高丢包率导致tcp发送方减小速率。

5.使用udp的应用是可能实现可靠数据传输的。可以通过在程序自身建立可靠性机制完成(通过增加确认与重传机制) 。

QUIC在udp实现了可靠。应用进程可以进行可靠通信，无需受制tcp拥塞强加的传输速率限制。

6.对于dns应用，数据字段包含一个查询报文或者响应报文，udp首部只有4个字段八个字节，通过端口号可以使目的主机将数据交给目的端系统的进程(分解)。

长度字段指示了包括首部在内的udp报文段的字节数(首部+数据)。接收方使用检验和来检查是否出现差错。检验和除了udp报文段还包括ip首部的一些字段。

7.udp检验和提供了差错检测功能。用于确定udp报文段从源到目的地移动时其中比特是否改变。发送方udp对报文段所有16比特字的和进行反码运算并且求和溢出回卷，其结果放在udp报文段的检验和字段。

8.udp和许多链路层协议(以太网协议)都提供差错检测原因:不能保证源和目的之间所有链路都提供差错检测。即使正确也会有比特差错。

9.端到端原则例子:既无法确保逐链路的可靠性、又无法确保差错检测的情况下，如果端到端数据传输服务要提供差错检测，UDP就必须在端到端基础上在运输层提供差错检测。

udp有差错检测但是无法恢复，可以丢弃受损的报文段或者将受损报文段交给程序给出警告。

10.可靠数据传输实现可以在传输层链路层应用层出现。为上层实体服务是:数据可以通过一条可靠的信道进行传输。 借助于可靠信道，传输数据比特不损坏成丢失，数据按序交付。

11.可靠数据传输协议的下层协议也许不可靠。 TCP 是在不可靠的(IP) 端到端网络层之上实现的可常数据传输协议。两个可靠通信端点的下层可能是由一条物理链路( 如在链路级数据传输协议的场合下)组成或是由一个全球互联网络组成。

12.可将较低层视为不可靠的点对点信道。底层信道将不会对分组重排序。rdt交换含有待传送的数据分组，rdt发送端和接收端还需往返交换控制分组。

13.经完全可靠信道的可靠数据传输: rdt1. 0。首先考虑底层信道是完全可靠的。

3.3 第三章136-140

1.rdt1.0简单协议里面，一个单元数据就是一个分组，，所有分组都是从发送方流向接收方，有了完全可靠的信道，接收端不需要提供任何反馈信息给发送方，不会有差错，假定接受速率和发送速率相等。

2.底层信道更加实际的就是分组中比特可能受损。在分组传输传播缓存时比特差错会出现在网络物理部件里，仍然假定分组按序接收，这里口述报文协议运用了肯定确认和否定确认，基于这种重传机制的可靠数据传输称为自动重传请求协议。

3.ARQ（自动重传请求协议）还需要另外三种协议功能来处理比特差错：

①差错检测。确定到何时出现了差错，udp使用因特网检测和字段就是这个目的，这可以使接收方检测或者纠正分组差错，这些技术需要额外的比特发送出去，这些比特汇集在rdt2.0数据分组的分组检验和字段里面。

②接收方反馈。两方在不同端系统上执行，在口述报文情况回答的ACK和NCK就是例子，rdt2.0会从接收方向发送方会送acknck分组，这些分组只需要一比特长（0/1）

③重传。接收方收到有差错分组时，发送方会重传。

4.发送端等待来自上层传下来的数据，发送方协议等待来自接收方的acknak分组，如果收到ack分组，则已经被正确接收，协议返回到等待来自上层数据的状态。如果收到nak分组，协议重传上一个分组并等待接收方为响应重传分组而回送的ack和nak。

5.当发送方处于等待ack或者nak状态时，他不能从上层获得更多的数据，rdt_send()事件不可能出现，仅当接收到ack并且离开该状态才能发生。

发送方不会发送一块新数据，除非发送方确信接收方已经正确接收当前分组，所以rdt2.0被称为停等协议。

rdt2.0接收方的fsm仍然只有单一状态，当分组到达时，接收方回答ack或者nak，这取决于收到的分组是否受损。

6.rdt2.0致命的缺陷有了，ack或者nak分组可能会受损，所以需要在acknak分组里面添加检验和比特来检测这样的差错，更难的是还要纠正这些差错，如果acknak受损了，咱就不知道接收方是否正确接收了上一块数据。

7.考虑处理受损ack和nak的三种可能：

①引入一种新型发送方到接收方的分组，接收方会复述其回答，“你说什么”到底是信息内容还是要求重复的请求。

②增加足够的检验和比特，时使发送方不仅检测差错还可以恢复差错。对于有差错但是不丢失分组的信道就可以。

③当收到模糊不清的ack或者nak分组时，只需要重传当前数据分组。这种方法在信道中引入了冗余分组，根本困难是在于接收方不知道上次他发送的ack或者nak是否被正确收到，不知道这次是新的还是一次重传。

8.解决方法是（几乎所有的数据传输协议比如tcp都引用了）在数据分组添加一个新字段，发送方对其数据进行编号，将分组序号放在该字段。接收方只需要检查序号就可以确定分组是否一次重传，对于停等协议，1比特序号就可以。假定信道不丢分组，acknak本身不需要指明他们要确认的的分组序号，发送方知道就行。

9.rdt2.1的发送方和接收方fsm的状态数都是以前的两倍，协议状态必须反应目前正在发送或者接收的分组序号是0还是1.

发送接收0号分组和1号分组的动作是相似的，唯一不同的是序号处理方法不同。

rdt2.1使用了ack或者nak，当接收到失序的分组，接收方发送ack。

如果收到受损的分组，接收方发送nak。如果不发送nak，对上次正确接收的分组发一个ack也可以。发送方接收到对同一个分组的两个ack（有冗余ack），就知道接收方没有正确接收到跟在被确认两次的分组后面的分组。

10.rdt2.2是在有比特差错信道上面实现一个无nak的可靠数据传输协议，rdt21和rdt22变化在于接收方此时必须包含由一个ack报文所确认的分组序号（在接收方fsm中，在make_pkt()中包括参数ack0或者ack1实现），发送方此时必须检查接收到的ack中被确认的分组序号（在发送方fsm中，在isack()中包含参数0或者1来实现）。

11.具有比特差错的丢包信道的可靠数据传输：rdt3.0

底层信道也会丢包，rdt2.2已经研发出使用检验和序号啊ack分组和重传机制。

3.6 第三章141-145

1.发送方传输一个数据分组， 该分组或者接收方对该分组的ACK发生丢失。在这两种情况下，发送方都收不到接收方的响应。如果发送方愿意等待足够长的时间以便确定分组已丢失，则它只需重传该数据分组。

2.发送方至少需要等待(发送方与接收方之间的一一个往返时延( 包括在中间路由器的缓冲时延)+接收方处理分组的时间)。等待最坏情况的时延可能要等待较长的时间， 直到启动差错恢复为止。方法是发送方明智地选择时间值， 以判定可能发生了丢包。

如果在这个时间内没有收到ACK，则重传该分组。如果分组经历了一个特别大的时延，发送方可能会重传该分组，即使该数据分组及其ACK没有丢失。

3.因此发送方到接收方的信道中引人了冗余数据分组。rdt2. 2协议已经有足够的功能(即序号)来处理冗余分组情况。

4.从发送方的观点看，重传是一种万能灵药。发送方不知道是数据分组还是ack丢失，或者只是该分组或ACK 过度延时。

在所有这些情况下，都重传。因此引入了倒计数定时器，在一个给定的时间量过期后，可中断发送方。

5.因此，发送方需要能做到:

①每次发送一个分组(包括第一次分组和重传分组)时，便启动一个定时器。②响应定时器中断(采取适当的动作)。③终止定时器。 6.注意:分组的接收时间必定迟于分组发送时间，因为发送时延和传播时延的原因。

7.因为分组序号在01之间交替，因此rdt3.0被称为比特交替协议。

8.可靠数据传输协议的要点:检验和，序号，定时器，肯定和否定确认分组这些技术，都必不可少。

9.流水线可靠数据传输协议。rdt3.0是一个功能正确的协议，但是rdL3. 0性能问题的核心在于它是一个停等协议。

考虑具有两台主机的理想化场合， 一台主机美国西海岸另一台美国东海岸，在这两个端系统之间的光速往返传播时延RTT大约为30毫秒。

10.如果我们定义发送方(或信道) 的利用率为:发送方实际忙于将发送比特送进信道的那部分时间与发送时间之比，表明停等协议有着非常低的发送方利用率。

11.发送方只有万分之2.7时间是忙的，有效的吞吐很低，即使有很多容量的链路可用也是如此。这是形象的网络协议限制底层网络硬件所提供的能力例子。此时还忽略了在发送方和接收方的底层协议处理时间，以及出现在发送方与接收方之间的任何中间路由器上的处理与排队时延。这些因素增加时延，使其性能更糟糕。

12.这种特殊的性能问题的一个简单解决方法是:不以停等方式运行，允许发送方发运以在等个分组而无须等待确认。如果发送方可待确认之前发送3个报文，其利用率也基本上提高3倍。

13.许多从发送方向接收方输送的分组被看成填充到一条流水线中，因此被称为流水线。

●必须增加序号范围，因为每个输送中的分组(不算重传的)必须有唯一的序号，而且也许有多个在输送中的未确认报文。

●协议的发送方和接收方两端也许不得不缓存多个分组。发送方最低限度应当能缓冲那些已发送但没有确认的分组。接收方或许也需要缓存那些已正确接收的分组。

●所需序号范围和对缓冲的要求取决于数据传输协议如何处理丢失、损坏及延时过大的分组。解决流水线的差错恢复有两种基本方法是:回退N步GBN和选择重传SR。

15.回退N步 在gbn中，允许发送方发送多个分组(当有多个分组可用)不需等待确认，受限于在流水线中未确认分组数不能超过某个最大允许数N。

16.那些已被发送但还未被确认的分组的许可序号范围可以被看成是一个在序号范围内长度为N的窗口。随着协议的运行，该窗口在序号空间向前滑动。N常被称为窗口长度，GBN协议也常被称为滑动窗口协议。 流量控制是对发送方施加限制的原因之一。

17.分组的序号承载在分组首部的一个固定长度的字段中。如果分组序号字段的比特数是k，则该序号范围是[0, 2^k-1]。

3.6 第三章141-145

1.gbn发送方必须响应三种类型的事件:

①上层的调用。当上层调用rdt_send，发送方检查窗口。若窗口未满，产生分组发送并更新，若已满，数据返回上层隐式指示过会再试。实际上，发送方缓存或者使用同步机制，允许上层仅窗口不满才调用rdtsend。

②收到一个ack。对序号为n的分组采取累积确认，表明已经正确接收n前分组。

③超时事件。“回退n步”出现丢失或者时延过长分组时发送方的行为 ，定时器用于再次恢复数据或者确认分组丢失。

2.在gbn中，接收方的动作简单，如果序号n的分组被正确按序接受到，则为分组n发送一个ack和交付数据到上层 。其他情况下，丢弃分组为n-1分组重新发送ack，如果k接收交付，则比k小的都交付，所以是累积确认。

3.在gbn中，接收方丢弃失序分组，现在接收缓存分组了n+1，等他收到交付分组n后交付上层，如果n丢失，n和n+1被重传，只需丢弃n+1就行。

优点:接收缓存简单，不需缓存任何失序分组。

4.虽然发送方必须维护窗口上下边界和nsq在窗口的位置，接收方维护只有下一个按序接收的分组序号。

5.丢弃一个正确接收的分组缺点:随后对该分组重传也会丢失或者出错甚至更多重传。

6.在协议栈实现gbn协议与扩展fsm相似。每个过程实现了在响应各种可能出现的事件时要采取的动作，被称为基于事件的编程，这些过程要么被协议栈中的其他过程调用，要么作为一次中断的结果。

7.在发送方，这些事件包括

①来自上层实体的调用去调用rdt_send ();

②定时器中断;

③报文到达时，来自下层的调用去调用rdt_rev()。

8.GBN 协议中综合了TCP 可靠数据传输构件时遇到的所有包括使用序号、累积确认、检验和以及超时/重传 *** 作。

9.gbn允许发送方用多分组填充流水线，避免了停等协议的信道利用率问题。

10.gbn本身性能问题:窗口长度和带宽时延积都很大时，单个分组差错引起gbn重传大量分组，很多分组没必要重传。随信道差错率增加，流水线被不必要重传分组充斥。

11， SR协议通过让发送方仅仅重传那些他怀疑在接收方出错丢损的分组来避免不必要的重传。这种个别按需重传要求接收方逐个确认正确接收的分组 。 sr与gbn不同的是，发送方已经收到了对窗口中某些分组的ack。

12，sr接收方会确认一个正确接收的分组不管是不是按序。失序分组被缓存直到所有丢失分组都被收到，这时将一批分组按序交付给上层。

13.sr发送方: 从上层收到数据，超时，收到ack。

14.sr接收方: 序号在范围内的分组被正确接收[rcv_base,r+N-1] [ r-N,r-1]。

15.接收方重新确认已经收到的那些序号小于当前的分组，很重要!

对sr协议，那些被正确接收，哪些没有，接收方发送方看到的不一样，两者窗口并不总是一致。

16.当面对有限序号范围，发送方接收方窗口间缺乏同步会产生严重后果。

3.7 第三章151-155

1.SR协议里面，接收方重新确认已经收到过的那些序号小于当前窗口基序号的分组，确实需要。

2.接收方和发送方之间有假想的帘子。

SR协议里面窗口长度必须小于等于序号空间大小的一半。多种机制一起提供可靠数据传输。

P151总结了检验和定时器续航确认否定确认窗口流水线等等这些可靠数据传输机制及其用途的总结。底下的看不懂。

3， TCP面向连接的运输

在因特网运输层面向连接的可靠运输协议，tcp依赖于前面的 差错检测，重传，累积确认，定时器，用于序号和确认号的首部字段。

tcp是面向连接的，进程向另一个进程发送数据之前，进程之间必须先握手，必须发送某些预备报文段，来建立参数。

4 .tcp/ip协议代表传输控制协议/网际协议。一开始看成单一的实体，后来分成单独运行的两个部分，这是当今的支柱性协议。CK获得ACM图灵奖。

5.这种tcp连接是一条逻辑连接，其共同状态仅保留在两个通信端系统的tcp程序中，中间的网络元素(路由器链路层交换机)不会维持tcp连接状态，只在端系统运行。中间路由器看到的是数据报，对连接视而不见。

6.tcp连接提供全双工服务，主机a上的进程b和主机c上的进程d存在tcp，那么应用层数据b<->d，tcp连接也是点对点的，单发单接。多播不存在的。

7.客户先发一特殊tcp报文段 服务器用另一特t报回应，最后客户再第三个特t报响应。前两个不包含应用层数据，第三个包含，所以称为三次握手。

8.一旦建立起连接，进程互发数据，客户进程通过套接字传数据流，通过以后由tcp控制。tcp将这些数据引导到连接的发送缓存中，发送缓存是发起三次握手期间的缓存之一。接下来tcp不时从发送缓存取一块数据传到网络层，在他方便的时候。

9.tcp可以从缓存中取出并放入报文段数据数量受限于最大报文段长度，mss根据最初确定的由主机发送的最大链路帧长度(最大传输单元)，设置保证一个tcp报文段＋tcp/ip首部长度才适合单个链路层帧。

10.tcp为每块客户数据配上一个tcp首部从而形成多个tcp报文段，报文段下传给网络层分别封装在网络层ip数据报中，然后被发送到网络。当tcp另一端收到一个报文段，此数据被放入tcp的接收缓存中。应用程序从缓存中读取数据流，连接每一端都有发送缓存和接收缓存。

11.tcp连接组成包括:一台主机的缓存，变量和进程连接的套接字，另一台主机的…。两台主机之间的网络元素(路由器交换机中继器)，没有为连接分配缓存和变量。

12.tcp报文段结构:首部字段+数据字段(一块应用数据)。mss限制了报文段数据字段的最大长度。P144

13.首部包含:源端口号+目的端口号。tcp首部也包括检验和字段。还包括(32bit序号字段+16bit接收窗口字段+4bit首部长度字段+可选与变长的选项字段+6bit标志字段)

14， tcp报文段首部中最重要的是序号字段+确认号字段，这俩是tcp可靠传输服务的关键。

15.tcp把数据看成无结构有序字节流，序号建立在传送字节流上。一个报文段序号是报文段首字节的字节流编号。

3.8 第三章156-160

1.tcp只确认流中至第一个丢失字节为止的字节，所以tcp被称为提供累积确认。

2.当主机在一条tcp连接中收到失序报文段时，tcprfc并没有为此明确规定任何规则 留给编程人员去解决:

①接收方立即丢弃失序报文段(可简化接收方的设计)②接收方保留失序的字节，并等待缺少的字节来填补间隔。后一种更有效现实。

3.一条tcp连接的双方均可随机选择初始序号。 这样可以减少将那些仍在网络中存在的来自两台主机之间先前已经终止的连接的报文段，误认为后来两台主机之间新建连接产生的有效报文段的可能性?

4.telnet是用于远程登陆的流行应用层协议，运行在tcp，在任意一对主机之间工作，它是交互式应用。

很多用户更愿意采用ssh协议而不是telnet，因为telnet里面发送的数据口令不加密，更容易受到窃听攻击。

5.一个报文段序号就是该报文段数据字段首字节的序号，确认号就是主机正在等待的数据的下一个字节序号。tcp建立后没发送数据之前，客户等服务器第一个报文段序号字节，…

6.对客户到服务器的数据的确认被装载在一个承载服务器到客户的数据的报文段中，这种确认被称为是被捎带在服务器到客户的数据报文段中的。

7.即使报文段没有数据还仍有序号，因为tcp存在序号字段，报文段需要填入某个序号。

8.用户 seq＝42 ack＝79 data＝’c’－> 服务器 <－seq＝79 ack＝43 data＝’c’ seq＝43 ack＝80 ->

9.tcp/rdt 采用超时/重传机制处理报文段丢失，在tcp实际中，最明显的问题是超时间隔长度的设置 显然，超时间隔必须大于连接的往返时间rtt，rtt就是从一个报文段发出到他被确认的时间，否则有不必要的重传。

10.tcp如何估计发送方和接收方之间的往返时间?报文段样本rtt从某报文段发出交给ip到对该报文段的确认被收到之间的时间量。

大多数tcp仅在某个时刻做一次samplertt测量。tcp绝不为已被重传的报文段计算samplertt，仅为传输一次的报文段测量samplertt。

11.由于路由器的拥塞和端系统负载变化，这些srtt随之波动，所以任何给定的srtt都非典型，所以取平均，ertt＝x_srtt+(1-x)_ertt。x＝1/8

12.ertt是加权平均值，越最近样本权值越大，越近样本更反应网络当前拥塞，被称为指数加权移动平均，ewma中指数是指srtt权值更新时指数型快速衰减，还有devrtt测量rtt变化偏差，srtt波动与devrtt波动成正比。

13.tcp超时间隔应该大于等于ertt，否则有不必要重传，也不应该大太多，否则当报文段丢失时，tcp不能很快重传报文段导致数据传输时延太大。因此超时间隔＝ertt+一定余量，当rtt波动大，余量应该大一点，…

此时devrtt有作用，tointerval＝ertt+4*devrtt。

推荐的toinvertal为一秒，当超时后，值会加倍，以免即将被确认的后继报文过早出现超时

14.ip服务不可靠，不保证交付，按序，完整，对ip服务，数据报能溢出路由器缓存而永远不能到达目的地，数据报乱序到达比特损坏，运输层报文段也有这样的问题。

15.tcp在ip不可靠的尽力而为创建一种可靠数据传输服务，tcp这种服务确保数据流无损坏无间隔不冗余按序。该字节流和发送的完全相同。

16.推荐的定时器管理过程仅使用单一的重传定时器，即使有多个已发送未确认的报文段。发送方用超时和冗余确认来恢复报文段丢失。

17.tcp发送方有三个与发送和重传有关的主要事件:从上层应用程序接收数据，定时器超时和收到ack。 如果定时器没有为某些其他报文段运行，当报文段传给ip，tcp启动该定时器，定时器的过期间隔是tointerval。

3.9 第三章161-165

1.tcp发送方处理第三个主要事件:到达来自接收方的确认报文段(ack)。

事件发生时，tcp将ack的y值与变量sendbase比较。seba时最早未被确认的字节序号(seba-1)是接收方已经正确按序接受到数据最后一个字节序号)。

tcp累积确认，y之前所有字节都已经收到。若y>seba，ack在确认多个先前未被确认的报文段，发送方更新他的seba。如果当前有未被确认的报文段，tcp还要重新启动定时器。

2.有趣的情况自己看看P161

3.在定时器时限过期后超时间隔的长度:每当超时事件发生，tcp重传最小序号未被确认的报文段，每次重传将下一次超时间隔设为先前值的两倍。

因此超时间隔在每次重传后呈指数型增长。每当定时器在另两个事件(收到上层应用数据和收到ack)中任意一个启动时，toinvertal由最近的ertt和devrtt推算得到。

4.两倍修改提供了一个形式受限的拥塞控制。定时器过期很可能由网络拥塞引起的(太多的分组到达源与目的地路径上的路由器队列中)，造成分组丢失或者长时间排队时延。

如果拥塞的时候源持续重传分组，拥塞更加严重。相反，tcp更文雅一点，每个发送方重传经过越来越长时间间隔，csma/cd以太网采用了。

5.超时触发重传的问题是超时周期相对更长。当报文段丢失，长超时周期使发送方延迟重传丢失的分组增加了端到端的时延。 发送方在超时事件发生之前通过冗余ack来检测丢包情况。冗余ack即再次确认某个报文段的ack(发送方先前已经收到报文段的确认)

6.当tcp接收方收到序号的报文段时，现在序号大于下一个期望按序的报文段，他检测到数据流间隔(有报文段丢失)，此间隔可能由于网络中报文段丢失或者重新排序造成的。

tcp不使用否定确认，接收方不能向发送方发回显式否定确认。他只是对已经接收到最后一个按序字节数据进行重复确认(产生冗余ack)

7.P163表格还可以。

8.发送方持续发送大量报文段，一个丢失，引起接连冗余ack。如果tcp发送方接受到对相同数据的3个冗余ack，跟在已经被确认三次后面的报文段已经丢失。

9.一旦收到3个冗余ack，tcp进行快速重传(该报文段定时器过期前重传丢失的报文段)。

10.tcp发送方仅需维持已经发送过未被确认字节的最小序号和下一个要发送的字节序号(看起来像gbn)tcp和gbn有明显区别，见164

11.tcp的修改意见，进行选择确认，运行tcp接收方有选择的确认失序报文段，并不累积确认。 当该机制与选择重传机制结合使用(跳过重传已经被接收方选择性确认过的报文段)，tcp看起来像通常的sr协议 因此，tcp的差错恢复机制最好被分类为gbn协议和sr协议的混合体。

12.tcp连接的每一侧主机都为该连接设置了接收缓存。当tcp收到正确按序的字节，它将数据放入接收缓存，进程会从缓存中或早或晚读取数据。如果程序读取数据相对缓慢，发送方发送太快太多，就会接收缓存溢出。

13.tcp提供了流量控制服务，消除接收方缓存溢出的可能性，流量控制是速度匹配服务，发送速率与程序读取速率匹配。 tcp发送方可能因为ip网络拥塞而被遏制，这种形式发送方的控制被称为拥塞控制。 两者采取动作很相似，但是显然是针对完全不同的原因采取的。

14.tcp通过让发送方维护接收窗口来提供流量控制。接收窗口给发送方一个指示(该接收方还有多少可用的缓存空间)。tcp是全双工通信，连接两端的发送方各自维护接收窗口。

15.当主机b的接收窗口为0，主机a继续发送只有一个字节数据的报文段。这些报文段会被接收方确认，最终缓存开始清空，确认报文里将包含一个非零rwnd值。

16.udp并不提供流量控制，报文段由于缓存溢出可能在接收方丢失。一个典型的udp实现，udp将在一个有限大小的缓存中加上报文段缓存在相应套接字之前。进程每次从缓存读取一个完整报文段。如果读取速度慢，缓存溢出，报文段丢失。

3.10 第三章166-170

1.如何建立和拆除一条tcp连接，tcp连接会增加时延，许多网络攻击(syn洪泛攻击)利用tcp连接管理的弱点。

①客户端的tcp首先向服务器端tcp发送一个特殊tcp报文段(syn报文段)，报文段不包含应用层数据，报文段首部的syn比特被置为1。避免安全性攻击，适当随机选择client_isn。

②一旦包含tcpsyn报文段的ip数据报到达服务器主机，服务器会从数据报提取出tcpsyn报文段，为tcp分配tcp缓存和变量，向客户tcp发送允许连接的报文段。(完成三次握手的第三步之前分配这些缓存变量容易受到syn洪泛的拒绝服务攻击)也没有应用层数据。3重要信息。

③收到synack报文段(允许连接的报文段)以后，客户也要给该连接分配缓存和变量。客户主机则向服务器发送另一个报文段，最后一个对允许连接报文段进行确认。

2.一旦完成三步，客户服务器主机可以互相发送包括数据的报文段。以后的每一个报文段，syn比特都被置为0，两台主机之间发送三个分组，因此称为3次握手。

3.参与一条tcp连接的两个进程中任何一个都能终止连接，结束后缓存和变量都将被释放，过程就像客户>服务器，客户<服务器，然后释放。

4.在一个tcp连接的生命周期中，运行在每台主机中tcp协议在各种tcp状态中间变迁。

5.P168这个图还可以，好好看看。

6.服务器为了响应一个收到的syn，分配并初始化连接变量和缓存。然后服务器发送一个synack进行响应，等待客户的ack报文段。如果客户不发送ack来完成三次握手的第三步，一分钟多以后服务器终止这个半开连接并且回收资源。

7.这种tcp连接管理为dos攻击(syn洪泛攻击)提供了环境。这种攻击里，攻击者发送大量tcpsyn报文段，不完成第三次握手。这种syn报文段纷至沓来，服务器为半开连接分配资源又不用，服务器连接资源被用完。这种是众多dos攻击的第一种，现在有syncookie可以防御已被部署。

8.syncookie工作原理见169还可以

9.当主机接收到一个tcp报文段，其端口号或者源ip地址与该主机上进行的套接字都不匹配时，则该主机向源发送一个特殊重置报文段，该tcp报文段将rst标志位置为1。当主机发送一个重置报文段时，它告诉源“我没有你别发了”。当一台主机接收一个udp分组，他的目的端口与进行的udp套接字不匹配时，该主机发送一个特殊的icmp报文段。

10.nmap端口扫描工具:为了探索特定的tcp端口，nmap向主机目的端口发送一个特殊的tcpsyn报文段，三种输出: ①源主机从目的主机接收到一个tcpsynack报文段，nmap返回打开。 ②源主机从目标主机接收到一个tcprst报文段，syn报文段到达了主机，但主机没有运行程序，攻击者知道报文段没有被源和目的主机之间的任何防火墙阻挡。 ③源啥都没收到。syn报文段被防火墙阻挡。

11，nmap侦查打开的tcp端口和udp端口，侦查防火墙及其配置，侦查应用程序的版本和 *** 作系统。其中大多数都能通过 *** 作tcp连接管理报文段完成。

2022.3.12 第三章171-175

1.丢包一般是当网络变得拥塞由于路由器缓存溢出引起的，分组重传是网络拥塞的征兆(某特定运输层报文段的丢失)但是无法处理导致网络拥塞的原因，太多源想过高速率发送数据。

2.分析三个复杂性越来越高发生拥塞的情况:

①两个发送方和一台具有无穷大缓存的路由器

②两个发送方和一台具有有限缓存的路由器

③四个发送方和具有有限缓存的多台路由器及多跳路径

3.在实践中tcp用于拥塞控制的方法:根据网络层是否为运输层拥塞控制提供显式帮助来区分拥塞控制方法。

①端到端拥塞控制。网络层没有为运输层拥塞控制提供显式支持。即使存在拥塞，端系统必须通过网络分组丢失与时延来推断。tcp采用端到端的方法解决拥塞控制，ip层不会向端系统提供拥塞的反馈信息。tcp报文段的丢失(通过超时或者三次冗余确认得知)是拥塞的一个迹象，tcp会相应的减小窗口长度。最新建议:增加往返时延值

②网络辅助的拥塞控制。路由器向发送方提供网络中拥塞控制的显式反馈信息。这种可以简单的用一个比特指示链路中的拥塞情况。在atm可用比特率拥塞控制中，路由器显式通知发送方它能在输出链路支持的最大主机发送速率。默认因特网版本的ip和tcp采用端到端拥塞控制方法，最近的ip和tcp能选择性实现网络辅助拥塞控制。

4.网络辅助的拥塞控制，拥塞信息从网络反馈到发送方通常有两种方式:

①直接反馈信息可以由网络路由器发给发送方，这种通知采用一种阻塞分组的形式，(“我阻塞了!”)

②更通用的是:路由器标记或者更新发送的分组中的某个字段来指示拥塞的产生。一旦收到一个标记的分组，接收方会向发送方通知该网络拥塞指示，至少要经过一个完整的往返时间。

5.三个发生拥塞的具体情况(原因代价)我看不懂

2022.3.15第三章176-180

1.tcp有可靠传输服务和拥塞控制。tcp必须使用端到端拥塞控制，不是网络辅助的拥塞控制!ip层不向端系统提供显式的网络拥塞反馈。

2.tcp采用的方法是:让每一个发送方感知到的网络拥塞程度来限制向其连接发送流量的速率。没什么拥塞就增加，有拥塞就降低。

3.tcp连接每一端都有发送缓存接收缓存和几个变量组成，运行在发送方的tcp拥塞控制机制跟踪一个额外变量(拥塞窗口cwnd)，他对发送方发送流量速率进行了限制。发送方未被确认的数据量＜＝min{cwnd，rwnd}。

4.发送方的发送速率大概是cwnd/ RTT 字节/秒通过调节cwnd的值，发送方能调整它向连接发送数据的速率。

5.tcp发送方丢包事件:超时/收到接收方的三个冗余ack(包括快速重传的后继修改)。当出现过度拥塞，路径上的路由器缓存会溢出，引起一个数据报(包括一个tcp报文段)被丢弃，丢弃的数据报会引起发送方的丢包事件(超时/三个冗余ack)，他就知道路上有拥塞。

6.网络没有拥塞(无丢包):tcp发送方将收到以前未确认报文段的确认，这些确认到达才是正常成功交付，使用确认来增加窗口长度(传输速率)。如果确认以相当慢的速率到达(高时延/包含低带宽链路)，拥塞窗口增加很慢，…这是因为tcp使用确认来触发(计时)增加他的窗口长度，所以tcp是(自计时)的。

7.给定调节cwnd值来控制发送速率的机制:tcp发送方是显式协作，存在分布式方法设置发送速率，tcp有下列指导性原则。

①一个丢失的报文段表意味着拥塞，因此当丢失报文段时应当降低tcp发送方的速率。给定报文段，一个超时事件或者四个确认(一个初始ack和随后三个冗余ack)暗示发生了丢包 。该问题是tcp发送方如何减小窗口长度和发送速率来应对丢包。

②一个确认报文段指示该网络正在向接收方交付发送方的报文段，当对先前未确认报文段的确认到达时，能增加发送方速率。确认的到达是顺利的暗示，不拥塞窗口长度就增加。
③带宽检测。

8.tcp拥塞控制算法三个部分:慢启动 拥塞避免 快速恢复。12是tcp强制部分，差异在于对收到的ack反应时增加cwnd长度的方式。1比2能更快增加cwnd的长度，3是推荐部分非必需。

9.慢启动
tcp连接开始时，cwnd值初始为mss较小值，速率MSS/ RTT，对发送方可用带宽可能比MSS/ RTT大的多。cwnd以1MSS开始，首次确认增加1，确认到达以后，发送方将窗口增加1MSS，发送两个最大长度报文段，再增加1Mss，窗口翻倍。每过一个RTT，速率就翻倍，发送速率开始慢，后来指数增加。

10.何时结束指数增长:①存在由超时指示的丢包事件(拥塞)②直接与ssthresh相关联③检测到三个冗余ack，tcp执行快速重传进入快速恢复状态。

11.拥塞避免
cwnd大概是上次遇到拥塞的一半，每个RTT只将cwnd增加一个MSS,有很多种方式完成，通用的是对于tcp发送方无论到达一个新确认，cwnd都增加一个MSS/字节。
11.何时结束拥塞避免的线性增长?当超时，与慢启动行为相同，但是tcp对于丢包事件行为不那么剧烈:tcp将cwnd值减半(计及已收到的3个冗余ack加上3个mss)，当收到3个冗余ack，ssthresh的值记录为cwnd值的一半，接下来快速恢复。

2022.3.19 第三章180-185
1.快速恢复
对于引起tcp进入快速恢复的缺失报文段，对收到的每个冗余ack，cwnd增加一个mss。最终，当对丢失报文段的一个ack到达时，tcp在降低cwnd后进入拥塞避免状态。
如果出现超时事件，执行和慢启动和拥塞避免相同的动作以后，迁移到慢启动状态。
如果出现丢包事件，cwnd被设置为1个mss，ssthresh设置为cwnd的一半。

2.快速恢复是tcp推荐的非必需的，一种tcp tahoe早期版本，发生丢包事件，都无条件的将拥塞窗口减到1个mss，进入慢启动阶段。tcp reno新版本综合了快速恢复。

3.区分tcp差错控制/重传与tcp拥塞控制非常重要，但是这两个方面交织链接的方式也很重要。

4.忽略一条连接开始时初始的慢启动阶段，假定丢包由三个冗余ack指示，tcp的拥塞控制是：每个RTT内cwnd线性增加1mss，然后出现3个冗余ack时cwnd减半，因此tcp拥塞控制称为：加性增，乘性减 的拥塞控制方式。

5.AIMD拥塞控制引发了图示的锯齿行为，tcp线性增加他的拥塞窗口长度（来增加他的传输速率），直到出现3个冗余ack事件，然后以2个因子来减少他的拥塞窗口长度，又开始线性增长，探测是否还有另外可用的带宽。

6.很多tcp实现采用了reno算法，他也有很多变种已经被提出。tcp vegas算法试图在维持较好的吞吐量同时避免拥塞，vegas的基本思想是：1分组丢失之前在源和目的地之间检测路由器中的拥塞 2当检测出快要发生分组丢失时，线性降低发送速率。

7.快要发生的分组丢失是通过观察RTT来检测的。分组的RTT越长，路由器中的拥塞越严重。

8.在tcp研发后十年，理论分析显示tcp的拥塞控制算法被用作一种分布式异步优化算法，使得用户和网络性能的几个重要方面被同时优化。

9.给出tcp的锯齿形状行为以后，考虑一个长存活期的tcp连接的平均吞吐量（平均速率），在这个分析中，忽略超时事件出现以后的慢启动阶段（非常短，发送方很快以指数增长离开这个阶段），在一个特定的往返间隔内，tcp发送速率是拥塞窗口与当前RTT的函数。
一条连接的平均吞吐量=0.75*W/RTT, 这个是高度理想化的tcp稳态动态性模型。

10.tcp继续演化的需求能够通过考虑 网格和云计算应用 需要的高速tcp连接加以阐述。
一条连接的平均吞吐量=1.22MSS/RTTpow（L，1/2）
L是丢包率，RTT是往返时间，MSS是最大报文段长度。由这个公式，w为了取得10GBPS的吞吐量，今天的拥塞控制算法仅能容忍2*10^-10报文段丢失概率，这很低了。

11.对于K条tcp连接，每条都有不同的端到端路径，都经过一段传输速率为Rbps的瓶颈路径（对于每条连接，沿着该连接路径上的所有其他段链路都不拥塞，其他的都有充足的传输容量）。假设每条连接都在传输一个大文件，无UDP流量通过该段瓶颈链路。如果每条连接的平均传输速率接近R/K，每条连接都得到相同份额的链路带宽。，就认为该拥塞控制机制是公平的。

12.许多多媒体应用（因特网电话+视频会议），就因为公平性不在tcp上运行，即使是网络非常拥塞时，他们不想被传输速率遏制。他们宁可在udp上运行，udp没有内置的拥塞控制。
当运行在udp上时，这些应用能以恒定的速率将音频和视频数据注入网络之中并且偶尔会丢失分组，他们不愿意公平反而不丢失任何分组。

13.运行在udp上的多媒体应用是不公平的，因为他们不与其他连接合作，也不适时调整其传输速率。tcp拥塞控制在面临拥塞增加（丢包）时，将降低其传输速率，udp源不需要这样做，udp源有可能压制tcp流量。

14.即使能够迫使udp流量具有公平地行为，公平性问题还没完全解决，没有办法阻止基于tcp的应用使用多个并行连接，例如web浏览器通常使用多个并行的tcp连接来传送一个web页中的多个对象。当一个应用使用多条并行连接，他占用了一条拥塞链路中较大比例的带宽。

15.tcp已经实现了端到端拥塞控制的形式，一个tcp发送方不会收到来自网络层的明确拥塞指示，而是通过观察分组丢失来推断拥塞。最近，对于IP和TCP的扩展方案已经实现和部署，方案允许网络明确向tcp发送方的接收方发出拥塞信号，这种网络辅助拥塞控制称为 明确拥塞通告（ECN)。

还有45678章加油加油，更新未完待续…怀挺！！！摆烂了中间没有划重点了太多了

这本书真的好难看呜呜，晦涩难懂，令我爱不释手。