传输层

传输层的基本服务

一、传输层的功能

传输层的核心任务是为应用进程之间提供\color{blue}{端到端的逻辑通信服务}

1. 主要功能包括:

\bullet  传输层寻址

\bullet  应用层报文的分段和重组

\bullet  报文的差错检测

\bullet  进程间的端到端可靠数据传输控制

\bullet  面向应用层实现复用与分解

\bullet  端到端的流量控制

\bullet  拥塞控制

2. 传输层提供的服务

传输层协议提供\color{blue}{逻辑通信}服务;

传输层协议只需在\color{blue}{端系统}中实现;

通信的真正端点并不是主机,而是主机中运行的\color{blue}{应用进程}

二、传输层寻址与端口

1. 用统一的寻址方法对应用进程进行标识——\color{blue}{端口号}

2. 在全网范围内利用 "\color{blue}{IP地址+端口号}" 唯一标识一个通信端点。(即应用进程)

3. 传输层端口号为16位整数,包含三类端口:

    (1)\color{blue}{熟知端口号},数值为 0~1023.

    (2)\color{blue}{登记端口号},数值为 1024~49151,为没有熟知端口号的应用程序使用。使用这个范围的端口号必须在IANA登记,以防止重复。

    (3)\color{blue}{客户端口号或短暂端口号},数值为 49152~65535,留给客户进程选择暂时使用。

提供服务的人端口号一定要固定,但对于用户来说无所谓。

三、无连接服务与面向连接服务

1. 无连接服务——数据传输之间无需与对端进行任何信息交换(即 “握手”),直接构造传输层报文段并向接收端发送。           ——UDP

2. 面向连接服务——在数据传输之前,需要双方交换一些控制信息,\color{blue}{建立逻辑连接},然后再\color{blue}{传输数据},数据传输结束后还需要再\color{blue}{拆除连接}。           ——TCP


传输层的复用与分解

多路复用与多路分解:是传输层的一项基本功能,支持众多应用进程共用同一个传输层协议,并能够将接收到的数据准确交付给不同的应用进程。

一、无连接的多路复用与多路分解

UDP套接字:<目的IP地址,目的端口号>

UDP套接字的端口号是UDP实现复用与分解的重要依据。

通过目的IP地址可以判断到哪个主机,通过目的端口可以判断到哪个应用进程

二、面向连接的多路复用与多路分解

TCP套接字(标识一条TCP连接)

<源IP地址,源端口号,目的IP地址,目的端口号>

当一个TCP报文段从网络层到达一台主机时,该主机根据这 4 个值来将报文段分解到相应的套接字。



停-等协议与滑动窗口协议

一、可靠数据传输基本原理

实现可靠数据传输的措施:

1. 差错检测:利用差错编码实现数据包传输过程中的比特差错检测。

2. 确认:接收方向发送方反馈接收状态。

3. 重传:发送方重新发送接收方没有正确接收的数据。

4. 序号:确保数据按序提交。

5. 计时器:解决数据丢失问题。

二、停-等协议

停-等协议的主要特点就是每发送一个报文段后就停下来等待接收方的确认。

停-等协议的基本工作过程:

1. 发送方发送经过差错编码和编号的报文段,等待接收方的确认;(\color{blue}{发送并等待确认})

2. 接收方如果正确接收报文段,即差错检测无误且序号正确,则接收报文段,并向发送方发送ACK,否则丢弃报文段,并向发送方发送NAK;(\color{blue}{接收并确认/否认}

3. 发送方如果收到ACK,则继续发送后续报文段,否则重发刚刚发送的报文段。(\color{blue}{继续发送/重发})

三、滑动窗口协议

1. 停-等协议的主要性能问题:

停止-等待机制降低了信道利用率。

2.解决方法:

\color{blue}{流水线协议}或管道协议——允许发送方在没有收到确认前连续发送多个分组。

3. 流水线协议的改进:

增加分组序号范围;

发送方和(或)接收方必须。

4. 典型的流水线协议:

滑动窗口协议

停-等协议发送端每发送一个报文就需要停下来等待对方确认,相当于发送窗口大小为1;接收端仅接收符合当前预期的一个报文,接收窗口大小为1.

三、滑动窗口协议

两种最具有代表性的滑动窗口协议:

1. 回退N步(Go-Back-N,GBN)协议:

发送端窗口大小较大,可以在未得到确认前连续发送多个分组;但接收窗口大小仅为一,只能接收1个按序到达的分组,未按序到达的分组或者某个分组差错,就会引起发送方重发该分组及其之后的所有分组。

2. 选择重传(Selective Repeat,SR)协议:

增加接收方缓存能力(接收窗口>1),缓存正确到达但失序的分组,仅要求发送方重传未被接收方确认的分组,等缺失分组到达后一并向上层按序提交。



用户数据报协议(UDP)

用户数据报协议UDP是Internet传输层协议,提供\color{blue}{无连接}\color{blue}{不可靠}、数据报尽力传输服务。

一、UDP数据报结构

1. 源和目的端口号:用于UDP实现复用与分解。

2. 长度字段:在UDP报文段中的字节数(首部和数据的总和)。

3.校验和:接收方用来检测该报文段是否出现了差错。

二、UDP校验和

计算校验和:

1. 对所有参与运算的内容(包括UDP报文段)按16位(16位对齐)求和;

2. 求和过程中遇到的任何溢出(即进位)都被回卷(即进位与和的最低位再加);

3. 最后得到的和取反码。



传输控制协议(TCP)

一、TCP报文段结构

源端口(2字节):发送端应用程序的端口号.

目的端口(2字节):接收端应用程序的端口号.

序号(4个字节):TCP是面向字节流传输的,他为每一个字节编了一个序号,该报文段中序号为传输数据第一个字节的序号。例如:一个报文端的数据部分大小为100个字节,他的序号为400,那么下一次报文段的序号就为500.

确认号(4个字节):指明了下一个期待接收的字节序号,表明该序号之前的所有字节都正确接收到了,只有当ACK为 1 的时候确认号才有效.

数据偏移/首部长度(4个字节): 用来表示报文段数据的起始处距离报文起始处的长度,也就是TCP报文首部的长度,由于首部含有可选项,所以TCP报头长度是不确定的.

保留:为了将来定义新的用途保留,现在一般都置为0.

URG紧急控制位:与紧急指针配合使用,当URG为1的时候,就是通知系统这个报文段有紧急数据,需要优先传输。

ACK确认控制位:当它为 的时候,确认号字段才有效,TCP规定,在连接建立后,所有ACK都应该置为1

PSH推送控制位:当报文段的psh为 1 的时候,接收方接到该报文段,就立刻将他交付给接收应用进程,而不是等缓存已满的时候再交付。

RST复位控制位:当报文段的RST为1的时候,说明该TCP连接出现错误,必须释放连接,并重新建立连接。

SYN同步控制位:在连接建立时用来同步序列号,当 SYN=1,ACK=0 时说明这是一个连接请求报文段,如果对方同意建立连接则应该在响应的报文段中将 SYN=1,ACK=1,表示接受请求

FIN终止控制位:用来释放连接,当FIN=1时表示此报文段发送方的数据已经发送完毕,并要求释放连接。

窗口(2字节):用来告知发送端,接收端的缓存大小,以此控制发送方发送数据的速率,从而达到流量控制,窗口最大为65536。

校验和:用CRC来校验整个TCP报文段,包括tcp头,tcp数据,由发送端进行计算和存储,接收端进行校验,如果接收方发现校验和有差错,则TCP段会被直接丢弃。

紧急指针(2字节):标识紧急数据在报文段结束的位置。

选项:长度可变,最大长度40个字节

二、TCP连接管理

连接建立——三次握手:

1. SYN连接请求(客户端-->服务端)

2. SYNACK确认(同步确认)

3. ACK确认(客户端再次确认)

TCP三次握手建立连接过程:

TCP断开连接的过程——四次挥手:

三、TCP可靠数据传输

1. TCP的可靠数据传输实现机制包括差错编码、确认、序号、重传、计时器等。

2. TCP的可靠数据传输是基于滑动窗口协议,但是发送窗口大小动态变化

    (1)封装TCP报文段

    (2)发出一个报文段后启动一个计时器

    (3)通过校验和发现数据差错

    (4)通过序号重新排序,丢弃重复的报文段

    (5)流量控制

四、TCP流量控制

1. TCP协议利用\color{blue}{窗口机制}实现流量控制,但不是简单的滑动窗口协议。

2. TCP连接建立时,双方都为之分配了固定大小的缓冲空间;TCP的接收端只允许另一端发送其缓冲区所能接纳的数据。

    (1)接收端在给发送端发送确认段时,通告接收窗口大小。

    (2)发送端在接下来发送数据段时,确保未确认段的应用层数据总量不超过接收端通告的接收窗口大小,从而确保接收端不会发生缓存溢出。

五、TCP拥塞控制

1. 窗口机制:

通过调节窗口的大小实现对发送数据速率的调整。

2. 窗口调整的基本策略:

AIMD(Additive Increase,Multiplicative Decrease)加性增加,乘性减小

网络未发送拥塞时,逐渐 “加性增大窗口大小,当网络拥塞时 “乘性快速减小窗口大小。

3. TCP的拥塞控制算法:

包括了慢启动拥塞避免快速重传快速恢复4部分。

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

推荐阅读更多精彩内容

  • 【计算机网络】传输层 传输层协议概述 传输层协议为运行在不同host上的进程提供了一种逻辑通信机制。使得端到端不需...
    666真666阅读 1,986评论 0 4
  • 计算机网络系列博文——目录 概述 TCP服务 多路复用与多路分解将端系统间的IP交付服务扩展为运行在端系统上的两进...
    疼呃阅读 492评论 0 0
  • 由于不同机器上的程序要通信,才产生了网络 基础知识 基本架构 应用类:qq、微信、网盘...(安装应用) web类...
    SMEB_阅读 1,016评论 0 7
  • 运输层协议概述 从通信和信息处理的角度看,运输层向它上面的应用层提供通信服务,它属于面向通信部分的最高层,同时也是...
    srtianxia阅读 2,399评论 0 2
  • 一、传输层的功能 1.1 OSI和DoD模型 TCP(Transmission Control Protocol)...
    yjaal阅读 827评论 0 0