传输层--计算机网络自顶向下笔记（三）

简介

服务

• 最基本的职责是将两个端系统间IP的交付扩展为运行在端系统上的两个进程的交付，即运输层的多路复用（transport-layer multiplexing）和多路分解（demultiplexing）。
  
  • 一个进程拥有一个或多个套接字（socket），是进程和网络之间传递数据的门户。比如某些Web服务器通常只使用一个进程，但是为每个客户创建一个具有新连接套接字的线程。
  • UDP套接字是一个二元组标识，包括：目的IP、目的端口号。
  • TCP套接字是一个四元组标识，包括：源IP、源端口号、目的IP、目的端口号。
• 进程到进程的数据交付和差错校验是最低限度的运输层服务。
• 一个端口扫描工具：nmap。

和网络层的关系

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

• 一个有趣的类比（page 124）：两个家庭分别有12个兄弟姐妹，每个人之间都要互相写信。Ann和Bill负责收集各自家庭的信，然后交到邮政服务的邮车上。则：

  网络	家庭
  应用层报文	信件内容
  进程	兄弟姐妹
  主机（端系统）	家庭
  运输层协议	Ann和Bill
  网络层协议	邮政服务

• 运输层提供的服务受制于网络层，但是可以提供网络层不能提供的服务。

应用层对应的协议

UDP

优点

1. 由应用层控制数据发送的时间和内容会更为精细。
   
   • TCP的可靠传输和拥塞控制机制可能过分的延迟报文段的交付。实时应用不能过分延迟交付且可以容忍一定的数据丢失。
   • 应用层可以控制报文的发送，实现UDP的可靠传输。
2. 无需建立连接。没有建立连接的时延。
3. 无连接状态。无需维护接受发送缓存、拥塞控制参数、序号、确认号等。
4. 分组首部开销小：TCP报文段首部至少20个字节，UDP报文段首部只有8个字节。

UDP报文段

• 源端口号、目的端口号、长度(首部+数据）、检验和、应用层报文。
• 
• UDP提供校验和的原因：1、无法保证所有链路都提供差错检测；2、存储在内存如路由器内存中时引入比特差错。这样符合端到端原则（end-end principle）。

TCP

• TCP是面向连接的可靠的运输协议。
• TCP运行在端系统中，连接状态完全保留在端系统中。
• TCP连接提供全双工服务（full-duplex service）：数据可以从进程A流向进程B的同时，从B流向A。
• TCP连接是点对点（point-to-point）的，多播对TCP不可能。
• TCP通过三次握手建立连接。客户进程通过套接字将数据传送到发送缓存（send buffer），TCP在在他方便的时候从缓存中取出数据并放入报文段。
  数据长度受限于最大报文长度（Maximum Segment Size, MSS），MSS由链路层的最大传输单元（Maximum Transmission）设置，要保证一个TCP报文段+TCP/IP首部（通常40个字节）适合单个链路层帧。典型数值：MTU-1500字节，MSS-1460字节。
  

TCP报文段

• 源端口号、目的端口号。
• 序号、确认号：和可靠传输相关。
  
  • 序号：报文段首字节的字节流编号。
  • 确认号：主机A**期望**从主机B收到的下一个字节的编号。
  • TCP提供累计确认（cumulative acknowledgment），只确认流中至第一个丢失字节为止的字节。
  • TCP接收方保留失序字节，并等待缺少的字节填补空隙。
• 首部长度：由于选项字段，TCP首部长度可变。
• 选项字段：协商MSS,定义时间戳（计算RTT）等。
• 接受窗口：用于流量控制，接收方愿意接受的字节数量。
• 6比特的标志字段、紧急数据指针：ACK表示确认号是否有效，RST、SYN、FIN用于连接的建立和拆除，PSH、URG和紧急数据指针实践中并未使用。
• 

往返时间和超时

• 在某个时刻测量往返时间SampleRTT。
• TCP维护SampleRTT平均值EstimatedRTT，EstimatedRTT=(1-α)*EstimatedRTT+α*SampleRTT。
  
  • α典型值为0.125，EstimatedRTT=0.875*EstimatedRTT+0.125*SampleRTT。
• RTT偏差量DevRTT，DevRTT=（1-β)*DevRTT+β*|SampleRTT-EstimatedRTT|。
  
  • β典型值为0.25,DevRTT=0.75*DevRTT+0.25*|SampleRTT-EstimatedRTT|。
• TCP超时重传间隔TimeoutInterval，TimeoutInterval=EstimatedRTT+4*DevRTT。
  
  • 初始值为1s，超时后TimeoutInterval加倍，直到收到收到上层数据和收到ACk后使用公式计算。

可靠传输

• 

解决比特差错

• 接收方通过控制报文让发送方直到哪些报文被正确接收，那些报文有误需要重复。基于这种重传机制协议称为自动重传请求协议（Automatic Repeat reQuest, ARQ）。
• ARQ需要的功能。
  
  1. 差错检测。通过校验字段等额外的比特实现。
  2. 接收方反馈。接受方提供明确的反馈信息给发送方，表明接受情况。
  3. 重传。接受方收到有错分组，发送方重传。
• 反馈分组ACK或NAK**受损，需要在分组中加上一个新的字段-分组序号**（sequence number）。接收方以此判断接受的数据是新数据还是一次重传，发送方以此判断反馈分组是否用来响应最近发送的数据分组。

解决丢包

• 发送方发送分组后通过倒计数定时器，等待一个时间值，如果这段时间内没有接收ACK，判断可能丢包，重传分组。
• 分组经历较大时延，可能引发重传，产生冗余数据分组，但是这个可以通过之前的序号处理。

解决性能问题

• 重传协议使用停等（stop-and-wait）方式运行，发送方信道利用率低下，改用流水线（pipelining）方式，允许发送方发送多个分组而无需等待确认，这要求：
  
  1. 增加序号范围。有许多未确认报文。
  2. 发送方和接收方必须缓存多个分组。
  3. 流水线的差错恢复。通过回退N步（Go-Back-N，GBN）和选择重传（Selective Repeat， SR），处理丢失、损坏、时延大的分组。

GBN协议

• 允许发送方发送多个分组无需等待确认，但是未确认的分组数不能大于N。N称为窗口长度，GBN协议也称为滑动窗口协议（sliding-window protocol）。
  
• 发送方的动作：
  
  1. 上层调用。窗口未满，产生分组发送；满，返回数据，或者缓存数据，或者用同步机制只允许窗口不满的时候受上层调用。
  2. 收到ACK。对分组累计确认（cumulative acknowledgemetn），表明接收方正确接受序号n和以前的所有分组。
  3. 超时。出现超时，发送方重传已发送但还未被确认的报文，即协议名称由来。发送方仅需维护一个定时器–最早已发送但未被确认的分组的定时器。
• 接收方动作：
  
  1. 序号n的分组正确接受且按序，为分组n发送ACK并将数据交付上层。
  2. 其他情况，丢弃分组并为最近按序接受的分组重新发送ACK。
• 优点：接受缓存简单，无需缓存失序分组。

SR协议

• GBN协议中单个分组的差错能引起大量重传，许多分组没有必要重传。
• SR协议让发送方仅重传怀疑在接收方出错（丢失或受损）的分组，避免不必要的重传。需要接收方逐个确认正确接受的分组。
  
• 发送方动作：
  
  1. 上层调用。若下一个可用序号位于发送窗口内，打包发送数据；否则像GBN缓存或者返回数据。
  2. 收到ACK。若分组序号在窗口内，确认该分组；如果分组序号为send_base，则send_base移动到最小序号的未确认分组处，若窗口移动后窗口内有未发送分组，则发送这些分组。
  3. 超时。每个分组拥有自己的逻辑定时器（单个硬件定时器可模拟多个逻辑定时器），超时后只发送该超时的一个分组。
• 接收方动作：
  
  1. 序号[rcv_base,rcv_base+N)的分组正确接受，发送该分组的ACK。
     
     • 如果该分组未被接受过，缓存该分组。
     • 序号为rcv_base,起始于rcv_base的缓存分组交付上层，接受窗口向后移动。
  2. 序号[rcv_base-N,rcv_base)的分组正确接受，产生ACK，即时以前已经确认（确认报文丢失、差错等，对于分组正确接受等状态，发送方和接收方并不能总看到相同的结果）。
  3. 其他情况，忽略分组。
• 对于SR协议，接受窗口必须<=序号空间大小的一半。

TCP可靠传输

• TCP采用流水线式的ARQ，单一重传定时器，是累计确认，缓存正确失序的报文但是不会逐个确认，差错恢复机制是GBN和SR的混合体。
• 超时后TimeoutInterval加倍，直到收到收到上层数据和收到ACk后使用公式计算。
• TCP发送方接收到对相同数据的3个冗余ACK（duplicate ACK，再次确认某个报文段的ACK），认为该报文段之后的报文段已经丢失，执行快速重传（fast retransmit）。

流量控制

• TCP提供流量控制（flow-control service）消除发送方使接收方缓存溢出的可能性。
• 通过让发送方维护接受窗口（receive window）–rwnd，表示接收方还有多少可用的缓存，控制已发送但未被确认的数据<=rwnd，从而提供流量控制。
  
• 特例：B接受缓存已满，rwnd=0，B没有数据发送给A。当rwnd=0时，A继续发送只有一个字节数据的报文段，直到rwnd非零。

TCP连接管理

• 面试整理
• 三次握手
  
  
  1. C向S发送连接请求，SYN=1的报文，客户端选择初始序号client_isn。报文称为TCP SYN报文。
  2. S连接允许，SYN=1,初始序号server_isn。，分配服务器TCP的缓存和变量。报文称为SYNACK报文。
  3. 收到SYNACK后，客户端分配TCP缓存和变量。发送确认报文，可携带数据。
• 四次挥手
  
• SYN泛洪攻击（SYN flood attack）
  
  • 由于在TCP连接第二步分配资源，攻击者发送大量的TCP SYN报文，不完成第三次握手，导致服务器为大量半开的连接消耗资源。
  • SYN cookie：源和目的IP、端口号，以及服务器的秘密数的hash函数值，作为服务器初始序列号，服务器不记录该hash值。如果第三步中的确认号值为该hash值+1，则直接生成全开连接。若无报文返回则也不会分配资源。

拥塞控制

拥塞的代价

1. 分组到达速率接近链路容量时，分组经历巨大的排队时延。
2. 发送方必须重传来补偿因为缓存溢出而丢失的分组。
3. 发送方遇到大延时会进行不必要的重传，占据链路带宽。
4. 一个分组被丢弃，上游路由器传输该分组的传输容量被浪费。

控制方法

1. 端到端拥塞控制：TCP通过端到端控制，Ip层不提供反馈信息。
2. 网络辅助拥塞控制：例如ATM ABR，采用面向虚电路的方法处理分组。

TCP拥塞控制

1. 限制发送速率：发送方维护拥塞窗口（congestion window）–cwnd。已发送未被确认的数据量（LastByteSent-LastByteAcked）<=min{cwnd,rwnd}。如果接受缓存足够大，可忽略rwnd，发送速率大约是cwnd/RTT 字节/秒。
2. 感知拥塞：丢包事件发生，即超时或者受到3个冗余ACK。
3. 拥塞后处理的原则：
   
   1. 丢失报文意味拥塞。丢失报文段时降低发送的速率。
   2. 确认报文意味网络正在交付报文段，确认报文到达时增加发送速率。
   3. TCP通过丢失报文和确认报文进行带宽探测。
4. 加增乘减（Additive-Increase, Multiplicative-Decrease, AIMD）。
5. 每条TCP连接可以公平的使用带宽，TCP并行连接可以使用带宽的比例。

慢启动

• cwnd以1MSS开始，当确认报文到达时，cwnd翻倍，慢启动阶段以指数增长。
• 结束慢启动
  
  1. cwnd为**慢启动阈值**ssthresh时，结束慢启动，进入拥塞避免模式。
  2. 发生超时，cwnd设为1，重新开始慢启动，ssthresh设为cwnd/2。
  3. 收到3个冗余ACK，快速重传，快速恢复。

拥塞避免

• 每个RTT，cwnd增加1个MSS。
• 结束拥塞避免
  
  1. 发生超时，同慢启动超时。
  2. 收到3个冗余ACK，同慢启动冗余ACK。

快速恢复

• ssthresh设为cwnd/2，cwnd减半（可计及3个冗余ACK加上3个MSS），进入拥塞避免状态。
• TCP Tahoe 这一早期版本只要发生丢包事件，则进入慢启动，TCP Reno 综合了快速恢复。
•