计算机网络原理知识点(第五章:运输层)

*第五层:运输层*

(1)真正数据通信的意思其实是: 在主机的进程中, 由A主机的进程与B主机的进程进行数据交换的 过程而不是主机之间的数据交换. 很显然, 将一个通信过程分为这么多层, 是为了让底层给高层服务, 并将每一层的任务分配好. 更重要的是, 我们知道 一个主机当中有很多个进程同时在通信, 但是我们又只有一个运输层, 所以很明显, 运输层具有"复用"和"分用"功能, "复用"指的是这么多进程都只使用一个运输层来传输数据, 而"分用"指的是运输层收到数据后,能够准确地派递相应的数据给相应的进程.

(2)在物理层, 链路层, 网络层都没有对数据的可靠传输进行把关, 所以这个任务也就留到了运输层上了. 运输层要对报文进行差错检测.

(3)运输层的UDP协议: 又叫 用户数据报协议, UDP不提供可靠交付, 对给出的发送报文, 不需要任何确认.

(4)运输层的TCP协议: 又叫 传输控制协议, TCP是一种面向连接的服务, 要很多确认报文. 并且TCP不提供广播和多播服务.

(1)历史: 在概述(1)中提到, 运输层有"分用"和"复用"功能, 所以对于每一个进程有一个标识号是非常重要的. 所以在运输层使用"协议端口号"可以解决这问题, 简称"端口".

(2)分类: 端口分两种: 第一种叫熟知端口号(系统端口号), 这些是一些常用并且固定下来的应用程序端口, 例如(FTP:21, HTTP:80), 另外一种叫登记端口, 这类端口是要申请的.

(1)概述: UDP是一种无连接, 尽最大努力交付的协议, 所以他不需要建立链接, 最重要的是, UDP协议是面向报文的, 也就是说, 对于应用层丢下来的数据, 和网络层传上来的数据, UDP协议对它都不做任何改动, 既不拆分, 也不合并. 直接去除或者加上 UDP协议的首部就继续下一步工作.

(2)格式:

1.源端口: 在对方回信时选用, 不用就全0.

2.目的端口: 在重点交付报文时需要.

3.长度: UDP数据部分的长度.

4.检验和: 检验UDP报 是否出现差错, 有就丢弃.

5.summary: 检验和部分百度把,不过这里提一点, 在进行检验和时, 是将首部和数据报一起检验.

(1)格式:

1.源端口和目的端口: 和UDP协议一样.

2.序号: 对每一个字节都进行按顺序编号. 例如(一个数据包开始字节序号:20111, 长度为10 , 则结束序号为20110)

3.确认号: 期望收到对方下一个报文的第一个数据字节的序号.例如(A收到B的报文, 结束序号为100, 所以B希望下一次收到的是A的101序号开始的报文)

4.数据偏移: 指出 数据起始处距离TCP报文起始处有多远, 其实就指出了TCP报文首部的长度.

5.保留: 无用就置为0, 根据一下功能置为1.

5.1. 紧急URG: 当URG置为1, 表明紧急指针有效. 当URG=1(有紧急数据时), 此TCP报文就把紧急数据插入到本TCP报文的数据部分的最前面.

5.2. 确认ACK: 当ACK=1时, 确认序号字段生效.

5.3. 推送PSH: 当PSH=1时, 就表明要尽快将此报文交付给应用进程.不要等到发送缓存满了再发送.

5.4. 复位RST: 当RST=1时, 表明TCP连接出现严重差错, 需要释放连接并重新连接.

5.5. 同步SYN: 这是一个"在连接建立时用来同步的序号", SYN置为1表示这是一个连接请求互殴连接接受的报文

5.6. 终止FIN: 当FIN=1时, 表示此报文段的发送方的数据已经发送完毕, 要求释放连接.

6.窗口: 指的是发送这个报文段的一方的接收窗口. 发送窗口的大小就是窗口值决定的.

7.校验和: 和UDP一样

8.紧急指针: 当IRG=1才有意义, 即使窗口值为0, 也可以发送数据.

9.选项: 长度可变, 最长40字节.

(2)概述: TCP协议是一种"端对端"的可靠交付的服务, 也可以理解成点对点, 所以, 他提全双工通信, 并且, 在接收方设置一个接收缓存, 在发送方设置一个发送缓存, 用来保存临时的数据报, 最最重要的是, TCP协议是一种面向字节流的服务, 也就是说, 它关注的对象不是UDP的报文, 而是报文里面的字节流, 对字节流进行信息处理.

(3)TCP的连接方式: TCP把连接作为最基本的抽象, 很多行为都是基于连接上实行的. 运输层是根应用层打交道的, 所以我们把TCP的连接的断点叫做套接字或者插口. 格式如下: {IP地址:端口}

(1)产生背景: 要想TCP传输实现无差错.就必须满足以下两点, 传输信道不产生差错和不管发送方以多块的速率发送数据, 接收方都可以来得及处理数据. 但是, 现实的网络情况是很复杂的, 以上两个情况也不可能存在, 所以我们需要一些技术去辅助, 变相实现以上两个条件.

(2)停止等待协议: 概念: 就是每发送完一个分组就停止发送, 直到收到对方的确认, 才发送下一个分组.

(3)出现差错的情况: 无差错就是你传一个, 我就确认, 你再传下一个, 如此类推. 但是这里说明一下特殊情况. 当分组出现差错, 接收方就丢弃此分组, 然后什么都不做.  那么发送方应该有所表示, 既然接收方收不到, 发送方就要重传, 但这个重传是建立在一定要过一段时间后. 所以要在发送方设置一个超时计时器. 以便实现超时重传. 当然, 因为发送方的分组虽然是发送了, 但未必接收方一定收得到, 所以发送方要暂时保留自己发的分组. 而且 待确认分组和已确认分组 都要进行编号, 这样才能更好了解那些已经确认了.

(4)确认丢失和确认迟到的情况:

丢失: 因为接收方的确认分组丢失, 所以发送方重传, 所以接收方又收到同一份报文, 这是 接收方要么丢弃这个重复的分组, 要么向发送方发送确认！！

迟到:因为接收方的确认分组迟到了, 所以A经过重传后, 收到了重复的确认. 那么发送方就收下后, 丢弃。没有别的操作.

(1)概念: 按照我自己的理解: 就是一个分组, 里面有很多已经打上顺序编号的字节, 因为要实现无论发送方多块的发速率, 接收方都可以接受, 所以我们就 规定一个发哦是那个窗口, 这个窗口如图所示, 可设置大小.

(2)工作原理: 首先先把发送窗口里的字节都发送出去, 那接收方, 采用累积确认的方式(不必每个分组都确认， 对按序到达的最后一个分组发送确认就好了) 发送确认报文, 然后 发送方接收到确认报文后, 看一下确认分组里面最后一个分组的序号是多少,(就是看一下有N个已经确认接收了),就把发送窗口的起始位置向前推进N个.

接下来的部分就是 谈谈关于 滑动窗口, 流量控制, 拥塞控制了. 而且接下来的内容就是基于上面的内容来展开的.

(1)注意: 发送窗口是由接收方的接收窗口具体数值和当前网络拥塞程度决定的.窗口值为20.

(2)工作原理:由上图可以知道, 发送窗口是由三个指针来决定的（在(1)之后）, 现在, A发送了31-41的字节, 但还没收到确认,  再看看B接收方. 显然, 31是已经收到并发送确认报文了, 所以B发送的确认报文是31序号. 很显然B也只收到了31, 31以后的32.33都没收到.所以就要求A重传32.33-》( A就把发送窗口P1移到32, 并从32开始发字节。)

(3)假定32和33字节B都已经收到了, 那么再把A的放松窗口往前推(即P1(34位置)), 然后再把P3往后推,P2保持不动,窗口值仍为20

(4)现在继续传34-41,在B接收方看来. 31-41的字节, 剩下37,38,40没有收到, 所以B就发送36的确认分组给A。A重传37-41(就是重复(2)的操作). 即如果A收到B的确认号落在A的发送窗口内, 那么A就使发送窗口向前移动, 并发送新数据.

(5)直到发完全部字节(即P2和P3指针重合), 这样就全部发送完成了.

(6)TCP通常对不按序到达的数据先临时存放在接收窗口中, 等到缺失的字节补回来, 再上交给应用层.

TCP采用自适应的算法,  对报文的往返时间(RTT) 进行加权平均, 得出平滑的往返时间, 并且, 对于报文重传的情况: 这一次就不采用加权平均, 而是直接将重传时间增大两倍. 直到分组不重传.

(1)在8.滑动窗口中的(6)中, 我们提到: 可以将不按序的数据先存放在接收临时窗口先, 等连续了再交付

(2)那么我们怎样才能让发送方知道那些序号是缺失了呢.

(3)我们使用选择确认来实现. 利用两个指针来描述出缺失序号的起始位置和终点位置, 并将在即将返回的确认分组中添加这两个指针的信息.

(4)这样下一次发送方发送的就是这个缺失序号段的内容了.

http://blog.csdn.net/sicofield/article/details/9708311

http://blog.csdn.net/sicofield/article/details/9708383

(1)建立连接:三次握手
1. 首先, B的TCP服务器创建 传输控制块(TCB),准备接受请求, 然后B处于监听状态.

2. A的TCP客户端也创建传输控制块TCB, 并向B发出请求报文段, 这里SYN必须为一喇, 肯定的. 然后初始序号SEQ就给一个X把.

3. B收到请求后, 确认同意连接, 所以呢ACK也必须为1拉, SYN也为1, 确认号ack=x+1, 并且自己初始事序号SEQ=Y.

4. A客户端收到B的确认后, 还要给B 一个确认收到确认的报文. ACK也肯定为1, 确认号为ack=Y+1, 然后这属于A的第二个报文, 所5. 以SEQ=X+1;

5. 就这样, TCP连接就建立了.

(2)为什么要最后确认B的确认报文,? 当B没有收到A的请求而致使A重传请求报文, 当重传的请求生效并且完成到释放连接的部分时, B收到了A第一个请求的报文, B就误以为A又要请求连接,并确认连接, 产生新的连接. (这个情况叫 "防止已经失效的连接请求突然接收方又收到了").

(1)释放连接: 四次挥手
1. A想要关闭连接, 就发送报文. 首先FIN=1 必须的, 给个初始序号给他把 SEQ=U(这个U等于前一个报文的最后一个字节+1).

2. 这时A进入等待结束状态, B 收到释放连接的报文后, 肯定给予确认嘛, 所以ACK=1,ack=U+1, 也给一个B的初始序号给它, SEQ=V.

3. 这时, TCP 处于半关闭状态, 因为是A提出关闭的, 所以A就没有数据传给B , 但是如果B有数据传给A , A一定要接收.

4. A收到B的确认报文, 整个TCP处于半关闭状态后, 就剩下最后一步, 等待B也发送 释放连接的请求.(相当于把半关闭状态提升为全关闭状态)

5. B发送释放链接报文. FIN=1, ACK=1, ack=u+1(相当于还是回复A的u报文嘛), 重新给个初始序号给它SEQ=W.

6. 当A收到B的请求释放连接报文后, A也要做出回应的嘛, 所以ACK=1, ack=w+1(回复B的请求),SEQ=U+1. 发了之后, 进入"时间等待" 状态.  经过时间等待计时器设置的2MSL后, 才算是完全释放了TCP连接.

7. 除了时间等待计时器, 还有一个保活计时器, 如果客户端突然出现故障, 为了不让服务器端白白等下去呢, 就设计这个计时器,: 一段时间之后，发送一个探测报文段, 若连续发10个都没有回应, 就自动断开连接把.