计网复习第三章part one

最新推荐文章于 2024-06-22 12:56:38 发布

桃地睡不着

最新推荐文章于 2024-06-22 12:56:38 发布

阅读量529

点赞数 1

分类专栏：计网文章标签：计网计算机网络

本文链接：https://blog.csdn.net/Q_U_A_R_T_E_R/article/details/116949391

版权

计网专栏收录该内容

1 篇文章 0 订阅

订阅专栏

写在前面：
此博客仅用于记录个人学习进度，学识浅薄，若有错误观点欢迎评论区指出。欢迎各位前来交流。（部分材料来源网络，若有侵权，立即删除）
记录计网学习（复习）

计网学习第三章 part one

3第三章运输层

3第三章运输层

3.1运输层服务

3.1.0概述

运输层协议提供逻辑通信，在端系统中实现（provide logical communication between app processes running on ifferent hosts）
分组：报文段（segment）
服务于运行在不同主机上的进程
中间路由器既不处理也不识别运输层加在应用层的任何信息
运输协议能够提供的服务常常受制于底层网络层协议的服务模型

3.1.1运输层和网络层的关系

TCP(传输控制协议)/reliable
- data delivery and error checking
- flow control
- congestion control
- connection setup
UDP(数据用户报协议)/unreliable
- only provide data delivery and error checking
- no-frills extension of “the best”
底层网络协议是不可靠的，会使分组丢失、篡改和冗余
运输层协议能为应用程序提供可靠的数据传输服务

3.1.2因特网与运输层的关系

TCP和UDP的分组统称为报文段
因特网网络层协议：IP（网际协议）
- 为主机之间提供逻辑通信
- IP的服务模型是尽力而为交付服务（ best-effort delivery service）
- 不做任何确保
  - 不确保报文的交付
  - 不保证报文的按序交付
  - 不保证报文段数据中的完整性
进程到进程间的数据交付与差错检查是两种最低限度的运输层服务

3.2多路复用与多路分解

多路分解与多路复用：将主机间交付扩展到进程间的交付
一个进程有一个或多个套接字（socket）
运输层将数据交付给套接字
每一个套接字都有唯一的标识符
标识符的格式取决于它是UDP还是TCP套接字
多路分解（demultiplexing):将运输层报文中的数据交付到正确的套接字的工作
多路复用（multiplexing）在源主机从不同套接字中收集数据块，并为每一个数据块封装首部信息（这在以后用于分解）从而生成报文段，然后将报文段传递到网络层
运输层多路复用要求：
- 套接字有唯一标识符
- 每个报文段有特殊字段来指示该报文段所要交付到的套接字
0-1023端口:周知端口号
- HTTP:80
- FTP:20,21
- DNS:53
- IMAP:143
- SMTP:25
- POP3:110
1023-65535:动态/私有端口

3.2.1无连接的多路复用和分解

每个进程有自己的UDP套接字及相应的端口号
网络到达TCP报文段时，主机通过检查该报文段中的目的的端口号，将每个报文定向（分解）到相应的套接字
一个UDP套接字是由一个二元组来全面标识：
- 目的IP地址
- 目的端口号
二者相同就会被套接字定位到相同的目的的进程
源端口号：用作“返回地址”的一部分

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

TCP套接字由一个四元组来标识：
- 源IP地址
- 源端口号
- 目的IP地址
- 目的端口号
两个具有不同源IP地址或源端口号的到达TCP报文段将被定向到两个不同的的套接字；除非TCP报文携带了初始创建连接的请求。
到一个TCP报文段到达主机时，所有4个字段被用来将报文段定向到相应的套接字
连接1套接字与进程之间并非总是有着一一对应的关系

3.3无连接运输：UDP

“我们必须做一点点事，而不是什么都不做”
UDP协议只是做了运输协议能够做的最少工作，除了复用/分解以及少量的差错检测外，它几乎没有对IP增加别的东西
UDP被称为是无连接的：发送方和接收方的运输实体之间没有握手
TCP20字节首部开销
UDP8字节首部开销
UDP uesed in:
- streaming multimedia apps (loss tolerant, rate sensitive)
- DNS
- SNMP (Simple Network Management Protocol)
- RIP (Routing Information Protocol)
应用首选UDP原因：
- 关于何时、发送什么数据的应用层控制更为精细
- 无需建立连接
- 无连接状态
- 分组首部开销小
UDP和TCP都用于多媒体应用，如因特网电话、实时视频会议、流式储存音频与视频
使用UDP是可以实现可靠数据传输的
- 通过在应用程序自身中建立可靠性机制来完成
  - 例如通过增加确认与重传机制来实现

3.3.1 UDP 报文段结构

UDP首部仅有四个字段每个字段两个字节，一共32比特
- 源端口号
- 目的端口号
  - 使目的主机将应用数据交给运行在目的端系统中的相应进程（执行分解功能）
- 长度
  - 指示了在UDP报文段中的字节数（首部加数据）
- 检验和
  - 使用检验和来检验在该报文中是否出现了差错

3.3.2 UDP 检验和

检验和提供了差错检验功能
发送方的UDP对报文中的所有16比特字的和进行反码运算，求和时遇到的任何溢出都被回卷
得到的结果被放在UDP报文段中的检验和字段
在接收方，全部的4个16比特字（包括检验和）加在一起，如果分组中没有引入差错，则显然在接收方处该和将是1111111111111111，如果这些比特之一是0，那么该分组已经出现差错
端到端原则（end-end principle）:在既无法确保逐链路的可靠性，又无法确保内存中的差错检测的情况下，如果端到端数据传输服务要提供差错检测，UDP就必须在端到端基础上在运输层提供差错检测
UDP提供差错检测，但它对差错恢复无能为力
UDP的某种实现只是丢弃受损的报文段，其他实现可以是将受损的报文段交给应用程序并给出警告

3.4 可靠数据传输原理

可靠数据传输协议（reliable data transfer protocol）:RDT
不可靠数据传输（udt）
单向数据传输（unidirectional data transfer)
双向数据传输（bidirectional data transfer）

3.4.1 构造可靠数据传输协议

经完全可靠信道的可靠数据传输： rdt 1.0

底层信道完全可靠：rdt：1.0
有限状态机（Finite-State Machine,FSM)
sender sends data into underlying channel
receiver reads data from underlying channel

在这里插入图片描述

经具有比特差错信道的可靠数据传输：rdt 2.0

underlying channel may flip bits in packet
- still assume the packets arrive at receiver in order, no loss
- checksum to detect bit errors
肯定确定（positive acknowledgment)
否定确认（negative acknowledgment)
如何恢复
- (positive) acknowledgements (ACKs): receiver explicitly tells sender that pkt received OK
- negative acknowledgements (NAKs): receiver explicitly tells sender that pkt had errors (need repeat)
- sender retransmits pkt on receipt of NAK
基于重传机制的可靠传输协议称为自动重传请求（Automatic Repeat ，ARQ）协议
- 差错检测（ error detection）
- 接收方反馈： feedback（肯定确认：ACK,否定确认：NAK）
- 重传（retransmission）

在这里插入图片描述

rdt2.0的发送端有两个状态
1. 发送端正在等待，产生rdt_send(data)事件时，发送方将产生一个包含待发送的数据的分组（sndpkt）带有检验和，如何经udt_send(smdpkt)操作发送该分组
2. 发送方协议等待来自接收方的ACK或NAK分组
  - 如果收到ACK分组，则发送方知道最近发送的分组已被正确接收，因此协议返回到等待来自上次的数据的状态
  - 如果收到NAK分组，该协议重传最后一个分组并等待接收方响应重传分组而送回送的ACK或NAK
  - 当发送方处于等待ACK或NAK时，它不能从上层获取更多的数据，仅当接收到ACK并离开该状态时才能获取更多的数据
rdt2.0的接收端仅有一个状态
- 当分组到达时，接收方回答ACK或NAK，取决于分组是否受损
缺陷：ACK与NAK分组受损
- introducing a new type of sender-to-receiver packet, similar to human say “what did you say?”
  - Receiver repeat the ACK/NAK packet
  - “What did you say?” is corrupted?
- add checksum bits to allow the sender to detect and recover (effective for corrupt packets but no loss, How to solve the problem of ACK/NAK loss?)
- sender simply to resend the current data packet when receives a garbled ACK or NAK packet!
要点：正确收到ACK则发下个新数据，正确收到NAK则重发老数据，无法确认ACK或NAK（错误数据）则重发老数据，避免漏发
解决上述问题的一个新方法：在数据分组中添加一新字段，让发送方对其数据分组编号，即将发送数据分组的序号（sequence number）放在该字段。

rdt 2.1

sender, handles garbled ACK/NAKs

在这里插入图片描述

receiver, handles garbled ACK/NAKs

在这里插入图片描述

rdt 2.1使用了从接收方到发送方的肯定确认和否定确认
- 当接收到失序分组时，接受方对所接受的分组发送一个肯定请求
- 如果收到受损的分组，则接收方将发送一个否定确认
- 发送方接收到对同一个分组的两个ACK（冗余ACK duplicate ACK）后，就知道接收方没有正确接收到跟在被确认两次的分组后面的分组