1.传输层的服务和协议
上下文:上层应用层,下层网络层。传输层的作用是实现进程间的逻辑通信。
收到来自应用层的消息将它拆分为一个个segment向下通过socket传递给网络层,收到网络层提取的segment还原为组装为消息通过socket上交给应用层。
socket编程即是封装了两种传输层的协议UDP+TCP(也可以自定义写其他协议)给上层应用层。很多时候应用层编程会使用UrlConnection比直接使用Socket要简单的多,不用关心状态和线程治理。 UrlConnection基于Http协议,只是进行了封装,添加了一些额外规则(如头信息),本质上也是建立TCP连接,利用Socket实现连接和传输数据的。
2.传输层技术层面
2.1 多路复用分用
比起无连接的分用有连接的分用有四个标识的字段,可以更加精准的建立连接导向到指定的socket,无连接只可以通过端口号来导向(意味着端口号必须不同),有连接的分用则可以使用相同的端口号,因为还有其他字段的存在。
2.2 可靠数据传输
a图介绍了可靠数据传输的角色是在应用层之下提供一个可靠数据传输,b图说明可靠数据传输通过对传输层前后的数据做处理进而为上层服务。
Rdt 1.0就是最原始的模型,可靠数据传输通过实现对data的make_pkt()方法使得传输的data不错不丢。这个FSM(状态机)比较好的阐述了可靠数据传输实现的机制。
因为前面rdt1.0假设不会发生位错误,都是实际会在传输过程发生位错误。增加校验和如果错误就发送NAK让发送方重新发送。诞生了rdt2.0 停等协议 一直在停和等待的状态
也就相当于对接收方不发送NAK,收到重复的ack就相当于nak。发送带有序号的ack,发送方如果不是想要的ack0就继续重新发送数据包0,如果收到ack0就发送数据包1。
rdt3.0针对分组如果丢失分组产生无限等待的问题增加计时器,超时重传。
rdt3.0虽然可以正确的工作,但是由于还是停等协议,所以浪费了资源带宽。起码rdt3.0完成了它的任务可靠数据传输。
rdt3.0效率低分析:由于只发送一个分组就陷入等待接收确认,这样一个分组发送等待确认再发送的机制(只需要一个bit的序列号就可以满足不接受重复的分组)效率低。
2.3 滑动窗口协议
滑动窗口协议是一种流水线协议 问题明显:没有缓存--丢弃分组效率低发送方和接收方的窗口大小之和应该小于序列号总数
2.4 拥塞避免
如果网络拥塞情况严重,路由器或者交换机将data里特定的标记网络拥塞情况的bit置1,接收方将该信息返回给发送方从而控制发送速率实现拥塞控制。
2.5 流量控制
设置buffer来通过在返回的segment里面增加返回接收窗口大小来实现。具体研究TCP的流量控制实现。
3. UDP 尽力而为
只完成传输层的基本任务,实现进程之间的通信。
segment结构如下:数据保存的就是封装的应用层的message数据。
4. TCP 可靠服务
4.1 TCP可靠数据传输
设置timer的值来控制是否重发关于GBN和SR与TCP
TCP的实现运用了之前介绍的RDT系列算法里面的一些机制,也借鉴了滑动窗口协议的机制。比如TCP采用了累积确认,和SR类似有缓冲区,但是ack的含义不同于SR,ack为期待接受的下一个数据报文的序号,它有快速重传机制,可以提高效率,发送多个ack,发送方收到重复的ack(意味着可能发生了超时或丢包)时候就会重传。
4.2 TCP流量控制
流控是针对接收方的接收速度和拥塞控制不同,拥塞控制是数据在网络传输过程,也就是在路由器的缓存有限防止路由器丢包和崩溃导致数据丢失和传输过慢。
4.3 TCP连接管理
TCP建立的三次握手第三次可能就携带数据比如html请求之类的信息,注意SYN的变化110
释放过程4次挥手 TCP连接建立和关闭的生命周期
4.4 TCP的拥塞控制
上图和教材版本不同仅作为参考
发生timeout时候congwin减少为1开始慢启动,threshold折半
收到三个ack时候congwin折半+3,threshold折半启动拥塞避免开始线性增长
控制机制:监控segment接受的状态(超时和3个ack)---->启动拥塞控制协议---->慢启动和拥塞避免----->congwin的值发生改变---->发送方根据rate = congwin/RTT的速率发送
其实是通过congwin(一个描述当前拥塞程度的量)来控制发送速率
4.5 TCP探讨
TCP在发送很多的数据时出现丢包率严重,未来的TCP需要重新改进设计。
对于请求打开多个TCP连接请求获得更多的速率 不公平。
网友评论