运输层

3.1概述和运输层服务

运输层协议为运行在不同主机上的应用进程之间提供了逻辑通信。其在端系统中而不是路由器中实现。

3.1.1运输层和网络层的关系

网络层提供了主机之间的逻辑通信。用类比的方法就是两个家庭之间收发信件,每个家庭都有一个负责人进行信件的收集和交付邮局工作,其中负责人相当于运输层协议,而邮政服务相当于网络层协议。

3.1.2运输层概述

运输层分组称为报文段。网络层协议有一个IP协议,为主机之间提供逻辑通信,IP的服务模型是尽力而为交付服务,它并不能确保任何报文段的交付,不保证按序交付,不保证数据完整性。将主机间交付扩展到进程间交付称为运输层的多路复用多路分解
进程到进程的数据交付和差错检查是两种最低限度的运输层服务,也是UDP提供了仅有的两种服务。

3.2多路复用和多路分解

运输层通过检查报文段中的几个字段来标识出接受套接字,并将报文段定向到该套接字,这个过程称为多路分解。(负责人从邮递员接受一批信件,然后通过收信人名字将信件交给其他人)主机从不同套接字收集数据块,并为每个数据块封装首部信息从而生成报文段,然后将报文段传递到网络层的工作称为多路复用。(负责人收集信件然后交给邮递员)

多路复用要求

  • 套接字有唯一标识符
  • 每个报文段有特殊字段来指示该报文要交付的套接字。其中特殊的字段是源端口号字段目的端口号字段,端口号是一个16比特的数,大小在0 ~ 65535之间,0 ~ 1023是周知端口号,该端口号保留给诸如HTTP(80)、FTP(21)

1.无连接的多路复用和多路分解
使用传统方法创建套接字的时候,运输层会自动给该套接字分配一个端口号,当然,也可以用socket.bind(('',19157))这样的方法来绑定端口号。
一个UDP套接字是由一个二元组来全面标识的,即目的IP和目的端口号。所有标识符一致的请求,都会被分解到相同的套接字中

2.面向连接的多路复用和多路分解
TCP套接字是由一个四元组(源IP、源端口号、目的IP、目的端口号)标识的。在敲门端口号接收到请求后,会根据标识符来生成相应的连接套接字。

3.web服务器与TCP
如今高性能Web服务器只使用一个进程,而每个新的客户连接创建一个新连接套接字的新线程

3.3无连接运输:UDP

UDP只是做了运输协议能够做的最少工作,除了复用/分解功能及少量的差错检测外,它几乎没有对IP增加别的东西。
DNS是一个通常使用UDP的应用层协议的例子。有很多应用更加适合用UDP,原因如下:

  • 关于何时、发送什么数据的应用层控制更加精细。能实现立即传递,无需考虑拥塞控制
  • 无需建立连接。UDP不会引入建立连接的时延
  • 分组首部开销小。每个TCP报文段又20字节的首部开销,而UDP仅有8字节
    UDP可以实现可靠数据传输,只不过需要在应用程序自身中建立可靠性机制来完成(如增加确认和重传机制)

3.3.1 UDP报文段结构

UDP首部只有4个字段,一个字段由两个字节组成。长度字段表示报文段中的字节数(首部加数据)。利用检验和来检查报文段中是否出现差错。


UDP报文段结构

3.3.2 UDP检验和

发送方的UDP对报文段中所有的16比特字的和进行反码运算,(求和时遇到任何溢出都被回卷)得到的结果放在检验和字段。
在接收方,全部的4个16比特加在一起,如果没有引入差错,那显然在接收方初该和将是1111111111111111,如果出现了0,那就表明分组出错。
虽然链路层也提供了差错检测的协议,但是不能保证每条链路都有,也不能保证内存中不会出现,所以运输层的差错检验是非常必要的。

3.4可靠数据传输原理

3.4.1可靠数据传输协议

1.经完全可靠信道的可靠数据传输rdt1.0
有限状态机(Finite-State Machine, FSM)可以用来定义接收方和发送方的操作,横线上方表示引起变迁的事件,横线下方表示事件发生时所采取的动作,FSM的初始状态用虚线表示

2.经具有比特差错信道的可靠数据传输:rdt 2.0
协议可以使用肯定确认否定确认来让发送方知道接收方知道,哪些内容需要被重复传输,基于这种重传机制的可靠数据传输协议称为 自动重传请求协议(Automatic Repeat reQuest,ARQ)
该协议需要三种协议功能来处理比特出错

  • 差错检测。
  • 接收方反馈。
  • 重传。

    rdt2.0的发送端有两个状态,一个等待来自上层的调用,一个用来等待ACK或NCK分组。注意,当发送方处于等待ACK/NCK的状态时,就不能从上层获取更多数据。这样的行为称为停等协议
    rdt2.0的接收方只有一个状态。
    如果ACK/NCK分组受损,发送方就无法知道接收方有没有正确接受上一块发送的数据,为此,有3种可能
  • 接收方面对出错的ACK/NCK分组,发送方可能会进一步发送报文,但这样的话就容易陷入死胡同
  • 增加足够的检验和比特,使得发送方在检测到出错的时候也能恢复
  • 发送方遇到出错ACK/NCK时就重新发送,但会存在冗余分组

解决上述问题的方法是在数据分组种添加一个新字段,让发送方对其数据分组编号,将发送数据分组的序号放在该字段。这样就能确定该序号的分组是否被正确的接收到。
也可以不发送NAK,而是对上一次正确接收的分组发送一个ACK,也能实现和NAK一样的效果。

3.经具有比特差错的丢包信道的可靠数据传输:rdt3.0
假设除了比特受损,还会丢包。现在需要处理两个关注的问题:怎么检测丢包以及丢包后该怎么做
解决上述方法最简单的方法就是重传,虽然会引入冗余数据分组,但是可以用编号的方法来处理。
为了实现时间的重传机制,需要一个倒计数计时器。即如果超时,那就需要重新发
至此,在检验和、序号、定时器、肯定和否定确认分组这些技术加入之后,我们得到了一个可靠数据传输协议。

3.4.2 流水线可靠数据传输协议

流水线技术对可靠数据传输协议带来了以下的影响:

  • 增加序号范围
  • 协议的发送方和接收方必须缓存多个分组。发送方至少能缓存已发送但是没有确认的分组。接收方也需要缓存那些已正确接受的分组
  • 所需序号的范围和对缓冲的要求取决于数据传输协议如何处理数据丢失、损坏和延时过大的分组。两种基本方法:回退N步选择重传

3.4.3回退N步(GBN)(滑动窗口协议)

基序号定义为最早的未确认分组的序号
下一个序号定义为最小的未使用序号
窗体长度的定义是为了流量控制和拥塞控制

GBN发送方序号

发送方:当出现丢失和时延过长分组时发送方会利用定时器来恢复数据或确认分组的丢失。如果超时,发送方会重传所有已发送但是还未被确认的分组,如果收到一个ACK,但还有已发送但未确认的分组,那就重启定时器。知道没有已发送未确认的分组,定时器才会终止。
接收方:丢弃正确接受但失序的分组。该方法接受缓存简单,无需缓存失序分组。

3.4.4选择重发(SR)

由于GBN方法在单个分组出错后就会引起大量分组的重传,所以效率较慢。
发送方:SR仅重传那些怀疑在接收方出错的分组。而且每个分组必须拥有自己的逻辑定时器,以防止超时。当收到ACK时,将对应的分组标记为已接受,如果时send_base,那就移动。
接收方:确认一个正确接受的分组而不管其是否按序,缓存起来直到所有丢失的分组都收到了。


SR操作流程

接收方重新确认已经收到过的那些序号小于当前窗口基序号的分组。
窗口的大小必须小于或等于序号空间大小的一半,否则会出现接收方无法确认,收到的分组是新传入的还是重新发送的(如下面的两种情况)


3.5面向连接的传输:TCP

3.5.1TCP连接

TCP连接提供的是全双工服务,该连接也总是点对点的,即单个发送方与单个接受方之间的连接。
在经过三次握手之后开始互相发送数据,客户进程通过套接字传输数据,TCP将数据引导到连接的发送缓存中,TCP可从缓存中取出并放入到报文段中的数据量受限于最大报文段长度(MSS)
TCP连接的组成包括:一台主机上的缓存、变量和与进程连接的套接字,以及另一台主机上的缓存、变量和套接字

3.5.2 TCP报文段结构

TCP报文段结构

上图可知,首部字段一般是20字节。除了源端口号、目的端口号和因特网检验和三个字段,TCP报文段还包括:

  • 4字节的序号字段和4字节的确认好字段
  • 2字节的接受窗口字段,用于流量控制
  • 4比特的首部长度字节,表示以32为比特的字为单位的TCP首部长度
  • 选项字段
  • 6比特的标志字段,ACK表明该报文段包括一个对已成功接收报文段的确认,RST、SYN、FIN用于连接的建立和拆除。PSH表明该数据应立即交给上层,URG表明报文段中存在发送端设置为”紧急“的数据,该数据的最后一个字节由紧急数据指针指出。

1.序号和确认号
序号是建立在传送的字节流上,而不是传送的报文段上。如一个包含了500000字节的数据,MSS是1000字节,数据流的首字节编号是0,那么TCP就会为该数据流构建500个报文段,第一个报文段的序号是0.第二个报文段的序号是1000.

主机A填充进报文段的确认号是主机A期望从主机B收到的下一个字节的序号。比如说主机A已经收到一个来自主机B的包含字节0~ 535的报文段,以及一个包含字节900~ 2100的报文段,那么A到B的下一个报文段将在确认号中包含536.

2.Telmet:序号和确认号的案例
大体流程是主机A键入的每个字符都会被发送到远程主机B,远程主机B又将会送每个字符副本到主机A。之后主机A将取人以从服务器收到的数据
假设客户和服务器的起始序号分别是42和79,所以TCP建立之后,客户等待字节79,而服务器等待字节42


3.5.3往返时间的估计和超时

1.估计往返时间
首先需要估计发送方与接受方之间的往返时间。在任意时刻,仅为一个已发送但是目前尚未被确认的报文段估计样本RTT,从而产生一个接近于每个RTT的新的值,而且绝不为已经重传的报文段计算。
为了计算典型的RTT,即平均样本RTT,需要用加权平均值来进行计算,被称为制数加权移动平均(EWMA)
EstimatedRTT=0.875×EstimatedRTT +0.125×SampleRTT
计算RTT的变化,用于估算sampleRTT一般会偏移EstimateRTT的程度:
DevRTT=0.75×DevRTT+0.25×|SampleRTT-EstimateRTT|

2.设置和管理重传超时间隔
TimeoutInterval=EstimateRTT+4×DevRTT
推荐的初始值TimeoutInterval是1秒

3.5.4 可靠数据传输

  • 简化的描述
    发送方有3个与发送和重传相关的事件:从上层应用程序接受数据、定时器超时和收到ACK。
    一种有趣的情况:主机A发送两个报文段,第一个报文段序号是92,包含8个字节。第二个报文段序号是100,包含20字节,两个报文段无损达到主机B,但超时前A收到一个确认号是120的确认报文,那主机A就知道主机B已经收到了序号119及之前所有的字节,也就不会重传。

冗余ACK:当TCP接收方收到一个具有这样序号的报文段,其序号大于下一个所期待的、按序的报文段,说明有报文段丢失。所以他会对已接受的最后一个按序字节数据进行重复确认。也就产生了冗余ACK

3.5.5流量控制

TCP提供的流量控制可以消除因发送方速率较快,而接收方读取数据相对缓慢所导致的缓存溢出的可能性。
拥塞控制使发送方因为IP网络的拥塞而被遏制的控制。两者采取的动作相似,但针对的原因和目的完全不同。
TCP通过让发送方维护一个称为接受窗口的变量来提供流量控制。定义以下的变量:

  • LastByteRead:主机B的应用进程从缓存读取的数据流的最后一个字节的编号
  • LastByteRevd:从网络中到达并且已放入主机B接收缓存中的数据流的最后以一个字节的编号
    接收窗口用rwnd表示
    rwnd=RevBuffer-[LastByteRevd-LastByteRead]
    主机B把当前的rwnd放入发送给A的报文段中通知主机A
    主机A轮流跟踪两个变量。LastByteSent和LastByteAcked。主机A在连接的整个生命周期中需要保证:
    LastByteSent-LastByteAcked<=rwnd

3.5.6TCP连接管理

  • 第一步:在报文段的首部中的SYN比特被设为1,这个特殊报文段被称为SYN报文段。随机选择一个初始序号(client _isn),该序号放置在开始的TCP SYN报文段的序号字段中。
  • 第二步:提取TCP SYN报文段,为TCP 连接分配TCP缓存和变量。在第二个报文段中包含3个重要信息,首先SYN置为1,确认号字段置为client_isn+1,最后服务器选择自己的初始序号(server_isn)。该连接有时被称为SYNACK报文段
  • 第三步:客户为该连接分配缓存和变量。首部的确认字段设为server_isn+1,SYN比特设为0.同时可以携带客户到服务器的数据

客户端的生命周期如下:客户端刚开始处于Closed状态,然后客户端向服务器发送一个SYN报文段,发送完报文段之后就处于SYN_SENT状态(等待来自服务器的确认报文段),收到确认报文段之后客户TCP就处于ESTABLISHD状态。此时客户TCP就可以发送和接受应用层产生的数据了。 关闭时TCP发送一个带有FIN比特被置为1的TCP报文段,然后进入FIN_WAIT_1状态,当收到服务器带确认的报文段后,客户TCP进入FIN_WAIT_2状态,当收到FIN比特被置为1的另一个报文段后,发送确认报文段,进入TIME_WAIT状态,之后就正式关闭。


客户端

服务器端的生命周期与上述相对。不再赘述


服务器端

3.6 拥塞控制原理

3.6.1 拥塞原因和代价

情况1:两台发送方与一台具有无穷大缓存的路由器
吞吐量如左图所示,还算可以接受,但是随着发送速率的增加,时延产生了指数级的增加,如图右

情况2:两个发送方和一台具有有限缓存的路由器
发送方必须执行重传来补偿因为缓存溢出而丢失的分组。
发送方在遇到大时延时所进行的不必要重传会引起路由器利用其链路带宽来转发不必要的分组副本。
情况3:四个发送方和具有有限缓存的多台路由器及多条路径
当一个分组沿一条路径被丢弃时,每个上游路由器用于转发该分组到丢弃该分组而使用的传输容量最终被浪费掉了。

3.6.2拥塞控制方法

  • 端到端拥塞控制。
  • 网络辅助的拥塞控制。

3.6.3网络辅助的拥塞控制例子:ATM ABR拥塞控制

没看懂

3.7 TCP拥塞控制

思考三个问题,第一,一个TCP发送方如何限制它向其连接发送流量的速率?第二,一个TCP发送发如何感知他从目的地之间的路径上存在的拥塞?第三,当发送方感知端到端的拥塞时,采用何种算法来修改其发送效率。

第一个问题:发送方跟踪一个额外的变量,拥塞窗口,表示为cwnd,可以通过调节这个值来调整他向连接发送数据的速率。
第二个问题:超时或者收到来自接收方的3个冗余ACK
第三个问题:如果收到的确认以相当慢的速率增加,那拥塞窗口也以相当慢的速率增加。TCP用确认来增大它拥塞窗口长度的行为被称为是自计时

1.慢启动
csnd的值刚开始会设置的较小,为MSS的较小值,MSS=500然后cwnd的值以1个MSS进行增加.如此,报文段的增加形式就是(1,2,4,8,16....)如果存在一个拥塞,TCP发送方将cwnd设置为1并重新开始慢启动。还将第二个状态变量的值ssthresh设置为cwnd/2。
慢启动结束的第二种方式是直接与ssthresh的值相关联,当检测到拥塞时,ssthresh设为cwnd的一半,当cwnd的值等于ssthresh时,结束慢启动并进入拥塞模式。

2.拥塞避免
进入拥塞避免状态时,每个RTT只将cwnd的值增加一个MSS,

3.快速恢复
尚未看懂

©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 206,126评论 6 481
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 88,254评论 2 382
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 152,445评论 0 341
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 55,185评论 1 278
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 64,178评论 5 371
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,970评论 1 284
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 38,276评论 3 399
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,927评论 0 259
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 43,400评论 1 300
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,883评论 2 323
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,997评论 1 333
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,646评论 4 322
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 39,213评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 30,204评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,423评论 1 260
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 45,423评论 2 352
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,722评论 2 345