【Coursera】Sixth Week(1)

Transport Layer

在学习完 Link Layer(Ethernet)，Internetwork Layer(IP)之后，我们来到了TCP/IP协议簇的上半部分。

Review：Magic of IP

它做了啥？想办法把数据报从一个网络 通过 5 - 20 个路由器 转递到另外一个网络。

保持对网络中 畅通 或者 堵塞的路径 的跟踪，如果有可能的话想办法选择更好的路径。

但是不能保证 数据能到达目的地，如果转递过程中出现了差错，数据报会被丢弃。

这使得 它非常快速，和可伸缩性(scalable)，最终 “具有可靠性”，因为它并没有把所有的事情都做了。

Internet Protocol

很多连接，节点。

很多路由。

Thinks can change dynamically(动态地)，and the IP has to react(link up/down).

IP 有可能会扔掉 packet。

TCP：Transport protocol

• Build on top of IP.
• Assume IP might lose data.
• In case data gets lost, we keep a copy of the data. We send until we get an acknowledgement.
• If it takes "too long", just send it again.

TCP 弥补了在IP层中可能的错误，同时也使用了可用的资源。

底层的网络 有多快？(快的话，目的是节省时间，慢的话，目的是为了提高效率)它很可靠吗？如果底层的网络数据传输出现了错误，怎么办？这就是TCP考虑的问题。

所以 TCP协议 的核心是 如果我们发送了一些数据报，我们把它分片成一些 分组，然后我们一片片的发送它们，如果发送端收到了目的端的ACK(acknowledgement)，就可以准备发送下一个数据了。与此同时，如果某些数据报片丢失了，发送端会重新发送数据报，直到收到目的端的ACK为止。

所以这就是 TCP 所做的最基本的工作。

这里有一个例子：

一个数据报被分成五片，大小分别是：100，200，300，400，500字节。首先 我们发送 100，200，300字节的三片数据，100，300到达目的地，200在途中销毁。过了一段时间，接收端发送ACK 告诉 发送端：

嘿，老哥，我收到了你发送的两片数据了，他们是 100 和 300，但是我还没有收到200的，能不能给我发送一下？

当然，发送端就“猜到”200的数据报片在转递过程中被遗失了，由于接收端已经收到了100，那么发送端丢弃了100的数据报片，从200开始重新发送。

第二次，发送端 发送200 和 300的数据报片，接收端发送ACK确认收到了。于是发送端继续发送 400，500 的数据报片，并且丢弃 200 和 300 的数据报片。dotdotdot···

所以，这有点像在 TCP的接收端和发送端 记账一样。

设计IP层的时候，我们要求它很快速，很灵活，但是我们同时也给予了它丢弃数据报的权力，我们并没有要求IP层进行存储的工作。

但是，很明显，在网络中有很多的路由器，连接上网络的PC却是以亿计数的。我们需要让数据的传输具有可靠性，所以在PC上我们需要有足够的内存来存储这些数据以防万一：在必要的时候重新发送数据报。

当我们连接一台计算机到网络上的时候，我们就在这台计算机上配置了内存来存储发送的数据，所以当计算机在发送数据的时候，它负责对发送的数据报进行复制并且保留复制品。它并不期望网络来做这个事情。

这非常的 absolutely brilliant，这个机制给互联网带来了无穷的好处。

当然了，在成功的背后，同样有许多的工程师为这个机制做出了贡献。

在1980年，很多人预言，Internet即将消亡，当时的学术界的技术不足以支撑Internet的发展。越来越多的计算机连接到网络中，导致网络越来越慢，逐渐有“crash”的倾向。

工程师 Van Jacobson 拯救了“世界”，发明了TCP协议。

Van Jacobson - Slow Start Algorithm

Van Jacobson：Packet Design，PARC首席工程师。

网络通过在不同的大学聚集的方式 逐渐地扩大。NFS 用56kb的电缆 把这些校园网络连接到了一起，形成了NSFNET 一期。这在当时很受欢迎，人们可以通过网络交流，发电子邮件等等。但是每一个校园都会让当时的网络超负载，丢失了很多分组。

当时 Van 在 Lawrence Berkerly 实验室做 high-energy 的物理实验，同时也在 Berkerly 校园教书，在上个世纪八十年代，每一门课都有一个信息群，任何作业都会被发送到网络上，Van 通过网络下载下来课程的资料，但是当时的网络非常缓慢，吞吐量为0，大概十分钟一个分组，这就很糟糕了。于是 Van 就和 Mike Karels 一起商讨，Mike 当时也领导了开发 Berkerly Unix 的BSD团队，他也被这个问题所困扰。

那个时候，运行TCP/IP最简单的方法就是，启动 Berkerly Unix，在 Unix 上有一个程序，但是性能实在是有点糟糕。这个小程序在运行小规模的测试的时候崩溃了，Van 和 Mike 花了很长的一段时间来找错误，尝试找出原因。他们的关注点就来到了 协议是如何处理这些带宽的变化，如何处理多个跳数。

接收端发送的 ACK 就像时钟一样，提醒 发送端 什么时候是安全的时刻来发送一个新分组。

TCP 运行的时候是相当完美的，但是困难的地方就在于 启动的时候，如果你突然启动，很容易造成某个网关的缓存饱和，当你重新发送的时候，又重新做了一遍这种我们不想看到的事情，所以总是会丢失分组。但是如果你逐渐的启动，就会得到一个时钟(ACK)来控制 TCP数据报输出队列，以便控制缓存，防止缓存过载。

那么是如何把这种机制 引入进全球的 TCP/IP 系统中呢？

Van 非常的机智，开发组里的内核黑客们开发了一个内核的程序，通过这个程序可以获取数据报，并导致内核错误。他们把这个程序通过全球用户的邮件列表(当时规模不大)用邮件发送到了网络上，许多用户来下载这个东西，并提供错误的反馈，Van 于是 发布了很多次新的版本，修改了这一错误，并且也潜移默化的把这个机制植入了用户的系统中。

2016/8/4