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

  • 简介
    • 服务
    • 和网络层的关系
    • 应用层对应的协议
  • UDP
    • 优点
    • UDP报文段
  • TCP
    • TCP报文段
    • 往返时间和超时
    • 可靠传输
      • 解决比特差错
      • 解决丢包
      • 解决性能问题
        • GBN协议
        • SR协议
      • TCP可靠传输
    • 流量控制
    • TCP连接管理
    • 拥塞控制
      • 拥塞的代价
      • 控制方法
      • TCP拥塞控制
        • 慢启动
        • 拥塞避免
        • 快速恢复

简介

服务

  • 最基本的职责是将两个端系统间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平均值EstimatedRTTEstimatedRTT=(1-α)*EstimatedRTT+α*SampleRTT
    • α典型值为0.125,EstimatedRTT=0.875*EstimatedRTT+0.125*SampleRTT
  • RTT偏差量DevRTTDevRTT=(1-β)*DevRTT+β*|SampleRTT-EstimatedRTT|
    • β典型值为0.25,DevRTT=0.75*DevRTT+0.25*|SampleRTT-EstimatedRTT|
  • TCP超时重传间隔TimeoutIntervalTimeoutInterval=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 综合了快速恢复。

你可能感兴趣的:(网络)