计算机网络之运输层

一、基础概念

  • 服务对象:进程
  • 功能:逻辑通讯
  • 载体:报文段
  • 工作环境:端系统
  • 运输层协议
      TCP:为进程提供可靠的、面向连接的服务
      UDP:为进程提供不可靠的、无连接的服务

二、多路分解与多路复用

  • 多路分解:将运输层报文中的数据交付到正确的套接字(socket)上工作
  • 多路复用:在原主机从不用套接字中收集数据块,并为每个数据块封装上首部信息,从而生成报文段,然后将报文段传递到网络层。
  • 运输层多路复用要求:
      a. 套接字有唯一标识符
      b. 每个报文段有特殊字段(源端口号字段、目的端口号字段)来指示改报文段所要交付到的套接字
  • 运输层分解服务实现:
      在主机上的每个套接字能够分配一个端口号,当报文段到达主机时,运输层检查报文段中的目的端口号,并将其定向到相应的套接字
      UDP套接字由一个二元组(目的IP地址,目的端口号)来标识
      TCP套接字由一个四元组(源IP地址,源端口号,目的IP地址,目的端口号)来标识

三、可靠数据传输

  1. 可靠数据传输协议的要点:检验和、序号、定时器、肯定和否定确认分组
机制 用途和说明
检验和 用于检测在一个传输分组中的比特错误
定时器 用于超时/重传一个分组,可能该分组(或其ACK)在信道中丢失
序号 用于为从发送方流向接收放的数据分组按顺序编号
确认 接收方用于告诉发送方一个分组或一组分组已被正确接收到
否定确认 接收方用于告诉发送方一个分组或一组分组未被正确接收到
  1. 流水线技术
     1) 含义:不使用停等方式运行,允许发送方发送多个分组而无需等待确认
     2) 对可靠数据传输协议带来的影响:
      a. 必须增加序号范围,因为每个输送中的分组(不计算重传的)必须有一个唯一的序号,而且也许有多个在输送中未确认的报文;
      b. 协议的发送方和接收方两端也许必须缓存多个分组;
      c. 所需序号范围和对缓冲的要求取决于数据传输协议如何处理丢失。损坏及延时过大的分组。
     3) 解决流水线的差错恢复的两种基本方法:回退N步 (GBN) 和选择重传 (SR)

  2. 回退N步 (GNB)
      1) 定义:允许发送放发送多个分组而不需要等待确认,但在流水线中未确认的分组数不得超过窗口长度N,随着协议运行,该窗口的序号空间在向前滑动,所以GBN协议也被称为滑动窗口协议
      2) 发送方采用动作:
       a. 上层的调用。发送方检查发送窗口是否已满,如果未满则产生分组将其发送;如果已满则缓存等待或者通过同步机制运行上层仅当窗口不满时才被调用。
       b. 收到一个ACK。GBN采用累积确认,表明接收方已经收到序号n以及n以前的所有分组。
       c. 超时事件。发送方重传所有已发送但未被确认过的分组,如果接收到一个ACK,但仍有已发送但未被确认的分组,则定时器重新启动。
      3) 接收方采用动作:如果序号为n的分组被正确收到,兵器按序,则接收方为分组n发送一个ACK,并将分组中的数据交付到上层;其他情况,接收方丢弃该分组,并为最近按序接收的分组重新发送ACK。
      4) 丢弃未按序分组带来的优缺点
       a. 优点:接收缓存简单,即接收方不需要缓存失序分组
       b. 缺点:随后对该分组的重传也许会丢失或出错,因此需要更多的重传

  3. 选择重传(SR)
      1) 定义:允许发送放发送多个分组而不需要等待确认,发送方仅重传那些他怀疑接收方出错的分组而避免面不必要的重传。
      2) 发送方采用动作:
       a. 上层的调用。发送方检查发送窗口是否已满,如果未满则产生分组将其发送;如果已满则缓存等待或者通过同步机制运行上层仅当窗口不满时才被调用。
       b. 超时。每个分组都有一个自己的逻辑定时器,发生超时只能发送一个分组。
       c. 收到ACK。如果ACK确认的序号等于窗口最左端序号,则窗口向右移动,否则标记该组为已收到。
      3) 接收方采用动作
       a. 序号在窗口内。发送ACK,如果第一次接收则缓存(窗口左端如果缓存了则向上交付)
       b. 序号在窗口-N内。立刻发送ACK。
       c. 其它情况。忽略分组


四、面向连接的运输:TCP

  1. TCP报文结构


  2. TCP连接管理

  • 三次握手
      (1) 第一次握手:建立连接时,客户端A发送SYN包[SYN=1,seq=x]到服务器B,并进入SYN_SENT状态,等待服务器B确认。
      (2) 第二次握手:服务器B收到SYN包,必须确认客户A的SYN,同时自己也发送一个SYN包,即SYN+ACK包[SYN=1,ACK=1,seq=y,ack=x+1],此时服务器B进入SYN_RECV状态。
      (3) 第三次握手:客户端A收到服务器B的SYN+ACK包,向服务器B发送确认包ACK[ACK=1,seq=x+1,ack=y+1],此包发送完毕,客户端A和服务器B进入ESTABLISHED状态,完成三次握手。 第三次握手可在报文段负载中携带客户到服务器的数据。三次握手后客户端与服务器开始传送数据。

  • 四次挥手
      (1) 首先A B端的TCP进程都处于ESTABLISHED状态, 当A的应用程序传送完报文段,就会去主动关闭连接。A会停止发送报文段(但是还会接收),并向B发送[FIN = 1,seq=u]数据,之后进入FIN-WAIT-1状态;
      (2) B接收到A发送的请求之后,会通知应用进程,A已经不再发送数据,同时B会向A发送ACK确认数据[ACK=1,seq=v,ack=u+1 ],B进入CLOSE-WAIT状态,A接收到B发送的数据之后,A进入FIN-WAIT-2状态;此时A到B方的连接已经关闭了(即半连接状态)。
      (3) 当B的应用进程发现自己也没有数据需要传送,B应用进程就会发出被动关闭的请求,B此时向A发送[FIN=1,ACK=1,seq=w,ack=u+1]数据,并且进入LAST-ACK状态;
      (4) A接收到B发送的数据之后,向B发送ACK确认数据[ACK =1,seq=u+1,ack=w+1],进入TIME-WAIT状态,等待2MSL之后正常关闭连接进入CLOSED状态;B接收到A发送的确认之后进入CLOSED状态。B到A方的连接关闭!至此,TCP连接才真正全部关闭!

  • 为什么建立连接协议是三次握手,而关闭连接却是四次握手呢?
      这是因为服务端的LISTEN状态下的SOCKET当收到客户端的SYN报文的建立连接请求后,它可以把ACK和SYN(ACK起应答作用,而SYN起同步作用)放在一个报文里来发送。但关闭连接时,当收到对方的FIN报文通知时,它仅仅表示对方没有数据发送给你了;但未必你所有的数据都全部发送给对方了,所以你可以未必会马上会关闭SOCKET,也即你可能还需要发送一些数据给对方之后,再发送FIN报文给对方来表示你同意现在可以关闭连接了,所以它这里的ACK报文和FIN报文多数情况下都是分开发送的。

  • 为什么TIME_WAIT状态还需要等2MSL后才能返回到CLOSED状态?
      这是因为虽然双方都同意关闭连接了,而且握手的4个报文也都协调和发送完毕,按理可以直接回到CLOSED状态(就好比从SYN_SEND状态到 ESTABLISH状态那样);但是因为我们必须要假想网络是不可靠的,你无法保证你最后发送的ACK报文会一定被对方收到,因此对方处于 LAST_ACK状态下的SOCKET可能会因为超时未收到ACK报文,而重发FIN报文,所以这个TIME_WAIT状态的作用就是用来重发可能丢失的 ACK报文。

  1. TCP可靠数据传输

(1) 上层调用
  TCP从应用程序接收数据,将数据封装到一个报文段中,并将改报文段交给IP(每个报文段都包含一个序号)
(2) 超时
  TCP通过重传引起超时的报文段来相应超时时间,然后TCP重启定时器。
(3) 收到ACK
  TCP采用累计确认策略。确认序号表示序号前的所有字节都已经正确且按序接收。

  • 超时间隔设定
      每次TCP重传时都会将下一次的超时间隔设定为先前值的两倍,这种修改提供了一个形式受限的拥塞控制(在拥塞的时候,如果源持续重传分组,会使拥塞更加严重)

  • 快速重传
      如果TCP发送方接收到对相同数据的3个冗余ACK(3个冗余ACK = 1个正常ACK + 3 个重复ACK),它把着当作一种指示,说明跟在这个已被确认过3次的报文段之后的报文段已经丢失,TCP就执行快速重传,即在改报文段的定时器过期之前重传丢失的报文。

  • TCP 差错恢复机制
      虽然TCP采用累计确认,但是TCP发生超时事件时重传至多一个报文段。此外,如果对报文段 n+1 的确认报文在报文段 n 超时前到达,TCP不会重传报文段 n。因此,TCP的差错恢复机制是GBN和SR协议的混合体。

  • TCP超时重传举例
      (1) 如果主机 A 向主机 B 发送一个报文段,当超时事件发生时,A 会重传相同的报文段
      (2) 如果主机 A 向主机 B 发送两个报文段,当超时事件发生时(没有一个确认报文到达 A),A 只会重传第一个报文段,并启动定时器,如果第二个报文段的ACK在新的超时发生前到达,则第二报文段不会被重传。
      (3) 如果主机 A 向主机 B 发送两个报文段,如果第一个报文段的ACK在网络丢失,但在超时前接收到第二个报文段的确认报文,由于TCP采用累积确认,所以不会发生重传。

  • 流量控制
      TCP的流量控制是一个速度匹配服务。通过发送方维护一个接收窗口(接收方还有多少缓存空间)的变量来提供流量控制。接收窗口大小 = 接收缓存空间大小 - 缓存中的TCP数据大小。
      当主机的接收窗口为0时,发送方会继续发送只有一个字节数据的报文。

  • 为什么当接收窗口为0时,发送方仍然继续发送报文?
      TCP当且仅当有数据或有确认要发时才会发送报文段。
      A为发送方,B为接收方。假设B告知A接收窗口大小为0,且B没任何数据发送给A。当B上的应用进程将缓存清空,因为B没有数据或者确认向A发送报文段,所以TCP并不会向A发送带有接收窗口大小的新报文,导致A不可能知道B中有新的空间,即A被阻塞而不能再发送给数据。


五、TCP拥塞控制

  • TCP采用的方法:让每一个发送方根据所感知到的网络拥塞程度来限制其能向链接发送流量的速率。

  • TCP发送方如何限制它发送流量的速率?
      运行在发送方的TCP拥塞控制机制跟踪一个额外的变量——拥塞窗口,在发送方未确认的数据量不得超过拥塞窗口与接收窗口的最小值(间接地限制发送方的发送速率)。
      发送速率 = 发送数据量(未确认数据流) / 往返时间,通过调节拥塞窗口可以达到调整发送方发送数据的速率。

  • TCP如何感知它到目的地之间的路径是否拥塞?
      TCP发送方的“丢包事件”定义为:要么出现超时,要么收到来自接收方的3个冗余ACK。当出现过度的拥塞时,在沿着这条路径上的一台或多台路由器的缓存会溢出,引起数据包(含TCP报文段)被丢弃。被丢弃的数据包会引发发送方的丢包时间(超时或者收到3个冗余ACK),发送方就会认为在发送方到接收方的路径上出现了拥塞的指示。

  • TCP发送方如何确定发送速率?
      (1) 当发生丢失报文段时应当降低TCP发送方的速率(减少拥塞窗口的长度)
      (2) 当对先前未确认报文段的确认到达时,增加发送方速率(增加拥塞窗口的长度)
      (3) 带宽探测。

  • TCP拥塞控制算法
    慢启动算法
      1) 连接建好的开始先初始化拥塞窗口cwnd大小为1,表明可以传一个MSS大小的数据。
      2) 每当收到一个ACK,cwnd大小加一,呈线性上升。
      3) 每当过了一个往返延迟时间RTT(Round-Trip Time),cwnd大小直接翻倍,乘以2,呈指数让升。
      4) 还有一个ssthresh(slow start threshold),是一个上限,当cwnd >= ssthresh时,就会进入“拥塞避免算法”
    拥塞避免算法
      1) 收到一个ACK,则cwnd = cwnd + 1 / cwnd
      2) 每当过了一个往返延迟时间RTT,cwnd大小加一。
    拥塞状态时的算法
      1) 更改cwnd和ssthresh为原有cwnd的一半
      2) 然后进入快速恢复算法Fast Recovery。
    快速恢复
      1) cwnd = cwnd + 3 * MSS,加3 * MSS的原因是因为收到3个重复的ACK。
      2) 重传DACKs指定的数据包。
      3) 如果再收到DACKs,那么cwnd大小增加一。
      4) 如果收到新的ACK,表明重传的包成功了,那么退出快速恢复算法。将cwnd设置为ssthresh,然后进入拥塞避免算法。

六、无连接的服务UDP

  • 定义:在IP协议上,添加复用/分解功能以及少量的差错检测。发送放和接收方的运输层实体之间没有握手,所以被称为是无连接的。

  • 使用UDP优势
      1) 能够为应用层更精细控制(时间及数据类型)。只要应用进程将数据传递给UDP,UDP就会将数据打包进UDP报文段并立刻传递给网络层。TCP由于可靠传输、拥塞控制机制等,可能会导致报文段传送的延迟。当实时应用要求最小的发送速率、不希望过分地延迟报文段的发送,且容忍一些数据的丢失,UDP更为适用。
      2) 无需连接建立。UDP不需要任何准备就能进行数据传输,所以UDP不会引入建立连接的时延。
      3) 无连接状态。TCP需要在段端系统中维护连接状态(接收和发送缓存、拥塞控制参数以及序号与确定号等参数),由于UDP是无连接状态所以不需要维护也不需要跟踪这些参数。所以在某些专门应用于特定应用的服务器,当应用程序运行在UDP而非TCP上时,能够支持更多的活跃用户。
      4) 分组首部开销小。TCP报文段需要20字节的首部开销,而UDP仅需要8字节。

  • UDP的弊端
      UDP中缺乏拥塞控制能够导致UDP发送方和接收方之间的高丢包率,并挤垮了TCP会话,这是一个潜在的严重问题。

  • 流行的因特网应用及其下面的运输协议

应用 应用层协议 运输层协议
电子邮件 SMTP TCP
远程终端访问 Telnet TCP
Web HTTP TCP
文件传输 FTP TCP
远程文件服务器 NFS 通常UDP
流式多媒体 通常专用 UDP或TCP
因特网电话 通常专用 UDP或TCP
网络管理 SNMP 通常UDP
路由选择协议 RIP 通常UDP
域名转换 DNS 通常UDP
最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 216,240评论 6 498
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 92,328评论 3 392
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 162,182评论 0 353
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 58,121评论 1 292
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 67,135评论 6 388
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 51,093评论 1 295
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 40,013评论 3 417
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 38,854评论 0 273
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 45,295评论 1 310
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 37,513评论 2 332
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 39,678评论 1 348
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 35,398评论 5 343
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 40,989评论 3 325
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 31,636评论 0 22
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,801评论 1 268
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 47,657评论 2 368
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 44,558评论 2 352

推荐阅读更多精彩内容