计算机网络Revision--ch03：传输层-UDP--Transmission Layer

Posted 2021-06-27 temporary2021.6期末复习版

传输层协议与进程通信

乍一看标题，咦，进程通信？学操作系统了，我也很诧异。
这一章very important，同时内容太多，会按照自己的理解【自己心目的重要性进行内容篇幅的分配】来组织。

3.1 传输层基本概念
网络层进行的是“主机->主机”间的通信(是第四章的内容)，我们俗称就是“点->点”。传输层刚好在其上面一层。其能实现的是主机进程间(就是我们操作系统里那个pid)的通信，我们称为“端->端”通信。

网络层是由运行商提供服务的（中国移动，联通……），用户只能在其上加上一层传输层来改善服务质量。比如赋予传输层一些功能：对分组丢失或者线路故障进行检测，再厉害一点就可以进行补救。

概念：传输层中实现传输协议的硬件和软件称为“传输实体”【可能在操作系统内核或者单独的进程中】，传输层间传输的报文我们称为“TPDU（transport protocol data unit）”。报文格式长这样：

有效数据来自应用层，传输层负责加上TPDU头部。
网络层中加上IP分组头部后，最后到数据链路层加上帧头和帧尾就成功了。

这里有个Socket套接字，这个比较适用于编程实践当时java被逼死，建议好好学Python吧，总感觉同为脚本解释语言，Python好一丢丢 所以就粗略讲一下概念。整体的概念图如下：

当然了我们就是开发者，我们站在应用层最高的角度看问题，屏蔽了很多问题（无需考虑物理链路……）。
至于TCP和UDP传输协议，在Linux操作系统中有tcp.c源代码，也就是说协议这玩意儿人家都给你设计好了，你啥都不用管。
你用“Socket”管啥？
你可以选择TCP或者UDP、你也可以设置你的最大缓存（是接受或发送取决于你的角色是服务器还是客户端）、最大报文缓存……就酱。

前边我们说了传输层干的就是“端->端”通信，那么一个重要问题就是怎么标志一个端？其实就是标识一个进程。我其实前面也已经提到操作系统里的知识啦，就是那个pid，我们在Linux系统下可以用ps或者top还有其他来看。
那么在计网中，我们称之为端口号，毕竟听起来也和“端->端”更搭配。
简单的例子：
一个IP地址为202.1.2.5的客户端用3022号端口号，那么其套接字就是
202.1.2.5:3022。

2¹⁶ = 65536，这就是我们所有的端口号了（0～65535）。
我们将其做一些分类：
比如一些比较常用的服务进程像什么域名解析DNS就得到53，什么超文本传输协议HTTP得到80。除非你和我说你不上网！！ 这类服务进程非常重要且常用，我们称为“熟知端口号”：给每种服务器分配确定的全局端口号，范围为（0～1023）。

我们当然也需要一些临时端口号，当服务进程运行时由TCP/IP协议随机选取的，范围在（49152～65535）。

显然了，还有中间一些端口号，这些是在IANA注册的端口号。

这一块我自己猜测就是考个熟知的服务的端口号吧，应该不会考范围。临时的也没啥好考，注册的话课本都没啥针对性。所以到时候记一下下面这张表：

我们刚刚讲过一个套接字的结构，IP+端口号。
那么要标识一个进程实际上需要一个三元组，是 协议+IP+端口号。无非多了一个协议。UNIX中这也称为“半相关”。应该不会这么恶心考这个吧？
然而当我们要进行通信时，需要的是一个五元组：
协议+源IP+源端口+目的IP+目的端口，UNIX称相关。

多路复用和多路分解：
这个技术用得还是比较广泛的，但不涉及计算机相关？？
我们需要了解就是这项技术的内容和含义：
其允许同时运行不同协议栈上的不同的进程，如下图所示：
SMTP，HTTP，DNS，SNMP同时运行，不难理解，你可以开网页的时候发邮件，可以边看电影边聊天……

OK小节结束。

对了，3.2原本应该是TCP和UDP对比，我寻思这儿连啥是啥都不知道搞吗子对比？
3.2
这一节仔细讲讲UDP。
这是传输层的一种协议，其设计核心思想是简洁高效。也正因为其简洁，其可靠性相较于TCP会较差。它较适合在低延迟、高可靠的局域网进行。
下面是特点简述：
【总感觉问答题这个还挺可能考的，不知道哪里的自信】
1.面向无连接，不可靠的传输协议。有人会说了，这是个锤子特点，害，咱也没说是优点是吧哈哈。 无连接会减少协议开销和传输的延时啊，**其报文结构里有校验和选项但只是可选项！**如果采用了校验和，且查出了这报文有问题，那么其只是丢弃，不会通知重传。对于UDP，一个较好的形容词就是“尽力而为”！
2.面向报文的传输。对于应用层提交的数据报文，其不做任何处理就是加个UDP头部，就会给到IP分组，最后成TPDU……
所以，这就要求我们数据报文长度适中。
太短？如果说UDP报文头比你数据报还长，那么效率大大降低。
太长？IP层会进行分段，对方需要为你重组，必然也会降低效率。

ppt上还有一些特点，如报文头短：只要8Byte【TCP 要20B】，支持多对多的交互通信。

报文格式：（8位 = 1Byte别忘了哦）

根据UDP协议的特点，我们可以总结出其适用的范围：
1.对性能的要求高于对数据完整性的要求。视频就是典型的例子，视频少掉一两帧你都反应不过来！卡死了你就骂街，垃圾网络，我***。
2.需要“简单快捷”的数据交换，只需要进行简单的请求和应答报文交互，如在线游戏。它问你“是or否”，你就点一个？我是这么理解的。
3.需要广播和多播的应用，源主机会恒定的发送报文，拥塞时会丢弃部分报文。

当然了其缺点也很明显。没有必须的差错控制机制，校验和只是可选的！
拥塞严重时缺乏必要的拥塞控制和调节机制，路堵了还往上开是不对的！

校验和
这个是差错控制一个较好的机制，TCP和UDP计算校验和方式是类似的。虽然老师说了这种题考了怕错一大堆（粗心，算错，漏了步骤……）所以可能会体谅一下我们不考 ，但还是掌握一下吧。
这里用课本上的例子看一遍：
1.我们会在UDP数据报上面加上一个伪报头，这个伪报头来自IP报头。
伪报头简要解释：
第一行变为4Byte的源IP，第二行则是4Byte的目的IP，填充0，协议号17为UDP，长度为15【和UDP自己的长度里的15是一致的】。
长度 = 4 × 3（第四、五、六行都是4Byte） + 3（第七行有3Byte，0是填充位，为了凑16的整数倍） = 15Byte
2. 先为校验和设置为0。
3. 不难看出我们每16bit一行写出。
4. 数据位也会补0至最后数据行也是16的整数倍。
5. 求和运算，注意是循环求和！
循环求和就是最高位有时候还会溢出，溢出位会再给到第一位，直到最后完全停止。

那么一定要注意转换（十进制->二进制千万先别搞错啊！！），还是别一串一起加吧，两两来吧……

应该是没啥问题的哈，后续想附一下代码，看看有没有简便方法。【还是有点麻烦。】

后续的话就是把此值插入到校验和中，删掉伪报头和填充位。
那么如何验证呢？
接收方得到的是有填充check sum的报文，同样是按上述操作：
加伪报头，数据位填充，分为16bit计算，循环求和，最后结果取反码，只要全为0，就可以证明报文正确。否则就认为报文传输过程中出错！！
【咱也不知道为啥，也没看过证明，但计算机的嘛，主要还是得会求上一个吧，后面这个证明不咋重要，但定理得知道！！】