[网络协议]传输层最全知识点

1. 传输层概述

1.1 传输层基本概念

• 传输层位于通信部分的最高层，也是用户功能的最底层
• 只有位于网络边缘的主机的协议栈才有运输层，位于网络核心的路由器在转发时只用下三层。
• 传输层协议运行在端系统上
• 为运行在不同主机上的应用进程之间提供逻辑通信

传输成的关键功能

将网络层在两个端系统之间的交付服务扩展到运行在两个不同端系统上的应用层进程之间的交互服务

传输成的面对基础问题

1. 两个实体怎样才能在一种会丢失的媒体上可靠地通信
2. 如何控制传输层实体的传输速率以避免网络拥塞，或从拥塞中恢复回来。

因特网的网络层为传输层提供服务，但是网络层协议IP为主机之间提供逻辑通信,IP的服务模型为尽力而为的交互服务，意味着IP并不确保主机之间报文段的交付, IP也被称为不可靠服务。

1.2 传输层的作用

• 向上层提供服务：以报文为单位提供进程与进程之间逻辑通信（不是主机之间的，而是不同主机上的应用进程之间）
  • 通过逻辑通信使运行在不同进程之间的主机，通过很多的路由器及各种类型的链路连接在一起
• 将报文(发送应用进程的数据)转换为报文段(传输层分组)
• • 运输层：为运行在不同主机上的进程之间提供逻辑通信
  • 网络层：为主机之间提供逻辑通信

1.3 传输层不同概念的区分

举一个例子，A家庭和B家庭，两个家庭之间同信，其中A家由Ann来收集自家的信件交给邮递员，B家庭由Bill负责，从邮递员手中收到信件分发给家庭中的每个成员,其中：

• 应用层报文 = 信封上的字符
• 进程 = 堂兄弟姐妹
• 主机(端系统) = 家庭
• 运输层协议 = Ann和Bii
• 网络层协议 = 邮政服务

传输层的两个主要协议

• 用户数据包协议UDP,
• 传输控制协议TCP,TCP分组被称为报文段
• 传输层协议是在端系统中实现而不是在路由器中实现。

应用程序的开发人员必须使用两种职业中的一种应用程序，开发者在声明套接字时必须指定选用UDP还是TCP。

1. 在端系统中，传输层协议将来自应用进程的报文移动到网络边缘(网络层)反过来也一样
2. 中间路由器及不处理也不识别运输层加在网络层报文上的任何信息。
3. 传输层协议还有很多，每种为应用程序提供不同服务。
4. 传输层协议常常受限于底层网络层协议服务模型

UDP与TCP概述

• UDP与TCP最基本的责任是将两个端系统间IP的[交付服务]扩展到运行在端系统上的两个进程之间的[交付服务]

UDP

• 一种无连接协议
  • 提供无连接服务
  • 在传送数据之前不需要家里连接
  • 传送的数据单位协议是UDP报文或用户数据报
  • 对方收到UDP报文后不需要给出确认
  • 不提供可靠传输，但在某种情况下是最有效的工作方式

TCP

• 一种面向连接的协议
  • 提供面向连接服务
  • 传送的数据单位协议是TCP报文
  • 该协议提供可靠的传输服务，因此不可避免增加了许多开销，

TCP提供的两种服务

1. 可靠传输服务
   通过流量控制、序号、确认、定时器，使数据正确的、按序的发送
2. 拥塞控制

• 传输层UDP用户数据报与网络层IP数据报有很大区别

  • IP数据报要经过互联网中很多路由器的转发
  • UDP用户数据报在传输层端到端抽象的逻辑信道中传送

• TCP报文段实在运输层抽象的端到端逻辑信道中传送，该信道是全双工信道，但这种信道却不知经过哪些路由器，而且这些路由器也不知道上面传输层是否建立了TCP连接。

传输层的端口

• 端口用16位端口号标记
• 端口号只有本地意义（未标记本计算机应用层中的各进程）
• 不同计算机相同端口没有联系。
  • 连个计算机互相通信不仅要知道IP地址，还要知道端口号

服务器端口号

客户端口号

2.多路复用与多路分解

• 将网络层提供的主机到主机的交付服务延伸到运行在主机上的应用进程提供进程到进程的交付服务。

多路分解

• 作用：将传输层报文段中的数据交付到正确的套接字。（每个报文段都有几个字段，传输层会检测这些字段，表示出套接字）

1. Bill把信从邮递员手里接过，分发到兄弟姐妹手里，就完成了分解操作

多路复用

1. 收集：在源主机不同套接字接收数据块
2. 封装：为每个数据块封装首部信息。
3. 生成：分装上首部信息后就成为报文段
4. 传递：将报文段传递给网络层
   以上的4个工作被称为多路复用。

• Ann把信从兄弟姐妹手里收集，并交给邮递员，他就执行了一个多路复用

套接字

套接字位于传输层及应用层之间，是一个应用编程接口， 应用程序通过调用此接口进行传输接收数据 。
传输层真正连接的是套接字，通过套接字将数据发送给特定的进程

• 同一台主机内应用层与传输层的接口。
• 进程是一座房子，套接字就像是门

注：

开发者可以控制套接字在网络层的一切，但是几乎不能控制传输层的套接字。

传输层多路复用的要求

1. 套接字有唯一的标识符
2. 每个报文段有特殊的字段来只是该报文段所要交付给的套接字
   这些特殊字段是源端口字段和目的端口字段

端口号：是一个16比特的数，大小在0 ~ 65535之间，0 ~ 1023为周知端口号，时受限制的，他们报留给应能用层协议使用（HTTP：80号端口）

在主机上的每个套接字能够分配一个端口号，当报文段到达主机时，传输层检查报文段中的目的端口号，并将其定向到相应的套接字。然后报文段中的数据通过不套接字进入其所连接的进程。

端口号是一个16比特的数，其大小在0_{65535之间，0}1023范围是端口号称为周知端口号是受限制的，它是指将它们保留给诸如HTTP( 80号端口)和FTP(21号端口)之类的周知应用协议来使用。

无连接的多路复用与多路分解

• A主机一个进程具有UDP端口19157，发送数据块给主机B中的进程UDP端口号46428
  1. 创建：A主机创建报文段（包含数据、源端口号、目的端口号）
  2. 传递：传输层将报文段传递给网络层
  3. 封装：网络层将报文段封装到IP数据报中，并尽力交付到主机
  4. 检查：B主机接收到后，传输层检查目的端口号（46428）
  5. 交付：根据目的端口号交付给端口号（46428）所对应的套接字

端口号的用途是:以源端口号作用"返回地址"的一部分B需要返回一个报文段给A时，B到A的报文段中目的端口，便从A到B的报文段中的源端口号中取值。

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

TCP套接字是由一个4元组(源IP地址，源端口号，目的IP地址，目的端口号)来标识的,当一个TCP报文段从网络到达主机时，该主机使用全部4个值来将报文段定向分解到相应的套接字，特别与UDP不同的是两个具有不同源IP地址与源端口号的到达TCP报文段，将被定向到两个不同的套接字，除非TCP报文段携带了初始创建连接的要求。

3. UDP用户数据包协议

UDP 概述

• UDP只在IP数据报服务之上增加了很少的一点功能,并没有对IP添加别的东西
  • 多路复用与多路分解
  • 差错检验
• 虽然UDP用户数据报只能提供不可靠的交付，但是UDP在某些方面有优点。

当选用UDP时，应用进程差不多就是直接与IP打交道，1. UDP从应用进程得到数据2. 附加上用于多路复用分解服务的源和目的端口号字段以及两个其他的小字段，然后3. 将形成的报文交给网络层。4. 网络层将该运输层报文段封装到一个IP数据报中，然后尽力而为的尝试，将此报文转付给接收主机，如果该报文到达接收主机UDP使用目的端口号将报文段中的数据交付给正确的应用进程。

UDP特点

• UDP是无连接的（发送数据前不需要连接，因此减少了开销和发送数据之前的延迟）
• 无连接状态。（UDP使用尽可能最大努力交付，不保证可靠交付，因此主机不需要维持复杂的连接状态）
• UDP是面向报文的。（对应用层交下来的报文不做处理，保留了报文的大小）
• UDP没有拥塞控制（网络出现阻塞不会是源主机的发送速率下降）
• 如果应用程序选择UDP，该应用程序差不多直接和IP打交道
• 分组首部开销小（TCP首部要20个字节，UDP首部8个字节）

使用UDP的应用也是可以通过应用程序本身建立可靠型机制来完成可靠数据传输

面向报文UDP

• 由于UDP对IP层数据报文去除首部后原封不动的交付给应用层
• 应用程序必须选择大小合适的报文
  • 太长: EUP给IP层后，IP层会进行分片，减低IP层效率
  • 太短：EUP给IP层后，IP数据报首部相对长度太大，降低了IP层效率

UDP报文段格式

UDP首部只有4个字节，32比特，每个字段有两个字节组成。

UDP检验和

• 作用：提供了差错检验功能，检验报文段在传输过程当中比特是否发生改变

4. 可靠传输的工作原理

• 可靠传输协议：rdt
• 面临的问题：可靠传输协议的下一层协议可能不可靠，但是上一层要求要可靠的传输。
• 不可靠因素：1. 出现比特损坏、2. 丢失分组

rdt函数

1. rdt_send():由应用层调用，功能是将数据直接交付给接收点的上层应用。
2. rdt_rcv():
3. deliver_data():由rdt调用，功能是将数据交付给上一层
4. udt_send():由rdt调用，将数据包通过不可靠传输信道传输给接收端
5. rdt_rcv():当数据报到达接收端后被调用
6. make_pkt():

rdt1.0 （经完全可靠的信道）

• 假设底层信道是完全可靠的（前提假设）
• FSM：有限状态机

1. 发送端：rdt通过rdt_send(data)事件，接收来自较高层的数据，产生一个包含数据的分组，并将分组发送到信道中。
2. 接收端：rdt通过rdt_rcv(packet)事件，从底层接受一个分组，从分组中取出数据，并把数据上传给较高层。

rdt2.0 (经具有比特差错的)

• 所有发送分组虽然有比特可能受损，但是按期发送的顺醋接收

ARQ协议

报文的接受者在接收报文后，会反馈一个肯定确认ACK或否定确认NAK，这样发送方可以知道那些内容需要重传，基于这种重传机制的可靠传输协议称为自动重传请求协议ARQ

• 滑动窗口协议较为复杂，是TCP协议的精华所在。
• 发送方维持窗口是为了，位于发送窗口内的分组可以连续发送而不需要等待对方确认，提高了利用率。
• 连续的ARQ协议规定，发送方收到一个确认就可以把发送窗口向前移动一分组。

ARQ协议还需要另外三种协议辅助来处理比特差错

1. 差错检验
2. 接收方反馈
3. 重传

rdt2.0 发送端的两种状态

1. 当发送给收到来自接收方的ACK分组，发送方知道发送分组也被正确接收，则分组回到等待来自上层的数据状态
2. 当发送给收到来自接收方的NAK分组，则发送方重传上一个分组，并等待来自接收方的ACK、NAK。

• 注意：当发送方处于停等状态时，发送方不能从上层在获得新的数据，只能等着，所以rdt2.0被称为停等协议

rdt2.0的缺陷

经上述描述看似rdt2.0已经能正常运行传输数据了，但是它还存在致命的缺陷

1. ACK与NAK可能受损（需要在ACK与NAK中添加检验机制）
2. 更难得是如何纠正ACK与NAK中的错误

解决rdt2.0的缺陷的方法

rdt2.1
当接收方收到不确定的ACK或NAK时，就重新传送当前分组，发方法会造成冗余分组，冗余分组的根本困难在于接收方无法知道上次的ACK或NAK是否被正确收到，所以无法知道该分组是新的还是重传。
解决放过：

• 发送方给发送分组编号，接收方只检验序号即刻知道该分组是新的还是重传（建立在ACK或NAK只相应最近发送的分组）

1. 当收到失续的分组，接收方发送一个肯定确认
2. 当收到受损的分组，接收方发送一个否定确认

rdt2.2
是在有比特差错的信道上实现的一个无NAK的可靠数据传输协议。

rdt3.0 （经具有比特差错的丢包信道的可靠传输）

丢包

• 发送方等待一定的时间，如果没有收到ACK,就重传分组。
  • 为实现重传功能，需要一个倒技术定时器。
  • 发送方只需要做到，1.每次发送一个分组时，便启动一个定时器。2.响应中断定时器。3.终止定时器

流水线可靠数据传输协议

• rtd3.0是一个停等协议，迫切的需要改变
• 流水线技术：不以停等方式运行，允许发送方发送多个分组而无需等待确认。

发送发同时发送多个分组，但每一个分组到达后，会反馈发送ACK，发送方接收发到ACK后，会发送下一份分组，一次同时多分分组在同时发送

1. 必须增加序号分为，每个分组必须有唯一一个序号。
2. 协议的发送接收方可能会缓存多个分组
3. 所需序号的范围和对缓冲的要求取决于数据传输协议如何处理丢失、损坏和延时过大的分组。解决错恢复的两种基本方法为：回退N步和选择重传

回退N步协议

• 允许发送方发送多个分组，而不需等待确认，但是未确定分组数也不能超多最大数N
  1. N被称作窗口长度
  2. GBN又被称作滑动窗口协议

GBN响应的三种类型

1. 上层调用：当上层调用rdt_send()时，发送方首先检验发送窗口是否已满，未满则发送，已满则将数据返回上一层，等一会再发；或者接收方缓存
2. 接受一个ACK：在GBN协议中，对N个分组的确认，再去累积确认的方式
3. 超时重传：但计时器超时，发送方再次发送已发送但是未被确认的信息，如果发送多分分组也只我用一个定时器。

选择重传 SR

在GBN中，发送反可以流水线的发送，但是缺点在于，当发送分组很多时，当有一个分组错误，就会导致大量分组重传，造成不必要的浪费

• 选择重传（SR）只重传他怀疑的分组，但是避免不了需要逐个的确认分组，再次用窗口长度N来限制流水线中分组的长度。
• SR接收方确定一份分组的正确，不管是否时序，时序的分组，将缓存，知道所有分组到齐，才将一批分组交付

1. 从上一层接收数据：SR检查序号，如果序号在发送分组内，打包发送；如果不在，就像GBN一样要么缓存，要么返回给上一层。
2. 超时：防止丢失分组，每个分组都要拥有一个自己的定时器，因为重传只能发送一个分组。
3. 接收ACK:接收ACK时，如果序号在窗口内，该分组被标记接收；如果序号等于send_base()则 窗口基序号向前移到具有最小序号的未确认分组处；如果窗口有一些序号落在窗口外，则发送这些分组。

SR发送方事件与动作

1. 序号在[rcv_base,rcv_base+N-1]被正确接收：如果该分组以前没接受过，则缓存该分组；如果分组序号等于接收窗口，则接收窗口安向前移动的序号向上交付分组。
2. 序号在[rcv_base-N,rcv_base-1]被正确接收:产生一个ACK，及时发分组已被确认
3. 其他情况忽略该分组

累计确认

• 按顺序发送的分组最后一个分组发送确认，表示这个分组前所有分组都以确认收到。
  • 当前5个分组发送完，而中间第三个分组丢失，这时发送方会把从第3个分组往后的所有分组从新传输一次。叫做（Go-back-N）
  • 可见通信链路质量不好时，连续的ARQ协议会带来负面影响。

TCP可靠传输的具体实现

• 一个发送窗口和一个接收窗口
• 依靠字节的序号进行控制，而不是基于报文段（TCP所有序号都是基于序号）
• TCP两端的四个窗口处于动态变化中
• TCP连接的往返时间RTT也是不固定的，需要使用特定的算法估算较为合理的重传时间

可靠数据传输机制和用途

5. TCP协议

TCP最主要的特点

• TCP是面向连接的传输层协议
• TCP连接只能点对点，一对一，不能多播
• TCP提供可靠交付的服务
• TCP提供全双工通信
• TCP面向流
  • “流”指流入或流出程序的字节序列
  • TCP面向流：TCP把应用程序传下来的数据块仅看成一串无结构的字节流

TCP面向流的概念

• TCP不保证接收方和发送发的数据块大小对应关系
• 但是能确保接收方和发送发的数据流完全一样
• TCP链接是一条虚连接，而不是一条真正的物理连接
• TCP不关心一次把多长的报文发送到TCP的缓存区
• TCP根据对方的窗口值和当前网络拥塞程度，来决定一个报文段应包含多少个字节。
• TCP可把太长的数据块 分短一些在发送。
• TCP可等待积累足够多的字节后在构成报文段发送出去。

TCP的连接

• TCP被称为面向连接的，是因为一个应用进程向另一个进程发送数据之前必须要“握手”（互相发送预备报文段已建立确保数据传输的参数）。
• TCP把连接作为最基本的抽象
• TCP连接总是点对点的
• TCP连接的是套接字或插口。（不是主机，不是IP地址，不是应用进程，不是传输层协议端口）
  • 套接字：IP地址和端口号的组合，通过IP地址确定唯一主机，又通过端口来确定确定唯一主机的唯一端口唯一进程
• TCP只在端系统中运行，而不再中间网络元素中运行，所以中间网络不会维持TCP连接状态（中间路由器对TCP连接视而不见，他们看的是数据报而不是连接）
• TCP提供全双工服务，连接双方的进程可以相互交付数据
• 发起连接的为客户端，另一个进程为服务器端

TCP连接的建立

1. 首先客户首先发送一个特殊TCP报文段
2. 服务器用一个特殊的报文段相应
3. 最后三次握手建立连接
   三次握手：客户用三个特殊的报文端作响应，前两个不承载负荷，不包含应用层数据，第三个个即承载又包含
4. 建立连接后连个进程就可以发送数据了
5. 用户数据通过套接字后，就由客户中的TCP控制了，TCP将数据引导到发送缓存中。（发送缓存在三次握手期间设置的缓存之一）
6. 接下来TCP会不时地从发送缓存里取出数据，交给网络层

• 最大传输长度MSS：限制TCP从缓存中取出报文段的数据量，该值通常由本地主机发送的最大链路层桢长度决定

TCP报文的交互过程

1. TCP为每块客户数据配上一个TCP首部，从而形成多个TCP报文段
2. 这些报文段被下传给网络层，网络层将其分别封装在网络层IP数据报中，然后这些IP数据报被发送到网络中
3. 当TCP在另一端收到一个报文后，该报文段的数据被放入该TCP连接的接收缓存中。应用程序从此缓存中读取数据流

该连接的每一端都有，各自的发送缓存和接收缓存。

TCP报文段的首部

• TCP为每个客户数据配上TCP首部形成TCP报文段
• TCP报文段下传给网络层，网络层将其封装在网络层IP数据报中，然后将IP数据报发送到网络中
• TCP首部一般20个字节，UDP一般为8个
• TCP面向字节流，

1. TCP首部包括源端口号和目的端口（用于多路复用与分解）
2. 包含检验和字段(和UDP一样)
3. 32比特的序号字段和32比特的确认号字段（用来实现可靠传输）
4. 16比特的接收窗口字段（用于流量控制）
5. 4比特的首部长度字段（TCP首部长度可变，因为有选项字段）
6. 选项字段用于发送发与接收方协商最大报文长度MSS；高速网络下作用窗口调节因子
7. 6比特标志字段确认时段中的值是有效的

以太网和PPP链路层协议都具有1500个字节的最大传输单元MTU,TCP手部长度通常40个字节。,因此最大报文长度MSS的经典值为1460个字节。

序号与确认号

• 这两个字段是TCP可靠传输的关键部分
• TCP把数据看成无结构（一长串的）、有序的字节流，序号建立在字节流之上，而不是报文段的序列之上。

TCP把数据看成是一个无结构的、有序的字节流，假设数据流由一个包含5万个字节的文件组成，由于MSS为1000个字节，所以每1000个字节被分成一个报文段，第1个报文段分配的序号是0，第2个报文带分配的序号是1000，第3个报文段分配的序号是2000，以此类推。

当主机A发送数据报到主机B时，主机B接收到数据包后返回给A一个确认号，该确认号是主机A希望从主机B收到的下一个字节的序号，该序号为确认号

当主机a在收到第2个报文段之前，收到了第3个报文段，因此第3个报文段失序到达,该问题的解决主要采取: 接收方保存秩序的字节并等待缺失的字节以填充该间隔。

往返时间的估算与超时

• 大多数TCP的实现仅在某个时刻做一次SampleRTT测量，而不是每次发送报文都做一次测量

TCP可靠传输的实现

• IP不保证数据报的交付，也不保证数据报的交付，还不保证数据报中数据的完整性
• TCP要在IP不可靠的基础上建立可靠的数据传输，确保数据流无损坏、无间隙、无冗余、按序。

TCP发送方三个与发送重传的主要事件
第一：TCP从程序接收数据，将数据封装到一个报文段中，并把报文段交给IP
第二： 超时，TCP通过重传引起超时的报文段
第三：到达一个来自接收方的确定报文。

超时间加倍

• 在定时器时限过期后，超时间隔时间会加倍。
  • 每次他TCP重传下一次的超时间隔都会上一次的一倍
• 因此超时间隔在每次重传后都呈指数增长

快速重传

• 当一个报文段丢失时，这种长超时周期迫使发送方延时重传丢失分组，因而增加了端到端的延时。

冗余ACK

• 再次确认某个报文段的ACK,尽管发送方之前已经收到对该报问的确认

为什么需要冗余ACK？

当发生报文段丢失时，可能是由于网络中的报文段丢失或重新排序造成的，因为TCP不使用否定确认，只能对已经收到的报文段进行确认。

当发送方大量的发送报文，如果其中一个报文丢失，就可能引起许多冗余ACK，如果TCP发送方接收到对相同数据的三个除以ACK，这就说明跟这个已被确认的三个确认的报文段之后的报文已经丢失，一旦收到三个冗余ACK，TCP就执行快速重传（在该报文段的定时器过期之前重传丢失分报文）

回退N步(GBN)还是选择重传(SR)

回退N步：当发送方发送一个分组报文段1，2…N，并且所有的报文段都按序无差别的到达接收方，进一步假设对分组n(n<N)的确认报文段丢失，但是其余N-1确认报文，在分组超时之前已到达接收端。在概率中这边不仅会重传第n个分组,还会重传后续所有的n+1,n+2…N。

选择重传：它允许TCP接收方有选择的确认时序报文段，而不是累积的确认，最后一个正确接收的有序报文段。

• TCP发送方仅需要维持已发送过但是未被确认的字节的最小序号和下一个发送字节的序号
• TCP确认是累积的，正确但失序的报文不会被接收方逐个确认
  看似TCP需要GBN风格的协议，但是二者有一些明显的差距，TCP会正确的接收
• GBN不仅会重传分组N还会重传后继的分组
• SR它允许接收方有选择的正确接收失序报文段，而不是累积的确认最后一个正确接收的有续报文段
• TCP差错恢复机制也许最好是GBN和SR的混合体

流量控制

TCP发送网可能因为IP网络的拥塞而被抑制，这种形式的发送方的控制被称为拥塞控制。

当应用程序的接收方读取速率缓慢，发送方发送的又很多，很容易造成接收方缓存溢出，流量控制服务是一个速度匹配服务，，是发送防御接收方的读取速度相匹配。

接收窗口：可以只是接收方还有多少缓存空间（TCP连接的每一侧都有缓存空间，来来缓存正确接收的数据）他是动态的

A向B发送一个大文件

• LastByteRead：主机B上的应用进程从缓存读取的数据流的最后一个字节的编号
• LastByteRcvd：从网络中到达的并且已放入主机B接收缓存中的数据流的最后一个字节的编号
• rwnd：接收窗口
• RcvBuffer：接收缓存

TCP不允许缓存溢出,所以要满足：
LastByteRcvd-LastByteRead<=RcvBuffer

接收窗口表示：

rwnd=RcvBuffer-[LastByteRcvd-LastByteRead]

• UDP并不提供流量控制，报文段由于缓存溢出可能在接收方丢失

TCP连接管理（TCP建立与拆除）

TCP的建立

• 第一步： 客户端TCP首先向服务器的TCP发送一个特殊的TCP报文段SYN报文段

  1. 该报文段不包含应用层数据，但是报文段首部有一个标志位SYN比特被置为1。
  2. 客户选择一个初始序号并放在TCP SYN 报文段的序号字段中
  3. 该报文段会被分装在IP数据报中，发送给服务器

• 第二步：一旦包含TCP SYN 报文段的IP数据报到达服务器，服务器会将数据报中TCP SYN 报文段提取出来，为TCP分配TCP缓存和变量，并向客户TCP发送允许连接的报文

  • 这个允许连接的报文，不包含应用层信息，但包含3个重要信息。
    1. SYN被置为1
    2. TCP报文首部的确认号字段被置为client_isn+1
    3. 服务器选择自己的初始序号，并交其放置在TCP报文首部的序号字段中

该报文表明我收到你建立的SYN分组，该分组初始序号为client_isn.我同意连接。我的初始序号为swever_isn.他允许连接的报文段为被称为SYNACK报文段。

• 第三步：接收到SYNACK报文段后客户也要给连接分配内存和变量。客户则向主机发送另外一个报文段，该报文段对服务器的允许连接的报文进行确认。（连接建立SYN报文段被置为0，三次握手的第三个阶段可以再报文段负载中携带客户到服务器的数据信息）

经历这三步后客户服务器之间就可以发送数据了，由于在三步中二者之间发送了3个分组，这种连接也被称为三次握手

TCP连接的拆除

• 双方任何一方都可以终止连接

当客户要结束连接时

1. 客户TCP发出特殊的TCP报文段，该报文段让其首部FIN比特置为1。
2. 服务器接收到该报文，响应一个去人报文ACK
3. 服务器发送一个终止报文，其FIN比特被设置为1.
4. 客户对这个终止报文确认，此时两者之间所有资源被释放。

• TCP连接声明周期中的状态
  1. CLSDED状态：关闭状态——【开始时】
  2. SYN_SENT状态：等待来自服务器TCP发送来的SYN被置为1的报文——【客户向向服务器发送一个SYN报文段后进入该状态】
  3. ESTABLISHFED状态：TCP客户就能发送和接收TCP报文段了——【收到SYN被置为1的报文后进入该状态】

服务器要结束连接时

1. TCP发送一个带有FIN被置为1的TCP报文
2. FIN_WAIT_1状态：客户TCP等待来自服务器带有确认的TCP报文段——【TCP发送一个带有FIN被置为1的TCP报文进入该状态】
3. FIN_WAIT_2状态：客户等待来自服务器的另一个报文，当客户收到报文，客户TCP对服务器报文进行确认，并进入下一状态【收到确认报文后进入该状态】
4. TIME_WAIT状态：若ACK丢失，该状态会使TCP客户重传确认报文（该状态所消耗的时间因具体情况而定）

7. TCP的流量控制

利用滑动窗口控制流量

• 当我们希望发送数据很快的时候，若接收方接收速度跟不上就会造成数据丢失。
• 流量控制：让发送方以合适速度发送，让接收方来得及接收，同时不要使网络发生拥塞。
• 利用滑动窗口机制可以很方便的在TCP连接上实现流量控制

持续计时器

1. TCP位每一个衔接设置一个持续计时器。
2. 只要TCP连接的一方的零窗口通知，就启动持续计时器
3. 计时器设置时间到期，就发送一个零窗口探测报文段（仅带一个字节），接收方在确认这个报文段时给出现在的窗口值。
4. 若窗口值仍为零，发送方重设一个持续计时器
5. 若窗口不为零，可锁死就会打破。

传输效率

• 用不同的机制控制TCP报文段的发送机制
  • 第一种机制：TCP维持一个变量，缓存中的数据达到最大报文长度MSS字节时，就组装成一个TCP报文发送出去
  • 第二种机制：是由发送方的应用进程指明要求发送报文段，
  • 第三种机制：发送方的一个计时器期限到了，就发当前缓存的发送出去

8. 拥塞控制

1. 拥塞控制原理

情况1：两个发送方与一台具有无穷缓存的路由器

• 无穷大缓存能力意味着分组不会丢失
  当两台主机在一个容量为R的链路上时：
  1. 当发送速率在0～Ｒ/2之间时，两者发送与接受速率相同，经有限时间数据可以到达接收方。
  2. 当发送速大于Ｒ/2时，吞吐量只能到达Ｒ/2(该吞吐量上限是由链路的容量造成的)。
• 链路的容量接近Ｒ/2时，平均时延会越来越大。
• 链路的容量超过Ｒ/2时，时延会无穷的大，相当于断路。

情况2：两个发送方与一台具有有限缓存的路由器

• 当一个分组到达已满的缓存时会被丢弃，之后会重传该分组（重传会导致数据量跟多，所以更讨小心）。
• 我们用λ的字节每秒表示应用程序，将初始数据发送到套接字中的速率。运输层向网络中的发送报文段的速率，λ有时也被称为网络的供给载荷。

在情况二下实现的性能，强烈的依赖于重传方式。

情况3：4个发送方与具有有限缓存的多台路由器及多条路径

拥塞控制方法

1. 端到端的拥塞控制

   • 该方法中网络层中没用为运输层提供拥塞控制的支持，当发现拥塞，网络层也必须通过观察的形式判断。
   • TCP采用端到端的方式来解决拥塞控制，因为IP层不会向端系统提供网络拥塞显示反馈信息。
   • 当TCP报文段丢失，超时或3次冗余确认，被认为是拥塞，TCP会相应的减小窗口长度。

2. 网络辅助的拥塞控制

   • 路由器发送方会提供网络中拥塞的显示反馈信息。（该信息简单，用一个比特来指示）

   反馈信息有两种形式：

   1. 直接反馈信息：有网络路由器发给发送方。
   2. 路由器标记或更新从发送方流向接收方的分组中的某个字段来指示拥塞的产生，一旦收到一个标记的分组后，接收方就会向发送方通知该网络拥塞指示。

TCP的拥塞控制

• TCP采用端到端的方式来解决拥塞控制，而不是网络辅助的拥塞控制，因为IP层不会向端系统提供网络拥塞显示反馈信息。

TCP让每一个分组感知拥塞程度来限制发送速率，该方法面临三个问题

1. 发送方如果限制它向其连接发送流量的速率
2. 如何感知发送过程中的拥塞
3. 感知到拥塞后，采用何种算法改变发送速率

• cwnd：拥塞窗口
  他对一个TCP发送方能向网络中发送流量的速率进行限制。
• rwnd：接收窗口

TCP发送方的"丢包事件"的定义:要么出现超时，要么收到来自接收方的三个冗余ACK。

TCP拥塞控制算法

• 核心算法包括三个部分:1. 慢启动（指数型增长）2. 拥塞避免（+1增长）3.快速恢复。

1.慢启动

1. 开始cwdn的值被设置为1（1个MSS，如果MSS=500字节，RTT=200ms，则得到的初始发送速率为20kbps）
2. 当收到上一次发送的确认之后，下一次的cwdn被设置为上一次的2倍，这样指数型的增长下去。
3. 这种增长也不会一直的持续下去，ssthreish(慢启动阈值)，当到达该值后（cwdn=ssthreish），慢启动会缓慢的，每次只+1的向上增加（拥塞避免）。
   • 当出现超时指示的丢包事件，TCP发送方将cwnd设置为1,记录发生超时时cwnd的值,ssthreish的值会被重新设置为cwnd/2,并重新开始慢启动过程.
   • 当检测到网络拥塞(出现三个ACK时)，将检测到超时时，ssthresh设为cwnd/2,这时cwnd的值也cwnd/2,因此当cwnd=ssthresh时结束慢启动，并且TCP转移到拥塞避免模式(+1增长)

2. 拥塞避免

一旦进入拥塞避免状态，cwnd的值大约为上次cwnd的1/2，不能盲目的进行指数增长，所以在每个RTT只将cwnd的值增+1。
当丢包事件出现时，ssthresh的值被更新为cwnd值的一半。然而前面讲过丢包事件也能由一个三个冗余ACK事件出发。

• TCP对超时指示的丢包要比由三个冗余ACK的丢包反应要更加的强烈。

出现超时指示的丢包，cwnd的值将被设为1。
出现三个冗余ACK, cwmd的值将会减半。

3. 快速恢复

如果出现超时事件，快速恢复再执行，同在慢启动和拥塞，避免中相同的动作后迁移到慢启动和拥塞避免种相同的状态，当丢包事件出现是cwnd的值被设置为一个MSS并且ssthresh的值被设置为cwnd值的一半。

9.TCP的运输连接管理

TCP连接建立要解决的三个问题

• 双方能够确定对方的存在
• 允许双方协商一些参数
• 能够对运输实体资源进行分配

三报文握手

• TCP连接的过程叫握手
• 握手需要在客户和服务器之间交换三个TCP报文
• 主要为了防止已失效的链接请求报文段突然又传过来，产生错误。

TCP的间接释放

• 数据传输结束，通信双方都可以释放连接
• TCP链接释放过程是四报文握手