/auther:Zynu11/

    1. 运输层的任务（功能）是什么

    提供进程到进程的通信，将网络层的在两个端系统之间的交付服务拓展为运行在两个不同端系统上的应用层进程之间的服务，IP的服务模型是尽力而为交付服务

    1. 应用层协议是在端系统中实现的而不是在路由器中实现的
    2. 运输层和网络层的关系

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

    1. 运输层有哪两种服务

    TCP：传输控制协议，报文段UDP：用户数据报协议，数据报

    1. TCP协议的特点是什么
      1. 面向连接
      2. 可靠数据传输
        1. 流量控制
        2. 序号
        3. 确认
        4. 定时器
      3. 流量控制
      4. 拥塞控制（其实是提供给整个互联网的服务）
    2. UDP仅能提供的两种服务
      1. 进程到进程的交付
      2. 差错检测
    3. UDP协议的特点是什么
      1. 无连接
      2. 不可靠
    4. 多路复用与多路分解

    通过套接字，一个进程有一个或者多个套接字，主机运输层接收或者发送信息实际上并没有直接将数据交付给网络层，而是将数据交付给了一个中间的套接字或者通过套接字来接收信息，每个套接字都有唯一的标识
    多路复用：源主机从不同套接字中收集数据块，并为每个数据块封装上首部信息从而生成报文段，然后将报文段传递到网络层，这个过程就叫做多路复用
    多路分解：接收端，主机收到报文段时，运输层检查这些字段，标识出接收套接字，进而将报文段定向送到该套接字，这个过程就叫做多路分解

    1. 运输层多路复用要求
      1. 套接字有唯一标识符
      2. 每个报文段有特殊字段来指明报文段所要交付到的套接字
    2. TCP套接字

    一个四元组：源IP，源PORT，目标IP，目标PORT用四个值来将报文段定向到响应的套接字，但是与UDP不同的是，两个具有不同源IP地址和源port的到到达TCP报文将被定向到两个不同的套接字，除非TCP报文段携带了初始创建连接的请求

    1. UDP套接字

    一个二元组：目标IP，目标PORT如果两个UDP报文段有不同的源IP地址或者PORT，但是具有相同的目标IP和目标PORT，那么这两个报文将通过相同的目的套接字被定向到相同的目的进程

    1. 连接套接字与进程之间并非总是一一对应的关系

    事实上，当今的高性能Web服务器通常只有一个进程，但是为每个新的客户连接创建一个具有新连接套接字的新线程，对于这样的一台服务器，在任意给定的时间内都可能有许多连接套接字连接到相同的进程

    1. HTTP为什么在新版本中改为了持续连接

    如果使用非持续连接，对每一对请求/响应都要创建一个新的套接字并在随后关闭，套接字的频繁创建和关闭会严重的影响一个繁忙的Web服务器的性能。

    1. UDP相对于TCP的优势
      1. 关于发送什么数据以及何时发送的应用层控制更为精细采用UDP时，只要应用进程将数据传递给UDP，UDP就会将此数据打包进UDP报文并立即将其传递给网络层，实时应用通常要求最小的发送速率，且能容忍一些数据丢失，不希望过分地延迟报文段的发送
      2. 无需建立连接UDP不会引入建立连接的时延，这也是DNS采用UDP而不是TCP的原因，如果运行在TCP上，则速度会慢上很多，HTTP使用TCP而不是UDP是因为对于具有文本数据的Web网页来说，可靠性是至关重要的
      3. 无连接状态TCP需要在端系统中维护连接状态，此连接状态包括接收和发送缓存，拥塞控制参数以及序列号与确认号的参数
      4. 分组首部开销小TCP首部有20字节的首部开销，UDP首部只有8字节的开销
    2. UDP报文段结构image.png
    3. UDP校验和

    UDP校验和提供了差错检测服务，但是它对差错恢复无能为力原因：不能保证源和目的主机之间的所有链路都提供差错检测，也就是说，也许二者之间的链路中的某一条可能使用没有差错检验的协议，再者，机试报文段经过链路正确的传输，当报文段储存在某台路由器的内存中时也可能印出比特差错image.pngimage.png

    1. 可靠数据传输

    数据 “不多”“不少”：“不乱”“不错”

    1. RDT发展过程
      1. RDT 1.0（经完全可靠信道的可靠数据传输）不必担心出现差错，接收端就不需要提供任何反馈信息给发送方
      2. RDT 2.0（经具有比特差错信道的可靠数据传输，数据仍然假设按照顺序到达，停等协议）在分组的传输，传播和缓存的过程中，可能出现比特差错引入“肯定确认ACK”“否定确认NAK”机制，接收方收到报文后检测是否出现差错，无差错发送ACK，出现差错发送NAK，这些报文使得接收方可以让发送方知道哪些内容出现差错并对出错内容进行重发，基于这样的可靠数据传输协议被称为“自动重传请求协议ARQ”ARQ协议中还需要另外三种协议功能来处理存在比特差错的情况
        1. 差错检测，需要额外的比特
        2. 接收方反馈，需要ACK，NAK，只需要一个比特长度，0表示NAK，1表示NAK
        3. 重传
      3. RDT 2.1但是RDT 2.0存在致命的缺陷，没有考虑到ACK，NAK报文受损的情况，引入“序号”机制，在此情况下，一比特序号足够使用
      4. RDT 2.2在RDT 1.1的基础上实现的一个无NAK的可靠报文传输协议，需要发送方进行重传的时候只需要发送上一个分组的ACK确认消息即可
      5. RDT 3.0（经具有比特差错的丢包的可靠数据传输，分组序号01交替，比特交替协议）假如发送方发送一个数据分组，该分组或者接收方对该分组的ACK发生了丢失，在这两种情况下，发送方都收不到应到到来的接收方的响应引入“超时重传”机制，需要一个“倒计数定时器”时间设置为一个RTT＋一个分组处理时间，每次发送一个报文便单独设置一个定时器，超过定时时间未收到接收方响应，便重传报文
    2. 流水线可靠数据传输协议

    RDT 3.0是一个功能正确的协议，但是由于RDT 3.0是一个停等协议，所以它的性能有瓶颈引入流水线协议：

    1. 需要增加序号范围
    2. 协议的发送方和接收方两端要缓存多个分组
    3. 所需序号范围和对缓冲的要求取决于数据传输协议如何处理丢失，损坏，及延时过大的分组
      1. 流水线差错恢复的两种基本方法
    4. 回退N步
    5. 选择重传
      1. 回退N步GBN（滑动窗口协议）的原理

    一个序号为n的分组被正确接收到，并且按序，则接收方为分组n发送一个ACK，并将该分组中的数据部分交付到上层，在所有其他情况下，接收方丢弃分组，并为最近按序接收的分组重新发送ACK，因为是一次交付给上层一个分组，如果分组k已接收并交付，则所有比k小的分组也已经被接收优点：接收缓存简单，接收方不需要缓存任何分组缺点：分组乱序到达，丢弃一个正确接收的分组意味着随后要对该正确的分组进行重传，但是随后的重传可能出错从而导致更多的重传

    1. 选择重传SR的原理

    在Go Back N协议中，单个分组的差错可能引起GBN重传大量分组，但是很多分组完全没有必要重新传输，SR协议顾名思义，就是让发送方选择性的重传那些它怀疑在接收方出错的分组，SR接收方的接收窗口大于1原理：SR收到一个正确但是失序的分组时将其存在缓冲区中，失序的分组直到所有序号更小的分组被全部正确接收时一并交付给上层

    1. SR协议的潜在风险是什么

    对于哪些分组被正确接收，哪些没有，发送方和接收方并不总能看到相同的结果，这就导致发送窗口和接收窗口并不总是一致，当面对序号有限时，窗口不一致会面临巨大的风险：没有办法区分是第一个分组的重传还是新的的分组的初次传输

    1. SR风险解决的办法

    窗口长度必须小于或者等于序号空间的一半

    1. TCP是积累式的，使用GBN协议
    2. TCP的特点
      1. 面向连接
      2. 全双工
      3. 点对点
      4. 可靠数据传输
      5. 流量控制
      6. 拥塞控制
    3. MSS最大报文长度

    MSS通常根据最初确定的由本地发送主机的最大链路层帧长度（最大传输单元MTU）MSS典型值为1460 bytes，TCP/IP首部为40字节，注意MSS是指在报文段里应用层数据的最大长度，而不是指包括首部的TCP报文段的最大长度

    1. TCP报文段结构

    image.png

    1. 估计往返时间

    image.pngimage.png

    1. 超时间隔加倍

    每当超时事件发生时，TCP不使用由EstimatedRTT和DevRTT推算出来的数值，而是为先前数值的二倍，之所以这样做是因为，如果进行相同间隔的重传，会加剧网络的拥塞情况

    1. 快速重传

    使用冗余ACK，当发送方连续收到同样三个对上一个报文的ACK时，便在该报文段的定时器过期之前进行重传

    1. 什么是流量控制

    消除发送方发送速率过快使接收方缓存溢出的可能性

    1. 流量控制原理

    TCP让发送方维护一个称为接收窗口的变量来提供流量控制，接收窗口用于给发送方一个指示，该接收方还有多少可用的缓存空间，TCP是全双工通信，接收方向发送方发送响应报文时，响应报文里面会带有这个参数当接收主机接收窗口为0时，发送主机继续发送只有一个字节数据的报文段，这些报文段最终会被接收方确认，最终缓存将开始清空，并且确认报文里将包含一个非零的接收窗口的参数。

    1. TCP发起连接

    三次握手第一步：客户端的TCP首先向服务器端的TCP发送一个特殊的TCP报文段，该报文段中不包含应用层数据，但是在报文段的首部，SYN位被设置为1，因此该报文段被称为SYN报文段，会随机选择一个初始序号第二步：一旦包含TCP SYN的报文段的IP数据报到达服务器主机，服务器主机会提取出TCP SYN报文段，为该TCP连接分配TCP缓存和变量，并向客户TCP发送允许连接的报文段，这个报文段也不包含应用层数据，SYN被设置为1，ACK为客户端seq_client+1，随机选择一个初始序号，该报文段被称为SYNACK报文段第三步：客户端接收到SYNACK报文段后为客户端分配缓存和变量，接着向服务器端发送一个报文，ACK=seq_server+1，SYN=0之后的每一个报文段，SYN都将为0传输层 - 图7

    1. 为什么是三次握手而不是两次握手

    为了防止已失效的连接请求报文段突然又传送到了服务端，因而产生错误client发出的第一个连接请求报文段并没有丢失，而是在某个网络结点长时间的滞留了，以致延误到连接释放以后的某个时间才到达server。本来这是一个早已失效的报文段。但server收到此失效的连接请求报文段后，就误认为是client再次发出的一个新的连接请求。于是就向client发出确认报文段，同意建立连接。假设不采用“三次握手”，那么只要server发出确认，新的连接就建立了。由于现在client并没有发出建立连接的请求，因此不会理睬server的确认，也不会向server发送数据。但server却以为新的运输连接已经建立，并一直等待client发来数据。这样，server的很多资源就白白浪费掉了。采用“三次握手”的办法可以防止上述现象发生。例如刚才那种情况，client不会向server的确认发出确认。server由于收不到确认，就知道client并没有要求建立连接。

    1. 为什么不是四次握手

    三次握手便可以建立起可靠的连接，四次握手浪费资源

    1. 为什么需要初始序号

    一方面是为了防止连接失效后SOCKET被重用使得以前残留的包被错误的接受另一方面是为了防止黑客轻易的知道序列号之后制造tcp序列号攻击

    1. TCP连接关闭

    四次挥手第一步：客户端向服务器端发送FIN位置1的报文段第二部：服务器发送ACK第三部：服务器向客户端发送FIN位置1的报文段第四步：客户端发送ACK

    1. 为什么TCP连接关闭是四次挥手

    因为TCP是全双工通信的 （1）第一次挥手因此当主动方发送断开连接的请求（即FIN报文）给被动方时，仅仅代表主动方不会再发送数据报文了，但主动方仍可以接收数据报文。（2）第二次挥手被动方此时有可能还有相应的数据报文需要发送，因此需要先发送ACK报文，告知主动方“我知道你想断开连接的请求了”。这样主动方便不会因为没有收到应答而继续发送断开连接的请求（即FIN报文）。（3）第三次挥手被动方在处理完数据报文后，便发送给主动方FIN报文；这样可以保证数据通信正常可靠地完成。发送完FIN报文后，被动方进入LAST_ACK阶段（超时等待）。（4）第四挥手如果主动方及时发送ACK报文进行连接中断的确认，这时被动方就直接释放连接，进入可用状态。

    1. 网络拥塞发生的原因
      1. 链路容量有限，分组的速率接近链路容量时，分组经历巨大的排队时延，网络发生拥塞
      2. 路由器缓存有限，分组被丢弃，分组重传增大链路负担
    2. 网络拥塞的代价
      1. 分组的到达速率接近链路容量时，分组经历巨大的排队时延
      2. 发送方必须执行重传以补偿因为缓存溢出而丢弃的分组，会带来额外的开销
      3. 网络拥塞时，会发生大量的超时重传，链路不得不牺牲一些带宽来重发超时的分组
      4. 当一个分组沿着一条路径被丢弃时，每个上游的路由器用于转发该分组到丢弃分组而使用的传输流量最终被浪费了
    3. 拥塞控制方法
      1. 端到端拥塞控制，网络层没有为传输层拥塞控制提供显示支持，即使网络中存在拥塞，端系统也必须通过对网络行为的观察来推断
      2. 网络辅助的拥塞控制，路由器向发送方提供关于网络中拥塞状态的显示反馈信息
        1. 直接反馈信息由网络路由器发送给发送方
        2. 路由器标记或者更新从发送方流向接收方的分组中的某个字段来指示拥塞的产生
    4. 一个TCP发送方如何限制向其他连接发送流量的速率？

    运行在发送方的TCP拥塞控制机制跟踪一个额外的变量，这个变量叫做拥塞窗口，cwnd，它对一个TCP发送方能向网路中发送流量的速率进行了显示，发送方中未被确认的数据量不会超过cwnd和rwnd的最小值

    1. 一个TCP发送方如何感知从它到目的地之间的路径上存在拥塞呢？

    超时或者收到3个冗余ACK

    1. 发送方怎么样确定应当发送的速率呢
      1. 报文丢失意味着拥塞，当报文丢失时应当降低TCP发送方的速率
      2. 未确认报文段的确认到达时，应该增加发送方的速率
      3. 带宽探测
    2. TCP拥塞控制算法
      1. 慢启动阶段
      2. 拥塞避免阶段
      3. 快速恢复阶段
    3. 慢启动阶段

    一开始以一个MSS的速率发送，随后每次变为原来的二倍，发送速率以指数增长
    增长结束阶段：
    方法一：如果存在一个由超时指示的丢包事件，TCP发送方将cwnd设置为1，重新开始慢启动阶段，将第二个状态变量的值设置为ssthresh=cwnd/2，即检测到拥塞时将ssthresh置为拥塞窗口值的一半
    方法二：直接与ssthresh的值相关联，检测到拥塞时ssthresh的值设为cwnd的一班，当到达或则超过ssthresh时，转移到拥塞避免模式
    方法三：检测到三个冗余ACK，执行快速重传并进入快速恢复状态

    1. 拥塞避免阶段

    一旦进入拥塞避免状态，cwnd的值大约是上次遇到拥塞时的一半，距离拥塞并不遥远，此时每个RTT只将cwnd增加一个MSS，结束状态与慢启动结束方法一样

    1. 快速恢复阶段

    在快速恢复中，对于引起TCP进入快速恢复状态的缺失报文段，对收到的每个冗余的ACK，cwnd增加1个MSS

    1. TCP拥塞控制整体过程

    一开始是慢启动阶段，然后每个RTTcwnd线性增加一个MSS，然后出现3个冗余ACK时减半，然后重复。

    1. 公平性

    如果每条连接的平均传输速率接近R/K，即每条连接都得到相同份额的链路宽带，则认为该拥塞机制是公平的