计算机网络----运输层

《运输层概述》

 

 

 

 

　　解释：

　　　《端口》

　　　　

 

　　　　具体书P214

　　　　两台主机进行通信就是两台主机中的应用进程相互通信

　　　　所谓的端到端的通信也就是应用进程之间的通信

　　　　这个端就是所谓的 　端口

　　　　　　　　　　

 

 

 　　　　　　　　从图中可以看出，端口位于应用层与运输层之间

　　　　　　　当应用层中的应用进程要通过运输层发到互联网要通过端口

　　　　　　　当别的主机上的应用进程要寻找本机中的某个应用进程，也要通过端口

　　　　　即端口是应用层与运输层进行数据交互的地点，每一个应用程序至少有一个端口

 

　　　　TCP/IP的运输层用一个16位端口号来标识一个端口

　　　　《服务器端使用的端口号》

　　　　　　这一类端口号又叫做熟知端口号，数值1~1023

　　　　　　一般是TCP/IP上最重要的应用程序在用

　　　　　　　　如：

　　　　　　　　FTP:21　　DNS:53　　HTTP:80 等

　　　　　　

　　　　《客户端使用的端口号》

　　　　　　　　　　数值为49152~65535

　　　　　　留给客户进程临时使用

　　　　　

　　《运输层协议必备功能》

 

 　　　　　　1.复用与分用

　　　　　　

 

 

 

　　　　　　复用：发送方不同的应用进程都可以使用同一个运输层协议传送数据

　　　　　　分用：接收方的运输层在去除报文首部后能够把这些数据正确交付给目的应用进程

 

　　　   2.差错检测

　

 

《UDP与TCP的对比》

　　《首部均有源端口号与目的端口号》

　　　　

 

 

 　　　　

　　　《是否需要连接》

　　　　　　

 

 

 　　　　　　　　

　　　　　UDP是在任何时候都可以进行数据的传输

　　　　　而TCP在传输时需要进行三报文握手

　　　　　　　　在结束时继续四报文挥手

 

　　　《多交换通信与一对一通信》

　　　　

 

 

 

 

　　　　　　　　

 

 

 

 　　　　　　　　TCP仅支持单播

 

 

 

　　　　《面向应用报文与面向字节流》

 

 　　　　　　

 

 

 　　　　　　UDP在处理应用层的应用报文时，直接将应用报文套上UDP首部即可

　　　　使之称为UDP应用数据报，然后发送

　　　　　　接受方在接受到数据时直接除去UDP首部

 

　　　　

 

 

 

　　　　而TCP将应用层报文看成是一连串无结构的字节流，给他们编号

　　　　　　

 

　　　　《不可靠服务与可靠服务》

　　　　　　　　

 

 

 

 

 

 　　　　　　　　接受方UDP在检查出错误后直接丢弃数据报，

　　　　　发送方不做出然后反应

　　　　

　　　　

 

 

 

　　　　接受方TCP在检查到错误后丢弃（具体在TCP中讲）

　　　　发送方会因为没有接受到接受方的响应而重新传送

 

　　　《首部的区别》

　　　　　

 

 

 

 

　　　　　UDP的数据报仅仅只在网际层的基础上添加了用于区分应用进程的端口

　　　　　

 

 

 

《UDP》

　　　

 

 

 　　　伪首部即不向下传递  也不向上递交，其只是在计算检验和时，临时添加在UDP

　　那么检验和的过程是什么？

　　　　在发送方：

　　　　　　1.首先把全零放入检验和字段

　　　　　　2.再把伪首部以及UDP用户数据报中的数 转化为16进制，每一个数有8位

　　　　　　　以16位为一组

　　　　　　　然后进行相加

　　　　　　　最后求和的反码

　　　　　　　然后将结果写入检验和

　　　　在接收方：

　　　　　　1.将接收到的检验和 与 伪首部（接收方的伪首部不是接收到的，而是自己生成的）

　　　　　　　的数 转化为16进制　　　

　　　　　　　以16位为一组

　　　　　　　然后进行相加

　　　　　　2.如果结果的每个位上全为1，说明无差错

　　　　　　　否则有差错，应该要丢弃

　　　　

 

 

 　　　　　　 比如上述：

　　　　　　153.19

　　　　　　其中将153转化为16进制，有8位

　　　　　　即是1001 1001

　　　　　　19同理 0001 0011　　

 

 

 

 《TCP》

　　《TCP概述》

　　　　　　这里解释一下:

　　　　TCP提供可靠交付的服务：

　　　　　　即通过TCP连接传送的数据：无差错，不丢失，不重复，并且按序到达

　　　　TCP提供全双工通信：

　　　　　　即通信双方的应用程序在任何时候都能够同时收发数据

 

　　　　每一条TCP连接唯一地被通信两端的两个端点,即套接字（IP+端口号）

 

　　《TCP报文段的首部格式》

 　　　　　　

 

 　　　　　　

 

 　　　　　　　　　　　　

 

 　　　　　　　　

 

　　　　　　　　　　像seq表示的是序号

　　　　　　ack表示的是确认号

 

　　　　　　　　

 

 　　　　　　　　

 

 　　　　　　　　

 

 

　　　　　　

 

　　《停止等待协议》

　　　　即 发送方每发送完一个分组就停止发送，等待对方的确认

 

　　　当发送方发送完成一个分组后，必须暂时保留已发送的分组的副本

　　　　只有在受到接收方的接收确认后才能清除

 

　　　分组和确认分组都必须进行编号

 

　　　当发送方超过了一段时间仍然没有接收到确认，则认为刚才发送的分组丢失了

　　　　　则进行超时重传

 

　　　当接收方接受到了重复的分组，则直接丢弃，并再次发送这次分组的确认信息

 

　　　

 

 

 　　　　　可见停止等待协议的信道利用率不太高（P224）

　　　 TD=分组长度/发送速率

　　　 即 U=TD/（TD+RTT+TA）

 

 

　　　TA一般忽略

 

　　　上述的协议也叫自动重传协议 （ARQ）

　　　 为了提高信道利用率 ，我们有

　　　　连续ARQ协议（回退N (GBN）协议)（选择性重传协议 （SR））

　　　

 

 

 

 

　　《连续ARQ协议》

　　　　《GBN》

　　　　

 

 

 　　　　　　可见只要没有按序受到分组则先到的分组全部丢弃

　　　   这是比较浪费的，显然我们可以改进

 

　　　　这里要注意的点是：

　　　　　　1.注意重发的规则：

　　　　　　　　

 

 　　　　　　　　　　　　后面所有已发送但未被确认的分组

　　　　　　2.注意累积确认机制：

　　　　　　

 

 　　　　　　　　　　比如5号分组确认了，4号一定发送成功了

　　　　　　如果4号没被确认，说明

　　　　　　　　要不就是接受方的确认丢失了

　　　　　　　　要不就是发送方的4号分组丢失了

　　　　对于前者，如果收到了5号分组（或者更后面的分组）的确认，那么4号分组的确认也就无所谓了，

　　　　反正一定4号分组被接受方受到了

 

　　　　后者接受方对于4号之前的分组一律不收，4号以后的确认一定发不出了

 

　　　　所以可以得出上面的结论

 　　　　　　　　

 

 　　　　　

　　　　　　　　　则要重传的是 4 5 6 7

 

 

 　　　　　　　　

　　《SR（选择性重传）》

　　

　　　　　　SR利用了　TCP可靠传输的实现技术中的　　滑动窗口

　　　　 其还可以携带  TCP可靠传输的实现技术中的   SACK 选择确认

　　　　 实现 可以缓存非按序的分组 和 不用重发确认的分组 的功能

　　　　  

 

 

 　　　　　　　　如图：

　　　　　　对于丢失的2号分组，接受方在发出确认时一直都附带着 

　　　　　　　　2号分组没有确认的信息

　　　　　　所以发送方这里的窗口一直停在2号分组这里，直到发送方接受到了2号分组接受到了的信息

 

　　　　注意因为SR 没有累计确认的功能

　　　　1号分组受到了确认，不代表0号分组发送成功了

 

　　　　

 

 　　　　　　　　

 

 　　　　   注意这里只要重发已经确认超时的，所以 为0,2

 

　　　而3还不知道有没有超时，所以不用重发

 

 

 《TCP可靠传输的实现》

　　需要注意的是实现可靠传输，滑动窗口并不是必须的

　　差错检测　　序号和确认　　超时重传 　

　　这三个才是必须的

　　1.以字节为单位的滑动窗口

　 2.超时重传的时间选择

　　　　d

 

 

　　　　超时重传时间RTO 应该略大于 往返时间RTT

 

　　　　所以有RTO=RTTS+4*RTTD

 

　　　　RTTS是平均加权RTT，RTTD是RTT的偏差的加权平均值

 

　　　　其计算如上

 

　　　　注意初始值

 

　　　　如果现有RTT1

 

　　　　　　则 知道RTTS1,RTTD1

 

　　　　　　如果现在还知道RTT2

 

　　　　　　则　　

 

　　　　　　　　RTTS2=(1-a)*RTTS1+a*RTT2

 

　　　　　　　　RTTD2=（1-b）*RTTD + b*| RTTS1-RTT2 |

 

 

 

　 3.选择确认SACK

 

 

 《TCP的运输连接管理》

　　《TCP的连接建立》

　　解释:

　　首先A创建TCB（传输控制块），B也创建TCB

　　注意同步位SYN=1时，报文不能携带数据

　　　　但是要消耗一个序号，

　　　　体现在虽然

　　　　　　但是

 　　即x这个序号被消耗了

 

　　相比之下，ACK=1时，报文可以携带数据，同时在无数据时不消耗序号

　　体现在：　

　　B的y序号被消耗了，A这边ack=y+1

　　《为何需要三报文握手？不要最后一次A的响应 行吗？》

　　　　答案肯定是不行的

　　　　考虑，如果某次A的第一次连接报文在网络中延迟了

　　　　在后面才发送到B

　　　　这个时候B肯定要为这个请求连接的报文分配资源

　　　　同时发送响应报文

 

　　　　如果A不回复，B如何知道这个请求连接的报文原来是错误的

　　　　同时还占用了B的资源

　　　　

　　　　所以我们设定，如果最后一次A不回复，那B就撤销资源与连接

 

《TCP的连接释放》

、

　　解释：

　　　FIN=1时，即使没有携带数据也要消耗一个资源，表现为：

　　A的u序号被消耗掉了

　　在A发送FIN=1的报文后，A到B这个方向的TCP连接就释放掉了

　　即A不能再向B发送含数据的TCP报文

　　但是A还可以接受数据并响应

 

　　当B发送FIN=1的报文后，A接受响应后，不会立即进入CLOSED

　　而是进入 TIME-WAIT，经过时间等待计时器设置的时间后才能进入CLOSED

　　其中等待的时间单位为MSL,最长报文段时间

　　一般时间等待计时器设置的时间为2MSL

 

　　同时B这边还要设置一个保活计时器，目的是防止客户端

　　长时间占用服务端资源而不发信息的情况

　　

　　《为何要设置时间等待计时器？》

　　1.保证A发送的最后一个ACK报文段能够到达B，使B能够正常进入CLOSED

　　　　因为可能A的最后响应会丢失等

 

　　2.使本次连接持续时间内所产生的所有报文段都从网络中消失

　　　防止下一个连接中不会出现旧的连接请求报文段

　　

　

 《TCP的流量控制》

 

 

 　

 

 　　　　　　解释：

　　　　当A与B建立TCP连接后，B就对A进行流量控制，即告知A，A的窗口大小应该是多少

　　　　然后A就可以将窗口中的分组数据，一组一组进行发送

　　　　seq 表示

 

 

　　　　然后看对于丢失是如何处理的：

　　　　　　首先接收方每受到一个分组的数据后，接收方的滑动窗口也会进行移动（注意肯定是按序接受后才会移动）

　　　　　　然后给发送方进行发送确认信号，同时可以附带上流量控制信息

　　　　　　调整发送方的滑动窗口大小

　　　　　　对于接收到的分组，接收方先保留着（这些分组肯定在接收方的滑动窗口之内），

　　　　　 

　　　　　　然后发送方这边是接受到了确认信息，然后滑动窗口也会移动（注意肯定是按序接受后才会移动）

　　　　　　同时也会进行超时重传

 

　　　

　　　　当接收方给发送方发送的流量调控是发送方的滑动窗口应该为0时

　　　　后面发送方的滑动窗口大小一直为0吗？

　　　　不，接收方会根据自身可接受的情况给发送方继续进行调控

　　　　

 

 　　　　　　   如果这个调控丢失了，发送方长时间处于零窗口的局面

　　　　那么发送方就会发送一个确认

 

　　　　　　　接收方也会给出响应，对发送方进行流量控制

 

　《TCP的传输效率问题》

　　《问题一：接收方何时将流量控制信息发给发送方？》

　　　　想象一下如下场景：

　　接收方在发送完 rwnd=0 后

　　这个时候接收方这里的缓存多出来了1bity

　　然后将这个信息发送给发送方，告知发送方可以发1bity来了

　　然后持续这个过程

　　

　　你会发现：由于发送的数据过少，发送的TCP首部过多（一个TCP报文首部是40bity）

　　所以网络中的效率是十分低的

　　这个问题也被称为糊涂窗口综合征

　　咋办？

　　　　让接收方有空闲缓存后等待一段时间

　　　　使得接收缓存已有足够空间容纳

　　　　一个最长的报文段 或 有一半的接收空间

　　

　　《问题二：发送方何时发送数据？》

　　再来想象一下如下场景：

　　　　发送方每次都发送1bity（没错跟上面一样）

　　然后可想而知

 

　　咋办？

　　三大机制：

　　　　1.TCP维持一个变量，其等于最大报文段长度MSS

　　　　　一旦缓存中存放的数据达到MSS字节，

　　　　　就组装成一个TCP报文段发送出去　　

 

　　　　2.发送方进程指明要求发送某个报文段（即push操作

　　　　　　在TCP首部的标准位上有这个标志）

　　　　

　　　　3.发送方计时器期限到了，将已有的缓存装入报文段（当然不能超过MSS字节）

　　

　　Nagle算法：

　　　　发送方将第一个数据字节发送出去（试探一下）

　　　　如果受到这个的确认

　　　　再将缓存的数据字节组装成报文段发送出去，

　　　　只有在接受到了上一个报文段的确认后，才能发送另一个报文段

　　　　当缓存的数据到了 发送窗口大小的一半 或 到达报文段的最大长度

　　　　立即发送一个报文段

 

《TCP的拥塞控制》

　　所谓的拥塞 

　　即 对网络中某一资源的需求超过了该资源所能提供的可用部分

　　网络性能下降

 

　　注意这里强调的是：

　　　　网络中的

　　与流量控制不同的是，流量控制强调的是端与端之间的

　　即接收方的状态影响发送方的状态

　　拥塞控制是网络的状态影响发送方的状态

　　（如网络中的某一个节点缓存不足，处理速度不行等）

 

　　拥塞控制是通过该拥塞窗口cwnd 与 一些算法来实现的

　　　　　　　其中cwnd是发送方自己持有

　　　　并且通过超时计时器，是否接受到响应等（根据一下规则）

　　　　自动变化的

　　　　　　

　　　　cwnd与流量控制中接收方的rwnd一起决定了

　　　　发送方可以发送数据的数量

　　　　　　　即 发送方窗口的上限值=min (rwnd,cwnd)

 

《拥塞控制的方式》

　　慢开始和拥塞避免

　　1.慢开始

　　　　即TCP发送报文段时，只发送1个报文段，cwnd=1

　　　　(cwnd的初始设置又新旧版本之分，具体看实际情况，P241）

 

　　　　　慢开始阶段规定：

　　　　每一次受到一个新的报文段确认后（即一个RTT时间）

　　　　cwnd+=min（N，SMSS）

　　　　其中N 是 原先未被确认的，但现在刚被受到的确认报文段所确认的字节数

　　　　SMSS 是 Sender Maximum Segment Size,

　　　　即发送方最大能够发送的报文段数值

 

　　2.设置慢开始门限 ssthresh 状态变量

　　　当cwnd>ssthresh 停止使用慢开始算法

　　　转而使用拥塞控制算法

　　（当cwnd==ssthresh，两个算法都可以用）

　　

　　3.拥塞避免算法

　　　　cwnd开始每经过一个RTT

　　　　则cwnd++

　　

　　 4.遇到超时咋办？

　　　　ssthresh = cwnd/2

　　　　cwnd=1

　　　　

《快重传和快恢复》

　　这两个算法都是为了避免发送方误以为超时

　　导致错误地实现

　　　　我们之所以对超时进行行动是因为我们认为那是网络拥堵导致的

　　 而不是发送方某个报文段意外丢失导致的

　　 意外丢失并不能说明网络拥堵

　　为了解决这个问题，有一下方案：

 

　　重复确认

　　　快重传是针对接受方来说的

　　　当接收方受到了发送发来的A1，A2

　　　但是A3意外丢失

　　　接受方本来什么都不用做（发送完应该有的响应后 就行了）

　　　但是这里接受方要立刻发出（不等待自己发送数据时捎带）

　　　已经按序受到的报文段的最后一个报文段的重复确认

　　　

　　　这里是A2

　　　在发送方后面未按序到来的报文段被接受方接受后

　　　接受方立刻发送

　　　已经按序受到的报文段的最后一个报文段的重复确认

　　　这里是A2

 

　　快恢复 与快重传

　　　当发送方接受到3个连续的重复确认后

　　　立即快重传

　　　这里快重传A3

　　　　然后知道这一次不是超时，而是报文段丢失了

　　 这个时候

　　　　ssthresh =cwnd/2 

　　　　cwnd=ssthresh

 

《总结》

 

 

《练习》　　　

　　这里需要注意的是：

　　当拥塞窗口cwnd增长下一次要大于ssthresh时

　　则按照避免拥塞窗口的方法进行增长

　　

　　比如这里 cwnd 依次为 

　　　　1 2 4 8 12 （注意不是16）13 .... 16 1 2 4 8 (注意ssthresh 变成了8) 9

　　所以第14次cwnd=9

 

 

 

　　根据这幅图确实应用层提供的是一串无结构的字节流（TCP看成是一串无结构的字节流）

　　然后TCP就开始分块（即形成数据块）

　　TCP发送的数据块个数a， 在接收方处可能将这a个数据块重铸成了b个数据块往上交了

　　

　

需要小小记忆：

 

 

 

TCP首部最小20个字节，UDP首部固定8个字节

TCP源端口和目的端口 占 16位（2个字节），注意序号和确认号为32位（4个字节）

UDP源端口和目的端口 占 16位（2个字节），其余都是16位（2个字节）

 

TCP 中 WIN 是流量控制的字段，为流量窗口的大小