看课本学习：传输层

前言

本文是复习原来的课本《计算机网络（第6版）》而总结出来的梳理思维的小笔记，因为内容也比较多，一次是整理不完了，所以又是慢慢补坑。若有错误欢迎提出(ง •_•)ง。

为什么会出现传输层

我们知道网络层的IP协议可以通过IP地址来帮助我们定位到某一台电脑，但是真的在进行通信的是电脑上的进程，所以我们需要一个东西来区分不同电脑的不同进程，这也是为什么会出现一个传输层。
但是这里就会出现一些问题：

1. 不同的操作系统的进程标识符格式不同。
2. 进程的创建和撤销是动态的。
3. 我们需要的终点入口是功能，而不是实现这个功能的进行是哪一个。

解决的方法：使用协议端口号（简称端口）
虽然通信的终点是应用进程，但我们只要把传送的东西交给端口，剩下的工作就由传输层的协议来完成。

关于端口

端口の分类

1. 服务器端使用的端口号
   熟知端口号（0~1023）：分派给TCP/IP重要应用程序，如DNS是53，SMTP是25。
   登记端口号（1024~49151）：为没有熟知端口号的应用程序使用的。
2. 客户端使用的端口号（49152~65535）。又叫短暂端口号，客户进程运行时才进行动态选择。通信结束后，端口号就会不复存在，后面又会分配给新的客户进程使用。

传输层的两种协议

分别是无连接的UDP和面向连接的TCP。

UDP

UDP是无连接的

发送数据之前UDP不需要像TCP一样建立连接，所以减少了开销和时延。

UDP尽最大努力交付

UDP是不保证可靠交付的，也就是传输很快，但是不保证质量。

UDP面向报文

• UDP对于应用层给它的报文：不合并和不拆分，只是保留边界。所以应用层给它多少，他就一次性发多少。
• UDP对于网络层给它的报文：去除首部之后，就原封不动的都给应用层。

UDP没有拥塞控制

所以即使出现网络拥塞，主机的发送速率也不会降低。对于视频在线直播，网络电话之类的应用来说是很有效的，它们需要实时的传输速率，又可以适当的有数据的损失。

UDP支持x对y的交互通信

这句话的意思是UDP支持下面四种通信：

• 一对一
• 一对多
• 多对一
• 多对多

UDP首部开销小

UDP首部只有8个字节，而TCP首部有20个字节。
UDP首部的结构：

1. 源端口
2. 目的端口
3. 长度
4. 检验和

这里每个都是占了2个字节。

UDP的伪首部：
在UDP的8个字节首部的基础上，其实还有一个12字节的伪首部。
之所以是伪首部，是因为它址在UDP计算检验和的时候临时添加在数据报前的：

• 这个伪首部不会给应用层也不会给网络层。
• 检验方法是把首部和数据部分一起检验。
• 如果检查错误，就丢弃/带着警告交给应用层。

TCP

TCP是面向连接的

应用程序在使用TCP协议前，必须要通过三次握手进行建立，要经过四次挥手来结束连接。
来插一个自己画的有机物小剧场，帮助记忆：

Q：为什么是三次握手，不是两次握手？
A: 在某种情况下，假如只有两次握手，第一个分组在路上延迟发送了，等到传输结束后，服务器又收到了SYN请求，此时建立连接的话就迟迟得不到客户端的回应。

每条连接只能有两个端口

TCP连接的端口叫做套接字（插口），注意很多地方都有这个套接字的概念，但是在这里它的定义是：

端口号+IP地址

每一条TCP连接唯一地被通信两端的两个端点所确定。

TCP提供可靠交付的服务

现实情况下：

1. 传输信道可能会有差错。
2. 接收方可能不能及时处理收到的数据。

所以我们必须要想办法来应付这两种情况，才能实现可靠的服务：

停止等待协议

我们假设只有年糕君在发送数据，有机物在接收数据，并发送确认（但是现实是双方都可以作为发送方和接收方）。

• 正常情况下，年糕君发送数据后，有机物收到后再回复一个确认的消息，年糕君收到这个确认的消息才会继续发送下一个。

情景一：发送分组丢失
如果一开始年糕君发送的数据块M丢失了，有机物迟迟没有回应，年糕君会通过等待回应的时间来判断块M是不是丢失了，然后就选择重发，这就是超时重传。

• 所以必须给予年糕君一个超时计时器，如果年糕君收到有机物确认的时间比定时要早，那就撤销目前的计时，继续发送下一个数据块。

注意点：

1. 年糕君在发送一个分组后，必须要保留发送分组的副本。
2. 分组和确认分组必须进行编号，这样才能明确哪个收到了哪个没收到。
3. 计时器设置的重传时间应该比数据在分组传输的平均往返时间更长。

情景二：确认丢失
如果有机物给年糕君的对数据块M的确认丢失了。年糕君在设定时间内没有收到确认，就会又发送一个M的副本，有机物收到后此时应该：

• 丢弃这个重复的分组
• 向年糕君发送确认，以免年糕君又继续重发M副本。

这样我们就可以实现在不可靠的传输网络上实现可靠通信，这种协议通常称为：自动重传请求ARQ。

停止等待协议的缺陷
信道利用率太低。
因为年糕君必须要等到收到有机物的确认才能发送下一个，这其中包括了很多时间，除了包括分组和确认的发送时间，还要加上往返时间（RTT）。但这个过程的核心只是分组发送的时间。

解决方法
采用流水线传输，也就是年糕君可以一次性发送多个分组，不必收到确认才发送下一个。

TCP提供全双工通信

所谓全双工通信的定义是：

通信的双方可以同时发送和接收信息的信息交互方式

TCP允许通信双方在任何时候都能发送数据。
So，为什么？
因为发送方和接收方都拥有发送缓存和接受缓存，存放双向通信的数据。
所以，应用程序把数据块放进缓存里后，就可以去做自己的事情了。比如在发送的时候，只用丢给缓存，就可以拜拜啦，在接收的时候，有需要再从缓存里去拿行了。

传输是面向字节流的

Q：什么是“流”？
A: 流入到进程或从进程流出的字节序列。

虽然程序和TCP的交互是一个个数据块（大小不等），但TCP认为这些都只是一串无结构的字节流。
【虽然我的漫画画的是一个个小块（包裹)，但这个小块是可以被拆开，然后把里面的东西（字节）取出来一些或者填进去一些( •̀ ω •́ )】
它不保证发送方的数据块和接收方的数据块是一样的大小，比如你给了它10个块，但是它只用了4个块就把你传来的东西送给它的上级了。
TCP是根据当前的窗口值和拥塞情况来决定一个报文段包含多少字节的。如果TCP缓存数据块太长，就划分短一点再发，如果进行一次只发来一个，就等到足够字数再发送出去。