Internet Protocols -- Transport layer

List

Application Layer

PPT : A3-1

- Intro.

- Socket

- Addresses in TCP/IP

Transport Layer

PPT : A3-1 A3-2 A4-1 A4-2

- Transport-Layer services

- Multiplexing & Demultiplexing

- UDP

- Reliable data transfer(R.D.T)

- TCP

- Congestion control

Application Layer

Intro.

没什么好说的，这是我们日常最接近的一层。因为我们都在使用着各类的网络应用。PPT上说：It is up to you to define the format of data your application writes and receives. 所以我们这里可以定义一些私有协议，比如qq聊天就是自己定义的协议。同时还有以下常用的协议：

• HTTP (Hyptertext transfer protocol) world-wide web
• FTP (File transfer protocol) moving data
• SMTP (Send Mail transfer protocol) sending email
• IMAP (Internet message access protocol) receiving email

Socket

中文名叫套接字，它是一个接口。与高级网络编程所学内容很容易理解它的作用。

At the application layer the “network” is abstracted away and you access a stream of data that arrives at a “socket”.

我们通过Socket来将数据流传入Transport Layer。这里会出现多路复用，也就是多个数据流通过一个Socket来进行传输。那么就需要有寻址过程。

Address in TCP/IP

以下就是TCP/IP模型中的四种地址

Physical address

· 也叫MAC 地址，处于数据链路层。他就是跟我们电脑上的网卡绑定的，一个网卡有一个mac地址，像人的身份证一样。具有唯一标识性，一旦与这个网卡绑定就无法更改。

Logical address

· 就是IP地址，处于网络层。IP地址是IP协议提供的一种统一的地址格式，它为互联网上的每一个网络和每一台主机分配一个逻辑地址，以此来屏蔽物理地址的差异。主机只要遵守IP协议，就可以与互联网中的计算机进行通信，而IP地址就是来确定通信主机的位置。

Tip：

IP 地址是基于逻辑的，比较灵活，不受硬件的限制，也容易记忆。而 MAC地址在一定程度上与硬件一致，是基于物理的，能够标识具体的网络节点。这两种地址各有优点，使用时也因条件不同而采取不同的地址。关于两者怎么使用见此图：

所以通常查封IP，也就是查封MAC地址。要解决IP被封的问题根本就是要修改MAC地址。

Port Address

端口号，就是对于每一个应用有一个端口号。信息进入主机后，根据端口号来确定发送给计算机上哪一个应用。所以它在传输层上，根据端口后确定Socket的位置，然后将数据流送入Socket。

Application-specific address

也就是URL(Uniform Resource Locator,统一资源定位器)。关于URL具体是啥，我可能也解释的不是很清。大概分为，本机上的，和非本机上的。

本机上的是啥呢，小学期跑tomcat的时候应该多有接触。当我们编译完代码部署到服务器上后。跳出的网站上的那行，就是URL，就是localhost：8080/EmailCode.jsp。而根据这行，我们也可以大体看出来URL的结构。localhost代表了本地IP，端口就是8080，也就是这个应用。而EmailCode.jsp就是这个路径下的jsp文件，对应着这个网页。

 那非本机的是啥呢，我们输入网站时候经常会看到一大串比如：HTTP://。。。。。。。。。

反正各种数字字母和符号的组合，但是他的形式就跟上面本机的一样，你可以理解为这个jsp文件在别人的电脑上，你需要通过这个URL来请求服务器，从而访问这个网站。

URL的格式就是 protocol :// hostname[:port] / path / [;parameters][?query]#fragment 

这里不详说了就

Transport Layer

Transport-Layer services

运输层协议为运行在不同主机上的应用进程之间提供了 逻辑通信(Logic communication) 功能。

这是啥意思呢，从应用程序的角度来看，通过逻辑通信，运行不同进程的主机好像直接相连一样。但是实际上，它们可能在地球的两端，通过很多路由器及不同类型的链路相连。应用进程使用运输层提供的逻辑通信功能彼此发送报文，而无须考虑承载这些报文的物理基础设施的细节。就比如我们的qq实时聊天。好像两个人就在一块，但其实隔着很远。就像这张图里的内容：

 但是对这张图更详细的描述是：运输层协议是在端系统中实现而不是路由器。在运输层为报文增加一个运输层首部。然后传递给网络层，网络层并不会检查这个封装的头部。相应的头部只在相应的层内处理。

啥意思呢，就是运输层和网络层是隔开的。它们中间仿佛有一道门，它们可以把东西从门拿入，从门拿出。但是并不知道门的那边对这个东西干了什么。所以我们来进一步看运输层和网络层的关系。

网络层提供了主机之间的逻辑通信，而运输层为运行在不同主机上的进程之间提供了逻辑通信。

上面讲到这种逻辑通信就像是把两个东西连在一起，连接主机和连接进程还是有区别的。课本给了一个很好的例子。通过这个例子，我们也能更好理解这个关系以及后续要讲的内容。

在继续讲解后面的知识前，需要简单了解一些IP。

因特网网络层协议有一个名字叫IP ，叫网际协议。IP为主机之间提供了逻辑通信，它是不可靠服务。然后每台主机都有一个IP地址。

Multiplexing & Demultiplexing

运输层的多路复用和多路分解，也就是将由网络层提供的主机到主机交付服务延伸到为运行在主机上的应用程序提供进程到进程的交付服务。多路复用和多路分解是一个对应的，两个一定同时存在。切所有计算机网络都需要这两个服务。

大白话就是，将一对进程的数据合一块传输就是多路复用。然后将这些数据分解到相应的进程上就是多路分解。

我们看到这两个服务是在Socket上实现的。它是如何实现的呢？

首先每个套接字都有唯一标识符，每个报文段都要有特殊字段来指示该报文段要交付的套接字。具体往下看 

传输层协议只有UDP和TCP，我们要选择一种来进行传输。而它们都对应着不同的多路复用与分解。上面这个过程大概就是UDP的。

因为UDP是无连接的，所以就是Connectionless multiplexing & demultiplexing。

而TCP更为复杂一些，且需要连接，所以就是Connection-oriented multiplexing & demultiplexing

UDP和TCP都对应着不同类型的Socket，他们的标识不一样。

这里开始看比较乱，建议上下比对着看。

Connectionless multiplexing & demultiplexing

UDP套接字由一个二元组全面标识的，该二元组包含一个目的IP地址和一个目的端口号。

UDP报文段包含一个源端口号和一个目的端口号。

“两个UDP报文段可能有不同的源IP地址，有不同的端口号，但具有相同的目的IP地址和目的端口号，那么这两个报文段将通过相同的目的套接字被定向到相同的目的进程。”

Connection-oriented multiplexing & demultiplexing

TCP套接字由一个四元祖全面标识的，该四元祖包含一个源IP地址，一个目的IP地址，一个源端口号和一个目的端口号。

TCP报文段包含一个源端口号和一个目的端口号。

“两个TCP报文段可能有不同的源IP地址，有不同的端口号，就算具有相同的目的IP地址和目的端口号，这两个报文段也会用过不同的目的套接字被定向到相同的目的进程。”

来解释一下，多路复用和分解是怎么实现的呢。比如你的计算机上面有2个UDP进程，3个TCP进程。（可能有问题，大体意思就是这样）

那么就生成2个UDP套接字，3个TCP套接字，同时用IP和端口号来标识相应的套接字。不同进程的数据从相应进程下的套接字进入传输层，被封装进UDP或者TCP内标识上源端口号和目的端口号。然后这一堆UDP，TCP小块就被弄成一个大块，这就是多路复用。然后传入网络层被标识上主机的IP地址。

然后用下面几个层传输，到达对应主机，数据被一层层的拆解到的目的主机的运输层。

这个大块被拆回原来的小块，根据小块内部的源端口号和源IP地址，分配进对应的套接字。UDP块就去找UDP套接字，并匹配端口号。TCP块就去找TCP套接字，并匹配IP地址和端口号。经过套接字后，就到达了对应进程。

所以为啥TCP就需要这个IP呢，看起来多此一举是不是。

后续会讲到，UDP是不稳定的，无连接的。所以他的多路复用和分解也是无连接的，也就是你不知道这个数据来自那个主机，是谁发给你的，你只是收到了而已。

TCP是需要连接的，稳定的。所以多路复用和分解是连接的，那么你就必须知道这些数据来自那台电脑。我其实也不是特别清楚，可以看一下这张图里说的：

这是课本的一个例子，当回传的端口号一样后，IP的作用就体现出来了。

Connectionless transport: UDP

为什么是无连接的？

在使用UDP时，发送报文段之前，发送发和接收方的运输层实体之间没有握手。关于什么是握手，具体细节会在TCP里

使用UDP的应用有很多，比如之前提到的DNS(域名解析)

UDP报文段结构

 如图所示，UDP是传输层协议，在接收到应用层的报文(message)后，将其传入传输层并封装成UDP报文段(segment)，也就是为message加一个运输层头部。

如图所示，应用数据就是应用层的message。上面的就是加入的传输层的头。

长度字段是指示了在UDP报文段中的字节数(首部加数据，因为每个UDP携带的数据不一样，所以需要指明长度)

UDP检验和(CheckSum)

UDP检验和提供了差错检测功能。

检验和是用于确定当UDP报文段从源到达目的地移动时，其中的比特是否发生了改变

也就是检验是否有0变1，1变0这种错误。这个没什么好说的 

Reliable data transfer(R.D.T)

这是一个可靠数据传输模型的发展过程，我们通过不断引入新的问题来寻找解决方案，从而克服数据传输中的差错。而最终 形成的模型中的原理，就是TCP的基础。

首先，我们在这节中关注的是传输层，对于TCP/IP模型，每层之间是分开的，每层都会提供属于它本层的服务。而对于每层来说，都有对应的协议来确保每层的数据传输可靠

我们如何传输层实现可靠的数据传输呢？

我们将这种服务模型抽象成如下所示：

如果我们想达到左边的，传输层是一个可靠的信道(当然这在现实是不可能的，因为没有完全可靠的信道)

我们就专注于传输层的协议定义，而假设传输层以下为一条不可靠信道，这条不可靠信道可以导致数据出错，丢包，等等等等。

而我们通过修改传输层协议，来克服不可靠信道中出现的问题

这个一步步解决的过程就是RDT的发展过程

 这里解释一下四个方法，在后续都会一直出现

rdt_send()：上层调用传输层发送端来发送数据，rdt代表可靠数据传输协议

udt_send()：传输层调用底层来信道传输数据，udt代表不可靠数据传输协议

rdt_rcv()：数据从信道到达接受端时，调用该方法来接受数据

deliver_data()：当运输层要向更高层交付数据时，会调用该方法

Finite State Machine

有限状态机，就是一种表示方法。当执行一个操作后，会引起机器状态的变迁

rdt1.0

我们考虑，底层信道完全可靠

那么我们只需要简单的发送，接受就好。数据在这个过程不会出现任何差错及丢失。

这里解释一下图中的写法，引起变迁的事件显示在表示变迁的横线上方，事件发生时所采取的动作显示在横线下方。如果对于一个事件没有动作，或没有就事件发生而采取一个动作，就在横线上方或下方使用符号A(应该是A去掉中间那一横线)

对于发送端

在上层调用的时候，执行rdt_send(data)，向着接收端发送数据，引起发送端状态变迁

变迁所采取的动作就是make一个packet并且通过udt发送

对于接收端

执行rdt_rcv(data)，接受发送端传来的数据，因为信道可靠，没有任何差错，然后引起接收端状态变迁

变迁所采取的动作就是提取数据并且交付给高层应用

rdt2.0

我们考虑，底层信道中可能导致比特差错

在分组的传输、传播或者缓存的过程中，比特差错经常会出现在网络的物理部件中

解决方案，引入ACK(Positive acknowledgment)，NCK(Negative acknowledge)机制，检测出错误后重传数据包

看图也很好懂，也就是使用checksum来检测是否出现比特差错，然后将检测结果通过ACK，NAK来传输

对于发送端

收到上层调用后，发送数据包(数据+checksum)。然后进入等待ACK或NAK状态

接收端收到数据包后计算checksum，并且与发送来的checksum进行比较

如果接收到ACK(接受端接受数据正确)，就回到等待调用状态来准备继续发送数据

如果收到NCK(接收端接受数据发生比特差错)，就将数据重新发送并且继续等待ACK或NCK

对于接受端

收到数据后，如果是正确的(notcorrupt)，就生成一个包含ACK的包并发送，同时提取数据交付给上层

如果是错误的(corrupt)，就生成一个包含NAK的包并发送

rdt2.1

在rdt2.0的基础上，我们考虑包含ACK，NCK的包也会出现比特差错

rdt2.0的实现，是保证ACK，NCK的传输不会出任何错误，但是它俩也是数据包也会出先比特差错

解决方案，为ACK，NCK编号

我们这里只有0，1编号，其实就是在rdt2.0的基础上，对于每个ACK，NAK的包增加一个编号，当一个编号的包出错，我们就可以请求另一方对这个编号的包重新发送

对于发送方

当上层调用发送方后

发送一个编码为0的数据包(数据+checksum)，然后进入等待编码为0的ACK或NAK的状态

如果收到编码为0的NAK的包，那么重新传输编码为0的数据包

如果收到编码为0的ACK的包，那么进入调用状态，而且这次发送包的编码将是1

当上层再次调用发送方来发送下一个数据包后

将发送一个编码为1的数据包(数据+checksum)，然后进入等待编码为1的ACK或NAK的状态

如果收到编码为1的NAK的包，那么重新传输编码为1的数据包

如果收到编码为1的ACK的包，那么进入调用状态，而且这次发送包的编码将是0

因为我们这里只有0，1两个编号，所以在这两个过程中循环往复。当然不一定从0开始，也可以从1开始，这是一个圈，从谁开始都是在这个圈子里循环

对于接受端

假设先收到编号为0(has_seq0)的包

如果正确(notcorrupt)，那么将会发送编号为0的ACK，然后进入等待编号为1的状态

如果错误(corrupt)，那么将会发送编号为0的NAK，然后继续在等待编号为0的状态

1也是一样的，在这两种状态中循环往复

rdt2.2

在rdt2.1的基础上，我们继续改进，简单化模型来提升效率

对于上面的功能，其实只需要ACK就可以实现，我们的模型当然是越简单，成本越低，效率越高，所以我们在这里改进一下

解决方案：只使用ACK，去掉NCK

对比上面这个也很好理解就不赘述了，就是接受方的重传机制改成收到不对应的ACK，那么只要在接受端发现错误后发送一个不对应编码的ACK就可以告知发送端出错让它重传

rdt3.0

在rdt2.2的基础上，我们开始考虑，在传输过程中丢包，或者过度时延的问题

在包的传输过程中，可能会出现丢包的错误。这跟比特错误是完全不一样的。当丢包后，总有 一方会一直在等这个包的到达，但是已经丢失的包是不可能到达的。这样就无法进入下一个状态而彻底卡在一个状态。

那么我们就需要思考怎么检测出丢包，并且解决。

解决方案：增加计时器

我们增加一个计时器，并且设定一个时间。当超过了这个时间后，这个包还没传过来，我们就认定这个包丢失在传输过程中，并且请求重新发送。

对于发送方

当发送编号为0的数据包后，会同时启动计时器，然后进入等待编号为0的ACK的状态

如果收到编号为1的ACK(比特差错)会继续等待编号为0的ACK

如果time_out超时(丢包)则会认为0号数据包丢失，并且重新发送，然后重新计时

如果收到编号为0的ACK，则传输成功进入等待发送编号为1的状态，和等待0的状态一样

对于接收方，依旧和rdt2.2类似就不赘述了。

这张图列出来各种可能出现的状况，这种分组在0，1之间交替，所以rdt有时候也被称作比特交替协议。

这里多提一些，应该由谁来规定这个计时器的时间呢？

如果时间过长，会导致延迟加大。

如果时间过短，那么会导致数据发送冗余，详情可以见下图中的 d）

所幸的是，在rdt2.2中我们就解决了这种数据发送冗余。比如你看d)，因为过短导致两个ACK1被连续发回来。在接受到第一个ACK1的时候，就会进入等待ACK0的状态。所以就算再次收到ACK1，那么也会继续在等待ACK0的状态，直到收到ACK0。详情可以看rdt2.2的图

而这个时间长短，后续会具体介绍一种算法

总之，我们引入了ACK，NAK，Checksum，timer

构成了我们的rdt协议，实现了运输层数据的稳定传输

流水线可靠数据传输协议(Pipe-line)

rdt3.0虽然可靠，但是性能过差。这里我们先定义一下如何计算性能：

直接看这张图比较直接 

RTT(Round trip time) 也就是数据包过去回来的时间，注意是过去再回来，有时候可能只给一个过去的时间，要乘二

t=L/R，可以理解为数据包上传到信道的时间，数据包长度L除以上传时间R

而衡量性能的U就是t在这个时间内的占比，我们可以看到rdt的性能很差。

你可以理解为，传输一点数据，就要很多时间。

所以我们应该怎么提高呢？那就是让单位时间内传输更多的分组

所以我们引出了流水线协议

可以理解为rdt3.0一次就传一个分组，而流水线一次会传一串分组，但是他们的RTT基本相差无几，所以性能就提高了很多。

这部分的计算需要注意一下单位的变化

 流水线协议具体分为两种

Go-Back-N(GBN)

Selective Repeat(SR )

TCP

Congestion control

停更了，跑去更高编去md